Geschäftsprozesse im Zeitalter der Digitalisierung - Einführung und Überblick (in Arbeit, Vers. 2022/1)

©2020, 2021, 2022 Josef L. Staud

Autor: Josef L. Staud

Stand: Februar 2022

Dieser Text ist im Entstehen. Die Vorabinformation dient der Seminarunterstützung.

Aufbereitung fürs Web

Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator (Version 2021-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. Dies erfolgt inzwischen in zwei Versionen: mit und ohne Frames. Derzeit (2022) werden beide Versionen paralell angeboten.

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 Verzeihung und um Hinweise (hs@staud.info).

Urheberrecht

Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Warenzeichen und Markenschutz

Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Prof. Dr. Josef L. Staud

 

Vorwort, Inhalt, Abkürzungen

Vorwort

Der vorliegende Text ist mein Manuskript zur Thematik Geschäftsprozesse im Zeitalter der Digitalisierung. Es dient – in Vorlesungen und Seminaren, innerhalb und außerhalb von Hochschulen – der Seminarunterstützung. Zahlreiche Hinweise auf vertiefende Literatur helfen, die Lücken zu füllen und die Ausführungen zu ergänzen.

Eine Besonderheit des Textes ist, dass neben den fachlichen und betriebswirtschaftlichen Aspekten auch IT-technische angesprochen werden. Der Grund ist, dass Geschäftsprozesse schon seit einiger Zeit mindestens IT-gestützt, oft auch automatisiert realisiert werden und dass dies das Geschäftsprozessmanagement grundsätzlich verändern wird.

„IT + GP(M)“

Dieser Text ist "im Entstehen". Er wird voraussichtlich 2022 fertig sein. Die Vorabveröffentlichung dient der Seminarunterstützung.

„Unfertig“

Vereinzelt sind Fragen und Hinweise in den Text eingebaut, die zur Vertiefung und als Kontrollfragen dienen können. Diese sollen in den nächsten Monaten noch zahlreicher werden.

Fragen und Hinweise

Die Kapitel zur Modellierung mit Ereignisgesteuerte Prozessketten (13) und mit der Business Process Model and Notation (BPMN) (14) sind Zusammenfassungen der Bücher

  • Staud, Josef Ludwig: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014.
  • Staud, Josef Ludwig: Geschäftsprozessmodellierung mit der Methode Business Process Model and Notation (BPMN). Vilshofen 2017.

Kapitel 20 ("Geschäftsprozesse im Internet – NoSQL et al.") ist eine leicht veränderte ("zugeschnittene") Zusammenfassung von Kapitel 24 in

  • Staud, Josef: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. Hamburg 2021 (2. Auflage).

Hinweise zu Bezugsmöglichkeiten der Bücher finden sich auf www.staud.info.

Prof. Dr. Josef L. Staud

 

Inhaltsverzeichnis der Buch- und PDF-Version

Vorwort, Inhalt, Abkürzungen 3

1 Einführung 15

1.1 Prozessgedanke 15

1.2 Geschäftsprozesse 16

1.3 Geschäftsprozessmanagement 16

1.4 Digitalisierung und Automatisierung 21

1.5 Begrifflichkeiten 21

1.6 Einbettung 21

2 Geschäftsprozesse 23

2.1 Herkunft 23

2.2 Grundbegriffe 25

2.3 Definitionen 28

2.4 Art der Problemlösung 36

2.5 Art der Aufgabe 37

2.6 Wichtige Eigenschaften 41

2.7 Geschäftsprozesse im Zeitalter der Digitalisierung 43

3 Kategorisierung von Geschäftsprozessen 45

3.1 Kern- und Supportprozesse 45

3.2 Steuerungs- und Führungsprozesse 49

3.3 Primäre und sekundäre Geschäftsprozesse 49

3.4 Kreative / wissensintensive Prozesse 50

4 Identifikation und Standardisierung 51

4.1 Identifikation 51

4.1.1 Top Down oder Bottom Up 51

4.1.2 Orientierungsrahmen für die Prozessgestaltung 54

4.2 Standardisierung 54

5 Ist- und Sollmodellierung 57

5.1 Istmodellierung 57

5.1.1 Werkzeuge 58

5.1.2 Zweck? 59

5.1.3 Mögliche Schwachstellen 60

5.2 Sollmodellierung 61

6 Strategisches Geschäftsprozessmanagement 63

6.1 Einleitung 63

6.2 Prozessvision und Prozessziele 64

6.3 Kernkompetenzen 65

6.4 Ergebnisse 66

6.5 Zielsystem 66

6.6 Prozesseffektiviät und -effizienz 68

7 Prozesscontrolling 71

7.1 Operatives Prozesscontrolling 71

7.2 Strategisches Prozesscontrolling 73

7.3 Prozesskennzahlen 75

7.3.1 Ausgangspunkt, Voraussetzungen 76

7.3.2 Arten von Kennzahlen 77

7.3.3 Gestaltung von Kennzahlen 78

8 Reifegrade 79

8.1 Einführung 79

8.2 Assessments 79

8.3 Reifegradmodelle 80

8.4 Capability Maturity Model Integration (CMMI) 81

8.5 SPICE/ISO 15504 84

9 Risiken erkennen und beherrschen 87

9.1 Worum geht es? 87

9.2 Risikomanagement in Geschäftsprozessen 88

9.3 Risiken heute 88

10 Qualitätsmanagement und Performancesteigerung 91

10.1 Qualitätsmanagement 91

10.2 Performancesteigerung 94

10.2.1 Prozesserneuerung / BPR 94

10.2.2 Prozessverbesserung 96

11 Vorgehensmodelle für das GPM 97

11.1 Nach Becker 97

11.2 Nach Schmelzer/Sesselmann 98

11.3 Nach Österle 98

12 Prozessmodelle, Prozessmodellierung 101

12.1 Gründe, Ziele, Realisierung 101

12.2 Grundsätze ordnungsgemäßer Modellierung 103

12.2.1 Fachliche und technische Prozessmodelle 104

12.3 Basiselemente einer jeden Prozessmodellierung 104

12.4 Methoden für Abläufe 110

12.5 Ergänzende Modellierung 112

12.6 Grenzen der Prozessmodellierung 113

12.7 Software für die Prozessmodellierung 114

13 Methode EPK 115

13.1 Einführung 115

13.2 Elemente 116

13.2.1 Funktionen 116

13.2.2 Ereignisse 117

13.2.3 Organisationseinheiten 118

13.2.4 Informationsobjekte 119

13.2.5 Operatoren und Kontrollfluss 121

13.2.6 Zeitliche Dimension und Zeitverbrauch 122

13.3 Aufbau Ereignisgesteuerter Prozessketten 123

13.3.1 Anfrageprüfung Teil 1 123

13.3.2 Anfrageprüfung Teil 2 125

13.3.3 Anfrageprüfung Teil 3 128

13.3.4 Anfrageprüfung Teil 4 130

13.3.5 Instanzen 133

14 Methode BPMN 138

14.1 Geschäftsprozesse in der BPMN 138

14.2 Einführung durch Beispiele 140

14.2.1 Das erste Business Process Diagram 140

14.2.2 Jetzt mit Daten 142

14.2.3 Träger der Aktivitäten 143

14.3 Öffentliche Geschäftsprozesse 144

14.4 Aufgabentypen 146

14.5 Subprozesstypen 149

14.6 Ereignisse 154

14.7 Gateways 157

15 Ebenen und Muster 159

15.1 Verschiedene Ebenen 159

15.1.1 Vertikale Dimension 159

15.1.2 Prozess- vs. Funktionsmodellierung 163

15.1.3 Prozesslandschaften 163

15.2 Muster in Geschäftsprozessen 165

15.2.1 Geschäftsprozess starten 166

15.2.2 Geschäftsprozess beenden 167

15.2.3 Entscheidungsfindung 167

15.2.4 Abstimmung von Prozesshandeln 168

15.2.5 Teilaufgaben anstoßen 168

15.2.6 Bedingungen – einfach 168

15.2.7 Bedingungen – Kombinatorik 168

15.2.8 Wiederholungen 168

15.2.9 Zeitpunkte 169

15.2.10 Zeitfenster 169

15.2.11 Warten 169

15.2.12 Delegation 169

15.2.13 Zusammenarbeit über Abteilungsgrenzen 169

15.2.14 Zusammenarbeit über Organisationsgrenzen 170

15.2.15 Informationsweitergabe, -verarbeitung 170

15.2.16 Optionales Handeln 171

15.2.17 Automatisierte Abläufe 171

15.2.18 Überwachen, Kontrollieren 171

15.3 Muster mit der BPMN 173

15.3.1 Entscheidungsfindung 174

15.3.2 Teilaufgaben 178

15.3.3 Geschäftsprozess / Tätigkeit starten 179

15.3.4 Wiederholung, Rückschleife 185

15.3.5 Bedingungen 186

15.3.6 Zeitaspekte 189

15.4 Muster mit EPKs 191

15.4.1 Entscheidungsfindung 191

15.4.2 Teilaufgaben und Tätigkeiten starten 194

15.4.3 Zeitfenster 196

15.4.4 Zeitpunkte 198

15.4.5 Bedingungen 200

15.4.6 Kombinatorik 202

15.4.7 Warten 206

15.4.8 Wiederholung, Rücksprünge 207

15.4.9 Repetitive Handlungen 214

15.4.10 xxx Überwachen, Kontrollieren 216

15.5 Basismuster in Geschäftsprozessen mit EPKs 218

15.5.1 Mögliche Anordnungen 218

15.5.2 Ereignisverknüpfung mit auslösenden Ereignissen 221

15.5.3 Ereignisverknüpfung mit erzeugten Ereignissen 224

15.5.4 Funktionsverknüpfung mit auslösenden Ereignissen 229

15.5.5 Funktionsverknüpfung mit erzeugten Ereignissen 234

16 Referenzprozessmodelle 245

16.1 Einführung 245

16.2 Wertkette von Porter 247

16.3 Das ARIS-Konzept 250

16.4 Das Handels-H 253

16.5 Nach Schmelzer / Sesselmann 254

16.6 Das SCOR-Modell 258

16.7 Das EFQM - Modell 261

16.8 S-BPMN 263

16.9 Weitere Referenzmodelle 264

17 IT-Unterstützung der Prozessabwicklung 265

17.1 Historische Entwicklung 265

17.2 Dauerthema Integration 274

17.3 ERP-Software 275

17.3.1 Definition 275

17.3.2 Grundlage 278

17.3.3 Echtzeit und Datenintegration. 280

17.3.4 Beispiel SAP 281

17.3.5 Aktuelle Situation 283

17.3.6 Konsequenzen 283

17.3.7 Vor- und Nachteile 284

17.3.8 Perspektiven 285

17.3.9 Nicht nur ERP-Software 285

17.3.10 Die führenden Anbieter 285

17.4 Workflow-Management-Systeme 286

17.4.1 Definition 286

17.4.2 Softwareseitige Realisierung 287

17.4.3 Automatisierungsstufen 288

17.4.4 Workflow-Management Coalition 289

17.4.5 Beispiele 289

17.5 Serviceorientierte Architekturen 289

17.6 Weitere Anwendungssysteme 293

17.6.1 CRM 293

17.6.2 SCM 293

17.6.3 PLM 293

17.6.4 EAI-Plattformen 293

17.6.5 Eigenentwickelte Software 294

17.6.6 Electronic Business 294

17.7 Cloud Computing 296

17.8 InMemory 297

17.9 Microservices 299

17.10 Schattenseiten? 300

18 Automatisierung von Geschäftsprozessen 302

18.1 Automatisierung 302

18.2 Ausgangspunkte 303

18.3 Prozessanalyse 303

18.4 Wege 306

18.5 Ziele 307

18.6 Voraussetzungen 307

18.7 Umsetzung 308

18.8 Zementierung 310

19 Aktuelle Wege zur Automatisierung 311

19.1 Robotic Process Automation (RPA) 311

19.1.1 Einführung 311

19.1.2 Lose Kopplung 311

19.1.3 Drei Typen von Systemen 312

19.1.4 Voraussetzungen für den Einsatz 312

19.1.5 Schatten-IT 312

19.1.6 Erwartungen 313

19.1.7 Grenzen von Softwarerobotern 313

19.1.8 RPA/Bot-Lösung vs. Integrationsprojekt 313

19.1.9 Einschätzung 314

19.1.10 Anbieter / Softwarehäuser 314

19.1.11 "Bots überall" 315

19.1.12 Schattenseiten? 317

19.2 Cognitive Process Automation (CPA) 318

19.3 Process Mining 320

19.3.1 Ausgangspunkt 320

19.3.2 Ziele und Möglichkeiten 321

19.3.3 Aktuelle Methoden 321

19.3.4 Automatisierte Prozessmodellierung 322

19.3.5 Heute und Morgen 324

19.3.6 Process Mining als wissenschaftliche Disziplin 325

19.3.7 Unternehmen 325

19.3.8 Durchdringung, Ziele 325

19.4 Beispiele 326

19.4.1 Online-Fachhändler 326

19.4.2 ActBot 327

19.4.3 RPA Datenbankübergreifend 334

19.4.4 Automatisierte Prozesserkennung 335

20 Geschäftsprozesse im Internet - NoSQL et al. 336

20.1 Neue Anforderungen, neue Datenbanken 336

20.1.1 Neue Datenbanktechnologien 336

20.1.2 BigData 337

20.2 NoSQL-Datenbanken 341

20.2.1 Begriff 341

20.2.2 Definition 342

20.2.3 NoSQL-Kernsysteme 343

20.2.4 Volume, Velocity, Variety 345

20.2.5 Skalierbarkeit 345

20.2.6 Parallelisierung mit Hilfe des MapReduce-Frameworks 346

20.2.7 Konsistenz, CAP-Theorem 347

20.2.8 Schemafreiheit 348

20.2.9 Key/Value vs. Attribut 351

20.2.10 Key/Value – Datenbanken 355

20.2.11 Graphendatenbanken 357

20.2.12 Dokumentendatenbanken 358

20.2.13 Spaltenorientierte Datenbanken 363

21 KI für Geschäftsprozesse 367

21.1 Konventionelle Programmierung 367

21.2 KI-Programmierung 368

21.3 KI für Geschäftsprozesse 368

21.4 Maschinelles Lernen 369

21.5 Konkreter Einsatz 370

22 GPM im Zeitalter der Digitalisierung 371

23 Software für Geschäftsprozessmanagement 372

23.1 Mögliche Untersützung 372

23.2 Anbieter und Produkte 372

23.3 Modellierungswerkzeuge 373

24 Glossar 375

A 375

B 375

G 376

N 376

O 376

R 376

S 377

V 377

W 378

25 Stichwortverzeichnis (der Textversion) 379

26 Literaturverzeichnis 391

A 391

B 391

C 393

D 393

E 393

F 394

G 394

H 395

K 396

L 397

M 397

N 397

O 398

P 398

R 399

S 399

Staud 400

T 401

U 402

V 402

W 402

Z 403

 

Abkürzungsverzeichnis


Abkürzung

Langbezeichnung

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

CPO

Chief Process Officer

DV

Datenverarbeitung

EDV

Elektronische Datenverarbeitung

EPK

Ereignisgesteuerte Prozesskette

GUI

Graphical User Interface

GP

Geschäftsprozess

IS

Informationssystem

IT

Eigentlich Informationstechnologie, bzw. information technology. 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

WfM

Workflow-Management

WfMS

Workflow-Management-System

XODER

Logischer Operator EXKLUSIVES ODER


 

1 Einführung

1.1 Prozessgedanke

Es ist nun schon einige Jahre her, dass der Prozessgedanke in die unternehmerische Wirklichkeit und in die wissenschaftliche Diskussion Einzug gehalten hat. Man kann den Anfang in die 1970er-Jahre positionieren. Seitdem hat er immer mehr Bedeutung gewonnen und heute ist er aus der organisatorischen Wirklichkeit und der theoretischen 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 Anfang

Der Prozessgedanke diente auch als Grundlage eines sehr erfolgreichen Softwaretyps, der integrierten prozessorientierten Software, heute meist ERP-Software genannt (vgl. Abschnitt 17.3).

ERP-Software

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 Geschäftsprozesse und ihre Defizite. Der Weg war die einfache Optimierung, von den Ist-Prozessen zu optimierten Soll-Prozessen, oftmals verbunden mit der Einführung einer ERP-Software. Treiber dieser Entwicklung war die Notwendigkeit, die Wertschöpfung zu erhalten bzw. zu steigern, also mehr Effektivität und mehr Effizienz zu erzielen.

Dieser Treiber zeigte weiterhin Wirkung und trieb die unternehmerische Wirklichkeit und die Theoriediskussion voran. Es folgte die Betrachtung der Geschäftsprozesse 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 Wirtschafts­informatik 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 anhält, angetrieben durch denselben Wunsch nach Sicherung und Steigerung der Wert­schöpfung: Die IT-Unterstützungder Prozessabwicklung durch Software und Hardware (vgl. Kapitel 17). Dies war von Anfang an so, allerdings wurden zu Beginn nur einzelne Tätigkeiten durch die IT [Anmerkung] 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äftsprozessen, der Detaillierungsgrad der in die Software umgesetzten Geschäftsprozesse wurde ständig erhöht.

IT-Unterstützung der Prozessabwicklung

Immer mehr Unterstützung bzw. Realisierung der Geschäftsprozesse durch die IT bedeutet, dass Programme teilweise die Prozessabwicklung übernehmen. Da war es nicht mehr weit bis zur vollständigen Automatisierung, wie wir sie seit einigen Jahren erleben. Ganz aktuell wird diese weit vorangetrieben (in den klassischen Unternehmen) oder weitgehend erreicht (bei den Internet-Unternehmen). Vgl. dazu Kapitel 18, 19.

Automatisierung der Prozessabwicklung

1.2 Geschäftsprozesse

Für den Erfolg einer Organisation ist also - neben vielem anderen - die optimale Gestaltung der Geschäftsprozesse wichtig. Das beste Geschäftsmodell und die intelligenteste Geschäftsstrategie nützen wenig, wenn die Geschäftsprozesse nicht leistungsstark gestaltet sind. Nur dann kann das Ziel, die Kundenwünsche so zu erfüllen, dass die eigene Wertschöpfung realisiert wird, erreicht werden. Die Optimierung der Geschäftsprozesse hinsichtlich Effektivität und Effizienz ist Gegenstand des Geschäftsprozessmanagements (GPM) oder Business Process Managements (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 2016 [Anmerkung] 59% der Befragten an erster Stelle die Optimierung der Geschäftsprozesse als ein Thema, das sie beschäftigt [Herrmann 2016, S. 24].

Seit es Organisationen gibt, mit oder ohne Wertschöpfungsabsicht, wurden Geschäftsprozesse (vgl. Kapitel 2) betrachtet. Die Notwendigkeit dafür war schon immer gegeben, sie wurde mit den Jahrzehnten immer dringlicher und hat jetzt einen Punkt erreicht der mit Recht disruptiv genannt werden kann. Und dies aus zwei Gründen:

Digitalisierung und Automatisierung

  • Die fortschreitende Globalisierung und Digitalisierung macht das organisationelle Umfeld immer komplexer. Kürzere Lebenszyklen von Produkten und Dienstleistungen zwingen Organisationen, ihre Geschäftsprozesse ständig anzupassen und zu optimieren.
  • Inzwischen geht es nicht mehr nur um weitere Optimierung, um effizientere Abwicklung, z.B. durch immer weitergehende IT-Unterstütung, sondern um die fast vollständige Abbildung der Geschäftsprozesse in Software. M.a.W.: Die technische Entwicklung ermöglicht heute die weitgehende Automatisierung vieler Geschäftsprozesse. Dies hat massive Auswirkungen auf das Geschäftsprozessmanagement.

1.3 Geschäftsprozessmanagement

Business Process Management (BPM) umfasst schon immer u.a. Aufgaben des operativen und strategischen Prozessmanagements, des Prozessentwurfs, der Prozesseinführung und -implementie­rung sowie des Prozesscontrollings. Durch die Automatisierung wird sich dieses Aufgabenspektrum verändern. Es werden softwaregestützte und bereits voll automatisierte Geschäftsprozesse eingeführt, beobachtet und bei Bedarf optimiert. Dabei bleiben aber die "alten Fragen" des Geschäftsprozessmanagements zumindest teilweise erhalten.

BPM in Zukunft

Eine Frage, die hier beantwortet werden soll, ist, wie das Business Process Management der Zukunft insgesamt aussehen wird.

Aufgaben

Geschäftsprozesse bedürfen der Einrichtung, der Pflege und evtl. auch mal der Abwicklung. Zur Pflege gehört die Optimierung, zur Optimierung gehören Ziele.

Becker et al. sehen das Geschäftsprozessmanagement als Mittel zur prozessorientierten Unternehmensgestaltung, das sich per IT-Unterstützung mit der Dokumentation, dem Gestalten und Verbessern von Geschäftsprozessen befasst [Becker, Kugeler und Rosemann (Hrsg.) 2012].

Für Schmelzer/Sesselmann ist Geschäftsprozessmanagement „ein integriertes System aus Führung, Organisation und Controlling zur zielgerichteten Steuerung und Optimierung von Geschäftsprozessen. Es ist auf die Erfüllung der Bedürfnisse der Kunden sowie anderer Interessengruppen ausgerichtet und dient dazu, die strategischen und operativen Ziele der Organisation bzw. des Unternehmens zu erreichen." [Schmelzer und Sesselmann 2013]

Führung, Organisation, Controlling

Die hier angesprochenen Kundenbedürfnisse spielen natürlich eine wesentliche Rolle. Davon ausgehend wird als eine wichtige Aufgabe für das Geschäftsprozessmanagement die Herstellung der sog. Kundenorientierung formuliert. Deshalb wird in vielen Definitionen dieser Begriff mit angeführt.

Kundenorientierung

Dass dies eine aktuelle und auch in den Unternehmen erkannte Aufgabe ist, zeigt auch der IT-Kompass 2016. Nach dem wichtigsten Thema Optimierung der Geschäftsprozesse (59%) kam an zweiter Stelle mit 41% Nennungen Steigerung der Kundenzufriedenheit/Kundenbindung [Herrmann 2016, S. 24].

Es geht aber nicht nur um die aktuellen Wünsche der Kunden. Wir erleben es ständig: Unternehmen 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 Telekommunikation, usw. Diese potentiellen Wünsche(von denen man aber nicht weiß, ob sie vom potentiellen Kundenauch wirklich angenommen werden), müssen auch bedacht werden.

Potentielle Kunden

Auch wenn dies v.a. Fragen des Marketings sind, betrifft dies auch das Geschäftsprozessmanagement. Denn viele dieser Leistungen bzw. Produkte sind direkt mit IT-gestützten bzw. automatisierten Geschäftsprozessen verknüpft. Dazu unten mehr.

Andere Definitionen weisen – mit etwas anderer Begrifflichkeit – auch auf Automatisierungsaspekte hin. So die Fraunhofer-Gesellschaft:

Automatisierung

„Unter Business Process Management (BPM) versteht man alle Aktivitä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 automatisierten verschoben. Dies wird in Zukunft noch viel stärker so sein.

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 Umgestaltung betrieblicher Organisationsstrukturen.

Business Process Reengineering

Es versteht sich, dass Business Process Reengineeringdamit auch in engem Zusammenhang mit den oben diskutierten Begriffen Kerngeschäftsprozesse und Kernkompetenzen 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, akquisitorische 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 Flussorientierung.“ [Rupper 1994, S. 10]

Dies sind alles Themen, die auch ein modernes Geschäftsprozessmanagement bewältigen muss. Damit kann wie folgt definiert werden:

Definition Geschäftsprozessmanagement:

(1) Geschäftsprozessmanagement hat das Ziel, die Geschäftsprozesse einer Organisation so zu gestalten, dass eine möglichst hohe Wertschöpfung erzielt wird (Unternehmen), bzw. dass ein möglichst effektiver und effizienter Einsatz der Resssourcen erfolgt (sonstige Organisationen).

(2) Es geht um alle Aktivitäten, die mit der Planung, Gestaltung, Ausführung und Überwachung von Geschäftsprozessen zu tun haben.

Zur Planung und Gestaltung gehört heute auch die Herbeiführung einer weitgehenden IT-Unterstützung oder Automatisierung der Geschäftsprozesse. Dies wiederum muss die Ausführung und Überwachung der Geschäftsprozesse heute berücksichtigen, sie hat zu einem erheblichen Teil heute mit Software-Lösungen zu tun.

IT-Unterstützung, Automatisierung

Ebenen des Geschäftsprozess­managements

Entsprechend den üblichen Managementebenen wird auch das Geschäftsprozessmanagement in eine operative, fachlich-konzeptionelle und strategische Ebene eingeteilt [Gadatsch 2013a, Pos. 784]:

  • Fachlich-konzeptionelle Ebene: Hier ist sozusagen das betriebswirtschaftliche Geschäftsprozessmanagement mit Prozessabgrenzung, -modellierung, -führung angesiedelt.
  • Operative Ebene: Hierzu gehören neben der Prozessüberwachung, Prozessmessung und Prozessteuerung auch alle Fragen rund um die Einbettung der Geschäftsprozesse in die IT, unabhängig davon, wie sie erfolgt: durch das Workflow-Management, die Entwicklung von Anwendungssystemen, Kauf von ERP-Software, usw.
  • Strategische Ebene: Diese umfasst strategische Fragen rund um die Prozessgestaltung. Vgl. hierzu Kapitel 6.

Lebenszyklus

Zum Abschluss dieser Betrachtungen, wie Geschäftsprozessmanagement definiert ist und welche Aufgaben es hat, noch eine andere Sichtweise. 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äftsprozesses wie folgt definiert werden:

Prozesse …

  • ... identifizieren und standardisieren
  • ... modellieren, Erstellen eines Prozessmodells
  • ... in die Prozesslandschaft einbetten
  • ... einrichten
  • ... durchführen und lenken
  • ... pflegen
  • ... überwachen, Controlling der Prozesse
  • ... standardisieren und optimieren
  • ... abwickeln

Damit sind ebenfalls die wichtigsten Tätigkeitsbereiche zusammengestellt, die im Rahmen des Geschäftsprozessmanagements zu lösen sind, ergänzt um den Aspekt der Abwicklung, der inzwischen auch Bedeutung erlangt hat.

Prozessorientierung

Führt man Geschäftsprozessmanagement in einer Organisation ein, stellt dies neue Anforderungen an die Mitarbeiter. Sie sollten sich bewusst werden über den Prozess, erkennen, wo sie im Prozss wirken und wie die "benachbarten" Prozessabschnitte 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ührung" [ebenda].

Neue Anforderungen

Dies deckt natürlich nur einen Teil der Wirklichkeit ab. Sehr oft gibt es Konflikte bei der Durchführung von Optimierungsschritten, aus dem einen oder anderen Grund. Becker/Berning/Kahn haben sich mit einem Aspekt solcher Konflikte beschäftigt, möglichen Haltungen und Verhalten der Beschäftigten, die nach ihrer 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/Paralyse" für mangelnde Umsetzung

Subjektorientiertes Prozessmanagement

Direkt mit der obigen Thematik hat auch das subjektorientierte Prozessmanagement (auch: Social Business Process Management und S-BPM) zu tun. Deren Urheber sehen in diesen Projekten eine zu geringe Beteiligung der an den Geschäftsprozessen beteiligten Menschen. 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äftsprozessmanagement im Allgemeinen und Prozessmodellierung im Besonderen. In ihm wird die Rolle der Mitarbeiter und die Rollen anderer Beteiligter am Geschäftsprozessmanagement 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 Berücksichtigung der an den Geschäftsprozessen beteiligten Menschen. Im Hintergrund 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 verbundenen Prozessanpassungen heutzutage notwendig sind.

Rollen

Am Geschäftsprozessmanagement sind zahlreiche Personen mit unterschiedlichen Aufgaben beteiligt. 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 Steuerung). Diese Rolle ist in Unternehmen häufig etabliert.
  • Prozessmitarbeiter/Prozessexperte (unterstützen die erstmalige Implementierung des Geschäftsprozessmanagements und Weiterentwicklung bei größeren Restrukturierungen)
  • Prozessberater (Ausführung von konzeptionellen und ausführenden Projektarbeitspaketen)
  • 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änderungsprojekten)

Vgl. [Gadatsch 2015, Pos. 265f].

1.4 Digitalisierung und Automatisierung

Im Kontext dieses Textes bedeutet Digitalisierung, dass im Rahmen eines Geschäftsprozesses Aufgaben, die bis dahin durch Menschen realisiert wurden, nun von Programmen erledigt werden. Dies kann einzelne Tätigkeiten (z.B. Brief schreiben), Aufgaben (z.B. Angebote einholen), Vorgänge (z.B. Angebot erstellen) oder ganze Geschäftsprozesse (z.B. Leistungserbringung) betreffen.

Digitalisierung betrifft statische Aspekte, die sich in Dateien und Datenbanken artikulieren und dynamische Aspekte, die sich – in diesem Kontext – als Geschäftsprozesse äußern. Der Gegensatz „Statik – Dynamik“ ist ein altes und grundlegendes Thema der Informatik, insbesondere der Softwareentwicklung. „Statik“ meint hier die von jedem Anwendungsprogramm zu verwaltenden Daten, „Dynamik“ die Umsetzung von Handlungen, Vorgängen, Abläufen, Geschäftsprozessen, usw. in Programme.

Statik + Dynamik

Die Bewältigung der „Statik“ führte von den datenerfassenden Lochstreifen der ersten Zuse-und Hollerith-Computer zu Dateien, Datenbanken (relational, objektorientiert, nicht-konventionell) bis zu den NoSQL-Datenbanken.

Statik -> Datenbanken

Die Bewältigung der „Dynamik“ führte im hier betrachteten Bereich zu immer ausgefeilteren Programmen. Zuerst erfolgte die Unterstützung einzelner Aufgaben von Geschäftsprozessen, dann die abschnittsweise automatisierte Abwicklung und nun der Versuch weitgehender Automatisierung bis zum Kundenkontakt (vgl. Kapitel 18, 19).

Dynamik -> Programme

Automatisierung, wie sie heute verstanden wird, hat die Digitalisierung als Grundlage. Davor war es ein Thema der Mechanik. Spannende Einblicke zu diesen Vorläufern gibt [Giedion 1982].

1.5 Begrifflichkeiten

Organisation vs. Unternehmen

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

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

Somit gilt: Wo immer es sinnvoll ist, wird von Organisationen als Anwendungsbereich (Gegenstand der Ausführungen) gesprochen. Wo es um nach Wertschöpfung zielende Organisationen geht, von Unternehmen.

1.6 Einbettung

Die Betrachtung von Geschäftsprozessen erfolgt im Rahmen des Geschäftsprozessmanagements. Dieses war lange Zeit eine betriebswirtschaftliche Thematik, inzwischen ist es auch Sache der IT der Organisationen.

BWL + IT

Geschäftsprozessmanagement ist Teil des Managements einer Organisation. Wichtige benachbarte Managementbereiche sind IT-Management und strategisches Management (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 Management 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äftsprozessmanagement. Im Überschneidungsbereich aller drei Managementgebiete (D) finden sich strategische Aufgaben des Geschäftsprozessmanagements mit IT-Bezug, z.B. die Klärung der Frage, welche Geschäftsprozesse langfristig in "die Cloud" verlagert werden können.


Abbildung 1.6-1: Geschäftsprozessmanagement - Einbettung

 

2 Geschäftsprozesse

2.1 Herkunft

Der Prozessgedanke ist heute absolut dominant in der Wahrnehmung der Organisationswirklichkeit. 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 beschreibt die Aufteilung der im Unternehmen anfallenden Aufgaben nach funktionalen 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 organisiert sind. Im Mittelpunkt standen also Stellen und Abteilungen, betriebliche Abläufe wurden nur selten strukturiert geplant und modelliert.

Taylor

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 Industrieunternehmen. 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 Aufteilung in Funktionsbereiche angedeutet und zusätzlich die Aufteilung nach unterschiedlichen Managementaufgaben (vgl. die Abschnitte 2.4, 2.5). Dies hat in jüngster Zeit angesichts der Automatisierung von Geschäftsprozessenwieder an Bedeutung gewonnen, da sich (natürlich) nur bestimmte Aufgaben automatisieren lassen (vgl. Kapitel 21).

Die Pyramidenform kommt daher, weil "von unten nach oben" Informationen immer verdichteter werden und weil typischerweise die Anzahl der mit der jeweiligen Aufgabe befassten Personen immer mehr abnimmt.

Einen frühen Hinweis auf die prozessartige Struktur des betrieblichen Geschehens gab Nordsieck [Nordsieck 1932, 1934], der schon in den 1930-er Jahren ein prozessorientiertes Verständnis einer Organisation formulierte:

„Der Betrieb ist in Wirklichkeit ein fortwährender Prozess, eine ununterbrochene Leistungskette“ [Nordsieck 1932, S.77].

Dies erlangte damals aber keine Wirkung. Wissenschaftler, die dem Objekt des betrieblichen Prozesses Aufmerksamkeit haben zukommen 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ätigkeiten, ihre Stelleninhaber und die Einbettung der Tätigkeiten in die Abläufe. Danach kam der Geschäftsprozessgedanke auf. Mit dem Konzept des Geschäftsprozesses veränderte sich die Perspektive. Jetzt standen längere zusammenhängende Folgen von Tätigkeiten, die zur Erledigung einer größeren Aufgabe nötig sind, im Mittelpunkt der Betrachtungen. Unter Umständen sogar eine Folge von Tätigkeiten, die in Bezug auf das betrachtetet Unternehmen abgeschlossen ist. Das ist auch heute noch der Stand der Technik. Die meisten Bemühungen, die Abläufe in den Unternehmen effektiver und effizienter zu gestalten, starten mit einer Analyse der Geschäftsprozesse und deren Optimierung.

Geschäftsprozess­gedanke

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

Die senkrechte gestrichelte Linie weist darauf hin, dass es auch Geschä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

Das Geschäftsprozessmanagement, wie wir es heute kennen, baut auf den Vorarbeiten der Organisationslehre auf. In diesem Abschnitt werden einige Begriffe erläutert, die für die weiteren Ausführungen unabdingbar sind.

Kunden werden bei der Betrachtung von 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 eigenen Unternehmen, sie werden auch unternehmensinterne Auftraggeber [Stahlknecht und Hasenkamp 2005, S. 206] genannt. Z.B. hat die IT einer Organisation die übrigen Beschäftigten als interne Kunden.

Externe Kunden, interne Kunden

Geschäftsprozesse haben statische Elemente z.B. die benutzten Datenbestände [Anmerkung] und dynamische. Letztere sind die Tätigkeiten, die in Geschäftsprozessen erledigt werden. Sie werden Aufgaben oder auch Funktionen genannt. Geschäftsprozesse bestehen - 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 zugrundeliegenden Modellüberlegungen.

Statische und dynamische Elemente

Detaillierungsebenen, Aggregationsniveaus

Eine wichtige Eigenschaft von Aufgaben ist, dass sie auf unterschiedlichen Detaillierungsebenen betrachtet werden können. Man kann sie zusammenpacken (aggregieren) 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. „Wertschöpfung erzielen“). Im Geschäftsprozesskontext stellen die sog. Elementaraufgaben die unterste Ebene dar, die Bullinger/Fähnrich als

„... entweder nicht weiter zerlegbare oder auf der betreffenden Beschreibungsebene nicht weiter zerlegte Aufgaben“

bezeichnen [Bullinger und Fähnrich 1997, S. 41]. Mehrere solche Elementaraufgaben werden dann in einer Aufgabe zusammengefasst. Wir übernehmen folgende Definition, die auch auf die selbstverständliche Erwartung eines Ergebnisses und auf die Durchführbarkeit durch Menschen oder Maschinen hinweist [Österle 1995, S. 45]:

Definition: Aufgabe

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

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 Handhabungen geht. Soll die Prozessbeschreibung in das Anforderungsmanagement der Entwicklung einer prozessorientierten Software einfließen, kann bei den durch die 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 Aufgaben wird mit der Definition von Vorgängen gemacht. Mit Bullinger/Fähnrich sind Vorgänge

Definition: Vorgang

„Abfolgen von Tätigkeiten, die zur Realisierung von Aufgaben ausgefü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 1998a, S. 20]

Workflow

Standardisierbare Vorgänge (vgl. Kapitel 5) 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 auftretenden Ereignissen. Sie bewirken damit Zustandsänderungen im Geschäftsprozess.
  • Daten- bzw. Objektflüsse modellieren Eingangsinformationen oder -objekte, die zur Aufgabenausführung benötigt werden. Weiterhin modellieren sie die Verwendung der Resultate in nachfolgenden Aufgaben.
  • Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Aufgaben.
  • Ressourcen sind Materialien oder Betriebsmittel, die zur Aufgabenausführung benötigt werden. Dies können auch Aufgabenträger sein.

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

Definition: Funktion

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

Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsobjekte (Business Objects) gemeint. Dieser Objektbegriff stimmt weitgehend (bei den meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen 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 hier angeführt. 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äumlich 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 einen Geschäftsprozess "... als Bündel von Aktivitäten, für das ein oder mehrere unterschiedliche 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 Aufbauorganisation, Ablauforganisation (vgl. Glossar) und Informationssystem einen Prozess

Hess

Definition: Geschäftsprozess

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

Er gibt damit auch einen deutlichen Hinweis auf das Konzept des Kontrollflusses. In seiner umfassenden Darstellung zahlreicher Methoden des Business Reengineering gibt er bei fast jeder die jeweils benutzte Prozessdefinition an [Hess und Brecht 1996]. Hier finden sich auch zahlreiche Hinweise auf die bei den Beratungsunternehmen benutzten Begriffe und Definitionen.

Zahlreiche Definitionen zu Geschäftsprozessen führt auch [Rump 1999, S. 18f] an. Er selbst definiert, bezugnehmend auf die Unternehmensziele, wie folgt:

Rump

Definition: Geschäftsprozess

Ein Geschäftsprozess ist eine zeitlich und sachlogisch abhängige Menge von Unternehmensaktivitäten, die ein bestimmtes, unternehmensrelevantes Ziel verfolgen und zur Bearbeitung auf Unternehmensressourcen zurückgreifen. [Rump 1999, S. 19]

Keller und Teufel berücksichtigen neben den externen auch die internen Kunden. Für sie ...

Keller und Teufel

Definition: Geschäftsprozess

... beschreibt ein Geschäftsprozess alle Aktivitäten, mit deren Durchführung eine angestrebte Leistung bzw. Soll-Leistung durch Aufgabenträger erstellt wird, die an externe Kunden (Hauptprozesse) oder interne Kunden (Serviceprozesse) übergeben wird und für diesen einen 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:

Scheer

Definition: Geschäftsprozess

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 abgenommen wird." [Scheer 1998a, S. 3f]

Mertens definiert, aufbauend auf seinem oben eingeführten Funktionsbegriff, Prozesse als eine Abfolge von Funktionen mit definierten Anfangs- und Endpunkten:

Mertens

Definition: Geschäftsprozess

Eng verwandt mit dem Begriff Funktion ist der Begriff Prozess. Ein Prozess entsteht aus einer Folge von einzelnen Funktionen (Funktionsablauf) und weist einen definierten Anfangspunkt (Auslöser des Prozesses) sowie Endpunkt (Endzustand) auf. [Mertens 2013, S. 43]

Ganz ähnlich Becker und Vossen. Sie definieren einen Geschäftsprozess als

Becker und Vossen

Definition: Geschäftsprozess

... die inhaltlich abgeschlossene zeitliche und sachlogische Abfolge von Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts notwendig sind. [Becker und Vossen 1996, S. 19]

Der Objektbegriff deckt sich mit dem, was auch Geschäftsobjekt genannt wird. Allerdings gehen diese Autoren von einem einzelnen (betriebswirtschaftlich relevanten) Objekt aus, das den Prozess prägt.

Einige weitere Aspekte betont Gadatsch:

Gadatsch

Definition: Geschäftsprozess

Ein Prozess ist eine sich regelmäßig wiederholende Tätigkeit mit einem definierten Beginn und Ende. Er verarbeitet Informationen (Input) zu zielführenden Ergebnissen (Output) und ist in der Regel arbeitsteilig organisiert. Er kann manuell, teilautomatisiert oder vollautomatisiert ausgeführt werden. [Gadatsch 2015, Pos. 139]

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]). Schmelzer/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 Ergebnisse und Empfänger der Ergebnisse des Prozesses offen" [ebenda].

Prozess vs. Geschäftsprozess

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 Aktivitäten werden als wertschöpfende Aktivitäten spezifiziert und das Ergebnis wird als Leistungen für Kunden definiert. Geschäftsprozesse sind dann …

Definition: Geschäftsprozess

... 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." [ebenda, S. 53]

und

"Geschäftsprozesse beginnen und enden bei Kunden" [ebenda]

Dies ist eine sehr spezifische Sicht, die bei der Lektüre der entsprechenden Fachliteratur bedacht werden muss.

Für Gaitanides besteht ein Prozess aus einer …

Gaitanides

Definition: Geschäftsprozess

… "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äftsprozessen 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 Themengebietes 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 Organisationsverstä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 Unternehmenszielen 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 (Geschä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ätigkeiten.
  • 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 zu einer immer umfassenderen Unterstützung.

Fasst man dies zusammen und ergänzt es um eigene Erfahrungen, kommt man zur folgenden Definition von Geschäftsprozessen, die wir hier zugrunde legen:

Definition: Geschäftsprozess

Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisationsziels notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten oder Programmen unter Nutzung der benötigten Produktionsfaktoren geleistet. Unterstützt wird die Abwicklung der Geschäftsprozesse durch die IT der Organisation.

Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfaktoren in verkaufte Produkte bzw. Dienstleistungen (vgl. für diesen produktionstheoretischen Ansatz [Porter 1992a,b]).

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 aufeinander folgen, wie verzweigt wird, welche Ergebnisse erzielt werden sollen, usw. Die Basis dafür sind Regeln:

Kontrollfluss

"Regeln bilden die Grundlage für das Gestalten von Prozessen und darüber hinaus für prozesskonformes Handeln. Prozesse verwirklichen sich als regelgeleitete Aktivitäten" [Gaitanides 2012, S. 3).

Ein wichtiger Aspekt dieser Regeln ist der sog. Kontrollfluss, bei den Autoren der BPMN (vgl. Kapitel 14) Sequenzfluss.

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 Ganzes, weil dadurch die damit verbundene neue Sichtweise auf das Unternehmensgeschehen verdeutlicht wird.

Die sequentielle Grundstruktur liegt allerdings nicht immer vor. Es gibt Geschäftsprozesse, denen diese Eigenschaft fehlt oder bei denen man diese nicht erheben will. Z.B. kreative Prozesse. Vgl. dazu Abschnitt 3.4.

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 Kundenauftrag, 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äftsprozessen. Eigenschaften sind nun mal 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 Aufgaben. 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. Solche Geschäftsprozesse sind standardisierbar (vgl. Kapitel 4) und können auch durch die IT unterstützt oder sogar vollautomatisch abgewickelt werden. Die anderen Prozesse, die "chaotischen" / kreativen (vgl. Abschnitt 3.4) entziehen sich dieser Erfassung und Umsetzung.

Kundenorientierung

Ein weiterer Aspekt verdient besondere Beachtung. Geschäftsprozesse sollen sich, so wird gefordert, an den Kundenwünschen orientieren. Direkt (bei den Kernprozessen) oder indirekt (bei zuliefernden Prozessen oder Supportprozessen). Dies ist erst mal vernünftig, muss aber hinterfragt werden. Vgl. dazu Abschnitt 3.1 ("Potentielle Kunden)".

Überwindung von Organisationsgrenzen

Geschäftsprozesse wurden bewusst so gesehen, dass sie die Grenzen organisatorischer Einheiten überschreiten. Das war eines der Motive bei der Entwicklung des Prozessgedankens: Die Organisationsbrüche (Probleme bei der Abwicklung der Geschäftsprozesse an den Grenzen organisatorischer Einheiten, z.B. 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 Unternehmen mit einer ausgeprägten Projektorganisation.

Aufgabenträger

Träger der durchzuführenden Aufgaben waren zu Beginn der Zeit intensiverer Prozessbetrachtungen (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äftsprozesse also durch "die IT unterstützt" wurden, wie man dann sagte. Später wurden dann viele und immer mehr Prozesse voll automatisiert (vollkommen durch Programme realisiert) , z.B. bei den Internet-Unternehmen. Dies muss, will man die aktuelle Situation des Geschäftsprozessmanagements betrachten, berücksichtigt werden.

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 ("Angebot erstellen") in Teilaufgaben. Durch diese entsteht Subjektivität - es kann mehr oder weniger zusammengefasst bzw. zerlegt werden. Ausgehend von tayloristischen Handlungen bis zur Gesamttätigkeit der Organisation.

Dies ist nicht immer ein Fehler derjenigen, die den Prozess erfassen, weil sie nicht zwischen Funktion und Prozess unterscheiden können 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 Prozesssituation 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.

Eine Lösung, die oft ausreicht, ist die der Standardprozessmodellierung (vgl. Kapitel 12). Diese erfasst das Handeln der Prozessträger in integrierter Form und lässt auch die Geschäftsobjekte, wie Rechnungen, Lieferscheine, usw., zusammen.

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 Produktion, die Kalkulation, die Auslieferung, usw. Auch hier erfolgt die Festlegung nur durch denjenigen, der den Geschäftsprozess erfasst, 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 Kernprozesse sinnvoll.

Automatisierung, IT-Abdeckung

Eine wichtige Eigenschaft von Prozessen oder Prozessabschnitten ist der Automatisierungsgrad. Damit ist der Anteil an der Aufgabenerfüllung gemeint, der ohne menschliches Zutun allein durch die Informationstechnologien erledigt wird. In vielen Bereichen strebt man nach einem möglichst hohen Automatisierungsgrad. Dort, wo es sich um stark standardisierte Abläufe mit einfachen Entscheidungsprozessen handelt, hat man dieses Ziel weitgehend erreicht. Ein einfaches Schema für diese Eigenschaft ist "voll automatisiert, teilweise automatisiert, nicht automatisiert". Dies betrifft inzwischen auch ganze Prozesse. Das Geschäftsmodell der Internet-Unternehmen beruht darauf, es wäre auf andere Weise auch nicht denkbar. Diese ständig zunehmende Automatisierung hat tiefgreifende Konsequenzen für das Geschäftsprozessmanagement. Dazu unten mehr.

Unterstützung oder Automatisierung

Geschäftsprozesse können durch die IT unterstützt werden oder sie können automatisiert sein (vgl. Kapitel 17, 18, 19). Der Unterschied ist folgender: Unterstützung meint, dass einzelne Abschnitte durch Programme realisiert werden. Automatisierung meint, dass alle Abschnitte durch Programme realisiert sind, evtl. auch Entscheidungsvorgänge. D.h., um einige einfache Beispiele anzuführen, die Nachbestellung für das Lager wird automatisch durchgeführt, die Kaufempfehlung beim Web-Anbieter automatisch generiert (weshalb sie uns oft zum Schmunzeln bringt) und auch der Umgang mit anscheinend zahlungsunwilligen Kunden wird ein ganzes Stück weit durch die Software gesteuert (vgl. hierzu das Prozessbeispiel Rechnung in [Staud 2019, Kapitel 13]).

Unterstützung der Abwicklung der Geschäftsprozesse durch Anwendungssoftware ist heute Standard, nur das Ausmaß ist unterschiedlich. Sind wirklich nur noch die Funktionen im Geschäftsprozess nicht IT-gestützt realisiert, die Entscheidungen darstellen, oder gibt es Abschnitte, die trotz der Möglichkeit der IT-Unterstützung diese nicht bekommen haben.

Alles in allem ist die IT-Abdeckung heute, v.a. seit der Etablierung prozessorientierter integrierter Standardsoftware (ERP-Software), sehr hoch.

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

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 Leistungserbringung 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äftsobjekte ü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 standardisierte Vorgänge einfacherer Struktur. Dem ist aber, wie wir ja auch alle wissen, 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.


105

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 angestrebten 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 IT-Systeme unterstützt oder sogar automatisiert werden. Wenn ein Problem erkannt wurde, können Lösungsalternativen entwickelt werden.

In der Praxis (von IT-Systemen) muss dann eine getroffene Entscheidung auch umgesetzt (implementiert) werden. Danach wird geprü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ücksprü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 Vorgehen 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.

wohlstrukturiert

Als semistrukturiert gelten Probleme, bei denen für einige Phasen Lösungsansätze 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.

semistrukturiert

Als unstrukturiert wird ein Problem empfunden, wenn zu keiner der Phasen ein geeignetes Vorgehen bekannt ist. Solche Probleme entziehen sich der Automatisierung vollkommen. Unterstützung durch IT ist denkbar.

unstrukturiert

Die Einteilung des Strukturierungsgrads ist offensichtlich subjektiv. Die Verwendung 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 Klasse: 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

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 Wissensverarbeitung, usw. Dies rührt von der Unterschiedlichkeit der in einer Organisation zu lösenden Aufgaben her und hat unmittelbare Auswirkungen auf die Möglichkeiten zur IT-Unterstützung und Automatisierung.

Deshalb werfen wir hier nochmals einen Blick auf die oben eingeführte Managementpyramide (Abschnitt 2.1), jetzt aber mit dem Fokus auf die zu lösenden Aufgaben. In der Managementliteratur finden wir dazu die üblichen Einteilungen, wie sie die folgende Abbildung zeigt. Bzgl. der Managementaufgaben werden dabei eine obere, mittlere und untere Führungsebene unterschieden. Führungskräfte der unteren Ebene arbeiten unmittelbar mit den Personen auf Stellen ohne Führungsverantwortung zusammen, ihre Entscheidungen sind in der Regel detailliert, sachbezogen und konkret. Je höher die Führungsebene, desto größer ist der Entscheidungsspielraum sowie die Tragweite der zunehmend abstrakteren Entscheidungen. Wie oben schon ausgeführt, verkleinert sich von "unten nach oben" aufgrund des hierarchischen Aufbaus die Anzahl der Leitungsstellen auf einer Hierarchieebene, deshalb die Pyramidenform.

Managementpyramide

Hier ist diese Pyramide von Interesse, weil auf all diesen Ebenen Geschäftsprozesse stattfinden, allerdings von sehr unterschiedlicher Natur und weil sich Geschäftsprozessmanagement um all diese Geschäftsprozesse kümmern muss.

Geschäftsprozesse verlaufen natürlich auch über Ebenen hinweg. Dies wurde schon in Abbildung 2.1-1 angedeutet am Beispiel eines Prozesses, der sozusagen senkrecht 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 Arbeitsbereiche (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 unterschieden [Anmerkung] (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 Arbeitsbereichen vornehmen und den möglichen Automatisierungsgrad abschätzen.

Zur Administration gehören die Verwaltung und Verarbeitung von Massendaten, z.B. die …

Administration

  • Berechnung der Entlohnung im Personalwesen
  • Buchführungsarbeiten in der Finanzbuchhaltung
  • Berechnung der Monats- und Jahresabschlüsse in der Finanzbuchhaltung
  • Kontoführung bei Kreditinstituten
  • Lagerbestandsführung im Handel

Prozesse können hier dahingehend optimiert werden, dass die Massendatenverarbeitung rationalisiert wird.

Administrationsaufgaben sollen vorhandene Abläufe und die Massendatenverarbeitung 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.

Zur Disposition gehört die Steuerung kurzfristiger, gut strukturierter Abläufe innerhalb des Betriebs und die Vorbereitung kurzfristiger dispositiver Entscheidungen, vor allem auf der unteren und mittleren Führungsebene. Beispiele für damit zu erledigende Aufgaben sind die …

Disposition

  • (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 zwischen semistrukturiert und unstrukturiert.

Das Automatisierungspotential ist hier, da es sich um Routineabläufe handelt, hoch. Evtl. werden auch Entscheidungsprozesse automatisch durchgeführt ("Nachbestellung einfacher Güter nach Lagerbestand, derzeitiger Nachfrage, usw.").

Wertorientierte Abrechnungsaufgaben begleiten die oben dargestellten mengenorientierten Prozesse. Sie machen die betriebswirtschaftlichen Konsequenzen sichtbar. Am Beispiel des Personalwesens kann man dies gut erläutern: Die operativen Systeme liefern die Daten zum täglichen Einsatz eines jeden Beschäftigten: Arbeitsbeginn, Arbeitsende, Überstunden usw. Im Rahmen der wertorientierten Abrechnung wird daraus z.B. das Monatsgehalt berechnet.

Wertorientierte Abrechnung

Wertorientierte Abrechnungsaufgaben nehmen somit eine betriebswirtschaftliche Auswertung der mengenorientierten Daten aus den operativen Systemen vor.

Das Automatisierungspotential ist hier, da es sich meist um stark durchstrukturierte Abläufe handelt, sehr hoch. Hier liegen bereits IT-Lösungen vor.

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

Berichts-, Planungs- und Kontrollaufgaben

Das Automatisierungspotential im Berichtswesen ist, nach der Festlegung der Art der Berichte, sehr hoch.

Planungsaufgaben und -entscheidungen werden in der betrieblichen Leitungsebene realisiert. Hier liegen oft schlecht strukturierte Probleme vor. Ein Beispiel ist das Berechnen von Planalternativen und -varianten mit Hilfe von Modellrechnungen. 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 unterstützt werden (Erhebung und Verarbeitung von Informationen), die eigentliche Planung ist Sache der beteiligten Menschen [Anmerkung] .

Mit Kontrollaufgaben sind die zur Überwachung der Einhaltung der Pläne gemeint. 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 eingerichtete Kontrollprozesse können automatisiert ablaufen. Die eigentlichen Entscheidungen müssen Menschen fällen.

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.

Analyseaufgaben, Langfristige Planung und Entscheidung

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.


Abbildung 2.5-2: Art der betriebswirtschaftlichen Aufgabe, Aufgaben im Unternehmen
Quelle: Managementpyramide inspiriert von [Scheer 1997, S. 5], [Mertens 2013, S. 19]

2.6 Wichtige Eigenschaften

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 gemeint. Daneben natürlich, wenn auch erst seit einigen Jahren, die Durchgängigkeit über Unternehmensgrenzen hinweg.

Ausmaß der Prozessintegration

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 semantische Prozessintegration ist nicht gewährleistet, usw. Semantische Prozessintegration betrifft die Weitergabe von Informationsobjekten, meist zwischen verschiedenen 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 B2B [Anmerkung] gearbeitet.

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 Prozessabschnitt auftaucht. Es muss deutlich gemacht werden, u.a. durch eine Erfassung des Informationstransports.

Medienbrüche

Beispiele für Medienbrüche:

  • Ausgabe von weiterzugebender 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 bereitgestellt werden, in der sie benötigt werden

Im Kern ist es so: Muss dieselbe bereits erfasste Information nochmals erfasst werden, liegen Medienbrüche und damit ein Defizit in der Prozessintegration vor.

"Nochmalige Erfassung"

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äftsprozesses benötigt werden. Auch sie ist von großer Bedeutung, da nichtintegrierte Datenbestände Reibungsverluste bedeuten. Konkret kann dies folgendes bedeuten: Daten zu einem Bereich, zu einer Aufgabe, für einen Geschäftsprozess …

Ausmaß der Datenintegration

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

Stammdatenkrise

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 heterogenen (nicht miteinander verknüpften) Datenbeständen, damals auch Dateninseln genannt. 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 oder wenn im Rahmen der Automatisierung von Geschäftsprozessenmittels Robotic Process Automation(RPA) Geschäftsprozesse verknüpft werden (vgl. Kapitel 19).

Wie erkennt man nun in der Prozesserfassung solche Defizite in der Datenintegration? Durch eine exakte Erfassung der Informationen, die bei den einzelnen Tätigkeiten erzeugt oder benutzt werden. Hier sollte, wenn genügend detailliert und genau untersucht wird, diese Zersplitterung aufgedeckt werden.

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.

Komplexitäts- und Automatisierungsgrad

Eine weitere wichtige Eigenschaft ist der Umfang der Automatisierung, der Automatisierungsgrad, wie in Abschnitt 2.5 thematisiert. Er hängt mit der vorigen Eigenschaft zusammen. Der Trend zeigt hier ganz eindeutig in Richtung Ausdehnung 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.

Automatisierungsgrad

2.7 Geschäftsprozesse im Zeitalter der Digitalisierung

Das in der Überschrift genannte Thema wird hier an vielen Stellen thematisiert. Vgl. insbesondere Abschnitt 12.2 ("Basiselemente") und das Stichwort Digitalisierung im Stichwortverzeichnis. Hier nur ein paar einführende Anmerkungen:

Die Geschäftsprozesse, wie wir sie heute antreffen, sind auf vielfältige Weise durch Trends geprägt.

Beginnen wir mit dem Trend zu einer immer intensiveren Unterstützung der Geschäftsprozesse durch die IT. Schon früh (1970-er Jahre), nachdem die betrieblichen Abläufe als Geschäftsprozesse wahrgenommen wurden, setzten die Versuche ein, sie durch die IT (damals: EDV) zu unterstützen. Diese ständig zunehmende IT-Unterstützung (vgl. Kapitel 17) wurde zum Trend, der bis heute anhält.

IT-Unterstützung

Obiger Trend setzte sich fort bis zur automatisierten Abwicklung von Prozessabschnitten heute. "Automatisiert" meint "durch Programme" und evtl. auch Gerate/Hardware (Lagersysteme, Drohnen) realisiert. Dies wurde, aufgrund der technologischen Entwicklungen in Informatik und Computertechnik möglich. Konkret bedeutet dies, dass die Geschäftsprozesse in Software "gegossen sind", bis auf nicht automatisierbare Abschnitte, und dass die IT - heute meist auch über das Internet - die Geschäftsprozesse abwickelt. Vgl. dazu die Kapitel 19 und 20.

Automatisierung

Verstärkt wird der Automatisierungstrend durch die Entwicklung der sog. Künstlichen Intelligenz. Deren Ergebnisse wurden zunehmend für die Prozessunterstützung genutzt, so dass wir heute beim Kontakt mit Geschäftsprozessen nicht nur auf klassisch programmierte Programme und Softwareroboter stoßen, sondern auch auf KI-gestützte.

KI-Grenze

Zu den technologischen Entwicklungen mit großer Bedeutung für die Geschäftsprozesse zählt auch das Internet. Es wurde zu einem zentralen Medium für die Abwicklung der Geschäftsprozesse, auch aber nicht nur an der Schnittstelle zwischen Unternehmen und Kunden (vgl. Kapitel 20).

Internet

Grundlage all dieser Bemühungen Richtung IT-Unterstützung und Automatisierung war eine immer detailliertere Erfassung und Modellierung der Geschäftsprozesse. Von einer punktuellen Erfassung wichtiger Prozessmeilensteine zu Beginn bis zur sehr detaillierten und umfassenden (u.U. auch systemnahen) Modellierung heute.

Immer detailliertere Erfassung

So kommt es, dass wir heute, wenn wir mit Geschäftsprozessen ungehen, so gut wie immer mit IT-Unterstützung arbeiten, oftmals das Internet nutzen und an einigen Stellen auf automatisierte Prozessabschnitte stoßen.

 

3 Kategorisierung von Geschäftsprozessen

Geschäftsprozesse werden nach unterschiedlichen Kriterien kategorisiert. Die wichtigsten werden wir hier betrachten.

3.1 Kern- und Supportprozesse

Angesichts der Bedeutung des Zieles, Wertschöpfung zu erreichen [Anmerkung] , verwundert die erste schon sehr früh in der Diskussion des Geschäftsprozessmanagements definierte (auf Porter zurückgehende) Unterscheidung 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 Definition der Kernprozesse ist wichtig. Natürlich leisten alle Geschäftsprozesse einen Beitrag, 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 Kerngeschäftsprozessen meist noch präzisiert wird in Bezug auf folgende Punkte:

  • Kundenähe
  • Profilbildung
  • Wettbewerbssituation
  • Leistungserbringung
  • Hauptleistung

Kerngeschäftsprozesse müssen, sollen sie auf Dauer erfolgreich sein, an den Kunden ausgerichtet werden (vgl. z.B. [Hammer und Champy 2006], [Gadatsch 2013, Position 346], [Schmelzer und Sesselmann 2013, S. 53]). Schmelzer/Sesselmann gehen sogar so weit, dass sie fordern, jeder Kerngeschäftsprozess müsse beim Kunden beginnen (Kundenwunsch) und bei ihm enden (Lieferung).

Kundennähe

Dies kann ergänzt werden. Da ja ständig neue Leistungen und Produkte entwickelt werden, von denen man hofft, dass sie von den Kunden angenommen werden, müssen auch die potentiellen Kunden in den Adresssatenkreis miteinbezogen werden. 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.

Potentielle Kunden

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

Profilbildung

Kernprozesse stehen sozusagen voll im Wettbewerb. Sie sind wettbewerbskritisch [Gadatsch 2013, Position 346].

Wettbewerbssituation

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

Leistungserbringung

Kerngeschäftsprozesse erscheinen oftmals fixiert, fast zementiert. Dies sind sie aber nicht, sie ändern sich im Zeitablauf. Teilweise oder auch ganz. Die Wirtschaftsgeschichte kennt zahlreiche Beispiele dafür. Zum Beispiel die Kreditinstitute, bei denen die Bereitstellung der Konten mal ein Kerngeschäftsprozess war oder große IT-Unternehmen, die von Hardwareprodukten auf Dienstleistungsangebote umstell(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.

Änderungen

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 für Kernprozesse

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 Prozessabwicklungin vollem Umfang realisiert. Verlangt sind Schnelligkeit, Übersichtlichkeit, einfacher und sicherer Bezahlvorgang und automatisiertes Customer Relationship Management. Alle Geschäftsprozesse, die dazu einen Beitrag leisten, z.B. auch in der Softwareentwicklung, sind Kernprozesse.
  • Für Dienstleistungsunternehmen im Transportbereich ist die eigentliche Transportleistung 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 Kernprozessen. Ein unterstützender Prozess ist die Abrechnung von Messeveranstaltungen.
  • In einem Steuerbüro gehört die Erstellung der Finanzbuchhaltungen, der Jahresabschlüsse, der Steuererklärungen und Lohnabrechnungen zu den Kernprozessen (je nach Ausrichtung der Geschäftstätigkeit). Ein Beispiel für einen unterstützenden Prozess ist die Neumandantenwerbung.
  • In einem Handelshaus gehören die Auftragsabwicklung und die Einkaufsabwicklung (Qualität, Preis, ...) zu den Kernkompetenzen. Unterstützende Prozesse sind hier z.B. die Qualitätskontrolle, der Kundenservice, das Personalwesen, das Mahnwesen und die Kundenaquisition.
  • 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.
  • In einem Softwarehaus gehört die Entwicklung (Systemanalyse, Systemdesign, Programmierung) und der adäquate Einsatz von Methoden und Werkzeugen zu den Kernkompetenzen.
  • In einem Softwarehaus, das integrierte prozessorientierte Software (ERP-Software) anbietet, ist neben den im vorigen Punkt genannten Tätigkeiten auch die möglichst effiziente Planung der „vorgedachten“ Geschäftsprozesse (vgl. [Staud 2006] und deren möglichst automatisierte Realisierung ein Kerngeschäftsprozess.

Etwas konkreter - Beispiele für kundennahe Geschäftsprozesse

Hier nun noch einige Beispiele, die direkt mit den Kunden zu tun haben. Stellen wir uns einen mittelständischen Betrieb vor, der Investitionsgüter herstellt. Hier können folgende kundennahe Prozesse gefunden werden:

Vertrieb Innendienst

  • Bestellungsbearbeitung
  • Angebotsanfrage
  • Erstellung Verzugsmeldung
  • Änderungswunsch annehmen
  • Preislisten (Erstellung und zur Verfügung stellen)
  • Kundenkontakt allgemein (Einladungen, Informationen, etc.)

Vertrieb Außendienst

  • Kundenbesuche
  • Reklamation bearbeiten
  • Feedback annehmen, verarbeiten
  • Reiseberichte erstellen
  • Technische Beratung
  • Absprache zur Werkzeugkorrektur, zu Änderungsvorschlägen

Konstruktion

  • Konvertierung Kunden CAD
  • Freigabezeichnung
  • Kundenzeichnung
  • Werkzeugkorrektur

Arbeitsvorbereitung

  • Ablauf-/Zeitplanung
  • Änderungswünsche prüfen
  • Verzugsmeldung an Vertrieb
  • Statusabfrage Kundenauftrag im Bearbeitungsprozess

Versand

  • Rechnungserstellung
  • Versandtracking
  • Papiere bereitstellen für Nicht-EU-Versand
  • Rückholungsauftrag

Qualitätsmanagement:

  • Prüfprotokolle / Erstbemusterung
  • Reiseberichte
  • Reklamationsbearbeitung
  • Kundendatenanalyse (z.B. Prozessdaten)

Automatisierungspotential bei Kernprozessen

Das Automatisierungspotential bei bei Kernprozessen ist sehr unterschiedlich. Geht es dabei um kreative Vorgänge (Marketingstrategie entwerfen, neue Leistungen entwickeln, ...), ist kaum Automatisierung möglich, die Prozesse können lediglich durch die IT unterstützt werden. Geht es um die Produktion hochwertiger Güter, ist auch die Produktion ein Kernprozess, der sehr stark automatisiert ist und dessen Automatisierungsniveau gerade durch die Angebote rund um Industrie 4.0 höher getrieben wird.

Kreative Vorgänge

Falls E-Commerce, also der Vertrieb über das Internet vorliegt, ist das Automatisierungspotential sehr hoch. Es liegen vollautomatisierte Prozesse vor, sowieso gegenüber den Kunden, das gehört zum Geschäftsmodell, aber auch darüberhinaus in die Supportprozesse hinein.

E-Commerce

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.

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.

Automatisierungs-kandidaten

Einige Beispiele für Supportprozesse:

  • Gehaltszahlung
  • Beantragung von Urlaub
  • Bezahlung einer Rechnung
  • Zahlungseingangsprüfung
  • Bearbeitung einer Reklamation

Wertschöpfungskette

Die wichtigsten Geschäftsprozesse sind für Unternehmen die der sog. Wertschöpfungskette (manchmal auch Wertkette). Darunter wird die gesamte Prozessfolge verstanden, die der Leistungserstellung dient und hoffentlich die Wertschöpfung realisiert. Der Begriff geht auf Porter zurück. Vgl. zu seinem Konzept der Wertkette(value chain) [Porter 1985], [Porter 1998, S. 77ff], [Porter 1999]).

Bedeutung für die Gestaltung der IT

Für das Thema Geschäftsprozessmanagement ist die Identifizierung und Unterscheidung von Kern- und Supportprozessen von großer Bedeutung. Kernprozesse sollen durch ihr indviduelles Profil und ihre Leistungsstärke 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. Solche Aktivitäten rund um Geschäftsprozesse sind im Überschneidungsbereich von Geschäftsprozessmanagement und IT-Management angesiedelt (Bereich A von Abbildung 1.5-1).

3.2 Steuerungs- und Führungsprozesse

Eine andere Unterscheidung hebt auf die Managementebene, die Art der Problemlösung ab (vgl. Abschnitt 2.4). Führungsprozesse (Managementprozesse, Steuerungsprozesse) sind für die übergreifende Planung, Steuerung und Kontrolle zuständig (obere drei Ebenen von Abbildung 2.5-1). Mit ihnen werden die Kern- und Unterstützungsprozesse geplant und gesteuert [Gadatsch 2013b, S. 38]. In diesen Leitungsebenen sind andere Prozesse und Prozessschritte notwendig, als in der Ausführungsebene. 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 Wertschö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 leistungserstellenden und unterstützenden Prozesse." [Gadatsch 2013a, Pos. 1430]

3.3 Primäre und sekundäre Geschäftsprozesse

Schmelzer und Sesselmann empfehlen die Unterscheidung von primären und sekundären Geschäftsprozessen [Schmelzer und Sesselmann 2013, S. 67]. Primäre Geschäftsprozesse erzeugen Leistungen (Produkte und/oder Dienstleistungen) für externe 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 weitgehend 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ützungsprozesse ein und weisen darauf hin, dass sekundäre Geschäftsprozesse in der Regel keinen direkten Marktbezug haben und sich nur indirekt auf die Wettbewerbsfähigkeit ausweisen. Wichtig ist ihr Hinweis auf eine wichtige Ausnahme: Der Strategieprozess („Strategie planen und überwachen"), der "die Weichen für das Erzielen nachhaltiger Wettbewerbsvorteile stellt" [Schmelzer und Sesselmann 2013, S. 67].

3.4 Kreative / wissensintensive Prozesse

Es gibt Geschäftsprozesse, die sich nur eingeschränkt erfassen und detailliert beschreiben lassen. Ihre Leistung wird wesentlich durch die beteiligten Menschen erbracht. Die Autoren nähern sich auf unterschiedliche Weise dieser Thematik. In der Modellierung 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 Menschen wesentlich auf der Basis von Erfahrungen und Wissen Probleme lösen sowie Entscheidungen fällen, wird hier auch von wissensintensiven Prozessen gesprochen. Schmelzer/Sesselmann charakterisieren die wissensintensiven Geschäftsprozesse als Typ-I-Geschäfts­prozesse (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, Erfahrungen und Einschätzungen der Verantwortlichen sowie der Mitarbeiter(...)" sehen sie als Kernaspekte dieser Prozesse [ebenda, S. 71].

 

4 Identifikation und Standardisierung

4.1 Identifikation

"Identifikation der Geschäftsprozesse" klingt merkwürdig, schließlich sind die Geschäftsprozesse ja meist schon da, sonst gäbe es das Unternehmen oder die Organisation 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 (z.B. auch Abgrenzung) eines Geschäftsprozesses. Dies kann verschiedene Ursachen haben:

Um was geht’s?

  • 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 unmittelbar dort Aktiven klar ist. Falls möglich, sollte dies geändert und die Geschäftsprozesse dokumentiert werden.
  • Unternehmen wurden verschmolzen ("merging"), Prozesse müssen angeglichen werden. Auch hier ist im ersten Schritt die Identifizierung der Prozesse in den beiden Unternehmen 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 voranzutreiben, werden die alten Geschäftsprozesse durch neue softwarebasierte ersetzt. 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 Prozessidentifizierung auch 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 Geschä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.

Beim Top Down - Vorgehen löst man sich völlig von der vorhandenen Prozesslandschaft 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 vorhandener Prozesslandschaft, falls ein radikaler Neuanfang gewollt ist sowie bei einer völligen Neuentwicklung mit oder ohne Automatisierungsabsicht

Top Down

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 Geschä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 verlagerten Geschäftsprozessen und den übrigen neu gestaltet werden. Unter Umständen muss auch der Umgang der Geschäftsprozesse mit den Datenbestä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 Arbeitsschritte und Subprozesse. Dabei entdeckte Optimierungspotentiale werden genutzt/umgesetzt. Hierbei entstehen Sollprozesse. Im nächsten Schritt werden die Automatisierungsmöglichkeiten ausgelotet: Welche Prozessabschnitte können, welche sollen in Software gefasst werden. Falls der Prozess vollständig automatisiert werden soll, muss eine Prozessmodellierung für das Anforderungsmanagement 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 Aufbauorganisation abstrahiert, da der Prozessgedanke ja die Überwindung der Aufbauorganisation 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 aufwendig, 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.

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

(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 Geschäftsprozesse entsteht. Wird dies kompetent realisiert, kann eine Optimierung gegenüber der vorliegenden Situation erfolgen.

Chancen

Bei einer sehr unterentwickelten Prozesslandschaft kann diese Vorgehensweise vorteilhaft sein, weil eine solche sich nicht als Ausgangspunkt eignet. Für Sekundärprozesse ist sie aber nicht sinnvoll, hierfür gibt es standardisierte vorgedachte Geschäftsprozesse.

Das Bottom Up - Vorgehen geht von der bestehenden Prozesslandschaft und der vorhandenen Aufbauorganisation aus. Folgende Schritte werden vorgeschlagen:

Bottom Up

  • Erhebung und Modellierung der Istprozesse
  • Schwachstellenanalyse der Istprozesse
  • Modellierung von Soll-Prozessen, die auf den von Schwachstellen bereinigten Ist-Prozessen 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. Organisationsgrenzen
  • Redundanzen zu anderen vergleichbaren Prozessen würden nicht erkannt
  • Vorgehen sei eher auf die Beseitigung von Schwachstellen als auf Chancennutzung 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 unterentwickelten Prozesssituation aus, wie man sie zu Beginn der Phase der Prozessorientierung tatsächlich vorfand. Inzwischen ist aber, so die Erfahrung des Verfassers, der Wissensstand der Beteiligten und der Reifegrad der Prozesslandschaft so, dass die meisten dieser Fehler vermieden werden (können).

Trotzdem bleibt es dabei: Dem Bottom Up - Vorgehen fehlt der Reiz des Neuanfangs und vieleicht macht dies den Top Down - Ansatz für viele so attraktiv.

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äftsprozesse einer integrierten prozessorientierten Standardsoftware (z.b. ERP-Software) eingekauft (vgl. auch [Staud 2006, S, 34f]). Da hat dann das "Finden" und die Gestaltung der Prozesse 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äftsprozesse durchgeführt, bei Supportprozessen wird meist die Lösung der Integrierten prozessorientierten Software gewählt.

Vorgedachte Geschäftsprozesse

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 Anwendungssoftware 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 13.3.5 eingeführte Unterscheidung von Prozessmodell und Prozessinstanz benötigt. Das Prozessmodell gibt an, welche Durchgänge durch den Prozess möglich sein sollen. Eine Prozessinstanz gibt einen konkreten Durchgang an.

Prozessmodell vs. Prozessinstanz

Wer in einem hinreichend großen Unternehmen tätig ist, kennt es. Ein Geschäftsprozess („Beschaffung“) wird an verschiedenen Stellen im Unternehmen unterschiedlich realisiert. Die allgemeine Prozessvorstellung ist also in Unternehmensbereichen oder auch Abteilungen unterschiedlich. Dies ist in einer Zeit, in der schon mittelständische Unternehmen weltweit Tochtgesellschaften oder Vertretungen haben, ein wichtiges Thema:

Quellen des Standardisierungs­bedarfs

  • In einem Unternehmen mit Tochtergesellschaften im nationalen Rahmen werden u.U. dieselben Prozesse in den Tochtergesellschaften auf unterschiedliche Weise durchgeführt.
  • In einem international agierenden Unternehmen sind in den jeweiligen nationalen Gesellschaften Geschäftsprozesse unterschiedlich realisiert. Und dies nicht nur wegen kultureller Unterschiede oder wegen Unterschieden in Bezug auf rechtliche und gesetzliche Festlegungen.

Eine weitere Quelle für den Standardisierungsbedarf ist das Verschmelzen von Unternehmen ("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.

Die Standardisierung ist auch sinnvoll, weil ihre Realisierung die Abbildung des Prozesses in eine IT-Lösung wesentlich erleichtert bzw. erst sinnvoll erscheinen lässt.

Grundsätzlich ist eine Standardisierung allerdings nur dann sinnvoll, wenn der Geschäftsprozess viele Routineanteile enthält und wenn er 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 3.4).

Die Standardisierung bringt zahlreiche Vorteile. Sie schafft ein einheitliches Erscheinungsbild gegenüber den Kunden und Lieferanten, gewährleistet einheitliche Unternehmensschnittstellen mit Kunden, Lieferanten und Partnern und erleichtert die Kommunikation.

Vorteile der Standardisierung:

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], [Gaitanides 2012, S. 139].

Obwohl die Standardisierung heute unumgänglich ist, weil ohne sie IT-Untersützung und Automatisierung kaum möglich ist, gibt es auch Nachteile bzw. Risiken, die aber nicht die Standardisierung als solche, sondern deren Realisierung betreffen:

Nachteile/Risiken der Standardisierung:

  • Falls Geschäftsprozesse standardisiert werden, deren Unterschiede durch Kundenwünsche oder regionale Besonderheiten begründet sind und die besser erhalten 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 standardisieren, 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 gemacht wird.

 

5 Ist- und Sollmodellierung

5.1 Istmodellierung

Eine Bestandsaufnahme der bestehenden Geschäftsprozesse wird Istmodellierung oder auch Istanalyse genannt. Sie kann sich auf einzelne Geschäftsprozesse oder auf Teile der Prozesslandschaft beziehen. Ihr Ziel ist, Defizite und Verbesserungspotentiale in den Geschäftsprozessen zu erkennen. Die Erhebung muss, soll sie aussagekräftig sein, umfassend erfolgen.

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 (vgl. Kapitel 12). Geht es um Überblicksgewinnung wird eine höhere Aggregationsebene gewählt.

Verschiedene Ebenen

Erhoben werden alle Komponenten (Träger, Aufgaben, ...) und ihr Zusammenhang (Kontroll- und Nachrichtenflüsse, evtl. andere Flüsse), soweit sie für die Modellierungsebene notwendig sind.

Prägung durch Zielsetzung

Jede Prozessmodellierung hat die allgemeine Zielsetzung, den Prozess zu erfassen, kennenzulernen, zu optimieren, usw., wie oben besprochen. Manchmal kommen aber noch weitere dazu, die sich aus tatsächlichen oder vermuteten Defiziten ableiten. In diesen Prozessen oder Prozessabschnitten erfolgt die Istanalyse wesentlich detaillierter, sozusagen in Vorbereitung der nachfolgenden Optimierungsbemühungen.

Subjektivität 3

Dazu zwei Beispiele, die der Verfasser in der Praxis beobachten konnte. Das erste ist in [Staud 2006, Abschnitt 6.2] vorgestellt. Dort wird ein Geschäftsprozess vorgestellt, mit dem die ganze Auftragsabwicklung eines mittelständischen Unternehmens modelliert wurde. Der Schwerpunkt lag aber auf der Frage, inwieweit die Erstellung der hierbei notwendigen CAD-Unterlagen durch die Einführung eines leistungsstärkeren CAD-Systems verbessert werden könnte. Deshalb wurde in Prozessabschnitten, die dies thematisieren, die Modellierung sehr detailliert („ausgedruckte CAD-Unterlatgen in Schubladen ablegen“), während 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 wurde.

Beispiel 1 – leistungsstärkeres CAD-System

Das Ergebnis waren hier sehr unterschiedliche Aggregationsniveaus in den Prozessmodellen. Von tayloristisch anmutenden Abschnitten bis zu groben Überblicken („Teile beschaffen“).

Das zweite Beispiel betrifft die Datensicherung bei einem Finanzdienstleister. Im Rahmen eines übergreifenden Projekts zur Prozessmodellierung fiel auf, dass die Geschäftsprozesse rund um die Sicherung und Wiederbereitstellung (nach einem entsprechenden Vorfall) der Daten in sehr viel größerer Detailliertheit erfasst wurden, als der Rest der Prozesswelt. Ursache war nicht nur die große Bedeutung dieser Vorgänge im digitalisierten Zeitalter, sondern das ausgefeilte rechtliche Rahmenwerk, das auch auf die Prozessgestaltung Einfluss hatte.

Datensicherung

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 ist meist auch eine tabellarische Beschreibung von Geschäftsprozessen notwendig. Ein einfaches Formular zur Erhebung von Prozessinformationen ist in der folgenden Abbildung angegeben.


Abbildung 5.1-1: Formular zur Erhebung von Prozessinformationen

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. Nachbestellung), das Datum der Erstellung der Beschreibung, der Name des Erstellers und der Automatisierungsgrad angegeben.
  • Auslöser des Prozesses (Nachbestellanforderung aus dem Lager)
  • Ergebnisse: Ergebnisse des Prozessablaufs (Nachbestellung oder Ablehnung derselbigen)
  • Rollen, die hier aktiv werden
  • Prozessverantwortliche(r): Person oder Software, die für den Prozess verantwortlich 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
  • Datenbankzugriff: Zugriffe auf die Datenbanken des Unternehmens

5.1.2 Zweck?

Die Istmodellierung erfolgt meist zur Feststellung von Schwachstellen (vgl. unten) oder einfach zu Dokumentationszwecken (z.B. im Rahmen einer ISO-Zertifizierung). Weitere Ziele werden unter dem Stichwort Einsatzzwecke von Prozessmodellen in [Becker, Kugeler und Rosemann 2012, S. 199f] genannt:

Schwachstellen beseitigen

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

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

Ein wichtiges Ziel ergibt sich bei der Einführung einer prozessorientierten Standardsoftware (z.B. ERP-Software). Der Vergleich der konkreten vorliegenden Geschä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 entdecken kann. Besonders wichtig sind evtl. Defizite in der Daten- und Prozessintegration. Aus ihnen entstehen Medien- und Organisa­tionsbrü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. Organisationsbrüche sind, auf unterschiedliche Weise, ebenfalls in der Modellierung erkennbar: Zu übergebende Information muss angepasst werden. Zuständigkeiten wechseln, obwohl nicht sachlich begründet. Solche Defizite treten heute meist nur an Unternehmensgrenzen auf, nicht mehr innerhalb der Organisationen.

Daten- und Prozessintegration

Eine Istmodellierung darf sich allerdings nicht nur auf Störungen im Prozessablauf beschränken. Sie muss auch alle Prozessaktivitäten hinsichtlich Effektivität und Effizienz untersuchen, auch diejenigen, die sich nicht als Störungen äußern. Dies kann im Extremfall auch dazu führen, dass der Geschäftsprozess als Ganzes für überflüssig erachtet oder durch eine automatisierte Variante ersetzt wird.

Effektivität und Effizienz

Hier einige konkrete 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):

  • 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 die zusätzliche Analyse des Geschäftsprozessmanagements erkennt man Defizite wie:

  • mangelnde Prozessorientierung
  • unzulängliche Prozessverantwortlichkeiten
  • fragmentierte Verantwortlichkeiten

Manche Defizite treten bei der Prozessmodellierung gleich zutage. Andere nur bei entsprechender Schwerpunktsetzung, entsprechend den Zielen. Diese Ziele prägen die konkrete Ausgestaltung der Prozessmodellierung sehr stark. Je nach vermutetem Defizit wird sie unterschiedliche Schwerpunkte haben. In [Staud 2006, Abschnitt 6.2] wird ein Geschäftsprozess vorgestellt, in dem dies sehr deutlich wird. Modelliert wird eine ganze Auftragsabwicklung. Der Schwerpunkt lag aber auf der Frage, inwieweit die Erstellung der notwendigen CAD-Unterlagen verbessert werden könnte. Deshalb wird in Prozessabschnitten, die dies thematisieren, die Modellierung sehr detailliert, während 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.2 Sollmodellierung

Aufbauend auf der Istmodellierung und den dabei entdeckten Schwachstellen (und weiterer Schwachstellenanalysen) kann die Erstellung von Prozessmodellen erfolgen, in denen die Schwachstellen beseitigt sind. Dies wird Sollmodellierung genannt, die dann zu Sollprozessen führt.

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

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 Funktionserfüllung, Abschaffung von Medienbrüchen, Abschaffung von nicht sinnvollen Genehmigungsschritten.
  • Vergabe von Teilprozessen oder vollständigen Prozessketten durch externe spezialisierte Dienstleister (z. B. Buchführung und Bilanzierung durch einen Steuerberater).
  • Zusammenfassung arbeitsteiliger Aufgaben dergestalt, dass ein Bearbeiter zusammengehörige Teilprozesse vollständig ohne Bearbeiterwechsel durchführt (z. B. Kundenberatung und Auftragserfassung bis zur Erstellung der Auftragsbestätigung).
  • Erhöhung der Arbeitsteilung bei parallelisierbaren Teilschritten (z. B. Klausurkorrektur 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 Erfassung 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 Bestelldaten im Rahmen der Auftragserfassung und Freigabe des Auftrages erst nach vollständiger Plausibilisierung der Daten).
  • 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].

<<Wie müssen, angesichts der generellen Automatisierungsbemühungen die Überlegungen und Maßnahmen bzgl. einer Sollmodellierung aussehen?

Fragen

<<Wie müssen, angesichts der aktuellen Wege zur Automatisierung die Überlegungen und Maßnahmen bzgl. einer Sollmodellierung aussehen?>>

<<Wie müssen, angesichts der umfassenden Digitalisierung der Geschäftswelt die Überlegungen und Maßnahmen bzgl. einer Sollmodellierung aussehen?>>

 

6 Strategisches Geschäftsprozessmanagement

6.1 Einleitung

Strategisches Management

Das strategische Geschäftsprozessmanagement ist in das ganz allgemeine Strategische Management eingebettet. Dieses befasst sich damit, wie die Geschäftstätigkeit des Unternehmens optimal gestaltet werden kann. Dazu gehört auch die Klärung der Erfolgsfaktoren und der Kernkompetenzen der Organisation. Ausgangspunkt ist dabei die strategische Zielsetzung der Organisation, die Geschäftsstrategie.

Einbettung

Strategisches Management hat also - mit anderen Worten - die Aufgabe, das (profitable) Fortbestehen des Unternehmens langfristig zu sichern.

Die Aufgaben des strategischen Managements beziehen sich auf das gesamte Unternehmen, nicht auf die einzelnen Geschäftsprozesse. Zu ihnen gehören:

Für das gesamte Unternehmen

  • 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 erweisen")
  • Identifizierung von zukünftigen Tätigkeitsfeldern, Geschäftsfeldern und strategischen Geschäftseinheiten ("nationale Cloud-Angebote")

In Anlehnung an [Schmelzer und Sesselmann 2013, S. 18].

Strategisches Geschäftsprozessmanagement

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 (Prozessvision, strategische Prozessziele)?
  • Wie soll die organisatorische Verankerung des Geschäftsprozessmanagementsystems im Unternehmen umgesetzt werden, welche Rollen werden definiert und eingerichtet.

Dies führt zum strategischen Geschäftsprozessmanagement, das somit Teil des strategischen Managements ist. Hier bauen die Überlegungen auf obigem auf, konzentrieren sich aber auf die Geschäftsprozesse. Dabei geht es um die langfristige 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 / primäre Geschäftsprozesse.

Langfristige Ausrichtung, Ausgestaltung und Ausstattung

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 Geschäftsprozessen, denn bei konsequenter Umsetzung stellt das strategische Geschä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 IT-Unterstützung und Automatisierungsmöglichkeiten, zusammen mit dem IT-Management.
  • Klärung der Möglichkeiten und Grenzen des Outsourcing und Cloud Computing (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.2 Prozessvision und Prozessziele

Zentrale Konzepte des strategischen Geschäftsprozessmanagements sind Prozessvision und Prozessziele.

Eine Prozessvision sollte ...

Prozessvision

  • nachvollziehbar sein.
  • langfristigen Interessen entsprechen.
  • realistische Ziele enthalten.
  • ausreichend spezifisch sein.
  • flexibel sein, sodass sie auch bei veränderten Bedingungen Gültigkeit besitzt.

[Schmelzer und Sesselmann 2013, S. 83f].

Die Prozessziele werden aus den Unternehmenszielen abgeleitet. Sie sind mit geeigneten 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. Besteht zum Beispiel das Prozessziel Marktführer zu werden, muss man die Ziele für die einschlägigen Geschäftsprozesse entsprechend formulieren, z.B. in der Entwicklung ("jedes Jahr ein neues Produkt"), im Vertrieb ("Auslieferung innerhalb eines Tages") und bei der Leistungserbringung ("Fehlerquote unter 0,5%).

Prozessziele

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öglichst großer Effektivität und Effizienz.

6.3 Kernkompetenzen

Im Zusammenhang mit strategischen Überlegungen spielen die Kernkompetenzen des Unternehmens eine zentrale Rolle. Sie sollten so etwas wie Alleinstellungsmerkmale darstellen. Sie müssen gefunden, gepflegt und u.U. hinzugewonnen werden. Bei effektivem Einsatz (meist in Kerngeschäftsprozessen) führen sie zu dauerhaften Wettbewerbsvorteilen, die von den Mitbewerbern nur schwer imitiert oder substituiert werden können. Insbesondere für den langfristigen Unternehmenserfolg sind sie von zentraler Bedeutung.

Alleinstellungs­merkmale

Der Begriff Kernkompetenz spricht die besonderen, den Erfolg sichernden Fähigkeiten der Organisation an. Diese liegen bei den einzelnen Mitarbeitern vor oder im Zusammenwirken von Mitarbeitern (in Abteilungen, Projekten oder sonst wie). Auch der Einsatz von bestimmten Technologien ("Erstellung, Pflege und ständige Optimierung der Präsenz im E-Commerce"; früher: "Erstellung hochwertiger Alluminium-Chassis für Automobile") kann eine Kernkompetenz darstellen.

Kernkompetenzen entstehen also 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 auszugeben.
  • 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 besitzen. Becker/Meise fordern hier eine „langfristige Bedeutung“. Dem kann angesichts der schnellen Umwälzungen in Wissenschaft und Technik nur eingeschränkt zugestimmt werden. Auch Kompetenzen können heute über Nacht wertlos werden oder ihr Profil verändern.

Für eine vertiefte Diskussion vgl. [Becker und Meise 2012, S. 102f].

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

Während sich die operative Prozessplanung zumeist über ein bis zwei Jahre erstreckt, liegt der zeitliche Rahmen 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äftsprozessverantwortlichen vereinbart [Schmelzer und Sesselmann 2013, S. 87].

Zeitlicher Rahmen

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 Strategieumsetzung gelegt. Die Balanced Scorecard dient der Strategieumsetzung, nicht der Strategiefindung. Für eine nähere Beschreibung vgl. [Schmelzer und Sesselmann 2013, S. 18f].

6.5 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 definiert. Vorab ist eine eindeutige Identifikation der Geschäftsprozesse (Kapitel 5) und eine Typisierung vorzunehmen (vgl. Kapitel 3).

Wichtige kritische Erfolgsfaktoren (vgl. unten) sind meist auf hohem Abstraktionsniveau formuliert und 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, kann die konkrete Prozessdurchführung mit den gesetzten Zielen abgeglichen werden. Zu einem solchen Zielsystem, wie Alpar/Alt/Bensberg es nennen, gehören

  • Organisationsziele/Unternehmensziele,
  • kritische Erfolgsfaktoren und
  • Führungsgrößen

[Alpar, Alt, Bensberg u.a. 2014 (E-Book), Pos. 3261]

Organisationsziele definieren die langfristige Richtung der Aktivitäten, ohne unmittelbar umsetzbar zu sein. Beispiele dafür sind:

Organisationsziele

  • Marktführer werden in einem bestimmten Segment
  • Attraktives Webportal einrichten
  • Erhöhung der Kundenzufriedenheit
  • Auslieferungszeiten verkürzen
  • Innovationskraft erhöhen

[ebenda, Pos. 3017, 3024]

Mit Erfolgsfaktoren sind die Leistungsfaktoren gemeint, die dem Erfolg der Organisation dienlich sind. Einige Beispiele:

Erfolgsfaktoren

  • hoher Prozessreifegrad (vgl. Kapitel 9)
  • 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 konkretisieren die (langfristigen) Organisationsziele z. B. durch kürzere Fristigkeit, durch Bezug zu aktuellen Lösungen und/oder durch Quantifizierung. Es sind solche, die den Erfolg eines Prozesses maßgeblich beeinflussen [Heinrich und Lehner, 2005, S. 344]. Sie sind meist auf hohem Abstraktionsgrad formuliert und müssen daher auch operationalisiert werden. Beispiele sind:

Kritische Erfolgsfaktoren

  • Investitionen in Forschung und Entwicklung erhöhen (bzgl. Organisationsziel "größere Innovationskraft")
  • Fähigkeiten der Mitarbeiter erhöhen (bzgl. Organisationsziel "größere Innovationskraft")
  • Prozessdurchlaufzeit senken (bzgl. des Organisationsziels "Auslieferungszeiten verkürzen")
  • Verbesserung der Kundenbindung
  • Optimierung des Webportals (bzgl. des Organisationsziels "Erhöhung der Kundenzufriedenheit")

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.

Führungsgrößen


Abbildung 6.5-1: Zielsystem eines Unternehmens

Das Zielsystem kommt immer dann zum Einsatz, wenn Effektivität und Effizienz der Prozessrealisierung gemessen werden sollen.

6.6 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 Prozessergebnissen 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 Produkt") und Marketing, ohne das heute kaum mehr verkauft werden kann.

Effektivität

Geschäftsprozesse sind effizient, wenn die Kundenleistungen mit möglichst geringem 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.

Effizienz

Zielgrößen

Es gibt zahlreiche Zielgrößen für die Effektivität und Effizienz von Geschäftsprozessen. Die wichtigsten sind die folgenden:

Für Effektivität:

  • Kundenzufriedenheit mit den möglichen Zielen "Senkung der Anzahl an Reklamationen", "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 mit dem Ziel, Lieferzusagen unter allen Umständen einzuhalten.
  • Prozessqualität mit dem möglichen Ziel "Leistungsfähigkeit besser als Wettbewerb", 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].

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.

 

7 Prozesscontrolling

Prozesscontrolling ist eine Teilaufgabe des allgemeinen Controlling mit dem Fokus auf Geschäftsprozesse. Es umfasst alle Aufgaben, Methoden und Techniken "zur Zielplanung und -kontrolle von Geschäftsprozessen sowie die damit verbundene Informationsversorgung und Koordination" [Schmelzer und Sesselmann 2013, S. 265] und gibt damit eine Antwort auf die Frage, ob die Durchführung der Prozesse erfolgreich ist.

Die dafür notwendige Messung der Leistung erfolgt auf Basis des Zielsystems der Organisation (vgl. Abschnitt 7.5).

Das strategische Prozesscontrolling unterstützt durch Planung, Umsetzung und Monitoring geeigneter prozessbezogener Maßnahmen die Erreichung der strategischen Unternehmensziele, also die Umsetzung der Unternehmensstrategie. Der Fokus liegt somit auf der Schaffung von prozessorientierten Erfolgspotenzialen bzw. Kernkompetenzen [ebenda, S. 266].

Strategisch

Dagegegen liegt der Schwerpunkt des operativen Prozesscontrolling auf der Nutzung der Erfolgspotentiale zur Erzielung einer hohen Prozesseffektiviät und - effizienz [ebenda, S. 266]. Dazu werden Ziele gesetzt und die Zielerreichung gemessen.

Operativ

Obiges macht klar, dass strategisches und operatives Prozesscontrolling voneinander abhängen. Werden im strategischen Prozesscontrolling die falschen Maßnahmen ergriffen, sind die Erfolgspotentiale falsch gesetzt und das operative Prozesscontrolling misst die falschen Werte.

Gadatsch definiert einen Regelkreislauf Prozesscontrolling, der die Zusammenhänge sehr deutlich macht:

  • Die Unternehmensstrategie beeinflusst die Prozessstrategie und umgekehrt.
  • Ausgehend von der Prozessstrategie gibt es dann den Regelkreislauf: Aus der Prozessstrategie werden Zielwerte ermittelt. Aus diesen zu realisierende Maßnahmen. Diese führen zu Istwerten, danach wird gegebenenfalls eine Abweichungsanalyse durchgeführt, die wiederum evtl. die Prozessstrategie beeinflusst.

Quelle: Vgl. die Abbildung in [Gadatsch 2015, Pos. 557]

7.1 Operatives Prozesscontrolling

Die Verantwortung für das operative Prozesscontrolling liegt "bei den Geschäftsprozessen". Folgende Aufgabenschwerpunkte gehören dazu:

1. Bestimmung und Gewichtung der Prozessziele pro Geschäftsprozess

2. Festlegung der Zielwerte für die Prozessziele

3. Definition der Prozesskennzahlen zur Kontrolle der Zielerreichung und zur Messung der Prozessperformance

4. Festlegung des Messsystems

[Schmelzer und Sesselmann 2013, S. 271]

Zielpräzisierung

Jedes Prozesszielbesteht aus drei Zieldimensionen[Schmelzer und Sesselmann 2013, S. 272ff]:

  • Zielinhalt: Was ist zu erreichen? Zum Beispiel eine Reduzierung der Auslieferungszeit.
  • 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 terminiert (vgl. [Schmelzer und Sesselmann 2013, S. 272]). Bezogen auf Geschäftsprozesse bedeuten diese Anforderungen:

SMART

  • 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 erreichbar 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 Prozessebenen und alle Prozessmitarbeiter das Erreichen der Geschäftsprozessziele und damit der Geschäftsziele unterstützen" [Schmelzer und Sesselmann 2013, S. 272f].

Vertikal, horizontal

Kosten/Nutzen

Prozessziele sind mit Kosten verbunden. Das betrifft ihre Festlegung aber vor allem ihre Messung. Die Kosten müssen in Relation zum Nutzen gesetzt werden. Deshalb wird man für Kernprozesse mehr Aufwand betreiben als für Supportprozesse. 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ührungshäufigkeit verspricht mehr Einsparung bei Zielerreichung.

Kosten durch Prozessziele

Bei automatisierten Prozessen liegt eine besondere Situation vor. Der Geschäftsprozess 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 entsprechenden Programmkomponente, danach müssen die Ergebnisse nur noch gelesen werden. Deshalb sind hier die "beobachteten" Programmziele recht zahlreich.

Automatisierte Geschäftsprozesse

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 strategischen Gewicht eines Geschäftsprozesses auszurichten" [Schmelzer und Sesselmann 2013, S. 275].

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 abgestimmte 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 Prozesskontrolle ist die Kenntnis der Wechselwirkungen zwischen Geschäftsstrategie und Geschäftsprozessen. Besteht zum Beispiel das strategische Ziel Innovationsführerschaft, dann sind Geschäftsprozesse wie Produkt planen, Produkt entwickeln betroffen. Diese Beziehungen hat die strategische Prozessplanung aufzuzeigen und zu berücksichtigen.

[Schmelzer und Sesselmann 2013, S. 266f] stellen folgende Aufgaben im strategischen Prozesscontrolling fest:

Aufgaben

  • Strategische Prozessplanung: Definition der Prozessstrategie mit Festlegung des strategischen Prozessprogramms, Festlegung strategischer Prozessziele und strategischer Prozesskennzahlen. 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 Geschäftsprozesse

Die strategische Prozessplanung legt auch die Kennzahlen fest, mit denen die Umsetzung der Maßnahmen in den Geschäftsprozessen kontrolliert wird.

Kennzahlen

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äftsprozessmanagements 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 zwischen Prozesscontrolling und Bereichscontrolling.

[Schmelzer und Sesselmann 2013, S. 266]

Instrumente

Neben dem Zielportfolio des Geschäftsprozessmanagements ist die Prozess Balanced Scorecard ein wichtiges Instrument für das strategische Prozesscontrolling. Es handelt sich um eine auf das Prozessgeschehen zugeschnittene Variante der allgemeinen Balanced Scorecard.

Die Balanced Scorecard ist ein kennzahlenbasiertes Führungs- und Steuerungssystem für das allgemeine Unternehmenscontrolling. Sie stellt eine strukturierte Sammlung von Zielen (und zugrundeliegenden Daten) dar, die eine Sicht der Unternehmens- 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äftsprozessmanagements aus.

Prozess Balanced Scorecard

"Balanced" bedeutet, dass die abgeleiteten Ziele unterschiedliche Sichtweisen berücksichtigen und aufeinander abgestimmt sind.

Die Balanced Scorecard für das Geschäftsprozessmanagement leitet von der Unternehmensvision und -strategie vier Perspektiven ab (vgl. [Kaplan und Norton 1996, S.7] sowie [Kaplan und Norton 2001], zitiert nach [Gaitanides 2012, S. 246f]):

  • die Finanzperspektive
  • die Kundenperspektive
  • die Geschäftsprozessperspektive
  • die Lern- und Entwicklungsperspektive, auch Potenzialperspektive 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, Prozessqualität, Prozesstermintreue gesteuert werden (vgl. [Schmelzer und Sesselmann 2013]). Für ein Beispiel zum Vertriebsprozess mit den Perspektiven Kunde, Prozessperformance, Ressourcen/Personal und Finanzen vgl. [Gadatsch 2015, Pos. 552].

Ziele für Perspektiven

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 Strategie 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 geschlossen 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 Literatur.

7.3 Prozesskennzahlen

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 Messung der Leistung eines Geschäftsprozesses anhand der Indikatoren Prozessqualität, Durchlaufzeit und Prozesskosten, die wiederum in operationale Messindikatoren untergliedert werden [Gaitanides 2012, S. 207].

Zweck

  • Prozessqualität ist definiert als die Menge der Fehler oder Abweichungen (vom geplanten Ablauf), die im Prozess auftreten.
  • Für die Durchlaufzeit werden Bearbeitungszeiten, Liegezeiten und Transferzeiten gemessen, aus denen sich dann die gesamte Druchlaufzeit ergibt.
  • Für die Prozesskosten wird der gesamte Resourceneinsatz erfasst, wie z. B. Gebäudekosten, Gehalts- und Gehaltsnebenkosten, Kosten für Datenverarbeitungssysteme usw.

Konkret geht es bei Prozesskennziffern i.d.R. um die Feststellung des Leistungsstands und um die Steuerung der Umsetzung der Prozessstrategie (z.B. Maßnahmen zur Verkürzung der Auslieferungszeit). Es sind also Maßnahmen eingeleitet worden und die Wirksamkeit dieser Maßnahmen soll gemessen werden.

Im oben angeführten Regelkreislauf des Prozesscontrolling, wie er von Gadatsch vorgestellt wurde sind die Kennzahlen die Basis für die Steuerung der Strategieumsetzung:

"Ausgehend von der Unternehmensstrategie wird eine Prozess-strategie erarbeitet. Zur Steuerung der Umsetzung werden Kennzahlen gebildet, die durch Maßnahmen umgesetzt werden sollen. Die Istwerte aus der Realität werden mit den Zielwerten der Kennzahlen abgeglichen und münden in eine Abweichungsanalyse. Hieraus können verschiedene Aktivitäten resultieren. Beispielsweise kann steuernd in die Maßnahmen eingegriffen werden (Veränderung von Ressourcen, Terminen, Zielen u. a.) oder aber es können Änderungen der Prozess-Strategie vorgenommen werden." [Gadatsch 2015, P. 557]

Zuständig für die Einrichtung von Prozesskennzahlen ist das Qualitätsmanagement, insbesondere die Person mit der Rolle Qualitätsmanagementbeauftragter. Zu den Nutzern gehören:

Zuständige

  • Prozessverantwortliche, Prozessmanager und Teilprozessmanager
  • Prozesscontroller
  • Führungskräfte mit Prozessverantwortung
  • Leiter und Mitarbeiter Prozessmanagement, Prozesskoordinatoren
  • Leiter und Mitarbeiter des Controllings
  • Leiter und Mitarbeiter des Qualitätsmanagements

7.3.1 Ausgangspunkt, Voraussetzungen

Am Anfang aller Bemühungen rund um Prozesskennziffern muss natürlich stehen, den "Gegenstand" – die Geschäftsprozesse – überhaupt korrekt zu erkennen. Dies kann auf den Bemühungen aufbauen, die Prozesse zu identifizieren und zu standardisieren (vgl. Kapitel 5). Gibt es hier Defizite, müssen diese beseitigt werden.

Gegenstand erkennen

Gibt es bereits eine ausgearbeitete Prozesslandschaft, ist diese natürlich die Grundlage (vgl. Kapitel 18). Wurden hier mehrere Bereiche ausgewiesen, sind v.a. die Kernprozesse Kandidaten für die Ausstattung mit Prozesskennziffern.

Danach muss das kommen, was als Istanalyse des Prozesses bezeichnet wird (vgl. Abschnitt 5.1). Mit ihr werden Schwachstellen und Entwicklungspotentiale erkannt. Diese werden mit den strategischen Organisationszielen abgestimmt, in detaillierte Ziele zerlegt und dann im Rahmen einer Sollmodellierung umgesetzt. Handelt es sich um Ziele, die in Prozesskennzahlen ausgedrückt werden können, wird dies unter Umständen (vgl. unten) getan.

Istanalyse

Für solche Prozesskennzahlen werden Zielwerte festgelegt ("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, Terminen, Zielen u. a.) oder der Prozessstrategie [Gadatsch 2015, Pos. 557].

Einsatz Prozesskennzahlen

Bleibt abschließend noch der Hinweis, dass man Prozesskennziffern natürlich mit Zielwerten ausstattet, die dann im Rahmen der Prozessüberwachung zu Aktionen führen. Auf jeden Fall mit einem "gewünschten" Zielwert, der im Rahmen der Optimierungsbemühungen erreicht werden sollte ("Auslieferungszeit von 3 auf 2 Wochen verkürzen"). Evtl. aber auch mit weiteren, die in gradueller Abstufung zu Hanldungen auffordern. Z.B.:

Zielwerte und Aktionen

  • Auslieferungszeit höher als 3 Wochen – Notfallmaßnahmen durchführen
  • Auslieferungszeit zwischen 2 und Wochen – Optimierungsmaßnahmen einleiten
  • Auslieferungszeit kleiner/gleich 1 Woche – keine Aktion nötig

7.3.2 Arten von Kennzahlen

[Gadatsch 2015] schlägt die folgende Unterteilung von Kennzahlen vor. Zuerst typmäßig in absolute Kennzahlen und Verhältniskennzahlen. Mit ersteren sind z.B. folgende gemeint:

Absolute Kennzahlen

  • Anzahl der Mitarbeiter
  • Anzahl der Prozesse
  • Anzahl der Prozessinstanzen

Verhältniskennzahlen werden unterschieden in

Verhältniskennzahlen

  • Gliederungskennzahlen (z.B. Anteil Prozesskosten an Gesamtkosten, Anzahl Prozessmitarbeiter an allen),
  • Beziehungskennzahlen (z.B. Schulungskosten je Mitarbeiter, Anteil Prozesskosten am Umsatz) und
  • Indexkennzahlen (z.B. Entwicklung Budget in den letzen 10 Jahren, Prognose Prozesskosten der nächsten 2 Jahre)

[Gadatsch 2015, Pos. 557].

Inhaltliche Untergliederung

In inhaltlicher Hinsicht können Prozesskennziffern vielfältig untergliedert werden. Hier einige Beispiele:

Ergebniskennzahlen zur Messung der Prozessqualität. Sie sollen erfassen, ob der Geschäftsprozess die gesetzten Ziele erreicht hat. Einige Beispiele:

Ergebniskennzahlen

  • Anzahl akzeptierter Fehler.
  • Zeitrahmen für eine Prozessdurchführung.
  • Materialverbrauch (z.B. in Mengen oder in Euro)
  • Materialabfall (in Mengen)
  • Ausschussquote (Anzahl)
  • Verhältnis von Anzahl der Aufträge mit verspäteter Lieferung zu allen Aufträgen
  • Anzahl an Garantiefällen.
  • Verhältnis Liefermenge mit korrekten Lieferungen zu allen Lieferungen (Lieferzuverlässigkeit)?

Steuerungskennzahlen, die helfen sollen, den Geschäftsprozess zu steuern. Zum Beispiel der Umfang des Auftragseingangs.

Steuerungskennzahlen

Störungskennzahlenzur Messung von Störungen. Darunter versteht man Einflüsse, die man nicht (direkt) beeinflussen kann:

Störungskennzahlen

  • Zuverlässigkeit von Produktionsanlagen (Ausfallstunden, -tage)
  • Zuverlässigkeit der IT (Ausfallminuten, -stunden)
  • Ausfalltage auf Grund von Witterungsverhältnissen
  • Lieferengpässe durch Streiks

Lieferantenkennzahlen(interne und externe). Messung des Prozessinputs aus dem eigenen Unternehmen (von anderen Proezssen) oder von externen Lieferanten.

Lieferantenkennzahlen

Effektivitätskennzahlen, mit denen die Effektivität des Geschäftsprozesses gemessen wird. Zum Beispiel:

Effektivitätskennzahlen

  • Pünktlichkeit der Waenlieferung
  • Zufriedenheit des Kunden (in Bezug auf einen bestimmten Prozess)
  • Einhaltung von Reparaturzeiten
  • Lieferung der vereinbarten Menge

Effizienzkennzahlen zur Betrachtung der Kostenseite. Zum Beispiel:

Effizienzkennzahlen

  • Verhältnis von Nutzen und Aufwand
  • Kosten für pünktliche Lieferung
  • Investitionskosten für die Prozessoptimierung
  • Lohnkosten pro verkauften Artikel
  • Prüfkosten pro Produktionsmenge
  • Personalkosten pro Bestellung

7.3.3 Gestaltung von Kennzahlen

Kennzahlen müssen sehr gründlich geplant werden. Dies betrifft

Planung

  • 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 angemessener Nutzen gegenüber?")
  • sowie ihre Organisierbarkeit (z.B.: "Können Verantwortliche für Datenbereitstellung, Berechnung, Berichterstattung benannt werden?).

 

8 Reifegrade

8.1 Einführung

Da hat man seine Geschäftsprozesse optimiert, in ständigem Bemühen Schwachstellen ausgemerzt, dann kommt plötzlich die Forderung nach der Bestimmung des Reifegrades der Geschäftsprozesse und des Geschäftsprozessmanagements. Hintergrund 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 aufzuweisen.

Ständige Aufgabe

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 Strukturen 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) hervorragende Leistung erzielen.

Es geht damit also um die 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 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. Festgestellt wird der Reifegrad durch sog. Prozessassessments, die nur dann ihren Zweck erfüllen, wenn aus den Ergebnissen Verbesserungsmaßnahmen abgeleitet und umgesetzt werden [Schmelzer und Sesselmann 2013, S. 358].

Kriterien?

Was sind Reifegrade? Die in der Literatur genannten Ziele sind recht allgemein gehalten. So heben Schmelzer/Sesselmann auf die Breite und Tiefe des Geschäftsprozessmanagements ab. Wie breit wird Geschäftsprozessmanagement eingesetzt? Wie vollständig ist es umgesetzt? "Inwieweit erfüllen Geschäftsprozesse und Geschä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 Anforderungen für die einzelnen Grade formuliert werden. Dazu unten mehr.

Reifegrade

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 Übereinstimmung 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ändigkeiten ausgestattet sein.

Assessments können auch in Form von Selbstbewertungen durchgeführt werden. "Die Selbstbewertung ist eine umfassende und systematische Bewertung der Tätigkeiten 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].

Selbstassessments

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.

Ergebnisse

 

Risiken beherrschen?

Schmelzer/Sesselmann sehen sogar die Möglichkeit, durch Assessments die Risiken in Geschäftsprozessen besser zu beherrschen. U.a. führen sie als mögliche Ergebnisse von Assessments an:

  • Klärung von Erfolgsrisiken in Geschäftsprozessen und im Geschäftsprozessmanagement
  • 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 Situation rund um den betrachteten Geschäftsprozess oder das Geschäftsprozessmanagement mit einer idealisierten Situation vergleichen und dies sollte sollte gestuft erfolgen können. Genau dazu dienen die sog. Reifegradmodelle. Bewertet werden können die gesetzten Rahmenbedingungen für

„Reife“ messen

  • 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 Voraussetzungen für die Effektivität und Effizienz der Prozesse realisiert sind. Die Reifegradstufen bauen aufeinander auf. Bei jeder ist angegeben, durch welche Maßnahmen die nächst höhere erreicht werden kann.

Reifegradstufen


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. Bewertungsmethode ist SCAMPI. Vgl. die Beschreibung unten.
  • Software Process Improvement and Capability Determination (SPICE) zusammen mit ISO 15504 (SPICE/ISO 15504) für den Anwendungsbereich Softwareentwicklung. Beurteilt werden einzelne Prozesse. Bewertungsmethode SCAMPI. 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 Bewertungsmethode dienen Checklisten.
  • ISO-Reifegradmodell nach ISO 9004 für alle Anwendungsbereiche. Es ist allgemein einsetzbar. Beurteilt wird das Geschäftsprozessmanagement.
  • PEM-Modell (Process and Enterprise Maturity Model) für alle Anwendungsbereiche. Beurteilt werden die Organisation und einzelne Prozesse. Als Bewertungsmethode dienen Checklisten.

Vgl. [Schmelzer und Sesselmann 2013, S. 360ff] und die dort angegebene Literatur.

8.4 Capability Maturity Model 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 Erkenntnis ausgegangen wird, dass Fortschritte nur schrittweise möglich sind. Deshalb bietet CMMI einen schrittweisen Verbesserungsweg an. Falls die Situation es erfordert, von einem unreifen Ad Hoc - Prozess zu einem optimierten und leistungsstarken 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 Anwendungsbereiche:

Anwendungsbereiche

  • CMMI for Aquisition (CMMI-ACQ) für Beschaffungsvorgänge (Produkte und Leistungen)
  • CMMI for Development (CMMI-DEV) für die Software- und Systementwicklung
  • CMMI for Services (CMMI-SVC) für die Erbringung von Dienstleistungen

Betrachtet werden 22 Prozessgebiete, wovon 16 Kernprozessgebiete sind. Die Prozessgebiete umfassen in vier Untergruppen wichtige prozessrelevante Themen:

Prozessgebiete

  • Unterstützung (Konfigurationsmanagement, Sicherung Prozessqualität, Sicherung Produktqualität, ...)
  • Prozessmanagement (Aus- und Weiterbildung, Prozessentwicklung, Prozessausrichtung, Prozessleistung, ... - alles organisationsweit.
  • Projektmanagement (Anforderungsmanagement, Projektplanung, Zulieferungsmanagement, 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ängender 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 erreicht 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 „Institutionalisierung“ bringt eine organisatorische Verankerung zum Ausdruck.

Die Reifegrade bauen auf den Fähigkeitsgraden auf. Um einen Reifegrad zu erreichen, 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 aufweisen.

4

Quantitatively Managed

Alle Prozessgebiete, die den Reifegraden 2, 3 und 4 zugeordnet sind, müssen den Fähigkeitsgrad 3 aufweisen.

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 Personen 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" verwechselt 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 Geschäftsprozesse für die gesamte Organisation wurden eingeführt. Z.B. existiert ein standardisierter Beschaffungsprozess, von dem die unterschiedlichen Landesgesellschaften ihre spezifischen Beschaffungsprozesse ableiten können.

Reifegrad 4: Ouantitatively Managed

Die Leistungsfähigkeit der Prozesse wird quantitativ gemessen, analysiert und anhand 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 Einsatzes. Dies sei am Beispiel des Fähigkeitsgrads 2 erläutert. Für diesen wird u.a. verlangt [Schmelzer und Sesselmann 2013, S. 363f]:

Was wird tatsächlich gemessen?

  • 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

Dies wird also verlangt. Nicht erfasst wird (es wäre auch schwierig), in welcher Qualität dies realisiert wird. Das macht deutlich, dass die Leistungsfähigkeit auch eines Geschäftsprozesses mit hohem Reifegrad sehr stark vom Engagement und der Kompetenz derjenigen abhängt, die ihn realisieren.

Schwachstelle der Reifegradmodelle

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 Bewertung der Prozessreife von Auftragnehmern durchgeführt. "Die Begutachtung basiert auf dem Vergleich der Prozesse einer Organisation mit den Praktiken (Best Practices) von CMMI." [Schmelzer und Sesselmann 2013, S. 366f]

Bewertungsverfahren

8.5 SPICE/ISO 15504

"Das Reifegradmodell Software Process Improvement and Capability Determination wurde 1993 vom britischen Institute of Electrical amp; 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 unterscheidet neun Prozessattribute und sechs aufeinander aufbauende Fähigkeitsstufen.

Jeder Prozess wird anhand der Prozessattribute [1] Prozessoptimierung, [2] Prozessinnovation, [3] Prozesssteuerung, [4] Prozessmessung, [5] Prozessanwendung, [6] Prozessdefinition, [7] Management der Arbeitsprodukte, [8] Management der Prozessdurchführung und [9] Prozessdurchführung bewertet (Kriterium: "realisiert"). Diese führen dann zu den Fähigkeitsstufen:

(5) Optimizing

Prozessattribute [1] und [2]. Der Geschäftsprozess ist auf die Geschäftsziele abgestimmt. 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 Prozessverantwortlichkeiten sind definiert."

(1) Performed

Prozessattribut [9]. Der Prozess ist implementiert und wird durchgeführt, die Ergebnisse 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 2013, S. 357ff].

Mehr in [Schmelzer und Sesselmann 2013, 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 befö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 erreichte 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 Einrichtung der Voraussetzungen für den Prozesserfolg, wie sie das jeweilige Reifegradmodell fordert.

 

9 Risiken erkennen und beherrschen

Die Sichtweise der Betriebswirtschaftslehre ist umfassend dargestellt in [Schmelzer und Sesselmann 2013, Kapitel 8] und [Becker, Kugeler und Rosemann 2012, Kapitel 16].

9.1 Worum geht es?

Die Realisierung von Geschäftsprozessen ist eine komplizierte Angelegenheit, bei der zahlreiche Faktoren zusammenspielen müssen. Entsprechend groß sind die Risiken, das einer der Faktoren nicht wie geplant funktioniert. Das hat sich mit der Automatisierung von Geschäftsprozessen nicht grundsätzlich geändert, wird allerdings um IT-technische Aspekte erweitert.

Basis für Risikobetrachtungen ist, dass der Geschäftsprozess eingerichtet wurde und funktioniert. Er drückt also in einem gewissen (bis dahin erreichten Umfang) Effektivität ("der richtige Prozess") und Effizienz ("mit möglichst geringem Auwand") aus.

Basis

Zu trennen sind diese Überlegungen auch von den allgemeinen Geschäftsrisiken ("Mit welchen Produkten / Leistungen kann die Organisation erfolgreich sein, usw."). Diese sind auf der strategischen Ebene angesiedelt, während wir uns hier auf der operativen bewegen.

Schmelzer / Sesselmann definieren Risiko hier wie folgt:

Risiko

"Von Risiko wird gesprochen, wenn das Ergebnis einer Handlung ungewiss ist und die Zielsetzung nicht oder nicht vollständig erfüllt werden kann. Das Maß des Risikos ist der erwartete Verlust oder Schaden. Dieser wird aus der Multiplikation von möglichen Verlusten/Schäden mit den Wahrscheinlichkeiten ihres Eintretens ermittelt. Das Risiko ist umso größer, je hoher die Eintrittswahrscheinlichkeit und das Ausmaß des potenziellen Verlustes oder Schadens sind. In Geschäftsprozessen können Schäden finanzieller oder nicht finanzieller Natur sein. Besonderes Gewicht haben finanzielle Verluste, die durch ein Verfehlen der Prozessziele verursacht werden." [Schmelzer und Sesselmann 2013, S. 387], gestützt auf die International Group of Controlling.

Schmelzer / Sesselmann sehen folgende Gründe für das Entstehen von Risiken in Geschäftsprozessen:

"Unternehmensexterne Einflüsse

  • Veränderungen der Wettbewerber, des Absatzmarktes, des Beschaffungsmarktes, des Arbeitsmarktes, der Umwelt
  • technologischer Wandel, insbesondere der Informationstechnologie
  • mangelhafte Qualität externer Zulieferungen

Unternehmensinterne Einflüsse

  • mangelhafte Geschäfts- und Prozessstrategie
  • unzureichende finanzielle, personelle oder technische Prozessressourcen
  • mangelhafte Qualität interner Zulieferungen

Prozessinterne Einflüsse

  • niedrige Prozessreife
  • mangelhafte Ziel- und Durchführungsplanung
  • Zielabweichungen bei der Prozessausführung bezogen auf Kundenzufriedenheit, Prozesszeiten, -termine, -qualität, -kosten"

[Schmelzer und Sesselmann 2013, S. 388]

9.2 Risikomanagement in Geschäftsprozessen

Der Umgang mit den Risiken wird mit Risikomanagementbezeichnet. Schmelzer / Sesselmann definieren wie folgt:

"Risikomanagement umfasst alle Aufgaben zur Identifikation, Analyse, Bewertung, Steuerung, Überwachung und Reporting von Risiken." Vgl. [Schmelzer und Sesselmann 2013, S. 388] und die dort angegebenen Quellen.

Als zentrale Fragen des Risikomanagements sehen sie (ebenda):

  • Welche Risiken können auftreten?
  • Wie hoch sind die Risiken und mit welcher Wahrscheinlichkeit treten sie auf?
  • Wie können Risiken beeinflusst und gesteuert werden?

Ziel des Risikomanagements ist es dann nicht nur, Risiken zu vermeiden, sondern die Risiken auch in Bezug zu den evtl. dadurch gegebenen Chanden zu setzen, denn "Risikomanagement ist gleichzeitig auch Chancenmanagement." [Schmelzer und Sesselmann 2013, S. 388]

9.3 Risiken heute

Wie sehen die Risiken in Geschäftsprozessen heute aus? Auch hier erfolgt wieder eine Konzentration auf Geschäftsprozesse, nicht auf die Organisation als Ganzes, nicht auf die IT, usw.

Ausgangspunkt der Überlegungen sollen hier die Träger der Geschäftsprozesse sein, seien es Menschen, IT-Lösungen oder Programme.

Folgende Unterscheidung wird hier getroffen:

  • Umfassend menschgestützte Prozessabschnitte. Dazu gehören auch "chaotische" Abschnitte, also z.B. kreative bzw. wissensintensive (vgl. Abschnitt 3.4).
  • IT-gestützte Prozessabschnitte. D.h., Prozesse, die von Menschen realisiert werden, die aber IT-gestützt abgewickelt werden. Vgl. Kapitel 19.
  • Automatisierte Prozessabschnitte. Diese werden vollständig durch Software und evtl. Hardware realisiert. Vgl. Kapitel 20.

Risiken für menschgestützte Prozesse / Prozessabschnitte:

  • Menschliches Versagen durch mangelndes Können oder Wollen.
  • <<mehr in Kürze>>

Risiken für IT-gestütze Prozesse / Prozessabschnitte:

  • Softwarefehler
  • Ungeeignete Software
  • Mangelnde Flexibiliät der Software
  • Fehlerhafte Umsetzung des GPs
  • Fehlentscheidung durch die beteiligten Menschen
  • <<mehr in Kürze>>

Risiken bei automatisierten Geschäftsprozessen:

  • Automatisierung erweist sich nach einiger Zeit als fehlerhaft. Z.B. weil Geschäftsvorfälle auftreten, die bei der Softwareentwicklung nicht vorgedacht waren.
  • Die automatisierte Komponente ist ganz grundsätzlich überschätzt worden.
  • <<mehr inKürze>>

Fragen:

[F9.1] Klären Sie mit Hilfe von [Schmelzer und Sesselmann 2013, Kapitel 8] wie das Risikomanagement nach ISO 31000:2009 gehandhabt wird.

[F9.2] Welche Merkmale charakterisieren das Risikomanagementsystem in Geschäftsprozessen nach [Schmelzer und Sesselmann 2013, Kapitel 8].

[F9.3] In welche Aufgabenblöcke werden - in Anlehnung an ISO 31000:2009 die Aufgaben des Risikomanagements in Geschäftsprozessen unterteilt? Beachten Sie Abb. 8.1 in [Schmelzer und Sesselmann 2013, S. 390]

[F9.4] Schmelzer und Sesselmann stellen Methoden zur Risikobeurteilung und -überwachung vor, u.a. ein "Prozessportfolio in Form des Attraktivitäts-Risiko-Portfolios". Beschreiben Sie dieses.

<<mehr dazu in Kürze>>

 

10 Qualitätsmanagement und Performancesteigerung

In diesem Kapitel arbeiten wir im Wesentlichen mit den unten zitierten Büchern von Gaitanides, Schmelzer/Sesselmann und Gadatsch.

10.1 Qualitätsmanagement

Mit Gaitanides kann Qualität in Geschäftsprozessen gleichgesetzt werden "mit der Erfüllung von (objektivierten) Anforderungen zur dauerhaften Kundenzufriedenheit" [Gaitanides 2012, S. 208]. Er weist darauf hin, dass eine hohe Qualität des Prozessoutputs "nur durch die Fehleranalyse und -beseitigung über die gesamte Prozesskette hinweg stabilisiert werden kann" [ebenda].

Die Bemühungen zur Verbesserung der Qualität von Geschäftsprozessen werden unter dem Begriff Qualitätsmanagement zusammengefasst. Dabei geht es in der Regel um Maßnahmen organisatorischer Art.

Definition

Die bekanntesten Qualitätsmanagementmodelle sind der

  • TQM-Ansatz, die
  • ISO 9001 und der sog.
  • kontinuierliche Verbesserungsprozess (KVP)

Messung der Prozessqualität

Bei der Messung der Prozessqualität spielt Benchmarking eine wichtige Rolle [Gaitanides 2012, S. 210]. Er erwähnt das Beispiel IBM, wo (zum Zeitpunkt der Entstehung dieses Textes) jedem identifizierten Geschäftsprozess ein Ratingwert zugewiesen wurde, "der die Güte des Prozesses in 4 Rangstufen messen soll":

  • Stufe 4: Dafür genügt es, wenn der Prozess dokumentiert und im Unternehmen eingeführt ist.
  • Stufe 3: Diese Stufe erhält ein Prozess, wenn die „Qualität" bereits verbessert wurde.
  • Stufe 2: Für diese Stufe musste der Prozess einem Benchmarking unterzogen und weiter verbessert worden sein.
  • Stufe 1: Diese höchste Stufe erhält der Prozess, wenn die "Werte der
    Vergleichsentitäten übertroffen" wurden [ebenda]

Benchmarking

Gaitanides versteht unter Benchmarking den "Vergleich von Produkten und Prozessen mit internen oder externen Vergleichsobjekten (z. B. Abteilungen, Unternehmensbereiche oder Wettbewerber)". Für den Vergleich werden "Kategorien wie Kundenzufriedenheit, Prozesszeiten, Termintreue, Prozessqualität, Prozesskosten und Ressourceneinsatz als Objekte des Vergleichs vorgeschlagen." [Gaitanides 2012, S. 236]

Im Vordergrund des Benchmarkings steht also die Messung der Prozessqualität. Sie verfolgt üblicherweise die folgenden Ziele (vgl. hierzu [Gaitanides et al. 1994, S. 74]):

  • Reduzierung der Fehlerkorrekturkosten sowie der damit verbundenen Arbeitszeit
  • Behebung prozessualer Schwachstellen
  • Kundenzufriedenheit.

Zum Schwerpunkt der Qualitätsmessung führt Gaitanides aus:

"Schwerpunkt der Qualitätsmessung ist die Erfassung der Outputqualität, da die Inputqualität gleichzeitig die Outputqualität des vorgelagerten internen oder externen Lieferantenprozesses darstellt. Sie wird in der Regel durch Leistungsnachweise vom verantwortlichen Prozesseigner bzw. vom Lieferanten verifiziert." [Gaitanides 2012, S. 210]

Hier spielen die sog. Nahtstellen in den Geschäftsprozessen eine wichtige Rolle:

"Qualitätswerte können ausschließlich an den Prozessnahtstellen und nicht wie bei der Zeitmessung aus der Differenz zwischen Eingangs- und Ausgangsschnittstelle eines Geschäftsprozesses ermittelt werden."

Prozessnahtstellen

Zum Vorgehen führt Gaitanides aus:

"Im Vordergrund stehen prozessuale Aspekte, d.h. wie und in welcher Form Leistungsvereinbarungen mit internen Servicenehmern und Servicegebern bzw. externen Kunden und Lieferanten eingehalten werden. Wichtig ist die Definition einer Outputnorm, die neben der Fehlerdefinition das zu erreichende Qualitätsniveau eindeutig festlegt. Diese Outputnorm kann zusätzlich zu der mit den externen Kunden vereinbarten Leistung weitere Qualitätsaspekte beinhalten, z. B. die Anzahl tolerierter, fehlerhafter Rechnungen in der Auftragsabwicklung. Dieser Prozessleistungsparameter ist Bestandteil der Outputnorm, wird aber nicht Gegenstand einer Leistungsvereinbarung mit einem externen Kunden sein. Für Prozesse mit externem Kundenkontakt sind aus der Output-Norm drei Arten von Qualitätsindikatoren abzuleiten:

[Gaitanides 2012, S. 211]

  • Qualitätsanforderungen, die Bestandteil der Leistungsvereinbarung mit externen Kunden sind:
  • Qualitätsaspekte, die nicht in der Leistungsvereinbarung mit externen Kunden enthalten sind, deren Ergebnis aber einen maßgeblichen Einfluss auf die Kundenzufriedenheit haben, z. B. Rechnungsrichtigkeit,
  • Qualitätsergebnisse, die primär interne Kunden bzw. Servicenehmer tangieren.

Die Einteilung der Qualitätsindikatoren in diese drei Kategorien wird also jeweils von der Kundennähe des betreffenden Prozesses oder Subprozesses beeinflusst. Wichtig ist die Unterscheidung insbesondere dann, wenn die intern ermittelten Qualitätswerte mit den externen, d. h. aus Kundenumfragen gewonnenen Ergebnissen, überprüft werden sollen." [Gaitanides 2012, S. 211]

Methoden zur Messung der Prozessqualität

  • Six Sigma

Quellen: [Schmelzer und Sesselmann 2013, S. 432ff], [Gaitanides 2012, S. 211], [Gadatsch 2013, P. 1361]

Frage:

Beschreiben Sie die Methode Six Sigma, auch mit einem Beispiel

  • Total Quality Management (TQM)

TQM ist ein weitreichender Ansatz zur Qualitätssicherung. „T" steht für Total, gemeint ist das Einbeziehen aller Mitarbeiter und Mitarbeiterinnen sowie auch der Kunden und Lieferanten. „Q" steht für Quality, die Qualität der Arbeit, der Prozesse und des Unternehmens, aus denen heraus sich die Qualität der Produkte wie selbstverständlich ergeben soll. „M" steht für Management.

Gaitanides definiert wie folgt:

"Total Quality Management (TQM) bezeichnet einen ganzheitlichen Qualitätsansatz, dem eine Denk- und Handlungsweise zu Grunde liegt, die auf permanente Qualitätsverbesserung ausgerichtet ist. Ein hohes Qualitätsniveau kann nur durch eine entsprechende Koordination des gesamten Leistungsprozesses auf Basis von Kunden-Lieferanten-Beziehungen sowie einer funktionsübergreifenden Optimierung erreicht werden. Zum anderen müssen die Mitarbeiter durch Selbstkontrolle, Gruppenarbeit und entsprechende Leistungsanreize dazu motiviert werden, eine qualitativ hochwertige Prozessarbeit zu leisten. Das Qualitätsbewusstsein soll alle Geschäftsprozesse und Aktivitäten eines Unternehmens erfassen und zu einem kontinuierlichen Verbesserungsprozess (KVP) führen." [Gaitanides 2012, S. 210]

TQM eignet sich dabei sowohl für kleine und mittlere als auch für global agierende Konzerne.

Die Prinzipien des TQM lauten:

1. Neue Sichtweise verinnerlichen

2. Engagement der Geschäftsführung

3. Führungskräfteentwicklung

4. Mitarbeiterorientierung

5. Kundenorientierung

6. Lieferantenintegration

7. Strategische Ausrichtung auf Basis von Grundwerten und festem Unternehmenszweck

8. Ziele setzen und verfolgen

9. Präventive Maßnahmen der Qualitätssicherung

10. Ständige Verbesserung auf allen Ebenen - Kaizenanwenden, Prozessorientierung

11. Schlankes Management

12. Benchmarking

13. Qualitätscontrolling

  • Kaizen

[Gaitanides 2012, S. 210]: "Unter dem Begriff des Kaizenwird die systematische Ausschöpfung von Verbesserungspotentialen zu einem Bestandteil der Unternehmenskultur erhoben." In Deutschland wird Kaizen zumeist als KVP (Kontinuierlicher Verbesserungsprozess) bezeichnet.

  • ISO 9001

<<inKürze mehr>>

10.2 Performancesteigerung

Schmelzer und Sesselmann definieren Performancesteigerung wie folgt:

"Geschäftsprozessmanagement verfolgt das Ziel, die Performance (Effektivität + Effizienz) der Geschäftsprozesse nachhaltig zu steigern und damit das Erreichen der strategischen und operativen Unternehmensziele zu unterstützen. Es gibt zwei unterschiedliche Ansätze zur Performancesteigerung in Geschäftsprozessen: Prozesserneuerung (Revolution) und Prozessverbesserung (Evolution)." [Schmelzer und Sesselmann 2013, S. 407]

Ziel von GPM

Dies sind die klassischen Vorschläge. Seit der zunehmenden IT-Unterstützung und Automatisierung muss dies ergänzt/verändert werden. Vgl. dazu die Kapitel 20-22.

10.2.1 Prozesserneuerung / BPR

Prozesserneuerung hat als Methode klassisch das Business Process Reengineering (BPR). Dabei werden bestehende Geschäftsprozesse grundlegend verändert bzw. durch neue ersetzt. Aktuell sind hier v.a. die Bemühungen zu nennen, Geschäftsprozesse zu automatisieren. Vgl. Kapitel 19 und 20.

Vgl. Abbildung 9.1 in [Schmelzer und Sesselmann 2013, S. 407ff].

Schmelzer und Sesselmann beschreiben in Abschnitt 9.2 das klassische BPR. Hier einige Zitatstellen.

Zu den Ursachen:

"Starke und abrupte Veränderungen des unternehmerischen Umfeldes (z.B. Märkte, Wettbewerber, Partner, Kundenanforderungen, Technologien), tief greifende Änderungen der Unternehmensstrategie (z. B. Geschäftsmodell, Geschäftsfelder, Kernkompetenzen) oder gravierende Änderungen der Unternehmensstruktur (z.B. durch Zusammenschlüsse, Akquisitionen, Kooperationen) wie auch ein "Reorganisationsstau" können dazu führen, dass bisherige Geschäftsprozesse nicht mehr strategiekonform ausgerichtet und wettbewerbsfähig sind. In solchen Fällen kann es notwendig sein, Geschäftsprozesse grundlegend zu erneuern. Als Methode bietet sich dafür das Business Process Reengineering (BPR) an." [Schmelzer und Sesselmann 2013, S. 410f]

Zur Vorgehensweise:

"Business Reengineering bedeutet, altbekannte Vorgehensweisen aufzugeben und die Arbeit, die in den Produkten oder Dienstleistungen steckt, aus einem neuen Blickwinkel zu betrachten sowie dem Kunden einen neuen Wert zu bieten (nach [Hammer und Champy 1995, S. 47]).

Wichtige Merkmale von BPR sind:

- Kunden- und Prozessfokussierung,

- fundamentales Überdenken aller Aufgaben und Abläufe,

- radikales Redesign aller Strukturen und Verfahrensweisen,

- Empowerment der Mitarbeiter,

- Nutzung der Möglichkeiten der Informationstechnologie,

- Quantensprünge der Prozessperformance (Kundenzufriedenheit, Prozesszeit, -qualität, -kosten)."

[Schmelzer und Sesselmann 2013, S. 411]

Zum Aufwand:

"BPR verlangt große Anstrengungen, bindet erhebliche Personalressourcen, erfordert intensive Koordination und unterliegt einem hohen Erfolgsrisiko. Deshalb ist BPR auf Geschäftsprozesse zu beschränken, die hohe strategische Bedeutung besitzen und gleichzeitig strategische Risiken und gravierende Performancedefizite aufweisen. Treffen diese Voraussetzungen nicht zu, sollte den Methoden der kontinuierlichen Prozessverbesserung der Vorzug gegeben werden." [Schmelzer und Sesselmann 2013, S. 411]

Zur Rolle der Kernprozesse:

"Hohe strategische Bedeutung haben Kernprozesse, da sie maßgeblich den Aufbau und Ausbau von Kernkompetenzen beeinflussen. Strategische Risiken liegen vor, wenn notwendige Kernkompetenzen nicht ausreichend vorhanden oder gesichert sind. Gravierende Performancedefizite sind gegeben, wenn in einem Kernprozess die Diskrepanz zwischen Performanceziel und vorhandenem Performanceniveau so groß ist, dass sie durch kontinuierliche Prozessverbesserungen nicht beseitigt werden kann." [Schmelzer und Sesselmann 2013, S. 411]

Zur Einschätzung:

"BPR war in den 1990er-Jahren ein viel beachtetes Thema. Die hochgesteckten Erwartungen hat damals ein Großteil der BPR-Projekte nicht erfüllt." [Schmelzer und Sesselmann 2013, S. 412]

Soweit einige Ausführungen zu diesem Thema von Schmelzer/Sesselmann.

Gaitanides befasst sich auch mit den Phasen von Reengineering-Projekten. Er unterscheidet:

  • Prozessidentifikation
  • Prozessanalyse
  • Prozessdesign
  • Prozessimplementierung

[Gaitanides 2012, Kapitel 3]

Fragen:

[F10.3] Erarbeiten Sie sich, wie Gaitanides in [Gaitanides 2012, Kapitel 3] das "Prozesskonzept des Business Process Reengineering" sieht.

[F10.4] Welche Merkmale, Vor- und Nachteile charakterisieren das Business Pro- cess Reengineering?

10.2.2 Prozessverbesserung

Schmelzer/Sesselmann definieren Prozessverbesserungen wie folgt:

"Prozessverbesserungen beinhalten schrittweise Performancesteigerungen, um Zielabweichungen zu korrigieren und Performancedefizite auszugleichen. Die Geschäftsprozesse bleiben dabei in ihrer Grundstruktur erhalten. Prozessverbesserungen werden in Geschäftsprozessen kontinuierlich durchgeführt, beziehen viele Mitarbeiter ein und zeichnen sich durch geringes Umsetzungsrisiko aus. Sie stärken das organisationale Lernen und tragen zu einer permanenten Verbesserung der Problemlösungskompetenz der Organisation bei." [Schmelzer und Sesselmann 2013, S. 409]

Die in der Praxis angewandten Methoden der Prozessverbesserung sind:

  • Total Cycle Time (TCT)
  • Kaizen und
  • Six Sigma.

Frage:

Vergleichen Sie anhand von [Schmelzer und Sesselmann 2013, S. 408] die beiden Methoden Prozesserneuerung und Prozessverbesserung.

11 Vorgehensmodelle für das GPM

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

11.1 Nach Becker

Becker stellt ein Vorgehensmodell vor, das sieben Phasen beinhaltet (vgl. [Becker und Kahn 2004, S. 15 f] und [Becker 2013]).


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

Vorbereitung

In der Strategie- und Ordnungsrahmenentwicklung werden die Prozesse und Prozessziele strukturiert. Ziel ist, die wesentlichen Elemente und ihre Beziehung schematisch darzustellen, um die Transparenz im weiteren Projektverlauf sicherzustellen (für eine ausführliche Darstellung vgl. [Becker und Meise 2012]).

Strategie und Ordnungsrahmen

Die Istmodellierung und -analyse dient der Identifizierung von Verbesserungspotenzialen; sie ist also Grundlage für die Sollmodellierung, da Schwachstellen identifiziert werden. Daneben dient die Istmodellierung zu Protokollierungs-, Präsentations- oder Schulungszwecken.

Ist und Soll

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 Unternehmens und andererseits die Basis für internes Benchmarking oder Workflow-Management.

Die prozessorientierte Aufbauorganisationsgestaltung geht von den Soll-Prozessen aus. Kriterien für die Festlegung der Aufbauorganisation sind Zeit, Kosten und Qualität.

Prozessorientierte Aufbauorganisation

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.

Im Anschluss an die Implementierung einer prozessorientierten Organisationsstruktur ist es notwendig, ein kontinuierliches Prozessmanagement zu etablieren, um sich einem veränderten Umfeld anzupassen.

11.2 Nach Schmelzer/Sesselmann

Schmelzer und Sesselmann schlagen im Rahmen ihres Vorgehensmodells vier Phasen vor (vgl. [Schmelzer und Sesselmann 2008, S. 414]).


Abbildung 11.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 Entwicklung der Vision, die Klärung der Ausgangssituation und die Identifikation des Handlungsbedarfs für Prozessmanagement.

Strategie

Die Identifizierung der Geschäftsprozesse klärt, welche Geschäftsprozesse zur Erfül- lung der Geschäftsstrategie und der Kundenanforderungen notwendig sind.

Identifizierung

Die Implementierung der Geschäftsprozesse legt Prozessstrukturen, Prozessverant- wortliche und ein Prozessgremium fest. Daneben wird die Aufbauorganisation an die Geschäftsprozesse angepasst. Das Prozesscontrolling definiert Leistungsparameter mit Ziel- und Messgrößen und führt das Berichtssystem ein.

Implementierung

Die letzte Phase beinhaltet den operativen Ablauf und die Steuerung der Geschäftsprozesse. Hierfür werden die Prozessziele (Kundenzufriedenheit, Prozesszeit, Termintreue, Prozesskosten, Prozessqualität) laufend überwacht. Die Optimierung der Geschäftsprozesse erfolgt entweder in Form einer Prozessverbesserung oder in Form einer Prozesserneuerung. Die Prozessverbesserung beinhaltet die Erhöhung der Leistungsfähigkeit der Prozesse. Die Prozesserneuerung beinhaltet hingegen die völlige Neugestaltung der Prozesse.

Verbesserung oder Erneuerung

11.3 Nach Österle

Ein Vorgehensmodell, das radikale Innovation im Prozessbereich beschreibt, ist das Vorgehensmodell von Österle.


Abbildung 11.3-1: Vorgehensmodell von Österle [Österle 1995]

Die Prozessvision hat radikale Innovationen zum Ziel und nimmt einen Abgleich zwi- schen Strategie und Prozess vor. Sie ist langfristig orientiert, berücksichtigt IT-Potenziale und bietet eine Gesamtsicht auf den Prozess. Hauptergebnis der Prozessvision sind die Prozessgrundsätze (vgl. [Österle 1995, S.63 und 77]).

Vision

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 Kontextdiagramm (Leistungsaustausch zwischen Prozessen), das Leistungsverzeichnis (grobe Beschreibung der Leistungen) und das Qualitätsprofil (Beurteilung der Leistungen) [ebenda, S. 78-85].

Leistungsanalyse

Die Ablaufplanung legt die Aufgaben des Prozesses, deren Reihenfolge und die ausführenden Einheiten fest. Als Ergebnis liegen das Aufgabenkettendiagramm, das Aufgabenverzeichnis und stellenbezogene Dokumente vor [S. 98].

Ablauf

Die Workflowplanung detailliert das Aufgabenkettendiagramm und enthält zusätzlich: Ereignisse, Applikationen, Transaktionen, Datenflüsse und Bedingungen. Zur Unterstützung wird hierbei ein Workflow-Managementsystem eingesetzt [S. 104f].

Workflow

Die Prozessführung dient der Planung, Gestaltung und Beobachtung des Prozesses; 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].

Prozessführung

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

Architekturplanung

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

IT-Assessment

Die Kundenbeziehungsanalyse erhebt die Aufgaben des Kunden in Zusammenhang 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 Architekturplanung und die Ablaufplanung liefert [S. 160].

Kundenbeziehungen

Aufgabenbezogene Analysen betrachten Durchlaufzeiten, Kosten und die Fehlerhäufigkeit von Prozessen; dabei werden die einzelnen Merkmale von Prozessen untersucht, um Verbesserungspotenziale abzuleiten [S. 161-164].

Benchmarking kann unternehmensintern, branchenintern oder branchenübergreifend durchgeführt werden. Als Ergebnis des Benchmarkings 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].

Benchmarking

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 Weiterentwicklung des Prozesses bereitgestellt werden [ebenda, S. 170 und 179].

organisatorische Monitoring

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äftsprozessmanagement einzuführen. Die beiden erstgenannten gehen bezüglich der Geschäftsprozesse von einer schrittweisen Optimierung aus, während Österle im Rahmen der Formulierung einer Prozessvision eine radikale Innovation vorschlägt

 

12 Prozessmodelle, Prozessmodellierung

12.1 Gründe, Ziele, Realisierung

Gründe für Modellbildung

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

Komplexität

Softwareerstellung

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

Abstraktion

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

Automaten

Ziele der Prozessmodellierung

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

Dokumentation und Istanalyse

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

Schwachstellen beseitigen durch Optimierung

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

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

Kundenorientierung

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

Requirements Engineering

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

Einsatzzwecke Becker

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

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

Zwecke Gaitanides

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

12.2 Grundsätze ordnungsgemäßer Modellierung

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

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

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

12.2.1 Fachliche und technische Prozessmodelle

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

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

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

BW-Referenzmodelle

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

SW-Referenzmodelle

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

Unternehmens­prozessmodelle

12.3 Basiselemente einer jeden Prozessmodellierung

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

Ebenen

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

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

Gewählte Ebene

Standardprozessmodellierung

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

Basiselemente

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

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

Heute und morgen

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

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

(1) Zentraler Gegenstand und Aufgabe des Geschäftsprozesses

Gegenstand und Aufgabe

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

"Neu" im Zeitalter der Digitalisierung:

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

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

(2) Elementare Tätigkeiten

Tätigkeiten

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

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

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

Anstoßen – ausführen – beenden

"Neu" im Zeitalter der Digitalisierung:

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

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

(3) Informationen auf Trägern aller Art

Informationen 1

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

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

Flüsse

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

"Neu" im Zeitalter der Digitalisierung:

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

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

(4) Informationsverarbeitung

Informationen 2

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

„Neu“ im Zeitalter der Digitalisierung:

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

(5) Informationstransport

Informationen 3

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

„Neu“ im Zeitalter der Digitalisierung:

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

(6) Träger der Tätigkeiten

Träger

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

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

Heute sind dies neben den beteiligten Menschen Programme unterschiedlichster Art:

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

„Neu“ im Zeitalter der Digitalisierung:

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

(7) Ereignisse

Ereignissteuerung

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

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

Ereignisumwelt des Unternehmens

„Neu“ im Zeitalter der Digitalisierung:

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

(8) Kontrollfluss

Tätigkeitsfolge

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

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

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

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

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

(9) Andere Flüsse

Viele Flüsse

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

„Neu“ im Zeitalter der Digitalisierung:

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

(10) Ebenen, Kapselung

Rauf und runter

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

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

(11) Verweise, Verknüpfungen

Hin und her

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

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

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

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

„Neu“ im Zeitalter der Digitalisierung:

  • Eindeutige Klärung der Schnittstellen auf programmnaher Ebene

(12) Zeitliche Dimension

Zeitachse

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

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

modelliert werden können.

„Neu“ im Zeitalter der Digitalisierung:

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

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

12.4 Methoden für Abläufe

Modellierungskonzepte

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

„Flusskonzepte“

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

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

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

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

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

Prozesslandkarten

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

Prozesse im Zusammenspiel

Darstellung der Prozessmodelle

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

Graphen und Netzwerke

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

Petri-Netze

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

Vgl. www.staud.info

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

Mit und ohne Schwimmbahnen (swim lanes)

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

Becken und Bahnen, pools und lanes

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

Insgesamt gilt in der Praxis heute:

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

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

Tabellarische Prozesserhebung

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

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

Modell vs. Instanz

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

Allgemein und spezifisch

12.5 Ergänzende Modellierung

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

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

DMN für Entscheidungs­prozesse

<<mehr dazu in Kürze>>

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

ArchiMate zur Modellierung der IT-Architektur

<<mehr dazu in Kürze>>

12.6 Grenzen der Prozessmodellierung

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

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

Grenzen, Einschränkungen, Defizite

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

Methodengrenzen

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

UML

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

Verarbeitung von Daten

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

Analysegrenzen

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

Rahmenbedingungen

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

Grafikdefizite

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

12.7 Software für die Prozessmodellierung

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

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

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

 

13 Methode EPK

Die Ausführungen in diesem Kapitel sind Auszüge aus dem Buch

Staud, Josef L.: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014,

Buch zu EPKs

einer umfassenden Einführung in die Ereignisgesteuerten Prozessketten (vgl. für nähere Informationen www.staud.info).

13.1 Einführung

Ereignisgesteuerte Prozessketten (EPKs) beschreiben Geschäftsprozesse, ihre Tätigkeiten (Funktionen genannt), die sie steuernden Ereignisse, die Handelnden (Organisationseinheiten genannt) und die benutzten oder erzeugten Informationen (Informationsobjekte 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äftsprozesses an.

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 optimierter Prozesse (Sollmodellierung). Nur wenn die Modellierung auf eine Ebene mit höherem Detaillierungsgrad zielt, z.B. zu Vorbereitung der Programmierung einer prozessorientierten Software, sind andere Modellierungsmethoden besser geeignet (vgl. die Abschnitte 12.2 und 12.5 in [Staud 2014]).

Istanalysen und Sollmodellierung

Diese Methode und die zugehörige grafische Beschreibungstechnik (Notation) für Geschäftsprozesse wurde von Scheer und seinen Mitarbeitern im Rahmen ihres ARIS-Konzepts entwickelt (vgl. [Keller, Nüttgens und Scheer 1992], [Scheer 1997]).

Ereignisgesteuerte Prozessketten sind (wie alle Methoden zur Prozessmodellierung) eine semi-formale Methode. Sie genügen nicht den Ansprüchen (wie auch im weiteren zu sehen sein wird), die an formale Methoden [Anmerkung] bzw. Sprachen gestellt werden müssen. So auch Rosemann in seinem Beitrag in [Mertens u.a. 1997, S. 334], wo er

Semi-formal

  • 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äufigkeit [Anmerkung] , von bedingten Verzweigungen und von Schleifen, die Wiedergabe des Datenflusses sowie die Angabe der involvierten Organisationseinheiten und Informationssysteme erfüllen Ereignisgesteuerte Prozessketten ohne weiteres.

Trotz des nicht voll formalen Charakters dieser Notation soll hier auch von Syntaxgesprochen werden, wenn die Regeln für den korrekten Aufbau der Ereignisgesteuerten Prozessketten gemeint sind.

ERP-Software

Modellelemente von Scheer

Eine immer noch tragfähige Auflistung notwendiger Modellelemente legte Scheer schon vor vielen Jahren vor. Er unterscheidet [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 betriebswirtschaftlich relevante Ereignisse definiert)
  • Zustände (die sich jeweils nach Abschluss einer Tätigkeit, vor allem in den Daten, neu ergeben).

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 Auftragseingang, nach Fertigstellung einer Kalkulation, usw.

  • Bearbeiter (und Bearbeiterinnen)
  • Organisationseinheiten sowie
  • Ressourcen der Informationstechnologie

Er fasst diese dann, nochmals abstrahierend, zu folgenden Elementen seiner formalen Beschreibungssprache Ereignisgesteuerte Prozessketten zusammen:

  • Ereignisse
  • Funktionen
  • Organisationseinheiten
  • Informationsobjekte

13.2 Elemente

13.2.1 Funktionen

Alle Tätigkeiten, die in einem Geschäftsprozess zu leisten sind, werden im Rahmen der Prozessmodellierung mit Ereignisgesteuerten Prozessketten als Funktionen erfasst. Die Gesamtaufgabe des Geschäftsprozesses (z.B. Kalkulation erstellen) wird also, mehr oder weniger detailliert, in einzelne Teilaufgaben unterteilt, die dann die Funktionen darstellen. Die Festlegung, welchen Umfang an elementaren Tätigkeiten die einzelne ausgewiesene Funktion hat, bleibt dem Modellierer überlassen. Der in [Staud 2014, S. 6f] diesbezüglich diskutierte subjektive Faktor der Modellierung bleibt also erhalten.

Subjektiver Faktor

Funktionen beschreiben bei Menschen deren operative Tätigkeit, bei einem IT-System ein Programm, z.B. eine Transaktion oder einen betriebswirtschaftlichen Funktionsbaustein.

Die grafische Darstellung von Funktionen geschieht durch ein Rechteck mit abgerundeten Ecken und einer Beschriftung in der Mitte des Rechtecks. Vgl. die folgende Abbildung.


Abbildung 13.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:

Benennung von Funktionen

  • Machbarkeit prüfen oder Machbarkeitsprüfung
  • Kalkulation erstellen
  • Auftrag ablehnen

13.2.2 Ereignisse

Unter Ereignissen werden hier betriebswirtschaftlich relevante Ereignisse verstanden. Diese beeinflussen und steuern auf die eine oder andere Weise die Abläufe im Unternehmen. Einige Beispiele dafür sind:

Steuerung durch Ereignisse

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

Benennung

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.

Definition

Etwas enger gefasst wird diese Definition dadurch, dass in der Prozessmodellierung eine enge Beziehung zwischen Funktionen und Ereignissen gesehen wird. Die Durchführung einer Funktion führt zum Beispiel immer zu einem Ereignis („erledigt“) oder zu mehreren.

Funktion – Ereignis – usw.

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 Ereignissen eingebettet wird. Mit anderen Worten: Ereignisse lösen Funktionen aus und sind deren Ergebnis. Dies ist der Grund, weshalb Scheer schreibt:

Auf Zeitpunkte bezogen

„Ein Ereignis kann als Auftreten eines Objekts oder Änderung einer bestimmten Attributsausprägung definiert werden.“ [Scheer 1998a, 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 oder – quasi aus heiterem Himmel – von außen kommen („IT wurde gehackt“, „Auftrag ist eingegangen“).

Die Menge aller in einem Unternehmen und seinem Umfeld möglichen prozessrelevanten Ereignisse sollen als der Ereignisraum des Unternehmens bezeichnet werden.

Ereignisraum

Ein Ereignis ist immer auch eine Feststellung, die irgendwie und von irgendjemandem 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 Abschluss. Grundsätzlich können auch mehrere Start- und mehrere Endereignisse vorliegen.

Anfang und Ende

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 13.2-2: Grafische Darstellung von Ereignissen

13.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 klassische Lösung) oder die Anwendungssoftware, die automatisiert die Funktion realisiert. 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 Analyse der Schwachstellen zu erhalten. Beispiele für (klassische) Organisationseinheiten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informationsvermittlungsstelle.

Träger des Prozessgeschehens

Die grafische Darstellung von Organisationseinheiten in Ereignisgesteuerten Prozessketten erfolgte durch eine in der Mitte beschriftete Ellipse. Organisationseinheiten sind immer durch eine richtungslose Verbindungslinie mit der Funktion verbunden, die realisiert wird.


Abbildung 13.2-3: Grafische Darstellung von Organisationseinheiten und ihre Anbindung an Funktionen

Es hat sich eingebürgert, in der Grafikgestaltung im Prozessfluss die Organisationseinheiten bei nachfolgenden 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.

Grafische Festlegung

13.2.4 Informationsobjekte

Keine Organisation kommt ohne Datenbestände und andere Informationen aus, die die Organisation selbst, ihre Geschäftsobjekte und ihre informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Informationen sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung.

Datenbestände und Informationen

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 irgendeinen 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 13.2-4: Grafische Darstellung von Informationsobjekten und ihre Anbindung an Funktionen

Wie im Folgenden zu sehen ist, werden damit Datenflüsse (im Sinne der Datenflussdiagramme) nur erfasst, wenn dieser Teil der Modellierung sehr sorgfältig geschieht, was in der Praxis oft nicht der Fall ist.

Informationsobjekte können nicht nur aus Daten von Datenbanken bestehen. Grundsätzlich kann jede Information auf jedem Informationsträger berücksichtigt werden. Der Hinweis auf nicht elektronische Träger (bei einer Istanalyse) kann sogar ein erster Hinweis auf Möglichkeiten zur Optimierung des Geschäftsprozesses sein.

Informationsträger aller Art

Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisierungsgrad des betrachteten Geschäftsprozesses. Vgl. zur Automatisierung die Kapitel 18 und 19. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte oftmals (aber nicht immer!) nicht digital sein.

Informationsobjekte und Automatisierungsgrad

Kontrollfluss: Die unsichtbare, ordnende Hand

Der oben schon eingeführte Begriff Kontrollfluss kann jetzt für Ereignisgesteuerte Prozessketten präzisiert werden. Die in einem Geschäftsprozess möglichen Abfolgen von Ereignissen und Funktionen, beginnend mit Startereignissen und endend mit Schlussereignissen, werden Kontrollfluss genannt.

Abfolgen strukturieren

Ausgehend von dem Begriff Instanz (vgl. Abschnitt 13.3.5) könnte man den Kontrollfluss auch als die Gesamtheit aller möglichen Instanzen des Geschäftsprozesses bezeichnen.

Beim Begriff Kontrollfluss ist also an alle möglichen Durchgänge durch den Geschä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 geschrieben 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 stellen 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) gesprochen werden kann.

Richtung

13.2.5 Operatoren und Kontrollfluss

Der Kontrollfluss eines Geschäftsprozesses besteht nicht nur aus einfachen sequentiellen Abfolgen von Ereignissen und Funktionen, sondern auch aus Verzweigungen und Zusammenführungen von Kontrollflusszweigen . Zum Beispiel, wenn mehrere Tätigkeiten „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. Genauso 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 Ereignisgesteuerten Prozessketten werden Operatoren (manchmal auch Konnektoren genannt) benötigt.

Verzweigungen und Zusammenführungen

Für die Modellierung von Geschäftsprozessen durch EPKs genügen drei solche Operatoren. Hier die Bezeichnungen mit den grafischen Symbolen:


Abbildung 13.2-5: Logische Operatoren und ihre grafische Darstellung

Es gibt für jeden Operator jeweils zwei Seiten, ankommende Kontrollflusszweige und wegführende. Auf jeder Seite ist mindestens ein Kontrollflusszweig vorhanden, so dass der Weiterverlauf über den Operator gesichert ist. Mindestens auf einer Seite sind es mehrere Zweige, die dann durch den (mehrstelligen) Operator verknüpft sind. Dabei gilt: Entweder werden Ereignisse mit Ereignissen oder Funktionen mit Funktionen verknüpft.

„Operator-Syntax“

Die Operatoren können auf jeder Seite nur Ereignisse mit Ereignissen bzw. 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 Kontrollfluss 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 5].

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 grafischen Notation üblicherweise in einem zweigeteilten Kreis platziert, z.B. so:

Grafikfestlegung


Dort wo ein Operator ist, ist dann mehr als eine Kante. Liegt kein Operator vor, gibt es nur eine einzige Kante. Liegen oben und unten mehr als eine Kante vor, müssen auf beiden Seiten Operatoren vorhanden sein, z.B. so:


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 dasselbe für die weggehenden Kanten.

Syntaxregel: Das Verzweigen und Zusammenführen von Kontrollflusszweigen kann nur über Operatoren erfolgen.

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.

Verteiler und Verknüpfer

13.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 abgeschlossen ist.

Zeitliche Dimension

Somit erfolgt eine erste fundamentale zeitliche Festlegung bei jeder Ereignisgesteuerten Prozesskette dadurch, dass die Funktionen - getrennt durch Ereignisse - nacheinander angeordnet sind. Dadurch ist ihre Reihenfolge festgelegt. Diese Festlegung ist allerdings keine absolute, mit Angabe des Zeitverbrauchs, sondern nur eine relative (zu den anderen Funktionen).

Nicht absolut, nur relativ

In Ereignisgesteuerten Prozessketten wird der erwartete 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 Ereignis, 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.

Zeitverbrauch

Kommunikation bzw. Wie „rettet“ man Informationen über die Zeit

Die Prozessmodellierung mit Ereignisgesteuerten Prozessketten kennt keine Nachrichten, Informationskanäle, und ähnliche Elemente, die ein Kommunikationsnetz modellieren könnten. Hier werden Informationen bei ihrer Entstehung in die Unternehmensdatenbank geschrieben und später im Prozess bei Bedarf wieder gelesen. Dies entspricht auch der Philosophie moderner ERP-Software mit ihrer integrierten unternehmensweiten Datenbank.

In die Datenbank schreiben und von dort lesen

Eher systemorientierte Modellierungsansätze wie die Dynamikkomponenten der UML (Sequenzen, Aktivitäten, Zustandsautomaten, Anwendungsfälle, …) gehen teilweise andere Wege. Hier gibt es durchaus auch das Konzept des Nachrichtenaustausches zwischen den Elementen des Systems. Auch die Methode BPMN (Kapitel 14) kennt den Nachrichtenaustausch zwischen handelnden Einheiten, sogar ein "Broadcastsignal", eine Nachricht an alle übrigen Komponenten.

13.3 Aufbau Ereignisgesteuerter Prozessketten

Die im vorigen Kapitel beschriebenen Elemente von Ereignisgesteuerten Prozessketten werden in der Prozessmodellierung verknüpft, um aussagekräftige Beschreibungen 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 Ausführungen ein einfacher Geschäftsprozess zugrundegelegt. Dieser wird Stück für Stück beschrieben, danach wird die Umsetzung in die EPK erläutert. Die entstehende EPK wird bei jedem Schritt fortgeschrieben, um den Gesamtzusammenhang jeweils deutlich zu machen.

13.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 Gespräch formuliert worden sein. Bei Briefanfragen wird ein Antwortbrief verfasst und versendet. Bei Mailanfragen wird der Maileingang bestätigt, bei im Gespräch formulierten Anfragen eine Auftragsfestlegung (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 Arbeiten, 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 13.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 Ergebnisereignisse genannt werden. Alle diese sechs Ereignisse zeigt die folgende Abbildung.

Ergebnisereignisse


Abbildung 13.3-2: Die ersten Ereignisse der Anfrageprüfung

Nun zum Kontrollfluss dieser Anfangssequenz. Ganz grundsätzlich wird die Syntaxregel eingehalten, dass Funktionen und Ereignisse sich immer ablösen müssen und dass jeder Geschäftsprozess mit einem Ereignis endet und beginnt. Die drei Startereignisse 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 Organisationseinheit Zentralsekretariat angefügt – mit einer richtungslosen Linie.

Syntaxregel E - F - E - …

Informationsobjekte und Organisationseinheiten

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ätigungsmail mit Pfeil zum Informationsobjekt. Die handelnde Organisationseinheit ist hier immer das Zentralsekretariat.

Richtung Informationsfluss

13.3.2 Anfrageprüfung Teil 2

Prozessbeschreibung

Anschließend wird durch den Vertrieb die Anfrage in der ERP-Software angelegt.

Danach folgen zwei Prüfungen: die der zur Verfügung stehenden Fertigungskapazitäten (durch die Abteilung Produktion) und die des Lagerbestandes (durch die Abteilung Lager). Dabei werden Daten der Produktionsplanung bzw. die Lagerdatenbank genutzt. Beide Prüfungen können zu einem positiven oder zu einem negativen Ergebnis führen.

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 genommen werden, da die Startereignisse alternativ sind. Muss innerhalb einer EPK zusammengeführt werden gilt, dass mit demselben Operator zusammengeführt wird, mit dem aufgeteilt wurde. Damit ergibt sich das folgende EPK-Fragment.

Zusammenführung, Verknüpfung


Abbildung 13.3-3: Geschäftsprozess Anfrageprüfung – Zusammenführung alternativer 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 Ereignisgesteuerten Prozessketten. Zuerst wird die Anfrage (B/M/AFL) [Anmerkung] gelesen, dann wird die AnfrageERP geschrieben. Diese Reihenfolge wird im Modell nicht ausgedrückt, sie muss aus der Prozessbeschreibung bzw. der Prozesssituation gefolgert werden.

Etwas spannender wird der nächste Abschnitt des Geschäftsprozesses. Die Prozessbeschreibung 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 Informationsobjekt AnfrageERP dient bei beiden Funktionen als Input, ebenso die abgefragten Datenbestände (Produktionsplanung und Lagerdatenbank).


Abbildung 13.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 werden [Anmerkung] . 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 Lagerbestand.

Da diese jeweils alternativ sind, muss hier in den Kontrollfluss ein XODER-Operator eingefügt werden.

13.3.3 Anfrageprüfung Teil 3

Prozessbeschreibung

Im positiven Fall, wenn also die Prüfungskapazität reicht und der Lagerbestand ausreichend ist, wird dem Kunden durch den Vertrieb zugesagt. Dazu wird die AnfrageERP benötigt. In ihr wird auch die Zusage 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 angestoß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 beschreibt die EPK-Syntax tatsächlich sehr genau die in der Prozessbeschreibung geforderte Semantik: Zum Weiterfluss kommt es nur, wenn beim UND-Operator beide Kontrollflusszweige von den Ereignissen her ankommen.

Verknüpfer mit UND

Bei der Funktion Dem Kunden zusagen werden dann noch die genannte Organisationseinheit und die beiden Informationsobjekte angefügt. Beide werden gelesen und beschrieben, weshalb die Pfeile der Verbindungslinien in beide Richtungen zeigen.


Abbildung 13.3-5: Geschäftsprozess Anfrageprüfung – Positives Ergebnis und Aufruf 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 13.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 flussaufwärts ankommen. In dieser Anordnung (Ereignisse durch UND verknüpft vor einer Funktion) stellen die Ereignisse immer Bedingungen für die Ausführung der nachfolgenden Funktion dar. Vgl. für eine umfassende Darstellung solcher Muster in Geschäftsprozessen [Staud 2014a,b].

13.3.4 Anfrageprüfung Teil 4

Prozessbeschreibung

Falls entweder die Kapazität oder der Lagerbestand nicht reicht, wird dem Kunden durch den Vertrieb abgesagt. Dafür wird die AnfrageERP benötigt, in der auch die Absage vermerkt wird. Ebenso die Kundendatei, in der ebenfalls das Scheitern der Anfrage festgehalten 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 Muster Kombinatorik genannt wird. Der Grund liegt darin, dass die Ergebnisereignisse der beiden Funktionen miteinander kombiniert werden müssen, um alle möglichen Fortführungen 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 Konstellationen 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 wegführenden oder ankommenden Kanten aktiviert werden (nur die Kanten(!), nicht die nachfolgenden Funktionen), führt diese syntaktische Lösung zur gewollten Semantik.

Semantik sucht Sntax


Abbildung 13.3-7: Kombinatorik – in vollem Umfang realisiert

In dem hier vorliegenden konkreten Geschäftsprozess 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 zusammengefasst 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 Abbildung Vor die Funktion Dem Kunden absagen wird ein ODER-Operator gesetzt, der die Kontrollflusszweige der beiden negativen Ergebnisereignisse zusammenfü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.

Semantik sucht Syntax: „mindestens“ mit ODER

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 Ergebnisereignisse vor) durch eine entsprechende Semantik verkleinert wird.


Abbildung 13.3-8: Geschäftsprozess Anfrageprüfung – Die finale EPK

13.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 betrachten.Eine solche EPK wird als Instanz der „allgemeinen“ EPK bzw. der konkrete Geschäftsprozessdurchgang als Instanz des „allgemeinen“ Geschäftsprozesses bezeichnet.

Prozessmodell vs. Prozess-Instanz

Die folgende Abbildung zeigt eine Instanz der obigen EPK, die für den positiven Fall (Auftrag kann angenommen, Folgeprozess kann gestartet werden). Dieser ist durch eine verdickte Linie hervorgehoben. Das Startereignis sei Anfrage per Mail eingetroffen. Es könnte auch jedes der beiden anderen Startereignisse sein. Der folgende Ablauf ist bis zum UND-Operator und den ihm nachfolgenden Funktionen für alle Instanzen gleich. D.h., der UND-Operator „sendet“ immer alle von ihm wegführenden Kanten (Kontrollflusszweige) los.

Kontrollfluss für den positiven Fall

Danach beginnen die möglichen Unterschiede zwischen den Instanzen. Hier („positiver 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 ausreichend) 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 Geschäftsprozess bzw. seiner EPK verweist.


Abbildung 13.3-9: Geschäftsprozess Anfrageprüfung. Die Instanz für den positiven Ausgang.

Kontrollfluss für einen der negativen Fälle

Die folgende Abbildung zeigt eine andere Instanz, einen der Kontrollflussdurchgänge, der zu einem negativen Ergebnis führt. Wiederum sind die entsprechenden Kontrollflusspfeile verdickt.

„negative“ Instanz

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 Funktionen (Prüfung Fertigungskapazität) führt dann aber zum negativen Ergebnis, weshalb 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ängen“, da es über den UND-Operator nur weiter geht, wenn beide Kontrollflusszweige 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 13.3-10: Geschäftsprozess Anfrageprüfung. Die Instanz für einen der negativen 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 effizient modelliert werden können. Dies gilt insbesondere für Istanalysen. Eine detaillierte Darstellung findet sich in [Staud 2014a,b].

14 Methode BPMN

Die Ausführungen in diesem Kapitel sind Auszüge aus dem Buch

Staud, Josef: Geschäftsprozessmodellierung mit der Methode Business Process Model and Notation (BPMN). Vilshofen 2017,

einer umfassenden Einführung in die Methode BPMN (vgl. für nähere Informationen www.staud.info).

14.1 Geschäftsprozesse in der BPMN

Die Business Process Modeling Notation (BPMN) wird von ihren Autoren als DIE Methode zur Prozessmodellierung gesehen. Sie soll die Lücke zwischen einfachen “Business-Anwendern” und Programmnähe schließen.

Wie definieren die BPMN-Autoren Geschäftsprozesse? Im Text finden sich folgende Definitionsmerkmale [OMG 2011, S. 145]:

Definition

  • 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 dargestellt als ein Graph für die genannten Elemente.
  • Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie unter­nehmens­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 die wichtigsten Elemente zusammengestellt, die man für die Modellierung von Geschäftsprozessen benötigt. Die Aktivitäten sind die kleinsten Einheiten (des Geschäftsprozesses, der Tätigkeitsfolge), aus denen man den Gesamtprozess zusammenstellt. 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. Für die Kommunikation über Organisationsgrenzen hinweg gibt es das Konzept der Nachrichtenflüsse.

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 Geschäftsprozesses allgemeiner als eine Menge von Aktivitäten, die innerhalb einer Organisation oder über Organisationen hinweg realisiert werden.

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 Organisation 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 (wie z.B. bei den Aktivitätsdiagrammen der UML, vgl. [Staud 2019, Kapitel 10]), können die BPMN-Autoren auch definieren, dass die internen Prozesse in einem Becken (pool) ablaufen.

Interne Geschäftsprozesse

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äftsprozess. In diesen wird folgendes gepackt:

Öffentlicher Geschäftsprozess

  • Die Aktivitäten, die benutzt werden, um mit der Umgebung des privaten Geschä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 Nachrichten, die notwendig sind, um mit diesem Geschäftsprozess zu interagieren.

Ein Globaler Prozess beschreibt das Zusammenwirken von zwei oder mehr Geschäftseinheiten (business entities). Die Interaktionen sind eine Folge von Aktivitäten, die den Nachrichtenaustausch zwischen den handelnden Einheiten darstellen.

Globaler Prozess

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 miteinander verknüpft werden können. Dies ist möglich durch folgende Methodenelemente:

  • Sequenzfluss
  • Nachrichtenfluss
  • Assoziationen
  • Schwimmbahnen

Schwimmbahnen dienen der Zuordnung der Basismodellelemente zu den Trägern der Aktivitäten. Hier wird unterschieden in

  • Becken (pools)
  • Bahnen (lanes)

Artifakte liefern zusätzliche Informationen über den Prozess. Drei werden vorgegeben, andere können – so die BPMN-Autoren – hinzugefügt werden:

  • Datenobjekte
  • Gruppen
  • Anmerkungen

14.2 Einführung durch Beispiele

14.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 14.2-1: Darstellung einer Aktivität (Subprozess, Aufgabe).

Das Element für dem Kontrollfluss (hier sequence flow, übersetzt mit Sequenzfluss) sind 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 Ende eines Geschäftsprozesses. Damit können wir – bei Hinzunahme der Elemente für Prozessstart und Prozessende (Ereignisse!) – bereits ein erstes natürlich noch sehr schlichtes Prozessmodell erstellen: Eine Folge von Aktivitäten, die initiiert und dann nacheinander abgewickelt werden.


Abbildung 14.2-2: Auftragsabwicklung – Variante 1

Die prozessrelevanten Ereignisse zu den Aktivitäten sind in der Grafik nur implizit vorhanden, z.B. „Lieferung wird gestartet“, Lieferung ist erledigt“, sie werden in der Grafik nicht ausgewiesen. Dies ist in der BPMN meistens so: Nur wenn die Ereignisse nicht-trivial sind, werden sie in der Grafik angeführt.

Ereignisse

Natürlich ist das wirkliche "Prozessleben" nicht so einfach, es fehlt hier noch vieles, was man in einer Prozessmodellierung erwartet. Am meisten vermisst man sicherlich die Entscheidung, ob der Auftrag überhaupt angenommen wird und das Auffächern der Tätigkeiten in parallele Pfade, Auftragsabwicklung auf der einen und Zahlungsabwicklung auf der anderen Seite. Dies ist aber möglich, die dafür nowendigen Operatoren liegen in der Methode vor.

Defizite

Betrachten wir dazu die folgende Abbildung. In ihr ist obiges Business Process Diagram (BPD) etwas ausgebaut. Es ist außerdem mit Nummern in Kreisen versehen. Diese sind nicht Teil der Methode BPMN, sondern dienen nur der Kennzeichnung für die beschreibenden 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 werden. 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 mehrere. 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.

Exclusive Gateway

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 Prozessmodellierung, 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 Gateway

Parallel?

Die Parallelität durch das UND-Gateway (6) bedeutet hier, dass beide weiterführenden Pfade angestoßen werden und dass die Aktivitäten der beiden Pfade durchlaufen werden. "Parallel" bedeutet hier also nur gleichzeitiges Anstoßen, nicht echte Parallelität der Abläufe. Die beiden Sequenzflüsse werden dann, da es in nur einem einzigen 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). Hierfü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 Schlussereignis (9).

Exclusive Merging


Abbildung 14.2-3: Auftragsabwicklung – Variante 2
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85] Übersetzung 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.

14.2.2 Jetzt mit Daten

Informationsobjekte sind alle Geschäftsobjekte wie Rechnungen, Lieferscheine, usw., jegliche Koordinierungsinformation (Anfragen, Angebot, Liefermitteilungen) und natürlich die Datenbestände der ganz normalen Datenbank der Organisation. Diese sind von großer Bedeutung für jeden Geschäftsprozess, weshalb jede Methode zur Modellierung von Geschäftsprozessen vorsehen muss, sie zu erfassen.

Informationsobjekte

In der BPMN können Informationsobjekte einer Aktivität oder einem Sequenzfluss zugeordnet werden. Außerdem können sie in einem eigenen Fluss neben dem Sequenzfluss dargestellt werden. In der folgenden Abbildung sind zwei Informationsobjekte eingebaut. Zuerst der Auftrag, der ins Unternehmen kommt und damit den Geschäftsprozess ja erst auslöst. Er wird ganz einfach der Aktivität Auftragseingang 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.


Abbildung 14.2-4: Auftragsabwicklung – Variante 3
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85]. Übersetzung durch den Verfasser.

14.2.3 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 einzelnen Aktivitäten bestimmt. Möglich sind hier Menschen oder auch Programme, mit oder ohne Maschinen [Anmerkung] . Für die Zuordnung der Träger von Aktivitäten haben die BPMN-Autoren die bekannte Schwimmbahnentechnik gewählt. Bei ihr werden Becken (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.

Handelnde in Becken und Bahnen

Das obere Becken enthält alle Aktivitäten, die durch das hier betrachtete Unternehmen realisiert werden. Es ist weiter unterteilt in zwei Bahnen, eine für die Abteilung Auftragsbearbeitung, eine für die Abteilung Finanzwesen. Die Aktivitäten sind in der Bahn der Abteilung, die sie realisiert. Der Sequenzfluss geht dann entsprechend 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 Einheiten" [Anmerkung] 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 ("Zahlungseingang").


Abbildung 14.2-5: Auftragsabwicklung – Variante 4
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85]. Übersetzung durch den Verfasser.

14.3 Öffentliche Geschäftsprozesse

Öffentliche Geschäftsprozesse wurden oben schon kurz vorgestellt. Die BPMN-Autoren verstehen darunter die Vorgänge, die zwischen einem internen Geschäftsprozess 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 modelliert. 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 solchen Teilnehmer am Geschäftsprozess enden und starten dann an der Grenzlinie des Beckens. Ansonsten dürfte das Beispiel selbsterklärend sein.

Nachrichtenaustausch


Abbildung 14.3-1: Kontakt zwischen Arztpraxis und Patient – Version 1.
Quelle: [OMG 2011, S. 24, Figure 7.2]; Übersetzung durch den Verfasser.

Zusammenarbeit …

Eine Zusammenarbeit (collaboration) beschreibt die Interaktionen zwischen zwei oder mehr Teilnehmern am Prozessgeschehen, die normalerweise durch je ein Becken erfasst werden. Zwischen diesen kann es ja nur Nachrichtenverkehr geben, der die Becken oder die Objekte im Becken verknüpft.

… zwischen den Prozessteilnehmern

Liegen öffentliche Prozesse vor, können die Aktivitäten für die Kollaboration als die Berührungspunkte zwischen den Teilnehmern aufgefasst werden. Die zugehörigen 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 ausgestalteten Prozess beim Patienten und den Nachrichtenverkehr zwischen einzelnen Aktivitäten. Wenn dann – wie hier – zwei oder mehr öffentliche Prozesse miteinander 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].

Globaler Prozess


Abbildung 14.3-2: Kontakt zwischen Arztpraxis und Patient – Version 2. Quelle: [OMG 2011, S. 24, Figure 7.2]; Übersetzung durch den Verfasser.

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.

14.4 Aufgabentypen

Die folgende tabellarische Auflistung 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, gekennzeichnet werden (Call Activity).

 


Grundsymbol

Beschreibung

 

Eine Aufgabe ist eine atomare Aktivität in einem Prozessfluss. Sie wird in der Prozessbeschreibung benutzt, wenn die Tätigkeit nicht weiter detailliert werden kann (soll).

Auch: abstrakte Aufgabe


 

 


Symbole für:
Innere Struktur

Beschreibung

 

Aufgaben, die parallel mehrfach aktiv werden können, parallel oder sequentiell. Dies sind zum Beispiel – in einem entsprechenden Geschäftsprozess – die Auslieferungen von Sendungen.

 

Aufgaben mit sich wiederholenden Tätigkeiten. Zum Beispiel die Abarbeitung des Maileingangs.

 

Aufgaben, die als Ersatz für andere dienen ("zur Kompensation"). Zum Beispiel die Stornierung einer Flugbuchung, falls bei dieser Probleme auftraten.


 


Symbole für:
Grad der Automatisierung

Beschreibung

 

Aufgaben des Typs Handarbeit. Sie werden von Menschen durchgeführt, ohne Anwendungsprogramm und ohne Business Process Engine. Z.B. entlang einer papiergestützten Anweisung für einen Telefontechniker.

 

Aufgaben des Typs Nutzeraufgabe. Sie werden von Menschen mit Hilfe von Anwendungsprogrammen durchgeführt. Die Aufgabenerledigung wird durch einen task list manager gesteuert.

 

Aufgaben des Typs Dienst. Sie werden durch einen WebService oder ein automatisch ablaufendes Anwendungsprogramm erledigt.

 

Aufgaben des Typs Skript. Sie werden durch eine Business Process Engine ausgeführt.

 

Aufgaben des Typs Geschäftsregel. Sie dienen dazu, Input an eine Business Rules Engine zu liefern und die dort erzielten Ergebnisse zu empfangen.


 


Symbole für:
Nachrichtenbasierte Tätigkeiten

Beschreibung

 

Aufgaben des Typs Sender. Sie dienen dem Versenden einer Nachricht an einen externen Prozessteilnehmer.

 

Aufgaben des Typs Empfänger. 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.


 


Symbol für:
Globale Aufgabe

Beschreibung

 

Ein Bild, das Schild, Himmel, draußen, Flasche enthält.#10;#10;Automatisch generierte Beschreibung

Call Activity, die eine globale Aufgabe aufruft (hier des Typs Handarbeit).


 

14.5 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 Subprozesse als Ganzes aufgerufen werden und nicht einzelne ihrer Aktivitäten. Sie sind also als solche in das übrige Prozessmodell eingebunden.

Elternprozess

Dieses Methodenelement gibt es in jeder Methode zur Prozessmodellierung. Die folgende Abbildung zeigt einige der hierbei 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.

 


Grundymbole

Beschreibung

 

 

Verborgener Subprozess (collapsed sub process)

 

 

Entfalteter Subprozess (expanded sub process)


 


Symbole für:
Innere Struktur – mit Beispielen

Beschreibung

 

 

Kompensations-Subprozess

Subprozess, der als Ersatz für andere dienen kann ("zur Kompensation").

 

Mehrfachinstanz-Subprozess, parallel

Subprozess, der parallel mehrfach aktiv werden kann

 

 

Mehrfachinstanz-Subprozess, sequentiell

Subprozess, der sequentiell mehrfach aktiv werden kann.

 

 

Subprozess mit Schleifencharakter

Beschreibt sich wiederholende Tätigkeiten.

 

 

Ad Hoc – Subprozess

 

 

Verborgener Subprozess mit mehreren Kennzeichnungen: Ad Hoc und Schleife.


 


Symbole für
Innere Struktur – Fortsetzung

Beschreibung

 

 

Entfalteter Subprozess mit mehreren Kennzeichnungen: Mehrfachinstanz und Ad Hoc.


 


Symbole für:

Weitere Subprozesse

Beschreibung

 

 

Call Activity, die einen verborgenen Prozess aufruft.

 

 

Call Activity, die einen entfalteten Prozess aufruft.

 

 

Ereignissubprozess, verborgen (event sub-process, collapsed)

 

 

Ereignissubprozess, entfaltet (event sub-process, expanded)

 

 

Transaktion


 

14.6 Ereignisse

Die Ereignisse werden von den BPMN-Autoren auf vielfältige Weise unterschieden und alle diese Unterscheidungen werden auch in der grafischen Darstellung ausgedrückt.

Der Ausgangspunkt der Differenzierung ist die Unterscheidung von Start-, Zwischen- und Schlussereignissen. Ihre grafische Gestaltung erfolgt mit schwarzen Linien und ist ansonsten wie folgt:

Start, Zwischen, Schluss

  • 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 empfangende Auslöser, Schlussereignisse nur abgebende Auslöser und Zwischenereignisse beide haben, ergibt sich die Einteilung der Kopfzeile der folgenden Abbildung.

Empfangend, abgebend

Das dritte Kriterium erfasst Sondersituationen für Subprozesse. Es geht um Ereignisse, 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 Zwischenereignissen "Boundary Interrupting" (E) und "Boundary Non-Interrupting" (F).

Sondersituationen für Subprozesse

Die nicht unterbrechenden Varianten werden jeweils mit gestrichelter Linie gekennzeichnet.

Die vierte Ausdifferenzierung erfolgt nach den Auslösern der Ereignisse. Hier gibt es insgesamt die folgenden:

  • Kein bestimmter Auslöser (none). [In der folgenden Abbildung Nr. 13]
  • Nachricht (message): Dies bedeutet, dass von einem Teilnehmer am Prozess eine Nachricht erwartet oder versendet wird. Grafisches Symbol: Briefumschlag. [12]
  • Fehler (error): Dieses Symbol gibt an, dass eine benannte Fehlermeldung erzeugt wird. Grafisches Symbol: Blitz. [11]
  • Zeitgeber (timer): Mit diesem Kennzeichen kann zum Ausdruck gebracht werden, dass das Ereignis Zeitaspekte erfasst. Grafisches Symbol: Uhr. [10]
  • Eskalation (escalation): Damit wird beschrieben, dass sich eine Prozesssituation zugespitzt hat und besondere Maßnahmen zu ergreifen sind. Grafisches Symbol: nach oben gerichtete Pfeilspitze. [9]
  • Signal: Gibt an, dass Signale gesendet oder empfangen werden. Grafisches Symbol: Dreieck. [8]
  • Abbruch (cancel): Durch diese Kennzeichnung entsteht ein Ereignistyp, der den Geschäftsprozess bzw. den jeweiligen Fluss abbricht. Grafisches Symbol: schräg gestelltes Kreuz. [7]
  • Kompensation (compensation): Erhält ein Ereignis das Kennzeichen Kompensation (compensation) und wird dieses Ereignis an die Grenzlinie einer Aktivität angefügt, muss es auch einen Sequenzflusspfeil zu einer anderen Aktivität geben. Diese andere Aktivität ist dann im Krisenfall Ersatz für die Ausgangsaktivität (die mit dem Kompensationsereignis). Grafisches Symbol: "Rücklauftaste", wie früher bei Kassettenrekordern. [6]
  • 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. [5]
  • 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. [4]
  • Beenden (terminate): Ein Ereignis mit diesem Kennzeichen beendet den Prozess. Grafisches Symbol: Gefüllter Punkt. [3]
  • Mehrfach (multiple): Dies bedeutet, dass dem Ereignis mehrere Auslöser zugewiesen sind. Grafisches Symbol: Fünfeck. [2]
  • Parallel mehrfach (nur empfangend): Wie "Mehrfach", nur dass alle Auslöser aktiv werden müssen. Grafisches Symbol: waagrecht stehendes Kreuz. [1]

Alle Kennzeichen sind grafisch so gestaltet, dass eine nicht geschwärzte und eine schwarz eingefärbte Fassung möglich ist.


Abbildung 14.6-1: 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.

14.7 Gateways

Die folgende Tabelle zeigt die grafischen Symbole für die hier möglichen Operatoren. 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 abgearbeitet 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]).

Tabelle 14-1: Gateways der BPMN – Kurzüberblick. Quelle: [Staud 2017, Kapitel 11].

15 Ebenen und Muster

15.1 Verschiedene Ebenen

15.1.1 Vertikale Dimension

Zur Prozessmodellierung gehört, insbesondere im Kontext der Unternehmensmodellierung, dass Geschäftsprozesse auf unterschiedlichen Ebenen betrachtet werden. Ganz oben z.B. die Wertschöpfungskette, darunter auf einem mittleren Level die gesamte Prozesslandschaft mit hoch aggregierten Einzelaktivitäten, darunter eine Art Standardprozessmodellierung (bei der Geschäftsobjekte wie Rechnungen als solche verarbeitet werden), ganz unten, nahe „an der Programmierung“ eine programmnahe Prozessmodellierung.

Verschiedene Ebenen

Erst die Betrachtung dieser vertikalen Dimension im Prozessmodell erlaubt ein umfassendes Verständnis des Prozessgeschehens und eine wirklich umfassendes Prozessverständnis.

Die Ebenen spiegeln Aggregationsniveaus der im Prozess zu lösenden Aufgaben wider. Sehr hoch aggregiert ist z.B. die Aufgabe Leistungserbringung, die für jede Organisation Gültigkeit hat. Nicht ganz ernst gemeint, könnte dieses grundlegende Existenzmerkmal von Organisaionen als Ereignisgesteuerte Prozesskette so ausgedrückt werden:


Abbildung 15.1-1: Organisationszweck – sehr hoch aggregiert

Hier ist die Aussagekraft allerdings sehr gering.

Eine immer noch hohe Ebene, die aber schon mehr Aussagekraft hat, wäre (für Industrieunternehmen) eine Erfassung der Abteilungen und – ganz grob – der Beziehungen zwischen diesen. Z.B. also mit Beschaffung, Produktion, Lagerhaltung, Vertrieb. Sie wird für die Darstellung von Wertschöpfungsketten genutzt, wie auszugsweise in der nächsten Abbildung gezeigt (vgl. [Staud 2006, Abschnitt 8.2.3], auch für Beispiele), und auch für Prozesslandschaften (vgl. unten). Die dabei verwendeten Chevron-Symbole repräsentieren die Geschäftsprozesse des jeweiligen Bereichs.

Übersichtsnotationen

Diese Übersichtsnotationen finden auch in der Unternehmensmodellierung Verwendung. Jedes Element repräsentiert dabei inhaltlich zusammengehörige Geschäftsprozesse. Die Elemente sind linear angeordnet (auch mit Verzweigungen) und stellen auf diese Weise die repräsentierten Bereiche, wenn auch auf sehr einfache Weise, in Beziehung. Die folgende Abbildung zeigt ein Beispiel. Die Pfeile drücken die Verknüpfung zu vor- und nachgeordneten Bereichen aus.


Abbildung 15.1-2: Wertschöpfungskettendiagramm mit Chevron-Symbolen.

Wesentlich weniger aggregiert ist dagegen eine Grobmodellierung von Geschäftsprozessen. Diese beschreibt den Prozess zwar noch integriert, fasst aber in den einzelnen Aktivitäten (bzw. Funktionen) ganze Prozessabschnitte zusammen. Insgesamt entsteht so eine eher oberflächliche Prozessbeschreibung. 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 (vgl. [Staud 2006, Abschnitt 8.2.2]).

Grobmodellierung von Geschäftsprozessen

Eine Ebene tiefer kann die in Kapitel 12 schon eingeführte Modellierungsebene angesiedelt werden, bei der eine geschlossene Handlung eines Prozessteilnehmers in ein Basistheorieelement (eine Tätigkeit: Aufgabe/Funktion) gepackt wird und bei der die Geschäftsobjekte (Rechnung, usw.) als Ganzes erhalten bleiben. Diese wurde Standardprozessmodellierung genannt. Das ist also die Ebene, auf der Geschäftsobjekte sichtbar sind und Prozesshandeln erfasst werden kann, so dass die Modellierung des Kontrollflusses ohne Schwierigkeit möglich ist. Oftmals erfolgt dies im Rahmen einer Istmodellierung. Selbstverständlich lässt auch solch eine Definition noch Raum für unterschiedliche Aggregationsniveaus, bewältigt also auch nicht ganz den sog. Subjektivitätsfaktor 1 (vgl. Abschnitt 2.3).

Standardprozess­modellierung

Geht es darum, die Geschäftsprozesse programmgestützt abzuwickeln (vgl. Kapitel 17 – 19), muss die oben schon angeführte weitere, detailliertere, Modellierung folgen. Sie soll programmnahe Prozessmodellierung genannt werden. Sie dient zur direkten Vorbereitung der Systemanalyse und des Software Engineering, ist also Teil des Requirement Engineering. In der heutigen Situation sind dafür Aktivitäten und Zustandsautomaten der UML und die BPMN die Werkzeuge der Wahl. Für Detailanalysen, wenn eine bestimmte Situation programmtechnisch intensiv zu hinterfragen ist, sind Sequenzdiagramme sehr hilfreich. Hier kommen also Prozessmodellierung und Systemanalyse zusammen.

Programmnahe Prozessmodellierung

Mit „System“ ist hier IT-System gemeint. Dieses ist notwendig, so gut wie jeder Geschäftsprozess wird durch IT unterstützt und dies wird durch den Trend zur automatisierten Abwicklung von Geschäftsprozessen noch wichtiger.

Programmnahe Prozessmodellierung muss wesentlich detaillierter sein als eine Standardprozessmodellierung. Hier müssen die einzelnen „Handlungen“ so zerlegt werden, dass sie 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. Rechnungen, 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 Geschäftsobjekt für die Zwecke der Speicherung und Programmierung zerlegt werden musste. Die Semantik zu den Geschäftsobjekten ist da dann im jeweiligen Programm hinterlegt.

Insgesamt sind also folgende Ebenen sinnvoll: "Ganz oben" die Übersichtsdarstellungen, darunter auf einem mittleren Level Grobmodellierungen (mit der gesamten Prozesslandschaft oder Teilen davon) mit hoch aggregierten Einzelaktivitäten, darunter die Standardprozessmodellierung, ganz unten, nahe „an der Programmierung“ eine programmnahe Modellierung (vgl. [Staud 2019, Kapitel 14 und 15]).

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.

Vertikale Dimension


Abbildung 15.1-3: Vertikale Dimension der Prozessmodellierung – Mögliche Ebenen.

Sie wird meist so eingerichtet, dass ein Element der oberen Ebene in genau abgegrenzte mehrere der unteren Ebene zerfällt. Hier also:

  • Zu einem Element der Wertschöpfungskette/Prozesslandschaft (z.B. Vertrieb) gehören bestimmte (genau abgegrenzte) der Zwischenebene. Zum Beispiel die einschlägigen Szenarien.
  • Zu jedem Element der Zwischenebene (Grobmodellierung) gehören ganz bestimmte Geschäftsprozesse der Standardprozessmodellierung (z.B. einzelne Geschäftsprozesse des Vertriebs) .
  • 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 Funktionen weiter spezifiziert.

Gaitanides betrachtet diese Gesamtthematik unter dem Stichwort Vertikale Ausdifferenzierung von Geschäftsprozessen und weist auf das Dilemma hin, dass sich mit zunehmender Detaillierung "die Transparenz und Übersichtlichkeit der Gesamtstruktur des Geschäftsprozesses" verringert, dass der hohe Detaillierungsgrad aber notwendig ist für die IT-Unterstützung [Gaitanides 2012, S. 162].

Modellierungsdilemma

15.1.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 hervorgehoben zu werden. In der Standardprozessmodellierung werden normalerweise bestimmte Tätigkeiten in elementare Einheiten zusammengefasst (Kalkulation erstellen, 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.

Funktionsmodellierung

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 Funktion, die Art und Weise, wie die Stundenvorgaben für den Projektleiter berechnet werden [Staud 2017, Abschnitt 14.7.2]. Dies muss man erkennen, wenn man einen solchen Prozess modelliert. Sonst entsteht eine Prozessmodellierung, die auf sehr unterschiedliche 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.

Beispiel

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.

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

15.1.3 Prozesslandschaften

Den Rahmen für Geschäftsprozesse stellen Organisationen dar, wertschöpfende (Unternehmen) und nicht wertschöpfende (Verwaltungen, usw.). Bei Letzteren sollten die Bemühungen in Richtung möglichst hoher Effizienz zielen. Die organisationsrelevanten Tätigkeiten werden als Geschäftsprozesse bezeichnet, die Geschäftsprozesse insgesamt als Prozesslandschaft oder Prozesslandkarte.

Prozesslandschaft

Eine Prozesslandschaft besteht damit aus zahlreichen Geschäftsprozessen, die aufgerufen, durchgeführt und beendet werden. Bis auf wenige Ausnahmen sind alle Geschäftsprozesse einer Organisation miteinander verknüpft (im Sinne einer "loosen Kopplung"), was im Folgenden auch zu berücksichtigen ist.

Für einen Überblick zu Übersichtsnotationen und Grobmodellierungen vgl. [Staud 2006, Kapitel 8].

In Prozesslandkarten kann zwischen unterschiedlichen Prozesstypen unterschieden 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 Unterstützungsprozesse [Gadatsch 215, Pos. 354].

Hier ein Beispiel eines Industrieunternehmens, das einen Schwerpunkt im Reklamationswesen setzen muss. Unterschieden und unterschiedlich grafisch dargestellt werden Management-, Kern- und Supportprozesse. Die Abteilungen werden manchmal durch Linien verbunden, wie in [Alpar, Alt, Bensberg u.a. 2014, S. 141] und drücken dann den Grobablauf aus.


Abbildung 15.1-4: Beispielhafte Prozesslandschaft

Die folgende Abbildung zeigt eine Verbindung von Prozesslandschaft und vertikaler Struktur, wie sie die Entwickler von ARIS Express vorschlagen. Die inhaltlich sehr einfache Ausgestaltung stammt vom Verfasser.

Vertikal und horizontal


Abbildung 15.1-5: Prozesslandschaft. Erstellt mit ARIS Express.

Aufgabe: xxx

Vergleichen Sie die Beispiele in den folgenden Quellen hinsichtlich Aufbau und Struktur:

- [Gadatsch 2015, Pos. 354] ("Prozesslandkarte für eine Versicherung")

- [Alpar, Alt, Bensberg u.a. 2014, S. 141] ("Prozesslandkarte – Beispiel Reiseplattform")

- [Alpar, Alt, Bensberg u.a. 2014, S. 141] ("Generische Prozesslandkarte")

15.2 Muster in Geschäftsprozessen

Prozessmodellierung geht vom Geschäftsprozess aus, seinem Aufbau und seiner Semantik. So gut wie jeder Prozessabschnitt drückt Semantik aus. Zahlreiche davon tauchen immer wieder auf: Entscheidung fällen, Tätigkeit wiederholen, Bedingungen für den Fortgang, Aufgaben anstoßen, Datenobjekte erzeugen, Bedingungen und Zeitpunkte beachten, Prozesse starten und beenden, usw. Dies sind (sich oft wiederholende) Muster in Geschäftsprozessen. Die sie abbildenden Prozessmodellabschnitte sind dann Muster im Prozessmodell.

Semantik von Prozessabschnitten

Da sie sich oft wiederholen, einige kommen in so gut wie jedem nicht-trivialen Geschäftsprozess vor, lohnt sich die genauere Betrachtung. Dies sorgt für Effizienz und für weniger Fehler. Konkret: Es entstehen schneller korrekte Prozessmodelle.

Ich beschreibe diese Thematik oft mit …

Semantik sucht Syntax,

… denn bei der Modellierung von Geschäftsprozessen geht es dann darum, diese semantischen Muster in die Syntax der gewählten Modellierungsmethode umzusetzen. Man sucht also für eine bestimmtes semantisches Muster die geeignete Syntax der Modellierungsmethode.

Semantische Muster und ihre Umsetzung

In Abschnitt 15.2 werden die Muster grundsätzlich betrachtet – ohne Bezug zu einer Modellierungsmethode.

Abschnitt 15.3 betrachtet deren Umsetzung mit der BPMN, Abschnitt 15.4 zeigt, wie sie mit Ereignisgesteuerte Prozessketten umgesetzt werden. Diese Kapitel entstammen, leicht verändert, meinen Büchern zu Ereignisgesteuerte Prozessketten und zur BPMN ([Staud 2014a,b], [Staud 2017]).

Folgende Muster werden hier betrachtet:

  • Prozessstart
  • Prozessende
  • Wiederholung, Rückschleife
  • Entscheidungsfindung
  • Abstimmung von Prozesshandeln
  • Teilaufgaben anstoßen; Start mehrerer Aufgaben
  • Bedingungen – einfach
  • Bedingungen –Kombinatorik
  • Wiederholung von Geschäftsprozessabschnitten
  • Zeitpunkte
  • Zeitfenster
  • Warten
  • Delegation
  • Zusammenarbeit über Abteilungsgrenzen
  • Zusammenarbeit über Organisation
  • Informationsweitergabe, -verarbeitung

15.2.1 Geschäftsprozess starten

Die Standardauffassung von Geschäftsprozessen in der Prozessmodellierung ist, dass sie gestartet, abgewickelt und beendet werden. Und dies jedesmal, wenn ihre Leistung erforderlich ist. Dass dies nicht immer so ist, merkt man spätestens, wenn man sich der Programmierung von Geschäftsprozessen und dem Thema „Geschäftsprozesse als Automaten“ widmet (vgl. [Staud 2019, insbesondere Kapitel 19 zu Zustandsautomaten]).

Starten, abwickeln, beenden

Hier soll es aber bei der „Standardauffassung“ bleiben. Dann werden also Geschäftsprozesse regelmäßig gestartet. Dies geschieht durch Ereignisse und kann auf folgende Weise geschehen:

  • Durch ein externes Ereignis. Z.B. Auftrag geht ein.
  • Durch ein internes Ereignis, d.h. in der Regel durch einen internen Geschäftsprozess.

Die Ereignisse können unterschiedlicher Natur sein, Z.B.:

  • Eine ankommende Nachricht ("Auftrag geht ein")
  • Eine Fehlermeldung ("Cloud-Anwendung nicht erreichbar")
  • Zeitliche Aspekte ("Jeden Morgen um 3:00 Uhr startet die Kontrolle der Zahlungseingänge")
  • Ein Signal ("Geldautomat wird aufgebrochen")
  • Eine Kompensation ("Online-Buchung ist fehlgschlagen, anrufen!")
  • Eine Bedingung ("Nachbestellen, weil Bestand unter 1000 und erwarteter Absatz 2000")

Die Ereignisse kommen aus der informationellen Umwelt des Geschäftsprozesses (des Unternehmens).

Ein Geschäftsprozess kann meist in einzelne Aufgaben zerlegt werden. Auch für diese gilt (natürlich), dass sie gestartet und dann auch beendet werden müssen. Scheer hat das in seiner Methode (den Ereignisgesteuerte Prozessketten) sehr klar ausgedrückt, indem er vor und nach jeder Aufgabe ein Ereignis platzieren lässt, das den Start bzw. die Erledigung signalisiert. Vgl. dazu [Staud 2014].

Tätigkeiten

15.2.2 Geschäftsprozess beenden

Ein weiteres triviales Muster ist das Beenden von Geschäftsprozessen. Dies kann ein einfaches Beenden sein, ohne direkte weitere Aktion.

Es kann aber auch mit einer Aktion verbunden ein. Z.B. dem Versenden des Angebots, nachdem dieses fertiggestellt wurde. Oder schlicht dem Versenden einer Nachricht.

Ende mit Aktion

Es kommt natürlich auch vor, dass ein Geschäftsprozess einen anderen nachfolgenden aufruft. Dann wird am Prozessende ein entsprechender Aufruf zu platzieren sein.

Ende mit Aufruf

15.2.3 Entscheidungsfindung

Das am weitesten verbreitete Muster in Geschäftsprozessen ist die Entscheidungsfindung. Dabei handelt es sich um Aufgaben, deren Lösung den weiteren Verlauf des Geschäftsprozesses steuert.

In der Vergangenheit wurden Entscheidungen durchweg von Menschen gefällt. Inzwischen sind dies – wenn es sich um sog. wohlstrukturierte Probleme (vgl. Abschnitt 2.4) handelt – oftmals Programme, mit oder ohne KI-Techniken.

Wer fällt die Entscheidung

Entscheidungen bedeuten immer Problemlösung. Für deren unterschiedliche Komplexität hat Simon bereits 1957 ein Schema vorgelegt (vgl. [Simon 1957]), das von Alpar et al. aufgegriffen wurde (vgl. [Alpar et al. 2014]). Es unterscheidet unstrukturierte, semi-strukturierte und wohlstrukturierte Probleme. Für eine Kurzdarstellung vgl. Abschnitt 2.4.

Unstrukturiert, semi-strukturiert, wohlstrukturiert

Problemlösungen und Entscheidungen benötigen eine informationelle Basis. Diese kann aus den Daten des Unternehmens und der informationellen Umwelt kommen. Sie kann aber auch durch Ereignisse (interne und externe) ausgelöst und fundiert sein.

Informationelle Basis

Die möglichen Ergebnisse von Entscheidungen können unterschiedlich strukturiert sein. Sehr oft liegen alternative Ergebnisse vor (Auftrag wird angenommen oder nicht). Möglich sind auch komplexere Ergebnisstrukturen. Z.B. solche, die Teilmengen von Entscheidungen zulassen. Dazu mehr in den folgenden Kapiteln.

Ergebnismuster

Ein letzter Aspekt betrifft die Anzahl der Entscheidungsträger. Ist es eine einzelne Person oder sind es mehrere zusammen.

Einzel- oder Gruppenentscheidung

15.2.4 Abstimmung von Prozesshandeln

Sehr oft muss eine nicht-triviale Tätigkeit mit anderen Prozessträgern und mit Externen abgestimmt werden. Beispiel: Die Rechtsabteilung des Unternehmens hat einen Vertrag entworfen (für das Mitwirken einer externen Unternehmensberatung) und muss ihn mit der Geschäftsleitung und dem Beratungsunternehmen bzgl. verschiedener Aspekte abstimmen.

Dies hat auch Kontrollaspekte. Im obigen Beispiel: Beim Zusammenspiel der Rechtsabteilung mit der Geschäftsleitung.

Kontrolle

Hier wird Informationstransport zum Thema. Abstimmung in diesem Sinn ist nur möglich, wenn das entsprechende Geschäftsobjekt (Vertrag, Rechnung, usw.) zwecks Abstimmung transportiert wird.

15.2.5 Teilaufgaben anstoßen

Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen der Abschlusskontrolle eines Buchmanuskripts: Es muss die Seitenformatierung geprüft und korrigiert werden. Ebenso die Kopfzeilen. Außerdem müssen Index und Inhaltsverzeichnis neu erstellt werden.

15.2.6 Bedingungen – einfach

Ein weiteres wichtiges Muster in realen Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Z.B. die, dass man erst dann den Urlaubsantrag stellen darf, wenn man geprüft hat

Semantik: Bedingungen für Fortgang

  • ob noch genügend Urlaubstage vorhanden sind,
  • ob die Geschäftslage die Abwesenheit erlaubt und
  • ob eine Vertretung für wichtige Fragen organisiert ist.

15.2.7 Bedingungen – Kombinatorik

Oben war der Ausgangspunkt, dass eine einzelne Bedingung zu prüfen ist. Sehr oft sind aber mehrere Bedingungen zu prüfen und deren Ergebnisse in Beziehung zu setzen. Ein (zugegeben einfaches) Beispiel, das auch in den folgenden Kapiteln aufgegriffen wird: Nach dem Eingang einer Anfrage wird die Fertigungskapazität und der Lagerbestand geprüft. Nur wenn beide Prüfungen positiv ausfallen, wird die Anfrage angenommen, sonst wird verhandelt oder abgesagt. Vgl. unten.

15.2.8 Wiederholungen

Die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, spielt in Geschäftsprozessen eine wichtige Rolle. Dabei handelt es sich entweder um ganze Geschäftsprozesse oder um Prozessabschnitte. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen auf.

Wiederholung von Geschäftsprozessen

Es gibt Situationen in Geschäftsprozessen, wo man nur eine bestimmte Anzahl von Wiederholungen zulassen möchte ("Wiederholklausuren").

Kontrollierte Wiederholung

Ein anderes ganz ähnliches Muster ist ebenfalls oft in Geschäftsprozessen anzutreffen: Sich mehrfach wiederholende (repetitive) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt.

Sich mehrfach wiederholende Handlungen.

15.2.9 Zeitpunkte

Das folgende Muster gehört zum weiten Bereich der zeitlichen Dimension von Geschäftsprozessen: Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat, z.B.:

Muster Zeitpunkte

  • Die Gehälter werden immer am vorletzten Tag des Monats überwiesen.
  • Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten.

15.2.10 Zeitfenster

Oftmals liegt in Geschäftsprozessen das folgende Muster vor: Für die Erledigung bestimmter Aufgaben gibt es ein Zeitfenster (Vorbereitung auf eine Klausur sollte vor derselbigen stattfinden; Angebotserstellung bis zum …), das einzuhalten ist. Etwas konkreter ergibt sich dies so, dass mehrere Tätigkeiten angestoßen werden und erledigt sein müssen, bevor der Zeitrahmen ausgeschöpft ist und der Geschäftsprozess weiter geht.

Muster Zeitfenster

15.2.11 Warten

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf die Entscheidung anderer, Warten auf Lieferungen, einen Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger oder einen Partner des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet.

Muster Warten

Dies sollte erfasst und modelliert werden können.

15.2.12 Delegation

Im Managementbereich, im Verwaltungsbereich, Verantwortung tragen/übernehmen,

immer optional

optionale Abschnitte

15.2.13 Zusammenarbeit über Abteilungsgrenzen

In der BPMN: Element Gruppe

Xxx als Screenshot übernommen


15.2.14 Zusammenarbeit über Organisationsgrenzen

xxx

  • Keine Weisungsbefugnis, normalerweise.
  • Basiert auf Nachrichtenverkehr
  • Treffen? Real oder virtuell. Als eigene Tätigkeit ausweisen.
  • Unterscheiden: Zusammenarbeit durch Hin- und Herschicken von Nachrichten mit Informationen, z.B. Auftrag vergeben, Auftragsbestätigung senden sowie sich treffen, um in Verhandlungen eine Lösung zu finden. .

In der BPMN: Nachrichten, neues Becken. Siehe unten

 

 

15.2.15 Informationsweitergabe, -verarbeitung

In Geschäftsprozessen spielen Informationen aller Art eine wichtige Rolle. Meist treten sie als Geschäftsobjekte (Rechnungen, Angebot, …) auf. Aber auch Datenbankkomponenten sind, v.a. bei einer sehr detaillierten und evtl. programmnahen Modellierung, zu betrachten. Diese Informationen basieren heutzutage i.d.R. auf einer Unternehmensdatenbank.

Muster Informationen – Weitergabe und Verarbeitung

Hinzu kommen noch Informationen mit Nachrichtencharakter. Z.B. textlich formulierte Informationen (Anfragen, …) und Nachrichten (z.B. für Koordinierungsinformationen). Auch die für einen Workflow benötigten Informationsweitergaben gehören hierzu.

Nachrichten

Alle diese Informationstypen werden in Geschäftsprozessen erzeugt, verarbeitet, gelöscht und transportiert.

15.2.16 Optionales Handeln

z.B.

  • Bedarfsweise erfolgt eine Klärung mit dem Antragssteller
  • Delegation (siehe oben)

15.2.17 Automatisierte Abläufe

xxxIm Geschäftsprozess, der ansonsten konventionell realisiert ist, ist ein automatisierter Vorgang enthalten.

xxxBeispiel: Die Organisation hat Individualsoftware und ERP-Software, z.B. von SAP. Die von den Entwicklern erstellten Änderungen für die ERP-Software werden bereitgestellt. Eine Software, nennen wir sie TSW (Transport Software) spielt alle 30 Minuten die bereitgestellten Änderungen in das SAP – System ein, unter Beachtung einer evtl. notwendigen Reihenfolge, mit Kontrolle ob nicht schon eingegeben, usw. Führt Protokoll über alle Einspielungen.

Konkret:

  • Klären, ob Transportaufträge vorliegen
  • Falls ja: ERP-Job, der typischerweise das Einspielen übernimmt, anstoßen.
  • Klärung der Reihenfolge
  • Überspielen

Insgesamt: Zusammenspiel von Software, menschliches Mitwirken: Freigabe erstellen, Vermerken im Programmierauftrag

Weitere Beispiele zu automatisierten Abläufen und ihrer Einbindung finden sich in Kapitel 19.

15.2.18 Überwachen, Kontrollieren

xxxHier allgemeine Beschreibung, unten, bei EPKs, spezifische für EPKs

„Überwachen“ oder „prüfen“ sind ständige Themen in realen Geschäftsprozessen und ihrem Geschäftsprozessmanagement. Sie sollten daher im Geschäftsprozessmanagement bedacht und, insbesondere bei der Erfassung und Modellierung von Geschäftsprozessen, umfassend repräsentiert werden.

Ein einfacher Fall ist Kontrolle auf korrekte Erledigung. In die Prozessbeschreibung kommt die Tätigkeit (z.B. Erstellung von irgendwelchen Unterlagen), danach im Sequenzfluss die Kontrolle, die entweder Erfolg oder Misserfolg signalisiert und im Falle eines Misserfolgs zum Rücksprung führt. Das lässt sich hervorragend in das sequentielle Grundmuster von BPDs und EPKs einfügen. Vgl. dazu die Beispiele in meinen Büchern zu EPKs und BPDs (insbesondere [Staud xxx]).

Kontrolle nach Erledigung

Geht es um komplexere oder auch nur längere Arbeitsabläufe, die insgesamt überwacht werden müssen, wo also der Arbeitsfortschritt kontrolliert werden soll, ist die Situation schwieriger.

Ein Beispiel dafür findet sich in Abschnitt 6.1 (Abbildungen 6.1-5 und 6.1-6) von [Staud xxx]. Dort lag folgende Situation vor (Originalbeschreibung):

Aufeinanderwirken von Funktionen; Einwirken

Die Arbeitsvorbereitung erstellt die Angebotsunterlagen, was bei den Produkten dieses Unternehmens ein längerer und anspruchsvoller Vorgang ist. Der Verkauf überprüft regelmäßig den Fortgang der Arbeiten in der Arbeitsvorbereitung und erstellt im Falle eines Verzuges eine sog. Mahnliste, mit der sozusagen der Verzug dokumentiert wird.

In der ursprünglichen EPK-Beschreibung des Geschäftsprozesses war die Erstellung der Angebotsunterlagen in eine Funktion gekapselt. Damit ergab sich ein EPK-Abschnitt wie in der folgenden Abbildung.

Kapselung


Abbildung 15.2-1: Gekapselte Tätigkeiten

Wird aber auf diese Weise modelliert, werden also kontinuierlich ablaufende Tätigkeiten in einer Funktion zusammengefasst, kann auf die einzelnen Abschnitte im Rahmen der linear/sequenziellen EPK-Methode nicht mehr zugegriffen werden.

Problem durch Kapselung

Als Notlösung bleibt dann lediglich der Rückgriff auf den Ereignisraum, d.h. auf die Verknüpfung von Geschäftsprozessen bzw. Ereignisgesteuerten Prozessketten über Ereignisse. Konkret bedeutet dies, dass, wie ebenfalls in Abschnitt 6.1 gezeigt (vgl. Abbildung 6.1.6), ein eigener Geschäftsprozess (eine eigene Ereignisgesteuerte Prozesskette) angesetzt wird mit einem Startereignis, das den Verstoß angibt. In Abbildung 6.1-6 z.B. Verzug ist aufgetreten. Überwachung wird somit über ein eventuelles negatives Ergebnis der Überwachung modelliert.

Verknüpfung über Ereignisse

Ist eine direktere Verknüpfung der Tätigkeit mit ihrer Überwachung gewollt, bleibt nichts anderes übrig, als die Tätigkeit aus einer Funktion herauszunehmen und in einzelne Teilaufgaben zu zerlegen, (sie – u.U. künstlich – zu sequenzialisieren), nach denen dann jeweils kontrolliert wird. Diese Lösung ergibt sich aus der linearen und sequenziellen Grundstruktur von Ereignisgesteuerten Prozessketten. Vgl. dazu das Beispiel in Abbildung 6.1-5. Dann kann durch Abfragen nach jedem Abschnitt die Überwachung und Erstellung der Mahnliste auf einfache Weise modelliert werden.

Künstliche Sequenzialisierung

Auf diese Weise wird die Ereignisgesteuerte Prozesskette allerdings kompliziert. Außerdem wird u.U. die Semantik nicht voll getroffen, da ein eigentlich kontinuierlicher Ablauf künstlich unterteilt wurde.

Besser wäre es, hier die EPK-Notation um ein Element zu ergänzen, das ganz allgemein die Zuordnung einer Funktion zu gekapselten oder kontinuierlichen Arbeitsschritten erlaubt. Damit könnten zwei Funktionen direkt in Beziehung gesetzt werden. Ergeben sich aus der Beziehung Konsequenzen, könnte dies durch entsprechende Ereignisse modelliert werden.

Erweiterung der Notation

Ein Vorschlag für die im obigen Beispiel vorliegende Situation findet sich in Abbildung 7.1-2. Eine „Funktion“ überwacht die andere und reagiert auf bestimmte Ereignisse. Auf diese Weise ist eine Verknüpfung der Prozesse ohne komplizierte Konstruktion möglich. Allerdings erweitert dies die Notation um ein Element.

Diese Konstruktion könnte nicht nur zur Überwachung bzw. Kontrolle, sondern ganz allgemein zur Beobachtung anderer Tätigkeiten und eventuellen Reaktionen benutzt werden. Allerdings nur, wenn es sich auf der einen Seite tatsächlich um mehrere oder kontinuierliche Arbeitsschritte handelt und wenn auf der anderen Seite wirklich ein weiterer Akteur (ein Mensch oder aber – auch das ist denkbar – eine Maschine bzw. ein Programm) mit im Spiel ist.

Beobachten und Reagieren


Abbildung 15.2-2: Neues Element für die Überwachung kontinuierlicher/gekapselter Arbeitsschritte

15.3 Muster mit der BPMN

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 12 von …

Staud, Josef: Geschäftsprozessmodellierung mit der Methode Business Process Model and Notation (BPMN). Vilshofen 2017.

… weshalb es auch einige Überschneidungen mit obigem Abschitt gibt, was schon bald behoben wird. :)

 

Beschäftigt man sich einige Zeit mit konkreten Geschäftsprozessen, merkt man, dass bestimmte Prozesssituationen immer wieder auftreten. Zum Beispiel Entscheidungen oder die Notwendigkeit, mehrere Tätigkeiten gleichzeitig anstoßen zu müssen. In diesem Kapitel wollen wir von solchen Mustern in Geschäftsprozessen ausgehen und ihre Umsetzung in BPMN-Strukturen betrachten. Wir wechseln also die Perspektive, weg von einer syntaxgesteuerten, hin zu einer von der Semantik ausgehenden Betrachtungsweise.

Dies ist durchaus sinnvoll, weil in der Praxis ja zuerst die realen Geschäftsprozesse mit ihren Mustern da sind und für diese dann Modellstrukturen bzw. -fragmente gefunden werden müssen. Diese Situationen müssen dann bewältigt werden, Semantik sucht also passende Syntax. Folgende werden hier betrachtet:

Semantik such Syntax

  • Geschäftsprozess / Tätigkeit starten
  • Geschäftsprozess beenden
  • Wiederholung, Rückschleife
  • Abstimmung von Prozesshandeln
  • Entscheidungsfindung
  • Bedingungen – einfach
  • Bedingungen – Kombinatorik
  • Teilaufgaben anstoßen
  • Wiederholung von Geschäftsprozessabschnitten
  • Zeitpunkte
  • Zeitfenster
  • Warten
  • Informationsweitergabe, -verarbeitung

15.3.1 Entscheidungsfindung


Semantik sucht Syntax

 

Semantik:

Eine Entscheidung ist zu fällen.

Passende Syntax:

- Aufgabe mit verzweigendem Exclusive Gateway oder Inclusive Gateway

- Ereignisbasiertes Exclusive Gateway für den Prozessstart

- Complex Gateway

- Methodenelement Gruppe

- Ereignisse auf der Grenzlinie von Aufgaben


Das am weitesten verbreitete Muster in Geschäftsprozessen ist die Entscheidungsfindung. Auch dafür gibt es in der BPMN eine tiefe Detaillierung mit entsprechenden syntaktischen Varianten.

Der einfachste Fall

Entscheidungsfindung wird im einfachsten Fall durch eine Aufgabe modelliert, der ein Exclusive Gateway folgt. Die möglichen alternativen Ergebnisse werden an die Kanten geschrieben.


Abbildung 15.3-1: Entscheidungsfindung (alternative Entscheidung) mit Hilfe eines datenbasierten Exclusive Gateway

Gateway:

- Exclusive Gateway, verzweigend (datenbasiert))

Die Entscheidung ergibt sich aus dem Geschehen im Geschäftsprozess ("data based" also, in der Sprache der BPMN-Autoren). Der Entscheidungsvorgang hier soll zu alternativen Ergebnissen führen, entsprechend dem logischen exklusiven Oder (XODER).

Geht es um eine Situation, in der eine oder mehrere Aufgaben realisiert sein müssen, damit es im Fluss weitergeht oder der Fluss startet, wird das Inclusive Gateway benutzt.

Falls die Entscheidung durch externe Ereignisse vollzogen wird, ist die grafische Umsetzung mit Hilfe des ereignisbasierten Exclusive Gateway, das ein Zwischenereignis des Typs Empfangend enthält, vorgesehen. Danach werden die Ereignisse (vom Typ Zwischenereignis / empfangend) angefügt, die den Entscheidungsvorgang beschreiben. Die Entscheidung fällt also außerhalb.

Der folgende Auszug aus dem Beispiel zur Buchausleihe ([Staud 2017, Abb. 14.1-1]) zeigt es exemplarisch. Eine Sender-Aufgabe verschickt die Nachricht darüber, dass das gewünschte Buch ausgeliehen ist. Mit Hilfe des ereignisbasierten Exclusive Gateway und zweier empfangender Nachrichten-Zwischenereignisse wird modelliert, dass nun auf eine Nachricht bzw. auf den Ablauf einer Frist (Zeitgeber-Zwischenereignis / empfangend) gewartet wird.


Abbildung 15.3-2: Entscheidungsfindung mit Hilfe eines ereignisbasierten Exclusive Gateway.
Quelle: Auszug aus [Staud 2017, Abbildung 14.1-1 ("Buchausleihe")]

Enthaltene Elemente:

- Sender-Aufgabe

- Exclusive Gateway / ereignisbasiert

- Nachrichten-Zwischenereignis, empfangend

- Zeitgeber-Zwischenereignis / empfangend

- Zwischenereignis / empfangend

Prozessstart

Falls modelliert werden soll, dass die zur Entscheidung führenden Ereignisse am Prozessanfang anfallen, muss wie folgt modelliert werden. Zuerst wird das Gateway für diesen Fall angegeben (mit einem Startereignis des Typs Mehrfach), dann die Ereignisse. Das Zusammenführen der Sequenzflüsse kann dann wie hier gezeigt erfolgen, also ohne ausdrückliche Betonung des "exklusiven" Charakters der Verzweigung. Die möglichen Handlungen werden durch ein Nachrichten-Zwischenereigns, ein Bedingungs-Zwischenereignis oder ein Signal-Ereignis angestoßen, alle vom Typ empfangend.


Abbildung 15.3-3: Entscheidungsfindung mit Hilfe eines ereignisbasierten Exclusive Gateway für den Prozessstart.
Quelle: Auszug aus [Staud 2017, Abbildung 14.1-1 ("Buchausleihe")]

Enthaltene Elemente (Auswahl):

- Bedingungs-Zwischenereignis, empfangend

- Dienst-Aufgabe

- Exclusive Gateway / ereignisbasiert, für den Prozessstart

- Nachrichten-Zwischenereignis, empfangend

- Nutzer-Aufgabe

- Signal-Zwischenereignis, empfangend

Komplexe Entscheidungen

Handelt es sich um komplexere Entscheidungen, die z.B. auf einem Regelwerk beruhen, und will man dies ausdrücken, dann wählt man das Complex Gateway.


Verdeckte Entscheidungen

Die Möglichkeit, Ereignisse auf die Grenzlinie von Aufgaben zu setzen, schafft ebenfalls eine Kontrollstruktur, die zu Entscheidungen führt. Intern liegt in der Aufgabe eine Verzweigung vor, die man vom Ergebnis her so beschreiben kann: Das Grenzlinienereignis tritt ein oder nicht. Dies muss vom Träger der Aufgabe (Mensch, Programm, Maschine, …) entschieden werden. Falls dann das Ereignis eintritt, kommt es zur gegenüber dem "normalen Sequenzfluss" abweichenden auszulösenden Aufgabe. Im folgenden Beispiel ist dies ein Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend.


Abbildung 15.3-4: Entscheidungsfindung mit Hilfe eines Grenzlinienereignisses

Ereignis:

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

Auch Kompensationen entsprechend diesem Muster.

Mehrere zusammen

Möchte man ausdrücken, dass mehrere Akteure zusammen die Entscheidungsfindung realisieren (ohne den Entscheidungsweg näher zu spezifizieren) kann das Methodenelement Gruppe (group) genutzt werden. Nachfolgende Abbildung zeigt ein Beispiel.


Abbildung 15.3-5: Element Gruppe (group) zur Modellierung von gemeinschaftlicher Entscheidungsfindung.
Quelle: Auszug aus [Staud 2017, Abbildung 7.2-1]

Enthaltene Elemente (Auswahl):

- Gruppe

- Nachrichtenfluss

15.3.2 Teilaufgaben


Semantik sucht Syntax

 

Semantik:

Teilaufgaben einer umfassenderen Aufgabe sollen gemeinsam "angestoßen" werden.

Passende Syntax:

Ein verzweigendes Parallel Gateway


Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen einer Auftragsabwicklung, wie es das folgende Beispiel zeigt. Nach Eingang des Auftrags (hier modelliert als empfangendes Nachrichten-Zwischenereignis) werden der Auftragseingang angelegt, die benötigten Teile vom Lager angefordert, Fremdteile beschafft und die Produktionsplanung durchgeführt. Dies kann mit Hilfe eines verzweigenden Parallel Gateway realisiert werden. Damit werden die nach dem Gateway folgenden Aktivitäten angestoßen.


Abbildung 15.3-6: Muster Teilaufgaben

Enthaltene Elemente:

- Nachrichten-Zwischenereignis, empfangend

- Parallel Gateway, verzweigend

Dies ist keine Parallelität im wortwörtlichen Sinn, sondern nur ein gemeinsames Starten der Aufgaben.

15.3.3 Geschäftsprozess / Tätigkeit starten

An sich ist es eine übersichtliche Situation: Ein Prozess wird gestartet (BPMN-Autoren: instanziiert) wenn eines seiner Startereignisse eintritt [OMG 2011, S. 426]. In der BPMN hat dieser Vorgang aber zahlreiche Varianten, so dass sich ein genauer Blick lohnt. Einen ersten Einblick in die Varianten gibt die folgende Abbildung. Sie gibt alle möglichen Startereignisse an.

In Abschnitt 9.1.4 wurden die Festlegungen der BPMN-Autoren dafür angeführt. In Abschnitt 9.2 wurde die Bedeutung der sieben Start-Ereignistypen erläutert. Folgende Semantikvarianten können berücksichtigt werden:

  • Prozessstart ohne besonderen Grund ([Staud 2017, Abschnitt 9.2-1) mit einem "None-Startereignis" (oberste Ebene)
  • Prozessstart durch eine ankommende Nachricht ([Staud 2017, Abschnitt 9.2-2]), mit einem Nachrichten-Startereignis (oberste Ebene, Ereignissubprozesse)
  • Prozessstart durch einen Fehler ([Staud 2017, Abschnitt 9.2.3]) mit einem Fehler-Startereignis (Ereignissubprozess, unterbrechend)
  • Prozessstart durch zeitliche Aspekte ([Staud 2017, Abschnitt 9.2.4]) mit einem Zeitgeber-Startereignis (oberste Ebene, Ereignissubprozesse)
  • Prozessstart durch eine Eskalation ([Staud 2017, Abschnitt 9.2.5]) mit einem Eskalations-Startereignis (Ereignissubprozesse)
  • Prozessstart durch ein Signal ([Staud 2017, Abschnitt 9.2.6]) mit einem Signal-Startereignis (oberste Ebene, Ereignissubprozesse)
  • Prozessstart aufgrund einer Kompensation ([Staud 2017, Abschnitt 9.2.8]) mit einem Kompensations-Startereignis (Ereignissubprozess, unterbrechend)
  • Prozessstart durch das Erfüllen einer Bedingung ([Staud 2017, Abschnitt 9.2.9]) mit einem Bedingungs-Startereignis (oberste Ebene, Ereignissubprozesse)
  • Prozessstart durch ein Ereignis aus mehreren ([Staud 2017, Abschnitt 9.2.12]) mit einem Mehrfach-Startereignis (oberste Ebene, Ereignissubprozesse)
  • Prozessstart durch mehrere Ereignisse, die alle eintreten müssen ([Staud 2017, Abschnitt 9.2.13]) mit einem "Parallel Mehrfach-Startereignis" (oberste Ebene, Ereignissubprozesse)

Einige betreffen also den ganz normalen Start von Prozessen und Subprozessen (angestoßen vom Sequenzfluss), andere sind für Ereignissubprozesse gedacht, unterbrechend und nicht unterbrechend.


Abbildung 15.3-7: Alle möglichen Startereignisse – Auszug aus [Staud 2017, Abbildung 9.1.-2]

Start von Geschäftsprozessen


Semantik sucht Syntax

 

Semantik:

Ein Geschäftsprozess soll gestartet werden. Eine getrennt modellierte Teilaufgabe soll gestartet werden.

Passende Syntax:

Startereignisse für die "oberste Ebene"

Prozessstart-Aufgabe


Der "ganz normale Start" (oberste Ebene) sieht ein Startereignis oder mehrere am Prozessanfang vor, so wie es viele Prozessbeispiele oben schon zeigten, weitere finden sich in [Staud 2017, Kapitel 14]. Hier zwei Beispiele:


Abbildung 15.3-8: Start durch ein None-Startereignis / oberste Ebene. Auszug aus [Staud 2017, Abbildung 9.1.-2]

Enthaltene Elemente:

- None-Startereignis / oberste Ebene

- Empfänger-Aufgabe

- Dienst-Aufgabe

Die folgende Abbildung zeigt, wie die Situation dargestellt wird, falls eine ankommende Nachricht den Prozess auslöst.


Abbildung 15.3-9: Start durch ein Nachrichten-Startereignis / oberste Ebene. Auszug aus [Staud 2017, Abbildung 9.1.-2]

Enthaltene Elemente:

- Nachrichten-Startereignis

- Aufgabe, abstrakte

Eine weitere (wohl v.a. grafische) Variante für einen solchen Prozessstart erlaubt der Einsatz einer Aufgabe des Typs Prozessstart (Prozessstart-Aufgabe). Diese sind für eingehende Nachrichten gedacht, was in der Grafik durch das Symbol für ein Nachrichten-Startereignis links oben im Aufgabensymbol angedeutet wird. Aufgaben dieses Typs dürfen keine ankommenden Sequenzflüsse haben und sie müssen – natürlich – zur Instanziierung fähig sein.

Durch eine Aufgabe des Typs Prozessstart


Abbildung 15.3-10: Prozessstart-Aufgabe

Es kommt relativ oft vor, dass ein Geschäftsprozess aufgrund von Ereignissen gestartet wird, die "von außen" kommen. Typisches Beispiel ist ein Auftragseingang, der auf unterschiedlichen Medien erfolgen kann. Wird eine der Varianten realisiert, startet die Auftragsbearbeitung. Um diese Semantik zu erfassen, mussten die BPMN-Autoren ein eigenes Gateway schaffen, das verknüpfende ereignisbasierte Exclusive Gateway für den Prozessstart.

Verknüpfendes ereignisbasiertes Exclusive Gateway für den Prozessstart

Auch folgende Semantikvariante kommt vor: Mehrere Ereignisse müssen eintreten, damit ein Prozess startet. Hierfür wird das verknüpfende ereignisbasierte Parallel Gateway für den Prozessstart genommen. Diese Variante ist in [Staud 2017, Abschnitt 11.5] beschrieben.

Verknüpfendes ereignisbasierte Parallel Gateway für den Prozessstart

Start von Subprozessen


Semantik sucht Syntax

 

Semantik:

Ein Subprozess soll, angestoßen vom Sequenzfluss, gestartet werden.

Ein Subprozess soll aufgrund von Ereignissen, die "von außen" stammen, gestartet werden.

Passende Syntax:

Startereignisse für die "oberste Ebene"

Startereignisse für Ereignissubprozesse, unterbrechend oder nicht


Subprozesse können durch einen ankommenden Sequenzfluss gestartet werden oder durch Ereignisse. Erstgenannte werden genauso behandelt, wie im obigen Abschnitt für Prozesse beschrieben. Zweitgenannte sind die Ereignisssubprozesse.

Die ganz allgemeine Semantik von Subprozessen ("zusammenhängende abgrenzbare Tätigkeitsfolgen") kann in der BPMN noch präzisiert werden:

  • Soll der Subprozess im Sequenzfluss eingebettet sein oder nicht
  • Soll er den aufrufenden Prozess unterbrechen oder nicht
  • Soll er auf dessen Daten zugreifen können oder nicht
  • Ist Verwendbarkeit an verschiedenen Stellen angedacht?

Betrachten wir die hier angebotenen Möglichkeiten.

(1) Subprozess im Sequenzfluss. Erlaubt die Semantik, dass der Subprozess einfach an einer bestimmten Stelle in den Sequenzfluss eingebunden wird, sind die "ganz normalen" Subprozesse die richtige Wahl.

Im Prozessmodell können diese entfaltet (sichtbar) oder verborgen eingefügt sein. Sie greifen auf die Daten des Prozesses zu, in den sie eingebettet sind, ihre Wiederverwendbarkeit ist dadurch eingeschränkt.

Der Start erfolgt einfach dadurch, dass der Sequenzfluss auf den Rand des Subprozesses stößt. Danach wird das Startereignis des Subprozesses aktiviert oder, falls kein Startereignis vorliegt, alle Aktivitäten, zu denen kein Sequenzfluss hinführt. Vgl. die Beispiele in [Staud 2017] in den Abschnitten 14.6 und 14.7, insbesondere die Abbildungen 14.6-5, 14.7-2, 14.7-5, 14.7-6, 14.7-7, 14.7-8, 14.7-9.

(2) Transaktionen


Semantik sucht Syntax

 

Semantik:

Ein Prozessabschnitt soll abgegrenzt und als Ganzes oder gar nicht realisiert werden.

Passende Syntax:

Transaktion


Der wesentliche Unterschied zu den Subprozessen oben besteht darin, dass eine Transaktion nach ihrem Start entweder ganz durchgeführt oder rückabgewickelt wird. Ein beliebtes Beispiel dafür ist eine Überweisung.

(3) Start von Ereignissubprozessen, unterbrechend

Mit dieser Variante werden Teilprozesse erfasst, die durch Ereignisse gestartet werden. Die dabei entstehenden Subprozesse werden Ereignissubprozesse genannt. Für einen solchen gilt:

  • Er wird durch Ereignisse gestartet, die Verbindung zum Elternprozess erfolgt also durch empfangende und abgebende Ereignisse.
  • Er unterbricht den aufrufenden Prozess.

Wesentlich ist, dass sich die Ereignisse nicht aus den Prozessdaten ergeben. Es können auch von "außen" kommende Ereignisse sein. Hier ein Beispiel:


Abbildung 15.3-11: Start eines Ereignissubprozesses mit Abbruch Elternprozess – Beispiel. Auszug aus [Staud 2017, Abbildung 14.3-1]

Enthaltene Elemente:

- Ereignissubprozess

- Fehler-Schlussereignis

- Fehler-Startereignis / Ereignissubprozess, unterbrechend

- Kompensations-Zwischenereignis / abgebend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Hier nimmt der Geschäftsprozess also folgenden Weg:

  • Falls der Fehler in der Aufgabe Belaste Kreditkarte auftritt, wird dies durch das abgebende Zwischenereignis Grenzlinie, unterbrechend im Ereignisraum bekannt gemacht.
  • Das Startereignis des Subprozesses Bearbeitung Buchungsfehler (Typ Ereignissubprozess, unterbrechend) empfängt dieses Fehlerereignis und startet den Subprozess. Außerdem wird der aufrufende Prozess unterbrochen. Letzteres wird durch die durchgezogene Linie beim Fehler-Startereignis ausgedrückt.

Wie in [Staud 2017, Abbildung 12.1-1] zu sehen ist, können für diese Aufgabe ("unterbrechender" Start eines Ereignissubprozesses) folgende Ereignistypen zur Verfügung stehen: Nachricht, Fehler, Zeitgeber, Eskalation, Signal, Kompensation, Bedingung, Mehrfach und Parallel Mehrfach.

(4) Start von Ereignissubprozessen, nicht unterbrechend

Der Unterschied zum obigen Fall ist, dass hier der aufrufende Prozess (Elternprozess) nach Start des Subprozesses nicht abgebrochen wird, sondern weiter seinen Gang geht.

Im Prozess von [Staud 2017, Abbildung 14.3-1] müssen die beschafften Kreditkarteninformationen (Aktivität links oben) u.U. aktualisiert werden. Dies löst eine (in der Grafik nicht ausgewiesene) Nachricht aus, die dann im Ereignisraum vorliegt. Sie wird dann vom Nachrichten-Startereignis (Typ Ereignissubprozess, nicht unterbrechend) des Ereignissubprozesses Aktualisierung Kreditkarteninformationen empfangen. Dieser Nachrichteneingang löst dann den Ereignissubprozess aus. Dies soll nicht unterbrechend sein, was grafisch durch die gestrichelte Randlinie des Startereignisses angedeutet wird.


Abbildung 15.3-12: Start eines Ereignissubprozesses ohne Abbruch Elternprozess – Beispiel. [Auszug aus Abbildung 14.3-1]

Enthaltene Elemente:

- Ereignissubprozess

- Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend

- Schlussereignis

Insgesamt können folgende Ereignistypen hier als Startereignisse dienen: Nachricht, Zeitgeber, Eskalation, Signal, Bedingung, Mehrfach und Parallel Mehrfach.

(5) Wiederverwendbare Subprozesse


Semantik sucht Syntax

 

Semantik:

Ein (meist kleiner) Geschäftsprozesses soll abgegrenzt und an vielen Stellen im Prozessgeschehen eingesetzt werden. Er soll außerdem unabhängig vom aufrufenden Prozess sein.

Passende Syntax:

Call Activity


Dieses Methodenelement (Call Activity, verborgen oder entfaltet) ist geeignet, falls der aufgerufene Prozess die Kontrolle übernimmt. Der Subprozess ist also unabhängig vom aufrufenden Prozess. Vgl. das Beispiel in [Staud 2017, Abbildung 14.5-1].

15.3.4 Wiederholung, Rückschleife


Semantik sucht Syntax

 

Semantik:

Ein Prozessabschnitt muss wiederholt werden, einmal oder mehrmals.

Passende Syntax:

"Rücksprung", Aktivität mit Schleifenmarkierung, Subprozess mit Kennzeichen Schleife.


Die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, spielt in Geschäftsprozessen eine wichtige Rolle. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen und Modellierungstheorien auf. Weil nach dem Rücksprung ein Abschnitt wiederholt wird, spricht man auch von einer Rückschleife. In der BPM liegen dafür folgende Varianten vor:

(1) Aufgabe mit Schleifenmarkierung (loop marker)

(2) Subprozess mit Kennzeichen Schleife

(3) Schleife im Prozess

Zu (1): Dies ist eher geeignet für Wiederholung "im Kleinen", im Rahmen einer Aufgabe. Z.B. "Maileingang abarbeiten".

Zu (2): Eher für längere Prozessabschnitte, solche, die typischerweise in einen Subprozess passen. Z.B. "Teilebeschaffung".

Zu (3): Für "echte" Rücksprünge im Geschäftsprozess. Wo also grafisch ausgewiesene Prozessabschnitte wiederholt werden. Dies sind dann prozessindividuelle Situationen, wo nicht der Abschnitt ausgelagert und evtl. an verschiedenen Stellen genutzt werden kann. Beispiele finden sich u.a. in Abbildung 10.5-3, 14.1-1, 14.7-1 und 14.7-7.

Alle hier angeführten Abbildungen stammen aus [Staud 2017].

In Abbildung 14.1-1 ("Buchausleihe") gibt es einen Rücksprung von Vorbestellung mitteilen über eine zweiwöchige Wartefrist zur Aufgabe "Ausleihstatus klären". Die Einbindung des Rücksprungs flussaufwärts geschieht ohne Gateway. Dies ist in der BPMN erlaubt, möglich ist dafür aber auch ein Exclusive Gateway.

In Abbildung 14.3-1 ("Flugbuchung") gibt es einen Rücksprung zu Kreditkarteninformation beschaffen. Er kommt von Belastung Kreditkarte über ein Fehlereignis und eine Kompensation für den Fall, dass noch nicht zu oft ein "Retry" versucht wurde. Ein weiterer Rücksprung kommt von einem Zwischenereignis Grenzlinie, unterbrechend zum gesamten Subprozess Buchung.

Ein ähnliches Muster ist das sich wiederholender (repetitiver) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt. Auch hierfür eignet sich diese syntaktische Struktur.

Muster repetitive Handlungen

15.3.5 Bedingungen


Semantik sucht Syntax

 

Semantik

Bedingungen müssen erfüllt sein, bevor es im Prozess weiter geht.

Passende Syntax:

Aufgabe mit den Ergebnissen "erfüllt" und "nicht erfüllt"

Mehrere Aufgaben mit nachfolgendem Parallel Gateway


Ein weiteres wichtiges Muster in Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Der einfachste Fall, dass nur eine einzige Bedingung erfüllt sein muss (oder dass man alle Prüfungen zu einer zusammengefasst hat), wird durch eine Aufgabe Prüfung und den zwei Ergebnissen erfüllt und nicht erfüllt modelliert. Z.B. bei den Bedingungen für die Genehmigung eines Urlaubsantrags, wo evtl. folgende Bedingungen erfüllt sein müssen:

  • es müssen noch genügend Urlaubstage vorhanden sein
  • die Geschäftslage muss die Abwesenheit erlauben
  • eine Vertretung für wichtige Fragen muss organisiert sein

Die Umsetzung kann auf unterschiedliche Weise erfolgen. Eine einfache Lösung besteht darin, alle Einzelentscheidungen in ein Exclusive Gateway zu packen mit den zwei möglichen Ergebnissen "genehmigt", "nicht genehmigt". Vgl. die folgende Abbildung.


Abbildung 15.3-13: Muster Bedingungen – aggregiert und vereinfacht

Enthaltene Elemente (Auswahl) und Konzepte:

- Exclusive Gateway / datenbasiert und verzweigend

- Aggregation

Dies ist dann auch ein Beispiel für Aggregation in Geschäftsprozessen. Mehrere Handlungen, hier sogar Einzelentscheidungen, werden in eine Aufgabe gepackt. Die dadurch entstehenden Einschränkungen bestehen darin, dass auf Einzelhandlungen (Teilentscheidungen) nicht eingegangen werden kann.

Eine detailliertere Modellierung sieht so aus, dass jede Teilprüfung einzeln angelegt wird. Diese müssen dann durch ein Parallel Gateway verknüpft und als Teilaufgaben gestartet werden. Jede der Teilentscheidungen kann dann negativ oder positiv ausfallen, was durch jeweils ein Exclusive Gateway modelliert wird. Die "positiven Sequenzflüsse" werden dann mit einem Parallel Gateway verknüpft, danach folgt die Funktion für das positive Gesamtergebnis. Das Parallel Gateway erzwingt, dass es zum positiven Gesamtergebnis nur kommt, wenn alle Teilprüfungen positiv ausgefallen sind. Durch ein Inclusive Gateway können dann die übrigen Fälle, wo ja mindestens eine Prüfung negativ ausfiel, dargestellt werden. Vgl. die folgende Abbildung.

Auch zu dieser Lösung passt das Token-Konzept der BPMN-Autoren. Das Parallel Gateway vor Urlaub genehmigen wird nur überwunden, falls alle "positiven" Token ankommen. Das Inclusive Gateway vor Urlaubsantrag ablehnen benötigt nur mindestens einen Token, um ein Token weiterzusenden. So trifft diese Syntax tatsächlich die gewünschte Semantik.


Abbildung 15.3-14: Muster Bedingungen für den Fortgang – am Beispiel Urlaubsantrag

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verzweigend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

- Inclusive Gateway, verknüpfend

Diese Art der Modellierung erlaubt, bei den negativen Fällen weitere Handlungen zu berücksichtigen, um dann evtl. doch noch zu einem positiven Gesamtergebnis zu kommen.

Ist die Prozesssituation so, dass es für jede Kombination der Einzelprüfungen eine bestimmte Vorgehensweise gibt, dann kann dies syntaktisch so ausgedrückt werden: Nach jeder Entscheidung folgen die möglichen alternativen Ergebnisse. Bei jedem Ergebnis einer Aufgabe wird ein Parallel Gateway platziert, von dem Sequenzflüsse zu jedem Ergebnis der anderen Aufgaben führen. Vor die Aufgaben, die zu den Kombinationen passen, muss ebenfalls ein Parallel Gateway platziert werden. Die dort angekommenen Sequenzflüsse spiegeln die Semantik: Jeweils ein Ergebnis bei jeder Aufgabe. Diese Lösung beruht also auf der "syntaktischen " Eigenschaft der Parallel Gateways, dass es bei Verschmelzungen nur weiter geht, falls alle Token ankommen und bei Verzweigungen, dass alle Token "losgeschickt" werden.

Die folgende Abbildung zeigt dazu ein Beispiel aus dem in Abschnitt 14.6 vorgestellten Geschäftsprozess. Dort wurde diese Situation mit Hilfe eines Complex Gateway modelliert. Die Prozessbeschreibung (leicht verändert gegenüber Abschnitt 14.6, um die Kombinatorikstärker zu betonen):

Danach folgt – weiterhin durch den Vertriebsingenieur – die Prüfung, ob die Angebotslegungsfrist (ALF) realisiert werden kann. Parallel hierzu wird die für die Projektabwicklung notwendige Ingenieurgruppe auf ihre Auslastung hin überprüft. Ist die Kapazität vorhanden, die Angebotsfrist aber zu knapp, wird um Fristverlängerung nachgefragt. Wird diese nicht gewährt, erfolgt eine Absage. Ist absehbar, dass benötigte Ingenieurfachkräfte schon für längere Zeit aufgrund laufender Projekte ausgelastet sind, wird um Verschiebung gebeten.

Dies wird wie folgt modelliert: Die Prüfung der Angebotslegungsfrist kann zu zwei Ergebnissen führen: "ausreichend / nicht ausreichend". Genauso die Prüfung der Kapazität der Ingenieurgruppe: "Ingenieurkapazität reicht / reicht nicht". Die kombinierten insgesamt vier möglichen Ergebnisse werden nun bezüglich ihrer Konsequenzen im Text oben wie folgt beschreiben:

  • Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess, die Anfrage wird angenommen.
  • Ist die Kapazität der Ingenieurgruppe nicht ausreichend und die Angebotslegungsfrist (ALF) realisierbar, wird um Verschiebung gebeten.
  • Ist die ALF nicht realisierbar und sind Ingenieurkapazitäten vorhanden, wird um eine Fristverlängerung gebeten.
  • Ist die Kapazität der Ingenieurgruppe nicht ausreichend und die ALF nicht realisierbar, erfolgt eine Absage.

Diese Semantik kann, wie beschrieben, durch den Einsatz von Parallel Gateways umgesetzt werden. Vgl. die folgende Abbildung.


Abbildung 15.3-15: Muster Bedingungen

Enthaltene Elemente (Auswahl) und Muster:

- Exclusive Gateway / datenbasiert und verzweigend

- Muster Kombinatorik

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Vgl. für eine ausführlichere Darstellung [Staud 2014, Abschnitt 6.6].

15.3.6 Zeitaspekte

Zeitpunkte

Das folgende Muster in Geschäftsprozessen betrifft Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat. Beispiele:

  • Die Gehälter werden immer am letzten Tag des Monats überwiesen.
  • Zahlungen erfolgen immer am letzten Tag der Zahlungsfrist.
  • Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten.

Dies wird durch empfangende Zeitgeber-Zwischenereignisse modelliert. Zum einen im normalen Sequenzfluss (empfangend) oder auf der Grenzlinie von Aktivitäten.

Zeitfenster


Semantik sucht Syntax

 

Semantik:

Teilaufgaben einer umfassenderen Aufgabe sollen gemeinsam erledigt werden. Der Prozess wird erst fortgesetzt, wenn dies geschehen ist.

Passende Syntax:

Ein verzweigendes und ein verknüpfendes Parallel Gateway, zwischen denen die Aktivitäten eingefügt sind.


Wir führen hier das Beispiel von oben zu Teilaufgaben fort. Wird wie oben aufgeteilt und will man den Prozess erst fortsetzen, wenn alle (Teil-)Aufgaben erfüllt sind, dann muss man die Sequenzflüsse mit einem Parallel Gateway wieder verknüpfen. Damit entsteht ein Muster, das hier Zeitfenster genannt wird, weil zwischen dem ersten und dem zweiten Parallel Gateway Aufgaben angeführt sind, die im selben Zeitraum erledigt werden müssen, damit es im Prozess weitergeht. Mit dem ersten Gateway werden die Teilaufgaben angestoßen und erst wenn alle realisiert sind, geht es über das zweite Gateway im Geschäftsprozess weiter.


Abbildung 15.3-16: Muster Zeitfenster

Enthaltene Elemente (Auswahl) und Muster:

- Muster Zeitfenster

- Nachrichten-Zwischenereignis

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Dies ist keine Parallelität im wortwörtlichen Sinn, sondern nur ein gemeinsames erledigt werden und es sind auch keine zeitlichen Fixierungen (maximal 2 Tage, …) vorhanden. Eine solche Semantik müsste auf andere Weise umgesetzt werden.

Warten, Zeitraum

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet. Dies kann in der BPMN durch ein empfangendes Zeitgeber-Zwischenereignis modelliert werden. Der Sequenzfluss hält dann an und wird erst fortgesetzt, wenn die beim Ereignis formulierte zeitliche Bedingung erfüllt ist. Das folgende Prozessfragment zeigt ein Beispiel.


Abbildung 15.3-17: Muster Warten – Bewerberantwort.
Quelle: Auszug aus Abbildung 14.1-1.

Enthaltene Elemente (Auswahl) und Muster:

- Dienst-Aufgabe

- Empfänger-Aufgabe

- Exclusive Gateway / datenbasiert und verzweigend

- Exclusive Gateway / ereignisbasiert

- Muster Rücksprung

- Nachrichten-Zwischenereignis / empfangend

- Zeitgeber-Zwischenereignis

15.4 Muster mit EPKs

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 6 von

Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014.

Alle hier angegebenen Verweise (auf Abbildungen, Textstellen) beziehen sich auf dieses Buch, NICHT auf diesen Text. Hinweise zu Bezugsmöglichkeiten der Bücher finden sich auf www.staud.info.

----------

Beschäftigt man sich einige Zeit mit Geschäftsprozessen, merkt man, dass bestimmte Ablaufsituationen immer wieder auftreten. Zum Beispiel Entscheidungssituationen oder die Notwendigkeit, mehrere Tätigkeiten gleichzeitig anstoßen zu müssen. In diesem Kapitel wollen wir von solchen Mustern in Geschäftsprozessen ausgehen und ihre Umsetzung in EPK-Strukturen betrachten. Wir wechseln also die Perspektive, weg von einer syntaxgesteuerten, hin zu einer von der Semantik ausgehenden Betrachtungsweise.

Perspektivenwechsel

Dies ist durchaus sinnvoll, weil in der Praxis ja zuerst die realen Geschäftsprozesse mit ihren Mustern da sind und für diese dann Modellstrukturen bzw. -fragmente gefunden werden müssen. Diese Situationen müssen dann bewältigt werden, Semantik sucht also passende Syntax. Dies ist auch für die meisten dieser Muster möglich. Folgende werden hier betrachtet:

Semantik sucht (halbwegs) passende Syntax

  • Entscheidungsfindung
  • Teilaufgaben
  • Tätigkeiten starten
  • Zeitfenster
  • Zeitpunkte
  • Bedingungen
  • Kombinatorik
  • Warten
  • Wiederholung
  • Repetitive Handlungen

15.4.1 Entscheidungsfindung

Das am häufigsten auftretende Muster in Geschäftsprozessen und Ereignisgesteuerten Prozessketten ist die Entscheidungsfindung, das Fällen einer Entscheidung bezüglich alternativer Möglichkeiten. Es ist sehr elementar und deshalb in den Syntaxmustern des vorigen Kapitels direkt präsent (Ereignisverknüpfung, erzeugte Ereignisse, XODER). Die nachfolgende Abbildung zeigt ein Beispiel.

Entscheidung 1
Genau ein Ergebnis


Abbildung 15.4-1: Entscheidungsfindung in EPKs – Genau ein Ergebnis

Die Semantik der Entscheidungsfindung wird also in der EPK durch eine Funktion, einen nachfolgenden XODER-Operator und alternative Ereignisse (hier auch Ergebnisereignisse genannt) dargestellt.

Entsprechendes gilt für Entscheidungen, die Teilmengen von Ergebnissen zulassen. Hier kann die Semantik so beschrieben werden: Bei der Entscheidungsfindung kommt es zu mindestens einer Tätigkeit aus einer Menge von Tätigkeiten. Modelliert wird dies durch eine Funktion, den ODER-Operator und eine Menge von Ereignissen, die alle zu Funktionen führen und von denen mindestens eines eintreten muss. Vgl. hierzu auch das direkt passende Basismuster Ereignisverknüpfung / Erzeugte Ereignisse / ODER. Die folgende Abbildung zeigt ein Beispiel. In der Funktion Prüfen, welche Aktion kommt es zu mindestens einer der durch die Ereignisse ausgedrückten Tätigkeiten.

Entscheidung 2
Mindestens ein Ergebnis


Abbildung 15.4-2: Entscheidungsfindung in EPKs – Mindestens eine Tätigkeit aus einer Menge von Tätigkeiten

Wenn wir Menschen Entscheidungen fällen, fassen wir oft mehrere (Teil-)Entscheidungen zusammen. Beispiele dazu finden sich bei der Thematik „ungenaue ODER-Modellierung und deren Lösung“. Auch im Beispiel der nachfolgenden Abbildung liegt eine solche Situation vor. Ware ist eingetroffen, die Wareneingangsprüfung findet statt. Im Rahmen dieser wird entschieden, ob außer der Annahme der Ware eine Aktion (Einlagern, Umverpacken, Qualitätskontrolle) notwendig ist und welche. Die linke Seite der folgenden Abbildung zeigt die syntaktisch korrekte Lösung. Zuerst muss die Prüfung „Aktion notwendig oder nicht“ modelliert werden, dann die, welche Aktion(en) konkret nötig sind.

Entscheidung 3

"Ein Ergebnis" und "mindestens ein Ergebnis" zusammen

Die rechte Seite der Abbildung zeigt die „syntaktische Kurzfassung“.Hier werden nach der Funktion Wareneingangsprüfung zwei Operatoren hintereinander platziert für die beiden Teilentscheidungen.

Korrekt vs. verkürzt

XODER und ODER kompakt


Abbildung 15.4-3: Entscheidungsfindung in EPKs – XODER und ODER kompakt

15.4.2 Teilaufgaben und Tätigkeiten starten

Teilaufgaben

Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen der Abschlusskontrolle eines Buchmanuskripts: Es muss die Seitenformatierung geprüft und korrigiert werden. Ebenso die Kopfzeilen. Außerdem müssen Index und Inhaltsverzeichnis neu erstellt werden.

Diese Semantik kann durch eine Funktion, einen nachfolgenden UND-Operator und eine Gruppe von verknüpften Ereignissen modelliert werden. Die Ereignisse geben die Teilaufgaben an. Die folgende Abbildung zeigt das oben angeführte Beispiel.

Funktion + nachfolgender UND-Operator


Abbildung 15.4-4: Muster Teilaufgaben und seine Umsetzung

Geht der Prozess weiter, müssen die einzelnen Kanten mit Funktionen und Ereignissen ausgebaut werden. Als erstes kämen die Funktionen, die durch die Ereignisse angestoßen werden. Ein eventuelles Zusammenführen der Kontrollflusszweige würde dann auch wieder mit dem UND-Operator erfolgen (vgl. zum Zusammenführen von Kontrollflusszweigen auch Abschnitt 7.2).

Tätigkeiten starten

Obige Prozessstruktur (Teilaufgaben) wird oft auch eher als das gleichzeitige Anwerfen mehrerer Tätigkeiten interpretiert, v.a. wenn die Tätigkeiten eigenständig sind. Dies kann dann wie folgt modelliert werden: Ein auslösendes Ereignis zeigt den Bedarf, dann folgen die durch UND verknüpften gleichzeitig zu startenden Tätigkeiten. Die folgende Abbildung zeigt das vorige Beispiel in dieser EPK-Struktur. Auch diese Lösung war bei den Syntaxmustern voll präsent (Funktionsverknüpfung / auslösendes Ereignis / UND), vgl. [Staud 2014, Abschnitt 5.4-1].

Ereignis stößt mehrere Funktionen an.

Geht der Prozess weiter, müssen die einzelnen Kanten mit Ereignissen und Funktionen ausgebaut werden. Als erstes kämen die Ergebnisereignisse der angegebenen Funktionen. Ein eventueller Zusammenschluss zu einem Kontrollflusszweig würde dann auch wieder mit dem UND-Operator erfolgen.

Weiterführung


Abbildung 15.4-5: Muster Tätigkeiten anstoßen und seine Umsetzung

Die beiden semantischen Muster sind also inhaltlich identisch, v.a. wenn man berücksichtigt, dass es ja in der Prozessmodellierung grundsätzlich immer die Möglichkeit gibt, mehrere Tätigkeiten zusammenzufassen, wodurch die erste obige Lösung immer möglich wird.

Zu beachten ist noch, dass weder die Semantik des Geschäftsprozesses, noch die Syntax der EPK ausdrücken, dass es sich um eine Parallelität im technischen Sinn handelt. Es geht immer nur um das gleichzeitige Realisieren der Teilaufgaben (erste Lösung) bzw. um das gleichzeitige Anstoßen.

Keine Parallelität

15.4.3 Zeitfenster

Oftmals liegt in Geschäftsprozessen das folgende Muster vor: Mehrere Tätigkeiten werden angestoßen (wie im vorigen Abschnitt gezeigt) und müssen alle erledigt sein, bevor der Geschäftsprozess weiter geht. Es wird also sozusagen ein Zeitfenster aufgemacht für die Erledigung dieser Aufgaben.

Zeitfenster – „auf und zu“

Dies wird in EPKs dadurch ausgedrückt, dass die durch UND aufgesplitteten Kontrollflusszweige später wieder durch ein UND verknüpft werden. Damit bleiben die gestarteten Kontrollflusszweige nach der Abarbeitung vor dem zweiten UND stehen, bis alle ankommen. Erst dann geht es über den zweiten UND-Operator weiter. Diese Syntax trifft weitgehend die gewünschte Prozesssemantik.

Semantik findet Syntax

Das Zeitfenster ist in der Prozessmodellierung üblicherweise nicht absolut, es gibt weder einen irgendwie gesetzten fixen Startpunkt bzw. Schlusspunkt, noch wird die maximale Länge des Zeitfensters fixiert. Man könnte es aber natürlich einbauen, z.B. indem man ein Ereignis einfügt, das den maximalen Zeitrahmen erfasst und für den Fall des Überschreitens alternative Handlungen anstößt.

Die folgende Abbildung zeigt ein einfaches Zeitfenster mit anschließenden Handlungen. Zusätzlich wurde sozusagen eine pragmatische Komponenteder Prozessmodellierung umgesetzt: Im einfachen sequentiellen Teil nach dem Zeitfenster wurden die Ereignisse weggelassen. Dies wird in einigen Unternehmen so gehandhabt, um die EPKs kleiner und übersichtlicher zu halten. Es ist bei einfachen Abfolgen ohne Verzweigungen auch ohne weiteres möglich.

Gestaltungsregel:
Weglassen der Ereignisse in der einfachen sequentiellen Abfolge.


Abbildung 15.4-6: Zeitfenster zwischen zwei UND-Operatoren

Wie schon im vorigen Abschnitt angemerkt, sollte die Semantik hier im Zeitfenster keine bestimmte Reihenfolge der Tätigkeiten verlangen, die Syntax der EPK drückt dies auch nicht aus. Sie ist modelltechnisch belanglos. Es gilt aber, dass es erst über den zweiten UND-Operator weitergeht, wenn alle Tätigkeiten erledigt sind.

Erst weiter nach dem zweiten UND, wenn "alles erledigt" ist.

15.4.4 Zeitpunkte

Das folgende Muster in Geschäftsprozessen betrifft Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat. Beispiele:

  • Die Gehälter werden immer am letzten Tag des Monats überwiesen
  • Zahlungen erfolgen immer am letzten Tag der Zahlungsfrist
  • Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten

Dieses Muster wird in Ereignisgesteuerten Prozessketten realisiert, indem das zeitliche Ereignis mit einem UND-Operator in den Kontrollflusszweig eingebunden wird. Die folgende Abbildung zeigt ein Beispiel. Ein weiteres findet sich in Abbildung 8.3-2.

Muster Zeitpunkte


Abbildung 15.4-7: Zeitpunkte in den Kontrollfluss einbauen

Mit dieser syntaktischen Struktur können auch Zeitspannen in den Kontrollfluss eingebaut werden. Z.B., dass man nach der Veröffentlichung einer Stellenanzeige vier Wochen wartet, bevor man die Bewerbungen sichtet.

Zeitspanne


Abbildung 15.4-8: Zeitpunkte in den Kontrollfluss einbauen

Abkürzungen:

PA: Personalabteilung

SchAbt: Schulungsabteilung

Zeitpunkte können auch als Startereignis eines Geschäftsprozesses gesetzt werden. Im folgenden Beispiel sollen an jedem Monatsende die Gehaltszahlungen gestartet werden. Hier spürt man deutlich die Vorstellung, dass die Geschäftsprozesse des Unternehmens natürlich in eine Umwelt eingebettet sind: zeitlich wie hier, aber auch informationell. Das folgende EPK-Fragment zeigt ein Beispiel.

Start-Zeitpunkte,
aus dem Ereignisraum der Organisation


Abbildung 15.4-9: Zeitpunkte in den Kontrollfluss einbauen

Oftmals sieht man diese Lösung auch in Prozessmodellen, die den Prozess recht programmnah modellieren, um die Programmierung vorzubereiten. Das folgende Fragment stammt von dem Beispiel aus [Staud 2014, Abschnitt 8.6]. Die Semantik ist einfach: An allen Tagen, an denen eine Fälligkeitsprüfung durchgeführt werden soll, erfolgt diese um 5.00 Uhr morgens.

Die passende EPK-Syntax besteht aus zwei entsprechenden Ereignissen

  • (Es ist) 5.00 Uhr morgens
  • Fälligkeiten sind zu prüfen

die durch UND verknüpft sind. Durch diese Syntax ist gesichert, dass der Prozess erst startet, wenn beide Ereignisse eingetreten sind. Beide Ereignisse sind Startereignissedes Geschäftsprozesses.


Abbildung 15.4-10: Zeitpunkte in den Kontrollfluss einbauen

Anmerkungen:

Muster: Start-Zeitpunkt mit zwei Startbedingungen.

Syntax: Zwei durch UND verknüpfte Startereignisse.

Wieder wird mithilfe des logischen UND dergestalt gesteuert, dass der Kontrollfluss stehen bleibt, bis der entsprechende Zeitpunkt erreicht oder das entsprechende Ereignis eingetreten ist.

Grundsätzlich geht es hier auch um das Warten (vgl. [Staud 2014, Abschnitt 6.7]), allerdings nicht auf eine externe Entscheidung, sondern auf einen Zeitpunkt. Das Eintreten eines bestimmten Zeitpunktes wird so zu einem externen Ereignis der Ereignisgesteuerten Prozesskette.

Warten

15.4.5 Bedingungen

Ein weiteres wichtiges Muster in realen Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Z.B. die, dass man erst dann den Urlaubsantrag stellen darf, wenn man geprüft hat …

Semantik: Bedingungen für Fortgang

  • ob noch genügend Urlaubstage vorhanden sind,
  • ob die Geschäftslage die Abwesenheit erlaubt ("Abwesenheit möglich") und
  • ob eine Vertretung für wichtige Fragen organisiert ist.

Oder so, wie im einführenden Geschäftsprozess von Kapitel 4. Dort war es so, dass dem Kunden nur zugesagt wird, wenn die Prüfungen der Fertigungskapazitäten und des Lagerbestandes positiv ausfallen.

Die Umsetzung in eine EPK geschieht wie folgt: Die Bedingungen werden durch Ereignisse modelliert. Diese werden nachfolgend mit UND verknüpft, danach folgt die Funktion, für die die Bedingungen existieren. Dies können natürlich auch mehrere sein.

Syntax: „Bedingungs“-Ereignisse“ mit UND verknüpfen


Abbildung 15.4-11: Muster Bedingungen für den Fortgang – Urlaubsantrag

Die folgende Abbildung zeigt ein Beispiel, eingebettet in seine Prozessumgebung. Es verdeutlicht auch, dass für die zu verknüpfenden Ereignisse natürlich Funktionen existieren müssen. Das Beispiel stammt aus dem Geschäftsprozess von [Staud 2014, Kapitel 4] und wurde um eine dritte Bedingung erweitert. Die für dieses Muster wichtigen Abschnitte der EPK wurden mit dickerem Strich gezeichnet.


Abbildung 15.4-12: Muster Bedingungen für den Fortgang – Prüfungen

15.4.6 Kombinatorik

Betrachtet man obiges Beispiel genauer, könnte man fragen, was geschieht, wenn eine der Prüfungen negativ ausfällt. Z.B. die Kapazitätsprüfung. Wird dann um Aufschub gebeten? Oder die Lagerprüfung? Wird dann versucht, das Lager schnell aufzufüllen? Oder wenn beide Prüfungen negativ ausfallen? Gibt es dann gleich eine Absage? In [Staud 2014, Kapitel 4] wurde, weil es ein einführendes Kapitel ist, zu einer einfachen Lösung gegriffen. In Wirklichkeit müssten aber, wenn jede Prüfung zu zwei alternativen Ergebnissen führen kann, zwei mal zwei Kombinationen bedacht werden. Oder wenn drei Prüfungen mit z.B. 3, 4 und 2 möglichen Ergebnissen vorliegen, insgesamt 24 mögliche Ergebniskonstellationen. So will es die Kombinatorik.

Kombinatorische Explosion

Semantisch kann diese Situation wie folgt beschrieben werden: Mehrere Prüfungen müssen bezüglich des weiteren Fortgangs durchgeführt werden. Die Prüfungen führen zu alternativen Ergebnissen. Diese Ergebnisse bestimmen in Kombination den weiteren Fortgang des Geschäftsprozesses.

Die syntaktisch korrekte Umsetzung dieser Semantik wird am obigen Beispiel aus [Staud 2014, Kapitel 4] gezeigt, jetzt aber in voller Detailliertheit. Zuerst der Beginn dieses EPK-Fragments, vgl. die folgende Abbildung. Der Prozess startet durch das Eintreffen einer Anfrage. Diese stößt zwei Funktionen an (Muster Teilaufgaben). Jede soll (nur, aus Gründen der Übersichtlichkeit) genau zwei Ergebnisereignisse haben.


Abbildung 15.4-13: Kombinatorik 1 – Ergebnisse von Prüfungen

So weit so gut. Nun soll es so sein, dass für jede Kombination der Ergebnisse dieser zwei Prüfungen ein spezieller Fortgang des Geschäftsprozesses in der Semantik vorliegt:

Volle Kombinatorik

  • Kapazität reicht nicht / Lagerbestand ausreichend: Mittelfristige Kapazität prüfen.
  • Kapazität reicht nicht / Lagerbestand reicht nicht: Um 1 Woche Fristverlängerung bitten.
  • Kapazität reicht / Lagerbestand ausreichend: Anfrage annehmen.
  • Kapazität reicht / Lagerbestand reicht nicht: Anfrage ablehnen.

Dies ist in der Realität nicht immer so. Da kommt es vor, dass mehrere Kombinationen zu ein und demselben weiteren Fortgang führen. Hier wollen wir aber mal die „volle Kombinatorik“ betrachten.

Die folgende Abbildung (reduziert auf die Elemente, die verknüpft werden müssen) zeigt den ersten Lösungsschritt. Eine zentrale Rolle spielt hier der UND-Operator. Nach jedem Ereignis wird einer eingefügt (wodurch zwei Kanten weggehen können, zu jedem Ergebnis der anderen Prüfung eine) und auch vor jeder nachfolgenden Funktion. Dieser UND-Operator erlaubt ganz im Sinne von [Staud 2014, Abschnitt 6.5] (Muster Bedingungen) den Einbau von Bedingungen.

Nun zum Beispiel. Die folgende Abbildung zeigt den ersten Schritt. Die beiden Ereignisse Kapazität reicht und Lagerbestand reicht nicht werden mit der Funktion mit der Bitte um Fristverlängerung verknüpft. Diese wird nur angestoßen, falls „beide Kanten ankommen“, denn nur dann geht es über den UND-Operator weiter.


Abbildung 15.4-14: Kombinatorik 2 – Bitte um Fristverlängerung

Nun wollen wir den sofortigen positiven Fortgang einbauen. Dazu wird vom Ereignis Kapazität reicht und von Lagerbestand ausreichend jeweils eine Kante zur Funktion Anfrage annehmen geführt.

Hier kann man nun bereits sehen, wie durch die UND-Operatoren vor den Funktionen die Semantik umgesetzt wird. Kommt bei einer Instanz des Geschäftsprozesses nur eine der beiden Kanten an, wird die entsprechende Funktion nicht ausgelöst. Dagegen sind die UND-Operatoren nach den Ereignissen syntaktisch motiviert, da ja beim Weiterführen mehrerer Kanten (wie auch beim Zusammenführen) immer ein Operator benutzt werden muss. Da hier beide Kanten „starten“ sollen, ist der UND-Operator der richtige.

Semantik durch UND-Operator


Abbildung 15.4-15: Kombinatorik 3 – Anfrage annehmen

In der folgenden Abbildung sind alle restlichen Kanten eingefügt, außerdem wird auch die Prozessumgebung gezeigt. Von jedem der Ergebnisereignisse gehen so viele Kanten weg, wie die andere Funktion Ergebnisse aufweist. Hier also je zwei. Die Kanten müssen so eingefügt werden, dass sie der gewünschten Semantik entsprechen.


Abbildung 15.4-16: Kombinatorik 4 – Alle Ergebnisse

Abkürzungen:

GL: Geschäftsleitung

VU: Vertriebsingenieur

Ein weiteres ausführliches inhaltliches Beispiel hierzu findet sich im Geschäftsprozess Zoo in [Staud 2014, Abschnitt 8.4].

15.4.7 Warten

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet.

Zeitaspekt Warten

Für die korrekte Modellierung solcher Wartesituationen in Ereignisgesteuerten Prozessketten gibt es grundsätzlich zwei Lösungen, die mit der folgenden Beispielsituation erläutert werden sollen:

  • Eine Entscheidung ist gefallen, hier die für eine/n bestimmte Bewerber/in auf eine Stelle.
  • Der weitere Verlauf hängt nun (aus Unternehmenssicht) von der Entscheidung eines Externen ab (ob sie/er die Stelle annimmt oder nicht).

Es muss also gewartet werden. Eine Lösung zeigt die folgende Abbildung. Nach dem Ereignis Bewerber/in ist benachrichtigt, das den Abschluss der eigentlichen Bewerberauswahl signalisiert, wird eine Wartefunktion eingefügt. Dies trägt auch der Tatsache Rechnung, dass Warten durchaus eine Tätigkeit ist. Die auf diese Funktion folgenden Ereignisse deuten die möglichen Beendigungen des Wartens an. Entweder durch eine Zu- oder eine Absage. Je nachdem werden dann die entsprechenden Funktionen angestoßen.

Warten auf Zu- oder Absage


Abbildung 15.4-17: Muster Warten – Bewerberantwort

Hier wird auf ein externes Ereignis gewartet. Dies kommt durchaus vor, da Geschäftsprozesse natürlicherweise auch auf diese Weise mit der Umwelt in Kontakt treten. Dabei wird also der weitere Verlauf des Geschäftsprozesses durch das Handeln Externer bestimmt.

Externes Ereignis

Neben dieser sozusagen konventionellen Lösung findet man auch die in der nächsten Abbildung angegebene. Bei ihr wird auf die Wartefunktion verzichtet. Unmittelbar nach dem Benachrichtigungsereignis folgt ein logischer Operator UND. Er soll signalisieren, dass der Kontrollfluss in beide Richtungen weitergeht, obwohl semantisch nur eine der beiden Alternativen eintreten kann. Vor den beiden weiteren UND-Operatoren bleibt der Kontrollfluss dann – sozusagen – stehen. Tritt nun eines der beiden Ereignisse ein, ist auf der entsprechenden Seite das UND erfüllt und die nächste Funktion wird angestoßen.

Das logische UND als Schalter


Abbildung 15.4-18: Warten mit dem logischen UND

15.4.8 Wiederholung, Rücksprünge

Wie im „wirklichen Leben“ spielt die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, auch in Geschäftsprozessen eine wichtige Rolle. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen und Ereignisgesteuerten Prozessketten auf. Weil nach dem Rücksprung ein Abschnitt wiederholt wird, spricht man bezüglich der EPK auch von einer Rückschleife.

Wiederholung von Geschäftsprozess­abschnitten durch Sprung nach flussaufwärts

Im folgenden Beispiel geht es um die Endphase einer Bucherstellung. Wenn der Text inhaltlich fertig ist folgt die Abschlusskontrolle. Dabei wird die Seitenformatierung und die Kopfzeilengestaltung geprüft. Außerdem wird der Index neu erstellt. Sobald diese drei Tätigkeiten durchgeführt sind, wird das finale PDF-Dokument für den Verlag erstellt. Dieses wird dann geprüft. Oft werden da dann Fehler bemerkt. Falls dies der Fall ist, wird der vorangegangene Prozessabschnitt wiederholt. Dies so oft, bis die abschließende Prüfung des jeweils neu erstellten PDF-Dokuments zufriedenstellend ausfällt.

Beispiel Texterstellung

Die folgende erweiterte Ereignisgesteuerte Prozesskette zeigt, wie dieser Vorgang modelliert wird. Die Rückschleife beginnt immer aus einem Ereignis heraus, dem Ereignis, das den Bedarf an der Wiederholung eines Abschnittes aufzeigt. Im Beispiel der folgenden Abbildung ist dies die Tatsache, dass das PDF-Dokument Fehler zeigt. Die Rückschleife wird dann grafisch durch eine nach flussaufwärts führende Pfeillinie dargestellt, die mithilfe eines XODER-Operators vor einer Funktion wieder in den Kontrollfluss zurückgeführt wird. Diese Funktion muss natürlich die sein, ab der die Wiederholung des Geschäftsprozesses beginnt. Es ist wichtig, dass dieser Wiedereinstieg vor einer Funktion erfolgt, da nur damit die syntaktische Grundregel Ereignis und Funktion lösen sich ab eingehalten wird.

Gestaltung der Rückschleife

Der XODER-Operator hat hier bei der Einbindung der Rücksprungkante eine etwas andere innere Struktur als sonst, wo er zwei oder mehr sich ausschließende Alternativen erfasst. Hier wird im ersten Durchgang auf jeden Fall der Kontrollfluss „von oben her“ durchlaufen. Zum seitlichen „Einstieg“ kommt es nur im Falle eines Rücksprungs.


Rücksprung 1 ohne Kontrolle

Abbildung 15.4-19: Wiederholung eines Geschäftsprozessabschnitts

In diesem Beispiel wurde darauf verzichtet, die Zahl der Rücksprünge zu kontrollieren. Dies ist auch sinnvoll, weil man hier – ganz pragmatisch – einen letztendlich positiven Ausgang annehmen kann.

Endlos?
Pragmatik!

Natürlich gibt es aber auch Situationen in Geschäftsprozessen, wo man nur eine bestimmte Anzahl von Wiederholungen zulassen möchte. Die folgende Abbildung zeigt eine EPK mit diesem Muster. In diesem Geschäftsprozess wird durch den Vertrieb eine Kalkulation durchgeführt. Ist diese erledigt, führt der Projektleiter eine Prüfung auf Korrektheit durch. Stellt er Fehler fest, wird die Kalkulation durch den Vertrieb überarbeitet. Danach kommt es wieder zur Prüfung durch den Projektleiter. Die Überarbeitung wird maximal zwei Mal angefordert. Ist dann die Kalkulation immer noch nicht korrekt, führt der Projektleiter selbst die Fertigstellung der Kalkulation durch.

Kontrollierte Wiederholung

Dies kann in einer Ereignisgesteuerten Prozesskette wie folgt gelöst werden: Nach dem inhaltlichen Teil der Wiederholung wird eine Funktion eingebaut, in der geprüft wird, wie oft schon zurückgegeben wurde. Wurde noch nicht oder erst ein Mal zurückgegeben, geht es in die Rückschleife, ansonsten in die Fortsetzung des Geschäftsprozesses mit der Funktion Fertigstellung der Kalkulation durch den Projektleiter. Vgl. die nächste Abbildung. Manchmal sieht man auch die Lösung, dass ein Zähler für die Rückgaben als Informationsobjekt angelegt wird. Dann wird bei der Entscheidung, ob nochmals zurückgegeben wird, dieser Zähler gelesen und entsprechend gehandelt.

Prüfung der Anzahl an Wiederholungen

 


Rücksprung 2 mit Kontrolle der Anzahl der Wiederholungen

Abbildung 15.4-20: Mehrmalige Wiederholung eines Geschäftsprozessabschnitts mit Kontrolle

Oftmals sieht man auch die folgende Lösung für das Muster Wiederholung. Dabei wird wiederum nach dem Scheitern der Prüfung auf Korrektheit die Überarbeitung der Kalkulation durch den Vertrieb angehängt – allerdings nur einmal. Damit ist in der EPK die u.U. auch mehrmalige Wiederholmöglichkeit angedeutet, auf die Ausgestaltung einer tieferen Semantik („wie oft kann wiederholt werden?“) wird aber verzichtet.

Rücksprung 3:
Wiederholung ohne Rückschleife

Syntaxhinweis

Die folgende EPK enthält zwei Leerzweige bei XODER-Verzweigungen. Dies ist durchaus möglich, muss allerdings bei der Abfolge von Funktionen und Ereignissen beachtet werden. Hier entstanden sie dadurch, dass die beiden Ergebnisereignisse in Kalkulation ist fertig zusammengefasst wurden.


Abbildung 15.4-21: Einmalige Wiederholung eines Geschäftsprozessabschnitts

15.4.9 Repetitive Handlungen

Ein anderes ganz ähnliches Muster wie im vorigen Abschnitt ist ebenfalls oft in Geschäftsprozessen anzutreffen: Sich mehrfach wiederholende (repetitive) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt.

Muster: Sich mehrfach wiederholende Handlungen.

Dies könnte wie in der folgenden Abbildung gezeigt durch eine Rückschleife modelliert werden. Die Punkte in der Mitte deuten weitere Funktionen an, die eventuell getätigt werden müssen, bevor geprüft wird, ob eine weitere Befragung durchzuführen ist. Ist noch eine weitere durchzuführen, kommt es zum Rücksprung und damit zu einer Schleifenkonstruktion. Wie im vorigen Abschnitt gilt auch hier, dass der Rücksprung von einem Ereignis aus startet und vor einer Funktion flussaufwärts wieder in den Kontrollfluss eingebunden wird.

Syntax: Rücksprung, Rückschleife


Abbildung 15.4-22: Wiederholung wegen „Abarbeitung“

Kapseln in eine Funktion

Eine solche Schleife kann, wenn kein so hoher Detaillierungsgrad erforderlich ist, auch in eine Funktion gekapselt werden . Dazu wird die sich wiederholende Tätigkeit in eine Funktion gepackt. Vgl. die folgende Abbildung. Damit werden Ereignisgesteuerte Prozessketten natürlich wesentlich einfacher, allerdings geht Aussagekraft verloren. Die Entscheidung, welches Aggregationsniveauman wählt, hängt einfach vom Ziel der Modellierung ab.

Aggregieren
durch Kapseln


Abbildung 15.4-23: Verzicht auf Rückschleife durch Kapselung

15.4.10 xxx Überwachen, Kontrollieren

xxxHier auf EPKs zuschneiden, oben grundsätzlich

xxx„Überwachen“ oder „prüfen“ sind ständige Themen in realen Geschäftsprozessen und ihrem Geschäftsprozessmanagement. Sie sollten daher im Geschäftsprozessmanagement bedacht werden und, insbesondere bei der Erfassung und Modellierung von Geschäftsprozessen, umfassend repräsentoert werden.

Aufeinanderwirken von Funktionen, Einwirken

Geht es um eine einfache Tätigkeit (z.B. Erstellung von irgendwelchen Unterlagen), deren Erledigung kontrolliert werden soll, ist die Lösung einfach. Wie in den xxxAbschnitten 5.1 und 5.2 gezeigt kann dies durch Rücksprünge bei Misserfolg bzw. durch die Wiederholung einzelner Geschäftsprozessabschnitte modelliert werden.

Kontrolle nach Erledigung

Geht es um komplexere oder auch nur längere Arbeitsabläufe, die wirklich überwacht werden müssen, wo also der Arbeitsfortschritt kontrolliert werden soll, ist die Situation schwieriger.

Ein Beispiel dafür findet sich in Abschnitt 6.1 (Abbildungen 6.1-5 und 6.1-6). Dort lag folgende Situation vor (Originalbeschreibung):

Die Arbeitsvorbereitung erstellt die Angebotsunterlagen, was bei den Produkten dieses Unternehmens ein längerer und anspruchsvoller Vorgang ist. Der Verkauf überprüft regelmäßig den Fortgang der Arbeiten in der Arbeitsvorbereitung und erstellt im Falle eines Verzuges eine sog. Mahnliste, mit der sozusagen der Verzug dokumentiert wird.

In der ursprünglichen EPK-Beschreibung des Geschäftsprozesses war die Erstellung der Angebotsunterlagen in eine Funktion gekapselt. Damit ergab sich ein EPK-Abschnitt wie in der folgenden Abbildung.

Kapselung


Abbildung 15.4-24: Gekapselte Tätigkeiten

Wird aber auf diese Weise modelliert, werden also kontinuierlich ablaufende Tätigkeiten in einer Funktion zusammengefasst, kann auf die einzelnen Abschnitte im Rahmen der linear/sequenziellen EPK-Methode nicht mehr zugegriffen werden.

Problem durch Kapselung

Als Notlösung bleibt dann lediglich der Rückgriff auf den Ereignisraum, d.h. auf die Verknüpfung von Geschäftsprozessen bzw. Ereignisgesteuerten Prozessketten über Ereignisse. Konkret bedeutet dies, dass, wie ebenfalls in Abschnitt 6.1 gezeigt (vgl. Abbildung 6.1.6), ein eigener Geschäftsprozess (eine eigene Ereignisgesteuerte Prozesskette) angesetzt wird mit einem Startereignis, das den Verstoß angibt. In Abbildung 6.1-6 z.B. Verzug ist aufgetreten. Überwachung wird somit über ein eventuelles negatives Ergebnis der Überwachung modelliert.

Verknüpfung über Ereignisse

Ist eine direktere Verknüpfung der Tätigkeit mit ihrer Überwachung gewollt, bleibt nichts anderes übrig, als die Tätigkeit aus einer Funktion herauszunehmen und in einzelne Teilaufgaben zu zerlegen, (sie – u.U. künstlich – zu sequenzialisieren), nach denen dann jeweils kontrolliert wird. Diese Lösung ergibt sich aus der linearen und sequenziellen Grundstruktur von Ereignisgesteuerten Prozessketten. Vgl. dazu das Beispiel in Abbildung 6.1-5. Dann kann durch Abfragen nach jedem Abschnitt die Überwachung und Erstellung der Mahnliste auf einfache Weise modelliert werden.

Künstliche Sequenzialisierung

Auf diese Weise wird die Ereignisgesteuerte Prozesskette allerdings kompliziert. Außerdem wird u.U. die Semantik nicht voll getroffen, da ein eigentlich kontinuierlicher Ablauf künstlich unterteilt wurde.

Besser wäre es, hier die EPK-Notation um ein Element zu ergänzen, das ganz allgemein die Zuordnung einer Funktion zu gekapselten oder kontinuierlichen Arbeitsschritten erlaubt. Damit könnten zwei Funktionen direkt in Beziehung gesetzt werden. Ergeben sich aus der Beziehung Konsequenzen, könnte dies durch entsprechende Ereignisse modelliert werden.

Erweiterung der Notation

Ein Vorschlag für die im obigen Beispiel vorliegende Situation findet sich in Abbildung 7.1-2. Eine „Funktion“ überwacht die andere und reagiert auf bestimmte Ereignisse. Auf diese Weise ist eine Verknüpfung der Prozesse ohne komplizierte Konstruktion möglich. Allerdings erweitert dies die Notation um ein Element.

Diese Konstruktion könnte nicht nur zur Überwachung bzw. Kontrolle, sondern ganz allgemein zur Beobachtung anderer Tätigkeiten und eventuellen Reaktionen benutzt werden. Allerdings nur, wenn es sich auf der einen Seite tatsächlich um mehrere oder kontinuierliche Arbeitsschritte handelt und wenn auf der anderen Seite wirklich ein weiterer Akteur (ein Mensch oder aber – auch das ist denkbar – eine Maschine bzw. ein Programm) mit im Spiel ist.

Beobachten und Reagieren


Abbildung 15.4-25: Neues Element für die Überwachung kontinuierlicher/gekapselter Arbeitsschritte

 

15.5 Basismuster in Geschäftsprozessen mit EPKs

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 5 von

Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014.

----------

15.5.1 Mögliche Anordnungen

In diesem Abschnitt wird betrachtet, wie bei der Verknüpfung durch Operatoren die Ereignisse (E) und Funktionen (F) aufeinander folgen können. Dazu wird erstens für jeden der drei Operatoren unterschieden, ob Ereignisse oder Funktionen verknüpft werden und zweitens, ob die Ereignisse im jeweiligen EPK-Fragment vorangehen oder nachfolgen. Dies ergibt dann die in der folgenden Abbildung angegebenen zwölf Varianten. Diese Abbildung zeigt die möglichen Verknüpfungen abstrahiert, d.h. mit Ereignisbenennungen wie E1, E2, … und Funktionsbenennungen wie F1, F2, … Außerdem sind bei Verknüpfungen immer nur zwei Ereignisse bzw. Funktionen angegeben. Inhaltliche Beispielsfragmente folgen in den anschließenden Abschnitten.

Alle möglichen Anordnungen von E und F im Kontrollfluss

Um die Übersichtlichkeit zu erhöhen wird der Kontrollfluss immer von oben nach unten angeordnet, sodass die eine Seite des Operatorkreises oben und die andere unten ist.

Für die Anordnung, bei der zuerst Ereignisse und dann Funktionen folgen, soll von auslösenden Ereignissen(aE) gesprochen werden. Vgl. die Zeilen 1 und 3 in der folgenden Abbildung. Die Bedeutung dieses Begriffs wird unten bei den Beispielen klarer, wenn deutlich wird, dass bei einer bestimmten Anordnung tatsächlich die Ereignisse so etwas wie Auslöser für die nachfolgenden Funktionen sind.

Definition: Auslösende Ereignisse

Im umgekehrten Fall, wenn Ereignisse nach Funktionen folgen, wird von erzeugten Ereignissen(eE) gesprochen. Dabei entstehen sozusagen die Ereignisse aus der Ausführung der Funktion heraus. Vgl. die Zeilen 2 und 4 in der folgenden Abbildung. Auch hier werden die entsprechenden Beispiele unten zur Verdeutlichung beitragen.

Definition: Erzeugte Ereignisse

Die durchgestrichenen Verknüpfungen sind nicht zulässig. Dazu unten mehr.

Hinweis: Die folgenden EPK-Fragmente sind typischerweise Auszüge aus größeren EPKs. Die Pfeilspitzen oben und am Ende deuten die Verbindungen zum "Umfeld" an.


Abbildung 15.5-1: Mögliche Verknüpfungen von Ereignissen und Funktionen durch Operatoren

Im Folgenden werden nun, entlang der obigen Tabelle, von oben nach unten und von links nach rechts, die einzelnen Anordnungen nacheinander mit mindestens einem inhaltlich aussagekräftigen Beispiel vorgestellt.

15.5.2 Ereignisverknüpfung mit auslösenden Ereignissen

Ereignisverknüpfung mit auslösenden Ereignissen bedeutet immer, dass Ereignisse so etwas wie Bedingungen für die nachfolgend auszuführende Funktion (es können auch mehrere sein) sind.

Ereignisse als Bedingungen

UND

Werden auslösende Ereignisse mit dem UND-Operator verknüpft, müssen alle eingetreten sein, bevor der Kontrollfluss über den Operator weiter geht. In einer solchen Situation haben die Ereignisse den Charakter von gemeinsamen Bedingungen für das Starten der Funktion: Die Funktion wird erst gestartet, wenn die Ereignisse eingetreten sind.

Gemeinsame Bedingungen

Im folgenden Beispiel geht es um eine Situation nach einem Auftragseingang. Hier wird mit der Produktionsplanung erst begonnen, wenn Kapazitäten frei sind und die notwendigen Rohstoffe usw. vorhanden sind.


Abbildung 15.5-2: Ereignisverknüpfung / Auslösende Ereignisse / UND

Auf diese Weise lassen sich Regeln und Bestimmungen, die den jeweiligen Prozess betreffen, mit einbeziehen.

XODER

Bei der Verknüpfung von auslösenden Ereignissen durch ein exklusives ODER (vgl. die folgende Abbildung) handelt es sich um alternative Ereignisse für die gilt, dass genau eines eintreten muss, damit es im Kontrollfluss weiter geht, damit also die nachfolgende Funktion gestartet wird. Die auslösenden Ereignisse stellen hier somit Bedingungen dar, von denen genau eine eintreten muss (erfüllt sein muss) damit der Geschäftsprozess weiterschreiten kann.

Alternative Bedingungen

Im folgenden Beispiel geht es um Bestellungen. Angenommen wird, dass diese entweder per Brief, aus dem Portal, aus dem Laden, per Mail oder per Fax eingetroffen sind. Dies wird durch Startereignisse modelliert, die natürlich alternativ sind, was der Logik des exklusiven ODER entspricht. Somit gilt: Die Auftragsbearbeitung wird nur gestartet, falls eines der Ereignisse zuvor eingetreten ist.


Abbildung 15.5-3: Ereignisverknüpfung / Auslösende Ereignisse / XODER

ODER

Die Ereignisverknüpfung mit dem logischen ODER bedeutet, dass mindestens eines der parallel angeordneten Ereignisse eintreten muss, damit die nachfolgende Funktion gestartet werden kann. Wie die Formulierung aber bereits sagt, können auch mehrere oder alle Ereignisse eintreten.

Mindestens ein Ereignis muss eintreten

Im folgenden Beispiel geht es um die Frage, ob Eltern eine Ermäßigung gewährt werden kann, wenn ihr Kind eine Kindertagesstätte (KITA) besucht. Die Kriterien dafür wurden als Ereignisse formuliert. Die Möglichkeit einer Ermäßigung liegt vor …

  • … wenn bereits ein Geschwister in der KITA ist (Geschwisterermäßigung).
  • … das Einkommen der Erziehungsberechtigten unter 1000,-- Euro liegt.
  • … der / die Erziehungsberechtigte alleinerziehend ist.
  • … der / die Erziehungsberechtigte Sozialhilfeempfänger ist.

Wenn mindestens eines der Ereignisse eintritt, wenn also mindestens ein Kriterium erfüllt ist, dann kann die Ermäßigung gegeben werden. Somit kann der ODER-Operator eingesetzt werden.

Dieses Beispiel ist fiktiv. Das tatsächliche Regelwerk dürfte deutlich komplizierter sein.


Abbildung 15.5-4: Ereignisverknüpfung / Auslösende Ereignisse / ODER – 1. Beispiel

Bei diesem Beispiel stellt sich die Frage, warum überhaupt die verschiedenen Ereignisse (Kriterien) angegeben werden. Genügt nicht auch einfach ein Ereignis Ermäßigungsgrund liegt vor nach einer Funktion, die dieses prüft? Dies wäre ohne weiteres möglich. Sehr oft möchte man aber die verschiedenen Möglichkeiten in der Ereignisgesteuerten Prozesskette dokumentieren. Dann ist die obige Ausgestaltung sinnvoll.

Mögliche Aggregation (Zusammenfassung)

Das folgende zweite Beispiel beschreibt eine ähnliche Situation bei einem Versicherungsunternehmen. Die Meldung über einen Schadensfall kann durch den Versicherten, den Geschädigten, die Servicestelle oder in seltenen Fällen auch durch die Polizei erfolgen. Sie kann aber auch durch mehrere dieser „Melder“ erfolgen, z.B. durch Versicherer und Geschädigten, usw. Damit ist auch hier das logische Oder der richtige Operator.


Abbildung 15.5-5: Ereignisverknüpfung / Auslösende Ereignisse / ODER – 2. Beispiel

Auch hier ist damit das ODER erfüllt. Für den konkreten Geschäftsprozess bedeutet dies ganz praktisch, dass eine eventuelle „Mehrfachmeldung“ (derselbe Schadensfall wird mehrfach gemeldet) abgefangen werden muss.

Wie oben schon angemerkt, können durch ODER verknüpfte Ereignisse immer auch zusammengefasst werden, wie im folgenden Beispiel gezeigt. Spaltet man jedoch auf, will man die möglichen Alternativen und die Kombinationen dokumentieren. Vielleicht wird ja auch diese Information an einer anderen Stelle der Ereignisgesteuerten Prozesskette benötigt. So z.B. bei dem Fragment zur Gewährung der Beitragsermäßigung. Obwohl für den weiteren Ablauf nicht unbedingt nötig, könnte es in bestimmten Fällen sehr nützlich sein zu wissen, welche Kriterien der Grund für die Ermäßigung waren. Allerdings müsste diese Informationsspeicherung dann noch mithilfe von Informationsobjekten hinzu modelliert werden.

Aggregieren oder Detaillieren

15.5.3 Ereignisverknüpfung mit erzeugten Ereignissen

In dieser Anordnung signalisieren die Ereignisse die Durchführung einer Funktion (oder mehrerer), sie geben Teilaufgaben oder mögliche Ergebnisse an.

UND

Beim logischen UND bedeuten die nachfolgenden Ereignisse Teilaufgaben, die sich aus der Abarbeitung der Funktion ergeben. Es sind die Teilergebnisse, die für so wichtig erachtet werden, dass sie in der Modellierung auftauchen sollen. Formal gesprochen: alle nachfolgenden Ereignisse müssen eintreten (alle Teilaufgaben müssen erledigt sein), dann geht es im Geschäftsprozess weiter.

Teilaufgaben mit UND

Das folgende inhaltliche Beispiel stammt aus dem Krankenhausbereich und beschäftigt sich mit dem Vorgang der Entlassung von Patienten nach einem stationären Aufenthalt. Vereinfacht wurde angenommen, dass hierzu das Bezahlen der Telefonrechnung, das Führen eines Schlussgesprächs und die Erstellung der endgültigen Abrechnung gehört.


Abbildung 15.5-6: Ereignisverknüpfung / Erzeugte Ereignisse / UND –
1. Beispiel

Der UND-Operator bedeutet hier nicht Parallelität (der Teilaufgaben), sondern nur, dass diese erledigt sein müssen, bevor die nächste Funktion gestartet werden kann. Teilaufgaben können auch auf andere Art modelliert werden. Auch das Anstoßen mehrerer Funktionen nach einem Ereignis, wie im einführenden Beispiel gezeigt, kann als Anstoßen von Teilaufgaben interpretiert werden. Siehe zu dieser ganzen Thematik Teilaufgaben Abschnitt 6.2.

Keine Parallelität im technischen Sinne

XODER

Beim exklusiven ODER bedeutet die Ereignisverknüpfung mit erzeugten Ereignissen, dass die Ereignisse die möglichen alternativen Ergebnisse der vorangehenden Funktion festhalten. Das heißt, genau eines der Ereignisse muss eintreten, dann es im Kontrollfluss weiter geht.

Festhalten alternativer Ergebnisse

Das folgende Beispiel beschreibt – in einem Verlag – den Ablauf, der zum Versenden der Bücher führt. Nachdem eine Buchsendung versandfertig gemacht wurde, wird sie mit einer der Transportgesellschaften versandt. Natürlich nur mit einer, da die Sendung ja nur einmal versandt werden kann. Die Ereignisse geben hier also mögliche alternative Ergebnisse an.


Abbildung 15.5-7: Ereignisverknüpfung / Erzeugte Ereignisse / XODER

Ganz ähnlich die folgende Situation. Hier sei die Semantik so, dass bei Eingang eines Auftrags geprüft wird, ob dieselbe Anlage, eine ähnliche oder keine der gewünschten Art früher schon mal hergestellt wurde. Ziel ist, auf vorhandene Produktionsunterlagen zugreifen zu können. Zusammen mit der Semantikfestlegung ergibt sich eine Semantik, die mit einem XODER-Operator modelliert werden kann.

Festlegung:
Nur das "beste" der Ereignisse wird jeweils berücksichtigt


Abbildung 15.5-8: Ereignisverknüpfung / Erzeugte Ereignisse / XODER

ODER

Die Syntax des ODER-Operators sagt in der Anordnung dieses Abschnitts, dass mindestens ein Ereignis eintreten muss, damit es im Kon­trollfluss weitergeht. Mit anderen Worten: Eine Teilmenge der Ereignisse muss eintreten – allerdings nicht die leere Menge.

In semantischer Hinsicht bedeutet dies, wie immer bei ausgelösten Ereignissen, dass die Ereignisse die Erledigung von Aufgaben signalisieren. Hier aber nicht von Teilaufgaben (wie beim UND) oder von alternativen Aufgaben/Ergebnissen (wie beim exklusiven ODER), sondern von Aufgaben/Ergebnissen, die einzeln oder auch zusammen (in beliebiger Kombination) anfallen können.

Erledigung von Aufgaben

Das folgende EPK-Fragment zeigt ein Beispiel. Bei einer Kundenabfrage wird geklärt, welche Leistungen ein Kunde in Anspruch nimmt. Da er bereits Kunde ist, liegt mindestens ein Ergebnis vor. Die Abfrage kann also zu einer beliebigen Anzahl von Ergebnissen führen. Diese Situation kann durch eine Funktion mit nachfolgendem ODER-Operator und entsprechenden Ergebnisereignissen modelliert werden, wie es die folgende Abbildung zeigt.


Abbildung 15.5-9: Ereignisverknüpfung / erzeugte Ereignisse / ODER

Bei erzeugten Ereignissen, die durch einen ODER-Operator verknüpft sind, stellt sich oft die Frage, ob die durch ein ODER verknüpften Ereignisse unabhängig voneinander sind, d.h. ob wirklich jedes unabhängig von den anderen in irgendeiner Kombination auftreten kann? Das kann man sich auch im obigen Beispiel vorstellen:

Unabhängigkeit

  • Für Online-Banking braucht man entweder ein Girokonto oder ein Depot.
  • Für eine EC-Karte braucht es ein Girokonto
  • Ein Darlehen gibt es nur, wenn der Darlehensnehmer ein Konto hat.

Solche Bezüge gibt es u.U. viele. Mit dem ODER-Operator verzichtet man auf deren Klärung. Sollte diese innere Strukturierung ebenfalls modelliert werden, würde die EPK etwas komplizierter.

Das inhaltliche Beispiel der folgenden Abbildung zeigt eine ähnliche Situation. In diesem Unternehmen kann die Wareneingangsprüfung dazu führen, dass die Ware eingelagert werden muss, dass eine Umverpackung notwendig ist, dass die Qualitätskontrolle bemüht werden muss oder dass mehrere dieser Tätigkeiten in beliebiger Kombination anfallen. So weit so gut, dies entspricht der „reinen“ Logik des ODER-Operators. Nimmt man zu diesen möglichen Prüfungsergebnissen dasjenige hinzu, das signalisiert, dass keine der anderen Aktionen nötig ist (Keine Aktion notwendig), entsteht die in der folgenden Abbildung angegebene Ereignisgesteuerte Prozesskette. Dies liegt durchaus nahe und wird auch oft so gemacht. Damit ist aber der ODER-Operator nicht mehr in vollem Umfang erfüllt, denn das Ereignis „Keine Aktion notwendig“ kann nicht in Kombination mit den anderen auftreten. Die Ereignisse sind nicht mehr unabhängig voneinander.

Vgl. zur Problematik des ODER-Operators und zu den Fehlerquellen [Staud 2014, Abschnitt 7.3.]

Diese Syntax widerspricht also dem ODER-Operator, zumindest in der semantischen Auslegung, das heißt, wenn der Bedeutungsgehalt der Ereignisse (die Semantik) berücksichtigt wird. Rein syntaktisch, wenn es nur darum geht, dass mindestens ein Ereignis eintreten muss, ist das ODER allerdings auch hier erfüllt.

Syntax vs.
Semantik


Abbildung 15.5-10: Ereignisverknüpfung / erzeugte Ereignisse / ODER
Wareneingangsprüfung 1

Die Tatsache, dass mit ODER verknüpfte Ereignisse eigentlich beliebig kombinierbar sein sollten, dies aber in der praktischen Modellierung nicht immer gemacht wird (werden kann), kann mit Unabhängigkeit bzw. Nichtunabhängigkeit von Ereignissen voneinander bezeichnet werden.

Eine Gruppe von mit ODER verknüpften Ereignissen ist unabhängig voneinander, wenn die Semantik zulässt, dass die Ereignisse in beliebiger Kombination auftreten können.

Definition

Wie man eine solche im strengen Sinn des Operators unrichtige Struktur zu einer korrekten macht, wird in [Staud 2014, Abschnitt 7.3] gezeigt.

15.5.4 Funktionsverknüpfung mit auslösenden Ereignissen

Funktionsverknüpfung mit auslösenden Ereignissen bedeutet immer, dass das Eintreten eines Ereignisses nachfolgende Funktionen startet. Entweder genau eine von mehreren (XODER) (?), mehrere zusammen (UND) oder mindestens eine (ODER) (?). Die Fragezeichen deuten Probleme an, die es hier zu lösen gibt.

Ereignis startet Funktionen

UND

Dass ein Ereignis gleich eine von mehreren Funktionen startet, gilt in der Prozessmodellierung als unerwünscht, weil ein Ereignis keine Tätigkeit ist, in der entschieden wird, welche Funktion gestartet werden soll. Dies wird auch das Thema der nächsten beiden Abschnitte (XODER, ODER) sein. Beim UND gibt es allerdings keine Probleme. Ein Ereignis kann zum parallelen Start zweier oder mehrerer Funktionen führen [Anmerkung] .

Wohl bekannt:
ein Ereignis führt zu mehreren zu erledigenden Aufgaben.

Das folgende Beispiel möge dies verdeutlichen. Ist in einer Spedition ein Transportauftrag erteilt, muss der Fahrer benachrichtigt, die Auftragsbestätigung geschrieben und es müssen die Transportpapiere erstellt werden. Hier kann mit Sicherheit von einer Reihenfolge der Tätigkeiten ausgegangen werden, auf deren Modellierung aber bei Verwendung des UND verzichtet wird.

Keine Reihenfolge
bzw.
Verzicht auf Modellierung der Reihenfolge


Abbildung 15.5-11: Funktionsverknüpfung / auslösendes Ereignis / UND

Das folgende EPK-Fragment zeigt ein zweites Beispiel. Ein Text wird erstellt (zum Beispiel für ein Fachbuch), irgendwann ist er fertig und die Schlussarbeiten stehen an. Das Startereignis ist hier also eine Erkenntnis im Kopf des Autors. Dann ist einiges zu tun.

Die Ereignisgesteuerte Prozesskette zählt die Aufgaben auf. In diesen Aufgaben mit ihren Ergebnissen steckt sogar eine spezielle Semantik: Eine Reihenfolge (Indexerstellung nach Formatierung, usw.), evtl. auch Wiederholung, denn die Neuerstellung der Formatierung führt u.U. dazu, dass das bisherige Inhaltsverzeichnis nicht mehr stimmt und die Erstellung desselbigen wiederholt werden muss. Wählt man die in der folgenden Abbildung gewählte Syntax, verzichtet man auf diese speziellen Semantikaspekte.

Pragmatik. Verzicht auf zu viel Detaillierung.


Abbildung 15.5-12: Funktionsverknüpfung / auslösendes Ereignis / UND –
2. Beispiel

Anmerkungen:

Semantik: Ereignis stößt mehrere fest bestimmte Tätigkeiten an.

Syntax: Ereignis mit nachfolgendem UND-Operator und zu erledigenden Funktionen.

Pragmatik: Verzicht auf die Modellierung eventueller Zusammenhänge zwischen den (Funktionen).

Wie immer beim logischen UND bedeutet die parallele Anordnung nicht, dass die Aufgaben tatsächlich parallel erledigt werden (schon gar nicht im technischen Sinn) , sondern nur, dass sie zusammen gestartet werden.

XODER – verboten

Die folgende Anordnung ist eine verbotene. Dabei geht es um Ereignisse, denen ein XODER-Operator nachfolgt, die also eine von mehreren mit dem exklusiven ODER verknüpften Funktionen auslösen.

Fehlende Entscheidungs­funktion

Betrachten wir das folgende Beispiel eines Auftragseingangs. Dem Ereignis des Auftragseingangs folgt entweder die Auftragsannahme, die Ablehnung oder die Notwendigkeit Rückfragen zu klären. Modelliert man dies so wie in der folgenden Abbildung übt die EPK aufgrund ihrer Schlichtheit eine gewisse Faszination aus. Schon kurzes Nachdenken macht aber deutlich, dass hier ein wichtiger Abschnitt des realen Geschäftsprozesses nicht modelliert wurde: die Entscheidungsfindung, die Analyse der Machbarkeit, usw. Die EPK „springt“ sozusagen gleich von dem Ereignis zur Ausführung einer der Funktionen.


XODER – verboten

Abbildung 15.5-13: Funktionsverknüpfung / auslösendes Ereignis/ XODER ohne Entscheidungsfunktion

Das ist der Grund, weshalb eine solche Struktur – sozusagen – verboten ist. Tritt sie auf, muss sie um eine Funktion ergänzt werden, die den Entscheidungsprozess modelliert und um Ereignisse, mit denen die möglichen Ergebnisse des Entscheidungsprozesses ausgedrückt werden. Obiger Ausschnitt ist dann wie in der folgenden Abbildung zu modellieren.


Richtige Lösung mit Entscheidungs-
funktion

Abbildung 15.5-14: Funktionsverknüpfung mit vorangestellten Ereignissen/ auslösendem Ereignis / XODER – mit Entscheidungsfunktion

Mit der Entscheidungsfunktion (hier: Machbarkeitsprüfung) kommen dann auch die Ereignisse in die EPK, mit denen die möglichen Ergebnisse des Entscheidungsprozesses angedeutet werden. Diese Ergebnisereignisse erhöhen dann auch die Aussagekraft der EPK.

ODER – verboten

Die folgende ODER-Verknüpfung ist wieder eine verbotene, ganz wie oben bei den durch XODER ausgelösten Funktionen. Das Beispiel zeigt die Situation bei einer Neuanlage eines Girokontos. Ist diese erfolgt, kann der Kunde verschiedene Leistungen anfordern, von EC-Karte bis Online-Banking. Modelliert man es so wie in der folgenden Abbildung, fehlt allerdings die Entscheidungsfunktion, die festlegt, welche Ereignisse bei einer konkreten Instanz des Geschäftsprozesses eintreten, bzw. welche Aufgaben zu tätigen sind.

Fehlende Entscheidungs-
funktion


Abbildung 15.5-15: Ereignisverknüpfung / auslösendes Ereignis/ ODER – ohne Entscheidungsfunktion

Auch hier fehlt wieder der Entscheidungsprozess in Form einer Funktion. In der nächsten Abbildung ist er zusammen mit den erforderlichen Ereignissen eingefügt. Die Entscheidungsfunktion kann hier mit Entscheidung im Gespräch mit dem Kunden umschrieben werden. Eine vertiefte Darstellung dieser Problematik, „Unschärfen bei der ODER-Modellierung“ findet sich in [Staud 2014, Abschnitt 7.3].

Richtige Lösung mit Entscheidungs-
funktion

Eine Zusammenfassung aller wichtigen Syntaxregeln findet sich in [Staud 2014, Kapitel 9]. Die Regel zu den verbotenen Strukturen wird wegen ihrer großen Bedeutung auch gleich hier angeführt.

Syntaxregel

Nach einem Ereignis (oder nach mehreren) darf kein ODER- oder XODER-Operator für die dann ja notwendigerweise nachfolgenden Funktionen folgen. Mit anderen Worten: Auslösende Ereignisse mit XODER und ODER sind nicht erlaubt.

Im folgenden Beispiel wurden, damit sie nicht in Vergessenheit geraten, auch mal wieder Organisationseinheiten und Informationsobjekte angefügt.


Abbildung 15.5-16: Ereignisverknüpfung mit vorangestellten Ereignissen/ auslösendem Ereignis / ODER – mit Entscheidungsfunktion

Anmerkungen:

Semantik: Ereignis löst Teilmenge von Tätigkeiten aus.

Syntax: Ereignis, ODER-Entscheidungsfunktion mit Teilmengen von Ergebnisereignissen, dann für jedes Ergebnisereignis eine Funktion.

Abkürzungen:

DiKu: Digitale Kundenakte

AFKK: Antragsformular Kreditkarte

AFDP: Antragsformular Depot

AFOB: Antragsformular Online-Banking

15.5.5 Funktionsverknüpfung mit erzeugten Ereignissen

Von mehreren Funktionen erzeugte (nachfolgende) Ereignisse entstehen, wenn die Beendigung mehrerer Funktionen durch ein- und dasselbe Ereignis angegeben werden kann. Dabei geht es immer um das Zusammenführen von Kanten, die von Funktionen kommen. Im Falle des XODER waren dies alternativ auszuführende, im Falle des UND parallel zu erledigende und im Falle des ODER Funktionen, von denen mindestens eine getätigt werden musste.

Erledigung von Funktionen

UND

Das logische UND bedeutet in dieser Anordnung, dass mehrere Funktionen getätigt werden müssen, bevor das nachfolgende Ereignis eintritt. Die Funktionen müssen also „gleichzeitig“ erledigt werden, bevor es mit dem Geschäftsprozess weitergeht. Ob diese Tätigkeiten in der Realität wirklich auch parallel erledigt werden, ist modelltechnisch ohne Bedeutung. Sie können genauso gut auch hintereinander abgearbeitet werden.

Mehrere Funktionen erledigen, dann gemeinsames Ergebnis

Im folgenden Beispiel stellen wir uns vor, dass in einem Unternehmen bei Neueinstellungen jeder Bewerber an einem Assessment Center teilnimmt, dass mit ihm oder ihr ein Gespräch geführt wird und dass die eingesandten Unterlagen ausgewertet werden. Erst danach geht es mit dem Auswahlprozess weiter.


Abbildung 15.5-17: Funktionsverknüpfung / erzeugtes Ereignis / UND

Anmerkungen:

Semantik: Mehrere Tätigkeiten sind durchgeführt, es geht im Geschäftsprozess einheitlich weiter.

Syntax: Mehrere Funktionen, Verknüpfung durch UND, nachfolgendes Ereignis.

Obiges Modell wird in der folgenden EPK noch etwas ausgebaut, um am Beispiel die Einbettung eines solchen EPK-Fragments in einen etwas größeren Zusammenhang aufzuzeigen. Der Geschäftsprozess startet durch den Wunsch, eine Stelle zu besetzen. Dies stößt eine Besprechung zur Vorgehensweise an, die von der Personalabteilung und der Fachabteilung getätigt wird und die den Stellenbesetzungsplan nutzt. Entschieden wird, ob die Stelle ausgeschrieben oder intern besetzt wird. Eine interne Besetzung läuft (hier) problemlos durch , für eine externe wird eine Bewerberakte angelegt und eine Ausschreibung durchgeführt, innerhalb derer dann die drei oben angeführten Aktivitäten

Stellenbesetzung – etwas umfangreicher

  • Gespräch mit Bewerber führen
  • Assessmentcenter durchführen
  • Bewerberunterlagen getätigt

durchgeführt werden. Die Ergebnisse werden in der Bewerberakte festgehalten. Anschließend wird auf der Basis der gewonnenen Daten eine Person durch die Fachabteilung ausgewählt und eingestellt.

Die folgende EPK zeigt die Umsetzung dieser Prozessbeschreibung in ein Modell. Neben der Einbettung des obigen Fragments zeigt das Beispiel auch ein Muster, das hier Zeitfenster genannt wird (vgl. für eine tiefere Betrachtung Abschnitt 6.3): Die drei Aktivitäten werden nach dem ersten UND-Operator gestartet und vor dem zweiten UND-Operator erledigt, erst dann geht es im Prozess weiter.

Muster Zeitfenster


Abbildung 15.5-18: Stellenbesetzung – Mögliche Einbettung des EPK-Fragments von [Staud 2014, Abb. 5.5-1]

Anmerkungen:

Muster: Zeitfenster

Syntaxregel: Zusammenführen Kontrollflüsse

Hier ist auch eine Syntaxregel umgesetzt, die das Zusammenführen von Kon­trollflusszweigen betrifft (vgl. [Staud 2014, Abschnitt 7.2]): Werden Kontrollflüsse durch einen Operator aufgesplittet und sollen sie weiter unten (flussabwärts) wieder zusammengeführt werden, so wird dafür derselbe Operator wie bei der Aufsplittung verwendet.

Syntaxregel Zusammenführen Kontrollflusszweige

XODER

Im Falle des XODER muss und darf hier nur eine einzige der verknüpften Funktionen eintreten, dann tritt das gemeinsame ausgelöste Ereignis ein. Es handelt sich also um Alternativen bzgl. der zu erledigenden Aufgabe, die aber alle zum selben Ergebnis führen. Dies ist eine Struktur, die in der Realität sehr oft vorkommt. Natürlich könnten statt einem einzelnen Ereignis auch mehrere folgen. Im folgenden Beispiel wird ein Versand durchgeführt. Er erfolgt hier entweder mit der einen oder der anderen Transportgesellschaft. Welche auch immer gewählt wurde, danach tritt das Ereignis Versand erfolgt ein.

Alternative Tätigkeiten mit einem Ergebnisereignis:


Abbildung 15.5-19: Funktionsverknüpfung / erzeugtes Ereignis / XODER

ODER

Ausgelöste (also nachfolgende) Ereignisse nach einem ODER bedeuten, dass mindestens eine der Funktionen durchgeführt werden muss, damit das Ereignis eintritt. Im folgenden Beispiel tritt das Ereignis Kalkulation und Angebot erstellt ein, wenn die davor stehenden Funktionen im Sinne des ODER („mindestens eine“) durchgeführt wurden.

Mindestens eine Funktion muss realisiert werden

Um dieses EPK-Fragment verstehen zu können wurden in der Abbildung die den Funktionen vorgestellten Ereignisse und Funktionen mit angegeben. Dies macht auch deutlich, wie es zu einer solchen Anordnung kommen kann.

Für alle EPK-Strukturen dieses Abschnitts gilt:

  • Es werden mehrere Kanten zusammengefasst. Dies geht nur mit einem Operator.
  • Es handelt sich um den abschließenden Teil eines Abschnitts, der mit einem zu Verzweigungen führenden Operator beginnt und bei dem mit demselben Operator die Verzweigung wieder aufgehoben wird.

Vgl. zu dieser Thematik auch [Staud 2014, Abschnitt 7.3]. Eine Einbettung dieses Fragments in einen größeren Kontext zeigt [Staud 2014, Abbildung 7.3-4].


Abbildung 15.5-20: Funktionsverknüpfung / erzeugtes Ereignis / ODER

Soweit die Betrachtung der im Kontrollfluss grundsätzlich möglichen Verknüpfungen zwischen Ereignissen und Funktionen. Die folgende Abbildung fasst die obigen Ergebnisse zusammen und zeigt alle Varianten in einer einzigen Abbildung. Eine vergrößerte Version davon findet sich auf www.staud.info.

Alle auf einmal


Abbildung 15.5-21: Mögliche Verknüpfungen von Ereignissen und Funktionen im Kontrollfluss – Gesamtübersicht

Die Bedeutungen der einzelnen Verknüpfungen sind in der folgenden Abbildung zusammengefasst. In ihr ist für alle 12 Varianten die jeweilige Rolle der Ereignisse angegeben.


Abbildung 15.5-22: Die Rolle der Ereignisse in den 12 Verknüpfungsvarianten

 

16 Referenzprozessmodelle

16.1 Einführung

Nach der Lektüre der ersten Kapitel liegt der Gedanke eigentlich nahe: Wenn Prozesse 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 Modelle oder als eine in prozessorientierter Software realisierte Lösung (vgl. die Abbildung unten). Dies ist inzwischen auf die eine oder andere Weise tatsächlich Realität:

  • Durch Ineinsichtnahme eines Referenzmodells mit Schwerpunkt auf Prozessarchitektur. 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 fundiert an die Arbeit gehen.
  • Durch Ineinsichtnahme eines Prozessmodells, in dem konkrete vorgedachte Prozesse enthalten sind. Dies erfolgt sinnvollerweise meist auch gleich mit Architekturfestlegungen.
  • Durch Kauf oder Miete (z.B. in der "Cloud") von Integrierter Prozessorientierter Software ("ERP-Software"). Dann sind die Geschäftsprozesse in der Software hinterlegt. Denn es gilt: Prozessorientierte Software beruht immer auf vorgedachten Prozessen und Prozessmodellen.

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äftsprozesse vom Softwarehaus bei einem bestimmten Unternehmen erhoben worden ("Individualsoftware") oder eine "für viele" (Standardsoftware). Dann sind die Geschäftsprozesse vom (Standard-)Softwarehaus so vorgedacht worden, dass sie auf viele Unternehmen passen.

Modellvorstellung

Dies sind in der Realität die wichtigsten "Referenzmodelle", da sie reale Prozessmodelle 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 optimierte 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 Architekturen mit wohlstrukturierten Problemen (vgl. Abschnitt 2.4). 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 Marketingkampagne). Wohlstrukturiert sind Aufgaben wie Projekteinrichtung, Projektstart, Mittelbereitstellung, Meetings durchführen, usw. Die eigentlichen Aufgaben (Strategiefindung, 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. Deshalb 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 Betriebswirtschaftliche 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 Geschäftsprozess gleich ein Stück weit automatisch abwickelt. Wie auch immer, sie beruht auf jeden Fall auf vorgedachten Geschäftsprozessen und ihren Modellen.

Ein anderer bedeutender und nicht-prozessorien­tierter Softwaretyp ist Standardsoftware, die nicht prozessorientiert ist. Sie wird auch funktionsorientierte Software genannt, weil sie einzelne Aufgaben (Funktionen) abdeckt. Wichtiges Beispiel hier sind die Office-Pakete.

Integriert meint hier, dass die Software vollkommen in die Gesamt-IT integriert ist. Dass es also zwischen ihr und der übrigen Software des Unternehmens keine schwer zu überwindenden Schnittstellen gibt. 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 modernen Softwareprodukten aber voraussetzen.

Die folgende Abbildung visualisiert diese Eigenschaften und zeigt auch noch weitere mögliche Softwareausprägungen.


Abbildung 16.1-1: Softwaretypen

Vgl. Abschnitt 17.3 für eine Kurzbeschreibung und [Staud 2006, Kapitel 3 in] für eine detaillierte Beschreibung dieses Softwaretyps.

16.2 Wertkette von Porter

Porter schlug eine Wahrnehmung der Geschäftsprozesse in einem typischen Industrieunternehmen vor, die durchschlagenden Erfolg hatte. Sie baut auf seinen Überlegungen 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ührenden unterstützt werden (Finanzwesen, Controlling, Personalwesen, usw.). Porter schlägt zwar nicht eine breite Palette von Geschäftsprozessen vor, aber er identifiziert zentrale Prozesse von besonderer Bedeutung und hat eine der Grundlagen für das Business Process Management gelegt.

Wertschöpfungskette

In der folgenden Abbildung ist die Wertschöpfungskette mit primären und sekundären Aktivitä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 16.2-1: Wertkette eines Unternehmens (nach [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. Hauptaufgabe der Eingangslogistik ist die flexible und pünktliche Versorgung der Produktion und die Sicherstellung der Qualität der Bezugsmaterialien.

Eingangslogistik

Mit Operationen sind Produktion, Fertigungs- bzw. Produktionswirtschaft gemeint. Aufgaben sind hier z.B. die mechanische Bearbeitung, die Montage, die chemisch-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.

Operationen

Ein zentraler Aspekt im Rahmen der Wertschöpfung sind Marketing und Vertrieb. Dazu zählt z.B. die Erschließung geeigneter Vertriebswege, um Zugang zum Endkunden im Markt zu schaffen. Daneben ist die Kommunikation des Produktnutzens relevant (z. B. durch Werbung), um die erforderliche Zahlungsbereitschaft bei der Kundengruppe zu wecken.

Marketing und Vertrieb

Die Ausgangslogistik (Distribution) hat zum Ziel, die zeitliche und räumliche Verfügbarkeit der Erzeugnisse und Leistungen für den Kunden sicherzustellen. Teilprozesse sind der Unterhalt/Betrieb von zentralen/dezentralen Distributionslägern, die Kommissionierung, der Transport und die Informationsverarbeitung. Die Ausgangslogistik ist relevant, da Produkte/Dienstleitungen (als Ergebnis der Operations) durch die Verfügbarkeit (Informations-, Orts- und Zeitnutzen) zur Bedürfnisbefriedigung beim Kunden beitragen.

Ausgangslogistik

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.

Kundendiensts

Die Beschaffung (Einkauf) ist darauf ausgerichtet, eine leistungsfähige Lieferantenbasis 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 Lieferantenbeziehung im Hinblick auf die gemeinsam verfolgten Ziele und die Durchsetzung günstiger Konditionen zu Lasten der Wertschöpfung vorgelagerter Stufen. Die Gestaltungsmöglichkeiten der Beschaffung sind je nach Fremdbezugsanteil und Stellung des Unternehmens im Beschaffungsmarkt (Einkaufsmacht) unterschiedlich. Insbesondere der Fremdbezug (Outsourcing) von Sachgütern und Dienstleistungen und die Verlagerung von Leistungsprozessen (Offshoring) in kostengünstige Wachstumsregionen hat die Relevanz der Beschaffung erhöht.

Beschaffung

Die Technologieentwicklung ist auf die Beherrschung und Verbesserung technischer 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.

Technologie

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 bereit. Wesentliche Bereiche sind z. B. das Rechnungswesen, das Planungs- und Managementsystem und Systeme der Informations- und Kommunikationstechnik. Komplexer strukturierte Großunternehmen haben im Bereich der Unternehmensinfrastruktur 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 zentral angeboten, an Dienstleister ausgelagert (Outsourcing) und dabei auch an kostengünstige Standorte verlagert (z. B. Callcenter). In diesem Zusammenhang spricht man auch von Shared Services und Business Process Outsourcing.

Infrastruktur

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 Wertschö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. Indirekte 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 Aktivitäten. Die Kosten für diese Qualitätssicherung werden in der Regel durch Einsparungen in den verbesserten Prozessen (z.B. verringerter Ausschuss, stärkere Anlagennutzung) kompensiert.

16.3 Das ARIS-Konzept

ARIS steht für Architektur integrierter Informationssysteme.

Das ARIS-Konzept ist eine Architekturempfehlung für die IT und ein Vorschlag für die Vorgehensweise bei der Gestaltung einer IT. Es wurde von Scheer schon in den 1970er-Jahren vorgestellt, hat aber bis heute seine Aussagekraft nicht verloren. Es ist in zahlreichen seiner Veröffentlichungen beschrieben (beispielhaft [Scheer 1997]). Wegen seiner großen Bedeutung – nicht nur in theoretischer sondern auch in praktischer Hinsicht – soll es hier kurz vorgestellt werden.

Das ARIS-Konzept ist prozesszentriert, d.h. es empfiehlt die Wahrnehmung der betrieblichen Realität als ein zielgerichtetes Miteinander von Geschäftsprozessen. Dies ist heute selbstverständlich, war es aber damals aber nicht. Gegenstand ist – wie oben schon angemerkt – die IT, genauer, deren Gestaltung.

Komponenten, Sichten

Folgende Komponenten, die er Sichten nennt, definiert Scheer in seinem Konzept:

  • Datensicht
  • Funktionssicht
  • Organisationssicht
  • Ressourcensicht
  • Steuerungssicht

Er nennt sie Sichten, weil ihr Gegenstand jeweils eine bestimmte Sicht auf die IT einer Organisation darstellt. Die Datensicht erfasst die Zustände und Ereignisse, die durch Daten repräsentiert werden. Gemeint sind die Daten der Datenbank, die mithilfe eines Datenmodells erstellt wurden. Das von Scheer hierfür vorgeschlagene Werkzeug sind ER-Modelle.

Datensicht

Mit Funktionssicht bezeichnet er die auszuführenden Funktionen und deren Zusammenhang. Hierzu gehört die Beschreibung der Funktion, die Aufzählung der einzelnen Teilfunktionen sowie die zwischen den Funktionen bestehenden Anordnungsbeziehungen. Erfasst werden sie z.B. durch Funktionsbäume.

Funktionssicht

Bearbeiter und Organisationseinheiten machen die Organisationssicht aus. Das Darstellungsmittel sind hier z.B. Organigramme. Eine moderne Sichtweise muss an dieser Stelle Nutzer von Software und die genutzten Anwendungsprogramme anführen, da heutzutage ja oft keine Benutzer mehr vorhanden sind.

Organisationssicht

Mit dem Begriff Ressourcensicht sind die Komponenten der Informationstechnik gemeint. Sie zielt somit auf die konkrete Hardware und Software.

Ressourcensicht

Den integrativen Aspekt betont wiederum die Steuerungssicht. Sie soll die Verbindung zwischen den anderen Sichten deutlich machen. Zentral ist hier die Geschäftstätigkeit, der letztendlich alle übrigen Ressourcen dienen. Man kann es auch so forumlieren: Die Analyse der Organisations-, Daten- und Ressoourcensicht muss von den Geschäftsprozessen ausgehend erfolgen.

Steuerungssicht

In der Leistungssicht, die in den ersten Jahren nicht ins Konzept integriert war, die Scheer später ergänzt hat, sind die unterschiedlichen Leistungsarten wie Sach-, Dienst- und Informationsleistungen zusammengefasst.

Leistungssicht

Insgesamt empfiehlt der Ansatz somit, neben der integrierten Betrachtung der Geschäftsprozesse auch den durch die Sichten spezifizierten. Diese entsprechen im Übrigen den überkommenen Vorgehensweisen, wo natürlich auch Datenstrukturen, Organisationsstrukturen, usw. analysiert wurden. Diese Komponenten ordnete er so an, wie es die folgende Abbildung zeigt, und stellt damit die Sichten in Beziehung: Ausgangspunkt ist die Steuerungssicht (die Geschäftsprozesse), von diesen ausgehend sollen die Datensicht (Datenbanken), Funktionen (Anwendungen) und die Organisationsstruktur gestaltet werden.

Empfehlung


Abbildung 16.3-1: Die „Sichten“ der ARIS-Architektur
Quelle: Eigene Darstellung nach [Scheer1998a, S. 41]

Beschreibungsebenen

Die Ressourcensicht war ja oben nicht dabei. Sie kommt jetzt, bei der Definition einer zweiten wichtigen Dimension – den Beschreibungsebenen – wieder zum Konzept dazu. In dieser zweiten Dimension drückt er aus, dass die in den Sichten stattfindenden Aktivitäten eine unterschiedliche Nähe zur Informationstechnik haben. Die drei Ebenen sind wie folgt benannt:

  • Fachkonzept (Semantische Modelle)
  • DV-Konzept
  • Technische Implementierung

Mit dem Begriff Fachkonzept beschreibt Scheer so etwas wie die Semantik eines Anwendungsbereichs, die natürlich umfassend beschrieben werden muss:

Fachkonzept

„Deshalb wird in einem Fachkonzept das zu unterstützende betriebswirtschaftliche Anwendungskonzept in einer soweit formalisierten Sprache beschrieben, dass es Ausgangspunkt einer konsistenten Umsetzung in die Informationstechnik sein kann.“ [Scheer 1998a, S. 15].

Das Fachkonzept ist von besonderer Bedeutung, da es „langfristiger Träger des betriebswirtschaftlichen Gedankengutes ist“ [ebenda S. 16]

Im DV-Konzept wird das Fachkonzept in die „Kategorien der DV-Umsetzung“ übertragen. Anstelle von Funktionen treten die sie ausführenden Modelle oder Benutzertransaktionen. Somit handelt es sich um eine „Anpassung der Fachbeschreibung an die generellen Schnittstellen der Informationstechnik“ [ebenda, S. 15].

DV-Konzept

Mit der dritten Ebene, der Technischen Implementierung, ist die konkrete technische Implementierung der Datenverarbeitung gemeint.

Technische Implementierung

Scheer verknüpft nun die zwei Dimensionen (Sichten und Beschreibungsebenen) seines Ansatzes und schlägt vor, in jeder Sicht diese drei Ebenen zu unterscheiden. Die graphische Repräsentation dieser Überlegung zeigt die folgende Abbildung.

Über der Abbildung ist die Realwelt, die z.B. aus den Strukturen und Abläufen eines Unternehmens besteht, als Betriebswirtschaftliche Problemstellung miteingefügt. Zusammengefasst schlägt dieser theoretische Ansatz somit vor, bei der Analyse und Gestaltung von IT-Systemen die Sichten zu unterscheiden und in diesen jeweils die drei Ebenen der DV-Gestaltung.

Methoden

Damit lassen sich, wie auch die Abbildung zeigt, in der ARIS-Architektur 13 Bereiche unterscheiden, wenn man die Betriebswirtschaftliche Problemstellung mit dazu nimmt. Für jeden dieser Bereiche stellt Scheer geeignete Methoden für den Aufbau und die Analyse der IT vor.

Für die Betriebswirtschaftliche Problemstellung schlägt Scheer Vorgangskettendiagramme (VKD) vor. Nach den Erfahrungen des Verfassers wird in der Praxis in dieser Phase allerdings meist nicht zu formalen Techniken, sondern zu textlichen Beschreibungen gegriffen.

Betriebs­wirtschaftliche Problem­stellung

Vorgangskettendiagramme und Hinweise für deren Aufbau finden sich in [Scheer 1997]. Vgl. zum Beispiel die dortige Abbildung A.II.01 für ein Soll-Konzept einer Kundenauftragsbearbeitung. In [Scheer 1997] dienen Vorgangskettendiagramme auch zur überblicksartigen Einführung neuer Geschäftsprozesse.


Abbildung 16.3-2: Die „Sichten“ + „Beschreibungsebenen“ der ARIS-ArchitekturQuelle: Eigene Darstellung nach [Scheer 1998a, S. 41]

Auf Fachkonzeptsebene schlägt Scheer für die Funktionssicht Hierarchiediagramme (Funktionsbäume) vor. Die Zerlegung soll dort enden, wo Funktionen erreicht werden, die in einem Arbeitsablauf bearbeitet werden (Elementarfunktionen). Funktionsbäume sind statisch, d.h. die Reihenfolge in der die Teilfunktionen abgewickelt werden, ist nicht ersichtlich. Für die Organisationssicht empfiehlt er Organigramme. Als Verknüpfungsart zwischen Organisationseinheiten wird die Weisungsbefugnis gewählt. Für die Datensicht wählt er ER-Modelle [Anmerkung] , mit einigen Änderungen gegenüber der Standardterminologie. Die Steuerungssicht wird u.a. durch Prozessmodelle erfasst.

Beschreibungs­ebene Fachkonzept

16.4 Das Handels-H

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 konkrete 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, Warenausgang, 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 Informationssystems und seiner Prozesse.

In einer zweiten Dimension sind dann die Ebenen Funktionen, Daten und Prozesse angedeutet. Dies drückt aus, dass für die Realisierung der jeweiligen Geschäftsprozesse Funktionen, Daten und Prozesse notwendig sind, bzw. dass diese drei Sichten eingenommen werden sollten.

<<Vgl. Abb. 4.1 von [Becker und Meise 2012]. Auch: Ergänzung>>

16.5 Nach Schmelzer / Sesselmann

Das Referenzprozessmodell von Schmelzer/Sesselmann stellt, wiederum am Beispiel von Industrieunternehmen (mit Serienproduktion), überblicksartig die zu realisierenden Prozesse zusammen (vgl. [Schmelzer und Sesselmann 2008, S. 231], [Schmelzer und Sesselmann 2013, S. 249]). Es unterscheidet primäre und sekundäre Prozesse. Siehe auch die folgende Abbildung. Betont wird die Kundenorientierung: Kundenanforderungen sind der Ausgangspunkt, die Leistungserbringung gegenüber dem Kunden mit dem erhofften Ziel der Kundenzufriedenheit ist der Endpunkt.

Bei den sekundären Prozessen werden die Unterstützungsprozesse (Supportprozesse) und die Strategieplanungsprozesse unterschieden.


Abbildung 16.5-1: Referenzprozessmodell von Schmelzer/Sesselmann.
Quelle: [Schmelzer und Sesselmann 2008, S. 231])

Innerhalb des Innovationsprozesses erfolgt die Gewinnung, Konkretisierung und Selektion von Ideen. Diese Ideen beziehen sich entweder auf neue Produkte/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 planen/bereitstellen, Ideen gewinnen/vorselektieren, Machbarkeit prüfen, Ideen auswählen und Vorentwicklung durchführen (vgl. [Schmelzer und Sesselmann 2008, S. 200ff]).

Im Produktplanungsprozess erfolgt die Erarbeitung von Produktkonzepten. Ausgangspunkt 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, Produktprofil/-konzept planen und Produkte steuern [ebenda, S. 203ff].

Der Produktentwicklungsprozess beinhaltet die Erarbeitung von Entwicklungsprojekten für Produkte, Produktversionen und Produktänderungen. Startpunkt des Prozesses ist das Pflichtenheft und Endpunkt die Lieferfreigabe. Teilprozesse sind: System entwerfen, Hardwarekomponenten entwickeln, Softwarekomponenten entwickeln, 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ürfnisse, die Vermittlung des Leistungsangebots und die Abfrage der Kundenzufriedenheit beinhaltet. Teilprozesse sind: Kunden betreuen, Kundenbedürfnisse analysieren, 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, Material abrufen/bereitstellen, Produkt/System fertigen, Produkt/System liefern, Auftrag fakturieren. Die einzelnen Teilschritte innerhalb des Auftragsabwicklungsprozesses 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öchte [ebenda, S. 211].

Der Serviceprozess beinhaltet die Betreuung des Kunden nach dem Kauf; diese Betreuung beinhaltet die Hilfe bei Schwierigkeiten und die Behebung von Produktmä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 Produkten und Prozessen. Teilprozesse sind: Kundenfragen vorklären, Problemlösung veranlassen, Problem lösen, Produkte/Systeme installieren/warten und Service unterstützen [ebenda, S. 215f].

Die aufgeführten primären Prozesse werden zusätzlich anhand einheitlicher Kriterien beschrieben. In der folgenden Tabelle ist exemplarisch die Beschreibung des Innovationsprozesses dargestellt (Quelle: [Schmelzer und Sesselmann 2008, S. 201]).

 


Beispiel Innovationsprozess

 

Prozessname: Innovationsprozess

von: Kundenproblem

bis: ausgewählte Produkt-/Prozessideen

Prozessverantwortlicher: Name

Objekt:

Produkt-/Prozessidee

 

Prozessinputs:

Forschungsergebnisse, Patente, Kundenprobleme, Konkurrenzprodukte

Lieferanten:

Forschungsinstitute, Literatur, Kongresse, Mitarbeiter, Kunden, Wettbewerber, Zulieferer

Prozessergebnis:

Technologien, Prototypen, ausgewählte Produkt-/Prozessideen, Durchführbarkeitsstudien, Basislösungen, (Plattformen, Systemkonzepte), Patente

Kunden:

Strategieplanungsprozess, Produktplanungsprozess, Produktentwicklungsprozess, Fertigungsprozess


Neben der Beschreibung der Prozesse sind auch die dazugehörigen Teilprozesse detailliert beschrieben. Vgl. dazu die folgende Tabelle (Quelle: [Schmelzer und Sesselmann 2008, S. 202]).

xxx


Teilprozesse

Technologien planen / bereitstellen

Ideen gewinnen/ vorselektieren

Machbarkeit prüfen

Objekte

Technologie

Produkt-/Prozessidee

Produkt-/Prozessidee

Inputs

Forschungsberichte, Patentrecherchen

Technologien, Kundenprobleme, Konkurrenzprodukte

vorselektierte Produkte-/ Prozessideen

Ergebnisse

Technologiestrategie, Technologieprojekte

vorselektierte Produkte-/Prozessideen

Prototypen, Labormuster, Machbarkeitsstudien, Patente

Methode

Szenarien, S-Kurve, Technologie-Roadmap, Technologie-Portfolio

Kreativitätstechniken

Rapid Prototyping


 


Teilprozesse

Ideen auswählen

Vorentwicklungen durchführen

Objekte

Prozessidee

Vorentwicklungsprojekte

Inputs

Prototypen, Labormuster, Machbarkeitsstudien

ausgewählte Produkt- und Prozessideen

Ergebnisse

ausgewählte Produkt- und Prozessideen

Plattformen, Architekturen, kritische Komponenten

Methode

Famp;E-Portfolio

Projektmanagement


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, Geschäfts-/Prozesssituation bewerten, Geschäfts-/Prozessstrategie festlegen, Geschäftsplan/Prozessmodell erstellen (vgl. [Schmelzer und Sesselmann 2008, S. 219]).

Strategieplanung

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, Beschaffen des Personals, Betreuen des Personals, Beraten des Personals, Qualifizieren/entwickeln/fördern des Personals und Abbau von Personal [ebenda, S. 221f].

Personalmanagement

Im Rahmen des Finanzmanagementprozesses werden finanzielle Mittel geplant und gesteuert Zielsetzung ist es dabei, eine geeignete Vermögens- und Geldmitteldisposition vorzuhalten. Folgende Teilschritte liegen vor: Finanzbedarf planen/abdecken, Liquidität planen/realisieren/kontrollieren, Kapital beschaffen/anlegen, Anlagen-/Finanzbuchhaltung durchführen, Zahlungseingänge überwachen und Steuer-/Versicherungsfragen klären [ebenda, S. 222]).

Finanzmanagement

Der Ressourcenmanagementprozess plant und steuert die notwendigen Ressourcen wie zum Beispiel Standorte, Gebäude, Maschinen, Werkzeuge, Transporteinrichtungen und die Energieversorgung. Teilprozesse sind: Ressourcen planen/beschaffen, Ressourcen installieren/warten/instand halten, Ressourcen wiederverwenden/entsorgen, Lieferanten bewerten/auswählen und Nutzer beraten [ebenda, S. 222]).

Ressourcenmanagement

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 sicherzustellen. Teilprozesse sind: IT-Systeme planen/beschaffen, IT-Systeme betreuen, Rechenzentrum betreiben, Dokumente verwalten/archivieren, Daten sichern/schützen und Anwender beraten [ebenda, S. 222f].

IT-Management

Innerhalb des Qualitätsmanagementprozesses werden Rahmenbedingungen geschaffen, die eine Qualität sicherstellen und sie Einhaltung relevanter Qualitätsvorschriften sicherstellen. Teilprozesse sind: QM-System einführen/anpassen/auditieren/­zertifi­zie­ren, Management-Reviews/Q-Assessments koordinieren, Q-Dokumente/Berichte erstellen/lenken, QM schulen und QM beraten [ebenda, S. 223].

Qualitätsmanagement

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-/Informa­tions­system entwickeln/implementieren, Compliance Management durchführen, Controllingmethoden/-instrumente auswählen/bereitstellen und Weiterbilden/Beraten.

Controlling

Zusammenfassend kann festgehalten werden: Das Referenzprozessmodell von Schmelzer/Sesselmann setzt sich aus primären und sekundären Prozessen zusammen. Primäre Prozesse nehmen Kundenanforderungen auf und setzen diese in Kundenzufriedenheit um. Das Modell umfasst zahlreiche Prozesse und Subprozesse.

16.6 Das SCOR-Modell

Das SCOR-Modell (Supply Chain Operations Reference-Modell) ist für den Produktionsbereich gedacht und berücksichtigt die gesamte Supply Chain (Wertschöpfungskette). 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 Entsorgung) analysiert und gestaltet werden. Das SCOR-Modell wurde vom Supply-Chain Council, einem gemeinnützigen Industrieverband mit ca. 1.000 internationalen Unternehmen, 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 Lieferanten und Kunden dargestellt.


Abbildung 16.6-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 Kapazitätsnachfrage abzustimmen und somit die Rahmenbedingungen für die übrigen Prozesse 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 Bereitstellung der (Vor-) Produkte und Dienstleistungen.

Make

Die Herstellung beinhaltet die Produktionsplanung, Produktionsausführung, Montage, Qualitätskontrolle und Verpackung. Es sollen End-/Zwischenprodukte hergestellt, die dann an Kunden geliefert werden. Hierbei ist zwischen Make-to-stock (Lagerfertigung), Make-to-order (Auftragsfertigung) und Engineer-to-order (Projektfertigung) zu unterscheiden.

Deliver

Die Lieferung umfasst die Auftragsabwicklung, das Lager- und das Transportmanagement 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 Lieferanten gesteuert.

Neben diesen fünf Kategorien berücksichtigt das SCOR-Modell vier Detaillierungsebenen; der Fokus des SCOR-Modells bezieht sich aber nur auf die ersten drei Ebenen, da die vierte Ebene unternehmensindividuell auszugestalten ist (= Implementierungsebene). Die vier Ebenen sind in der folgenden Abbildung dargestellt.


Abbildung 16.6-2: Ebenen des SCOR-Modells. Quelle: [SCOR 2005, S. 6]

Die vier Ebenen sind nachfolgend kurz erläutert (vgl. [SCOR 2005, S. 6-11]):

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önnen z.B. die Planung und die Koordination der Wertschöpfungsaktivitäten entscheidend sein, wohingegen für einen Lebensmittelhersteller der Wettbewerbsvorteil in der Produktion oder der Distribution liegt.

Ebene 1

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 Auftragsart (z.B. auftragsbezogene Produktion oder Produktion auf Lager). Die Planungsprozesse 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 2

Auf der Ebene 3 (Gestaltungsebene) werden die Prozesskategorien mittels Prozesselementen konkretisiert. Die Prozesselemente beschreiben die wesentlichen Prozessschritte (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 3

Auf der Ebene 4 (Implementierungsebene) findet die Beschreibung der unternehmensspezifischen Aufgaben und Aktivitäten für jedes Prozesselement statt. Hierfür liegen keine Modellierungselemente vor, da die Abbildung sehr detailliert und unternehmensspezifisch ist und da Modellierungsverfahren existieren, die eingesetzt werden können.

Ebene 4

Bitte beachten: Das Supply Chain Operation Reference-Model wurde vom Supply-Chain Council (SCC) entwickelt und gepflegt. Das SCC ist eine unabhängige, nicht-gewinnorientierte Organisation. Im Jahr 2014 fusionierte der Supply-Chain Council mit der APICS unter dem neuen Namen APICS Supply-Chain Council (APICS SCC). Quelle: Wikipedia, "Supply-Chain Council".

16.7 Das 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) einzuführen. Dabei werden Organisationen ausgezeichnet, die das Qualitätsmanagement in beispielhafter Weise umgesetzt haben. Das EFQM-Modell bezieht sich auf die Organisation als Ganzes und auf die Umsetzung des Qualitätsmanagements in allen Bereichen einer Organisation. Die folgende Abbildung stellt die Bestandteile des EFQM-Modells dar.


Abbildung 16.7-1: EFQM-Modell. Quelle: [Bou Llusar et al. 2009, S. 7]

In diesem Modell werden Befähiger (Enabler) und Ergebnisse (Results) unterschieden.

Die Führung ist der erste Bestandteil und unterstreicht die Rolle des Managements innerhalb der Organisation. Ihre Aufgabe ist Entwicklung der Vision, der Mission und der Werte, um somit der Organisation eine Richtung und Handlungsprinzipien vorzugeben. Damit werden die Zielerreichung und der nachhaltige Erfolg von Unternehmen sichergestellt (vgl. [Wongrassamee et al. 2003, S. 17]).

Führung

Im Rahmen der Mitarbeiter als zweiter Bestandteil des Modells werden die Ausschö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. Wichtige Prinzipien innerhalb dieses Bestandteils sind die Betrachtung des systemischen Zusammenwirkens der Mitarbeiter auf verschiedenen Ebenen, die Mitarbeiterorientierung, 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.

Mitarbeiter

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 untergeordnete Ziele bzw. Pläne erstellt, die der Umsetzung der Strategie dienen (vgl. Tummala und Tang 1994, S. 47).

Politik und Strategie

Partnerschaften und Ressourcen beinhalten die Bewertung der Nutzung von technologischen, 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).

Partnerschaften und Ressourcen

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, gefü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:

Prozesse

  • 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. Mitarbeiterzufriedenheit, -motivation und -identifikation gemessen.
  • Die Kundenergebnisse werden mittels Indikatoren wie z.B. Kundenzufriedenheit und -loyalität gemessen.
  • 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.

16.8 S-BPMN

In [Fleischmann et al. 2011] wird für die Prozessmodellierung ein Vorschlag formuliert, bei dem die beteiligten Menschen als Subjekte im Mittelpunkt stehen. Damit sollen subjektorientierte Prozessmodelle entstehen (S-BPM-Modelle) .

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 Objekte (Mit wem oder was wird etwas getan?). Das ist allerdings nichts neues, die gängigen Modellierungsmethoden beruhen auch darauf. In Ereignisgesteuerte Prozessketten 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 eigenen 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.

Ausgangspunkt

Die Methode kennt in der Grundstruktur nur wenige Symbole:

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 Beschriftung 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 auf S. 34ff.

Die Vorgehensweise ist wie folgt [ebenda]: Zuerst werden die am Prozess beteiligten prozessspezifischen Rollen, die Subjekte und die zwischen ihnen ausgetauschten 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.

Vorgehensweise

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 dargestellt. 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 Zustandsautomaten der UML. Also von Sendezustand, Empfangszustand, usw. Ein solches Modell entsteht für jeden Partizipanten, die Modelle der einzelnen Teilnehmer müssen 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 Prozessbeschreibungen 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 eingebunden werden.

16.9 Weitere Referenzmodelle

In [Schmelzer Sesselmann 2013, Abschnitt 5.2.2; S. 241ff] finden sich für den Bereich der Betriebswirtschaftlichen Referenzmodelle weitere Beispiele:

  • BAM: Business Activity Model, MIT Process Handbook
  • PCF: Process Classification Framework des American Productivity amp; Ouality Center (APQC) für unterschiedliche Industriebranchen
  • VRM: Value Reference Model der Value Chain Group (VCG) für die Industrie
  • REFA-Prozessmodelle für Industriebranchen
  • eTOM: enhanced Telecom Operations Map für Telekommunikationsunternehmen und IT-Dienstleistungen
  • Handels-H-Modell für Handelsunternehmen
  • SCOR: Supply Chain Operations Reference for Supply Chains
  • Referenzmodell ISO 12207 für Softwareentwicklungsprozesse
  • ITIL: Infrastructure Library für den IT-Betrieb
  • COBIT: Control Objectives for Information and related Technology for IT-Governance
  • Referenzmodell für das Innovationsmanagement

Vgl. [Schmelzer Sesselmann 2013, S. 241ff] und die dort angegebenen Quellen.

 

17 IT-Unterstützung der Prozessabwicklung

17.1 Historische Entwicklung

Es ist ein altes Thema. Schon bald nach dem Aufkommen der Computer stellte sich die Frage, ob und wie diese die Geschäftstätigkeit von Unternehmen und anderen Organisationen ("Volkszählung") unterstützen können. Dabei ging es erstmal um einzelne Aufgaben (Finanzwesen, Lagerverwaltung, …) und das ganz normale operative Geschäft.

Als dann die Zahl der Computer in den Organisationen größer wurde, begann das Thema Integration Bedeutung zu gewinnen. Und nur wenige Jahre später wurde dies durch den Prozessgedanken geprägt. Seitdem hängen IT-Integration und Geschäftsprozesse untrennbar zusammen. Die Geschichte der betrieblichen Informatik im Allgemeinen und die der betrieblichen Anwendungssysteme im Besonderen kann auch als ein ständiger Versuch interpretiert werden, die Geschäftsprozesse der Organisationen immer stärker durch IT zu unterstützen. Dies war anfänglich nur in Form von Insellösungen möglich, weshalb es darum ging, diese "Inseln" zu integrieren. Dadurch sollten die Prozesse effizienter und effektiver werden.

Integration und Prozessgedanke

Im Rahmen der IT-Entwicklung dehnte sich die Softwareunterstützung immer mehr aus, von der Unterstützung einzelner weniger Funktionen (in den 1950-er Jahren) bis zur heutigen flächendeckenden Geschäftsprozessunterstützung. Parallel wurde und wird die Prozessunterstützung immer detaillierter. Wurden anfangs in den Geschäftsprozessen nur einzelne 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.

Softwareunterstützung

So kommt es, dass heute die integrierte prozessorientierte Software (z.B. von SAP) die Nutzer für die Interaktion von Maske zu Maske leitet und der Prozess ansonsten automatisiert abläuft. Das machte es auch möglich, dass das Geschäftsmodell der Internet-Unternehmen 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.

Automatisierung

Dies war möglich, weil seit dem Aufkommen des Prozessgedankens eine immer detailliertere Erfassung und Modellierung der Geschäftsprozesse erfolgte. Sie diente als Grundlage und wurde zum Trend, der bis zur heutigen teilweise vollautomatischen Abwicklung von Geschäftsprozessen reicht.

Trend zu immer detaillierterer Erfassung

Warum eigentlich Integration?

Geschäftsprozesse in Unternehmen bestehen, knapp zusammengefasst, aus zusammenhängenden Handlungen zur Erreichung der Organisationsziele. Dazu gehören u.a. Datenflüsse aller Art und ein Kontrollfluss. Integration von IT-Systemen bedeutet nun, dass Informationssysteme, die unverbunden nebeneinander einzelne Aufgaben in den Geschäftsprozessen erledigen so verknüpft werden, dass sie Daten aller Art austauschen können. Mit dieser Integration kann eine gegenüber dem vorigen Integrationsstand weitere Optimierung der Geschäftsprozesse und der gesamten IT erreicht werden, denn „Nicht-Integration“ bedeutet Defizite in der Prozess- und Datenintegration, die mit viel Aufwand überwunden werden müssen.

Die durch Nicht-Integration entstehenden Reibungsverluste äußern sich v.a. als großer Aufwand für die Informationsweitergabe. Wenn z.B. von der Abteilung Produktion Daten zur Abteilung Vertrieb weitergegeben werden sollen, müssen die Formate jeweils umgewandelt werden. Falls die beiden Abteilungen unterschiedliche Hardware nutzen, muss auch dies überwunden werden.

„Kosten“ der „Nicht-Integration“

Eine weitere Konsequenz der Nicht-Integration von Datenbeständen sind oft Redundanzen. Werden z.B. die Daten der Kunden ganz oder teilweise in verschiedenen Datenbanken gehalten, kann es leicht geschehen, dass in der einen Datenbank dieselbe Information anders festgehalten ist als in der anderen. Für die Absicherung der Geschäftsprozesse durch Datenbanken ist dies eine verhängnisvolle Situation.

Ein weiterer Grund für Integrationsanstrengungen ist der Wunsch nach einer immer detaillierteren Abbildung der Geschäftsprozesse durch die Software. Höhere Detaillierung bedeutet, dass der jeweilige Geschäftsprozess immer detaillierter durch die Software abgedeckt wird. Dies ist ein ständiges Verlangen, seit es die ersten einzelne Funktionen unterstützende Anwendungssoftware gab und vor allem seit entsprechende integrierte prozessorientierte Software (ERP-Software) entwickelt wurde, weshalb diesbezüglich tatsächlich von einem Trend gesprochen werden kann.

Höhere Detaillierung

Seit einigen Jahren ist nun diesbezüglich ein weiterer Trend sehr deutlich zu erkennen, der nach vollständig automatisierten Geschäftsprozessen. D.h. nach Geschäftsprozessen, die ganz durch Software umgesetzt werden. Beispiele bieten die Internet-Unternehmen, deren Geschäftsmodelle ohne diese Automatisierung (v.a., was die Prozesse mit den Kunden angeht) nicht denkbar wäre. Die Entwicklung hat aber inzwischen auch die übrigen Organisationen erreicht (vgl. die folgenden zwei Kapitel).

Automatisierte Geschäftsprozesse – vollständig in Software gepackt

Konkrete Entwicklungsschritte

Zumindest ein klein wenig soll der Blick auf die oben angedeutete historische Entwicklung vertieft werden. V.a., weil man hier tatsächlich aus der Vergangenheit lernen kann, weil sich defizitäre Muster von damals heute wieder zeigen.

Geschäftsprozesse wurden schon immer realisiert, seit es Organisationen mit zielgerichtetem Handeln gibt. Bis in die 1950-er Jahre allerdings ohne Computerunterstützung.

Insellösungen

In den Jahren des ersten kommerziellen Einsatzes von Computern (in den 1960er Jahren), die damals alle Großrechner waren, wurden die Computer für wichtige einzelne Aufgaben (Finanzwesen, Lagerwesen, …) genutzt und dies auf eine Weise die wir heute funktionsorientiert nennen würden.

1960er-Jahre – Geschäftsprozesse erhalten IT-Unterstützung für einzelne Funktionen

Natürlich war die Geschäftstätigkeit damals auch durch Geschäftsprozesse geprägt. Dies wurde aber nicht erkannt, der Schwerpunkt der Betrachtung lag auf Stellen und ihren Aufgaben [Anmerkung] . Die einzelnen Anwendungssysteme lösten Aufgaben, die wir aus heutiger Sicht als sehr einfache bezeichnen würden: Verarbeitung von Massendaten im Bereich der wertorientierten Abrechnungssysteme, z.B. im Finanz- und Personalwesen. Die Anwendungssysteme standen isoliert nebeneinander, mit u.U. sehr unterschiedlicher Hardware und Software (proprietäre Systeme) und lösten ihre „punktuellen“ Aufgaben. Aus der heutigen, durch Geschäftsprozesse geprägten Sicht lösten die damaligen Anwendungssysteme also nur einzelne isolierte (d.h. unverbunden nebeneinanderstehende) Funktionen. Deshalb wurde damals von Insellösungen gesprochen.

Insellösungen

Ihr Einsatz brachte Produktivitätsgewinne, weil durch sie die Verarbeitung von Massendaten wesentlich effizienter erledigt werden konnte. Bei dieser Vorgehensweise, Großrechner mit entsprechender Software isoliert nebeneinander für einzelne Aufgaben einzusetzen, blieb es auch eine ganze Weile, solange nämlich, wie diese Vorgehensweise Produktivitätsgewinne erlaubte.

Die folgende Abbildung veranschaulicht den Zustand am Ende dieser Phase. Zahlreiche Aufgaben oder kurze Geschäftsprozesse waren auf Anwendungssystemen (AS) realisiert, in der Regel isoliert voneinander. Einzelne von ihnen wurden aber auch schon (mit hohem Aufwand) „verknüpft“, was bedeutet, dass das eine Anwendungssystem Informationen an ein anderes weitergeben konnte.


Abbildung 17.1-1: Geschäftsprozesse mit punktueller IT-Unterstützung durch Insellösungen

AS: Anwendungssysteme

Erste Integrationsbemühungen

Die automatische Weitergabe von Daten von einem IT-gestützten Teilprozess zu einem anderen war zunächst kein Thema. Dies änderte sich aber, als die Zahl der Anwendungssysteme zunahm und die von ihnen abgedeckten Aufgaben immer umfangreicher wurden. Es fielen nun öfter in einem Prozessabschnitt Daten an, die in einem anderen benötigt wurden. Die Schnittstellen zwischen den Insellösungen wurden schmerzhaft (teuer, weil sie durch menschliches Tun überwunden werden mussten) und als Medienbrüche erkannt. Es setzte sich die Erkenntnis durch, dass weitere Produktivitätssteigerungen nur möglich waren, wenn die Schnittstellen zwischen den Anwendungssystemen automatisiert wurden.

Medienbrüche

Die folgende Abbildung verdeutlicht diese Situation. Die einzelnen IT-gestützten Prozessabschnitte wurden, soweit es sinnvoll war, verknüpft, so dass Daten ausgetauscht werden konnten. Daten, die in der einen Anwendung entstanden und die in der anderen als Input benötigt wurden.


Abbildung 17.1-2: Geschäftsprozesse mit punktueller IT-Unterstützung durch verknüpfte Insellösungen.

Damit wurde Ende der 1960er Jahre die Integration der Informationsverarbeitung zu einem zentralen Thema. Nicht nur in der betrieblichen Informatik sondern auch und gerade in der (neu entstehenden) Wirtschaftsinformatik. Der wichtigste Vertreter dieser Denkrichtung war und ist Peter Mertens, dessen Buch Integrierte Informationsverarbeitung in Erstauflage im Jahr 1969 und 2007 in 16. Auflage erschienen ist (vgl. [Mertens 2013]).

Peter Mertens

Die Integration der vorhandenen IT-gestützten Prozessabschnitte (Hard- und Software) war von nun an das zentrale Thema. Ein wichtiges Analyseinstrument waren Datenflussdiagramme, in denen untersucht wurde, welche Informationen sinnvollerweise von einem Prozessabschnitt zum anderen fließen sollten.

Datenflüsse

Diese Sichtweise, das Informations- und Kommunikationssystem eines Unternehmens als ein Miteinander von IT-gestützten Insellösungen zu sehen, die in Interaktion gebracht werden müssen, blieb eine ganze Zeit lang dominierend. Solange mit ihr Produktivitätsgewinne zu erzielen waren. Doch die Entwicklung ging weiter und in den 1980er Jahren setzte sich langsam die Erkenntnis durch, dass weitere Effizienzgewinne nur zu erzielen waren, wenn die Integrationsbemühungen auf eine neue Basis gestellt wurden. Das größere Ganze, die Gesamtaufgabe, und nicht die Datenweitergabe nur von Funktion zu Funktion, von Anwendungssystem zu Anwendungssystem, sollte betrachtet werden.

Der Geschäftsprozess­gedanke

Dieses neue Konzept war der Geschäftsprozessgedanke. Die Betrachtung der Geschäftsprozesse eines Unternehmens, ob sie nun schon automatisiert waren oder nicht, erlaubt viel fundiertere Produktivitätsgewinne als die Optimierung der vorhandenen IT hinsichtlich der auszutauschenden Informationen. Wichtigster Träger dieses Konzepts/Gedankens war und ist August-Wilhelm Scheer mit seinem Standardwerk Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse (vgl. [Scheer 1997]). Er begann mit der Arbeit an diesem Buch 1983, die bisher letzte Auflage (7.) erschien 1997 (2011 erschien ein Softcover reprint der 1997er-Ausgabe).

August-Wilhelm Scheer

Seine Hauptaussage ist, dass die Integration der Informationsverarbeitung viel effizienter betrieben werden kann, wenn sie auf der Analyse der Geschäftsprozesse erfolgt. Mit seinem ARIS-Konzept und seinem Y-CIM-Modell legte er gleichzeitig auch wichtige theoretische Grundlagen bzw. gab erfolgreiche Architekturhinweise.

ARIS: Architektur integrierter Informationssysteme

Er stellte, was damals neu war, Geschäftsprozesse in den Mittelpunkt seines Vorschlags. Das ARIS-Konzept kann verstanden werden als eine Empfehlung, die IT einer Organisation ausgehend von einer Analyse der Geschäftsprozesse zu gestalten. Für die Erfassung, d.h. Modellierung der Geschäftsprozesse erarbeitete sein Team die Methode der Ereignisgesteuerten Prozessketten (EPK). In dieser Phase erreichte die Prozessmodellierung ihre erste Blüte.

Geschäftsprozesse im Mittelpunkt

Die folgende Abbildung veranschaulicht, den damit erreichten Stand. Es wurde erkannt, dass Geschäftsprozesse, wenn sie nicht zu eng definiert werden, quer durch das Unternehmen „gehen“, d.h. zahlreiche Organisationseinheiten und Anwendungssysteme tangieren. Sie liegen dann „quer“ zur klassischen Aufbauorganisation. Denken wir nur an eine Auftragsabwicklung in einem Industrieunternehmen, die klassischerweise durch die Bereiche Vertrieb, Beschaffung, Lagerhaltung, Produktion und Versand abgedeckt wird.

Entlang der Geschäftsprozesse fließen Informationen (auf allen Trägern) in beide Richtungen. Integrationsbemühungen haben sich also an wichtigen Geschäftsprozessen zu orientieren.

Die Prozessmodellierung war in dieser Zeit wesentlich durch die Methode EPK geprägt.

Methode EPK


Abbildung 17.1-3: Geschäftsprozesse mit IT-Unterstützung.

Der Geschäftsprozessgedanke führt aber ganz automatisch dazu, dass man auch Geschäftsprozessabschnitte, die noch nicht mit Hilfe von Anwendungssystemen realisiert werden, in die Analyse miteinbezieht. Die Betrachtung dieser noch nicht unterstützten Geschäftsprozessabschnitte (in der Abbildung mit „NI“ bezeichnet) ist von besonderer Bedeutung, wenn es um Produktivitätsgewinne geht. Hier stellt sich immer die Frage, ob ihre Unterstützung bzw. Automatisierung sinnvoll ist oder ob sie besser nicht oder nur teilweise unterstützt bzw. automatisiert werden sollen.

Integrierte prozessorientierte Software

Der nächste Schritt war dann ein nahe liegender: Wenn schon Integration, dann nicht durch (teure) Überwindung zahlreicher Schnittstellen (bei Hardware und Software), sondern durch die Realisierung aller automatisierten Abschnitte in einem einzigen Anwendungssystem, mit einer einzigen Datenbank, auf einer einzigen Hardwareplattform. Damit entfallen die Hardwareschnittstellen, die Softwareschnittstellen mutieren zu Datenübergaben zwischen Programmmodulen innerhalb einer einzigen Datenbank.

Ein Anwendungssystem, eine Datenbank, eine Hardware-Plattform

Eine solche Software bedarf der umfassenden Modellierung der Geschäftsprozesse des Anwendungsbereichs.

Nimmt man noch dazu, dass eine solche Software natürlich prozessorientiert ist, alle (kaufmännischen) Funktionsbereiche und vielleicht noch etwas mehr abdeckt sowie an die konkreten Geschäftsprozesse unterschiedlicher Unternehmen anpassbar ist, dann sind wir bei dem Softwaretyp ERP-Software (Enterprice Resource Planning, auch: betriebswirtschaftliche Standardsoftware) angelangt. Idealtypisch vereinfacht sich dann die IT eines Unternehmens im kaufmännischen Bereich zu dem, was die folgende Abbildung andeutet: Eine integrierte prozessorientierte Software bedient die Geschäftsprozesse des Unternehmens. Vgl. für eine Kurzbeschreibung dieses Softwaretyps Abschnitt 17.4.

In der Abbildung ist auch angedeutet, dass es daneben für einzelne Prozessabschnitte Anwendungssysteme außerhalb der ERP-Software gibt, in Verbindung mit dieser (z.B. eine Data-Warehouse-Lösung) oder auch nicht (z.B. ein isoliertes Programm für die Erstellung von Absatzprognosen).


Abbildung 17.1-4: Geschäftsprozesse – IT-unterstützt in ERP-Software

Zurück mit der Integration – Serviceorientierte Architekturen

Es gab dann in den 1980-er Jahren einen Vorschlag, der – genau betrachtet – eine Rücknahme der Prozessintegration vorschlug, die sog. Serviceorientierten Architekturen. Er ist in Abschnitt 17.5. kurz beschrieben. Kurz zusammengefasst war die Idee, die Gesamtleistung des Geschäftsprozesses in einzelne Abschnitte aufzuteilen, die Services, und diese durch Software, vor Ort oder aus der Cloud (WebServices) realisieren zu lassen. Aktuelle Ansätze, rund um Robotic Process Automation (vgl. Kapitel 19), ähneln – zumindest in der Grobarchitektur – diesem Vorschlag.

Rücknahme Prozessintegration

Integration über Unternehmensgrenzen

Unsere arbeitsteilig organisierten Wirtschaftssysteme sind durch einen intensiven und globalen Austausch von Gütern und Leistungen gekennzeichnet. Dieser Austausch verlangt die Weitergabe von Daten, Belegen, von Koordinierungsinformationen (Koordination des Abwicklungsprozesses) oder – mit anderen Worten – die Fortsetzung der Geschäftsprozesse über Unternehmensgrenzen hinweg. Anfang und Ende eines Geschäftsprozesses sind damit in den meisten Fällen nicht mehr so sehr an den Unternehmensgrenzen orientiert, sondern an der umfassenden logistischen Kette von Vorlieferanten zu Endkunden.

Unternehmens-übergreifende Flüsse

Wenn traditionell Handel betrieben wird, ist damit ein reger Austausch von Daten verbunden: Ausschreibungsinformationen, Angebote, Lieferscheine, Rechnungen, Versandavise, Frachtpapiere, Stornierungen, Zahlungen und Bestätigungsschreiben - für jedes dieser Dokumente sind zwischen Auftraggeber und einer beliebigen Menge von Auftragnehmern Daten auszutauschen. Traditionell erfolgte diese Kommunikation per Post und auf Papier. Mit Aufkommen der Daten- und Rechnernetze wurde es jedoch möglich, sie auch auf elektronischem Weg auszutauschen. Damit entstanden die Zwischenbetrieblichen Informationssysteme.

Zwischenbetriebliche Informationssysteme

Diese verbinden die IT-Systeme zweier oder mehrerer Unternehmen. Ziel ist der automatisierte Austausch von Koordinierungsinformationen im Rahmen der Abwicklung von Geschäftsprozessen über Unternehmensgrenzen hinweg. Beispiele sind der elektronische Austausch von Bestellungen, Lieferscheinen oder Rechnungen. In diesem Zusammenhang spricht man auch vom Extended Enterprise, weil hier juristische Grenzen des (einzelnen) Unternehmens durchbrochen werden, wenn gemeinsame Funktionen und Prozesse zum gemeinsamen Vorteil integriert werden.

Extended Enterprise

Dieser klassische elektronische Datenaustausch verursacht hohe Implementierungskosten und ist nicht sehr flexibel. Deshalb gibt es seit nun schon vielen Jahren Anstrengungen, EDI auf der Basis des Internet und mit Hilfe von XML zu betreiben.

XML (Extensible Markup Language) liefert Standards für Aufbau, Inhalt und Aussehen von Dokumenten zur direkten Weiterverarbeitung in der IT der beteiligten Unternehmen. Im Gegensatz zu EDI benötigt XML keine gesonderte Infrastruktur, da hier die Internettechnologien genügen. Es ist eine Weiterentwicklung von HTML (einer typographischen Auszeichnungssprache) mit dem Ziel, den erfassten Texten semantische Eigenschaften zuzuweisen, wodurch XML zu einer sog. semantischen Auszeichnungssprache wird (vgl. [Hansen und Neumann 2009, S. 457]).

Die wirklich aufwendigen Medienbrüche liegen damit heute an den Unternehmensgrenzen. Hier werden Informations- und Kontrollflüsse unterbrochen oder gehemmt, hier wird (sozusagen) die Datenautobahn zur Landstraße. Der Aufwand ist auch deshalb recht hoch, weil es schon lange nicht mehr nur um den einfachen Austausch von Daten geht, sondern darum, ein Geschäftsobjekt(Rechnung, Angebot usw.) bzw. eine Koordinierungsinformation (Eingangsbestätigung usw.) als solche zu übermitteln. Dann kann das empfangende System des anderen Unternehmens z.B. die Rechnung als solche erkennen und gleich dem Prozessverlauf entsprechend weiter handeln. Falls dies realisiert ist, sprechen wir von semantischer Prozessintegration.

Aufwendige Medienbrüche

Eine zentrale Rolle bei der softwaretechnischen Realisierung nimmt hierbei ERP-Software ein, die zusätzlich zu ihren bisherigen Aufgaben noch diese übernimmt, unterstützt allerdings durch Software für die eigentliche unternehmensübergreifende Kommunikation, sei es zwischen Unternehmen (B2B), zwischen Unternehmen und Kunden (B2C) oder sonst wo.

Rolle der ERP-Software

Klappt die Integration über Unternehmensgrenzen, sind die Vorteile enorm. Die dann entstehenden Wertschöpfungsketten weisen folgende Merkmale auf:

  • Enge Verzahnung betrieblicher und zwischenbetrieblicher Leistungsprozesse.
  • Verstärkte digitale Steuerung der Abläufe unter steigender Einbeziehung interner und externer Informationen.
  • Steigende Anzahl beteiligter Partner.
  • Sich verkürzende Zeitspanne zwischen Leistungsanforderung und Leistungserstellung.

Die dabei erzielbaren Vorteile sind im wesentlichen Zeitvorteile in der logistischen Kette (z.B. Wiederbeschaffungszeiten) und Rationalisierungspotenziale im administrativen Bereich.

Außenwelt und Cloud Computing

Ganz grundsätzlich ist jede Organisation heute in eine dichte informationelle Umwelt eingebettet. Dies bedeutet, 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 ("Auftragseingang"), 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. In der folgenden Abbildung steht die gestrichelte Linie für einen solchen Geschäftsprozess. Es könnte die Leistungserbringung sein, da diese in der Regel eine solche Struktur aufweist: 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 Prozessintegration und Portallösungen. Hier muss die Prozessmodellierung Klarheit schaffen und die Grundlagen für die Automatisierungsbemühungen liefern.

Informationelle Umwelt;

Vgl. zu Cloud Computing Abschnitt 17.7

Informationelle Umwelt

Jede Organisation ist in eine informationelle Umwelt eingebettet. Dorthin sendet sie Informationen, von dort erhält sie Informationen. Zur informationellen Umwelt von Unternehmen gehören die Partner, die Wettbewerber, die staatliche Verwaltung, die Kunden, die zuständigen Gewerkschaften, usw. Der Informationsaustausch erfolgt auf allen denkbaren Trägern, natürlich auch mit den Internet-basierten, z.B. durch Auswerten von Daten, die im Social Web entstehen.

In der Abbildung ist auch angedeutet, dass die Gesamtleistung eines Geschäftsprozesses u.U. von mehreren IT-Systemen und WebServices erbracht wird, zusammen mit einem ERP-System. Dies ist heute durchaus Realität. Auch dann gibt es vielfältige Schnittstellen, die zu bewältigen sind. Diese Schnittstellen sind durch ein grafisches Symbol angedeutet. Sie müssen geklärt und durch eine effektive Prozessmodellierung bewältigt werden.

Mehrere IT-Träger und ihre Verknüpfung

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. Eine entsprechende Prozessmodellierung ist dafür unabdingbar.

WebServices


Abbildung 17.1-5: Schnittstellen in die Außenwelt und ihre Bewältigung durch die Prozessmodellierung

Genau dasselbe gilt für die moderne Form des Outsourcings, die Verlagerung von Teilen der IT in irgendwo auf dem Globus eingerichtete Servicerechenzentren. Dieses Cloud Computing wird inzwischen von vielen Unternehmen genutzt. Konkret bedeutete es, dass ganze Geschäftsprozesse oder Teile von Geschäftsprozessen in die Cloud verlegt werden (vgl. den Punkt Cloud-AS in der folgenden Abbildung). Geschieht dies, müssen die Schnittstellen zwischen den Geschäftsprozessen in der eigenen Organisation und den ausgelagerten geklärt werden. Insbesondere auch, welche Informationen hin und welche zurückfließen. Auch dafür ist eine umfassende Prozessmodellierung unabdingbar, insbesondere auch was die Informationsobjekte (Datenbestände) angeht.

Cloud Computing Weitere Schnittstellen

Cloud Computing

Diese moderne Version des Outsourcings unterscheidet sich von älteren Formen dieses Angebots v.a. durch eine größere Flexibilität. Bei den meisten Angeboten ist es möglich, schnell und unkompliziert zu skalieren (die benutzten Kapazitäten auszubauen oder zu reduzieren). Bezüglich der technischen Realisierung dieser Servicerechenzentren ist v.a. die umfassende Virtualisierung dieser Leistungen zu nennen. Vgl. auch Abschnitt 17.7.

Dabei ist meist zuerst Desintegration zu leisten. Bezieht man nicht die gesamte IT-Leistung auf diesem Weg, muss man Bereiche bestimmen, die man auf diese Weise auslagern möchte. Beispielsweise die wöchentlichen Versandaktionen, die gesamte Buchhaltung, die vierteljährliche Prognoserechnung oder auch gleich das gesamte Finanzwesen. Egal wie, anschließend muss diese Leistung in die übrigen Anwendungssysteme integriert werden. Welche Informationen werden hin gesandt, welche Aktionen werden von dort erwartet, welche Informationen und Koordinierungsinformationen sollen zurückkommen, usw. Auch dies muss die IT eines Unternehmens gegebenenfalls leisten.

Desintegration

Die folgende Abbildung illustriert dies. Der Geschäftsprozess verlässt an einer Stelle die Organisations-IT und setzt seinen Weg "in der Cloud" fort. Die erste durch Prozessmodellierung zu klärende Schnittstelle ist gegeben. Später, wenn der Geschäftsprozess in die Organisation "zurückkehrt", ganz oder teilweise, gibt es wieder eine solche.


Abbildung 17.1-6: Neue Cloud-Schnittstellen und ihre Bewältigung durch die Prozessmodellierung

Inzwischen schreitet die Integration munter voran. Seit einigen Jahren unter dem Stichwort Robotic Process Automation (mit und ohne KI). Dazu mehr in Kapitel 19.

17.2 Dauerthema Integration

Fassen wir zusammen: Integration von Geschäftsprozessen und die damit verbundene Integration der IT sind ein Dauerthema. Nicht nur für das IT-Management der Organisationen, sondern auch für das Geschäftsprozessmanagement.

Die Integration von Geschäftsprozessen ist eingebettet in das Thema der ganz grundsätzlichen Integration der verschiedenen Anwendungssysteme, die insgesamt zur Gesamtleistung der IT beitragen. Damit lassen sich beim gegenwärtigen Stand der IT-Entwicklung drei Integrationsaufgaben feststellen:

  • IT-Integration: Integration der IT-Systeme im eigenen Unternehmen.
  • Prozessintegration: Integration der IT-Systeme entlang eines Geschäftsprozesses, auch über Unternehmensgrenzen hinweg - mit oder ohne Internet.
  • Cloud-Integration: Integration „mit der Wolke“ - Cloud Computing. Typischerweise, indem Angebote aus dem Web für die eigene IT genutzt werden, oder indem die eigene IT ganz oder teilweise ins Web verlagert wird.

Sucht man nach den Ursachen für diese Integrationsbemühungen, wird man schnell fündig: Es ist der von Beginn des IT-Zeitalters an beobachtbare Trend, der oben beschrieben wurde: ständige Ausdehnung der Prozessunterstützung durch die IT [Staud, 2006, Kapitel 2]. Heute gibt es kaum eine Aufgabe in den Unternehmen, die nicht von Anwendungssystemen unterstützt wird. Und dies bei der oben beschriebenen immer detaillierteren Unterstützung der Geschäftsprozesse durch die Anwendungssysteme, die inzwischen zur Automatisierung geführt hat (vgl. Kapitel 18, 19).

Ursache: Immer mehr, immer detaillierter

Weitere Integrationsbemühungen sind notwendig, falls Teile der IT-Leistung von Cloud-Angeboten bezogen werden. Nutzt man das Cloud Computing, ist meist zuerst Desintegration zu leisten: Bezieht man nicht die gesamte IT-Leistung auf diesem Weg, muss man Bereiche bestimmen, die man auf diese Weise auslagern möchte. Beispielsweise die wöchentlichen Versandaktionen, die gesamte Buchhaltung, die vierteljährliche Prognoserechnung oder auch gleich das gesamte Finanzwesen. Egal wie, anschließend muss diese Leistung in die übrigen Anwendungssystemen integriert werden. Welche Informationen werden hin gesandt, welche Aktionen werden von dort erwartet, welche Informationen sollen zurückkommen, usw. Auch dies muss die IT eines Unternehmens gegebenenfalls leisten.

Integration mit „der Wolke“

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.

WebServices

Die hier anstehenden Aufgaben löst in erster Linie das IT-Management. Das Geschäftsprozessmanagement sollte aber mitentscheiden. Z.B. bei Fragen mit strategischer 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?

IT-Management

Nicht-Integration bedeutet Defizite in der Prozess- und Datenintegration, die mit viel Aufwand überwunden werden müssen. Die Reibungsverluste äußern sich als großer Aufwand für alle Maßnahmen der Informationsweitergabe. Wenn z.B. von der Produktion Daten zum Vertrieb weitergegeben werden sollen, müssen die Formate jeweils umgewandelt werden. Falls die beiden Abteilungen unterschiedliche Hardware nutzen, muss auch dies überwunden werden.

Defizite in der Prozess- und Datenintegration

Damit ist die Integration der einzelnen Systeme (Hardware und Software) die große Herausforderung. Eine solche Integration ist notwendig, um eine weitere Optimierung der Geschäftsprozesse und der gesamten IT zu erreichen

Eine weitere Konsequenz der „Nicht-Integration“ von Datenbeständen sind oft Redundanzen. Werden z.B. Kundendaten in verschiedenen Datenbanken verwaltet, kann es leicht geschehen, dass im einen Datenbestand dieselbe Information anders festgehalten ist als im anderen.

Redundanzen

Ein weiterer Grund für Integrationsbemühungen ist der oben schon erwähnte Wunsch nach einer Automatisierung der Geschäftsprozesse (vgl. Kapitel 18, 19).

Automatisierung

Integration in allen Aspekten (Technik, Organisation, Geschäftsprozesse, Programme) ist also unabdingbar. Eine solche Integration von Anwendungssystemen wird auch unter dem Stichwort Enterprise Application Integration (EAI) diskutiert.

In den nächsten Abschnitten werden wichtige IT-Systeme, mit denen zentrale Prozessbereiche unterstützt werden, kurz vorgestellt.

17.3 ERP-Software

17.3.1 Definition

Wenn es um die IT-Unterstützung für die Geschäftstätigkeit geht, muss an ersten Stelle ERP-Software (Enterprise Resource Planning) genannt werden. Sie ist geradezu Ausdruck der Prozessorientierung, die vor ca. 50 Jahren [Anmerkung] einsetzte.

Bis Anfang der 1990er-Jahre wurden in den Unternehmen vorwiegend Großrechner- oder PC-Lösungen eingesetzt. Diese unterstützten aber meistens nur einen Teilbereich des Betriebes und waren nicht oder nur unzureichend miteinander integriert, wie in Abschnitt 17.1 gezeigt.

Mit dem Aufkommen leistungsfähiger Netze und Computer wurde der Einsatz integrierter Software möglich und auch gefordert. Die Entwicklung solcher integrierten Anwendungssysteme, die möglichst alle Unternehmensbereiche verbinden und abdecken sollen, benötigt eine große Kapazität an Entwicklungsressourcen und umfangreiche Kenntnisse in der Informationstechnologie und den Anwendungsbereichen, die nur wenige Softwareentwickler bieten können. Deshalb entwickelte man immer weniger „maßgeschneiderte“ Individualsoftware , sondern setzt auf gekaufte Software „von der Stange“, auf Standardsoftware. Im betriebswirtschaftlichen Bereich hat sich hier ERP-Software durchgesetzt.

Individualsoftware,
Standardsoftware,
prozessorientierte Standardsoftware

Dieser Softwaretyp hat sich, trotz aller Prognosen, die immer wieder ein baldiges Verschwinden ankündigten, bis heute bewährt. Er stellt für viele Organsationen das "Rückgrat" der IT dar. Diese Integrierte prozessorientierte Standardsoftware, die meist ERP-Software genannt wird, hat (idealtypisch) folgende Eigenschaften:

Der Text dieses Abschnitts fasst Ausführungen von [Staud 2006, Kapitel 3] zusammen.

  • Sie ist prozessorientiert in dem Sinn, dass sie ganze Geschäftsprozesse unterstützt und nicht nur einzelne Funktionen (wie z.B. eine Textverarbeitung).
  • Sie unterstützt alle Geschäftsprozesse des kaufmännischen bzw. betriebswirtschaftlichen Bereichs eines Unternehmens einschließlich der Produktionsplanung (1. Integrationsaspekt).
  • Sie ist für die konkreten Strukturen und Geschäftsprozesse vieler Unternehmen geeignet (2. Integrationsaspekt).

Mit den beiden Integrationsaspekten ist dieser Softwaretyp von Textverarbeitungen, Tabellenkalkulationen, usw. abgegrenzt, die ja auch als Standardsoftware bezeichnet werden.

ERP-Software ist 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 von Organisastionen (insbesondere Unternehmen) eine gemeinsame, integrierte und prozessorientierte Software zu erstellen. Dies beruht auf zwei Eigenschaften heutiger Geschäftsprozesse:

  • Die meisten Geschäftsprozesse sind standardisiert, d.h. sie laufen bei Wiederholung gleich ab und es gibt nicht zu viele Varianten (vgl. Kapitel 4).
  • Es gibt so viele Gemeinsamkeiten zwischen den Geschäftsprozessen verschiedener 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üllen. Die wichtigste ist, dass sie Modelle von Geschäftsprozessen in ihrer Datenbank und in ihren Programmen realisiert hat und dass diese - mithilfe entsprechender Analysen realer Geschäftsprozesse - den tatsächlichen Abläufen und Strukturen 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.

Modelle von Geschäftsprozessen

Deshalb ist es unvermeidlich, dass ERP-Software softwaretechnisch so realisiert sein muss, dass sie in einem gewissen Umfang an die realen Strukturen des jeweiligen Unternehmens angepasst werden kann. Diese Möglichkeit der Anpassung durch das Verstellen von Parametern ("Customizing", vgl. unten) 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 betriebswirtschaftlichen/kaufmännischen Bereiche einschließlich der Produktionsplanung umfassen.

Etwas genauer kann die Abgrenzung mit dem Ansatz von Scheer [Anmerkung] 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, Wertorientierten Abrechnungssystemen, Berichts- und Kontrollsystemen, usw.) unterscheiden. 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 Systeme abdeckt (ohne Forschung/Entwicklung und die eigentliche Produktionssteuerung) und sich auch zunehmend in die Berichts- und Kontrollsysteme hinein ausdehnt.

Genauere Agrenzung

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 verschiedenen betriebswirtschaftlichen Anwendungsprogramme gelingt.

2. Integrationsaspekt

Der 2. Integrationsaspekt meint den Umstand, dass ERP-Software vielen unterschiedlichen 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 Branche begrenzt, wird sie Branchensoftware genannt.

Branchensoftware

Das Gegenstück zu Standardsoftware ist Software, die für ein bestimmtes Unternehmen und die dort vorliegenden Abläufe und Strukturen gefertigt wurde. Sie wird Individualsoftware genannt und kann von den eigenen Entwicklern des Unternehmens oder von einem Softwarehaus stammen.

Individualsoftware

Anspruch und Customizing

Der Anspruch von ERP-Software, für viele (wenn nicht alle) Unternehmen geeignet zu sein, ist schon erstaunlich, denn betrachten wir, über eine größere Zahl von Unternehmen hinweg, einen bestimmten betriebswirtschaftlichen Anwendungsbereich, z.B. die Finanzbuchhaltung, die Auftragsabwicklung, die Kontaktbearbeitung oder das Personalwesen, so stellen wir fest, dass dieser in den einzelnen Unternehmen natürlich durchaus unterschiedlich gestaltet sein kann. Dies gilt selbst für Bereiche wie die Finanzbuchhaltung, die durch Vorschriften, gesetzliche Regelungen und betriebswirtschaftliche Theorien vorgeprägt sind, viel mehr aber für Gebiete wie Materialwirtschaft, Produktionsplanung, usw., die durch das Produkt, den Produktionsprozess, die jeweilige Firmenkultur und andere Dinge geprägt und daher sehr unterschiedlich sind. Die standardisierten Geschäftsprozesse sind deshalb in ERP-Software recht flexibel gestaltet, sodass man sie in gewissem Rahmen an die einzelnen Bedürfnisse in den Unternehmen anpassen kann. Man spricht dann von Customizing (vgl. unten).

Anpassund der Software an die realen Prozesse

Darüberhinaus hat sich in den vergangenen Jahrzehnten aber auch immer wieder gezeigt, dass der Leistungsumfang der jeweiligen ERP-Produkte nicht ausreichte und neue Softwarelösungen in die vorhanden IT-Architektur mit hinzu genommen wurden, von CRM-Lösungen bis zu den ganz aktuell diskutierten Softwarerobotern.

Ergänzungen

17.3.2 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ösende 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 „durchschnittlichen Geschäftsprozess“), die ebenfalls in der Software realisiert werden.
  • Eventuelle Miteinbeziehung neuer Methoden für den jeweiligen Geschäftsprozess (z.B. neuer Verfahren der Absatzplanung in den entsprechenden Geschäftsprozess)
  • Anbieten eines Instrumentariums, mit dem die Kunden dann ihre Variante der Geschäftsprozesse festlegen können (Customizing bzw. Parametrisierung)

Customizing

Mit dem Begriff Customizing wird, siehe oben, die Anpassung der Standardsoftware an die realen 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 z.B. Java, früher bei SAP ABAP) erledigt werden.

Anpassung Software an reale Prozesse

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

Reale Geschäftsprozesse und „Software-Prozesse“

Grundsätzlich sind für die Überwindung einer solchen Lücke folgende Vorgehensweisen denkbar:

1. Umfassende Anpassung der realen Geschäftsprozesse an die der ERP-Software.

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

Wahrscheinlich erscheinen die ersten beiden Lösungen als sehr radikal. Nichtsdestotrotz werden sie gewählt. Die erstgenannte z.B. bei Supportprozessen, die zweitgenannte 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 Einschnitt in die bis dahin vorhandenen Unternehmensabläufe und schafft von daher u.U. Akzeptanzprobleme bei den Nutzern. Außerdem entsteht ein erhöhter Schulungsaufwand, 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 Releasewechseln angehtangeht, die preiswerteste Lösung. Oft wird sie in Unternehmen gewählt, die auf eine rasche Entschärfung ihrer Kostensituation angewiesen sind.

Konsequenzen

Mit Releasewechsel werden Lieferungen einer neuen Version der Software mit wenigen oder vielen, manchmal auch grundlegenden Änderungen, bezeichnet. Sie erfolgen relativ oft (bei einzelnen Herstellern bis zu jährlich).

Viele Unternehmen entscheiden sich auch dafür, diese erste Lösung für die unterstü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 Individualsoftware (vor allem deren Ablauflogiken, weniger deren Oberflächen) und hat großen 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 aufwendiger gestaltet sich oft der Abgleich der veränderten Datenstrukturen. Natürlich gibt diese Variante aber die Möglichkeit, Profilverlusten aller Art energisch entgegenzutreten.

Reproduktion der „alten“ Software

„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ändert, 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 Standardsoftware 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 Standardsoftware meist sowieso dazu führt, sich mit den Geschäftsprozessen näher zu befassen, wird die Einführung dann gleich für Optimierungsvorhaben genutzt. Dieses Reengineering erfolgt dann unter gleichzeitiger Berücksichtigung der realen Geschäftsprozesse und denen der Standardlösung.

ISO-Zertifizierung

In vielen Unternehmen kommt noch ein vierter zu berücksichtigender Faktor hinzu, eine ISO-Zertifizierung. Da diese natürlich auch auf die Geschäftsprozesse Einfluss nimmt, müssen dann

  • reale Geschäftsprozesse,
  • die der Standardlösung,
  • die Optimierungswünsche und
  • die Zertifizierungsvorgaben

zusammengebracht werden.

17.3.3 Echtzeit und Datenintegration.

Wichtig für jede integrierte Software ist, dass die einzelnen Anwendungen umfassend miteinander verknüpft sind, sowohl bezüglich der Prozesse als auch der Daten. Auf den Punkt gebracht bedeutet dies, dass eine Information ab dem Zeitpunkt ihrer Entstehung überall dort zur Verfügung steht, wo sie benötigt wird. Erfolgt beispielsweise die Erfassung einer Lieferung im Wareneingang, wird nicht nur die Bestandsführung angepasst, sondern es erfolgt auch sofort die wertmäßige Verbuchung. Diese Verknüpfung erfordert eine leistungsstarke, voll integrierte Datenbank. Hier werden die Informationen für die Module redundanzfrei und konsistent gehalten, z.B. Materialien (Artikel), Lieferanten, Kunden, Mitarbeiter, Sachkonten, Kostenstellen, Aufträge, Bestellungen, Lieferscheine usw.

Umfassende Verknüpfung

In Richtung schnellerer Auswertungszeiten zielt die InMemory-Technologie (Hana) von SAP. Sie verbindet spezifische Hardware- und Softwaretechnologien, um die auszuwertenden Daten im Arbeitsspeicher zu halten. Damit werden die Auswertungszeiten stark verkürzt. Zum Einsatz kommt diese Technologie überall dort, wo große Datenmengen verarbeitet werden müssen, z.B. im Kundenbeziehungsmanagement oder bei der Auswertung von Daten aus dem Social Web.

17.3.4 Beispiel SAP

Das Softwarehaus SAP war das erste, das eine ERP-Softwarr angeboten hat, und es ist damit groß geworden. Das erste Produkt hatte die Bezeichnung R/2 und war eine Großrechnerlösung. Es hatte bereits den Charakter einer integrierten prozessorientierten Software, allerdings auf dem damaligen (Gründungsjahr SAP: 1972) Stand der Technik. Das Nachfolgeprodukt war R/3, eine Client/Server-basierte Software.

Inzwischen bietet das Unternehmen SAP eine Vielzahl von Produkten an. Eines davon, SAP Business One, ist für Kleine und Mittelständische Unternehmen (KMU) gedacht. Es weist das für heutige ERP-Software typische Leistungsspektrum auf (Abruf der Daten von der SAP-Webseite am 5.6.2013. Da hat sich bis heute (2020) natürlich auch einiges geändert, die Grundstruktur blieb aber gleich. Eine aktuelle Darstellung folgt.):

  • Integriertes Finanzmanagement (Buchhaltungs- und Finanzprozesse, Geschäftsabschlüsse erstellen, usw.)
  • Lagerverwaltung und Produktionsplanung (Lagerdatenverwaltung für Bestandsführung und Fertigungssteuerung)
  • Kundenbeziehungsmanagement (Unterstützung der Vertriebsprozesse vom Lead-Management bis zum Kundenservice)
  • Beschaffung (alle Beschaffungsprozesse)
  • Mobilität (Verwaltung von Aufgaben, Aktivitäten und Kundendaten mit dem mobilen Gerät)
  • Integrierte Berichtsfunktion und Business Intelligence (Erstellung von Berichten, Auswertung von Daten)

Durch den Einsatz der von der SAP entwickelten InMemory – Datenbanktechnologie (vgl. Abschnitt 17.8) sind teilweise Auswertungen in Realzeit möglich.

Eher auf größere Unternehmen zielt das Produkt SAP ERP. Dieses besteht aus folgenden Komponenten:

SAP ERP.

  • SAP ERP Financials,
  • SAP ERP Human Capital Management,
  • SAP ERP Operations,
  • SAP ERP Corporate Services.

SAP ERP Financials unterstützt die finanzwirtschaftlichen Prozesse und deckt kon­kret folgende Funktionen ab:

  • Finanzbuchhaltung und Controlling
  • Financial Supply Chain Management für die Auftragsabwicklung, den Cashflow und die Verwaltung des Umlaufvermögens
  • Treasury für die Verwaltung der finanziellen Mittel
  • Corporate Governance für die Verwaltung und die verbesserte Einhaltung gesetzlicher Vorschriften

SAP ERP Human Capital Management (SAP ERP HCM) unterstützt die Geschäftsprozesse im Personalwesen. Besondere Erwähnung finden auf den Webseiten der SAP die folgenden:

  • Personalanalyse – hier werden in Echtzeit Personaldaten zur Verfügung gestellt, mit allen Kosten und den ROI aus Personalprojekten,
  • Talent Management für die Personalentwicklung,
  • Workforce Process Management zur Gestaltung von Personalprozessen, auch auf einer globalen Plattform,
  • Workforce Deployment für den Personaleinsatz und die Auswertung der dabei anfallenden Daten.

SAP ERP Operations für die operativen Prozesse (bezogen auf Industrieunternehmen). Ausdrücklich nennt die SAP auch die damit gegebene Möglichkeit der Automatisierung dieser Prozesse:

  • Beschaffung und Logistik für alle anfallenden Prozesse, von Bestellanforderungen per Self-Service bis hin zur flexiblen Fakturierung und Zahlungsabwicklung sowie der Optimierung des physischen Materialflusses im Unternehmen.
  • Produktentwicklung und Fertigung für den gesamten Produktentwicklungs- und Fertigungskreislauf.
  • Vertrieb und Service für die kundenorientierten Prozesse, den Vertrieb von Produkten und Dienstleistungen, die Beratungsservices und die dafür evtl. erforderlichen internen Prozesse, beispielsweise die Berechnung von Provisionen und leistungsorientierten Vergütungen.

SAP Corporate Services für die Verwaltung von Immobilien, der Vermögenswerte im Unternehmen, von Projektportfolios, Geschäftsreisen, der Einhaltung von Umweltschutzauflagen, Gesundheitsvorschriften und Sicherheitsrichtlinien, von Qualität und Außenhandel. Konkret sind enthalten:

  • Immobilienmangement für die Erschließung von Bauland, Vermietung und das Immobilienmanagement.
  • Enterprise Asset Management für die Wartung und Pflege des Anlagevermögens. Enthalten sind Funktionen für regelmäßige Wartungsarbeiten, die Budgetierung von Wartungskosten, die planmäßige Ausführung von Maßnahmen und die Abwicklung von Freischalteverfahren.
  • Projekt- und Portfoliomanagement für das strategische Portfoliomanagement,
  • Reisemanagement zur Verwaltung von Geschäftsreisen.
  • Umwelt-, Gesundheits- und Arbeitsschutz in der Anwendung SAP Environment, Health, and Safety Management (SAP EHS Management), es erlaubt die Umsetzung der entsprechenden Strategien und rechtlichen Vorgaben auf lokaler Ebene sowie standort- und länderübergreifend.
  • Qualitätsmanagement für die unternehmensweite Umsetzung der hier geplanten Maßnahmen.
  • Außenhandel für die Verwaltung der internationalen Lieferkette, z.B. auch für den elektronischen Austausch von Daten mit den Systemen der entsprechenden Behörden.

Soweit ein kurzer Blick auf das Angebot der SAP. Diese Auflistung sollte den Leistungsumfang von integrierten Anwendungssystemen deutlich machen. Einen ähnlichen Leistungsumfang weisen auch die Produkte der anderen einschlägigen Softwarehäuser auf.

17.3.5 Aktuelle Situation

Nutzung von Cloud-Lösungen

Marc Pfeifer (Lufthansa Industry Solutions) skizziert die aktuelle Situation:

SAP C/4 HANA Suite (auch: SAP Customer Expereience Suite) besteht aus "fünf Clouds", die einerseits verknüpft sind, die aber "je nach Bedarf sepaat eingesetzt werdne können"

SAP

<<mehr und aktuelles in Kürze>>

17.3.6 Konsequenzen

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 Geschäftsprozessmanagement und IT-Management bedacht werden sollten.

Hat ein Unternehmen ERP-Software eingeführt, erfolgen Weiterentwicklung und Wartung außerhalb des eigenen Unternehmens. 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.

Fremdbestimmung

Dies realisieren derzeit aber nur sehr wenige und sehr große Unternehmen.Die Innovation ist im Wesentlichen 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 Softwareherstel­ler. 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.

Abhängigkeiten

Ein Unternehmen, das vor der Einführung von ERP-Software ein hervorragendes und auf dem Stand der Technik befindliches IT-System mit entsprechender Anwendungssoftware 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.

Profilverlust

In der Regel ist es aber so, dass ein so hervorragend ausgestattetes Unternehmen auf die Übernahme einer Standardlösung verzichten wird.

17.3.7 Vor- und Nachteile

Trotz der dominanten Position von ERP-Software kann man sich mit der Frage beschäftigen, was für und gegen ERP-Software spricht.

Dafür spricht u.a.:

Vorteile

  • Kosteneinsparung gegenüber Eigenentwicklung
  • Verkürzung der Einführungszeiten, da die Software sofort verfügbar ist
  • hohe Programmqualität aufgrund der größeren Erfahrung der Programmierer
  • Wartung und Weiterentwicklung der Software erfolgt durch den Anbieter
  • Anwendungen lassen sich auch realisieren, wenn kein oder nur unzureichend qualifiziertes DV-Personal im Unternehmen verfügbar ist; die eigenen Ressourcen werden geschont
  • mit der Software wird betriebswirtschaftliches Know-how, das in der Software abgebildet ist, in die Unternehmen gebracht

Demgegenüber stehen u.a. folgende Nachteile:

Nachteile

  • Wegen des Charakters als Standardsoftware sind evtl. die Geschäftsprozesse des Unternehmens nicht umfassend abgedeckt, insbesondere im Bereich der Kernprozesse der Unternehmen.
  • Der Leistungsumfang ist sehr groß, trifft aber nur teilweise die Bedürfnisse des Unternehmens, denn es handelt sich immer um eine Standardlösung.
  • Gewisse Unflexibiltät gegenüber Weiterentwicklungen, ganz aktuell z.B. gegenüber den Bemühungen um Prozessautomatisierung. Hier wird dann "ergänzt", vgl. Abschnitt 19.2.
  • Abhängigkeit vom Hersteller der Software. Angesichts des Leistungsumfangs und auch der preislichen Dimension sind die Kosten für einen Wechsel zu einer anderen ERP-Software sehr hoch. Braucht man – um nur ein Beispiel zu nennen – die InMemory-Technologie des derzeitigen Softwarehauses nicht wirklich, ist eine Vermeidung und/oder ein Wechsel recht schwierig.

Aktuelles Beispiel zum letztgenannten Punkt: Nach einer Studie der Hochschule Koblenz, steht derzeit (2019) in vielen Unternehmen die Frage des Umstiegs auf S/4 HANA an. Das Support-Ende für das Vorgänger Release ERP Central Componente (ECC) ist für 2025 angekündigt. Der Artikel zur Studie deutet auch die Probleme der Nutzer an, z.B. die Umstellung des Datenmodells. Mehr dazu in [Bayer 2019d].

Abschließend kann hier folgendes angemerkt werden. Zumindest bei den Supportprozessen ist es heute für ein Unternehmen nicht mehr möglich, ohne eine ERP-Software auszukommen. Eine Individualsoftware wäre heute hier schlicht zu teuer. Nicht so bei Kernprozessen. Hier sind in den Unternehmen tatsächlich sehr oft Eigenentwicklungen oder eine stark durch Anpassungen („Customizing“) veränderte ERP-Software anzutreffen. Betrachtet man die gesamte IT, ergibt sich also fast immer ein Zusammenspiel verschiedener Anwendungsprogramme, übrigens unter Umständen auch von Programmen verschiedener Anbieter von ERP-Software.

Ganz anders ist die Situation bei den großen Internet-Unternehmen. Hier wird in großem Umfang webbasierte Individualsoftware programmiert (vgl. Kapitel 20).

17.3.8 Perspektiven

Einen Eindruck von der aktuellen Situation rund um ERP-Software gibt [Bayer 2019c]. Auch hier wird deutlich, dass ERP-Software weiterhin für viele Unternehmen das Rückgrat ihrer IT darstellt.

<<mehr in Kürze>>

17.3.9 Nicht nur ERP-Software

Man könnte oben den Eindruck gewinnen, dass „nichts mehr geht“ ohne ERP-Software und dass sie völlig ausreicht für die Gestaltung der IT, so dass Eigenentwicklungen nicht mehr nötig sind. Die Umsätze der entsprechenden Softwarehäuser (SAP, Oracle, …) deuten auch in diese Richtung.

Dagegen spricht, dass tatsächlich in vielen Unternehmen (immer noch bzw. wieder) eigene Software entwickelt wird. Softwareentwicklung ist ein wichtiges Thema, ständig werden alte Entwicklungsplattformen verbessert, neue angeboten und neue Methoden vorgeschlagen (nur ein Beispiel: agile Entwicklung). Es ist tatsächlich so, dass ERP-Software (als integrierte prozessorientierte Software, die auf den betriebswirtschaftlichen Teil fokussiert) und andere Programme – auch eigenentwickelte – koexistieren. Der Grund liegt darin, dass durch die Ergänzungen der ERP-Software das IT-mäßige Leistungsprofil der Unternehmen ergänzt werden kann und oft auch ergänzt werden muss. Ganz aktueller Ausdruck hiervon sind die Bemühungen rund um Geschäftsprozessautomatisierung, z.B. das Einfügen von Softwarerobotern in vorhandene IT-Landschaften.

Individualsoftware – immer wieder

Es gibt auch Bereiche, in denen ERP-Software, so weit man einen Einblick gewinnen kann, keine dominante Rolle spielt. Dies sind die großen Internet-Unternehmen. Hier ist Individualsoftwaredominant. V.a. für die Durchführung der Geschäftstätigkeit. Mehr dazu in Kapitel 20.

Vor allem Individualsoftware

17.3.10 Die führenden Anbieter

Gemäß einer Gartner-Studie sind im Jahr 2018 folgende Unternehmen die führenden Anbieter im ERP-Markt:


Firma

Marktanteil

SAP

22%

Oracle

11%

Workday

7%

Sage

6%

Infor

5%

Microsoft

4%

Quelle: Computerwoche 2019, 34-35, S. 15.

 

17.4 Workflow-Management-Systeme


Wenn in der einschlägigen betriebswirtschaftlichen Literatur von IT-Unterstützung für Geschäftsprozesse die Rede ist, dann wird meist an Workflow-Management-Systeme gedacht (vgl. z.B. [Gadatsch 2015, Abschnitt 2.3], [Schmelzer und Sesselmann 2013]).

17.4.1 Definition

Ein Workflow ist ein ganz oder teilweise automatisierter Abschnitt eines Geschäftsprozesses. Laudon et al. sprechen diesbezüglich von Geschäftsvorfall, Vorgang und Arbeitsablauf. Er besteht aus einzelnen Aktivitäten und ist ausdrücklich auf der operativen Ebene angesiedelt, "idealerweise so exakt, dass die folgende Aktivität durch den Ausgang der jeweils vorangehenden determiniert ist." [Laudon, Laudon und Schoder 2010, S. 918].

Workflow

Ein Workflow hat einen definierten Anfang, einen fixierten Kontrollfluss und ein definiertes Ende. "Allgemein sind Workflows organisationsweite arbeitsteilige Prozesse, in denen die anfallenden Tätigkeiten von Personenen bzw. Softwaresystemen koordiniert werden." [ebenda]

Laudon et al. definieren dann Workflow-Management (WfM) wie folgt:

Workflow-Management

"Workflow-Management umfasst alle Aufgaben, die bei der Modellierung, Spezifikation, Simulation sowie bei der Ausführung und Steuerung von Workflows erfüllt sein müssen." [ebenda]

Das umfasst dann auch die Aufgabe, "eine Spezifikation für die technische Ausführung von Arbeitsabäufen zu liefern" und kann deshalb als "eine technische Umsetzung des Geschäftsprozessmanagements verstanden werden." [ebenda]

Workflow-Management beruht auf dem, was früher Vorgangsbearbeitung genannt wurde. Ein Vorgang (vgl. Abschnitt 2.2) besteht (hier) aus einer Folge von Tätigkeiten und, falls notwendig, dem Weg des Vorgangs über mehrere Arbeitsplätze. Dazu gehörten Entscheidungsalternativen, die zu Verzweigungen führten. Mehrere miteinander verknüpfte Vorgänge können dann zu dem führen, was hier Geschäftsprozess genannt wird.

Historische Seite

Workflow-Management war lange Zeit und ist auch heute noch im Ansatz dokumentenzentriert. Erfasst werden daher die differenzierten Befugnisse von Einzelnen oder Gruppen bzgl. der Bearbeitung der Dokumente auf dem Laufweg entlang des Kontrollflusses (lesen, ändern, löschen, usw.).

Dokumentenzentriert

Die Abwicklung der Workflows erfolgt mit Hilfe eines Workflow-Management-Systems (WfMS). Dies geschieht weitgehend automatisiert, die beteiligten Menschen realisieren (noch) nicht automatisierbare Vorgänge (z.B. kreativer Natur), treffen nicht automatisierbare Entscheidungen und greifen bei Sonderfällen ein.

Workflow-Management-System

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 automatisch 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 zusammen und arbeiten (mit oder ohne menschliche Unterstützung) den Geschäftsprozess ab. Da es ohne Kontrollfluss, Nachrichtenfluss usw. nicht geht, muss das Workflow-Management-System diesen realisieren. Es werden also entlang des vorgegebenen Kontrollflusses die einzelnen Prozessabschnitte angestoßen, Nachrichtenflüsse initiiert, usw.

Etwas konkreter kann die Aufgabe eines Workflow-Management-Systems so beschrieben werden: Arbeitsaufträge werden, einschließlich benötigter Informationen und Dokumente, dem zuständigen Mitarbeiter elektronisch übermittelt. Die einzelnen Schritte werden überwacht und protokolliert. Nutzer werden über neue Aufgaben informiert, bei Nichtbearbeitung erfolgen Warnhinweise. Teilprozesse ohne gegenseitige Abhängigkeit werden parallelisiert.

Etwas konkreter

Zuerst Geschäftsprozess-, dann Workflowmodellierung

Die Modellierung der Workflows baut auf der Prozessmodellierung auf. Ist diese kompetent durchgeführt (mit allen Informationsweitergaben, Geschäftsobjekten, usw.), ist die Abbildung in den Workflow nicht aufwendig. Hinzu kommt immer die Hinterlegung 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. Wurde die hier vorgestellte Standardprozessmodellierungdurchgefü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].

17.4.2 Softwareseitige Realisierung

Ein Workflow-Management-System beruht also auf einer IT-Lösung mit dem Workflow-Management-System und einer Hardwarebasis. Letzteres ist meist eine Client-Server-Architektur.

Diese Softwaresysteme wickeln Prozesse ab, indem sie die Ausführungsreihenfolge der Aktivitäten (des Kontrollflusses) eines Prozesses überwachen, Daten für die Ausführung einzelner Aktivitäten bereitstellen, anstehende Aktivitäten menschlichen oder technischen Bearbeitern zur Ausführung zuordnen und Anwendungssysteme für die Bearbeitung der Aktivitäten zur Verfügung stellen. Das Workflow-Management-System stößt dann die entsprechenden Bausteien an.

Ein weiteres wichtiges Architekturmerkmal für WfMS ist, dass sie zur Ausführung von Workflows diverse andere IT-Systeme aus den abgedeckten Bereichen einsetzen. Es gibt also neben der Software, die den Ablauf realisiert, verschiedene IT-Systeme, die zur Erledigung einzelner Aufgaben eingesetzt werden. Von Textverarbeitung bis zu prozessorientierter Software.

Die zentrale Komponente, die mit der Realisierung der Workflows beauftragt ist, wird Process Engine oder auch Workflow Engine genannt.

Process Engine

Bei dieser Architektur ist es leicht möglich, den Ablauf der Workflows automatisiert zu überwachen, z.B. zum Zwecke des Process Mining (vgl. Abschnitt 19.3). Stimmen dann die erreichten 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 konventionell programmierten Software (vgl. Abschnitt 21.1) und da liegt der Charme dieser Lösung. Alle diese Ansätze, die Gesamtaufgabe (den Gesamtprozess) 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. Vergleiche zu diesem Problem der Komplexitätsbewältigung Kapitel 22.

Überwachung

17.4.3 Automatisierungsstufen

Oben wurde schon ausgeführt, dass die Workflows eines Geschäftsprozesses in der Regel nicht vollständig automatisiert realisiert werden, so dass Automatisierungsstufen unterschieden werden können. Gadatsch beschreibt folgende Einteilung:

  • Stufe 0 – Manuelle Ausführung. Dabei werden die Geschäftsprozesse ohne IT-Unterstützung durchgeführt. Als Beispiel nennt er die Ermittlung des zuständigen Sachbearbeiters zu einer Kundenanfrage.
  • Stufe 1, Ad Hoc - Workflow. Geschäftsprozesse werden mit optionaler IT-Unterstützung ausgeführt. Z.B. bei einer Angebotsprüfung: Bearbeiter können freiwillige vorgeschlagene Tools verwenden.
  • Stufe 2, Fallbezogener Workflow. Die meisten Geschäftsprozesse werden computergestützt ausgeführt. Die Arbeitsabläufe sind weitgehend strukturiert, Teilaufgaben sind noch unstrukturiert. Das Anwendungssystem wählt eine geeignete Applikation aus und startet sie. Der Arbeitsablauf wird jedoch noch von individuellen Entscheidungen beeinflusst. Beispiel Antwortbrief: Ein Nutzer wird durch ein IT-System aufgefordert, einen Antwortbrief zu verfassen. Das Anwendungssystem startet selbstständig ein Textverarbeitungsprogramm.
  • Stufe 3, Allgemeiner Workflow. Alle Geschäftsprozesse werden computerunterstützt ausgeführt. Das IT-System wählt eine geeignete Applikation aus, startet sie und fügt vorhandene Daten ein. Die Arbeitsabläufe sind stark strukturiert, weisen Wiederholcharakter auf und sind vollständig spezifiziert. Beispiel Anlegen Kundenauftrag: Das Anwendungssystem startet die Transaktionen und füllt relevante Daten (Auftragsnummer, Kundennummer) selbstständig aus.
  • Stufe 4, Applikationsautomatisierung. Hier ist an einen vollständig automatisierten Ablauf der Geschäftsprozesse gedacht. Beispiel: Nach Lieferscheinerstellung wird durch das Anwendungssystem automatisch eine Rechnung erstellt.

Vgl. [Gadatsch 2012, Pos. 4359].

<<Klären Sie anhand von [Gadatsch 2012], welche Arbeitsabläufe in den einzelnen Stufen wohl typischerweise vorliegen.>>

17.4.4 Workflow-Management Coalition

Seit 1993 befasst sich die Workflow-Management Coalition (WfMC), eine Vereinigung von Forschungsinstituten, Hochschulen, Anwendern und Softwareherstellern, 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. Workflow-Management-Systeme sind somit auch hier "Softwaresysteme, deren Kernaufgabe die Unterstützung betrieblicher Prozessabläufe durch die Koordination von Aktivitäten, Anwendungen, Daten und prozessbeteiligten Personen ist" [zur Mühlen und Hansmann 2012, S. 367].

17.4.5 Beispiele

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

17.5 Serviceorientierte Architekturen

Vorbemerkung: Serviceorientierte Architekturen werden derzeit im Kontext der Geschäftsprozesse nicht diskutiert. Sie sind aber weiterhin von Bedeutung für die IT-gestützte Realisierung von Geschäftsprozessen.

Die Idee hinter dem Konzept der serviceorientierten Architekturen lässt sich kurz so beschreiben: 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 vorhandenen Software.

Idee

Die folgende Abbildung will dies ausdrücken. Dabei gehen wir von Geschäftsprozessen 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 17.5-1: Geschäftsprozesse realisieren mit Services.

Anmerkung: AS steht für Anwendungssysteme, Serv für einen Service, Web für die Herkunftsangabe.

Ein WebService ist eine unabhängige, in sich geschlossene Anwendung, die eine genau definierte Aufgabe erfüllt. Er kapselt Daten und Anwendungslogik und tauscht Nachrichten über eine standardisierbare Schnittstelle aus und steht im Web zur Nutzung zur Verfügung.

Grundlagen

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.

Wie kommt es nun zum Einsatz dieser WebServices. Stellen wir uns ein Zusammenspiel 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 gekoppelten Funktionsbausteinen mit klar umrissenen Aufgaben bilden [Mertens 2013, S. 16]. Dabei haben die drei Parteien folgende Aufgaben:

Serviceorientierte Architekturen.

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

Grundlage des ganzen Geschehens ist, dass Diensteanbieter ihre Services veröffentlichen, z.B. ein neues Programm zur Absatzprognoserechnung. Hat nun ein Nachfrager einen entsprechenden Bedarf, wird das Verzeichnis abgefragt und gegebenenfalls 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.

Ablauf

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 verschiedener einschlägiger WebServices. Nachdem ein Anbieter für die Anwendung gefunden wurde, können Nutzer und Anbieter eine Verbindung aufbauen und über das Internet miteinander kommunizieren. So können sie die gemeinsame Aufgabe erfüllen (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.

Beispiel

In der Literatur ist manchmal auch von 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 17.5-2: Grundstruktur einer serviceorientierten Architektur

Wird ein solches Anwendungssystem realisiert spricht man einer Serviceorientierten Architektur (SOA). Diese ist somit eine Form einer verteilten Informationsarchitektur, deren Fokus auf der Ankündigung, dem Auffinden und dem dynamischen Aufrufen von 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 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äftsprozessmanagement (fachlich).

Nutzen

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 Prozessabschnitten klar definierte Schnittstellen haben. Das sollten auch die oben angeführten Beispiele verdeutlichen.

Stand der Technik

Die Idee der Auslagerung von Services ins Web und die Vorstellung, den Geschä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 Vorstellung einer serviceorientierten Architektur an heterogene Systemwelten erinnert fühlt, hat nicht unrecht. Allerdings wird diese heutige heterogene Lösung auf einer anderen technologischen Basis realisiert als früher.

Integration

Beherrschbar wird diese Technologie, wenn es um klar abgegrenzte Aufgaben mit exakt definierten Schnittstellen zu den vor- und nachgelagerten Prozessabschnitten geht und wenn das Problem der Datenhaltung geklärt ist. Der einfachste Fall liegt vor, wenn dem WebService replizierte Daten übergeben werden (z.B. die monatlichen Absatzzahlen der letzten fünf Jahre) und wenn er fest definierte zurückliefert, die dann in die unternehmensweite integrierte Datenbank eingefügt werden (die Prognosen des Folgejahres).

Stellt man sich eine ganze Anwendungssoftware 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.

Durch Orchestrierung zum Kontrollfluss.

Betrachten wir als Beispiel die Lösung von SAP, NetWeaver . 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.

Stand 2016 war dieses Konzept Grundlage der allgemeinen ERP-Lösung von SAP:

Stand 2016

"SAP ERP is based on the architecture 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)

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 Geschäftsprozess, wobei existierende IT-Systeme und Anwendungen einbezogen werden. 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.

17.6 Weitere Anwendungssysteme

17.6.1 CRM

Begriff: Customer Relationship Management (CRM)

Kurzbeschreibung: Software für die integrierte Planung, Steuerung und Kontrolle der Kundenbeziehungen; Integration aller kundenbezogenen Prozesse in Marketing, Vertrieb und Service.

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

17.6.2 SCM

Begriff: Supply Chain Management (SCM)

Kurzbeschreibung: integrierte Planung, Steuerung und Kontrolle der innerbetrieblichen und zwischenbetrieblichen Lieferkette; Integration von Beschaffung, Herstellung und Lieferung von Produkten, Systemen, Anlagen und Dienstleistungen.

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

17.6.3 PLM

Begriff: Product Lifecycle Management (PLM)

Kurzbeschreibung: Integrierte Planung. Steuerung und Kontrolle von Produkten über ihren gesamten Lebenszyklus; Integration von Produktplanung, Produktentwicklung, Produktfertigung, Produktservice bis zur Produktausphasung.

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

17.6.4 EAI-Plattformen

In der konkreten Praxis heutiger IT-Lösungen ist es so, dass unterschiedliche Softwareprodukte zum Einsatz kommen. Z.B. neben einer ERP-Software noch weitere spezialisierte Softwaresysteme. Dies können die oben erwähnten oder andere sein, die ergänzend hinzugefügt werden. Grundsätzlich ist es in der Regel immer so, dass abhängig von der Branche und ihrer spezifischen Geschäftstätigkeit, das Leistungssprektrum der ERP-Software ergänzt werden muss.

Dies ist – vor allem bei Kernprozessen – auch Individualsoftware. Z.B. für die Produktion (bei Industrieunternehmen) oder für die Kundenkontakte (bei Internet-Unternehmen).

Individualsoftware

Seit einigen Jahren erfolgen Ergänzungen auch mit dem Ziel der Prozessoptimierung durch Softwareroboter (Bots). Auch diese müssen mit der übrigen Software in Kontakt auftreten. Vgl. dazu Abschnitt 19.2.

Softwareroboter

Eine sehr große Vielfalt an Softwarelösungen also, die im Zusammenspiel helfen, die Geschäftsprozesse der Organisation IT-gestützt zu realisieren.

Für das damit notwendige Zusammenspiel wurden sog. Enterprise Application Integration - Systeme (EAI-Systeme) entwickelt. Mit ihnen ist es möglich, unterschiedliche Softwaresysteme über klar definierte Schnittstellen zu verknüpfen. Dazu stellt ein EAI-Portal eine Benutzeroberfläche bereit, über die auf die einzelnen Anwendungen zugegriffen werden kann. Wichtigste Aufgabe dabei ist, die Datenweitergabe zwischen den Softwaresystemen zu realisieren. Dazu gehört die Anpassung der verschiedenen Datenformate und die konkrete Weiterleitung. Hierfür findet sehr oft XML Verwendung.

Enterprise Application Integration - Systeme

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

17.6.5 Eigenentwickelte Software

Es wurde mehrfach erwähnt. Individualsoftware ist "nicht tot". In vielen Bereichen der IT-Architekturen werden individuelle Softwarelösungen erstellt (in der Organisation selbst oder durch ein Softwarehaus). Die beeindruckendsten Beispiele finden sich bei den großen im Internet tätigen Unternehmen. Bei diesen Internet-Unternehmen entstand mit hohem personellen Aufwand eine leistungsstarke Software, die auch ständig weiterentwickelt wird und für die methodisch neue Lösungen entwickelt werden mussten. Vgl. dazu Kapitel 20.

Individualsoftware

Aber auch in anderen Organisationen finden sich Beispiele. Hier sind es oft Kerngeschäftsprozesse, für die eine leistungsstarke, die eigenen Erfolgsfaktoren sicherende Softwarelösung programmiert wird. Bei Industrieunternehmen sind dies oftmals Programme für die Produktion.

Für das Geschäftsprozessmanagement bedeutet dies folgendes:

  • Evtl. Nichtzuständigkeit, falls das Projekt ganz und gar im technischen Bereich angesiedelt ist, z.B. in der Produktion. Ein klein wenig Zuständigkeit entsteht aber meist doch, da solche Softwarelösungen heute und schon lange mit der übrigen IT integriert sein müssen. Dies haben schon Mertens und Scheer vor Jahrzehnten thematisiert.
  • Falls die zu unterstützenden Geschäftsprozesse in die Zustsändigkeit des "ganz normalen" Geschäftsprozessmanagements fallen, bedeutet Individualsoftware, dass erstmal geklärt werden muss, ob überhaupt eine (in der Regel teurere) Individualoftware erstellt werden soll oder ob auf eine Standardasoftware zurückgegriffen wird. Hier sollte neben der Geschäftsleitung und der Fachabteilung auch das Geschäftsprozessmanagement mitwirken.
  • Kommt es dann zur Individualsoftware muss das Geschäftsprozessmanagement bei der Anforderungsentwicklung mitwirken: Festlegung der Plattform (Cloud?), der fachlichen Anforderungen (zusammen mit der Fachabteilung), usw.

17.6.6 Electronic Business

Die globale Vernetzung über das Internet hat zu einer tiefgreifenden Veränderung der Märkte und der Geschäftstätigkeiten über dieses Medium geführt. Die Marktveränderungen sind durch folgende Punkte gekennzeichnet:

  • veränderte Kundenerwartungen
  • Kontakt mit potenziellen Kunden auf der ganzen Welt
  • verstärktes Angebot von Leistungen in elektronischer Form, insbesondere Aufbau von neuen Dienstleistungen wie Suchdienste, Agenten usw.
  • dramatische Senkung der Eintrittsschwelle für neue Wettbewerber
  • Entstehung neuer Geschäftsmodelle
  • Erweiterung der Geschäftsprozesse über Unternehmensgrenzen hinweg
  • neue Organisationsformen durch veränderte Wertschöpfungsketten

Anmerkung

Agenten sind Softwaremodule, die autonom, insbesondere in vernetzten Systemen, Aufgaben im Auftrag eines Nutzers zielgerichtet lösen (auch: Software-Roboter oder Soft-Bots).

Electronic Business (E-Business) hat somit eine große Bedeutung für Unternehmen gewonnen. Es wurde dadurch auch zu einem wichtigen Einflussfaktor für die Gestaltung der IT. Kein Unternehmen wird heute bei der Planung seiner IT-gestützten Geschäftsprozesse darauf verzichten können, die Anforderungen des E-Business zu berücksichtigen.

Mit dem E-Business hat sich die informationelle Umwelt von Organisationen grundsätzlich geändert. Während es noch vor einigen Jahrzehnten im Wesentlichen um überschaubare Kontakte zu Lieferanten, Kunden und staatlichen Verwaltungen ging, sind die Organisationen heute in die globalen Netzwerke, v.a. die des Internets, eingebettet, wovon die IT jeweils unmittelbar betroffen ist. Denn diese muss entweder die zusätzlichen Aufgaben mit übernehmen oder mit anderen Systemen kommunizieren.

Informationelle Umwelt

Für die elektronische Unterstützung von unternehmensübergreifenden geschäftlichen Aktivitäten gibt es zahlreiche Begriffe. Die beiden wichtigsten sind:

E-Business und E-Commerce

  • Electronic Business (kurz: E-Business) meint alle Geschäftsprozesse innerhalb und außerhalb von Organisationen, die mit elektronischen Medien über globale öffentliche und private Netze durchgeführt werden.
  • Electronic Commerce (kurz: E-Commerce) meint die kommerziellen Aktivitäten, die sich zwischen Marktteilnehmern/Handelspartnern abspielen. Er ist derjenige Teil des E-Business, der auf die Vereinbarung und Abwicklung rechtsverbindlicher Geschäftstransaktionen ausgerichtet ist.

Vereinfacht kann man sagen, dass E-Business die elektronische Geschäftsabwicklung und E-Commerce den elektronischen Handel umfasst. E-Commerce ist damit ein Teil vom E-Business.

Die Aktivitäten im E-Business sind sehr zahlreich, neben dem E-Commerce sind auch die elektronische Beschaffung (E-Procurement), z.B. über Online-Kataloge, Portale, Online-Auktionen, der elektronische Zahlungsverkehr (E-Banking) sowie der Online-Vertrieb (z.B. über Online-Shops) und das Online-Marketing besonders zu erwähnen. Letztlich läuft die elektronische Unterstützung all dieser Aktivitäten auf eine unternehmensübergreifende Integration von Geschäftsprozessen und damit von IT-Systemen hinaus. Nur so können moderne Produktions- und Logistikkonzepte auf der einen Seite, sowie ein konsequent kundenorientiertes Informationsmanagement auf der anderen Seite, sinnvoll verwirklicht werden.

Für das Geschäftsprozessmanagement stellen sich in diesem Zusammenhang v.a. zwei Fragen;

  • Ausmaß der Nutzung "des E-Business" für die eigene Geschäftstätigkeit
  • Form der Realisierung: Cloud-Lösung, "eigene Lösung", usw.

17.7 Cloud Computing

Zuerst von nicht wenigen belächelt, inzwischen Realität. Die moderne Form des Outsourcing hat sich ihren Platz erkämpft. Sie reicht von der Einbeziehung einzelner Funktionalitäten („Prognoserechnung“) oder ausgewählter Geschäftsprozesse (Mailing-Aktion, Finanzwesen) bis zur Nutzung vollständiger ERP-Software „aus der Wolke“. Man kann dort ganze Plattformen, einzelne Server oder bestimmte Programme buchen und nutzen.

Cloud Computing meint die Nutzung großer Servicerechenzentren, die mit starken Leitungen „irgendwo“ im Internet“ platziert sind und über das Internet nutzbar sind. Für immer mehr Unternehmen stellt sich die Frage, ob und welche IT-Leistung von diesen Rechenzentren bezogen werden sollte. Denn das Angebot ist verführerisch:

Um was geht's?

  • Die in Anspruch genommene Leistung ist leicht skalierbar.
  • Kein Betrieb eigener Hardware ist notwendig, keine eigenen diesbezüglichen Aufwendungen.
  • Durch die Möglichkeit der Virtualisierung in den Servicerechenzentren der Cloud u.U. eine Lösung, die dem Kunden wie eine individuelle anmutet (eigener Entwicklungsserver, eigene ERP-Software)

Voraussetzung ist natürlich ein leistungsstarkes Servicerechenzentrum in „der Cloud“ (oder auch mehrere verteilte), das gegen die vielfältigen Risiken dieser Zeit abgesichert ist (was in den letzten Jahren nicht immer der Fall war). Dann entsteht die Win-Win-Situation, die dem Erfolg dieses Outsourcing-Angebots zugrunde liegt: Die Nachfrager nach IT-Leistung sparen den Aufwand für eine IT, die oftmals nicht ausgelastet ist, der Cloud-Anbieter kann durch die Vielzahl seiner Kunden und durch die Virtualisierbarkeit eine hohe Auslastung erreichen.

Natürlich können hier keine maßgeschneiderten Lösungen für Kernprozesse erwartet werden. Es ist aber nicht risikoreich, zu prognostizieren, dass in der Zukunft immer mehr Software für die Supportprozesse in „die Cloud“ verlagert werden wird.

Supportprozesse

IT-gestützte Geschäftsprozesse können also – grob gesagt - auf der organisationseigenen Hardware, in einem externen Rechenzenrum "in der Nähe" oder "in der Cloud" realisiert werden. Dabei haben die Cloud-Lösungen in den letzten Jahren ständig an Bedeutung gewonnen. Sie sind also auch ein Thema für ein zeitgemäßes Geschäftsprozessmanagement.

Plattformen

Die Cloud-Rechenzentren sind inzwischen so umfangreich und leistungsstark, dass von Serverfarmen gesprochen wird. Angemerkt werden muss, dass diese Geschäftsidee nur funktionieren konnte, weil die Übertragungsleistung des Internet in den letzten Jahrzehnten ständig ausgebaut wurde und inzwischen sehr groß ist, denn die Kunden verlangen sehr kurze Antwortzeiten.

Serverfarmen

Die so angebotene Rechnerleistung ist typischerweise skalierbar, d.h. man kann auf einfache Weise mehr oder weniger Leistung „buchen“. Wenn also z.B. für eine Marketingaktion vorüberhend mehr Rechenkapaziät benötigt wird, kann dies auf einfache Weise hinzugebucht werden. kann problemlos an eine vorübergehende Lastspitze (intensives Testen der neuen Software, Erstellung des wöchentlichen „Builds“, …) angepasst werden.

Skalierbarkeit

Dieses Angebot wird Cloud Computing genannt [Hansen und Neumann (Hrsg.) 2009, S. 268] . Dabei steht der Begriff cloud 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. Will man dies nicht, muss man einen Cloud-Anbieter wählen, der explizit mitteilt, wo seine Serverfarmen stehen. Auch dies wird, gerade in Deutschland, inzwischen angeboten.

Begriff

Cloud Computing ist eine moderne Form des Outsourcing, d.h. des Auslagerns von IT-Leistung zu einem anderen Unternehmen (so wie der Steuerberater u.U. seine Buchungen von der DATEV machen lässt).

Zu dieser Entwicklung kam es, als große Internet-Unternehmen im B2C bemerkten, 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“.

Ursprung

Vorreiter war hier Amazon. Inzwischen haben zahlreiche andere Unternehmen, z.B. Microsoft und IBM nachgezogen und ebenfalls solche Serverfarmen aufgebaut, auch mit anderen Rahmenbedingungen (z.B. mit regionalen Festlegungen).

Beispiel VW Industrial Cloud (Quelle: [Bayer 2019b, S. 8f])

Wie sehr das Cloud Computing in die Realität der heutigen IT auch globaler Unternehmen vorgedrungen ist, zeigt ein Beispiel von Volkswagen. Im April 2019 konnte man lesen, dass VW mit Amazon Web Services (AWS) eine Kooperation vereinbart hat. Dabei geht es um eine "Industrial Cloud" über sämtliche Fabriken des Konzerns hinweg. In ihr sollen "die Daten aller Maschinen, Anlagen und Systeme aus sämtlichen 122 Fabriken des Konzerns zusammenlaufen" [ebenda]. Motivator ist das Ziel, dass die Anlagen bis 2025 "um ein Drittel produktiver arbeiten sollen als heute".

"Dabei soll die "IT auf der Fertigungsebene von Maschinen, Anlagen und Systemen - etwa für die Produktionsplanung und Lagerhaltung - … über alle 122 Fertigungsstatten des Konzerns hinweg einheitlich gestaltet und verknüpft werden."

Die Zusammenarbeit geht aber noch weiter: "Konkret ist geplant, in den Bereichen Internet of Things (IoT), Machine Learning und Computing Services auf Amazon-Technologien aufzusetzen, die speziell für das Produktionsumfeld entwickelt und für die Anforderungen der Automobilindustrie erweitert werden sollen. Als Architekturbasis dient die neue Digital Production Platform (DPP) der Niedersachsen, an die künftig alle Standorte im Konzern wie auch weitere Unternehmen andocken sollen. Diese Plattform soll den system- und werksübergreifenden Datenaustausch vereinheitlichen und vereinfachen. Dazu zählten eine effizientere Steuerung des Materialflusses, die frühzeitige Erkennung und Korrektur von Lieferengpässen und Prozessstorungen sowie eine optimierte Fahrweise von Maschinen und Anlagen in jeder Fabrik. Darüber hinaus erhofft man sich bei VW, neue Technologien und Innovationen schneller und standortübergreifend bereitstellen zu können.

"Mit Hilfe intelligenter Robotik und Analytics wollen die Wolfsburger werksübergreifend Prozesse analysieren und vergleichen. Zudem ließen sich neue Anwendungen, zum Beispiel in der IT-Sicherheit für Anlagen, über die Cloud-basierte Plattform direkt auf alle weltweiten Standorte skalieren Der Autobauer will an dieser Stelle auch auf Best-Practice-Erfahrungen von AWS setzen.

Die Volkswagen-Verantwortlichen planen sogar noch weiter. Die Industrial Cloud werde als offene Plattform angelegt. Langfristig gehe es auch um die Integration der globalen Lieferkette des Konzerns mit über 30.000 Standorten und mehr als 1500 Zulieferern und Partnerunternehmen."

17.8 InMemory

Auch bei diesem Thema stellt sich die Frage, was es mit Geschäftsprozessmanagement zu tun hat, denn es geht ja in erster Linie um eine neue und in mancherlei Hinsicht effizientere Datenbanktechnologie. Nun, die Antwort ist schnell gegeben. Jeder Geschäftsprozess benötigt Daten und damit Datenbanken. Die Menge der Daten wurde in den letzten Jahrzehnten immer umfangreicher und ihre Verarbeitung mit klassischen Datenbanktechnologien immer mühsamer. Denken wir nur an den Wunsch, operative und strategische Daten integriert zu verwalten. Dieser Leidensdruck führte zur Entwicklung von InMemory-Datenbanksystemen.

Hintergrund

Ausgangspunkt für die Entwicklung dieser Datenbanktechnologie waren die großen Datenmengen aus dem Customer Relationship Management (CRM) und anderswoher, deren Speicherung, Verwaltung und Auswertung mit den in den Unternehmen vorliegenden (i.w. relationalen) Datenbanken und der klassischen Hardwarearchitektur nur mit Mühe zu bewältigen ist. Da die heute für Computer dominante von Neumann – Architektur die strikte Trennung der Arbeitsspeicher und der peripheren Speicher vorsieht, stellt sich der Datenverkehr zwischen diesen als Engpass heraus, trotz Cache und anderer Techniken zur Zugriffsbeschleunigung. Deshalb kam schon früh die Idee auf, die Datenbank in den Arbeitsspeicher zu laden und die Verarbeitungsschritte dort durchzuführen.

Ausgangspunkt

Der Unterschied zwischen herkömmlichen Datenbanksystemen und InMemory-Datenbanksystemen ist also, dass nicht der Festplattenspeicher zum Lesen und Schreiben der Daten verwendet wird, sondern der Arbeitsspeicher, in den die Datenbank geladen wurde. Die Festplatte bekommt dann die Aufgabe der Sicherung und – falls notwendig – der Wiederherstellung. Denn ein Arbeitsspeicher ist ja recht flüchtig. Die Vergrößerung des Arbeitsspeichers erfolgt durch den Einsatz von Bladeservern mit Multi-Core-CPUs und Hauptspeicher in der Größe von Terabyte.

Daten im Arbeitsspeicher

Der wichtigste Vorteil einer solchen Lösung ist die Verkürzung der Zugriffszeiten. Diese sind beim Arbeitsspeicher um einiges kürzer als bei Festplatten (unabhängig davon, ob es sich um eine Magnetplatte oder eine SSD handelt). Dadurch können die Datenbankoperationen und die Auswertungen signifikant schneller erfolgen. Mit einer entsprechenden Lösung ist es möglich, riesige Datenbestände bei gleichzeitig hoher Anzahl von Abfragen und trotz der Nutzung durch sehr viele Nutzer in angenäherter Echtzeit zu verarbeiten und zu analysieren.

Zugriffszeiten

Eine weitere Besonderheit dieser Anwendungssysteme besteht im Aufbau der In-Memory-Datenbank . Entgegen den relationalen Datenbanksystemen, wo die Daten zeilenweise gespeichert werden, verfolgt die In-Memory-Datenbank-Technologie meist eine spaltenorientierte Speicherung der Daten (vgl. [Staud 2015, Abschnitt 24.11]) beziehungsweise eine Kombination aus beiden Techniken.

Andere Datenstruktur

Falls zum Datenmodell auch aggregierte Daten gehören (z.B. bei Data Warehouse - Lösungen) können bei diesen Datenbanken und ihren Systemen diese aus den Basisdaten bei Bedarf berechnet werden. Die Aggregate werden also nicht vorher berechnet und gesondert gespeichert (wie ansonsten in Business Intelligence / Data Warehousing), sondern bei Bedarf (wenn eine entsprechende Datenauswertung ansteht).

Die hohe Zugriffsgeschwindigkeit erlaubt nicht nur obiges, sondern ganz generell Auswertungen in Echtzeit oder, falls die Auswertungen sehr umfangreich sind, wesentlich beschleunigt. Wenn z.B. Millionen von Belegen bei einer Krankenversicherung auszuwerten sind, bedeutet dies Minuten statt Stunden.

Diese Leistungsstärke erlaubt Lösungen, an die vor Einführung dieser Technologie nicht zu denken war, z.B. die Einrichtung einer einzigen Datenbank für operative und analytische Daten. Operative Daten werden typischerweise in einem OLTP-Datenbanksystem verwaltet (vgl. [Staud 2015, Abschnitt 24.1]). Für ein OLAP-System (ebenda) werden dann ausgewählte Daten mittels eines ETL-Prozesses periodisch in ein OLAP-Datenbanksystem geschrieben. Bei InMemory-Technologien ist diese Trennung von OLTP und OLAP teilweise aufgehoben, so dass die Anfragen in Echtzeit realisiert werden können.

Bei sehr großen Datenbeständen ist für InMemory-Datenbanksysteme an Parallelverarbeitung gedacht. Eine solche Parallelrechner - Architektur erlaubt, Datenbankoperationen gleichzeitig auf mehreren Hauptprozessoren auszuführen. Dies erhöht die Leistungsstärke solcher datenverwaltender Systeme nochmals deutlich.

Es gibt inzwischen zahlreiche Anbieter von ERP-Software und Datenbanksystemen, die Produkte mit InMemory-Technologie anbieten, darunter ORACLE und SAP. Das bekannteste ist SanssouciDB von SAP, eine Kombination aus relationalen und spaltenorientierten multidimensionalen Datenbanktechnologien. Vgl. für eine Beschreibung [Plattner und Zeier 2011, S. 41ff].

Beispiele

17.9 Microservices

Xxx“ iX 2/2021 S. 146f : „Microservices helfen Softwarearchitekten und Entwicklern, die Komplexität zu bändigen, die in modernen Softwarelandschaften gelegentlich Verwirrung stiftet. Das liegt vor allem daran, dass sich die eingesetzten Systeme aus unzähligen Komponenten zusammenfügen, die nicht immer gut miteinander auskommen. Wer die komplizierten Zusammenhänge besser verstehen möchte, kann sich aus einem großen Angebot an hilfreichen Büchern bedienen.

In „Distributed Tracing in Practice“ beschreiben die vier Autoren zunächst das Nachverfolgen des Systemverhaltens, was in einer MicroservicesArchitektur schwierig ist, weil man nicht einfach einen Debugger irgendwo einhängen kann. Großunternehmen wie Google begegnen diesem Problem seit einigen Jahren mit Tracing-Programmen, die den Verlauf einer Nachricht durch das System verfolgen. Der Entwickler bekommt detaillierte Informationen darüber, in welchem der vielen Gerätschaften es ruckelt und knirscht.

 

Das Buch von Wolfgang Golubski demonstriert ebenfalls das Erzeugen von Microservices. Da sich Java „ohne alles“ dazu nicht gut eignet, entscheidet sich der Autor für Spring Boot. Das Webframework hilft dem Entwickler bei vielerlei Dingen. Dazu gehören das Erstellen von RESTAPIs, das Verarbeiten von Ereignissen, das Implementieren von Dependency Injection, das Reduzieren der Programmkomplexität und das Einhalten des Model-View-Controller-Designs.

Ethan Garofolo geht anders heran an die Architektur: Seine Systeme kommunizieren nach den Regeln der eventorientierten Programmierung. Daraus ergibt sich zum Beispiel der Bedarf, eine als Message Store bezeichnete Datenbank zu erzeugen, die Nachrichten vorhält und verwaltet. Der Autor setzt auf das Standardwerkzeug MessageDB. Auch sonst gibt der behandelte Stoff keinen Anlass zur Klage. Es geht um den praktischen Betrieb, die Fehlersuche und automatisierte Funktionstests. Die Codebeispiele nutzen durch die Bank die aktuelle Version von JavaScript. Ein Appendix zur neuen Syntax von ECMAScript 6 mildert den Sprung ins kalte Wasser etwa ab.

Michael Geers ist vor allem für seine Webseite micro-frontends.org bekannt und schickt nun als Buch „Micro Frontends in Action“ hinterher. Hinter der Idee der Micro Frontends steckt, dass man die Anwendungsseite einer Webapplikation aus verschiedenen Komponenten zusammensetzen darf, und das auch noch mit verschiedenen technischen Methoden. Was zunächst wie eine Einladung zum totalen digitalen Chaos klingt, erweist sich in der Praxis schon deshalb als vorteilhaft, weil jedes Team so die Technik verwenden kann, die für die speziellen Bedürfnisse am besten geeignet erscheint. „

 

 

 

 

 

 

17.10 Schattenseiten?

Die IT-Unterstützung von Geschäftsprozessen, deren mögliche Strukturen hier skizziert wurden, ist heute unabdingbar. Es ist heute keine Organisation denkbar, die ohne eine solche auskommt. Wenn es hier also um Schattenseiten dieser Entwicklung geht, dann nur in dem Sinn, dass die gewählten Realisierungen Risiken bergen oder noch Verbesserungsbedarf haben.

Diskutieren wir die folgenden Punkte.

Zementierung

Jedes Abbilden von Geschäftsprozessen 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.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Abhängigkeit

Die Abhängigkeit der Organisationen von ihren Softwarelieferanten war schon immer sehr groß. Dies ist inzwischen noch verschärft. Viele der neuen Lösungen führten zu einer größeren Abhängigkeit vom jeweiligen Anbieter. Z.B. bei Cloud-Lösungen. Der Wechsel eines nennenswerten Teils der IT-Lösung vom einen zum anderen Cloud-Rechenzentrum ist nicht so einfach, wie es viele versprechen.

Oder der Wechsel des ERP-Anbieters. Dieser war schon immer aufwendig. In Zeiten von InMemory-Lösungen ist er noch schwieriger, auch weil dabei auf standardisierte Lösungen verzichtet wird. Es sind ja jetzt nicht mehr relationale Datenbanken, die im Fall des Falles migrieren müssen und deren grundsätzliche Struktur durch Standards und eine Theorie einigermaßen gefestigt ist, sondern Lösungen ohne einen solchen Hintergrund. Dies führt letztendlich zu proprietären Lösungen, die durch spaltenorientierte Dateistrukturen bzw. Speichertechniken nicht weniger proprietär werden.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Rückkehr der Insellösungen

Es gab eine Zeit, da wurde die Überwindung von Insellösungen als großer Fortschritt gefeiert. Das war die Phase der Einführung von ERP-Software. Inzwischen wird doch recht "ungebremst" wieder zu Insellösungen gegriffen. D.h. Programme für die Prozssabwicklung werden zusammengefügt, Schnittstellen müssen definiert und gepflegt werden.

Dies geschieht im Übrigen noch "ungebremster" im Rahmen der Automatisierung von Geschäftsprozessen, vgl. die nächsten zwei Kapitel.

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

Eigene Kompetenz

Aktuelle Lösungen für die IT-Unterstützung der Geschäftstätigkeit basieren oftmals auf Cloud-Lösungen. Dies kann zu einem Abbau von IT-Kompetenz in der eigneen Organisaion führen.

<<Diskussion: Einschätzung, Wirkung, Bewältigung. Z.B.: Soll man in der eigenen Organisation IT-Kompetenz vorhalten? Soll man verzichten. Was ergeben sich für Konsequenen aus dem einen oder anderen.>>

18 Automatisierung von Geschäftsprozessen

18.1 Automatisierung

Im vorigen Kapitel wurde ausgeführt, wie IT-Unterstützung von Geschäftsprozessen heutzutage realisiert wird. Die Entwicklung der IT hat allerdings einen Stand erreicht, der es möglich macht, Geschäftsprozesse nicht nur durch IT-Systeme zu unterstützen, sondern sie so weit wie heute möglich automatisch zu realisieren. Diese Automatisierung von Geschäftsprozessen ist in einigen Bereichen schon sehr weit fortgeschritten und wird immer weiter getrieben.

Konkret bedeutet Automatisierung hier, dass die Aktivitäten eines Geschäftsprozesses umfassend (einschließlich benötigter Informationen) in Elemente eines IT-Systems abgebildet werden. Dies kann auf unterschiedliche Weise erfolgen:

Um was geht's?

  • Durch klassische konventionelle Programmierung
  • Durch Programmierung im Internet-Kontext
  • Durch Entwicklung und Weiterentwicklung von Workflow-Management-Systemen
  • Durch verbesserte Integration IT-gestützter Prozesse mittels Robotic Process Automation

Mehr dazu unten.

Grundlagen, wie kam es dazu?

Nur damit wir es nicht vergessen. Die wichtigste Grundlage für die Automatisierung ist die Entwicklung der IT, hardware- und softwaretechnisch. Ohne diese wären die entsprechenden Softwarelösungen nicht möglich.

Technologische Grundlagen

Seit einigen Jahren gehört dazu auch die Entwicklung der Internettechnologie. Auf dieser werden in großem Umfang und mit riesigen Datenmengen Geschäftsprozesse automatisiert abgewickelt.

Dieser Entwicklung liegen die in Abschnitt 2.7 beschriebenen Trends zugrunde. Schon seit dem Aufkommen prozessorientierter integrierter Software (heute meist ERP-Software genannt; vgl. Abschnitt 17.3 sowie [Staud 2006] für eine Einführung) 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 Prozessmodellierung. Seit Aufkommen der Internet-Unternehmen kam ein zweiter massiver Trend dazu, der zu vollständig durch Programme abgewickelten Geschäftsprozessen führt – zur Automatisierung also.

Immer detaillierter

Voraussetzung für den Einsatz ist wie immer, wenn es um Automatisierung geht, dass es sich um einen standardisierten und wohlstrukturierten Prozess mit hoher Wiederholzahl handelt. Dazu unten mehr.

Voraussetzung

18.2 Ausgangspunkte

Die aktuellen Bemühungen zur weiteren Automatisierung von Geschäftsprozessen haben folgende Ausgangspunkte:

  • Menschgestützte Geschäftsprozesse mit gar keiner oder höchstens funktioneller IT-Unterstützung. Heute eher selten.
  • Menschgestützte Geschäftsprozesse mit IT-Unterstützung. Diese ist heute meist prozessorientiert, z.B. auf Basis einer ERP-Software.
  • Bereits teilweise automatisierte Geschäftsprozesse mit minimalem menschlichem Einwirken (sprach- und textgestützte Kundenkontakte, Entscheidungen, unstrukturierte Probleme, …). Bei diesen geht es darum, die Automatisierung weiter zu treiben. Konkret um Prozessabschnitte, die aufgrund von Fortschritten in der IT (insbesondere der Softwareentwicklung) jetzt auch automatisiert werden können (z.B. durch neue KI-Techniken zu Sprach-/Textverstehen, Sprach-/ Textproduktion, usw.).

Außerdem ist zu unterscheiden, auf welchem Träger die digitalisierten Geschäftsprozesse realisiert werden. Wenn auch z.B. die genutzten Programmiertechniken letztendlich auf dieselben Algorithmen bzw. Strukturen zurückgehen, macht dies doch einen Unterschied (dazu unten mehr). Folgende können derzeit unterschieden werden:

Träger

  • "Das Internet" mit den Internet-Unternehmen, wo inzwischen ein nicht unerheblicher Teil der Geschäftstätigkeit realisiert wird. Hier werden Web-Programmiertechniken verwendet. Außerdem gilt für Internet-Unternehmen, dass die Automatisierung sehr weit fortgeschritten, gegenüber den Kunden sogar umfassend realisiert ist, so dass die weiteren Bemühungen von einem hohen Stand ausgehen.
  • Die IT-Systeme von Organisationen und Unternehmen, im eigenen Unternehmen oder ausgelagert.

18.3 Prozessanalyse

Grundsätzliche Anforderungen

Unabhängig davon, auf welchem Weg und auf welchen Plattformen die Automatisierung angestrebt wird, ist zu Beginn eine umfassende Prozessanalyse und Prozessmodellierung nötig. Zu dieser gehören:

Umfassende Prozessanalyse

  • Eine umfassende Istanalyse und Istmodellierung. Da automatisierte Geschäftsprozesse in Software abgebildet werden, sollte die Prozessmodellierung detailliert sein. Es gibt auch die Vorstellung, Prozessmodelle automatisch zu erzeugen, vgl. Abschnitt 19.2 (Process Mining).
  • Klärung der Thematik "Prozess vs. Funktion"
  • Falls gewünscht, ein optimierter Vorschlag, eine Sollmodellierung. Dann ist dieser der Ausgangspunkt der Automatisierungsbemühungen.
  • Falls gewünscht, eine programmnahe Prozessmodellierung, als Beitrag zum Requirements Engineering der (Prozess-)Softwareentwicklung.
  • Klärung des Prozesstyps bezüglich der Problemstruktur.
  • Klärung der Häufigkeit. Nur bei häufig realisierten Prozessen lohnt sich der Aufwand.
  • Klärung der Rentabilität: Lohnt sich der Aufwand für die Automatisierung?
  • Falls der Prozess bereits IT-gestützt ist: Bestimmung der Softwareprodukte, mit deren Hilfe er realisiert ist.
  • Klärung der Automatisierbarkeit beim aktuellen Stand der Technik

Als Ergebnis sollte eine Klärung aller Prozessabschnitte, die automatisiert werden können (und sollen), erfolgen:

Ergebnis

  • Gar keine – unstrukturierte Abschnitte und Geschäftsprozesse. Keine Automatisierung ist möglich. Z.B. bei kreativen Prozessen ("Fortschreibung der Geschäftsstrategie").
  • Einige – wohlstrukturierte Abschnitte in semistrukturierten Geschäftsprozessen.
  • Alle – der gesamte Prozess ist wohlstrukturiert und automatisierbar.

Vgl. zum Thema Art der Problemlösung (unstrukturiert, semistrukturiert, wohlstrukturiert) Abschnitt 2.4.

Bei IT-gestützten Geschäftsprozessen

Bei nicht automatisierten IT-gestützten Geschäftsprozessen liegen typischerweise mehrere Softwareprodukte vor, die den Prozess unterstützen und deren Zusammenspiel nicht automatisiert ist.

Es geht hier also immer um das verbesserte Zusammenspiel von Softwarekomponenten, über verbesserte Schnittstellen oder roboterähnliche Software. Schnittstellen heute – sozusagen.

Bei diesen Voraussetzungen ist folgendes zu leisten:

  • Klärung, welche Aufgaben bereits softwaregestützt realisiert werden. Dies kann auf Basis einer detaillierten Standardprozessmodellierung erfolgen. Im Prozessmodell wird also angegeben, durch welche Software die jeweilige Aufgabe unterstützt wird.
  • Klärung der Prozessabschnitte, die automatisiert werden sollen. Dies kann Prozessabschnitte im bereits IT-gestützten Geschäftsprozess betreffen oder in den nicht-unterstützten.
  • Beachtung der Thematik "Prozess vs. Funktion", weil dies oftmals zur (automatisierten) Hinzunahme externer Software führen kann.
  • Eine auszugsweise programmnahe Prozessmodellierung

Jeder Geschäftsprozess ist eingebettet in die Prozesslandschaft der Organisation. Unter Umständen hat er auch Kontakte zur Außenwelt. Beides muss beachtet werden. Im Idealfall wird natürlich die Gesamtheit aller Prozesse, bis auf die nicht automatisierbaren Abschnitte, automatisiert. Etwa so, wie es die Internet-Unternehmen mit ihren webbasierten Lösungen realisieren.

Gesamte Prozesslandschaft

Ansonsten muss der zu automatisierende Prozess in der Prozesslandschaft abgegrenzt werden. Insbesondere müssen seine Schnittstellen zu den anderen Prozessen geklärt werden.

Einzelprozess

Die technologische Entwicklung brachte es mit sich, dass inzwischen auch die Kontakte zur Außenwelt in die Nähe der Automatisierbarkeit gekommen sind. Dies lohnt sich natürlich besonders bei sehr zahlreich auftretenden Kundenkontakten. Diese Kontakte müssen deshalb identifiziert und diesbezüglich geprüft werden.

Außenwelt

Auch Entscheidungen können in sehr viel größerem Umfang als vor einigen Jahren automatisiert werden. Dafür ist die Identifikation entsprechender Abschnitte und der Abgleich mit den technischen (KI-)Möglichkeiten notwendig. Vgl. insbesondere Kapitel 19 und 21.

Entscheidungen

Bereits bei einer IT-Unterstützung und noch mehr im Rahmen der Automatisierung muss die Datenverwaltung umfassend bedacht werden und dies in mehrerlei Hinsicht:

Datenbanken

  • Wird die Integrität des Datenbestandes gewahrt? Z.B., wenn Softwareroboter auf die Unternehmensdatenbanken zugreifen und evtl. auch eigene verknüpfte Dateien anlegen.
  • Sind evtl. neu entstehende Dateninseln (z.B. durch den Einsatz von Softwarerobotern) wirklich notwendig? Der Verfasser erinnert sich noch gut an die Bemühungen, in den 1970-er Jahren die ("teuren") Dateninseln durch Einsatz von ERP-Software zu überwinden. Jetzt entstehen sie, mit den zugehörigen Schnittstellen, in großer Zahl neu.
  • Ist daran gedacht, für das eventuelle spätere Process Mining genügend "digitale Spuren" zu legen, z.B. in den Log-Dateien der Prozesssoftware?
  • Müssen aufgrund der Geschäftstätigkeit (Kundenzugriffe über das Web) und Größe des Datenbestandes die Datenbanken "im Internet" gehalten werden? Vgl. dazu Kapitel 20 ("NoSQL").
  • Soll im Rahmen der Automatisierungsbemühungen die Reaktionszeit der Datenbanken durch Einsatz neuerer Datenbanktechnologien verbessert werden ("In-Memory-Datenbanken")? Die Bereitschaft von Kunden, längere Zeit auf Antworten zu warten, ist anscheinend sehr gering.

Bei Internet-Unternehmen.

Damit sind Unternehmen gemeint, deren Geschäftstätigkeit "im Internet" stattfindet. Die Automatisierung erfolgt hier mittels Web-Programmierung. Zumindest bei den großen einschlägigen Unternehmen entsteht hierbei Individualsoftware, die durch umfangreiche Entwicklerteams realisiert und ständig weiterentwickelt wird.

Geschäftstätigkeit im Internet

Die Automatisierung betrifft v.a. die Interaktion mit den Kunden. Diese ist umfassend automatisiert, lediglich für ganz spezielle Situationen ("Inkasso etc.") wird der Prozess menschgestützt realisiert.

Diese Automatisierungslösungen sind u.U. auch für ganz unterschiedliche Gruppen realisiert. Nicht nur für den "normalen Kunden". Z.B. bei Amazon: Die Verkäufer auf Amazon finden ebenfalls eine vollautomatisierte Umgebung vor. Ebenso die Autoren, die dort ihre Bücher veröffentlichen.

Zu leisten sind hier dieselben Schritte wie oben, mit dem Fokus auf Webprogrammierung.

Aus Kundenverhalten Marketingmaßnahmen programmieren

Automatisierte Geschäftsprozesse, die mit den Kunden zu tun haben, erlauben, das Kundenverhalten zu beobachten, festzuhalten und zu nutzen. Z.B. zur Profilerstellung und zur Erarbeitung maßgeschneiderter Angebote. Auch dies muss programmiert werden als Basis der Geschäftsprozesse, die den Kunden zu mehr Käufen bewegen sollen.

18.4 Wege

Auf welchen Wegen kann die Automatisierung von Geschäftsprozessen erreicht werden?

Konventionelle Programmierung

Eine naheliegende Lösung wäre die folgende: Eine einzige prozessorientierte integrierte Software, sozusagen "ERP/automatisiert", in Nachfolge der früheren und derzeitigen ERP-Lösungen (vgl. zu ERP-Software Abschnitt 17.3 sowie [Staud 2006, Kapitel 3]). Dies geschah ein Stück weit bereits in den letzten Jahrzehnten, indem die jeweils aktuelle Variante einer ERP-Software eine jeweils intensivere Abdeckung der Geschäftsprozesse realisierte und einzelne Funktionen automatisierte, was aber nicht zur Vollautomatisierung führte.

Lösung

Plattform solcher IT-Systeme ist die organisationseigene Hardware oder eine von der Organisation gewählte Cloud-Lösung.

Plattform

Programmierung im Web-Kontext

Die großen Internet-Unternehmen haben die Automatisierung bereits umgesetzt. Sie entwickelten umfassende Softwarepakete, die den Nutzern ihre Geschäftsprozesse vollautomatisch anbieten und die ständig weiterentwickelt werden.

Dieser Ausprägung der Automatisierung begegenen wir täglich bei unseren Internetaktvitäten. Hier werden die Prozessschritte (die der Nutzer und die durch das Handeln der Nutzer angestoßenen) in Konstrukte einer "Web-Programmiersprache" umgesetzt und in einer entsprechenden Entwicklungsumgebung umgesetzt.

Durch die dort vorliegenden Geschäftsmodelle (zahlreiche Kunden, Abwicklung über das Internet, riesige Datenbestände) entstanden und entstehen dabei so große Datenbestände, dass neue Datenbanktechnologien entwickelt werden mussten. Diese werden geprägt durch das Medium der Geschäftstätigkeit (das Internet) und dessen Anforderungen. Man kann sie vereinfacht unter dem Stichwort NoSQL zusammenfassen. Wegen ihrer großen Bedeutung wird ihnen Kapitel 20 gewidmet.

Riesige Datenbestände

Die Automatisierung betrifft nicht nur die Kundenkontakte, sondern auch die übrigen Bereiche der Unternehmen, z.B. im Finanzwesen. Zumindest in der Planung einiger Unternehmen betrifft es auch die Logistik ("Drohnen"). Wir nähern uns damit der vollautomatisierten Abwicklung von Geschäftsprozessen, wo menschliches Eingreifen nur noch da erfolgt, wo Entscheidungen anstehen, die nicht automatisiert sind oder die nicht automatisiert werden können. Hierzu gehören z.B. die Kauf- und sonstigen Entscheidungen der Kunden.

Nicht nur bei den Kundenkontakten

Diese Entwicklung setzt sich fort. Immer mehr der gesamtwirtschaftlichen Geschäftstätigkeit verlagert sich ins Internet und wird - zumindest gegenüber den Kunden - vollständig automatisiert erledigt. Nutzer und Beschleuniger dieses Trends sind die Internet-Unternehmen, deren Geschäftsmodell auf dem automatisierten Umgang mit Tausenden oder Millionen Kunden aufbaut.

Automatisierung bei Workflow Management-Systemen

In Abschnitt 17.4 wurden Workflow-Management-Systeme (WfMS) bereits als IT-unterstützende Systeme vorgestellt. Auch hier gibt es ständige Bemühungen, die Automatisierung weiter zu treiben.

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

Robotic Process Automation

Die letzte im derzeitigen Geschehen erkennbare Variante ist die rund um die Robotic Process Automation (RPA). Sie wird in Abschnitt 19.2 beschrieben. Hier liegt der Fokus nicht so sehr auf Neuentwicklung von prozessorientierter Software, sondern darauf, einzelne Funktionen zu automatisieren und/oder das Zusammenspiel von Softwarekomponenten zu verbessern. Z.B. so, dass rund um eine ERP-Softare zahlreiche andere Softwarekomponeten angeordnet sind, die für die Abwicklung der Geschäftsprozesse zusätzlich benötigt werden. Hier verlangt Automatisierung, dass das Zusammenspiel der Komponeten automatisiert wird, was dann durch Softwareroboter geschieht. Vgl., auch für Beispiele, Abschnitt 19.2.

18.5 Ziele

Hauptziel bei der Automatisierung von Geschäftsprozessen ist die Steigerung der Effizienz. Dies kann auf folgende Weise erreicht werden:

  • Beschleunigung der Durchlaufzeiten. Diese ist zum Teil dramatisch, vgl. die Beispiele in Abschnitt 19.2.
  • Kostensenkung. Auch diese kann sehr hoch sein.
  • Präziseres Prozessmanagement, da ein automatisierter Geschäftsprozess leichter überwacht werden kann ("Process Mining", vgl. Abschnitt 19.3)
  • Qualitätsverbesserungen durch die automatisierte Steuerung und Überwachung. Dadurch ist u.U. eine Reduzierung der Fehlerquoten möglich.
  • Mehr Übersicht. Bei automatisierten Prozessen können klare Aussagen über bereits durchgeführte und noch ausstehende Abläufe getätigt werden.

Dies alles natürlich nur, wenn die Automatisierung kompetent umgesetzt wurde.

Diese Ziele können nur mit Unterstützung der Mitarbeiter erreicht werden. Sie sollten bei der Formulierung der Anforderungen an die Software mitarbeiten, da sie die Prozesse am besten kennen. Sie müssen die erstellte Software testen. Auf die Zeit nach dem Einsetzen der Software müssen sie vorbereitet werden, da sich durch die automatisierte Software ihre Aufgabenschwerpunkte verschieben. So bedarf es zur Überwachung automatisierter Prozesse erhöhter softwaretechnischer Kompetenzen, die eventuell durch Schulungsmaßnahmen aufgebaut werden müssen.

Mitarbeiter

18.6 Voraussetzungen

Voraussetzung für eine Automatisierung von Geschäftsprozessen ist ein standardisierter wohlstrukturierter Prozess. Es sollte sich also um Routineprozesse und auf keinen Fall um kreative bzw. unstrukturierte Prozesse handeln.

Standardisiertheit

Für diesen müssen, nach dem jeweiligen Stand der Technik, die automatisierbaren Prozessabschnitte bestimmt werden. Dabei sollten für die Kunden (z.B. beim Kaufvorgang in WebPortalen) bzw. Mitarbeiter nur noch Prozessschritte verbleiben, die nicht automatisiert sind oder nicht automatisiert werden können (z.B. Ausnahmen und Entscheidungen. Aufgrund der Fortschritte im Bereich der künstlichen Intelligenz werden dies immer weniger.

Grundsätzliche Bedingung für die Automatisierung ist ja wohlstrukturiertheit (des Geschäftsprozesses, des Geschäftsprozessabschnitts), da nur in solchen für jeden Prozessschritt Lösungswege vorliegen. Bedingt durch neue Softwaretechnologien, insbesondere die von der Künstlichen Intelligenz (KI) – Forschung herrührenden, werden aber immer mehr Prozessabschnitte, die bisher unstrukturiert oder semistrukturiert waren, zu wohlstrukturierten und können daher auch automatisiert werden. Letztendlich bleiben dann nur die Entscheidungen übrig, die aus inhaltlichen Gründen durch Menschen zu realisieren sind, z.B. Führungsaufgaben.

Wohlstrukturiertheit

In Abschnitt 2.4 wurde definiert, dass ein Problem als wohlstrukturiert empfunden wird, wenn ein Entscheidungsträger zu jeder der Phasen ein geeignetes Vorgehen kennt. Jetzt können wir ergänzen, dass ein Entscheidungsträger oder ein KI-Programm ein geeignetes Vorgehen kennen muss. Dabei ist meist anzunehmen, dass der Prozessverantwortliche oder Prozessnutzer die genauen Abläufe im KI-Programm nicht kennt. Dies bleibt – wenn überhaupt - den KI-Programmierern vorbehalten.

KI-Programme haben es in sich, dass die Ergebnisse des Programms nicht in vollem Umfang "vorgedacht" werden können. Dies gilt für Programme, die auf der Prädikatenlogik mit ihren Wissensbasen und Inferenzmaschinen basieren (z.B. sog. Expertensysteme) genauso, wie für die derzeit im Fokus stehenden KI-Lösungen, die auf Musterabgleich beruhen.

18.7 Umsetzung

Obige Ausführungen zur Prozessanalyse und Prozessmodellierung in Automatisierungsprojekten können hier ergänzt werden um Anforderungen, die sich ergeben, wenn die entsprechenden Programme erstellt werden müssen.

Die zu automatisierenden Geschäftsprozesse müssen dafür nicht nur gründlich erfasst und modelliert werden, es muss zusätzlich die Klärung bereits automatisierter Prozessabschnitte erfolgen. Dabei ist auch festzulegen, ob die vorliegenden Programme weiter genutzt werden sollen. Im nächsten Schritt ist dann zu klären, welche bisher nicht-automatisierten Prozessabschnitte automatisiert werden sollen. Mit diesen Entscheidungen sind wir im strategischen Bereich.

Klärungen

Dann ist eine Optimierung nötig, die zur Automatisierung hinführt bzw. die durch diese möglich wird. Muss oder kann der Prozess für die Automatisierung umgestaltet werden. Dabei müssen auch die eventuellen Änderungen des Prozesses durch die Automatisierung berücksichtigt werden. Evtl. sind Prozessschritte nicht mehr nötig bzw. es kommen weitere hinzu (z.B. zur Dokumentation des Geschäftsprozesses). Ganz allgemein ist nicht mehr nur der eigentliche Prozess Bezugspunkt, sondern auch die Automatisierung (operativer Punkt).

Optimierung

Danach sollten Prozessmodelle entstehen, die unmittelbar der Softwareentwicklung dienen können. Sie werden hier programmnahe Prozessmodelle genannt. Die dafür notwendige programmnahe Prozessmodellierung wird zu einem Bestandteil des Anforderungsmanagements (Requirements Engineering).

Prozessmodelle für die Softwareentwicklung

Außerdem muss die Festlegung des Realisierungswegs erfolgen. Auf welcher Plattform, mit welchen IT-Lösungen, soll die Automatisierung durchgeführt werden?

Realisierungsweg

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

Abstimmung zwischen IT und Prozessverantwortlichen

Obiges sollte es deutlich gemacht haben. Klassische Prozessverantwortliche (mit fachlichem und/oder betriebswirtschaftlichem Hintergrund) oder klassische Informatiker können diese Aufgaben nicht lösen. Zusammenarbeit ist nötig und an zentraler Stelle auch Kompetenz, die fachliche und IT-Aspekte verbindet. Dies leisten z.B. Wirtschaftsinformatiker/innen.

Die Automatisierung von Geschäftsprozessen verlangt einen engen Kontakt zwischen Geschäftsprozessmanagement (insbesondere Prozessmodellierern) und IT-Management (insbesondere Softwareentwicklung).

Das Management automatisierter Geschäftsprozesse verlangt gleichermaßen fachliche, betriebswirtschaftliche und IT-Kompetenz.

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

Träger

Betrachtet man z.B. die Geschäftsprozesse eines typischen Internet-Unternehmens im B2C, ist in wichtigen Abschnitten neben dem Kunden nur noch Software aktiv (Ware anbieten, Vorschläge machen, Auftrag festhalten, (virtuellen) Warenkorb befüllen, usw.). Dieser Bereich reicht weit in die automatisierbaren Abschnitte des Finanzwesens und die Logistik hinein und wird ständig ausgedehnt.

B2C: Business to Customer

Notwendig ist dabei die oben schon geforderte detaillierte Modellierung, also im Rahmen einer Beschaffung nicht Teile beschaffen, sondern zulässige Lieferanten bestimmen, Lieferanten anfragen, Konditionen klären, Bestellung formulieren, Bestellung versenden, usw. Etwa so wie in einer Standardprozessmodellierung. Danach können dann diese elementaren Funktionen in einer noch detaillierteren Ebene in einer systemmnahen Prozessmodellierung in Programmkonstrukte abgebildet werden.

Detaillierung

Automatisierungsgrad

Mehrfach war in den Kapiteln oben schon vom Automatisierungsgrad von Geschäftsprozessen die Rede (vgl. das Stichwortverzeichnis). Hier nun eine Zusammenfassung und Präzisierung. Mit dem Automatisierungsgrad ist – allgemein gesprochen – der Anteil an der Aufgabenerfüllung gemeint, der ohne menschliches Zutun durch die IT-Systeme ersetzt wird.

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

18.8 Zementierung

Die in Abschnitt 17.9 angesprochene "Zementierung "der Geschäftsprozesse durch IT-Unterstützung ist hier, bei einer Automatisierung, noch umfassender gegeben. Menschliches Eingreifen, das u.U. ein Stück weit Flexibilität schaffen könnte, liegt ja kaum mehr vor.

Trotzdem ist eine Umkehr dieser Entwicklung nicht vorstellbar, höchstens ein erhöhter Einsatz von Entwicklern. Das ist der Grund für die Wiederkehr von Individualsoftware mit riesigen Entwicklergruppen bei den großen Internet-Unternehmen, wie wir sie zuletzt in den 1960- und 1970-Jahren bei großen Unternehmen für die Entwicklung der damaligen individuellen Anwendungssoftware (mit COBOL) sahen (die dann durch ERP-Software abgelöst wurde).

<<Diskussion: Einschätzung, Wirkung, Bewältigung>>

19 Aktuelle Wege zur Automatisierung

Im vorigen Kapitel wurde der Stand der Technik bezüglich der Automatisierung von Geschäftsprozessen skizziert. Hier werden die aktuellen Bemühungen zur Erhöhung des Automatisierungsgrades vorgestellt.

19.1 Robotic Process Automation (RPA)

19.1.1 Einführung

Im Kern geht es hier um folgendes: Ein weiterer bisher von Menschen realisierter Geschäftsprozessabschnitt soll automatisiert werden. Dafür wird ein neues Programm geschrieben, das möglichst problemlos mit der übrigen Software zusammenarbeitet.

Um was geht's?

Ulrich Storck, Head of Product Development bei der Scheer GmbH, beschreibt es sehr präzise:

"Es geht um die Weiterentwicklung der klassischen Prozessautomatisierung" …"Ein RPA-System simuliert demnach, wie Menschen einzelne Bedienungsmasken oder auch ganze Geschäftsprozesse bedienen. Dazu werden Softwareroboter eingesetzt, die vom Anwender lernen, Benutzerschnittstellen zu verwenden. Zur Bedienung einer Software nutzen sie eine virtuelle Tastatur und eine Maus." [Herrmann 2017, S. 20]

Programme also, die – einmal eingerichtet – selbständig ihre Aufgabe erfüllen und die diese sogar vom früheren menschlichen Nutzer lernen.

Hier wird auch gleich der Lernprozess angesprochen, den diese Software leisten soll.

Weitgehend synonym werden in der aktuellen Diskussion die Bezeichnungen RPA-Lösung, Softwareroboter, Frontend-Assistent (FEA) und Botverwendet. Bei Bots wird u.a. noch unterschieden nach ChatBots, RPA-Bots, ActBots. Dazu unten mehr. Der Begriff Bot kommt vom englischen Wort robot.

Begriffe

Bei Frontend-Assistenten liegt der Schwerpunkt auf der Unterstützung von Mitarbeitern. Z.B. unterstützt die Telekom damit vor allem ihre Servicemitarbeiter, die bei Bedarf per Mausklick einen „ServiceBot" für eine bestimmte Aufgabe starten können.

Frontend-Assistent

19.1.2 Lose Kopplung

Ein wichtiges Motiv für die Entwicklung dieser Softwareprodukte ist der Wunsch, separate IT-Systeme miteinander ohne großen Aufwand zu koppeln. Also nicht durch Reengineering der Prozesse und Anpassungen in den IT-Systemen.

Dies betont auch Andreas Lüth (Partner bei ISG, Head of Robotic Process and Cognitive Automation DACH). Er weist darauf hin, dass RPA sich vor allem für die Automatisierung von Geschäftsprozessen eignet,

"bei denen die prozessunterstützenden IT-Systeme nicht ausreichend vernetzt sind".

Damit, so führt er weiter aus, ergibt sich die Möglichkeit, mit RPA Geschäftsprozesse zu automatisieren, "ohne die Prozesse oder die sie unterstützenden IT-Systeme anpassen zu müssen". [Bayer 2018, S. 18]

Typischerweise werden hier also die Aufgaben über verschiedene Anwendungen bzw. Geschäftsprozesse hinweg ausgeführt. Der Softwareroboter "bedient" dazu vorhandene Applikationen und führt auf diese Weise systemübergreifend Transaktionen aus, bearbeitet Datenbestände oder stößt die Kommunikation mit anderen digitalen Systemen an.

Verknüpfung

Sehr treffend haben es Haisermann/Rückershäuser beschrieben:

"Ein RPA-Bot … bleibt also an der Benutzeroberfläche von CRM- oder ERP-Systemen und interagiert auf nichtinvasive Weise mit jeder Art von Infrastruktur." [Haisermann und Rückershäuser 2019, S. 34]

RPA-Bot steht hier für ein Softwareprodukt (einen Softwareroboter), das die Verknüpfung solcher IT-Systeme realisiert.

19.1.3 Drei Typen von Systemen

Die Scheer Group unterscheidet dabei drei Typen von Systemen:

  • Einfache RPA-Systeme zur Nachahmung sich wiederholender Routineaufgaben.
  • Kognitive RPA-Systeme, die das Anwenderverhalten auch in komplexeren Situationen nachahmen können, z.B. durch das Einbringen von Expertenwissen und die Fähigkeit zur natürlichsprachigen Kommunikation.
  • Intelligente RPA-Systeme, die zusätzlich lernfähig sein sollen.

19.1.4 Voraussetzungen für den Einsatz

Voraussetzung für den Einsatz ist wie immer, wenn es um Automatisierung geht, dass es sich um einen standardisierten und wohlstrukturierten Prozess mit hoher Wiederholzahl handelt.

Der Prozess des Softwareroboters sollte detailliert modelliert, die Schnittstellen seiner Partner (mit ihrem Prozessumfeld), wie auch immer sie geartet sind (vgl. unten), sollten genau spezifiziert sein. In der aktuellen Diskussion wird hier für die Modellierung eine automatisierte Erfassung der Process durch Process Mining diskutiert. Vgl. Abschnitt 19.3.

19.1.5 Schatten-IT

In der aktuellen Diskussion wird immer wieder darauf hingewiesen, dass der Einsatz von Softwarerobotern oftmals von "den Fachabteilungen" und nicht von der IT realisiert wird:

"Oft sind es die Fachabteilungen, die die meisten Bots bauen, in den häufigsten Fällen mit Unterstützung von externen Dienstleistern. Die IT wird häufig erst im Nachgang eingeschaltet, obwohl Governance, Roboter-Management und Prozessanalyse eine zunehmend wichtige Rolle spielen." [Bremmer 2018a, S. 36]

Damit streifen wir das Thema Schatten-IT. Vgl. auch 19.1.12.

19.1.6 Erwartungen

Die Erwartungen an die Automatisierung durch RPA-Systeme sind sehr hoch. Sie soll zu einer Beschleunigung der Prozessabwicklung und zu größerer Transparenz führen. Entsprechend sind die Erwartungen (der Unternehmensberatungen):

"Die Marktforscher von Forrester Research gehen davon aus, dass es bis 2021 weltweit mehr als vier Millionen Softwareroboter geben wird, die Büro- und Verwaltungsarbeiten sowie Vertriebs- und verwandte Aufgaben erledigen." [Bremmer 2018a, S. 36]

19.1.7 Grenzen von Softwarerobotern

In Bezug auf die einfachen RPA-Systeme mit konventioneller Programmierung (vgl. oben) gelten die oben angeführten Grenzen. Sehr plastisch beschreibt diese Andreas Lüth, zitiert nach Bayer:

"Die grundlegende Einschränkung von Softwarerobotern bestehe darin, dass sie "dumm" seien. Die Technik tue genau das, wofür sie entwickelt worden sei - nicht mehr und nicht weniger. Das bedeute unter anderem, dass nichts mehr geht, wenn Ausnahmen auftreten oder Daten fehlen. Anwender müssten deshalb darauf achten, für RPA ausgesuchte Prozesse korrekt abzubilden und sämtliche möglichen Ausnahmen zu berücksichtigen." [Bayer 2018, S. 19]

Dimitar Todorov (Head of IT Applications and Integration Services bei der Energieversorgung Niederösterreich) beschreibt den Stand von 2018 sehr plastisch. Die bis dahin umgesetzten RPA-Projekte zeigen positive Aspekte. Der Return on Invest (ROI) wird "um Faktoren besser", die Time to Market kürzer. An die zu automatisierenden Prozessabschnitte sollten allerdings keine zu hohen Erwartungen gestellt werden:

"In einem automatisierten Prozess Daten von A nach B zu schaufeln, ist laut Todorov der Idealfall." (zitiert nach [Bremmer 2018b, S. 43])

Das ist ohne weiteres nachvollziehbar. Es wundert nicht, dass dadurch der Ruf nach leistungsfähigeren Softwarerobotern deutlich wurde, den sog. kognitiven und intelligenten RPA-Systemen.

19.1.8 RPA/Bot-Lösung vs. Integrationsprojekt

Beim Einsatz von Softwarerobotern stellt sich immer die Frage, ob man deren automatisierte Prozessabschnitte nicht besser in die vorhandene integrierte Software einfügt, durch programmieren bzw. programmieren lassen. Dies wird auch in der Praxis so gesehen. Evtl. auch so, dass die "Roboter-Lösung" eine Übergangslösung ist: Zuerst Bots, dann, bei Bewährung, Integration in die Unternehmenssoftware. So auch Sebastian Zeiss (Vice President Lean Management Competence Center bei der Telekomm Service GmbH), der in [Bremmer 2018a, S. 37] zitiert wird:

Integriert oder nicht

"Seine Company greife als eines der Werkzeuge auf RPA zurück, um durch die typische agile Scrum-Vorgehensweise Zeit zu sparen und sofort Ergebnisse zu erhalten. Später werde dann geprüft, ob es Sinn gibt, die Bot-Lösung durch ein Integrationsprojekt abzulösen."

Immer wieder taucht auch das Argument auf, der Einsatz von Softwarerobotern erlaube es Unternehmen, eine eigentlich veraltete Software (meist angedeutet: auf Großrechnern) weiterzubetreiben und sei insoweit ein "Fortschrittshemmer".

Fortschrittshemmer?

19.1.9 Einschätzung

In der Computerwoche (Ausgabe 2020, 12-14) wird von einer Diskussionsrunde berichtet, in der IT-Verantwortliche den Einsatz von RPA-Bots thematisieren (vgl. [Stocker 2020, S. 34]). Insbesondere ging es auch um die oben angesprochene Frage, ob durch RPA-Bots notwendige Softwareneuerungen unterlassen werden können ("Fortschrittshemmer").

Zu Beginn wird aus einer aktuellen RPA-Studie von IDG zitiert, die auf die Bedeutung der Thematik hinweist [Stocker 2020, S. 34]. Danach sind bis zu 20 automatisierte Prozesse "bei Konzernen und Mittelständlern durchschnittlich in Betrieb".

Einsatz

Die Diskussion zeigt eine durchaus realistische Einschätzung der Möglichkeiten. Einige der Positionen:

  • Aufgrund ihrer Architektur ("Andocken am User-Interface") haben Softwareroboter ein begrenztes Veränderungspotential. "Der Prozess bleibt der gleiche, er läuft nur schneller und weniger fehleranfällig ab" (S. 34).
  • Gehofft wird, dass RPA "eine Schlüsselrolle als Enabler der digitalen Transformation" einnimmt, weil dadurch Nutzer in die Lage kommen, "ihre Arbeit selbst zu automatisieren" (S. 35).
  • Hingewiesen wird auf "Bot-Molochs". Von diesen spricht man, wenn ein "robotergestützter Prozess an einen oder mehrere andere andockt". Dies wird als kritisch angesehen (S. 35).
  • RPA und Process Mining gehören zwingend zusammen, weil mit Process Mining der gesamte Prozess im Fokus ist und die RPA-Bots dadurch effizient eingesetzt werden können.

19.1.10 Anbieter / Softwarehäuser

In [Bremmer 2018c] wird aus einer Umfrage von Forrester Research berichtet. Danach zeigte es sich, dass Blue Prism der führende Anbieter ist (32 % Marktanteil), gemeinsam "mit den etwas besser gerankten Anbietern UiPath und Automation Anywhere". Weiter wurde ausgeführt, dass zum Kreis der „Strong Performers" außerdem Pegasystems, Nice, Edgeverve, Kryon, Kofax und Thoughtonomy" gehören [Bremmer 2018c, S. 16].

Insgesamt also:

  • Blue Prism
  • UiPath
  • Automation Anywhere
  • Pegasystems
  • Nice
  • Edgeverve
  • Kryon
  • Kofax
  • Thoughtonomy

Diese Liste hat sich in einer neuen Übersicht, wiederum basierend auf einer Gartner-Studie, nur unwesentlich verändert:

  • UiPath
  • Automation Anywhere
  • Blue Prism
  • NICE
  • Pegasystems
  • Kofax
  • NTT-AT
  • EdgeVerve Systems
  • Openconnect
  • HelpSystems

Vgl. [Bremmer 2019a, S. 24, basierend auf Gartner]

Die dort angegebene Tabelle zeigt außerdem auf, dass im Jahr 2018 knapp 40% des Marktanteils auf weitere Anbieter entfallen.

19.1.11 "Bots überall"

Wie wir oben gesehen haben, ist ein Softwareroboter im Kern ein Computerprogramm, das im IT-gestützten Umfeld Aufgaben automatisiert und selbstständig ausführt, meist auch wiederholt. Diese Softwaretechnologie kann natürlich in vielen Bereichen zum Einsatz kommen, auch außerhalb des geschäftlichen Umfelds:

  • Bei Computerspielen als selbständiger "Mitspieler", als Ersatz für einen menschlichen Spieler
  • In Chats und Foren zur Bereinigung und Kontrolle der Inhalte
  • Auch die sog. Webcrawler der Suchmaschinen, die aus dem Internet die Sucheinträge einsammeln, sind Bots.
  • Trojaner und Malware beruhen teilweise auch auf dieser Technologie.

Richtet man es entsprechend ein, dann können Bots auch miteinander kommunizieren. Man spricht dann von einem Botnet. Im nicht-kriminellen geschäftlichen Umfeld geht es dann z.B. um unternehmensübergreifende Kommunikation. Ansonsten handelt es sich meist um Schadsoftware. Ein typisches Beispiel hierfür ist Spam.

Botnet

Social Bots

Nur zur Abrundung hier noch ein Blick in das Social Web. Eine immer wichtigere Rolle in der Gesellschaft, vor allem bei dem Teil, der sich im Internet bewegt, spielen die sog. Social Bots. Die Bundeszentrale für politische Bildung (BPD) beschreibt es treffend:

"Sie können menschliches (Kommunikations-) Verhalten imitieren, beispielsweise bei Facebook Freundschaftsanfragen versenden, bei Twitter anderen Accounts folgen oder eigene Texte vorbereiten. Ihre Zielsetzung hingegen ist unterschiedlich und der Übergang zwischen folgenden drei Kategorien verläuft fließend. Ein Bot kann auch mehrere Aufgaben übernehmen.

 

1. Die Überlaster

 

Ein Bot kann den Feed einer bestimmten Seite oder einer Person mit einer bestimmten Aussage überfluten. Sieht er beispielsweise, dass eine Nachrichtenseite sich zu einem bestimmten Thema geäußert hat, postet er immer wieder dieselben Gegenaussagen. Vor allem, wenn solche Bots ihre Nachrichten gegenseitig "liken" oder kommentieren können, beschleunigen diese sich in ihrem gegenseitigen Mechanismus selbst. Echte Kommentare gehen dadurch oftmals unter. Das macht eine normale Diskussion über ein Thema unmöglich.

 

2. Die Trendsetter

 

Mit einer kleinen Bot-Armee, die immer und immer wieder dasselbe Hashtag verwendet, ist es möglich, die Themen-Agenda zu bestimmen. Unterhalten sich plötzlich tausende Bots auf Twitter über diesen Hashtag kann der Inhalt Bedeutung in der öffentlichen Debatte erlangen. Ein Thema erscheint damit plötzlich größer als es ist und echte Nutzer schließen sich einer "Fake-Bewegung" an, weil sie diese als eine echte Mehrheit begreifen.

 

3. Die Auto-Trolle

 

Diese Bots sollen einzelne Nutzer ablenken, damit diese möglichst viel Zeit mit sinnloser Diskussion verbringen. Wenn sich etwa zwei Nutzer über ein Thema unterhalten, klinkt ein solches Programm sich ein und schreibt immer wieder unpassende, extreme oder sogar beleidigende Argumente. Weil viele Nutzer dann auf diese fiktiven Provokateure reinfallen, gerät die normale Diskussion in den Hintergrund. Wer nicht merkt, dass er eigentlich mit einem Bot diskutiert, kann stundenlang beschäftigt sein."

Vgl. http://www.bpb.de/252585/was-sind-social-bots, abgerufen am 2.8.2019

Hierzu ein Beispiel von August 2019, das den breiten Einsatz dieser Technologie zeigt. Dabei traten Bots als Käufer von Schuhen ("seltene Sneaker") bei einem Onlineshop auf. Die Geschäftsidee ist anscheinend, möglichst viele dieser Schuhe schnell zu kaufen und sie dann gleich wieder, zu einem höheren Preis, an Sammler wieder zu verkaufen. So kamen, nach der Quelle, "fast 700000 Zugriffe" zusammen, wenn ein seltener Sneaker im Angebot war. So etwas wirkt "wie ein DDoS-Angriff".

Onlineshop trickst Kaufbots mit teuren Produktbildern aus

Lassen wir die Quelle sprechen: "Der Mitgründer des Skaterladens … hat eine Strategie entwickelt, um Bots und automatische Scripts bei Onlinekäufen auszutricksen. Statt begehrter Nike-Schuhe hat er lediglich deren Produktbilder für 10 Euro pro Stück online gestellt - inklusive passender Beschreibung. Bots haben diese trotzdem tausendfach automatisiert bestellt."

Näheres unter der Quelle: https://www.golem.de/news/ddos-onlineshop-trickst-kaufbots-mit-teuren-produktbildern-aus-1908-142999.html?utm_source=pocket-newtab Abruf am 9.8.2019.

19.1.12 Schattenseiten?

Das Thema "Zementierung" im Sinne von Zementierung von Prozessstrukturen durch deren Umsetzung in Programme wurde schon öfters thematisiert. Im Rahmen der RPA taucht ein weiterer Aspekt dieser Fixierung von IT- und Prozessstrukturen auf.

Vgl. Abschnitte 17.9, 18.10

Freund (CEO von Camunda) thematisiert die Frage, ob der Einsatz von RPA nicht dazu führt, dass "veraltete IT-Systeme und Strukturen" zementiert werden, in dem Sinn, dass der Einsatz von Softwarerobotern hilft, die veralteteten Systeme nicht abzulösen. Er hebt insbesondere auf den Punkt ab, dass es mit Hilfe von Softwarerobotern möglich ist, "Software ohne API in einen Workflow einzubinden und von einer Workflow-Engine steueren zu lassen". Gemeint ist z.B., dass ein Softwareroboter die ganz normale grafische Bedienoberfläche (GUI) eines anderen Programmes nutzt und dort Daten einträgt, abfragt, usw. Also auch, ohne dessen API (falls vorhanden) zu nutzen [Freund 2019, S. 20f].

Altsysteme + RPA

Er sieht da, annehmend dass "Altsysteme" per se "schlecht" seien, die Gefahr, dass der Druck, Altsysteme zu ersetzten nachlässt. Und dass damit den Organisationen ermöglicht wird, "die Kosten für neue IT zu umgehen" [ebenda].

Licht oder Schatten?

Dies kann aber natürlich auch ein Vorteil sein, wenn z.B. die Altsysteme gut funktionieren und erhalten bleiben sollen. Dann wird diese Möglichkeit in vielen Organisationen sicherlich als Vorteil gesehen.

Ein echter Nachteil ist der ebenfalls angesprochene Punkt, dass RPA-Lösungen eine "zerbrechliche Angelegenheit" sind, denn "sobald sich an der Oberfläche (GUI) auch nur ein kleines Detail ändert, muss der Softwareroboter neu programmiert werden" [ebenda, S. 21]. Dies, kann man ergänzen, gilt aber natürlich auch für Lösungen, die eine API zur Anbindung nutzen.

Zerbrechliche Lösung

In den Erfahrungsberichten der Nutzer von Softwarerobotern wird auch deutlich, dass die Softwareroboter oft von "den Fachabteilungen" gewollt und sogar eingeführt werden [Freund 2019], [Bremmer 2018a], sie also im Zusammenspiel von IT und Fachabteilung eher eine Sache der Fachabteilungen sind. Dadurch entsteht eine sog. Schatten-IT (oder wird ausgebaut), also ein Bereich der IT, der ohne Kontrolle der IT-Abteilung betrieben wird. So wie Excel-Lösungen, usw. Freund führt auf Basis einer Studie von Camunda aus, dass heute "61 % der befragten Führungskräfte und IT-Leiter gar nicht mehr wissen, wieviele Softwareroboter überhaupt im Einsatz sind" [Freund 2019, S. 21].

Schatten-IT

Frage:

Obigen Ausführungen liegt die Annahme zugrunde, dass eine Schatten-IT immer negativ ist. Ist das so?

19.2 Cognitive Process Automation (CPA)

Einfache RPA-Lösungen sind, wie oben beschrieben, auf der Leistungsfähigkeit konventioneller Programme angesiedelt. Sie folgen vorher festgelegten Abläufen und Geschäftsregeln mit fest definierten Inputs und Outputs. Mögliche Varianten im Ablauf müssen im Programm realisiert worden sein.

Vgl. Abschnitt 21.1.

Konventionell erstellte Programme sind also typischerweise nicht in der Lage, sich auf veränderte Situationen, auf Ausnahmen, usw. selbständig einzustellen. Sie sind auch nicht lernfähig. Dies soll durch den Einsatz von Techniken der Künstlichen Intelligenz – Forschung verbessert werden. Es wurde oben schon kurz angeführt, aus einfachen werden kognitive und dann intelligente RPA-Systeme, so die Wortwahl der Scheer GmbH.

KI: Künstliche Intelligenz

Deshalb die Weiterentwicklung, die Ergänzung des Einsatzes von Bots durch KI-gestützte Programme. Schlagwort: Von Bots zu Smart Digitization, RPA + KI, und weiter zu Cognitive Process Automation (CPA).

Kombination von RPA und KI

Was konkret damit gemeint ist, kann von den erwarteten Leistungen abgeleitet werden:

  • Anwenderverhalten replizieren mittels hinterlegtem Experten- und Prozesswissen
  • Vorausschauende Wartung(Predictive Maintenance)
  • Analyse von Finanztransaktionen und des Warenabsatzes
  • IT-Sicherheitslösungen, die eigenständig Cyber-Angriffe abwehren
  • Spracherkennung
  • Assistenzsysteme
  • Planungs-Tools mit Kl-Unterstützung
  • Automatisierung von IT- Administrationsaufgaben
  • Weitgehend selbständiges Erfassen von Prozessen mittels Musteranalysen und -erkennungsverfahren sowie neuronalen Netze. [Bayer 2018, S. 19]

Das ist eine umfassende Liste aus dem Werkzeugkasten der KI. Vieles zielt auf automatisiertes Lernen (i.d.R. mit neuronalen Netzen; vgl. Kapitel 21). Daneben wird Spracherkennung gefordert und natürlich Texterkennung.

Da hierbei meist das Ziel ist, die Prozesse rund um den Kundenservice umfassend zu automatisieren, werden folgende konkreten KI-Funktionen genannt:

  • Optische Zeichenerkennung (optical character recognition; OCR) zur Texterkennung.
  • Intelligente Zeichenerkennung (intelligent character recognition; ICR) für die Interpretation von Handschriften.
  • Maschinelles Lernen für erweiterte Inhaltsanalysen, z.B. um "die Position von Feldern auf Dokumenten wie Kundenrechnungen zu identifizieren" [Bremmer 2019a, S. 23]
  • Verstehen natürlicher Sprache (natural Language Processing; NLP)
  • Erzeugen natürlicher Sprache (natural Language Generation; NLG)
  • Automatisiertes Erkennen von Geschäftsprozessen und Aufgaben

[Safar 2019, S. 18f], [Bremmer 2019, S. 23]

Safar (Managing Partner der Weissenberg Group) weist auf die Bedeutung der zu bearbeitenden Daten hin. Er führt aus, dass die klassische RPA für strukturierte Daten geeignet ist. Bei unstrukturierten Daten und komplexen Prozessen, "stößt die klassische RPA an ihre Grenzen" ([Safar 2019, S. 18]). Auch das ist ein Grund, RPA-Lösungen um KI-Funktionalitäten zu erweitern.

Strukturiert / Unstrukturiert: vgl. Abschnitt 20.1.1

Beispiele

(1) Sebastian Zeiss beschreibt als ein Beispiel für die erfolgreiche Kombination von RPA und KI bei Telekom Service …

"die automatische Bearbeitung und Lösung von E-Mail-Anfragen an die Clearing-Abteilung: Bei der im zweiten Quartal 2018 ausgerollten Lösung wird der Inhalt der Mails via KI erkannt und durch Bots weiterbearbeitet." (Sebastian Zeiss, Vice President Lean Management Competence Center bei der Telekomm Service GmbH. Zitiert in [Bremmer 2018a, S. 37]).

(2) "Beim Ausfüllen eines E-Formulars für die Eröffnung eines neuen Bankkontos werden Daten falsch eingegeben oder ein Abschnitt wird vollständig ausgelassen. Bisherige Lösungen lehnen das fehlerhafte Formular ab. Ein kognitiv automatisierter Prozess identifiziert und korrigiert das Problem selbständig, ohne dass ein menschliches Eingreifen erforderlich ist" [Safar 2019, S. 19].

(3) Insbesondere "das Erkennen von Datenmustern" erlaubt gegenüber den klassischen RPA-Lösungen weitere Anwendungsszenarien:

  • "das Feststellen von Inkongruenzen zwischen Verträgen und Rechnungen
  • ein End-to-End-Kundenservice mit Chatbots: Mit der kognitiven Automatisierung können Chatbots erstellt werden, mit denen sich problemlos Änderungen an anderen Systemen vornehmen lassen;
  • die Abwicklung von Bankfinanzierungsgeschäften: CPA wickelt die Bearbeitung der Unterlagen ab und führt behördliche Prüfungen durch;
  • das Bearbeiten von Versicherungs/Serviceverträgen: Mit Hilfe von NLP-Techniken und OCR können Vertragsdaten extrahiert werden, um automatisierte Entscheidungen in Bezug auf Vertragsänderungen zu treffen;
  • die automatische Schadensregulierung in der Versicherung: Kognitive automatisierte Prozesse treffen selbständig Entscheidungen über Schadensfälle auf der Grundlage von Vertrags- und Schadensfalldaten und benachrichtigen die Zahlungssysteme."

[ebenda, S. 19]

Zusammenfassend beschreibt Safar die Unterschiede zwischen RPA und CPA wie folgt:

  • Bezüglich der Einsatzbereiche "übernimmt RPA repetitive Aufgaben, die keine Entscheidungen und keine menschlichen Eingriffe verlangen". Dagegen soll CPA in der Lage sein, "menschliche Verhaltensweisen nachzuahmen" (S. 19)
  • Bezüglich der Technologien sieht er bei RPA "Basistechnologien wie Screen Scraping, Makro-Scripting und Workflow- Automation". Dagegen kommen bei CPA auch KI-Techniken zum einsatz, insbesondere "Textanalyse, Data Mining, NLP, semantische Technologien und Machine Learning" (S. 19).
  • Bezüglich der verwendeten Methoden sieht er RPA als regelbasiert und auf der konventionellen Programmierung ("if-then-Prinzip"). Dagegen soll CPA wissensbasiert und zu selbstständigem Lernen fähig sein. (S. 19)
  • Bezüglich der vewendeten Daten sieht er RPA mit strukturierten und semistrukturierten Daten umgehend, während CPA auch unstrukturierte Daten verbeiten können soll, "indem sie Beziehungen und Ähnlichktien erkennt."

Vertieftes zum Unterschied von RPA und CSA findet sich in [Safar 2019, S. 19]: "RPA vs. CPA - vier Unterschiede".

19.3 Process Mining

19.3.1 Ausgangspunkt

Prozesserhebung ist ein mühsames Geschäft, dies sollten insbesondere die Kapitel 12 bis 16 deutlich gemacht haben. Die Abläufe werden weitgehend manuell beziehungsweise werkzeuggestützt ermittelt. Interviews mit Prozessnutzern und Prozessspezialisten sind zu führen, Unterlagen und Dokumentationen sind zu sichten, evtl. müssen ausgewählte Prozessabschnitte beobachtet werden. Die entstehenden Prozessmodelle und Prozesslandkarten müssen dann von den Betroffenen verstanden werden, was oft zusätzliche Anstrengungen mit sich bringt.

Klassische Prozesserhebung

Außerdem hat die Veränderungsrate von Geschäftsprozessen deutlich zugenommen, gerade auch im Rahmen der Bemühungen um IT-Unterstützung oder Automatisierung. Dies bedeutet zusätzlichen Aufwand, denn die Änderungen müssen eingepflegt werden.

Da lag die Idee nahe, auch die Erfassung von Geschäftsprozessen automatisiert zu realisieren. Diese Bemühungen, mit Hilfe von Software Geschäftsprozesse zu erfassen und zu analysieren, werden mit Process Mining bezeichnet. Im Wesentlichen geschieht dies, indem die digitalen Spuren der Geschäftsprozesse erfasst und ausgewertet werden. Wesentlicher Bestandteil dieser digitalen Spuren sind die Log-Dateien des Geschäftsprozesses (falls vorhanden).

Automatisierte Prozesserhebung

Ein tiefer liegender Grund für diese Versuche der softwaregestützten Prozessanalyse ist, dass die Geschäftsprozesse in vielen Organisationen nicht ausreichend modelliert und beschrieben wurden, vielleicht weil der Aufwand dafür sehr groß ist.

Leidensdruck

Voraussetzung für Process Mining ist, dass die Geschäftsprozesse oder Prozessabschnitte IT-gestützt sind, dass sie also regelbasiert immer gleich und mit klar strukturierten Daten ablaufen.

19.3.2 Ziele und Möglichkeiten

Das erste Ziel ist, wie oben schon angemerkt, die automatisierte Erfassung von IT-gestützten Geschäftsprozessen. Dies soll dann zahlreiche Möglichkeiten eröffnen.

Durch eine solche effiziente Erfassung der IT-gestützten Geschäftsprozesse sollen Optimierungsvorhaben erleichtert werden. Der Geschäftsprozess wird transparent, Änderungen sind leichter "einpflegbar".

Optimierung

Die digitalen Spuren der Geschäftsprozesse erfassen konkrete Durchgänge ("Instanzen") durch den Prozess. Damit können die Optimierungsbemühungen vertieft werden. Z.B. kann der Zeitverbrauch des ganzen Prozesses und seiner Abschnitte (leichter) erfasst werden.

Instanzen

Die Anpassung von automatisierten oder IT-gestützten Geschäftsprozesse an neue Abläufe oder Datenstrukturen ist durch die gewonnene erhöhte Transparenz erleichtert.

Anpassung

Damit ist auch eine erleichterte Erfolgsmessung, z.B. nach durchgeführten RPA-Projekten, möglich. Die Messung von Durchlaufzeiten und der Zahl der Ausführungen (als Grundlage für die Bestimmung von Prozesskosten) sollte für beide Zeitpunkte (vor und nach der Automatisierung) leicht möglich sein.

Erfolgsmessung

Noch weiter geht Rother (Gründer der Process Analytics Factory), der sich vorstellt, dass durch Process Mining neue Geschäftsmodelle und -abläufe entstehen sollen, während …

Ableitung von Prozessmodellen

"gleichzeitig bestehende Prozesse und Bereiche umgebaut und digitalisiert werden."

Verbesserungspotentiale in digitalisierten Prozessen sollen gefunden werden, die

"mit traditionellen Verfahren des Messens, Aufschreibens und in Workshop Bearbeitens" nicht gefunden werden können. [Rother 2018, S. 36]

19.3.3 Aktuelle Methoden

Einen kurzen Überblick über die aktuellen Methoden legt Safar (Managing Partner der Weissenberg Group) vor. Genannt werden:

  • Process Mining als solches, um "die relevanten Kern-, Unterstützungs- und Management-Prozesse sowie die dazugehörigen Key Performance Indicators (KPI) aufzuzeichnen und zu analysieren". [Safar 2018, S. 28]
  • Process Recording zur Aufzeichnung von Prozessaktivitäten.
  • Process Reporting "zur Evaluierung der realisierten Effizienzsteigerung." (S. 29)

Safar geht auch ein Stück weit auf die Implementierung der jeweiligen Softwarekomponenten ein. Für das Process Mining skizziert er eine mögliche programmtechnische Umsetzung wie folgt:

Process Mining als solches

"Hierzu wird die Software an einer zentralen Stelle im IT-System des Unternehmens installiert. Alle Systeme, in denen die einzelnen Aktionen oder Schritte in einem Log gespeichert werden können, werden durch einen Experten angebunden. Die Software greift auf die produktiven Log-Dateien zu und konvertiert diese in ein eigenes Datenformat. Die konvertierten Daten bilden die Datenquelle der grafischen Darstellungen." [Safar 2018, S. 28]

Damit sollen dann Auswertungen möglich sein, die Hinweise auf "für die Automatisierung geeignete Prozesse" geben. Für diese wird "ein Codegerüst zur Implementierung" erstellt (ebenda). Es soll also um eine Vorbereitung der Modellierung gehen.

Für das Process Recording wird die Software auf einem PC im Unternehmen installiert. Diese

Process Recording

"zeichnet alle Aktionen des Mitarbeiters bis hin zu einzelnen Mausklicks und Tastenanschlägen im Hintergrund auf. Das Ablaufdiagramm eines Prozesses wird durch die tatsächlichen Aktionen des Users am PC erstellt. Seine Ergebnisse hinterlegt der Recorder in einem Logfile, das anschließend mit Hilfe eines speziell entwickelten Analyseroboters und einer dort hinterlegten Mustererkennung ausgewertet wird." [Safar 2018, S. 29]

Bremmer (er benutzt den Begriff Desktop Activity Mining) weist darauf hin, dass bei dieser Vorgehensweise

"… auch solche Aktionen erfasst werden, die trotz ihrer Prozessrelevanz bisher nicht durch vorhandene IT-Systeme dokumentiert werden können – beispielsweise das Schreiben einer E-Mail." [Bremmer 2018b, S. 25]

Process Reporting meint die Visualisierung der relevanten Informationen über ein Dashboard. Grundlage der angezeigten Informationen sind "strukturierte Logfiles" der verschiedenen Bots. Für die "technische und geschäftliche Sichtweise können getrennte Dashboards eingerichtet werden.

Process Reporting

Safar gibt einen Einblick in typischerweise in solch einem Dashboard verwaltete Daten, wobei es in seinem Beispiel um die Messung des Erfolgs der Prozessautomatisierung geht. Er führt an:

  • die Durchlaufzeiten des Softwareroboters
  • die Zahl seiner erledigten (Teil-)Aufgaben
  • die gesparten Kosten
  • das "Zusammenspiel aus vollautomatisierter und mitarbeiterbasierter Entscheidungsfindung, welche als Variable in eine Metrik „Mitarbeiterentlastung" einfließt." [Safar 2018, S. 29]

19.3.4 Automatisierte Prozessmodellierung

Es klingt in den Artikeln und Erfahrungsberichten immer wieder an. Die Befürworter dieser Technologien sehen auch die Möglichkeit, Prozessmodelle automatisch aus der softwaretechnischen Prozessbeobachtung zu gewinnen.

So z.B. Safar, wenn er in Bezug auf Process Recording ausführt:

"Das Ablaufdiagramm eines Prozesses wird durch die tatsächlichen Aktionen des Users am PC erstellt. Seine Ergebnisse hinterlegt der Recorder in einem Logfile, das anschließend mit Hilfe eines speziell entwickelten Analyseroboters und einer dort hinterlegten Mustererkennung ausgewertet wird. Da der Process Recorder an keine weiteren Systeme angeschlossen werden muss, können mit geringem Organisationsaufwand und ohne lange Anlaufzeiten die relevanten Kennzahlen und die Kosten des manuellen Prozesses ermittelt werden." [Safar 2018, S. 29]

Ähnlich Bremmer. Aus den durch das Desktop Activity Mining gewonnenen Daten sollen mit Hilfe von Process-Mining-Algorithmenautomatisch Prozessmodelle entwickelt werden.

In [Reder 2019] ist ebenfalls die Vorstellung bemerkbar, dass die Bestandsaufnahme und Optimierung der vorhandenen Prozesse mittels Process Mining erfolgen kann (S. 15f).

Konkret geht es also darum, die digitalen Spuren, die bei der Nutzung eines Geschäftsprozesses entstehen, zu erheben und sie den hoffentlich vorhandenen Prozessbeschreibungen hinzuzufügen. Diese digitalen Spuren sind:

Digitale Spuren

  • Transaktionsdaten
  • Log-Dateien, die einzelne Schritte oder Aktionen speichern
  • Log-Daten, die automatisch von den prozessunterstützenden IT-Systemen generiert werden.

Dafür ist meist die Beachtung der Zusammenarbeit verschiedener Softwareprodukte nötig. Bayer beschreibt es recht detailliert:

"…Process Mining arbeitet mit Log-Daten, die automatisch von den prozessunterstützenden IT-Systemen generiert werden. Die Process-Mining-Tools bringen dafür Konnektoren oder sogenannte Loader zu Systemen wie beispielsweise Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES) und Supply-Chain-Management (SCM) beziehungsweise Datenbanken mit."

 

"Die eingesammelten Daten werden in einem sogenannten Event Log aufbereitet, das heißt vor der weiteren Analyse noch einmal auf Vollständigkeit, Konsistenz und Integrität geprüft sowie gegebenenfalls entsprechend bereinigt. Für eine sinnvolle Auswertung der Prozessdaten müssen diese bestimmte Voraussetzunger erfüllen: Es braucht mindestens eine Case-ID und eine Aktivitätsbezeichnung, um die Log-Daten eindeutig einem Prozesskontext zuordnen zu können, sowie Zeitstempel wie Start- und Endpunkte." [Bayer 2019a, S. 14]

Damit sind wir wieder bei der automatischen Prozessmodellgenerierung:

"Mit Hilfe des Event Log kann die Process-Mining-Software ein Ist-Modell des untersuchten Prozesses erstellen. Diese sogenannte Process Discovery bildet die Grundfunktionalität eines jeden Process-Mining-Werkzeugs." (S. 15)

Bei diesem Beispiel wird dann auch wieder ein tatsächlicher Vorteil dieser Vorgehensweise deutlich, die Betrachtung einzelner Prozessinstanzen. Bayer führt aus, dass mit dieser Process Discovery "viele unterschiedliche Prozessdurchläufe … analysiert werden können". Deren "Abweichungen und Variationen" erlauben dann die Abklärung von Faktoren, die "einen Prozess im positiven oder negativen Sinn beeinflussen." (S. 15) Ergänzen kann man, dass dadurch auch der Standardisierungsgrad des betrachteten Geschäftsprozesses geklärt werden kann. Dieser Vorteil liegt auch vor, wenn die Daten über den Prozess nur den Verlauf widerspiegeln.

Instanzenbetrachtungen

19.3.5 Heute und Morgen

Die oben beschriebenen Methoden können IT-unterstützte oder automatisierte Geschäftsprozesse beschreiben. Dies sind dann natürlich nur wohlstrukturierte Prozessabschnitte (vgl. Abschnitt 2.4). Semistrukturierte werden nur abschnittsweise erfasst. Unstrukturierte gar nicht.

So verstandenes Process Mining erfasst Nutzereingaben und Log-Dateien und wertet diese aus. Alle semantischen Strukturen sind damit nicht erfasst. Deshalb überrascht nicht, dass in der aktuellen einschlägigen Diskussion KI-Techniken betont werden. Mit diesen kann die Softwareinteraktion verbessert und der Bereich der wohlstrukturierten Aufgaben erweitert werden.

Heute

Angesichts dessen, dass die Standardtechniken des Process Mining nur ein eingeschränktes Bild der Geschäftsprozesse erbringen, wundert es nicht, dass die hier aktiven Unternehmen über eine Erhöhung der Leistungsfähigkeit nachdenken. Folgendes wird derzeit vorgestellt:

Morgen

Nutzung von Künstliche Intelligenz-Techniken und Machine Learning.

  • "Um Ursachen für Ineffizienzen und Abweichungen in den Prozessen zu erkennen."
  • "selbständig relevante Daten in unterschiedlichsten Systemen identifizieren und für die Prozessanalyse aufbereiten können."[ebenda]
  • Als Grundlage "für selbstlernende Prozesse …, in denen Zusammenhänge zwischen den Daten und Abläufen automatisch erkannt und mit Systemkonfigurationen sowie Kennzahlsystemen in Korrelation gesetzt würden."[ebenda]
  • Automatisierte Gewinnung von Kontextwissen aus den Systemdaten (Tobias Rother)

Vgl. Lana Labs nach [Bayer 2019a, S. 16]

Großflächige Prozessabdeckung

  • Verbesserung der Prozessabdeckung, hin zu einer möglichst großflächigen Erfassung ("Process Monitoring").
  • Kontinuierliche Erfassung und Optimierung der Geschäftsprozesse und ("Continuous Auditing").

Das Unternehmen Processgold hat dafür ETL-Funktionen entwickelt, die eine "integrierte Datenerfassung aus unterschiedlichsten Quellen wie SAP HANA, Microsoft SQL und Oracle erlauben." (so Rudolf Kuhn, CEO von Processgold, nach [Bayer 2019, S. 16f]). "Für die Transformation und Aufbereitung der einlaufenden Daten verfügt die Processgold-Lösung über eine eigene integrierte In-Memory-Datenbank." [ebenda]

Digitale Unternehmenslandkarte

Oliver Zeller (Geschäftsführer von Ploetz + Zeller ) "… bringt eine digitale Unternehmenslandkarte ins Spiel, die laufend Live-Daten aus dem Geschäftsbetrieb sammelt und anhand derer sich Prozesse beobachten, steuern und optimieren lassen. Die Verantwortlichen erhalten damit ein Abbild, wie Mitarbeiter, Kunden und Partner intern wie extern zusammenspielen" (Oliver Zeller, vgl. [Bayer 2019, S. 17]). Wichtig ist der von ihm gegebene Hinweis, "auch manuelle Abläufe, die keinen digitalen Fußabdruck in den IT-Systemen hinterlassen, in das Process Mining einzubeziehen" [ebenda].

19.3.6 Process Mining als wissenschaftliche Disziplin

In [van der Aalst 2016] findet sich eine umfassende Darstellung der wissenschaftlichen Bemühungen rund um Process Mining.

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

19.3.7 Unternehmen

Folgende Unternehmen werden in den angeführten Artikeln genannt:

  • Processgold
  • Lana Labs. Berliner Process-Mining-Startup.
  • Celonis
  • Software AG. Hat nach der Übernahme der IDS Scheer AG die BPM-Suite ARIS in Richtung Process Mining weiterentwickelt.
  • Process Analytics Factory (PAF) GmbH. Darmstädter Startup.
  • Ploetz + Zeller.
  • Fluxicon https://fluxicon.com/

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

19.3.8 Durchdringung, Ziele

[Reder 2019a] berichtet aus der Studie "Process Mining amp; RPA 2019" von IDG Research Services. Danach haben 18% der befragten Unternehmen (n=361) RPA-Pilotprojekte laufen oder abgeschlossen (S. 15). Als Beispiele für den Einsatz werden genannt (S. 16):

  • Call-Center und Helpdesk-Abteilungen, z.B. zum Zurücksetzen vergessener Passwörter.
  • Bereitstellen von Cloud-Servies
  • Erstellen von Angeboten durch eine Versicherung

Dabei sind die von den befragten Unternehmen genannten Ziele durchaus klassischer Natur:

  • Steigerung des Umsatzes
  • Niedrigere Kosten
  • Höhere Kundenzufriedenheit

Die befragten Unternehmen sehen derzeit folgende Probleme für den vertiefteren Einsatz von Machine Lerning-Techniken:

  • Die Qualität der vorhandenen Daten. Obwohl Daten von Maschinen und Produktionsanlagen sowie Transaktionsdaten, Kundeninformationen und Log-Daten vorhanden sind, mangelt es an der Qualität, die für die "Fütterung der ML-System" nötig ist (S. 19)
  • Unverständichkeit der Machine Learning-Algorithmen. Da könnten nur ML-Experten Abhilfe schaffen, die derzeit aber auf dem Arbeitsmarkt knapp sind, oder IT-Beratungsunternehmen.

19.4 Beispiele

19.4.1 Online-Fachhändler

Milad Safar, Managing Partner der Weissenberg Group, schildert ein Beispiel für den Einsatz bei einem Online-Fachhändler:

"Ein Online-Fachhändler vergleicht regelmäßig die Preise seiner Artikel mit den Preisen der identischen Artikel seiner Mitbewerber auf drei unterschiedlichen E-Commerce-Plattformen. Die recherchierten Informationen bilden die Grundlage für seine Preispolitik. Recherche und Kalkulation der optimalen Marge sind aber mit einem erheblichen zeitlichen Aufwand verbunden. Der Einsatz des Process Recorders ergab, dass der Mitarbeiter fünf Minuten benötigte, um den Preis für einen Artikel manuell aus drei Vergleichsportalen abzugleichen. Für den Preisabgleich von 5000 Artikeln auf den Vergleichsportalen summierte sich der Aufwand auf 52 Arbeitstage (bei acht Arbeitsstunden). Das bedeutete, dass die Preise nur alle zweieinhalb Monate aktualisiert werden konnten.

Nach der Automatisierung des Prozesses mittels RPA entnimmt ein Roboter dem System des Online-Händlers die notwendigen Artikeldaten und sucht die Artikel mit Hilfe festgelegter Kriterien auf den Portalen. Die Informationen über die gefundenen Artikel werden ausgelesen und gespeichert. Auf Grundlage dieser Daten erfolgt die Berechnung der optimalen Marge jedes einzelnen Artikels." [Safar 2018, S. 29]

Die Effizienzsteigerung ist in einem solchen Fall enorm. Die Auswertung der Daten ergab, "dass der Roboter die Arbeit, für die der Mitarbeiter noch fünf Minuten benötigte, in 16 Sekunden erledigt. Für den Preisabgleich von 5000 Artikeln braucht der Roboter jetzt gerade einmal 22 Stunden (2,7 Arbeitstage). Das entspricht einer Effizienzsteigerung von 95 Prozent." [ebenda]

19.4.2 ActBot

Von ActBots wird gesprochen, wenn Chatbots, Robotic Process Automation und Cognitive Computing verknüpft werden. Zur Erinnerung: Das Eigenschaftswort "cognitive" wird in diesem Bereich immer dann hinzugefügt, wenn KI-Techniken zum jeweiligen Instrumentarium hinzugenommen werden.

Haisermann/Rückershäuser schildern in Actbot-Beispiel, bei dem es um die Koppelung von "Mail-Bearbeitung beziehungsweise Chat und RPA" geht:

  • RPA-Bots für die Verarbeitung der jeweiligen Prozesse in Standardsoftwareprodukten wie CRM von Salesforce oder ERP/MM von S/4HANA.
  • Für das "Cognitive Computing und Chatbot" wurde, wegen dem "semantischen Konzept", das Angebot von Cognesysgewählt.
  • Für die RPA-Interaktion mit Salesforce und SAP S/4HANA fiel die Entscheidung auf das patentierte Bilderkennungsverfahren sowie das REST-API des Darmstädter RPA-Spezialisten Servicetrace.

[Haisermann und Rückershäuser 2019, S. 34]

Sie beschreiben dann drei Anwendungsfälle:

  • Anwendungsfall 1 (S. 35): "Direkte Kundenkommunikation mit Salesforce und Abgleich des Produktbestands in SAP S/4HANA im Modul MM. Abwicklung und Änderung der Bestellung zu einer Expressbestellung mit abschließendem Rechnungsversand über das SAP-Modul SD".
  • Anwendungsfall 2 (S. 36): "Lieferantenkommunikation via Chatbot mit einem RPA-Bot, der eine Saldenbestätigung im S/4HANA-Modul FI erzeugt und an den anfragenden Lieferanten per Mail versendet."
  • Anwendungsfall 3 (S. 36): "Mail-Eingang, Interpretation des Mail-Inhalts und Versenden einer Rechnungskopie aus dem S/4HANA-System."

Anwendungsfall 1 - Bestellungsänderung

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Der erste Anwendungsfall startet dadurch, dass ein Kunde für eine von ihm getätigte Bestellung den Status erfahren und gegebenenfalls eine Expresslieferung initiieren möchte. Folgende Schritte können aus dem in [Haisermann und Rückershäuser 2019, S. 35f] beschriebenen Beispiel abgeleitet werden (vgl. auch das unten angegebene Business Process Diagram):

(1) Kunde wählt die Webseiten bzw. das Portal des produzierenden Unternehmens an.

Kunde

(2) Kunde startet ChatBot und fragt nach dem Status seiner Bestellungen. Dies kann, wie man vielleicht aus eigener Erfahrung weiß, durchaus zu einer regen Kommunikation zwischen Mensch und Software führen. In diesem Fall zwischen einem ChatBot und einem Kunden. Im Wesentlichen wird dabei der Kunde mit seiner Kundennummer identifiziert.

Kunde und ChatBot

Zum nachfolgenden Business Process Diagram (BPD): Die "rege Kommunikation" wird hier durch das Element Gruppe ausgedrückt.

(3) Der ChatBot formuliert Anfrage für das CRM-System. Er kann also aus den Ausführungen des Kunden den Wunsch erkennen, er kennt auch die Struktur der Anfragen an das CRM-System und kann damit die Anfrage erstellen.

ChatBot zwischen Kunde und CRM

Hinweis: Im Beispiel ([Haisermann und Rückershäuser 2019, S. 35f]) wird der positive Fortgang beschrieben. Dass bei jeglichem Handeln mögliche Scheitern wird nicht betrachtet. In dem nachfolgenden Business Process Diagram wird dies genauso gehalten, das mögliche Scheitern aber durch ein Exclusive Gateway und ein Schlussereignis angedeutet.

(4) Der ChatBot greift auf CRM-System (Salesforce) zu, bestimmt alle Bestellungen des Kunden und prüft den jeweiligen Bestellstatus.

ChatBot mit CRM

(5) Der ChatBot zeigt dem Kunden die Ergebnisse an. Der Kunde wählt eine Bestellung aus und verlangt für diese eine Expresslieferung.

Kunde mit ChatBot

(6) Der ChatBot gibt die Anfrage an einen RPA-Bot weiter.

ChatBot und RPA-Bot

Zum nachfolgenden BPD: Dies wurde mit Empfänger-/Sender-Aufgaben modelliert. Alternativ wäre auch ein einfacher Informationstransport möglich.

(7) RPA-Bot greift auf SAP-S/4HANA-Modul MM zu und prüft, ob eine entsprechende Bestandsmenge vorhanden ist.

RPA-Bot und SAP MM

Zum nachfolgenden BPD: Dies wurde als Dienst-Aufgabe (service task object) modelliert. Besser wäre – parallel zur Nutzeraufgabe (user task object) – ein Aufgaentyp "bot task objekt" (Bot-Aufgabe), der ist aber derzeit noch nicht vorgesehen.

Die weiteren Prozessschritte gelten für den positiven Fortgang. Falls positiv, d.h. falls die Bestandemenge eine Expresslieferung zulässt:

(8) Der RPA-Bot übergibt die Informationen an den ChatBot.

RPA-Bot und ChatBot

Zum nachfolgenden BPD: Auch dies wurde wieder mit Empfänger-/Sender-Aufgaben modelliert. Alternativ wäre auch ein einfacher Informationstransport möglich.

(9) Der ChatBot bestätigt dem Kunden, dass Expresslieferung "zu einem bestimmten Preis" möglich ist.

ChatBot und Kunde

Auch hier wird wieder ein positiver Fortgang angenommen, d.h. dass der Kunde tatsächlich die Bestellung auf Expresslieferung umstellen will.

(10) ChatBot bittet Kunden um Bestätigung, Nennung seiner E-Mail-Adresse, um die "Zustimmung zum Datenschutz" und nimmt die Angaben entgegen.

ChatBot und Kunde

(11) ChatBot greift auf CRM-System zu und stellt die ausgewählte Bestellung auf Expressversand um.

Chat-Bot und CRM

Der RPA-Bot leitet den Prozess der Rechnungserstellung ein.

(12) ChatBot weist Kunden darauf hin, dass er in Kürze eine Rechnung in seinem elektronischen Postfach findet.

ChatBot und Kunde

(13) ChatBot meldet sich im SAP-S/4HANA-Modul FI/SD an, erstellt eine Ausgangsrechnung und sendet diese an die Kunden-Mail-Adresse.

Chat-Bot und SAP FI/SD

Die Zugriffe des RPA-Bots auf Software wurden a) durch eine entsprechende Grafik (PC-Symbol) und b) durch einen Pfeil für den Informationsaustausch modelliert.


Abbildung 19.4-1: BPMN-Prozessmodell ActBot-Beispiel – Teil 1
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.


Abbildung 19.4-2: BPMN-Prozessmodell ActBot-Beispiel – Teil 2
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.

Anwendungsfall 2 - Saldenbestätigung

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff]. Daraus wurde auch wieder ein Business Process Diagram, vgl. die folgende Abbildlung, abgeleitet.

Hier geht es um eine Saldenbestätigung, d.h. ein Lieferant möchte von einem Kunden seine Forderungen bestätigt haben. Im Beispiel ist der Kunde ein Fahrradhersteller mit einem seiner Lieferanten.

Hier die einzelnen Prozessschritte:

(1) Der Lieferant wählt die Webseiten/das Portal des Kunden (des produzierenden Unternehmens) an. Das Beispiel geht davon aus, dass der Lieferant auf einen ChatBot stößt und diesen startet.

Lieferant und ChatBot

(2) In der Kommunikation zwischen Lieferant und Kunde wird der Lieferant durch den ChatBot einschließlich seiner Lieferantennummer identifiziert. Anschließend wird sein Wunsch auf Saldenbestätigung erfasst.

Lieferant und ChatBot

Im nachfolgenden Business Process Diagram (BPD) wird diese Interaktion wieder durch ein Element Gruppe modelliert.

(3) Der ChatBot übergibt über ein REST API die Lieferantennummer an den RPA-Bot und bittet um Prüfung, ob der Lieferant Forderungen hat.

ChatBot und RPA-Bot

(4) Der RPA-Bot prüft im S/4HANA-Modul FI, ob der Lieferant Forderungen hat.

Dies ist derzeit die Standardsituation rund um RPA: Der RPA-Bot nutzt eine Software. Er kennt also die Eingabebedingungen, die Struktur der Eingaben und kann die Antworten der Software entgegennehmen sowie interpretieren.

(5) Falls der Lieferant Forderungen hat ("positives Ergebnis"), wird dies dem ChatBot gemeldet. Dieser übermittel das positive Ergebnis ("Ja, Sie haben Forderungen, …") an den Lieferanten und bittet diese um Zusendung seiner E-Mail-Adresse.

RPA-Bot und ChatBot

(6) Der ChatBot übergibt dann die Mail-Adresse, die Lieferantennummer und den Wunsch des Lieferanten an den RPA-Bot.

ChatBot und RPA-Bot

(7) Der RPA-Bot greift auf das SAP-S/4-Modul FI zu, erstellt eine Rechnungsübersicht und wandelt diese in ein PDF-Dokument.

(8) Der RPA-Bot sendet die Rechnungsübersicht per Mail an den Lieferanten.

RPA-Bot und Lieferant

(9) Falls der Lieferant keine Forderungen hatte, wird dies ebenfalls dem ChatBot gemeldet. Dieser übermittelt das negative Ergebnis dem Lieferanten.

Die Zugriffe des RPA-Bots auf Software wurden a) durch eine entsprechende Grafik (PC-Symbol) und b) durch einen Pfeil für den Informationsaustausch modelliert.


Abbildung 19.4-3: BPMN-Prozessmodell Saldenbestätigung
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html

Anwendungsfall 3 – Reklamationsmanagement

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Bei diesem Beispiel findet die Kommunikation ausschließlich per Mail statt. Betrachtet wird die Anforderung einer neuen Rechnungskopie durch einen Lieferanten. Vgl. auch das nachfogende Business Process Diagram.

Hier die einzelnen Prozessschritte:

(1) Kunde oder Lieferant sendet eine Mail an die "Cognitive-Instanz". D.h., der Kunde stößt mit seiner Anfrage auf Softwarekomponenten, die KI-Techniken realisieren.

Kunde und Cognitive-Instanz

(2) Die Cognitive-Instanz interpretiert und klassifiziert die Mail.

Cognitive-Instanz

(3) Die Cognitive-Instanz prüft, ob die Daten vollständig sind.

(4) Falls die Daten vollständig sind, werden sie über das REST API an den RPA-Bot übergeben.

Cognitive-Instanz und RPA-Bot

Im Beispiel wurde nicht ausgeführt, was geschieht, falls die Daten nicht vollständig sind. So wird es auch hier gehalten.

(5) Der RPA-Bot nimmt die Daten an und zieht im S/4HANA-System eine Rechnungskopie.

RPA-Bot mit SAP S/4HANA

(6) Der RPA-Bot versendet die Rechnungskopie an den Lieferanten. Der RPA-Bot soll also auch selbständig Nachrichten versenden können.

In diesem Beispiel spielt die sog. Cognitive-Instanz (vgl. Abschnitt 19.2) eine zen­trale Rolle. Ihre Aufgabe der Interpretation und Klassifizierung von Mail verlangt eine leistungsstarke KI-Lösung.

Anmerkungen zu den obigen Beispielen

Insgesamt ergeben die Beispiele ein eindrucksvolles Bild bzgl. des notwendigen Zusammenspiels von Softwarekomponenten. Es wirken mit:

  • RPA-Bots
  • CRM (Salesforce)
  • Module von SAP S/4HANA.
  • Cognitive Computing
  • Bilderkennungsverfahren sowie eine REST-API
  • ChatBots

Für eine detaillierte Beschreibung des Ablaufs vgl. [Haisermann und Rückershäuser 2019].


Abbildung 19.4-4: BPMN-Prozessmodell Reklamationsmanagement
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.

19.4.3 RPA Datenbankübergreifend

Herrmann erwähnt als Einsatzgebiete für RPA datenbankübergreifende Abgleiche von Informationen. Beispielsweise die Änderung von Kundenadressen, z.B. in der Finanz- und Versicherungsbranche. Auch eine polizeiliche Personenüberprüfung, wie sie etwa beim Beantragen eines Waffenscheins obligatorisch ist, ließe sich, so Herrmann, beschleunigen. Bearbeiter müssen heute verschiedene Datenbanken konsultieren, um zu prüfen, ob gegen einen Antragsteller etwas vorliegt. Diese Aufgabe könnte ein RPA-System zumindest teilweise erledigen und beispielsweise alle Personen aussortieren, für die kein negativer Eintrag zu finden ist. Genauer prüfen müssten die Bearbeiter dann nur noch wenige Einzelfälle [Herrmann 2017, S. 20].

Ein konkretes Beispiel für datenbankübergreifende Aktivitäten führt Bayer an:

Dekabank

"So hat die Dekabank nach der Übernahme der Landesbank Berlin Investment (LBB-Invest) 2014 rund 46.000 Wertpapierdepots in ein einheitliches System übertragen. Eine manuelle Migration inklusive Datenprüfung hätte rund drei Jahre gedauert, so die Kalkulation der Verantwortlichen. Der gemeinsam mit Capgemini Consulting entwickelte Softwareroboter schaufelte die Depotdaten innnerhalb von zehn Tagen in das Dekabank-System und sorgte nebenbei auch noch für eine bessere Datenqualität, indem er unplausible Datensätze erkannte und automatisch reparierte." [Bayer 2018, S. 19]

19.4.4 Automatisierte Prozesserkennung

Ulrich Storck (Head of Product Development bei der Scheer GmbH) beschreibt in einem Vortrag auf dem Scheer Digital World Congress 2018 in Frankfurt am Main die Scheer Process Automation Suite als "Low-Code-Plattform für die modellgetriebene Digitalisierung und Automatisierung von menschlichen Arbeitsprozessen." [Bremmer 2018b, S. 24]

Scheer Process Automation Suite (PAS)

Sie dient als

"… eine Methode, mit deren Hilfe Arbeitsprozesse automatisiert erfasst und dokumentiert werden können. Mit Desktop Activity Mining, das Techniken aus dem Data und Process Mining nutzt, würden Vorarbeiten entfallen, die bisher für RPA notwendig waren. Im Detail werden über ein im Hintergrund laufendes Aufnahmeprogramm die relevanten Prozessaktionen der Mitarbeiter wie Texteingaben, Mausklicks oder Programmaufrufe identifiziert und anonymisiert erfasst. Aus diesen werden dann mit Process-Mining-Algorithmen Prozessmodelle generiert, um eine umfangreiche Darstellung des realen Arbeitsprozesses zu erhalten." [Bremmer 2018b, S. 25]

Dies erscheint beim gegenwärtigen Entwicklungsstand nicht möglich, erfasst doch die Aktvität des Nutzers am Desktop, selbst wenn sie sehr umfassend erfolgt, nur einen Teilaspekt des Geschäftsprozesses. So auch Ulrich Storck, der in seinem Vortrag auch anmerkt, dass sich bzgl. RPA bei vielen Anwendern "eine gewisse Ernüchterung einstellt, "geboren aus der Erkenntnis, dass RPA nicht die eierlegende Wollmilchsau ist, sondern nur ein Mittel von vielen." [Bremmer 2018b, S. 24]

Realismus

20 Geschäftsprozesse im Internet - NoSQL et al.

Die Ausführungen in diesem Kapitel sind eine aktualisierte Zusamenfassung von Kapitel 24 ("Andere Datenbanken") aus dem Buch

Staud, Josef: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. Vilshofen 2015,

Buch zu Datenbanken

Vgl. für nähere Informationen zu diesem Buch www.staud.info.

20.1 Neue Anforderungen, neue Datenbanken

Das war noch eine "gemütliche Zeit", als sich die Hardware und Software für die Unterstützung der Geschäftsprozesse auf dem (unternehmens-; organisations-)eigenen Rechner (heute gern "On Premise" genannt) befanden. Davon kann heute keine Rede mehr sein. Heutzutage wird zumindest ein Teil, wenn nicht sogar die gesamte Geschäftstätigkeit von Unternehmen "im Internet" abgewickelt.

Insbesondere wenn die Kunden zahlreich sind und sich über den Globus verteilen, ist das Internet der Bereich, in dem sich Geschäftstätigkeit abspielt.

Nehmen wir als Beispiel die Internet-Unternehmen. Bei ihnen spielt sich die Geschäftstätigkeit ganz im Internet ab. Mit einer Software, die umfassend die Interaktion mit Kunden realisiert (und evtl. anderen Partnern) und mit Kunden, die über das Internet auf diese Software zugreifen.

Geschäftstätigkeit im Internet

Die Geschäftsprozesse nutzen also das Medium Internet. Dies geht nur, wenn die dort notwendigen Software- und Speicherlösungen berücksichtigt werden, deren Grundzüge von eben diesen Internet-Unternehmen (v.a. Google, Amazon) bei ihrer Expansion entwickelt wurden und ständig weiterentwickelt werden. Der Schwerpunkt liegt dabei auf neuen Datenstrukturen und Speichertechniken, weil sich für diese Geschäftsprozesse und ihre Kunden die klassischen Datenbanktechniken als ungeeignet erwiesen haben und neue entwickelt werden mussten. Dann war und ist da das Problem des Zugriffs, denn die zahlreichen und geographisch weit verstreuten Kunden verlangten rasche Antwortzeiten. Auch dies verlangte neue Lösungen.

Neue Datenstrukturen,
Speichertechniken und
Zugriffstechniken

Alle diese neuen Technologien und Techniken waren so erfolgreich, dass sie sich auf breiter Front durchgesetzt haben, so dass sie heute für Organisationen aller Art Bedeutung haben.

"Bedeutung" meint hier vor allem, Bedeutung für die Abwicklung der Geschäftsprozesse. Mit anderen Worten: Geschäftsprozessmanagement muss heute auch die Realisierung von Geschäftsprozessen im Internet reflektieren.

Deshalb werden hier, ohne allzuviele technische Details, die Grundlagen dazu vorgestellt.

20.1.1 Neue Datenbanktechnologien

Jede prozessorientierte (integrierte) Software verwaltet Daten. Diese waren bis vor einigen Jahren ausschließlich relational strukturiert. D.h., man kann diese Daten in das übliche Attribut/Objekt-Schema pressen (zu Objekten werden Attribute erhoben) und diese dann in Relationenform ("Tabellen") speichern (vgl. [Staud 2015, Kapitel 4]). Mit relationalen Datenbanken und Datenbanksystemen war man gut bedient, zumal das Geschwindigkeitsproblem durch neue Technologien (z.B. InMemory-Datenbanken) gelöst erschien. Doch in den letzten 20 Jahren hat sich die Situation grundlegend gewandelt.

strukturierte Daten

Im Kern geht es dabei darum, dass unstrukturiert genannte Informationen und Daten auch Gegenstand von digitaler Erfassung, Speicherung, Verwaltung und Verarbeitung wurden. Dies betraf zuerst Texte, nicht als Attributsausprägung, sondern als Langtext, dann Dokumente (sozusagen strukturierte Texte), Graphen und Netzwerke (motiviert durch die Beziehungsdaten des Internet), Audio- und Video-Daten und einige mehr.

unstrukturierte Daten

Folgende Herausforderungen waren und sind zu meistern:

  • Diese Informationen konnten und können nicht sinnvoll mit relationalen Datenbanken verwaltet werden. Die erste Herausforderung bestand also darin, datenverwaltende Systeme für diese Informationsarten zu finden.
  • Die zweite Herausforderung stellten die großen Datenmengen dar. Selbst wenn es mal gelang, einige dieser "neuen" Daten in eine relationale Datenbank zu packen, erwiesen sich die Antwortzeiten der relationalen Datenbanksysteme als zu langsam. Diese Herausforderung verlangte also nach "mehr und schnellerer Hardware" (vertikale Skalierung durch immer stärkere Server, leistungsfähigere Prozessoren).
  • Die dritte Herausforderung bestand darin, dass diese Daten teilweise nicht nur "im Internet" entstehen, sondern dort auch verwaltet werden müssen (horizontale Skalierung).

Es entstand also Leidensdruck, der zu verschiedenen neuen Angeboten führte:

  • Neue Speichertechniken (z.B. spaltenorientierte Datenbanken, vgl. Abschnitt 20.2.12)
  • Neue Datenstrukturen, die einfacher zu verwalten sind (Key/Value-Daten, vgl. Abschnitt 20.2.9)
  • Neue Art der Datenhaltung (in Netzwerken, horizontal skaliert, NoSQL-Datenbanken)
  • Neue Auswertungsmöglichkeiten

Sehr schnell wurde erkannt, dass diese Informationsarten und die mit ihnen möglichen Auswertungen im Rahmen des Informationsmanagements der Organisationen genutzt werden müssen, so dass sich neue Aufgaben für die Verwaltung der Daten ergaben.

20.1.2 BigData

Seit einigen Jahren wird der Begriff Big Data genutzt, um die großen Datenmengen, die mittlerweile in der digitalisierten Welt entstehen, zu kennzeichnen. Dabei geht es inzwischen nicht mehr um Megabyte (MB) oder Gigabyte (GB), sondern um Tera- Peta- und Zetabyte. Der Grund für das Entstehen dieser Datenmengen ist, dass sie in digitalen Systemen entstehen und daher leicht erfasst werden können und dass die digitalen Systeme aller Art intensiv genutzt werden.

Exkurs: Größere Einheiten von Bytes

Bezeichnung

Abkürzung

Anzahl Bytes

Byte

B

20= 1 Byte

Kilobyte

KB

210 = 1024 Bytes

Megabyte

MB

220 = 1024 KB

Gigabyte

GB

230 = 1024 MB

Terabyte

TB

240 = 1024 GB

Petabyte

PB

250 = 1024 TB

Zetabyte

ZB

260 = 1024 PB


 

Eine Quelle für diese Datenmengen ist das Internet, das für viele Menschen nicht nur ein Hilfsmittel für Kommunikation und Informationsspeicherung geworden ist, sondern mit seinen Möglichkeiten

  • dort die geschäftlichen Aktivitäten zu tätigen,
  • die sozialen Beziehungen in Clique, Kohorte (vgl. unten) und vielleicht auch Familie zu pflegen,
  • dort kriminelle Aktivitäten zu entwickeln,
  • als Plattform für die Selbstdarstellung zu dienen,
  • Kommunikation unterschiedlichster Art zu ermöglichen (Mail, Telefonie, SMS, ...),
  • von dort - aus der Cloud - Rechenleistung zu beziehen,

den Charakter einer Parallelwelt zur realen angenommen hat. Dafür spricht auch, dass sich dort, genauso wie in der wirklichen Welt, nicht nur eine Rotlichtszene, sondern auch sehr aktive kriminelle und terroristische Milieus gebildet haben und - so sagen einige Prognosen - dort in der Zukunft auch Kriege geführt werden (cyber war).

Kohorte: Die, mit denen man zusammen das Leben verbringt und die nicht unbedingt zum Freundeskreis gehören. Je nach Alter z.B. die Schulklasse, die anderen Beschäftigten am Arbeitsplatz, die Menschen, mit denen man im Rahmen seiner Freizeitaktivitäten zu tun hat, usw.

Clique: Freundeskreis. Die, deren Urteil einem wichtig ist.

Diese Parallelwelt beruht auf Rechnernetzen mit großen Serverrechenzentren, PCs (und Smartphones) der Nutzer und dem leistungsstarken weltumfassenden Telekommunikationsnetz. Sie ist so erfolgreich, dass ihr schon die Adressen ausgingen und deshalb neue längere Adressen eingerichtet werden mussten. Das "alte" IPv4 hatte einen Adressraum von 232 (etwas über vier Milliarden) IP-Adressen, das neue IPv6 erlaubt 2128 (rund 340 Sextillionen) Adressen. Dies sollte erst mal reichen.

Grundlage 1: Rechnernetze

Sie beruht aber auch auf sehr leistungsstarken Speichermedien, die inzwischen bei erschwinglichen Preisen Terabyte von Daten der unterschiedlichsten Art verwalten können. Diese Speicherkapazität kann über verteilte Netzwerkarchitekturen beliebig und flexibel ausgebaut werden.

Grundlage 2: Datenbanken

Der Bedarf an Datenübertragungskapazitäten, an Rechner- und Speicherkapazität im Internet (das heutzutage den wesentlichen Teil des globalen Computernetzwerks beansprucht), wird noch weiter wachsen. Die zwei wichtigsten Ursachen hierfür sollen aufgezeigt werden.

Immer mehr Daten in den Rechnernetzen

Ursache 1: Immer mehr Daten in den Rechnernetzen

Das weltweite Rechnernetz ist tatsächlich eine Parallelwelt geworden, in der inzwischen nicht nur die Wirtschaft wichtige Anteile ihrer Aktivitäten abwickelt. Um nur die wichtigsten zu nennen:

Parallelwelt Rechnewrnetze

  • Kommunikation über das Internet und Verwaltung der dabei entstehenden Daten in großen Datenbanken.
  • Nutzung von Service-Rechenzentren, die irgendwo "im Internet" angesiedelt sind (oft Cloud genannt). Dies können Entwicklungsumgebungen sein, einfache Anwendungen (Mail-Server, Finanzbuchhaltung, usw.) oder eine ganze ERP-Software (vgl. Abschnitt 17.3). Dabei wird Geschäftstätigkeit ins Internet verlagert und damit in eine vernetzte Umgebung. Wenn ein Unternehmen seine Geschäftsprozesse mit einer Software in der Cloud abwickelt, werden die Handlungen dieses Unternehmens durch Netzstrukturen realisiert. Z.B. liegen die Kundendaten dann "in der Cloud", die Rechnung wird dort erstellt, evtl. durch einen sog. WebService in ein PDF-Dokument überführt und vom selben Web-Dienstleister versandt.

WebService: Einfach ausgedrückt ein Programm, das per Internet angeboten wird und das ein Unternehmen in seine Geschäftsprozesse einbauen kann.

Alles das schafft bereits Bedarf an zuverlässiger und robuster Netzkapazität und an leistungsstarken Speichermedien. Doch was ist das gegenüber dem, was wir Menschen in unserem privaten Leben, das viele ja auch ins Internet verlagert haben, an Bedarf erzeugen? Auch hier nur die wichtigsten diesbezüglichen Aktivitäten:

  • Repräsentationen von uns im Netz (oft Profile genannt) pflegen, die von uns selbst oder von anderen erstellt wurden. Es geht darum, uns im Social Web zu präsentieren, uns darzustellen, mit Informationen aller Art.
  • Beziehungen pflegen im Social Web, z.B. unter dem Gesichtspunkt "Wer teilt mit wem welche Vorlieben?" Dies sind netzwerkartig strukturierte Informationen, die eine besondere Herausforderung an Speicherung und Verarbeitung stellen. Sie haben die Tendenz immer weiter zu wachsen, weil schon die Plattformbetreiber sie erfassen und auswerten und andere Unternehmen dies inzwischen auch tun.
  • Bilder auf entsprechende Plattformen laden.
  • Videosequenzen hoch- oder runterladen.
  • Ständiges automatisiertes Daten sichern "in die Cloud".
  • SMS - Nachrichten versenden.
  • Kommunikation per Mail.
  • Kommunikation mit Gruppen, z.B. durch Twitter.
  • Spielen im Internet, auch in weltweit organisierten Gruppen.
  • Telefonieren über das Internet. Die vollständige Umstellung auf IP-Telefonie ist realisiert.
  • Radio hören über das Internet.
  • Fernsehen über das Internet; „Streamen“ von Videomaterial.
  • Einkaufen auf der Basis von Geschäftsprozessen, die in Software "gegossen" wurden.
  • Log-Dateien erfassen und auswerten. Hinweise hierzu finden sich in [Wartala 2012].
  • Daten zum Kaufverhalten auf Shopping-Seiten im Internet und ihr in Beziehung stzen mit vielen Millionen Werbemittelsichtkontakten von Online-Werbung [Wartala 2012, S. 9].
  • Daten aus Suchmaschinen zum Suchverhalten der Nutzer.
  • Überwachung von Logistikvorgängen durch Logistikunternehmen.
  • Durchführung von Fernunterricht. Z.B. in großem Umfang in Verbindung mit der Pandemiebekämpfung in 2020. Dies erforderte nicht nur leistungsstrake Netzwerke, sondern auch große Mengen Speicherplatz, v.a. für aufgezeichnete Vorlesungen, usw.
  • Realisierung des Kundenbeziehungsmanagements (CRM) - ganz allgemein und v.a. auch bei Internet-Unternehmen.

Vgl. auch die Ausführungen in [Wartala 2012, S. 15ff].

Bei den meisten dieser Aktivitäten entstehen Daten, die dauerhaft gespeichert werden.

Ursache 2: Internet der Dinge und Industrie 4.0

Lange Zeit blieb der Einsatz von PCs, Workstations und der größeren Systeme auf den Arbeitsplatz in der Firma oder zu Hause beschränkt. Durch die Kombination von Computertechnik mit modernen Kommunikationseinrichtungen eröffnen sich jedoch viele weitere Einsatzgebiete. Zum Beispiel beim Mobiltelefon oder Handy. Es wurde vom mobilen Telefon zum universellen Kommunikationsendgerät, den Smartphones, weiterentwickelt.

Die Gerätevielfalt nimmt fast täglich zu und reicht bis zu am Körper tragbaren Rechnern (wearable computer), etwa in Form von Armbanduhren, Brillen oder eingenäht in "intelligente" Kleidung. Die Einsatzbereiche sind vielfältig: Sie lassen beide Hände zum Arbeiten frei, können als mobiles Navigationssystem oder als Überwachungseinheiten für Körperparameter (z.B. Blutdruck, Temperatur usw.) dienen. Will man den Kommunikationsaspekt betonen, spricht man in diesem Zusammenhang auch vom Internet der Dinge.

Internet der Dinge

Dieses sog. Internet der Dinge wird die "Vermaschung" der Computernetze deutlich erhöhen. Es entsteht damit unterhalb der globalen, nationalen und regionalen Ebene eine Vernetzung, die im lokalen Umfeld stattfindet.

"Lokale Vernetzung"

Im Bereich der Industrie, vor allem der Produktionssteuerung und der Logistik, wird das Internet der Dinge zu Industrie 4.0. Auch hier werden "Dinge" (Bauteile, Produkte, Maschinen, Anlagen) mit kommunikationsfähigen "intelligenten" Systemen ausgestattet, mit denen sie kommunizieren, Umweltbedingungen aufnehmen und innerhalb der gesetzten Grenzen handeln können.

Industrie 4.0

Die Zahl 4 rührt von der Einteilung der Industriegeschichte in industrielle Revolutionen her. Die Erste: Einführung mechanischer Produktionsanlagen mit Wasser- und Dampfkraft (Ende 18. bis Beginn 20. Jahrhundert); Die Zweite: arbeitsteilige Massenproduktion mithilfe elektrischer Energie (bis in die 1970-er Jahre); Die Dritte: Einsatz von Elektronik und IT zur weiteren Automatisierung der Produktion (bis heute). Vgl. [Lange 2013, S. 110].

Gedacht ist hier an Produktion und Logistik, die in Echtzeit über das Internet vernetzt werden sollen und zwar über die gesamte Wertschöpfungskette hinweg, nach Möglichkeit sogar unternehmensübergreifend. Weil die Vernetzung über das Internet erfolgen soll und weil auch Software zur Steuerung der Kontrollflüsse nötig ist, spricht man hier auch von Cloud-Lösungen, denn natürlich ist die steuernde Software am besten in den Rechenzentren der Cloud aufgehoben.

Im Kern geht es also um die

"... Verbindung der realen Industrie-Abläufe mit den sie steuernden virtuellen Softwaresystemen in Echtzeit und ohne kostentreibende Medienbrüche" (Wolf-Rüdiger Hansen, Geschäftsführer des Verbandes Automatische Identifikation, Datenerfassung und Mobile Kommunikation e.V. (AIMD), zitiert nach [Lange 2013, S. 109]).

Eine der Basistechnologien von Industrie 4.0 ist das oben vorgestellte RFID. Weitere werden entwickelt. Industrie 4.0 bringt also eine weitere intensive Vernetzung mit sich, jetzt zwischen den physikalischen Objekten unserer Welt. Hinweise auf damit verbundene Risiken und offene Fragen finden sich in [Lange 2013].

Der erwartete Nutzen ist groß, denn schließlich soll eine weitere Automatisierung mit "intelligenten" Elementen erreicht werden. Dies könnte Einsparungen in der Produktion, Logistik und Lagerhaltung ermöglichen, da z.B. die Teile miteinander und mit steuernden Elementen kommunizieren könnten. Ein möglicher Vorteil könnte auch sein, niedrige Losgrößen leichter zu angemessenen Kosten herstellen zu können. Dies käme dem Trend zu immer mehr individualisierten Produkten entgegen.

Alle diese Aktivitäten führen zu einem immensen Speicherbedarf, denn für die meisten dieser Aktivitäten gilt: Was wären sie ohne abgespeicherte Daten? Vor allem diese können ausgewertet werden. Neben der Größe der Datenmengen ist ein zweiter Punkt wichtig, will man die jüngste Entwicklung im Datenbankbereich verstehen, die große Vielfalt der "neuen" Daten:

Immenser Speicherbedarf und Vielfalt

  • Netzwerkdaten aus dem Social Web und anderen Bereichen des Internet. Hier erfassen die Daten die Kontaktaufnahmen zwischen Teilnehmern am Netz. Daten dieses Typs werden am besten als Graphen verarbeitet.
  • Faktendaten aus dem Social Web. Die hier entstehenden Informationen beruhen auf Dokumenten.
  • Andere sog. unstrukturierte Daten.

In den folgenden Kapiteln betrachten wir nun, welche Techniken, Methoden und Systeme dafür heute zur Verfügung stehen.

20.2 NoSQL-Datenbanken

20.2.1 Begriff

Der Begriff NoSQL-Datenbanken dient in der Literatur zum einen zur Abgrenzung von relationalen Datenbanken, meist wird er dann aber präzisiert auf Datenbanken in der "Web-2.0-Welt". Dabei wird auf die sozialen Netzwerke wie Facebook, Twitter, usw. verwiesen, in denen sehr große Datenmengen entstehen und verarbeitet werden sollen.

Wie so vieles in der Entwicklung der Anwendungssysteme entstanden auch die NoSQL-Datenbanken aus einem Leidensdruck heraus: Die relationalen Datenbanksysteme sind für die attributbasierte Information, wie sie in den obigen Kapiteln beschrieben wurde, sehr gut geeignet, nicht aber für andere Arten von Information, wie einfache Fakteninformation (z.B. Dokumente), textliche Information, Beziehungsdaten, chemische Strukturformeln, Bildinformation, Zeitreihen und viele andere. Deshalb entstanden immer alternative datenverwaltende Systeme. Die wichtigsten aus der Vergangenheit sind:

Not only SQL

  • volltextverarbeitende Systeme mit invertierten Listen (Information Retrieval Systeme genannt). Die Suchmaschinentechnologie von Google etc. beruht im Kern auf deren Technologie
  • Faktendatenbanken mit einfachen Fakten zu Unternehmen, Personen usw.
  • Dokumentationssysteme mit attribut- und textbasierter Information
  • Chemiedatenbanken mit ihren Systemen zur Verwaltung von chemischen Strukturformeln (genauer: deren Repräsentation im Rechner)

Heute werden diese und weitere neu hinzugekommene Informationen unter dem Stichwort unstrukturierte Informationen geführt und - wenn es sehr viele sind - mit Big Data bezeichnet. Die datenverwaltenden Systeme für einige dieser Informationsarten erhielten die Bezeichnung NoSQL - Datenbanksysteme. Dies sind derzeit:

  • Dokumentenorientierte Datenbanken
  • Key/Value - Datenbanken
  • Spaltenorientierte Datenbanken
  • Graphendatenbanken

Ihr "Heimatort" ist heute das Internet, insbesondere die Web 2.0 - Welt [Trelle 2014, S. 2].

In der einschlägigen Literatur zu diesem Thema werden oft die Begriffe Datenbanksystem und Datenbank nicht klar getrennt. Dies macht die Lektüre - v.a. für Einsteiger in das Thema - nicht einfacher. Trotzdem bleibt es dabei: Datenbanksysteme sind die entsprechenden datenverwaltenden Softwareprodukte, Datenbanken die Datenbestände.

Noch einmal: Bis auf die spaltenorientierten Datenbanken, bei denen es um eine spezifische Speicherung von Tupel-Daten geht (eine, die schnellere Zugriffe und Auswertungen erlaubt), sind dies jeweils sehr unterschiedliche Datenbanksysteme für sehr unterschiedliche Daten, die mit Relationalen Datenbanken nur sehr schwer verwaltet werden können.

Vgl. Abschnitt 20.2.12

20.2.2 Definition

NoSQL-Datenbanksysteme werden in der einschlägigen Literatur wie folgt definiert:

1. Nicht-relationales Datenmodell

2. Ausrichtung auf verteilte Architekturen und horizontale Skalierbarkeit

3. Schemafreiheit bzw. schwächere Schemarestriktionen

4. Unterstützung einer einfachen Datenreplikation, aufbauend auf einer verteilten Architektur

5. Einfache API(Application Programming Interface; Programmierschnittstelle)

6. Anderes Konsistenzmodell als bei relationalen Datenbanksystemen: Eventually Consistent und BASE, aber nicht ACID

Vgl. beispielhaft [Edlich, Friedland, Hampe u.a. 2011, S. 2], [Gull 2011].

zu Punkt 1: Dieser Punkt grenzt gegenüber relationalen Datenbanken ab. Zu beachten ist aber, dass es noch sehr viele weitere Datenmodelle und Datenbanken gibt, die nicht relational sind, nicht mit SQL bearbeitet werden können und trotzdem nicht in den Bereich der jetzt diskutierten NoSQL-Datenbanken fallen.

zu Punkt 2: Dies war ein wichtiger Motivator. Ursache sind die riesigen Datenmengen.

zu Punkt 3: Schemaänderung meint Änderung des Datenmodells und (vor allem) der logischen Datenorganisation. Das also, was mit SQL durch Alter Table realisiert wird. Dies ist sehr aufwendig bei laufendem Betrieb und auch nicht ungefährlich für den Datenbestand. Bei NoSQL-Anwendungen soll dies einfacher zu lösen sein.

zu Punkt 4: Dies ergibt sich aus dem Design der meisten NoSQL-Anwendungen, das auf verteilten Netzwerkarchitekturen beruht. In solchen Strukturen muss leicht repliziert werden können. So kann mit CouchDB eine Datenbank mit einem einzigen Befehl repliziert werden.

zu Punkt 5: Dieser Punkt reicht tief. Da das normale Instrumentarium eines klassischen Datenbanksystems (z.B. eine komfortable Abfrage- und Auswertungssprache) nicht zur Verfügung steht und auch die dort möglichen inhaltlichen (relationalen) Verknüpfungen nicht und außerdem die Datenstruktur selbst fast semantikfrei ist (meist nur Key/Value-Paare, siehe Abschnitt 20.2.9), muss hier wesentlich mehr (eigentlich fast alles) rund um die Datenabfrage und -auswertung programmiert werden. Deshalb ist eine einfache Programmierschnittstelle (API) unabdingbar.

Programmieraufwand

Noch tiefer (mit [Edlich, Friedland, Hampe u.a. 2011, S. 51]):

Das dominante Entwurfsmuster für heutige verteilte Anwendungen wird REST genannt. Es hat sich "... in seiner Inkarnation http als extrem erfolgreich hinsichtlich der Skalierbarkeit erwiesen." Problematisch wird es bei komplexen Abfragen. Dann müssen die NoSQL-Anwender diese als MapReduce-Abfragen formulieren (vgl. Abschnitt 20.2.6).

REST (Representational State Transfer) gilt als die Basis für die Skalierbarkeit des World Wide Web von einem einzelnen kleinen Server am CERN im Jahr 1990 zum weltumspannenden Netzdienst mit Milliarden von Nutzern heutzutage. Nicht die effizienteste Ausnutzung des Einzelsystems steht im Vordergrund, sondern die effektive Verteilung der Systemlast auf viele Maschinen. Die Plattform skaliert nahezu linear mit der Anzahl der verfügbaren Maschinen [ebenda].

zu Punkt 6: In NoSQL-Anwendungsbereichen sind die Anforderungen relationaler Datenbanksysteme an Konsistenz der Daten und Sicherheit der Transaktionen (ACID) nicht realisierbar. Vielleicht auch nicht nötig, wie die einschlägige Fachliteratur meint. Insgesamt wird nicht ACID(Atomar, Konsistent, Isoliert, Dauerhaft) realisiert, sondern BASE (basic available, soft state, eventually consistent). Vgl. Abschnitt 20.2.4.

BASE statt ACID

20.2.3 NoSQL-Kernsysteme

Folgende NoSQL-Kernsysteme werden in der Literatur genannt (mit zum Teil leicht abweichenden Bezeichnungen):

  • Wide Column Stores/Column Families
  • Document Stores, Document Full Text Search
  • Key/Value Tuple Stores
  • Ordered-Key-Value Stores
  • BigTable
  • Graphdatenbanken (auch: Graph Ordered-Key-Value Stores)

[Edlich, Friedland, Hampe u.a. 2011], [Welkenbach und Schmutz 2012], [Kurowski 2012], [Wolff et al. 2013]. Vgl. die (auch vergleichenden) Abbildungen zu Struktur und Speicherkonzept dieser datenverwaltenden Systeme in [Welkenbach und Schmutz 2012, "Abb. 2"].

Auf eine wichtige Eigenschaft der meisten NoSQL-Datenbanken weisen Wolff et al. hin:

NoSQL-Datenbanken vermeiden "weitestgehend" die Erfassung von Beziehungen zwischen den Datensätzen. "Wenn Datensätze stark miteinander in Beziehung stehen, ist es schwer, die Daten auf mehrere Server zu verteilen" [Wolff, Nitschinger und Trelle 2014, Pos. 38].

Und damit ist, so kann man ergänzen, horizontale Skalierbarkeit wesentlich erschwert und bei großen Datenmengen mit verlangten schnellen Antwortzeiten nicht mehr möglich.

Beispiele und einige ihrer Fundstellen

Beispiele für NoSQL-Systeme:

  • Apache HBase (Beschrieben in [Fondermann, Spichale und George 2014, Kapitel 3], [Wolff et al. 2013, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 64ff].
  • Amazon SimpleDB. Beschrieben in [Edlich, Friedland, Hampe u.a. 2011, S. 96ff]
  • CouchDB. Beschrieben in [Kurowski 2012, Kapitel 2], [Wolff, Nitschinger und Trelle 2014, Kapitel 2], [Edlich, Friedland, Hampe u.a. 2011, S. 118ff], [Gull 2011]
  • MongoDB. Beschrieben in [Kurowski 2012, Kapitel 3], [Wolff, Nitschinger und Trelle 2014, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 131ff].
  • Redis. Beschrieben in [Kurowski 2012, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 152ff], [Trelle 2014].
  • Cassandra. Beschrieben in [Wolff et al. 2013, Kapitel 3], [Edlich, Friedland, Hampe u.a. 2011, S. 82ff]
  • Riak (NoSQL-Key-Value-Store). Beschrieben in [Wolff, Nitschinger und Trelle 2014, Kapitel 3], [Edlich, Friedland, Hampe u.a. 2011, S. 179ff].
  • Neo4j. [Wolff et al. 2013, Kapitel 2], [Edlich, Friedland, Hampe u.a. 2011, S. 290ff]
  • ArangoDb von triAGENS (hps@ct.de). Quelloffen mit Applikations-Framework Foxx 2.0.

Vgl. die Übersicht zu NoSQL-Datenbanken in [Edlich, Friedland, Hampe u.a. 2011, S. 371ff] ("Orientierung im Datenbankraum").

Im Folgenden werden nun weitere Begriffe und Konzepte aus diesem Umfeld geklärt und die angeführten Typen datenverwaltender Anwendungssysteme genauer betrachtet.

20.2.4 Volume, Velocity, Variety

Mit diesem Datenumfang sind meist auch Aufgaben verbunden, die mit Relationalen Datenbanksystemen kaum zu lösen sind. Diese grundlegenden Herausforderungen im BigData-Umfeld werden in der Literatur oft durch die Stichworte Volume, Velocity und Variety (3V) beschrieben:

  • Volume: Masse an Daten, die pro Zeiteinheit gespeichert werden müssen. Diese ist in BigData-Anwendungsbereichen sehr groß.
  • Velocity: Geschwindigkeit, mit der die Daten persistent gespeichert und verarbeitet werden (Batch oder in Echtzeit). Diese muss, v.a. wegen der Datenmenge, sehr hoch und auch mittels der Systemarchitektur gesichert sein.
  • Variety: Unterschiedlichkeit der Daten, oft beschrieben als unterschiedliche Grade von Strukturiertheit mit der Skala völlig unstrukturiert, semistrukturiert, stark strukturiert.

Solche Anwendungen sind (beim heutigen Stand der Technik) im Regelfall nur mit verteilten Systemen realisierbar. Diese müssen darüberhinaus leicht skalierbar sein, Parallelverarbeitung erlauben, Replikation von Daten erleichtern und eine hohe Ausfallsicherheit aufweisen.

Anforderungen

20.2.5 Skalierbarkeit

In diesen Anwendungsbereichen liegen nicht nur große Datenmengen vor, die meist auf verteilten Systemen betrieben werden müssen, sondern solche, deren Umfang sich auch kurzfristig verändern kann. Daran müssen die datenverwaltenden Systeme angepasst werden. Diese Fähigkeit wird Skalierbarkeitgenannt und nach horizontal und vertikal unterschieden.

Vertikale Skalierbarkeit meint den Ausbau der eigenen Hardware. Also z.B. durch Nutzung größerer Server. Um es mit [Kurowski 2012, Kapitel 1] zu sagen:

Vertikale Skalierbarkeit

"Vertikale Skalierung ist das Tuning einer abgeschlossenen Datenbankeinheit durch Hinzufügen von Rechenleistung oder Speicher, ....."

Und evtl. durch Umstellung auf eine InMemory-Lösung (vgl. Abschnitt 17.8), kann man ergänzen. Dies alles reicht derzeit (wer kann die Entwicklung der Hardware schon prognostizieren?) allerdings nicht aus für die in den BigData - Anwendungsbereichen anfallenden Daten, weshalb hier die horizontale Skalierbarkeit benötigt wird.

Horizontale Skalierbarkeit meint den Ausbau des Netzwerks, in dem die Daten verwaltet werden. Dies erfolgt durch das Hinzufügen weiterer abgeschlossener Datenbankeinheiten. Sie ist für die Bewältigung großer Datenmengen oft die bessere Alternative bzw., ab einer gewissen Datenmenge die einzige Möglichkeit (es muss immer wieder gesagt werden: beim derzeitigen Stand der Hardwaretechnologie). Das bedeutet, dass für größere Datenmengen oder höhere Performanceanforderungen einfach mehr Server genutzt werden und umgekehrt Server wegfallen, wenn die Anforderungen geringer werden.

Horizontale Skalierbarkeit

Nun bedarf die Skalierbarkeit nicht nur einer angemessenen Hardwarelösung, sprich Netzwerkstruktur, sondern auch eines datenverwaltenden Systems, mit dem die Skalierung realisiert werden kann (grundsätzlich, bzw. in vertretbarem zeitlichen Aufwand). Relationale Datenbanken leisten dies nur eingeschränkt. Edlich et al. fassen ihre diesbezüglichen Erkenntnisse wie folgt zusammen: Der Einsatz relationaler Datenbanksysteme führt zu ...

Geeignete datenverwaltende Systeme

"... nicht vertretbaren Antwortzeiten, insbesondere bei gleichzeitiger Replikation, die oft auch gewünscht ist. ... Sobald Tabellen und Indizes eine Datenmenge erreicht hatten, die eine Verteilung über mehr als eine Maschine erfordert, stellten die verantwortlichen Entwickler und Administratoren fest, dass sie für eine akzeptable Reaktionszeit nur mit Workarounds und Eingriffen in den Quellcode der verwendeten Datenbanksysteme Herr der Lage werden konnten" [Edlich, Friedland, Hampe u.a. 2011, S. 30].

Dies ist ohne Probleme nachvollziehbar. Für relationale Datenbanken gilt wegen der ausgeprägten internen Verknüpfungsstruktur (vgl. Kapitel 5 bis 13 in [Staud 2015]), die wiederum durch die Art der Daten begründet ist, die Notwendigkeit, Transaktionen nach den ACID-Prinzipien zu realisieren. Dies ist ein Kernprinzip der Architektur relationaler Datenbanksysteme. Nur so kann die Konsistenz dieser intensiv verknüpften Daten aufrechterhalten werden.

Es werden also andere datenverwaltende Systeme und im Übrigen auch "einfachere" Datenstrukturen benötigt. Da fügt es sich gut, dass ein "Großteil der Daten im Web 2.0 ohne Relationen" (gemeint sind die Beziehungen zwischen Tabellen bzw. Basiskomponenten) sind, so [Edlich, Friedland, Hampe u.a. 2011, S. 151].

Insgesamt also: Für relationale Datenbanken reicht es aus bzw. muss es (will man gute Reaktionszeiten) ausreichen, vertikal zu skalieren, indem eine leistungsfähigere Hardware angeschafft wird, bis hin zu InMemory-Lösungen (vgl. Abschnitt 17.8 für eine sehr kurze und Abschnitt 24.11 in [Staud 2015] für eine etwas ausführlichere Beschreibung). Mit dem Internet-Boom entstanden Datenmengen, die (in der derzeitigen Entwicklungsphase) nur durch verteilte Verarbeitung bewältigt werden können und die einer horizontalen Skalierbarkeit bedürfen.

20.2.6 Parallelisierung mit Hilfe des MapReduce-Frameworks

Zur horizontalen Skalierung und zur Lösung rechenintensiver Aufgaben gehört die Parallelverarbeitung. Nur wenn die jeweilige Aufgabe sich auf die Rechner im Netz verteilen lässt, kann sie in angemessener Zeit gelöst werden. Voraussetzung für BigData-Lösungen ist also ein Programmiermodell, das sich leicht parallellisieren lässt [Wartala 2014, S. 17]. Z.B. das MapReduce-Framework. Dies ist ein Programmiermodell für die Kopplung verteilter Dateisysteme, auch Cluster-Dateisystem genannt [Wartala 2012, S. 18]. Kerngedanke ist die Daten-Lokalität.

Aufgaben verteilen

"Die Verarbeitung großer Datenmengen auf einem verteilten System ist nur sinnvoll, wenn diese Daten den jeweiligen Verarbeitungsprozessen zur Verfügung stehen, sprich: Die Anwendungen müssen zu den Daten kommen, nicht die Daten zu den Anwendungen" [Wartala 2012, S. 17].

Es geht also, mit anderen Worten, um die nebenläufige Berechnung in Computerclustern, bei der Seiteneffekte wie Verklemmungen (deadlock) und Wettlaufsituationen (race conditions) vermieden werden.

Realisierung

Im Kern ist dies wie folgt realisiert. Eine Funktion map() (Map-Funktion) nimmt als Eingabeparameter eine Liste mit Key/Value-Paaren und eine Funktion für deren Verarbeitung entgegen und verarbeitet sukzessive alle Elemente der Liste. Sie gibt dann die durch die Funktion modifizierte Liste (wiederum Key/Value-Paare) zurück. Im Rahmen einer konkreten Verarbeitung entstehen mehrere solcher Listen. Diese werden mit Hilfe einer Funktion reduce() (Reducer-Funktion) zusammengeführt und weiterverarbeitet. Bezogen auf ein verteiltes Dateisystem auf vielen Rechnerknoten eines Clusters, stellt sich dies wie folgt dar: Auf jedem Rechnerknoten werden die Daten zur Verfügung gestellt, die genau der Map-Prozess auf diesem Rechner benötigt. Dann werden parallel die Ergebnislisten der Mapper-Funktionen eingesammelt und nach erfolgreicher Weiterverarbeitung (Reduzierung) wieder in das verteilte Dateisystem geschrieben.

Key/Value-Paare

Es geht also nur um die Verarbeitung von Key/Value-Paaren mit ihrer doch recht mageren Semantik. Dies ist gegenüber den Möglichkeiten von SQL deutlich vereinfacht. Die Semantik muss dann vom Anwendungsprogramm geliefert werden. Entwickelt wurde dieses Programmiermodell von Google-Entwicklern.

Weiter gehende Beschreibungen finden sich in [Wartala 2012, S. 17], [Edlich, Friedland, Hampe u.a. 2011, S. 17], [Fondermann, Spichale und George 2014, Kapitel 2] und [Schrempp 2012, Kapitel 2].

Hadoop ist ein auf Java basierendes Open Source Framework für die skalierbare und verteilte Verarbeitung großer Datenmengen auf vielen Rechnern innerhalb eines Netzwerks. Es implementiert den MapReduce-Algorithmus auf einem verteilten Dateisystem [Wartala 2012, S. 9]. Vorgeschlagen wurde es erstmals von Google [Wartala 2012, S. 21] für deren Dateisystem HDFS. Dies ist ein sog. verteiltes Dateisystem, kann also über Rechnergrenzen hinaus existieren. Vgl. für eine Beschreibung [Wartala 2012, S. 22ff].

Hadoop

Hadoop wird z.B. für HBase benötigt (Vgl. [Fondermann, Spichale und George 2014, Kapitel 1], [Wartala 2012]).

20.2.7 Konsistenz, CAP-Theorem

In der für BigData-Anwendungsbereiche notwendigen (Datenbank- und System-) Architektur können nicht die üblichen datenbanktechnischen Forderungen an Konsistenz und Transaktionssicherheit erfüllt werden (vgl. zu ACID-Transaktionen [Staud 2015, Abschnitt 19.9]). Von den gewünschten Eigenschaften (absolute) Konsistenz, (hohe) Verfügbarkeit und Ausfalltoleranz können, so zeigte es zuerst Eric Brower im so genannten CAP-Theorem, nur zwei realisiert werden.

Zuerst die drei Ziele:

(1) Konsistenz (C von Consistency) bezogen auf Transaktionen.

Dies bedeutet, dass die verteilte Datenbank nach Abschluss einer Transaktion einen konsistenten Zustand erreicht. Dabei geht es v.a. darum, dass bei einer Änderung der Daten in einem Knoten, alle folgenden Lesezugriffe - egal über welchen Knoten - den aktualisierten Wert liefern. Dies bedeutet, dass der aktualisierte Wert erst dann wieder gelesen werden kann, wenn alle replizierenden Knoten aktualisiert sind. Beispiel: Wenn in einem WebShop eine Bestellung getätigt und der Lagerbestand verändert wird, sollte die nächste Abfrage des Lagerbestandes erst erfolgen können, wenn alle Knoten den aktualisierten Wert aufweisen.

(2) Verfügbarkeit (A von Availability) eines Datenservice bezogen auf ein Netz.

Systeme müssen weiterarbeiten, auch wenn eines der Systeme nicht mehr antwortet. Dies beruht auf der Forderung nach einer akzeptablen Reaktionszeit. Bei Bestellvorgängen im E-Commerce sind schnelle Reaktionen nötig, sonst sinkt der Umsatz.

(3) Ausfalltoleranz (P von Partition Tolerance).

Der Ausfall eines Knotens oder einer Kommunikationsverbindung zwischen den Knoten einer verteilten Datenbank soll nicht zum Ausfall des gesamten Systems führen, sondern das System soll weiterhin auf Anfragen von außen reagieren können.

Nur zwei dieser Ziele können erreicht werden. Da die hohe Verfügbarkeit und die Ausfalltoleranz als absolut dominant angesehen werden, muss man die Anforderungen an die Konsistenz lockern. Somit muss das eigentliche Konsistenzmodell ACID durch ein anderes ersetzt werden, das BASE (Lauge) genannt wird. Mit ihm sind die Hauptanforderungen an horizontal skalierte Datenbanksysteme wie folgt formuliert:

Alternatives Konsistenzmodell BASE

  • BA von Basically Available: Das System ist erstmal grundsätzlich immer verfügbar.
  • S von Soft State: Der Zustand des Systems ist nicht immer gleich.
  • E von Eventually Consistent: Der Datenbestand ist nicht immer gleich wieder konsistent [Kurowski 2012]

Bezüglich der Konsistenz wird nur verlangt, dass "irgendwann" der konsistente Zustand wieder erreicht wird und nicht nach jeder Transaktion. Dieses Ziel kann auf unterschiedliche Art erreicht werden. Vgl. hierzu und zu den Wegen, wie dieses Ziel erreicht werden kann [Edlich, Friedland, Hampe u.a. 2011, S. 34].

20.2.8 Schemafreiheit

Schema meint hier die logische Struktur der Daten, wie sie aus einem Datenmodell abgeleitet wurde. Nun geht es natürlich nicht ohne ein Schema. Schon die Festlegung einer Key/Value-Struktur (die unabdingbar ist, will man Informationen erfassen) ist ein Schema. Werden dann zur Modellierung von Objekten Tupel gebildet, ist der Schema-Aspekt noch deutlicher.

Ohne Schema?

Die folgenden Ausführungen beziehen sich auf Dokumentendatenbanken (vgl. Abschnitt 20.2.11), weil hier dieses Thema die größte Bedeutung besitzt. Für die Zwecke dieses Kapitels genügt es, sich zu Beginn ein Dokument wie einen Datensatz vorzustellen (vgl. die Beispiele unten).

Drei Faktoren waren die Treiber für diese Entwicklung hin zur Schemafreiheit:

(1) Die Tatsache, dass Dokumente über irgendwelche Objekte sehr unterschiedlich sein können. Nehmen wir z.B. Personen. Der eine ist Programmierer, der andere arbeitet in der Hausverwaltung, beide gemeinsame Attribute, aber auch spezifische. Abgebildet auf die relationale Theorie liegt damit folgende Struktur vor: Alle Objekte haben bestimmte Attribute gemeinsam, andere sind nur für bestimmte Objekte gültig. In der relationalen Theorie wird dies durch Normalisierung, Zerlegung der Relationen und Einfügen von relationalen Verknüpfungen bewältigt. Dies ist aber in NoSQL-Anwendungen nicht gern gesehen (bzw. nicht möglich).

(2) Einzelne Dokumente sind verschachtelt. D.h. ein Key/Value-Paar kann auch wieder ein Objekt sein, eine Liste enthalten, usw.

(3) Änderungen des Schemas kommen, wegen der Dynamik dieser Anwendungsbereiche, oft vor. Diese sollten mit wenig Aufwand und schnell realisiert werden können. Z.B. wenn neue Attribute hinzukommen oder vorhandene wegfallen.

Eines der Mittel, die Schemafreiheit zu realisieren, ist Versionierung, d.h. Versionen von Werten (z.B. Attributsausprägungen) zu halten. Zum Beispiel kann die Anwendung von Anfang an erweiterte Daten nutzen (mit einem Feld mehr als aktuell benötigt), ein Hintergrundprozess konvertiert die Daten und schreibt sie als neue Version. Es gibt dann nur ein kleines Zeitfenster, in dem das Lesen der Daten die alte Version ohne das neue Feld zurückliefert, was in diesen Anwendungsbereichen als tolerierbar angesehen wird.

Versionierung

Insgesamt ist mit dem Begriff Schemafreiheit auch gemeint, dass das vorhandene Schema zur Laufzeit ohne großen Aufwand geändert werden kann und dass die einzelnen Dokumente einen unterschiedlichen Aufbau (eine unterschiedliche Attributzusammensetzung) haben können. Wolff et al. beschreiben dies am Beispiel von Cassandra wie folgt:

Schemafreiheit

Zur Laufzeit können weitere Spalten (gemeint sind Attribute, ...) hinzugefügt werden, "ohne dass das Cassandra-Schema explizit geändert werden muss. So könnte beispielsweise eine Entität Benutzer um zusätzliche Attribute zur Erfassung des Geburtsdatums und des Geburtsorts erweitert werden, ohne dass Attribute zuvor definiert werden" [Wolff et al. 2013, Kapitel 3].

Wolff et al. weisen aber auch darauf hin (wiederum am Beispiel Cassandra), dass es den Prozess des Schemadesigns doch gibt:

Cassandra

"Der Keyspace sowie die notwendigen Spaltenfamilien mit all ihren Parametern sollten vorab definiert werden. Columns mit einem Sekundärindex müssen zwingend definiert werden."

Columns=
Spalten=
Attribute

Sie weisen dann darauf hin, dass hier, wie bei Relationalen Datenbanksystemen, das Schema auch noch nachträglich geändert werden kann und dass deshalb die Bezeichnung "dynamisches Schema" geeigneter wäre [Wolff et al. 2013, Kapitel 3].

Hier einige Beispiele für konkrete Umsetzungen und deren Konsequenzen. Wolff et al. beschreiben den Modellierungsaspekt mit "BigTable und damit HBase" wie folgt: Das logische Datenmodell ähnelt dem relationalen (mit Tabellen, Zeilen und Spalten). Es gibt aber keine referentielle Integrität, keine Transaktionen und beliebige Indexe und kein SQL. Der Zugriff erfolgt mit einer einfachen API mit nur vier Befehlen (Put, Get, Scan und Delete). Zeilen (Tupel) haben einen eindeutigen Schlüssel (row key) mit dem die Anwender auf die eigentlichen Spalten zugreifen können, die ebenfalls einen Schlüssel haben (column key). Als Folge der notwendigen oben beschriebenen eingeschränkten Konsistenz muss versioniert werden. Dies geschieht auf unterschiedliche Weise. Bei HBase werden die Werte in den Zeilen versioniert und - so die systemweite Vorgabe - drei Versionen der Werte aufgehoben. Auch ein Zeitstempel ist für die Daten möglich, dann kann man auch auf historische Werte zugreifen [Wolff et al. 2013, Kapitel 4].

BigTable, HBase

Trelle beschreibt die Situation für MongoDB. An sich, führt er aus, gilt MongoDB als schemafrei, trotzdem nimmt das Schemadesign einen hohen Stellenwert ein. Er sieht die Schemafreiheit als einen "rein technischen Aspekt", der für performante Anwendungen und zur Beherrschung der fehlenden dokumentenübergreifenden Transaktionen durch Überlegungen zur Strukturierung der Datenablage ergänzt werden muss. [Trelle 2014, S. 177f]

MongoDB

Auch Wolff et al. weisen auf die Schemaflexibilität von MongoDB hin:

"Es gibt keinen Mechanismus, der Dokumenten innerhalb einer Collection eine bestimmte Struktur oder Datentypen für bestimmte Felder aufzwingt ..... Ob es fachlich Sinn macht, völlig unterschiedliche Dokumentarten in einer Collection zu verwalten, beurteilen Sie besser selbst." [Wolff, Nitschinger und Trelle 2014]

Abschließend hierzu noch ein Beispiel aus [Trelle 2014, S. 17], ein Produktkatalog mit unterschiedlichen Produkttypen innerhalb einer Collection:

> db.produkte.insert({

typ: "dvd",

titel: "Lost Higway",

regie: "DavidLynch"

})

> db.produkte.insert({

typ: "cd",

titel: "Highway to hell",

band: "AC/DC"

})

Die zwei Befehle fügen jeweils ein Dokument (einen Datensatz) ein, allerdings mit jeweils einem unterschiedlichen Attribut.

In der Sprache der relationalen Theorie kann die flexible Schemabildung in diesem Bereich der NoSQL-Welt (Dokumente) wie folgt zusammengefasst werden:

  • Die Schemabildung besteht darin, Objekte zu identifizieren und ihnen Eigenschaften (Attribute, Key/Values, ...) zuzuordnen.
  • Die Objekte werden in Collections gruppiert.
  • Key/Value-Paare können verschachtelt sein und Informationen aller Art enthalten.
  • Dokumente bestimmter Objekte können unterschiedliche Key/Value-Paare aufweisen.
  • Neue Attribute können bei einem "neuen Dokument" einfach hinzugefügt und überflüssig gewordene einfach gelöscht werden.
  • Theoretisch könnten auch Dokumente abgespeichert werden, deren Schnittmenge gemeinsamer Attribute nur sehr gering ist. Dass dies nicht sinnvoll ist, wird auch im obigen Zitat von Wolff et al. deutlich.
  • Es gibt keine Verknüpfung zwischen unterschiedlichen Objekttypen, nur einfache Verweise sind bei einigen Systemen möglich.
  • Es gibt keine Transaktionen über die Grenzen von Collections.
  • Feldnamen müssen bei jedem Dokument mit abgespeichert werden [Trelle 2014, S. 33].

Dies sollte das Ausmaß an Flexibilität aufzeigen wie auch ihre Konsequenzen andeuten. Zu den Konsequenzen gehört der Verzicht auf die Ausmodellierung von Zusammenhängen zwischen den Daten. Schrempp beschreibt dies wie folgt:

"Aufgrund des einfachen Datenmodells dieser Technologien wird bei NoSQL meistens ein Ansatz verwendet, bei dem die Daten so vorliegen, dass alle relevanten im Datensatz selber vorhanden sind und keine Navigation zu anderen Datensätzen nötig ist. Beispielsweise können mit einem Kunden auch gleich seine Bestellungen gespeichert werden" [Schrempp 2012, Pos. 216].

In den folgenden Kapiteln wird nun zuerst das Key/Value – Konzept vorgestellt und mit dem Atribut-Konzept verglichen, anschließend werden die wichtigsten Datenbank(system)typen aus diesem Bereich kurz vorgestellt.

20.2.9 Key/Value vs. Attribut

Vorbemerkung für Leser, die keinen Kontakt mit der Datenbanktheorie hatten:

Oben war schon mehrfach von Anwendungsbereichen die Rede. Hier – im Datenbankkontext – wird der Begriff auch verwendet. Er beschreibt hier den Teil der Welt über den eine Datenbank errichtet werden soll. Also z.B. die Finanzbuchhaltung des Unternehmens, die Geschäftstätigkeit eines Internet-Unternehmens oder ein Unternehmen als Ganzes. Bei letzterem entstehen unternehmensweite Datenbanken, z.B. als Grundlage einer ERP-Software.

In dem jeweiligen Anwendungsbereich werden dann (typischerweise) Objekte und Beziehungen (zusammengefasst: Informationsträger) zwischen diesen identifiziert und durch (für die Datenbank wichtige) Eigenschaften beschrieben. Zur Erfassung dieser Eigenschaften dienen Key/Values bzw. Attribute. Vgl. für eine vertiefte Beschreibung des Attributkonzepts [Staud 2015].

Ganz am Anfang des Datenbankdesigns und der Datenmodellierung muss geklärt werden, wie die Eigenschaften von Objekten und Beziehungen (Informationsträgern) erfasst werden, denn diese sind Grundlage jeglicher Datenbank. Bis vor einiger Zeit wurde dies über das Attributkonzept realisiert, weshalb so gut wie alle Datenbanken attributbasiert waren. D.h., alle Datenbanken (v.a. relationale) hatten Attribute zur Beschreibung der Informationsträger des jeweiligen Anwendungsbereichs.

„SQL-Datenbanken“

Dies änderte sich mit den NoSQL-Datenbanken. Hier gewann ein Konzept Bedeutung, das mit Key/Value beschrieben wird. Wegen dessen großer Bedeutung und v.a. wegen der Konsequenzen dieser Abwendung vom Attributbegriff werden hier die beiden Konzepte vergleichend dargestellt.

Das Attributkonzept

Für eine vertiefte Betrachtung vgl. [Staud 2015], insbesondere Kapitel 2.

Betrachten wir die folgende Abbildung. Ein Attribut erfasst das, was umgangssprachlich als Eigenschaft aufgefasst wird. Im Datenbankumfeld sind dies Eigenschaften von Objekten und Beziehungen. Vgl. Pos. [3] in der Abbildung. Dies können Namen, Semesterzahl oder ein BMI (Body Mass Index) sein.

Pos. [3]

Zu den Eigenschaften gehören die Objekte und Beziehungen, auf die sich die Attribute beziehen. Vgl. Pos. [2]. Dies können z.B. Angestellte (für die Eigenschaft Namen), Studierende (für die Eigenschaft Semesterzahl) oder „Sportlich aktive“ sein (für die Eigenschaft BMI).

Pos. [2]

Diese Objekte und Beziehungen gehören wiederum zu einem bestimmten Anwendungsbereich. Vgl. Pos. [1]. Im Beispiel der Abbildung Unternehmen (für die Angestellten), Hochschulen (für die Studierenden) und Fitnessclub (für die sportlich aktiven).

Pos. [1]

Darauf baut das Attributkonzept auf. Die Sachverhalte sind lediglich etwas formaler gefasst. In Position [4] ist dies angedeutet.

Pos. [4]

Zu jedem Attribut gehört der Anwendungsbereich, für den das Attribut eingerichtet wurde. Er stellt sozusagen das weitere Umfeld dar und kann evtl. in der Datenbankbezeichnung aufschimmern. Hier entsprechend dem Obigen Unternehmen, Hochschule, Fitnessclub.

(a)

Jedes Attribut bezieht sich auf bestimmte Informationsträger (Relationen in relationalen Datenbanken; Entitätstypen in der semantischen Modellierung; Objekte in objektorientierten Datenbanken). Hier zum Beispiel die Angestellen eines Unternehmens, die Studierenden einer Hochschule oder Menschen in einem Fitnessclub.

(b)

Jedes Attribut hat eine Bezeichnung, hier Name, Semesterzahl und BMI (Body Mass Index). Diese wird Attributsbezeichnung genannt.

(c)

Schlussendlich kann jedes Attribut bestimmte Werte annehmen. Diese werden als Attributsausprägungen bezeichnet. Hier wurden beispielhaft Widmer und Maier für das Attribut Name; 2, 7, 6 für die Semesteranzahl und 22.5 bzw. 29.2 als Wert des BMI angegeben.

(d)

Für die konkrete Nutzung in einer relationalen Datenbank wird jedes Attribut in der zugehörigen Relation angelegt und mit einem Datentyp sowie einer Eingrenzung der Attributsausprägungen und evtl. semantischen Integritätsbedingungen versehen. Eine vertieftere Darstellung hierzu, auch mit Berücksichtigung von Beziehugnen, findet sich in [Staud 2015], Kapitel 18 und 20.


Abbildung 20.2-1: Das Attributkonzept

Soweit – in aller Kürze – das Attributkonzept. Werfen wir nun einen Blick auf das Key/Value-Konzept.

Key/Value-Konzept

Das Key/Value – Konzept dient auch, wie das Attributkonzept, zur Erfassung von Eigenschaften zum Zwecke der Datenverwaltung. Dabei meint Value den Wert, den die Eigenschaft im konkreten Fall annnimmt und Key eine identifizierende Information für diesen Wert, also einen Schlüssel.

Die folgende Abbildung zeigt einige Beispiele. Im Beispiel (1) geht‘s um die Nachnamen der Angestellten eines Unternehmens. Den Personalnummern als Key sind die Nachnamen als Values zugeordnet.

Keine Meta-Informationen in den Daten

Beispiel (2) gibt für die Studierenden einer Hochschule die Anzahl der bereits abgeleisteten Semester an. Als Key dient hier die Matrikelnummer, als Value die Semesterzahl.

Beispiel (3) gibt die Bezeichnungen von Abteilungen an. Jeweils einer eindeutigen Abteilungsnummer (Key) ist die Abteilungsbezeichnung (Value) zugeordnet.

Beispiel (4) gibt für jede Abteilungsbezeichnung die Zahl der Mitarbeiter an. Hier dient also die Abteilungsbezeichnung als Key.

Dies sind auch schon alle Informationen, die im datenverwaltenden System vorliegen. Die in der Abbildung angegebenen Hinweise auf den jeweiligen Anwendungsbereich, die Informationsträger und die Bezeichnung der Eigenschaft sind in den Daten des datenverwaltenden Systems nicht vorhanden. Sie müssen entweder im Anwendungsprogramm oder in eigenen Datenbeständen verwaltet werden.

Datenverwaltende Systeme dieses Typs verwalten also Daten, die lediglich aus einem Schlüssel und einem Wert bestehen, wobei der Begriff "Schlüssel" sich auf die jeweilige Eigenschaft bezieht, nicht auf die gesamte beschreibende Information eines Objekts (vgl. die Anmerkung zu diesem Key-Begriff unten).

Der Wert einer solchen Key/Value-Kombination, diese wird hier auch Datensatz genannt wie die objektbeschreibenden Gegenstücke mit mehreren Attributen der physischen Datenorganisation, ist in der Regel ein Byte-Array.

Kurowski vergleicht diese Struktur mit den assoziativen Feldern (arrays) in PHP und schreibt:

"Flüchtig betrachtet ist ein Key Value Store erst einmal nichts weiter als ein assoziatives Array, bei dem der Key der Index des Arrayeintrags ist. Daher kann man sagen, dass auch die PHP-eigenen assoziativen Arrays durchaus als Key Value Store funktionieren:

 

$autohaus["id:1"]='Meier"

$autohaus["id:2"]=array("name":"Müller", "stadt":"Berlin")

echo "Autohaus 1: ".$autohaus["id:1"] -> Meier

echo "Autohaus 2 ist in ".$autohaus["id:2"]["stadt"] -> Berlin

 

Genau diesen Ansatz verfolgen alle Key Value Stores. Daten werden gespeichert und anhand des Keys wieder abgerufen." [Kurowski 2012, Kapitel 4 (E-Book)]

Was sind assoziative Felder (arrays) in PHP?

Bei "normalen" Feldern (arrays) werden die einzelnen Einträge über eine automatisch vergebene laufende Nummer angesprochen. So führt $gew = array(87.5, 88.3, 90.1, 89.6, 87.4) zu einem Feld (z.B. mit den Ergebnissen der morgendlichen Gewichtsmessung), dessen Elemente automatisch durchnummeriert sind, beginnend bei 0.

Assoziative Felder dagegen enthalten eine eindeutige Schlüsselbezeichnung ("key"), durch die die Elemente angesprochen werden. Beispiel:

$gew = array("Montag"=>87.5, "Dienstag"=>88.3, "Mittwoch"=>90.1, "Donnerstag"=>89.6, "Freitag"=>87.4).

Key und Value: Die Funktion array() macht $gew zu einem Feld mit Einträgen, die aus drei Elementen bestehen. Dem Schlüssel (Key), dem zugehörigen Wert (Value) und dem Operator "=>". Zu der Frage, ob dieser Key im datentechnischen Sinn wirklich ein Schlüssel ist, vgl. unten.

Datentechnisch (im klassischen Sinn) liegen damit Attributsbezeichnungen und Attributsausprägungen vor und damit - im Hintergrund - Realweltphänomene (Objekte, Beziehungen, ...), die beschrieben werden.

 


Abbildung 20.2-2: Das Key/Value-Konzept

20.2.10 Key/Value – Datenbanken

Obige Key/Value – Werte werden dann in datenverwaltenden Systemen gespeichert, verarbeitet und abgerufen. Speichern und Abrufen sind dann auch die Hauptfunktionen dieser Systeme. Viel mehr ist da auch nicht, hier wird programmiert.

Hauptfunktionen

In Redis werden die Einträge mit SET getätigt und die Daten mit GET abgerufen [Kurowski 2012, Kapitel 4]:

>SET meinAuto Skoda Superb -> "OK"

>GET meinAuto -> Skoda Superb

Die Bezeichnung "meinAuto" ist der Key (eigentlich: Attributsbezeichnung) und "Skoda Superb" der Wert, d.h. die Attributsausprägung.

Die Datentypen können bei einem solchen System, das doch recht einfache Datenstrukturen anbietet, durchaus vielfältig sein. Redis z.B. kennt integer, string, hash, list und (sorted) set [Kurowski 2012, Kapitel 4]. Eine besondere Rolle spielt bei diesem System der Datentyp Hash. Die Daten werden anhand eines Keys in einer "Hashtable" [Kurowski 2012, Kapitel 4] verwaltet.

Datentypen

Schlüssel, Zugriffe, Verarbeitung

Unter einem Schlüssel im obigen Sinn kann also nur genau ein Wert (eine Attributsausprägung, ...) abgelegt werden. Dieser kann jede Art von Zeichen enthalten. Mehr zum möglichen Aufbau dieser Schlüssel findet sich in [Kurowski 2012, Kapitel 4]. Auch die Abfrage kann nur über diesen Schlüssel erfolgen, was die Situation für Auswertungen natürlich erschwert. Da verwundert es nicht, wenn einzelne Systeme weitere Zugriffsmöglichkeiten anbieten. Wolff et al. beschreiben für Riak, dass es neben der Abfrage nach Schlüsseln auch sekundäre Indizes gibt. Das ermöglicht den Zugriff nicht nur über den Schlüssel, sondern über andere Attribute [Wolff, Nitschinger und Trelle 2014, Pos. 396].

Weitere Zugriffsmöglichkeiten

Der Einbau semantisch begründeter Beziehungen, wie bei relationalen Datenbanken, findet hier nicht statt. Es gibt also keine relationalen Verknüpfungen [Edlich, Friedland, Hampe u.a. 2011, S. 151] [Trelle 2014, S. 3].

Eine wie auch immer geartete Verarbeitung der Daten ist direkt nicht vorgesehen. Sie wird mit MapReduce (vgl. Abschnitt 20.2.6) realisiert, das für solche dann typischerweise im Netz verteilten Daten konzipiert wurde [Wartala 2012, S. 17].

Einfache Datenstruktur

Diese Datenstruktur ist recht einfach. Die Schemabildung (Modellierung) und die logische Datenstruktur fällt auf das Elementarste zurück: Ohne die Zuweisung einer identifizierenden Information zu einer beschreibenden (Attributsbezeichnung Personalnummer zur Nummer selbst) geht es einfach nicht.

Allerdings können oftmals die Schlüssel in Namensräume und Datenbanken aufgeteilt werden, so dass die Daten wenigstens ein Stück weit gruppiert werden.

Eine solche Datenstruktur bedeutet, dass die Struktur und Semantik des Anwendungsbereichs in den Daten so gut wie nicht repräsentiert ist. Lediglich der elementare Zusammenhang zwischen beschreibender und identifizierender Information liegt vor und - sozusagen im Hintergrund - der Bezug auf bestimmte Informationsträger des Anwendungsbereichs. Der ganze Rest muss von der Anwendungssoftware geleistet werden. Dies ist eine ganz andere Vorgehensweise als in der semantischen, relationalen oder objektorientierten Modellierung.

Weitgehend semantikfrei

Vorteile

Ein großer Vorteil dieser Art der Datenspeicherung ist, dass verteilte Datenhaltung und Skalierbarkeit leicht zu realisieren sind [Wolff, Nitschinger und Trelle 2014]. Von daher ist auch der Druck in Richtung Verzicht auf Verknüpfungen zu verstehen. Verknüpfungen über Server hinweg würden die Skalierbarkeit erschweren. Insgesamt können als Motiv für eine solche Verwaltung von Daten die riesigen Datenmengen des Internet und die Notwendigkeit der schnellen Reaktionszeit gesehen werden.

Motive

Für eine vertiefte Betrachtung der verschiedenen Ausprägungen dieses Systemtyps vgl. [Wolff et al. 2013].

Beispiele

Edlich et al. nennen folgende Beispiele: Redis, Chordless, Riak, Membase, Voldemort, Azure Table Store, Tokyo Cabinet, BerkeleyDB, Scalaris, GT.M [Edlich, Friedland, Hampe u.a. 2011, S. 151].

20.2.11 Graphendatenbanken

Die Begriffe Graph und Netzwerk bedeuten eine vernetzte Struktur. In einer solchen gibt es Knoten und Beziehungen zwischen diesen. Bei Netzwerken können diese Beziehungen mit Werten versehen sein. Vgl. für eine Einführung in die Graphentheorie [Kastens und Kleine Büning 2008, Kapitel 5], [Gumm und Sommer 2011, Abschnitt 4.9].

Bei Graphendatenbanken liegen ebenfalls Knoten und Beziehungen vor, die hier aber beide Eigenschaften haben können und zwar als Key/Value-Paare. Das wirklich hervorstechende Merkmal von Graphendatenbanken ist, dass sie ein effizientes "Durchqueren" des Graphen/Netzwerks entlang der Beziehungen erlauben [Perkins, Redmond und Wilson 2018, 286-289]

Man stelle sich als Knoten eine Präsentation im SocialWeb vor und als Verbindung eine Beziehung, die "mag ich" ausdrückt. Oder, mit Bezug auf die Weltwirtschaft, die einzelnen Nationalstaaten als Knoten und die Ein- und Ausfuhren zwischen diesen als Beziehungen. Das ist eigentlich ein altes Thema. Der Verfasser dieses Textes hat bereits 1983 soziometrische Netzwerke und v.a. Welthandelsnetzwerke untersucht und Programme für deren Erfassung, Verarbeitung und graphische Darstellung geschrieben [Staud 1983]. Das Thema hat aber durch die weltweite Vernetzung und die Internet- bzw. SocialMedia- Aktivitäten inzwischen eine sehr viel größere Bedeutung gewonnen.

Beispiele

Graphen und Netzwerke sind in den Relationen der relationalen Theorie nur schwer abbildbar, v.a., wenn die Zeiten für Zugriff und Auswertung kurz sein müssen und der Datenbestand groß ist. Deshalb bedarf es eigener Lösungen, abseits der klassischen Datenbanktechnologie. Während der Verfasser 1983 noch die Lösung selbst programmieren musste und v.a. mit dem Problem zu kämpfen hatte, Netzwerke zwischen 100 Nationalökonomien mit der damaligen Hardware zu verwalten, gibt es heute entsprechende datenverwaltende Systeme, die Beziehungsgeflechte mit Millionen Verknüpfungen verwalten können. Die dabei entstehenden Datenbestände werden in der einschlägigen Literatur Graphendatenbanken genannt. Die aktuelle Situation beschreiben Wolff et al. wie folgt:

Netzwerke

"Graphendatenbanken sind vor allem auf die effiziente Speicherung von komplexen, vernetzten Domänen ausgerichtet. In den Graphen sind die Entitäten als Knoten durch getypte Kanten miteinander verbunden. Beide können beliebige Attribute enthalten." [Wolff, Nitschinger und Trelle 2014]

Anmerkung: Entität steht für Informationsträger, Domäne für Anwendungsbereich (vom. engl. domain).

Datenmodell, Schema

Die Modellvorstellung ist also die eines Graphen (gerichtet oder ungerichtet) oder auch Netzwerks (vgl. für Beispiele hierzu [Staud 1983]) und dessen Repräsentation in der sog. Adjazenzmatrix (Nachbarschaftsmatrix), der Matrix mit den Beziehungswerten.

Anwendungsbereiche

Anwendungsbereiche sind neben den schon erwähnten sozialen Netzen auch sonstige Empfehlungssysteme, die Bild- und Textanalyse, die Wissensrepräsentation, das Semantic Web, Linked Open Data bis zu Geoinformationssystemen, einfach alle Anwendungsbereiche, bei denen die zu verwaltende Information nicht nur aus einzelnen Datensätzen besteht, sondern bei denen auch verknüpfende Information vorliegt und erfasst wird, bzw. im Mittelpunkt steht. Bei all diesen Anwendungen besteht die gesuchte Information nicht mehr länger nur aus einzelnen, zur Suchanfrage passenden Datensätzen, sondern aus Informationen über die Art und Weise der Verknüpfungen dieser Datensätze untereinander" (vgl. auch [Edlich, Friedland, Hampe u.a. 2011, S. 217]).

Beispiele

Beispiele sind Neo4j und SonesDB. Neo4j ist beschrieben in [Wolff et al. 2013, Kapitel 2].

20.2.12 Dokumentendatenbanken

Was ist ein Dokument?

Das Grundkonzept des Schemas (Datenmodells) sind hier sog. Dokumente. Stellen wir uns für den Anfang ein solches als einen einzelnen Datensatz im Sinne der relationalen Datenbanken vor. Die einzelnen Felder enthalten meist die Ausprägungen von Attributen (hier Werte genannt), wie gewohnt. Einzelne können aber auch Texte enthalten oder andere Informationsarten wie Arrays und eingebettete Dokumente (so bei MongoDB). Außerdem können unterschiedliche Informationsträger eine unterschiedliche Felder-Zusammensetzung haben. Die Sicht der Informatik ist wie folgt:

Für zahlreiche Beispiele vgl. [Staud 1991, Kapitel 7]. Damals nannte man sie Faktendatenbanken.

Ein Dokument kann als eine geordnete Liste von Key/Value-Paaren gesehen werden (zu Key/Value-Paaren vgl. Abschnitt 20.2.9).

Es werden hier also nicht nur einzelne Key/Value-Paare verwaltet, wie bei (den meisten) Key/Value-Datenbanken, sondern semantisch begründete Zusammenstellungen, die dem entsprechen, was man ansonsten Tupel (und dann später Datensatz) nennt.

Bezugspunkt für Objekte

Dokumente beziehen sich auf bestimmte Informationsträger, die sie beschreiben. Dies können Unternehmen, Personen, Geschäftspartner, usw. sein, einfach alles, was identifiziert (hier durch ein Attribut mit der Endung "id" gekennzeichnet) und durch weitere Attribute ("key/values") beschrieben wird.

Bei CouchDB (einem wichtigen Vertreter dieses Systemtyps) werden die Datendokumente im JSON-Format (vgl. unten) gespeichert. Auch alle Arten binärer Daten (Bilder, PDF-Dateien, HTML-Dateien, CSS-Dateien, MP3-Dateien) sowie virtuelle Dokumente (entsprechend den Views der relationalen Datenbanken) können mit den Dokumenten abgelegt werden [Gull 2011, S. 73f]. In CouchDB erfolgt die Zuordnung über ein Attribut _attachements.

Im Unterschied zu Datensätzen (einer Datei, bzw. Tupeln einer Relation), die ja alle denselben Aufbau haben, können Dokumente strukturell verschieden sein (wie bei den Key/Value-Datenbanken schon vorgestellt). Dies wird hier als Vorteil gesehen. Angenommen, die Dokumente beschreiben Unternehmen (für eine Wirtschaftsdatenbank). Dann ist die Gesamtzahl der Key/Value - Paare evtl. 200, verschiedene Unternehmen können aber unterschiedlich viele haben. Werden z.B. auch Tochtergesellschaften durch 10 Key/Value - Paare beschrieben, dann haben Unternehmen ohne solche auch keine entsprechenden Felder/Feldeinträge.

Strukturell unterschiedlich

Dies ist tatsächlich ein altes Problem, es wurde auch immer gelöst, vgl. die Faktendatenbanken früherer Zeiten, heute wird es von der NoSQL-Bewegung thematisiert. Denn natürlich haben die großen Internetanbieter - v.a. die aus dem Social Web - eine Unmenge solcher Daten gespeichert ("Profile", uw.) und wollen sie verarbeiten. Beispiele für Dokumente dieses Typs finden sich in [Trelle 2014, S. 13].

Etwas genauer lassen sich die Unterschiede zwischen Dokumenten (in der NoSQL-Fassung) und Tupeln (Datensätzen) der relationalen Theorie so beschreiben:

Unterschiede

(1) Unterschiedliche Anzahl von Key/Value-Paaren bei den Dokumenten.

Dem entspricht bei relationalen Datenbanken eine unterschiedliche Attributzusammensetzung der Tupel (Datensätze). In der relationalen Theorie wird dies durch eine Generalisierung / Spezialisierung beseitigt und es entstehen mehrere verknüpfte Relationen (vgl. [Staud 2015, Abschnitt 14.1]). Zusammen bleiben da nur die Datensätze, die genau denselben Aufbau haben.

Dieser Verzicht auf einen einheitlichen Aufbau der Dokumente führt dazu, dass die Feldbezeichnungen ("Keys") bei jedem Dokument/bei jedem Feld (Key) mitgeführt werden müssen.

Zur Erinnerung: In den sequenziellen Dateien (vgl. [Staud 2015, Abschnitt 21.3]), die den Relationen zugrunde liegen, wird die Bezeichnung der Felder (der Attribute) nur am Dateianfang angegeben, danach ist sie nicht mehr nötig.

(2) Eingebettete Dokumente

Darunter wird verstanden, dass in einem Wert (ein Wert in einem Key/Value-Paar) ein ganzes Dokument erfasst wird. Z.B. also bei obigen Dokumenten zu einem Unternehmen eine ganze Unternehmens­beschrei­bung für den "Key" (das Feld) Tochtergesellschaft. Dies würde in einem relationalen Datenmodell zu einer eigenen Relation führen, die beiden Relationen wären durch Schlüssel/Fremdschlüssel verknüpft.

(3) Weitere Informationsarten in den Werten (Key/Values)

Also z.B. die Rede des Vorstandsvorsitzenden von der letzten Hauptversammlung als BLOB (Binary Lage Object). Diese würden in relationalen Datenbanken zu eigenen Relationen führen und über Attribute mit der Ausgangsrelation verknüpft werden.

Bei all diesen Punkten verzichtet die NoSQL-Lösung auf Komplexität (z.B. auf Verknüpfungen). Dies vereinfacht das Datenmodell und den Datenbestand. Er kann dann z.B. leichter (auch horizontal) skaliert werden.

JSON

Wie oben schon ausgeführt, sind Dokumente hier als JSON-Datenstrukturen realisiert. JSON bedeutet JavaScript Object Notation. Es ist ein leichtgewichtiges Datenaustauschformat (www.json.org), leicht les- und schreibbar für Menschen wie Programme (ebenda), das auf einer Untermenge der JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999 beruht. Betont wird sein von formalen Sprachen unabhängiges Textformat, seine Syntax ist bei der "C-Programmiersprachen-Familie" angesiedelt. Basiselement sind Key/Value - Paare, wie oben vorgestellt.

Quelle:
www.json.org

Grundlage von JSON sind zwei Strukturen:

  • Eine Sammlung von Key/Value - Paaren (Eigenschaften). Dies entspricht dem, was in anderen formalen Sprachen object, record, struct, dictionary, hash table, keyed list, oder associative array genannt wird.
  • Eine geordnete Liste von Werten. Dies entspricht den Konzepten array, vector, list oder sequence anderer formaler Sprachen.

Dies sind, da hat die Quelle tatsächlich recht, universelle Datenstrukturen. Auch die Datensätze der üblichen Dateitechniken lassen sich da unterbringen. Es geht also zum einen um die elementare Zusammenstellung identifizierender und beschreibender Information, zum anderen um die Zusammenstellung solcher Informationen zur Beschreibung von ganzen Realweltphänomenen (Objekten, Beziehungen, usw.). Die konkrete Ausgestaltung in JSON ist wie folgt:

Universelle Datenstrukturen

  • Objekte ("Realweltphänomene") werden als ungeordnete Menge von Key/Value-Paaren gesehen. Eine Objektbeschreibung beginnt und endet mit einer geschweiften Klammer. Nach der Objektbezeichnung folgt ein Doppelpunkt, danach die Key/Value-Paare, jeweils durch ein Komma getrennt.
  • Ein array ist eine sortierte Sammlung von Werten. Er beginnt und endet mit einer eckigen Klammer. Die Werte sind durch Kommata getrennt.
  • Datentypen sind der Nullwert (null), Boolean (true, false), Ziffern, Zeichenketten (in Anführungszeichen), die oben angeführten arrays und Objekte.
  • Eine Zeichenkette ist eine Folge von Unicode-Zeichen, die in doppelten Anführungszeichen stehen.
  • Ein Buchstabe wird als single character string repräsentiert

Hier ein Beispiel aus [Gull 2012, S. 299], wo sich zahlreiche weitere Beispiele finden. Die Objekte dieses Beispiels sind Städte und ihre Verkehrsinfrastruktur:

Vgl. zu folgendem auch die Syntaxdiagramme in der Quelle

{

"_id": "city_münchen",

"_rev": "2-54a357f5e0172cb2c35b4b2ea88fa366",

"country": "Deutschland",

"cityName": "München",

"subName": "U-Bahn",

"memos": "Wurde zur Olympiade in den 1970ern eröffnet.",

"type": "city",

"created_at": "2011-05-08T17:11:09.007Z"

}

Das binäre Format von JSON wird BSON (Binary JSON) genannt.

Ist ein "Key" ein Schlüssel?

Jetzt wird es Zeit, den Begriff key in key/value zu hinterfragen. Bezogen auf ein Objekt (mit einer identifizierenden und üblicherweise mehreren beschreibenden Informationen) ist er nicht sinnvoll, da außer dem Schlüssel (der id) meist kein weiteres identifizierendes Attribut vorhanden ist. Besser wäre, wie es in einigen wenigen Quellen auch getan wird, von name/value pairs zu sprechen, denn es geht ja nur um die Bezeichnung der Eigenschaft (Bezeichnung des Attributs). Da sich aber in der einschlägigen Literatur der Begriff key/value durchgesetzt hat, soll er auch hier verwendet werden.

Betrachtet man, wie bei den Key/Value-Datenbanken, die einzelnen Eigenschaften isoliert (was ja eigentlich nicht sinnvoll ist, denn eine Objektbeschreibung benötigt mindestens zwei Key/Values), erscheinen die Attributbezeichnungen als Schlüssel. Im obigen Beispiel: country für sich betrachtet ist identifizierend - für Staaten - nicht für Städte und ihre Verkehrseinrichtungen.

Schlüssel, Id

Jedes Dokument hat (auch hier) einen eindeutigen Schlüssel, in MongoDB gibt es dafür einen Datentyp ObjectId [Trelle 2014, S. 7]. Er wird im Feld _id verwaltet. Schlüssel müssen hier natürlich ausgefeilter sein als in relationalen Datenbanken. Zum Beispiel besteht bei MongoDB die ObjectId aus 12 Bytes mit folgender Bedeutung: Zeitstempel mit 4 Bytes, Maschine mit 3 Bytes, PID mit zwei Bytes, Zähler mit 3 Bytes. Der Zeitstempel gibt die Sekunden seit dem 1.1.1970 an [Trelle 2014, S. 36].

Erläuterung:

Maschine: Computer, auf dem die ID erzeugt wurde. Hashwert des Hostnamens.

PID: Identifikation des laufenden Prozesses.

Zähler: einfacher Zähler, der inkrementiert wird. "Damit können von einem Prozess ... 16 MB ... Dokumente pro Sekunde eingefügt werden, bevor es zu Kollissionen kommt." [Trelle 2014, S. 36]

Auf dem Primärschlüssel liegt ein Index [Trelle 2014, S. 37], so dass Suchvorgänge wesentlich beschleunigt werden.

Indexierung

Versionierung

Das Ändern von Daten läuft hier wie folgt ab (am Beispiel CouchDB): Ist ein Feld zu ändern, wird das gesamte Dokument geladen und verändert. Dann wird das gesamte Dokument als neue Version abgespeichert [Gull 2011, S. 72]. Deshalb erhalten Dokumente eine Revisions-ID, die bei jedem Update verändert wird, so dass ein gezieltes Auffinden der Änderungen ermöglicht wird.

Ändern von Daten

Die Kennzeichnung der Versionen ist (bei CouchDB) wie folgt: Am Anfang steht eine fortlaufende Nummer, woraus erkennbar ist, wie oft das Dokument gespeichert wurde. Es folgt ein Bindestrich und nach diesem ein von CoachDB berechneter MD5-Hashwert [Gull 2011, S. 73]. MD5 bedeutet Message-Digest Algorithm 5. Dieser Hashwert ist eine Prüfsumme mit der Länge 128 Bit, die aus einer beliebigen Zeichenfolge erzeugt werden kann [Gull 2011, S. 339].

Kennzeichnen von Versionen

Mehrfachzugriffe bewältigen

Das klassische Vorgehen bei Mehrfachzugriffen ist, dass ein Datensatz gesperrt ist, solange der Zugriff erfolgt. Dies ist bei verteilten Daten und der gleichzeitigen Forderung nach möglichst sofortiger Anfragebeantwortung nicht möglich. Hier mussten also andere Lösungen gefunden werden. Eine davon wird MVCC(Multi-Version-Concurrency-Control) genannt. Sie kontrolliert konkurrierende Zugriffe auf eine Datenbank und führt sie effizient aus und zwar so, dass normalerweise keine Blockaden bei den einzelnen Zugriffen auftreten. Außerdem muss die Datenbankkonsistenz gesichert werden. Um die Effizienzforderung zu erfüllen, müssen Transaktionen nicht warten, bis Datenbankobjekte verfügbar sind. Dazu werden verschiedene versionierte Objekte im Speicher vorgehalten und den jeweiligen Transaktionen angeboten [Gull 211, S. 340]. Auf diese Weise werden lesende Zugriffe niemals blockiert. Allerdings geht dies zu Lasten des Speicherplatzes, da viele verschiedene Versionen eines Objekts vorgehalten werden müssen.

MVCC

Wieso MVCC?

Diese Datenbanksysteme übertragen die Daten zwischen den Rechnerknoten mit dem HTTP-Protokoll. So auch CouchDB. Das HTTP-Protokoll ist zustandslos (stateless), was bedeutet, dass eine Übertragung wie folgt realisiert wird: Es wird eine Anfrage (request) an den Server gesendet, die Netzwerkverbindung wird geöffnet, die Daten werden gesendet und/oder empfangen, die Verbindung wieder geschlossen und der Server verliert die Informationen zur Anfrage wieder. D.h. der Client packt alle notwendigen Informationen in diese eine Anfrage [Gull 2011, S. 30]. Dadurch wird die Kontrolle der Daten dem Datenbankserver entzogen, sie liegt bei der Anwendung und ein Verfahren wie MVCC muss für die Abstimmung der Zugriffe sorgen.

Datenmodell, Schema

Damit ergibt sich, gegenüber den relationalen Datenbanken, eine wesentlich veränderte Struktur des Datenmodells (Schemas). Elementarer Bestandteil sind die Dokumente, mit der Flexibilität bzgl. ihres Aufbaus (unterschiedliche Key/Value – Paare, usw.). Eine weitergehende Strukturierung erfolgt, ähnlich den Key/Value - Datenbanken, durch Collections. Dies sind Gruppierungen von Dokumenten nach inhaltlichen / fachlichen Gesichtspunkten, die beim Umgang mit den Daten Bedeutung haben. Z.B. können in MongoDB innerhalb einer Abfrage nur Dokumente aus einer Collection durchsucht und zurückgeliefert werden [Trelle 2014, S. 93]. Direkt vom System her kommen zum Datenmodell noch hinzu die Versionen von Dokumenten.

Das, was man als relationale Verknüpfung kennt, gibt es bei diesem Datenbanksystemtyp nicht. Es gibt aber Referenzen auf Objekte. Diese können manuell oder mittels sogenannter DBRef-Verweise verwaltet werden. Verwendet man DBRefs, wird neben der ObjektId des referenzierten Dokuments auch der Name der Collection und ggf. sogar der Name der Datenbank gespeichert. Ein Beispiel:

Verknüpfungen zwischen Dokumenten (Referenzen)

{$ref: <collectionName>, $id: <ObjectId>, $db: <dbName>} [Trelle 2014, S. 39].

Somit kann zumindest ein Stück weit die Beziehungssemantik von Daten erfasst werden.

Ein Datenmodell wie dieses erlaubt ein Vorgehen, wie es Edlich et al. für MongoDB beschreiben:

Beispiel MongoDB

"Das Schema wird mit Einfügen eines Dokuments zur Laufzeit erzeugt." [Edlich, Friedland, Hampe u.a. 2011, S. 133]

Und, so kann man ergänzen, wird mit jedem abweichenden Dokument verändert.

Auf einen wichtigen Nachteil dieser Schemaausgestaltung und -flexibilität weist Trelle hin: Es gibt keine Transaktionen, die mehr als ein Dokument umfassen und selbst bei Operationen auf nur einem Dokument ist kein explizites Rollback möglich [Trelle 2014, S. 7].

Beispiele

Apache CouchDB, MongoDB, Lotus Notes [Gull 2011, S. 19].

20.2.13 Spaltenorientierte Datenbanken

Eine andere Zielsetzung als obige NoSQL-Datenbanken hat die in diesem Abschnitt vorgestellte Architektur. Bei ihr geht es darum, durch eine andere Art der Speicherung der Tabellen (Relationen) relationaler Datenbanken bestimmte Auswertungen schneller ausführen zu können.

Zeilenorientiert - Spaltenorientiert

Für Relationen gibt es die konzeptionelle Vorstellung einer Tabelle, die dann durch einige Festlegungen ("flat table", ...) zur Relation wird (vgl. die Kapitel 4 – 13 in [Staud 2015]). Dabei stehen die Attribute nebeneinander und beschreiben die Tupel. In jedem Tupel stehen dann die Attributsausprägungen genauso nebeneinander. Auch bei der physischen Datenorganisation relationaler Datenbanken ist dies dann so. Aus Tupeln werden Datensätze, am Anfang der Datei ist der Dateikopf mit den Attributsbezeichnungen, Datentypen, usw., dann folgen die Datensätze, einer nach dem anderen, jeweils Ausprägung nach Ausprägung. Deshalb werden diese Datenbanken als zeilenorientiert bezeichnet.

Zeilenorientierung

Diese "Zeilenorientierung" ist gut im Sinne sparsamer Datenzugriffe, wenn mehrere Attribute einer Relation abgefragt werden müssen, z.B. die Namen, Vornamen und Gehälter der Angestellten. Sprünge beim Lese- oder Schreibzugriff gibt es dann im Wesentlichen nur, wenn von Tupel zu Tupel weitergegangen wird. Hat man nun aber Abfragen, bei denen ein bestimmtes Attribut über sehr viele Tupel, also eine Ausprägung über sehr viele Datensätze, abgefragt wird, ist diese Anordnung hemmend. Von jedem Datensatz wird ja nur eine Ausprägung gelesen, dann muss die Abfrage zum nächsten Datensatz springen. Dies kostet Zeit. Ein wirkliches Problem ist dies angesichts der immer besser gewordenen Zugriffsgeschwindigkeiten externer Speicher aber nur bei sehr großen Datenmengen.

Für solche Situationen wurden die spaltenorientierten Datenbanksysteme und Datenbankengeschaffen. Hier werden die Attributsausprägungen eines Attributs mehrerer Tupel (sozusagen) hintereinandergeschrieben. Jede Spalte kann dabei in einer eigenen Datei liegen. Die Ausprägungen eines Attributs liegen hier also hintereinander, über die Tupel hinweg. Hierzu ein Beispiel:

Spaltenorientierung

Es soll eine Datenbank mit Kundendaten angelegt werden. Die Attribute sind KuNr (Kundenummer), KuName (Kundenname), Ort und Umsatz. Das führt in relationalen Datenbanken zur folgenden konzeptionellen Tabellendarstellung:

KUNDEN

#KuNr

KuName

Ort

Umsatz

1001

Schmidt

Berlin

5000

1002

Koch

Stuttgart

3000

1003

Widmer

Köln

7000

...

 

 

 


Zeilenorientiert

Die klassische Lösung in relationalen Datenbanken, die auf der physischen Ebene zu evtl. indexierten sequentiellen Dateien führt, ist wie folgt: Alle Datenwerte einer Zeile (Attributsausprägungen) werden aneinandergefügt und anschließend folgt die nächste Zeile. Somit entsteht aus dem obigen Beispiel eine "Tupelfolge" mit folgendem Aufbau:

1001, Schmidt, Berlin, 5000; 1002, Koch, Stuttgart, 3000; 1003, Widmer, Köln, 7000; ...

Zeilen hintereinander

Der Strichpunkt wurde als Trenner zwischen den Tupelwerten genommen.

Und nun spaltenorientiert

Eine spaltenorientierte Datenbank hingegen legt die Ausprägungen eines Attributs in der entsprechenden Datei über alle Tupel hinweg hintereinander. Mit dem obigen Beispiel:

1001,1002,1003; Schmidt, Koch, Widmer; Berlin, Stuttgart, Köln; 5000, 3000, 7000; ...

Spalten hintereinander

Die konzeptionelle Vorstellung ist die einer Zerlegung der Relation:

KUNDEN-Name

#KuNr

KuName

1001

Schmidt

1002

Koch

1003

Widmer

...

 


KUNDEN-Ort

#KuNr

Ort

1001

Berlin

1002

Stuttgart

1003

Köln

...

 


KUNDEN-Umsatz

#KuNr

Umsatz

1001

5000

1002

3000

1003

7000

...

 


Entscheidend ist aber nicht diese, sondern die damit einhergehende veränderte physische Struktur.

Hat man Auswertungen, die zahlreiche Attributsausprägungen eines Attributs verarbeiten (hier z.B. der Durchschnittsumsatz aller Kunden; eine Auszählung, wieviele Kunden in den einzelnen Städten sind), müssen nicht alle Zeilen, sondern nur die Spalten, welche für die Auswertung relevant sind, durchsucht werden. Damit erhofft man sich vor allem folgende Vorteile:

Vorteile der spaltenorientierten Speicherung

  • Die für Auswertungen in einem Data Warehouse benötigten Auswahlprozesse können, wenn sie auf einem einzelnen Attribut basieren, schneller realisiert werden.
  • Aggregate (gespeicherte aggregierte Werte: z.B., ausgehend von Tagesdaten, die von Wochen, Monaten, Jahren) können eingespart werden, da die aggregierten Werte bei Bedarf in Realzeit berechnet werden.
  • Bessere Komprimierbarkeit, da die Spalten homogenere Daten als Tupeldaten haben. Vgl. unten.
  • Evtl. Verzicht auf Indexierung, da diese Speicherungstechnik die Effizienz der Abfragen steigert.

Diesen Vorteilen steht der Nachteil gegenüber, dass das Einfügen von Tupeln aufwendiger ist. Ebenso die Durchführung bestimmter Abfragen, z.B. wenn viele oder alle Attribute der Tupel benötigt werden. Dann muss bei dieser Speicherungsform deutlich mehr „gesprungen“ werden als in der zeilenorientierten.

Nachteil

Neben dem schnelleren Zugriff ist der Wunsch nach effizienterer Komprimierung ein Motiv, denn die spaltenorientierte Speicherung eignet sich besonders gut für Komprimierungsmethoden. Der Grund liegt darin, dass Daten desselben Typs (Attributsausprägungen eines Attributs) auf dem Speichermedium in aufeinander folgenden Abschnitten gespeichert werden. Wenn es sich beim jeweiligen Attribut nicht um einen Schlüssel handelt, liegen sogar viele gleiche Attributsausprägungen vor.

Hauptmotiv: große Datenmengen

Als Komprimierungsmethode nennen [Plattner und Zeier 2011] die Light-Weight-Compression. Die Vorgehensweise ist recht einfach, so können mehrfach vorkommende Werte durch Variablen ersetzt werden, die in einem Wörterbuch gepflegt werden. Mithilfe dieses Wörterbuches können sie wieder in ihre ursprünglichen Werte übersetzt werden. Bei identischen Werten, die direkt aufeinander folgen, können diese als Sequenzlauflängen codiert abgelegt werden.

Ein weiteres Entwurfsziel spaltenorientierter Datenbanken ist die Erleichterung der horizontalen Skalierbarkeit. Damit ist die Möglichkeit gemeint, den Datenbestand und seine Verarbeitung auf eine große Anzahl von Clustern zu verteilen (vgl. [Staud 2015, Abschnitt 24.5.6]).

Horizontale Skalierbarkeit

Zusammengefasst kann mit [Plattner und Zeiher 2011] festgehalten werden, dass spaltenorientierte Datenbanken für analytische Systeme mit sehr vielen Lesevorgängen optimiert sind, während zeilenorientierte Datenbanken für operative Systeme mit sehr vielen Schreibvorgängen entwickelt wurden.

[Plattner und Zeiher 2011] empfehlen für moderne Datenbanksysteme beides, Zeilen- und Spaltenorientierung (hybride Technik). Durch eine solche optimale Mischform sehen sie Performanceverbesserungen von bis zu 400% gegenüber einer reinen Zeilen- oder Spaltenorientierung.

Hybride Technik

 

21 KI für Geschäftsprozesse

21.1 Konventionelle Programmierung

Es ist in den Kapiteln 17 bis 19 deutlich geworden, Geschäftsprozesse werden inzwischen IT-gestützt abgewickelt oder sind sogar völlig automatisiert. Konkret bedeutet dies, dass sie durch Softwaresysteme realisiert sind, dass Menschen weitgehend nur noch Entscheidungen fällen. Typisches Beispiel ist unser aller Umgang mit den Plattformen der Internet-Unternehmen.

Diese Programme sind heutzutage i.d.R. mit klassischen prozeduralen oder objektorientierten Programmiersprachen und ihren Entwicklungsumgebungen eingerichtet worden. Also z.B. mit C, C++, Java, JavaScript, PHP. Damit wird schon einiges geleistet, wie man insbesondere bei den Plattformen der Internet-Unternehmen sehen kann.

Die Ansprüche wuchsen aber, parallel zur immer detaillierteren Abbildung der Geschäftsprozesse in Software. Komplexere Abläufe und Problemstrukturen mussten programmiert werden, womit man an die Grenzen der konventionellen Programmierung stieß.

Grenzen

Konventionell?

Rund um das Thema Software für Geschäftsprozesse wird hier bzgl. der zugrundeliegenden Programmiersprachen die einfache Unterteilung "KI-Sprachen / sonstige Sprachen" gewählt. Dies ist eine sehr schlichte Unterteilung, die für diesen Zweck aber völlig ausreichend ist. Für eine vertiefte Differenzierung vgl. die einschlägige Literatur, für die aktuelle Situation die IT-Fachzeitschriften, z.B. die Zeitschriften des Heise-Verlags. Das Sonderheft "ix kompakt 2019 – Programmieren heute" gibt einen verständlichen aktuellen Überblick zu Programmiersprachen und Entwicklungsumgebungen.

Hier wird der Begriff konventionelle Programmierung und Programmiersprachen für die Entwicklung mit den "sonstigen Sprachen" gewählt.

Woher kommen diese Grenzen? Konventionell programmierte Programme folgen vorher festgelegten Abläufen und Geschäftsregeln mit fest definierten Inputs und Outputs. Mögliche Varianten im Ablauf müssen im Programm realisiert worden sein. Bei Geschäftsprozessen bedeutet dies, dass standardisierte, nicht zu tief detaillierende Prozessmodelle von wohlstrukturierten Prozessen gut mit konventionellen Programmiersprachen nachgebildet werden können. Hierfür sind die typischen Programmierkonstrukte wie Fallunterscheidung ("if-then"), Schleifen ("do while"), usw. ausreichend. Nur um die Leistungsfähigkeit dieser Programmiertechniken zu verdeutlichen, hier der Hinweis, dass die derzeitigen Internet-Portale mit der Plattform Webbrowser und sehr oft mit JavaScript realisiert sind, einer durch und durch konventionellen Programmiersprache.

Ablauf

21.2 KI-Programmierung

KI-Programmierung beruht auf anderen Programmiertechniken. Sie hat im Übrigen schon eine sehr lange Geschichte. Der Verfasser hat bereits zu Beginn seiner Berufstätigkeit – in den 1980er-Jahren – mit den Studierenden einfache Expertensysteme mit Prolog erstellt. Ertel schreibt sogar von 60 Jahren KI-Geschichte [Ertel 2016, S. V].

So richtig Fahrt aufgenommen hat die Entwicklung der KI-Methoden in den letzten 20 Jahren. Sie sind inzwischen auch sehr leistungsstrak, wie viele Beispiele zeigen. Von den vielen Methodenvorschlägen haben sich folgende als erfolgreich erfolgreich erwiesen:

  • Prädikatenlogik erster Stufe. Hierfür fand und findet Prolog Verwendung
  • Neuronale Netze
  • Methoden des maschinellen Lernens

Vgl. [Ertel 2016] für eine Einführung in die KI.

Die aktuellen Schlagworte sind

  • Maschinelles Lernen, aktuell meist basierend auf künstlichen neuronalen Netzen. Inzwischen auch mit zahlreichen Schichten (deep learning)
  • Deep Learning

<<Schon bald mehr>>

Ein erstes "Hineinschnuppern" erlaubt das Tutorial von Völkl in der Zeitschrift iX: [Völkl 2018 a,b,c].

Frage:

Viele der aktuellen erfolgreichen KI-Beispiele beruhen auf der Analyse von Mustern (Bildpunkten, Szenarien, usw.). Diese müssen in großer Zahl erhoben und dem Programm zur Verfügung gestellt werden. Welche Konsequenzen ergeben sich daraus?

21.3 KI für Geschäftsprozesse

Bei dem oben beschriebenen Leistungsspektrum ist es nicht überraschend, dass KI-Techniken bei den Entwicklern von Software für Geschäftsprozesse, insbesondere bei denen, die sich der Entwicklung automatisierter Software widmen, ebenfalls Aufmerksamkeit erregten.

Woher kommt nun der Bedarf an KI-Techniken für die Programme, die Geschäftsprozesse umsetzen. Sie speisen sich, wie oben zu sehen war, aus dem Wunsch, den gesamten Prozess zu automatisieren. Dies wird oft "end-to-end" genannt und meint insbesondere, dass auch der Kontakt zum Kunden in die IT-Unterstützung bzw. Automatisierung genommen werden muss. Daraus entsteht folgender Bedarf:

„end-to-end“

  • Verstehen des Inhalts von Textdokumenten (z.B. Kundenmails)
  • Verstehen menschlicher Sprache (z.B. Kundenanrufe)
  • Fähigkeit, Text zu erzeugen (schriftliche Antworten an Kunden, Partner, usw.)
  • Fähigkeit, Sprache zu erzeugen (telefonische Antworten an Kunden, Partner, usw.)
  • Entscheidungsunterstützung. Bis dahin unstrukturierte Probleme können u.U. mit Problemlösungstechniken der KI gelöst werden.

<<Schon bald mehr>>

21.4 Maschinelles Lernen

Bald wurde erkannt: KI ohne Lernfähigkeit ist nicht ausreichend. Es ist die Vorstellung, eine Software zu schreiben, die Vorgänge beobachtet und dabei lernt. Etwa so, wie beim Schachspiel: Die Software beobachtet Spieldurchgänge bis zum Erfolg und oder Misserfolg und kann dann erfolgreiche Strategien ableiten. Sie wird, das zeigen die Beispiele, umso besser, je mehr Vorgänge sie beobachten kann.

Software, die lernt

Heute beruht dies auf Mustern und ihrer Analyse. Ganz zu Beginn wird die Software mithilfe möglichst vieler Muster der zu durchdringenden Problematik "traniert", während der Einsatzzeit erwartet man, dass die Software aus ihrem Tun mit weiteren realen Mustern dazulernt. Dies funktioniert in vielen Bereichen recht gut, z.B. der Bilderkennung.

Diese Lernfähigkeit von Software ist nur mit KI-Techniken realisierbar. Eine wichtige Technik hierfür war und ist die der neuronalen Netze und des Deep Learning. Vgl. für die Grundlagen [Ertel 2016], insbes. Kapitel 9.

Typische Forderungen, die damit umgesetzt werden sollen, sind:

  • Automatisches Erkennen von Personen auf hochgeladenen Photos (z.B. bei Facebook)
  • Selbständiges Entdecken neuer Zusammenhänge in Kundendaten (wie mit Salesforce's Einstein)
  • Analyse und Diagnoseerstellung auf Basis von digitalisierten Patientendaten

Von grundsätzlicher Bedeutung für den Erfolg dieser auf Musteranalyse beruhenden KI-Techniken ist, dass sehr viele Muster zum Trainieren der Software zur Verfügung stehen und dass diese alle tatsächlich vorkommenden Muster angemessen repräsentieren. Gelingt dies nicht, scheitern diese Verfahren. Dann kann es zur "BlackSwan" - Thematik kommen: die Software scheitert, wenn etwas gänzlich Neues passiert.

Viele repräsentative Muster

Frage:

Woran könnte es liegen, dass die Versuche, Geschäftsprozesse automatisch zu modellieren, derzeit noch nicht sehr weit kommen.

Dass bzgl. Machine Learning hier bei den Softwarerobotern (noch?) nicht alle Erwartungen erfüllt werden, zeigt die Anmerkung von Bremmer, der eine Gartner-Studie zitiert: "Trotz der Behauptungen einiger RPA-Anbieter gibt es laut Gartner jedoch nur begrenzte Möglichkeiten, ML im Kern von RPA selbst zu nutzen". [Bremmer 2019, S. 23]

ML = Machine Learning

Software für Machine Learning

Ganz aktuell (2018 - 2020) wird diesbezüglich derzeit das Machine Learning Framework TensorFlow von Google (so etwas wie eine Programmbibliothek) thematisiert. Einen verständlichen Einstieg bietet das Tutorial von Völk in der Zeitschrift iX (vgl. [Völkl 2018a, b, c]). Einen Überblick über die zur Verfügung stehenden Tools gibt [Dose 2019].

21.5 Konkreter Einsatz

In [Reder 2019a] wird aus der IDG-Studie "Machine Learning/Deep Learning 2019" berichtet. Die Frage an die Unternehmen war: Welche KI/ML-Methoden nutzen Sie oder planen Sie demnächst zu nutzen?" Danach sind bei der Stichprobe (n=239) folgende KI-Methoden im Einsatz:

 


Technologie

Anteil in %

Spracherkennung

48,5

Assistenzsysteme

44,4

Maschinelle Übersetzung

43.1

Planungssysteme

41,4

Bilderkennung/Bildanalyse

39.3

Optische Zeichenerkennung/Textanalyse

38,5

Big Data Analytics

37.7

intelligente Steuerungssysteme

35,6

Zielgruppenidentifikation

33,1

Autonome Systeme

32,6

Gesichtserkennung

32,6


 

22 GPM im Zeitalter der Digitalisierung

<<Dieses Kapitel wird gerade überarbeitet>>

23 Software für Geschäftsprozessmanagement

23.1 Mögliche Untersützung

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
  • Mithilfe bei der Modellierung von Geschäftsprozessen, z.B. bei der Erstellung einer graphischen Repräsentation
  • 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äftsprozessmanagements, durch

  • Werkzeuge zur Systementwicklung (Case-Tools).

Die Liste deutet schon an, dass sehr unterschiedliche Typen von Software hier genannt 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 Softwarepakete, 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]).

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 Abbildung des Geschäftsprozesses und die Fähigkeit, Änderungen am Prozess leicht einzubauen, bedacht werden.

23.2 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 gekauft und auf eigener Hardware betrieben oder als Cloud-Lösung gemietet werden.

23.3 Modellierungswerkzeuge

Hier einige ausgewählte Produkte (in Klammern jeweils das anbietende Unternehmen):

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

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

BPMN-Suiten

  • Bizagi Suite (Bizagi Ltd.). Hauptsitz Großbritannien, 2014 mehrfach als „Finalist" für BPM ausgezeichnet.
  • DHC Vision (DHC Business Solutions GmbH amp; Co. KG). Saarbrücker Unternehmen mit Fokus auf Prozessunterstützung und regulatorischen Anforderungen.
  • HCM VDoc Process (HCM Customer Management GmbH). Stuttgarter Unternehmen, 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. amp; Co. KG)

Quelle: [Adam, Koch, Neffgen et al. 2014, S. 124f], zitiert nach [Gadatsch 2015, Pos. 653ff].

Soweit eine kleine Auswahl. In den Quellen finden sich mehr. Die OMG (Object Management Group) listet über 150 meist kleinere Anbieter von BPM-Produkten.

<<Mehr dazu im Seminar/in der Lehrveranstaltung

 

24 Glossar

A

Ablauforganisation

„Unter Ablauforganisation versteht man die Gestaltung von Arbeitsprozessen. ... Man unterscheidet

(1) die Ordnung des Arbeitsinhalts,

(2) die Ordnung der Arbeitszeit,

(3) die Ordnung des Arbeitsraumes,

(4) die Arbeitszuordnung“ [Wöhe 1993, S. 196].

Aufbauorganisation

Mit Aufbauorganisation ist die Zerlegung der Gesamtaufgabe einer Organisation in Teilaufgaben angesprochen. Die Zerlegung muss so erfolgen, dass ein effektives Zusammenwirken bei der Abwicklung konkreter Geschäftsprozesse möglich ist. Mit diesem Begriff bezeichnet man die entstehende Organisationsstruktur als solche wie auch die Tätigkeit des Organisierens selbst:

„Erste Aufgabe 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 (Aufgabensynthese), wobei sich aus der Aufgabenstellung Beziehungszusammenhänge zwischen diesen Stellen ergeben“ [Wöhe 1993, S. 183].

B

Bewegungsdaten

„Die Bewegungsdaten lassen sich in Transferdaten, die Vormerkdaten und die Archivdaten untergliedern. ... Transferdatenbestände enthalten solche Daten, die von einem Programm generiert oder bearbeitet wurden und nun einem anderen geliefert werden. ..." [Mertens 1995, S. 21f]

„Bewegungsdaten sind Daten mit einem zeitlichen Bezug. Sie dienen der chronologischen Speicherung aller Vorgänge und entstehen im Verlauf der Geschäftsprozesse. Typische Bewegungsdaten sind die Kundenaufträge, die Bestellungen oder die Fertigungsaufträge. Inhalte von Bewegungsdaten können Plan- oder Istdaten sein.“ [Hohmann 1999, S. 92f] Siehe auch: Stammdaten

G

Graph, Graphentheorie 

Für die Beschreibung im Rahmen des Kontrollflusses benutzen auch die UML-Autoren Begriffe der Graphentheorie. Hier vor allem zwei:

  • Kanten / edges
  • Knoten / nodes

Ein Graph besteht aus Knoten, die durch Kanten verknüpft sind. Hier in der UML sind die Kanten immer gerichtet, so dass es sich um gerichtete Graphen handelt.

N

Nebenläufigkeit

„Haben zwei Aufgaben weder eine direkte noch eine indirekte Verbindung, so sind sie nebenläufig, d.h., sie können nacheinander oder nebeneinander ablaufen.“ [Österle 1995, S. 95]

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

O

Organisationseinheit

Eine Organisationseinheit ist eine Zusammenfassung von einer oder mehreren Stellen zu einem selbständigen Teil der Organisationsstruktur eines Unternehmens.

R

Referenzmodelle

Im Bereich der Betriebswirtschaftlichen Standardsoftware oder ERP-Software ist damit ein abstraktes (nicht auf ein bestimmtes Unternehmen bezogenes) Modell der Unternehmensrealität gemeint. Dabei werden heute, in Anlehnung an Scheer’s Arbeiten, Modelle bzgl. der Datenbanken, der Organisationsstrukturen, der Funktionen (Tätigkeiten) und der Geschäftsprozesse unterschieden. Hier ist dann auch von Unternehmensmodellierung die Rede.

Eine Diskussion des Begriffs auf dem allgemeinen Hintergrund der Gestaltung Integrierter Informationssysteme mit weiteren Literaturhinweisen findet sich bei [Hohmann 1999, S. 56ff].

S

Stammdaten

Stammdaten sind Teil der Datenbestände (betriebswirtschaftliche und technische), die ein Unternehmen zur informationellen Absicherung benötigt, und zwar der Teil, der nur in Ausnahmefällen verändert wird.

„Die wichtigsten Stammdaten einer integrierten IV sind: Kunden, Lieferanten von Erzeugnissen und Dienstleistungen ..., Teile - unter dieser Bezeichnung sollen Roh-, Hilfs- und Betriebsstoffe sowie Halb- und Fertigfabrikate zusammengefaßt werden -, Stücklisten ..., Arbeitspläne ...., Betriebsmittel, Kostenstellen und Personal.“ [Mertens 1995, S. 21].

„Stammdaten unterliegen selten Veränderungen und bilden die Basis von Integrierten Systemen. Stammdaten sind zustandsorientierte Daten, die der Identifizierung, Klassifizierung und Charakterisierung von Objekten (Sachverhalten) dienen und die über einen längeren Zeitraum hinweg unverändert zur Verfügung stehen. Typische Stammdaten sind Kundenstamm, Lieferantenstamm, Preis- und Konditionenstamm, Artikelstamm, Stücklisten, Arbeitspläne, Kostenstellen usw.“ [Hohmann 1999, S. 92], s.a. Bewegungsdaten

Stellen

Stellen sind die kleinsten organisatorischen Einheiten im Unternehmen.

V

Vorgehensmodelle

„Vorgehensmodelle legen für die Aktivitäten, die im Rahmen der Tätigkeit softwareproduzierender Einheiten (SPEs) notwendig sind, deren wechselseitige Beziehungen fest und geben vorgeschriebene Reihenfolgen an.“ Sie bringen auch gleich ein Beispiel: „Das Wasserfallmodell ist das bekannteste Modell zur Softwareentwicklung; es bildet den gesamten Lebenszyklus einer Software durch sequentielle Unterteilung in Phasen ab.“ [Bullinger und Fähnrich 1997, S. 11]. In dieser Arbeit findet sich auch ein Vergleich unterschiedlicher Vorgehensmodelle des Software Engineerings (S. 11ff).

Im Umfeld Betriebswirtschaftlicher Standardsoftware wird ebenfalls von Vorgehensmodellen gesprochen, im Sinne von Vorschlag für die Einführung. Bekanntestes Beispiel ist das Vorgehensmodell der SAP für die Einführung von R/3.

W

Wertschöpfung

Eigentlich bedeutet Wertschöpfung: „Beitrag, den ein Unternehmen zum Bruttoinlandsprodukt beiträgt“ [Schneck 1998, S. 779]. Die Betriebswirtschaftslehre versteht unter Wertschöpfung das Betriebsergebnis abzüglich externer Vorleistungen [Stahlknecht 1995, S. 235]. Steinbuch definiert wie folgt: „Wertschöpfung wird üblicherweise als Differenz von Betriebsertrag und Vorleistungen definiert.“ Er führt die Definition des Verband Deutscher Maschinenbauanstalten (VDMA) an: Wertschöpfung = Betriebsertrag – Vorleistungen [Steinbuch 1998, S. 33]. Im Zusammenhang dieser Arbeit ist der Begriff von Bedeutung für das Konzept der Wertschöpfungskette.

Wertschöpfungskette

Der Begriff Wertkette oder Wertschöpfungskette (valuechain) geht auf Porter zurück (vgl. [Porter 1985], [Porter 1998]). 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ührenden unterstützt werden (Finanzwesen, Controlling, Personalwesen, usw.). Es versteht sich, dass Wertschöpfungsketten auch Geschäftsprozesse sind (vgl. auch [Stahlknecht 1995, S. 235] sowie für eine Kurzdarstellung [Schneck 1998, S. 779]).

 

25 Stichwortverzeichnis (der Textversion)

 

 

1. Integrationsaspekt 277

2. Integrationsaspekt 277

3V 345

Abhängigkeit vom Softwarehersteller 283

Abteilungen 23

Abwicklung 19

ACID vs. BASE 343

Actbot

Beispiel 327

Definition 327

ActBot-Beispiel

Bestellungsänderung 327

Saldenbestätigung 330

ActBots 311

Adjazenzmatrix 358

Aggregation 223

Beispiel 186

durch Kapselung 215

Aggregationsniveau

Beispiel 215

Aktivität 140

Aktivitätsdiagramme 110

Amazon Web Services 297

Analysegrenzen 113

Anbieter von Diensten 290

Anwendungsbereich

im DB-Kontext 351

Anwendungsfälle 110

API 342

Appraisal 82

Architektur integrierter Informationssysteme. 250

Architekturmerkmal für WfMS 288

ARIS 250

Assessment 79

Attributkonzept 351, 352, 353

Attributsausprägungen 352

Attributsbezeichnung 352

Aufgabe

Definition 26

Aufgabe, abstrakte

Beispiel 181

Aufgaben 26

Eigenschaft 26

Aufgabenträger 33

Auftragsabwicklungsprozesses 256

auslösende Ereignisse 219

Auslösern der Ereignisse 154

Außenwelt und Cloud Computing 272

Automaten 101

Automatisierung 34, 52

Problemstruktur 37

SAP 282

Automatisierung der Prozessabwicklung

Beispiel 46

Automatisierung von Geschäftsprozessen 23, 43, 275, 302

Automatisierungsgrad 34, 43, 309

Informationsobjekte 120

Automatisierungspotential 39, 40, 48

bei Kernprozessen 48

bei Supportprozessen 48

Automatisierungsstufen 288

Bahnen 143

Balanced Scorecard 66

BASE 348

BASE vs. ACID 343

Basically Available 348

Becken 143

Bedingungen 130

Bedingungs-Startereignis 180

Bedingungs-Zwischenereignis, empfangend

Beispiel 176

Beispiel

Aggregation 186

Aufgabe, abstrakte 181

Bedingungs-Zwischenereignis, empfangend 176

Dienst-Aufgabe 176, 181, 190

Empfänger-Aufgabe 181, 190

Ereignissubprozess 183, 184

Exclusive Gateway / datenbasiert und verzweigend 186, 187, 188, 190

Exclusive Gateway / ereignisbasiert 176, 190

Exclusive Gateway / ereignisbasiert, für den Prozessstart 176

Exclusive Gateway, verzweigend (datenbasiert) 175

Fehler-Schlussereignis 183

Fehler-Startereignis / Ereignissubprozess, unterbrechend 183

Gruppe 178

Inclusive Gateway, verknüpfend 187

Kompensations-Zwischenereignis / abgebend 183

Nachrichtenfluss 178

Nachrichten-Startereignis 181

Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend 184

Nachrichten-Zwischenereignis 190

Nachrichten-Zwischenereignis / empfangend 190

Nachrichten-Zwischenereignis, empfangend 176, 179

None-Startereignis / oberste Ebene 181

Nutzer-Aufgabe 176

Online-Fachhändler 326

Parallel Gateway, verknüpfend 183, 187, 188, 190

Parallel Gateway, verzweigend 179, 183, 187, 188, 190

Schlussereignis 184

Sender-Aufgabe 176

Signal-Zwischenereignis, empfangend 176

Supportprozess 48

unstrukturierte Probleme 50

Zeitgeber-Zwischenereignis 190

Zeitgeber-Zwischenereignis / empfangend 176

Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend 177

Zwischenereignis / empfangend 176

BEispiel

Muster Kombinatorik 188

Benchmarking 59

Definition 91

Beschreibungsebenen

Definition 251

Betriebswirtschaftliche Standardsoftware 246

Beziehung zwischen zwei Funktionen 173, 217

Big Data 337

BlackSwan - Thematik 369

Blue Prism 314

Bot 311

Definition 315

Botnet 315

BPM 16

Branchensoftware

Definition 278

BSON 361

Business Objects 27

Business Process Diagram 141

Business Process Management 16, 17

Business Process Reengineering 18, 61, 94

Definition 18

BW-Referenzmodelle 104

Byte 338

Call Activity 184

CAP-Theorem 347

Chatbot

Beispiel 327

ChatBot-Beispiel 331

ChatBots 311

Chevron-Symbole 159

Chief Process Owner 20

Clique 338

Cloud Computing 273, 274, 296

Definition 296

Cognesys 327

Cognitive Process Automation 318

collaboration 145

Collections 362

Controllingprozess 257

CRM 293, 340

Customer Relationship Management 276, 293, 298

Customizing 278

Begriffsklärung 59

Definition 278

Dashboard 322

Datenflussdiagramm 268

Datenflussorientierte Methoden

für die Prozessmodellierung 110

Datenintegration

fehlende 102

Daten-Lokalität 346

Datenstrukturen

neue im Internet 336

Decision Model and Notation 112

Definition

Aufgabe 26

auslösende Ereignisse 219

erzeugte Ereignisse 219

Funktion 27

Geschäftsprozess 28, 29, 30, 32

Geschäftsprozessmanagement 18

Informationsobjekt 119

Kontrollfluss 32

Kontrollflusszweig 120

Objekt 27

primäre Geschäftsprozesse 49

Prozesseffektivität 68

Prozesseffizienz 68

Prozessvision 64

sekundäre Geschäftsprozesse 49

Standardprozessmodellierung 105

unabhängige Ereignisse 229

Vorgang 27

Zeitfenster 189

Zielsystem 66

Desintegration 273

Desktop Activity Mining 322, 323, 335

Detaillierung 26

Dienst-Aufgabe

Beispiel 176, 181

Beispiele 190

Digitalisierung 43, 105, 106, 107, 108, 109, 110

Dokument 358

Dokumentation von Geschäftsprozessen in Tabellen 58

durchschnittlicher Geschäftsprozess 278

EAI 275

EAI-Systeme 294

E-Banking 295

E-Business 295

Definition 295

E-Commerce

Definition 295

EDI 271

Effektivitätskennzahlen 78

Effizienzkennzahlen 78

Einfache RPA-Systeme 312

Eingebettete Dokumente 359

Elementaraufgaben

Definition 26

Elementare Tätigkeiten

Definition 106

Elternprozess 149

Empfänger-Aufgabe

Beispiel 181, 190

Enterprise Application Integration 275

Enterprise Application Integration - Systeme 294

Entscheidungsfindung 167

BPMN 174

Entscheidungsfunktion 232, 233

E-Procurement 295

Ereignis startet Funktionen 229

Ereigniskonzept 33

Ereignisraum

zeitlich 199

Ereignisraum eines Unternehmens 172, 217

Ereignisse 115, 116

auslösende 219

Benennung 117

Definition 117

erzeugte 219

gemeinsame Bedingungen 221

Ereignisse (Unabhängige)

Definition 229

Ereignisse als Bedingungen 221

Ereignissubprozess 183

Beispiel 183, 184

Ereignissubprozess, nicht unterbrechend 184

Ereignisverknüpfung mit auslösenden Ereignissen 221

Ereigniswelt des Unternehmens 108

Erfolgsfaktoren 63, 67

Ergebnisereignis 232

Ergebnisereignisse 124

Ergebniskennzahlen 77

ERP Central Componente

Support-Ende 284

ERP-Software 15, 26, 269, 271, 276, 281, 302

Abklärung 246

Anspruch 278

Beschreibung 276

Notwendigkeit 284

Erweiterung der Notation 173, 217

Erzeugen natürlicher Sprache 319

erzeugte Ereignisse 219

Eskalations-Startereignis 179

ETL-Prozess 298

European Foundation for Quality Management 261

Eventually Consistent 348

Exclusive Gateway 141

Exclusive Gateway / datenbasiert und verzweigend

Beispiel 186, 187, 188, 190

Exclusive Gateway / ereignisbasiert

Beispiel 176, 190

Exclusive Gateway / ereignisbasiert, für den Prozessstart

Beispiel 176

Exclusive Gateway, verzweigend (datenbasiert)

Beispiel 175

exclusive merging 142

Extended Enterprise 270, 271

externes Ereignis 206

Fähigkeitsgrade 82

Fähigkeitsstufe

Established 84

Incomplete 85

Managed 84

Optimizing 84

Performed 85

Predictable 84

Faktendatenbanken 358

Fehlende Entscheidungsfunktion 231

Fehler-Schlussereignis

Beispiel 183

Fehler-Startereignis 179

Fehler-Startereignis / Ereignissubprozess, unterbrechend

Beispiel 183

Finanzmanagementprozess 257

flussabwärts

Definition 121

flussaufwärts

Definition 120

Fortschrittshemmer RPA 314, 317

Fremdbestimmung

durch ERP-Software 283

Führungsgrößen 67

Führungsprozesse 49

Funktion

Definition 27

Funktionen 26, 115

Benennung 117

Funktionsbäume 253

Funktionsbeziehungen 173, 217

Funktionsmodellierung

Definition 163

funktionsorientierte Software 246

Gateway 141

Geschäftsobjekt 271

Geschäftsobjekte 27, 105, 106, 119, 142, 170

Geschäftsprozess

Definition 28, 29, 30, 32

Geschäftsprozessdefinition

Becker und Vossen 29

Geschäftsprozessgedanke 24, 268

Geschäftsprozessmanagement

Definition 18

Geschäftsprozessmodellierung

Ziel 102

Geschäftsprozessoptimierung

Definition 61

Geschäftsprozessschema 112

Geschäftsregeln 120

Geschäftsstrategie 52, 63

Geschäftsziel 52

Gestaltungsregel

Weglassen Ereignisse 197

Gigabyte 338

globaler Prozess 145

GPM

fachlich-konzeptionelle Ebene 18

operative Ebene 18

strategische Ebene 19

Grafikdefizite 113

Graphendatenbanken 357

Grenzen der Prozessmodellierung 102

Grobmodellierung von Geschäftsprozessen 160

Gründungsjahr SAP 281

Gruppe

Beispiel 178

Hadoop 347

horizontale Skalierbarkeit 366

Horizontale Skalierbarkeit 345

Inclusive Gateway, verknüpfend

Beispiel 187

Individualsoftware 49, 246, 276, 285, 305

Definition 278

informationelle Umwelt 167, 295

Informationelle Umwelt 272

Informationsobjekt

Definition 119

Informationsobjekte 115

Definition 142

Informationsträger 351

In-Memory-Datenbank 298

InMemory-Technologie 281

Innovationsprozess 255

Insellösungen

Rückkehr 300

Instanz 120

eines Geschäftsprozesses 112

Instanz einer EPK 133

Instanz eines Geschäftsprozesses 133

Institutionalisierung 82

Integration von Geschäftsprozessen 274

integrierte prozessorientierte Software 15, 270

Integrierte Prozessorientierte Software 245

integrierte prozessorientierte Standardsoftware 54

Integrierte prozessorientierte Standardsoftware

Abklärung 246

integrierte Software 246

Intelligente RPA-Systeme 312

Intelligente Zeichenerkennung 318

interne Geschäftsprozesse 139

Internet 4.0 340

Internet der Dinge 340

Internet-Unternehmen 293, 294, 303, 306, 336

Definition 305

ISO 9001 93

ISO-Zertifizierung 280

Istanalyse 57, 76

Prüfung Effektivität 60

Prüfung Effizienz 60

Istmodellierung

Definition 57

IT 15

IT -Unterstützung 34

IT-Management-Prozess 257

IT-Unterstützung 15

JSON-Format 360

Kaizen 66, 93

Kante

Definition 120

Kapselung 172, 217

Beispiel 215

Probleme 172, 217

Kerngeschäftsprozesse 45

Kernkompetenzen 52, 63

Erläuterung 65

Kernprozesse

Aufwand 72

Beispiele 46

Kernziele von Geschäftsprozessen 69

Key

als Begriff in Key/Value 361

Key/Value - Paare 358

Key/Value in PHP 354

KI-Grenze 43, 107

Kilobyte 338

Kognitive RPA-Systeme 312

Kohorte 338

Kombinatorik 187

Kombinatorische Explosion 202

Kompensations-Startereignis 179

Kompensations-Zwischenereignis / abgebend

Beispiel 183

Kontinuierliches Prozessmanagement 59

Kontrolle

nach Erledigung 216

von Arbeitsfortschritten 171, 216

Kontrollfluss 28, 32, 108, 207

Definition 32, 120

EPK 115

grafische Anordnung 122

Kontrollflussorientierte Methoden

für die Prozessmodellierung 110

Kontrollflusszweig

Definition 120

Kontrollflusszweige 124

konventionelle Programmierung 306, 367

Erläuterung 367

konventionelle Prorammiersprachen 367

Koordinierungsinformation 271

Kreative / wissensintensive Prozesse 50

Kriterien für Kernkompetenzen 65

kritische Erfolgsfaktoren 19, 66, 67

Kunden

externe 25

interne 25

Kundenorientierung 17, 33, 102

Kundenzufriedenheit 68

Leidensdruck

bzgl. Datenverwaltung 337

Leistungsprofil der Organisation 45

Leistungsspektrum 52

Lieferantenkennzahlen 78

Lineare und sequenzielle Grundstruktur von Ereignisgesteuerten Prozessketten 172, 217

Log-Dateien

eines Geschäftsprozesses 320

Malware 315

Managementprozesse 49

Managementpyramide 23

Erläuterung 23

MapReduce-Framework 346

Marketing als Kerngeschäftsprozess 46

Maschinelles Lernen 318

Medienbruch 42, 267

Medienbrüche 42, 60

Megabyte 338

Mehrfach-Startereignis 180

Messung des Reifegrades 79

Methodengrenzen 113

Mobiltelefon 340

Modell vs. Instanz 54, 112

Modellbasiertes Customizing 59

Modelle von Geschäftsprozessen 276

Modellelemente von Geschäftsprozessen 116

Modellierung durch Process Mining 322, 323

Multi-Version-Concurrency-Control 362

Muster

Bedingungen 130, 168, 186, 200, 203

Entscheidungsfindung 167

BPMN 174

in GPn und Modellen 165

Informationsverarbeitung 170

Informationsweitergabe 170

repetitive Handlungen 169, 185

sich wiederholende Handlungen 214

Tätigkeiten starten 126

Teilaufgaben 168

Warten 169, 190, 206

Wiederholung 168, 185, 207, 211

Zeitfenster 169

Zeitpunkte 169

Muster in Geschäftsprozessen 191

BPMN 174

Muster Kombinatorik

Beispiel 188

Muster Rücksprung 190

Muster Zeitfenster 189

Beispiel 236

Muster Zeitpunkte

Beispiel 198

MVCC 362

Nachbarschaftsmatrix 358

Nachfrager nach Diensten 290

Nachrichtenfluss

Beispiel 178

Nachrichtenflüsse

zwischen Becken 144

Nachrichten-Startereignis 179

Beispiel 181

Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend

Beispiel 184

Nachrichten-Zwischenereignis

Beispiel 190

Nachrichten-Zwischenereignis / empfangend

Beispiel 190

Nachrichten-Zwischenereignis, empfangend

Beispiel 176, 179

NetWeaver 292

Nichtzuständigkeit 294

NLG 319

NLP 319

None-Startereignis 179

None-Startereignis / oberste Ebene

Beispiel 181

NoSQL 306

Nutzer-Aufgabe

Beispiel 176

Objekt

Definition 27

Objektorientierte Methoden

für die Prozessmodellierung 110

OCR 318

ODER

Beispiel 131, 222, 238

erzeugte Ereignisse 226

öffentlicher Geschäftsprozess 139

Öffentlicher Geschäftsprozess 144

On Premise 336

operative Prozessplanung 66

operatives Prozesscontrolling 71

Operatoren 121

Optische Zeichenerkennung 318

Orchestrierung 292

Ordnungsrahmen 253

Organisation

Definition 163

Organisation vs. Unternehmen 21

Organisationsbrüche 33, 60

Organisationsdokumentation 59

Organisationseinheiten 115

in EPKs 118

Organisationsziel 67

Parallel Gateway 141

Parallel Gateway, verknüpfend 189

Beispiel 183, 187, 188, 190

Parallel Gateway, verzweigend

Beispiel 179, 183, 187, 188, 190

Parallel Mehrfach-Startereignis 180

Parallelität

scheinbare, beim UND-Operator 225, 231

Parallelwelt 338

Personalmanagementprozess 257

Petabyte 338

Petri-Netze 111

PHP 290

PLM 293

potentielle Kunden 45

Potentielle Kunden 33

potentielle Wünsche 17

potentieller Kunde 17

Pragmatik

Anzahl Rücksprünge 209

Verzicht auf Details 230

Predictive Maintenance 318

primäre Geschäftsprozesse

Definition 49

Problem durch Kapselung 172, 217

Process Discovery 323

Process Engine 288

Process Mining 312, 321, 323

Definition 320

Process Owner 20

Process Recording 321, 322

Process Reporting 321

Process-Mining-Algorithmen 323

Product Lifecycle Management 293

Produktentwicklungsprozess 255

Produktplanungsprozess 255

Profilverlust 279, 283

Programmnahe Modellierung 104

Programmnahe Prozessmodelle 308

programmnahe Prozessmodellierung 159, 160

Programmnahe Prozessmodellierung 308

Projektleiter 20

Proprietäre Systeme 267

Prozess Balanced Scorecard 74

Prozess vs. Funktion 163, 304

Prozess- vs. Funktionsmodellierung 163

Prozessassessments 79

Prozessauditor 20

Prozessberater 20

Prozesscontrolling

Definition 71

Prozesseffektivität

Definition 68

Prozesseffizienz

Definition 68

Prozesserneuerung 98

Prozessexperte 20

Prozessgedanke 265, 268

Prozessintegration 41

Defizit 42

fehlende 102

Prozesskennzahlen 66, 72, 77

Prozesslandkarten 111, 163

Prozesslandschaft 76, 163, 245

Prozessmanager 20

Prozessmission 64

Prozessmodell 112

Prozessmodell vs. Instanz 133

Prozessmodellierer 20

Prozessmodellierung

programmnah 110

programmnah (Beispiel) 199

Prozessnahtstellen 92

Prozessorientierte Reorganisation 59

prozessorientierte Software 246

Prozessorientierung 19

Prozessstart 140

Prozessstart-Aufgabe 181

Prozessverbesserung 98

Prozessvision 64

Definition 64

Prozesswegweiser

Beispiel 130

Prozessziel 72

Prozessziele 66

Qualität der durchgeführten Arbeiten 113

Qualitätsmanagement 91

Qualitätsmanagementprozess 257

Reifegrad

Defined 83

Initial 83

Managed 83

Optimizing 83

Ouantitatively Managed 83

Reifegrade 82

EFQM 263

Reifegradmodelle

Schwachstelle 84

Releasewechsel 279

repetitive Handlungen 185

Requirement Engineering 160

Ressource IT-Landschaft 35

Ressourcenmanagementprozess 257

REST

Definition 343

Risikomanagement 88

Robotic Process Automation 43, 274, 307

Routine 33

RPA-Bot

Definition 312

RPA-Bot-Beispiel 331

RPA-Bots 311

RPA-Lösung 311

Rückschleife 185

Rückschleifen

Syntax 207

Rücksprung

Aufgabe mit Schleifenmarkierung 185

Schleife im Prozess 185

Subprozess mit Kennzeichen Schleife 185

Salesforce 327

SanssouciDB 299

SAP 281

SAP S/4HANA 327

S-BPM 20

Schatten-IT 313, 317

Schema 348

Schemaänderung 343

Schemafreiheit 349

Schlussereignis

Beispiel 184

Schwachstelle 102

Schwachstelle der Reifegradmodelle 84

SCM 293

SCOR-Modell 258

sekundäre Geschäftsprozesse

Definition 49

Semantik

ODER 228

Semantik sucht Syntax 174

Bedingungen 201

Erläuterung 165

Kombinatorik 204

Kombinatorik mit UND 131

'mindestens' mit ODER 131

mit UND 135

semantische Auszeichnungssprache 271

semantische Prozessintegration 271

Semantische Prozessintegration

Definition 41

semi-formale Methode 115

semistrukturiert

Definition 37

semistrukturierte Probleme 37

Sender-Aufgabe

Beispiel 176

sequentielle Grundstruktur (bei Geschäftsprozessen) 32

Sequenzdiagramme 160

Sequenzen 110

Sequenzfluss 32

Serverfarmen 296

service provider 290

Serviceorientierte Architektur 290, 291

Beschreibung 289

Serviceprozess 256

Services 270

Servicetrace 327

Signal-Startereignis 179

Signal-Zwischenereignis, empfangend

Beispiel 176

Simulation 59

Skalierbarkeit 296, 345

SMART 72

Smartphone 340

SOA 291

Social Bots 316

Social Business Process Management 20

Soft State 348

Softwareentwicklung 59, 102

Softwareroboter 311

Sollmodellierung

Definition 61

Soll-Prozess 15

Soll-Prozesse 104

spaltenorientierte Datenbanken

Def 364

spaltenorientierte Datenbanksysteme 364

Spam 316

Speichertechniken

neue im Internet 336

Stammdatenkrise 42

Standardisierbarkeit 33

Standardprozessmodellierung 57, 104, 105, 106, 108, 109, 159, 161, 162, 163, 287, 309

Definition 105, 160

Geschäftsobjekte 160

zeitliche Dimension 110

Standardsoftware 49, 246, 276

nicht prozessorientierte 246

Startereignis 172, 217

Startereignisse

Beispiel 200

Stellen 23, 33

Steuerungskennzahlen 78

Steuerungsprozesse 49

Störungskennzahlen 78

Strategieplanungsprozess 257

strategische Erfolgsfaktoren 52

strategische Prozessplanung 66, 74

Strategisches Geschäftsprozessmanagement 63

Strategisches Management 63

strategisches Prozesscontrolling 71

strukturierte Daten 336

Subjektivität 3

Zielsetzung 57

subjektorientierte Prozessmodelle 263

Subprozess im Sequenzfluss 182

Supply Chain 258

Supply Chain Management 276, 293

Supply Chain Operations Reference-Modell 258

Supportprozesse 45, 296

Aufwand 72

SW-Referenzmodelle 104

Syntax 116

Syntax vs. Semantik 228

Syntaxregel

E - F - E - ... 124

ODER nach Ereignis 233

XODER nach Ereignis 233

Zusammenführen Kontrollflüsse 238

Zusammenführen nur durch Operatoren 122

tabellarische Beschreibung von Geschäftsprozessen

Beschreibung 58

Tätigkeit

Begriff 105

Tätigkeitsfolge

Begriff 105

Teilaufgaben 178

Terabyte 338

Token-Konzept 187

Trend

Automatisierung 302

detailliertere Abbildung von Geschäftsprozessen 265, 302

zu vollständig automatisierten Geschäftsprozessen 266

Trojaner 315

Typ-I-GeschäftsGeschäftsprozesseprozess 50

Überblicksnotationen 104

Übersichtsnotationen 159

Überwindung der Abteilungsgrenzen 24

Überwindung der Lücke 279

Überwindung von Organisationsgrenzen 33

UDDI 290

UDDI-Verzeichnis 290

Umwelt des Unternehmens 199

Unabhängige Ereignisse

Definition 229

Unabhängigkeit

von Ereignissen beim ODER 227

UND

Anhalten Kontrollfluss 200

Beispiel 221, 224, 229, 235

Ereignis startet mehrere Funktionen 229

mit auslösendem Ereignis 229

Teilaufgaben 224

Universal-Description-Discovery-and-Integration - Verzeichnis 290

unstrukturiert

Definition 37

unstrukturierte Daten 337

unstrukturierte Probleme

Beispiel 50

unstrukturiertes Problem

Beispiel 50

Unternehmensprozessmodelle 104

Unternehmenssoftware 246

Unternehmensziel 67

unterstützende Proezsse 45

Unterstützung oder Automatisierung 35

valuechain 378

Variety 345

Velocity 345

verbotene Struktur in EPK’s 231

Verdeckte Entscheidungen 177

Verklemmungen 346

verknüpfendes Exclusive Gateway (ereignisbasiert) für den Prozessstart 182

verknüpfendes Parallel Gateway (ereignisbasiert) für den Prozessstart 182

Verknüpfung über Ereignisse 172, 217

Verschmelzen von Unternehmen 55

Versionierung 349

Verstehen natürlicher Sprache 319

verteilte Systeme 345

Vertikale Ausdifferenzierung von Geschäftsprozessen 163

vertikale Dimension 163

vertikale Dimension der Prozessmodellierung 161

Vertikale Skalierbarkeit 345

Vertriebsprozess 255

Verzeichnisdienst 290

Verzweigungen 121

Volkswagen 297

Volume 345

von Neumann - Architektur 298

Vorausschauende Wartung 318

Vorgang 286

Definition 27

Vorgänge 116

Vorgangsbearbeitung 286

Vorgangskettendiagramm 252

vorgedachte Geschäftsprozesse 245, 276

Vorgedachte Geschäftsprozesse 54

Erläuterung 245

VW Industrial Cloud 297

Wartefunktion 122, 206

Ersatz 207

Warten in EPK’s 200

Webcrawler 315

WebService

Definition 290

Web-Service-Description-Language 290

WebServices 270

Werkzeuge für die Istmodellierung 58

Werte 358

Wertkette 48, 49

Wertschöpfung

Definition 378

Wertschöpfungskette 258

Aufbau 247

Definition 48, 378

Wertschöpfungskette von Porter 247

Wertschöpfungsketten 159

Wettbewerbsstrategie 52

Wettlaufsituationen 346

WfMC 289

wissensintensive Geschäftsprozesse 50

Wissensmanagement 59

wohlstrukturiert

Definition 37

Definition (Ergänzung) 308

wohlstrukturierte Probleme 167

Wohlstrukturiertheit 308

Wolke 274

Workflow

Definition 27, 286

Grundidee 287

Workflow Engine 288

Workflow-Management 286

Definition 286

Workflow-Management Coalition 289

Workflowmodellierer 20

WSDL 290

XML

Beschreibung 271

XODER

Beispiel 222, 225, 231

XODER und ODER kompakt 193

Zeitaspekt

Warten 206

Zeitfenster

Definition 189

Zeitgeber-Startereignis 179

Zeitgeber-Zwischenereignis 189

Beispiel 190

Zeitgeber-Zwischenereignis / empfangend

Beispiel 176

Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend 189

Beispiel 177

Zementierung 300, 310

Zertifizierung nach DIN ISO 9000ff 59

Zetabyte 338

Zielausmaß 72

Zieldimensionen 72

Zielinhalt 72

Zielsystem 67

Definition 66

Zielsystems 71

Zieltermin 72

Zugriffstechniken

neue im Internet 336

Zusammenarbeit 145

Zusammenführen Kontrollflusszweige

XODER 125

Zusammenführungen 121

Zustände 116

Zustandsautomaten 110

Zwecke der Prozessmodellierung

Gaitanides 103

Zwischenbetriebliche Informationssysteme 271

Zwischenereignis / empfangend

Beispiel 176

26 Literaturverzeichnis

A

Aalst 2016
Aalst, Wil van der: Process Mining. Data Science in Action. (2. Auflage) Berlin und Heidelberg 2011 (Springer)

Adam, Koch, Neffgen et al. 2014
Adam, Sebastian; Koch, Matthias; Neffgen, Fabian; Riegel, Norman und Weidenbach, Justine: Business Process Management - Marktanalyse 2014, BPM Suites im Test, Fraunhofer IESE, Kaiserslautern 2014

Allweyer 2009
Allweyer, T.: BPMN 2.0 Business Process Model and Notation (2. Ausg.). Norderstedt: Books on Demand GmbH.

Alpar, Alt, Bensberg u.a. 2014
Alpar, Paul; Alt, Rainer; Bensberg, Frank; Grob, Heinz Lothar; Weimann, Peter; Winter, Robert: Anwendungs­orientierte Wirtschaftsinformatik. Strategische Planung, Entwicklung und Nutzung von Informationssystemen. (7. Auflage). Wiesbaden 2014 (E-Book)

B

Bayer 2018
Bayer, Martin: Softwareroboter übernehmen immer mehr Prozesse. In: Computerwoche 2018, 27-29, S. 18 - 19.

Bayer 2019a
Bayer Martin: Process Mining verspricht Durchblick im Prozessdschungel. In: Computerwoche 2019, 19-20, S. 14-17.

Bayer 2019b
Bayer, Martin: Volkswagen will mit Amazon-Hilfe seine Produktivität verbessern. In: Computerwoche 2019, 14-15.

Bayer 2019c
Bayer, Martin: ERP auf dem Weg zum digitalen Prozess- und Daten-Hub. In Computerwoche 2019, 34-35, S. 14-17

Bayer 2019d
Bayer, Martin: SAP S/4HANA – viele Anwender machen sich auf den Weg. In: Computerwoche 2019, 32-33, S. 14-19

Bayer 2019e
Bayer, Martin: Artifial Intelligence, Machine und Deep Learning – das sind die Unterschiede. In: Computerwoche 2019, 16-18, S. 14-17

Becker und Kahn 2012
Becker, Jörg; Kahn, Dieter: Der Prozess im Fokus. In: [Becker, Kugeler und Rosemann 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: [Becker, Kugeler und Rosemann 2012, S. 17 - 45]

Becker, Kugeler und Rosemann (Hrsg.) 2012
Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung (7. Aufl.), Berlin u.a. 2012

Berndt 1997
Berndt, Ralph (Hrsg.): Business Reengineering. Effizientes Neugestalten von Geschä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 empirical assessment of the EFQM Excellence Model: Evaluation as a TQM framework relative to the MBNQA Model. In: Journal of Operations Management 27 (1), 2009, S. 1–22.

Brahm und Pargmann 2003
Brahm, M. und Pargmann, H.: Workflow-Management mit SAP® WebFlow® - Das Handbuch für die Praxis. Berlin Heidelberg: Springer-Verlag.

Bremmer 2018a
Bremmer, Manfred: Robotic Process Automation bei der Telekom. In: Computerwoche 2018, 36-37, S. 36-37.

Bremmer 2018b
Bremmer, Manfred: Robotic Process Automation – Erfahrungen und Best Practices. In: Computerwoche 2018, 42 – 43, S. 24 – 25. Bericht vom Scheer Digital World Congress 2018.

Bremmer 2018c
Bremmer, Manfred: Robotic Process Automation wird zur Einstiegstechnologie. In: Computerwoche 2018, 27-29, S. 14-16.

Bremmer 2019a
Bremmer, Manfred: Wenige Anbieter dominieren den jungen RPA-Markt. In: Computerwoche 2019, 34-35, S. 22-25.

Brenner und Hamm 1995
Brenner, Walter; Hamm, V.: Prinzipien des Business Reengineering, in: [Brenner und Keller 1995, S. 17 – 43]

Brenner und Keller 1995
Brenner, Walter; Keller, Gerhard (Hrsg.): Business Reengineering mit Standardsoftware. Frankfurt 1995

Brucker-Kley, Kykalová und Keller (Hrsg.) 2018
Brucker-Kley, Elke; Kykalová, Denisa und Keller, Thomas (Hrsg.): Prozessintelligenz. Business-Process-Management-Studie – Status quo und Erfolgsmuster. Berlin 2018 (Springer Nature)

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

C

Chen und Scheer 1994
Chen, R.; Scheer, A.-W.: Modellierung von Prozessketten mittels Petri-Netz-Theorie. Technischer Bericht 107, Institut für Wirtschaftsinformatik an der Universität des Saarlandes, Saarbrücken, Februar 1994

D

Davenport 1993
Davenport, Thomas: Process innovation. Reengineering work through information technology. Boston (Mass.) 1993.

Diestel 2017
Diestel, Reinhard: Graphentheorie (5. Auflage). Heidelberg 2017

Dose 2019
Dose, Jens: Machine Learning – die besten Tools für TensoFlow. In: Computerwoche 2019, 32-33, S. 22-23]

E

Edlich, Friedland, Hampe u.a. 2011
Edlich, Stefan; Friedland, Achim; Hampe, Jens; Brauer, Benjamin und Brückner, Markus: NoSQL. Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken (2. Auflage). München 2011 (Hanser)

Ertel 2016
Ertel, Wolfgang: Grundkurs Künstliche Intelligenz. Eine praxisorientierte Einführung (4. Auflage). Wiesbaden 2016

F

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 )

Fondermann, Spichale und George 2014
Fondermann, Bernd; Spichale, Kai und George, Lars: BigData. Apache Hadoop. E-Book 2014

Franke und Dangelmaier 2006
Franke, W. und Dangelmaier, W.: RFID - Leitfaden für die Logistik - Anwendungsgebiete. Einsatzmöglichkeiten. Integration. Praxisbeispiele. Wiesbaden 2006.

Franz 1996
Franz, Klaus-Peter: Prozesskostenmanagement für ein strategisches Aktivitätencontrolling, in [Perlitz u.a. 1996], S. 210 – 220

Freund 2019
Freund, Jacob: Zementiert RPA veraltete IT-Systeme und Strukturen? In: Computerwoche 2019, 30 - 31, S. 20 - 21.

Freund und Götzer 2008
Freund, J. und Götzer, K.: Vom Geschäftsprozess zum Workflow - Ein Leitfaden für die Praxis. München 2008

Freund und Rücker 2017
Freund, Jakob; Rücker, Bernd: Praxishandbuch BPMN 2.0. Mit Einführung in CMMN und DMN. (5. Auflage). München 2017

G

Gadatsch 2013a
Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management, Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 7. Aufl. Springer, Wiesbaden 2013 (E-Book)

Gadatsch 2013b
Gadatsch, A., Mayer, E.: Masterkurs IT-Controlling, 5. Aufl. Springer, Wiesbaden 2013

Gadatsch 2015
Gadatsch, Andreas: Geschäftsprozesse analysieren und optimieren. Praxistools zur Analyse, Optimierung und Controlling von Arbeitsabläufen. Wiesbaden 2015 (E-Book)

Gadatsch, A. (2012).
Grundkurs Geschäftsprozessmanagement - Methoden und Werkzeuge für die IT-Praxis (7. Ausg.). Wiesbaden: Vieweg+Teubner-Verlag.

Gaitanides 2012
Gaitanides, Michael: Prozessorganisation. Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen (3. Aufl.), München 2012 (E-Book)

Gaitanides et al. 1994
Gaitanides, Michael; Scholz, Rainer; Vrohlings, Alwin; Raster, Max: Prozeßmanagement: Konzepte, Umsetzungen und Erfahrugnen des Reendineerings. München 1994

Galler 1997
Galler, J.: Vom Geschäftsprozeßmodell zum Workflow-Modell. Wiesbaden 1997

Giedion 1982
Giedion, Sigfried: Die Herrschaft der Mechanisierung. Ein Beitrag zur anonymen Geschichte. Frankfurt 1982

Grivas 2020
Grivas, Stella Gatziu (Hrsg.): Digital Business Development. Die Auswirkungen der Digitalisierung auf Geschäftsmodelle und Märkte. Berlin 2020

Gull 2011
Gull, Clemens: Web-Applikationen entwickeln mit NoSQL. Haar 2011 (Franzis)

H

Haisermann und Rückershäuser 2019
Haisermann, Alexa und Rückershäuser, Peter: Actbots automatisieren Standardtransaktionen. In: Computerwoche 2019, 12-13, S. 34-36.

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.

Hansen und Neumann 2009
Hansen, Hans Robert; Neuman, Gustaf: Wirtschaftsinformatik I. Grundlagen betrieblicher Informationsverarbeitung, (10. Auflage), Stuttgart 2009.

Harrison 2016
Harrison, Guy: Next Generation Databases. NoSQL, NewSQL, and BigData, New York 2016 (E-Book)

Heinrich und Lehner 2005 Heinrich, Lutz; Lehner, Franz : Informationsmanagement. Planung, Überwachung und Steuerung der Informationsinfrastruktur, 8. Auflage, München und Wien 2005.

Heinrich, Linke, und Glo#776;ckler 2015
Heinrich, B.; Linke, P. und Glo#776;ckler, M.: Grundlagen Automatisierung. Wiesbaden: Springer Vieweg-Verlag 2015

Herrmann 2016
Herrmann, Wolfgang: Digitalisierung bringt die IT in Zugzwang. In: Computerwoche 2016, 11-13, S. 22 – 27

Herrmann 2017
Herrmann, Wolfgang: Softwareroboter und KI treiben die Digitalisierung. In: Computerwoche 2017, 40-42, S. 20 - 21

Hess 1996
Hess, Thomas: Entwurf betrieblicher Prozesse. Grundlagen – Bestehende Methoden – 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. Prozessorientierung als Erfolgskonzept. Köln u.a. 1999

K

Kastens und Kleine Büning 2008
Kastens, Uwe und Kleine Büning, Hans: Modellierung. Grundlagen und formale Methoden (2. Auflage). Bonn 2008 (Hanser)

Kaufmann und Servatius 2020
Kaufmann, Timothy; Servatius, Hans-Gerd: Das Internet der Dinge und Künstliche Intelligenz als Game Changer. Wege zu einem Management 4.0 und einer digitalen Architektur. Wiesbaden 2020

Keller und Teufel 1997
Keller, Gerhard; Teufel, Thomas: SAP R/3 prozessorientiert anwenden. Iteratives 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 Instituts für Wirtschaftsinformatik (Iwi), Universität des Saarlandes, Heft 89, Januar 1992

Klasen 2019
Klasen, Jörg: Business Transformation. Praxisorientierter Leitfaden zur erfolgreichen Neuausrichtung von Unternehmen und Geschäftsfeldern. Wiesbaden 2019

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 Aufbauorganisation. In: Becker, Jörg; Kugeler, Martin, Rosemann, Michael (Hrsg.), Prozessmanagement, 5. Auflage, Berlin 2004, S. 229-276.

Kütz 2011 Kütz, Martin: Kennzahlen in der IT. Werkzeuge für Controlling und Management (4. Auflage). Heidelberg 2011

Kurowski 2012
Kurowski, Oliver: NoSQL Einführung. CouchDB, MongoDB und Redis. E-Book 2012

L

Lange 2013
Lange, Barbara: Alles autonom. Die Produktion steuert sich selbst. In: iX Heft 7/2013, S. 108 – 114

Langner, Schneider und Wehler 1997
Langner, P.; Schneider, C.; Wehler, J.: Prozessmodellierung mit Ereignisgesteuerten Prozessketten (EPKs) und Petri-Netzen. In: Wirtschaftsinformatik, 39(5), S. 479-489, Oktober 1997

Laudon, Laudon und Schoder 2010
Laudon, Kenneth C., Laudon, Jane P., Schoder, Detlef: Wirtschaftsinformatik. Eine Einführung (2. Auflage). München 2010

M

Matt, Modrák und Zsifkovits 2020
Matt, Dominik T.; Modrák, Vladimír und Zsifkovits, Helmut: Industry 4.0 for SMEs. Challenges, Opportunities and Requirements. Cham (Schweiz) 2020

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 Wirtschaftsinformatik (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

Mohr 2020
Mohr, Thomas: Der Digital Navigator. Ein Modell für die digitale Transformation. Wiesbaden 2020

Müller und Rupper 1994
Müller, Roland; Rupper, Peter (Hrsg.): Process Reengineering. Prozesse optimieren und auf den Kunden ausrichten. Zürich 1994

Müller, J. (2005).
Workflow-based Integration. Berlin Heidelberg: Springer-Verlag.

N

Nordsieck 1932
Nordsieck, Fritz: Die schaubildliche Erfassung und Untersuchung der Betriebsorganisation. Stuttgart 1932

Nordsieck 1934
Nordsieck, Fritz: Grundlagen der Organisationslehre. Stuttgart 1934

O

Obermeier u.a. 2014
Obermeier, S., Fischer, H., Fleischmann, A. und Dirndorfer, M. (2014): Geschäftsprozesse realisieren - Ein praxisorientierter Leitfaden von der Strategie bis zur Implementierung (2. Auflage). Wiesbaden 2014

Oberweis 1996
Oberweis, Andreas: Modellierung und Ausführung von Workflows mit Petri-Netzen. Stuttgart und Leipzig 1996

OMG 2009 Object Management Group (OMG): Business Process Modeling Notation (BPMN). Version 1.2 January 2009 (OMG Document Number: formal/2009-01-03. Standard document URL: http://www.omg.org/spec/BPMN/1.2)

OMG 2011 Object Management Group (OMG): Business Process Modeling Notation (BPMN). Version 2.0 January 2011 (OMG Document Number: formal/2011-01-03. Standard document URL: http://www.omg.org/spec/BPMN/2.0)

Österle 1995
Österle, Hubert: Business Engineering. Prozess- und Systementwicklung. Band 1: Entwurfstechniken, Berlin u.a. 1995

P

Perkins, Redmond und Wilson 2018
Perkins, Luc; Redmond, Eric; Wilson, Jim R.: Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement ) (2. Auflage). Raleigh 2018

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

Plattner 2013
Plattner, Hasso: Lehrbuch In-Memory Data Management. Wiesbaden 2013

Plattner und Zeier 2011
Plattner, Hasso und Zeier, Alexander: In-Memory Data Management. An Inflection Point for Enterprise Applications. Berlin, Heidelberg 2011

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 behaupten (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 behaupten. (5. Auflage). Frankfurt 1999.

R

Reder 2019a
Reder, Bernd: Process Mining und Automatisierung sind Schlüsselelemente der Digitalisierung. In: Computerwoche 2019, 30-31, S. 14-17.

Reder 2019b
Reder, Bernd: Warum der Einsatz von Machine Learning noch nicht optimal ist. In: Computerwoche 2019, 16-18, S. 18-20.

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]

Rother 2018
Rother, Tobias: Process Mining ist das Bindeglied zwischen BPM und Business Intelligence. In: Computerwoche 2018, 38-39, S. 36-37.

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]

S

Safar 2018
Safar, Milad: Erfolgsmessung bei Robotic Process Automation. In: Computerwoche 2018, 34-35, S. 28 – 29

Safar 2019
Safar, Milad: Wenn der Bot selbst entscheidet. In: Computerwoche 2019, 30 - 31, S. 18 – 19

Scheer 1997
Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. (7. Auflage), Berlin u.a. 1997

Scheer 1998a
Scheer, August-Wilhelm: ARIS – vom Geschäftsprozess zum Anwendungssystem (3. Auflage), Berlin u.a.1998

Scheer 1998b
Scheer, August-Wilhelm: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen (3. Auflage), Berlin u.a.1998

Scheer 2020
Scheer, August-Wilhelm: Unternehmung 4.0. Vom disruptiven Geschäftsmodell zur Automatisierung der Geschäftsprozesse, 3. Auflage, Wiesbaden 2020

Scheer, Nüttgens und Zimmermann 1995
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äftsprozessmanagement in der Praxis. Kunden zufriedenstellen, Produktivität steigern, Wert erhöhen (8. Auflage). München 2013.

Schneck 1998
Schneck, Ottmar: Lexikon der Betriebswirtschaft (3. Auflage). München 1998

Schrempp 2012
Schrempp, Mirko (Hrsg): BigData - Technologiegrundlagen. E-Book 2012

Schwegmann und Laske 2012
Schwegmann, Ansgar; Laske, Michael: Istmodellierung und Istanalyse. In: [Becker, Kugeler und Rosemann 2012, S. 165 - 194]

Scor 2005
Supply Chain Council: Supply Chain Operations Reference Model, SCC 2005.

Simon 1957
Simon, H. A.: Models of Man, New York 1957.

Stähler 2017
Stähler, Dirk: Prozess- und IT-Modellierung – ArchiMate, BPMN, Datenmodellen un EPK verbinden. In: Computerwoche 2017, 21-22, S. 32-34.

Stahlknecht und Hasenkamp 2005
Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik. (11. Auflage), Berlin u.a. 2005

Staud

Staud 1991
Staud, Josef L.: Online Datenbanken. Aufbau, Struktur, Abfragen. Bonn u.a. 1991 (Addison-Wesley Publishing Company)

Staud 1983
Staud, Josef L.: Internationale Arbeitsteilung und Nationales Lohnniveau. Bedeutung und Rolle entwickelter Ökonomien im Geflecht der Welthandelsbeziehungen. Band I. Frankfurt u.a. 1983 (Dissertation)

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 (1. Auflage). 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 2015
Staud, Josef: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. Vilshofen 2015. ISBN 978-3-9817175-1-8. Auch als E-Book

Staud 2017
Staud, Josef Ludwig: Geschäftsprozesse und ihre Modellierung mit der Methode Business Process Model and Notation (BPMN 2.0), Hamburg 2017 (tredition)
Als Hardcover, Softcover, E-Book

Staud 2019
Staud, Josef: Unternehmensmodellierung – Objektorientierte Theorie und Praxis mit UML 2.5 (2. Auflage). Berlin u.a. 2019 (Springer Gabler)

Stocker 2020
Stocker, Florian: Diskussion: Ist RPA eine Übergangstechnologie oder mehr? In: Computerwoche 2020, 12-14, S. 34f.

T

Ternès und Englert (Hrsg.) 2019
Ternès, Anabel; Englert, Marco (Hrsg.): Digitale Unternehmensführung. Kommunikationsstrategien für ein exzellentes Management. Wiesbaden 2019.

Trelle 2014
Trelle, Tobias: MongoDB. Der praktische Einstieg. Heidelberg 2014

Tummala und Tang 1994
Tummala, Rao; Tang, Catherine: Strategie Quality Management, Malcolm Baldrige and European Quality Awards and ISO 9000 Certification: Core Concepts and Comparative Analysis. Hong Kong 1994.

U

Urbach und Ahlemann 2016
Urbach, Nils; Ahlemann, Frederik: IT-Management im Zeitalter der Digitalisierung. Auf dem Weg zur IT-Organisation der Zukunft, Berlin et al. 2016

V

Völkl 2018a
Völkl, Gerhard: Wie Programme lernen. Python-Tutorial, Teil 1: Maschinelles Lernen mit TensorFlow. In: iX kompakt 2018 – Programmieren heute, S. 8 - 16

Völkl 2018b
Völkl, Gerhard: Zeichenerkennung. Python-Tutorial, Teil 2: Neuronale Netze und Deep Learning. In: iX kompakt 2018 – Programmieren heute, S. 18 - 25

Völkl 2018c
Völkl, Gerhard: Ich sehe was, … Python-Tutorial, Teil 3: Neuronale Netze anwenden. In: iX kompakt 2018 – Programmieren heute, S. 26 - 31

Vossen und Becker 1996
Vossen, Gottfried; Becker, Jörg (Hrsg.): Geschäftsprozessmodellierung und Workflow-Management. Modelle, Methoden, Werkzeuge. Bonn u.a. 1996

W

Wartala, Ramon
Hadoop. Zuverlässige, verteilte und skalierbare Big-Data-Anwendungen. München 2012 (Open Source Press)

Weißenberg und Stemmer 2009
Weißenberg, Norbert und Stemmer, Michael: Moderne IT-Plattformen für Geschäftsprozessmanagement und Portale. Vergleichende Bewertung der Toolsuiten von IBM, IDS Scheer amp; SAP, sowie INTALIO amp; 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)

Welkenbach und Schmutz 2012
Welkenbach, Peter und Schmutz, Guido: Relationale, NoSQL- und NewSQL-Datenbanken. In [Schrempp 2012 (E-Book)]

Wöhe 1993
Wöhe, Günter: Einführung in die Allgemeine Betriebswirtschaftslehre (unter Mitarbeit von Ulrich Döring), München 1993

Wolff et al. 2013
Wolff, Eberhard; Hunger, Michael; Spichale, Kai und George, Lars: NoSQL-Überblick. Neo4j, Apache Cassandra und HBase. E-Book 2013

Wolff, Hunger, Spichale und George 2013
Wolff, Eberhard; Hunger, Michael; Sichale, Kai und George, Lars : NoSQL-Überblick. Neo4j, Apache Cassandra und HBase. E-Book 2013 (entwickler.press)

Wolff, Nitschinger und Trelle 2014
Wolff, Eberhard; Nitschinger, Michael und Trelle, Tobias: NoSQL-Überblick. Couchbase, Riak, MongoDB E-Book 2014 (entwickler.press)

Wongrassamee et al. 2003
Wongrassamee, Somchai; Simmons, John; Gardiner, Paul: Performance measurement tools: the Balanced Scorecard and the EFQM Excellence Model. In: Measuring Business Excellence 7 (1), 2003, S. 14–29.

Z

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