Ganzheitliche Digitalisierung von Prozessen: Perspektivenwechsel - Design Thinking - Wertegeleitete Interaktion [2. Auflage ed.] 3658417765, 9783658417765, 9783658417772

Citation preview

Matthes Elstermann · Albert Fleischmann · Christoph Moser · Stefan Oppl · Werner Schmidt · Christian Stary

Ganzheitliche Digitalisierung von Prozessen Perspektivenwechsel - Design Thinking Wertegeleitete Interaktion 2. Auflage

Ganzheitliche Digitalisierung von Prozessen

Matthes Elstermann • Albert Fleischmann • Christoph Moser • Stefan Oppl • Werner Schmidt • Christian Stary

Ganzheitliche Digitalisierung von Prozessen Perspektivenwechsel – Design Thinking – Wertegeleitete Interaktion 2. Auflage

Matthes Elstermann Karlsruhe Institut für Technologie – Karlsruhe, Deutschland

Albert Fleischmann InterAktiv Unternehmensberatung Pfaffenhofen, Deutschland

Christoph Moser Doka GmbH Amstetten, Austria

Stefan Oppl Universität für Weiterbildung Krems Krems, Österreich

Werner Schmidt Technische Hochschule Ingolstadt Ingolstadt, Deutschland

Christian Stary Johannes Kepler Universität Linz Linz, Österreich

ISBN 978-3-658-41776-5 ISBN 978-3-658-41777-2 (eBook) https://doi.org/10.1007/978-3-658-41777-2 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über https://portal.dnb.de abrufbar. © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018, 2023 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Petra Steinmüller Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany Das Papier dieses Produkts ist recyclebar.

Vorwort

Die weitere Auflage dieses Buchs macht uns Autoren nicht nur stolz, ob der bislang wahrgenommenen Rezeption der Inhalte – gemäß unserem Leitspruch der ursprünglichen Auflage Die wichtigsten Innovationen sind jene, die das Denken verändern – sie hat uns auch zum Nachdenken angeregt, in welcher Form wir relevante Entwicklungen der letzten Jahre zur ganzheitlichen Prozessgestaltung bei Digitalisierungsvorhaben einbringen können. Wir haben diese Entwicklungen in die zweite Auflage im Sinne theoriegeleiteter Praxis eingebracht, indem wir exemplarisch Handlungsfelder kommunikationsorientierter Gestaltungsarbeit durch Fallminiaturen erschließen. An Beispielen innovativer industrieller Handlungspraxis sowie integrativer künstlicher Intelligenzalgorithmen und sozialer Verhaltensmodelle können wir so die Vorteile modelltechnischer Abstimmung von Funktionalität und Interaktion im Prozessmanagement zeigen. Die Basis stellt ein leicht verständlicher, standardisierter Sprachschatz zur Erfassung und Spezifikation von Verhalten dar, der nicht nur zur Reduktion von Komplexität, sondern auch zur verbesserten Verständlichkeit und Ausführbarkeit von sozialen, organisationalen und technisch relevanten Sachverhalten beiträgt. Damit lassen sich mehrfach Brücken schaffen, welche digitale Transformationsprozesse erleichtern, etwa zwischen Industrie 4.0 und Industrie 5.0, zwischen physischen und digitalen Zwillingen, der Gestaltung und der technischen Umsetzung sozio-technischer Systeme, sowie zwischen natürlicher und künstlicher Intelligenz – Brücken, die im kommenden Zeitalter des Metaverse und Transhumanismus helfen können, neue Formen der Digitale Divide zu vermeiden. Bei allen Darstellungen haben wir uns erneut an den Aphorismen von Hans-Jürgen Quadbeck-Seeger orientiert: • Verständlichkeit ist die Höflichkeit eines Experten. Unser Werk soll alle an der ganzheitlichen Digitalisierung von Prozessen Interessierte begeistern. Daher muss es verständlich sein.

V

VI

Vorwort

• Luxus: Kult um das Unnötige. Wir wollen alle jene ansprechen, die das Wesen von Prozessen und ihre Nutzbarkeit im praktischen Tun begreifen wollen, ohne intensive Sprach- und Gebrauchsstudien, vielmehr mit praxistauglichen Konzepten unterfüttert. Studierende mögen den Textbuchcharakter des Buchs schätzen, PraktikerInnen die Beispiele, ForscherInnen und EntwicklerInnen die Konzeptdarstellungen und Theorieausflüge. • Je größer das Projekt, desto stiller wird es begraben. Seit mehr als einem Jahrzehnt gibt es das Konzept und auch das Projekt, Prozesse kommunikationsorientiert und damit systemisch zu denken. Es huldigt dabei Einfachheit und Überschaubarkeit, ohne komplexe Zusammenhänge zu vernachlässigen. Die Treiber des Projekts verspüren steten Aufbruch, und haben sich, wie anhand der Anzahl von Autoren ersichtlich, vermehrt. Es ist also Zeit, die Digitalisierung von Prozessen aus der Brille der Verhaltensorientierung anzureichern und die vornehmliche datenorientierte Praxis mit wertebasiertem Informationsaustausch abzugleichen. • Abenteuertouristen zieht es zu Orten, wo sie nichts zu suchen haben. Der Blick in Richtung Verhaltensorientierung lohnt sich, da sich eine Sicht auftut, die nahe an unsere Wahrnehmung der Wirklichkeit kommt, Bestehendes schlüssig erweitert, und uns so neuen Handlungsspielraum verschafft. Auch unsere BegleiterInnen auf dem Weg zur Fertigstellung des Werks sind Abenteurer. Ihnen gebührt besonderer Dank – Ulrike Butz und Petra Steinmüller von Springer Vieweg und Ralf Gerstner von Springer für ihre Unterstützung seitens des Verlags zur Umsetzung unserer Ideen, sowie Jerome Geyer-Klingeberg von Celonis SE zur Verdeutlichung der Prozesspraxis. Innovationen sind keine Naturereignisse, wir müssen sie wollen und durchsetzen. In diesem Sinne wünschen wir erbauliche Lektüre, gelingende Handlungspraxos, und uns Feedback nach Ingolstadt, Karlsruhe, Krems, Linz und Pfaffenhofen an der Ilm. Karlsruhe, Deutschland Pfaffenhofen, Deutschland Amstetten, Austria Krems, Österreich Ingolstadt, Deutschland Linz, Österreich Februar 2023

Matthes Elstermann Albert Fleischmann Christoph Moser Stefan Oppl Werner Schmidt Christian Stary

Inhaltsverzeichnis

1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Geschäftsprozesse und Geschäftsprozessmanagement . . . . . . . . . . . . . . . . . . . . 1.2 Blick auf die Welt, Strukturierung und Modellbildung . . . . . . . . . . . . . . . . . . . . 1.3 Bestandteile einer Prozessbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Rahmenbedingungen für Prozessmodelle und Prozessinstanzen . . . . . . . . . 1.5 Prozesskennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Unterstützungskonzepte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Digitalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Prozess zum Erstellen von Prozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9 Organisatorische und technische Implementierung . . . . . . . . . . . . . . . . . . . . . . . . 1.10 Erfolgsmessung mit Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.11 Kontinuierliche Verbesserung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.12 Unternehmensführung und Geschäftsprozessmanagement. . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 3 5 6 7 8 10 11 13 14 14 15 17

2

Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Modell und Wirklichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Ablauf des systematischen Wissenserwerbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Eigenschaften von Modellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Modelle der Sozialwissenschaften. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Modelle der Betriebswirtschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Modelle der Wirtschaftsinformatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Modelle der Informatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Fazit: Modelle für Geschäftsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 19 20 23 25 30 38 48 65 68

3

Modellierungssprachen für Geschäftsprozesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Flussdiagramme: Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71 72 73

VII

VIII

Inhaltsverzeichnis

3.3 Ereignisgesteuerte Prozessketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.4 UML-Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.5 BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3.6 S-BPM und PASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.7 Vergleich und Gegenüberstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4

Gegenwärtige Herausforderungen im Geschftsprozessmanagement . . . . . . . . 4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur . . . . . . . . 4.2 Vom Prozessmodell zur Digitalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Einbeziehen von Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Einbeziehung von Künstlicher Intelligenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

135 135 152 157 173 177 191

5

Vorgehensweise von der Modellbildung zur Digitalisierung . . . . . . . . . . . . . . . . . . 5.1 Einordnung in den Gesamtzusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Aktivitätsbündel im Geschäftsprozessmanagement . . . . . . . . . . . . . . . . . . . . . . . 5.3 Einführung in Design Thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Verbindung der Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195 195 196 208 216 223

6

Vorbereitung der Prozessimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Analyse und Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Qualitätskontrolle: Validierung und Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

225 226 260 266

7

Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Prozessdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Verknupfung von Elementen der Unternehmensarchitektur: organisatorische und IT-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Betrieb und Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

269 270

Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Erfassungs- und Modellierungswerkzeuge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Validierungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Optimierungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 IT-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Werkzeuge für die organisatorische Implementierung . . . . . . . . . . . . . . . . . . . .

299 300 314 318 320 325

8

272 284 297

Inhaltsverzeichnis

9

10

IX

8.6 Werkzeuge für den Betrieb und das Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Zusammenwirken der Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Werkzeuge für das Management des Digitalisierungsprozesses . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327 329 331 334

Beispiele aus der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion von Durchlaufzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems . . . . . . . . . . . 9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System . . . . . . 9.4 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335 336 351 359 371 372

Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Über die Autoren

Matthes Elstermann entwickelt als Wirtschaftsingenieur Vorgehensweisen, Methoden und Werkzeuge zur kommunikationsorientierten Beschreibung von industriellen Prozesses und deren Optimierung. Albert Fleischmann ein über Jahrzehnte aktiver Projektmanager, akademischer Lehrer und Berater, der grundlegende Informatik-Konzepte für den effektiven unternehmerischen Einsatz querdenkt. Christoph Moser wendet als Projektmanager und Werksleiter allgemeine Managementund Geschäftsprozessmanagementmethoden zur Strukturierung und Verbesserung von Produktionsprozessen erfolgreich an. Stefan Oppl Wirtschaftsinformatiker und Bildungsforscher mit integrativem Methodenwissen aus Wissens- und Prozessmanagement sowie verteilter sozio-technischer Systementwicklung, deren Ausgangspunkt immer die beteiligten Stakeholder sind. Werner Schmidt anwendungsorientierter Wirtschaftsinformatiker mit ausgeprägtem Methodenwissen in den Bereichen Geschäftsprozessmanagement, IT-Management und wirtschaftlich orientierter Unternehmensentwicklung. Christian Stary Forscher im Bereich Lernunterstützung zur Reflexion und Gestaltung komplexer Prozesse, die sich durch kognitive, soziale und technische Merkmale begründen.

XI

1

Motivation

Geschäftsprozesse sind unerlässlich, um die Arbeit von Organisationen und die Zusammenarbeit zwischen ihnen zu beschreiben. Sie stellen den Bezugsgegenstand des Prozessmanagements dar und integrieren alle wesentlichen Elemente, um Anforderungen, welche an Organisationen gestellt werden nachvollziehbar und strukturiert zu bearbeiten. Alle Beteiligten wissen somit, in welcher Form ihre Aufgaben zu bewältigen sind. Jedoch ist auf Seiten der Stakeholder grundsätzlich Verständnis zu den heutigen Rahmenbedingungen der Geschäftswelt sowie zu Unternehmensstrukturen und deren Repräsentanten erforderlich.

1.1

Geschäftsprozesse und Geschäftsprozessmanagement

Es gibt keine Organisation ohne Prozesse. Wenn Menschen etwas gemeinsam tun wollen, benutzen sie dafür die notwendigen Hilfsmittel und stimmen entsprechend dem gewünschten Ergebnis ihre Tätigkeiten aufeinander ab. Da solche Tätigkeiten nicht nur von Menschen ausgeführt werden können, sondern auch von Automaten und Computern, müssen deren Aktivitäten in die Abstimmung ebenfalls einbezogen werden. Insbesondere in zumindest teilweise automatisierte Prozesse sind also verschiedene Typen von Handelnden involviert. Ausgelöst wird ein Prozess durch ein Ereignis, das seinen Ursprung innerhalb oder außerhalb der Organisation haben kann, wie etwa ein Dienstreiseantrag oder eine Kundenbestellung. Das abgestimmte und zielgerichtete Handeln als Reaktion auf ein solches Ereignis wird als Prozess bezeichnet. Handelt es sich bei der Organisation um ein Unternehmen spricht man von Geschäftsprozessen. Es gibt kein Unternehmen ohne Geschäftsprozesse. Es gibt nur Unterschiede welchen Reifegrad diese haben. Die Reaktionen einer Organisation auf bestimmte Geschäftsereig© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_1

1

2

1 Motivation

nisse können bei ihrem Auftreten immer von neuem abgestimmt werden oder es wird eine Vorgehensweise festgelegt, die dann in solchen Fällen immer wieder ausgeführt wird. Ereignisse der gleichen Art wie z. B. Bestellungen werden als Ereignisklasse bezeichnet. Eine vorab festgelegte Vorgehensweise für eine Ereignisklasse wird als Prozessmodell bezeichnet. Bei der Ausführung der im Modell festgelegten Tätigkeitsfolgen als Reaktion auf ein identifiziertes konkretes Ereignis, z. B. die Buchbestellung des Kunden Huber vom 20. Mai, handelt es sich um eine Prozessinstanz. Jedes Unternehmen hat unabhängig von seiner Art des Geschäfts bestimmte Standardprozesse, die aber unternehmensindividuell ausgestaltet und zugeschnitten sein können. So verfügt beispielsweise jedes Unternehmen über einen Order-to-Cash-Prozess, mit dem es auf Geschäftsereignisse vom Kundenauftrag bis zum Zahlungseingang reagiert und diese durch Buchungen dokumentiert. Umgekehrt wird ein Beschaffungsprozess existieren mit Bestellungen zur Befriedigung eigener Bedarfe, dem konkreten Bezug (z. B. Wareneingang und Einlagerung) sowie der Bezahlung der Kreditoren. Weitere Beispiele sind Prozesse für die Personalbeschaffung oder die Logistik. Eine gebräuchliche Klassifikation unterteilt Prozesse nach ihrem Charakter in Management-, Kern- und Supportprozesse. Die Einordnung ist unternehmensspezifisch und hängt u. a. von der Branche ab. Je klarer ein Unternehmen seine Geschäftsprozesse definiert und je konsequenter es diese im täglichen Geschehen umsetzt, umso leistungsfähiger ist es. Bei viele Unternehmen gründet ihre Wettbewerbsfähigkeit nicht (mehr) nur auf der Besonderheit ihrer Produkte, sondern auf der Güte der Geschäftsprozesse. Während beispielsweise das Geschäft eines Verlags in erster Linie durch seine Bücher bestimmt wird, bestimmt bei Amazon maßgeblich die Kundenerfahrung bei Suche, Auswahl, Kauf, Bezahlung, Lieferung und eventueller Rückgabe von Produkten, also der reibungslose, kundenzentrierte Prozess den Erfolg. Die Modelle für solche Prozesse sind laufend anzupassen oder komplett neu zu gestalten, weil sich die Reaktionen auf eine Ereignisklasse ändern können bzw. zusätzliche Reaktionen auf neue Ereignisklassen nötig werden. Die resultierenden Spezifikationen müssen außerdem in der Organisation und der IT-Infrastruktur umgesetzt werden, damit die Mitarbeiterinnen und Mitarbeiter im Tagesgeschäft Instanzen der Prozesse abarbeiten können. Dabei sind Rahmenbedingungen zu beachten wie die Effektivität, Effizienz und Compliance, also die Anforderungen, das gewünschte Ergebnis mit dem geringsten möglichen Ressourcenaufwand und unter Einhaltung gültiger externer und interner Regularien (z. B. Gesetze) zu liefern. Für die Erledigung dieser Aufgaben hat sich das Geschäftsprozessmanagement (Business Process Management, BPM) etabliert. Es bezeichnet einen integrierten Managementansatz für Analyse, Design, Optimierung, Implementierung, Steuerung, Überwachung und Weiterentwicklung der Management-, Kern- und Supportprozesse im Unternehmen. In technischer Hinsicht schließt es auch die IT-Unterstützung dieser Teilaufgaben durch Werkzeuge z. B. für die Modellierung oder Ausführung (z. B. Process Engines) oder umfassendere Business-Process-ManagementSysteme (BPMS) ein.

1.2 Blick auf die Welt, Strukturierung und Modellbildung

3

Im Geschäftsprozessmanagement wird als Ausschnitt der Wirklichkeit ein Unternehmen und sein unmittelbares Umfeld betrachtet. In diesem Ausschnitt der Welt wünscht jemand eine Leistung von anderen in Form eines physischen Produkts, eines Service oder einer Kombination aus beidem. Die Leistung soll entsprechend den Anforderungen erbracht werden, der Wunsch nach ihr ist das Geschäftsereignis, auf welches das Unternehmen nach seinen Vorstellungen im definierten Modell reagieren soll. Beim Geschäftsprozessmanagement gilt es also ein Modell der Leistungserstellung zu definieren und auf die Abwicklung von Geschäftsfällen anzuwenden. Dies bedeutet die Wirklichkeit gemäß Modell anzupassen, also betroffene Ausschnitte der Realität zu analysieren und diese Wirklichkeit zu verändern. Da diese Wirklichkeit und die angestrebten Veränderungen sehr komplex sind, werden im BPM mehrere Modellkonzepte aus der Sozialwissenschaften, der Betriebswirtschaft und der Informatik zusammengeführt und kombiniert. In den folgenden Abschnitten umreißen wir eine Gesamtsicht auf das Prozessmanagement und erläutern diese dann in den weiteren Kapiteln detailliert. Ausgehend vom Blick der Beteiligten auf die Welt werden die vielfältigen Facetten des Geschäftsprozessmanagements dargestellt und eine Auswahl von Modellen vorgestellt, die sich dabei in unserer Praxis bewährt haben. Die Gestaltung solcher Modelle unterstützt den Weg von einer mehr oder weniger unstrukturierten oder unbefriedigenden Arbeitsweise zu einer Prozessabwicklung wie sie den Vorstellungen des Unternehmens und seiner Kunden entspricht. Die überblicksartige Gesamtsicht entwickeln wir schrittweise, ausgehend von individuellen Perspektiven der Beteiligten auf ihre Arbeit in einem Prozess, deren Strukturierung und Harmonisierung über die Spezifikation in einem Modell und dessen Einbettung in die organisatorische und IT-Umgebung des Unternehmens bis hin zur gemeinsamen Bearbeitung von Prozessinstanzen in den dadurch entstehenden soziotechnischen Systemen . Eine entsprechend mitwachsende Abbildung zeigt am Ende unser umfassendes Verständnis des Geschäftsprozessmanagements.

1.2

Blick auf die Welt, Strukturierung und Modellbildung

Wie schon erwähnt gilt es für ein Unternehmen die interessierenden Geschäftsereignisse zu identifizieren und die dadurch ausgelösten Tätigkeiten zu definieren. Dazu ist der entsprechende Ausschnitt der Wirklichkeit zu identifizieren und genauer zu betrachten. Der Ausschnitt wird bestimmt durch die Kunden, die eine Leistung fordern, und bildet für die an der Leistungserbringung beteiligte Gruppe von Mitarbeitern des Unternehmens die sie unmittelbar betreffende und umgebende Wirklichkeit. Zum Erbringen der gewünschten Leistung müssen die Beteiligten direkt oder indirekt zusammenwirken. Jeder leistet dabei in Abstimmung mit den anderen seinen Beitrag. Basierend auf seinem persönlichen Hintergrund bezüglich Ausbildung, Wissen, Wollen (Motivation),

4

1 Motivation

Weltsicht

Mentale Weltmodelle Wissen und Wollen

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.1 Individuelle mentale Modelle der Beteiligten

Erfahrungen und Vorlieben hat jedes Gruppenmitglied eine eigene Wahrnehmung des Prozesses und seines Kontextes. Es entwickelt seine individuelle Vorstellung, was sein Beitrag sein soll, wie er erbracht wird, welche Ereignisse mit welchen Tätigkeiten und vom wem zu berücksichtigen sind, in welcher Reihenfolge Teilschritte stattfinden, von wem welche Vorleistungen erwartet und für wen welche Vorleistungen erbracht werden. Folglich besitzen alle Betroffenen ihr eigenes mentales „Weltmodell“ des betrachteten Wirklichkeitsausschnitts (vgl. Abb. 1.1). Für die erfolgreiche Reaktion auf Geschäftsereignisse gilt es, die unterschiedlichen Wirklichkeiten der Beteiligten zu strukturieren und in ein konsistentes Prozessmodell für ein gemeinsames zielgerichtetes Tun zu überführen. Das heißt, der Geschäftsprozess wird „verabredet“, in dem die einzelnen, mehr oder weniger gut zusammenpassenden mentalen Modelle der involvierten Personen harmonisiert werden. Dieses Zusammenführen der individuellen Vorstellungen der von einem Geschäftsprozess Betroffenen und die wechselseitige Abstimmung der verschiedenen Aspekte eines Geschäftsprozesses (vgl. Abschn. 1.3) ist selbst ein komplexer Prozess und zentraler Aspekt des Geschäftsprozessmanagements.

1.3 Bestandteile einer Prozessbeschreibung

1.3

5

Bestandteile einer Prozessbeschreibung

Wir teilen eine Geschäftsprozessbeschreibung gedanklich in drei Abschnitte (vgl. Abb. 1.2). Der erste als Prozessstrategie bezeichnete Teil macht Aussagen zu Zweck, Auslöser, Inputs, Ende und Outputs des Vorgangs. Auslöser ist das Ereignis, das die Leistungserbringung auf Basis der Erwartungen des Initiators in Gang setzt, also eine Prozessinstanz erzeugt. Mit diesem Anstoß geht einher, dass der Initiator Informationen oder Gegenstände bereitstellt, welche entsprechend seiner Erwartungen bearbeitet werden sollen. Diese Inputs gilt es in die erwarteten Ergebnisse zu transformieren und diese dem definierten Empfänger zur Verfügung zu stellen. Damit schafft der Geschäftsprozess einen Wert, für den ein (externer) Kunde bezahlt. Diese Außensicht eines Geschäftsprozesses wird ergänzt durch die Prozesslogik. Diese innere Perspektive beschreibt die involvierten Handelnden und deren abgestimmtes Zusammenwirken. Die Akteure führen Aktivitäten in einer sachlogisch und zeitlich sinnvollen Reihenfolge aus. Die Ergebnisse ihrer Aktionen übergeben sie zur Weiterbearbeitung an andere Handelnde bzw. am Ende an den vorgesehenen Empfänger. Bei der Prozessrealisierung geht es um die Bereitstellung der Ressourcen für die Abarbeitung von Prozessinstanzen. Dies können Menschen, Maschinen und Softwaresys-

Bestandteile einer Prozessbeschreibung „ Prozessstrategie: Ein Prozess hat „ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „

Weltsicht

„ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert

Mentale Weltmodelle

„ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Wissen und Wollen

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.2 Bestandteile einer Prozessbeschreibung

6

1 Motivation

teme sein, welche als konkrete Realisierungen der involvierten Handelnden die diesen zugeordneten Aktivitäten übernehmen. Im Zeitalter der Digitalisierung synchronisieren Softwaresysteme (Process oder Workflow Engines) die Aktionen der Handelnden durch Steuerung der zeitlichen und sachlogisch notwendigen Reihenfolge der Teilschritte gemäß dem Prozessmodell. Für die Erledigung ihrer einzelnen Aufgaben setzen die Handelnden gegebenenfalls Hilfsmittel ein wie Informationen, Anwendungsprogramme oder Werkzeuge. Im Rahmen der Prozessrealisierung ist dafür zu sorgen, dass auf Basis des als Muster definierten Modells durch entsprechende Ressourcenzuordnung mehrere Prozessinstanzen parallel und unabhängig voneinander ausgeführt werden können.

1.4

Rahmenbedingungen für Prozessmodelle und Prozessinstanzen

Das Geschäftsmodell beschreibt im Wesentlichen wie ein Unternehmen in die Welt hineinwirkt und auf welche Art und Weise es dabei Erlöse erzielt und Gewinn erwirtschaftet. Wesentlich dabei sind das Kundenversprechen sowie die Ressourcen und Partner, mit denen dieses Versprechen eingelöst wird. Die Unternehmensarchitektur beschreibt eine Maschinerie, mit der das Geschäftsmodell zum Leben erweckt werden soll. Als typisches Schichtenkonzept definiert sie fachliche und IT-Strukturen und verknüpft diese miteinander. Das Konzept des Business Engineering sieht etwa auf einer strategischen Ebene die Geschäftsarchitektur mit der Definition von Zielen und Leistungen vor, die mit dem Geschäftsmodell verwoben ist (vgl. Österle und Winter 2013). Auf der Ebene der Prozesse als Implementierungshilfsmittel der Strategie folgt die Prozessarchitektur mit Aufbau- und Ablauforganisation. Der Übergang zu den IT-Strukturen für die Unterstützung der Prozesse führt auf die Ebene der Informationssysteme mit der Applikationsarchitektur und der IT-Architektur. Die Geschäftsprozesse befinden sich also als zentraler Bestandteil der Unternehmensarchitektur in einer Art Sandwich-Position, welche ihre Beeinflussung durch andere Architekturelemente verdeutlicht. Beispielsweise kann eine gegebene und nur schwer änderbare Organisationsstruktur die Vorgehensweisen in Prozessen und die Art, wie mit externen Partnern zusammengearbeitet wird, mitbestimmen. Analog gilt dies für die Verfügbarkeit von Ressourcen. Aber auch horizontale Abhängigkeiten innerhalb der Ablauforganisation sind zu berücksichtigen, etwa wenn eine bestimmte Arbeitsweise im Bestellprozess Auswirkungen auf die Gestaltung der Zahlungsabwicklung hat. Von „unten“ wirken Einflüsse nicht nur hinsichtlich der inhaltlichen Gestaltung der Prozessmodelle, sondern auch hinsichtlich Detailgrad und Genauigkeit. Für die Entwicklung von IT-Lösungen zur Prozessdigitalisierung gelten rigide Anforderungen an die Modelldefinition. Prozessteile, die mit IT-Unterstützung ausgeführt werden sollen, müssen genau und präzise spezifiziert sein. Neben den exemplarisch erläuterten und in Abb. 1.3 ergänzten internen Rahmenbedingungen wirken auch noch externe Faktoren auf

1.5 Prozesskennzahlen

7

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat „ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „

Weltsicht

„ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert

Mentale Weltmodelle

„ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Wissen und Wollen

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.3 Ergänzung um Rahmenbedingungen für die Prozessdefinition

die Prozessgestaltung ein. Hier kann man als Beispiel Prüfschritte sehen, welche aufgrund von Compliance-Vorschriften in einen Ablauf aufgenommen werden müssen.

1.5

Prozesskennzahlen

Die zu entwickelnden oder zu ändernden Prozesse haben das allgemeine Ziel die Umsetzung des Geschäftsmodells und der zugehörigen Strategie zu unterstützen. Die Beziehung zwischen den Kennzahlen aus dem Geschäftsmodell (Key Performance Indicators) und den Prozessen wird über Prozesskennzahlen (Process Performance Indicators) hergestellt. Diese Prozesskennzahlen sind Verfeinerungen von Zielen aus dem Geschäftsmodell (vgl. Abb. 1.4). Typische betriebswirtschaftliche Key Performance Indicators leiten sich aus Geschäftsmodell und -strategie ab und messen den Geschäftserfolg auf höheren Aggregationsebenen, z. B. Erlöse und Kosten auf Gesamtunternehmens-, Sparten-, Produktgruppenebene etc. Hier steht die Effektivität im Vordergrund („Doing the right things“). Mit den Geschäftsprozessen werden die Strategie umgesetzt und die Elemente der Unternehmensarchitektur zusammengeführt. Die damit verbundenen Process Performance Indicators (PPI) zielen auf die Effizienz ab („Doing things right“). Sie stehen damit in

8

1 Motivation

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat „ „ „

Mentale Weltmodelle Wissen und Wollen

„ Prozesslogik: Ein Prozess ist

Key & Process Performance Indicators

Weltsicht

„ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.4 Definition von Prozesskennzahlen

engem Zusammenhang mit den Key Performance Indicators und leiten sich teilweise von diesen ab. Beim Ableiten der Kennzahlen muss bereits geprüft werden, ob diese mit vertretbarem Aufwand in ausreichender Präzision gemessen werden können. Unter Umständen ergeben sich daraus auch Anforderungen an den zu entwickelnden Prozess, um die Kennzahlen direkt oder indirekt messen zu können. Ist unmittelbare Messung nicht möglich können auch Ziele für Ersatzkennzahlen festgelegt und daraus Werte für den eigentlich gewünschten Performance Indicator abgeleitet werden. Für die Prozesskennzahlen werden Zielwerte festgelegt, die es durch einen geänderten oder neu zu gestaltenden Prozess zu erreichen gilt. Während des ganzen Wegs von der Identifikation des Problems, bis hin zur Inbetriebnahme eines geänderten oder neuen Prozesses gilt es laufend zu plausibilisieren, ob mit dem entstehenden Prozess die angestrebten Ziele erreicht werden können.

1.6

Unterstützungskonzepte

Der Weg vom individuellen Wissen und Wollen, also von den mentalen Modellen der Beteiligten zu einem Prozessmodell, das auch zumindest in Teilen digitalisiert werden kann, ist komplex und aufwendig. Um Komplexität und Aufwand zu reduzieren wurden

1.6 Unterstützungskonzepte

9

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Mentale Weltmodelle Wissen und Wollen

Key & Process Performance Indicators

Weltsicht

Beschreibungssprachen: Sprachgrammak, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, …

„ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.5 Ergänzung um Konzepte zur Unterstützung der Prozessdefinition

Unterstützungskonzepte wie Frameworks, Vorgehensmodelle und Beschreibungssprachen entwickelt. Die folgende Übersicht umfasst eine thematisch gruppierte Auswahl solcher Hilfsmittel, welche nach unseren Erfahrungen in der Praxis weit verbreitet sind. Sie sind in Abb. 1.5 eingefügt und werden in den Kapiteln zu Modellbildung (Kap. 2) und Modellierungssprachen (Kap. 3) genauer betrachtet. Frameworks für das Qualitätsmanagement: • • • •

Total Quality Management (TQM) TQM/PDCA, Deming-Zyklus (PDCA, Plan-Do-Check-Act) EN ISO 9001 European Foundation for Quality Management (EFQM)

Frameworks für das Unternehmensarchitekturmanagement (Enterprise Architecture Management, EAM): • Zachman-Framework • The Open Group Architecture Framework (TOGAF) • Architecture Animate (ArchiMate)

10

1 Motivation

Frameworks für IT-Management und IT-Governance: • IT Infrastructure Library (ITIL®) • Control Objectives for Information and Related Technology (COBIT) Beschreibungssprachen für die Prozesslogik: • • • •

Flussdiagramme Ereignisgesteuerte Prozessketten mit Erweiterung (EPK, eEPK) Business Process Model and Notation (BPMN) Subject-oriented BPM (S-BPM)

1.7

Digitalisierung

Heute ist Digitalisierung das Schlüsselwort bei der Transformation der Wertschöpfung. Digitalisierung in der Wirtschaft oder allgemein in Organisationen heißt Digitalisierung von Geschäftsmodellen, Produkten und Services sowie von ganzen Prozessen oder Teilen davon. Bei Prozessen bedeutet dies jedoch nicht notwendigerweise Vollautomatisierung ohne jeglichen menschlichen Eingriff. Es kann z. B. sein, dass ein Programm, das einen Prozess steuert, bei entsprechender Notwendigkeit Aktionen einbindet, die von Menschen oder auch Cyber Physical Systems ausgeführt werden. Letztere bestehen aus miteinander kommunizierenden Geräten mit Software sowie mechanischen und elektronischen Komponenten. In der Initiative Industrie 4.0 wird diese umfassende Betrachtung von Prozessen, d. h. die Kommunikation zwischen Menschen, Maschinen und Werkstücken angestrebt. Diese Aspekte müssen zum einen in den Prozessmodellen ausgedrückt werden können und zum anderen muss die Überführung eines Geschäftsprozessmodells in die digitale Ausführung soweit wie möglich unterstützt werden. Insbesondere wenn man die Aspekte des Qualitätsmanagements, also die laufende Verbesserung der Prozesse, in die Betrachtung einbezieht, müssen Prozessänderungen, die eine Änderung der Digitalisierung nach sich ziehen, schnell und mit möglichst geringem Aufwand umgesetzt werden können. Die in den vorangegangenen Abschnitten beschriebenen Aspekte müssen bei der Modellbildung schon mit einfließen, um die technische Implementierung von Prozessen zu erleichtern, ohne jedoch bereits Implementierungsdetails vorweg zu nehmen (vgl. Abb. 1.6). Je präziser die Prozesse beschrieben sind, umso leichter fällt dies. Prozessabschnitte, deren Ablauflogik zum Zeitpunkt der Modellierung noch nicht präzise beschrieben werden können, sind entsprechend zu kennzeichnen. Diese Teile eines Prozesses können aber mit anderen geeigneten Methoden gemäß der gewünschten oder notwendigen Offenheit modelliert werden. Solche Prozessabschnitte können entweder mit Adaptive-Case-Management-Methoden beschrieben werden oder, falls eine kommunikationsorientierte Beschreibungssprache verwendet wird, als Kommunikationsschleife.

1.8 Prozess zum Erstellen von Prozessen

11

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Mentale Weltmodelle Wissen und Wollen

Key & Process Performance Indicators

Weltsicht

Beschreibungssprachen: Sprachgramm k, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, … Digitalisierung umsetzungsgetreue Spezifika on, Datenhhaltung, Datenverarbeitung, Ablauf- und Kommunika onssteuerung, IT-Pl orm

„ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Wissen und Wollen Wissen und Wollen

Strukturierung, Modellbildung

Wissen und Wollen Prozessmodell

Abb. 1.6 Berücksichtigung von Digitalisierungsaspekten im Modell

Letztere beendet einer der beteiligten Partner nach Erreichen eines entsprechenden Ergebnisses, ehe im Prozess fortgefahren wird. Wichtig in diesem Kontext ist die Granularität, also der Detailgrad der Prozessbeschreibung. Aktivitäten sollten so fein geschnitten werden, dass man eindeutig festlegen kann, ob sie digitalisiert, teildigitalisiert (Mensch-IT, Physik-IT) oder manuell von Menschen ausgeführt werden. Der Zuschnitt sollte sich an den fachlichen Anforderungen orientieren und nicht an der Funktionalität eines möglicherweise schon vorhandenen IT-Systems. Notfalls muss ein derartiges System bei der Prozessumsetzung an dessen fachlich gewünschte Spezifikation angepasst werden.

1.8

Prozess zum Erstellen von Prozessen

Die Definition der Geschäftsprozesse kann nicht schematisch bzw. algorithmisch erfolgen, d. h., es gibt keine Software, die gefüttert mit dem Geschäftsmodell, der Unternehmensarchitektur, den Kennzahlen mit dazugehörigen Zielwerten und Unterstützungskonzepten, nach kurzer Zeit eine passende Prozessbeschreibung ausgibt. Die Definition von Geschäftsprozessen ist ein intuitiver und kreativer Prozess. Deshalb werden v. a. zu Beginn auch Kreativitätstechniken und Methoden des Wissensmanagements wie Storytelling, World Café oder Value Networks eingesetzt. So kann man sich

12

1 Motivation

beispielsweise des Design-Thinking-Ansatzes bedienen. Dabei handelt es sich um ein Konzept, bei dem interdisziplinäre Teams in einem die Kreativität fördernden Umfeld in einem iterativen Prozess zusammenarbeiten, um innovative Lösungen für eine Problemstellung zu entwickeln (vgl. Abschn. 5.3). Ein Kernpunkt ist dabei ein tiefes Verständnis für die Bedürfnisse und Motivationen von Menschen der Zielgruppe zu entwickeln und zu berücksichtigen. Design Thinking bietet eine umfangreiche Methodensammlung für die Nutzung in den einzelnen Schritten seines Vorgehens. Mit diesen Eigenschaften lässt sich der Ansatz auch für die Überarbeitung bzw. Neudefinition eines Geschäftsprozesses einsetzen. Unter Umständen lassen sich dabei außergewöhnliche Lösungen finden, die beim üblichen BPM-Vorgehen nicht entstanden wären. Allerdings muss ein kreatives, innovatives Prozesskonzept auch detailliert ausgearbeitet und umgesetzt werden. Die kreative Gestaltung ist deshalb eingebettet in Bündel von Aktivitäten, die den Prozess letztlich Teil der realen Welt werden lassen. Als solche Aktivitätsbündel identifizieren wir Analyse und Modellierung, Validierung, Optimierung, organisatorische Implementierung, IT-Implementierung sowie Betrieb und Monitoring. Diese Aktivitätsbündel sind eine Weiterentwicklung bzw. Verfeinerung des Plan-DoCheck-Act-Kreislaufs. Sie werden meist kreisförmig angeordnet, was einen entsprechenden Durchlauf impliziert. Dies entspricht nicht immer der Realität, weshalb wir die Aktivitätsbündel in Abb. 1.7 als lose vernetzte Waben darstellen. Dort sind die Phasen

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Wissen und Wollen Wissen und Wollen Wissen und Wollen Wissen und Wollen

Digitalisierung umsetzungsgetreue Spezifikaon, Datenhhaltung, Datenverarbeitung, Ablauf- und Kommunikaonssteuerung, IT-Plaorm

Vorgehensstruktur

Mentale Weltmodelle

Key & Process Performance Indicators

Weltsicht

Beschreibungssprachen: Sprachgrammak, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, …

Design Thinking

„ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Team

Akvitätsbündel

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Strukturierung, Modellbildung Planung Prozessmodell

Abb. 1.7 Ergänzung um die Vorgehensstruktur und Planung für Prozessänderungen

1.9 Organisatorische und technische Implementierung

13

des Design-Thinking-Prozesses und die Aktivitätsbündel ergänzt. Beide Konzepte werden in Kap. 5 ausführlicher vorgestellt und miteinander in Beziehung gesetzt. Umfangreiche und komplexe Prozessänderungen bedürfen meist Tätigkeiten aus mehreren Aktivitätsbündeln und werden als Projekt durchgeführt. Ein solches Projekt kann deshalb als ein Durchlauf (Prozessinstanz) des Prozesses zum Erstellen von Geschäftsprozessen betrachtet werden. Dafür ist eine detaillierte Projektplanung zu erstellen mit den auszuführenden Tätigkeiten, Zuständigkeiten und Terminen (vgl. Abb. 1.7). Der Projektplan sollte dann entsprechend den Methoden des Projektmanagements abgearbeitet werden.

1.9

Organisatorische und technische Implementierung

Nach der Erstellung des Prozessmodells gilt es das Modell in die Organisationsstruktur eines Unternehmens einzubetten. Es wird damit festgelegt, welche Tätigkeit von welcher Person oder Organisationseinheit ausgeführt wird. Diese Zuordnung muss nicht statisch sein, sondern kann von Instanz zu Instanz variieren. So kann z. B. der Einkaufsprozess für die Teile A und B die gleiche Ablauflogik haben, allerdings ist für den Einkauf der Teile A eine andere Einkaufsabteilung zuständig als für die Teile B. Prozessinstanzen für die Teile A tangieren also andere Organisationseinheiten (und ihnen zugeordnete Personen) als für Teile B. Diese Regeln sind so abzubilden, dass ein Prozess richtig mit der Aufbauorganisation verknüpft wird. Neben Tätigkeiten, die durch Menschen ausgeübt werden, können im Prozess auch Aktivitäten vorkommen, welche Anwendungsprogramme oder IT-Services ausführen. Dazu sind solche Aktionen im Prozessmodell auf Funktionen von Softwarebausteinen abzubilden, welche diese dann zur Laufzeit ausführen. Wurde bei der Prozessmodellierung schon auf die mögliche Digitalisierung geachtet, so ist diese Abbildung mehr oder weniger unproblematisch. Software kann auch die Abarbeitung von Vorgangsschritten steuern und dabei die im Modell spezifizierten Aufgaben den jeweils vorgesehenen Personen oder IT-Services als Akteur zuordnen. Softwaresysteme, die dies unterstützen, werden auch als WorkflowSysteme (Process Engine, Workflow Engine) bezeichnet. Im Idealfall können Prozessbeschreibungen direkt in Workflow-Systeme übernommen werden. Nach der Einbettung in die Organisation und in die IT-Umgebung kann ein Prozess für die Abwicklung von Instanzen, also echten Geschäftsfällen verwendet werden, das Ziel ist erreicht. Die Abb. 1.8 zeigt den nun vervollständigten Weg von den individuellen mentalen Modellen mit dem Wissen und Wollen der Beteiligten zur gemeinsamen Bearbeitung von Prozessinstanzen.

14

1 Motivation

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat „ „ „

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Wissen und Wollen Wissen und Wollen Wissen und Wollen Wissen und Wollen

Digitalisierung umsetzungsgetreue Spezifikaon, Datenhhaltung, Datenverarbeitung, Ablauf- und Kommunikaonssteuerung, IT-Plaorm

Vorgehensstruktur

Mentale Weltmodelle

Key & Process Performance Indicators

Weltsicht

Beschreibungssprachen: Sprachgrammak, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, …

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „

Design Thinking

„

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Team

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Akvitätsbündel

Strukturierung, Modellbildung Planung Prozessmodell

Organisatorische und techn. Implementierung

Abb. 1.8 Ergänzung um die Einbettung in die Organisation und IT-Umgebung

1.10

Erfolgsmessung mit Kennzahlen

Bei der Ausführung von Instanzen eines Prozesses im laufenden Betrieb kann überprüft werden, ob die für die Prozesskennzahlen (Process Performance Indidcators (PPI)) definierten Zielwerte erreicht werden. Dazu werden im Rahmen des Monitoring Ist-Werte für die festgelegten Kennzahlen gemessen, berechnet, gespeichert und mit den Zielwerten verglichen (vgl. Abb. 1.9). Dieser Vergleich kann in Realzeit oder über längere Zeitintervalle erfolgen. Eine Realzeitauswertung führt bei einer Zielabweichung zur sofortigen Einleitung geeigneter Gegenmaßnahmen. Eine Auswertung von Messwerten über längere Zeit zeigt dagegen mittel- bis langfristige Trends von Kennzahlen und kann entsprechende Änderungen auslösen. Auswertungsergebnisse werden u. a. in Prozesscockpits visualisiert.

1.11

Kontinuierliche Verbesserung

Prozesse sind nicht statisch, sondern unterliegen Veränderungen der in Abschn. 1.4 erläuterten internen und externen Rahmenbedingungen. Entwicklungen wie Geschäftsmodellmodifikationen, neue Wettbewerber, technischer Fortschritt oder Verschlechterungen bei gemessenen Prozesskennzahlen wie der Durchlaufzeit können Anpassungen eines Prozesses erfordern. Dazu sind passende Maßnahmen im Rahmen der in Abschn. 1.8

1.12 Unternehmensführung und Geschäftsprozessmanagement

15

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Wissen und Wollen Wissen und Wollen Wissen und Wollen Wissen und Wollen

Beschreibungssprachen: Sprachgrammak, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, … Digitalisierung umsetzungsgetreue Spezifikaon, Datenhhaltung, Datenverarbeitung, Ablauf- und Kommunikaonssteuerung, IT-Plaorm

Vorgehensstruktur

Mentale Weltmodelle

Key & Process Performance Indicators

Weltsicht

Design Thinking

„ „ „

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „ „

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Team

Akvitätsbündel

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt KPIs & PPIs

Strukturierung, Modellbildung Planung Prozessmodell

Organisatorische und techn. Implementierung

Betrieb & Monitoring

Abb. 1.9 Betrieb, Monitoring und Kennzahlen

vorgestellten Aktivitätsbündel und Vorgehensweisen zu ergreifen. Der Feedback-Pfeil in Abb. 1.10 deutet an, dass dazu die Beteiligten möglicherweise wieder divergierende Sichten des Realitätsausschnitts haben. Mit deren Harmonisierung in der beschriebenen Weise wird eine neue Instanz des Prozesses zur Erstellung von Prozessen gestartet. Die kontinuierliche Verbesserung ist ein sehr wesentlicher Aspekt des Prozessmanagements. Durch laufende Anpassungen nähert man sich dem gewünschten Prozess immer mehr an. Allerdings können Veränderungen im Umfeld diese Annäherung beeinflussen. Der angestrebte Zustand ist also ein bewegliches Ziel („moving target“).

1.12

Unternehmensführung und Geschäftsprozessmanagement

Die Unternehmensführung als Institution gestaltet das Unternehmen. Sie bestimmt maßgeblich das Geschäftsmodell, die Unternehmensstrategie und die Organisation. Geschäftsmodell und Strategie sollen zukünftige Erfolgspotenziale erschließen und damit die nachhaltige Existenz des Unternehmens sichern. Mit der Unternehmensarchitektur wird die Infrastruktur zur Ausschöpfung der Erfolgspotenziale geschaffen. Die Geschäftsprozesse und die in ihnen bearbeiteten Geschäftsobjekte (Daten) verknüpfen die fachliche und technische Ebene der Unternehmensarchitektur. Die Geschäftsprozesse sind Gegenstand der Digitalisierung, d. h. der informationstechnischen Unterstützung der Prozessausführung durch Menschen und Maschinen. In

16

1 Motivation

Geschäftsmodell und -strategie Unternehmensarchitektur

Bestandteile einer Prozessbeschreibung

Geschäftsprozesse

„ Prozessstrategie: Ein Prozess hat „ „ „

Unterstützungskonzepte: Total Quality Management, Plan-Do-Check-Act, ISO 9001, EFQM, ITIL, TOGAF, ArchiMate

Wissen und Wollen Wissen und Wollen Wissen und Wollen

„ Prozesslogik: Ein Prozess ist „ „ „ „ „

die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die nach dem Startereignis von Handelnden in sachlogischer und zeitlicher Reihenfolge zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um das gewünschte Ergebnis zu erzeugen.

„ Prozessrealisierung: Ein Prozess wird realisiert „

Design Thinking

„

mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen.

Team

Verbesserung?

Wissen und Wollen

Digitalisierung umsetzungsgetreue Spezifikaon, Datenhhaltung, Datenverarbeitung, Ablauf- und Kommunikaonssteuerung, IT-Plaorm

Vorgehensstruktur

Mentale Weltmodelle

Key & Process Performance Indicators

Weltsicht

Beschreibungssprachen: Sprachgrammak, Flussdiagramme, EPK, eEPK, BPMN, S-BPM, …

einen definierten Anfang (Startereignis) und Input, weißt ein definiertes Ende und Ergebnis auf, das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt

Gemeinsames zielgerichtetes Tun, von Werkzeugen unterstützt

Akvitätsbündel

KPIs & PPIs

Strukturierung, Modellbildung Planung Prozessmodell

Organisatorische und techn. Implementierung

Betrieb & Monitoring

Abb. 1.10 Ergänzung um kontinuierliche Verbesserung

den letzten Jahren haben sich die diesbezüglichen Anforderungen deutlich vergrößert. So sollen in Geschäftsprozessen nicht nur Menschen und IT-Systeme, sondern auch „smarte“ Maschinen und Geräte interagieren können. Gemeint sind hochintegrierte Geschäftsprozesse im Kontext von Industrie 4.0 und Internet of Things, die sowohl menschliche Akteure, als auch einzelne Geräte und Maschinen zu einem gemeinsamen Ganzen integrieren. Die technischen Akteure werden dabei oftmals als „smart“ oder „intelligent“ bezeichnet. Unternehmensführung als Prozess bezeichnet die Managementtätigkeiten bei der Schaffung und Ausschöpfung der Erfolgspotenziale. Im Kontext des Geschäftsprozessmanagements bedeutet dies das Management von soziotechnischen Systemen mit Menschen, die in Prozesse eingebunden sind, und mit Maschinen, die Menschen bei ihren Tätigkeiten unterstützen oder Folgen von Tätigkeiten autonom ausführen. Trotz der zunehmenden Bedeutung der Digitalisierung steht der Mensch als Gestalter von soziotechnischen Systemen und Anwender der unterstützenden Technik im Mittelpunkt des Prozessmanagements. Nicht zuletzt aufgrund steigender Agilitätsanforderungen ist es heute Ziel, dass die Mitarbeiter, soweit wie möglich, autonom und selbständig die operativen Prozesse gestalten (modellieren) können und diese danach ohne wesentliche Verzögerungen und zusätzlichen Aufwand direkt informationstechnisch unterstützt werden. Mit einem deutlichen Bekenntnis zur Prozessorientierung muss die Unternehmensleitung die Voraussetzungen dafür schaffen („Tone from the top“). Diese umfassen

Literatur

17

sowohl die notwendige Infrastruktur als auch ein Umfeld, das Menschen ermutigt, sich aktiv in die Prozessmanagementaktivitäten einzubringen. Der Grad der Einbindung der Mitarbeiter ist geprägt vom Menschenbild und der damit verbundenen Führungsphilosophie der Unternehmensleitung („Tone at the top“). Bei einem klassisch eher hierarchisch geprägten Ansatz werden die Menschen und ihre Fähigkeiten als Ressource betrachtet, die Gegenstand der Handlungen von Führungskräften sind und schließlich Anweisungen ausführen. Eine derartige Managementphilosophie ist gekennzeichnet durch direkte Intervention der Unternehmensführung und folgt der Theorie X. Gemäß dieser Theorie wird etwaiger fehlender Motivation durch Androhung von Sanktionierung seitens der Unternehmensführung begegnet. Im mehr systemischen, d. h. ganzheitlichen Ansatz wie er dem St. Gallener Managementmodell zugrunde liegt, soll ein System geschaffen werden, das selbst und weitgehend selbstständig an der Gestaltung eines Geschäftsprozessmanagementsystems arbeitet. Alle Mitarbeiter sollen sich aktiv selbst einbringen. Dieser Managementstil folgt dem Menschenbild gemäß Theorie Y. Danach sind die wesentlichen Merkmale eines Menschen Freude an anspruchsvoller Arbeit, Selbstdisziplin, Verantwortung und Verstandeskraft. Ergänzt wird das Menschenbild durch entsprechende Organisationstheorien. Diese haben den Zweck, das Entstehen, Bestehen und die Funktionsweise von Organisationen zu erklären. Organisationstheorien setzen implizit ein entsprechendes Menschenbild voraus. So geht der Taylorismus mehr von einem Menschenbild aus, das der Theorie X entspricht. Die systemische Organisationstheorie nach Luhmann macht dagegen keinerlei ethische Annahmen zu den Menschen in einer Organisation, sie nimmt nur an, dass diese kommunizieren. Der Schwerpunkt bei der Theorie des Kommunikativen Handelns liegt zwar auch auf der Kommunikation, aber durch Theorie und Vernunft soll die Welt verändert werden. Es wird davon ausgegangen, dass der Mensch von Natur aus einsichtig und offen für Argumente ist. Zu den verschiedenen Menschenbildern gibt es dazu passende Managementphilosophien und Organisationstheorien. Art und Einsatz von Methoden, Techniken und Werkzeuge müssen damit in Einklang stehen. Beispielsweise passt es nicht zusammen, die Einbindung von Mitarbeitern zu propagieren, wenn die Unternehmensführung dann deren Vorschläge nicht ernst nimmt oder gar nicht wahrnimmt. Bevor es an die Gestaltung von Prozessen geht, sollte sich ein Unternehmen deshalb bewusst machen, welches Menschenbild seine Führungs- und Unternehmenskultur prägt. Wir denken, dass es insbesondere für die mit der Digitalisierung verbundenen Herausforderungen einer Ausrichtung zu Theorie Y bedarf, welche in der Praxis häufig zu Kulturwandel führen wird.

Literatur Österle H, Winter R (2013) Business Engineering: Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl. Springer, Berlin/Heidelberg

2

Modelle

Im vorangegangenen Kapitel haben wir die vielfältigen Aspekte des Geschäftsprozessmanagements umrissen. Da in der Praxis häufig Modelle für die Beschreibung dieser Aspekte zum Einsatz kommen, gehen wir in den folgenden Abschnitten zunächst näher auf die Aufgaben und Eigenschaften von Modellen und Modellbildung ein. Danach stellen wir Beispiele von Modellen aus verschiedenen Fachgebieten vor, welche sich nach unserer Erfahrung in zahlreichen Geschäftsprozessmanagementprojekten als hilfreich erwiesen haben. Die Darstellung erhebt keinen Anspruch auf Vollständigkeit, kann jedoch dem Leser als Orientierung dienen, wenn er selbst Beschreibungsmodelle für sein individuelles Projekt auswählen muss.

2.1

Modell und Wirklichkeit

„Man muss die Welt nicht verstehen, man muss sich nur darin zurecht finden“. Im Internet wird dieser Satz Albert Einstein zugeschrieben. Wer versteht schon, was in der Welt alles geschieht? Wer weiß schon, wie sie funktioniert? Daher sollten wir uns um unsere Welt kümmern, um den Teil der Welt, der uns momentan wichtig ist. Wir sollten erkennen, dass wir uns unsere Welt täglich erschaffen bzw. konstruieren. Ein betrachteter Ausschnitt ist natürlich bestimmt von unseren subjektiven Interessen. Bevor wir unsere Umwelt beobachten können, müssen wir entscheiden, was uns interessiert. Wir entscheiden, welchen Ausschnitt der Welt wir betrachten wollen, und welche Aspekte uns darin wichtig erscheinen. Wir identifizieren dabei die für uns wesentlichen Artefakte und die für uns wesentlichen Beziehungen zwischen ihnen. Eine solche Abstraktion eines Ausschnitts der Wirklichkeit wird als Modell bezeichnet und die darin enthaltenen Aspekte werden Attribute des Modells genannt. Es kann auch sein, dass

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_2

19

20

2 Modelle

Betrachteter Ausschni der Wirklichkeit

Subjekv als wesentlich betrachtete Aspekte

Modell: Individuen und Beziehungen

Abb. 2.1 Modellbildung

der betrachtete Ausschnitt der Wirklichkeit bereits ein Modell ist. Damit können Teile eines bereits existierenden Modells näher betrachtet werden. Dies wäre dann ein Modell eines Modells. Dieses Hochschrauben kann beliebig fortgesetzt werden. Die Entscheidung welche Aspekte der Welt betrachtet werden, nennt Herbert Stachowiak in seinem Buch „Allgemeine Modelltheorie“ pragmatische Entscheidung (Stachowiak 1973): Beschließe über dasjenige, was Du unter „Erkenntnis“ verstehen willst, immer nur bezüglich der Intentionen (Zwecke, Absichten, Ziele), die du dir als einzelner oder Mitglied einer oder mehrerer hinreichend intentionshomogener Gruppen für eine gewisse Zeitspanne gesetzt hast. Versuche also nicht, auf Intensionslosigkeit des Erkennens, auf eine Erkenntnis, die nicht auf ein „Wissen wozu“ erzeugt zu intendieren.

Aus dem pragmatischen Entschluss und dem Modellkonzept der Erkenntnis leitet sich die neopragmatische Erkentnislehre des Modellismus ab (Stachowiak 1973). Dementsprechend ist „alle Erkenntnis, Erkenntnis in Modellen“ und durch Modelle und jede menschliche Weltbegegnung bedarf des Mediums „Modell“ (Stachowiak 1973). Jede Person hat eine eigene, von seinen Interessen geleitete, subjektive Sicht auf die Welt oder einen Ausschnitt der Welt. Verschiedene Menschen betrachten den gleichen Ausschnitt der Wirklichkeit, kommen allerdings zu unterschiedlichen Modellen, da sie unterschiedliche Schwerpunkte setzen, oder anders ausgedrückt, eine andere pragmatische Entscheidung treffen (vgl. Abb. 2.1).

2.2

Ablauf des systematischen Wissenserwerbs

Das Kreieren eines Modells und seine Verwendung sind subjektive Tätigkeiten, d. h. der Ersteller wählt die Eigenschaften der Wirklichkeitsabbildung nach seinen Vorstellungen aus. Allerdings ist es üblich, dass sich Gruppen von handelnden Personen, in weiterer

2.2 Ablauf des systematischen Wissenserwerbs

21

Folge als Subjekte oder Akteure bezeichnet, auf ein Modell zur Betrachtung der Wirklichkeit einigen. Viele wissenschaftliche Schulen basieren auf solchen gemeinsamen Modellen der involvierten Forscher. Modellbildung ist eine wesentliche Tätigkeit in allen Wissenschaften, seien es Philosophie, Soziologie, Physik, Chemie, alle Ingenieurswissenschaften, Ökonomie usw. Die jeweiligen Modelle haben dabei verschiedene Aufgaben: Entweder bilden sie den betrachteten Ausschnitt ab, wie in den Naturwissenschaften üblich, oder sie dienen dazu, bestimmte notwendige Änderungen an dem betrachteten Ausschnitt der Wirklichkeit auszuprobieren (Simulationsmodell). Dies ist beispielsweise wichtig, um keine Menschenleben zu gefährden. Die Sicherheitsmodelle von Autos werden vor deren Serienproduktion in entsprechenden Tests auf ihre Eigenschaften hin überprüft. Dies geschieht nicht mit Menschen, sondern Modellen von Menschen, sogenannten Dummies. Dabei werden zwei Modelle miteinander kombiniert: Das Automodell, das die entsprechenden Sicherheitskonzepte umsetzt, und das Menschenmodell (Dummy), um die Verletzungsrisiken zu untersuchen. Der in einem Modell erfasste Sachverhalt kann nun so lange angepasst werden, bis bei den mit dem Modell betrachteten Phänomenen das gewünschte Ergebnis erreicht wird. Beispielsweise werden dem Sicherheitsmodell eines Autos weitere Sicherheitskonzepte hinzugefügt, bis die gewünschte Reduktion des Verletzungsrisikos erreicht wird. Solche Modelle sind dann keine Abbilder der Wirklichkeit mehr, sondern stellen eine gewünschte Wirklichkeit dar. Die gewünschten Eigenschaften werden dann in die Wirklichkeit zurück transferiert, indem man beispielsweise die im Modell überprüften Sicherheitskonzepte in die Serienautos einbaut. Ziel bei der Modellbildung ist immer, dass wir uns in der Welt zurechtfinden, oder gefahrlos ausprobieren können, wie eine entsprechende Änderung der Wirklichkeit sich auswirken würde. Zu verstehen, was die Welt im Innersten zusammenhält, wird uns wie es aussieht auf absehbare Zeit damit nicht gelingen. Das entsprechende Modell wäre dann die Welt, die es nicht gibt (Gabriel 2015). Den oben umrissenen Denk-, Erkenntnis und Wissensprozess, der die operationale Seite dieses Prozesses betont, hat Stachowiak (1973) in seinem sogenannten K-System beschrieben (das K steht für die kybernetische Orientierung dieses Systems). Dieses K-System ist modellistisch zu verstehen, d. h. es beansprucht keine Realgeltung im erkenntnistheoretischen Sinne. Das Abb. 2.2 zeigt den Ablauf des Erkentnisgewinns nach dem kybernetischen Modell von Stachowiak (1973). Es zeigt das Interaktions- und Kommunikationsverhalten zwischen dem Subsystem Außenwelt und den individuellen Menschen (Modellierer). Als Ein-/Ausgabesystem empfängt der Mensch Informationen aus seiner Außenwelt. Er registriert diese, verknüpft sie mit anderen bereits vorhandenen Informationen und leitet daraus Handlungen ab, die über entsprechende Ausgaben in die Außenwelt einfließen und sie verändern. Der Mensch als Ein-/Ausgabesystem führt dabei verschiedene Funktionen aus. Das K-System entspricht einem Regelkreis in dem der Motivator der Führungsgröße entspricht. Hier werden die Sollgrößen definiert, die den Zweck der Erkenntnisgewinnung

22

2 Modelle

Abb. 2.2 K-System: Ablauf des Wissenserwerbs

Abb. 2.3 Einordnung der Prozessmanagementaspekte in den Ablauf des Wissenserwerbs

betreffen. Der Operator entspricht dem Regler des Systems. Er sorgt dafür, dass sich das Verhalten der Handelnden in der Außenwelt den Motiven, Bedürfnissen, Wünschen, Bestrebungen usw. des Modellierers anpasst. Das Subsystem Perzeptor, Operator und Motivator ist ebenfalls ein rückgekoppeltes System. Die Elemente, die der Perzeptor registriert, sind nicht nur von der Außenwelt, sondern auch vom Motivator und schließlich vom Operator abhängig. Das Verhalten des Operators wird im Gegenzug vom Perzeptor und Motivator beeinflusst, wobei der Perzeptor und Operator den Motivator beeinflusst. Dies bedeutet, dass sich Ziele durch die wahrgenommene Außenwelt ändern können. Ausgehend von diesem allgemeinen Modell zur Erkenntnisgewinnung können nun die in Kap. 1 umrissenen Aspekte des Prozessmanagements eingeordnet werden. Abb. 2.3 zeigt diese Einordnung. Im Prozessmanagement entspricht die Außenwelt dem Verhalten der Kunden, das wiederum in die Markt- und Wirtschaftssituation eingebettet ist. Die Funktion Motivator enthält das Unternehmensziel, das Geschäftsmodell, die Unternehmensarchitektur und die Beschreibung der Geschäftsprozesse. Der Perzeptor nimmt die Informationen aus

2.3 Eigenschaften von Modellen

23

der Außenwelt wahr, und zwar in der Regel über die Prozesskennzahlen bzw. die Key Performance Indicators, oder auch Verbesserungsvorschläge von den Prozessbeteiligten. Diese Informationen werden über die Motivator-Operator-Schleife analysiert und die entsprechenden Aktionen abgeleitet. Dies können Änderungen an den Prozessen oder deren Implementierung sein. Über den Effektor werden die entsprechenden Änderungen vorbereitet, wie z. B. Erweiterungen der Prozessabläufe, und die notwendigen Änderungen an der Außenwelt durchgeführt. Diese geänderte Außenwelt wird Quelle von neuen Informationen, die möglicherweise neue Aktionen auslösen. Das gewonnene Wissen wird in Modelle eingearbeitet. Da alle Erkenntnis Erkenntnis von und in Modellen ist, entstehen durch das K-System der Erkenntnisgewinnung Modelle. Die Eigenschaften dieser Modelle sollen im folgenden Abschnitt näher erläutert werden.

2.3

Eigenschaften von Modellen

Modelle dienen sowohl der abstrakten Darstellung der betrachteten Wirklichkeit im Sinne einer Erkenntnisfunktion als auch der Gestaltung der betrachteten Realität im Sinne eines Rückschlusses. Wie bereits angesprochen wird ein Modell so verändert, dass es einer gewünschten Wirklichkeit entspricht, und dann als Bauplan für eine entsprechende Umgestaltung der Realität verwendet. In Naturwissenschaften wie der Physik haben Modelle überwiegend eine Erkenntnisfunktion, während sie in den Ingenieurwissenschaften und der Betriebswirtschaft die Gestaltung der Wirklichkeit unterstützen sollen (Siemoneit 2010). Bei der Präzisierung des bisher verwendeten Modellbegriffs lehnen wir uns an Herbert Stachowiak an, der in seiner Modelltheorie die Merkmale und die daraus abgeleiteten Eigenschaften von Modellen genauer untersucht hat (Stachowiak 1973). Demnach sind Modelle durch mindestens drei Merkmale gekennzeichnet (Stachowiak 1973):

2.3.1

Abbildung

Ein Modell ist stets ein Modell von etwas. Es kann die Abbildung oder Repräsentation eines natürlichen oder künstlichen Originals sein, wobei dieses Original wiederum selbst ein Modell sein kann. Die Originale können auf natürlichem Wege entstanden, technisch produziert oder sonst wie einfach gegeben sein. Modelle können sehr unterschiedlich beschrieben bzw. repräsentiert werden: • • • • •

Mentale Modelle: Vorstellung im Kopf Verbale Modelle: Natürlich-sprachliche Beschreibung Grafische Modelle: Technische Zeichnungen oder sonstige Bilder Materielle Modelle: Modelle von Gebäuden Formale Modelle: Mathematische Modelle, Computerprogramme usw.

24

2 Modelle

Ein Modell und das Original bilden eine Klasse von Attributen. Unter Attributen versteht man Merkmale und Eigenschaften von Individuen, Relationen zwischen Individuen, Eigenschaften von Eigenschaften, Eigenschaften von Relationen usw. Stachowiak überlässt dem modellierenden Subjekt, was ein Individuum ist. Er sieht Individuen als Attribute nullter Stufe. Mengen von Attributen können zu Klassen zusammengefasst werden und bilden dann Attribute der ersten Stufe. Diese Klassen können wieder zu einer nächsten Attributstufe zusammengefasst werden usw.

2.3.2

Verkürzung

Ein Modell erfasst im Allgemeinen nicht alle Attribute des betrachteten Originals, sondern nur diejenigen, die den Modellschaffern bzw. Modellnutzern als relevant erscheinen. Nicht alle Attribute des Originals werden von einem Modell erfasst. Bereits mit diesem Merkmal ist im weiteren Sinne eine pragmatische Betrachtungsdimension eingeführt worden. Im „weiteren Sinne“ bedeutet hier, dass noch nicht spezifische pragmatischoperationale Gesichtspunkte betrachtet werden, nach denen die Attributklassen, die in ein Modell eingehen sollen, selektiert werden. Diese erste Auswahl der Attribute ist intuitiv und willkürlich. Im engeren Sinn pragmatisch ist die Verkürzung erst dann, wenn die Absichten und operationalen Zielsetzungen des Modellerstellers bzw. Modellbenutzers die Auswahl der modellrelevanten Attribute beeinflussen. Diese Anpassungen an den beabsichtigten praktischen Gebrauch erfolgt erst im nächsten Schritt.

2.3.3

Pragmatismus

Nach der intuitiven Auswahl der Attribute wird überprüft, ob damit der beabsichtigte Zweck erreicht wird. Modelle sind ihren Originalen nicht eindeutig zugeordnet. Sie erfüllen eine Ersetzungsfunktion • für bestimmte erkennende bzw. handelnde modellbenutzende Subjekte (für wen?). Modelle sind nicht nur Modelle von etwas, sie sind auch Modelle für jemanden. Dieser Jemand kann ein Mensch oder auch ein künstlicher Modellbenutzer wie z. B. ein Computerprogramm sein. Für einen Modellierer können Modelle dazu dienen, sich in der Welt zurecht zu finden, d. h. der Modellierer ist gleichzeitig auch Nutzer des Modells. Modellierer und Modellnutzer können aber auch zwei unterschiedliche Subjekte sein. • innerhalb bestimmter Zeitintervalle (wann?) Modelle erfüllen auch eine Funktion über die Zeit, d. h. ihre Nutzung ist auf einen bestimmten Zeitpunkt oder auf ein definiertes Zeitintervall bezogen. Innerhalb dieser Zeit können sich die betrachtete Wirklichkeit oder die Vorstellungen des Modellierers

2.4 Modelle der Sozialwissenschaften

25

oder Modellanwenders derart verändert haben, sodass zusätzliche Attribute in ein Modell einfließen sollen. • unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen (wozu?). Modelle werden zu einem bestimmten Zweck geschaffen, sei es, damit ein bestimmter Ausschnitt der Wirklichkeit besser verstanden werden kann, oder, um einen Bauplan für den Umbau der Wirklichkeit zu bekommen. Bei der Erstellung eines Modells stecken Modellierende immer in einem gewissen Dilemma. Zum einen soll das Modell in ausreichendem Maße die gewünschten Aspekte der Wirklichkeit wiedergeben, wobei nicht klar definiert ist, was ausreichend ist. Zum anderen soll das Modell nicht zu komplex sein, damit es noch handhabbar bleibt. Dieser Zielkonflikt führt dazu, dass die meisten Modelle iterativ weiterentwickelt werden, bis sie ob der steigenden Komplexität das Ende ihres Lebenszyklus erreichen, da sie nicht mehr handhabbar sind. In den folgenden Abschnitten stellen wir Beispiele für Modelle vor, die Aspekte betrachten, welche explizit oder implizit in Modelle für Geschäftsprozesse einfließen. Wir haben die Beispiele gruppiert in Modelle aus den Sozialwissenschaften, der Betriebswirtschaftslehre, der Wirtschaftsinformatik und der Informatik. Die Einordnung in diese Gruppen ist teilweise nicht überschneidungsfrei, da insbesondere die Wirtschaftsinformatik als Querschnittsdisziplin Sachverhalte grundsätzlich aus mehreren Perspektiven betrachtet.

2.4

Modelle der Sozialwissenschaften

Geschäftsprozessmanagement hat mit Menschen und Maschinen zu tun. Es möchte deren Zusammenwirken unter Berücksichtigung von Zusatzanforderungen der technischen sowie der ökonomischen und ökologischen Machbarkeit organisieren. Insbesondere das Zusammenwirken und Zusammenleben der Menschen ist schon Jahrtausende lang Thema der Philosophie. Die Philosophie als die Lehre von den grundlegenden Bestimmungen und Strukturen des Lebens, der Welt und des Wissens versucht, die Welt und die menschliche Existenz zu ergründen, zu deuten und zu verstehen. Die ursprüngliche Bedeutung von Philosophie war die Lehre vom guten Leben. In diesem Sinn ist Philosophie der Versuch, das umfassende Modell unserer Welt zu kreieren was bisher noch nicht gelungen ist. Gesellschaftsphilosophen reduzieren durch ihre pragmatische Entscheidung den Blick und versuchen ein Modell der Gesellschaft als einen Ausschnitt der Wirklichkeit zu schaffen und damit deren Sinn und Wesen besser zu verstehen. Insbesondere beleuchten Gesellschaftsphilosophien das Verhältnis zwischen dem einzelnen Menschen und der Gemeinschaft sowie die Strukturen des Zusammenlebens. Sie gelten deshalb auch als Philosophievarianten, welche die Soziologie

26

2 Modelle

berühren. Sie sollen Soziologen dabei helfen, gesellschaftliche Vorgänge zu analysieren und Organisationsentwickler bei ihrer Arbeit unterstützen, und den “normalen“ Menschen helfen, sich in der Welt zurecht zu finden. Es gibt zahlreiche Organisationstheorien, die in ihren Modellen auf unterschiedliche Aspekte fokussieren (Kieser und Wagenbach 2007; Schreyögg 2008; Crowther und Green 2004; Kieser und Ebers 2006). Die Frage, welche Organisationstheorie die Beste ist kann nicht beantwortet werden. Organisationstheorien repräsentieren Modelle und damit (nach Stachowiak) die zwar begründete, aber subjektive Sicht des Modellierers. Organisationstheorien setzen höchst unterschiedliche Schwerpunkte bei der Analyse von Organisationen und verfolgen unterschiedliche Zielsetzungen. Es gibt zu den jeweiligen Organisationstheorien empirische Untersuchungen, die Ergebnisse zu Gunsten oder Ungunsten einer Theorie liefern. Allerdings sind die verwendeten Untersuchungs- und Analysemethoden umstritten (Kieser und Ebers 2006). Organisationstheorien liegen bestimmte Menschenbilder zugrunde, und die Ausgestaltung des Geschäftsprozessmanagements wird stark von dem in einer Organisation herrschenden Menschenbild geprägt. Deshalb stellen wir mit dem Taylorismus, der Habermas’schen Theorie des kommunikativen Handelns, und den sozialen Systemen von Luhmann drei Organisationstheorien mit ihren pragmatischen Entscheidungen und den diesbezüglichen Menschenbildern in den folgenden Abschnitten vor.

2.4.1

Taylorismus und Fordismus

Der Taylorismus führte das Experiment in die Managementlehre und -praxis ein und zählt zu den Klassikern der Organisationslehre. Mit dem sogenannten Scientific Management erhielten Organisationen ein Instrument zu ihrer effizienten Gestaltung. Ein wesentliches Kennzeichen ist die Trennung zwischen planender Kopfarbeit und ausführender Handarbeit. Nach dem Tayloristischen Menschenbild sind Arbeiter dumm und faul und müssen deshalb strengen Regeln unterworfen werden. Diese Sicht beeinflusst auch heute noch oft implizit das Verhalten von Führungskräften. Für Frederik Winslow Taylor waren die wichtigsten Ziele die Vervollkommnung der Produktionsmittel und Arbeitsverfahren, straffere Organisation und Zeitordnung des Arbeitsablaufes im Betrieb, sowie eine Neuordnung des Entlohnungssystems. Ein Kernelement des Taylorismus ist die Gestaltung von Arbeitsprozessen auf der Grundlage von Zeit- und Bewegungsstudien. Eine Zerlegung des Produktionsprozesses in kleinste Arbeitsschritte, eine Entlastung der Arbeiter von geistigen Tätigkeiten, sowie eine Änderung des Lohnsystems sollen zu einer optimalen Nutzung der vorhandenen Leistungspotenziale führen. Ziel ist die Steigerung der Produktivität menschlicher Arbeit. Dies geschieht durch die Teilung der Arbeit in kleinste Einheiten, zu deren Bewältigung keine, oder nur geringe Denkvorgänge zu leisten, und die aufgrund des geringen Umfangs bzw. Arbeitsinhalts schnell und repetitiv zu wiederholen sind.

2.4 Modelle der Sozialwissenschaften

27

Dem Taylorismus liegen folgende Kernprinzipien zu Grunde: • Arbeitsplanung Die Planung der Arbeit wird von anderen Personen durchgeführt als deren Ausführung (Trennung von Hand- und Kopfarbeit). Damit wollte Taylor die Drückebergerei, die er den Arbeitern unterstellte, umgehen. Durch Zeit und Bewegungsstudien, die von den Kopfarbeitern ausgeführt wurden, sollte der geringste Bewegungs- und Zeitaufwand für einen Arbeitsschritt ermittelt werden. • Leistungslohn Aus diesen Zeit- und Bewegungsstudien ergab sich auch, was die Arbeiter in einer gewissen Zeit zu leisten hatten. Ein Bonus oder eine Prämie sorgten dafür, dass sich die als dumm und faul eingestuften Arbeiter auch tatsächlich bemühten, die vorgegebenen Leistungsdaten zu erreichen. • Auswahl der am besten geeigneten Arbeiter Durch eine entsprechende Auslese galt es einen erstklassigen Arbeiterstamm aufzubauen. Es wurden entsprechende Tests entwickelt und eingesetzt, um besonders fingerfertige und flinke Arbeiter zu identifizieren. • Versöhnung zwischen Arbeitern und Management Taylor glaubte, dass durch das von ihm entwickelte System die Produktivität so gesteigert werden kann, dass der Streit um die Verteilung des Gewinns zur Nebensache werden würde. Dadurch sollte der Konflikt zwischen Arbeitgebern und Arbeitnehmern aufgelöst werden. Der Taylorismus betrachtet im Wesentlichen die Strukturierung der Arbeitsschritte, stellt jedoch nicht auf deren Reihenfolge ab. Diesen Aspekt ging Henry Ford an, der mit der Einführung des Fließbands die einzelnen Tätigkeiten koordinierte. Damit waren die Voraussetzungen für die Massenfertigung geschaffen, die das 20. Jahrhundert prägte. Das Fließbandprinzip wurde auch in die Verwaltung übertragen und beeinflusste stark das Geschäftsprozessmanagement. Flussdiagramme sind die Fließbandvorgaben für die Abwicklung von Verwaltungsaufgaben oder die „Produktion“ von Dienstleistungen.

2.4.2

Kommunikatives Handeln nach Habermas

Im Gegensatz zum Taylorismus geht die Theorie des kommunikativen Handelns nach Habermas von einsichtigen Menschen aus, die durch die Kommunikation untereinander zu einem gemeinsamen vernünftigen Handeln kommen. Mit seinem Gesellschaftsmodell erklärt Habermas die Vorgänge in einer Gesellschaft, wie z. B. die Suche nach Wahrheit, nach Gerechtigkeit. Der Zweck dieses Modells ist es, allgemein akzeptierte moralische Prinzipien zu definieren. Es ist also ein Modell, das alle angeht, denn die Themen Wahrheit und Gerechtigkeit betreffen sämtliche Mitglieder von Gesellschaften. Der zentrale Aspekt im Gesellschaftmodell von Habermas ist das sogenannte kommunikative Handeln.

28

2 Modelle

„Der Begriff des kommunikativen Handelns schließlich bezieht sich auf die Interaktion von mindestens zwei sprach- und handlungsfähigen Subjekten, die (sei es mit verbalen oder extraverbalen Mitteln) eine interpersonale Beziehung eingehen. Die Aktoren suchen eine Verständigung über die Handlungssituation, um ihre Handlungspläne und damit ihre Handlungen einvernehmlich zu koordinieren.“ (Habermas 1981) Nach Habermas gelingt es durch Kommunikation, dass der einzelne Mensch, der von sich aus nicht vernunftbegabt ist, diesen Mangel überwindet. Die Kommunikation zwischen Menschen wird zum intersubjektiven Handeln und zu einer möglichen Quelle der Vernunft. Kommunikatives Handeln heißt Handeln auf der Grundlage der Verständigung zwischen Menschen. Habermas möchte damit Soziologen und Politikern ein Modell anbieten, das sie nutzen können, um die Gesellschaft zu analysieren bzw. zu gestalten. Dem einzelnen Menschen kann es dazu dienen, sich trotz der Komplexität heutiger Gesellschaften zurecht zu finden.

2.4.3

Soziale Systeme nach Luhmann

Ähnlich wie bei Habermas basiert das Gesellschaftsmodell von Luhmann auf Kommunikation (Luhmann 1987). Die Unterschiede liegen darin, in wieweit Kommunikation und Handeln kombiniert sind. Luhmann lässt ausschließlich Kommunikation als konstituierenden Aspekt für Organisationen zu – Kommunikation findet nicht zwischen Menschen statt, sondern zwischen mindestens zwei informationsverarbeitenden Prozessoren. Damit sieht Luhmann die Kommunikation abstrakter. Nach ihm besteht die Gesellschaft nicht aus Menschen oder Teilen von Menschen. Sonst würde man etwas von der Gesellschaft abschneiden, wenn man etwas vom Menschen abschneidet. Der Körper eines Menschen (als biologisches System) mit einem Bewusstsein (psychisches System) ist zwar in vielen Fällen Voraussetzung für das Funktionieren eines sozialen Systems, also der Kommunikation, aber ein Mensch ist nicht das soziale System selbst. Luhmann macht in seiner Organisationstheorie keinerlei Aussagen zur Natur des Menschen, lässt also das Menschenbild offen. Menschen sind nur insofern Teil der Organisation, als sie miteinander kommunizieren. Die Kommunikation zwischen den informationsverarbeitenden Prozessoren besteht aus den sogenannten Selektionen der Information, der Mitteilung und des Verstehens (siehe Abb. 2.4). Die ersten beiden Selektionen liegen beim Sender und die dritte beim Empfänger. Die Kommunikation als Stück mit mindestens zwei Akteuren in drei Akten ist eine unteilbare Einheit, nämlich die kleinste Einheit eines sozialen Systems und die elementare Operation der Gesellschaft (Berghaus 2004). Diese Sicht kann als Muster zur Definition der Kommunikation in Geschäftsprozessen dienen, vollkommen unabhängig von einem konkreten Menschenbild. Sowohl Luhmann als auch Habermas stellen in ihrer Organisationstheorie also die Kommunikation in den Mittelpunkt der Betrachtung. Dass diese beiden bedeutenden

2.4 Modelle der Sozialwissenschaften

29

Zwei informaonsverarbeitende Prozessoren In der Regel Personen oder soziale Systeme Sender Bei Luhmann: „Alter“ Drei Selekonen:

1. 2.

Selekon der Informaon Selekon der Mieilung

Empfänger Bei Luhmann: „Ego“ 3. Selekon der Annahme/des Verstehens

Abb. 2.4 Luhmann’sches Kommunikationsverständnis

Organisationstheoretiker den Kommunikationsaspekt der Organisation so stark betonen und ihre Theorien weitreichend akzeptiert sind, kann als Anstoß und Rechtfertigung gelten, Geschäftsprozesse primär kommunikationsorientiert zu betrachten.

2.4.4

Organisationen

Komplexe soziale Systeme können in kleinere soziale System gegliedert werden. Diese Struktur eines komplexen sozialen Systems wird als Organisationsstruktur bezeichnet. Nach welchen Kriterien die Aufteilung in kleinere soziale System erfolgt ist subjektiv und hängt von den jeweiligen Absichten ab. Entsprechend der Luhmann’schen Definition eines sozialen Systems kommunizieren die einzelnen sozialen Systeme innerhalb eines komplexeren sozialen Systems. Organisationsstrukturen sind also ein Modell eines komplexeren sozialen Systems. In Abgrenzung zum weiten Verständnis des Begriffs Organisation bei Luhmann oder Habermas hat sich auch ein engeres Verständnis von Organisationen entwickelt. In der Betriebswirtschaft wird unter Organisation das formale Regelwerk eines arbeitsteiligen Systems verstanden. In der Organisationssoziologie bezeichnet sie eine besondere Form von sozialem Gebilde, die sich von anderen sozialen Gebilden wie beispielsweise Familien, Gruppen, Bewegungen oder Netzwerken unterscheiden lässt. Wesentliche Kennzeichen von Organisationen sind, dass Personen sich ihnen anschließen oder sie verlassen können. Darüber hinaus besitzen sie einen Zweck auf den hin sie sich ausrichten. Organisationen haben Regelungen zur Arbeitsteilung wie Spezialisierung nach Verrichtung, Funktion, Objekten oder Raum bzw. entsprechende Mischformen. Diese Arbeitsteilung erfordert die Koordination der einzelnen Tätigkeiten. Als zentrales Instrument der Koordination gilt in der Organisationslehre die Hierarchie. Die hierarchische Koordination wird ergänzt durch Stäbe, Kommissionen, Arbeitskreise etc. Bei einmaligen oder erstmalig zu lösenden Problemen wird die Hierarchie durch eine Projektorganisation ergänzt.

30

2.5

2 Modelle

Modelle der Betriebswirtschaft

Betriebswirtschaftslehre ist die Lehre von den wirtschaftlichen, organisatorischen, technischen sowie finanziellen Abläufen und Strukturen in Unternehmen. Damit ist auch das Geschäftsprozessmanagement ein Teil der Betriebswirtschaft. Denn Geschäftsprozesse dienen dazu die Wirtschaftlichkeit eines Unternehmens zu verbessern, und zwar mit all den zugehörigen Aspekten wie Kundenzufriedenheit, Mitarbeitermotivation, Einbindung von Partnern usw. Für die Strukturierung all dieser Aspekte und zur Analyse ihres Zusammenwirkens hat die Betriebswirtschaft Modelle entwickelt, die bei ihrer Anwendung in das Geschäftsprozessmanagement hineinwirken.

2.5.1

Geschäftsmodell

Ein Geschäftsmodell (Business Model) bezieht sich auf das Gesamtkonzept eines Unternehmens. Es repräsentiert modellhaft die Zusammenhänge, wie dieses für seine Kunden Mehrwert erzeugen und damit nachhaltig Erträge erzielen kann. Neben den angebotenen Produkten und Services geht es u. a. um die Struktur des Unternehmens, die Definition der Zielgruppen (Kunden) und deren Ansprache sowie um die Gestaltung der Geschäftsprozesse. Über dieses Verständnis hinaus gibt es für den Begriff des Geschäftsmodells eine Reihe weiterer Definitionen (Scheer et al. 2003). Ein Geschäftsmodell dient folglich dazu, den Zusammenhang zwischen dem Unternehmen als Handlungssystem und der Wertschöpfung zu verstehen. Es spiegelt wider, wie eine Firma funktioniert und welche Werte sie für bestimmte Zielgruppen erzeugt. Geschäftsmodelle werden im Rahmen einer Unternehmensgründung oder einer Neuausrichtung erstellt. Sie bestehen aus mehreren Teilmodellen, in denen beschrieben wird, welche Ressourcen (Materialien, Informationen usw.) einem Unternehmen als Eingangsgrößen zur Verfügung stehen (müssen), und wie diese Ressourcen bearbeitet und in vermarktungsfähige Produkte oder Dienstleistungen umgeformt werden, die dann zum Kunden transferiert werden, um entsprechende Einnahmen zu erzielen (Osterwalder und Pigneur 2010). Geschäftsmodelle können mehreren Stakeholdern dienen. Die Unternehmensführung kann damit das eigene Geschäft besser verstehen, bestehende Stärken und Schwächen sowie Möglichkeiten zur Weiterentwicklung, Transformation und Verbesserung der Wettbewerbsposition erkennen. Für Investoren ist das Geschäftsmodell oft ein wichtiger Aspekt bei Anlageentscheidungen. Zur Erstellung von Geschäftsmodellen wurde eine Reihe von Instrumenten entwickelt. Das bekannteste ist der Business Model Canvas von Alexander Osterwalder, der in den letzten Jahren große Akzeptanz fand. Wie der Name sagt, geht der Business Model CanvasAnsatz von einem Plakat aus, auf dem die betrachteten Aspekte des Geschäftsmodells visualisiert werden. Der Canvas liefert ein Raster für neun Geschäftsmodellaspekte, welches mit den konkreten Ausprägungen der Aspekte für das betrachtete Unternehmen

2.5 Modelle der Betriebswirtschaft

31

Schlüsselpartner

Schlüsselaktivitäten

Werteversprechen

Kundenbeziehungen

Kundensegmente

Key Partners

Key Activities

Value Proposition

Customer Relationship

Customer Segments

Schlüsselressourcen

Kanäle Channels

Key Ressources

Kostenstruktur

Einnahmequellen

Cost Structure

Revenue Streams

Abb. 2.5 Schema des Business Model Canvas

gefüllt wird (vgl. Abb. 2.5). Im Zentrum steht das Werteversprechen (Produkt oder Dienstleistung). Beim Ausfüllen gilt es jeweils eine Reihe von Fragestellungen zu den neun Aspekten zu beantworten. Die folgenden Ausführungen erläutern die Aspekte kurz und geben eine Auswahl wichtiger dazugehöriger Fragen wieder. 1. Kundensegmente, Zielgruppen: Alle Personen oder Organisationen, für die das betrachtete Unternehmen Werte kreieren will. Zu beantwortende Fragen sind u. a.: • Wer profitiert vom Produkt oder der Dienstleistung? • Welche Kunden sind besonders wichtig? 2. Werteversprechen, Kundenutzen: Für jedes Kundensegment gibt es ein eigenes Werteversprechen, den Kundennutzen. Dies ist eine auf die Bedürfnisse des jeweiligen Segments abgestimmte Kombination aus Produkt und Dienstleistung. Zu beantwortende Fragen sind u. a.: • Welchen Nutzen bzw. Wert hat das Angebot für die Kunden? • Welche Kundenprobleme werden mit den angebotenen Produkten und/oder Dienstleistungen gelöst? 3. Kanäle, Vertriebswege: Dieser Faktor steht für die einzelnen Kanäle, über die mit den Kunden kommuniziert wird und ihnen die versprochenen Werte übermittelt werden. Die Vertriebskanäle bestimmen, wie die Interaktion mit den Kunden abläuft. Kommunikation, Distribution

32

2 Modelle

und Verkaufsstellen bilden Schnittstellen eines Unternehmens zu seinen Kunden. Die Wahrnehmung des Kunden an diesen Berührungspunkten ist dabei zentral und bestimmt den Eindruck, den ein Kunde von einem Unternehmen hat. Zu beantwortende Fragen sind u. a.: • Wie erfahren Kunden von den angebotenen Produkten und Dienstleistungen? • Wie gelangen die Produkte/Dienstleistungen zum Kunden? 4. Kundenbeziehungen: Hier wird beschrieben, welche Form des Umgangs mit den Kunden gepflegt wird. Jedes Unternehmen sollte sich darüber Gedanken machen, welche Arten von Kundenbeziehungen es mit den verschiedenen Zielgruppen eingehen möchte. Dabei hängt die Gestaltung der Kundenbeziehungen nicht nur von der jeweiligen Zielgruppe ab, sondern auch von den damit verbundenen Zielen des Unternehmens (Neukundengewinnung, Bestandskundenpflege, etc.). Zu beantwortende Fragen sind u. a.: • Welche Art von Beziehung erwarten die einzelnen Kundengruppen? • Wie wird die Beziehung zu den Kunden organisiert? • Was kostet die Pflege des Kundenkontakts und was bringt dieser Kunde? 5. Einnahmequellen, Erlösmodelle: Das Unternehmen schafft mit seinem Angebot einen Mehrwert. Die zentrale Frage ist, wie viel der Kunde bereit ist, dafür zu bezahlen. Das Unternehmen trifft eine Entscheidung bezüglich der Preismodelle und der Preisstrategie (Einmalzahlung, Abonnement etc.). Zu beantwortende Fragen sind u. a.: • Wofür und wie viel sind Kunden wirklich bereit für das Angebot zu zahlen? • Wie viel trägt jede der einzelnen Umsatzquellen zum Gesamtumsatz bei? • Wie würden die Kunden gerne zahlen? 6. Schlüsselressourcen: Zur Erstellung des Angebots sind in jeder Unternehmung bestimmte Ressourcen erforderlich. Diese können sich im eigenen Besitz befinden, aber auch gemietet oder von strategischen Partnern zur Verfügung gestellt werden. Zu beantwortende Fragen sind u. a.: • Welche physischen Ressourcen (Räumlichkeiten, Produktionsmaschinen) werden benötigt, um ein Produkt oder einen Service erstellen und anbieten zu können? • Welche intellektuellen Ressourcen (Wissen, Patente, Partnerschaften, Kundenstamm) werden benötigt? • Welche personellen Ressourcen (Team) werden benötigt? • Welche finanziellen Ressourcen (verfügbares Kapital, Sicherheiten) werden benötigt? • Wie können die nötigen Ressourcen beschafft und vorgehalten werden?

2.5 Modelle der Betriebswirtschaft

33

7. Schlüsselaktivitäten: Schlüsselaktivitäten sind die für die Leistungserstellung und -verwertung nötigen Tätigkeiten, z. B. Produktion, Vertrieb. Zu beantwortende Fragen sind u. a.: • Welche Schlüsselaktivitäten müssen ausgeführt werden, um ein Produkt oder einen Service anbieten und damit den Kundennutzen realisieren zu können? • Welche Aktivitäten für welche Vertriebskanäle? • Welche Aktivitäten für welche Kundenbeziehungen? 8. Schlüsselpartner: Schlüsselpartner sind Geschäftspartner, die wichtige Ressourcen für die Realisierung des Geschäftsmodells bereitstellen. Mit ihnen gehen Unternehmen oft strategische Allianzen ein. Beispiele sind Lieferanten, Service Provider o. Ä. Zu beantwortende Fragen sind u. a.: • Wer sind Schlüsselpartner und was tun diese für das Unternehmen? • Welche Schlüsselressourcen werden von welchen Partnern zur Verfügung gestellt? 9. Kostenstruktur: Die Kostenstruktur gibt Aufschluss über die wichtigsten Kostenfaktoren eines Geschäftsmodells. Zu beantwortende Fragen sind u. a.: • Was sind die größten und wichtigsten Kostenfaktoren in dem Geschäftsmodell? • Welche Schlüsselressourcen/Schlüsselaktivitäten sind die teuersten? Aus den einzelnen Feldern eines Geschäftsmodells lassen sich Kennzahlen und die zugehörigen Zielwerte für Geschäftsprozesse ableiten. Umgekehrt können die Kennzahlen und Zielwerte den Entwurf der Prozesse beeinflussen. Liegt der Fokus auf niedrigen Preisen, werden Prozesse anders aussehen, als wenn das Geschäftsmodell eher auf hoher Qualität ausgerichtet ist.

2.5.2

Balanced Scorecard

Die Balanced Scorecard (BSC) wurde Anfang der 1990er-Jahre von Kaplan und Norton vorgestellt (Kaplan und Norton 1997). Sie ist ein Bindeglied zwischen dem Geschäftsmodell, der Strategiefindung und deren Umsetzung. Unter Strategie werden in der Wirtschaft klassisch die (meist langfristig) geplanten Verhaltensweisen der Unternehmen zur Erreichung ihrer Ziele verstanden. Eine BSC beginnt bei der Vision und Strategie eines Unternehmens und definiert auf dieser Basis die kritischen Erfolgsfaktoren (KEF) mit Hilfe von Kennzahlen und dazugehörigen Zielwerten. Die Vision eines Unternehmens beschreibt das langfristige, ambitionierte Ziel, das eine Organisation bzw. Unternehmen anstrebt. Typische Visionen sind Formulierungen wie „Wir wollen Marktführer in unserem Marktsegment werden“ oder „Wir wollen das profitabelste Unternehmen in unserem Marktsegment werden“.

34

2 Modelle

Abb. 2.6 Perspektiven der Balanced Scorecard

Die Kennzahlen fördern die Zielsetzung und Leistungsfähigkeit in kritischen Bereichen der Strategie, um die Vision zu erreichen. Die BSC ist daher ein Management-System, das aus der Vision als Teil des Geschäftsmodells und der Strategie zur Umsetzung des Geschäftsmodells abgeleitet wird, und die wichtigsten Aspekte des Unternehmens widerspiegelt. Das BSC-Konzept unterstützt strategische Planung und Implementierung durch eine Bündelung der Maßnahmen aller Einheiten eines Unternehmens auf der Basis eines gemeinsamen Verständnisses seiner Ziele und durch einen leichteren Zugang zur Bewertung und Fortschreibung der Strategie. Da traditionelles, rein auf finanzielle Kennzahlen aufgebautes Management den Anforderungen von Unternehmen im Informationszeitalter an effektive Planungswerkzeuge nicht mehr genügt, haben Kaplan und Norton für die BSC vier Perspektiven eingeführt, aus deren Blickwinkel die Aktivitäten eines Unternehmens umfassend bewertet werden können. Für jede Perspektive werden Ziele, Kennzahlen, Vorgaben und Maßnahmen definiert (vgl. Abb. 2.6).

2.5.3

Total Quality Management und EFQM

Der Begriff des Total Quality Management (TQM) steht für die Optimierung der Qualität von Produkten und Dienstleistungen eines Unternehmens in allen Funktionsbereichen und auf allen Ebenen durch Mitwirkung aller Mitarbeiter. Optimierung der Qualität bedeutet dabei, weder mit gegebenem Aufwand das höchste Qualitätsniveau zu erreichen, noch

2.5 Modelle der Betriebswirtschaft

35

die Qualität ohne Rücksicht auf Kosten zu steigern. Vielmehr geht es darum, auf die Interessen des Kunden zu fokussieren und Qualität an der Erfüllung seiner Anforderungen festzumachen. Welche Anforderungen ein Unternehmen dabei an sich stellt, und durch welche Positionierung gegenüber dem Kunden es sich den größten und nachhaltigsten Geschäftserfolg verspricht, entscheidet die Führung eines Unternehmens selbst. Diese Positionierung ist nicht statisch. Erkenntnisse zu Kundenwünschen und zu den Vorgehensweisen zur Erfüllung dieser Wünsche erfordern eine permanente Anpassung des Unternehmens. Um TQM zu etablieren bietet die European Foundation for Quality Management(EFQM) Organisationen Hilfestellung für den Aufbau und die kontinuierliche Weiterentwicklung eines umfassenden Managementsystems. Abb. 2.7 zeigt die Struktur des EFQM-Ansatzes. Diese Struktur dient zum einen als Werkzeug, um ein TQM aufzubauen und zum anderen dazu, durch ein umfassendes Bewertungssystem Verbesserungspotenziale zu ermitteln und den Geschäftserfolg zu steigern. Als Befähiger gelten im EFQM-Modell die Methoden und Konzepte, die eingesetzt werden, um die Ergebnisse zu erreichen, die in der rechten Hälfte der Abbildung dargestellt sind. Die Prozentwerte in der Darstellung geben an, in wieweit die einzelnen Aspekte in die Gesamtbewertung eines Unternehmens einfließen.

Abb. 2.7 EFQM-Struktur

36

2 Modelle

Bei den Befähigern geht die EFQM davon aus, dass Prozesse den größten Einfluss auf die Ergebnisse auf der rechten Seite haben. Damit liefert das Modell gute Ansatzpunkte für die Identifikation von Kennzahlen und deren Zielwerte. Neben der Möglichkeit ein Managementsystem aufzubauen bietet EFQM auch ein sehr ausgefeiltes Konzept, dessen Stand der Entwicklung zu bewerten. Durch einen umfangreichen Fragenkatalog kann eine Rundumbewertung einer Organisation erfolgen. Die Bewertung kann durch Mitarbeiter der Organisation selbst oder durch externe Berater erfolgen. Die besten Organisationen in Europa erreichen bei einer solchen Bewertung rund 750 von maximal 1000 erzielbaren Punkten.

2.5.4

EN ISO 9001

Eine im Vergleich zu TQM abgeschwächte Form eines Qualitätsmanagements bildet der Standard EN ISO 9001. Er beschreibt Minimalanforderungen an ein Qualitätsmanagementsystem. Abb. 2.8 illustriert die Grundlagen des Standards. Die Verantwortung der Leitung bedeutet, dass diese definiert, welche Kundenforderungen erfüllt werden und welche Qualitätspolitik dabei verfolgt wird. Die Umsetzung der Qualitätspolitik wird geplant und die entsprechenden Verantwortlichkeiten und Befugnisse in der Organisation dafür festgelegt. In der Verantwortung der Leitung liegt auch die Bewertung des QM-Systems in geplanten Abständen und insbesondere unter Berücksichtigung der Kundenrückmeldungen. Die Unternehmensführung muss außerdem die notwendigen Ressourcen wie Personal, Infrastruktur und eine adäquate Arbeitsumgebung bereitstellen. Den Kern eines EN ISO 9001-konformen QM-Systems bilden die Prozesse zur Realisierung der Produkte und der zugehörigen kundenbezogenen Dienstleistungen. Aufgaben umfassen die Planung und Definition von geeigneten Prozessen für die Entwicklung und Herstellung von Produkten, die Beschaffung von Inputs usw. Die Hilfsmittel zur

Abb. 2.8 EN ISO 9001

2.5 Modelle der Betriebswirtschaft

37

Überwachung der Produktherstellung und der Produktqualität müssen regelmäßig auf ihre Tauglichkeit überprüft werden. Die Ausführung der Prozesse muss durch Messungen und Analysen von Kennzahlen laufend überwacht werden, um bei Abweichungen entsprechende Verbesserungsmaßnahmen einleiten zu können. EN ISO 9001 stellt also einen Rahmen für das Geschäftsprozessmanagement bereit. Die Ausführungen zeigen, dass es genau genommen keinen Unterschied zwischen Geschäftsprozess- und Qualitätsmanagement gibt. Ohne Geschäftsprozessmanagement gibt es kein Qualitätsmanagement und umgekehrt. Die vergleichsweise niedrigeren Anforderungen von EN ISO 9001 äußern sich in der Tatsache, dass ein Unternehmen mit einem (nur) EN ISO 9001-konformen Qualitätsmanagementsystem etwa 300 Punkte bei einer EFQM-Bewertung erreichen kann.

2.5.5

Value Networks

Das Konzept der Value Networks stammt von Verna Allee (Allee 2015). Basierend auf der Theorie adaptiver komplexer Systeme schaffen sie die Grundlage für effektive Wertschöpfung auf Basis gestaltbarer Interaktion beteiligter Stakeholder entsprechend ihrer organisationalen Funktion(en), und damit die Basis für prozessgeleitete Transformation von Organisationen (Fleischmann et al. 2015; Stary 2014). Unter einem Value Network versteht man Rollen und Personen, die untereinander sogenannte Tangibles und Intangibles austauschen (siehe auch 6.1.3.1 Tangible Wertflüsse sind materielle Wertflüsse zwischen Rollen und Personen und entsprechen dem Austausch von Waren, Dienstleistungen, Umsatzerlösen usw.). Tangible Wertflüsse repräsentieren Transaktionen, die auf Verträgen basieren. Intangible Wertflüsse sind ein Zusatznutzen durch den Fluss von Wissen, sie sind nicht vertraglich fixiert oder kostenpflichtig. Intangible Wertflüsse sind z. B. strategische Informationen, Planungswissen sowie bestehende emotionale Komponenten wie gegenseitiges Vertrauen, gemeinsame Interessen, Wissensbedarf, Sicherheit usw. Value Networks sollen Beteiligten und Organisationsentwicklern durch die Sichtbarmachung und gestalterische Handhabung wechselseitiger tangibler und intangibler Leistungsflüsse (Transaktionen) befähigen, soziale und fachliche Bezüge von Interaktion in organisationalen Systemen mit zu bestimmen bzw. aktiv zu gestalten. Abb. 2.9 zeigt ein einfaches Value Network. Der Kunde gibt einen Wert Bestellung als einen tangiblen Wertfluss an den Lieferanten. Dieser tangible Wertfluss wird begleitet vom intangiblen Wertfluss Vertrauen. Der Kunde und die Logistikfirma sind mit dem tangiblen Wertfluss Lieferung verbunden usw. Die Nummern an den einzelnen Transaktionen drücken aus, in welcher Reigenfolge sie ausgeführt werden. Organisationen erbringen Leistungen als Ergebnis ihrer Aktivitäten, die schließlich zur Wertschöpfung eines Unternehmens oder einer Institution beitragen. Um diese Leistungen zu erfassen und sichtbar zu machen, empfiehlt sich eine austauschorientierte Sicht auf Organisationen. Es ergibt sich dabei zumeist eine netzwerkartige Struktur, in der die Rollen

38

2 Modelle

Abb. 2.9 Schema eines Value Network

innerhalb einer Organisation sowie deren Übertragungs- bzw. Kommunikationskanäle im Vordergrund stehen. Damit kann der Übergang zu einem kommunikationsorientierten Geschäftsprozessmanagement erfolgen.

2.6

Modelle der Wirtschaftsinformatik

Modelle der Wirtschaftsinformatik kombinieren Aspekte aus dem wirtschaftlichen und sozialen Bereich und der Informatik, um daraus Anforderungen für Informationssysteme abzuleiten. Die Modelle dienen überwiegend der Beschreibung von sozio-technischen Systemen. Die soziale Komponente deckt die Aspekte um die Mitarbeiter und Partner ab. Die technische Dimension betrifft die Sachverhalte der Informatik. Wichtig ist dabei, dass entsprechende Modelle die Wechselwirkung zwischen den beiden Domänen betrachten, insbesondere die Mensch-Maschine-Interaktion. Im Gegensatz zu rein technischen Systemen, die als deterministisch betrachtet werden, können sozio-technische Systeme aufgrund der Mitwirkung von sozialen Komponenten auch nicht-deterministisch, und damit komplex, sein. Wir beschränken uns hier auf die Behandlung von Frameworks für Unternehmensarchitekturen und für IT-Management. Erstere entsprechen mit ihrer Verknüpfung der fachlichen und technischen Dimensionen von Organisationen genau dem Charakter der Wirtschaftsinformatik als Querschnittsdisziplin und sind von zentraler Bedeutung für das Prozessmanagement. Frameworks für das IT-Management beziehen sich im Wesentlichen auf das IT-ServiceManagement und damit verbundene Aspekte wie Governance und Compliance. Die bekanntesten Vertreter sind die IT Infrastructure Library (ITIL®) (itSMF 2019) und

2.6 Modelle der Wirtschaftsinformatik

39

die Control Objectives for Information and related Technology (COBIT). Wegen seiner vergleichsweise weiten Verbreitung in der Praxis gehen wir näher auf ITIL® ein und verweisen für weiterführende Informationen zu COBIT auf die einschlägige Website (ISACA 2019).

2.6.1

Unternehmensarchitekturen

Das Verständnis von Architektur im Kontext von Unternehmen deckt sich mit der ursprünglichen Bedeutung des Architekturbegriffs. Dieser bezeichnet in vielen Fachgebieten die grundlegende Organisation eines Systems mit seinen Komponenten und deren Beziehungen zueinander und zu ihrer Umgebung. Konkret beschreibt und verknüpft eine Unternehmensarchitektur (Enterprise Architecture), wie bereits in Abschn. 1.4 angesprochen, die fachlichen und technischen Elemente des Unternehmens. Letztere umfassen insbesondere die IT-Landschaft. Sowohl die Gesamtarchitektur als auch ihre Teile werden mit Modellen beschrieben. Die Palette der dafür eingesetzten Modelltypen reicht vom Geschäftsmodell über Organigramme, Datenund Prozessmodelle auf der fachlichen Ebene bis hin zu Datenbankmodellen, Algorithmen und Programmen in der technischen Schicht. Wie für Geschäftsmodelle gibt es auch für die Modellierung von Unternehmensarchitekturen zahlreiche Rahmenwerke, die den Verantwortlichen Orientierung geben und die Arbeit erleichtern sollen. Dirk Matthes (Matthes 2011) hat mehr als 40 Frameworks mit unterschiedlichem Detailierungsgrad, Schwerpunkt und Bekanntheitsgrad identifiziert. Wir beschränken uns auf die Behandlung von vier einschlägigen Vertretern: Das Zachman-Framework und The Open Group Architecture Framework (TOGAF) mit seiner Ergänzung Architecture Animate (ArchiMate) wurden in Umfragen als wesentliche Rahmenwerke genannt (Matthes 2011). Die Architektur Integrierter Informationssysteme (ARIS) ist im deutschsprachigen Raum in der Praxis weit verbreitet und hat signifikante Bedeutung im Rahmen des Prozessmanagements.

2.6.1.1 Zachman-Framework Das von John A. Zachman 1992 in seiner erweiterten Form vorgestellte Framework stellt ähnlich dem Business Modell Canvas ein Strukturraster dar, das der Anwender mit den Fakten für sein Unternehmen anreichern muss. Es besteht aus einer Matrix mit verschiedenen Perspektiven in den Zeilen und Abstraktionen zu jeder Perspektive in den Spalten. Abb. 2.10 zeigt eine verdichtete Darstellung, ein detailliertes Bild findet sich auf der Website von Zachman International.1

1 www.zachman.com.

40

2 Modelle

Abb. 2.10 Zachman-Framework

Die Perspektiven in den Zeilen haben folgende Bedeutung: • Planer: Zielsetzung des Unternehmens, externe Anforderungen und Einflüsse, Geschäftsmodell • Besitzer: Anforderungen an Daten, Abläufe, Strukturen usw. zur Unternehmensführung • Designer: Systementwurf und Systemstruktur zur Umsetzung der Anforderungen • Builder: Umsetzung des Systementwurfs • Programmierer: Bereitstellen der technischen Infrastruktur • Benutzer: Betriebsverantwortliche zur Sicherstellung der Funktionsfähigkeit In den Spalten finden sich die Fragen, die das Unternehmen beantworten muss: • Was (Inventar): Was für Objekte, Ausrüstungen, Daten, Informationen etc. werden benötigt? • Wie (Funktionen und Prozesse): Wie arbeitet das Unternehmen, z. B. wie sehen die Geschäftsprozesse aus? • Wo (Standorte, Netzwerk); Wo sind die Standorte des Unternehmens? • Wer (Menschen): Wer sind die Menschen, die das Unternehmen am Laufen halten? Welche Geschäftseinheiten gibt es und wie sieht die Organisationsstruktur aus? • Wann (Zeit): Wann werden Geschäftsprozesse instanziiert und ausgeführt? Was sind die Zeitpläne für das Geschäft? • Warum (Motivation): Warum betreiben wir das Geschäft so wie wir es betreiben? Was sind die Treiber des Geschäfts? Hier fließen Aspekte des Geschäftsmodells ein. Zachman sieht vor, dass für jede Zelle der Tabelle ein geeignetes Modell entwickelt wird. So gesehen handelt es sich bei seinem Framework um ein Modell für eine Menge von Modellen, die verschiedene Aspekte eines Unternehmens genauer betrachten. Die Nutzer können bei den Reihen und Spalten durch andere Schwerpunktsetzung vom Original abweichen. Diese Flexibilität ist eine Stärke des Modellrahmens. Er enthält aber

2.6 Modelle der Wirtschaftsinformatik

41

keine Vorgehensweise oder Methodik zur Definition einer konkreten Unternehmensarchitektur. Prozesse für deren Entwicklung oder Transformation müssen sich die Anwender anderweitig erschließen oder gänzlich selbst gestalten.

2.6.1.2 The Open Group Architecture Framework (TOGAF) TOGAF ist das Rahmenwerk der Open Group zur Entwicklung von Unternehmensarchitekturen einschließlich der Geschäftsprozesse. Während das Zachman-Framework die zu betrachtenden Objekte betont und kaum Unterstützung für den Architekturentwicklungsprozess bietet, fokussiert TOGAF auf die Vorgehensweise zur Modellerstellung. Es stellt Methoden und Werkzeuge zur Verfügung, die bei Einführung, Erstellung, Gebrauch und Weiterentwicklung von Unternehmensarchitekturen helfen. TOGAF unterscheidet bei der Beschreibung vier Teilarchitekturen: • Business Architecture: Fachliche Aspekte der Unternehmensarchitektur • Data Architecture: Logische und physische Strukturen der Daten und Ressourcen für deren Management. • Application Architecture: Verwendete Anwendungssysteme und deren Beziehungen untereinander sowie ihre Relevanz für das Geschäft des Unternehmens. • Technology Architecture: Anforderungen an die Software und Hardware für das Management der Daten und die Ausführung der Anwendungssysteme. Dies schließt z. B. Laufzeitumgebungen, Netzwerke, Middleware und sonstige Betriebsinfrastrukturen ein. Das TOGAF-Rahmenwerk setzt sich aus folgenden Komponenten zusammen: • Architecture Development Method (ADM) Methode und Vorgehensweise zur Entwicklung einer Unternehmensarchitektur • ADM Guidelines and Techniques Satz von Hilfsmitteln und Richtlinien, die die Anwendung des ADM unterstützen (z. B. Hilfsmittel für die iterative Verwendung des ADM) • Architecture Content Framework Strukturmodell um die Ergebnisse, die mit dem ADM erzeugt werden, einheitlich und konsistent zu definieren, zu strukturieren und darzustellen • Enterprise Continuum Modell zur Strukturierung eines möglichen Repository, das die jeweiligen Architekturen und die möglichen Lösungen wie Modelle, Muster, Architekturbeschreibungen etc. enthalten kann • Reference Models Grundmodelle, an denen sich spezifische Modelle für ein Unternehmen orientieren können. Dies sind das Technical Reference Model (TRM) und das Integrated Information Infrastructure Model

42

2 Modelle

Abb. 2.11 Architecture Development Method von TOGAF

• Architecture Capability Framework Verschiedene Referenzmaterialien für die Entwicklung bestimmter Architekturmodelle. Die Architecture Development Method (ADM) bildet als iteratives Prozessmodell den Kern von TOGAF (vgl. Abb. 2.11). Damit werden alle Architekturartefakte erzeugt. ADM kann auf mehreren Ebenen angewendet werden, so dass die Architekten unterschiedliche Detailierungsstufen der Unternehmensarchitektur definieren können. Mit Hilfe der anderen Komponenten werden die Ergebnisse dann beschrieben, strukturiert und abgelegt. Die Phasen der ADM sind: – Vorbereitungsphase (Preliminary Phase) Hier werden das organisatorische Umfeld und die verwendeten Rahmenwerke, Methoden, Unterstützungswerkzeuge sowie wichtige Prinzipien festgelegt. – Phase A: Architekturvision (Architecture Vision) Hier werden die Ziele und die Beteiligten bei der Aktualisierung der Unternehmensarchitektur festgelegt und eingebunden. – Phase B: Geschäftsarchitektur, Geschäftsmodell (Business Architecture) Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Es werden die gewünschten Sichten festgelegt und die dazu geeigneten Werkzeuge ausgewählt. – Phase C: IS-Architektur (Information System Architecture) Hier werden für die Anwendungs- und Informations-/Daten Architektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Anwendungen und Datenmodelle verwendet.

2.6 Modelle der Wirtschaftsinformatik

43

– Phase D: Technologiearchitektur (Technology Architecture) Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Hardwaresysteme beschrieben. – Phase E: Möglichkeiten und Lösungen (Opportunities and Solutions) Hier werden die Vorhaben festgelegt, welche die Transformation aus der IstSituation zum Sollzustand durchführen. – Phase F: Migrationsplanung (Migration Planning) Hier wird die Überführung von einem Ist-Zustand in einen Sollzustand geplant. – Phase G: Implementierungsregeln (Implementation Governance) Hier wird die Implementierung in den Sollzustand durchgeführt und überwacht. – Phase H: Änderungsmanagement (Architecture Change Management) Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für den nächsten Durchlauf des ADM dienen. • Anforderungen (Requirements Management) Das Anforderungsmanagement treibt den ADM-Prozess kontinuierlich und steht deshalb im Zentrum.

2.6.1.3 Architecture Animate (ArchiMate) Architecture Animate, kurz ArchiMate, ist die Bezeichnung einer von der Open Group veröffentlichten offenen und unabhängigen Modellierungssprache für Unternehmensarchitekturen.2 Sie bietet Instrumente, die es Enterprise-Architekten ermöglichen, die Beziehungen zwischen Geschäftsbereichen und deren Entwicklung zu beschreiben, zu analysieren und zu visualisieren. Die ArchiMate-Sprache ermöglicht die Beschreibung der Struktur und des Ablaufs von Geschäftsprozessen, von Organisationsstrukturen, Informationsflüssen, IT-Systemen und der technischen Infrastruktur. Die Beschreibungen helfen den Beteiligten, Veränderungen von Architekturelementen und deren Beziehungen zu konzipieren, die Folgen zu bewerten und zu kommunizieren. Abb. 2.12 zeigt das ArchiMate-Rahmenwerk. Die ersten drei Spalten entsprechen den Grundkonzepten von ArchiMate: • Passive Strukturelemente (Passive Structure Elements) Passive Strukturelemente sind die Objekte, auf denen die Aktionen aus dem Verhalten (Verhaltenselemente) ausgeführt werden. Im Allgemeinen sind dies Informationsobjekte, aber auch physikalische Objekte können als passive Strukturelemente modelliert werden. • Aktive Strukturelemente (Active Structure Elements) Aktive Strukturelemente sind Elemente, die Handlungen ausführen können. Beispiele sind Menschen, Anwendungen, Rechnerknoten o.Ä. Die Handlungen können über

2 https://www.opengroup.org/archimate-forum/archimate-overview.

44

2 Modelle

Passive structure

Behavior

Acve Strucure

Strategy

ressourcen

Business

Business objects

Business services, funcons and processes

Business actors and roles

Applicaon

Data objects

Applicaon services, funcons and processes

Applicaon components and interfaces

Technology

arfacts

Technology services, funcons and processes

Devices, system soware, communicaoon networks

Physical

material Work packages

plaorms

Implementaon and deliverables migraon

Movaon

ressourcen

Stakeholders, drivers, goals, principles and requirements

Abb. 2.12 ArchiMate Architectural Framework

Schnittstellen (Interfaces) angestoßen werden, die auch die Ergebnisse zur Verfügung stellen. • Verhaltenselemente (Behavior Elements) Verhaltenselemente repräsentieren die dynamischen Aspekte eines Unternehmens. Ein Service ist das von außen sichtbare Verhalten des Systems, das diesen Service erbringt. Die Services werden über die entsprechenden Schnittstellen verwendet. Schnittstellenereignisse stoßen die aktiven Strukturelemente an, welche dann die zugehörige Servicefunktion ausführen. Diese drei Modellfragmente entsprechen den Grundelementen von natürlichen Sprachen: Subjekt, Prädikat bzw. Verb und Objekt. Sie werden auf insgesamt sechs Ebenen betrachtet: • Strategieebene (Strategy Layer) In der Motivation wird beschrieben, was ein Unternehmen erreichen möchte. In den Strategiekonzepten wird auf übergeordneter Ebene beschrieben, wie ein Unternehmen seine Ziele erreichen möchte. • Geschäftsebene (Business Layer) Mit den Elementen des Business Layer können Produkte und Services beschrieben werden, die ein Unternehmen extern zur Verfügung stellt. Die Geschäftsebene zeigt, wie das Unternehmen diese Produkte und Services realisiert, und soll bei der Analyse der Unternehmensstruktur helfen. • Applikationsebene (Application Layer) In der Anwendungsebene wird die Unterstützung der Geschäftsebene durch Anwendungen und Daten dargestellt. • Technologieebene (Technology Layer) Auf der Technologieebene wird die Infrastruktur beschrieben, welche benötigt wird, um Anwendungen zu realisieren. Dies sind im Wesentlichen die benötigten Hardwareund Softwarekomponenten.

2.6 Modelle der Wirtschaftsinformatik

45

• Physikalische Ebene (Physical Layer) In dieser Ebene wird auf das Zusammenwirken von IT und den physischen Komponenten wie Maschinen, Sensoren und Aktoren fokussiert. • Implementierung und Migration (Implementation and Migration Layer) Das Implementierungs- und Migrationskonzept beschreibt, wie eine definierte Architektur realisiert werden soll. Insbesondere werden darin die Arbeitspakete für die Umsetzung beschrieben. Die Zellen der Tabelle enthalten also die Kernelemente für die aktiven und passiven Strukturen sowie für das Verhalten auf der jeweiligen Ebene. Die Spalte Motivation beschreibt die Gründe für den Entwurf oder die Änderung eines Unternehmensmodells. Diese beeinflussen die Modellbildung und geben ihr die entsprechende Richtung. ArchiMate wird als Ergänzung und Konkretisierung von TOGAF gesehen. TOGAF beschreibt den Prozess für die Definition und Beschreibung einer Unternehmensarchitektur (Unternehmensmodell), allerdings enthält es keine Beschreibungssprachen für die jeweiligen Teilmodelle. ArchiMate soll diese Lücke schließen. Es bietet neben dem gezeigten Rahmenwerk für die zu entwickelnde Architektur auch Sprachen, um die Aspekte in den einzelnen Ebenen auszudrücken. Abb. 2.13 zeigt wie die einzelnen Schritte in der Architecture Development Method von TOGAF mit den Schichten von ArchiMate zusammenhängen.

Abb. 2.13 Zusammenhang von ArchiMate-Ebenen und TOGAF ADM

46

2 Modelle

2.6.1.4 Architektur Integrierter Informationssysteme (ARIS) Die Architektur Integrierter Informationssysteme (ARIS) ist ein Rahmenwerk zur Definition von Unternehmensmodellen. Es umfasst die Daten-, Funktions-, Organisations-, Steuerungs- und Leistungssicht. Für jede Sicht sieht ARIS eine Reihe von Modelltypen für die Dokumentation vor. • Datensicht Die Datensicht umfasst die betriebswirtschaftlich relevanten Geschäfts- oder Informationsobjekte und deren Beziehungen untereinander, das heißt alle Daten, die im Zusammenhang mit den Aktivitäten eines Unternehmens stehen. Informationsobjekte umfassen sowohl Zustände wie Artikel- oder Kundenstatus als auch Ereignisse wie „Kundenauftrag ist eingetroffen“ oder „Fertigungsauftrag wurde ausgelöst“. Einschlägiger Modelltyp ist das Entity Relationship Model (ERM). • Funktionssicht Die Funktionssicht beschreibt die betriebswirtschaftlich relevanten Tätigkeiten (Funktionen, Aktivitäten) sowie ihre hierarchischen Beziehungen. Untergeordnete Funktionen sind Teilfunktionen der übergeordneten Funktion. Die Funktionen führen Operationen auf den in der Datensicht beschriebenen Objekten aus. Funktionen werden in der Praxis mit Funktionsbäumen modelliert. • Organisationssicht In der Organisationssicht wird die Organisationsstruktur, das heißt die personellen Ressourcen, eines Unternehmens und deren typischerweise hierarchischen Beziehungen in einer Aufbauorganisation modelliert. Das Organigramm ist hierfür als Modelltyp üblich. • Steuerungssicht Die Steuerungssicht stellt den zeitlich-sachlogischen Zusammenhang zwischen den einzelnen betrieblichen Tätigkeiten her. Sie führt die Daten-, Funktions- und Organisationssicht zusammen und nimmt damit eine zentrale, integrierende Rolle ein. Die Steuerungsschicht wird deshalb auch Prozesssicht genannt. Wesentlicher Modelltyp ist die Ereignisgesteuerte Prozesskette (EPK). • Leistungssicht In der Leistungssicht werden die Eingaben und Ergebnisse des beschriebenen Geschäftsprozesses in der Regel mithilfe von Produktbäumen beschrieben. Die Sichten, dafür typische Modelltypen und ihr Zusammenhang sind in Abb. 2.14 dargestellt. Das Bild macht auch deutlich, dass ARIS mit der integrierenden Steuerungssicht die Geschäftsprozesse, insbesondere mit der Abfolge der Aktivitäten, in den Mittelpunkt der Betrachtung stellt. Orthogonal zu der durch die Sichten vorgenommenen Strukturierung differenziert ARIS in Anlehnung an das Software Engineering die Abstraktionsebenen Fachkonzept,

2.6 Modelle der Wirtschaftsinformatik

47

Abb. 2.14 Sichten und einschlägige Modelltypen in ARIS

DV-Konzept und Implementierung. Dies zeigt die Nähe der mit ARIS entwickelten Modelle zur Informationstechnik. Für die Lösung einer betrieblichen Problemstellung wird ein fachliches Modell erstellt und in ein entsprechendes DV-Konzept (DV-Modell) überführt. Dieses dient schließlich als Basis für die konkrete technische Umsetzung. • Fachkonzept Im Fachkonzept werden die Sachverhalte der betrieblichen Problemstellung beschrieben. Auf dieser Ebene werden Datenmodelle, Funktionsmodelle, Organigramme, Wertschöpfungsketten bzw. Ereignisgesteuerte Prozessketten (EPKs) und Produktmodelle eingesetzt. • DV-Konzept Im DV-Konzept wird spezifiziert, wie das Fachkonzept DV-technisch umzusetzen ist. Auf dieser Ebene werden Datenbankmodelle (Datensicht), Struktogramme (Funktionssicht), Netztopologien (Organisationssicht) und Trigger-Mechanismen (Steuerungssicht) betrachtet. Der Zweck des DV-Konzepts ist eine Anpassung des Fachkonzepts an die Anforderungen der Informationstechnik. • Implementierung Auf dieser Ebene wird das DV-Konzept in ein ausführbares Softwaresystem umgesetzt. Auf dieser Abstraktionsstufe werden Datenbeschreibungssprachen (Datensicht), Programme (Funktionssicht), Netzwerkprotokolle (Organisationssicht) und die Programmsteuerung (Steuerungssicht) betrachtet.

48

2 Modelle

Abb. 2.15 ITIL®-Prozessgruppen

2.6.2

Framework für IT-Service-Management: ITIL®

Die IT Infrastructure Library (ITIL®) ist eine Sammlung vordefinierter Prozesse, Funktionen und Rollen, wie sie typischerweise in jeder IT-Infrastruktur mittlerer und großer Unternehmen vorkommen. Die praktische Zuweisung der Tätigkeiten erfolgt anhand von Rollen und Funktionen. Es handelt sich dabei um Good-Practice-Vorschläge, die an die Bedürfnisse des Unternehmens angepasst werden müssen. Inzwischen wurde die Sammlung ergänzt durch ISO 20000:2005, ein ITIL®-basiertes Zertifizierungsmodell für Organisationen. ITIL® umfasst fünf Kernbände mit derzeit insgesamt 37 Kernprozessen. Abb. 2.15 zeigt die Struktur von ITIL®. Die fünf Kernbände orientieren sich am Service Live Cycle. Ausgehend von der Servicestrategie mit den Prozessen Strategiefindung, Finanzmanagement, Serviceportfoliosteuerung und Nachfragesteuerung wird über die Prozessgruppen der Serviceentwicklung und der Serviceinbetriebnahme schließlich die Dienstleistung mit den Prozessen der Gruppe Serviceerbringung erbracht. Die Prozeduren unterliegen der permanenten Verbesserung. Weitere Bücher wie „Software Asset Management“, „Small-Scale Implementation“ oder „Building an ITIL®-based Service Management Department“ ergänzen die Kernpublikationen. Damit bietet ITIL® umfassende Unterstützung bei der Entwicklung eines Prozesssystems für den IT-Bereich einer Organisation.

2.7

Modelle der Informatik

Modelle der Informatik beziehen sich auf Datenstrukturmodelle und Abläufe in Computersystemen sowie wesentliche Aspekte wie Sicherheit, Robustheit etc.

2.7 Modelle der Informatik

49

Diese Modelle dienen zum einen zur Abbildung eines betrachteten Realitätsausschnitts, um eine Aufgabe mit Hilfe der Informationsverarbeitung zu lösen. Sie beziehen sich auf ein abgegrenztes Problemfeld oder bestimmte Einsatzbereiche von Computersystemen. Hierunter fallen Modelle, die Daten und die darauf ablaufenden Operationen im Fokus haben, sowie Modelle, die mehr die Gesamtstruktur von komplexen Programmen, also deren Architektur, betrachten. Diese beiden Modellkategorien werden auch Modelle zum Programmieren im Kleinen bzw. Modelle zum Programmieren im Großen genannt. Neben diesen zentralen Modellkategorien der Informatik gibt es weitere Modelle, die flankierende Aspekte betrachten, wie Zugriffsmodelle, Sicherheitsmodelle usw. Diese sind nicht Gegenstand der weiteren Ausführungen. Vielmehr erläutern wir in den folgenden Abschnitten einige für das Geschäftsprozessmanagement wesentliche Modellkonzepte. Ein allgemeiner Überblick zu Modellen in der Informatik findet sich in Embley und Thalheim (2011).

2.7.1

Information

Information ist der zentralere Aspekt der Datenverarbeitung, die deshalb auch Informationstechnologie oder IT genannt wird. Information und Informationssysteme sind Modelle, die ein Objekt der realen Welt gemäß den Vorstellungen eines oder mehrerer Subjekte repräsentieren. Die Vorstellungen des Subjekts orientieren sich dabei am beabsichtigten Verwendungszweck. Beispielsweise werden Gegenstände in einem Lager durch ihre Eigenschaften beschrieben wie Teilenummer, Maße, Gewicht usw. Verschiedene Anwender verwenden unterschiedliche Ausschnitte aus dem Modell: Der Einkauf blickt auf Informationen wie Einkaufspreis und Bestellgrenze, während den Lagerarbeiter eher die Maße und der Lagerplatz interessieren. Die Modellierung der Objektrealität kann deshalb als Interpretation durch die verwendenden Handelnden (Subjekte) wie Einkauf oder Lagerist verstanden werden. Information ist dann das Ergebnis und der Grund einer Interpretation; Sie kann aber auch selbst wiederum Objekt und damit Interpretations- und Modellierungsgegenstand sein. Dieses Verhältnis zwischen Subjekt, Information (Modell) und Original ist in Abb. 2.16 dargestellt: Information erhält ihren Wert durch die Interpretation des Gesamtgeschehens durch die betrachtenden Subjekte. Diese Betrachtung läuft teils bewusst, größtenteils aber unbewusst ab. Die Informationsmenge wird dabei reduziert und dem jeweiligen Erkenntnisinteresse entsprechend gefiltert oder mit anderen Informationen verknüpft.

Daten unterscheiden sich von Informationen. Ein Datum (Einzahl von Daten) stellt zunächst nur eine Folge von Zeichen dar, deren Bedeutung nicht eindeutig ist. Die Zeichen können z. B. Ziffern, Buchstaben oder Symbole sein. In der Marketingabteilung eines Online-Shops findet sich beispielsweise die Ziffernfolge 0815. Diese Abfolge von Zeichen stellt zwar ein Datum dar, die Bedeutung ist allerdings nicht bekannt. Die Zeichenfolge

50

2 Modelle

Abb. 2.16 Information ist „Modell-wovon-wozu-für wen“. (Steinmüller 1981)

selbst hat keine Bedeutung mit Ausnahme ihrer einzelnen Elemente. Aus diesem Datum können aber Informationen entstehen, wenn bekannt ist, in welchem Kontext es steht. Durch eine Kombination mit anderen Daten wird eine Beziehung hergestellt, die interpretiert werden kann und Information entstehen lässt. Steht das Datum 0815 im Kontext „Kunde Max Muster, Artikel 0815“ kann die Marketingabteilung interpretieren, dass der Kunde Max Mustermann einen Artikel mit der Nummer 0815 bestellt hat. Die Ergänzungen von Daten mit anderen Daten hängen vom Erkenntnisinteresse bzw. Nutzungsabsichten eines Subjekts ab. Ein Subjekt möchte mit den jeweils hergestellten Informationen meist einen Adressaten beeinflussen, z. B. zu einer Handlung bewegen. Information ist somit zu verstehen als „Aussagen, die den Erkenntnis- bzw. Wissensstand eines Subjektes (Informationssubjekt/-benutzer) über ein Objekt (Informationsgegenstand) in einer gegebenen Situation und Umwelt (Informationsumwelt) zur Erfüllung einer Aufgabe (Informationszweck) verbessern“ (Szyperski 1980) (vgl. Abb. 2.16). Die Modellbildung ist demnach ein Teil des Informationsmanagements. Informationen sind wichtig für Politiker, Führungskräfte in der Wirtschaft aber auch für jeden Bürger dieser Welt. Sie geben einen bestimmten Sachverhalt, der zu einem bestimmten Zeitpunkt galt, wieder und erlauben in der Regel eine Fortschreibung in die Zukunft. Sie dienen dazu politische, wirtschaftliche oder persönliche Entscheidungen zu treffen. Bei der Nutzung von Informationen stellt sich immer die Frage, wer sie erzeugt hat und welche Absichten derjenige damit verfolgt. Hier spielt folglich die Subjektivität von Modellen eine wesentliche Rolle.

2.7.2

Entity-Relationship-Modell

Um aus Daten Informationen zu generieren, müssen diese mit anderen Daten kombiniert und die entsprechenden Beziehungen beschrieben werden. Dadurch entsteht ein Datenmodell. Die bekannteste Methode für die Beschreibung von Datenmodellen ist das

2.7 Modelle der Informatik

51

Entity Relationship Model (ERM). Ein Entity-Relationship-Modell setzt sich aus drei Hauptelementen zusammen: • Entitäten: Entitäten sind die Objektklassen, die in dem interessierenden Ausschnitt der realen Welt betrachtet werden. • Beziehungen oder Relationen: Relationen beschreiben die Beziehungen zwischen Entitäten. • Attribute: Attribute sind Eigenschaften innerhalb des Kontexts einer Entität. Abb. 2.17 zeigt ein Beispiel für ein ERM. Aus ihm geht auch hervor, mit welchen Symbolen die Hauptelemente in der Regel ausgedrückt werden. Man findet jedoch auch ERM-Darstellungen mit Notationselementen der Unified Modeling Language (UML). Das Diagramm in der Abbildung beschreibt den folgenden Sachverhalt: • Ein Mitarbeiter hat einen Namen. Ein Projekt hat einen Namen, einen Beginn, ein Ende und ein Budget. Die sogenannte Kardinalität drückt aus, dass ein Mitarbeiter mehrere Projekte leiten kann, aber ein Projekt nur von genau einem Mitarbeiter geleitet werden kann. Im Modellierungskonzept der Klassifikation werden Objekte zu Objekttypen (entity sets), und Beziehungen zu Beziehungstypen (relationship sets) zusammengefasst. Diese Typen unterscheiden sich nach: • Entitätstyp: Typisierung gleichartiger Entitäten (z. B. Mitarbeiter, Projekt) • Beziehungstyp: Typisierung gleichartiger Beziehungen (z. B. Mitarbeiter leitet Projekt) • Attributtyp: Typisierung gleichartiger Eigenschaften (z. B. Name für den Entitätstyp Mitarbeiter). Attribute oder Attributkombinationen, deren Wert(e) eine Entität eindeutig identifizieren, heißen identifizierende(s) Attribut(e) (z. B. identifiziert das Attribut Projektname den Entitätstyp Projekt) Zur Beschreibung besonderer Sachverhalte wie z. B. der angesprochenen Kardinalität umfassen ERMs noch weitere Konstrukte (für Details dazu siehe dazu z. B. (Chen 2002)).

Abb. 2.17 Beispiel für ein Entity-Relationship-Diagramm

52

2.7.3

2 Modelle

Fluss- oder Ablaufdiagramme

Fluss- oder Ablaufdiagramme veranschaulichen eine Ausführungsreihenfolge von Tätigkeiten bzw. Aktionen und werden in zahlreichen Anwendungsbereichen verwendet. Sie können beschreiben, in welcher Reihenfolge Handlungen von Menschen oder anderen Akteuren ausgeführt werden sollen. Algorithmen oder Computerprogramme werden oft in Form von Flussdiagrammen (z. B. Programmablaufplänen) dokumentiert. Wegen der verbreiteten Anwendung von Flussdiagrammen haben sich zahlreiche Varianten herausgebildet, die spezielle Sachverhalte des jeweiligen Anwendungsbereichs berücksichtigen. Für die Datenverarbeitung wurde die Symbolik für Flussdiagramme in den Standards DIN 66001:1983-12 bzw. ISO 5807:1985 festgelegt. Abb. 2.18 und 2.19 enthalten eine Auswahl häufig verwendeter Symbole und ein Beispiel für ein Flussdiagramm. Bei der Erläuterung von ARIS in Abschn. 2.6.1.4 haben wir Ereignisgesteuerte Prozessketten (EPK) als Modelltyp für die Steuerungssicht angesprochen. Bei diesen EPKs handelt es sich um Flussdiagramme aus Sequenzen von Ereignisknoten, Funktionsknoten (Operationen) und Konnektoren. Pfeile als Kanten repräsentieren Kontrollflüsse zwischen den Symbolen. Funktionen und Ereignisse (mit Ausnahme von Start- und Endereignis) besitzen genau je eine eingehende und eine ausgehende Kante. Sollen Funktionen mehrere Ereignisse erzeugen oder mehrere Ereignisse eine Funktion auslösen, müssen Konnektoren wie ein exklusives Oder (XOR) zwischengeschaltet werden. Der Modellierer kann auch ausdrücken, wer eine Funktion mit welcher IT-Unterstützung ausführt und

Abb. 2.18 Häufige Symbole in Flussdiagrammen Abb. 2.19 Flussdiagramm für Kontotransaktion

2.7 Modelle der Informatik

53

welche Daten dabei manipuliert werden. Dazu ordnet er den Funktionsknoten Symbole für Organisationseinheiten (z. B. Abteilungen, Stellen, Rollen), Informationsobjekte (Daten) oder Anwendungssysteme zu. Diese Elemente müssen in den entsprechenden Modelltypen spezifiziert sein. Man spricht dann von erweiterten Ereignisgesteuerten Prozessketten (eEPK). Den Zusammenhang, den eine eEPK als Instrument der Steuerungs- oder Prozesssicht mit den Elementen der anderen Sichten und Modelltypen herstellt, haben wir bereits in Abschn. 2.6.1.4 kurz angedeutet. Konkret äußert er sich folgendermaßen (für weitere Details zur Sprache siehe Abschn. 3.3): • Steuerungssicht – Ein Ereignis ist ein Zustand, der vor oder nach einer Funktion auftritt. Das Symbol für ein Ereignis ist sechseckig. – Eine Funktion (Prozess) ist eine Aktion oder Aufgabe, die auf ein Ereignis folgt. Funktionen werden durch Rechtecke mit abgerundeten Ecken symbolisiert. – Konnektoren dienen zum Aufspalten (Split) oder Vereinigen (Join) des Kontrollflusses. Es stehen die drei Konnektoren UND, ODER und XOR zur Verfügung, die jeweils in einem kleinen Kreis mit dem entsprechenden Symbol dargestellt werden. Die Entscheidung, welcher Pfad nach einem Konnektor verfolgt wird, trifft die dem Konnektor vorangehende Funktion. • Funktionssicht Die Funktionsknoten in der Steuerungssicht werden mit Knoten aus dem Funktionsbaum der Funktionssicht verknüpft – damit wird jeweils die auszuführende Aktivität spezifiziert. • Datensicht Informationsobjekte sind Entitäten aus dem Datenmodell, die an Träger wie Dokumente oder sonstige Datenspeicher gebunden sind. Sie stellen Inputs oder Outputs der Funktion dar, mit der sie durch eine gerichtete Kante verbunden werden. Das Symbol für ein Informationsobjekt ist ein Rechteck, den Charakter als Input oder Output bestimmt die Pfeilrichtung der Verbindungskante. • Organisationssicht Organisationseinheiten zeigen an, welche Elemente aus dem für die Organisationssicht modellierten Organigramm die Aktivitäten (Funktionen) im Prozess ausführen. Organisationseinheiten werden durch ungerichtete Kanten mit Funktionen verbunden. In Abb. 2.20 ist das Flussdiagramm aus Abb. 2.19 in der Notation einer erweiterten Ereignisgesteuerten Prozesskette zu sehen.

2.7.4

Petrinetze

Einer der ersten und auch am weitesten verbreiteten Theorieansätze zur Beschreibung von Parallelität sind Petrinetze. Petrinetze dienen der logischen Modellierung von Verhalten.

54

2 Modelle

Abb. 2.20 Erweiterte Ereignisgesteuerte Prozesskette für Kontotransaktion

Sie betrachten das Verhalten von Systemen, in der Regel von Informationssystemen, unter folgenden Aspekten: • Auszuführende Aktivitäten • Vor- und Nachbedingungen einer Aktivität • Zustände aller Bedingungen (mögliche Ausprägung für jede einzelne Vor- bzw. Nachbedingung: Zustand einer Bedingung ist die Verteilung sogenannter Marken als Zustandsanzeige auf den Vor- bzw. Nachbereich) • Anfangszustand (Anfangsmarkierung) • Abläufe (mögliche Folgen von Aktivitäten) Ein Petrinetz ist ein Gebilde, das formal und mathematisch präzise beschrieben wird als gerichteter Graph mit Knoten, die aus zwei disjunkten Teilmengen bestehen und mit Markierungen versehen sind. In der Schreibweise als Quadrupel gilt: Ein Petrinetz ist ein Quadrupel: PN = (S, T, K, M) mit • s element S: Stellen (oder auch Plätze), zur Beschreibung von Zuständen und/oder Bedingungen, Puffer, Speicher oder Lager, im Graph kreisförmig. Sie dienen der Ablage von Information bzw. der Markierungen.

2.7 Modelle der Informatik

55

• t element T: Transitionen, beschreiben Zustandsübergänge, Ereignisse, Aktionen oder Tätigkeiten und sind im Graph strich-, balken- oder quaderförmig. Ihr Zweck ist die Verarbeitung von Information. • k element K: Kanten sind ggf. gewichtete (d. h. mit Zahlen versehene) Verbindungen zwischen Stellen und Transition, im Graph als Pfeile dargestellt. Sie zeigen den Verlauf der Transitionen an. • m element M: Marken (Token), die den aktuellen Zustand des Petrinetzes wiedergeben. Jedes Netz hat einen Initialzustand, d. h. es gibt eine Anfangsmarkierung. Gemäß obiger Definition gehen Kanten jeweils nur von Stelle zu Transition bzw. Transition zu Stelle. Eingabestellen einer Transition t sind Stellen, von denen Kanten zur Transition t laufen. Ausgabestellen einer Transition t sind Stellen, zu denen Kanten der Transition t führen. Eine Transition kann schalten, wenn in jeder Eingabestelle mindestens eine Marke (Token) liegt. Schalten heißt, dass aus jeder Eingabestelle der schaltenden Transition ein Token abgezogen und jeder Ausgabestelle ein Token hinzugefügt wird. Die Abb. 2.21 bis 2.23 zeigen ein Petrinetz mit seinen jeweiligen Zuständen nach der Durchführung der Schaltoperationen. Im Startzustand in Abb. 2.21 hat nur die Stelle s1 eine Markierung, die Initial- oder Anfangsmarkierung. Die Stelle s1 ist die einzige Eingangsstelle der Transition t1, die deshalb schalten kann. Die Markierung wird aus s1 abgezogen und eine Markierung zur einzigen Ausgangsstelle s2 hinzugefügt. Die rechte Hälfte von Abb. 2.21 zeigt den Zustand nach dem Schalten von t1. Die Stelle s2 ist die Eingangsstelle der beiden Transitionen t2 und t3 (vgl. linke Seite von Abb. 2.22). Es könnte also die Transition t2 oder t3 schalten, aber nicht beide. Welche Transition schaltet ist zufällig. Damit haben wir einen sogenannten nichtdeterministischen Zustand. Schaltet t3, wird der Stelle s5 ein Token hinzugefügt und ein

Abb. 2.21 Petrinetz I

Abb. 2.22 Petrinetz II

56

2 Modelle

Abb. 2.23 Petrinetz III

Endzustand erreicht, da aus s5 keine Kante mehr herausführt. Schaltet die Transition t2, so wird den Stellen s3 und s4, die Ausgangsstellen von t2 sind, jeweils ein Token hinzugefügt. Den entsprechenden Zustand zeigt die rechte Hälfte von Abb. 2.22. Nun kann entweder die Transition t4 oder t5 schalten. Hier könnte man folgern, dass diese beiden Transitionen gleichzeitig schalten. Dies ist aber in Petrinetzen nicht erlaubt. Zu einem Zeitpunkt darf nur genau eine Transition schalten. Es ist also keine echte Parallelität möglich. Es ist aber willkürlich, ob nun zuerst t4 oder t5 schaltet. In unserem Beispiel schaltet erst t4 und dann t5. Wenn beide Transitionen geschaltet haben, ist wieder ein Endzustand erreicht. Abb. 2.23 zeigt die entsprechenden Netzzustände. Petrinetz-Modelle erlauben die Analyse und Simulation von dynamischen Systemen mit nebenläufigen und nicht-deterministischen Vorgängen. Bei der vorgestellten Art der Petrinetze handelt es sich um die Grundversion. Mit ihr lassen sich bestimmte Sachverhalte nicht beschreiben. Beispielsweise ist es nicht möglich, Prioritäten für Transitionen zu vergeben, weshalb z. B. die Rechts-vor-links-Regel an Verkehrskreuzungen nicht modelliert werden kann. Um solche Defizite zu beheben wurden Erweiterungen eingeführt, mit denen man dem Modell weitere Aspekte der Wirklichkeit hinzuzufügen bzw. bestimmte Sachverhalte kompakter beschreiben kann. Beispiele sind mehrwertige, bunte oder mit Prioritäten versehene Petrinetze (Einzelheiten zu Petrinetzen und deren Erweiterungen findet man z. B. in Reisig 2010).

2.7.5

Calculus of Communicating Systems

Der Calculus of Communicating Systems (CCS) wurde von Robin Milner im Jahr 1980 publiziert (Milner 1989). Dieser Kalkül erlaubt die formale Modellierung von parallelen kommunizierenden Systemen. Damit können vernetzte Systeme mit einer statischen Topologie beschrieben werden. Mit CCS können Eigenschaften von Programmen wie Verklemmungen, Verhaltensgleichheit etc. formal untersucht werden. CCS erlaubt die Beschreibung folgender Aspekte: • • • • •

Kommunikation zwischen Akteuren über Kanäle Interaktion mit der Umgebung, d. h. Reaktivität Parallele Komposition Verbergen von Aktionen gegenüber der Umwelt (Information Hiding) Nicht-deterministische Verzweigungen

2.7 Modelle der Informatik

57

Der Ablauf eines Prozesses wird als Baum beschrieben, d. h. es gibt eine Wurzel, die den Anfangszustand darstellt und von der die einzelnen Äste ausgehen. Jeder der Äste ist markiert. Diese Markierungen repräsentieren die Aktionen, die ausgeführt werden, um von einem Zustand zum Folgezustand zu gelangen. Es wird zwischen beobachtbaren und nicht beobachtbaren Aktionen unterschieden. Nicht beobachtbare Aktionen können innerhalb eines Prozesses jederzeit ausgeführt werden, ohne dass dies Auswirkungen auf andere Prozesse hat. Prozesse haben keine gemeinsamen Variablen. Um das Verhalten eines Prozesses zu beschreiben werden rekursive Ausdrücke verwendet. Innerhalb von Verhaltensausdrücken können Variablen verwendet werden, um andere Verhaltensausdrücke zu referenzieren. Die Verhaltensausdrücke werden gemäß folgender Syntax beschrieben, bei der Großbuchstaben Prozessnamen und Kleinbuchstaben Aktionen bezeichnen. • Leerer Prozess: Ø • Aktion: Der Prozess a.P1 führt die Aktion a aus und verhält sich dann wie P1 • Prozessname: Mit dem Ausdruck A := P1 erhält der Prozess P1 den Namen A. Da rekursive Definitionen erlaubt sind kann in dem Ausdruck P1 der Name A wieder enthalten sein. • Auswahl: Der Prozess P1+P2 kann entweder mit dem Prozess P1 oder dem Prozess P2 fortgesetzt werden. • Parallelkomposition: P1|P2 bedeutet, dass die Prozesse P1 und P2 parallel ausgeführt werden – Umbenennung P1[b/a] beschreibt den Prozess P1, in dem alle Aktionen mit der Bezeichnung a in b umbenannt werden. • Restriktion: P1a bezeichnet den Prozess P1 ohne die Aktion a Zueinander passende Ein- und Ausgabeaktionen in zwei unterschiedlichen Prozessen können sich synchronisieren und zu einer internen Aktion Tau werden. Im Allgemeinen wird die Koaktion zu einer Aktion mit einem Querstrich über dem Aktionsnamen gekennzeichnet. Diese komplementären Aktionen sind die Sende- und Empfangsaktionen. Abb. 2.24 zeigt beispielhaft die Interaktion zwischen zwei Prozessen. Das Beispiel in siehe Abb. 2.25 zeigt, wie mit CCS ein einfacher Urlaubsantragsprozess beschrieben werden kann. Im Prozess Mitarbeiter wird die Sendeaktion Urlaubsantrag ausgeführt (Aktionsname mit Überstrich). Danach wird auf die Nachrichten ‚abgelehnt‘ oder ‚genehmigt‘ gewartet. Der Manager empfängt die Nachricht Urlaubsantrag, die er entweder mit der Nachricht

Abb. 2.24 Prozessinteraktion mit CCS

58

2 Modelle

Abb. 2.25 Beispielprozess in CCS

Abb. 2.26 Prozessbeschreibung mit Pi-Kalkül

‚genehmigt‘ oder ‚abgelehnt‘ beantwortet. Falls er die Nachricht ‚genehmigt‘ sendet, wird danach auch noch die Nachricht ‚genehmigter Urlaubsantrag‘ gesendet. Diese Nachricht empfängt die Reisestelle. Der Austausch von Nachrichten erfolgt in CCS asynchron, d. h. ein Sender wartet so lange, bis der Empfänger die dazugehörige Empfangsaktion ausführt. Zu der ausgeführten informellen Interpretation gibt es auch formale Ableitungsregeln. Damit werden Prozessdefinitionen zugänglich für formale Untersuchungen.

2.7.6

Pi-Kalkül

CCS erlaubt nur statische Prozessstrukturen. Kommunikationsbeziehungen können nicht dynamisch verändert werden. Der Pi-Kalkül, ebenfalls von Robin Milner entwickelt, erlaubt die Darstellung von Prozessen mit wechselnden Strukturen (Milner 1999). Es sind beliebige Verbindungen zwischen Komponenten darstellbar und diese Verknüpfungen können sich auch ändern bzw. neue können entstehen. Damit ist der Pi-Kalkül eine Erweiterung des CCS um Nebenläufigkeit. Die Notation im Pi-Kalkül orientiert sich weitgehend an der CCS-Notation. Das Beispiel in Abb. 2.26 erläutert die Modellierungsmöglichkeiten des Pi-Kalküls. Der Agent (Prozess) P möchte den Wert 7 an Q über einen Link a senden. Allerdings soll der Wert indirekt über einen weiteren Agenten R übertragen werden.

2.7 Modelle der Informatik

59

Abb. 2.27 Schritte bei der Ausführung des Systems O

Abb. 2.28 Strukturänderung

Die einzelnen Schritte bei der Ausführung des Systems O sind in Abb. 2.27 sichtbar. Die Prozesse P, R und Q werden parallel ausgeführt. Prozess P sendet über den Kanal b den Namen a und dann den Namen 7. Der Prozess P erhält über den Kanal b die beiden Namen. Dies bedeutet, alle x werden durch a ersetzt und alle z durch 7. In Abb. 2.27 ist dies das Ergebnis nach Schritt 2. Nun kann über den Kanal a der Name 7 gesendet werden, der vom Prozess Q dann angenommen wird. Damit wurde der Wert 7 über den Prozess R an den Prozess Q gesendet. Die Abb. 2.28 zeigt, wie durch den Ablauf des Systems O seine Struktur geändert wird. Da der Kanalname a von P nach R gesendet wird, sind nach der Annahme der Nachricht die Prozesse R und Q über den Kanal a verknüpft. Damit wird deutlich, dass der Pi-Kalkül im Gegensatz zu CCS die Modellierung von Strukturänderungen zulässt.

2.7.7

Communicating Sequential Processes

Communicating Sequential Processes (CSP) ist eine Methodik zur Beschreibung von Interaktion zwischen kommunizierenden Prozessen. Die Idee hat Tony Hoare erstmals 1978 als imperative Sprache vorgestellt (Hoare 1978), dann zu einer formalen Algebra ausgebaut und 1985 mit der Veröffentlichung des Buchs mit dem Titel Communicating Sequential Processes berühmt gemacht (Hoare 1985).

60

2 Modelle

In CSP ist wie in CCS die Anzahl der Prozesse statisch. Sie kann während der Laufzeit nicht geändert werden und zwischen Prozessen gibt es keine gemeinsamen Variablen. Stattdessen „kennen“ sich die Prozesse und verständigen sich untereinander durch das Senden und Empfangen von Nachrichten. Zum Senden führt der Sendeprozess P das Ausgabekommando Q ! (expr) und der Empfängerprozess Q das Eingabekommando P ? (vars) aus. Ausgabe- und Eingabekommandos heißen korrespondierend, falls die Folge von Ausdrücken (expr) und die Folge von Variablen (vars) in der Anzahl und komponentenweise vom Typ übereinstimmen. Analog CCS und dem Pi-Kalkül basiert CSP auf einem ungepufferten Nachrichtenaustausch, bei dem der Sende- und der Empfangsprozess explizit genannt werden müssen. Mit Q ! () und P ? () wird eine Nachricht ohne Inhalt gesendet. Solche Nachrichten werden als Signale bezeichnet und dienen einzig und allein der Synchronisation von Prozessen. Werden unterschiedliche Signale benötigt, so wird die Unterscheidung durch Typbezeichner der Form Q ! (Signal1) und P ? (Signal1) ausgedrückt. Neben dem oben beschriebenen unbedingten Nachrichtenaustausch gibt es die Empfangsanweisung innerhalb eines sogenannten Guarded Commands (bewachte Anweisung). Eine bewachte Anweisung wird nur ausgeführt, wenn die vorangestellte Bool’sche Bedingung wahr ist. So wird der Formelsatz x > y; P?(z) - > x:= x+ y; y := z nur ausgeführt, wenn x größer als y ist. Dann wird die Nachricht von P entgegengenommen, falls P bereit ist, die Nachricht zu senden. Um auf Nachrichten von unterschiedlichen Sendern warten zu können, werden mehrere Guarded Commands zu einer Alternativanweisung zusammengeschlossen. [ x > y; P?(z) - > x:= x+ y; y := z || x < y; Q?(z) - > y:= x+ y; y := z ] Im Fall x>Y wird die Nachricht P?(z) erwartet, im Fall x y; P?(z) - > x:= x+ y; y := z || x < y; Q?(z) - > y:= x+ y; y := z ] wird solange ausgeführt, bis keine der Bedingungen mehr wahr ist – dann wird die Wiederholung beendet. Die Konzepte bezüglich der Nebenläufigkeit von CSP dienen als Gestaltungsgrundlage der Programmiersprache Go.

2.7.8

Abstract State Machines

Eine abstrakte Zustandsmaschine (Abstract State Machine (ASM)) ist in der Informatik ein Modell zur formalen, operationellen Beschreibung von Algorithmen. Die Zustände einer abstrakten Zustandsmaschine sind allgemeine mathematische Strukturen. Der Erfinder des Modells ist Yuri Gurevich. Egon Börger hat die ASM für die praktische Anwendung weiterentwickelt (Börger und Stärk 2003; Börger und Raschke 2018). Abstract State Machines (ASM) sind endliche Mengen von Transitionsregeln der Form

2.7 Modelle der Informatik

61

If condition then action mit denen die Zustände einer ASM geändert werden. Condition ist dabei ein beliebiger logischer Ausdruck und Action eine beliebige Handlung. In der Regel ist Action eine Wertzuweisung der Form f(t1,. . . . . . .tn) := s. Die Bedeutung der Regel besteht darin, im gegenwärtigen Zustand die angegebene Regel auszuführen, wenn die angegebene Bedingung in diesem Zustand erfüllt ist. ASM-Zustände werden allgemein als beliebige Mengen beliebiger Elemente mit beliebigen darauf definierten Funktionen (Operationen) und Prädikaten definiert. Im Fall von Geschäftsobjekten sind die Elemente Platzhalter für Werte beliebigen Typs und Operationen wie Erzeugen, Duplizieren, Löschen oder algebraische Manipulationen von Objekten. Ein Berechnungsschritt einer ASM in einem bestimmten Zustand bedeutet, dass alle Actions, für die die Bedingung (Condition) wahr ist, gleichzeitig ausgeführt werden. Durch die simultane Ausführung kann von irrelevanten Reihenfolgen abstrahiert werden. Mehrere ASMs können gleichzeitig ablaufen und über sogenannte Controlled bzw. Monitored Functions verknüpft werden. Eine gegebene ASM M kann Controlled Functions aktualisieren, sie kann aber nicht von anderen ASM aus der Umgebung von M verändert werden. Monitored Functions einer gegebenen ASM M können nur durch deren Umgebung aktualisiert werden. Durch die paarweise Verwendung von Controlled and Monitored Functions kann ein Netzwerk paralleler sich koordinierender ASMs aufgebaut werden.

2.7.9

Objektorientierte Modelle

Die bisher betrachteten Modelle der Informatik legen den Schwerpunkt entweder auf Daten oder Funktionen. Die Darstellung von Daten in einem ERM und Funktionen in einem Flussdiagramm ergänzen sich nur in entkoppelten Darstellungen – die Unterscheidung in Daten- und Funktionssicht bei ARIS macht dies deutlich. Die objektorientierte Modellbildung reduziert diese isolierten Sachverhalte nicht mehr auf ihre Einzelteile, sondern betrachtet sie als integriertes Ganzes, bei dem die einzelnen Komponenten miteinander verbunden und voneinander abhängig sind. Unter einem objektorientierten Modell versteht man eine Sichtweise auf ein komplexes System, bei der dieses durch das Zusammenspiel von Objekten beschrieben wird. Durch diese Art der Modellbildung soll die Komplexität der Beschreibung für Sachverhalte, die in Software abzubilden sind, reduziert werden. Die Objektorientierung sieht die in der realen Welt vorkommenden Entitäten als Objekte. Ein Telefon ist ebenso ein Objekt, wie ein Fahrrad, ein Mensch oder ein Mitarbeiter. Solche Objekte setzen sich wiederum aus anderen Objekten zusammen wie z. B. Schrauben, Stangen, Armen, Füßen, Kopf o.Ä. Die Objekte werden, wie in der Modellbildung üblich, auf ihre in der jeweiligen Situation bedeutsamen Eigenschaften reduziert. So wird z. B. ein Mitarbeiter in einem Lohnabrechnungssystem auf Name, Adresse, Mitarbeiternummer, vereinbartes Einkommen, Steuerklasse usw. reduziert.

62

2 Modelle

Abb. 2.29 Beziehung Klasse-Objekt

Die in einem Modell berücksichtigten Objekte werden nicht einzeln konzipiert. Für gleichartige Objekte wird ein grober Bauplan mit gleichartigen Eigenschaften erstellt. Beispielsweise modelliert man für eine Bibliotheksanwendung die Eigenschaften von Büchern, die für alle Büchern identisch sind. Solche allgemeinen Beschreibungen von Objekten werden in der Objektorientierung Klassen genannt. Mit diesen Klassen werden dann innerhalb des Modells die benötigten konkreten Objekte erzeugt (Instanzen). Die Abbildung der Wirklichkeit in ein Modell erfolgt also zweistufig. Zuerst werden gleichartige Objekte der Wirklichkeit identifiziert und jeweils als Klasse beschrieben. Die einzelnen Objekte werden dann als sogenannte Instanzen einer Klasse erzeugt. Eine Klasse beschreibt somit die Struktur einer Menge gleichartiger Objekte. Abb. 2.29 zeigt eine Klasse-Objekt-Beziehung, nach der das Buch “Subjektorientiertes Prozessmanagement“ eine Instanz der Klasse „Buch“ ist. Die verwendete Notation entstammt der Unified Modeling Language (UML). UML ist eine von der Object Management Group standardisierte Sprache zur Beschreibung objektorientierter Modelle. Die Eigenschaften einer Klasse sind • ihre Bestandteile und die in ihnen enthaltenen Daten und Informationen, auch Attribute genannt, • die auf den Bestandteilen definierten Operationen und ihre Parameter (Methoden), mit denen ein Objekt manipuliert bzw. dessen Zustand abgefragt werden kann und • Bedingungen, Voraussetzungen und Regeln, die die Objekte erfüllen müssen (Zusicherungen). Abb. 2.30 zeigt ein Beispiel für die Beschreibung der Klasse „Buch“. Diese Klasse hat fünf Attribute. Das Attribut Seitenzahl hat eine Zusicherung, die besagt, dass die Seitenzahl positiv sein muss. Die Klasse erlaubt den Zugriff und die Manipulation ihrer Daten mit Abb. 2.30 Beschreibung der Klasse „Buch“

2.7 Modelle der Informatik

Abb. 2.31 Vererbung von Eigenschaften

63

Buch Titel Autoren Seitenzahl (Seitenzahl > 0) Verlag In halt AnzeigenSeite (Seite) SetTitel(String) SetAutoren (String) SetSeitenzahl(Integer) SetVerlag(String) SetInhalt(Text)

Notizbuch Seiteneintrag(Seite, Inhalt)

sechs Methoden. So können der Titel, die Autoren, die Seitenzahl, der Verlag und der Inhalt gesetzt werden (Set). Mit der Operation (Methode) AnzeigenSeite(Seite) kann der Inhalt der angegebenen Seite aus dem Buch “ausgelesen“ werden. Ausgehend von einer solchen Klassendefinition können nun Objekte instanziiert werden. Mit Hilfe der Operationen können dann für jede dieser Instanzen die jeweiligen Attribute entsprechend gesetzt werden. Ein objektorientiertes Modell beschreibt neben den Definitionen der Klassen und der zugehörigen Objekte auch die Beziehungen der Klassen zueinander. Die Arten von Beziehungen sind: • Vererbung Eigenschaften können von einer Klasse zur nächsten weitergegeben werden. Man spricht dann von Vererbung. Die Klasse, die vererbt, heißt Oberklasse, und die Klasse, die erbt, Unterklasse. So ist eine Klasse Notizbuch Unterklasse der Klasse „Buch“. Der Klasse „Notizbuch“ wird noch die Methode „Seiteneintrag(Seite, Inhalt)“ hinzugefügt. Damit kann auf der angegebenen Seite ein Text eingegeben werden; Ansonsten erbt die Unterklasse „Buch“ alle Attribute und Methoden von der Klasse „Buch“. Abb. 2.31 zeigt die Vererbungsbeziehung zwischen „Buch“ und „Notizbuch“. Der Dreieckspfeil zeigt von der Unterklasse zur Oberklasse. • Assoziationen Eine Assoziation ist eine Beziehung zwischen verschiedenen Objekten einer oder mehrerer Klassen. Dargestellt werden Assoziationen als einfache Linie zwischen zwei

64

2 Modelle

Klassen. Die Linie kann mit einem Name (Bezeichnung) und Anzahlangaben versehen werden. Auch die assoziierten Klassen können Namen bezüglich der Beziehung erhalten. Abb. 2.32 illustriert ein Beispiel für eine Assoziation. Eine Person (Arbeitnehmer) kann bei keiner oder einer Firma (Arbeitgeber) beschäftigt sein und eine Firma kann keine oder mehrere Personen beschäftigen. Assoziationen haben eine große Ähnlichkeit mit den Entity-Relationship-Diagrammen. • Aggregationen Aggregationen sind eine Variante von Assoziationen. Dabei handelt es sich ebenfalls um eine Beziehung zwischen zwei Klassen, jedoch mit der Besonderheit, dass die zwei Klassen zueinander in Beziehung stehen wie ein Teil zu einem Ganzen. Eine Aggregation setzt sich zusammen aus einer Menge von Einzelteilen. Abb. 2.33 zeigt ein Aggregationsbeispiel, bei dem ein Unternehmen aus Abteilungen, und eine Abteilung aus Mitarbeitern besteht. • Komposition Eine besondere Form der Aggregation ist die Komposition. Hier hängt das Ganze von der Existenz seiner Einzelteile ab. In Abb. 2.34 ist eine Änderung an der Aggregation aus Abb. 2.33 zu sehen. Eine Abteilung besteht nicht mehr, wenn ihr niemand angehört. • Objektkommunikation Objekte kommunizieren miteinander,3 d. h. ein Objekt sendet Nachrichten an ein anderes Objekt. Die Nachrichten stoßen dann die zugehörigen Operationen an. Ein

Firma

beschäftigt >

0..1 Arbeitgeber

0..*

Person

Arbeitnehmer

Abb. 2.32 Assoziationen zwischen Objekten

Firma

1

Besteht aus >

1..*

Abteilung

1

Besteht aus > 1..*

Person

Abb. 2.33 Mehrstufige Aggregation

Firma

1

Besteht aus >

1..*

Abteilung

1

hat>

1..*

Person

Abb. 2.34 Komposition

3 Dieses Gedankenmodell der kommunizierenden Objekte wird klassisch über die Objektorien-

tierung gelehrt, ist aber aus Sicht der Subjektorientierung nicht korrekt, da nur aktive Einheiten (Subjekte) kommunizieren können. Passive Elemente wie Objekte können dies nicht. Was tatsächlich in der objektorientierten Programmierung geschieht ist, dass der Prozessor des ausführenden Computersystems instruiert wird, Daten von einem anderen Objekt zu beziehen.

2.8 Fazit: Modelle für Geschäftsprozesse

Person

1

Seiteneintrag(Seite, Inhalt) ->

65

1

Notizbuch

Abb. 2.35 Nachricht zwischen Objekten

Objekt versteht also nur die Nachrichten, zu denen es auch die zugehörigen Operationen enthält. Abb. 2.35 zeigt die Kommunikation einer Person mit dem Notizbuch zum Eintragen einer neuen Notiz. Die beschriebenen Konstrukte bilden den Nukleus des objektorientierten Modellierungsansatzes. Darüber hinaus existieren zahlreiche Erweiterungen zur Abbildung bestimmter Sachverhalte wie die sogenannten Behälterklassen (zur objektorientierten Modellierung gibt es zahlreiche Literatur, ein frühes Werk dazu ist Booch et al. 2007).

2.7.10 Agenten-/Aktoren-orientierte Modelle Bislang gibt es keine standardisierte und allgemein akzeptierte Definition des Agentenkonzepts. Der Begriff wird abhängig von der Anwendungsdomäne im Detail unterschiedlich definiert (Franklin und Graesser 2017). All diesen Definitionen ist aber gemeinsam, dass ein Agent eine abgrenzbare Einheit ist, die in der Lage ist, die ihr vorgegebenen Aufgaben flexibel, interaktiv und autonom zu verfolgen. Oft wird der Begriff Aktor als synonym für den Begriff Agent benutzt. So definieren Lankhorst et al. (Lankhorst et al. 2017) einen Business Actor als „. . . an entity that is capable of performing behavior“. Multiagentensysteme bestehen aus mehreren Agenten, die synchron oder asynchron Nachrichten austauschen. Multiagentensysteme können die Strukturen von Softwaresystemen abbilden oder auch der Modellbildung sozialer Systeme dienen. Je nach Anwendungssituation kann dann zwischen Softwareagenten und menschlichen Agenten unterschieden werden. In gewisser Weise können die Prozesse in CCS, im PI-Kalkül und in CSP als Multiagentensysteme betrachtet werden. Der Begriff Prozess wird dort analog zu den Begriffen Agent und Aktor verwendet. Ein agentenorientiertes Modell beinhaltet also die Agenten, die Kommunikationspfade und die Nachrichten, die ausgetauscht werden (Cossetino et al. 2014).

2.8

Fazit: Modelle für Geschäftsprozesse

Geschäftsprozessmodelle bilden den Wirklichkeitsausschnitt der Geschäftsprozesse ab. Das subjektive Verständnis des Geschäftsprozessbegriffs beeinflusst, welche Prozessaspekte als wesentlich erachtet werden und deshalb in den Modellen im Vordergrund stehen. Hier schlagen sich Absichten und Interessen des Modellerstellers nieder. Konsequenz sind zahlreiche Auslegungen des Geschäftsprozessbegriffs, von denen jede weder richtig noch

66

2 Modelle

falsch ist, sondern lediglich andere Betrachtungsschwerpunkte setzt. Als Beispiele dafür können folgende Definitionen des Terminus Geschäftsprozess gelten: • „Folge von Wertschöpfungsaktivitäten (Wertschöpfung) mit einem oder mehreren Inputs und einem Kundennutzen stiftenden Output“ (Schewe 2017) • „Ein ‚Prozess‘ ist die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts notwendig sind.“ (Becker 2017) Beide Definitionen stellen auf die erforderlichen Aktivitäten und deren Folgen ab. Das erste Beispiel erwähnt zusätzlich den Input und den Output mit dem Kundennutzen, während in der zweiten Definition stattdessen die Bearbeitung der Geschäftsobjekte einbezogen wird. Handelnde und benötigte Ressourcen fehlen dagegen in beiden Begriffsfassungen. Sie betrachten nicht, durch wen und womit die Aktivitäten ausgeführt werden. Es gibt keinen Bezug zur Organisation, in die ein Geschäftsprozess eingebettet ist, sowie dazu, welche IT-Anwendungen oder sonstige Ressourcen eingesetzt werden, um ihn auszuführen. Wir folgen deshalb in Anlehnung an Gerhard Schewe einem umfassenden Begriffsverständnis, das auch diese fehlenden Aspekte berücksichtigt: 1. 2. 3. 4. 5. 6. 7. 8.

Ein Prozess ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), die von Handelnden (Menschen, Systeme als Aufgabenträger) in sachlogischer und zeitlicher Reihenfolge mit Hilfsmitteln (Sachmittel, Information) zur Bearbeitung eines Geschäftsobjekts ausgeführt werden, um ein Kundenbedürfnis zu befriedigen (und damit zur Wertschöpfung beizutragen), und einen definierten Anfang und Input sowie ein definiertes Ende und Ergebnis aufweisen.

Wie bereits in Abschn. 1.3 ausgeführt, formen wir die Bestandteile etwas um und gruppieren sie wie folgt: 1. Prozessstrategie: Ein Prozess hat a. einen definierten Anfang und Input (Startereignis), b. und weist ein definiertes Ende mit einem Ergebnis auf, c. das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) beiträgt 2. Prozesslogik: Ein Prozess a. ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), b. die nach dem Startereignis von Handelnden c. in sachlogischer und zeitlicher Reihenfolge

2.8 Fazit: Modelle für Geschäftsprozesse

67

d. zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um e. das gewünschte Ergebnis zu erzeugen. 3. Prozessrealisierung: Ein Prozess wird realisiert a. mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden übernehmen, und diese b. mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen. Mit diesem Verständnis von Geschäftsprozessen wird der Bezug der in diesem Kapitel beschriebenen Modelle aus unterschiedlichen Domänen zum Geschäftsprozessmanagement deutlich. Abb. 2.36 zeigt entsprechend den integrativen Charakter der Geschäftsprozessmodelle. Die Modelle von Habermas und Luhmann befassen sich mit Aspekten der gesellschaftlichen Systeme und Organisationen. Sie beschreiben welche Komponenten und Beziehungen eine Organisation ausmachen und wie Menschen darin positioniert sind. Komplexe Organisationen können beispielsweise anhand betrieblicher Funktionen, Leistungsspektrum, geografischer Aspekte oder Kombinationen davon in Teilorganisationen strukturiert werden. Das Ergebnis ist das Organigramm. Geschäftsmodelle betrachten unter anderem die Aspekte Kunden, Lieferanten, Partner und Wertschöpfung und blicken damit zunächst auf die externen Leistungsbeziehungen. Insbesondere mit Wertversprechen (Produkte und Services), Aktivitäten und Ressourcen stellen sie aber auch die Verbindung zur stärker nach innen gerichteten Unternehmensarchitektur her. In dieser sind auf der fachlichen Ebene die Aufbauorganisation mit den personellen Ressourcen, die Prozesse und die logischen Geschäftsobjekte modelliert. Die Verknüpfung mit der technischen Schicht der Unternehmensarchitektur führt zu den Modellen aus der Informatik. Diese beschreiben etwa Datenstrukturen, Kontrollflüsse

Abb. 2.36 Integration verschiedener Modelle durch Geschäftsprozessmodelle

68

2 Modelle

und Algorithmen für Programme sowie die Gestalt und das Zusammenwirken weiterer informations- und kommunikationstechnischer Komponenten, die für die Ausführung gewünschter Aktionen im Rahmen der Prozessunterstützung und -automatisierung nötig sind.

Literatur Allee V (2015) Value Networks and true nature of Collaboration. Meghan Kiffer Press Becker J (2017) Geschäftsprozessmodellierung. http://www.enzyklopaedie-der-wirtschaftsinform atik.de/lexikon/daten-wissen/Informationsmanagement/Information-/index.html. Zugegriffen am 15.03.2023 Berghaus M (2004) Luhmann leicht gemacht. Böhlau Booch G et al (2007) Object oriented analysis and design with applications, 3. Aufl. Addison Wesely, Berlin Börger E, Raschke A (2018) Modeling companion for software practitioners. Springer, Berlin Börger E, Stärk RF (2003) Abstract state machines: a method for high-level system design and analysis. Springer, Berlin Chen PS (2002) Entity relationship modeling – historical events, future trends and lessons learned. In: Broy M, Denert E (Hrsg) Software pioneers: contributions to software engineering. Springer Cossetino M et al (2014) Handbook on agent oriented design processes. Springer Crowther D, Green M (2004) Organisational theory. Chartered Institute of Personnel Development Embley DW, Thalheim B (Hrsg) (2011) Handbook of conceptual modeling. Springer Fleischmann A, Schmidt W, Stary C (Hrsg) (2015) S-BPM in the Wild. Springer International Publishing, Cham. http://link.springer.com/10.1007/978-3-319-17542-3. Zugegriffen am 15.03.2023 Franklin S, Graesser A (2017) Is it an agent, or just a program?: A taxonomy for autonomous agents. https://pdfs.semanticscholar.org/288d/7952b6648749fcbdcedabedf8f43cf7fda52.pdf. Zugegriffen am 15.03.2023 Gabriel M (2015) Warum es die Welt nicht gibt. Ullstein Taschenbuch Habermas J (1981) Theory of communicative action, Bde. 1 und 2. Suhrkamp Paperback Science Hoare AR (1978) Communicating sequential processes. Commun ACM 21(8):666–677 Hoare AR (1985) Communicating sequential processes. Prentice Hall ISACA (2019) COBIT 2019 framework: introduction and methodology. ISACA. https://store.isaca. org/s/store#/store/browse/detail/a2S4w000004Ko8kEAC. Zugegriffen am 15.03.2023 itSMF (2019) ITIL foundation. TSO. https://www.itsmf.de/. Zugegriffen am 15.03.2023 Kaplan RS, Norton DP (1997) Balanced scorecard. Schaeffer-Poeschl Kieser A, Ebers M (eds) (2006) Organisationstheorien. Kohlhammer Kieser A, Wagenbach P (2007) Organisation. Schäffer-Poeschl Lankhorst M et al (2017) Enterprise architecture at work. Springer Luhmann N (1987) Soziale Systeme. Suhrkamp Matthes D (2011) Enterproise Architecture Kompendium. Enterproise Architecture Kompendium Milner R (1989) Communication and concurrency. Prentice Hall Milner R (1999) Communicating and mobile systems: the Pi-Calculus. Cambridge University Press Osterwalder A, Pigneur Y (2010) Business model generation. Wiley Reisig W (2010) Petrinetze: Modellierungstechnik, Analysemethoden, Fallstudien. Vieweg+Teubner Scheer C, Deelmann T, Loos P (2003) Geschäftsmodelle und internetbasierte Geschäftsmodelle – Begriffsbestimmung und Teilnehmermodell. Working Papers of the Research Group Information Systems & Management, Universität Mainz

Literatur

69

Schewe G (2017) Geschäftsprozess. http://wirtschaftslexikon.gabler.de/Definition/geschaefts prozess.html#definition. Zugegriffen am 15.03.2023 Schreyögg G (Hrsg) (2008) Organisation, 5. Aufl. Gabler Siemoneit OJ (2010) Eine Wissenschaftstheorie der Betriebswirtschaftslehre. Dissertationsschrift, Universität Stuttgart Stachowiak H (1973) Allgemeine Modelltheorie. Springer Stary C (2014) Non-disruptive knowledge and business processing in knowledge life cycles-aligning value network analysis to process management. J Knowl Manag 18(4):651–686 Steinmüller W (1981) Eine sozialwissenschaftliche Konzeption der Informationseissenschaften. Nachrichten für Dokumentation 23, Nr. 2 Szyperski N (1980) Informationsbedarf. In: Grochla E (Hrsg) Handwörterbuch der Organisation. C.E. Poeschel

3

Modellierungssprachen für Geschäftsprozesse

Bei der Modellierung geht es immer darum Ausschnitte der menschlich wahrgenommenen Realität zu beschreiben und diese zueinander in Beziehung zu setzen. Mit der Wahl einer Modellierungssprache wird dabei festgelegt, mit welchen Konzepten diese Beschreibungen gemacht werden können. Modellierungssprachen stellen also das Vokabular und die Grammatik zur Verfügung, die benötigt werden, um Sachverhalte der menschlich wahrgenommenen Realität in Modellen abbilden zu können. Die Verwendung einer bestimmten Modellierungssprache schafft eine definierte Basis für die Modellbildung, auf die sich alle beteiligten Akteure beziehen können – seien sie aktiv an der Erstellung oder passiv als Konsumenten beteiligt. Akteure können dabei einerseits Personen sein, denen durch die Modellierungssprache ein gemeinsames, definiertes Vokabular zur Verfügung gestellt wird, um sich ein gemeinsames Verständnis über den Modellgegenstand zu bilden. Andererseits können Akteure auch Computersysteme sein, denen durch eine in der Modellierungssprache exakt spezifizierte Semantik von Modellelementen die Gelegenheit geboten wird, Modelle automationsgestützt weiter zu verarbeiten, um sie z. B. im Fall von Prozessmodellen als Grundlage für die WorkflowUnterstützung einzusetzen. Von der Wahl der Modellierungssprache hängt also ab, was in einem Modell überhaupt abgebildet werden kann und welche Aspekte nicht sichtbar werden können, weil die Modellierungssprache keine Konzepte dafür anbietet. Die Wahl der Modellierungssprache beeinflusst dabei auch die Verwendbarkeit des Modells für unterschiedliche Zielgruppen: Während manche Modellierungssprachen eher zur Unterstützung der Kommunikation menschlicher Akteure konzipiert wurden und dem entsprechend manchmal auch eine „vage“ Abbildung von Sachverhalten ermöglichen, gibt es andere Modellierungssprachen, die für eine exakte Spezifikation von Sachverhalten konzipiert sind und deren Anwendungsfeld eher in der Aufbereitung von Modellen für die Verwendung in IT-Systemen

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_3

71

72

3 Modellierungssprachen für Geschäftsprozesse

liegt (Curtis et al. 1992). Eine andere Frage ist die Formalität eine Sprache. Dabei sind z. B. informelle Methoden noch zur Unterstützung der Kommunikation zwischen menschlichen Akteuren geeignet, die dabei nicht an einen strikten Satz von Regeln gebunden sind sondern zumeist relativ frei in Ihrer Ausdruckswahl sind (Oppl 2018). Zur Kommunikation mit IT-Systemen, die klare und präzise Anweisungen benötigen, sind solche Sprachen ohne präzise und formale Syntax aber ungeeignet. Die Wahl einer Modellierungssprache ist also abhängig von der jeweiligen Zielsetzung der Modellbildung und damit ein wesentlicher Schritt hin zu einer erfolgreichen Unterstützung jener Aktivitäten, in denen die Modellierung eingebettet ist. Im vorliegenden Abschnitt wollen wir die Grundlage für die sach- und personengerechte Auswahl einer passenden Modellierungssprache schaffen und stellen dazu unterschiedliche Sprachen mit deren jeweiligen Zielsetzungen und Sprachelementen vor. Der Fokus liegt für dieses Buch natürlich auf der Abbildung von Geschäftsprozessen. Die Abbildung von organisationalen oder technischen Strukturen, wie sie im letzten Kapitel erwähnt wurden und in die die Prozesse eingebettet sind, lassen wir hier außen vor, um die Komplexität der Darstellung handhabbar zu halten. Alle in der Folge behandelten Sprachen ermöglichen deshalb im weiteren Sinne die Beschreibung von Abläufen bzw. die Abbildung von Verhalten von Akteuren in Organisationen. Im Verständnis darüber, was nun ein Akteur sein kann und wie dieses Verhalten beschrieben wird, unterscheiden sich die Sprachen fundamental. Dies ist deren Entstehungsgeschichte und den jeweiligen Zielsetzungen geschuldet. Die Anordnung der einzelnen Ansätze folgt einer historischen Perspektive, um die Zusammenhänge zwischen den Sprachen und deren Entstehung deutlich hervortreten zu lassen. Für jede der Sprachen betrachten wir abschließend, wie sich diese zur Abbildung von Prozessen entsprechend unserer Definition eignen und wo ihre Abbildungsschwerpunkte bzw. Lücken liegen.

3.1

Überblick

Flowcharts sind die älteste bis heute gebräuchliche Repräsentationsform von Modellen des Kontrollflusses ursprünglich in Fabriken und später in Computerprogrammen. Aufgrund der Generalität ihrer Sprachelemente werden sie auch für Zwecke der Modellierung von Abläufen in Organisationen eingesetzt und sind hier deshalb als Einstieg in die grafische Prozessmodellierung zu betrachten. Sie weisen das Konzept der Verzweigung im Kontrollfluss zur Abbildung von alternativen Abläufen auf. eEPKs („erweiterte Ereignisgesteuerte Prozessketten“) stellten in Europa lange Zeit einen de-facto Industriestandard für die Geschäftsprozessmodellierung dar. Sie umfassen neben der Modellierung von Abläufen auch Elemente, mit denen Verantwortlichkeiten, Daten oder Leistungen modelliert werden können und sorgen damit dafür, dass Geschäftsprozesse gemeinsam mit ihrem organisationalen Kontext in Modellen abgebildet werden können. Darüber hinaus erlauben sie die explizite Modellierung von parallelen

3.2 Flussdiagramme: Flowcharts

73

Aktivitäten und gehen damit bei der Abbildung des Arbeitsablaufs über die Ausdrucksstärke von Flowcharts hinaus. UML-Aktivitätsdiagramme sind historisch gesehen eine Weiterentwicklung von Flowcharts und stellen heute als Teil der Unified Modeling Language (UML) den de-facto Standard zur Abbildung von Kontrollflüssen in Software dar. Auch sie ermöglichen die Abbildung von parallelen Abläufen. Anhand von Aktivitätsdiagrammen führen wir die Strukturierung von Modellen durch Partitionierung und Schachtelung ein und zeigen damit, wie Modelle auch anhand von Verantwortlichkeiten und nicht nur ausschließlich anhand des Arbeitsablaufs strukturiert werden können. Business Process Model and Notation (BPMN) ist der heute meist eingesetzte Standard zur Abbildung von Geschäftsprozessen. Ausgehend von mehreren unterschiedlichen Modellierungssprachen – unter anderem von Aktivitätsdiagrammen – wurde eine Sprache definiert, die explizit zur Abbildung von Geschäftsprozessen geeignet sein sollte und mit deren Hilfe Modelle für unterschiedliche Zielsetzungen – von der Kommunikationsunterstützung bis hin zur Ausführung in Workflow-Management-Systemen – erstellt werden können sollten. Aus Sicht der Sprachkonzeption ist die BPMN vor allem hinsichtlich ihrer Möglichkeiten zur kompakten Abbildung von komplexen Abläufen (etwa Ausnahmebehandlungen) interessant. S-BPM (Subjektorientiertes Geschäftsprozessmanagement, Subject-oriented Business Process Management) ist ein Modellierungsansatz, der die in einem Geschäftsprozess involvierten Akteure und deren Interaktionsverhalten ins Zentrum der Modellbildung stellt. Die sich daraus ergebende Modellierungssprache Parallel Activity Specification Schema (PASS) zeichnet sich durch einen geringen Umfang von Sprachelementen bei gleichzeitig umfassender Ausdrucksstärke zur Abbildung von Geschäftsprozessen aus. Sie wird hier einerseits als Vertreterin eines nicht vorrangig ablauforientierten Herangehens an die Geschäftsprozessmodellierung vorgestellt und bildet außerdem in der Sprachkonzeption eine Alternative zur BPMN und ihrem sehr umfangreichen Satz an Modellierungselementen.

3.2

Flussdiagramme: Flowcharts

Flowcharts (Flussdiagramme bzw. ursprünglich Programmablaufpläne) ermöglichen es, einfache, sequenzielle Prozesse abzubilden. Ein sequenzieller Prozess zeichnet sich dadurch aus, dass zu keinem Zeitpunkt mehr als eine Aktivität gleichzeitig durchgeführt wird – parallele Abläufe können also nicht abgebildet werden. Erstmals beschrieben wurden Flowcharts im Rahmen der industriellen Produktionsplanung in den 1920erJahren. Ende der 1940er-Jahre wurden sie für die Beschreibung von Prozessen in der aufkommenden Informationstechnologie adaptiert. Seit Mitte der 1960er-Jahre stellen sie eine standardisierte Repräsentationsform für Programmabläufe dar. Bis heute sind sie ein Mittel der Wahl, um Abläufe in Computerprogrammen oder auch Prozesse

74

3 Modellierungssprachen für Geschäftsprozesse

in Organisationen darzustellen, solange deren Komplexität die Ausdrucksstärke eines Flowchart nicht übersteigt (Damij 2007). Die Einschränkung der Ausdrucksstärke von Flowcharts ist deren historischen Entwicklung geschuldet. Sowohl in der industriellen Produktionsplanung als auch in frühen Computersystemen war es nicht notwendig, parallele Abläufe abbilden zu können. Durch die eingeschränkten zur Verfügung stehenden Ressourcen (in Computern: nur eine CPU bzw. nur ein Prozessorkern) war es schlicht nicht notwendig, Sprachelemente zur Abbildung etwa von parallelen Abläufen zur Verfügung zu stellen.

3.2.1

Notationselemente

Flowcharts kommen heute in vielen unterschiedlichen Varianten vor, die sich vor allem in der verwendeten Notation (d. h. der grafischen Darstellung) unterscheiden. Die Semantik der Sprachelemente ist aber allen gemein: Grundsätzlich wird eine beliebige Anzahl von Operationen (also Aktivitäten, dargestellt als Rechtecke) definiert. Diese werden mittels gerichteten Verbindungen (dargestellt als Pfeile) in die Reihenfolge gebracht, in der sie ausgeführt werden sollen. Terminierungselemente (dargestellt als abgerundete Rechtecke) kennzeichnen den Beginn und das Ende eines Prozesses (siehe Abb. 3.1). Ein wesentliches Mittel der Beschreibung von Prozessen – sowohl in einem Computerprogramm als auch in Organisationen – stellt die Abbildung von alternativen Operationen dar. Die Auswahl einer Alternative ist üblicherweise abhängig von einer Bedingung, die geprüft werden kann – in einem Computerprogramm könnte dies das Überschreiten eines Grenzwertes in einer Variable sein, in einer Organisation etwa das Vorhandensein eines bestimmten Dokuments oder die Entscheidung einer für die Ausführung des Ablaufs verantwortlichen Person. Alternativen werden in Flowcharts durch Verzweigungen abgebildet (dargestellt als Rauten), die durch einen eingehenden Pfeil von der vorhergehenden Operation und mit zwei ausgehenden Pfeilen mit den alternativ ausgeführten nachfolgenden Operationen verbunden sind. Die Einschränkung auf genau zwei (und nicht mehrere) nachfolgende Operationen ist ebenfalls der Herkunft von Flowcharts aus der Abbildung von Computerprogrammen geschuldet, da diese eine Bedingung üblicherweise ausschließlich binär (d. h. als wahr oder falsch) auswerten können. Soll eine Bedingung auf mehr als zwei Ausprägungen geprüft werden, so müssen in Flowcharts mehrere Verzweigungen kaskadiert eingesetzt werden. Die ausgehenden Verbindungen werden mit der jeweiligen Ausprägung beschriftet, bei der nach der Prüfung der Bedingung das

Abb. 3.1 Notationselemente von Flussdiagrammen

3.2 Flussdiagramme: Flowcharts

75

Programm fortgesetzt wird. Eine wiederholte Ausführung von Operationen (etwa solange noch Dokumente vorhanden sind, die bearbeitet werden müssen) wird abgebildet, in dem mit einer ausgehenden Verbindung zu einer früheren Operation zurückgesprungen wird. Die andere ausgehende Verbindung leitet dann zu jenem Ablaufteil über, der ausgeführt wird, sobald die wiederholte Ausführung abgeschlossen ist. Neben diesen Grundelementen bieten Flowcharts in manchen Varianten noch spezielle Sprachelemente, die vor allem der Abbildung von spezifischen Operationen im Anwendungsgebiet dienen (bei Computersystemen etwa Ein- oder Ausgabeoperationen). Für das konzeptionelle Verständnis von Flowcharts und vor allem deren Anwendung in der Geschäftsprozessmodellierung sind diese jedoch nicht relevant. Im Folgenden betrachten wir die Verwendung der Notationselemente anhand von Beispielen aus der Geschäftsprozessmodellierung. Die verwendete Notation orientiert sich an den durch das ANSI bzw. die DIN in den 1960er-Jahren festgelegten Symbolik.

3.2.2

Beispiele

Das Beispiel in Abb. 3.2 zeigt einen Prozess mit einer einzelnen Operation, in der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, nachdem die Bearbeitung des Antrags abschlossen wurde. Im Beispiel in Abb. 3.3 ist der Prozess um eine Entscheidung erweitert. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über dessen Bestätigung oder Ablehnung. Das Bestätigen bzw. Ablehnen selbst sind wiederum Operationen. Die ausgehenden Verbindungen werden zusammengeführt, nachdem die alternativen Zweige abgeschlossen sind. Ist es nun notwendig, eine Entscheidung zu treffen, die mehr als zwei mögliche Ausgänge hat, muss dieser Sachverhalt in Flowcharts mittels kaskadierter Entscheidungselemente dargestellt werden. Dies ist im Beispiel in Abb. 3.4 zu sehen. Offensichtlich handelt es sich bei unseren Anträgen um Investitionsbegehren. Die erste Entscheidung prüft nun, Abb. 3.2 Einfaches Flussdiagramm

76

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.3 Flussdiagramm mit Entscheidung

Abb. 3.4 Flussdiagramm mit kaskadierten Entscheidungen

3.2 Flussdiagramme: Flowcharts

77

Abb. 3.5 Flussdiagramm mit Schleife

ob die Investition weniger als 1000 e kostet. Ist dies der Fall, wird der Antrag direkt bestätigt. Ist dies nicht der Fall, kommt es zu einer zweiten Entscheidung. Diese prüft, ob die Antragssumme kleiner als 10.000 e ist. Wenn dies der Fall ist, liegt die Antragssumme zwischen 1000 e und 9999 e, was zu einer Prüfung der Beilagen zum Antrag führt. Wenn die Antragssumme nicht kleiner als 10.000 e ist, also 10.000 e oder mehr beträgt, wird der Antrag weitergeleitet. Wir erfahren hier nichts über das Ziel der Weiterleitung, da Flowcharts dafür keine Notationselemente anbieten. Wie bereits erwähnt, können Verzweigungen auch genutzt werden, um Teile eines Prozesses wiederholt abzuarbeiten. Dazu wird die Entscheidung am Ende des zu wiederholenden Teils eingefügt und ein ausgehender Zweig vor die erste Operation des zu wiederholenden Teils zurückgeführt. Der andere ausgehende Zweig führt den Prozess nach der wiederholten Abarbeitung weiter. Im Beispiel in Abb. 3.5 werden also solange Anträge bearbeitet, solange noch weitere Anträge vorhanden sind. Wichtig ist hier zu verstehen, dass zumindest ein Antrag bearbeitet werden muss, bevor es zu einer Entscheidungsprüfung kommt. Soll der Prozess enden können, wenn gar keine Anträge vorliegen, müsste eine zusätzliche Entscheidung am Beginn des Prozesses eingefügt werden („Anträge vorhanden?“), von der eine ausgehende Verbindung („nein“) direkt zum Ende des Prozesses führt. Die andere ausgehende Kante („ja“) würde zum bereits abgebildeten Prozessablauf weiterführen.

3.2.3

Einordnung

Flowcharts bieten eine einfache Möglichkeit, Geschäftsprozesse hinsichtlich der logischen Abfolge der enthaltenen Aktivitäten abzubilden. Andere Aspekte eines Geschäftsprozes-

78

3 Modellierungssprachen für Geschäftsprozesse

ses, wie Daten oder Verantwortlichkeiten, sind im Sprachumfang nicht vorgesehen und können deshalb nicht abgebildet werden. Die Abbildung von parallelen Abläufen ist ebenfalls nicht möglich. Dies ist ein maßgeblicher Grund dafür, dass Flowcharts zum Teil von aktuelleren Sprachen wie UML-Aktivitätsdiagrammen oder BPMN abgelöst werden, die dafür Konstrukte anbieten. Da Flowcharts keine Verantwortlichkeiten abbilden lassen, ist auch die Abbildung von Kommunikationsvorgängen nicht möglich – diese Einschränkung wurde ebenfalls durch modernere Sprachen adressiert, die wir in den folgenden Abschnitten behandeln.

3.3

Ereignisgesteuerte Prozessketten

Ereignisgesteuerte Prozessketten (EPKs) waren lange Zeit in Europa der de-facto Standard zu Abbildung in Geschäftsprozessen in den industriellen Praxis. Sie wurden als Teil des bereits vorgestellten ARIS-Konzeptes (vgl. 2.6.1.4) spezifiziert und dienen dort als Mittel zur Abbildung von Modellen der Steuerungssicht einer Organisation – also jener Sicht, die sich mit den Abläufen in einer Organisation und der dort stattfindenden Verknüpfung zwischen deren unterschiedlichen Ressourcen beschäftigt. Ressourcen können hier im Speziellen aus aktiver Sicht die handelnden Organisationsmitglieder bzw. -einheiten, sowie aus passiver Sicht die benötigten und manipulierten Daten sein (Nüttgens und Rump 2002; Scheer et al. 1992). Die EPK verknüpft die Funktionen, die eine Organisation ausführen kann, auf Basis von auftretenden Ereignissen miteinander. Das grundlegende Abbildungsprinzip ist dabei, dass eine Funktion immer durch ein Ereignis ausgelöst wird – dass also vor einer Funktion immer ein Ereignis modelliert werden muss, um feststellen zu können, ob mit der Ausführung einer Funktion begonnen werden kann. In der umfassenderen Variante „erweiterte EPK (eEPK)“ sind den Funktionen die für deren Ausführung relevanten Elemente der anderen ARIS-Sichten zugeordnet. Insbesondere können aus der Organisationssicht die ausführenden Akteure, Rollen oder Organisationseinheiten zugeordnet werden, aus der Datensicht die relevanten Dokumente oder Datenobjekte. Wenn eine Funktion eine abrechenbare Leistung erbringt, so kann diese durch Elemente der Leistungssicht abgebildet werden. Neben der Abbildung von Entscheidungen im modellierten Ablauf ermöglicht die EPK auch die Abbildung von parallelen Abläufen in einem Geschäftsprozess. Dafür stellt sie zusätzliche Notationselemente zur Verfügung, die sich an den Operatoren der Bool’schen Logik orientieren – mittels UND-Konnektoren können parallel ablaufende Prozesszweige spezifiziert werden, der XOR-Konnektor dient dazu, Entscheidungen abzubilden, bei denen genau eine Alternative gewählt werden muss (dies entspricht dem Entscheidungselement bei Flowcharts). Mit dem ODER-Konnektor können Prozesse modelliert werden, bei denen aus einer oder mehreren Alternativen gewählt werden kann.

3.3 Ereignisgesteuerte Prozessketten

3.3.1

79

Notationselemente der EPK

Das Grundelement zur Beschreibung von Geschäftsprozessen ist bei EPKs, ähnlich wie bei Flowcharts, die Funktion (bei Flowcharts: Operation). Die Abfolge der Funktionen in einem Prozess wird aber nicht ausschließlich über Verbindungspfeile festgelegt. Durch den Einsatz von Ereignissen wird der Ablauf hier genauer spezifiziert. Jede Funktion wird durch ein Ereignis ausgelöst und erzeugt selbst ein oder mehrere Ereignisse. Ein Prozess wird also durch eine Folge von Ereignissen und Funktionen dargestellt, wobei sich Ereignisse und Funktionen immer abwechseln. Bei der Benennung muss hier darauf geachtet werden, dass Funktionen einen Vorgang beschreiben (etwa „Antrag prüfen“), während Ereignisse einen Zustand beschreiben (etwa „Antrag bestätigt“ oder „Antrag abgelehnt“). Eine EPK beginnt und endet immer mit einem Ereignis. Ereignisse, die einen Prozess auslösen, sind Start-Ereignisse. Ereignisse, die den Abschluss eines Prozesses beschreiben, sind Ende-Ereignisse. Folgeprozesse können durch Ende-Ereignisse eines vorangegangenen Prozesses ausgelöst werden, d. h. ein Ende-Ereignis kann in einem anderen Prozess ein auslösendes Start-Ereignis darstellen. Durch den Einsatz unterschiedlicher Konnektoren (siehe Abb. 3.6) können nun in Kombination mit Ereignissen verschiedene Ablaufvarianten eines Prozesses innerhalb eines Modells abgebildet oder auch die Möglichkeit zur parallelen Ausführung von Funktionen (wenn diese nicht voneinander abhängig sind) dargestellt werden. Es lassen sich der UND-, ODER- und XOR-Konnektor unterscheiden. Wird ein UND-Konnektor mit mehreren ausgehenden Verbindungen verwendet, so bedeutet dies, dass alle ausgehenden Pfade parallel durchlaufen werden. Diese werden dann in der Regel an einer zeitlich bzw. kausal nachgelagerten Stelle wieder mit einem weiteren UND-Konnektor zusammengeführt. Die darauf folgende Funktion wird erst ausgeführt, wenn alle der zusammengeführten Pfade abgeschlossen sind. Ein ODER-Konnektor mit mehreren ausgehenden Kanten zeigt an, dass ein oder mehrere der folgenden Pfade parallel durchlaufen werden. Diese Pfade werden zumeist an einer späteren Stelle wiederum mit einem ODER-Konnektor zusammengeführt, wobei der dann folgende Prozessschritt erst dann durchgeführt wird, wenn genau die Pfade, die bei der entsprechenden ODER-Verzweigung ausgewählt wurden, abgearbeitet sind. Wichtig ist hier, dass die zu aktivierenden Pfade zum Zeitpunkt des Eintreffens beim Konnektor ausgewählt werden müssen. Hinter jedem ODER-Konnektor muss sich auf je-

Abb. 3.6 Notationselemente von EPKs

80

3 Modellierungssprachen für Geschäftsprozesse

dem Pfad ein Ereignis befinden, das durch die vorangegangene Funktion ausgelöst werden könnte. Es werden jene Pfade aktiviert, deren erste Ereignisse tatsächlich eingetreten sind. Ein XOR-Konnektor steht schließlich für ein „exklusives Oder“ bzw. ein „entweder, oder“. Die Verwendung eines XOR – Konnektors mit mehreren ausgehenden Kanten bedeutet, dass bei der Durchführung des Prozesses genau einer der folgenden Pfade ausgewählt wird. Er eignet sich also zur Abbildung von einander ausschließenden Alternativen in der Prozessabarbeitung. Bei der Zusammenführung dieser Pfade mit einem XOR-Konnektor wird der folgende Schritt dann ausgeführt, wenn der ausgewählte Pfad fertig durchlaufen wurde. Auch bei einem XOR-Konnektor muss sich auf jedem Pfad ein Ereignis befinden, das durch die vorangegangene Funktion ausgelöst werden könnte. Diese Ereignisse müssen einander ausschließen. Es wird jener Pfad aktiviert, dessen erstes Ereignis tatsächlich eingetreten ist. Im Gegensatz zu Flowcharts ist es hier möglich, auch mehr als zwei Alternativen zu beschrieben, solange die eingesetzten Ereignisse einander ausschließen.

3.3.2

Beispiele zur EPK

Wir verwenden hier vorerst die gleichen Beispiele, wie sie für Flowcharts angegeben wurden, um die Unterschiede in der Notation zu visualisieren. Das Beispiel in Abb. 3.7 zeigt einen Prozess mit einer einzelnen Funktion, in der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, nachdem der Antrag geprüft wurde. Im Beispiel in Abb. 3.8 ist der Prozess um eine Entscheidung erweitert. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung auf Basis deren positiven oder negativen Beurteilung. Das Bestätigen bzw. Ablehnen selbst sind ebenfalls Funktionen. Die ausgehenden Verbindungen werden mit einem XOR-Konnektor zusammengeführt, nachdem die alternativen Zweige abgeschlossen sind. Die Darstellung von Entscheidungen, die mehr als zwei mögliche Ausgänge haben (siehe Abb. 3.9), ist hier nun einfacher möglich als bei Flowcharts. Dem XOR-Konnektor werden in diesem Fall drei Ereignisse nachgelagert, die sich alle auf die Investitionssumme beziehen und einander ausschließen. Abb. 3.7 Einfache EPK

3.3 Ereignisgesteuerte Prozessketten

81

Abb. 3.8 EPK mit Verzweigung

Der XOR-Konnektor kann auch genutzt werden, um Teile eines Prozesses wiederholt abzuarbeiten. Dazu wird der Konnektor am Ende des zu wiederholenden Teils eingefügt und ein ausgehender Zweig auf das Ereignis zurückgeführt, das den zu wiederholenden Teil auslöst. Der andere ausgehende Zweig führt den Prozess nach der wiederholten Abarbeitung weiter und muss dementsprechend zu einem Ereignis führen, das den Abbruch der Wiederholung auslöst. Im Beispiel in Abb. 3.10 werden also solange Anträge bearbeitet als Anträge vorhanden sind. Der UND-Konnektor kann zum Einsatz kommen, wenn zwei Funktionen unabhängig voneinander ausgeführt werden können (siehe Abb. 3.11). Der im Beispiel modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich unabhängig vom Antrag geprüft werden können. Ist dies nicht der Fall, müssten die beiden Funktionen sequenziell angeordnet werden. Aus Sicht der Modellerstellung ist hier anzumerken, dass dem UNDKonnektor im Gegensatz zu den anderen Konnektoren nicht unmittelbar Ereignisse folgen müssen, da ja keine Entscheidung getroffen wird, sondern in jedem Fall alle ausgehenden Zweige aktiviert werden. Die Abb. 3.12 zeigt ein Beispiel für den Einsatz des ODER-Konnektors. Hier gehen wir davon aus, dass ein Antrag Angebote oder Stellungnahmen oder beides enthalten kann

82 Abb. 3.9 EPK mit Verzweigung für drei Alternativen

Abb. 3.10 EPK mit Schleife

3 Modellierungssprachen für Geschäftsprozesse

3.3 Ereignisgesteuerte Prozessketten Abb. 3.11 EPK mit UND-Konnektor und parallel ablaufenden Zweigen

Abb. 3.12 EPK mit ODER-Konnektor und optional parallel ablaufenden Zweigen

83

84

3 Modellierungssprachen für Geschäftsprozesse

(aber zumindest Angebote oder Stellungnahmen enthalten muss). Wären Angebote und Stellungnahmen vollkommen optional (könnten also beide fehlen), würde deren grundsätzliche Notwendigkeit mit einem vorgelagerten XOR-Konnektor und entsprechenden Ereignissen zu prüfen sein. Alternativ könnte nach dem ODER-Konnektor ein zusätzlicher Zweig mit einem Ereignis „Antrag alleine genügt“ eingefügt werden. In beiden Fällen muss darauf geachtet werden, dass die Bedingung, dass sich Ereignisse und Funktionen auf allen Pfaden durch den Prozess abwechseln, nicht verletzt wird. Falls nicht anders möglich, muss dies durch eine „Dummy“-Funktion, die keine Aktivität verursacht, gewährleistet werden.

3.3.3

Ergänzende Notationselemente der eEPK

Die eEPK ergänzt nun den in einer EPK abgebildeten Geschäftsprozess um Information über dessen Ausführungskontext. Insbesondere werden hier den Funktionen Verantwortlichkeiten und Ressourcenbedarf zugeordnet. Die grundsätzlichen Regeln einer EPK bleiben wie oben beschrieben in Kraft. Die zusätzlichen Elemente können Funktionen zugeordnet werden. Ereignisse sind nicht betroffen. Wir verzichten an dieser Stelle auf eine vollständige Beschreibung der möglichen Elemente und führen nur die gängigsten an (siehe Abb. 3.13). Verantwortlichkeiten werden durch Organisationale Einheiten abgebildet. Solche Einheiten sind üblicherweise nicht konkrete Personen, sondern werden abstrakt durch die Benennung von Rollen (etwa: GeschäftsführerIn) oder Abteilungen (etwa: Finanzbuchhaltung) angeführt. Dadurch wird gewährleistet, dass die Spezifikation eines Prozesses von der Verfügbarkeit konkreter Personalressourcen unabhängig ist und erst zur Durchführungszeit konkrete Personen zugewiesen werden müssen. Die Zuordnung zu einer Funktion erfolgt durch ungerichtete Linien. Eine organisationale Einheit kann so mehreren Funktionen zugeordnet werden. Auch ist es möglich, organisationale Einheiten mehrfach anzuführen, wenn die Prozessdarstellung dadurch übersichtlicher wird. In ähnlicher Form werden Anwendungssysteme modelliert. Sie kennzeichnen die Notwendigkeit, bei der Ausführung einer Funktion ein bestimmtes IT-System einzusetzen (z. B. ein ERP-System oder eine Datenbank). Sie werden Funktionen ebenfalls mit ungerichteten Linien zugeordnet. Informationsobjekte werden dazu verwendet, um die Datenverarbeitung in einem Geschäftsprozess darzustellen. Ein Informationsobjekt kann beliebig umfassend sein (also ein einzelner Wert ebenso wie ein vollständiges Dokument) und wird einer Funktion

Abb. 3.13 Zusätzliche Notationselemente in eEPKs

3.3 Ereignisgesteuerte Prozessketten

85

immer mittels einem gerichteten Pfeil zugeordnet, der den Datenfluss beschreibt. Endet der Pfeil bei der Funktion, bedeutet dies, dass das Informationsobjekt zur Durchführung der Funktion benötigt wird. Endet der Pfeil beim Informationsobjekt, so bedeutet dies, dass es durch die Funktion erzeugt oder verändert wird. Ein Informationsobjekt kann dabei mehrere ein- und ausgehende Verbindungen haben, wodurch sowohl dessen Entstehung als auch dessen Verwendung in einem Geschäftsprozess beschrieben werden kann.

3.3.4

Beispiele zur eEPK

Zur Illustration von eEPKs ergänzen wir eines der oben angeführten Beispiele um den stattfindenden Datenfluss sowie die benötigten Personal-Ressourcen (siehe Abb. 3.14). Anwendungssysteme würden analog zur Verwendung von organisationalen Einheiten modelliert werden. Hinsichtlich des Datenflusses erkennen wir nun, dass zum Prüfen des Antrags der eigentliche Antrag vorhanden sein muss. Diese Prüfung führt nicht nur zur positiven oder negativen Beurteilung eines Antrags im Prozessablauf, sondern auch zu einem Informationsobjekt, in dem die Beurteilung gespeichert ist. Im Falle einer negativen

Abb. 3.14 Beispiel für eine eEPK

86

3 Modellierungssprachen für Geschäftsprozesse

Beurteilung wird dieses Informationsobjekt benötigt, um die Ablehnung zu erstellen (wir können also annehmen, dass die Ablehnung eine inhaltliche Begründung enthält). Im Falle der Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt – wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt. Hinsichtlich der Verantwortlichkeiten erkennen wir nun, dass mehrere organisationale Einheiten am Prozess beteiligt sind. Während die Antragsprüfung durch eine SachbearbeiterIn erfolgt, ist für die endgültige Bestätigung oder Ablehnung die AbteilungsleiterIn zuständig. Wichtig ist hier, dass die Ereignisse, auf Basis derer die Entscheidung getroffen wird, durch die Funktion „Antrag prüfen“ ausgelöst werden, für welche die SachbearbeiterIn zuständig ist. Im vorliegenden Prozessmodell hat also die Abteilungsleitung nur noch die Aufgabe, die Entscheidung (Ablehnung oder Bestätigung des Antrags) zu kommunizieren.

3.3.5

Einordnung

Die EPK bietet umfassendere Möglichkeiten zur Abbildungen von Geschäftsprozessen als Flowcharts. Gemein ist ihnen die Orientierung an den Abläufen innerhalb einer Organisation als primäres Strukturierungsmerkmal des Geschäftsprozesses (d. h. alle im Modell abgebildete Information ist an der Beschreibung des Prozessablaufs verankert). Dies ist zwar naheliegend, wenn ein organisationaler Prozess beschrieben wird, aber – wie wir später sehen werden – nicht unbedingt die einzige Möglichkeit. Andere Modellierungssprachen nutzen Akteure oder Daten als primäre Strukturierungsmerkmale, an denen alle anderen Informationen verankert werden und machen so Aspekte des Prozesses sichtbar, die in (e)EPKs nur implizit abgebildet werden können (wie etwa der Übergang von Verantwortlichkeiten im Prozess und die dabei notwendige Kommunikation zwischen den Akteuren). Die Notwendigkeit, Funktionen und Ereignisse einander immer abwechseln zu lassen, führt in EPKs zu sehr umfangreichen und zum Teil nur schwer verständlichen Modellen. Außerdem birgt sie das Risiko, Modellierende bei der Erstellung der Modelle dazu zu verleiten, Trivial-Ereignisse zu formulieren, die dem Modell keine Information hinzufügen (etwa: Funktion: „Aufgabe ausführen“, Ereignis: „Aufgabe ausgeführt“). Korrekt eingesetzt, bietet diese Systematik aber Vorteile: Einerseits können Prozesse exakter beschrieben und abgegrenzt werden als etwa mit Flowcharts, andererseits erlaubt die EPK eine Verknüpfung zwischen der Sicht auf die Fähigkeiten einer Organisation (ihrer Funktionen) und der Sicht darauf, wie sie mithilfe ihrer Fähigkeiten auf externe Reize oder Ereignisse innerhalb der Organisation selbst reagiert. So können organisationale Fähigkeiten generisch beschrieben und mehrfach in Prozessen eingesetzt werden, wodurch Ineffizienzen durch Replikation vermieden werden. Aus pragmatischer Sicht hat sich in der Praxis jedoch gezeigt, dass sowohl die Spezifikation generischer Funktionen als auch prozess-spezifischer Ereignisse nicht immer in der notwendigen Gesamtheit umsetzbar ist. Modernere Ansätze, wie die im folgenden

3.4 UML-Aktivitätsdiagramme

87

behandelten Aktivitätsdiagramme oder die BPMN, kennen deshalb zwar nach wie vor das Konzept von Ereignissen, setzen diese aber nur ein, wenn tatsächlich auf einen externen Reiz (wie eine eingehende Nachricht, einen Fehler, oder einen Zeitablauf) eingegangen werden soll. In Abgrenzung zu den Modellierungssprachen mit technisch orientierter Entstehungsgeschichte (wie Flowcharts oder die im nächsten Abschnitt beschriebenen Aktivitätsdiagramme) verfolgt die eEPK und das umgebende ARIS-Framework als ein ursprünglich aus der Betriebswirtschaftslehre stammendes Konzept einen umfassenderen Ansatz zur Beschreibung von Geschäftsprozessen. Die Berücksichtigung von Daten, Verantwortlichkeiten, aber auch Zielen oder Leistungen (die hier nicht diskutiert wurden) ermöglicht insgesamt eine umfassende Modellierung von Geschäftsprozessen, die bis heute Einfluss auf die Gestaltung von Modellierungssprachen zur Abbildung organisationaler Phänomene (wie Geschäftsprozessen oder Unternehmensarchitekturen) hat.

3.4

UML-Aktivitätsdiagramme

Das Aktivitätsdiagramm wurde als Teil der UML (Unified Modeling Language) definiert, die eine Sammlung von Diagrammen enthält, die zur Spezifikation von Softwaresystemen geeignet sind (siehe OMG 2017). Das Aktivitätsdiagramm dient dabei analog zum Flowchart zur Abbildung des Verhaltens eines Softwaresystems, stellt aber ob seiner jüngeren Entstehungsgeschichte auch Elemente zur Abbildung verteilter und paralleler Prozessabläufe zur Verfügung. Wie das Flowchart ist auch das Aktivitätsdiagramm zur Abbildung organisationaler Abläufe, also von Geschäftsprozessen, geeignet (Dumas und Hofstede 2001). Während dieses bis heute zu diesem Zweck eingesetzt wird, hat sich der Fokus im Bereich der Geschäftsprozessmodellierung stark hin zur BPMN (Business Process Model and Notation) verschoben. Diese wurde vom gleichen Standardisierungsgremium wie die UML spezifiziert und hat viele Elemente des Aktivitätsdiagramms übernommen hat. Die BPMN fokussiert explizit auf die Anforderungen der Geschäftsprozessmodellierung und der dort abzubildenden organisationalen Aspekte, die wir bereits im Rahmen der EPKs diskutiert haben.

3.4.1

Notationselemente

Ein Aktivitätsdiagramm beschreibt per Definition immer eine Aktivität, die sich aus einzelnen Aktionen zusammensetzt („Aktivität“ wird hier also analog zu „Prozess“ verwendet). Eine Aktion entspricht einer Operation bei Flowcharts oder einer Funktion bei EPKs (siehe Abb. 3.15). Eine Aktivität beginnt üblicherweise mit einem Startknoten und endet mit einem Endknoten (analog zu den Terminierungselementen bei Flowcharts). Zwischen diesen Knoten werden die enthaltenen Aktionen angegeben und durch Ablaufpfeile in die

88

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.15 Notationselemente von UML-Aktivitätsdiagrammen Abb. 3.16 Notationselemente zur Abbildung von Verantwortlichkeiten und Datenflüssen in UML-Aktivitätsdiagrammen

durchzuführende Reihenfolge gebracht. Zur Beeinflussung des Ablaufs ist es möglich, Entscheidungselemente einzufügen. Entscheidungen können beliebig viele ausgehende Zweige haben, deren Aktivierungsbedingungen sich einander ausschließen müssen. Die Bedingungen werden an den ausgehenden Verbindungen angeführt. Die Semantik des Entscheidungssymbols entspricht dem XOR in der EPK – für den ODER-Konnektor gibt es in Aktivitätsdiagrammen keine Entsprechung. Um voneinander unabhängig, parallel ausführbare Prozessteile abzubilden, bietet das Aktivitätsdiagramm das Split/Join-Element. Zum Aufspalten des Ablaufs eingesetzt, kann es beliebig viele ausgehende Verbindungen haben, die alle gleichzeitig aktiviert werden. Die so angelegten Zweige sollten durch ein Join wieder zusammengeführt werden. Der Ablauf wird erst fortgesetzt, sobald alle Zweige abgearbeitet sind. Signale dienen der Kommunikation zwischen Prozessteilen in unterschiedlichen Aktivitäten (also in unterschiedlichen Diagrammen) oder innerhalb einer Aktivität, wenn Information für spätere Prozessteile bereitgestellt werden soll. Sie werden wie Aktionen in den Kontrollfluss eingebaut. Modelle müssen nicht immer vollständige Signalpaare (also gesendete und empfangene Signale) enthalten, sondern können auch Signale für nicht abgebildete Prozesse bereitstellen (also nur ein gesendetes Signal enthalten), oder dieses von einem nicht abgebildeten Prozess entgegennehmen (also nur ein empfangendes Signal enthalten). Empfangene Signale können außerdem eine Aktivität auslösen und damit den Startknoten in einem Diagramm ersetzen. Das Aktivitätsdiagramm bietet auch Elemente, um Verantwortlichkeiten und Datenflüsse abzubilden (siehe Abb. 3.16). Verantwortlichkeiten werden mittels Partitionen abgebildet. Partitionen sind Elemente, die Teile eines Aktivitätsdiagramms umschließen und damit festlegen, dass alle Elemente, insbesondere Aktionen, die von ihnen

3.4 UML-Aktivitätsdiagramme

89

umschlossen sind, in die Verantwortlichkeit der angeführten organisationalen Einheit (oder bei Softwaresystemen, der Systemkomponente) fällt. Wenn Partitionen eingesetzt werden (was nicht verpflichtend ist), so sollten alle Elemente des Aktivitätsdiagramms von genau einer der abgebildeten Partitionen umschlossen werden. Überlappungen sind nicht erlaubt, Aktionen außerhalb einer Partition sollten vermieden werden. Datenobjekte werden in Aktivitätsdiagrammen direkt im Kontrollfluss, und zwar zwischen Aktionen modelliert. Sie können damit (nur) dafür eingesetzt werden, den Informationsfluss zwischen zwei aufeinanderfolgenden Aktionen abzubilden. Wird ein Datenobjekt erst später im Prozessablauf wieder benötigt, so müsste dieses im Kontrollfluss über alle dazwischenliegenden Aktionen weitergegeben oder mittels eines Signals übergeben werden.

3.4.2

Beispiele

Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungssprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Beispiele. Das Beispiel in Abb. 3.17 zeigt eine Aktivität mit einer einzelnen Aktion, in der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Die Aktivität endet, nachdem die Bearbeitung des Antrags abschlossen wurde. Im Beispiel in Abb. 3.18 ist der Prozess um eine Entscheidung mit drei möglichen Ausgängen erweitert, die sich einander ausschließen. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über die weitere Bearbeitung. Auch hier können wir Verzweigungen nutzen, um Teile eines Prozesses wiederholt abzuarbeiten (siehe Abb. 3.19). Dazu wird die Entscheidung am Ende des zu wiederholenden Teils eingefügt und ein ausgehender Zweig zu einer schließenden Entscheidung vor die erste Operation des zu wiederholenden Teils zurückgeführt (eine schließende Entscheidung dient der Zusammenführung und hat mehrere eingehende und nur eine ausgehende Verbindung). Der andere ausgehende Zweig der öffnenden Verzweigung führt den Prozess nach der wiederholten Abarbeitung weiter. Abb. 3.17 Einfaches UML-Aktivitätsdiagramm

90 Abb. 3.18 UML-Aktivitätsdiagramm mit Verzweigung (drei Zweige)

Abb. 3.19 UML-Aktivitätsdiagramm mit Schleife

3 Modellierungssprachen für Geschäftsprozesse

3.4 UML-Aktivitätsdiagramme

91

Das Split/Join-Element kann zum Einsatz kommen, wenn zwei Aktions-Sequenzen unabhängig voneinander ausgeführt werden können (siehe Abb. 3.20). Der im Beispiel modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich unabhängig vom Antrag geprüft werden können. Ist dies nicht der Fall, müssten die beiden Funktionen sequenziell angeordnet werden. Beim zusammenführenden Join-Element wird auf den Abschluss beider eingehender Zweige gewartet, bevor der Prozess fortgesetzt wird. Das Beispiel in Abb. 3.21 zeigt den Einsatz von Partitionen, Datenobjekten und Signalen. Mittels Partitionen werden die Verantwortlichkeiten im Prozess abgebildet (siehe Abb. 3.21). Dessen Auslösung durch ein empfangenes Signal bildet explizit ab, das die Ausführung erst startet, wenn ein Antrag einlangt (das hatten wir bei Flowcharts und den anderen Beispielen zum Aktivitätsdiagramm bislang immer implizit angenommen, Abb. 3.20 UML-Aktivitätsdiagramm mit parallel ablaufenden Zweigen

Abb. 3.21 UML-Aktivitätsdiagramm mit Partitionen, Datenobjekten und Signalen

92

3 Modellierungssprachen für Geschäftsprozesse

aber im Gegensatz zu EPKs nie im Modell abbilden können). Gesendete Signale werden eingesetzt, um die Bestätigung oder Ablehnung an den Empfänger (der hier nicht abgebildet ist) zu übermitteln. Die Beurteilung des Antrags wird nur im Falle einer negativen Beurteilung als Datenobjekt zur Aktion „Antrag ablehnen“ übergeben – wir können folglich annehmen, dass die Ablehnung eine inhaltliche Begründung enthält. Im Falle der Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt – wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt.

3.4.3

Einordnung

Aktivitätsdiagramme vereinen mit gewissen Einschränkungen die Einfachheit der Flowchart-Notation mit der Ausdrucksstärke von EPKs. Sie erlauben es, die Behandlung von Daten im Prozess darzustellen und führen mit Partitionen ein Mittel zur übersichtlichen Abbildung von Verantwortlichkeiten ein. Die Verfügbarkeit von Signalen erlaubt im Gegensatz zu den bisher behandelten Sprachen erstmals eine Abbildung von Kommunikationsvorgängen zwischen Prozessbeteiligten oder mit der Umwelt des abgebildeten Prozesses. Das Fehlen eines Elements, das dem ODER-Konnektor in der EPK entspricht, stellt zwar eine Einschränkung dar, die allerdings in der Praxis selten schlagend wird, da im realen Umfeld zumeist einander ausschließende Alternativen oder vollständig voneinander unabhängige Ausführungszweige vorkommen. Insgesamt stellen Aktivitätsdiagramme also ein geeignetes Mittel zur Abbildung von Geschäftsprozessen dar, vor allem wenn die Zielgruppe für die Modellverwendung einen informationstechnischen Hintergrund hat und mit der Notation bereits vertraut ist. Für andere Zielgruppen ist aufgrund der flexibleren Einsetzbarkeit und der höheren Ausdrucksstärke für Geschäftsprozessmodellierung die BPMN vorzuziehen, die wir im nächsten Abschnitt behandeln werden.

3.5

BPMN

Die BPMN – Business Process Model and Notation – wurde 2002 bei IBM entwickelt und nachfolgend von der BPMI (Business Process Management Initiative) veröffentlicht (siehe Open Management Group and OMG). Ziel war es, der Vielzahl an Prozessmodellierungssprachen, die im akademischen Bereich und der industriellen Praxis eingesetzt wurden, einen universell verwendbaren Standard entgegen zu setzen. Dieser sollte die wesentlichen Eigenschaften der gängigsten Sprachen übernehmen und es ermöglichen, neben der Dokumentation von Geschäftsprozessen auch Modelle zu erstellen, die unmittelbar zur IT-unterstützten Ausführung geeignet sind. Die BPMI wiederum wurde 2005 von der OMG (Object Management Group) übernommen bzw. fusionierte mit dieser. Dadurch wurde BPMN zum OMG-Standard und ergänzt damit die bereits erwähnte UML (Unified Modeling Language).

3.5 BPMN

93

Im dritten Quartal 2010 wurde der neue Standard BPMN 2.0 veröffentlicht. Dieser Standard umfasst unterschiedliche Diagrammtypen: das Choreographie-, das Konversations- und das Kollaborationsdiagramm. Im Folgenden betrachten wir die grundlegenden Elemente der BPMN 2.0, die die Abbildung von Geschäftsprozessen auf fachlicher Ebene ermöglichen. Die BPMN konzentriert sich auf Geschäftsprozesse, welche sie als eine zeitlich logische Abfolge von Aktivitäten (Aufgaben) darstellt und hinsichtlich der organisationalen Verantwortlichkeiten strukturiert. Die Darstellung von Daten ist nur ansatzweise und im Kontext von Prozessabläufen vorgesehen (Chinosi und Trombetta 2011).

3.5.1

Notationselemente zur Modellierung von Abläufen

Prozessdiagramme, die mit der BPMN erstellt wurden, werden „Business Process Diagrams (BPD)“ genannt. Das BPD orientiert sich in seinen Kernelementen an Aktivitätsdiagrammen, die um Elemente ergänzt sind, die die potenziell komplexe Ablaufsteuerung in Geschäftsprozessen abbildbar machen (siehe Abb. 3.22). Im Prinzip müssen in einem Prozess bestimmte Dinge getan werden (Aufgaben), möglicherweise aber nur unter bestimmten Bedingungen (Gateways), und es können Dinge passieren (Ereignisse). Diese drei Flussobjekte werden über Sequenzflüsse miteinander verbunden, jedoch nur innerhalb eines Pool bzw. einer Lane. Pool und Lanes sind Konstrukte um Verantwortlichkeiten in verteilten Geschäftsprozessen darzustellen und werden im Folgenden genauer betrachtet. Falls eine Verbindung über Pool-Grenzen hinweg erfolgt, wird diese mittels Nachrichtenflüssen modelliert, die wir später detaillieren werden. Ein Prozess besteht aus Aufgaben (Tasks). Nach dem Start eines Prozesses (durch ein Ereignis) folgt eine Aufgabe der anderen bis der Prozess endet (durch ein Ereignis). Aufgaben können dabei atomar sein (also nicht weiter verfeinert sein), oder als Subprozess

Abb. 3.22 Grundlegende Notationselemente in BPMN

94

3 Modellierungssprachen für Geschäftsprozesse

vorliegen. In diesem Fall wird eine Aufgabe durch ein eingebettetes weiteres BPD verfeinert, d. h. dessen detaillierter Ablauf dargestellt. Dieser detaillierte Ablauf kann „versteckt“ werden und wird durch ein „+“-Symbol am unteren Rand der Aufgabe repräsentiert. Ein Prozess beginnt mit einem Start-Ereignis und endet in einem End-Ereignis. Die BPMN bietet eine Vielzahl an Möglichkeiten, Ereignisse zu definieren, die einen Prozess auslösen, abschließen oder dessen Verlauf beeinflussen können. Diese werden wir später näher behandeln. An dieser Stelle ist wichtig zu betonen, dass ein Prozess mit einem oder mehreren StartEreignissen beginnen kann und auf jedem Pfad durch den Prozess (siehe Sequenzfluss und Gateways weiter unten) mit einem oder mehreren End-Ereignissen abgeschlossen werden kann. Von jedem Startereignis muss es einen durchgängigen Sequenzfluss zu mindestens einem Endereignis geben. Aufgaben, Gateways oder Zwischen-Ereignisse dürfen keine Endpunkte im Prozess sein, benötigen also auch immer mindestens einen ausgehenden Sequenzfluss. Ein Gateway ist eine Abzweigung im Kontrollfluss. Das exklusive (oder XOR-)Gateway benötigt zu jedem ausgehenden Kontrollfluss eine Bedingung, die sich laut Standard immer auf das Ergebnis einer unmittelbar vorangehenden Aufgabe beziehen muss. Das parallele (oder AND-)Gateway verfolgt alle ausgehenden Kontrollflüsse unabhängig voneinander und parallel weiter. Die verzweigten Kontrollflüsse können separat mit Endereignissen beendet werden oder wieder explizit mit einem weiteren parallelen Gateway zusammengeführt werden. Der Kontrollfluss setzt nach dieser Zusammenführung erst fort, wenn alle eingehenden Kontrollflüsse abgeschlossen sind (entsprechend dem Split/JoinKonzept bei Aktivitätsdiagrammen). Das inklusive (oder OR-)Gateway kann einen oder mehrere Pfade weiterverfolgen, wobei zur Pfadauswahl jeweils (wie beim exklusiven Gateway) eine Bedingung angeführt werden muss. Diese Bedingung muss zum Zeitpunkt der Entscheidung bereits prüfbar sein, die notwendigen Daten müssen also in einer der vorangegangenen Aufgaben erzeugt worden sein. Für Entscheidungen, die nicht auf Basis bereits existierender Daten getroffen werden können, bietet sich die Verwendung des ereignisbasierten Gateways an. Dieses benötigt in jedem ausgehenden Zweig unmittelbar nach dem Gateway ein Ereignis (z. B. eintreffende Nachricht oder Timer). Es wird dann jener Zweig (und nur dieser) aktiviert, dessen Ereignis zuerst eintritt. Dieses werden wir genauer behandeln, wenn wir die Verwendung von Ereignissen diskutieren.

3.5.2

Beispiele zur Modellierung von Abläufen

Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungssprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Beispiele.

3.5 BPMN

95

Abb. 3.23 zeigt einen Prozess mit einer einzelnen Aufgabe, in der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, nachdem die Bearbeitung des Antrags abschlossen wurde. Im Beispiel in Abb. 3.24 ist der Prozess um eine Entscheidung mit drei möglichen Ausgängen erweitert, die sich einander ausschließen. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über die weitere Bearbeitung. In der BPMN ist wichtig, dass die Daten, die als Grundlage einer Entscheidung verwendet werden, vor dem Gateway explizit erzeugt oder empfangen werden. Abb. 3.23 Einfaches BPMN-Modell

Abb. 3.24 BPMN-Modell mit Verzweigung (drei Zweige)

96

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.25 BPMN-Modell mit Schleife

Auch hier können wir Verzweigungen nutzen, um Teile eines Prozesses wiederholt abzuarbeiten (siehe Abb. 3.25). Dazu wird die Entscheidung am Ende des zu wiederholenden Teils eingefügt und ein ausgehender Zweig zu einer schließenden Entscheidung vor die erste Operation des zu wiederholenden Teils zurückgeführt (eine schließende Entscheidung dient der Zusammenführung und hat mehrere eingehende und nur eine ausgehende Verbindung). Der andere ausgehende Zweig der öffnenden Verzweigung führt den Prozess nach der wiederholten Abarbeitung weiter. Die Anforderung, die Entscheidungsgrundlage explizit vor dem Gateway zu schaffen, ist hier durch die zusätzliche Aufgabe abgebildet, das Vorhandensein weiterer Anträge zu prüfen. Das parallele Gateway kann zum Einsatz kommen, wenn zwei Aufgabensequenzen unabhängig voneinander ausgeführt werden können (siehe Abb. 3.26). Der im Beispiel modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich unabhängig vom Antrag geprüft werden können. Ist dies nicht der Fall, müssten die beiden Funktionen sequenziell angeordnet werden. Beim zusammenführenden Gateway wird auf den Abschluss beider eingehenden Zweige gewartet, bevor der Prozess weiter fortgesetzt wird. Das Beispiel in Abb. 3.27 zeigt den Einsatz von Pools, Lanes und Datenobjekten. Mittels Lanes werden die Verantwortlichkeiten im Prozess abgebildet. Mit den bislang eingeführten Elementen der BPMN können wir Kommunikationsvorgänge nicht abbilden. Die in Aktivitätsdiagrammen verfügbaren Signale können deshalb vorerst nicht abgebildet werden, weswegen das Beispiel hier erneut unspezifischer wird. Der Einsatz von Nachrichten-Ereignissen, die wir im übernächsten Abschnitt einführen werden, wird diesen Mangel aber wieder beheben. Die Beurteilung des Antrags wird nur im Falle einer

3.5 BPMN

97

Abb. 3.26 BPMN-Modell mit parallel ablaufenden Zweigen

Abb. 3.27 BPMN-Modell mit Pools, Lanes und Datenobjekten

negativen Beurteilung als Datenobjekt zur Aufgabe „Antrag ablehnen“ übergeben – wir können also annehmen, dass die Ablehnung eine inhaltliche Begründung enthält. Im Fall der Bestätigung des Antrags, wird das Datenobjekt „Beurteilung“ nicht mehr benötigt – wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt.

3.5.3

Notationselemente zur Ablaufsteuerung mit Ereignissen

Ein Unterscheidungsmerkmal von BPMN zu allen bislang behandelten Sprachen ist das hier sehr detailliert und umfassend ausgeführte Ereignis-Konzept, das eine umfassende

98

3 Modellierungssprachen für Geschäftsprozesse

Kontrolle des Prozessablaufs ermöglicht. Ereignisse geben an, dass etwas geschehen ist und sind damit Zeitpunkte im Gegensatz zu Aufgaben, die einen gewissen Zeitraum in Anspruch nehmen. Bis jetzt haben wir nur Start- und Endereignisse eingeführt, im Folgenden werden Start-, Zwischen- und Endereignisse noch einmal ausführlich beschrieben (siehe Abb. 3.28). Ereignisse werden immer mit einem Kreis und üblicherweise einem Symbol dargestellt. Einfache Kreise kennzeichnen Startereignisse, doppelte Kreislinien Zwischenereignisse und dicke Kreislinien Endereignisse. Ist kein Symbol angegeben, handelt es sich um ein untypisiertes (Blanko-)Ereignis, das in der Regel nur am Beginn oder Ende eines Prozesses oder als auslösendes Zwischenereignis zu finden ist.

3.5.3.1 Startereignisse Startereignisse geben den Auslöser für einen Prozess oder Teilprozess an. Häufig wird das unbestimmte (Blanko-)Ereignis verwendet, wenn sich der Auslöser aus dem Zusammenhang ohnehin ergibt oder wenn der Auslöser nicht näher bekannt ist. Wird ein Prozess aufgrund eines Zeitpunkts oder einer Zeitspanne oder eines periodisch stattfindenden Ereignisses ausgelöst, wird zusätzlich das Symbol der Uhr verwendet. Ein Brief-Symbol wird verwendet, wenn eine Nachricht den Prozess auslöst (siehe Abb. 3.29). Darüber hinaus gibt es noch Symbole für Bedingungen – der Prozess wird nur ausgeführt, wenn die angegebene Bedingung erfüllt ist. Ein Signal ist ein Zeichen, durch das der Prozess gestartet wird. Das Fünfeck als Symbol kennzeichnet mehrere mögliche Startereignisse, wobei nur eines der Ereignisse eintreten muss, um den Prozess zu starten (siehe Abb. 3.30). Ein Prozess muss kein einzelnes Startereignis haben, Prozesse können auch mehrere alternative Startereignisse haben. Abb. 3.28 Beispiele für Start-, Zwischen- und Endereignisse

Abb. 3.29 Grundlegende BPMN-Startereignisse

Abb. 3.30 Komplexe BPMN-Startereignisse

3.5 BPMN

99

Abb. 3.31 Grundlegende BPMN-Endereignisse

3.5.3.2 Endereignisse Mit einem Endereignis werden Prozesse beendet, wobei es mit Ausnahme des zeitbezogenen Symbols, der Bedingung und des parallelen mehrfachen Auslösers die gleichen Symbole gibt wie bei den Startereignissen (siehe Abb. 3.31). Zusätzlich zu den verschiedenen Arten von Endereignissen gibt es ein TerminierungsEndereignis (schwarz gefüllter Kreis mit dicker schwarzer Umrandung), das den gesamten Prozess sofort beendet, d. h. die gesamte Prozessinstanz beendet, unabhängig davon, ob andere Sequenzen innerhalb des Prozesses zur gleichen Zeit noch durchlaufen werden oder nicht. Ein Standard-Endereignis beendet immer nur jenen Prozesszweig, in dem es eingefügt ist. Eventuell weitere, noch laufende Prozesszweige werden weiter ausgeführt. Prozesse können, wie bereits bei den Startereignissen erklärt, mehrere Endereignisse haben. Ein Prozess ohne Endereignis ist unvollständig. 3.5.3.3 Zwischenereignisse und das ereignisbasierte Gateway Zwischenereignisse können an irgendeiner Stelle in einem Prozess verwendet werden und werden durch einen Kreis mit doppelter Umrandung dargestellt. Sie werden modelliert, wenn in einem Prozess ein für andere (Prozesse) relevantes Zwischenergebnis erreicht wird, oder innerhalb eines Prozesses auf ein Ereignis reagiert wird, etwa auf eine eingehende Nachricht oder den Ablauf eines bestimmten Zeitraums. Gateways können auch ereignisbasiert sein, wenn ein oder mehrere Ereignisse zum Durchlaufen von verschiedenen Pfaden führen. Dabei kann die Modellierung mit einem ereignisbasierten Gateway erfolgen. Abb. 3.32 zeigt die Prozessmodellierung eines Bewerbungsvorgangs mit Ereignissen. Abhängig davon, ob eine Einladung oder eine Absage eintrifft oder eine Deadline von 2 Wochen abläuft, werden unterschiedliche Wege im Prozess beschritten. Das ereignisbasierte Gateway ist damit das einzige Gateway, bei dem zum Zeitpunkt der Prüfung des Gateways die dafür notwendigen Daten noch nicht vorliegen müssen. Ein ereignisbasiertes Gateway blockiert den Kontrollfluss so lange, bis eines der unmittelbar nachgelagerten Ereignisse eintritt und verfolgt dann den jeweiligen Zweig weiter.

3.5.4

Notationselemente zur Modellierung von Kommunikation

Die BPMN unterstützt auch die Modellierung verteilter Geschäftsprozesse. Die BPMN rückt zwar klar den Prozessablauf bei der Modellierung in den Fokus (wie etwa auch ein Flowchart, eine EPK oder ein Aktivitätsdiagramm), aber auch den ausführenden

100

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.32 Beispiel für den Einsatz des ereignisgesteuerten Gateways

Abb. 3.33 Notationselemente zur Abbildung von Kommunikation in BPMN

bzw. beteiligten Personen eines Prozesses wird Beachtung geschenkt. Die dafür zur Verfügung stehenden Modellierungselemente werden in diesem Abschnitt betrachtet (siehe Abb. 3.33). Ein Pool stellt eine Unternehmung oder eine Organisationseinheit in einer Unternehmung dar, wie z. B. eine Abteilung. Jede (Swim-)Lane in einem Pool repräsentiert eine prozessbeteiligte Person bzw. Rolle, die diesem Pool zugeordnet ist. BPMN bietet die Möglichkeit, das Zusammenspiel von zwei oder mehreren Prozessen aufzuzeichnen. Zum Darstellen von Kollaborationen sind die eben erwähnten Pools und Lanes notwendig, wobei für alle an einem Prozess beteiligten Personen oder Gruppen eine eigene Lane erforderlich ist, für jeden Prozess bzw. jede Organisationseinheit, die für diesen Prozess verantwortlich ist, ein eigener Pool. In jedem Pool entstehen so eigene, individuelle Prozesse mit separaten Start- und Endereignissen. Dennoch kann es vorkommen, dass die einzelnen Prozesse von anderen Prozessen stark beeinflusst werden. Dies kann durch Nachrichtenflüsse modelliert werden. Nachrichtenflüsse geben an, wenn zwischen verschiedenen Prozessen Daten ausgetauscht werden. Innerhalb eines Prozesses (Pool) kann daher kein Nachrichtenfluss stattfinden. Somit ist kein Nachrichtenfluss innerhalb einer Lane und zwischen einzelnen Lanes möglich. Sequenzflüsse zeigen an, welche Aktivitäten in welcher Reihenfolge

3.5 BPMN

101

ausgeführt werden. Sie dürfen im Gegensatz zu Nachrichtenflüssen nur innerhalb eines Pool stattfinden können und nicht zwischen unterschiedlichen Prozessen (Pools). An Nachrichtenflüsse können zusätzlich Nachrichten angebracht werden, die hier als Datenelemente eingesetzt werden und eine genauere Spezifikation der übermittelten Information enthalten. Nachrichtenflüsse dürfen einerseits von Pools und Aktivitäten ausgehen und dort enden, andererseits können sie explizit von Sende-Ereignissen abgeschickt und durch Empfangs-Ereignisse empfangen werden. Der erstgenannte Fall ist für die beschreibende Modellierung von Geschäftsprozessen sinnvoll, bei der ein Kommunikationsvorgang zwar erfasst werden soll, aber nicht notwendigerweise exakt beschrieben werden muss. Eine von einer Aktivität ausgehende Nachricht wird irgendwann im Zuge der Aufgabenausführung gesendet – der genaue Zeitpunkt bleibt unklar. Eine an einem Pool endende Nachricht sagt nur aus, dass die repräsentierte Organisation diese Nachricht empfängt, aber nicht, welche Aktivität sie auslöst. Dies kann sinnvoll sein, wenn externe Organisationseinheiten modelliert werden sollen, deren detailliertes Verhalten unbekannt ist. Nur durch die Verwendung von expliziten Sende- und Empfangsereignissen ist eine exakte Spezifikation von Kommunikationsvorgängen möglich.

3.5.5

Beispiele zur Modellierung von Kommunikation

Im Folgenden ergänzen wir das Beispiel, das wir zur Demonstration des Einsatzes von Ereignissen verwendet haben, um den dort nicht abgebildeten Kommunikationspartner, also das Unternehmen, an das eine Bewerbung gerichtet wird. Das Beispiel in Abb. 3.34 zeigt zwei Prozesse (je einen pro Pool), die über Nachrichtenflüsse miteinander verknüpft sind. Der Prozess des Unternehmens wird durch eine eingehende Bewerbung gestartet, die hier im ersten Nachrichtenfluss abgebildet ist. Nach der Prüfung kann die Entscheidung getroffen werden, ob eine Einladung ausgesprochen oder eine Absage erteilt werden soll. Im oberen Pool wartet der/die BewerberIn auf eine Antwort – allerdings maximal 2 Wochen lang. Durch das ereignisbasierte Gateway wird jener Prozesszweig aktiviert, dessen Ereignis zuerst eintritt. Die jeweils zusammengehörigen Sende- und Empfangs-Ereignisse sind über einen Nachrichtenfluss gekoppelt. Wichtig ist hier, dass Nachrichtenflüsse immer 1:1-Beziehungen abbilden – dass also eine gesendete Nachricht genau einmal empfangen werden kann und dass ein empfangendes Ereignis auf genau eine Nachricht reagieren kann. Das Beispiel in Abb. 3.35 zeigt nun, wie die BPMN verwendet werden kann, um ausschließlich Kommunikationsvorgänge abzubilden. Die Pools werden hier als Blackbox verwendet, das in ihnen enthaltene Verhalten ist nicht abgebildet und bleibt unbekannt. Wir sehen lediglich, dass Nachrichten ausgetauscht werden, wobei die Reihenfolge der Nachrichten nicht definiert ist. Nachdem hier die näher beschreibenden Ereignisse zum Versenden und Empfangen fehlen, ergänzen wir das Modell um Nachrichten-Elemente, um die Kommunikation nachvollziehen zu können. Ein weiterer Unterschied ist der

102

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.34 Beispiel von verteilt ablaufenden Prozessen mit Kommunikationsvorgängen

Abb. 3.35 Ausschließliche Abbildung von Kommunikationsvorgängen in BPMN

im oberen Pool angebrachte Modifikator (drei senkrechte Striche), der eine parallele Mehrfachausführung des im oberen Pool enthaltenen Prozesses kennzeichnet. Dies bedeutet, dass der Prozess im unteren Pool mit mehreren, parallel unabhängig voneinander eintreffenden Bewerbungen umgehen können würde bzw. müsste.

3.5 BPMN

103

Leere und gefüllte Pools können auch beliebig kombiniert werden. Wollten wir z. B. den Prozess der Bearbeitung einer eingehenden Bewerbung abbilden, könnten wir den Pool „BewerberIn“ unspezifisch belassen, da wir deren Verhalten nicht kennen (und es auch nicht relevant ist), aber wissen müssen, dass wir von dort eine Bewerbung erhalten können und dass wir unsere Antwort dann wieder dorthin adressieren.

3.5.6

Notationselemente zur Modellierung komplexer Sachverhalte

Die BPMN bietet mithilfe der bislang vorgestellten Notationselemente die Möglichkeit, Geschäftsprozesse aus Sicht der durchführenden organisationalen Einheiten darzustellen. Die BPMN lässt dabei die Freiheit, Prozessmodelle vage zu halten oder Teile davon unspezifiziert zu lassen, wenn diese für die Zielsetzung der Modellierung nicht relevant erscheinen. In manchen Fällen soll aber ein Prozess möglichst exakt gefasst und in all seinen vorstellbaren Varianten und möglicherweise auftretenden Ausnahmefällen abgebildet werden. Dies ist etwa notwendig, wenn das Modell die Grundlage für die ITbasierte Unterstützung der abgebildeten Arbeitsprozesse dienen soll. Werden hier Aspekte weggelassen oder verkürzt abgebildet, ergibt sich eine Diskrepanz zwischen dem realen Arbeitsprozess und den auf dem Modell basierenden Unterstützungsmaßnahmen, was letztendlich zu nicht zufrieden stellenden Werkzeugen und Work-Arounds führt. Dieser Abschnitt beschreibt jene Notationselemente der BPMN, die komplexe Ablaufbeschreibungen ermöglichen. Aufgrund der Vielfalt der abbildbaren Szenarien führen wir Beispiele hier direkt bei der Beschreibung der jeweiligen Elemente an.

3.5.6.1 Varianten der Aktivitätsmodellierung Im folgenden Abschnitt werden Besonderheiten der Modellierung von Aktivitäten sowie deren Modellierung als Subprozesse genauer erklärt. Subprozesse Prozesse können mittels Subprozessen modelliert werden. Diese Methode wird meistens verwendet, um bei der Modellierung von großen, umfangreichen Prozessen den Überblick behalten zu können. Subprozesse können dabei diagrammatisch minimiert werden. Dann ist der Prozess nur mehr als kleine Aufgabe im gesamten Prozess zu erkennen und durch ein kleines Plus gekennzeichnet. Subprozesse erlauben aber auch die Zusammenfassung mehrerer Aktivitäten in einen Durchführungskontext, ohne deren genau Reihenfolge festzulegen. Das rechte Modell in der Abb. 3.36 zeigt einen Ad-hoc Unterprozess (durch Tilde gekennzeichnet). Dieses Konstrukt gibt nur an, dass beliebig viele der eingebetteten Aktivitäten durchgeführt werden können, macht aber keine Aussage über deren Zusammenhänge. Das linke Modell legt fest, dass alle vier Subaktivitäten ausgeführt werden müssen, bevor der Subprozess abgeschlossen ist. Es trifft keine Aussage über die Reihenfolge oder sonstige Zusammenhänge – die Aktivitäten können parallel ausgeführt werden.

104

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.36 Beispiel für Subprozesse mit parallel (links) oder ad-hoc (rechts) ausführbaren Aktivitäten

Abb. 3.37 Unterschiedliche Aktivitätstypen

Aktivitätstypen Aufgaben-Typen beschreiben den Charakter einer Aufgabe, also welchen Zweck eine Aufgabe erfüllt. Dabei wird unterschieden nach Service, Empfang, Sendung, Benutzer, Geschäftsregel, Skript, manuell und unbestimmt (siehe Abb. 3.37 von links nach rechts). Diese Modifikatoren müssen nicht unbedingt verwendet werden, konkretisieren aber die Semantik eines Prozessmodells.

Ausführungsverhalten von Aktivitäten Aktivitäten können unterschiedliche Markierungen haben, die das Ausführungsverhalten von Aktivitäten beschreiben. Aktivitäten oder gesamte Prozesse oder Teilprozesse können dabei als Schleife, parallel, sequentiell, ad hoc oder als Kompensation ausgeführt werden (vgl. Abb. 3.38). Bei einer Schleife kann eine Abbruchbedingung zusätzlich zum Symbol angegeben werden. Ist die Abbruchbedingung erreicht, wird die Aktivität oder der betreffende Prozess nicht mehr länger ausgeführt und die jeweilige übergeordnete Sequenz weiter ausgeführt.

3.5 BPMN

105

Abb. 3.38 Modifikatoren zur Abbildung unterschiedlichen Ausführungsverhaltens

Kann ein Prozess parallel ausgeführt werden, so wird dies durch drei vertikale Striche gekennzeichnet. So kann beispielsweise der Prozess „Bewerbung prüfen“ für mehrere eingelangte Bewerbungsunterlagen von mehreren Bearbeitern durchgeführt werden. Ist nur eine parallele Ausführung nicht möglich, die einzelnen Fälle aber unabhängig voneinander, so handelt es sich um eine sequenzielle Mehrfachausführung, die durch drei horizontale Striche gekennzeichnet wird. Bei Ad-Hoc-Prozessen ist die genaue Reihenfolge der enthaltenen Aktivitäten unbekannt und ergibt sich erst während der Ausführung des Prozesses. Solche Prozesse werden über eine Tilde gekennzeichnet (wie oben bereits dargestellt). Es müssen auch nicht alle Aktivitäten abgearbeitet werden. Kompensationsaktivitäten werden im Rahmen der Transaktionsmodellierung verwendet und werden weiter unten beschrieben.

3.5.6.2 Ereignistypen Die BPMN bietet zur detaillierten Ablaufsteuerung eine Vielzahl von unterschiedlichen Events in verschiedenen Ausprägungen an. Während wir diese im Folgenden im Detail behandeln werden, soll hier ein Überblick gegeben und der systematische Aufbau von Events dargestellt werden (siehe Abb. 3.39). Grundsätzlich können Events in drei unterschiedlichen Varianten vorkommen, die wir oben bereits eingeführt haben: • Start-Ereignisse lösen neue Prozessinstanzen aus, starten also die Ausführung eines Prozesses. Sie sind immer „empfangend“, reagieren also auf Stimuli von außen (etwa eingehende Nachrichten, Zeitabläufe etc.). • End-Ereignisse sind Ereignisse, die beim Beenden einer Prozessinstanz ausgelöst werden. Sie sind immer „sendend“, lösen also potenziell Stimuli für andere Prozesse bzw. Prozessteile aus. • Zwischen-Ereignisse treten innerhalb des Sequenzflusses auf, haben also sowohl eine eingehende als auch eine ausgehende Kante (Ausnahme: Link-Event, siehe weiter unten).

106

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.39 Vollständiger Satz an BPMN-Ereignistypen

Start-Ereignisse lassen sich darüber hinaus hinsichtlich ihres Einsatzortes unterscheiden. Sie können zum Auslösen eines gesamten Prozesses oder zum Auslösen von Subprozessen verwendet werden. Der zweite Fall wird als „Ereignis-Teilprozess“ bezeichnet und kann mittels „unterbrechend“ und „nicht unterbrechend“ spezifiziert werden. Im eher üblichen Fall wird durch ein „unterbrechendes“ Startereignis gekennzeichnet, dass der Kontrollfluss vollständig an den Subprozess übergeben wird, innerhalb des jeweiligen Pools also alle anderen Aktivitäten unterbrochen werden. „Nicht unterbrechende“ Ereignis-Teilprozesse werden beim Eintreffen des jeweiligen Ereignisses gestartet, ohne dass die Durchführung der aktuell innerhalb eines Pools ausgeführten Aktivitäten unterbrochen wird. Damit kann etwa auf Ereignisse reagiert werden, die nicht im Hauptprozess eines Pools behandelt werden sollen oder können, deren Auftreten aber eine Reaktion nach sich ziehen soll, ohne dass der Hauptprozess beeinträchtigt wird (etwa Kundennachfragen über die Status einer Auftragsbearbeitung, während dieser Auftrag gerade im Rahmen des Hauptprozesses bearbeitet wird).

3.5 BPMN

107

Zwischenereignisse existieren grundsätzlich in einer „empfangenden“ und einer „sendenden“ Variante. Die „empfangende“ Variante (eingetretenes Ereignis) wartet auf das Eintreffen des spezifizierten Ereignisses und blockiert dabei den Sequenzfluss. Dieser kann also nicht fortgesetzt werden, bis das Ereignis eingetreten ist. Die „sendende“ Variante (ausgelöstes Ereignis) kennzeichnet das Eintreten bestimmter Ereignisse in einem Prozess (oder auch zwischen Prozessen aus unterschiedlichen Pools). Ereignisse treten bei vollständig modellierten Prozessen üblicherweise reziprok auf, d. h. dass zu einem eingetretenen Event auch ein auslösendes Event existiert. Empfangende Zwischenereignisse existieren auch in einer „angehefteten“ Form. Diese Ereignisse werden an Aktivitäten „angeheftet“ (d. h. grafisch an deren (Unter-)Kante angebracht) und kennzeichnen, dass während der Durchführung der Aktivität auf das jeweilige Ereignis reagiert werden können soll. Die Reaktion wird durch einen aus dem angehefteten Event ausgehenden Sequenzfluss spezifiziert, der zu den jeweils durchzuführenden Aktivitäten führt. Das angeheftete Zwischenereignis existiert dabei wiederum in einer unterbrechenden und einer nicht unterbrechenden Form. Die unterbrechende Form bricht die Ausführung der so gekennzeichneten Aktivität ab und setzt den Sequenzfluss ausschließlich über das angeheftete Event fort. Die nicht unterbrechende Form erlaubt die weitere Ausführung der so gekennzeichneten Aktivität, parallel dazu wird aber der vom Event ausgehende Sequenzfluss ausgelöst. Die auslösenden Ereignisse, die zum Eintreten von angehefteten Events führen, können von außen kommen (etwa von anderen Pools eintreffende Nachrichten) oder auch von innerhalb der Aktivität, sofern diese durch einen Subprozess detailliert wird. So kann ein Fehler bei der Ausführung des Subprozesses zu Aktivitäten im Hauptprozess führen, etwa das Dokumentieren des Fehlers und einer Eskalation zu Vorgesetzten. Nachrichten- und Timer-Ereignisse haben wir bereits in der grundlegenden BPMNModellierung verwendet. Die übrigen Ereignistypen betrachten wir nun im Rahmen ihrer jeweiligen Einsatzgebiete.

3.5.6.3 Link-Event Bei komplexeren oder umfangreicheren Abläufen wird die Nachverfolgung von Sequenzflüssen durch das Diagramm manchmal schwierig. Einander kreuzende Sequenzflüsse oder Sequenzflüsse mit vielen Richtungsänderungen erschweren die Lesbarkeit und sind der Verständlichkeit und Übersichtlichkeit abträglich. In derartigen Fällen kann das Link-Event verwendet werden (siehe Abb. 3.40). Im Gegensatz zu den übrigen Events bildet es semantisch kein echtes Ereignis ab, sondern

Abb. 3.40 Beispiel für den Einsatz des Link-Events

108

3 Modellierungssprachen für Geschäftsprozesse

dient lediglich als Konnektor zwischen zwei Sequenzflüssen, die weit voneinander entfernt liegen. Die Kopplung erfolgt dabei über die Bezeichnung des auslösenden und des empfangenden Events. Es muss immer eine 1:1-Zuordnung bestehen – eine implizite Parallelisierung durch ein auslösendes und mehrere gleichnamige empfangende LinkEvents ist folglich nicht zulässig. Link-Events sollten zur Erhöhung der Übersichtlichkeit trotzdem nur in nicht anders auflösbaren Fällen genutzt werden, da das Suchen zusammengehöriger Link-Events im Aufwand das Nachverfolgen komplexer Sequenzflüsse sogar übersteigen kann (sofern keine Werkzeugunterstützung durch Sprungfunktionalitäten oder optische Markierung zusammengehöriger Events besteht). Eine alternative Anordnung von Aktivitäten oder Lanes ist üblicherweise die bessere Wahl.

3.5.6.4 Verwendung von Signalen Nachrichten können in BPMN ausschließlich zur Kommunikation zwischen Pools verwendet werden. Weiters hat eine nachrichtenbasierte Kommunikation immer exakt zwei Endpunkte, kann also immer nur genau einen Sender mit genau einem Empfänger verbinden. Wenn eine Information global innerhalb einer Kollaboration zur Verfügung gestellt werden soll, und dies unabhängig von Poolgrenzen passieren soll, können Signale verwendet werden. Signale können (als Zwischen- oder End-Ereignisse) im Prozess ausgelöst werden und stehen dann sowohl innerhalb des Pools als auch in allen anderen Pools der gleichen Kollaboration zur Verfügung. Signale können dazu eingesetzt werden, alle Pools einer Kollaboration etwa über den Abbruch eines der abgebildeten Prozesse zu informieren. So können alle anderen noch ausgeführten Prozesse ihrerseits ihre Prozesse zum Abschluss bringen und es bleiben keine „Prozesszombies“ zurück, die nicht mehr abgeschlossen werden können, weil etwa aufgrund eines Prozessabbruchs eines Kommunikationspartners eine erwartete eingehende Nachricht nicht mehr ankommt. 3.5.6.5 Behandlung von Ausnahmen und Unterbrechungen Aktivitäten, also Aufgaben und Prozesse, können durch bestimmte Ereignisse abgebrochen oder unterbrochen werden. Dies wird durch Ereignissymbole gekennzeichnet, die der jeweiligen Aktivität angeheftet sind (siehe Abb. 3.41). Wird durch das eintretende Ereignis die Aktivität abgebrochen, wird dies durch zwei durchgehende äußere Kreislinien gekennzeichnet, wird die Aktivität nicht unterbrochen, so wird dies durch zwei gestrichelte Kreislinien dargestellt. Im Beispiel reagieren wir auf das Eintreten eines Timer-Ablaufs. Wir können also modellieren, dass die Ausführung der Aufgabe nicht länger als eine bestimmte Zeitspanne dauern darf (links) oder dauern sollte (rechts), und dass bei Zeitablauf in irgend einer Form reagiert werden muss. Die Reaktion ist in dem vom angehefteten Ereignis ausgehenden Sequenzfluss zu modellieren. Auf dieselbe Art und Weise können auch ungeplante Ereignisse wie Fehler oder Eskalationen modelliert und dargestellt werden.

3.5 BPMN

109

Abb. 3.41 Beispiel für angeheftete Ereignisse (links: nicht unterbrechend, rechts unterbrechend)

Abb. 3.42 Beispiel für die Verwendung von nicht unterbrechenden Timer-Events

Beispiel: Nicht unterbrechende Timer-Events Abb. 3.42 stellt dar, dass der Subprozess, der die Aktivitäten der Bearbeitung einer Bestellung in einem Fast-Food-Restaurant abbildet, nicht länger als 5 Minuten dauern soll. Dauert die Bearbeitung der Bestellung länger als 5 Minuten, soll der Kunde das Geld zurückerhalten. Die Bestellung soll trotzdem noch fertig bearbeitet werde. Im Fall eines unterbrechenden Event würde der Kunde lediglich sein Geld zurückerhalten, nicht aber das bestellte Essen.

3.5.6.6 Terminierung von Prozessen Sequenzflüsse in einem Prozess werden üblicherweise mit einem Endereignis abgeschlossen. Endereignisse beenden jedoch nur die Ausführung des jeweiligen Sequenzflusses. Fall parallel noch weitere Sequenzflüsse aktiv sind, etwa weil sie durch eine paralleles oder inklusives Gateway geöffnet wurden oder weil sie durch angeheftete Events ausgelöst wurden, werden diese weiterhin ausgeführt. Um einen (Sub-)Prozess vollständig und sofort zu beenden (also die Ausführung in allen Zweigen zu beenden), existieren mehrere Möglichkeiten.

110

3 Modellierungssprachen für Geschäftsprozesse

Terminate-Event Das Terminate-Event bricht alle aktiven Zweige eines Prozesses innerhalb eines Pools unmittelbar und sofort ab. Prozesse in anderen Pools sind nicht betroffen und sollten deshalb ggf. vor dem Abbruch durch das Senden eines Signals vom Abbruch in Kenntnis gesetzt werden. Error-Event Das Error-Event zeigt das Auftreten eines semantischen Fehlers an und wird üblicherweise in Subprozessen eingesetzt. Es bricht die Ausführung des Subprozesses ab, der Fehlergrund kann dem Event als Parameter mitgegeben werden. Durch angeheftete empfangende Ereignisse kann auf diese Fehler im übergeordneten Prozess reagiert werden und entsprechende Aktivitäten ausgelöst werden. Angeheftete Fehlerereignisse sind immer unterbrechend, brechen also die Ausführung des Subprozesses (inkl. aller ggf. noch aktiver Sequenzflüsse in Zweigen, in denen kein Fehler aufgetreten ist) ab. Als „schwächere“ Variante kann auch das „Eskalationsereignis“ in identischer Weise verwendet werden. Dieses existiert auch in einer nicht unterbrechenden Form und erlaubt damit die Fortsetzung der Bearbeitung des Subprozesses, in dem das Problem aufgetreten ist. Falls beim Abbruch von Subprozessen die Auswirkungen von bereits durchgeführten Aktivitäten rückgängig gemacht werden müssen, kann auf die im nächsten Abschnitt vorgestellte Transaktionsbehandlung wie in der BPMN vorgesehen zurückgegriffen werden.

3.5.6.7 Transaktionen In BPMN existiert auch die Möglichkeit, Transaktionen in einem Prozess abzubilden. Von einer Transaktion spricht man, wenn eine Menge von Aufgaben eines Prozesses als Gesamtheit vollständig oder gar nicht ausgeführt werden sollen. Insbesondere sollen bei Scheitern einer Aufgabe bestimmte andere bereits abgeschlossene Aufgaben wieder rückgängig gemacht werden. BPMN kennt das Konzept transaktionaler Subprozesse in Kombination mit Kompensierungsereignissen und -aktivitäten. Kompensierung bedeutet, dass bereits ausgeführte Prozessschritte dadurch zurückgerollt werden, indem konkrete Gegenmaßnahmen durch einen weiteren Prozessschritt eingeleitet werden. In einem Transaktionssubprozess (in BPMN gekennzeichnet durch eine doppelte Umrandung) wird jeder Aufgabe über ein angeheftetes Kompensierungszwischenereignis (gekennzeichnet durch ein „Zurückspulen“-Symbol) eine Kompensierungsaufgabe zugeordnet. Bricht die Transaktion ab, so wird für jede Aufgabe, die bereits erfolgreich abgeschlossen wurde, die jeweilige Kompensierung ausgeführt. In diesem Zusammenhang kommt das Abbruch-Event (gekennzeichnet durch „X“) ins Spiel. Als auslösendes Endereignis in einem Transaktionssubprozess bewirkt es dessen Abbruch und damit das Auslösen der Kompensierungen. Wenn es an die Transaktion angeheftet wird, ist es ein empfangendes Zwischenereignis und bestimmt den weiteren Ablauf des Prozesses nach dem Abbruch der Transaktion. Durch das Konzept der Kompensierung kann eine Transaktion auch dann noch zurückgerollt werden, nachdem sie eigentlich schon erfolgreich abgeschlossen wurde. Außerhalb der Transaktion kann ein auslösendes

3.5 BPMN

111

Abb. 3.43 Beispiel für einen Transaktions-Subprozess

Kompensierungsereignis verwendet werden, um die Kompensierung der referenzierten Transaktion nachträglich auszulösen. Abb. 3.43 illustriert diese Konzepte anhand eines Reisebuchungsprozesses. Eine Reisebuchung besteht aus einer Flug- und einer Hotelbuchung, die potenziell parallel vorgenommen werden können. Ist eine der Buchungen nicht möglich, so muss die andere Buchung (falls sie schon ausgeführt wurde) wieder storniert werden. Ein Fehler bei einer einzelnen Buchung löst also den Abbruch der Transaktion aus und führt dazu, dass der Prozess mit einer Fehlernachricht an den Kunden reagiert. Außerhalb der eigentlichen Transaktion führt ein Fehler bei der Belastung der Kreditkarte zur Stornierung der gesamten Buchung.

3.5.6.8 Ereignisgesteuerte Sub-Prozesse Ereignisgesteuerte Sub-Prozesse sind eine Alternative zur Behandlung von auftretenden Ereignissen in (Sub-)Prozessen. Während an Subprozessen angeheftete Events die Reaktion auf diese in den umgebenden Prozess „hinaustragen“, kann diese durch den Einsatz von ereignisgesteuerten Sub-Prozessen lokal gehalten werden. Abb. 3.44 zeigt ein Beispiel für einen Timer-gesteuerten nicht unterbrechenden Subprozess. Es greift das oben bereits verwendete Szenario der Zubereitung einer Bestellung in einem Fast-Food-Restaurant wieder auf. Die Events, mit denen ereignisgesteuerte Subprozesse ausgelöst werden können, sind identisch mit jenen, die an einen Subprozess angeheftet werden können. Beide Varianten können unterbrechend und nicht-unterbrechend sein. Semantisch unterscheiden sie sich wie erwähnt lediglich in der Art der Behandlung des Ereignisses – nämlich lokal innerhalb des Subprozesses oder außerhalb im umschließenden Prozess. Je nach Anwendungsfall

112

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.44 Beispiel für den Einsatz eines nicht unterbrechenden, ereignisgesteuerten Subprozesses

kann die eine oder die andere Variante zu sinnvollen und/oder übersichtlichen Darstellungsformen führen.

3.5.7

Choreographiediagramme

Die explizite Modellierung von Choreographien in Choreographie-Diagrammen wurde in der BPMN 2.0 neu eingeführt. Bei einer Choreographie handelt es sich um den Ablauf von Nachrichtenaustauschen zwischen unterschiedlichen Akteuren. Eine Choreographie ist damit eine andere Sicht auf eine Kollaboration, bei der die Reihenfolge der Nachrichtenübermittlung unabhängig von den Prozessen der einzelnen Akteure dargestellt wird (Decker und Puhlmann 2007). Zwar kann man einer Darstellung der Kommunikation mittels zugeklappten, d. h. leeren, Pools entnehmen, welche Nachrichten zwischen welchen Partnern ausgetauscht werden, doch lassen sich die genaue Reihenfolge, bedingte Nachrichtenflüsse oder Schleifen nicht daraus ersehen. So ist im bislang verwendeten Bewerbungsbeispiel z. B. nicht gezeigt, dass nach dem Eintreffen eines Angebots beim Kunden entweder die Einladungsoder die Absage-Nachricht gesendet wird. Dies lässt sich mit einem ChoreographieDiagramm visualisieren. Abb. 3.45 enthält die Choreographie zu dem oben bereits als Kollaboration gezeigten Beispiel eines Bewerbungsprozesses. Hier sind die Nachrichtenaustauschvorgänge in den Mittelpunkt gerückt. Eine so genannte Choreographie-Aktivität (Choreography Activity) repräsentiert den Austausch einer oder mehrerer Nachrichten zwischen zwei oder mehreren Partnern. Im einfachsten Fall entspricht sie dem Senden einer einzigen Nachricht von einem Partner zu einem anderen.

3.5 BPMN

113

Abb. 3.45 Beispiel für den Einsatz von Choreographieaktivitäten

Jede Choreographie-Aktivität wird von einem der beteiligten Partner ausgelöst, indem er die erste Nachricht sendet. Dieser auslösende Partner wird am oberen oder unteren Rand der Choreographie-Aktivität in einem hellen Feld eingetragen. Die Namen des oder der weiteren Beteiligten werden am anderen Rand in einem dunkleren Feld eingetragen. Wer oben und wer unten eingetragen wird, ist dem/der ModelliererIn freigestellt. Normalerweise wird man bei mehreren Choreographie-Aktivitäten zwischen denselben Partnern die Anordnung beibehalten. Wenn man zusätzlich noch eine Kollaboration modelliert, ist es naheliegend, die vertikale Anordnung der Pools zugrunde zu legen. Entsprechend sind in den Choreographie-Aktivitäten der Abbildung entweder der Kunde oben und die Werbeagentur unten oder aber die Werbeagentur oben und die Grafiker unten eingezeichnet. Choreographie-Aktivitäten mit mehr als zwei Partnern kommen in diesem Beispiel nicht vor. Hierfür kann man oben bzw. unten mehrere Partner-Felder eintragen. Dabei ist aber immer nur ein Feld hell hinterlegt, da nur einer der Partner den Nachrichtenaustausch durch eine initiale Nachricht in Gang setzt. Für die Choreographie-Aktivitäten ist im Choreographie-Diagramm ein Sequenzfluss definiert. Seine Modellierung entspricht im Wesentlichen der Sequenzfluss-Modellierung von Prozessen. Allerdings sind gewisse Elemente der Prozessmodellierung im Zusammenhang mit der Choreographie-Modellierung nicht sinnvoll und daher auch nicht zulässig. So gibt es z. B. keine Nachrichten-Ereignisse innerhalb eines Sequenzflusses, da der Nachrichtenaustausch per Definition Teil der Choreographie-Aktivitäten ist. Entsprechend folgen beispielsweise auf das ereignisbasierte Gateway in der Abbildung keine

114

3 Modellierungssprachen für Geschäftsprozesse

Ereignisse, sondern Choreographie-Aktivitäten. Hierbei wird der Pfad gewählt, dessen Choreographie-Aktivität zuerst durch die jeweilige auslösende Nachricht gestartet wird. Will man wissen, welche Nachrichten in jeder Choreographie-Aktivität ausgetauscht werden, so können diese wiederum in Form kleiner Briefsymbole hinzugefügt und mit dem jeweiligen Partnerfeld verbunden werden. Die Briefe sind ebenso wie die beteiligten Partner farblich gekennzeichnet. Ein helles Briefsymbol steht für die Nachricht, mit der eine Choreographie-Aktivität ausgelöst wird. Die Briefsymbole der anderen Nachrichten sind dunkler dargestellt.

3.5.8

Einordnung

Die BPMN hat sich in den letzten Jahren auch in der industriellen Praxis durchgesetzt. Durch ihren umfassenden Satz an Sprachelementen eignet sie sich für viele Anwendungsbereiche von der Dokumentation bis hin zur automationsgestützten Ausführung von Geschäftsprozessen in Organisationen. Der umfangreiche Sprachschatz wird gleichzeitig aufgrund der gesteigerten Komplexität als Manko der BPMN gesehen (Recker 2010). Insbesondere die Vielzahl an Ereignistypen mit zum Teil nur schwer zu unterscheidenden Bedeutungen führt zu gesteigertem Aufwand beim Erlernen der Sprache. Der mit der möglichen Komplexität der entstehenden Modelle und der damit einhergehenden erschwerten Verständlichkeit wird üblicherweise dadurch begegnet, dass in geeigneten Anwendungsfällen ein reduzierter Sprachumfang verwendet wird. Zur deskriptiven Dokumentation von Geschäftsprozessen ist es üblicherweise nicht notwendig, den vollständigen Satz an Ereignissen und komplexeren Aufgabentypen zu verwenden. Erst wenn ein Prozessmodell etwa durch Simulation validiert oder zur Ausführung gebracht werden soll, müssen die Modelle um Information zu Ausnahmefällen o. ä. angereichert werden. In diesen Fällen kann von den einfacheren Modellen ausgehend eine Detaillierung und Ergänzung vorgenommen werden. Die BPMN ist eine der wenigen Sprachen zur Geschäftsprozessmodellierung, die explizit auf Kommunikationsvorgänge zwischen beteiligten Akteuren eingeht und deren Abbildung ermöglicht. Bei der Definition der Sprache war der Ausgangspunkt zur Spezifikation von Kommunikationsflüssen allerdings die Kopplung technisch getrennter Informationssysteme. Die BPMN geht implizit davon aus, dass es innerhalb eines Pools (also zwischen Lanes) nicht notwendig ist, sich um die Kommunikation zwischen Akteuren zu kümmern, weil alle Zugriff auf die gleiche Informationsinfrastruktur haben. Zwischen Pools werden Nachrichtenflüsse modelliert, die im Rahmen der Ausführung dazu dienen, die Abbildung der im Ausgangspool verwendeten Datenstrukturen auf jene des Ziel-Pools zu beschreiben. Ein Nachrichtenfluss entspricht also im Wesentlichen semantisch einer Datenübergabe von einem Informationssystem zu einem anderen und ist dem entsprechend immer ein Kommunikationsvorgang mit genau einem Sender und genau einem Empfänger – mehrere Empfänger können beispielsweise nicht mit einer einzelnen Nachricht angespro-

3.6 S-BPM und PASS

115

chen werden. Während dieser Mechanismus auch zur Abbildung von nicht-technischer Kommunikation eingesetzt werden kann, ist seine Ausdrucksstärke jedoch beschränkt. Insbesondere kann etwa eine Kommunikation zwischen zwei oder mehreren Akteuren ohne klar abgrenzbare Nachrichten nur auf Umwegen und mehrdeutig modelliert werden. Diese Einschränkung ist jedoch dem Anspruch der Ausführbarkeit der erstellten Prozesse geschuldet und existiert in dieser Form auch in anderen kommunikationsorientierten Ansätzen. Die BPMN fokussiert weiters auf Prozesse mit einem vollständig spezifizierbaren Kontrollfluss. Dies stößt an Grenzen, sobald Prozessteile fallspezifisch sind und nicht vorab im Detail beschreibbar sind. Für derartige Prozesse haben sich in den letzten Jahren unterschiedliche Ansätze gebildet, die entweder auf eine deklarative Modellierung der Ausführungsbedingungen von Prozessteilen abzielen, oder die Kommunikationsvorgänge zwischen den beteiligten Akteuren in den Mittelpunkt stellen. Als Beispiel für letztere Kategorie betrachten wir im nächsten Abschnitt die subjektorientierte Geschäftsprozessmodellierung (S-BPM) und die dort eingesetzte Notation PASS.

3.6

S-BPM und PASS

Ein subjektorientiertes Prozessmodell beschreibt im Gegensatz zu anderen Modellierungsansätzen Geschäftsvorgänge primär aus Sicht von miteinander kommunizierenden Handelnden oder Systemen. Es erfasst, welche Arbeitsschritte eines Geschäftsprozesses durch wen bzw. welches System mit welchen Hilfsmitteln ausgeführt werden, welches Ergebnis dadurch erzeugt wird und für wen dieses bestimmt ist (Fleischmann et al. 2012). Bei der Modellierung nach dem subjektorientierten Ansatz stehen die Subjekte als Repräsentanten für an einem Prozess beteiligte Handelnde bzw. ausführende Systeme im Mittelpunkt der Betrachtung. Es wird im Wesentlichen beschrieben, wer in welcher Form miteinander kommuniziert und wie die einzelnen Akteure auf erhaltene Nachrichten reagieren. Die Beschreibung der Kommunikation erfolgt durch die Definition der Nachrichten, die zwischen den Subjekten ausgetauscht werden. Das Verhalten der Subjekte wird jeweils separat durch Zustandsdiagramme beschrieben, wobei drei unterschiedlichen Zustandstypen zum Einsatz kommen: Ein Subjekt kann auf eine Nachricht warten, eine Nachricht senden oder etwas tun, ohne mit anderen Subjekten zu kommunizieren. Der letztere Zustandstyp wird als Funktionszustand bezeichnet und wird verwendet, um das eigentliche Verhalten, also die Aktivitäten eines Subjekts zu beschreiben.

3.6.1

Notationselemente

Bei der Modellierung nach dem subjektorientierten Ansatz mit der Sprache des Parallel Activity Specification Schema (PASS) stehen die Subjekte als Repräsentanten für an einem Prozess beteiligte Handelnde bzw. ausführende Systeme im Mittelpunkt der Betrachtung.

116

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.46 Notationselemente des PASS-Interaktionsdiagramms

Abb. 3.47 Notationselemente des PASS-Verhaltensdiagramms

Die Modellierung eines Prozesses läuft im Wesentlichen in folgenden Schritten mit zunehmendem Detaillierungsgrad ab: zuerst wird das Subjektinteraktionsdiagramm erstellt, in dem die Subjekte und deren Nachrichtenaustausch modelliert werden. In einem weiteren Schritt wird das Verhalten jedes Subjektes in einem separaten Subjektverhaltensdiagramm (SBD) beschrieben. Für das Subjektinteraktionsdiagramm werden zuerst die an einem Prozess beteiligten Subjekte festgelegt. Ein Subjekt ist eine aktive Einheit, muss aber nicht unbedingt ein menschlicher Akteur sein. Auch technische Systeme können Subjekte sein, solange sie eine aktive Rolle im Prozess einnehmen. Subjekte sind immer abstrakt zu beschreiben, d. h. nicht für konkrete Personen oder Maschinen, sondern auf Basis der notwendigen zu erfüllenden Aufgaben im Prozess festzulegen (also etwa „AntragsprüferIn“, und nicht „Hr. Müller“). Zwischen den Subjekten werden Nachrichten ausgetauscht. Im Interaktionsdiagramm wird nur festgelegt, welche Nachrichten existieren und wer jeweils Sender und Empfänger ist (siehe Abb. 3.46). Die Reihenfolge der Nachrichten wird hier noch nicht festgelegt. Für jedes Subjekt wird im Verhaltensdiagramm beschrieben, in welcher Reihenfolge es Nachrichten sendet und empfängt bzw. interne Funktionen ausführt. Die einzelnen Zustände werden mit Verbindungen (Transitionen) zueinander in Beziehung gesetzt, welche die Zustandsübergänge beschreiben (siehe Abb. 3.47). Deren Verwendung hängt vom jeweils eingesetzten Zustandstyp ab: • Zu jedem Funktionszustand wird beschrieben, was im jeweiligen Verhaltensschritt zu tun ist. Die Endbedingungen eines Funktionszustandes entsprechen den Verbindungen, die vom jeweiligen Funktionszustand ausgehen. Wenn die Funktion zu unterschiedlichen Ergebnissen führen kann, können also verschiedene Folgezustände aktiviert werden. Dadurch wird die Abbildung von alternativen Verhaltensweisen möglich. • In einem Sendezustand wird eine Nachricht an einen Empfänger übermittelt. In ihm wird solange verharrt, bis der Empfänger in der Lage ist, die Nachricht entgegenzuneh-

3.6 S-BPM und PASS

117

men. Wer die Nachricht empfangen soll und welche Nachricht übermittelt wird, wird an der ausgehenden Kante des Sendezustands beschrieben. • In einem Empfangszustand wird so lange verharrt, bis eine der Nachrichten eingetroffen ist, die der Empfangszustand entgegennehmen kann. Da auf unterschiedliche Nachrichten reagiert werden kann, kann je nach Typ der eingetroffenen Nachricht auch ein unterschiedlicher Folgezustand aktiviert werden. Dazu werden wiederum mehrere ausgehende Verbindungen verwendet, an denen beschrieben wird, welche Nachricht von welchem Absender zum entsprechenden Zustandsübergang führt. Auf diese Weise ist es auch möglich, auf die gleiche Nachricht von unterschiedlichen Absendern unterschiedlich zu reagieren.

3.6.2

Beispiele

Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungssprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Beispiele. In den ersten Beispielen findet keine Kommunikation statt, wir fokussieren deshalb auf das Verhaltensdiagramm des jeweils einzigen beteiligten Subjektes. Das Beispiel in Abb. 3.48 zeigt einen Prozess mit einer einzelnen Aufgabe, in der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, nachdem die Bearbeitung des Antrags abschlossen wurde. Ein Verhaltensdiagramm muss immer einen Startzustand haben, der üblicherweise durch ein Dreieck in der linken oberen Ecke gekennzeichnet wird. Außerdem muss ein Endzustand existieren, der durch ein Dreieck in der rechten unteren Ecke gekennzeichnet wird. Um das Verhalten des Subjektes vollständig zu beschreiben, benötigen wir einen Zustandsübergang, der kennzeichnet, unter welchen Bedingungen wir den Zustand „Antrag prüfen“ verlassen können. Deshalb fügen wir hier einen funktionslosen Zustand „Fertig“ ein, den wir als Endzustand kennzeichnen. Im Beispiel in Abb. 3.49 ist der Prozess um eine Entscheidung mit drei möglichen Ausgängen erweitert, die einander ausschließen. Der Antrag wird geprüft, das Ergebnis dieser Abb. 3.48 Einfacher Prozess als PASS-Verhaltensdiagramm

118

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.49 PASS-Verhaltensdiagramm mit Verzweigung (drei Zweige) Abb. 3.50 PASS-Verhaltensdiagramm mit Schleife

Prüfung ermöglicht das Treffen einer Entscheidung über die weitere Bearbeitung. Im Falle einer Investitionssumme ab 10.000 e wird der Antrag weitergeleitet. Dies kennzeichnen wir durch einen Sendezustand und spezifizieren an der ausgehenden Verbindung, wer den Antrag erhalten soll. Damit der Prozess vollständig beschrieben ist, müsste an dieser Stelle auch ein Verhaltensdiagramm für den Vorgesetzten erstellt werden. Auch hier können wir Teile eines Prozesses wiederholt abarbeiten. Dazu wird eine Verbindung am Ende des zu wiederholenden Teils eingefügt, mit einer Wiederholungsbedingung versehen und zum ersten Zustand des zu wiederholenden Teils zurückgeführt (siehe Abb. 3.50). Die andere ausgehende Verbindung führt den Prozess nach der wiederholten Abarbeitung weiter.

3.6 S-BPM und PASS

119

Abb. 3.51 PASS-Interaktionsdiagramm

Abb. 3.52 PASS-Verhaltenssdiagramme zum Interaktionsdiagramm (links: Verhalten Sachbearbeiter; rechts: Verhalten Abteilungsleitung)

Das Beispiel in den Abb. 3.51 und 3.52 zeigt nun einen Prozess mit zwei Subjekten. Abb. 3.51 zeigt das Interaktionsdiagramm. Die beiden Modelle in Abb. 3.52 zeigen die Verhaltensdiagramme von SachbearbeiterIn und AbteilungsleiterIn. Die positive oder negative Beurteilung wird jeweils als Nachricht übermittelt. Die Begründung zur Beurteilung wird nur im Falle einer negativen Beurteilung als Datenobjekt zur Aufgabe „Antrag ablehnen“ übergeben. Im Fall der Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt – wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt.

3.6.3

Erweiterte Formen der Kommunikationsmodellierung

Durch den Fokus von PASS auf die Abbildung von Kommunikationsvorgängen erlaubt diese eine umfassendere und flexiblere Beschreibung derselben als sämtliche zuvor betrachteten Modellierungssprachen. Insbesondere erlaubt die PASS die Abbildung von komplexen Kommunikationsszenarien durch den Einsatz von Inputpools sowie die detail-

120

3 Modellierungssprachen für Geschäftsprozesse

lierte Beschreibung der in Nachrichten ausgetauschten Daten durch Geschäftsobjekte – wie nachfolgend erklärt.

3.6.3.1 Inputpools Ein Inputpool dient einem Subjekt quasi als Postkasten, in dem eingehende Nachrichten gespeichert werden, bis sie im Verhaltensdiagramm benötigt werden. Im Gegensatz zu einem einfachen Postkasten ist ein Inputpool aber konfigurierbar. Es kann festgelegt werden, wie viele Nachrichten welchen Typs zwischengespeichert werden können. Wenn der Inputpool entsprechend seiner Konfiguration nicht in der Lage ist, eine Nachricht entgegenzunehmen, so muss der Sender im Sendezustand warten, bis die Nachricht zugestellt werden kann. Dadurch lassen sich unterschiedliche Kommunikationsszenarien abbilden. Wird der Platz im Inputpool für einen bestimmten Nachrichtentyp auf 0 reduziert, so muss der Sender immer warten, bis der Empfänger bereit ist, die Nachricht entgegenzunehmen. Man spricht dann von synchroner Kommunikation. Wenn der Inputpool so konfiguriert ist, dass er Nachrichten zwischenspeichern kann, muss der Sender nicht warten, bis der Empfänger in jenem Zustand ist, in dem er die Nachricht annehmen kann. Man spricht dann von asynchroner Kommunikation (dies ist die einzige Art der Kommunikation, die in der BPMN abgebildet werden kann). Außerdem erlauben Inputpools, Nachrichten in beliebiger Reihenfolge entgegen zu nehmen. Die Nachrichten müssen also nicht in jener Reihenfolge abgearbeitet werden, in der sie eintreffen, sondern können entsprechend der Bedürfnisse des Empfängers verarbeitet werden. Inputpools haben keine grafische Entsprechung in PASS, sondern sind ein Konzept der Ausführungssemantik. Sie werden für jedes Subjekt textuell bzw. in einem Konfigurationswerkzeug beschrieben. Wenn keine Inputpools definiert werden, so hat die Standardkonfiguration unbegrenzt viele Speicherstellen für beliebige Nachrichten. Das Kommunikationsverhalten entspricht also den Nachrichtenflüssen der BPMN (asynchrone Kommunikation). 3.6.3.2 Geschäftsobjekte Geschäftsobjekte dienen der Spezifikation jener Dinge, die zur Leistungserbringung in einem Geschäftsprozess benötigt werden. Es sind also die Dinge, die in einem Prozess verwendet werden und können Daten genauso umfassen wie physische Ressourcen. Geschäftsobjekte sind passiv, d. h. sie initiieren keine Interaktionen oder Aktionen. Geschäftsobjekte werden von Subjekten bearbeitet und können Nachrichten zugeordnet werden, um diese hinsichtlich ihres Inhalts näher zu spezifizieren. Wie für Inputpools gibt es auch für Geschäftsobjekte keine grafische Entsprechung in der Notation der Modellierungssprache. Sie sind ebenfalls Konzepte der Ausführungssemantik und daher von der technischen Ausführungsumgebung abhängig. Sie werden deshalb üblicherweise tabellarisch angegeben. Eine Grundstruktur von Geschäftsobjekten besteht aus einem Bezeichner, aus Datenstrukturen und Datenelementen. Der Bezeichner

3.6 S-BPM und PASS

121

eines Geschäftsobjektes ergibt sich aus dem Geschäftsumfeld, in dem es eingesetzt wird. Beispiele sind Dienstreiseantrag, Bestellung, Lieferschein, Rechnung etc. Geschäftsobjekte setzen sich aus Datenstrukturen zusammen, deren Komponenten einfache Datenelemente eines bestimmten Typs (z. B. Zeichenkette oder Zahl) oder selbst wieder Datenstrukturen sein können. Um das Verständnis sicherzustellen bzw. zu erleichtern empfiehlt es sich, die Bedeutung der Datenelemente näher zu beschreiben, insbesondere dann, wenn sich diese nicht zweifelsfrei aus den Bezeichnern ableiten lässt. Abb. 3.53 zeigt ein Beispiel für einen Dienstreiseantrag. Dieser besteht unter anderem aus der Datenstruktur „Daten zum Antragsteller“ (Mitarbeiter) mit den Datenelementen für Name, Vorname und Personalnummer und der Struktur „Daten zur Dienstreise“ mit den Datenelementen für Beginn, Ende und Zweck der Reise. In vielen Fällen ändert sich die Semantik eines Geschäftsobjekts während der Prozessausführung, etwa wenn ein Lieferschein in eine Rechnung überführt wird. Für ein

Bedeutung

Datentyp

Kann/Muss

Wertebereich/ Default

Nachname

Character

M

...

Vorname

Character

M

...

Personalnummer

...

Integer

M

...

Organisationseinheit

...

...

K

...

Vergütungsgruppe

...

...

K

...

Reisebeginn

...

Date

M

> = akt. Dat./akt. Dat.

Reiseende

...

Date

M

> = Dat. Reisebeg./...

Internationale Reise

...

Boolean

M

j/n; n

Reisezeil (Ort/Land)

...

Character

M

...

Reisegrund

...

Character

M

...

Gewünschter Vorschuss

...

Integer

K

...

Genehmigungsvermerk

Boolean

M

Kostenstelle

...

Integer

M

...

Gewünschter Vorschuss

...

Integer

K

...

Datenstruktur Daten zum Antragsteller Name Vorname

Daten zur Reise

Daten zur Genehmigung Genehmigung

Abb. 3.53 Dienstreiseantrag als PASS-Geschäftsobjekt

j/n; n

122

3 Modellierungssprachen für Geschäftsprozesse

Geschäftsobjekt können deshalb mehrere verschiedene Zustände definiert werden. Bei einem Wechsel des Status werden nur die Datenstrukturen bzw. Datenelemente des vorherigen Status übernommen, die der neue Status benötigt, und bei Bedarf neue Komponenten hinzugefügt oder nicht mehr benötigte entfernt. Damit ist gewährleistet, dass ein Subjekt nur diejenigen Datenelemente für seine Arbeit zur Verfügung bekommt, die es dafür wirklich benötigt. Dies erleichtert die Einhaltung von Datenschutzbestimmungen. Im Beispiel des Dienstreiseantrags kann aus dem ursprünglichen Status „Reiseantrag“ des Geschäftsobjekts der Status „Dienstreisebuchung“ abgeleitet werden. Dabei werden insbesondere Datenelemente mit internen Angaben wie Personalnummer, Vergütungsgruppe, Reisegrund und die komplette Datenstruktur zur Genehmigung entfernt, welche beispielsweise bei der Einschaltung eines Reiseagenten für die Buchung das Unternehmen nicht verlassen sollen und auch nicht relevant sind. Dafür wird, wie in Abb. 3.54 gezeigt, eine neue Datenstruktur „Daten zur Buchung“ eingefügt. Sie enthält Datenelemente, mit denen die Reisestelle gegenüber dem Reiseagenten eine Frist für den spätesten Eingang der Buchungsbestätigung setzen und bestimmte Hotelketten vorgeben kann, mit denen beispielsweise Rahmenverträge bestehen.

3.6.3.3 Message Guards Die Behandlung einer Ausnahme (auch message guard, message control, message monitoring, message observer genannt) ist eine Verhaltensbeschreibung eines Subjekts, die relevant wird, wenn bei der Ausführung einer Subjekt-Verhaltensspezifikation eine bestimmte Ausnahmesituation eintritt. Sie wird aktiviert, wenn eine entsprechende Nach-

Datenstruktur/ Datenelement

Bedeutung

Datentyp

Kann/Muss

Wertebereich/ Default

Daten zum Antragsteller Nachname

Character

M

...

Vorname

Character

M

...

Reisebeginn

...

Date

M

> = akt. Dat./akt. Dat.

Reiseende

...

Date

M

> = Dat. Reisebeg./...

Reiseziel (Ort/Land)

...

Character

M

...

Genehmigungsvermerk

Character

M

...

...

Date

K

...

...

Boolean

M

Name Vorname Daten zur Reise

Daten zur Buchung Vertragshchelketten Frist für Buchungsbestätigung Buchungsbestätigung

j/n

Abb. 3.54 Dienstreiseantrag im Status Dienstreisebuchung als PASS-Geschäftsobjekt

3.6 S-BPM und PASS

123

richt empfangen wird und das Subjekt sich in einem Zustand befindet, in dem es auf die Ausnahmebehandlung reagieren kann. In einem solchen Fall hat der Übergang zur Ausnahmebehandlung die höchste Priorität und wird erzwungen. Die Ausnahmebehandlung ist dadurch gekennzeichnet, dass sie in einem Prozess in vielen Verhaltenszuständen von Subjekten auftreten kann. Der Empfang bestimmter Nachrichten, z. B. zum Abbruch des Prozesses, führt immer zu demselben Verarbeitungsmuster. Dieses Muster müsste für jeden Zustand, in dem es relevant ist, modelliert werden. Ausnahmebehandlungen verursachen einen hohen Modellierungsaufwand und führen zu komplexen Prozessmodellen, da von jedem betroffenen Zustand ein entsprechender Übergang spezifiziert werden muss. Zur Veranschaulichung der kompakten Beschreibung von Ausnahmebehandlungen wird ein Service-Management-Prozess mit dem Subjekt „Service Desk“ verwendet (vgl. Abb. 3.55). Dieses Subjekt identifiziert im Rahmen der Bearbeitung eines Kundenauftrags einen Bedarf für eine Wartung – ein Mitarbeiter muss den Kunden besuchen, um vor Ort eine Wartung zu durchzuführen. Das Subjekt „Service Desk“ gibt einen Wartungsauftrag an einen Mitarbeiter weiter. Der Mitarbeiter stellt also eine Wartungsanfrage. Der Wartungsauftrag kann prinzipiell in jeder Phase der Bearbeitung bis zum Abschluss storniert werden. Dies gilt folglich auch für die interne Wartungsanfrage und ihre Folgeaktivitäten. Dieses relativ einfache Beispiel zeigt bereits, dass die Berücksichtigung solcher Ausnahmemeldungen die Verhaltensbeschreibung schnell unübersichtlich machen kann, weil zusätzliche Empfangszustände hinzugefügt werden müssen. In diesen zusätzlichen Empfangszuständen wird geprüft, ob eine entsprechende Abbruchmeldung eingetroffen ist. Das Konzept der Ausnahmebehandlung ermöglicht es, Ausnahmen zum Standardverhalten von Subjekten in einer strukturierten und kompakten Form zu ergänzen. Die Abb. 3.56 zeigt, wie sich ein solches Konzept auf das Verhalten des Mitarbeiters auswirkt. Anstatt zusätzliche Empfangszustände mit einem Timeout von Null einzubauen, um zu prüfen, ob eine Nachricht eingetroffen ist, die den Standardkontrollfluss unterbricht, wird die Verhaltensbeschreibung mit einer Ausnahmebehandlung für die Nachricht „Wartung stornieren“ angereichert. Ihr Ausgangszustand ist mit den Zuständen gekennzeichnet, von denen aus in sie verzweigt wird, sobald die Nachricht „Wartung stornieren“ eintrifft. Im Beispiel sind dies die Zustände „Wartungsanfrage ausfüllen“ und „Antwort vom Manager entgegennehmen“. Jeder von ihnen ist durch ein Dreieck am rechten Rand des Zustandssymbols gekennzeichnet. Das Ausnahmeverhalten führt zum Verlassen des Subjekts, nachdem die Nachricht „Wartungsstorno“ an das Subjekt „Manager“ gesendet wurde. Das Verhalten eines Subjekts muss nicht notwendigerweise durch eine Ausnahmebehandlung beendet werden, es kann auch von dort zum angegebenen Standardverhalten zurückkehren. Das Verhalten eines Subjekts bei der Behandlung von Ausnahmen kann unterschiedlich sein, je nachdem, aus welchem Zustand oder durch welche Art von Nachricht (Abbruch, vorübergehendes Anhalten des Prozesses usw.) es ausgelöst wird. Der Ausgangszustand der Ausnahmebehandlung kann ein Empfangszustand oder ein Funktionszustand sein.

124

3 Modellierungssprachen für Geschäftsprozesse

Abb. 3.55 Beispiel für Ausnahmebehandlung

Meldungen, die eine Ausnahmebehandlung auslösen, wie z. B. „Wartung stornieren“, haben immer eine höhere Priorität als andere Meldungen. Auf diese Weise bringen Modellierer zum Ausdruck, dass bestimmte Nachrichten bevorzugt gelesen werden. Wenn z. B. die Genehmigungsnachricht des Managers im Inputpool des Mitarbeiters eingeht und kurz darauf die Abbruchnachricht, wird letztere zuerst gelesen. Dies führt zu den entsprechenden Abbruchfolgen. Da nun weitere Nachrichten zwischen Subjekten ausgetauscht werden können, kann es notwendig sein, die entsprechenden Bedingungen für die Struktur des Eingangspools anzupassen. Insbesondere sollten die Inputpool-Bedingungen die Speicherung einer Interrupt-Nachricht im Inputpool erlauben.

3.6 S-BPM und PASS

125

Abb. 3.56 Beispiel für eine Verhaltenserweiterung

3.6.3.4 Verhaltenserweiterungen Wenn Ausnahmen auftreten, werden laufende Vorgänge unterbrochen. Dies kann zu Inkonsistenzen bei der Verarbeitung von Geschäftsobjekten führen. Beispielsweise wird die Fertigstellung des Geschäftsreiseformulars unterbrochen, sobald eine Stornomeldung eingeht, und der Geschäftsreiseantrag wird nur teilweise fertiggestellt. Solche Folgen werden aufgrund der Dringlichkeit von Stornomeldungen als akzeptabel angesehen. In weniger dringenden Fällen möchte der Modellierer das Verhalten von Subjekten in ähnlicher Weise erweitern, ohne jedoch Inkonsistenzen zu verursachen. Dies kann durch die Verwendung einer Notation analog zur Ausnahmebehandlung erreicht werden. Anstatt das entsprechende Diagramm mit „Ausnahme“ zu bezeichnen, wird es mit „Erweiterung“ beschriftet. Verhaltenserweiterungen reichern das Verhalten eines Subjekts mit Verhaltenssequenzen an, die von mehreren Zuständen aus gleichwertig erreicht werden können. So kann der Mitarbeiter beispielsweise selbst entscheiden, dass die Wartung nicht mehr erforderlich ist, und seine Wartungsanfrage zurückziehen. Abb. 3.56 zeigt, dass der Mitarbeiter in den Zuständen „Wartungsanfrage an Manager senden“ und „Antwort vom Manager entgegennehmen“ eine Wartungsanfrage zurückziehen kann. Wird die Transition „Wartungsanfrage zurückziehen“ im Zustand „Wartungsanfrage an Manager senden“ ausgeführt, so wird die Erweiterung „F1“ aktiviert. Sie führt lediglich zum Stornieren des

126

3 Modellierungssprachen für Geschäftsprozesse

Antrags. Da der Vorgesetzte noch keinen Antrag erhalten hat, braucht er nicht informiert zu werden. Entscheidet sich der Mitarbeiter im Zustand „Antwort vom Manager entgegennehmen“, die Wartungsanfrage zurückzuziehen, so wird die Nebenstelle „F2“ aktiviert. In diesem Fall wird zunächst der Vorgesetzte informiert und dann die Wartung storniert.

3.6.3.5 Wahlsegmente Bislang wurde das Verhalten von Subjekten als eine eindeutige Abfolge von internen Funktionen, Sende- und Empfangsaktivitäten betrachtet. In vielen Fällen ist die Reihenfolge der internen Ausführung jedoch nicht wichtig. Bestimmte Sequenzen von Aktionen können in beliebiger Reihenfolge ausgeführt werden, dies wird als Wahlfreiheit bezeichnet. In diesem Fall gibt der Modellierer keine strikte Reihenfolge der Aktivitäten vor. Vielmehr organisiert ein Subjekt (oder eine konkrete Entität, die einem Subjekt zugeordnet ist) sein Verhalten zur Laufzeit bis zu einem gewissen Grad selbst. Die Wahlfreiheit in Bezug auf das Verhalten wird durch Wahlsegmente beschrieben, die eine Reihe von parallelen Pfaden skizzieren. Am Anfang und am Ende einer jeden Alternative werden Schalter verwendet: Ein am Anfang gesetzter Schalter bedeutet, dass dieser alternative Pfad begonnen werden kann, ein am Ende gesetzter Schalter bedeutet, dass dieser alternative Pfad vollständig durchlaufen werden muss. Daraus ergeben sich die folgenden Konstellationen: • Anfang ist gesetzt/Ende ist gesetzt: Die Alternative muss bis zum Ende abgearbeitet werden. • Anfang ist gesetzt/Ende ist offen: Alternative muss begonnen, aber nicht beendet werden. • Anfang ist offen/Ende ist gesetzt: Alternative kann bearbeitet werden, muss aber abgeschlossen werden. • Anfang ist offen/Ende ist offen: Die Alternative kann bearbeitet werden, muss aber nicht abgeschlossen werden. Die Ausführung eines Wahlsegments gilt als abgeschlossen, wenn alle alternativen Abläufe, die begonnen wurden und abgeschlossen werden mussten, tatsächlich vollständig abgearbeitet wurden und den Endoperator des Wahlsegments erreicht haben. Übergänge zwischen den alternativen Pfaden eines Wahlsegments sind nicht erlaubt. Eine alternative Sequenz beginnt an ihrem Startpunkt und endet vollständig innerhalb ihres Endpunktes. Damit ist die Kerneigenschaft eines Zustandsdiagramms, nämlich dass ein Zustandsdiagramm immer nur einen einzigen aktiven Zustand enthält, nicht verletzt. Abb. 3.57 zeigt ein Beispiel für die Modellierung von Wahlsegmenten. Nach dem Eingang einer Bestellung des Kunden können drei alternative Verhaltenssequenzen gestartet werden, wobei die ganz linke Sequenz mit der internen Funktion „Bestellung aktualisieren“ und dem Senden der Nachricht „Bestellung ausliefern“ an das Subjekt „Lager“ auf jeden Fall gestartet werden muss. Dies wird durch das „X“ im Symbol für den

3.6 S-BPM und PASS

127

Abb. 3.57 Beispiel für ein Wahlsegment

Start der alternativen Folgen bestimmt (grauer Balken ist der Startpunkt für Alternativen). Diese Sequenz muss bis zum Ende des Wahlsegments durchlaufen werden, da sie auch im Endesymbol dieser Alternative mit einem „X“ gekennzeichnet ist (grauer Balken als Endpunkt der Alternative). Die beiden anderen Sequenzen können, müssen aber nicht, gestartet werden. Wird jedoch die mittlere Sequenz gestartet, d. h. die Nachricht „Auftrag eingetroffen“ an die Verkaufsabteilung gesendet, muss diese bis zum Ende abgearbeitet werden. Dies wird durch eine entsprechende Markierung im Endesymbol der Alternative festgelegt („X“ im unteren grauen Balken als Endpunkt der Alternative). Der ganz rechte Weg kann begonnen werden, muss aber nicht zu Ende geführt werden. Diese Art der Visualisierung vereinfacht die Darstellung der Zustandsübergänge radikal, die bei einer traditionellen Zustandsdiagramm-Visualisierung (mit einer einzelnen Verbindung für jeden potentiellen Zustandsübergang) notwendig wäre.

128

3 Modellierungssprachen für Geschäftsprozesse

Die einzelnen Aktionen in den Alternativpfaden eines Wahlsegments können beliebig parallel und überlappend ausgeführt werden, oder anders ausgedrückt: Ein Schritt kann in einer alternativen Sequenz ausgeführt werden und dann von einer Handlung in einer beliebigen anderen Sequenz gefolgt werden. Dies gibt dem Ausführenden eines Subjekts die entsprechende Wahlfreiheit bei der Ausführung seiner Handlungen.

3.6.4

Einordnung

Im Gegensatz zu den anderen bislang besprochenen Modellierungssprachen gibt es in PASS kein einzelnes Diagramm, das einen Geschäftsprozess vollständig beschreibt. Vielmehr wird für jedes Subjekt ein separates Verhaltensdiagramm erstellt, welche durch ein Interaktionsdiagramm miteinander verknüpft werden, in dem der Nachrichtenaustausch beschrieben ist. Dadurch ermöglicht PASS eine lose Kopplung von Prozessteilen und eine einfachere Veränderbarkeit des Verhaltens eines Subjektes, solange dessen Kommunikationsschnittstelle, also der Satz an empfangenen und gesendeten Nachrichten und deren Reihenfolge, unverändert bleibt. Die Verwendung von Zustandsdiagrammen zur Beschreibung des Verhaltens eines Subjekts stellt ebenfalls einen grundlegenden Unterschied zu den anderen bislang behandelten Sprachen dar. Ein Zustandsdiagramm beschreibt – im Namen bereits enthalten – den Zustand eines Systems (hier: eines Subjektes – dies kann genauso ein Mensch wie eine Maschine sein) und die Ereignisse, die zu einem Zustandsübergang führen. Ein Subjekt kann sich immer nur in genau einem Zustand befinden – es ist deshalb per Definition nicht in der Lage, Vorgänge parallel auszuführen. Vielmehr arbeiten alle Subjekte parallel und unabhängig voneinander. Dies bedingt ein Umdenken bei der Modellierung, da Konstrukte wie UND-Konnektoren (in EPKs), Split/Joins (in Aktivitätsdiagrammen) oder parallele Gateways (in BPMN) nicht zur Verfügung stehen. Gleichzeitig führt dieser Modellierungsansatz zu einfacheren, kompakteren Modellen und einem vor allem im Gegensatz zur BPMN deutlich reduzierten Sprachumfang, was der Verständlichkeit der Modelle zuträglich ist.

3.7

Vergleich und Gegenüberstellung

Die hier betrachteten Modellierungssprachen sind unterschiedlich ausdrucksstark und haben aufgrund ihrer historischen Entwicklung unterschiedliche Schwerpunkte in der Abbildung von Aspekten der Geschäftsprozessmodellierung. Dieser Abschnitt versucht, diese Unterschiede nochmals systematisch anhand der im Abschn. 2.8 vorgestellten Prozessdefinition darzustellen und so die Handhabbarkeit der Sprachen ihrer Ausdrucksstärke gegenüberzustellen. Dabei ziehen wir die Semantik der vorgestellten Modellierungselemente als Ausgangspunkt heran.

3.7 Vergleich und Gegenüberstellung

129

Der Referenzpunkt der folgenden Betrachtungen ist die Prozessdefinition aus dem letzten Kapitel, die wir hier der Einfachheit halber nochmals anführen: 1. Prozessstrategie: Prozesse haben a. einen definierten Anfang und Input (Startereignis), b. und weisen ein definiertes Ende mit einem Ergebnis auf, c. zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung beizutragen), 2. Prozesslogik: Ein Prozess a. ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), b. die nach dem Startereignis von Handelnden c. in sachlogischer und zeitlicher Reihenfolge d. zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um e. das gewünschte Ergebnis zu erzeugen. 3. Prozessrealisierung: Ein Prozess wird realisiert a. in dem Menschen und/oder Maschinen die Aufgaben der jeweiligen Handelnden übernehmen, und diese b. mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen Auf Basis dieser Definition können die Konzepte identifiziert werden, die in einem Prozessmodell abbildbar sein müssen, um Prozesse vollständig (entsprechend obiger Definition) abbilden zu können. Abb. 3.58 zeigt diese Konzepte. Mehrfach vorkommende Konzepte werden nur beim erstmaligen Auftreten genannt – wie z. B. „Ergebnis“. Bei Konzepten, die unterschiedlich konkret angeführt sind, werden nur die konkreteren Konzepte betrachtet – z. B. „miteinander verknüpfte Aktivitäten“ als allgemeinere Formulierung von „sachlogische und zeitliche Reihenfolge“. Ordnet man nun die Modellierungselemente der betrachteten Sprachen diesen Konzepten zu, so ergibt sich Abb. 3.59. Zu erkennen ist, dass die konzeptionelle Abdeckung über die Sprachen hinweg variiert. Darüber hinaus zeigt sich, dass nicht alle Sprachen alle Konzepte in gleichem Umfang bzw. in der gleichen Ausdrucksstärke behandeln. Die Zuordnung der Modellierungselemente zu den Konzepten ermöglicht einen ersten Ansatzpunkt für die Einschätzung ihrer Ausdrucksstärke. Nur bedingt erkennbar werden in dieser Übersicht die unterschiedlichen Zugänge in der Abbildung der sachlogischen und zeitlichen Zusammenhänge. Dennoch unterscheiden sich in diesem Punkt die Sprachen wesentlich: Flowcharts bieten keine Möglichkeit zur Abbildung paralleler Abläufe, in EPKs ist lediglich eine starke Kopplung von parallel verlaufenden Aktivitätszweigen vorgesehen, indem diese innerhalb eines Prozesses mittels UND- bzw. ODER-Operator verknüpft werden. UML-Aktivitätsdiagramme und BPMN bieten die gleichen Mechanismen (unter anderen Namen), erlauben aber auch eine lose

130 Abb. 3.58 Kozepte der Geschäftsprozessmodellierung

3 Modellierungssprachen für Geschäftsprozesse

Definitionsteil

Konzept

1a

Anfang Input

1b

Ende Ergebnis

1c

Kundenbedürfnis

2a

Aktivitäten/Aufgaben

2b

Startereignis Handelnder

2c

sachlogische Reihenfolge zeitliche Reihenfolge

2d

Geschäftsobjekt

3a

Mensch Maschine

3b

Sachmittel Information Anwendungsprogramm Hilfsmittel (allgemein)

Kopplung von Prozessen bzw. Prozessteilen mittels Signalen (bei Aktivitätsdiagrammen) bzw. Nachrichtenflüssen (bei BPMN). Insbesondere letzterer Mechanismus ermöglicht eine detaillierte Beschreibung von Kommunikationsabläufen von grundsätzlich unabhängigen Prozessteilen. Eine Einschränkung liegt in der notwendigen Vorabfestlegung von eindeutigen Zuordnungen zwischen Sendern und Empfängern von Nachrichten. S-BPM bietet in PASS einen ähnlichen Kommunikationsmechanismus, ist aber in diesem Punkt flexibler (insbesondere bei Verwendung der in der grafischen Darstellung der Sprache nicht abgebildeten Inputpools). Eine Beschreibung von parallel ablaufenden Prozessteilen ist in PASS nur durch die Verteilung derselben auf unterschiedliche Subjekte möglich – innerhalb eines Subjektes kann immer nur ein Funktionszustand aktiv sein, es können also ausschließlich alternative Zweige im Verhalten eines Subjektes dargestellt werden. Generell bietet die BPMN die größte Flexibilität in der Wahl der Darstellungsform eines Prozesses. Durch die Vielzahl an Modellierungselementen können auch komplexe Zusammenhänge kompakt dargestellt werden, was jedoch höhere Ansprüche an das Sprachverständnis der Modellnutzenden stellt. Einen anderen Ansatz verfolgen hier Aktivitätsdiagramme oder PASS, die auf einem kompakten Satz an Modellierungselementen aufbauen. Dies führt bei komplexen Zusammenhängen zu umfangreichen Modellen, die hohe Ansprüche an die Modellnutzenden hinsichtlich des Modellverständnisses stellt. PASS reduziert die unmittelbar sichtbare Komplexität von Modellen durch die Verteilung

Ablaufpfeil & Entscheidung

sachlogische/

zeitliche

-

Anwendungs-

eEPK

Split/Join

für alternative und parallele

-

-

-

Datenobjekt

Informationsobjekt

Anwendungssystem

-

-

Partition

-

-

Org. Einheiten

Informationsobjekt

Datenobjekt

Ablaufpfeil, Entscheidung,

Ablaufpfeil & Konnektoren Abläufe, Datenfluss

Partition

nur unspezifisch. evtl. durch empfangenes Signal

Aktion

-

Signal

Datenobjekt/gesendetes

Endknoten

empfangenes Signal

Datenobjekt/

Startknoten

UML-Aktivitätsdiagramm

Org. Einheiten

spezifisch benanntes Ereignis

Funktion

-

Informationsobjekt

Ereignis

Informationsobjekt

Ereignis

Abb. 3.59 Konzeptuelle Abdeckung unterschiedlicher Modellierungssprachen

(allgemein)

Hilfsmittel -

-

Information

programm

-

-

Sachmittel

Maschine

3b

-

Mensch

3a

-

Geschäftsobjekt

2d

Reihenfolge

-

Handelnder

2c

nur unspezifisch

Startereignis

2b

Operation

Aktivitäten/ Aufgaben

2a

-

-

Ergebniz

Kundenbedürfnis

Terminierungselement

Ende

1c

1b

-

Input

1a

Flowchart Terminierungselement

Konzept

Anfang

Definitionsteil

BPMN

S-BPMN

-

-

Subjekt

Nachricht

Datenspeicher Service-Task

Geschäftsobjekt,

-

Subjekt

Subjekt

Nachricht

Geschäftsobjekt,

Subjektverhalten

Zustandsübergänge in

Bedingungen für

Subjekten,

Nachrichten zwischen

Datenobjekt Nachricht,

-

Service-Task

Manueller Task

Pool, Lane, Benutzur-Task,

Datenobjekt, Nachricht

Sequenzfluss, Gateways für alternative und parallele Abläufe, Nachrichtenfluss, Ausnahmebehandlung, Transaktionen, Choreographie

Nachricht Subjekt

Empfang einer

Pool, Lane

Startzustand, meist via

Funktionszustand

-

Nachricht

Geschäftsobjekt,

Endzustand

Nachricht

Geschäftsobjekt,

Startzustand

unterschiedliche Startereignisse (Nachrichten, Timer, Regeln etc.)

Aufgabe (unterschiedliche Typen)

-

Datenobjekt, Nachricht

Endereignis

Datenobjekt, Nachricht

Startereignis

3.7 Vergleich und Gegenüberstellung 131

132

3 Modellierungssprachen für Geschäftsprozesse

eines Prozesses auf unterschiedliche Subjekte. Dies führt zu einfach erfassbaren Teilmodellen, kann aber gleichzeitig höhere Ansprüche an Modellnutzende bei der Erfassung der Gesamtzusammenhänge innerhalb des Prozesses stellen. Für unerfahrene Modellierende zeigen sich in empirischen Untersuchungen in direkten Vergleichen Vorteile von S-BPM mit PASS gegenüber BPMN sowohl hinsichtlich der Modellierungseffizienz als auch hinsichtlich der syntaktischen und semantischen Korrektheit der resultierenden Modelle (Moattar et al. 2022). Die gesteigerte Effizienz ist hier auf die stärkere Entkopplung der einzelnen Modellteile, die im Fall von PASS in Subjekten gekapselt sind, zurückzuführen, die eine einfachere Parallelisierung der Modellierung ermöglicht, als dies in der integrativen Darstellungsform von BPMN der Fall ist. Die höhere syntaktische und semantische Korrektheit kann auf das kompaktere Vokabular von PASS zurückgeführt werden, das einfacher zu erlernen und konsistent anzuwenden ist (ibid.). Es sind auch Hinweise darauf zu erkennen, dass für unerfahrene Modellierende ein kommunikationsorientierter Modellierungsansatz wie S-BPM intuitiver und einfacher anzuwenden ist als ein kontrollflussorientierter Ansatz wie BPMN. Dies wird auch durch Untersuchungen gestützt, die emergente Sprachkonstrukte bei Prozessmodellierung ohne vorgegebene Modellierungssprache untersucht (Oppl 2018) und zum Ergebnis kommt, dass rein an der temporal-kausalen Aktivitätsabfolge orientierte Modelle kaum erstellt werden, wenn keine Vorgaben gemacht werden. Bei der Auswahl einer für eine gegebene Aufgabenstellung und Zielgruppe geeigneten Modellierungssprache ist dem entsprechend nicht nur auf den Abbildungsgegenstand (also den betrachteten Geschäftsprozess) Bezug zu nehmen, sondern auch auf die bekannten oder vermuteten Kompetenzen der Modellierenden und Modellnutzenden (Turetken et al. 2017). Eine grundlegende Unterscheidung kann zwischen den Sprachen getroffen werden, die den Aktivitätsfluss ins Zentrum der Betrachtung stellen (wie die Flowcharts und die EPK), und jenen, die die Handelnden eines Prozesses und deren Kommunikation in den Vordergrund stellen (wie in PASS). Die BPMN und Aktivitätsdiagramme eignen sich grundsätzlich für beide Abbildungsarten, wobei die BPMN ausdrucksstärkere Mittel zur Abbildung von Kommunikationsabläufen bietet. Die endgültige Auswahl einer Modellierungssprache nach Festlegung des grundlegend verfolgten Abbildungsansatzes (Aktivitäts- vs. Kommunikationsfluss) ist letztendlich abhängig von den Präferenzen der Modellierenden bzw. Modellnutzenden (Oppl 2016).

Literatur Chinosi M, Trombetta A (2011) BPMN: an introduction to the standard. Comput Stand Interfaces 34(1):124–134 Curtis B, Kellner MI, Over J (1992) Process modeling. Commun ACM 35(9):75–90 Damij N (2007) Business process modelling using diagrammatic and tabular techniques. Bus Process Manag J 13(1):70–90

Literatur

133

Decker G, Puhlmann F (2007) Extending bpmn for modeling complex choreographies. In: On the Move to Meaningful Internet Systems 2007: CoopIS, DOA, ODBASE, GADA, and IS: OTM Confederated International Conferences CoopIS, DOA, ODBASE, GADA, and IS 2007, Vilamoura, Portugal, 25–30 Nov 2007, Proceedings, Part I. Springer, S 24–40 Dumas M, Hofstede AT (2001) UML activity diagrams as a workflow specification language. In: UML 2001 – The Unified Modeling Language. Modeling Languages, Concepts, and Tools. Springer, S 76–90 Fleischmann A, Schmidt W, Stary C, Obermeier S, Boerger E (2012) Subject-oriented business process management. Springer, Berlin Moattar H, Bandara W, Kannengiesser U, Rosemann M (2022) Control flow versus communication: comparing two approaches to process modelling. Bus Process Manag J 28(2):372–397 Nüttgens M, Rump FJ (2002) Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). Promise, S 64–77 OMG (2017) Unified Modeling Language® (OMG UML®). An OMG® Unified Modeling Language® Publication Open Management Group and (OMG) (2011) Business Process Model and Notation (BPMN). Open Management Group. http://www.omg.org/spec/BPMN/2.0 Oppl S (2016) Selbstgesteuerte Reflexion und Gestaltung von Arbeitsprozessen. Momentum Quart 5(4):200–223. https://doi.org/10.15203/momentumquarterly.vol5.no4.p200-223 Oppl S (2018) Which concepts do inexperienced modelers use to model work? - An exploratory study. In: Drews P, Funk B, Niemeyer P, Xie L (Hrsg) Tagungsband Multikonferenz Wirtschaftsinformatik (MKWI) 2018, Bd 3. Leuphana Universität Lüneburg, Lüneburg, S 953–964 Recker JC (2010) Opportunities and constraints: the current struggle with BPMN. Bus Process Manag J 16(1):181–201. http://www.emeraldinsight.com/doi/abs/10.1108/14637151011018001 Scheer AW, Keller G, Nüttgens M (1992) Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. Technical report Turetken O, Vanderfeesten I, Claes J (2017) Cognitive style and business process model understanding. In Advanced Information Systems Engineering Workshops: CAISE 2017 International Workshops, Essen, Germany, June 12–16, 2017, Proceedings 29. Springer International Publishing, Cham, S 72–84

4

Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Die vorangegangenen Kapitel behandelten konkrete Werkzeuge und Methoden, um Abläufe und Sequenzen von Aktivitäten in einem Prozess zu beschreiben. Im Zuge der zunehmenden Digitalisierung werden organisationsinterne und insbesondere organisationsübergreifende Prozesse jedoch zunehmend komplexer. Hinzu kommen noch einmal eine Zunahme an möglichen Technologien oder Konzepten und Ansätzen, die für moderne Prozesse im Zuge der Digitalisierung eine Rolle spielen können. Dieses Kapitel widmet sich einigen aktuellen Herausforderungen, die bei der Digitalisierung von Prozessen eine Rolle spielen, erklärt diese und stellt sie in den Kontext dieses Buches. Die Natur dieser Herausforderungen ist dabei durchaus unterschiedlich und geht von der Problemstellung real existierende, komplexe Prozesssysteme überhaupt den Anforderungen entsprechend akkurat abzubilden, über die Herausforderung und Möglichkeiten Prozessmodelle ggf. direkt digital umzusetzen und auszuführen, bis hin zur Einbeziehung von aktuellen Technologien wie der Künstlichen Intelligenz (KI) oder dem Internet of Things (IoT). Letztendlich werden alle diese Herausforderungen aber vor allem einen großen Einfluss auf die von ihnen betroffenen Menschen haben, so dass letzten Endes immer auch die soziale Komponente die eigentliche Herausforderung darstellen wird.

4.1

Beschreibung komplexer Prozesssysteme und Systemarchitektur

Eine essentielle Herausforderung der Digitalisierung besteht darin, dass reale Geschäftsprozesse oft komplex sind, bzw. oft viele Prozesse miteinander interagieren und untereinander verwoben sind. Sollte man also IT-Systeme aus Prozessen ableiten © Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_4

135

136

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

oder deren Funktionen präzise in Modellen beschreiben wollen, so muss die verwendete Modellierungsmethodik es erlauben, diese Umstände logisch und trotzdem möglichst einfach nachvollziehbar abzubilden. In den folgenden Abschnitten wird daher analysiert, wie verschiedene Prozessmodellierungssprachen insbesondere den Aufbau von komplexen Modellsystemen unterstützten, inwiefern sie für das Strukturieren von Prozesssystemen geeignet sind und inwiefern dann wiederum digitale Workflows aus den Modellen abgeleitet werden können. In praktisch jeder Organisation mit mehr als einem Geschäftsprozess sind einzelne Prozesse zwar formal getrennt aber trotzdem miteinander verbunden und voneinander abhängig, entweder direkt oder indirekt. Beispielsweise kann auf einen Sales-Prozess ein Auftragsabwicklungsprozess folgen, der wiederum Lieferprozesse und die Rechnungsstellung auslöst. Um solche Prozesslandschaften oder Prozessarchitekturen und ihr Verhalten sinnvoll abbilden zu können, sollten Spezifizierungssprachen Mechanismen beinhalten, die es ermöglichen komplexe und ineinandergreifende Umstände strukturiert und übersichtlich darzustellen. Dabei ist es insbesondere wichtig, dass die „Umgebung“ oder „Nachbarschaft“ eines Prozesses repräsentiert werden kann und welche Verbindungen und Beziehungen eines einzelnen Prozesses zu seinen „Nachbarn“ bestehen bzw. wie diese aussehen. Für den oben genannten Fall des Auftragsabwicklungsprozesses sollten also auch seine Verbindungen zum Sales-Prozess und zum Lieferprozess abbildbar sein, wobei es sich eben nicht um einfach aufeinander folgende Aktivitäten innerhalb eines einzelnen Prozesses handelt, sondern um Interaktionen zwischen unterschiedlichen Prozesssystemen. Dabei sollten insbesondere Details dieser Interaktionen benannt werden können, die den Austausch von Daten und die Veränderung bzw. Übergabe des Kontrollflusses betreffen. Im Folgenden werden verschiedene Möglichkeiten vorgestellt, wie solche komplex strukturierten Prozesssysteme bzw. Prozessarchitekturen mit den verschiedenen Modellierungssprachen aus Kap. 3 abgebildet und strukturiert werden können.

4.1.1

Strukturierung komplexer Prozesse mit Flowcharts

Die einzige Möglichkeit komplexere Strukturen in Flowcharts abzubilden ist es, auf andere vordefinierte Prozesse zu verweisen. Solche vordefinierten Prozesse stellen wiederum andere benannte Prozesse dar, die in getrennten Modellen beschrieben werden müssen. Abb. 4.1 zeigt eine solche Konstruktion. Dabei verweist das Prozessmodell auf der linken Seite auf den Lieferprozess, der auf der rechten Seite dargestellt ist. Der Kontrollfluss springt dabei vom ursprünglichen Prozessmodell zum anderen Modell. Jenseits dieses Unterprozesskonzeptes gibt es jedoch keinen standardisierten Weg, um Prozessarchitekturen formal darzustellen, die einen Überblick darüber geben welche

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

137

Abb. 4.1 Prozesssystemmodell-Strukturierung mit Prozessverweis in Flowcharts

Prozesse es gibt, und in welchem Zusammenhang diese stehen bzw. welcher Prozess welchen anderen (Unter-)Prozess nutzt. Datentechnisch wird bei Flowcharts davon ausgegangen, dass alle prozessrelevanten Daten automatisch jederzeit in allen Aktivitäten zur Verfügung stehen und aktualisiert wurden. Daher werden konzeptionell bedingt keine Datenanforderungen der Prozesse oder der Datenaustausch zwischen einzelnen Prozessen explizit betrachtetet. Durch diese Konzepte, zum einen den Aufrufmechanismus von anderen Prozessen und zum anderen das implizite Data Sharing, sind Flowchart Prozessmodelle, wenn sie verknüpft sind, immer extrem eng miteinander verzahnt (tight coupling). Diese extrem enge Verzahnung von Modellen sorgt wiederum dafür, dass Flowcharts relativ ungeeignet sind, um Situationen darzustellen, in denen Prozesse nur lose gekoppelt sind oder insbesondere durch den Datenfluss, bei dem es ein wichtige Rolle spielt, wo welche Daten zu welcher Zeit vorgehalten werden. Dies ist insbesondere bei Prozessen der Fall, die über Organisationsgrenzen hinweg ablaufen.

4.1.2

Strukturierung komplexer Prozesse mit EPKs

Sehr ähnlich zu Flowcharts nutzen auch Ereignisgesteuerte Prozessketten (EPKs) die Möglichkeit auf andere Prozesse zu verweisen. Die Symbolik lässt es dabei offen ob der „Prozesswegweiser“ ein Anschlussprozess oder ein Unter-Prozess ist. Er hat eine Symbolik wie in Abb. 4.2 beschrieben. Das Grundprinzip dieses Prozesswegweisers ist das gleiche wie bei den Flowcharts und daher aus den gleichen Gründen nicht ausreichend, um hinreichend komplexe Prozesssysteme abzubilden, insbesondere wenn mehr als diese eine binäre Art der Beziehung zwischen Prozessen dargestellt werden soll. Daher gibt es im Kontext der EPKs zusätzlich noch das Wertschöpfungskettendiagramm (Value Chain Diagram – VCD),

138

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.2 Prozesssystemmodell-Strukturierung mit Unterprozessverweis in EPKs

Abb. 4.3 Wertschöpfungskettendiagramm für die EPKs aus Abb. 4.2 – im Prozess der Bestellverwaltung wird der Lieferungsprozess angestoßen

das es theoretisch erlaubt das Zusammenspiel bzw. die Abhängigkeit von Prozessen zu beschreiben. Abb. 4.3 beschreibt den Umstand aus Abb. 4.2, dass im Prozess der Bestellverwaltung der Lieferungsprozess angestoßen oder aufgerufen wird. Die grafische Indikation stellt ihn hierbei als angestoßenen Folgeprozess dar und nicht als Unterprozess. Neben diesem Anstoßen oder Folgen gibt es in Wertschöpfungskettendiagrammen auch die Möglichkeit hierarchische Beziehung zu konnotieren. Dies wird in Abb. 4.4 gezeigt, wobei das Prozesssystem als übergeordneter Prozess der Auftragsabwicklung bezeichnet wird, der wiederum aus den Unterprozessen „Bestellverwaltung“, „Lieferung“ und „Rechnungsstellung“ besteht.

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

139

Abb. 4.4 Wertschöpfungskettendiagramm mit Prozesshierarchie

4.1.3

Strukturierung komplexer Prozesse mit UML-Aktivitätsdiagrammen

UML-Aktivitätsdiagramme bieten keine spezielle Notation an, um die Zusammenhänge komplexer Prozesse strukturiert abzubilden. Es ist nicht erlaubt, ein Aktivitätsdiagramm innerhalb eines anderen Aktivitätsdiagramms zu verwenden oder aufzurufen (keine rekursiven Aufrufe). Die einzige Möglichkeit, mehrere Prozesse strukturiert zu verknüpfen, ist es, die sie darstellenden Aktivitätsdiagramme durch die Beschreibung des Austausches von Nachrichten zu verknüpfen. Es gibt dafür jedoch keine spezielle Symbolik oder übergeordnete Diagrammtypen, mit denen eine solche Kommunikation ausgedrückt werden könnte.

4.1.4

Strukturierung komplexer Prozesse mit BPMN

In der Sammlung der verschiedenen Diagrammtypen, die mit BPMN verbunden sind, stellt das Kollaborations- bzw Konversationsdiagramm das höchste Abstraktions- bzw. Abbildungslevel dar. Es wurde geschaffen um komplexe Situationen besser verständlich zu machen in denen es, z. B. innerhalb eines Prozesses viele Teilnehmer gibt, die alle mit ihren eigenen „Pools“ dargestellt werden müssen, die jeweils noch einmal mehrere Swimlanes enthalten. Solche Diagramme, wie z. B. in Abb. 4.5, zeigen das „Big Picture“ bzw. eine Übersicht über das Netzwerk an Partnern an, und wie diese miteinander kommunizieren. Es gibt dabei jedoch keine formalen Abhängigkeiten zwischen solchen Konversationsdiagrammen und den eigentlich Prozessgrafiken, für die BPMN vor allem bekannt ist, selbst wenn sie zum gleichen Modelkomplex gehören und damit zumindest konzeptionell zusammengehören. Abb. 4.5 zeigt ein solches Konversationsdiagramm, bei dem die „Pools“ der Bestellverwaltung und des Lieferungsprozesses komprimiert dargestellt werden und über die Nachricht „Lieferung ausführen“ miteinander kommunizieren. Konversationsdiagramme stellen dabei die höchste Abstraktionsstufe von allen BPMNDiagrammen dar. Da es nicht erlaubt ist, Konversationsdiagramme ineinander zu ver-

140

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.5 Einfaches BPMN-Kollaborations- bzw. -Konversationsdiagramm

schachteln, muss es sich bei den darin dargestellten Rechtecken logischerweise, wie beschrieben, um „Pools“ handeln. Es kann sich andersherum also nicht um weitere Konversationsdiagramme auf einer weniger abstrakten Ebene handeln. Dies führt also zu einer starren, nur zwei Stufen umfassenden Abstraktionshierarchie von Konversationsdiagramm und Geschäftsprozessdiagramm, wobei entsprechend der Konzepte von BPMN, formal gesehen, das übergeordnete Konversationsdiagramm vom untergeordneten Geschäftsprozessdiagramm abhängig ist bzw. dieses „nur“ zusammenfasst. Unterhalb des Geschäftsprozessdiagramms bzw. darin integriert gibt es auch in BPMN das Unter- bzw. Subprozesskonzept wie es auch bei Flowcharts und EPKs vorkommt. Es unterliegt jedoch ebenfalls den dafür beschriebenen Einschränkungen.

4.1.5

Strukturierung komplexer Prozesse in PASS/S-BPM

Eine besondere Rolle spielt die in Kap. 3 vorgestellte Modellierungsmethodik des Parallel Activity Specification Schemas (PASS). Im Gegensatz zu den anderen Sprachen handelt es sich bei dem auf (Fleischmann 1994) zurückgehenden PASS nicht einfach nur um einen anderen Satz an Symbolen, sondern es unterliegt mit der Subjektorientierung einem grundsätzlich anderen Modellierungsparadigma. Dadurch bietet es mehrere zusätzliche Mechanismen um Prozesse strukturiert und vernetzt darzustellen. So ist es Modellierern möglich Abstraktionsgrad und Abstraktionsabstufungen entsprechend ihrer aktuellen Anforderungen zu wählen und auch später anzupassen. Durch die paradigmenbedingte konzeptionelle Trennung zwischen Subjekten, Objekten und Aktivitäten stehen nämlich tatsächlich drei getrennte Abstraktionsdimensionen zur Verfügung.

4.1.5.1 Abstraktion über Aktivitäten in PASS Die Abstraktionsdimensionen beinhaltet zuerst einmal das bereits bekannte Unterprozesskonzept in Form der Möglichkeit sogenannte Makros bzw. Makro-Verhalten zu definieren und in anderen Zuständen aufzurufen. Dieses Makro ist dann ein ausführlicher

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

141

beschriebenes „Unterverhalten“.1 Dies kann, so wie bei den anderen Sprachen, für Aktivitäten genutzt werden, um diese weiter zu detaillieren bzw. auszudrücken, sodass diese aus weiteren Unter-Aktivitäten bestehen. Dies wird im Subjektverhaltensdiagramm (SBD) in Abb. 4.6 dargestellt. Das dazugehörige Subjektinteraktionsdiagramm (SID) ist in Abb. 4.7 zu sehen.

4.1.5.2 Abstraktion über Objekte in PASS Die zweite mögliche Abstraktionsdimension in einer subjektorientierten Beschreibung wäre die Möglichkeit, über die Objekte bzw. die Nachrichten zu abstrahieren. Bei den Nachrichten in einem subjektorientierten Modell handelt es sich quasi um objektorientierte Klassen, die entsprechend den Grundprinzipien der Objektorientierung instanziiert werden würden, wenn das Modell zur Ausführung kommen sollte. Sollte es für einen Modellierer wichtig sein, dann können z. B. Unterklassen für ein spezielleres Modell definiert werden. So kann z. B. in einem Modell eines Geschäftsprozesses von einer allgemeinen Nachricht „Vertrag“ gesprochen werden, für die es dann eine Vielzahl von möglichen detaillierteren Ausprägungen (Unterklassen) gibt, wie z. B. „Mietvertrag“ oder „Kaufvertrag“, die zusätzliche Informationen beinhalten. One Direction of Abstraction: In der objektorientierten Modellierung/Programmierung gibt es hierzu das Prinzip, bei dem Abstraktion und damit auch die Abhängigkeit immer nur in eine Richtung erfolgen sollte. In der dargestellten Vererbungshierarchie in Abb. 4.8 ist dies gut ersichtlich. Die Unterklassen sind alle von der Oberklasse abhängig und erben von dieser. Änderungen der Beschreibung der Oberklasse betreffen auch alle Unterklassen. Andersherum ist dies nicht der Fall und die Erstellung und Veränderung der Oberklasse ist unabhängig von den Unterklassen. Die formale Abhängigkeit besteht nur in eine Richtung. Dieses Prinzip wie hier beschrieben ist nicht zwangsläufig, kann aber als Best Practice verstanden werden, insbesondere, wenn es um die formale Abstraktion von digitalen Systemen geht. Im nachfolgenden Abschnitt wird dieses auch konzeptionell für Subjekte bzw. gesamte Prozessmodelle verfolgt. Der zuvor dargestellte Makro-Mechanismus von PASS hat zwar auch Abhängigkeiten in nur eine Richtung. Diese erfolgt jedoch umgekehrt, da hier die in der allgemeineren (abstrakteren) Beschreibung angegeben werden muss, sodass eine detailliertere Beschreibung in Form eines Makro-Verhaltens aufgerufen wird. Die allgemeine Beschreibung verlinkt also die detailliertere und ist damit abhängig von dieser.

4.1.5.3 Abstraktion über Subjekte in PASS Die dritte Möglichkeit in PASS zu abstrahieren stellt die Dimension der Subjekte dar, die explizit in einer subjektorientierten Beschreibung benannt werden müssen. Sie stellen

1 In einer subjektorientierten Beschreibung ist das Verständnis „Prozess“ sehr viel umfassender als

in einer klassischen Darstellung, in der „Prozess“ quasi gleich „Aktivität“ ist. Subjektorientiert kann eine Aktivität zwar aus „Unteraktivitäten“ „bestehen“, aber eine Aktivität kann rein logisch nicht aus Subjekten bestehen, die wiederum einen Unterprozess ausmachen würden.

Abb. 4.6 SBD des Subjektes „Firma“ aus Abb. 4.7 mit Aufrufen von Makro-Verhalten (Unter-aktivitäten) in PASS – symbolische Darstellung

142 4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

143

Abb. 4.7 PASS SID für die nachfolgenden Beispiele

Abb. 4.8 Vererbungsmechanismus/Vererbungshierarchie (UML-Notation für Nachrichten (Daten)Objekte)

Abb. 4.9 SID Prozessmodell B – Erweiterung von Modell aus Abb. 4.7 – je nach Betrachtung ein Unterprozess oder auf gleicher Ebene

die wichtigste Möglichkeit dar, komplexe Kommunikationsnetzwerke von Prozessen abzubilden. Klassisch steht das Interface-Subjekt „Lieferservice“ aus Abb. 4.7 für ein einzelnes, in diesem Modell nicht weiter ausgearbeitetes Verhalten. Dieses Verhalten kann dann wiederum in einem anderen Modell als erweiterter Prozess beschrieben werden, in dem „Lieferservice“ zusammen mit z. B. mit einem „Fuhrparkmanagement“ als Standardsubjekt vorkommt, und dafür „Kunde“ und „Firma“ als Interface-Subjekte fungieren. Abb. 4.9 stellt eine solche Erweiterung dar. Dieser zweite, in Abb. 4.9 dargestellte Prozess kann als Unterprozess verstanden werden. Das Standard-Konzept für Interface-Subjekte ist dabei jedoch, dass beide Modelle sich gegenseitig verlinken und somit formal auch gegenseitig voneinander abhängig sind. Eine Veränderung der Kommunikation in einem Modell müsste z. B. jeweils im anderen Modell gespiegelt werden, damit die Verlinkung kompatibel bleibt. Formal wäre also diese Art von Modell als parallele Erweiterung zu sehen, bei der nicht formal festgelegt wird,

144

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.10 SID mit Darstellung des Interface als System ohne Abhängigkeiten zum Modell aus Abb. 4.9

ob das Modell aus Abb. 4.7 die Vorgabe macht, an die sich das Modell aus Abb. 4.9 hält, oder umgekehrt. Soll das Modell aus Abb. 4.7 die feste Vorgabe sein und damit auf einer formal höheren Abstraktionsstufe liegen, dann darf es nicht von Abb. 4.9 abhängig sein. Dies kann dadurch ausgedrückt werden, dass „Lieferservice“ nicht als normales Interface mit einem fixen Link zu einem anderen Modell beschrieben wird, sondern indem es als Interface zu einem kompletten Prozesssystem mit möglicherweise vielen „Unter-Subjekten“ ausgedrückt wird, wie in Abb. 4.10 gezeigt. Ein solches System-Interface-Subjekt ist eine Zusammenfassung mehrerer aktiver Einheiten (Subjekte) und kann damit als Abstraktion für einen kompletten (subjektorientierten) Unterprozess verstanden werden – ein Unterprozesskonzept, das sich prinzipiell von jenem der nicht-subjektorientierten Modellierung unterscheidet, da hier nicht gesagt wird, dass eine (Ober-)Tätigkeit aus Untertätigkeiten (Verb) besteht, sondern eine aktive Entität (Subjekt) sich aus mehreren Unter-Entitäten (Unter-Subjekten) zusammensetzt.

4.1.5.4 Subjektorientierte Hierarchien und Prozessarchitekturen Das im vorherigen Abschnitt erläuterte Beispiel ist nur eine relativ einfache Abstraktion. Der Mechanismus, Interfaces als abstrakte Spezifikation für ganze Sub-Prozesssysteme zu verstehen, die in abhängigen Modellen weiter spezifiziert werden können, ist jedoch sehr mächtig. Erlaubt es umfangreiche Abstraktionshierarchien verschiedener Modelle aufzustellen, über die unterschiedlichste Zusammenhänge und Prozessarchitekturen einfach und übersichtlich und ggf. vereinfacht dargestellt werden können. Abb. 4.11 zeigt, wie auf drei verschiedenen Abstraktionsstufen das Zusammenspiel zwischen dem Bestell- und dem Lieferprozess in PASS beschrieben werden kann. Dabei sind die jeweils weniger abstrakten Modelle vom abstrakteren Modell abhängig bzw. halten sich an dessen Vorgaben (technisch: sie „implementieren“ die abstraktere Spezifikation). Im abstraktesten Modell A oben in Abb. 4.11 wird dabei nur angegeben, dass es zwei aktive Prozesssysteme gibt, die sich über einen abstrakten Kommunikationskanal zum Thema Lieferungskoordination austauschen. Davon abgeleitet ist das minimal konkretere Modell B, in dem zusätzlich spezifiziert wird, dass es innerhalb des Bestellprozesssystems

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

145

Abb. 4.11 Abstraktionshierarchie mit drei Prozessmodellen

die Subjekte Kunde und Firma gibt. Diese Zusatzinformation ist natürlich sehr gering und würde normalerweise nicht in einem gesonderten Modell beschrieben werden. Hier ist es jedoch ein gutes Beispiel für diesen Abstraktions- bzw. Ausgestaltungsmechanismus und wie er verwendet werden sollte. Modell C detailliert Modell B. Die Kommunikation zwischen Kunde und Firma wird verfeinert, insbesondere der abstrakte Kommunikationskanal wird modelliert. Dabei sind nun nicht mehr System-Interfaces das Ziel der konkreten Nachrichten, sondern auf der einen Seite Standardsubjekte für „Kunde“ und „Firma“, und auf der anderen Seite

146

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.12 Abstraktionshierarchie mit drei Prozessmodellen – implementierende Modelle

das „Lieferservice“-Subjekt, das hier als Unterelement des Lieferservice-Prozesssystems modelliert wird. Da auf dieser Ebene bereits konkrete Nachrichten angegeben werden, fungiert das Lieferservice-Subjekt hier als sogenanntes Border-Subjekt für das System, in das es eingebettet ist (Abb. 4.12).

4.1.5.5 Ein komplexes Beispiel Das Beispiel aus dem vorherigen Abschnitt ist relativ einfach und dient der Erklärung des Abstraktionskonzeptes über Subjekte bzw. Subjektsysteme in PASS. Es besteht in dem einfachen Beispiel eigentlich keine Notwendigkeit, die Beschreibung des vollständigen Prozesssystems über mehrere Modelle auf verschiedenen Abstraktionsstufen aufzuteilen (Abb. 4.13–4.15). Dies ist dann notwendig, wenn reale Prozesse verteilt und zeitlich versetzt beschrieben werden müssen, z. B. für die Entwicklung einer komplexeren Dienstleistung, die dann digital in einem Informationssystem umgesetzt werden soll. Das folgende Beispiel zeigt die Prozessbeschreibungen der dazugehörigen Prozessarchitektur, die auf verschiedenen Hierarchiestufen erstellt wurden bzw. im Verlauf der Entwicklung immer weiter ausgearbeitet wurden. Das Thema ist dabei das organisatorische

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

147

Abb. 4.13 Abstraktes Interaktionsdiagramm eines komplexen Prozesses

Abb. 4.14 Subjektinteraktionsdiagramm abgeleitet aus dem Modell in Abb. 4.13 mit genauerer Angabe von (Border-)Subjekten, die innerhalb der unterschiedlichen Prozesssysteme vorkommen

Abwicklung einer Autopanne, bei dem für den Käufer einer Mobilitätsgarantie einfach und umfassend alle Aspekte des Abschleppens, der Reparatur und eines Ersatzwagens organisiert werden sollen.

148

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

4.1.5.6 Verhaltens-Interface: Abstrakte Spezifizierung von Verhalten Wie bisher ausgeführt, können in komplexen Modellsystemen abstrakte Beschreibungen immer als Spezifikationen für konkretere Modelle dienen. Neben den zuvor aufgezeigten Beschreibungsmöglichkeiten betrifft dies natürlich auch das Zusammenspiel zwischen Interaktionsbeschreibung und Verhaltensbeschreibung, bei dem z. B. in PASS im Subjektinteraktionsdiagramm beschrieben wird, welche Nachrichten an wen in konkreteren Subjektverhaltensdiagrammen geschickt werden können.

Abb. 4.15 Standard-SID, das einen Teilausschnitt des abstrakteren Modells in Abb. 4.14 spezifiziert

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

149

Mit einfachem Standard-PASS kommt es hier zu einer gewissen Problematik. Da es außer dem Makro-Mechanismus keine Möglichkeit gibt, Verhalten detaillierter zu spezifizieren, können Standard-PASS-Modellsysteme nur bedingt weiter konkretisiert werden, sobald sie Standard-Subjekte mit einem normalen Verhaltensdiagramm beinhalten. Dies liegt vor allem darin begründet, dass Standard-PASS eine sogenannte imperative Beschreibungssprache ist, bei der die Abfolge von Aktivitäten fix vorgegeben wird und relativ restriktiv ist. Dabei besteht schnell die Gefahr Verhalten auch schon auf einem sehr hohen Abstraktionslevel bzw. in den frühen Phasen einer Prozesskonzipierung „über“ zuspezifizieren. Die Verhalten können dann für eine konkrete Umsetzung oder Digitalisierung nur sehr bedingt angepasst werden, weil die Vorgaben zu strikt sind. Um die Möglichkeiten zu haben, differenziert Vorgaben/Spezifikationen zu erstellen, bedarf es einer Erweiterung, die es ermöglicht abstrakte Verhaltensvorgaben zu machen. Diese Idee steht hinter dem Abstract Layered PASS (ALPS) (Elstermann und Ovtcharova 2014) und ergänzt PASS um deklarative Elemente, mit denen es möglich ist, sogenannte Verhaltens-Interfaces zu beschreiben. ALPS erlaubt es bei Bedarf, Verhalten quasi unvollständig zu beschreiben, damit diese nicht über-spezifiziert werden und später leichter implementiert bzw. konkret umgesetzt werden können. Die Abb. 4.16 und 4.17 zeigen dieses Prinzip. Als einfaches Beispiel wird dabei das Sprichwort „Der Kunde ist König“ prozessual umgesetzt. Im oberen Modell A wird ein sehr einfacher, allgemeiner Bestellprozess eines Kunden abstrakt beschrieben. Dabei wird der Dienstleister nur als Interface-Subjekt ohne Verhalten beschrieben und der Kunde als sogenanntes abstraktes Subjekt – ein Subjekt mit einem unvollständigen Verhalten, das ALPS-Elemente enthalten kann. Dieses Modell A wird dann auf einer konkreteren Ebene durch Modell B umgesetzt, wobei alle spezifizierten Kommunikationspartner und Nachrichten vorkommen, aber ihre Namen den gewünschten Umständen angepasst werden. Die Verhalten dazu sind dann jeweils in Abb. 4.17 zu sehen. Das obere abstrakte Verhalten des Kunden enthält neben den abstrakten Zuständen auch sogenannte „Trigger“und „Precedence“-Transitionen“, die eine temporale Abhängigkeit nur in eine Richtung ausdrücken und damit weniger strikt sind als Standard-Transitionen und auch Ergänzungen dazwischen zulassen. So ist zwischen dem Aufgeben einer Bestellung und dem Warten auf die Antwort eine solche Precedence Transition, die ausdrückt, dass man vor dem Warten auf eine Antwort eine Bestellung aufgegeben haben muss. Andersherum besteht aber keine Abhängigkeit, d. h. das Absenden einer Bestellung verpflichtet prozessual, laut diesem Modell, nicht zum Warten. Vor dem Aufgeben einer Bestellung wird zwar empfohlen sich darüber Gedanken zu machen was man bestellen will, aber die sehr schwache Advice Transition ist eben nur das, ein Vorschlag. Im unteren Teil von Abb. 4.17 ist dann eine konkrete, abgeleitete Umsetzung des abstrakten Verhaltens zu sehen, wobei diese dem Subjekt des Königs aus Abb. 4.16 zugeordnet wird. Sie implementiert alle beschriebenen Aktivitätszustände aber ergänzt diese auch um eigene Aktivitäten, die für den konkreten Prozess wichtig sind. Wie bei den Subjekten im Interaktionsdiagramm sind auch hier die Benennungen dem Kontext

150

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.16 Abstraktes SID und davon abgeleitetes konkretes SID in zwei Modellen

Abb. 4.17 Abstraktes Verhalten und abgeleitetes, konkretes Verhalten der Subjekte „Kunde“ bzw. „König“ aus Abb. 4.15

4.1 Beschreibung komplexer Prozesssysteme und Systemarchitektur

151

entsprechend verändert worden, jedoch werden alle Aktivitäten umgesetzt und auch die Reihenfolgeregeln aus dem abstrakten Verhalten werden eingehalten.

4.1.5.7 Abstraktion und Spezifikation von Daten und Datenstrukturen Ebenso wie die Objektorientierung (OO) in der Programmierung die „Methode“ bzw. die Beschreibung der Aktivität nicht obsolet gemacht hat, sondern diese quasi miteinschließt und um das Konzept des Objektes ergänzt hat, ist die Subjektorientierung kein Ersatz für die OO, sondern ergänzt die Beschreibungsmöglichkeiten um die explizite Idee des Subjekts. Dies bedeutet jedoch auch, dass der formale Abstraktionsmechanismus der Objektorientierung, die Vererbung in der Modellierung von abstrakteren Beschreibungen genutzt werden kann. Dies wurde in den Modellen aus den Abb. 4.16 und 4.17 bereits getan, da die Daten-Objekte bzw. Nachrichten wie „Wunsch“ durch eine Nachricht „Befehl“ oder die Nachricht „Ablehnung“ durch die Nachricht „Revolution“ ersetzt wurden. Damit dies formal kohärent bleibt, müssen die Nachrichten im konkreten Modell B die abstrakten Nachrichten im Modell A implementieren, so wie es Klassen in der OO-Programmierung mit dem Programmierkonstrukt der Interfaces machen. Die konkrete Vererbungs- bzw. Implementierungshierarchie für die Datenobjekte würde aussehen wie in Abb. 4.18.

Abb. 4.18 Vererbungshierarchie von Daten-Objekten zwischen den Modellen A und B aus Abb. 4.16

152

4.2

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Vom Prozessmodell zur Digitalisierung

Die Fähigkeit komplexe und trotzdem inhaltlich richtige Prozessbeschreibungen zu erstellen, ist eine der wichtigsten Voraussetzungen für die Digitalisierung von Prozessen, die aus mehr als ein paar wenigen Aktivitäten bestehen. Wie in den vorherigen Abschnitten beschrieben, hängt diese von Ausdrucksmöglichkeiten und formalen Abstraktionsmechanismen der verwendeten Modellierungssprache ab. Die Erstellung eines Prozessmodells des zu digitalisierenden Prozesses ist jedoch nur der erste Schritt, auf den die Aktivitäten der eigentlichen digitalen Umsetzung folgen. Es gibt dabei zwei grundsätzliche Vorgehensmöglichkeiten, um die weiteren prinzipiellen Herausforderungen auf dem Weg zur Digitalisierung anzugehen.

4.2.1

Indirekte Ausführung

Die erste Herausforderung ist dabei unabhängig von der verwendeten Prozessmodellierungssprache und besteht darin, das erstellte Modell einem Programmierer zu geben oder diesen in die Erstellung des Prozessmodells mit einzubinden. Die Beteiligten müssen das im Prozessmodell enthaltene Wissen dann nutzen, um die eigentlichen IT-Systeme zu konfigurieren oder zu programmieren. Der Prozess wird dadurch natürlich digitalisiert, aber das Modell spielt nur eine indirekte Rolle bzw. wird durch das IT-System nur indirekt ausgeführt (siehe Abb. 4.19). Der offensichtliche Nachteil dieses Vorgehens ist, dass bei der „Übersetzung“ des Modells in Code durch einen Menschen Fehler oder Missverständnisse auftreten können. Im Gegensatz zum reinen „Malen“ von Grafiken kann hier eine formale Modellierungssprache mit überprüfbaren Struktur- und Syntax-Regeln insofern Verbesserungen schaffen, als das zu übertragende Modell automatisiert auf Richtigkeit überprüft werden kann. Wenn Ersteller und auch Leser eines formalen Modells ausreichend im Erstellen und Verstehen eines Modells geschult sind, dann reduziert dies auch die Wahrscheinlichkeit von Missverständnissen.

Abb. 4.19 Indirekte/Implizite Ausführung von Prozessmodellen. (Elstermann 2019)

4.2 Vom Prozessmodell zur Digitalisierung

4.2.2

153

Direkte Ausführung

Eine formale Modellierungssprache bietet jedoch auch die prinzipielle Option der direkten, digitalen Ausführung eines Modells. Voraussetzung dafür ist, dass für die entsprechende Sprache eine formale Ausführungssemantik existiert und diese auch in Form einer sogenannten Workflow Engine als Software umgesetzt worden ist. Ist diese Voraussetzung erfüllt, dann bedarf es ggf. keines Programmierers mehr, sondern ein hinreichend geschulter Business-Experte kann die von ihm oder ihr erstellten Prozessmodelle in die Software laden und diese dann ausführen bzw. instanziieren lassen, so wie es in Abb. 4.20 dargestellt ist. Nicht alle in diesem Buch diskutieren Modellierungsansätze bieten jedoch die gleichen Voraussetzungen für eine akkurate, direkte oder wenigstens indirekte digitale Umsetzung. In den folgenden Abschnitten beleuchten wir die Möglichkeiten, die die einzelnen Sprachen bieten.

4.2.2.1 Möglichkeiten der digitalen Umsetzung von Flowcharts Wegen ihrer langjährigen Existenz und breiten Verwendung (Laue et al. 2022) kann das Verständnis der Syntax von Standard-Flowcharts quasi zum Allgemeinwissen gezählt werden. Es existiert jedoch weder eine formale, präzise Definition der Sprachsyntax, noch existiert eine offizielle Ausführungssemantik. Ebenso wenig gibt es ein offizielles Datenformat, das den Austausch zwischen verschiedenen Modellierungsprogrammen, Datenbanken oder Projektmanagementsystemen ermöglicht. Aufgrund ihrer weiten Verbreitung dienen Flowchart-artige Beschreibungsansätze als Grundlage von visuellen Programmiersprachen (Myers 1986), die z. B. in Low-Code Plattformen genutzt werden. Wie der Name hier jedoch bereits sagt, dienen diese Ansätze mehr der Programmierung von spezifischen Systemen und nicht dazu, Geschäftsprozesse zu modellieren. Dies trifft ebenso auf sämtliche Flowchart-ähnlichen Workflow-Sprachen zu, die speziell dazu geschaffen wurden, konkrete Systeme zu spezifizieren, und, dementsprechend auch nur im Kontext dieser Systeme funktionieren.

Abb. 4.20 Direkte/Explizite Ausführung von Prozessmodellen. (Elstermann 2019)

154

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

4.2.2.2 Möglichkeiten der digitalen Umsetzung von EPKs Es gibt viele Software-Werkzeuge, um EPK-basierte Prozessmodelle zu erstellen. Es gibt jedoch auch hier kein standardisiertes Format, um diese Modelle zu speichern und auszutauschen. Das meistgenutzte Werkzeug, um EPKs zu erstellen und teilweise auch auszuführen ist ARIS.2 ARIS nutzt dabei sein eigenes proprietäres Dateiformat, das nicht in andere Werkzeuge übertragen werden kann. Es gab Forschungsvorhaben mit dem Ziel ein offenes Datenformat für EPK-Modelle zu generieren (Mendling und Nüttgens 2004) und auch um EPK-Modelle über die Business Process Execution Language (BPEL) ausführbar zu machen (Kopp 2005). Diese konnten sich jedoch in der Praxis nicht etablieren. Weitere Ansätze sind nicht bekannt, insbesondere hinsichtlich der direkten Ausführung von EPK-basierten Prozessmodellen. 4.2.2.3 Möglichkeiten der digitalen Umsetzung von UML-Aktivitätsdiagrammen Werkzeuge, um digitale UML-Aktivitätsdiagramme zu erstellen gibt es viele – eine Liste der unterschiedlichen Möglichkeiten gibt es z. B. bei (Ihpiv 2022). Auch existiert ein offizieller XML Austauschstandard der Object Management Group (OMG), der theoretisch genutzt werden kann um Modelle zwischen verschiedenen Werkzeuge auszutauschen. In der Praxis kann dieser Austausch jedoch teilweise sehr mühselig sein: Viele Tool-Hersteller unterstützen hier nur ihren eigenen Dialekt, d. h. es werden z. B. nicht alle Notationselemente unterstützt oder es werden eigene Definitionen und Elemente hinzugefügt. Die meisten Werkzeuge bieten auch eine Funktion zur Generierung von Programmcode für verschiedene Programmiersprachen, wobei hier im Einzelfall die Frage gestellt werden muss, ob sich das auf UML-Klassendiagramme beschränkt oder tatsächlich auch UML-Aktivitätsdiagramme mit beinhaltet – letzteres ist selten, aber es gibt prinzipielle Ansätze und Vorschläge dafür, wie z. B. (Backhauß 2016). Backhauß (2016) bezieht sich jedoch nur auf die Code-Generierung für Echtzeitsysteme und es bleibt die Frage offen in wie fern dieses Konzept oder der Ansatz generell für Geschäftsprozesse geeignet ist. Ein UML-basiertes Werkzeug mit einer expliziten Anwendungsempfehlung für die digitale Umsetzung von Geschäftsprozessen ist den Autoren nicht bekannt. 4.2.2.4 Möglichkeiten der digitalen Umsetzung von BPMN Der offizielle BPMN-Standard umfasst auch eine XML-Schema-Definition, die den Austausch von Prozessmodellen und deren Verwendung in unterschiedlichen Programmen ermöglichen soll. In der Praxis funktioniert dieses bedingt gut, da viele Werkzeuge auf unterschiedliche Aspekte der Verwendung von BPMN spezialisiert sind und die Hersteller

2 Das Software-Tool der Software AG – nicht zu verwechseln mit der gleichnamigen „Architektur

integrierter Informationssysteme (ARIS)“ (Scheer 1998) auf deren Konzepten die ARIS-Software aufbaut.

4.2 Vom Prozessmodell zur Digitalisierung

155

den Standard teilweise unterschiedlich interpretieren. Als Folge kann sich – ähnlich zu UML – der Austausch von Modellen durchaus aufwändig gestalten (Dirndorfer et al. 2013). Die offizielle Definition der Ausführungssemantik des BPMN-Standards existiert auf Englisch, d. h. in einer natürlichen Sprache mit allen Nachteilen von Missverständnissen und Fehlinterpretationen. Zusätzlich existiert eine formale Definition, die vom Software Competence Center in Hagenberg, Österreich, für BPMN- Prozessmodelle geschaffen wurde (Kossak et al. 2014). Zusätzlich wurde die Ausführungssemantik auch mit Hilfe des Abstract State Machine (ASM)-Formalismus analysiert (Börger and Stärk 2003), wobei mehrere Mehrdeutigkeiten, inhärente Inkonsistenzen und Lücken identifiziert wurden (Kossak et al. 2014). Dies betrifft insbesondere Werkzeuge zur Ausführung von BPMN-Prozessmodellen. Die Mehrheit dieser Werkzeuge setzt den BPMN-Standard nicht vollständig um, sondern unterstützt nur eine beschränkte Untermenge der BPMN-Symbole für die Ausführung. Hinzu kommt auch, dass teilweise die gleichen Symbole unterschiedlich interpretiert bzw. ausgeführt werden, was zu unterschiedlichen und inkompatiblen Ergebnissen der Ausführung des gleichen Prozessmodells führen kann (Geiger et al. 2018).

4.2.2.5 Möglichkeiten der digitalen Umsetzung von subjektorientierten Prozessspezifikationen Für das auf (Fleischmann 1994) zurück gehende PASS als einzige wirkliche subjektorientierte Prozessmodellierungssprache existieren zwei formale Spezifikationen, die eine digitale Umsetzung leicht ermöglichen. Zuerst wäre hier der formale Austauschstandard für PASS-Modelle zu nennen, der auf den Arbeiten von Elstermann (2017) und Elstermann und Krenn (2018) basiert und zu einer offiziellen Ontologie-basierten Spezifikation geführt hat, die über das Institute for Innovative Process Management (I2PM) verwaltet wird und unter (I2PM 2022) veröffentlicht ist. Dieser offizielle technische Standard dient dazu, Prozessmodelle zwischen verschiedenen IT-Werkzeugen zur Modellierung oder auch zur Ausführung auszutauschen. Als Spezifikations- und Austauschsprache wird dafür die vom W3C spezifizierte Web Ontology Language (OWL) (McGuinness et al. 2004; Org 2012) verwendet. Diese ist komplexer als z. B. ein XML-basierter Ansatz, bietet jedoch zahlreiche Vorteile hinsichtlich Ausdrucksmächtigkeit, Flexibilität, Erweiterbarkeit und der Möglichkeit, komplexe Graphstrukturen eines Prozessmodells nativ abzubilden, anstatt sie z. B. auf die Baumstruktur eines XML-Formates zu reduzieren (Elstermann und Krenn 2018). Dieser OWL-Standard spezifiziert die Grundelemente von PASS-Modellen und die Beziehungen, in denen diese zueinanderstehen sollten. Die eigentlichen Modelle werden ebenfalls in OWL gespeichert; dann jedoch nicht mit dem Sprachteil zur Datenstrukturspezifikation, sondern dem Aspekt zur Beschreibung von konkreten Dateninstanzen. Abb. 4.21 zeigt eine Visualisierung eines Ausschnittes des PASS OWL-Standards mit Modellelementen für die Beschreibung von Subjektverhaltensdiagrammen (Behavior Describing Components). Die dargestellte, in der Standard-PASS-Ontologie enthaltene

156

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.21 Visualisierung der OWL-Klassenstruktur in der Standard-PASS-Ontologie für Modellkomponenten zur Verhaltensbeschreibung

Struktur, entspricht dabei prinzipiell jener von PASS, wie sie in Abschn. 3.6 vorgestellt wurde. Die Spezifikation der statischen Modellstruktur ist jedoch nur die Hälfte dessen, was formal für eine einfache, direkte Digitalisierung von Prozessen notwendig ist. Der zweite, wichtige Aspekt ist eine formale Spezifikation der Ausführungssemantik einer Modellierungssprache. Das heißt, also eine einheitliche Definition des Verhaltens, das eine Workflow Engine haben würde, wenn sie ein entsprechendes Prozessmodell ausführen würde, so dass sich jede Engine, die sich an die Spezifikation hält, 100% identisch zu anderen Engines laufen würde, die das gleiche Modell ausführen. Für S-BPM/PASS existiert eine solche Spezifikation auf Basis des Abstract State Machine (ASM)-Formalismus (Börger and Stärk 2003). Diese wurde in (Börger 2011) veröffentlicht. Abb. 4.22 zeigt einen Auszug aus den unterschiedlichen ASM, die zusammen diese formale Ausführungsspezifikation für einen Interpreter bilden, der Subjektverhaltensdiagramme (SBDs) ausführen soll. Die Bedeutung beider Standardspezifikationen – die Standard-PASS Ontology/OWL für die statische Modellstruktur und die ASM-Interpreter-Spezifikation für die dynamischen Ausführungsaspekte von PASS – entsteht durch die Kombination von beiden, wie sie in (Elstermann und Wolski 2020) beschrieben ist. Jede hat ihren Zweck und zusammen ermöglichen sie es interessierten Softwareherstellern Workflow Engines oder andere

4.3 Einbeziehen von Internet of Things

157

Abb. 4.22 Teil der formalen Ausführungssemantikspezifikation von PASS in ASM-Notation – Auszug aus (Börger 2011)

digitale Werkzeuge zu schaffen, um Prozesse zu digitalisieren. Prototypisch wurde eine solche Umsetzung als Proof-Of-Conept erfolgreich von (Wolski et al. 2019) implementiert. Eine Übersicht über weitere Werkzeuge, die sich an diese Standards halten, sind in (Fleischmann et al. 2017) zu finden. Damit bietet die Subjektorientierung mit PASS von allen hier genannten Ansätzen formal gesehen die umfangreichsten Möglichkeiten, Prozesse bzw. Prozessmodelle einfach und direkt digital umzusetzen bzw. auszuführen.

4.3

Einbeziehen von Internet of Things

Entgegen seinem Namen handelt es sich beim Internet der Dinge (Internet of Things – IoT) nicht um eine andere, besondere Art von Netzwerk. Es ist nach wie vor das herkömmliche Internet, als ein Zusammenschluss von Computersystemen, die über das Internet Protokoll (IP) Daten austauschen. Der Begriff IoT steht allerdings für einer Veränderung vor allem der Anzahl der dabei verbundenen Geräte und deren Größe. Im Gegensatz zur klassischen Struktur, bei der im Internet quasi nur große, systemerhaltende Computersysteme verbunden waren, geht es beim Konzept von IoT darum, dass sehr viel kleinteiligere, vielfältigere, adpative und interaktive Systeme realisiert werden. Dies wird dadurch ermöglicht, dass angebundene aktive Computer teilweise sehr klein sind und z. B. einzelne Sensoren oder Aktuatoren repräsentieren, die in klassischen Kontexten einfach elektrisch mit entsprechenden Steuercomputern fest verdrahtet gewesen wären, was relativ unflexibel oder teilweise auch unpraktikabel zu realisieren gewesen wären. Aktuelle Software-Lösungen, die als IoT-Plattformen bezeichnet werden, sind notwendig, um eine entsprechend große Fülle an unterschiedlichsten Geräten zunächst auf technischer Ebene koordinieren zu können. Das eigentliche Ziel hinter dem Konzept von IoT ist jedoch die einfache und effektive Gestaltung von sogenannten CyberPhysischen Systemen (CPS). Um diese zu ermöglichen ist jedoch neben den technischen Vorbedingungen auch ein Umdenken notwendig, das die Gestaltung von Prozessen in

158

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

solchen Systemen betrifft. Dieses Umdenken bedeutet eine Änderung des Verständnisses eines Prozesses als lineare Abfolge von Tätigkeiten, die hierarchisiert beschrieben werden kann, hin zu einem vernetztem Denken von Prozessen als Netzwerk aus aktiven Entitäten. Diese Erkenntnis ist nicht neu, sondern wurde z. B. bereits 2013 in (Bettenhausen und Kowalewski 2013) geäußert. Abb. 4.23 zeigt einen Auszug basierend auf dieser Veröffentlichung. Auf der linken Seite wird dabei das klassische Verständnis der Organisation in der Automatisierungspyramide dargestellt. Hier stehen die eigentlichen Maschinen und Sensoren auf einer untersten Stufe, unterliegen einem linearen Ablauf und werden durch ein hierarchisch organisiertes Steuerungssystem kontrolliert. Die Aussage oder Forderung der Publikation ist jedoch, dass dieses Konzept oder Denkmuster falsch ist, vor allem wenn es darum gehen soll, Prozesse und technische Abläufe in cyber-physischen Systemen zu gestalten. Auf der rechten Seite von Abb. 4.23 wird die Begründung dafür dargestellt. Die Maschinen und Sensoren im unteren Bereich der Automatisierungspyramide links existieren natürlich immer, denn sie verrichten tatsächliche Arbeit, auch wenn sie nicht mehr unbedingt vollständig linear strukturiert sind. Auch existieren die links benannten Aufgabenbereiche nach wie vor. In der realen Welt sind die entsprechenden Prozesse der Aufgabenbereiche allerdings nicht linear und hierarchisch organisiert, sondern viel mehr komplex vernetzt, so wie rechts dargestellt. Es ist hier zu betonen, dass die rechte Grafik nicht etwa einen Spezialfall abbildet, sondern den Standard einer digitalisierten Welt und der darin ablaufenden Prozesse. Eine naheliegende Forderung aus diesem Umstand ist, dass eine Methodik, mit der Prozesse in einer solchen Welt beschrieben werden, diesen Umständen der Vernetzung gerecht wird. Sie soll es ermöglichen, verschiedenste, verteilte Entitäten aufzugreifen und sich darüber einfach und effizient zu unterhalten. Folgt man hier (Elstermann 2019), dann erfüllt von den in diesem Buch vorgestellten Beschreibungsansätzen nur die

Abb. 4.23 Versinnbildlichung der Notwendigkeit eines anderen Verständnisses von Prozessen – adaptiert von. (Bettenhausen und Kowalewski 2013)

4.3 Einbeziehen von Internet of Things

159

Subjektorientierung mit der PASS-Modellierungssprache die Voraussetzungen, effektiv und ohne zu große Umstände genutzt werden zu können. Um diese Nützlichkeit zu zeigen, betrachten wir in den folgenden Abschnitten die Paradedisziplin der CPS-Entwicklung bzw. der IoT-Systeme: Digitaler Zwilling. Genauer gesagt betrachten wir die modellgetriebene Entwicklung und einen prozessbasierten Architekturansatz auf der Basis Digitaler Zwillinge (Digital Twins, DTs), zumal es sich beim Thema Digitaler Zwilling selbst schon um eine Herausforderung im Kontext der Digitalisierung von Prozessen handelt.

4.3.1

Digitale Zwillinge

Viele Unternehmen stehen bei der digitalen Transformation zu Cyber-Physical Systems (CPS) und zu Anwendungen des Internet of Things (IoT) bzw. Internet of Behaviors (IoB) (Javaid et al. 2021; Stary 2020) vor einer Vielzahl von Herausforderungen. Diese Herausforderungen reichen von der Berücksichtigung sich ändernder Standorte von Komponenten über Interoperabilität aufgrund der Heterogenität der Komponenten bis hin zu Managementproblemen bei der Entwicklung derartiger Systeme (vgl. Wankhede und Vinodh 2021a,b; Yang et al. 2018). CPS sind sozio-technische Systeme, die im operativen Geschehen physische Geräte über Sensoren oder Aktoren mit digitaler Informationsverarbeitung verknüpfen. Sobald Systemkomponenten via Internet-basierter Protokolle verbunden sind, kommen IoTTechnologien zum Einsatz. Mit IoT bzw. IoB wird in der Regel ein konzeptionelles3 Netzwerk aus physischen Geräten und anderen Objekten bezeichnet, in dem Netzwerkkonnektivität die Einbettung elektronischer Elemente (Software, Sensoren oder Aktuatoren) ermöglicht, um Daten zu sammeln und auszutauschen. Digitale Zwillinge (Digital Twins, DTs) wiederum unterstützen die Entwicklung bzw. den Betrieb von CPS, wie die Vielfalt der Anwendungsdomänen zeigt. Sie inkludiert Landwirtschaft (vgl. Pylianidis et al. 2021), Medizin (vgl. (Voigt et al. 2021), Logistik (Rudskoy et al. 2021) und digitale Produktion (vgl. Hartmann und Van der Auweraer 2021). Die rasche Durchdringung unterschiedlichster Anwendungsbereiche hat auch zu einer Vielzahl an Vorgehensmodellen zur DT-Entwicklung geführt (Heindl und Stary 2022). Ursprünglich wurden DTs als virtuelle Modelle entworfen, um einzelne physische Objekte oder ganze Anlagen als Zusammenspiel von einzelnen Objekten zu spiegeln. Sie können allerdings mit Funktionen ausgestattet werden, die den ursprünglichen Leistungsumfang des abgebildeten physischen Objekts erweitern, beispielsweise um die Vorhersagbarkeit von Rüstzeiten auf der Grundlage von Big-Data- und Machine-Learning-Anwendungen.

3 Die Geräte sind oft technisch über das Internet selbst verbunden und nutzen dafür meist die

entsprechenden Internet-Technologien bzw. Protokolle wie TCP/IP oder HTTP.

160

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Darüber hinaus ermöglichen DTs Verhaltensmodifikationen und Simulationen, um verschiedene Prozesse zu untersuchen, bevor das physische Objekt eingebunden wird (vgl. Batty 2018; Herwig et al. 2021), https://www.ibm.com/topics/what-is-a-digital-twin). Das Digital Twin Consortium berücksichtigt in seiner DT-Definition neben dem physischen Objekt auch Prozesse, die in digitaler Form repräsentiert werden. Sie dienen insbesondere zur Simulation von „predicted futures“ – vgl. https://www.digitaltwinconsortium.org/ initiatives/the-definition-of-a-digital-twin/: „A digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity: Digital twin systems transform business by accelerating holistic understanding, optimal decision-making, and effective action; Digital twins use real-time and historical data to represent the past and present and simulate predicted futures; Digital twins are motivated by outcomes, tailored to use cases, powered by integration, built on data, guided by domain knowledge, and implemented in IT/OT systems.“ Digitale Prozesszwillinge (Digital Process Twins, DPTs) haben zum Ziel die Systemkomponenten für zukünftige Einsätze zu synchronisieren (vgl. Rosen et al. 2015). Dies sollte auf möglichst hoher Abstraktionsebene erfolgen: „[This] macro level of magnification, reveal how systems work together to create an entire production facility. Are those systems all synchronized to operate at peak efficiency, or will delays in one system affect others? Process twins can help determine the precise timing schemes that ultimately influence overall effectiveness.“ (https://www.ibm.com/topics/what-is-a-digitaltwin). Sobald die Makroebene von DPTs adressiert wird, ist zur Modellausführung und Simulation jedoch eine Detaillierung des individuellen Komponentenverhaltens im Sinne von Verhaltensmodellierung und -strukturierung erforderlich, um Steuerung, Interaktion und Verarbeitung im Rahmen eines integrativen Design- und Implementierungsprozesses gleichermaßen zu berücksichtigen (Sobhrajan und Nikam 2014). Aus Sicht des Geschäftsprozessmanagements kann das Konzept des „Prozesszwillings“ als eigenständige Idee oder als redundant oder überspezifiert bezeichnet werden, da es sich eigentlich um die Beschreibung bzw. Abbildung oder Vorhersage von Abläufen handelt, die eine bestimmte Komponente (als Subjekt) z. B. ein Produktionssystem ausführt und damit ein Teil des entsprechenden Digitalen Zwillings ist. Sollte versucht werden, damit die Spiegelung eines Prozesses zu beschreiben, der ein Objekt, z. B. ein zu produzierendes Gut, bearbeiten soll, ggf. durch mehrere unterschiedliche Akteure – eine Art passiver Prozess – so macht dies Sinn, sobald eine subjektorientierte Betrachtung im Kontext der Modellierung vorliegt, in der konstant zwischen aktiven Subjekten und passiven Objekten unterschieden wird. Aber selbst in dem Fall werden bei einer Ausführung immer noch aktive Einheiten genutzt werden müssen, für die dann wieder entsprechende digitale Zwillinge notwendig sind, die ja im Prozesszwilling mindestens implizit vorkommen. Mit Überlegungen in Richtung synchroner Interaktion physikalischer und digitaler CPS-Komponenten, d. h. der Echtzeiteinbindung von DT, wurden DTs auch noch differenzierter betrachtet (Rasheed et al. 2020). Derartige Ausführungen sind zu hinterfragen, da sie zumeist spezielle Möglichkeiten des Einsatzes von digitalen Zwillingen heraus-

4.3 Einbeziehen von Internet of Things

161

streichen, ohne deren Struktur und Funktionalität grundlegend zu verändern oder zu erweitern: • Virtueller Zwilling: Hier wird eine digitale Darstellung basierend auf einem physischen Objekt (in der Cloud) erstellt.4 • Prädiktiver Zwilling: Daten zu physikalischen Gegebenheiten bzw. von hybriden Modellen, die auf einem digitalen Modell basieren, werden genutzt um Vorhersagen des Verhaltens eines physischen Vermögenswerts zu generieren.5 • Zwillingsprojektion: Die durch den prädiktiven Zwilling erhaltenen Daten werden sukzessive analysiert, um Einblicke in die zugrunde liegenden Vorgänge und Prozesse zu gewinnen.6 In jedem Fall werden Netzwerke und Sensoren beim Einsatz von DT in CPS dazu genutzt, um mit anderen Systemen und deren Umgebung zu kommunizieren oder Daten von diesen abzurufen und dadurch die Grundfunktionalität der Kommunikation eines DTs zu realisieren.7 Das CPS umfasst im Wesentlichen die materiellen Vermögenswerte, wie beispielsweise eine Anlage oder Produktionsstätte, sowie die digitale Darstellung dieser physischen Objekte (vgl. Lu et al. 2020). Da ein DT auf sein digitales Modell beschränkt ist, kann dieser ohne Verbindung zur physischen Welt und ohne die Existenz des physischen Vermögenswerts nicht existieren. Erfolgt nun die Steuerung physikalischer Komponenten via eines DT, dann ist der DT als inhärenter Bestandteil eines CPS und dessen Entwicklung zu betrachten, wobei IoT das Netzwerk für den Datenaustausch zwischen physischen Komponenten repräsentiert. Herausforderungen für DT-basierte CPS-Entwicklungen ergeben sich insbesondere dadurch, dass DTs so entwickelt werden, um dem physikalischen Gegenstück und den Einsatzbedingungen zu entsprechen (Rasheed et al. 2020): So werden zur Erfüllung von Datenschutz-, Sicherheits- und Qualitätsanforderungen Kryptografie-, Blockchainund Big-Data-Technologien eingesetzt. Echtzeitkommunikation wird durch Komprimierungstechniken oder geeignete Kommunikationstechnologien einschließlich 5G- und IoTProtokollen unterstützt. Sowohl die Echtzeitmodellierung als auch die Bearbeitung bislang nicht erfasster Ereignisse bzw. nicht vorab bedachter Situationen erfordert eine

4 Es scheint hierbei versucht zu werden den Fokus darauf zu legen, dass die Darstellung (siehe

„Visualisierung“ im späteren Referenzmodell in Abschn. 4.3.3) des physischen Objektes durch die Technologien der Virtuellen Realität (VR) erfolgt. 5 Mit Bezug auf das Referenzmodell in Abschn. 4.3.3 wird durch diese Bezeichnung die mögliche technische Komponente der „Vorhersage“, die ein DT haben kann, in den Fokus gerückt. 6 Ausdruck dafür, dass die Vorhersagefähigkeiten des DTs komplexer sind (ggf. weil das vom DT gespiegelte System selbst komplexer ist und ggf. aus mehreren Sub-Systemen und Komponenten besteht) 7 vgl. z. B. „Externe Überwachungssyteme“ bzw. Component Manager und die entsprechenden Nachrichten im Referenzmodell.

162

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Modellierung reduzierter Ordnung, um CPS-Modelle schrittweise konstruieren sowie kontinuierlich aktualisieren und adaptieren zu können. Wesentlich bei der technologischen und organisatorischen Verknüpfung physikalischer Komponenten sind neben vernetzter Sensortechnologien die Simulation physikalischer Komponenten und neben datengesteuerten Modellen für Menschen zugängliche Interaktionsmechanismen. CPS-Betrieb und -Wartung bzw. -Weiterentwicklung sollte auf transparenten und interoperablen verteilten Architekturen basieren, die eine hybride Analyse und Modellierung ermöglichen. In einer aktuellen Studie wurde die branchenübergreifende Entwicklung digitaler Zwillinge untersucht (Heindl und Stary 2022). Obwohl es ein einheitliches Verständnis zur Konstruktion von DTs auf einer hohen Abstraktionsebene zu geben scheint, gibt es eine Vielzahl von Verfeinerungsstrategien, die verschiedene Abstraktionsschichten umfassen, um operative DTs zu entwickeln. Für DPTs sollten Systementwickler Unterstützung zu effizientem Design und effektiver Implementierung im Hinblick auf integrierte Prozesszwillinge erhalten. Entsprechende Unterstützung durch digitale Zwillinge hat die Integration und Interoperabilität von heterogenen Systemen, aus denen CPS bestehen, auf modulare, effiziente und robuste Weise zu ermöglichen (Sobhrajan und Nikam 2014). Der bereits auf Basis der Subjektorientierung vorgeschlagene verhaltenszentrierte Ansatz zur strukturierten Entwicklung von PDTs basiert auf neueren Konzeptentwicklungen (Stary 2021; Barachini und Stary 2022a) sowie vielfältigen Anwendungserfahrungen mit subjektorientierter Modellierung und ebensolchen Ausführungsmodellen (Fleischmann et al. 2012, 2015; Neubauer und Stary 2017; Stary et al. 2022).

4.3.2

Ein exemplarischer Anwendungsfall

Wir verwenden ein Verkehrsmanagementsystem als Showcase für die Beschreibung eines CPS mittels subjektorientierter Darstellung (siehe auch Stary 2021), basierend auf mehreren Smart-City-Studien, die in diesem Bereich durchgeführt wurden. Abb. 4.24 zeigt als Demonstrator den Ansatz, bestehend aus neun Teilnehmern, die mittels Subjekten repräsentiert sind, die miteinander kommunizieren. Die Kommunikationspfade sind durch Pfeile dargestellt. Das Sammelsubjekt zählt die von den vier Detektorsubjekten gemeldeten Autos und gibt die Zahlen an das Subjekt „Traffic Management“ (Verkehrsmanagement) weiter, das Daten mit dem „Environment Management“ (Umweltmanagement) austauscht. Es kommuniziert auch mit der „Intersection Control 1“ (Kreuzungszentrale 1), die wiederum das „Traffic Light 1“ (Ampel 1) steuert. Das logische Verhalten eines Subjekts enthält, wie bei Verhaltensdiagrammen vorgesehen, die Sequenzen, in denen Nachrichten gesendet oder empfangen werden, und die Aktionen, die auf lokalen Objekten/Daten ausgeführt werden. Dazu wird Abb. 4.24 mit den zwischen den beteiligten Subjekten ausgetauschten Nachrichten zu einem Subjektinteraktionsdiagramm angereichert (Abb. 4.25).

4.3 Einbeziehen von Internet of Things

Abb. 4.24 Kommunikationsstruktur eines einfachen Verkehrsmanagementsystems

Abb. 4.25 Subjektinteraktionsdiagramm des Verkehrsmanagementsystems

163

164

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.26 zeigt beispielhaft das Verhalten des Subjekts „Car Detection 1 North“ (Autoortung 1 Nord). Nach Erhalt der Nachricht „Switch on“ (Einschalten) beginnt der Sensor mit der Erkennung von Autos. Dies wird durch die interne Aktion „wait for car“ (Autos erkennen) repräsentiert. Sobald ein Auto erkannt wird, wird eine Nachricht „Car detected“ (Auto erkannt) an das Subjekt „Detected car collector“ (Zähler für erkannte Autos) gesendet. Das Subjekt „Car Detection 1 North“ (Autoortung 1 Nord) kann jederzeit die Nachricht „Switch off“ (Ausschalten) erhalten. Daher muss es jederzeit bereit sein, diese Nachricht zu empfangen. Dies wird durch einen sogenannten Wächter (engl. Guard) bzw. ein Guard Behavior realisiert (vgl. Abschn. 3.6.3.3). Diese kümmern sich um Nachrichten mit hoher Priorität bzw. fungieren als eine Art Interrupt für das Standard-Verhalten. Sobald eine solche Guard-Nachricht mit hoher Priorität im Eingabepool abgelegt wird, wird die aktuelle Verhaltenssequenz unterbrochen und das betroffene Subjekt schaltet sein Verhalten auf das Wächter-Verhalten um. In unserem Fall wird die Nachricht „Switch off“ (Ausschalten) akzeptiert und der Sensor wechselt in den Zustand „end“ (Ende). Guards bzw. Guard Behaviors sind ein Mittel, um die Reaktionen auf unvorhergesehene und unerwünschte Ereignisse zu spezifizieren.

Abb. 4.26 Verhaltensdiagramm des Subjekts „Car detection 1 north“ aus Abb. 4.25

4.3 Einbeziehen von Internet of Things

165

Auf der korrespondierenden Seite wird die Nachricht „Car detected“ (Auto erkannt) nach dem Versand im Eingangspool des Subjekts „Detected car collector“ (Zähler für erkannte Autos) gespeichert. Dieses kann dabei die Meldungen aller Autodetektoren aufnehmen, zählt in seinem Verhalten die Autos und informiert das Subjekt „Traffic Management“ (Verkehrsmanagement), wenn ein Schwellwert erreicht ist. Letzteres steuert dann die „Intersection Control 1“ (Kreuzungssteuerung 1), die wiederum das Subjekt „Traffic Light 1“ (Ampel 1) schaltet, indem sie die entsprechenden Nachrichten sendet. Abb. 4.27 zeigt jenen Teil des Verhaltens, in dem das Subjekt „Detected car collector“ (Zähler für erkannte Autos) die Nachrichten „Car detected“ (Auto erkannt) von den verschiedenen „Car detection“-(Autodetektor) Subjekten erhält.

4.3.3

Ein subjektorientiertes Referenzmodell

Eine andere Art sich mit dem Thema Digitalisierung von Prozessen und digitalen Zwillingen zu beschäftigen entstammt (Bönsch et al. 2022). Bei dem in Abb. 4.28 dargestellten Modell wurde das subjektorientierte Modellierungsparadigma genutzt, um ein Referenzmodell zu schaffen, das die prinzipielle Funktionsweise eines Prozesssystems darstellt, das als Digital Twin System (DTS) bezeichnet werden kann. Die Besonderheit liegt bei diesem Modell in der konsequenten Anwendung der Subjektorientierung. Das Modell ist vollständig subjektorientiert gedacht, was insbesondere auf die Bezeichner von Modellelementen Auswirkungen hat. Leser können sich bei ihrem Verständnis darauf verlassen, dass alle gezeigten „Boxen“ eben nicht willkürlich für Konzepte oder Methoden stehen, sondern für klar identifizierbare, aktive Elemente eines Digital Twin Systems bzw. für die Datenobjekte, die zwischen den Systemkomponenten ausgetauscht werden. Das Modell soll insbesondere Menschen, die nicht mit dem Konzept eines DTS vertraut sind. auf einfache Weise Fragen beantworten wie: „WER macht WAS WOMIT?“ oder „WOHER kommt welche Information?“, um darüber zu verstehen, was ein DTS ist. Es ist also vor allem ein erklärendes Prozesssystemmodell, das für die zwischenmenschliche Kommunikation und den Austausch über digitale Prozesse gedacht ist. Dadurch ist es ein Beispiel für eine andere Art von Rolle, die Prozessmodelle für die Bewältigung von Herausforderungen der Digitalisierung spielen können. Um diesen Ansatz besser zu verstehen werden im Folgenden die Struktur des Modells und die darin enthaltenen Subjekte kurz erläutert.

4.3.3.1 Aufbau des Referenzmodells Die prinzipielle Idee des Modells ist es, alle Arten von Digital Twin Systemen (DTS) zu repräsentieren, auch wenn diese unterschiedliche Ausprägungen oder Reifegrade haben. In realen DTS werden nur in wenigen Fällen wirklich alle gezeigten aktiven Komponenten vorkommen. Mehrere Beispiele für konkrete Ausprägungen sind in (Bönsch et al. 2022) aufgezeigt.

Abb. 4.27 Teil des Verhaltens des Subjekts „Detected car collector“ (Zähler für erkannte Autos)

166 4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

4.3 Einbeziehen von Internet of Things

167

Abb. 4.28 SID eines subjektorientierten Referenzmodells für Digital Twins aus. (Bönsch et al. 2022)

4.3.3.2 Das Real Twin System Im Kern des Modells steht das „Real Twin System“ (RTS) das durch das namensgebende „Digital Twin System“ (DTS) gespiegelt wird. Essenziell innerhalb des RTS ist das eigentliche „Asset“. Abhängig von der tatsächlichen Beschaffenheit dieses Assets, kann dieses auch eigenen „Sensoren“ oder „Aktuatoren“ haben, die es dem Asset ermöglichen, sich selbst zu überwachen und zu steuern. Bei Assets ohne eigene Verarbeitung. Um ein physisches Asset in der digitalen Domäne zu repräsentieren und die Kommunikation mit seinem Digital Twin zu koordinieren und Sensoren/Aktuatoren anzubinden, bedarf es in der Regel einer Software-Komponente die hier als „Component Manager“8 bezeichnet wird. Diese Komponente kann z. B. Teil einer technischen Industry 4.0-Software-Lösung oder eines Architektur Frameworks sein. Auch wieder in Abhängigkeit der Beschaffenheit des Assets kann der Component Manager ggf. auf Hardware ausgeführt werden, die

8 Das Konzept des Component Managers basiert grob auf der Idee der Verwaltungsschale, die

von der Initiative Plattform Industrie 4.0 erstellt wurde. (Verein Deutscher Ingenieure e.V. and VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik 2014).

168

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

physisch Teil des RTS ist. Ebenso kann dieser aber auch auf externen Geräten ausgeführt werden, wenn das Asset selbst keine eigenen oder ausreichende Rechenanlagen besitzt.9 In jedem Fall und solange das Asset entsprechende Fähigkeiten besitzt, wird es mit dem DTS Informationen austauschen. Dabei handelt es sich prinzipiell um Berichte über den eigenen Zustand („digital status information“), die an das DTS gesendet werden. Sollte das Asset entsprechend ausgestattet sein, dann können wiederum Steueranweisungen („control commands“) vom DTS zurückgesendet werden, die, wenn ausgeführt, zu einer Zustandsänderung des Assets führen können. Neben direkten Steuerkommandos können damit aber auch z. B. Software-Updates gemeint sein. External Surveillance: Wie erwähnt, kann es sein, dass es sich beim Asset um ein primitives, physisches Objekt ohne eigene Sensoren handelt, z. B. ein Motorblock der eine Produktionsanlage durchläuft. Damit ein Digital Twin in diesem Fall die notwendige „Status Information“ zu seinem Asset erhalten kann, bedarf es externer Überwachungssysteme („Surveillance Systems“) bzw. Sensoren, die zunächst nicht speziell zur Überwachung eines einzelnen Assets gedacht sind und daher auch kein expliziter Teil des DTS sind. Beispiele dafür sind z. B. Überwachungskameras oder Temperatursensoren, die zu einem Fabrikgebäude gehören, oder auch Anlagen zum Tracken von RFID-Labeln in der Logistik. Wichtig hierbei ist, dass diese Systeme für Information über das einzelne Asset vom DTS explizit angefragt bzw. ihre Daten explizit ausgewertet werden müssen.

4.3.3.3 Eigentliches Digital Twin System Wie bereits beschrieben, steht dem Asset bzw. dem RTS das eigentliche „Digital Twin System (DTS)“ gegenüber. Die tatsächliche Beschaffenheit und Fähigkeiten eines DTS können dabei sehr vielfältig sein und hängen stark von den Technologien ab, mit denen es selbst geschaffen wird. Ein DTS hat dabei prinzipiell sechs Hauptfunktionen, von denen vier die eigentlich wertschaffenden Aufgaben eines Digital Twins repräsentieren: „Data Collection“, „Data Processing“, „Simulation“, und „Auto Decision“. Diese bauen aufeinander auf, bzw. sind teilweise voneinander abhängig. Gegebenenfalls sind jedoch nicht alle Funktionen immer in jedem DTS vorhanden. Dies hängt von seinem Reifegrad10 bzw. den Anforderungen eines konkreten Use Cases ab. Darüber hinaus werden die vier Kernfunktionen von zwei Funktionen ergänzt, die notwendig sind, um einen DTS tatsächlich nutzen zu können. Dies sind zum einen der „Sync Supervisor“, eine Komponente die für die Kommunikation zwischen virtueller Welt und physischer Welt des Assets zuständig ist, sowie die Visualization, die für den Austausch zwischen 9 Für die konkrete Realisierung dieser Aspekte spielen, wie im vorherigen Abschnitt erläutert, IoT-

Technologien eine große Rolle. 10 Die Funktionsbereiche des Modell koinzidieren relativ gut mit dem Industrie 4.0 Maturity Index

(I4.0 MI) Modell der Deutsche Akademie der Technikwissenschaften – acatech. https://en.acatech. de sind dabei jedoch nicht als abstrakte Stufen sondern als Aufgabenbereiche bzw. Funktionen zu sehen.

4.3 Einbeziehen von Internet of Things

169

DTS und den es nutzenden Menschen notwendig ist. Im Folgenden werden die einzelnen Funktionen und ihre Aufgabe noch einmal detailliert erläutert. Data Collection Die Sammlung und Speicherung von Daten („Data Collection“) ist die notwendigste Funktion die jedes DTS besitzen sollte. Sie bildet die Grundlage, um den Nutzern Sichtbarkeit (Visibility) über den gegenwärtigen und vergangenen (IST-)Zustand eines gespiegelten Assets zu liefern und auch die Basis für die übrigen Funktionen. Das Funktionieren der „Data Collection“ ist wiederum besonders auf das Funktionieren des „Sync Supervisor“ angewiesen. Data Processing Die (Vor-)Verarbeitung und Auswertung der Daten („Data Processing“) ist die nächste Stufe der Fähigkeiten, die ein Digital Twin haben sollte. Im Gegensatz zur reinen Sammlung und Speicherung von Daten, beinhaltet dieser Funktionsblock alle Methoden, um Daten zusammenzufassen und aufzubereiten, und um die Transparenz (transparency) der Informationen über das Asset für Nutzer zu verbessern. Dabei kann es sich um einfache statistische Auswertungsverfahren handeln. Aber auch komplexere Formen z. B. mit Methoden der künstlichen Intelligenz (KI) sind prinzipiell für diese Art von Aufgabe anwendbar. Eine weitere typische Aufgabe des „Data Processing“ ist z. b. die Diskretisierung von Zeitserien und die Identifikation von darin enthaltenen Events, die wiederum weitere Aktionen des DTS auslösen können. Simulation Die nächste Reifegradstufe, die ein DTS erreichen kann, beinhaltet die Fähigkeit auf Basis der gesammelten und aufgearbeiteten Daten Vorhersagen über einen oder mehrere mögliche Zustände des RTS in der Zukunft zu machen. „Predictive Maintenance“ ist hierfür der wahrscheinlich bekannteste Use Case. Der Begriff der „Simulation“ ist dabei der treffendste Oberbegriff, der unterschiedlichste Methoden und Techniken umfasst, die von etablierten statistischen Methoden wie der Regressionsanalyse, über klassische, Agenten-basierte Computersimulation, bis hin zu Verfahren des Maschinellen Lernens (ML) reichen können. Welche davon eingesetzt werden hängt wieder von der Beschaffenheit und Funktionsweise des RTS ab und welche Methoden und Techniken zur Abschätzung einer zukünftigen Entwicklung von einem Jetzt-Zeitpunkt zur Verfügung stehen. Auto Decision Zuerst einmal können die Ergebnisse und möglichen Szenarien, die durch Simulationskomponenten erstellt werden natürlich manuell durch Menschen ausgewertet werden. Diese können dann basierend auf den Vorhersagen entsprechende Entscheidungen treffen und sind für diese auch verantwortlich. Die eigentliche Vision für Digital Twins, insbesondere im Rahmen des Konzeptes der Industrie 4.0 wie sie z. B. von (Schuh et al. 2020) beschrieben wird, beinhaltet allerdings die Vorstellung, dass Entscheidungen teilweise oder sogar vollständig autonom von Systemen getroffen werden (Auto Decision) und durch die Funktionen des DTS ggf. auch direkt umgesetzt werden. Dies kann grundsätzlich auf zwei Arten technisch gelöst werden. Der einfache Weg ist ein regelbasierter Ansatz, bei dem durch das Detektieren eines bestimmten Events in den gesammelten oder ggf. simulierten Daten bestimmte, vordefinierte

170

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Aktionen ausgelöst werden. Dies ist konzeptionell sehr ähnlich bzw. identisch zu den bestehenden Methoden der Regelungstechnik. Der zweite Ansatz ist der explorative Ansatz, bei dem es Aufgabe des Digitalen Zwillings ist zu bestimmen, welchen Zustand das RTS optimalerweise annehmen sollte. Der mögliche, optimale Zustand kann dabei sowohl aus vergangenen und gegenwärtigen als auch aus zukünftigen (simulierten) Daten bestimmt werden, wobei zusätzlich intern Optimierungsalgorithmen zusammen mit von Menschen gesetzten Rahmenbedingungen und Regeln zur Anwendung kommen. Die Möglichkeiten dieses technisch umzusetzen reichen dabei von direkten und fix programmierten Regelsätzen, über dynamische „Business Rules“ in verschiedenen domänenspezifischen Ausprägungen (z. B. die Semantic Web Rule Language – SWRL), bis hin zu selbstlernenden KI-Systemen. Darüber hinaus hängt der tatsächlich Grad der Unabhängigkeit, mit der ein DTS eigene Entscheidungen treffen kann, von den Präferenzen seiner Nutzer ab, die entsprechende Einstellungen vornehmen können sollten. Synchronization Der „Sync Supervisor“ repräsentiert alle technischen Komponenten eines DTS die dafür verantwortlich sind, die Verbindung mit dem RTS sowie anderen externen Systemen aufzubauen, zu managen und aufrecht zu erhalten, oder bei einem Ausfall entsprechend wieder herzustellen bzw. das DTS entsprechend einzuschränken solange keine Verbindung besteht. Diese unterstützende Funktion muss notwendigerweise, zumindest rudimentär, in jedem Digital Twin System vorkommen, da ein komplexes, ggf. Netzwerk-basiertes IT-System niemals eine hundertprozentige Verfügbarkeit haben kann. Mögliche Gründe für einen zumindest temporären Verlust der Verbindung zwischen DTS und RTS sind z. B. wechselnde Latenzen, Ausfälle von Netzwerk oder Strom, fehlende Überwachungsmöglichkeiten, menschliche Fehler oder absichtliche Sabotage. Visualization Die zweite dargestellte, unterstützende Funktion eines Digital Twin System ist die Visualisierung („Visualization“). Ihre Aufgabe ist es für menschliche Nutzer die Daten und Informationen, die ein DTS über ein RTS enthält möglichst intuitiv und verständlich zugänglich zu machen und ggf. auch seinen Usern die Kontrolle über das RTS via DTS zu geben. Unter allen Funktionen ist die Visualisierung wahrscheinlich die wichtigste, wenn es darum geht, die Fähigkeiten eines Digital Twin nach außen für seine Nutzer darzustellen. Wie etwas tatsächlich dargestellt werden kann oder sollte, hängt stark vom jeweiligen Use Case ab und welche der Kernfunktionalitäten implementiert sind. Die technischen Möglichkeiten reichen dabei vom vollständigen Fehlen einer Visualisierung (z. B. für DTS, die technische Unterkomponenten von komplexeren übergeordneten Systemen sind und keine menschlichen Nutzer haben), über einfache 2D-Darstellungen von Tabellen und Diagrammen in sogenannten Dashboards, bis hin zu vollständig immersiven Virtual oder Augemented Reality (VR/AR)Umgebungen. Prinzipiell sind aber auch andere Konzepte, die ein Interface zwischen Digital Twin und menschlichen Nutzern bilden, in dieser Komponente enthalten. Z. B. eine vom DTS generierte Sprachanleitung für Fabrikarbeiter.

4.3 Einbeziehen von Internet of Things

171

4.3.3.4 Die menschliche Komponente Wie jedes andere IT-System sollten auch Digital Twins prinzipiell dem Nutzen von Menschen dienen. Daher spielen diese im Referenzmodell auch eine entsprechend wichtige Rolle. Genauer unterscheidet das Modell drei unterschiedliche, prinzipielle Rollen, die Menschen im Kontext von DTS haben können. Entsprechend des Konzeptes der subjektorientierten Beschreibung könnte ein Mensch zu verschiedenen Zeitpunkten alle diese Rollen ausfüllen. User of the Asset In den meisten Fällen wird es Menschen geben, die direkt und ausschließlich mit dem physischen Asset interagieren und sich dabei noch nicht einmal der Existenz eines Digital Twins gewahr sein müssen („Users of [the] Asset“). Ein Beispiel hierfür wäre z. B. ein Fabrikarbeiter, der eine Produktionsmaschine vor Ort bedient oder Änderungen an ihr vornimmt, aber nichts über die Daten weiß, die an ein zentrales Informationssystem fließen. Ein anderes Beispiel wäre der Fahrer eines modernen Automobils, der nicht wissen muss, dass der Hersteller einen DTS für den Wagen betreibt, um z. B. im Pannenfall Probleme schneller beheben zu können oder diese durch verbesserte Wartung (Predictive Maintainance) gar nicht erst entstehen zu lassen. User of the Digital Twin Seinen tatsächlichen Nutzen kann ein DTS nur für Menschen erbringen, die direkt über den Digital Twin den Zustand des RTS überprüfen oder andersherum auch Daten über das Asset manuell in das DTS einpflegen. Ebenso können natürlich auch Anweisungen aus dem DTS an diese Art von Nutzer gehen, deren Ausführung eine Veränderung des RTS zur Folge hat. Aber auch vom DTS erzeugte und aufbereitete (Simulations-)Daten können z. B. Auswirkungen auf Manager haben, die diese auswerten und daraufhin Veränderung an der Konfiguration des Assets vornehmen lassen. Wenn es sich um ein steuerbares Asset handelt können diese Art von Nutzern das Asset natürlich auch über den DTS steuern bzw. entsprechende Anweisungen geben, die Auswirkung auf das Verhalten des Assets haben. Designer of the Digital Twin Die dritte Rolle, die ein Mensch im Kontext eines Digital Twin Systems haben kann, ist die des „Designers“ oder „Admins“. Im Gegensatz zu einem normalen Nutzer, der quasi nur passiv ein vorkonfiguriertes System benutzt, hat ein entsprechender Designer die Möglichkeit, den Digital Twin zu gestalten und anzupassen. Neben der ursprünglichen Initialisierung, Programmierung und Konfiguration hat ein Administrator nach dem Start eines DTS die Möglichkeit Regeln (Business Rules) oder Richtlinien zu verändern, die z. B. Auswirkungen auf die autonomen Entscheidungen des Systems haben.

4.3.3.5 Andere IT-Systeme Neben den verschiedenen menschlichen Rollen, dem eigentlichen RTS und ggf. überwachenden Sensoren, interagiert ein DTS noch mit zwei weiteren prinzipiellen Arten von Entitäten.

172

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Externe IT-Systeme Die erste Art diese Entitäten repräsentiert unterschiedlichste externe technische Informationssysteme, die weder direkter Teil des DTS sind noch anderweitig für die Überwachung des RTS verantwortlich sind. Beispiele dafür sind u. a. angeschlossene Enterprise Resource Planning (ERP) Systeme, über die das DTS z. B. automatisch Wartungsdienstleistungen oder Ersatzteile ordern kann – dies setzt eine entsprechend fähige Auto Decision-Komponente voraus. Ein weiteres mögliches Szenario ist der automatische Bezug von Konstruktionszeichnungen oder anderen Engineering-Informationen aus PDM/PLM-Systemen, die ggf. für Simulationen benötigt werden. Die Kommunikation zwischen DTS und diesen Systemen wird dem entsprechend im Modell sehr generisch beschrieben. Dabei wird die Möglichkeit dargestellt, dass das DTS gezielte Anfragen (queries) an diese externen Systeme stellen kann, die dann beantwortet werden sollten („reports/responses“). Darüber hinaus kann, ganz allgemein, das Melden von Ereignissen („trigger“) in beiden Systemen wechselseitig weitere Reaktionen auslösen. Andere Digital Twins Technisch gesehen sind andere Digitale Zwillingssysteme, mit denen das betrachtete System interagiert, zunächst „externe IT-Systeme“. Das Referenzmodell betrachtet die Interaktion mit anderen DTS etwas spezieller und komplexer. Prinzipiell kommt es dort zwar zum Austausch der gleichen Informationen (Trigger, Anfragen und Antworten). Allerdings hängt die tatsächliche Ausprägung der Kommunikation von der Art der Beziehung ab, in der beide DTS zueinanderstehen. Dabei gibt es prinzipiell drei unterschiedliche Arten von Beziehungen. Die erste ist die, in der beide digitalen Zwillinge konzeptionell ebenbürtig oder gleichwertig sind und sich mit einer Peer-to-Peer-Strategie koordinieren müssen. Z. B. zwei autonome Roboter, die gemeinsam etwas transportieren müssen. Die zweite Beziehungsvariante ist die einer einfachen Assoziation. Dabei unterscheidet sich die Natur der repräsentierten Assets stark aber beide interagieren zumindest zeitweise auf eine festgelegte Weise wie z. B. die digitalen Zwillinge eines Produktes und der Produktionsanlage, auf der es gerade produziert wird. Die dritte Variante besteht, wenn die physischen Assets beider digitalen Zwillinge in einer hierarchischen Beziehung zueinander stehen. Das Beispiel dafür ist eine einzelne Produktionsmaschine (mit ihrem eigenen dedizierten DTS), die aber gleichzeitig fester Teil einer größeren Produktionsanlage ist, deren DTS alle darin enthaltenen Maschinen koordiniert. Gleichzeitig kann es auch jeweils digitale Zwillinge für Unterkomponenten geben, die fester Bestandteil der einzelnen Produktionsmaschine sind. Dabei leiten die Zwillinge der Unterkomponenten den Zustand ihrer Assets an das übergeordnete System weiter, so dass hier z. B. Predictive Maintenance für die Maschine realisiert werden kann. Auf der anderen Seite ist das DTS der Fabrik dem der einzelnen Maschine gegenüber „weisungsbefugt“, wofür es jedoch Prognosen über Auslastung und Verfügbarkeit benötigt. Alle drei Szenarien sind potenziell komplex, aber innerhalb der möglichen Anwendungskonzepte, die für digitale Zwillinge existieren. Die Betrachtung eines Szenarios mit

4.4 Einbeziehung von Künstlicher Intelligenz

173

nur einem einzelnen konkreten digital Zwilling ist dabei der einfachste Use Case. Da der Hauptzweck dieses Modells jedoch die verständliche Erklärung ist, wurde an dieser Stelle vereinfacht und nur ein allgemeiner Kommunikationskanal mit anderen digitalen Zwillingen dargestellt („Neighbouring Digital Twin Systems“).

4.3.3.6 Fazit zum Referenzmodell In den vorherigen Abschnitten wurde ein Referenzmodell erläutert. Als Fazit sei an dieser Stelle dazu bemerkt: Sobald ein Leser ein Referenzmodell als einfach und leicht verständlich empfindet, und ggf. offensichtliche Umstände beschreibt, dann erfüllt es seine Funktion in vollem Ausmaß.

4.4

Einbeziehung von Künstlicher Intelligenz

Eine weitere und vielleicht aktuell die prägnanteste Herausforderung für die Digitalisierung von Prozessen ist der Themenkomplex der Künstlichen Intelligenz (KI). Es steht nahezu außer Frage, dass die Informationstechnologien, die unter dem Begriff KI zusammengefasst werden, einen großen Einfluss auf die digitale Arbeitswelt der kommenden Jahre haben werden. Die genauen Anwendungsmöglichkeiten, Herausforderungen oder Risiken detailliert zu analysieren liegt bei Weitem außerhalb des Umfanges dieses Buches und noch viel weniger in den Möglichkeiten eines Abschnittes in einem einzelnen Kapitel. Es sollen hier jedoch drei prinzipiellen Anwendungs- bzw. Impakt-Szenarien dieser Technologie umrissen werden, um darzulegen wie KI im Kontext von digitalen Prozessen verstanden oder eingesetzt werden kann.

4.4.1

Künstliche Intelligenz als Ersatz für Prozesse?

Ein großer Traum, der vielleicht schon seit den ersten Tagen der Nutzung von digitalen Rechnern besteht, ist es, dass die Maschinen dem Menschen umständliche Arbeit vollständig abnehmen werden; dass ein Nutzer nur noch mittels Sprachbefehl sein Problem benennen muss und die Lösung wird automatisch ermittelt. Für Geschäftsprozesse würde dies bedeuten, dass sich weder Anwender noch Entwickler noch wirklich um etwas kümmern müssten, weil ein KI-System auf „magische“ Weise alle Abläufe, die zum Erfolg einer Organisation notwendig sind, eigenständig plant, durchführt und überwacht und sich daher niemand mehr mit der Gestaltung und Digitalisierung von Prozessen manuell beschäftigen muss (was dieses Buches hier relativ nutzlos werden ließe). Um nicht die gleichen Vorhersagefehler über die Möglichkeiten oder Unmöglichkeit von Computersystemen zu machen, wie sie im Laufe der Jahre in der Digitalisierung oft gemacht worden sind, soll hier nicht widersprochen werden, dass dieses Szenario irgendwann möglich sein wird. Allerdings noch nicht in ganz naher Zukunft und dann

174

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

erst einmal nur für relativ einfache Prozesse und Abläufe, also Abläufe, die vollständig digital überwachbar sind und für die daher eine große Datenmenge als Lernmaterial für KI-Anwendungen vorhanden ist, sowie Abläufe, die so oft geschehen, dass sich ihre Automatisierung und Überwachung in einem extra für sie angelernten KI-System lohnt und ohne hohen Aufwand ist. Das Stellen eines Weckers per Sprachsteuerung funktioniert z. B. jetzt schon adäquat, sei es mit Siri, Cortana oder Google Sprachassistent. Dabei handelt es sich aber um einen Routineprozess, der millionenfach täglich gemacht wird, und der dadurch gut für entsprechende KI-Systeme trainiert werden kann. Ähnlich verhält es sich mit dem Überwachen der Qualität von Produktionsprozessen, bei denen viele Bauteile einzeln begutachtet werden müssen. Die Existenz einer klaren Qualitätsdefinition vorausgesetzt, ist ein KI-basiertes System, das fehlerhaft produzierte Teile aussortiert, relativ einfach umsetzbar. Ob diese Beispiele allerdings überhaupt als Prozesse bezeichnet werden sollten, hängt von der Definition des geneigten Lesers ab. Das vorläufige Fazit, das hier gezogen werden soll, ist, dass es durchaus vorstellbar ist, dass Routineaufgaben und Teilprozesse mit KI einfach zu automatisieren sein werden. Dies wird aber auf absehbare Zeit Entwickler wie Anwender nicht davon entbinden, sich zumindest über das Zusammenspiel bzw. die Orchestrierung von Aktivitäten, also mindestens über übergeordnete Geschäftsprozesse, Gedanken zu machen.

4.4.2

Einbindung von Ansätzen zur Künstlichen Intelligenz in Prozesse

Während also eine vollständig automatisierte Gestaltung und Abwicklung von Geschäftsprozessen einer Organisation durch KI wahrscheinlich noch ein ferner Traum ist, ist es quasi sicher, dass einzelne Aufgabenblöcke innerhalb von Prozessen durch IT-Komponenten übernommen werden, die nicht mehr klassisch programmiert wurden, sondern auf Basis von unterschiedlichen KI-Technologien erstellt wurden. Die Frage, die sich aus dieser Betrachtung ergibt, ist: Wie kann oder soll KI in Prozesse integriert werden? Übersichten darüber, wo welche Art von KI wie erfolgreich eingesetzt wird gibt es viele (z. B. Javaid et al. 2022 oder Ahmed et al. 2022). Die von KI gelösten Fragestellungen und Aufgaben sind dabei meist relativ konkret und sind gut zu lösen, sobald eine entsprechende Datenlage mit messbaren und klassifizierten Daten vorhanden ist, also bei wiederkehrenden Abläufen und einem sich zunächst kaum verändernden Prozesskontext. Um diese Abläufe in übergeordneten Prozessen zu koordinieren, gibt es zwei Möglichkeiten der Betrachtung bzw. der Modellierung. Zum einen können KI-Aktivitäten in einem klassischen Aktivitätsdiagramm einfach als Funktionsaufrufe beschrieben werden. Dabei kann ihre Bedeutung jedoch leicht untergehen oder versteckt werden, wodurch wiederum die Kommunikation über ihren Einsatz ggf. unterbunden oder zumindest vermindert wird.

4.4 Einbeziehung von Künstlicher Intelligenz

175

Abb. 4.29 zeigt, wie diese Art der Abbildung in einem Prozessmodell aussehen könnte. Ohne den explizit gezeigten Kommentar würde die KI-Unterstützung komplett untergehen. Und selbst mit Kommentar ist sie kaum mehr als eine Randbemerkung. Sobald die Akzeptanz durch Nutzer und damit die humanzentrierte Gestaltung technischer Systeme in den Mittelpunkt rückt, ist Transparenz jedoch ein hohes Gut. Dafür ist es empfehlenswert, entsprechende KI-Funktionen als explizite aktive Prozesskomponenten oder Module zu betrachten, die in einen organisatorischen Rahmen effizient eingebunden werden müssen. Diese Art der Darstellung wie auch in Abb. 4.30 gezeigt, illustriert den expliziten Einsatz von KI in einem Prozess, wobei die entsprechende Komponente als Subjekt in einem Interaktionsdiagramm vorkommt. Die konkreten, internen Abläufe der KI können dabei detailliert beschrieben werden. Sie können aber auch als Black Box weggelassen werden, da Sie für den Prozessablauf, der Menschen involviert, unmittelbar nur bezüglich ihres Ergebnisses von Bedeutung sind. Allerdings ist es bereits wichtig, bei der Gestaltung von Prozessen zu überlegen, wie die Interaktion einer Black Box mit der Außenwelt erfolgen kann oder soll. „Welche Informationen werden gebraucht?“ und „Was genau wird zurückgeliefert?“, um daran anschließend zu überlegen, wer den Einsatz der KI quasi verantwortet und deren Ergebnisse auswertet. Alleine dadurch kann oder sollte in Prozessen dieser sozio-technischen Systeme auch gezeigt werden, dass zwar KI eingesetzt wird, dabei jedoch der Zweck und die zu erwartenden Ergebnisse von Menschen vorgegeben werden. KI sollte also als ein weiteres Werkzeug bei der Digitalisierung von Prozessen verstanden und gestaltet werden, nicht jedoch als etwas Magisches, dem Prozessbeteiligte ausgeliefert sind.

Abb. 4.29 Leicht zu ignorierende Beschreibung der Nutzung von KI in einem Prozess als Ergänzung in einem Aktivitätsdiagramm

Abb. 4.30 Explizite Modellierung der Verwendung von KI als explizites und aktives Prozesselement – in Form eines Subjekts in einem SID

176

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Eine klare Darstellung ist dabei für die Einbindung in Prozesse eine Voraussetzung. Es bedarf aber auch der Nachvollziehbarkeit für die Entscheidungen der KI selbst, um diese als vertrauenswürdigen Prozessbeteiligten ansehen zu können. Das dazugehörige Stichwort der Forschung ist Explainable AI – siehe z. B. (Gunning et al. 2019) – eine Disziplin, die in diesem Kontext in den kommenden Jahren auch wichtiger werden wird, aber noch am Anfang steht.

4.4.2.1 Künstliche Intelligenz im Prozessmanagement: Process Mining Das Management von Prozessen (Business Process Management – BPM) ist selbst ein Prozess. Es ist daher folgerichtig davon auszugehen, dass auch in diesem Bereich KIbasierte Unterstützungssysteme ein Teil von Arbeitsabläufen werden. Viele Aktivitäten der Automatisierung in dem Bereich fallen unten den Überbegriff des Process Mining (vgl. auch Abschn. 7.3.4). Typischerweise werden hier die Modellierung bzw. der Verständnisgewinn über Prozesse (Process Discovery), das Überwachen (Conformance Checking) und ggf. die Verbesserung von Prozessen (Enhancement) (Van Der Aalst 2016) genannt. Für die Digitalisierung dieser Art von Prozessen kommen prinzipiell klassische, algorithmische Verfahren zum Einsatz. Aber es gibt auch eine Vielzahl von Forschungsbeiträgen, die sich dem Einsatz von KI in diesem Feld der Digitalisierung widmen (z. B. Mehdiyev und Fettke 2021, Veit et al. 2017 oder Pery et al. 2022).

4.4.3

Verstehen von KI über Prozessmodelle

Eine dritte Möglichkeit KI-Technologien in Verbindung zum Management von Prozessen zu betrachten, ist ihre Funktionsweisen und Abläufe ihrer Anwendung selbst als Prozesse zu begreifen und entsprechend zu beschreiben. Dabei können die Möglichkeiten der Prozessmodellierung genutzt werden, um ein besseres Verständnis der unterschiedlichen KI-Technologien und ihrer Anwendung zu erreichen. Abb. 4.31 zeigt beispielhaft ein Subjektinteraktionsdiagramm eines Modells aus (Elstermann et al. 2021). Es soll erklären, wie das Zusammenspiel zwischen verschiedenen Entitäten wie dem KI-Trainer, dem Nutzer und den unterschiedlichen technischen Komponenten bei der Nutzung der KI-Technologie der künstlichen neuronalen Netze prinzipiell abläuft. Solche Modelle können dabei helfen, Verständnis zu erhöhen und einem größeren Kreis von Personen Gestaltungsmöglichkeiten mit KI zu vermitteln, um so Akzeptanz für das Ganze zu gewinnen.

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

177

Abb. 4.31 SID eines Modells zur Beschreibung des grundsätzlichen Anwendungsprozesses von Künstlichen Neuronalen Netzwerken. (Aus Elstermann et al. 2021)

4.5

Integration sozialer Verhaltensmuster in die Prozessmodellierung

Die letzte Herausforderung, die in diesem Kapitel angesprochen werden soll, betrifft das eigentliche Zusammenspiel von Menschen und digitalen Prozessen. Denn solange Menschen auch in digitalisierten Prozessen eine Rolle spielen sollen, sollten sie und ihre Eigenheiten entsprechend auch in der Konzipierung digitaler Prozesssysteme explizit berücksichtigt werden. Die subjektorientierte Modellierung stellt dafür geeignete Mittel zur Verfügung, da sie über Verhalten von materiellen und immateriellen Verhaltenseigenschaften abstrahiert. Dies inkludiert, dass soziale Verhaltensmuster ebenso wie technische Funktionen in subjektorientierten Modellen abgebildet werden können. Daher wollen wir uns in der Folge mit der Konstruktion von Verhaltensmodellen mittels subjektorientierter Modellierung unter Einbettung sozio-emotionaler Aspekte gemäß aktueller Mensch-SystemIntegrationsforschung (vgl. Boy 2022) widmen. Diese Weiterentwicklung von z. B. Digital Twins zu sogenannten Digital Selves, wie in (Barachini und Stary 2022b) dargestellt, berücksichtigt neben funktionalen bzw. kognitiven Aspekten von sozio-technischen Systemen auch sozial relevantes Verhalten von Akteuren in cyber-physischen Umgebungen. Wir erläutern zunächst das grundlegende Konzept, ehe wir die Entwicklung subjektorientierter Repräsentationen von Digital Selves detaillieren.

178

4.5.1

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Konzeption

Um Aspekte des Sozialverhaltens erweiterte funktionale Modelle können auf empirischen Befunden oder/und Simulationen von sozialen Systemen basieren. Diese Erweiterung des Verhaltens erlaubt so die Einbindung von sozial, und nicht unbedingt aus funktionalen Rollen begründbaren Verhaltensweisen neben aufgabenspezifischen Verhalten von Rollenträgern. Als Ausgangspunkt zur Entwicklung von erweiterten Modellen werden jedoch funktionale Rollen herangezogen, wie beispielsweise Kreditbearbeitung, Recruiting, Lernbegleitung, Facility Management oder Produktmanagement. Weniger typische, aber funktionale Verhaltensabstraktionen beziehen sich auf Aktivitäten, die organisationsoder bereichsübergreifende Aufgaben repräsentieren. Beispiele dieser Art sind Informationssammlung, Datenschutzbeauftragte, Qualitätsmanagement, Krisenkoordination oder Sicherheitsverantwortliche, die alle natürlich auch Teil von eigenen Prozessen sind. Diese Prozesse werden aber meistens nicht auf die gleiche Art beschrieben und betrachtet wie die vermeintlichen Haupt- oder Kerngeschäftsprozesse, in denen die Subjekte der ersten Kategorie vorkommen. Sie sind jedoch nicht von geringerer Bedeutung, da sie essenzielle Unterstützungs- bzw. Querschnittsfunktionen betreffen. Beide Arten von Rollen können mit sozialen Verhaltensbeschreibungen gekoppelt werden. Da Subjekte abstrakte Rollen innerhalb eines Kontextes jeweils eines spezifischen Prozesse sind und Digital Selves eine Art von erweiterten Subjekten sind, ist jede Instanziierung eines erweiterten Subjekts mit der Umsetzung in einem sozio-technischen Umfeld verknüpft, das wiederum vom Prozessmodell beschrieben wird, in dem das Subjekt vorkommt. Typische Implementierungen umfassen Roboter, die Notfälle erkennen und einen entsprechenden Ablauf in Gang setzen, sowie Komponenten, die Informationsdienste selbsttätig verrichten, oder Kundendienste, die in einer Smart-Home-Umgebung Internet-of-Things-Systeme in Abstimmung mit ihren NutzerInnen konfigurieren. Intern führt auch jedes sozial erweiterte Subjekt entweder lokale Aktivitäten aus oder sendet Nachrichten an andere Subjekte bzw. erwartet Nachrichten von anderen. Beim Erkennen emotionaler Aspekte kann jedoch jede ausführende Aktivität mit einem weiteren Subjekt verknüpft werden, das das Verhalten in nachfolgenden Schritten beeinflusst. Solche „Influencer“-Subjekte können mit Parametern versehen werden, die sich auf frühere Aktivitäten beziehen und so eine Entscheidungshilfe für die Auswahl weiterer Aktivitäten des aufrufenden Subjekts im Sinne von sozial begründbarem Verhalten liefern. Subjekte, die intern Aktivitäten ausführen, können so mit anderen Subjekten zu einem sozio-emotional relevanten Systemverhalten kombiniert werden. Dabei sind die bislang getrennten „Spezifikationen von Subjektverhalten“ mit den entsprechend gewünschten Verhaltensmustern abzustimmen. Verhaltensmuster, die funktionale Aufgaben wie die Auftragsbearbeitung umfassen, können mit sozial relevanten Aspekten, wie ständige Änderungswünsche von Kunden und damit verbundener aufwändiger Kundeninteraktion bzw. Auftragsbearbeitung verbunden werden. Diese Aspekte können somit in weiterer Folge die funktionalen Zustände eines Subjekts beeinflussen. Typische Beispiele sind:

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

179

• Ein Subjekt Lernender fühlt sich bei der Zusammenarbeit mit anderen Studierenden in seinem Handlungspotenzial eingeschränkt und hinterfragt die Beiträge und das Verhalten anderer Akteure (abgebildet durch Subjekt-Interaktionen) und ändert das Verhalten, um individuelle Ideen umsetzen zu können. • Ein Subjekt Facilitator hat das Bedürfnis, einen bevorstehenden Konflikt zwischen Akteuren (Subjekten) in einem Projekt anzusprechen, um so eine etwaige Eskalation, und damit den Projektabbruch zu vermeiden. Kommunikation, die auf Senden und Empfangen von Nachrichten (einschließlich Daten) basiert, kann – wie auch in funktionalen Modellen – Muster von sozio-emotionalem Informationsaustausch beinhalten. Dies kann zu einer Überschreitung institutioneller Regelungen führen, die sonst formaler Prüfung bedürfen, wie das folgende Beispiel zeigt: Ein Subjekt „Facility Manager“ möchte die Evakuierung eines Gebäudes im Falle eines Notfalls beschleunigen und bittet die Sicherheitsbeauftragte direkt um Unterstützung – er sendet dem Subject „Safety Unit“ direkt die Meldung „Clear Building“. Werden besondere Aspekte bzw. Ereignisse wie Notfälle zum Gegenstand der Betrachtung, empfiehlt sich die Berücksichtigung der System-of-Systems-Perspektive im Rahmen der Modellierung (vgl. Stary und Wachholder 2016; Stary 2017; Heininger und Stary 2021). Diese erlaubt Anforderungen zur Bearbeitung einer bestimmten Situation zunächst modellierungstechnisch bündeln, etwa die Umsetzung bestimmter Vorschriften, die alle Akteure einer Organisation in einem bestimmten Kontext betreffen. Somit kann das (Teil-) Verhalten von Systemen situationsspezifisch modelliert und adaptiert werden.

4.5.2

Entwicklungsstruktur

Ein mit sozialen Verhaltensmustern angereichertes subjektorientiertes Modell (Digital Self) erfordert, wie auch die Spezifikation digitaler Zwillinge, mehrere Schritte: • Festlegung des betroffenen Ausschnitts der beobachtbaren Realität, wie beispielsweise einen Geschäftsfall, bei dem sozio-emotionales Verhalten mit zu berücksichtigen ist • Identifikation von Akteuren oder aktiven Komponenten, die als Subjekte festgelegt an diesem Geschäftsfall oder Prozess beteiligt sind • Bestimmung der Interaktionen, an denen die aktiven Komponenten oder Subjekte beteiligt sind • Detaillierung der Nachrichten, welche die aktiven Komponenten oder Subjekte im Rahmen funktionaler oder sozio-emotionaler Interaktionen senden oder empfangen • Modellierung von sozio-emotional relevantem Verhalten von Subjekten, die Funktionen zur Bearbeitung des Geschäftsfalls und Interaktionsaktivitäten beeinflussen können

180

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.32 Generieren sozio-kognitiver Repräsentationen von Digital Selves

Abb. 4.32 zeigt die generischen Schritte, wie subjektorientierte Beschreibungskonzepte angewendet werden, um sozio-emotionale Aspekte in funktionale/kognitive digitale Repräsentationen von Digital Selves einzubetten. So kann beispielsweise das sozio-kognitive Verhalten in einem Klassenraum in einer Situation, die Notfallsmanagement erfordert, betrachtet werden. Beteiligt sind zumindest die Akteure (Subjekte) für den funktionalen Ablauf, also Lehrende, Schüler bzw. Studierende, Facility Management und Safety Unit. Beispiele für Interaktionen im Notfall sind Lehrende-Facility Management und Facility Management-Safety-Unit. Dabei sind die ausgetauschten Nachrichten Notfallsbenachrichtigung, Notfallsbestätigung, Evakuierungsanfrage und Evakuierungsplanzustellung. Der darin enthaltene Kontroll- und Informationsfluss ist wie folgt: Ein Lehrender sendet eine Notfallbenachrichtigung an das Facility Management des Gebäudebetreibers. Er erhält von der Safety Unit eine Notfallsbestätigung und den Evakuierungsplan. Dieser wird umgesetzt, vorausgesetzt, die Situation vor Ort verändert sich zwischenzeitlich nicht, etwa durch Ereignisse, welche durch das Sozialverhalten der Beteiligten oder Betroffenen bedingt sind. Das Verhalten jeder beteiligten Systemkomponente wie Facility Management und Safety Unit wird ebenfalls subjektorientiert modelliert. Zunächst führt das erkennende Subjekt, z. B. Lehrender im Klassenraum, eine interne Funktion zur Erstellung der Notfallmeldung aus. Sobald diese Funktion beendet ist, folgt die Benachrichtigung. Im Folgezustand wird eine Nachricht mit der Notfallmeldung an das Subjekt „Facility Management“ gesendet. Nachdem diese Nachricht gesendet wurde, geht das Subjekt „Lehrender“ in den Wartezustand bis zur nächsten empfangenen Nachricht. Abhängig vom sozialen Verhalten der Studierenden kann jedoch eine von der eingehenden Bestätigung unabhängige Aktion gesetzt werden. Im Falle sich ändernder Umgebungsbedingungen, z. B. die Bewegung von Studierenden in Richtung Ausgängen

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

181

anstelle des Abwartens von Unterstützung, könnte der Lehrende vor Abwarten einer Rückmeldung vom Facility Management die Studierenden nach draußen führen – dies wäre im Verhaltensdiagramm mit zu erfassen. Die Funktionen im Verhaltensdiagramm betreffen die Bearbeitung von Daten bzw. Objekten, die zur Meldung eines Notfalls erforderlich sind. So sind Daten zu erwarten, die von aktualisierten Sensorkomponenten stammen, wenn ein Klassenraum mit Internetof-Things-Komponenten ausgestattet ist und die Raumnutzung damit überwacht wird. Objekte sind Daten und/oder Anwendungen, die von internen Funktionen oder Vorgängen eines Subjekts betroffen sind und durch Dienste verarbeitet werden. Beispielsweise verwendet die Funktion zur Erstellung der Notfallsbenachrichtigung interne Daten, um die entsprechende Nachricht zeitnah vorzubereiten. Diese Benachrichtigungsdaten stellen die Payload der Notfallsbenachrichtigung an ihren Empfänger dar.

4.5.3

Sozio-emotionales Verhalten

Neben den kognitiven Verhaltensmustern kommt der Mensch-Mensch-Interaktion und damit emotional begründetem Verhalten bei sozio-kognitiven Modellen besondere Bedeutung zu. Sind mehrere Personen an einem Ort in eine bestimmte Situation involviert, so kann das (Sozial-)Verhalten dieser Personen ungeachtet ihrer primären funktionalen Rolle entscheidenden Einfluss besitzen. Im Beispiel des Klassenraums ist der Lehrende im Klassenzimmer an der Wissensvermittlung (kognitives Verhalten) beteiligt, während er auch das Facility Management in organisatorischen Fragen vor Ort repräsentiert, wie sich z. B. zu Beginn und Ende der Wissensvermittlung im Umgang mit der Räumlichkeit oder auch in Notfällen zeigt. Im Gebäude befindliche Funktionsträger, einschließlich der Facility Manager, spielen im ursprünglichen (Wissensvermittlungs-)Kontext zunächst keine aktive Rolle, erst bei entsprechender Aktivierung (durch den Lehrenden). Mensch-Mensch-Interaktionen sind wichtige Aspekte, die sowohl das Verhalten zwischen Aufgabenträgern (Rolle-zu-Rolle) als auch das Verhalten von Menschen und das (Reaktions-)Aktionsverhalten sowie wiederkehrende Verhaltensmuster in Organisationen bestimmen. Letztere resultieren aus der Tendenz der Menschen, die Reaktionen anderer auf kritische Situationen zu beobachten und ihr Verhalten entsprechend zu wählen. Zhu et al. (Zhu et al. 2020) konnten in ihrer Studie zu empirischen Verhaltensweisen mehrere Kategorien von Mensch-Mensch-Interaktionen identifizieren: Herdenverhalten (herding), Vermeideverhalten (avoiding), Gruppierung (grouping), Helfen und Konkurrieren (helping and competing), Sich-führen-lassen (leader-following), und Informationsaustausch (information sharing): • Herdenverhalten als spezifische Kategorie des Mensch-Mensch-Interaktionsverhaltens bezieht sich auf eine Person, die dem folgt, was andere tun, obwohl die wahrgenommenen Situationsinformationen etwas anderes vermuten lassen. Im Falle der Evakuierung des Klassenraums bezieht sich das Herdenverhalten beispielsweise darauf, dass eine Person, die am stärksten verstopfte Route wählt, weil diese Route die beliebteste Wahl

182

•

•

•

•

•

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

ist, anstatt alternative Routen mit weniger Menschen zu wählen. Herdenverhalten kann auftreten, wenn Menschen ein hohes Maß an Stress erfahren oder rationalisieren, soweit sie die Situation verstehen. Das Herdenverhalten wird sowohl von Umweltfaktoren beeinflusst wie beispielsweise die Anzahl der Peergruppenvertreter, Ausgänge in der Nähe, Sichtbarkeit der Umgebung, als auch von persönlichen Faktoren, wie beispielsweise der individuellen Einstellung. Vermeidungsverhalten hängt ebenfalls mit dem Ort und Umweltfaktoren zusammen. So ist beispielsweise an überfüllten Orten wie Hörsälen während der Vorlesungszeit der Grad der Unsicherheit, wie beispielsweise die Behinderung der Sicht durch Hindernisse, entscheidend, um das Verhalten anderer zu vermeiden. In Situationen mit geringer Unsicherheit, etwa wenn zur Evakuierung von Klassenräumen Ausgänge mit kürzeren Entfernungen überfüllt sind, neigt die Mehrheit der Menschen dazu, weiter weg gelegene Ausgänge zu wählen, um übermäßige Verzögerungen aufgrund von Staus zu vermeiden. Die Gruppenbildung ähnelt dem Herden- und Vermeidungsverhalten, berücksichtigt jedoch die Verbundenheit der Menschen zueinander. Während es in Massen von Fremden zu Herden- und Vermeidungsverhalten kommen kann, kann bei der Gruppenbildung eine bestimmte Form sozialer Verbundenheit festgestellt werden. Wenn beispielsweise Menschen aus derselben Peer-Gruppe stammen, wie Studienkollegen oder Klassenkameraden, neigen sie dazu, sich als Gruppe zu bewegen und aktiv nach Gruppenmitgliedern zu suchen. Helfendes und unterstützendes Verhalten hängt auch mit bereits bestehenden sozialen sowie entstehenden kollektiven Identitäten von Menschen im Umgang mit kritischen Situationen zusammen. Dadurch können Beziehungen zwischen ihnen hergestellt und durch den Austausch von Erfahrungen in einer kritischen Situation gestärkt werden. Letzteres erhöht die kollektive Identifikation und schließlich die Zusammenarbeit zwischen den Menschen. Andererseits verringert eine zunehmende Gefährdung, z. B. wenn das ursprüngliche Ereignis – ein Gegenstand fällt zu Boden – von einem Erdbeben begleitet wird, die Hilfeleistung. Konkurrierendes und egoistisches Verhalten kann auftreten, wenn Menschen ein erhöhtes Maß an Stress und den Verlust des persönlichen Freiraums erfahren. Falls beispielsweise eine Person das Bedürfnis verspürt, eine Situation zu verlassen, ohne sich um andere zu kümmern, kann dies konkurrierendem Verhalten um den Ausgang oder einen anderen Ort geschuldet sein. Die Bewältigung einer kritischen Situation für eine ganze Gruppe kann durch egoistisches Verhalten beeinträchtigt werden. Die Entscheidung über diese Art von Verhalten hängt großteils von bereits bestehenden und/oder neu entstehenden sozialen Beziehungen ab, wie sie etwa im Klassenraum gegeben sind. Leader-Following-Verhalten tritt auf, wenn eine berufliche und/oder soziale Rolle das Verhalten von Menschen beeinflusst. Personen können in kritischen Situationen die Rolle von Anführenden und Angeführten einnehmen. Die Entscheidung dafür basiert auf ihrem Wissen und ihrer Erfahrung sowie ihrer Persönlichkeit. Es kommt sehr häufig

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

183

vor, dass viele Menschen in kritischen Situationen die Rolle von Angeführten übernehmen, während es weniger wahrscheinlich ist, dass sich Menschen dafür entscheiden, in solchen Situationen zu führen. Führung wird zumeist von Personen mit Autorität übernommen, die dann die Angeführten gemäß ihrem individuellen Verständnis der kritischen Situation und der wahrgenommenen Umgebungsinformationen leiten (sollten). • Informationsaustausch ist ein Schlüsselfaktor in kritischen Situationen und ist ein essentieller Bestandteil bzw. treibender Faktor der Mensch-Mensch-Interaktion. Sobald ein kritisches Ereignis eintritt, beginnen die Menschen mit der „Jagd nach Informationen“ und unternehmen viele Anstrengungen, um mehr Informationen über die wahrgenommene Kritikalität ihrer Situation zu erhalten. Sie beginnen, Kollegen oder verantwortliche Akteure zu konsultieren, wenn sie nicht sogar einen Ad-hoc„Krisenausschuss“ bilden, um die Situation zu erörtern. Die Informationen, die sie wahrnehmen, helfen Menschen, die Optionen zu bewerten, sobald sie über ihre nächste Aktivität in einer bestimmten Situation nachdenken. Dies kann die Bewältigung kritischer Ereignisse erleichtern, aber auch den Umgang mit einer kritischen Situation für die Betroffenen erschweren. Anstatt entsprechend geeignete Maßnahmen zu ergreifen, können vermehrte Schäden bzw. Unfälle die Folge von hinderlichem bzw. zeitverschwendenen Informationsaustausch sein. Jede der erwähnten Verhaltenskategorien kann in Kombination mit anderen auftreten und zu gekoppelten Effekten führen. Beispielsweise können Folge- und Hilfsverhalten miteinander verflochten sein, wenn Anführende Hilfsverhalten zeigen, während sie Menschen anleiten, bestimmte Aktivitäten festzulegen. Dies kann die Führungsfunktion zugunsten der Erledigung der unterstützenden Tätigkeiten unterbrechen. Darüber hinaus können Personen, wenn sie in kritischen Situationen nicht in Panik geraten, erhaltene Informationen verarbeiten, die entweder von der Gruppe stammen, der sie beigetreten sind oder die sie leiten, oder aus dem Umfeld der Gruppe. Die Bewältigung kritischer Situationen kann auch weitere, zunächst nicht involvierte Rollen involvieren. Beispielsweise können Mitarbeiter von Organisationen, wie Facility Manager, sogar Ersthelfer in einer kritischen Situation sein, indem sie Menschen helfen, zu einem Ausgang zu gelangen oder ihnen den Umgang mit Notfallsausrüstung zeigen. Rollenspezifisches Verhalten beeinflusst also nicht nur das individuelle Verhalten, sondern auch Interaktionen, insbesondere bei gruppenrelevantem Verhalten.

4.5.4

Relevante Interaktionen

Mensch-Objekt-Kritische-Situation-Interaktionen spielen aufgrund der unterschiedlichen Verhaltensauslöser und -muster der beteiligten Akteure eine bedeutende Rolle. Wenn beispielsweise Facility Manager von Anfang an in den Beschaffungs-, Betriebs- und Wartungsprozess von Räumlichkeiten oder/und Inventar eingebunden sind, wird die Mensch-

184

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Kritische-Situations-Interaktion durch ihr Vorwissen und informiertes Handlungsverhalten beeinflusst. So ist oft Vertrauen in rollenspezifisches Verhalten der Auslöser zu LeaderFollowing-Mustern. Abb. 4.33 fasst die Abbildung von Interaktionstypen auf Modellkonstrukte für digitale Modellbildungen zusammen. Da wir einen kommunikationszentrierten Ansatz verfolgen, orientiert sich die Darstellung am Rollen- bzw. Aufgabenverhalten. Folglich basiert die Mensch-zu-Objekt-Interaktion auf Verhaltensentitäten, die einzelne Prozeduren darstellen, die Objekte handhaben oder mit Objekten umgehen. Da cyber-physische Komponenten in unserem Fall dedizierte Aufgaben erfüllen, z. B. die Vorverarbeitung von Sensordaten, können diese Interaktionen auch von Rolle zu Rolle, also zwischen dezidierten Aufgabenträgern einer Organisation, stattfinden. Die Mensch-zu-Mensch-Interaktion basiert traditionell auf einem Rolle-zu-RolleVerhalten. Gemäß dem subjektorientierten Modellierungsansatz stellen Subjekte Rollenabstraktionen dar, unabhängig von ihrer tatsächlichen Implementierung, und somit können Subjekte durch physische, digitale oder hybride Systeme implementiert werden. Für die Interaktion zwischen Menschen und kritischen Situationen ist ein steuerndes Subjekt erforderlich, da diese eine Ausgangsbasis erfordert, sowohl in Bezug darauf, was Akteure tun als auch welche Objekte der Umgebung in einer solchen spezifischen Situation betroffen sind. Daher betrachten wir die Mensch-Kritische-Situation-Interaktion bereits als Interaktion „zweiter Ordnung“, da sie implizit die Mensch-Objekt-KritischeSituation-Interaktion darstellt.

Abb. 4.33 Zuordnung von Interaktionskategorien zu Modellierungsfunktionen

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

4.5.5

185

Modellierungstechnische Einbettung

Um in unserem Beispiel das Unterrichtsumfeld zu erfassen, muss die Modellierung die organisatorischen Rahmenbedingungen berücksichtigen. Jeder der beteiligten Akteure und Systeme, etwa die Studienverwaltung oder das Facility Management, wird in einem Interaktionsdiagramm als Subjekt angelegt und mit einem entsprechenden Verhaltensdiagramm modelliert. Das Eintreten einer kritischen Situation wird in Message Guards Behaviorn modelliert (1) wo die Entscheidung getroffen wird, ob das Lernen im Klassenraum wie geplant fortgesetzt werden kann oder (2) dedizierte Verhaltenssequenzen zum Umgang mit der kritischen Situation ausgewählt werden sollen. Letzterer Fall entspricht der Behandlung eines komplexen Ereignisses und erfordert eine Entscheidungsfindung über Verhaltensoptionen. Der Sender der Guard/Interrupt Message ist dabei ein allgemeiner „Beobachter“ oder auch ein Warnsystem oder Sensor, was aber in jedem Fall als Interfacesubjekt, d. h. ohne spezifischeres Verhalten dargestellt werden kann. Abb. 4.34 zeigt das Eintreten eines Ereignisses aus Sicht eines Studierenden, das zu einer ersten Überprüfung führt, ob eine kritische Situation vorliegt oder nicht. Dieses Verhaltensdiagramm stellt den Umgang eines Menschen mit einer kritischen Situation dar und stellt das Steuerelement einer kritischen Situation dar. Der Message Guard wird aktiviert, sobald eine kritische Situation erkannt wird und eine spezifische Prüfung erfordert. Dies triggert gegebenenfalls das Verhalten anderer Akteure, wenn diese ebenfalls über den Eintritt durch eine Guard Message informiert werden. Mensch-zu-Objekt-Interaktionen werden in verhaltensorientierten Modellen nicht als Rolle-zu-Rolle-Interaktion dargestellt. Die eigentliche Interaktion mit einem Objekt wird als Tätigkeit im Verhaltensdiagramm beschrieben. Wenn sich Nachrichten auf Objektmanipulationen oder ortsspezifische Änderungen beziehen, dann werden im ersten Fall Daten über digitale oder physische Objekte über Nachrichten an andere Akteure (Subjekte) übermittelt die im Interaktionsdiagram dargestellt sind. Im letzteren Fall werden Bewegungen oder Manipulationen anderer Subjekte als Information gemeldet. Werden Objekte selbst übertragen ist dies natürlich auch im Interaktionsdiagramm sichtbar. Für die sozio-kognitive Modellierung gilt es aus Sicht sozialer Zusammenhänge Rahmenbedingungen zu beachten – in Übereinstimmung mit bereits evaluierten Modellsimulationen wie in (Barachini und Stary 2022b) dargestellt: So gehen wir von einer Population unbedingter Kooperierender aus. Betrachtet man die Lernenden als Population, in der Akteure alleine oder in Gruppen arbeiten können, können sie eine gewisse Fitness (d. h. Eignung zur Bewältigung einer herausfordernden Situation) erreichen, sobald sie erwartbares Wissen erreichen.

186

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.34 Eintritt in eine kritische Situation und erste Bewertung der Kritikalität (Base Verhaltensdiagram und Guard Behavior eines Studenten)

Abb. 4.35 zeigt die Aktivierung der Funktion zur Anpassung von Kooperationsverhalten. Die Anpassung umfasst die Zusammenarbeit aus unterschiedlichen Perspektiven in einer Gruppe nach den bestimmten Akteurstypen: • Emotional belastete Mitarbeiter arbeiten bedingt einem Ziel zu und kooperieren, bis ein gewisses Maß an Fitness (d. h. zur Bewältigung der der Situation) bei ihrem Gegenüber erreicht ist. • Egoisten maximieren die Fitness, indem sie nur in dem Maße tätig werden und kooperieren, wie die erwarteten Fitnesskosten dies zulassen. • Kooperative Mitarbeiter beteiligen sich bedingungslos und kooperieren in jedem Fall. Nach diesen fitnessgetriebenen Verhaltenstypen lassen sich (Re-)Aktionen in kritischen Situationen kategorisieren. So kann beispielsweise die Bereitschaft, anderen zu gefallen, bei der Zuordnung von Studierenden- und Lehrendenverhalten je nach zu erreichender Fitnessschwelle entweder emotional belasteten Kooperationspartnern oder Egoisten zugeordnet werden. Ein weiteres Beispiel ist das Befolgen normativer Regeln, wie das Abwarten von Anweisungen im Klassenraum, entweder von der Safety Unit außerhalb des Raums oder vom im Klassenraum anwesenden Lehrenden. Das Befolgen kann sich neben Regeln auf kulturelle Normen beziehen, einschließlich „ungeschriebener Gesetze“, auch um Belohnungen wie beispielsweise Lob vor der Gruppe zu erhalten.

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

187

Abb. 4.35 Anpassen des Kooperationsverhaltens basierend auf der Fitness des vorhandenen Wissens

Abb. 4.36 zeigt beispielhaft die Spezifikation des Interaktionsverhaltens von Mensch zu Mensch, wenn sich das Kooperationsverhalten der Studierenden an der Fitness orientiert. Die gepunkteten Linien zeigen die relative Reihenfolge der Aktivitäten an, da möglicherweise zusätzliche Funktionen ausgeführt werden müssen. Betrachten wir in diesem Zusammenhang zunächst nur Grundmuster, so lassen sich beispielhaft vier Kategorien gemäß der bereits oben genannten Verhaltenstypen unterscheiden: • Herding entspricht dem Beobachten durch ein Subjekt, das zur Laufzeit über alle instanziierten Studierenden-Subjekte berichtet. Sobald Verhaltensänderungen beobachtet werden können, werden sie gemeldet und von Studierenden empfangen, die das Herdenverhalten auswählen. • Das Teilen von Informationen erfordert die Konsolidierung individueller Informationen, die für diesen Fall als Funktionszustand modelliert werden. Sobald die Informationen konsolidiert wurden, können sie zur Laufzeit an alle anderen Instanzen des Studierenden-Subjekts gesendet werden. • Das Folgen löst ein Leader-Subjekt aus, etwa der Lehrende oder ein Mitglied der Peer-Gruppe, d. h. ein/e Studierende/r, bzw. ein anderer Rollenträger (z. B. Facility Manager), der zur Laufzeit des modellierten Systems angesprochen werden kann. • Helfen verpflichtet, andere darüber zu informieren, sodass sie bei Bedarf um Unterstützung ersuchen können. Es wird als Broadcast-Nachricht an instanziierte Subjekte zur Laufzeit modelliert.

188

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

• Mensch-zu-Mensch-Interaktion aus Studierendenperspektive zur Herdenbildung, zum Teilen von Informationen, Folgen eines Anführerenden und Helfen. Abb. 4.37 zeigt die Spezifikation des Mensch-zu-Mensch-Interaktionsverhaltens für Lehrende, die sich neben den Studierenden im Klassenraum im Fall einer Notsituation befinden. Neben der eigenen Anpassung des sozialen Verhaltens ist eine funktionale Interaktion mit dem Facility Manager für weitere Anweisungen in kritischen Situationen erforderlich. Im Falle einer Unterbrechung erhält der Facility Manager einen zeitnahen Bericht und übermittelt das zu befolgende Regime. Abb. 4.38 veranschaulicht zwischenmenschliche Interaktionen, die das Verhalten des Lehrenden betrifft, unter Berücksichtigung der verschiedenen Arten des Kooperationsverhaltens in Bezug auf die Fitness des verfügbaren Wissens: • Egoistisches Verhalten wird beim Ersuchen um Wiederherstellung des Zustands des Klassenraums evident, etwa durch (unmittelbares Einfordern einer) Reparatur eines beschädigten Gegenstandes, um die Kontrolle über den Lern- und Vermittlungsprozess zu behalten.

Abb. 4.36 Selektion von Verhaltensoptionen

4.5 Integration sozialer Verhaltensmuster in die Prozessmodellierung

189

• Beim Delegieren erwartet der Lehrende, dass ein anderer Rollenträger, entweder das Facility Management oder sogar ein Studierender, sich um die gesamte kritische Situation kümmert. Es kann durch nicht-kooperative Motive ausgelöst werden. • Das Evakuieren des Raums betrifft alle instanziierten Subjekte zur Laufzeit und führt zum Verlassen des Raums gemäß den Evakuierungsprinzipien der Einrichtung. In gewisser Weise entspricht dies der Übernahme von Führungsverhalten und andere dazu zu bringen zu folgen. • Helfen informiert die Studierenden im Klassenraum, in welcher Form sie Unterstützung bei der Bewältigung der kritischen Situation bekommen bzw. auch selbst die Situation bewältigen können, z. B. beim Organisieren eines Ersatzgegenstands oder beim Entfernen defekter Teile aus dem Klassenraum. Ähnlich dem Evakuierungsruf wird die Übermittlung dieser Information als Broadcast-Nachricht an instanziierte Subjekte zur Laufzeit modelliert. Falls der Lehrende durch eine Software-Komponente realisiert wird oder mit Hilfe digitaler Modelle zu sozio-emotionalem Verhalten unterstützt den Unterricht bewältigt,

Abb. 4.37 Rollenspezifische Verhalten des Lehrenden und des Gebäudemanagements in kritischen Situationen

190

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Abb. 4.38 Mensch-zu-Mensch-Interaktion aus Lehrenden-Perspektive, zur Wiederherstellung des ursprünglichen Zustands, zur Delegation weiterer Schritte, zur Evakuierung des Raums, zur Anbahnung von Hilfeleistungen

kann ein entsprechendes Subjekt Information dazu liefern, wie die Studierenden in Notsituationen reagieren werden. Es gibt in dem Fall dann also ein digitales Modell, das als Objekt dem Lehrenden direkt oder z. B. als Simulation bereitgestellt werden kann, um ihm oder ihr eine bessere Vorhersage zu ermöglichen was als nächstes passieren wird. In einem anderen Prozessmodell kann dann beschrieben werden, wie dort ein Subjekt Lehrender zu handeln hat. Er oder Sie übermittelt dann eine entsprechende Anforderungsnachricht an ein Subjekt Studierendenverhalten, welche Voraussagen zum Verhalten dieser Gruppe liefert. Basierend auf bekannten individuellen Eigenschaften der bestehenden Studierendenpopulation kann eine Einschätzung generiert werden, und der Lehrende kann entsprechend dieser eigene Verhaltensoptionen bewerten bzw. aktivieren. Egoisten werden das Facility Management gemäß ihren Vorstellungen instrumentalisieren. Bedingt sozial orientierte Lehrende werden Anreize suchen, um zu helfen, während Kooperationsbereite sofort helfen, ohne auf das Facility Management warten. Somit kann ein entsprechendes sozio-kognitives Verhaltensrepertoire bei der Modellierung geschaffen werden.

Literatur

191

Literatur Ahmed I, Jeon G, Piccialli F (2022) From artificial intelligence to explainable artificial intelligence in industry 4.0: a survey on what, how, and where. IEEE Trans Industr Inform 18(8):5031–5042 Backhauß S (2016) Code generation for UML activity diagrams in real-time systems. PhD thesis, Master’s thesis, Institute for Software Systems, Hamburg University of . . . Barachini F, Stary C (2022a). Beyond Data: Unifying Behavior Modeling. In: From Digital Twins to Digital Selves and Beyond. Springer International Publishing, Cham, S 21–33 Barachini F, Stary C (2022b). From digital twins to digital selves and beyond: engineering and social models for a trans-humanist world. Springer, Cham Batty M (2018) Digital twins. Environ Plan B: Urban Anal City Sci 45(5):817–820. http://journals. sagepub.com/doi/10.1177/2399808318796416 Bettenhausen K, Kowalewski S (2013) Cyber-physical systems: Chancen und nutzen aus sicht der automation. VDI/VDE-Gesellschaft Mess-und Automatisierungstechnik, S 9–10 Bönsch J, Elstermann M, Kimmig A, Ovtcharova J (2022) A subject-oriented reference model for digital twins. Comput Ind Eng 172(2022):108556 Börger E (2011) A Subject-Oriented Interpreter Model for S-BPM. In: Fleischmann A, Schmidt W, Stary C, Obermeier S, Börger E (Hrsg) Subjektorientiertes Prozessmanagement. Hanser-Verlag, München Boy GA (2022) Model-based human systems integration. In: Handbook of model-based systems engineering. Springer, Berlin, S 1–29 Börger E, Stärk RF (2003) Abstract state machines: a method for high-level system design and analysis. Springer, Berlin Dirndorfer M, Fischer H, Sneed S (2013) Case study on the interoperability of business process management software. In: International Conference on Subject-Oriented Business Process Management. Springer, Berlin, S 229–234 Elstermann M (2017) Proposal for using semantic technologies as a means to store and exchange subject-oriented process models. In: S-BPM ONE 2017 – Darmstadt, Germany – March 30–31 . Elstermann M (2019) Executing strategic product planning – a subject-oriented analysis and new referential process model for IT-tool support and agile execution of strategic product planning. KIT Scientific Publishing, Karlsruhe Elstermann M, Bönsch J, Kimmig A, Ovtcharova J (2021) Human-centered referential process models for ai application. In: International Conference on Human-Centered Intelligent Systems. Springer, Berlin, S 56–65 Elstermann M, Krenn F (2018) The semantic exchange standard for subject-oriented process models. In: Proceedings of the 10th International Conference on Subject-Oriented Business Process Management, S-BPM One ’18. Association for Computing Machinery, New York, NY, USA. https://doi.org/10.1145/3178248.3178257 Elstermann M, Ovtcharova J (2014) Abstract layers in PASS – a concept draft. In: Zehbold C (Hrsg) S-BPM ONE – Application Studies and Work in Progress – 6th International Conference, S-BPM ONE 2014, Eichstätt, Germany, April 22–23, 2014. Proceedings, vol. 422 of Communications in Computer and Information Science, Springer, Berlin, S 125–136 Elstermann M, Wolski A (2020) Matching execution and modeling semantics for subject-oriented process models. In: Freitag M, Kinra A, Kotzab H, Kreowski H-J, Thoben K-D (Hrsg) SubjectOriented Business Process Management: The Digital Workplace – Nucleus for Transformation, number 1278 in Communications in Computer and Information Science. Springer Fleischmann A (1994) Distributed systems – software design and implementation. Springer, Berlin

192

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Fleischmann A, Borgert S, Elstermann M, Krenn F, Singer R (2017) An overview to s-bpm oriented tool suites. In: Mühlhäuser M, Zehbold C (Hrsg) Proceedings of the 9th International Conference on Subject-oriented Business Process Management, S-BPM ONE. ACM Fleischmann A, Schmidt W, Stary C (Hrsg) (2015) S-BPM in the wild. Springer International Publishing, Cham. http://link.springer.com/10.1007/978-3-319-17542-3 Fleischmann A, Schmidt W, Stary C, Obermeier S, Börger E (2012) Subject-oriented business process management. Springer, Berlin/Heidelberg. http://link.springer.com/10.1007/978-3-64232392-8 Geiger M, Harrer S, Lenhard J, Wirtz G (2018) Bpmn 2.0: The state of support and implementation. Futur Gener Comput Syst 80:250–262 Gunning D, Stefik M, Choi J, Miller T, Stumpf S, Yang G (2019) Xai—explainable artificial intelligence. Sci Robot 4(37):eaay7120 Hartmann D, Van der Auweraer H (2021) Digital Twins. In: Cruz M, Parés C, Quintela P (Hrsg) Progress in industrial mathematics: success stories. Springer International Publishing, Cham, S 3–17 Heindl W, Stary C (2022) Structured Development of Digital Twins—A Cross-Domain Analysis towards a Unified Approach. Processes 10(8):1490. https://www.mdpi.com/2227-9717/10/8/ 1490 Heininger R, Stary C (2021) Capturing autonomy in its multiple facets: a digital twin approach. In: Proceedings of the 2021 ACM Workshop on Secure and Trustworthy Cyber-Physical Systems, Virtual Event, Heininger, S 3–12 Herwig C, Pörtner R, Möller J (2021) Digital twins. Springer International Publishing, Cham I2PM (2022) Standard-pass-ontology. https://github.com/I2PM/Standard-PASS-Ontology/releases Ihpiv (2022) List of unified modeling language tools. https://en.wikipedia.org/wiki/List_of_Unified_ Modeling_Language_tools. Zugegriffen am 24.07.2022 Javaid M, Haleem A, Singh RP, Rab S, Suman R (2021) Internet of behaviours (iob) and its role in customer services. Sens Int 2:100–122 Javaid M, Haleem A, Singh R, Suman R (2022) Artificial intelligence applications for industry 4.0: a literature-based study. J Ind Integr Manag 7(1):83–111 Kopp O (2005) Abbildung von EPKs nach BPEL anhand des Prozessmodellierungswerkzeugs Nautilus, PhD thesis, Stuttgart, Universität Stuttgart, Diplomarbeit Kossak F et al (2014) A Rigouros semantics for BPMN 2.0 process diagrams. Springer, Berlin Laue R, Mayr HC, Thalheim B (2022) 100 years of graphical business process modelling: Guest editorial. Enterprise Model Inf Syst Architectures (EMISAJ) 17:3–1 Lu Y, Liu C, Kevin I, Wang K, Huang H, Xu X (2020) Digital twin-driven smart manufacturing: Connotation, reference model, applications and research issues. Robot Comput Integr Manuf 61:101837 McGuinness D, Van Harmelen F et al (2004) Owl web ontology language overview. W3C Recommendation 10(10):2004 Mehdiyev N, Fettke P (2021) Explainable artificial intelligence for process mining: a general overview and application of a novel local explanation approach for predictive process monitoring. In: Interpretable Artificial Intelligence: A Perspective of Granular Computing. Springer, Cham S 1–28 Mendling J, Nüttgens M (2004) Transformation of aris markup language to epml. EPK 2004 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings of GIWorkshops und Arbeitskreistreffens (Luxemburg, 6. Oktober 2004) 2004:27–38 Myers BA (1986) Visual programming, programming by example, and program visualization: a taxonomy. ACM Sigchi Bull 17(4):59–66

Literatur

193

Neubauer M, Stary C (Hrsg) (2017) S-BPM in the production industry. Springer International Publishing, Cham. http://link.springer.com/10.1007/978-3-319-48466-2 Org W (2012) The web ontology language. https://www.w3.org/TR/owl2-overview. Zugegriffen am 14.01.2020 Pery A, Rafiei M, Simon M, van der Aalst W (2022) Trustworthy artificial intelligence and process mining: challenges and opportunities. In: International Conference on Process Mining. Springer, Berlin, S 395–407 Pylianidis C, Osinga S, Athanasiadis IN (2021) Introducing digital twins to agriculture. Comput Electron Agric 184:105942. https://linkinghub.elsevier.com/retrieve/pii/S0168169920331471 Rasheed A, San O, Kvamsdal T (2020) Digital twin: values, challenges and enablers from a modeling perspective. IEEE Access 8:21980–22012 Rosen R, von Wichert G, Lo G, Bettenhausen KD (2015) About the importance of autonomy and digital twins for the future of manufacturing. IFAC-PapersOnLine 48(3):567–572 https:// linkinghub.elsevier.com/retrieve/pii/S2405896315003808 Rudskoy A, Ilin I, Prokhorov A (2021) Digital twins in the intelligent transport systems. Transport Res Proced. 54:927–935. https://linkinghub.elsevier.com/retrieve/pii/S235214652100332X Scheer A (1998) ARIS – Modellierungsmethoden, Metamodelle, Anwendungen, 3., völlig neubearb. u. erw. Aufl. Springer, Berlin Schuh G, Anderl R, Dumitrescu R, Krüger A, ten Hompel M (2020) Industrie 4.0 maturity index: managing the digital transformation of companies: Update 2020 Sobhrajan P, Nikam SY (2014) Comparative study of abstraction in cyber physical system. Int J Comput Sci Inf Technol 5(1):466–469 Stary C (2017) System-of-systems design thinking on behavior. Systems 5(1):3 Stary C (2020) The internet-of-behavior as organizational transformation space with choreographic intelligence. In: International Conference on Subject-Oriented Business Process Management. Springer, Berlin, S 113–132 Stary C (2021) Digital twin generation: Re-conceptualizing agent systems for behavior-centered cyber-physical system development. Sensors 21(4):1096. https://www.mdpi.com/1424-8220/21/ 4/1096 Stary C, Elstermann M, Fleischmann A, Schmidt W (2022) Behavior-centered digital-twin design for dynamic cyber-physical system development. Complex Sys Inf Model Q 30:31–52 Stary C, Wachholder D (2016) System-of-systems support – a bigraph approach to interoperability and emergent behavior. Data Knowl Eng 105:155–172 Van Der Aalst W (2016) Process mining: data science in action, Bd. 2. Springer, Berlin Veit F, Geyer-Klingeberg J, Madrzak J, Haug M, Thomson J (2017) The proactive insights engine: Process mining meets machine learning and artificial intelligence. BPM (Demos) Verein Deutscher Ingenieure e.V. and VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (2014) Industrie 4.0: Gegenstände, entitäten, komponenten: Statusreport Voigt I, Inojosa H, Dillenseger A, Haase R, Akgün K, Ziemssen T (2021) Digital twins for multiple sclerosis. Front Immunol 12:669811. https://www.frontiersin.org/articles/10.3389/fimmu.2021. 669811/full Wankhede VA, Vinodh S (2021a) Analysis of barriers of cyber-physical system adoption in small and medium enterprises using interpretive ranking process. Int J Qual Reliab Manag (ahead-of-print). https://www.emerald.com/insight/content/doi/10.1108/IJQRM-06-2021-0174/full/html Wankhede VA, Vinodh S (2021b) Analysis of Industry 4.0 challenges using best worst method: a case study. Comput Ind Eng 159:107487. https://linkinghub.elsevier.com/retrieve/pii/ S0360835221003910

194

4 Gegenwärtige Herausforderungen im Geschftsprozessmanagement

Wolski A, Borgert S, Heuser L (2019) A coreasm based reference implementation for subjectoriented business process management executionsemantics. In: Betz MLS, Elstermann M (Hrsg) Proceedings of S-BPM ONE 2019, Virtual Event, Heininger, S-BPM ONE. ACM Yang S, Boev N, Haefner B, Lanza G (2018) Method for developing an implementation strategy of cyber-physical production systems for small and medium-sized enterprises in China. Proced CIRP 76:48–52. https://linkinghub.elsevier.com/retrieve/pii/S2212827118300416 Zhu R, Lin J, Becerik-Gerber B, Li N (2020) Human-building-emergency interactions and their impact on emergency response performance: A review of the state of the art. Saf Sci 127:104691

5

Vorgehensweise von der Modellbildung zur Digitalisierung

5.1

Einordnung in den Gesamtzusammenhang

Die vorangegangenen Kapitel haben gezeigt, dass das Geschehen in Organisationen (Unternehmen, Verwaltungen etc.) auf Modellen verschiedener Disziplinen basiert. Geschäftsmodelle, Unternehmensarchitekturen mit Modellen für Leistungen (Produkte und Services), Aufbauorganisation, Prozesse, Daten und IT-Infrastruktur beschreiben, was ein Unternehmen tut, wie es dies tut, in welchen Austauschbeziehungen mit Partnern es steht, welche technische Infrastruktur es besitzt usw. Im Zuge der Digitalisierung sind die mithilfe von Modellierungssprachen fachlich gestalteten betrieblichen Vorgänge wirtschaftlich mit Informations- und Kommunikationstechnik abzubilden. Inkrementellen Verbesserungen bestehender Prozesse und grundlegenden Prozessinnovationen liegen kreative Gestaltungsleistungen zugrunde, die von den fachlichen Modellen zu ausführbaren Systemen führen sollen. Deshalb beschäftigt sich dieses Kapitel zunächst mit typischen Aktivitäten des Geschäftsprozessmanagements, von der Analyse und Modellierung über Validierung, Optimierung und Implementierung bis zum laufenden Betrieb und Monitoring. Mit Design Thinking wird dann ein methodischer Ansatz beleuchtet, um kreativ Neuartiges hervorzubringen und komplexe Probleme zu lösen, ehe beide Konzepte miteinander in Beziehung gesetzt werden.

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_5

195

196

5 Vorgehensweise von der Modellbildung zur Digitalisierung

5.2

Aktivitätsbündel im Geschäftsprozessmanagement

5.2.1

Überblick

In Abschn. 1.8 haben wir bereits angesprochen, dass die Gestaltung von Geschäftsprozessen bis hin zu ihrer Ausführung als Instanzen bei der Abwicklung konkreter Geschäftsvorfälle („operatives Geschäft“) selbst einen Prozess darstellt. Dieser wird häufig als Geschäftsprozessmanagementzyklus mit Phasen wie Strategie, Entwurf, Implementierung und Controlling verstanden (Allweyer 2005). In der Praxis sind die Teilaktivitäten aber oft nicht klar voneinander abzugrenzen. Wir sehen diese deshalb weniger als Kreis mit sequenzieller Abfolge, sondern eher miteinander vernetzt und verwoben, wie es die Wabenstruktur in Abb. 5.1 andeuten soll. Die Darstellung zeigt außerdem, dass wir die Aufgaben etwas stärker differenzieren und als Aktivitätsbündel Analyse und Modellierung, Validierung, Optimierung, Organisatorische Implementierung, IT-Implementierung sowie Betrieb und Monitoring identifizieren. Obwohl die übliche Darstellung als Zyklus suggeriert, dass bei Prozessmanagementvorhaben alle Aktivitätsbündel als Sequenz durchlaufen werden, hängen deren Auswahl und Reihenfolge von der konkreten Situation, z. B. vom Reifegrad eines Prozesses ab. Die Abschn. 5.2.2 bis 5.2.7 erläutern die Aktivitäten anhand eines Beispielprozesses. Dabei werden die Schritte zunächst komplett und auch in der angegebenen Reihenfolge durchlaufen. Ein solches Szenario ist etwa bei der erstmaligen Gestaltung oder einer kompletten Reorganisation eines Prozesses realistisch. Anschließend diskutieren wir in Abschn. 5.2.8 mehrere Szenarien für Verbesserungen, die sich aus den Erfahrungen im dem laufenden Betrieb der ursprünglich gestalteten Prozessumgebung ableiten lassen.

Org. Implemenerung

Validierung

Analyse & Modellierung

Opmierung

Betrieb und Monitoring ITImplemenerung

Situave Abfolgen und Iteraonen

Abb. 5.1 Aktivitätsbündel im Geschäftsprozessmanagement

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

197

Sie verdeutlichen die situativ unterschiedlichen Pfade durch die Aktivitätsbündel bei der Weiterentwicklung des Prozesses.

5.2.2

Analyse und Modellierung

Die Analyse dient der Erhebung von Informationen darüber, warum ein Prozess existiert bzw. implementiert werden soll, welche Ziele eine Organisation mit ihm im Rahmen ihrer Strategie verfolgt, und wie in ihm aktuell gearbeitet wird. Ziele sind die Dokumentation und die Gewinnung von Anhaltspunkten für Verbesserungen. Die Modellierung verwendet u. a. die Ergebnisse der Analyse und befasst sich mit der Gestaltung der zukünftigen Arbeitsweise, also mit Prozessveränderungen und -innovationen. Wenn dazu weitere Information nötig ist, wechseln die Beteiligten wieder in den Analysemodus um diese zu erheben, und agieren danach wieder gestaltend. Analyse und Modellierung lassen sich deshalb nicht scharf voneinander abgrenzen. Auch Validierung und Optimierung finden in der Regel bereits hier statt, wenn die Beteiligten das Modell iterativ nach bestem Wissen und Gewissen und unter Berücksichtigung von in der Analyse erkannten Schwachstellen entwickeln und dabei Lösungsmöglichkeiten probieren und diskutieren. Neben der Betrachtung von Rahmenbedingungen wie strategischer Bedeutung, Zielen und Risiken geht es bei Analyse und Modellierung im Wesentlichen darum zu analysieren bzw. zu spezifizieren (vgl. Abschn. 1.3) • • • •

welche Handelnden (z. B. Menschen, Maschinen), welche Aktivitäten, nach welchen Geschäftsregeln (Business Rules), an welchen Geschäftsobjekten (z. B. an bestimmte Träger gebundene Informationen, physische Gegenstände) • mit welchen Hilfsmitteln (z. B. IT-Systeme) ausführen und • in welcher Weise sie dabei interagieren, um die gewünschten Prozessziele und -ergebnisse zu erreichen. Zur Entwicklung von Prozessmodellen auf Basis dieser Erkenntnisse bedient man sich der in Kap. 3 vorgestellten Modellierungssprachen mit den dazugehörigen grafischen Notationen. Bei der Analyse und Modellierung wird meist auch bereits eine wesentliche Voraussetzung für das operative Prozesscontrolling in der Betriebsphase geschaffen. Neben den bereits genannten Prozessattributen werden dafür Leistungsparameter (Kennzahlen), insbesondere Process Performance Indicators (PPIs), definiert, in einem Messgrößensystem systematisiert und mit Zielwerten versehen (vgl. Schmelzer und Sesselmann 2013, S. 265 ff.). Typische Beispiele für PPIs sind Durchlaufzeit, Ausbringungsmenge pro Zeiteinheit, Fehlerrate, Kundenzufriedenheit etc. Die PPIs und die dafür geplanten Soll-Werte bilden die Basis für das Geschäftsprozessmonitoring, also die operative Prozesskontrolle während der Ausführung (vgl. Abschn. 5.2.7).

198

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Analyse und Modellierung im Fallbeispiel Als Fallbeispiel verwenden wir den stark vereinfacht dargestellten Vorgang der Kreditantragsbearbeitung bei einer Bank. Dort gehen Anträge von Interessenten auf Gewährung eines Immobiliendarlehens ein. Vor der Erstellung eines Angebots prüfen Sachbearbeiter die Bonität des jeweiligen Kunden und die Werthaltigkeit der zu beleihenden Immobilie. Ist das Ergebnis beider Prüfungen positiv, fertigt der Sachbearbeiter ein Angebot an mit Daten wie Darlehenssumme, Zins- und Tilgungssatz und Laufzeit. Beträgt der Darlehensbetrag unter 200.000 e unterschreibt er das Angebot und schickt es dem Kunden. Im anderen Fall muss er erst noch die Zustimmung seiner Abteilungsleitung und bei mehr als 500.000 e die des Vorstands einholen. Ergeben sich aus der Bonitätsprüfung oder der Objektprüfung Anhaltspunkte für Risiken, nimmt ein Sachbearbeiter Kontakt mit dem Interessenten auf, um die weitere Vorgehensweise, z. B. eine Verminderung der Darlehenssumme, abzustimmen. Im Rahmen einer Analyse des Prozesses wurden diese Informationen erhoben und strukturiert (vgl. Abb. 5.2). Im vorliegenden Fall verwenden wir die in Abschn. 3.6 beschriebene Modellierungssprache PASS von S-BPM zur Darstellung des Prozesses, da dieser in einer stark interaktionsorientierten Beschreibung vorliegt. Grundsätzlich wäre die Abbildung mit

Abb. 5.2 Merkmale des Beispielprozesses und dafür ermittelte Information

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

199

jeder anderen Modellierungssprache, die die Abbildung von Verantwortlichkeiten erlaubt (etwa eEPK oder BPMN) ebenso möglich. Zusammen mit weiteren Informationen dienten diese Angaben als Basis für die Modellierung des Vorgangs. Die Abb. 5.3 bis 5.5 zeigen einen Auszug des zugehörigen Prozessmodells unter Verwendung der Modellierungssprache von S-BPM. Abb. 5.3 stellt die involvierten Subjekte (Handelnde) und die im Prozessablauf ausgetauschten Nachrichten im Subjektinteraktionsdiagramm (SID) dar. Die Kommunikation beginnt mit der Nachricht „Kreditanfrage“, die das Subjekt „Interessent“ an die „Sachbearbeitung Immobilienanfrage“ schickt und von dort die Nachrichten „Angebot“ oder „Ablehnung“ erhalten kann. Gemäß den Anforderungen im Prozess tauschen die weiteren Subjekte die abgebildeten Nachrichten aus. Die Kommunikationsstruktur (Subjektinteraktionsdiagramm, SID) enthält noch keine Reihenfolge, in der die jeweiligen Nachrichten ausgetauscht werden. Diese wird im Verhalten der Subjekte beschrieben. Die Abb. 5.4 und 5.5 zeigen das Verhalten des Subjekts „Interessent“ und auszugsweise das Verhalten des Subjekts „Sachbearbeitung Immobilienanfrage“. Abb. 5.4 zeigt das Verhalten des Subjekts „Interessent“. Im Startzustand (markiert durch ein Dreieck im Kreis) wird eine Kreditanfrage formuliert. In der Regel geschieht

S

• Kreditanfrage

S

• Prüfanfrage

S

• Prüfanfrage

S

Abteilungsleitung

Sachbearbeitung-

Vorstand

Interessent • Angebot • Ablehnung

Immobilienanfrage

• Genehmigt • Abgelehnt

ImmobilienKredit

• Genehmigt • Abgelehnt

Abb. 5.3 Kommunikationsstruktur (SID) der Handelnden im Prozess „Kreditanfrage“ D

Genehmigung erhalten From: SachbearbeitungImmobilienanfrage Msg: Angebot D

Kreditanfrage formulieren

Kreditanfrage erstellt

S

Kreditanfrage senden

To: Sachbearbeitung Immobilienanfrage Msg: Kreditanfrage

R

Auf Antwort warten From: SachbearbeitungImmobilienanfrage Msg: Ablehnung D

Abgelehnte Kreditanfrage

Abb. 5.4 Verhalten des Subjekts „Interessent“

200

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Abb. 5.5 Verhalten des Subjekts „Sachbearbeitung Immobilienanfrage“

dies durch das Ausfüllen eines entsprechenden Formulars. Dessen Inhalte wären Bestandteil der Spezifikation des Geschäftsobjekts „Kreditanfrage“. Nachdem die Kreditanfrage erstellt wurde, wird diese an das Subjekt „Sachbearbeitung Immobilienanfrage“ gesendet. Danach wird auf eine Antwort von diesem Subjekt gewartet. Diese kann entweder die Nachricht „Angebot“ oder „Ablehnung“ sein. In beiden Fällen ist das Subjektverhalten durch das Erreichen der jeweiligen Endzustände beendet, die als solche durch kleine schwarze Quadrate gekennzeichnet sind. In den Kreisen der Sprachsymbole ist jeweils die Art des Zustands zu sehen („D“ (Do) für Funktion, „S“ (Send) für Senden, „R“ (Receive) für Empfangen). Das Diagramm 5.5 zeigt einen Auszug der Verhaltensbeschreibung des Subjekts „Sachbearbeitung Immobilienanfrage“. Der Ausschnitt zeigt nur den Pfad für den positiven Fall. Im Startzustand (markiert mit Dreieck im Kreis) empfängt das Subjekt die Nachricht „Kreditanfrage“ vom Subjekt „Interessent“. Damit erhält das Subjekt das ausgefüllte Formular (Geschäftsobjekt) mit den Daten der Kreditanfrage. Im nächsten Zustand wird geprüft, ob diese Daten vollständig sind. Ist dies nicht der Fall wird eine entsprechende Rückfrage an das Subjekt „Interessent“ gesendet. Dieser Zweig ist in der Verhaltensbeschreibung nicht weiter spezifiziert, die Interaktion auch noch nicht im SID und im Verhaltensdiagramm des Interessenten berücksichtigt. Sind die Angaben vollständig wird die Kreditwürdigkeit des Interessenten geprüft. Bei positivem Ergebnis wird ein Angebot erstellt. Liegt der gewünschte Kredit unter 200.000 e wird die Nachricht „Angebot“ an das Subjekt „Interessent“ gesendet. Bei negativem Ergebnis der Kreditwürdigkeitsprüfung erhält der Interessent die Nachricht „Ablehnung“ (dieser Pfad ist im Verhalten nicht ausspezifiziert). Die nicht abgebildeten Verhaltensspezifikationen der Subjekte „Abteilungsleitung Immobilienkredit“ und „Vorstand“ sind analog zu beschreiben. Diese Subjekte würden in den Prozess involviert werden, wenn die gewünschte Kreditsumme 200.000 bzw. 500.000 e übersteigt. Diese Fälle sind in Abb. 5.5 nicht ausmodelliert (hierfür wären zusätzliche Zweige nach dem Zustand „Freigabe notwendig“).

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

5.2.3

201

Validierung

Unter Validierung verstehen wir im BPM-Kontext die Überprüfung, ob der gestaltete Prozess den vom (externen) Kunden und Prozesseigner erwarteten Output beispielsweise in Form eines Service oder Produkts erzeugt. Diese Frage nach der Effektivität bezieht sich auch schon auf die Ergebnisse von Teilschritten, also Prozessbeteiligte der eigenen Organisation als Kunden. So gilt es beispielsweise zu evaluieren, ob ein vorgelagerter Prozessschritt alle Informationen liefert, die ein Bearbeiter bei seiner Teilaufgabe für eine Entscheidung (z. B. Genehmigung) benötigt. Wir haben bereits angesprochen, dass ein Modell schon während seiner schrittweisen Entwicklung immer wieder in Teilen der Validierung unterzogen wird. Objekt der Validierung ist darüber hinaus das komplett fertiggestellte Prozessmodell, dessen Effektivität sichergestellt sein sollte, ehe es informationstechnisch umgesetzt wird (vgl. Abschn. 5.2.6). Sonst werden Fehler erst spät entdeckt und verursachen entsprechend hohe Kosten für ihre Beseitigung. Validierung im Fallbeispiel Das Prozessmodell für den Beispielvorgang wurde während seiner Entwicklung und abschließend validiert. Dabei wurde zum Beispiel zunächst festgestellt, dass im ursprünglichen Kreditantrag kein Feld für das Beschäftigungsverhältnis des Antragstellers vorgesehen war und somit eine wichtige Angabe zur Risikobeurteilung fehlt. Dies führte zur Erweiterung des Geschäftsobjektes und zu einem positiven Validierungsergebnis bei der entsprechenden Iteration.

5.2.4

Optimierung

Während die Validierung die Sicherstellung der Effektivität von Geschäftsprozessen zum Ziel hat, geht es bei der Optimierung um die Effizienz. Prozesseffizienz lässt sich fassen über Prozessattribute zur Ressourcenbeanspruchung wie Dauer und Kosten. Optimierung bedeutet, eine im Hinblick auf solche Prozessparameter optimale Gestaltung eines Prozesses zu finden. Wesentliche Ansatzpunkte sind Verbesserungen der ablauforganisatorischen und aufbauorganisatorischen Gestaltung sowie der IT-Unterstützung. Die Optimierung ist demnach strenggenommen kein eigenständiges Aktivitätsbündel, sondern bedient sich der Modellierung, der organisatorischen Implementierung und der IT-Implementierung (vgl. die Abschn. 5.2.2, 5.2.5 und 5.2.6). Eine bekannte Methode für den Vergleich von Alternativen im Ablauf oder beim Ressourceneinsatz ist die Simulation. Mit ihr lassen sich für eine größere Menge von Prozessinstanzen (Aufträge, Fertigungsstücke etc.) quantitative Aussagen über die Entwicklung von Prozessparametern gewinnen. Die Simulation ermöglicht die Bewertung eines Prozessmodells mit einer bestimmten Kombination von Parametern. Dies können deterministische oder auch stochastische, durch Wahrscheinlichkeitsverteilungen

202

5 Vorgehensweise von der Modellbildung zur Digitalisierung

beschriebene Größen sein. Durch Parameteränderungen und alternative Prozessgestaltungen können verschiedene Gestaltungsoptionen in ihrem Verhalten analysiert werden. Damit lassen sich Erkenntnisse über Engpässe bzw. Ineffizienzen und die Sensitivität von Parametern gewinnen. Der Aufwand für die Erweiterung eines Prozessmodells und für die Beschaffung notwendiger Informationen, um Simulationen durchführen zu können, kann beträchtlich sein. Eine Schwierigkeit bei der Optimierung besteht darin, dass die relevanten Attribute oft interdependent und einander gegenläufig sind. So kann es sein, dass eine Prozessalternative relativ zu einer anderen zwar eine geringere Durchlaufzeit, dafür aber höhere Kosten aufweist. Die Entscheidung für eine Alternative hängt damit auch von der Priorität der Prozessziele ab. Optimierung im Fallbeispiel Das Modell konnte bereits bei seiner Entstehung optimiert werden durch die Parallelisierung der zunächst sequenziell geplanten Schritte zur Prüfung der Kundenbonität und der Werthaltigkeit der Immobilie.

5.2.5

Organisatorische Implementierung

Validierte Prozesse müssen für den Produktivbetrieb in die bestehende und ggf. neu zu gestaltende organisatorische Umgebung eingebettet werden. Dies erfordert i. d. R. eine Anpassung der sie umgebenden Ablauf- und Aufbauorganisation. Ein einzelner Prozess ist meist Teil einer gesamten Wertschöpfungsumgebung (Wertschöpfungskette, Wertschöpfungsnetz), in die er sich nahtlos einfügen muss. Im Hinblick auf die ablauforganisatorische Integration in die Prozesslandkarte sind deshalb insbesondere die Schnittstellen mit anderen Prozessen zu betrachten. Dies kann dazu führen, dass an Schnittstellen eines vor- oder nachgelagerten Prozesses Änderungen durchzuführen sind. Solche Sachverhalte sind im Regelfall bereits in den vorgelagerten Aktivitätsbündeln berücksichtigt. Bei der Implementierung darf es deshalb letztlich nur noch um die zeitliche Synchronisation der Produktivsetzung gehen. Damit ist gemeint, dass Prozesse, die über Schnittstellen verbunden sind, gleichzeitig erneut produktiv gesetzt werden müssen, wenn sich an einer Schnittstelle eine Veränderung ergeben hat, die auch beim Partnerprozess Modifikationen nötig gemacht hat. Die aufbauorganisatorische Einbettung umfasst die Zuordnung von konkreten Handlungsträgern, also letztlich Menschen als Stellen- oder Rolleninhaber, zu den im Modell abstrakt spezifizierten Akteuren. Herausforderung ist dabei u. a. die Berücksichtigung des organisatorischen Kontexts beim Einsatz von Workflow Engines. Diese müssen etwa zur Laufzeit dynamische Vertreterregelungen ebenso auflösen können, wie die Tatsache, dass Personen im selben Prozess verschiedene Rollen bekleiden können. Beispielsweise kann eine vorgesetzte Person im Urlaubsantragsprozess der Genehmiger von Urlaubsanträgen

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

203

der eigenen Mitarbeiterinnen und Mitarbeiter sein, selbst aber auch Antragsteller für den eigenen Urlaub sein, den wiederum der eigene Vorgesetzte genehmigen muss. Für die korrekte Steuerung einer Instanz durch die Bearbeitungsstellen und -schritte muss die Software also Organisationswissen besitzen. Bei der organisatorischen Einbettung sind weitere qualitative und quantitative Aspekte zu berücksichtigen. So ist darauf zu achten, dass die Mitarbeiterinnen und Mitarbeiter die für die Ausführung des modellierten Verhaltens nötigen Qualifikationen (Skills) besitzen oder durch Schulungen erwerben können. Adäquate Qualifikation ist nicht nur Voraussetzung für eine erfolgreiche Arbeit im aktuell gültigen Prozess, sondern fördert auch Impulse für Verbesserungen seitens der Prozessbeteiligten. Die Anzahl der Personen, die den abstrakten Akteuren im Modell zugeordnet werden, beeinflusst die Kapazität für die Bearbeitung von Prozessinstanzen und wirkt sich damit auf Parameter wie die Durchlaufzeit aus. Organisatorische Implementierung im Fallbeispiel Den identifizierten und modellierten Rollen wurde die in Spalte 2 in Abb. 5.6 aufgeführte Zahl von Mitarbeiterinnen und Mitarbeitern zugeordnet, welche die Rolle aufgrund ihrer Qualifikation prinzipiell besetzen können. Die dritte Spalte enthält die tatsächlich eingesetzte Kapazität (kurzfristige Ausfälle z. B. wegen Krankheit sind nicht berücksichtigt). Die Abteilungsleitungen für Immobilien- und Konsumentenkredite vertreten sich gegenseitig sowohl in disziplinarischen als auch in fachlichen Angelegenheiten. Dies gilt analog für die Vorstände.

5.2.6

IT-Implementierung

Die meisten Prozesse sind ohne IT-Unterstützung nicht wirtschaftlich auszuführen. Insbesondere wenn ein hoher Automatisierungsgrad eines Ablaufes angestrebt wird, erlangt die

Abb. 5.6 Potenzielle und konkrete Besetzung von Rollen

204

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Qualität der Abbildung in der IT hohe Bedeutung. Aber auch oder gerade an Stellen, wo der menschliche Bearbeiter involviert ist (z. B. Eingaben tätigen, Entscheidungen treffen), muss viel Wert auf die bedarfsgerechte Gestaltung der IT-Systeme gelegt werden. Die IT-bezogene Implementierung eines Prozesses bedeutet, ihn als IT-gestützten Workflow unter Integration einer geeigneten Benutzeroberfläche, der Ablauflogik und der beteiligten IT-Systeme abzubilden. Dazu gilt es zunächst, die mehr oder weniger formale Modellbeschreibung (vgl. Kap. 3) in eine von einer Workflow Engine interpretierbare Sprache, d. h. ein ablauffähiges Programm zu überführen. Damit kann die Engine die Abarbeitung einer Prozessinstanz zur Laufzeit gemäß dem Modell steuern. Für die Erledigung einzelner Teilaufgaben bei der Abarbeitung sind meist eine ganze Reihe von Softwareapplikationen und -Services in den Ablauf zu integrieren. Typische Beispiele sind ERP-Transaktionen und Dokumenten- und Content-Management-Systeme. Ausgiebige Tests der implementierten Lösungen müssen die Qualität der Prozessunterstützung durch IT sichern. IT-Implementierung im Fallbeispiel Abb. 5.7 zeigt die wesentlichen Elemente der IT-Umgebung, welche zur Unterstützung des Prozesses und seiner Teilschritte aufgebaut wurde, zusammen mit ihren wichtigsten prozessrelevanten Funktionen.

Abb. 5.7 Realisierte IT-Umgebung

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

5.2.7

205

Betrieb und Monitoring

Implementierte Prozesse gehen nach der Abnahme in den Echtbetrieb (Going Live). Dies bedeutet, dass die Prozessbeteiligten sie in der aufgebauten organisatorischen und informationstechnischen Umgebung im Tagesgeschäft in Form von Instanzen ausführen. Für die Gewinnung von Information für das bewusste Management der Prozesse ist die Beobachtung ihres Verhaltens im laufenden Betrieb nötig. Dieses Monitoring nimmt Messdaten auf und berechnet daraus Ist-Werte für die bei der Analyse und Modellierung definierten Process Performance Indicators (PPIs). Ein sofortiger Vergleich mit definierten Soll-Größen führt bei Abweichungen zu Eskalationen entlang der Managementhierarchie und ggf. zu kurzfristigen Maßnahmen. Mittel- und längerfristige Auswertungen lassen strukturelle Verbesserungsmöglichkeiten erkennen. Die Analyse des Prozessverhaltens und möglicher Abweichungen lässt Rückschlüsse auf Ursachen zu und löst Rückkopplungen in andere Aktivitätsbündel aus. Betrieb und Monitoring im Fallbeispiel Seit Freigabe des Prozesses arbeitet die Bank Kreditanträge der Interessenten in der beschriebenen Form und Umgebung ab. Das Monitoring für das vergangene Quartal ergab folgende durchschnittliche Zahlen: • • • •

Interessenten haben 50 Anträge pro Woche gestellt Die Bank hat 20 % davon abgelehnt, die Hälfte davon wegen mangelnder Bonität Zu den restlichen Anträgen erhielt der Interessent ein Angebot innerhalb von 4 Tagen In 30 Prozent der Fälle hat der Interessent das Angebot angenommen und einen Vertrag abgeschlossen

Da Wettbewerber mit sehr kurzen Bearbeitungszeiten werben, nimmt die Bank an, dass die Dauer von 4 Tagen bis zum Erhalt eines Angebots bei sonst vergleichbaren Konditionen einer der Gründe ist, warum Kunden keinen Vertrag abschließen. Sie weicht auch signifikant vom vorab formulierten Ziel von 3 Tagen ab.

5.2.8

Verbesserungsszenarien

Die folgenden Szenarien zeigen, wie mit weiterführenden Analysen der MonitoringErgebnisse nach Ursachen für die lange Durchlaufzeit geforscht wird, und für Verbesserungsmaßnahmen (Optimierung) in passende Aktivitätsbündel verzweigt wird. Davon hängt im Einzelfall der weitere Pfad durch die Aktivitätsbündel ab, also welche Tätigkeiten anschließend nötig sind, ehe der umgestaltete Prozess produktiv gesetzt werden kann. Die Ausführungen beschränken sich zur Vereinfachung jeweils auf eine Maßnahme. In der Realität wird man meist mehrere Optimierungsmöglichkeiten parallel verfolgen.

206

5 Vorgehensweise von der Modellbildung zur Digitalisierung

5.2.8.1 Verbesserungsszenario 1 Die Betrachtung der Häufigkeitsverteilung für den Anfall der Kreditanträge hat ergeben, dass montags 25, dienstags 15, mittwochs 6 und donnerstags und freitags je 2 Anträge vorliegen. Dies könnte daran liegen, dass Interessenten am Wochenende vermehrt Immobilien besichtigen, Kaufentscheidungen treffen und die Finanzierung angehen. Die Auswertung der Liegezeit bis zur Bearbeitung durch die Sachbearbeitung Immobilienkredit zeigt, dass dort zu Wochenbeginn wegen des hohen Aufkommens ein Engpass vorliegt. Bei der derzeit vorgehaltenen Kapazität von 5 Sachbearbeitern in Vollzeit beträgt die durchschnittliche Liegezeit 2 Tage. Um diese und damit die Durchlaufzeit zu verringern könnte im Rahmen der organisatorischen Implementierung an den Montagen und Dienstagen zusätzliche Sachbearbeitungskapazität, etwa in Form verfügbarer Halbtageskräfte eingesetzt werden. In diesem Fall ändert sich der Prozess nicht, es sind keine weiteren Aktivitäten nötig. 5.2.8.2 Verbesserungsszenario 2 Eine genauere Analyse hat ergeben, dass die hohe durchschnittliche Durchlaufzeit von den Anträgen mit Beträgen zwischen 200.000 e und 500.000 e verursacht wird, weil die Liegezeit bis zur Genehmigung durch die Abteilungsleitung relativ zu den anderen Anteilen der Gesamtdauer sehr hoch ist. Dies liegt daran, dass Abteilungsleitung und Stellvertretung z. B. wegen häufigen Dienstreisen nicht regelmäßig für Genehmigungen zur Verfügung stehen. Der interne Prozessberater der Bank schlägt eine Änderung der Geschäftsregel zur Genehmigung vor. Zukünftig soll es den Sachbearbeitern erlaubt sein, für Beträge bis 500.000 e Angebote selbst zu unterschreiben und zu verschicken. Diese Reorganisation berührt mehrere Aktivitätsbündel. Zunächst erfordert sie eine Änderung des Modells, da die Genehmigungsschleife über die Abteilungsleitung entfällt. Die Modelländerung bedarf der anschließenden Validierung, um sicherzustellen, dass der geänderte Ablauf (immer noch) zum gewünschten Ergebnis führt. Im Rahmen der IT-Implementierung muss die Modifikation des Modells auch in die Workflow-Software überführt und getestet werden. Durch den Wegfall der Genehmigungen ändert sich der Aufgabenzuschnitt bei der Abteilungsleitung. Bei der Sachbearbeitung bleiben die Aufgaben zwar gleich, jedoch erhöhen sich Kompetenz und Verantwortung. Diesen Änderungen ist in der organisatorischen Implementierung Rechnung zu tragen, etwa durch aktualisierte Aufgabenbeschreibungen und möglicherweise durch Qualifikation der Sachbearbeiter mithilfe von Schulungen z. B. zur umfangreicheren Risikoabschätzung. Dieses Szenario greift im Vergleich zum Fall 1 massiv in die Art ein, wie im Prozess gearbeitet wird, und erfordert deshalb wesentlich umfangreichere Aktivitäten. 5.2.8.3 Verbesserungsszenario 3 Die Bank holt Bonitätsdaten über die Antragsteller bei der Schutzgemeinschaft für allgemeine Kreditsicherung (SCHUFA) ein. Hierzu übertragen die Sachbearbeiter Immobilienkredit die nötigen Kundendaten aus dem Kreditantrag in das Web-Formular der

5.2 Aktivitätsbündel im Geschäftsprozessmanagement

207

SCHUFA und die von dort gelieferten Abfrageergebnisse in das Bank-System zur weiteren Verarbeitung im bankeigenen Scoring. Die Sachbearbeiter berichten vom zeitraubenden Umkopieren der Daten durch Copy & Paste, den Fehlern, die dabei entstehen, und den dadurch verursachten Nacharbeiten. Um die Digitalisierung weiter voranzutreiben entscheidet die Bank ohne weitere Analysen, zukünftig anstatt der Internetauskunft der SCHUFA deren Web-Service zu nutzen. Dieser kann in den Workflow so integriert werden, dass die Process Engine ihn auf Knopfdruck des Sachbearbeiters aufruft und ihm die Kundendaten als Parameter übergibt. Der Service liefert das Ergebnis automatisch zurück an die Process Engine, die es in das Banksystem überträgt. Zu behandelnde Aktivitätsbündel beschränken sich in diesem Fall auf die ITImplementierung, in deren Rahmen die entsprechenden Softwareanpassungen mit anschließenden Tests durchzuführen sind, ehe die Produktivsetzung erfolgt. Die Arbeitsweise der Beteiligten ändert sich nur geringfügig, es sind keine Qualifizierungsmaßnahmen nötig. Der Wegfall der manuellen Datenübertragung entlastet sie von stupiden, zeit- und damit kostenintensiven und fehleranfälligen Routinetätigkeiten. Der intensivere IT-Einsatz spart Bearbeitungs- und Durchlaufzeit sowie Kosten und erhöht die Kundenzufriedenheit.

5.2.8.4 Verbesserungsszenario 4 In Abschn. 5.2.4 haben wir beschrieben, dass bei der Modellierung die Kundenbonitätsprüfung und die Objektprüfung bewusst parallelisiert wurden, um Durchlaufzeit zu sparen. Die Analyse hat gezeigt, dass die Bank pro Woche fünf Anträge aus Bonitätsgründen ablehnt. In diesen Fällen haben aber Sachbearbeiter bereits Aufwand für die parallele Wertprüfung der betreffenden Immobilien betrieben. Diesen einzusparen könnte zunächst wieder dafür sprechen zuerst die Bonität zu prüfen und nur bei positivem Ergebnis die Wertprüfung durchzuführen. Nötig wäre eine Modelländerung mit Validierung und Anpassung der Workflow-Anwendung. Die Rückführung der arbeitsteiligen Prüfung würde aber wieder die Durchlaufzeit erhöhen und zu einem Zielkonflikt führen. Deshalb gilt es weiter zu überlegen, ob sich der Aufwand für die Wertprüfung durch Automatisierung vermindern lässt, so dass eine unnötige Prüfung nicht mehr ins Gewicht fällt. Denkbar ist z. B., dass das Banksystem um Funktionen zur Bewertung erweitert wird. Es könnte dann nach automatischer Übernahme von Parametern aus dem Kreditantrag (Art, Größe, Baujahr, Adresse etc.) und angereichert mit Vergleichsinformationen (bankeigene Erfahrungswerte und Richtwerttabellen) und Geoinformationen (Infrastruktur mit Schulen, Einkaufsmöglichkeiten, Verkehrsanbindung etc.) einen Wertindex errechnen. Dieser beschleunigt die vom Sachbearbeiter vorgenommene finale Werteinschätzung. Bei dieser Möglichkeit könnte die parallele Ausführung der Schritte bestehen bleiben. Anstelle einer Modelländerung wären die Zusatzfunktionalität in der IT-Implementierung zu realisieren und zu testen sowie die Sachbearbeiter im Umgang mit der Softwareerweiterung zu schulen.

208

5 Vorgehensweise von der Modellbildung zur Digitalisierung

5.3

Einführung in Design Thinking

5.3.1

Wesen

Design Thinking (DT) ist ein methodischer Ansatz, kreativ und gestalterisch tätig zu werden, um Neuartiges hervorzubringen und komplexe Probleme zu lösen. Es zeichnet sich durch Beschreiten neuartiger Wege zur lösungsorientierten Gestaltung aus. Problemstellungen können besser gelöst werden, indem bei fortlaufenden Iterationen und dem „Begreifbarmachen“ durch Prototypen die Bedürfnisse der (potenziellen) Nutzer in den Vordergrund gestellt werden. Über dieses grundlegende Verständnis von Design Thinking herrscht Einigkeit in Praxis und Wissenschaft.1 Das Spektrum, das der Ansatz abdeckt, wird dagegen nicht einheitlich gesehen. Es gibt beispielsweise Interpretationen als Denkweise, Prozess und Werkzeugkasten (Brenner et al. 2016). Eine empirische Untersuchung belegt die Wahrnehmung im Kontinuum zwischen den beiden Polen Werkzeugkasten und Mindset (vgl. Abb. 5.8) (Schmiedgen et al. 2016). Dies ist einerseits auf die unterschiedlichen Wurzeln zurückzuführen, andererseits aber auch eine Folge der dem Konzept inhärenten, stetigen, erfahrungsgeleiteten Weiterentwicklung und Anpassung in unterschiedlichen Kontexten. „Die ständige Weiterentwicklung ist ein wichtiger Teil von Design Thinking“ konstatiert

Abb. 5.8 Verständnis von Design Thinking

1 Eine Übersicht über Definitionen findet sich z. B. bei (Schallmo et al. 2017).

5.3 Einführung in Design Thinking

209

Larry Leifer, einer der Protagonisten des Ansatzes an der d.school in Stanford, und betont: „Wenn Design Thinking eines Tages ein festgeschriebenes Manifest herausgeben sollte, würde es sich damit selber unkenntlich machen.“ (Leifer und Hoffmann 2012, S. 9). Der Ansatz geht auf David Kelley von der Design-Agentur IDEO und die Professoren Larry Leifer und Terry Winograd von der Universität Stanford zurück. Insbesondere letztere stellten bei der Ingenieursausbildung fest, dass bei der Entwicklung marktfähiger Produkte weniger die rein technischen, sondern vielmehr nutzerbezogene Aspekte im Mittelpunkt stehen sollten. Diese Erkenntnis führte etwa ab den 1980er-Jahren zur Entwicklung des DT-Konzepts und manifestiert sich bis heute im Stanford-Kurs zum Mechanical Engineering 310 – Design Innovation (me310.stanford.edu). Zur weiteren Verbreitung in Forschung, akademischer Lehre und betrieblicher Praxis trug maßgeblich Hasso Plattner mit seiner Unterstützung der nach ihm benannten Einrichtungen des d.school Institute of Design an der Universität Stanford und der School of Design Thinking an der Universität Potsdam (HPI D-School) bei. Aufgrund der Herkunft war DT ursprünglich vorwiegend auf die Entwicklung von physischen Produkten bezogen. Es findet aber mittlerweile vielfältige Anwendung auf unterschiedlichsten Gebieten wie der Entwicklung von Services oder ganzer Geschäftsmodelle, und gewinnt auch vermehrt in der Organisationsgestaltung und im Geschäftsprozessmanagement an Bedeutung.

5.3.2

Kernelemente

Kernelemente sind eine Mischung aus Mindset, Vorgehensweisen und konkreten Einrichtungen wie Arbeitsräumen. Dies spiegelt sich in der groben Einteilung in die drei „Ps“ wider, nämlich in die Bereiche People (Menschen), Process (Prozess) und Place (Arbeitsumgebung). Design Thinking beginnt mit der Schaffung tiefer Empathie für die Betroffenen. Es identifiziert die optimale Lösung im Überlappungsbereich von Wünschen der Menschen (menschlich-psychologischer Aspekt), der Machbarkeit (technologischer Aspekt) und Wirtschaftlichkeit (geschäftlicher Aspekt) (Uebernickel et al. 2015). Die zu entwickelnde Innovation soll etwas sein, • das die Menschen wirklich mögen (desirability), • das aus technologischer und prozessualer Sicht machbar ist (feasibility) und • das aus wirtschaftlicher Sicht erfolgreich ist (viability). Um dies zu erreichen durchläuft ein interdisziplinäres Team (People) in variablen, Kreativität fördernden Räumlichkeiten (Place) einen Prozess (Process) mit vielen Iterationen, wobei eine Vielzahl von Methoden zum Einsatz kommen kann.

210

5 Vorgehensweise von der Modellbildung zur Digitalisierung

5.3.2.1 People (Menschen) Die Fokussierung auf den Menschen erfolgt in zweierlei Hinsicht: Zum einen stehen Vertreter der Zielgruppe der Innovation, d. h. Kunden oder Anwender, mit ihren Bedürfnissen im Vordergrund. Empathie für sie zu entwickeln, sich in ihre Lage im betrachteten Kontext zu versetzen und somit ein tiefes Problemverständnis zu erlangen ist der Grundstein für erfolgreiche Innovation und nimmt breiten Raum in dem im Abschn. 5.3.2.2 beschriebenen Prozess ein. Zum zweiten stellt Design Thinking stark auf die am Projekt beteiligten Menschen als Einzelpersonen und als Team ab. Es sieht vor, die Diversität in interdisziplinären Teams für die Erhöhung der Ergebnisqualität zu nutzen. Teammitglieder sollen „T-Shaped“, d. h. sowohl Experten als auch Generalisten sein. Als Experten sind sie tief verwurzelt in ihrem Fachgebiet und bringen die entsprechende Expertise ein (senkrechter Strich des T). Damit kann auch die fachliche Vertretung einer Interessengruppe (Stakeholder) einhergehen (z. B. Vertrieb, Produktion, IT). Der Blick aus unterschiedlichen Perspektiven auf eine Problemstellung und die Synthese von Know-how und Erfahrungen aus verschiedenen Domänen hilft oft, neuartige Lösungsansätze zu entwickeln. Die Eigenschaft als Generalisten ist Voraussetzung dafür, von der eigenen Perspektive in die von anderen Beteiligten zu wechseln und offen zu sein für die Zusammenarbeit an den (fachlichen) Schnittstellen (waagrechter Strich des T, „Wir“-Denken) (Lewrick et al. 2018, S.122 ff.). Lewrick et al. plädieren deshalb für interdisziplinäre versus multidisziplinäre Teams, weil erstere wirklich kollektiv Ideen hervorbringen und hinter diesen stehen, wogegen die Mitglieder multidisziplinärer Teams bei der Lösungsfindung oft die eigene Perspektive überbewerten. Letzteres führt eher zu Kompromisslösungen, die nicht von allen hundertprozentig mitgetragen werden. Ein interdisziplinäres Team ist idealerweise heterogen zusammengesetzt nicht nur aus Vertretern möglichst vieler Fachgebiete, sondern auch unterschiedlicher Altersgruppen, Nationalitäten und Geschlechter. Der Erfolg eines Design-Thinking-Projektes wird maßgeblich durch die individuellen Eigenschaften der Mitglieder dieses Teams und der daraus erwachsenden gemeinschaftlichen Arbeitskultur und Denkweise bestimmt. Im Zentrum steht dabei, dem Menschen als Ausgangspunkt aller Aktivitäten hohe Wertschätzung und Empathie entgegenzubringen, sowohl den Kolleginnen und Kollegen im Team als auch den Benutzern bzw. Kunden. Dazu sollen Eigenschaften kommen wie Kooperationsfähigkeit, Neugier, Experimentierfreude, integratives Denken und Optimismus der Teammitglieder. Ein weiterer Erfolgsfaktor ist die Begleitung des Teams durch eine mit dem Prozess und dem Methodeneinsatz erfahrene Person als Facilitator. Diese gibt Orientierung über das jeweilige Stadium im Prozess und welche Instrumente dort am besten zu verwenden sind, ohne jedoch inhaltlich zu intervenieren. 5.3.2.2 Process (Prozess) Design Thinking folgt einem Vorgehensmodell mit einer Reihe von Schritten. Zwar haben sich mit der Zeit leicht unterschiedliche Varianten des sogenannten Mikrozyklus mit alternativen Bezeichnungen der Phasen herausgebildet, welche aber inhaltlich letztlich kaum

5.3 Einführung in Design Thinking

211

Abb. 5.9 Design-Thinking Prozess nach Stanford d.school

voneinander abweichen. Wir orientieren uns an dem Modell der d.school in Stanford, das dem Design-Thinking-Prozess fünf auch als Arbeitsmodi bezeichnete Phasen zugrunde legt (vgl. Abb. 5.9). Gekennzeichnet sind alle Modelle vom Wechsel zwischen divergentem und konvergentem Betrachten, Denken und Agieren, sowohl beim Verstehen des Problemraums und Gestalten des Lösungsraums. Der Übergang zwischen der Ausweitung des kreativen Rahmens mit stetig zunehmender Informationsmenge und dem Fokussieren durch Eingrenzung wird als Groan Zone bezeichnet, also als eine Stelle wie ein „knarzendes“ Scharnier (Lewrick et al. 2018, S. 28 f.). Auch die bewusste Iteration ist ein grundlegendes Element im DT-Prozess, das sich mit dem Motto „fail early, fail often“ bzw. „fail forward“ in einer offenen Fehlerkultur äußert. Es beschreibt die Vorstellung, dass ideale Lösungen nur durch mehrfaches frühzeitiges Experimentieren, Testen und Berücksichtigen des Feedbacks der Zielgruppe gefunden werden können, was zu mehr oder weniger umfangreichen neuen Durchläufen früherer Modi führen kann. Die mehrfachen Iterationen sollen als sogenannter Makrozyklus vom Problemverständnis zur Konkretisierung einer Lösungsvision führen und in einem Umsetzungsplan münden (Lewrick et al. 2018, S. 37 f.). In allen Prozessphasen gilt das Prinzip „Be visual & show“, was bedeutet, dass Gedanken, Ideen, Ergebnisse visuell und plastisch dokumentiert und vorgeführt werden sollen, etwa durch Post-its mit Stichworten und Zeichnungen, Mindmaps, Process Maps, greifbare Prototypen etc. Aufgrund dieses Prinzips wird manchmal auch vorgeschlagen besser von Design Doing anstatt von Design Thinking zu sprechen. Für die erfolgreiche Arbeit eines Teams entlang des Prozesses hat sich eine Reihe von Regeln und Tipps (Rules of Engagement) als hilfreich erwiesen, von denen einige auch generell bei Gruppenarbeiten zu beachten sind. Sie sollten zu Beginn eines Projekts

212

5 Vorgehensweise von der Modellbildung zur Digitalisierung

kommuniziert und im weiteren Verlauf vom Facilitator bei Bedarf in Erinnerung gerufen werden: • Nutzerorientierte Denk- und Arbeitsweise (Entwicklung von Empathie) • Keine Vorgabe oder Beschränkung von Denkweisen, Lösungswegen oder Lösungen (Offenheit, Autonomie, „Go for quantity“) • Konzentration auf das Thema (Fokussiertheit), daher auch keine Ablenkung durch Handys, Computer, iPads, Smart Watches etc., es sei denn sie sollen bewusst z. B. für Recherchen oder Prototyperstellung eingesetzt werden • Aktive Teilnahme jedes Teammitglieds (eigene Artikulation, diszipliniertes Zuhören („One conversation at a time“) und Aufbauen auf Ideen anderer) • Förderung der Entwicklung unterschiedlicher Perspektiven und wilder Ideen („Encourage wild ideas“) • Keine Wertungen bei der Ideengenerierung („Defer judgement“, „No killer phrases“) • Zeitlimitierung („Time Boxing“), um „Verliebtheit“ in eine bestimmte Idee zu vermeiden Die folgenden Abschnitte beschreiben jede Phase kurz zusammen mit einer tabellarischen Auswahl an Methoden und Werkzeugen, welche dort zum Einsatz kommen können. Ausführlichere Erläuterungen dazu finden sich beispielsweise im Bootcamp Bootleg der d.school2 und bei (Lewrick et al. 2018, S. 36 ff.). Empathize (Empathie aufbauen) Empathie ist das Herzstück eines menschen-zentrierten Designprozesses. Sie zu entwickeln heißt, ein tiefes Verständnis für die Mitglieder der Zielgruppe aufzubauen im Hinblick auf die Problemstellung und deren Kontext. Ziel ist es zu verstehen, warum und wie die Menschen Dinge tun, wie sie über die Welt denken und was ihnen wichtig ist und sinnvoll erscheint, sowie etwas über ihre körperlichen und emotionalen Bedürfnisse zu erfahren. Dies bedeutet die Nutzer zu beobachten, ihnen zuzuhören, mit ihnen zu interagieren, sich in ihre Situation einzudenken und einzufühlen und damit in ihre bewusste und unbewusste Welt von Gefühlen, Werten und Bedürfnissen einzutauchen (engage, observe, immerse). Dies ist die Grundvoraussetzung um Innovationen in die richtige Richtung zu lenken. Ein wesentliches Instrument zur Dokumentation des Verständnisses für die Zielgruppe sind die sogenannten Personas. Sie stellen fiktive Kunden oder Benutzer dar und verkörpern deren unterschiedliche Ziele, Verhaltensweisen, Bedürfnisse und Eigenschaften mit Relevanz für die zu entwickelnde Lösung. Im Modell des Hasso-Plattner-Instituts umfasst „Empathize“ die Phasen „Verstehen“ und „Beobachten“. Die Abb. 5.10 zeigt gängige Instrumente für die in der Phase enthaltenen Aktivitäten.

2 https://dschool.stanford.edu/resources/the-bootcamp-bootleg. Letzter Zugriff am 05.01.2018.

5.3 Einführung in Design Thinking

213

Abb. 5.10 Methoden und Werkzeuge für die Phase „Empathize“

Define (Problemstellung definieren) In diesem Modus geht es darum, auf den Erkenntnissen aus dem Modus „Empathize“ aufzubauen, sie zu teilen und zusammenzuführen, zu strukturieren, zu gewichten und zu interpretieren. Diese Synthese dient dazu, die Personas für idealtypische Nutzer zu prüfen und weiterzuentwickeln und gegebenenfalls die Perspektiven verschiedener Stakeholder einzunehmen. Ergebnisse sind ein weiter vertieftes Verständnis für die Benutzer und den Problemraum sowie eine konkretisierte, aussagekräftige Problemstellung (Design Challenge). Letztere schlägt sich in einem einzigen Satz nieder, welcher als sogenannter Point of View (POV) die Frage für die anschließende Phase der Ideengewinnung bildet (Lewrick et al. 2018, S. 73). In der Praxis werden unterschiedliche POV-Fragen verwendet. Eine typische Formulierung ist die „How might we?“-Frage, also beispielsweise „Wie könnten wir [User, Kunde] helfen, [ein bestimmtes Ziel] zu erreichen?“ (Lewrick et al. 2018, S. 74). Im Modell des Hasso-Plattner-Instituts entspricht „Define“ der Phase „Standpunkt definieren“. In der Abb. 5.11 sind übliche Hilfsmittel für die in der Phase enthaltenen Aktivitäten aufgeführt. Ideate (Ideen gewinnen) Das Ziel der Ideengewinnung ist es einen breiten Lösungsraum zu erarbeiten, also möglichst viele und auch möglichst unterschiedliche Ideen zu entwickeln und zu visualisieren. Ausgangspunkt ist die Point-of-View-Frage, jedoch gehen sämtliche bisher erarbeiteten Erkenntnisse in diese Phase ein, also beispielsweise auch User Profile Canvas, Empathy Map und Customer/User Experience Journey. Grundlegendes Instrument ist das Brainstorming, das durch Kreativitätstechniken und gezielte Aufgaben (z. B. Ideengenerierung zu bestimmten Funktionen) weiter und mehrfach stimuliert werden kann. Auch die Gestaltung erster „Low-Fidelity“-Prototypen und deren Test kann weitere Denkanstöße für Lösungen liefern und Iterationen auslösen. Der Methodeneinsatz in diesem Modus soll dazu befähigen, über offensichtliche Lösungen hinauszugehen und

214

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Abb. 5.11 Methoden und Werkzeuge für die Phase „Define“

Abb. 5.12 Methoden und Werkzeuge für die Phase „Ideate“

damit das Innovationspotenzial erhöhen, indem die kollektiven Perspektiven und Stärken des Teams genutzt werden. Unerwartete Lösungsrichtungen sollen aufkommen können und zur Menge und Unterschiedlichkeit der Ideen beitragen. So entsteht eine Vielzahl von Ideen, welche sortiert, verdichtet und bewertet werden. Beim gesamten Vorgehen sollte streng zwischen der Generierung und der Bewertung der Ideen getrennt werden, um nicht früh den kreativen Flow zu einzuschränken. Im Modell des Hasso-PlattnerInstituts entspricht „Ideate“ der Phase „Ideen finden“. Gängige Instrumente für die in diesem Modus enthaltenen Aktivitäten sind Abb. 5.12 zu entnehmen.

5.3 Einführung in Design Thinking

215

Prototype (Prototypen erstellen) Das Prototyping greift die am höchsten bewerteten Ideen aus der Ideenentwicklung auf und bearbeitet sie weiter. Dabei wird der Grundsatz des Design Thinking umgesetzt, Sachverhalte, Produkte und Ergebnisse möglichst früh zu visualisieren und anhand greifbarer Modelle mit potenziellen Nutzern zu testen, zu diskutieren und mit dem erhaltenen Feedback weiterzuentwickeln. Prototypen werden also erzeugt, um zu lernen, offene Fragen und Unstimmigkeiten zu klären, eine Konversation bzw. einen Diskurs zu beginnen und schnell und noch günstig Sackgassen zu erkennen. Prototyping transferiert Ideen aus dem Kopf in die physische Welt. Ein Prototyp kann demnach alles sein, was eine physische Form annimmt und der Maxime „don’t tell me, show me!“ folgt: eine Wand mit Post-it-Notizen, ein Rollenspiel, ein Raum, ein Objekt, ein Storyboard oder auch beliebige Kombinationen verschiedener Ausdrucksmittel. Die Granularität des Prototyps sollte dem Projektfortschritt entsprechen. In den frühen Stadien eines Projektes sollten Prototypen entstehen, die schnell anzufertigen und kostengünstig sind (Low Fidelity, Quick & Dirty), aber schon nützliches Feedback von Benutzern und Kollegen hervorrufen. In späteren Stadien sollten die Prototypen verfeinert werden und sich auch auf bestimmte Fragestellungen fokussieren. Sie dienen dazu, Empathie zu vertiefen, zu testen, weitere Ideen und Inspiration zu gewinnen. Im Modell des Hasso-Plattner-Instituts entspricht „Prototype“ der Phase „Prototyp entwickeln“. Die Abb. 5.13 zeigt gängige Instrumente für die in der Phase enthaltenen Aktivitäten. Test (Prototypen testen) Wie im vorherigen Abschnitt bereits ausgeführt, ist Testen eng mit dem Prototyping verknüpft. Die Empfehlung „Prototype as if you know you’re right, but test as if you know you’re wrong.“ beschreibt eine Denkhaltung, welche diesen Zusammenhang verdeutlicht. Testen bietet die Chance, qualitatives Feedback zu den prototypischen Lösungen zu erhalten, sie besser zu machen, weiter über die Nutzer zu lernen und damit die Empathie für sie zu vertiefen. Der Testmodus ist ein iterativer Lernmodus, in dem die Prototypen in den Kontext des potenziellen Benutzers gestellt und von diesem benutzt und bewertet werden. Wichtige Prinzipien dabei sind: Zeigen und nicht reden (siehe oben), Erlebnisse schaffen und dem Benutzer Vergleiche ermöglichen.

Abb. 5.13 Methoden und Werkzeuge für die Phase „Prototype“

216

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Abb. 5.14 Methoden und Werkzeuge für die Phase „Test“

Das Feedback bei den Tests kann nicht nur zu Veränderungen, sondern auch zum kompletten Verwerfen und damit zu einer grundlegenden Iteration über weiter zurückliegende Phasen führen. Dieses Vorgehen wird auch mit dem Slogan „Love it, change it or leave it“ umschrieben (Lewrick et al. 2018, S. 34). Prinzipiell ist bei jeder Iterationsschleife unabhängig von deren Umfang zu reflektieren, welche vorherigen Ergebnisse (z. B. Personas, User/Customer Experience Journey) aufgrund des Feedbacks angepasst werden müssen. Im Modell des Hasso-Plattner-Instituts entspricht „Test“ der Phase „Testen“. Die Abb. 5.14 enthält Instrumente für die in der Phase ausgeführten Aktivitäten.

5.3.2.3 Place (Arbeitsumgebung) Für die Arbeit der interdisziplinären Teams in den beschriebenen Modi gilt es eine Kreativität fördernde Umgebung, sogenannte Make oder Creative Spaces, zu schaffen. Dies bezieht sich insbesondere auf die Verfügbarkeit, Größe und Einrichtung von Räumlichkeiten als auch auf Hilfsmittel und Materialien für Visualisierung und Prototypengestaltung. Es geht vor allem darum, den Teams, frei und dauerhaft verfügbare Arbeits-, Interaktions-, Entspannungs- und Lagerbereiche, flexible Möbel mit Rollen, beschreib- und abwischbare Flächen (Wände, Tische, Tafeln), sowie gute und schnelle Zugänge zu Informationen (Internet, Bibliotheken etc.), Werkzeugen, Arbeitsmaterialien und Verpflegung bereitzustellen (Uebernickel et al. 2015, S. 216 ff.). Auch Beleuchtung, Belüftung und Klimatisierung sind wichtige Rahmenbedingungen. In der Praxis räumt man vor allem bei länger andauernden Projekten den Teams mitunter auch die Möglichkeit ein, die Umgebung selbst zu gestalten (z. B. Möbel selbst bauen). Doorley und Witthoft haben Anleitungen und Erfahrungen u. a. bei der Gestaltung von Kreativitätsumgebungen für die d.school publiziert (Doorley et al. 2012).

5.4

Verbindung der Konzepte

5.4.1

Überblick

Wie gezeigt zielt Design Thinking auf die Innovation von Produkten und Services, Geschäftsmodellen und -prozessen ab. Im Mittelpunkt stehen Benutzerzentriertheit, Kreativität und Agilität in einem experimentellen, iterativen Prozess, den interdisziplinäre Teams durchlaufen.

5.4 Verbindung der Konzepte

217

Das Prozessmanagement verfolgt mit der agilen und kreativen Prozessneu- oder -umgestaltung unter Berücksichtigung von Kundenbedürfnissen eine vergleichbare Zielsetzung. Im Folgenden stellen wir Bezüge zwischen den Konzepten her und diskutieren die Erfolg versprechende Nutzung von Design-Thinking-Elementen für das Prozessmanagement. Wir legen dabei besonderes Augenmerk auf die Digitalisierung von Prozessen, das heißt auf den sinnvollen Einsatz von Informations- und Kommunikationstechnik für die Prozessverbesserung und -innovation. Prototypen und endgültige Lösungen sind damit immer Workflow-Anwendungen unterschiedlichen Automatisierungsgrades.

5.4.2

Benutzerzentriertheit

Traditionellen BPM-Ansätze beziehen zwar bei der Prozessanalyse in der Regel die Beteiligten mit Interviews und Workshops ein. Im Vordergrund der aktivitäts- und ablaufbezogenen Interviewfragen, Kartenabfragen oder Beobachtungen stehen dabei jedoch die „harten“ Fakten der Arbeit im Prozess mit den in Abschn. 5.2.2 aufgeführten Merkmalen. Aspekte wie das Verstehen von Motivation, Denkweisen und Werten der Benutzer, die für die Entwicklung von Empathie im Design Thinking ausdrücklich betont werden, bleiben hier weitgehend unberücksichtigt. Daran haben auch neuere Konzepte wie Social BPM bisher wenig geändert. Eine interessante Brücke kann der Ansatz des Subjektorientierten Business Process Management (S-BPM) schlagen, der bereits zu Beginn dieses Kapitels im Fallbeispiel verwendet wurde. Er stellt die Subjekte als Handelnde im Prozess in den Mittelpunkt der Betrachtung. Mit der dazugehörigen Methodik und Sprache (vgl. Abschn. 3.6) sowie geeigneten Werkzeugumgebungen (vgl. Kap. 8) können Vertreter von am Prozess beteiligten Subjekten nicht nur als Befragte oder Beobachtete, sondern als aktive Designer an der iterativen Lösungsentwicklung mitwirken. Sie spezifizieren dabei nicht nur explizit das Verhalten des von ihnen repräsentierten Subjekts und dessen Interaktionen mit anderen Beteiligten, sondern können durch die Ausführung des resultierenden Modells sofort das Ergebnis ihrer Gestaltung erproben und verändern. Bei all dem können sie implizit auch die oben angesprochenen „weichen“ Faktoren einbringen.

5.4.3

Agiler Prozess mit Iterationen

Umfangreichere Prozessmanagementvorhaben werden in der Praxis häufig nach wie vor mit traditionellen Projektmanagementmethoden in klar definierten Phasen mit Meilensteinen durchgeführt, vergleichbar dem Wasserfallmodell bei der Softwareentwicklung. Dies bedeutet, dass der Weg von der Analyse über die Gestaltung des fachlichen Modells und dessen organisatorische und informationstechnische Umsetzung bis zu einer lauffähigen Workflow-Anwendung viel Zeit in Anspruch nimmt. Außerdem steigt

218

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Abb. 5.15 Zuordnung von Design-Thinking-Modi und BPM-Aktivitätsbündeln

damit die Wahrscheinlichkeit, dass die IT-Lösung von den sich weiterentwickelnden Bedürfnissen und Wünschen der Benutzer abweicht. Insbesondere für die Prozessdigitalisierung ist es deshalb von Vorteil, den agilen, iterativen Prozess des Design Thinking zu adaptieren. Dies eröffnet die Möglichkeit der steigenden Dynamik hinsichtlich der Entstehung neuer Prozesse und der Veränderungen bestehender Vorgänge, etwa aufgrund neuer oder geänderter Geschäftsmodelle wie Servitization, gerecht zu werden. Für die weiteren Überlegungen stellen wir die Modi des Design Thinking den Aktivitätsbündeln im Prozessmanagement gegenüber (vgl. Abb. 5.15). In Verbindung mit den Ausführungen in den Abschn. 5.2.2 und 5.3.2.2 zeigt die Abbildung, dass DT stärker zwischen Problemverständnis und Lösungsgestaltung trennt. Letztere beginnt erst mit Ideate. Davor wird ausgiebig die Ist-Situation beleuchtet und beispielsweise auf dem Weg über Personas in der Customer/User Experience Journey dokumentiert und visualisiert, ehe mit der Point-of-View-Fragestellung der Ausgangspunkt für die Ideengenerierung formuliert wird. Beim Prozessmanagement ist die Problemstellung dagegen in der Regel bereits zu Beginn klar formuliert. Bei der Erneuerung bestehender Prozesse leitet sie sich meist aus dem Wunsch nach verbesserter Prozessperformance ab (z. B. Durchlaufzeitverkürzung). In der Praxis werden deshalb meist nur diesbezügliche Schwachstellen des Ist-Zustands dokumentiert und Analyseinformation genutzt, um, wie auch bei einem neuen Prozess, gleich ein neues Soll-Modell zu entwickeln und zu visualisieren. Der kreative, gestalterische Teil beginnt damit früher als beim Design Thinking und ist tendenziell mit weniger Information als Ausgangsbasis unterfüttert. Er ist stärker analytisch (z. B. durch Performance Indicators) getrieben als durch die im Rahmen der Empathieentwicklung

5.4 Verbindung der Konzepte

219

im Design Thinking identifizierten „weichen“ Faktoren. Unabhängig von der etwas unterschiedlichen konkreten Ausgestaltung lässt sich das Aktivitätsbündel Analyse & Modellierung den DT-Modi Empathize, Define und Ideate zuordnen. Für eine umfassendere Erfassung des Problemkontextes und die dadurch erzielbare Ausweitung des Lösungsspektrums für die Prozessinnovation bietet sich der Einsatz bewährter DT-Instrumente an. Insbesondere bei der Entwicklung eines neuen Prozesses können die Teammitglieder z. B. mit einem Brain Dump zum Problemumfeld und der Diskussion der Ergebnisse ihren Betrachtungshorizont erweitern und ein gemeinsames Verständnis entwickeln. Mithilfe von Personas für die Prozessbeteiligten in ihren jeweiligen Rollen sowie mit Interviews und Beobachtungen lassen sich Customer/User Experience Journeys beschreiben. Sind Mitwirkende am Prozess selbst Teammitglieder können diese selbst ihre Erfahrungen ebenfalls als Journey visualisieren. Damit erweitert sich die Informationsbasis über die klassischen, objektiven Prozesscharakteristika hinaus um die Perspektive der User. Dieses breitere Fundament für das Entwickeln von Lösungsideen sollte den höheren Aufwand rechtfertigen. In Abschn. 5.2.2 haben wir dargelegt, dass bereits bei der Analyse und Modellierung von Prozessen Überlegungen zur Effektivität und Effizienz zumindest von Modellteilen angestellt werden. Dies gilt insbesondere, wenn die späteren Anwender dies wie bei der Subjektorientierung selbst tun. Deshalb sind die Aktivitätsbündel Validierung und Optimierung dem DT-Modus Test zugeordnet, erstrecken sich aber auch über Empathize, Define und Ideate. Mit dem Fokus auf Prozessdigitalisierung entspricht dem Modus Prototype beim Prozessmanagement das Aktivitätsbündel der IT-Implementierung. Das Prototyping im Design Thinking erhebt den Anspruch schnell und mit einfachen Mitteln, mithin kostengünstig, einen vorführbaren Prototyp zu erzeugen, um rasch Feedback vom Benutzer einzuholen (Modus Test) und dieses zu verwerten. Mit der Übertragung dieses „fail early, fail often“-Prinzips auf das Prozessmanagement muss das Team in die Lage versetzt werden, das Modell mit geringem Aufwand ausführbar zu machen. Im Vordergrund steht also die Erzeugung eines funktionalen Prototyps in Form von Software, der die Anwender erfahren und erleben lässt, wie ihre Arbeit mit der IT-Lösung aussehen würde. Die Zuordnung zur IT-Implementierung sollte aber für den Prototyp nicht Programmierung bedeuten. Vielmehr muss es im Sinne der schnellen Iterationen möglich sein, den Prototyp aus dem Modell automatisch zu generieren und im Aktivitätsbündel Validierung den Benutzern erproben zu lassen. Anschließende Modelländerungen aufgrund des Feedbacks führen auf demselben Weg zu einem neuen Prototyp, solange, bis eine Version gefunden ist, welche die Anwender zufriedenstellt. Solch kostengünstiges und frühzeitiges Prototyping verhindert möglicherweise aufwändigere Nacharbeiten bei der späteren Realisierung der echten Laufzeitumgebung. Mit einer vergleichbaren Vorgehensweise kann das Design der Benutzungsschnittstelle nach den Prinzipien des User Experience Design erfolgen.

220

5 Vorgehensweise von der Modellbildung zur Digitalisierung

Da das jeweilige Prozessmodell ja nicht nur Basis für Prototypen, sondern in seiner letztlich verabschiedeten Version auch für die angestrebte Workflow-Anwendung ist, umfasst das Aktivitätsbündel IT-Implementierung auch deren Realisierung in der in Abschn. 5.2.6 beschriebenen Weise. Wenn dafür über die modellbasierte WorkflowSteuerung hinausgehende Software entwickelt werden muss, bietet sich im Sinne der benutzerzentrierten, agilen Vorgehensweise SCRUM als Softwareentwicklungsmethode an. Im Zusammenhang mit der IT-Implementierung gilt es auch zu entscheiden inwieweit man die von Software-Startups oft verwendete Strategie der Minimum Viable Products verfolgen möchte. Dies würde bedeuten, Software mit minimaler Funktion den Kunden bzw. Anwendern nicht nur prototypisch, sondern auch produktiv zur Verfügung zu stellen, um deren Feedback für die Weiterentwicklung einzuholen. Bei IT-Lösungen für geschäftskritische Prozesse könnte dies riskant sein, anderseits kann es durch frühe Gewöhnung von Kunden an Features möglicherweise einen Vorsprung gegenüber Wettbewerbern eröffnen. Wie in den Abschn. 5.2.5 und 5.2.7 erläutert, ist das Modell auch in die Organisation einzubetten (Organisatorische Implementierung), ehe der Prozess produktiv gesetzt werden kann (Betrieb & Monitoring). Im Design Thinking folgen vergleichbare Schritte für die Implementierung z. B. eines Produkts auf Basis eines akzeptierten Prototyps, sowie für die Nutzung, die jedoch nicht mehr zu den Modi im engeren Sinn zählen (gepunktete Formen in Abb. 5.15). Fazit Um den Anforderungen der Digitalisierung von Prozessen gerecht zu werden sollte ein Prozessmanagementvorgehen Design-Thinking- und Prozessmanagementkonzepte kombinieren. Es muss geeignet sein, Prozesse und deren Änderungen rasch sowohl fachlich als auch in der IT abzubilden und dabei in kurzen Iterationszyklen die Anwender adäquat einzubinden, um die entstehende Lösung deren Vorstellungen anzunähern. Neben den für die Design-Thinking-Modi Empathize, Define und Ideate nutzbaren Instrumenten sind dafür insbesondere einfach handhabbare Methoden und Werkzeuge nötig, mit denen das Team und/oder die Prozessbeteiligten selbst 1. individuell unterschiedliche mentale Modelle der Arbeit artikulieren können 2. diese verschiedenen mentalen Modelle harmonisieren können 3. daraus Lösungsideen und konkrete Lösungsvorschläge in Form von Modellen entwickeln können 4. diese Modelle automatisch in ausführbare Prototypen überführen und testen können 5. freigegebene Modelle mit begrenztem Aufwand in Workflow-Anwendungen für den Live-Betrieb überführen können

5.4 Verbindung der Konzepte

221

Ein Beispiel für ein Konzept zur Unterstützung von (1) und (2) ist Compare/WP (vgl. Abschn. 6.1.2). Die Anforderungen (3), (4) und (5) werden beispielsweise vom S-BPMAnsatz und darauf basierenden BPM-Tools abgedeckt (vgl. Fleischmann et al. 2013, 2017).

5.4.4

Interdisziplinares Team

Die Bedeutung der Interdisziplinarität des von einem Facilitator begleiteten Teams beim Design Thinking haben wir im Abschn. 5.3.2.1 ausgeführt. Auch BPM-Projekte werden üblicherweise von Teams durchgeführt. Wir unterscheiden dabei vier Rollen: Governors (Treiber und Verantwortliche) setzen die Rahmenbedingungen. Diese umfassen im Wesentlichen den Betrachtungsbereich (Scope), also die Abgrenzung des im Projekt bearbeiteten Prozesssystems sowie, konkret auf die Analyse und Modellierung bezogen, die Methodik und die Werkzeuge. Actors (Arbeitshandelnde) sind die gegenwärtigen oder zukünftigen Akteure, welche die im zu verändernden oder zu entwickelnden Prozess zur Laufzeit die Aktionen in den Instanzen ausführen. Sie sind demnach die Träger konkreten ausführungsbezogenen Prozesswissens für ihren Anteil an der Erstellung des Prozessergebnisses, wissen also welche Teilschritte sie in welcher Reihenfolge erledigen, welche Informationen und Hilfsmittel sie dazu benötigen und mit wem sie dafür interagieren. Experts (Spezialisten) unterstützen die anderen Rollen mit methodischem und fachlichem Wissen. Es sind beispielsweise Domänenexperten, die im betreffenden Fachgebiet über Expertise verfügen und einbringen können, welche über die der Actors hinausgeht. Methodenexperten helfen den Beteiligten, insbesondere den Actors, bei der Artikulation und Harmonisierung ihrer mentalen Modelle sowie bei der Umsetzung mit einer der in Kap. 3 vorgestellten Modellierungssprachen. Für die technische Implementierung der fachlichen Modelle werden schließlich IT-Experten hinzugezogen. Experten in den unterschiedlichen Feldern werden bei Bedarf auch von außerhalb der eigenen Organisation als externe Berater involviert. Facilitators (Entwicklungsbegleiter) moderieren und koordinieren das Vorgehen und die Zusammenarbeit der Beteiligten. Sie sorgen beispielsweise dafür, dass Actors die Schnittstellen zwischen ihren Arbeitsschritten abstimmen und identifizieren für besondere Problemstellungen bei Bedarf geeignete Experten und binden sie ein. Bei alldem motivieren und überprüfen die Facilitators die Einhaltung der von den Governors gesetzten Rahmenbedingungen. Beim traditionellen phasenorientierten Vorgehen im BPM wirken bei Analyse, Modellierung, Validierung und Optimierung unter der Projektleitung als Facilitator zunächst

222

5 Vorgehensweise von der Modellbildung zur Digitalisierung

meist Actors und Experts als fachliche Inputgeber und Methodenexperten zusammen. Die Implementierung der verabschiedeten fachlichen Modelle übernehmen dann ITExperten. Als Nachteile dieses Vorgehens haben wir bereits in Abschn. 5.4.3 die mitunter lange Dauer und dadurch bedingte Abweichung von den Bedürfnissen der Stakeholder identifiziert. Seit einiger Zeit verbreitet sich deshalb der BizDevOps-Ansatz, der den im Zuge der Digitalisierung steigenden Agilitätsanforderungen Rechnung tragen will. Er strebt eine vergleichsweise engere Verzahnung von Fachabteilung (Business, Biz), IT-Entwicklung (Development) und IT-Betrieb (IT Operations) an.3 Dem agilen Team gehören von Beginn an Vertreter aller Bereiche in den beschriebenen Rollen an, welche die Prozesslösung gemeinsam gestalten. Das Konzept kann damit sowohl das Business-IT-Alignment verbessern als auch das Enabling durch IT fördern. Ersteres bedeutet, dass der Abdeckungsgrad der Bedürfnisse der Fachabteilungen durch passende IT-Services steigt. Beim Enabling gibt die IT Impulse für die Nutzung von Informations- und Kommunikationstechnik für Geschäftsmodell- und Geschäftsprozessinnovationen. Wie das Design Thinking sieht der BizDevOps-Ansatz also ein interdisziplinäres Team vor. Herausforderung ist es in solchen Teams, das „Wir“-Denken unter „T-shaped“ Personen zu etablieren. Dies liegt daran, dass Linieneinheiten, denen die Beteiligten entstammen (verschiedene am Prozess beteiligte Fachabteilungen, IT-Entwicklung, ITBetrieb), unterschiedliche Ziele verfolgen und diesen oft tendenziell höhere Priorität einräumen als einem gemeinschaftlich zu erreichenden Ziel (innovative oder verbesserte Prozesslösung). Hinzu kommt, dass die Kreativität möglicherweise durch Involvierung der fachlichen Domänenexperten behindert wird. Einerseits kennen Prozessbeteiligte oft Schwachstellen existierender Prozesse und Lösungsvorschläge dafür. Andererseits sind sie eventuell „betriebsblind“ und in der Betrachtung des Problem- und insbesondere des Lösungsraums zu eingeschränkt. Bei der Rekrutierung sollten demnach nicht nur Diversitätsaspekte wie Geschlecht, Alter und kultureller Hintergrund eine Rolle spielen. Vielmehr ist auf eine sinnvolle Balance zwischen Domänenexperten und Teammitgliedern zu achten, die themenfremde fachliche Hintergründe aufweisen und kein ausgeprägtes Eigeninteresse am Aussehen einer Lösung haben. Die Schwerpunktverschiebung kann man davon abhängig machen, ob das Ziel eher eine Prozessverbesserung ist, bei der Erfahrungen und Inputs der mit dem bestehenden Prozess vertrauten Personen hilfreich sein können. Steht dagegen eine radikalere Prozessinnovation im Vordergrund, könnten diese möglicherweise eher limitierend wirken. Selbstverständlich sollten auch bei der ursprünglichen Zielsetzung der Verbesserung Ideen für eine fundamentale Innovation des betrachteten Prozesses nicht außer Acht gelassen werden.

3 Bei der Betrachtung über Unternehmensgrenzen hinweg könnte man noch Partner im Wertschöp-

fungsnetzwerk ergänzen wie Lieferanten, Kunden oder Logistikdienstleister (Network Partners) und sinngemäß von NetBizDevOps sprechen.

Literatur

223

Literatur Allweyer T (2005) Geschäftsprozessmanagement: Strategie, Entwurf, Implementierung, Controlling. W3l GmbH Brenner W, Uebernickel F, Abrell T (2016) Design thinking as mindset, process, and toolbox. In: Design thinking for innovation. Springer, S 3–21 Doorley S, Witthoft S et al (2012) Make space: How to set the stage for creative collaboration. Wiley Fleischmann A, Borgert S, Elstermann M, Krenn F, Singer R (2017) An overview to s-bpm oriented tool suites. In: Proceedings of the 9th International Conference on Subject-oriented Business Process Management. S-BPM ONE. ACM, Hochschule Deggendorf Fleischmann A, Schmidt W, Stary C (2013) Subject-oriented bpm= socially executable bpm. In: 2013 IEEE 15th Conference on Business Informatics. IEEE, TU Darmstadt, S 399–407 Leifer L, Hoffmann F (2012) Über design thinking, bad guys, experimente, jagd und organisationalen wandel. OrganisationsEntwicklung 2:8–13 Lewrick M, Link P, Leifer L, Langensand N (2018) Das Design Thinking Playbook: mit traditionellen, aktuellen und zukünftigen Erfolgsfaktoren. Vahlen Schallmo DR, Lang K et al (2017) Design Thinking erfolgreich anwenden. Springer Schmelzer HJ, Sesselmann W (2013) Geschäftsprozessmanagement in der praxis, 8., überarb. u. erw. Aufl. Hanser, München Schmiedgen J, Rhinow H, Köppen E (2016) Parts without a whole?: The current state of Design Thinking practice in organizations, Bd 97. Universitätsverlag, Potsdam Uebernickel F, Brenner W, Pukall B, Naef T, Schindlholzer B (2015) Design Thinking: Das Handbuch. Frankfurter Allgemeine Buch

6

Vorbereitung der Prozessimplementierung

Ziel der Prozessvorbereitung für die anschließende Implementierung ist eine präzise Spezifikation des Prozesses mit Beschreibung von Prozessstrategie und Prozesslogik. Die Vorbereitung umfasst die Analyse und Modellierung sowie Validierung und Optimierung als Teile des in Kap. 5 vorgestellten Prozessmanagementmodells (vgl. Abb. 6.1). Das Ergebnis dieser Aktivitätenbündel ist eine Prozessbeschreibung, die präzise genug ist für die Umsetzung. Grundvoraussetzung dafür ist, dass Beteiligte Prozesswissen artikulieren, ein gemeinsames Verständnis für die (Um-)Gestaltung der Vorgänge entwickeln und das Ergebnis in einer geeigneten Modellierungssprache ausdrücken können. Dieses Kapitel befasst sich deshalb zunächst mit ausgewählten Methoden hierfür wie etwa der Value Network Analysis oder einer Kriterienliste zur Auswahl der Modellierungssprache. Im zweiten Teil geht es um die Qualitätskontrolle der beschriebenen Prozessgestaltung. Damit soll deren Effektivität und Effizienz sichergestellt werden, ehe die Umsetzung beginnt. So lassen sich unnötige Entwicklungskosten insbesondere im Bereich der ITUnterstützung minimieren. Validierungsverfahren wie Walk Throughs und Rollenspiele und Optimierungsmethoden wie die Simulation runden das Kapitel ab. Die angesprochenen Aktivitäten werden nicht notwendigerweise in einer strengen Reihenfolge durchgeführt, sondern die Tätigkeitsschwerpunkte können situativ zwischen den Aktivitäten wechseln. In den folgenden Abschnitten werden ausgewählte Methoden für diese Aktivitätenbündel vorgestellt.

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_6

225

226

6 Vorbereitung der Prozessimplementierung

Abb. 6.1 Einordnung der Vorbereitung in das Prozessmanagementmodell

6.1

Analyse und Modellierung

Analyse und Modellbildung sind nicht scharf zu trennen. Schwerpunkt der Analyse sind die strategischen Aspekte von Prozessen, während in der Modellierung auf die Prozesslogik fokussiert wird. In der Analyse wird also der Anfang mit dem zugehörigen Input, das Ende mit dem erzeugten Output und das damit befriedigte Kundenbedürfnis klargelegt. In der Analyse werden auch der Rahmen und die wesentlichen Aspekte der Prozesslogik abgesteckt. In der Praxis wird allerdings bei der Überarbeitung von Prozessen in dieser Phase kaum die Prozesslogik des Ist-Zustands explizit beschrieben. Die Analyse der aktuellen Prozesslogik erfolgt im Rahmen der Definition des gewünschten SollProzesses. Der ausschließliche Bezug zur Ist-Situation macht in der Regel wenig Sinn und ist auch für alle Beteiligten zumeist unangenehm zu dokumentieren – Was wurde in letzter Zeit „falsch“ gemacht? So lange man das Werkzeug „natürliche Sprache“ benutzt, befindet man sich eher in der Aktivität der Analyse als in der Modellierung. Der Übergang von der natürlichen Sprache zu einer formaleren Prozessmodellierungssprache entspricht dem Übergang zu den Modellierungsaktivitäten. Der Modellierung kann eine mehr oder weniger intensive Analysephase vorausgehen. In Extremfällen wird unmittelbar ein Prozessmodell ohne vorangehende natürlich-sprachliche Analyse erstellt. Allerdings ist zu empfehlen, dass zumindest die strategischen Aspekte des betrachteten Prozesses bekannt und definiert sind. In der Folge werden Richtlinien zur Artikulation und Abstimmung von prozessrelevantem Wissen vorgestellt, welche methodisch und werkzeugtechnisch unterstützt

6.1 Analyse und Modellierung

227

werden können. Ein wesentliches Element stellt dabei das Verständnis von Rollen dar, welche die Beteiligten als relevant für die Abwicklung von Prozessen erachten. Darüber hinaus empfiehlt sich, die Austauschbeziehungen zwischen Akteuren zu betrachten, zur weiteren Gestaltung von Prozessen deren Qualität zu bewerten und daraus gegebenenfalls Änderungspotenzial abzuleiten.

6.1.1

Einführung zu Artikulation und Abstimmung

Wissen über Arbeitsabläufe und organisationale Prozesse ruht in den meisten Fällen in den Köpfen von HandlungsträgerInnen. Daher kommen einer kontextsensitiven strukturierten Erhebung und Analyse entscheidende Bedeutung zu. Die Erhebung dient der Artikulation von Erfahrungswissen und wird in den meisten Fällen im Rahmen der Modellierung durchgeführt. Wird sie allerdings bereits vorab bearbeitet, dann kann in GPM-Projekten mit der Vielfalt von Ansätzen zur Aufgaben- oder Problembewältigung strukturierter umgegangen werden. Allerdings spielen in diesem Zusammenhang die Abstimmung und der Abgleich unterschiedlicher Ansätze eine wichtige Rolle. Deren Unterstützung trägt wesentlich zu einer integrationsfähigen Lösungsbildung trotz hoher Vielfalt und individueller Zugänge zur Aufgabenerfüllung bei. In diesem Abschnitt wird daher auf die Erhebungs- und Aushandlungsmethoden sowie Instrumente eingegangen, welche Individuen Artikulation im Rahmen kollektiver Reflexions- und Aushandlungsprozesse ermöglichen. Wie Menschen ihre Arbeit durchführen, wie sie auf wahrgenommene Vorgaben oder Abweichungen reagieren und wie sie mit anderen kooperieren, wird wesentlich von ihrer Wahrnehmung der organisationalen Realität geprägt. Die Interpretation der wahrgenommenen Rahmenbedingungen sowie die Ableitung der als adäquat erachteten Reaktion der agierenden Arbeitenden kann mit der kognitionswissenschaftlichen Theorie der mentalen Modelle erklärt werden. Diese Theorie kann auch als Grundlage verwendet werden, um von den operativ tätigen Personen ausgehende Lern- und Veränderungsprozesse in Organisationen zu erklären. In diesem Thema bildet sie deshalb die Grundlage für die Ableitung von Maßnahmen, die Arbeitende in die Lage versetzen sollen, sich ihrer Arbeitsabläufe und den diese prägenden organisationalen Zusammenhänge und Rahmenbedingungen bewusst zu werden. Das Konzept der „mentalen Modelle“ wird verwendet, um zu erklären „wie Menschen die Welt verstehen – genauer: wie sie ihr Wissen benutzen, um sich bestimmte Phänomene der Welt subjektiv plausibel zu machen“ (Seel, 1991). Mentale Modelle sind dabei Erklärungsmodelle der Welt, die von Menschen auf Basis von Alltagserfahrungen, bisherigem Wissen und darauf basierenden Schlussfolgerungen gebildet werden. Ein mentales Modell wird vom jeweiligen Individuum als Basis verwendet, um die Welt zu verstehen und ggf. Vorhersagen über deren Verhalten zu bilden (Seel, 1991). Das mentale Modelle prägende Wissen kann auf Alltagserfahrung basieren oder durch Vermittlung oder Instruktion begründet werden. Die Modifikation und Erweiterung der eigenen Wissensbasen und die (Weiter-)Entwicklung der kognitiven Fähigkeiten, die für

228

6 Vorbereitung der Prozessimplementierung

die Ableitung von Schlussfolgerungen notwendig sind, bezeichnet (Seel, 1991) als „Lernen“. Lernen ist „mit der Verarbeitung individueller Erfahrungen sowie mit vermittelter Information über die Welt, ihre Struktur und Evidenz verbunden und kann als ein Prozess permanenter konzeptueller Veränderungen verstanden werden.“ (Seel, 1991). Lernen setzt damit die Fähigkeit und Bereitschaft voraus, „vermittelte Weltauffassungen zu verstehen, zu akzeptieren und sodann den eigenen gedanklichen Konstruktionen zugrunde zu legen“ (Seel, 1991). Die Veränderung mentaler Modelle über Arbeitsprozesse weist zwei grundlegende Schwierigkeiten auf. Bei bereits als nicht adäquat erkannten mentalen Modellen besteht grundsätzlich die Bereitschaft zur Veränderung (im Sinne einer Anpassung des mentalen Modells an die als verändert wahrgenommenen Umweltbedingungen), die Herausforderung besteht aber darin, an die notwendige Information zu gelangen und diese adäquat dargeboten zu bekommen. Eine weitere Schwierigkeit ergibt sich in Situationen, in denen nicht alle involvierten Individuen die Situation als „problematisch“ wahrnehmen und deshalb keine grundlegende Bereitschaft zeigen, ihre der Arbeit zugrundeliegenden Annahmen (also ihre mentalen Modelle) zu verändern. Dies tritt vor allem in Situationen auf, in denen die kollaborative Reflexion nicht aus einer allgemein wahrgenommen Problemsituation heraus durchgeführt wird, sondern entweder mit rein planendem Charakter angestoßen wird, oder welche nur von einzelnen beteiligten Individuen als „problematisch“ wahrgenommen werden. Diesen Problemen kann mit einer expliziten Unterstützung des Reflexionsprozesses begegnet werden. Eine derartige Unterstützung muss sicherstellen, dass Artefakte zur Repräsentation der individuellen mentalen Modelle geschaffen werden, die dann die Grundlage für die gegenseitige Verständlichmachung der jeweiligen Sichten auf den Arbeitsprozess bedienen kann. Derartige Artefakte können dazu dienen, Aspekte eines Arbeitsprozesses abzustimmen und sicherzustellen, dass die in Artefakten kodierte ostensive Sicht auf einen Arbeitsprozess durch darauf aufbauendes performatives subjektives Handlungswissen in der Arbeitspraxis umgesetzt werden kann. Aus methodischer Sicht muss dazu sichergestellt werden, dass alle am realen Arbeitsprozess beteiligten Personen organisatorisch und methodisch in der Lage sind, sich am kollaborativen Lernprozess zu beteiligen. Dies bedingt vor allem, dass sie die verwendeten Ausdrucksformen verstehen und aktiv einsetzen können. Dies ist wiederum eine Lernherausforderung, die explizit adressiert werden muss. Eine in den Bildungswissenschaften weithin akzeptierte Möglichkeit zur Externalisierung und Abstimmung mentaler Modelle ist die Bildung konzeptueller Modelle. Gleichzeitig können derartige Modelle die Grundlage für die Spezifikation von Arbeitsprozessen und die Konfiguration von Arbeitsunterstützungssystemen bilden, sofern sie sich einer formal spezifizierten Semantik bedienen (wie etwa die BPMN oder S-BPM). Konzeptuelle Modelle stellen also ein Mittel dar, Arbeitende in die Lage zu versetzen, ihre Arbeit zu reflektieren, abzustimmen, die Ergebnisse dieser Abstimmungsprozesse für Dritte zugänglich zu machen und diese im Rahmen der existierenden Systemgrenzen zur Unterstützung der eigenen Arbeitsabläufe nutzbar zu machen.

6.1 Analyse und Modellierung

229

Modelle sind Abbildungen der Realität, die zu einem bestimmten Zweck gebildet werden. Modelle repräsentieren nie das reale Phänomen als Ganzes, sondern enthalten nur jene Aspekte der Realität, die vom Modellbildenden als relevant für die jeweilige Zielerreichung erachtet werden. Für die Modellbildung stellt sich damit die Frage nach der Definitionsmacht dieser Modelle und der durch sie abgebildeten sozialen Realität. Sofern ein Modell nicht nur einen das modellbildende Individuum betreffenden Zweck erfüllt, sondern von anderen Personen genutzt wird, beeinflusst das Modell die mentalen Modelle dieser Personen und damit auch deren Verhalten. Die aktive Involvierung operativ Arbeitender in die Spezifikation von Arbeitsprozessen stellt deshalb eine Möglichkeit für deren selbstermächtigte Gestaltung ihrer Arbeit dar. Dazu ist es jedoch notwendig, dass Arbeitende in die Lage versetzt werden, derartige Modelle zu verstehen, selbst zu gestalten, und deren Wirkung auf ihre Arbeitsprozesse abschätzen zu können. In aktuellen Ansätzen wird hingegen nach wie vor von der Notwendigkeit eines Prozess-Analysten ausgegangen, der die Sichtweisen der Arbeitenden in ein Prozessmodell übersetzt. Dies kann zu Abweichungen zwischen dem realen Arbeitsprozess und dessen Modellrepräsentation führen. Außerdem nimmt diese Vorgehensweise den operativ tätigen Personen die Möglichkeit im Sinne des modellbasierten Lernens ihre mentalen Modelle zu schärfen und mit jenen der anderen Beteiligten abzustimmen. Um Arbeitende in die Lage zu versetzen, derartige Modelle zu verstehen, muss das Erlernen von grundlegenden Ansätzen zur Erstellung und Interpretation konzeptueller Modelle Gegenstand der Aus- oder Weiterbildung sein. Arbeitende müssen jene Modelle erkennen können, die den Systemen zu Grunde liegen, in die sie eingebettet sind. Darüber hinaus sollen sie die Implikationen von externen oder selbst durchgeführten Änderungen an diesen Modellen abschätzen und Interventionen dementsprechend planen können. Dazu müssen folgende Punkte methodisch unterstützt werden: • die Ermöglichung der individuellen Artikulation eigener mentaler Modelle über Arbeit, um eine individuelle Reflexion zu ermöglichen und dadurch Lücken und Inkonsistenzen individuell wahrnehmbar zu machen, sowie zu verhindern, dass Sichtweisen einzelner Personen nicht berücksichtigt werden und diese in der Folge keinen Bezug zu ihrer Arbeitsrealität herstellen können, • die Unterstützung der Vereinbarung eines gemeinsamen Vokabulars, um unterschiedliche Verständnisse von Begriffen zu identifizieren und sich in der Folge eindeutig über die gegenständliche Arbeit austauschen zu können, und zu verhindern, dass das gleiche reale Phänomen mit unterschiedlichen Begriffen bezeichnet wird – oder dass umgekehrt der gleiche Begriff für unterschiedliche reale Phänomene verwendet wird, • die Unterstützung der Entwicklung eines gemeinsamen Verständnisses über die kollaborative Arbeit, um eine Grundlage für die Reflexion der individuellen mentalen Modelle anzubieten, und damit in Verbindung stehend, • eine Unterstützung bei der Identifikation und Auflösung von konfliktionierenden Sichtweisen, um Unterschiede in jenen mentalen Modellen, die die Kollaboration zwischen

230

6 Vorbereitung der Prozessimplementierung

Arbeitenden unmittelbar betreffen, sichtbar zu machen und deren Abstimmung zu ermöglichen. In den folgenden Abschnitten werden einige Methoden gezeigt, mit denen diese Anforderungen umgesetzt wurden.

6.1.2

Artikulations- und Erhebungsmethode CoMPArE/WP

Die oben beschriebenen Anforderungen werden in der Methode „CoMPArE/WP“ exemplarisch umgesetzt (Oppl 2016–2002, 2017). CoMPArE/WP steht für „Collaborative Multi-perspective Articulation and Elicitation of Work Processes“. Bei der Anwendung von CoMPArE/WP wird anhand der Reflexion über einen realen kollaborativen Arbeitsprozess Bewusstsein über die Zusammenarbeit in einem konkreten Einzelfall geschaffen. Aufgrund ihrer Verankerung an konkreten Arbeitsprozessen eignet sich die Methode auch als Mittel zur Organisationsentwicklung. Die Kooperationsform der Methode wird grundsätzlich durch deren Durchführung mit einer Kartenlegetechnik festgelegt. Die teilnehmenden Arbeitenden sind die wesentlichen Akteure und führen die Komponenten eigenverantwortlich durch, wobei Artikulations- und Nachfrage-Rollen wechseln können. Die konkrete Ausgestaltung der Kooperation ist in den Komponenten unterschiedlich und deshalb in der dort angeführten Prozedur beschrieben. Zur Unterstützung der Durchführung steht ein Facilitator bereit, der jedoch nicht inhaltlich interveniert. Die Methode soll bei der Artikulation und Abstimmung von mentalen Modellen über Arbeit unterstützen und gleichzeitig grundlegende Fähigkeiten zu deren Ausdruck in konzeptuellen Modellen vermitteln. Die Kombination dieser beiden Teilziele hat Auswirkungen auf das Rahmenwerk der Methode. Aus Sicht der Vermittlung von Modellierungskompetenz ist es sinnvoll, die notwendigen Fähigkeiten schrittweise mit steigender Komplexität einzuführen (Oppl und Hoppenbrouwers, 2016). Aus Sicht der Artikulationsunterstützung ist ein Vorgehen in drei Komponenten argumentierbar. Die Abb. 6.2 gibt eine Übersicht über diese drei Komponenten. Komponente 1 dient der Findung eines gemeinsamen Verständnisses darüber, wo und wie der abzustimmende Arbeitsprozess beginnt und endet sowie der Findung eines gemeinsamen Vokabulars. Komponente 2 dient der Artikulation und Reflexion des jeweiligen individuellen Arbeitsbeitrages. Alle TeilnehmerInnen erstellen hier individuell und ohne Interaktion mit anderen ein strukturiertes Modell ihrer Sichtweise auf ihren jeweiligen Arbeitsbeitrag. Durch die einheitlich strukturierte Darstellung der individuellen Beiträge ist in Komponente 3 eine kollaborative Abstimmung derselben möglich. Durch diese Abstimmung sollen konfliktionierende Sichtweisen aufgedeckt werden und eine gemeinsame Sicht auf den gesamten Arbeitsprozess entstehen. In diesen Komponenten sind die Ziele der Kompetenzentwicklung im Modellierungsbereich zu verankern. In Komponente 1 ist die Verbalisierung von mentalen Modellen und die darauf aufbauende Konzeptbildung zu vermitteln. In Komponente 2 muss das

Abb. 6.2 Drei Komponenten von CoMPArE/WP

6.1 Analyse und Modellierung 231

232

6 Vorbereitung der Prozessimplementierung

Beschreiben der verbalisierten Inhalte mittels eines vorgegebenen Kategorienschemas und einer Notation vermittelt werden. Dabei muss festgelegt werden, welche Elemente des Kategorienschemas in der Verantwortlichkeit des artikulierenden Individuums stehen und welche als Verhandlungsgegenstände bei der Abstimmung in Komponente 3 validiert und ggf. abstrahiert werden müssen bzw. zur Disposition stehen. Konkrete Umsetzung von Komponente 1 Nicht alle TeilnehmerInnen haben notwendigerweise ein gemeinsames Verständnis über die Konzepte, mit denen sie ihre Arbeit beschreiben. Um die vorhandenen mentalen Modelle soweit abzustimmen, dass ein gemeinsames Vokabular eine Zusammenarbeit ermöglicht, kann kollaboratives Concept Mapping eingesetzt werden. Zusätzlich kann ebenfalls nicht davon ausgegangen werden, dass ein gemeinsames Verständnis über die Grenzen des abzustimmenden Arbeitsprozesses gegeben ist. Auch hier kann Concept Mapping zur Klärung beitragen. Neben der inhaltlichen Dimension ermöglichen Concept Maps einen niederschwelligen Einstieg in die Welt der konzeptuellen Modellierung, da sie die Bedeutung von Modellelementen nicht vorgeben, sondern diese während der Modellierung durch die beteiligten Personen festlegen lassen. Dies erleichtert die Abbildung der individuellen mentalen Modelle in die explizite Repräsentation und vermeidet die Notwendigkeit, neben der Abstimmung mit den anderen beteiligten Personen auch noch eine Übersetzung auf ein Modell mit formal definierter Semantik durchführen zu müssen. Im Rahmen der Komponente werden die TeilnehmerInnen aufgefordert, alle relevanten Aspekte der Arbeitsumgebung zu beschreiben, in die der zu reflektierende Arbeitsprozess eingebettet ist. Dies erfolgt, indem jeder Aspekt individuell einzeln auf einer Karte notiert wird. Bei der Zusammenführung der individuellen gesammelten Aspekte werden die Karten reihum einzeln auf einer gemeinsamen Arbeitsfläche angeordnet. Die Aspekte können zueinander in Beziehung gesetzt werden. Karten mit unterschiedlichen Begriffen für den gleichen Aspekt werden überlappend angeordnet. Hierarchische oder kausale Beziehungen zwischen Aspekten können durch das explizite Zeichnen von Verbindungen, aber auch durch die räumliche Anordnung der Karten dargestellt werden. Das Beispiel in Abb. 6.3, das in diesem Abschnitt durchgängig zur Erläuterung der Methode herangezogen wird, zeigt eine Concept Map mit relevanten Aspekten für die Beantragung eines Urlaubs in einem Unternehmen. Die Aspekte wurden durch räumliche Anordnung zueinander in Beziehung gesetzt. Die überlappenden Elemente zeigen Aspekte, die von mehreren TeilnehmerInnen genannt und mit unterschiedlichen Begriffen bezeichnet wurden. Konkrete Umsetzung der Komponenten 2 und 3 Die Komponenten 2 und 3 fokussieren auf die Artikulation und Abstimmung des wahrgenommenen Ablaufs eines Arbeitsprozesses und der darin ablaufenden Interaktion. Die Modellbildung in Komponente 2 erfolgt dabei durch alle beteiligten Personen individuell, ohne Interaktion mit Anderen. So werden Überlagerungseffekte vermieden

6.1 Analyse und Modellierung

233

Abb. 6.3 Concept Map zum Thema Beantragung eines Urlaubs

und unterschiedliche Sichtweisen für die nächste Komponente explizit aufgedeckt. Die beteiligten Personen beschreiben dabei, welche Arbeitsschritte sie aus ihrer Sicht zur Erreichung des Arbeitsziels beitragen, mit wem sie interagieren und in welcher Form diese Interaktion erfolgt. Die Aushandlung einer gemeinsamen Sichtweise in Komponente 3 und die damit einhergehende Erstellung eines gemeinsamen Modells erfolgt wiederum mittels einer strukturierten Vorgehensweise, die an komplexere Modellierungsaufgaben heranführen soll und eine einheitlich aufbereitete Modellrepräsentation gewährleistet. Dabei werden die zuvor erstellten Modelle weiterverwendet. Das Strukturierungsschema trennt jene Modellaspekte, die in der Verantwortung der jeweiligen Arbeitenden bleiben, von jenen, die Gegenstand der Aushandlung sind. Zur Darstellung der Arbeitsprozesse wird in diesem Schritt eine strukturierte Darstellungsform mit vorab spezifizierter Semantik verwendet. Diese ist an den gängigen Kategorie-Schemata zur Beschreibung kollaborativer Arbeitsprozesse orientiert. Zum Einsatz kommen dabei die Kategorien WER, WAS und AUSTAUSCH. WER (blau in der Abb. 6.4) bezieht sich auf die Akteure im Arbeitsprozess, WAS (rot in der Abb. 6.4) wird verwendet, um aktive Beiträge im Rahmen des Arbeitsprozesses zu beschreiben. AUSTAUSCH (gelb in der Abb. 6.4) wird im Kontext kollaborativer Arbeitsprozesse verwendet, um die Weitergabe oder den Austausch von Informationen oder Material zwischen Akteuren im Rahmen der eigenen Tätigkeiten zu charakterisieren. Im Sinne der einfacheren Verwendbarkeit werden diese Kategorien nicht exakt spezifiziert und lassen bewusst Interpretationsspielraum im konkreten Einsatz – so kann ein WER-Element etwa eine konkrete Person, eine Rolle, eine Abteilung oder eine gesamte Organisation darstellen. WAS-Elemente verbleiben in der Verantwortung der einzelnen TeilnehmerInnen, WER- und AUSTAUSCH-Elemente sind in Komponente 3 Gegenstand der Abstimmung und müssen zu einem gemeinsamen Verständnis hin entwickelt werden.

234

6 Vorbereitung der Prozessimplementierung

Abb. 6.4 Individuelle Modelle in der vorgestellten Notation

Individuelle Artikulation In Komponente 2 beschreiben die beteiligten Personen individuell mit Hilfe der Elemente, WAS sie im Arbeitsprozess beitragen, WER mit Ihnen interagiert, und in welcher Form dieser AUSTAUSCH stattfindet. Zur Unterstützung des Artikulationsprozesses wurde ein Strukturierungsschema entwickelt, das die erstellten Modelle in einer einheitlichen Form aufbereitet und deren Zusammenführung im nächsten Schritt ermöglicht. Das Strukturierungsschema gibt – wie in Abb. 6.4 ersichtlich – die räumliche Anordnung der Modellelemente vor. Arbeitende repräsentieren sich selbst durch ein WER-Element, unter dem die wahrgenommenen Beiträge zum Arbeitsprozess als sequenziell angeordnete WAS-Elemente platziert werden. Für alle anderen Arbeitenden, mit denen eine Interaktion wahrgenommen wird, wir ein weiteres WER-Element platziert, unter dem jeweils die Interaktion durch AUSTAUSCH-Elemente näher spezifiziert wird. Deren vertikale Positionierungen bestimmen, ob eine eingehende Ressource erwartet wird (Platzierung oberhalb des davon abhängigen WAS-Elements), oder ob diese zur Verfügung gestellt wird (Platzierung oberhalb des erzeugenden WAS-Elements). Die Abb. 6.4 zeigt drei individuelle Modelle zu dem oben beschriebenen BeispielProzess, die entsprechend diesem Strukturierungsschema erstellt wurden. Im Beispiel ist ersichtlich, dass es an dieser Stelle zu inhaltlich divergenten Repräsentationen vor allem im Bereich der AUSTAUSCH-Elemente kommen kann (vgl. „Antrag“ vs. „vollständiger Antrag“). Diese Divergenzen werden in Komponente 3 explizit sichtbar und sind dann Gegenstand der Aushandlung einer gemeinsamen Sichtweise. Kollaborative Abstimmung Grundlage der kollaborativen Abstimmung sind die in Komponente 2 erstellten individuellen Modelle. Die Abb. 6.5 zeigt exemplarisch einen Abstimmungsprozess für zwei der im Beispiel repräsentierten Akteure. Die gemeinsame Modellbildung erfolgt wiederum auf einer gemeinsamen Arbeitsoberfläche (Abb. 6.5 Mitte). Jene Teilnehmende, welche auch den realen Arbeitsprozess auslöst, beginnt mit der Beschreibung der eigenen Beiträge zum Arbeitsprozess und fügt der Oberfläche die entsprechenden Modellelemente hinzu (Schritte 1–2 in der Abb. 6.5).

6.1 Analyse und Modellierung

235

Abb. 6.5 Kollaborative Abstimmung

Die übrigen Teilnehmenden intervenieren hier nur nachfragend zur Vermeidung von Missverständnissen oder zur Offenlegung von Unklarheiten. Eine aktive Beteiligung der anderen erfolgt, sobald das erste AUSTAUSCH-Element zum Einsatz kommt (Schritte 3–4). Sofern eine grundlegend gemeinsame Sichtweise auf den Arbeitsprozess existiert, sollte an dieser Stelle einer der Teilnehmenden ein entsprechend zuzuordnendes AUSTAUSCH-Element einbringen können (Schritte 5–7). Ist dies der Fall, so wird der Beschreibungsprozess durch diese Person fortgesetzt (ab Schritt 8). Bei einer grundsätzlichen Passung, die sich jedoch in der Bezeichnung des Elementes – etwa durch unterschiedliche Abstraktionsebenen – unterscheidet, muss diese mehrfache Bezeichnung aufgelöst werden oder die semantische Äquivalenz der beiden Elemente durch überlappendes Anordnen dargestellt werden (z. B. Schritt 7). Falls kein zuzuordnendes Element vorhanden ist, wird eine grundsätzlich divergierende Repräsentation sichtbar. Diese kann auf mangelndes Relevanzbewusstsein eines Austausches zurückzuführen sein, das bedeutet, dass dem angesprochenen Teilnehmenden die Interaktion zwar bewusst war, aber im Kontext des Arbeitsprozesses als nicht relevant erschien. Falls eine wahrgenommene Interaktionserfordernis eines Teilnehmenden nicht erwidert wird, muss es jedoch zu tiefergehenden Aushandlungsprozessen kommen. Der initiale Abstimmungsprozess endet, sobald alle Teilnehmenden ihre individuellen Modelle erläutert und zum gemeinsamen Modell hinzugefügt haben. Dieser Externalisierungs-Phase folgt eine kollaborative Reflexionsphase, im Rahmen derer der Arbeitsprozess anhand des gemeinsamen Modells durchgegangen und hinsichtlich seiner Passung auf die individuellen Sichtweisen der Beteiligten diskutiert wird. Etwaige notwendige Modifikationen werden an dieser Stelle nach einer Konsensbildung der jeweils Betroffenen durchgeführt.

236

6 Vorbereitung der Prozessimplementierung

Das Ergebnis der Anwendung der Methode stellt nun eine konsensuale Repräsentation des kollaborativen Arbeitsprozesses dar. Aufgrund der eingeschränkten Ausdrucksstärke der eingesetzten Modellierungssprache ist an dieser Stelle die Abbildung von – ansonsten in Prozessbeschreibungen üblichen – Arbeitsvarianten oder Entscheidungen nicht möglich. Die Entscheidung für eine semantisch auf wenige Elemente beschränkte Modellierungssprache fiel wiederum unter didaktischen Gesichtspunkten, da empirische Belege zeigen, dass unerfahrene Modellierende ihre Sichtweisen auf einen Arbeitsprozess initial einfacher narrativ anhand eines konkreten Falles beschreiben können. Entscheidungen hinsichtlich der konkreten Umsetzung des Arbeitsprozesses sind bei der fallbasierten Beschreibung bereits getroffen. Damit ist eine explizite Repräsentation derselben im Rahmen der Modellierung nicht notwendig. Eine vollständige Beschreibung des Arbeitsprozesses bedingt somit eine mehrfache Durchführung der Methode oder deren Erweiterung um weitere Verfeinerungsschritte, die aber an dieser Stelle nicht näher betrachtet werden sollen. Im Sinne der Bildung von Modellierungskompetenz liegt der Fokus in Komponente 1 auf der Hinführung zur für die Modellbildung notwendige Abstraktion und Konzeptualisierung von Wahrnehmungen der realen Welt. In Komponente 2 erfolgt die durch Strukturhilfen angeleitete Darstellung und Reflexion der eigenen Arbeitswahrnehmung in konzeptuellen Modellen und deren Beschreibung mittels vorgegebener Strukturelemente. Komponente 3 fokussiert in der Folge auf Modell-Verständnis (der anderen individuellen Modelle), -Interpretation (hinsichtlich deren Auswirkungen auf das eigene Modell) und –Aushandlung (der gemeinsam vertretbaren Sicht) von Modellinhalten, wodurch letztendlich die Kompetenz zur selbstermächtigenden Beeinflussung von Arbeitsprozessen vermittelt wird. Zur Auseinandersetzung mit der Wirkung einer konkreten Anwendung der Methode muss der Begriff der „Selbstermächtigung“ gefasst werden. „Selbstermächtigung“ kann nach (Liebert, 2015) folgendermaßen verstanden werden: Der Begriff der Selbstermächtigung . . . fordert . . . dazu auf, sein Schicksal in die eigene Hand zu nehmen, seine individuellen Ansprüche nicht nur zu formulieren, sondern auch – aktiv – durch Selbsttätigkeit umzusetzen –, auch wenn dies bedeutet, gegen die eingespielten Regeln und etablierten Strukturen der institutionellen Ordnungen zu verstoßen.“ Die Methode soll nun zur „Selbstermächtigung“ im Sinne dieser Definition führen. Der Anspruch, Arbeitende in die Lage zu versetzen, „individuelle Ansprüche [. . . ] zu formulieren“, ist das grundlegende Gestaltungsziel der vorgeschlagenen Methode. Die Zielsetzung, dazu zu befähigen, „diese [Ansprüche] auch – aktiv – durch Selbsttätigkeit umzusetzen“ wird im Kontext durch das Arbeitsbeeinflussungssystem gesteuerter Arbeitsprozesse insofern entsprochen, als dass Arbeitende dazu befähigt werden, die konzeptuelle Modellierung von Arbeitsprozessen als jene „Sprache“, die zur Konfiguration existierender Arbeitsbeeinflussungssystemen verwendet wird, nicht nur zu verstehen, sondern auch selbst zum Einsatz zu bringen. Dies soll dazu führen, diese sozio-technischen Systeme – wie zu Beginn argumentiert – als Arbeitsunterstützungssysteme einsetzen zu

6.1 Analyse und Modellierung

237

können, die den Arbeitsprozess und die zur Zielerreichung notwendige Kollaboration für die handelnden Individuen erleichtern können. Die Befähigung, diese „Umwidmung“ vorantreiben zu können, bildet die Grundlage dafür „die institutionelle Ordnung [. . . ] in Frage zu stellen und in letzter Konsequenz durch neue Formen der ‚freien‘ Selbstorganisation zu überwinden.“ Das Akzeptieren der existierenden organisationalen und technischen Rahmenbedingungen und der Unabdingbarkeit ihres weiteren Einsatzes stellt gleichzeitig die größte Herausforderung bei der Ermöglichung von Selbstermächtigung im organisationalen Kontext dar. Die Verwendung dieser Unterstützungssysteme ermöglicht nicht nur eine Fremdsteuerung, sondern auch eine Selbstdisziplinierung im Sinne der Erreichung vorgegebener Ziele, die mit der Verfügbarkeit technischer Unterstützung bei Planung und (Selbst- wie Fremd-)Kontrolle sogar erleichtert wird. Die Verwendung der Werkzeuge des klassischen Geschäftsprozessmanagements zur Bildung von Reflexions- und Gestaltungskompetenz von Arbeitsprozessen birgt darüber hinaus für Arbeitende das Potenzial, die entwickelten Kompetenzen auch zur Optimierung von Arbeitsprozessen aus betriebswirtschaftlicher Perspektive einzusetzen bzw. dazu angehalten zu werden. Während dies nicht per se dem Konzept der Selbstermächtigung entgegensteht, kann gleichzeitig auch nicht von einer Kohärenz der Interessen beider Gestaltungsperspektiven ausgegangen werden. Im Sinne einer nachhaltigen Verankerung der selbstermächtigten Gestaltung von Arbeitsprozessen in Organisationen muss diese Kohärenz aber angestrebt und auch explizit sichtbar gemacht werden. Dies stellt eine große Herausforderung im Kontext des Einsatzes von Geschäftsprozessmodellierung zur Organisationsentwicklung dar und muss als solche auch vor und während des Einsatzes der vorgestellten oder ähnlicher Methoden der akteurszentrierten Geschäftsprozesserhebung und -modellierung berücksichtigt werden.

6.1.3

Bewusstmachen von prozessrelevantem Veränderungspotenzial

In der Folge wird zunächst die Value Network Analysis vorgestellt, wie sie im Wissensmanagement zur Bearbeitung von Leistungsbeziehungen zwischen vernetzten Akteuren eingeführt wurde, ehe ihr Potenzial für die Prozessanalyse- und -modellierung detailliert wird.

6.1.3.1 Value Network Analysis Betrachten wir, wie eingangs erwähnt, die Wertschöpfung von Organisationen, und damit die Ebene der leistungsbezogenen Austauschbeziehungen zwischen Akteuren, so können im Rahmen von Arbeitsvorgängen tangible von intangible Austauschbeziehungen im Netzwerk von Akteuren unterschieden werden. Tangibler Austausch wird durch Energie- und Materialflüsse bestimmt. Intangibler Austausch, wie Wissen, verweist auf kognitive Prozesse und handlungsleitende Information. Werden nun TeilnehmerInnen und Austauschbeziehungen beschrieben, kann so die Struktur einer Organisation oder

238

6 Vorbereitung der Prozessimplementierung

eines Netzwerks erfasst werden. Austauschbeziehungen stellen die molekulare Ebene ökonomischer Aktivitäten dar. Somit besteht Wertschöpfung nicht nur aus tangiblen Transaktionen, sondern auch aus darüber hinausreichenden, intangiblen Transaktionen. Diese beziehen sich vor allem auf den kognitiven Austausch, da nachhaltiger Erfolg einer Organisation auf Informationsaustausch, Wissensteilung und offenen kognitiven Pfaden, die situationsgerechte Entscheidungsfindung (und damit erfolgreiches Bestehen einer Organisation) ermöglichen, beruht. Wissen und intangible Elemente verhalten sich allerdings anders als physische Ressourcen im Geschäftsleben, sodass sie nicht als tangibel betrachtet werden können. Sie konstituieren aufgrund ihrer Nähe zu lebenden Systemen eine eigene Kategorie von Austausch, und unterscheiden sich vom tangiblen Austausch mit Bezug zu Gütern, Dienstleistungen und Erträgen. Tangibler Austausch ist nach (Allee, 2009) definiert über Transaktionen, die Güter, Dienstleistungen oder Erträge beinhalten, z. B. physische Güter, Verträge, Rechnungen, Liefer- und Empfangsbestätigungen, Anfragen, Aufforderungen, Bietereinladungen, Zahlungen. Wesentlich dabei ist, dass wissensintensive Produkte und Dienstleistungen, welche Erträge bewirken und für die Zahlungen als ein Teil einer Dienstleistung oder eines Produkts geleistet werden bzw. aufgrund einer vertraglichen Verpflichtung zu leisten sind, auch als tangible Transaktionen betrachtet werden. Intangibler Wissens- und Informationsaustausch unterstützt Kernprozesse und damit die klassische Wertschöpfungskette, unterliegt aber keinerlei vertraglicher Verpflichtung. Intangibles sind „Extras“ bzw. (kleine) Aufmerksamkeiten, die Personen einander zukommen lassen, um Beziehungen aufzubauen und Abläufe ohne Störungen bzw. angenehm ablaufen zu lassen. Intangible Transaktionen inkludieren den Austausch strategischer Information, Planungswissen, fachlich-operatives Wissen, gemeinsame Planungsaktivitäten, kollaborative Gestaltung, und Policy-Entwicklung. Intangible Transaktionen sind folglich nicht vertraglich vereinbarte Leistungen zum Nutzen oder zur Unterstützung von Organisationen bzw. ihrer Mitglieder. Sie können von einer Person oder Gruppe zu anderen ausgeweitet werden, indem beispielsweise ein Experte für eine bestimmte Zeit von einer Organisationseinheit zur Mitarbeit aufgefordert wird, für den dies Prestige bedeutet. Anerkennung hilft oft in der Beziehungsarbeit, sodass Intangible Benefits echte Motivationsfaktoren für rege Beteiligung und aktive Teilnahme an Gruppenaktivitäten darstellen. Intangibles stellen das Kernstück allen menschlichen Handelns dar, und bestimmen somit auch sozio-ökonomisches Handeln. Intangible Transaktionen werden bewusst gesetzt. Sie können herbeigeführt und erkannt werden. Soll verstanden werden, wie Intangibles Wert generieren, ist zunächst zu verstehen, wie sie als Negotiables in ökonomischen Austauschbeziehungen sichtbar werden und wirken. Sie sind oft nicht unmittelbar sichtbar, vielmehr „verpackt“ in Dienstleistungen oder Produkten. Ein typisches Beispiel ist, Verständnis für eine Kundensituation aufzubauen (intangibel), bevor eine Leistung (tangibel) angeboten wird. Für eine Praxisgemeinschaft ist unmittelbar der störungsfreie Gang von Prozessen von Bedeutung. So sind jene Transaktionen wesentlich, welche (auch) mittels

6.1 Analyse und Modellierung

239

Intangibles gewährleisten, dass ein gemeinsamer Zweck des Handelns sichergestellt ist. Es gilt dies nun methodisch zu berücksichtigen. In einem Value Network werden mittels komplexer dynamischer Austauschvorgängen zwischen zwei oder mehreren Individuen, Gruppen oder Organisationen tangible und intangible Werte generiert, die den Gegenstand der reflektierenden Gestaltung darstellen.

6.1.3.2 Holomapping Die auf Vernetzung beruhende Sichtweise zur organisationalen Wertgenerierung bringt eine neue Form der Organisationsmodellierung mit sich, da jeder Austausch einen Mechanismus bzw. ein Medium als Enabler für Transaktionen erfordert. Diese können Arbeitsmittel wie e-mail oder face-to-face-Interaktionen in Communities of Practice sein. Typische Intangibles betreffen, wie oben bereits angesprochen, Wissen zur Informationsgewinnung von Kunden und Feedback zu (Produkt-)Entwicklungen. Die Darstellung tangibler und intangibler Austauschprozesse in einem Diagramm mit Flusselementen erlaubt die Dynamik von lebenden Systemen abzubilden. Zunächst werden die TeilnehmerInnen oder Rollen (auch Gruppen, Teams oder Organisationseinheiten, aber keine technischen Hilfsmittel) dokumentiert – sie bilden die Knoten des Netzwerks und werden oval visualisiert. Die TeilnehmerInnen senden oder ergänzen sogenannte Deliverables an andere TeilnehmerInnen. Pfeile zeigen die Richtung an, welche die Deliverables im Verlauf einer bestimmten Transaktion nehmen, bezeichnet mit dem jeweiligen Deliverable (vgl. Abb. 6.6). Transaktionen oder Aktivitäten werden als gerichtete Kanten (Pfeile) dargestellt, wobei der Ursprung bei einem/r TeilnehmerIn und das Ende bei einem/r anderen TeilnehmerIn zu sein hat. Der Pfeil zeigt Bewegung an und gibt die Richtung vor, in die etwas zwischen zwei TeilnehmerInnen geschieht. Im Gegensatz zu TeilnehmerInnen, welche zeitstabil sind, sind Transaktionen zeitlich begrenzt und flüchtig. Sie besitzen einen Startpunkt, eine Dauer und einen Abschluss. Deliverables hingegen sind echte „Dinge“, die sich von einem/r TeilnehmerIn zu einem/r anderen bewegen. Ein Deliverable kann materiell Abb. 6.6 Auszug einer Holomap zu Customer Service

240

6 Vorbereitung der Prozessimplementierung

(tangibel) sein, wie ein Dokument oder ein Tisch, oder ideell (nicht an Materie gebunden), wie eine Nachricht oder eine Anforderung, die nur verbal überbracht wird. Deliverables können auch intangibel sein, wie beispielsweise Wissen über einen bestimmten Sachverhalt (kognitiv) oder ein Gefallen (sozial/emotional). Pfeile sind immer nur in eine Richtung zulässig – sie umfassen eine einzige Transaktion. Beidseitige gerichtete Pfeile sind bedeutungslos, vielmehr verunmöglichen sie eine Analyse der Abläufe und Austauschbeziehungen. Ein Austausch tritt dann auf, sobald eine Transaktion in einem Deliverable resultiert, das zurückkommt. Er muss in der praktischen Handlungswelt in Organisationen nicht zwangsläufig gegeben sein. Tritt er allerdings auf, kann sich ein Value Network etablieren, mit Transaktionen als molekulare Elemente der Wertegenerierung. Wesentlich ist im Rahmen von Veränderungsprozessen die Ermächtigung der Beteiligten, und somit die Erstellung der Kommunikationslandkarte mit tangiblen und intangiblen Beziehungen (Holomap) durch die betroffenen Rollenträger, ebenso wie die Bearbeitung der erhobenen Daten durch diese im Rahmen der 3 Value Network-Analysen. Im Rahmen der Wissensgenerierung bzw. Wissenserhebung zu Beginn der Bearbeitung der Netzwerkstruktur überlegt jede/r einzelne TeilnehmerIn seine/ihre Rolle, welche er/sie dann den anderen TeilnehmerInnen mitteilt. So werden Beziehungen und Wechselwirkungen zwischen den einzelnen Rollen, die oft nicht bekannt sind, explizit und klarer. Die Rollen werden als Knoten symbolisiert, der Austausch von materiellen oder ideellen Werten wird in Form von Linien dargestellt, die die Rollen miteinander verbinden. Die Modellierung bildet die Basis für die anschließenden Analysen zur Wissensauswertung und -verarbeitung.

6.1.3.3 Exchange Analysis Ausgangsbasis für die Exchange Analyse stellt die Holomap dar. Tangibles (materielle Wertflüsse) im Netzwerk beziehen sich dabei auf den materiellen Austausch zwischen Personen (typischerweise Waren, Dienstleistungen und Umsatzerlöse). Sie repräsentieren Transaktionen, die auf Verträgen basieren. Intangibles (nicht-materielle, ideelle Wertflüsse) basieren im Unterschied zu Tangibles auf Wissen oder einem bestimmten Zusatznutzen. Sie sind nicht vertraglich fixiert oder kostenpflichtig. Oft erhobene Intangibles sind strategische Informationen, Prozess- oder Planungswissen sowie bestehende emotionale Komponenten wie gegenseitiges Vertrauen, gemeinsames Interesse, Wissensbedarf, Sicherheit etc. – siehe auch Abb. 6.6. Die Exchange-Analyse untersucht ein Value Network auf seine Schlüssigkeit, Robustheit und Nachhaltigkeit. Sie gibt Einblick in die aktuelle Struktur und Dynamik des Netzwerks. Folgende Fragestellungen sollen die Exchange-Analyse unterstützen: Wie fließen die Werte durch die Organisation? Zeichnet sich eine bestimmte Logik ab? Ist das Verhältnis des Austauschs von materiellen und ideellen Werten ausgeglichen oder überwiegt eine bestimmte Art des Austausches? Zeigt das Muster im Value Network reziproke Wertflüsse auf oder gibt es z. B. TeilnehmerInnen, die mehr Wertflüsse erhalten

6.1 Analyse und Modellierung

241

als bereitstellen? Gibt es im Netzwerk ineffektive Verbindungen, die Wertflüsse nicht weitergeben? Durch diese Fragen soll überprüft werden, ob das Netzwerk seinen Zweck erfüllt, fehlende Endknoten oder Verknüpfungen zu erkennen sind, und wie die Struktur des Netzwerkes optimiert werden kann. Sie gewährleisten einen generellen Überblick über Wertschöpfung und Wertverlust. Die Exchange-Analyse soll als Anregung zum Dialog dienen, komplexe Systeme zu verstehen und Systemdenken (Senge, 1990) fördern. Die Exchange-Analyse zu Customer Service, etwa in der Annahme, es handelt sich um die Organisation facebook, zeigt mehrere Befunde: Customer Service ist aus Sicht der Produktentwicklung tangible Senke – es empfängt nur Feature List. Der Verkauf bekommt zwar Lifestyle-Info, aber keine vertrauensbezogene Information. Die Übersetzung von Unsicherheit lastet auf Customer Service, zu Verkauf als auch zu Produkt-Entwicklung. Diese erste Auswertung kann ein Indiz für die in Abb. 6.6 gezeigte Informationsgebarung sein, wo Features zwar eine bestimmte Form der Rückkoppelung ermöglichen, die aber seitens der NutzerInnen gegebenenfalls mit Anfragen, die Unsicherheit widerspiegeln, quittiert wird.

6.1.3.4 Impact Analysis Die Impact-Analyse (Wirkungsanalyse) untersucht die Auswirkung jedes einzelnen WerteInputs auf die TeilnehmerInnen und legt so ihren Fokus auf die Empfangenden von WerteInputs. Diese Analyse zeigt also auf, welcher Input welche Reaktionen und Aktivitäten auslöst und wie sich dieser auf die materiellen und ideellen Vermögensgegenstände der betroffenen Empfänger auswirkt. Anschließend werden Kosten und Nutzen von WerteInputs mit niedrig, mittel oder hoch bewertet. Um einen besseren Überblick über diese Fragen zu erlangen, werden für jede/n einzelne/n EmpfängerIn von Werte-Inputs die Antworten in eine Tabelle eingetragen und die Ist-Situation analysiert. Die Tabelle zeigt die Impact-Analyse auf Basis der gewonnenen Erkenntnisse aus der Exchange-Analyse eines Customer Service-Mitarbeiters (vgl. Abb. 6.7). In der Tabelle wird abgebildet, von wem Input für welche Aktivitäten kommt und welche Auswirkungen in Form materieller oder ideeller Werteflüsse wahrgenommen werden. Wesentlich für die Abschätzung von Veränderungspotenzial sind die Spalteneinträge zu den allgemeinen Kosten und Risiken sowie zum Nutzen von dem angesprochenen Input. Die Daten der initialen Auswertung (Exchange-Analyse) stellen also eine Basis für die beiden weiteren Analysen dar, wobei aus der Sicht von erhaltenem Input (ImpactAnalyse) und übermitteltem Output (Value Creation-Analyse) wertebasiert detaillierte Auswertungen von Transaktionen erfolgen und so Erkenntnisse für Veränderungsprozesse gewonnen werden. So wird beispielsweise, wie in der Abb. 6.7 ersichtlich, ausgeführt, wann Features eine gelungene Form der Informationsrückkoppelung ermöglichen, um etwa Anfragen zu vermeiden, die Unsicherheit seitens der NutzerInnen widerspiegeln. Dies selbst, wenn der

Abb. 6.7 Teil einer Impact-Analyse zu Customer Service

242 6 Vorbereitung der Prozessimplementierung

6.1 Analyse und Modellierung

243

derzeitige Nutzen der Darstellung von Features seitens des Customer Service aufgrund mangelnder Verständlichkeit als gering eingeschätzt wird. Aus den Einträgen der Abb. 6.7 zur Feature List wird ebenfalls der für die Wertschöpfung relevante Bezugspunkt ersichtlich, und zwar die Qualität der Auskunftsleistung an Kunden durch Customer Service-MitarbeiterInnen. Aufbauend auf der Ist-Analyse können darauffolgend strategische Perspektiven abgeleitet werden und die Tabelle noch einmal im Vergleich dazu hinsichtlich ihrer geplanten, strategischen Aktivitäten (Soll-Analyse) ausgefüllt werden. Im gegenständlichen Fall kommt beispielsweise einer kundenorientierten Auskunftsleistung erhöhte Bedeutung zu.

6.1.3.5 Value Creation Analysis Die Value Creation-Analyse analysiert wie Werte bestmöglich erschaffen, erhöht und eingesetzt werden können. Wie die Impact-Analyse betrachtet die Value Creation-Analyse auch die einzelne Rolle im Bezug zum gesamten System. Der Unterschied zur ImpactAnalyse besteht darin, dass im Gegensatz zum Input diesmal der Sender oder Produzent von Output in seiner Rolle und mit seinen diesbezüglichen Aktivitäten betrachtet wird. Für jeden einzelnen Sender von Werte-Outputs wird analysiert, wie im Ist-Zustand Mehrwert und Wertezuwachs zum bestehenden Werte-Output realisiert wird. Auch hierzu wird eine Kosten/Nutzenabschätzung vorgenommen Bei der in der Abb. 6.8 gezeigten Value Creation-Analyse (oder Wertschöpfungsanalyse) wurde anhand erzielter Arbeitsergebnisse analysiert, wie Werte bestmöglich erschaffen, erhöht und eingesetzt werden können. Die Tabelle zeigt die Analyse auf Basis der Daten der Exchange-Analyse eines Kundenberaters. An Leistungsindikatoren können aus den Analysen die Anforderungen, die an den Verkauf sowie die Produktentwicklung gestellt werden, gefiltert werden. Die daraus

Abb. 6.8 Teil der fallbezogenen Value Creation-Analyse (Customer Service)

244

6 Vorbereitung der Prozessimplementierung

entwickelte Strategie kann mit der Aussage „Verfügbarkeit bzw. Transparenz von Information“ umrissen werden. So könnte als Veränderungsmaßnahme beschlossen werden, das identifizierte Wertschöpfungspotenzial im Value Network durch Erweiterung der tangiblen Informationsflüsse zwischen allen funktionalen Einheiten zu steigern. Nach der Darstellung der Ist-Situation ermöglicht auch die Value Creation-Analyse strategische Perspektiven abzuleiten. Hier sollte sich die Frage gestellt werden, welche Möglichkeiten in Zukunft noch genützt werden sollen, um Wertoptimierung beim WerteOutput zu generieren. Hinsichtlich der konkreten Frage „Was soll getan werden, um eine Wertsteigerung, -ausweitung oder -optimierung von Output zu erzielen?“ wird die Tabelle zur Analyse der Soll-Situation vergleichend ausgefüllt. Wesentlich zur Entscheidungsunterstützung sind die Einträge in die Spalten „Kosten/Risiken“ und „Nutzen“. Hier kann sich die Einschätzung vor allem bei Kosten und Risiken bei der Soll-Situation relativieren, wenn beispielsweise Inhalte in Schulungen aufgenommen werden sollte, da es Know How zur Erstellung entsprechender Unterlagen sowie der Bereitstellung effektiver Vermittlungsformate im Netzwerk gibt (etwa im Kontext „Report“ – dritter Tabelleneintrag in der Tabelle in Abb. 6.8). Eine Soll-Aufstellung berücksichtigt zumeist Wissen über die Machbarkeit bzw. Verfügbarkeit von Ressourcen und damit verbundene Aufwände zur Umsetzung von Maßnahmen, und zwar ohne eine diesbezügliche Entscheidung vorwegzunehmen (siehe Auswertung).

6.1.3.6 Auswertung Für die Auswertung werden in Tabellenform (Impact-Analyse, Exchange-Analyse, Value Creation-Analyse) Tangibles und Intangibles nach ihrer Bedeutung für die jeweilige(n) Rolle(n) bewertet. Anhand dieser Bewertungen werden Auswirkungen auf Beziehungen sichtbar und es können gezielt Maßnahmen gesetzt werden. Bislang wurde mit der Durchführung der Exchange-Analyse Einblick über die aktuelle Struktur und Dynamik des Netzwerks geschaffen. Die Durchführung der Impact-Analyse erlaubt allen TeilnehmerInnen ihre eigenen Rollen im Netzwerk kontextsensitiv zu erschließen. Die Impact-Analyse ermöglicht einen Überblick, welche Auswirkungen jede einzelne Wertetransaktion auf die TeilnehmerInnen hat. Die Value Creation-Analyse erlaubt hingegen zu befinden, wie Werte bestmöglich geschaffen, erhöht und eingesetzt werden können, und gegebenenfalls auf andere Rollen wirken bzw. diese miteinbeziehen sollten. Anhand der abgeleiteten Leistungsindikatoren kann nun eine Strategie entwickelt werden, um das identifizierte Wertschöpfungspotenzial im Value Network zu steigern. Typische Ergebnisse einer Auswertung zur Steigerung der Wertschöpfung umfassen die Berücksichtigung fehlender Austauschbeziehungen, also beispielsweise auf den gegenständlichen Fall bezogen: • Konkrete Anfragen an Kunden, um deren Anliegen (insbesondere jene, welche zur Verunsicherung von Kunden führen) aus Sicht der Produktentwicklung und des Verkaufs besser verstehen zu lernen – Customer Service nimmt hier eine Mittlerrolle

6.1 Analyse und Modellierung

245

ein, wodurch auch der tangible Report aufgewertet wird und das Feedback konkrete Hinweise zur Verbesserung bzw. Schaffung von Features beinhalten kann. • Feedback von Kunden, das sowohl den zukünftigen Umgang als auch den bisherigen Umgang mit Features, also im Besonderen die Produktentwicklung betrifft. Sobald die Verständlichkeit der Darstellung explizit adressiert wird, kann ein diesbezüglicher Informations(rück)fluss zur Produktentwicklung (und auch zum Verkauf) sichergestellt werden – eine weitere Maßnahme, die den kundengerechten Zugang zum Produkt erleichtert. Beide Maßnahmen zeigen die Notwendigkeit vernetzter Darstellung von Austauschbeziehungen. Es ist nicht unbedingt die Unmittelbarkeit von Austauschbeziehungen, sondern vielmehr die Verkettung von Austauschbeziehungen, die Mehrwert bewirken kann. Würde beispielsweise die Produktentwicklung (z. B. Softwaredesigner) beginnen, direkt mit Kunden zu kommunizieren, wäre zunächst eine bestimmte Gesprächsbasis herzustellen. Derartige Maßnahmen könnten für den zu erreichenden strategischen Zweck sogar kontraproduktiv sein und die bestehende Verunsicherung aufseiten der Kunden noch erhöhen, und damit dem angestrebten Ziel zuwider laufen. Die Ergänzungen des Netzwerks erlauben somit eine kontextsensitive Systembetrachtung der Wertschöpfung durch materielle und ideelle Leistungen, die zwischen den beteiligten Akteuren fließen sollten. Die vervollständigte Value Network Map, wie in Abb. 6.9 gezeigt, bildet die Grundlage für die weitere Entwicklungsplanung. Sie zeigt die Anfrage an Kunden sowie das Feedback zur Verständlichkeit erstmals als Tangible Deliverable, wodurch sich die Informiertheit der Beteiligten durch die Transparenz und Verfügbarkeit von Information erhöhen soll. Langfristig anzustreben ist als intangibler Austausch zwischen Kunden und Customer Service ein durch wechselseitige Sicherheit geprägter Umgang, der sich mit Loyalität der Kunden zur Organisation ausdrücken lässt. Erst durch den offenen Austausch an Information wird nachhaltiges Customer Knowledge Management möglich. Abb. 6.9 Adaptiertes Netzwerk

246

6 Vorbereitung der Prozessimplementierung

Value Networks betrachten Systeme in ihrer Gesamtheit und berücksichtigen deren Komplexität. Sie ermöglichen die ganzheitliche Identifikation von materiellen als auch ideellen Werten. Letztere bestimmen jedenfalls indirekt die Qualität materieller Austauschbeziehungen und sind folglich bei der Entwicklung sozio-technischer Systeme mit zu berücksichtigen. Der durch Value Networks einnehmbare Fokus auf die beteiligten Individuen fördert die Sinnstiftung und Motivation derselben zur Beteiligung an Reflexion und aktiven Mitgestaltung. Die vorgestellten Erhebungen und Analysen erlauben die Explikation einzelner Rollen und deren direkt oder indirekt wahrgenommenen Beitrag zur Wertschöpfung eines organisationalen Systems durch Akteure. Dies erleichtert die Rollenklärung sowie das Verständnis von Zusammenhängen, da diese mittels Wertaustauschbeziehungen grafisch in Holomaps visualisiert, und somit rollenspezifisch rückgekoppelt werden. Sie stellen somit einen viablen Ausgangspunkt partizipativer Gestaltung soziotechnischer Systeme dar.

6.1.3.7 Potenziale für Prozessanalyse und -modellierung Für die Gestaltung von Prozessen und deren Modellierung lassen sich aus der Value Network Analysis mehrfach Potentiale schöpfen: • Die Value Network Analysis erlaubt die Repräsentation einer Situation, wie sie von HandlungsträgerInnen wahrgenommen wird. Die Darstellung der Situation erfolgt anhand von Rollen, die durch Knoten eines Netzes von Akteuren repräsentiert werden. Da jede/r RollenträgerIn diese Analyse durchführen kann, können individuell wahrgenommene Interaktionsmuster mit der Wahrnehmung anderer Rollenträger gegenübergestellt und abgeglichen werden. Somit erlaubt die Value Network Analysis die strukturierte Feststellung von unterschiedlich wahrgenommenen Interaktionsmustern zwischen HandlungsträgerInnen aus deren Sicht, wobei die unterschiedlichen Interaktionsmuster auch kumuliert dargestellt werden können. • Die Erfassung und Darstellung der Ist-Situation stellt einen Referenzpunkt dar, von dem aus Veränderungspotenziale erschlossen werden können. Damit können für alle Beteiligten nachvollziehbar Änderungen von Interaktionen auf der Basis einer gemeinsamen Ausgangslage diskutiert werden. • Die Value Network Analysis erlaubt die Bestimmung von Rollen, welche nicht zwingend funktional in einer Organisation, etwa im Organigramm, zu finden ist. Die Rollenbestimmung orientiert sich an den Kommunikations- und Interaktionsmustern, welche im Rahmen der Aufgabenerfüllung und dem wahrgenommenen Organisationsgeschehen als relevant erachtet werden. Somit rücken die fachliche und die Interaktionsebene in den Vordergrund. • Im Rahmen der Erarbeitung von Veränderungsvorschlägen werden anstelle von Forderungen einzelner RollenträgerInnen Vorschläge an andere im Sinne individueller Angebote an das Kollektiv gemacht. Eine derartige Vorgangsweise stellt den Adressaten frei, dieses Potenzial zu nutzen. Sämtliche Angebote werden im Kontext ihrer Herkunft dargestellt und bezüglich ihrer organisationalen Wirksamkeit von den jeweilig

6.1 Analyse und Modellierung

247

vorschlagenden HandlungsträgerInnen bewertet und können darauf aufbauend im Kollektiv abgestimmt werden. • Interaktionsbeziehungen werden differenziert nach vertraglich verpflichtenden Leistungen (Tangibles) und nicht nur aus der jeweiligen Rolle nach vertragsmäßig geregelten Leistungen (Intangibles). Damit wird bereits evident, in welcher Form die Bewältigung von Aufgaben erfolgt, ob eher nach formellen Grundsätzen oder Interaktionen, welche eine erfolgreiche Prozesserfüllung begünstigen, oder nach informellen Grundsätzen. Gleiches gilt für Änderungsvorschläge, die ebenfalls in formelle Strukturen (als Teil von funktionalen Rollenbeschreibungen) oder auf informeller Ebene angesiedelt (als freiwilliger Beitrag) sein können. • Die Veränderung einer Ist-Situation in einen Soll-Zustand kann auf mehreren Wegen erfolgen: (i) eine informelle (intangible) Interaktion wird formeller Teil einer Rolle (tangible); (ii) eine formelle (tangible) Interaktion wird weggelassen oder informeller Teil einer Rolle (intangible); (iii) eine tangible bzw. intangible Beziehung wird neu eingeführt und ergänzt bestehende Interaktionsmuster. • Interaktionsbeziehungen sind direkt überführbar in konkrete Prozessschritte, da sie zeitlich aneinandergereiht die Erfüllung von Aufgaben durch die RollenträgerInnen repräsentieren. Somit kann aus einer Holomap ein Prozessmodell abgeleitet werden, welches den Austausch von Leistungen zwischen Akteuren (im Gegensatz zu linearisierten Funktionsschritten) in den Mittelpunkt stellt. Insgesamt stellt die Value Network Analysis eine diagrammatisch/tabellarische Technik zur Organisationsentwicklung mit dem Ziel von Prozessdefinitionen bzw. ausführbaren Prozessen dar, welche eine Abbildung von Interaktionsstrukturen auf kommunikationsorientierte Ansätze wie S-BPM direkt unterstützt. Sämtliche Informationen werden dabei aus der Sicht von beteiligten bzw. verantwortlichen RollenträgerInnen generiert, und können mittels entsprechender Werkzeugunterstützung wie beispielsweise digitalem Concept Mapping (Oppl und Stary, 2009, 2011, 2014; Oppl et al., 2016) effektiv im Rahmen von transformativen Veränderungsprozessen eingesetzt werden, wie die bisherigen Praxiseinsätze zeigen (Fleischmann et al., 2015; Stary, 2014).

6.1.4

Strukturierte Aktivsätze

6.1.4.1 Vorbemerkung Im Folgenden wird eine Vorgehensweise beschrieben, die ausgehend von natürlichsprachlichen Beschreibungen zu einem formalen Verhaltensmodell führt. Diese Vorgehensweise orientiert sich an den Aktivsätzen von natürlichen Sprachen. Der Ablauf wird anhand des Projekts Poly Energy Net (NET), einem vom Deutschen Bundesministerium für Wirtschaft und Energie geförderten Ansatz, eingeführt. In diesem Projekt galt es eine Lösung für ein sich selbst organisierendes verteiltes Energieversorgungssystem zu entwickeln. In den folgenden Abschnitten wird gezeigt, wie die dazugehörige Software

248

6 Vorbereitung der Prozessimplementierung

entwickelt wurde, und zwar ausgehend von einer allgemeinen Beschreibung bis hin zu einem präzisen Modell, das dann in einer ersten Stufe auf Basis von Prozessspezifikationen in ein Programm umgesetzt wurde. Die vorgestellten Schritte von einer informellen Beschreibung eines Prozesses zu einem formalen Modell des Ablaufs müssen nicht in der angegebenen Reihenfolge ausgeführt werden. Sie dienen vielmehr dem Ziel einer präzisen Prozessbeschreibung. Stellt sich in einem Schritt heraus, dass in einem vorangegangenen Schritt etwas vergessen wurde, oder dass es vorteilhafter ist, Teilabläufe anders zu gestalten, so wird diese Änderung in dem momentan bearbeiteten Schritt aufgenommen. Diese Änderung wird nicht in den vorangegangenen Beschreibungen nachgezogen. Um einen ersten Entwurf einer Prozessbeschreibung zu erstellen, können die in Abschn. 5.3 beschriebenen Vorgehensweisen des Design Thinking eingesetzt werden. Alle Dokumente der vorangegangenen Dokumentation sind nach Abschluss einer detaillierteren Beschreibung standardmäßig obsolet und nicht mehr gültig, ausgenommen, es wird explizit darauf hingewiesen, dass eine vorangegangene Beschreibung noch gültig ist (z. B. als Übersichtsdokument). Erfahrungsgemäß gelingt es nicht, mehrere Dokumente konsistent zu halten. Es sollte daher nur ein gültiges Dokument geben, sodass nach Abschluss der Vorbereitung ein formales Verhaltensmodell zur Verfügung steht. Änderungen sollten in der Regel nur noch an diesem Modell vorgenommen werden. Bei der Erstellung eines Prozessmodells kann auch mit einem beliebigen Schritt begonnen werden. So können beispielsweise bei einer natürlich-sprachlichen Beschreibung nur Aktivsätze verwendet werden. Damit fallen die Schritte, welche eine Spezifikation in beliebiger Form in eine aktive Beschreibungsform transformieren, weg. Es kann auch mit der Identifizierung der Handelnden begonnen und mit der Detaillierung deren Handeln fortgefahren werden, einschließlich der Kommunikation mit anderen Handelnden. Die konkrete Vorgehensweise hängt von den Umständen und den Vorlieben der Beteiligten ab.

6.1.4.2 Prozessbeschreibung in natürlicher Sprache Das Prozessgeschehen wird mehr oder minder strukturiert in natürlicher Sprache erzählt. Es gibt keinerlei Vorgabe hinsichtlich der Struktur des zu erstellenden Dokuments oder des zu verwendenden Vokabulars. Die Ersteller einer Prozessbeschreibung können ihren Vorlieben folgen. Abb. 6.10 zeigt einen Textauszug aus der groben Anforderungsbeschreibung für das Energiemanagementsystem. Die anfängliche freie Verwendung der natürlichen Sprache erfordert von den Beteiligten keine speziellen Methodenkenntnisse. Das Erfordernis solcher Kenntnisse könnte eine große Hürde für das Einbinden von Betroffenen aus den verschiedenen Fachbereichen darstellen. Textuelle Beschreibungen können durch geeignete Bilder ergänzt werden. Abb. 6.11 zeigt eine funktionale Struktur des zu erstellenden Systems. Eine solche funktionale Struktur ist eine erste Annäherung an die Spezifikation eines Prozesssystems. Aufbauend auf diese mehr strukturellen Beschreibungen kann eine erste ablauforientierte Spezifikation erstellt werden. Einen Auszug einer Ablaufbeschreibung zeigt Abb. 6.12.

6.1 Analyse und Modellierung

249

Abb. 6.10 Anforderungen an ein holares Energiemanagementsystem

Ergänzt wird diese Ablaufbeschreibung durch eine Illustration der Auswirkungen auf ein holares Energienetz. So verweisen Textstellen zu Konsequenzen von Schalterstellungen in Abb. 6.12 auf die entsprechenden Schalter in Abb. 6.13. Die am Anfang verwendeten Werkzeuge für eine erste Anforderungsdefinition und Ablaufspezifikation sind nicht strukturiert. Es können einfach Texte und ergänzende Zeichnungen beliebiger Art verwendet werden. In den nachfolgenden Schritten wird diese nicht schematische Beschreibung eines Prozesses Zug um Zug in eine präzise Ablaufbeschreibung überführt.

6.1.4.3 Prozessbeschreibungen in Aktivform Informelle Prozessbeschreibungen in natürlicher Sprache enthalten sehr oft Passivsätze (siehe auch die Ablaufbeschreibung in Abb. 6.12). Passivsätze enthalten allerdings keine direkte Aussage über den Ausführenden einer Aktion. Passivsätze werden dann verwendet, wenn der Ausführende einer Aktion nicht wesentlich ist. Allerdings ist dies bei Prozessen nicht gegeben. Prozessbeschreibungen müssen den Ausführenden einer Handlung enthalten. Es gilt also alle Passivsätze in Aktivsätze umzuwandeln. Dazu müssen zunächst die aktiven Elemente identifiziert werden. Aktive Elemente können Menschen sein, aber auch

250

6 Vorbereitung der Prozessimplementierung

Abb. 6.11 Funktionsblöcke eines holaren Energiemanagementsystems

Abb. 6.12 Dynamik eines holaren Energiemanagementsystems

6.1 Analyse und Modellierung

251

Abb. 6.13 Beispiel eines holaren Energiemanagementsystems

Softwaresysteme, die automatisch ablaufen und bestimmte Aktivitäten ausführen, sowie physikalische Systeme oder beliebige Kombinationen aus diesen Grundelementen. So kann in unserem Beispiel die Leitstation eine Kombination aus Software, Menschen und elektrischen Systemen sein. Die Software fordert einen Bediener auf einen bestimmten Messwert abzulesen und ihn einzugeben. Die Software veranlasst abhängig vom eingegebenen Messwert, dass ein Schalter geschlossen wird. Um zu vermeiden, dass eine Prozessbeschreibung zu sehr vom organisatorischen und technischen Umfeld abhängig ist, werden abstrakte Handelnde eingeführt. Solche abstrakten Handelnde sind Entitäten, die Nachrichten senden, empfangen oder interne Tätigkeiten ausführen. Abb. 6.14 zeigt das Funktionsdiagramm mit zugeordneten aktiven Elementen. Diese abstrakten aktiven Elemente werden als Subjekte bezeichnet, in Anlehnung an die Subjekte in Aktivsätzen. Subjekte sind die Rollen in Prozessen. Die Aufgaben der identifizierten Subjekte können für ein besseres Verständnis strukturiert wie in Abb. 6.15 beschrieben werden. Durch die Einführung von Handelnden in Form von Subjekten können nun alle Passivsätze durch entsprechende Aktivsätze ersetzt werden. Damit wird die Prozessbeschreibung inhaltsreicher. Abb. 6.16 zeigt eine Prozessbeschreibung mit Aktivsätzen in Tabellenform. Die Nummerierung der Sätze gibt bereits den Kontrollfluss wider. Die Nummer der Nachfolgeaktion wird in der so benannten Spalte angegeben. Hängt die Nachfolgeaktion von bestimmten Ergebnissen der Aktion ab, wird diese Bedingung in

252

6 Vorbereitung der Prozessimplementierung

Abb. 6.14 Subjektorientierte Betrachtung eines holaren Energiemanagementsystems

der Spalte Nachfolgeaktion mit beschrieben. Abhängig von der gültigen Bedingung kann es eine andere Nachfolgeaktion geben. Eine Tabelle mit dem Kontrollfluss eines Prozesses kann der Ausgangspunkt für ein kontrollflussorientiertes Prozessmodell sein. Die einzelnen Handelnden sind die Swim Lanes in BPMN bzw. in einer Swim-Lane-orientierten EPK oder in UMLZustandsdiagrammen. Allerdings sollten diese Modellierungsmethoden nur verwendet werden, wenn in einem Prozess keine asynchronen Ereignisse, wie z. B. die Möglichkeit Bestellungen zu ändern, vorkommen, und die Parallelität der Handelnden nicht modelliert werden soll. Darüber hinaus sollte die Anzahl der Handelnden nicht zu groß sein. SwimLane-Darstellungen sind in der Regel flach, d. h. es gibt keine Hierarchien von Swim Lanes. Mehr als fünf Swim Lanes führen zu unübersichtlichen Darstellungen. So hat ein Service-Prozess mindestens die Swim Lanes Kunde, Call Center, First Level Support, Abrechnung und gegebenenfalls Kundenrückmeldung. Die Erfahrung zeigt, dass in realen Prozessen in der Regel etwa zehn Handelnde und mehr involviert sind. Unübersichtlich werden Swim-Lane-Diagramme auch wenn der Kontrollfluss mehrere Swim Lanes kreuzen muss, um in eine andere Swim Lane zu wechseln. Bei organisations- oder unternehmensübergreifenden Prozessen in einem verteilten Umfeld sind Kontrollflüsse keine handhabbare Darstellung. In einer verteilten Umgebung sind Nachrichten die anschaulichere Art die Zusammenarbeit von einzelnen Handelnden zu modellieren.

6.1 Analyse und Modellierung

253

Name

Typ (Person, Organisation, Komponente, System, Subsystem, Anwendung)

Beschreibung

Spezifika in diesem Use Case

Holon Manager (HM)

Softwareservice

Die Rolle eines HM beschreibt eine Menge an Funktionalitäten, die durch eine oder mehrere Softwarekomponenten bereitgestellt werden

Beispiele für Use-Case-relevante Funktionalitäten sind: Einen Holon-Koordinator ermitteln In der Rolle eines HolonKoordinators agieren

Holares Element (HE)

Komponente

Holare Elemente sind Erzeugungs-, Verbrauchs-, Umwandlungs-, Speicher- oder Leitungselemente. Ein HE besitzt immer eine Verbindung mit dem Energiesystem, eine Verbindung mit dem IKT System ist optional aber die Regel. Ein HE besitzt minimal eine (i.d.R. IT-technische) Ansteuerbarkeit, meist auch eine Auskunfts-fähigkeit.

Beispiele für Use-Case-relevante Funktionalitäten sind: HE können Statusinformationen senden HE können Steuerbefehle empfangen

HolonKoordinator (HK)

Softwareservice

Holon-Koordinatoren erbringen die Basisfunktionen zum Betrieb eines Holons. Sie steuern Holare Elemente im eigenen Holon unter Nutzung der Funktionen eines Holon-Managers an.

Beispiele für Use-Case-relevante Funktionalitäten sind: -

-

Ermittlung eines zulässigen Holons (ggf. unter Berücksichtigung weiterer Ziele). Kriterien sind noch zu definieren Schaltbefehle für Etablierung eines Holons ermitteln Schaltbefehle in eimen Holon initiieren und deren Umsetzung überwachen.

Steuerbox

System

Eine Steuerbox kann Schaltbefehle für holare Elemente empfangen und umsetzen.

Leitstand (Leitstelle)

Person/ Organisation

Überwacht Netze und veranlasst Maßnahmen zur Sicherstellung einer optimalen Versorgung

Beispiele für Use-Case-relevante Funktionalitäten sind:

Überwacht Netze mittels bestimmter Services

Beispiele für Use-Case-relevante Funktionalitäten sind:

Netzüberwacher

Softwareservice/ System

-

-

Detektion von Netzzuständen Kommunikation von Netzzuständen

Detektion von Netzzuständen Kommunikation von Netzzuständen

Abb. 6.15 Aufgaben der identifizierten Subjekte

6.1.4.4 Rollenorientierte Prozessbeschreibung in Tabellenform Im letzten Schritt vor der eigentlichen Prozessmodellierung wird die Prozessbeschreibung entsprechend der Handelnden strukturiert. Alle Sätze mit denselben Handelnden als Subjekt werden in einer Tabelle zusammengefasst. Dazu kann es notwendig sein, dass die Prozessbeschreibung mit Interaktionen zwischen Subjekten ergänzt werden muss. Phrasen wie „informiert Subjekt xy“ oder „tritt in Verbindung mit“ usw. werden ersetzt durch Sende- und Empfangsaktionen (siehe Abb. 6.17). Der Satz 2 „Netzüberwacher meldet

254

Nr.

6 Vorbereitung der Prozessimplementierung

Handlung

Hinweise

Folgeaktion

1.

Netzüberwacher stellt Spannungsabfall im

nutzt dafür Funktionen aus der Funktionsgruppe

Niederspannungsnetz fest

„Messen“

2.

Netzüberwacher meldet Situation an Leitstelle

3.

Leitstelle identifiziert und lokalisiert den Fehler

2

3 nutzt dafür Funktionen aus der

4

Funktionsgruppen „Überwachen“ und „Messen“ (Bemerkung: Was passiert, wenn Leitstelle den Fehler nicht identifizieren kann?) 4.

Leitstelle informiert Holon-Manager (HM) bzw.

Achtung: hier kann ein single-point-of-failure

Holon-Koordinatoren im betroffenen Netzgebeit

bzw. Engpass vorliegen; ist ggf. durch einen

5

dezentralen Mechanismus zu ersetzen 5.

(sofern angesprochen) Holon-Koordinatoren

nutzt dafür Funktionen aus der Funktionsgruppe

treten mit Holon-Managern in den betroffenen

(Holonmanagement)

6

Holonen in Verbindung 6.

(sofern kein Holon-Koordinator tätig wird)

7

Holon-Manager identifizieren einen HM, der die Koordinationsaufgabe übernimmt 7.

Holon-Koordinator und betroffene Holon-

nutzt dafür Funktion „Holonbildung“ aus der

Manager ermittein eine plausible neue Hono-

Funktionsgruppe „Holonmanagement“

8

Konstellation 8.

8

Holon-Koordinator meldet den errechneten Vorschlag an die Leitstelle

9.

10

Holon-Koordinator geht in Zustand „alert“ und wartet auf Rückmeldung von der Leitstelle

10.

...

...

Abb. 6.16 Ablauf im holaren System

Situation an Leitstelle“ aus Abb. 6.16 wird in eine Sende- und eine Empfangsaktion umgewandelt. In Abb. 6.16 entspricht dies der Aktion 2 (Netzüberwacher sendet StatusSchwarz an Leitstand) in den Zeilen für den Netzüberwacher. Das Gegenstück dazu ist die Zeile 1 beim Leitstand. Nach dem Erstellen der Verhaltenstabellen kann ein formales Modell in einer geeigneten Modellierungssprache abgeleitet werden. Es sollte dabei eine Sprache verwendet werden, in der die für wichtig erachteten Aspekte des betrachteten Prozesses anschaulich und präzise ausgedrückt werden können. In unserem Beispiel haben wir S-BPM ausgewählt. Abb. 6.18 zeigt in der linken Hälfte die Netzwerkstruktur des betrachteten Prozesses. Die Rechtecke mit den abgerundeten Ecken stellen die beteiligten Handelnden dar. Die Pfeile zwischen den Handelnden sind mit den ausgetauschten Nachrichten beschriftet. Die Zahlen an den Nachrichtennamen entsprechen den Satznummern in der Abb. 6.17. Das Diagramm rechts neben der Prozessstruktur zeigt das Verhalten des Subjekts „Holonkoordinator“. Die Kreise mit den Buchstaben E (Empfang) und S (Senden)

6.1 Analyse und Modellierung

Nr.

Subjekt (Akteur)

Prädikat

255

Objekt

Indirektes Objekt

Ergebnis

Weiter bei

Netzüberwacher 1

Netzüberwacher

misst

im Nieder-

Spannung

spannungsnetz

Spannungs-abfall

2

Spannungs-

3

anstieg 2

3

Netzüberwacher

Netzüberwacher

sendet

sendet

(1) Status-

an Leitstand

Schwarz

(Leitstelle)

(10) Status-Grün

an Leitstand

gesendet

1

gesendet

1

empfangen

2

Fehler gefunden

3

Fehler nicht

?

(Leitstelle) Leitstand 1

2

Leitstand

Leitstand

empfängt

identifiziert

(1) Status-

von Netzüber-

meldung

wacher

den Fehler

und lokalisiert

gefunden 3

Leitstand

sendet

(2) Status

an* Holon-

gesendet

4

Koordinatoren 4

Leitstand

empfängt

(5) Vorschlag

5

Von* HolonKoordinator

5

Leitstand

prüft

Vorschlag

6

Leitstand

sendet

(6) V-Ange-

an* Holon-

nommen

Koordinatoren

...

...

...

...

...

angenommen

6 7

...

...

Abb. 6.17 Ablauf im Holaren System (präziser)

sind Kommunikationszustände. Übergänge von Kreisen mit einem E sind mit den in diesem Zustand erwarteten Nachrichten beschriftet. Die Übergänge nach S-Zuständen sind mit den in diesem Zustand gesendeten Nachrichten beschriftet. Alle anderen Übergänge definieren lokale Operationen auf lokalen Daten.

6.1.5

Prozessmodellierung

6.1.5.1 Auswahl der Modellierungssprache In der Folge werden exemplarisch einige Faktoren angeführt, welche die Auswahl einer geeigneten Modellierungsnotation bzw. -sprache erleichtern sollen. Dazu zählen die Rahmenbedingungen eines BPM-Vorhabens, die Handhabbarkeit der Sprache sowie die Unterstützung der nachgelagerten Aktivitäten wie Validierung (siehe auch Giaglis 2001;

256

6 Vorbereitung der Prozessimplementierung

Abb. 6.18 Verhaltensbeschreibung des Subjekts „Holonkoordinator“

Lin et al. 2002; Pinggera et al. 2013; Recker et al. 2009; Weske et al. 2012–2008; Muehlen und Recker 2008): Bezüglich Rahmenbedingungen interessiert vor allem die Frage“ was die Eigenschaften des zu modellierenden Sachverhalts sind. Bestimmend für die Auswahl einer Modellierungssprache sollten vor allem die folgenden Eigenschaften eines Sachverhalts sein: • Asynchrone Ereignisse: Liegen derartige Ereignisse vor, dann sollte eine Modellierungssprache die Möglichkeit bieten, die damit verbundene Parallelisierung von Prozessen oder Prozessschritten derart abzubilden, dass gegebenenfalls eine Ausführung die Parallelität widerspiegelt. Dies bedeutet, dass die Modellierungssprache Konstrukte zur Darstellung asynchroner Ereignisse aufweist, welche diese zeitliche Qualität explizit enthält. Damit kann zur Ausführungszeit entsprechend eine Laufzeitumgebung konfiguriert werden.

6.1 Analyse und Modellierung

257

• Organisations- und unternehmensübergreifend: Ist ein Sachverhalt nicht nur für eine bestimmte Organisation oder deren Einheiten, sondern auch für vernetzte Partner relevant, die außerhalb der unmittelbaren Tätigkeitsbereiche liegt, wie beispielsweise in der Zulieferindustrie, dann sollten ausgewiesene Modellierungsmechanismen oder Sprachkonstrukte zur Verfügung stehen, welche eine Kapselung organisationsexterner Sachverhalte ermöglichen. Damit wird eine Einbettung externer Akteure möglich, ohne im Detail deren Abläufe kennen und repräsentieren zu müssen. • Anzahl der Handelnden: Diese Kenngröße scheint auf den ersten Blick nicht unbedingt relevant für die Auswahl einer Modellierungssprache. Sie gewinnt allerdings an Bedeutung, wenn es zum einen um die Komplexität von Prozessen geht, und zum anderen um die Verständlichkeit der Modelle. Schließlich spielt auch die Instanz-Modell-Beziehung in diesen Faktor hinein. Besteht eine Vielzahl an handelnden Akteuren, dann sollte eine Notation auch Modellierungsmechanismen oder Sprachkonstrukte aufweisen, welche diese sowohl sichtbar machen, als auch aggregieren oder mittels anderer Perspektiven zugänglich machen (z. B. Funktionssicht). Bezüglich Handhabbarkeit interessiert vor allem die Frage, wie der Sachverhalt beschrieben werden soll. Bestimmend für die Auswahl sollten hier vor allem die folgenden Eigenschaften bzw. Qualitäten einer Modellierungssprache sein: • Anzahl der Symbole: Die Anzahl der Symbole kann zum einen mächtige Modelle einfach überschaubar gestalten lassen, aber zum anderen eine unerwünschte Verkürzung von Sachverhalten mit sich bringen. • Definition der Symbole: Der Gebrauch der Symbole sollte eindeutig, d. h. objektiv nachvollziehbar für Modellierende sein. Dies erleichtert die Effektivität und Effizienz bei der Erstellung von Modellen. • Verfügbarkeit der Werkzeuge zur Modellbeschreibung: Die Verfügbarkeit von digitalen Werkzeugen zur einfachen und korrekten Darstellung von Sachverhalten bestimmt die Gebrauchstauglichkeit einer Modellierungssprache mit. Ein Syntaxeditor bei diarammatischen Sprachen hilft beispielsweise, syntaktisch korrekte Modelle zu erstellen sowie umfangreiche Sachverhalte gebrauchstauglich zu strukturieren. • Möglichkeiten der Hierarchisierung von Modellen: Diese Eigenschaft erlaubt, vernetzte Sachverhalte aus einer Top-down-Perspektive zu erschließen. Dadurch wird üblicherweise die Lesbarkeit von Modellen erleichtert und damit die Verständlichkeit abgebildeter Sachverhalte für nicht unmittelbar Beteiligte erhöht. Bezüglich Unterstützung weiterer Aktivitäten interessiert vor allem die Frage‚ wie die Unterstützung des Modells für nächste Schritte ist. Für die Auswahl sollten in diesem Kontext vor allem die folgenden Features einer Modellierungssprache betrachtet werden: • Validierungswerkzeuge: Kann ein Modell validiert werden? Dies bedeutet, dass mittels eines Werkzeugs festgestellt werden kann, ob die Notation und damit alle verwendeten

258

•

•

•

•

6 Vorbereitung der Prozessimplementierung

Konstrukte im Sinne der Syntax der Sprache sowie im Sinn der Intention des abgebildeten Sachverhaltes korrekt verwendet wurden. Optimierungswerkzeuge: Kann ein Prozess mit Hilfe seines Modells optimiert werden? Die Optimierung ist der erstmaligen Modellierung und Validierung nachgelagert und zielt auf die optimale Verteilung von Aufgaben und optimale Nutzung von Ressourcen ab. So soll mittels eines Werkzeugs festgestellt werden können, ob die Notation die Optimierung von modellierten Prozessen durch entsprechende Konstrukte der Sprache oder durch spezielle Mechanismen zulässt bzw. aktiv unterstützt (etwa durch Vorschläge oder Referenzmodelle). Werkzeuge für die organisatorische Einbettung: Kann die Integration eines modellierten Prozesses in eine Organisation mit Hilfe eines Werkzeugs realisiert werden? Dieser Schritt ist der erste zur Implementierung von Prozessen und erfordert, dass mittels eines Tools bestimmt werden kann, welche Aufgaben- oder Rollenträger bzw. welche Organisationseinheiten den abgebildeten Sachverhalt in der Praxis ausführen können sollen. Auf dieser Basis kann danach die entsprechende Zuordnung zur organisationalen Umsetzung von Prozessmodellen vorgenommen und nach Bedarf wieder geändert werden. Werkzeuge für die technische Einbettung: Kann die Integration eines modellierten Prozesses in eine (informations-)technische Infrastruktur bzw. Informationssystemarchitektur mit Hilfe eines Werkzeugs realisiert werden? Dieser Schritt ist der zweite erforderliche zur Implementierung von Prozessen. Er bedarf der Bestimmung mittels eines Werkzeugs, welche technischen Systems den abgebildeten Sachverhalt in der Praxis ausführen können. Auf dieser Basis kann danach die entsprechende Zuordnung zur technischen Umsetzung von Prozessmodellen vorgenommen und nach Bedarf wieder geändert werden. Werkzeuge für die Inbetriebnahme und den Betrieb: Kann die Inbetriebnahme und der Betrieb eines modellierten Prozesses in einer Organisation mit Hilfe eines Werkzeugs unterstützt bzw. sichergestellt werden? Dieser Schritt ist erforderlich, sobald ein Prozess „produktiv“ geschaltet wird, d. h. nach seiner organisationalen und technischen Implementierung in den operativen Betrieb einer Organisation überführt bzw. in deren operativen Praxis wirksam wird. In diesem Kontext sollte ein Werkzeug helfen, die Einführungsphase eines modellierten Prozesses zu unterstützen, also etwa die Reihenfolge festzulegen, welche Prozessschritte in welcher Reihenfolge in den operativen Betrieb übernommen werden. Ein entsprechendes Werkzeug sollte auch die Überwachung des Einsatzes von implementierten Prozessen unterstützen und so helfen, den operativen Betrieb einer Organisation sicherzustellen und deren Weiterentwicklung effektiv zu gestalten. Letzteres kann etwa durch Annotation an Prozessmodellen, welche Ausführungshindernisse markieren, erfolgen.

6.1.5.2 Modellierung durch Konstruktion Bei der Konstruktion eines Prozessmodells beginnt die Modellierung mit einem „leeren Blatt Papier“. Mit den Informationen aus der Prozessanalyse wird Schritt für Schritt der

6.1 Analyse und Modellierung

259

Prozess beschrieben. Die erforderlichen Aktivitäten umfassen, abhängig vom gewählten Ansatz, mehrere Aktivitäten: • • • •

Beschreibung der Prozesse mit ihren Beziehungen (Prozessnetzwerk) Identifikation des zu beschreibenden Prozesses Identifikation der an dem Prozess beteiligten Akteure bzw. Systeme Festlegen der zwischen den Akteuren bzw. Systemen ausgetauschten Informationen im Rahmen des Kontroll-, Daten- und Nachrichtenflusses zur Bearbeitung von Geschäftsfällen. Dies inkludiert auch die Umsetzung von Geschäftsregeln, da sie das Verhalten von Akteuren und Systemen unmittelbar beeinflussen • Beschreiben des Verhaltens der einzelnen Akteure bzw. Systeme, insbesondere durch Funktionsschritte und deren zeitlich-kausalen Zusammenhang entsprechend dem modellierten Sachverhalt • Definition der Geschäftsobjekte bzw. Daten und deren Verwendung Diese Aktivitäten werden entsprechend der ausgewählten Sprache in eine bestimmte Reihenfolge gesetzt und führen dementsprechend zu unterschiedlich detaillierten Darstellungen von Sachverhalten.

6.1.5.3 Modellierung durch Restriktion Neben der Modellierung durch Konstruktion gibt es grundsätzlich noch die Möglichkeit der Modellierung durch Restriktion. Dabei wird von allgemeinen Prozessmodellen ausgegangen. Ein typisches Beispiel ist der kommunikationsorientierte Zugang, wie bei S-BPM verfolgt. Im universalen Prozessmodell kann jeder an einem Prozess beteiligte Akteur bzw. jedes System an jedes andere beteiligte System bzw. jeden anderen Akteur jederzeit eine Nachricht senden bzw. von diesen empfangen. Diese Nachricht hat den allgemeinen Namen „Nachricht“ und kann als Geschäftsobjekt beliebige Medien übertragen. Das Ergebnis ist ein Universalprozess, der durch die Anzahl seiner Subjekte gekennzeichnet ist. Diese werden als Kästen mit Subjekt 1..n gekennzeichnet. Deren wechselseitige Interaktionsmöglichkeiten werden durch vorab gesetzte Pfeile zwischen den SubjektKästchen gekennzeichnet. Daraus resultiert für jedes Subjekt ein gleichartiges initiales Verhalten. Im Rahmen der Modellierung durch Restriktion wird in folgenden Schritten zu einem detaillierten Sachverhalt vorgegangen: (i) Anzahl der Subjekte und Subjektbezeichner bestimmen, (ii) Kommunikationspfade reduzieren; (iii) Nachrichtentypen spezifizieren, (iv) Verhalten der Subjekte spezifisch anpassen, (iv) Geschäftsobjekte spezifizieren und verfeinern. Werden andere, etwa funktionsorientierte Ansätze gewählt, dann können grundsätzliche Strukturen verallgemeinert, etwa in Form von Referenzmodellen, zur Verfügung gestellt werden. Dabei werden auch verhaltensorientiere Muster zum Einsatz kommen, etwa vorangegangene Ereignisse zu Funktionen oder Bedingungen, die nach Abarbeiten einer Funktion den weiteren Verlauf von Geschäftsprozessen bestimmen.

260

6 Vorbereitung der Prozessimplementierung

6.1.5.4 Kombination Während bei der Konstruktion von Prozessmodellen die Modellierung mit einem „leeren Blatt Papier“ beginnt, welches um Informationen aus der Prozessanalyse Schritt für Schritt erweitert wird, geht man bei der Modellierung durch Restriktion von einer verallgemeinerten Struktur von Prozessmodellen und deren Bestandteile aus. Ein typisches Beispiel einer Kombination beider Ansätze stellt der Fall dar, der dem „middle out“ Ansatz entspricht. Eine Instanz dieses Falls ist, mit einer Konstruktion zu beginnen, und sobald ein (wiederkehrendes) Muster auftritt, ein Referenzmodell zum Einsatz zu bringen und zu reduzieren bzw. zu konkretisieren. Weitere Anwendungsinstanzen wären ein Mustervergleich sowie der Start mit wiederkehrenden (Routine-)Prozessen. Letztere kehren den oben genannten Fall um, und erlauben spezielle Ausprägungen von Prozessverläufen in generalisierte Prozessarchitekturen einzubetten. Der Mustervergleich hingegen stellt eine Art Kontrollvorgang dar, wobei mittels eines verallgemeinerten Musters die Vollständigkeit bzw. Korrektheit eines Modells überprüft werden kann.

6.2

Qualitätskontrolle: Validierung und Optimierung

Die Validierung steht in enger Beziehung zur Modellierung. In der Modellierung wird der Prozessablauf entsprechend der Zielsetzung beschrieben. Dies bedeutet, dass während der Modellierungstätigkeit die Frage mitschwingt, ob das Modell den gesetzten qualitativen und quantitativen Zielen entspricht. Die Prüfung, ob ein Prozessmodell den gesetzten Zielen entspricht, wird als Validierung bzw. Optimierung bezeichnet. Somit laufen während der Modellierung permanent Validierung und Optimierung mit. Am Ende der Modellierung wird nun abschließend geprüft, ob das Gesamtmodell den gesetzten Zielen entspricht. Eine Validierung zeigt, ob der Prozess alle Anforderungen erfüllt und die beabsichtigten Ergebnisse erreicht. Wesentlich ist auch, ob der Prozess die gewünschten Ergebnisse mit dem geringst möglichen Aufwand erreicht. Die Qualitätskontrolle bei Geschäftsprozessen hat also zwei wesentliche Aufgaben. Sie soll die Effektivität und die Effizienz von Prozessen prüfen. Effektivität bedeutet, dass der Prozess die an ihn gestellten Anforderungen erfüllt, d. h. das gewünschte Ergebnis (Output) liefert. Effizient ist der Prozess dann, wenn er mit möglichst geringem finanziellen und zeitlichen Mitteleinsatz ausgeführt werden kann, um das gewünschte Ergebnis zu liefern. Dies soll durch die Optimierung erreicht werden. Diese Qualitätskontrollen müssen möglichst frühzeitig einsetzen, und zwar bevor ITSysteme aufwändig entwickelt und die späteren Anwender geschult werden. Abb. 6.19 fasst die einzelnen Aspekte der Validierung und Optimierung zusammen. Die Überprüfung eines Prozessmodells wird durch entsprechende Werkzeuge und Referenzmodelle unterstützt. Für die Validierung gibt es manuelle Hilfsmittel wie z. B. Checklisten oder Rollenspiele, während für die Optimierung Simulationssoftware eingesetzt werden kann.

6.2 Qualitätskontrolle: Validierung und Optimierung

261

Abb. 6.19 Struktur der Qualitätssicherung eines Prozessmodells

Die Ergebnisse der Überprüfung werden in To-Do-Listen für die Abarbeitung aufbereitet, d. h. es wird erneut mit Modellierungsaktivitäten gestartet. Dieser Zyklus wiederholt sich, bis die Überprüfung zu einem zufriedenstellenden Ergebnis führt.

6.2.1

Validierung

Voraussetzung für die Validierung ist ein Modell, das den zu repräsentierenden Sachverhalt wiedergibt. Es wird überprüft, ob das Modell das erwartete Ergebnis gemäß den spezifizierten Qualitätsmerkmalen liefert und ob der Prozess zur Erreichung der Unternehmensziele beiträgt. Dieser Aspekt wird als semantische Richtigkeit bezeichnet. Diese ergibt sich aus dem Konsens der Führungskräfte sowie der Fach- und Methodenexperten, die das Modell als zutreffend erachten. Von der semantischen Richtigkeit ist die syntaktische Gültigkeit abzugrenzen, welche die Einhaltung der festgelegten Beschreibungsregeln betrifft, also die Frage, ob die Beschreibungsmittel entsprechend den Vorgaben der Modellierungssprache eingesetzt wurden.

6.2.1.1 Manuelle Prozessvalidierung Abb. 6.20 zeigt eine allgemeine Vorgehensweise bei der manuellen Validierung. Hier wird mit Hilfe von Checklisten die Prozessdokumentation überprüft. Die Prozessdokumentation umfasst die Beschreibung der Ziele, Inputs, Ergebnisse, auslösende Ereignisse und natürlich das Modell des Prozesses. Die Prozessdokumentation soll von allen betroffenen Parteien eines Prozesses anhand der Checklisten überprüft werden. Zur Vorbereitung eines solchen Reviews werden die Prozessbeschreibung und eine Checkliste, nach der die Prozessbeschreibung geprüft werden soll, an die Stakeholder kommuniziert. Diese Checkliste enthält Fragen, welche die Gutachter bezüglich des Prozesses beantworten sollen. Beispiele für solche Fragen sind:

262

6 Vorbereitung der Prozessimplementierung Start

Verteilung der Prozessdokumentation und Checkliste an die Beteiligten

Individueller Review der Prozessdokumentation und Ausfüllen der Checkliste

Konsolidierung der Antworten in den Checklisten

Unklarheiten/stark divergierende Einschätzungen?

ja

Klärung (Workshop, Einzelgespräche)

Überarbeitung der Prozessdokumentation

ja Überarbeitungsnotwendigkeit?

Ende

Abb. 6.20 Ablauf einer manuellen Prozessprüfung

• Unterstützt der Prozess die Ziele des Unternehmens? • Sind die Ziele des Prozesses definiert? • Ist der Nutzen des Prozesses in der Zielsetzung klar beschrieben und ist ersichtlich, welche Wertschöpfung er für wen liefert? • Welche Risiken birgt der Prozess? • Ist ein Prozessverantwortlicher (Process Owner) benannt? • Sind die Befugnisse des Prozessverantwortlichen (Process Owner) festgelegt und sind diese ausreichend? • Gibt es Kennzahlen, mit denen die Zielerreichung bewertet werden kann? • Sind die Messverfahren für die Kennzahlen eindeutig festgelegt? • Werden die Zielwerte für die Kennzahlen des Prozesses systematisch festgelegt und liefern sie eine Aussage über den Wertbeitrag des Prozesses? • Unterstützt der Prozess die Politik und Strategie des Unternehmens bzw. der ITOrganisation? • Ist der Prozessablauf beschrieben? • Sind die Eingaben und Ergebnisse des Prozesses beschrieben? • Ist klar, wer (Organisationen, Rollen, Personen) welche Eingaben liefert und welche Ergebnisse entgegennimmt? • Werden die Beschreibungskonventionen für Prozesse eingehalten? • Ist definiert, wer für die einzelnen Schritte des Prozesses verantwortlich ist (Organisationen, Rollen oder Personen)?

6.2 Qualitätskontrolle: Validierung und Optimierung

263

• Ist das Vorgehen in dem Prozess auf die Interessensgruppen (beispielsweise Kunden) ausgerichtet? • Ist das Vorgehen im Prozess klar begründet? • Gibt es neben der Prozessbeschreibung noch ausreichend Hilfsmittel für die Ausführung des Prozesses (Checklisten, Arbeitsanweisungen etc.)? • Ist der Geltungsbereich des Prozesses eindeutig festgelegt? • Sind die Beziehungen des Prozesses zu anderen Prozessen beschrieben bzw. definiert? Die Fragenliste ist nur exemplarisch und nicht vollständig. In Unternehmen werden Fragenlisten mit bis zu 100 Fragen verwendet. Die Befunde der einzelnen Parteien werden konsolidiert. In einem gemeinsamen Workshop klären die Beteiligten anschließend Fragen und Probleme und legen die notwendigen Überarbeitungen fest. Dieser Zyklus wiederholt sich bis gemeinsam entschieden ist, dass keine weiteren Änderungen mehr notwendig sind. Das Lesen von umfangreichen Prozessdokumentationen und deren Abgleich mit langen Checklisten ist sehr ermüdend. Die Erfahrung zeigt, dass mit zunehmender Seitenzahl die Intensität der Prüfung nachlässt. Die ersten Seiten werden noch genau gelesen. Dann nimmt die Aufmerksamtkeit und damit die Qualität der Checklistenbearbeitung immer mehr ab. Um die Schwächen einer visuellen Begutachtung zu kompensieren, wurde eine stärker formalisierte Version des Reviews entwickelt, der „Walk Through“, der sich überwiegend auf das Prozessmodell bezieht.

6.2.1.2 Walk Throughs Ähnlich wie bei der Code Inspection in der Programmierung, wird beim Walk Through ein Prozess gemeinsam mit ausgewählten Prozessbeteiligten Schritt für Schritt durchgegangen und besprochen. Um das schrittweise Durchgehen lebendiger zu gestalten, kann eine formale Prozessbeschreibung mit Hilfe eines praktischen Beispiels für den betreffenden Geschäftsvorfall durchlaufen werden. Ein Prozessbeteiligter geht anhand eines konkreten Beispiels die Geschäftsprozessbeschreibung schrittweise durch. Zu jedem Prozessschritt stellt ein Experte gezielte Fragen, um die Effektivität der Prozessbeschreibung zu hinterfragen. Es werden beispielsweise das Verständnis der Fachbegriffe, die fachliche Notwendigkeit von Schritten sowie die Vollständigkeit der Prozessbeschreibung hinterfragt. Auf diese Weise wird die Prozessspezifikation überprüft. Ein Walk Through wird mit etwa zwei bis vier Prozessbeteiligten durchgeführt, die verschiedene Benutzergruppen vertreten. Die „Autoren“ der Prozessbeschreibung (beispielsweise Prozessmanager), sollten sich dabei im Hintergrund halten, damit Kritik offen formuliert werden kann. Alle Kritikpunkte und Anregungen werden gesammelt, dokumentiert und anschließend mit den Prozessbeteiligten ausgewertet. Diese Auswertung führt zu einer Überarbeitung des Prozesses. Abb. 6.21 gibt einen Eindruck von einem Walk-Through-Workshop. Die schrittweise Analyse des Prozesses kann durch entsprechende Werkzeuge unterstützt werden. Beispielsweise zeigt ein Tool das Prozessmodell am Bildschirm, hebt

264

6 Vorbereitung der Prozessimplementierung

Abb. 6.21 Konventioneller Walkthrough

den aktuellen Prozessschritt farblich hervor und springt nach Weiterschalten durch den Analysten zur nächsten Aktivität im Modell. Bei der Verwendung von Swim-LaneMethoden zur Modellierung kann dies mitunter sehr unübersichtlich und aufwändig werden, da Prozessmodelle mit Swim Lanes nicht hierarchisch beschrieben werden können. Insbesondere komplexe Modelle benötigen deshalb sehr viel Platz.

6.2.1.3 Rollenspiele Eine fortgeschrittene Variante des Walk Through ist eine erlebbare Überprüfung von Prozessmodellen durch Rollenspiele. Diese sind insbesondere dann gut einsetzbar, wenn kommunikationsorientierte Modellierungssprachen verwendet werden. Die Handelnden sind dann bereits identifiziert und die Rollen werden geeigneten Personen zugeordnet. Ein Spielleiter löst Prozessanstöße aus und stellt die notwendigen Eingaben zur Verfügung. Damit arbeiten die einzelnen Rolleninhaber dann Prozessinstanzen gemäß den Prozessbeschreibungen ab, testen die Abläufe und besprechen und dokumentieren identifizierte Auffälligkeiten. Analog gilt dies für Beobachter, welche die Bearbeitung z. B. als Experten verfolgen. Nach der Abarbeitung einiger Prozessinstanzen werden die Befunde bewertet und notwendige Anpassungen identifiziert. Die Ausführung von Rollenspielen kann durch geeignete IT-Werkzeuge unterstützt werden. Die Rolleninhaber erhalten ihre Rollenbeschreibung dabei nicht auf Papier, sondern sie werden mittels Software durch den Prozess geführt, die insbesondere die Ablauflogik implementiert. Diese Software wird dabei unmittelbar und automatisch aus dem Prozessmodell generiert. Voraussetzung dafür ist, dass die Semantik der verwendeten Prozessmodellierungssprache eindeutig definiert ist. Dies ist beispielsweise für BPMN bedingt und für EPKs gar nicht der Fall, jedoch bei S-BPM dank einer eindeutigen, formalen Semantik erfüllt.

6.2 Qualitätskontrolle: Validierung und Optimierung

265

Abb. 6.22 Szenerie für ein IT-gestütztes Rollenspiel

Abb. 6.22 zeigt, wie eine IT-gestützte Validierung aussehen kann. Der Vorteil eines ITgestützten Rollenspiels ist, dass die Vorbereitungszeit sehr gering ist und das Prozesserleben schon sehr nahe an der späteren Prozessausführung im Echtbetrieb liegt.

6.2.2

Optimierung

Nach der Prüfung der Effektivität (liefern die Prozesse überhaupt das gewünschte Ergebnis?), muss überprüft werden, ob das Ergebnis mit dem geringsten möglichen Einsatz von Ressourcen zustande kommt. Eine Optimierung durch manuelle Prüfung, Walk Throughs oder Rollenspiele ist nur sehr eingeschränkt möglich. Die hierbei gewonnenen Erkenntnisse liefern nur eine Annäherung für die Ermittlung des Ressourcenbedarfs bei einer angenommenen Anzahl von Prozessdurchläufen. Eine systematische Ermittlung des Ressourcen- und Zeitbedarfs ist nur durch eine Simulation möglich. Voraussetzung für eine Simulation ist allerdings, dass das Prozessmodell ausführbar ist. Bei der Simulation von Geschäftsprozessen werden die von einem Prozess verarbeiteten Geschäftsereignisse zufällig gemäß einer angenommenen Wahrscheinlichkeitsverteilung erzeugt. In der Regel ist dies die Exponentialverteilung mit einem vermuteten oder durch Beobachtung ermittelten Erwartungswert. Den einzelnen Arbeitsschritten werden

266

6 Vorbereitung der Prozessimplementierung

die entsprechenden Ressourcen mit der benötigten Arbeitszeit zugeordnet. Die benötigte Arbeitszeit folgt in der Regel einer Normalverteilung mit aus der Beobachtung ermittelten Erwartungswerten und Standardabweichungen. Im Rahmen der Simulationsläufe werden Informationen über die Ablauffähigkeit von Prozessen, über Prozessschwachstellen und Ressourcenengpässe geliefert. Auf Basis der simulierten Prozesskennzahlen können bereits im Vorfeld kostenintensiver Prozessänderungen innerhalb eines Unternehmens verschiedene Alternativen bewertet und ein realitätsgetreues Benchmarking durchgeführt werden. Moderne Werkzeuge und Simulationsmethoden ermöglichen die Analyse und Optimierung der Prozesse bezüglich der Kosten, der Durchlaufzeiten, der Auslastung oder der Engpässe. Zusätzlich bildet die Simulation der Geschäftsprozesse eine Ausgangsbasis zur Einführung der Prozesskostenrechnung anstelle der relativ ungenauen Zuschlagskalkulation. Die Gewinne bzw. Verluste der einzelnen Bereiche werden damit frühzeitig transparent. Die Durchführung einer Simulationsuntersuchung setzt wie bereits erwähnt eine präzise Beschreibung des betrachteten Prozesses voraus. Dies bedeutet, dass zur Definition des Prozessablaufes eine formale Methode verwendet werden muss. Zusätzlich sind möglichst genaue Kenntnisse über die Wahrscheinlichkeitsverteilungen, deren Parameter und der untersuchten Kennzahlen notwendig. In der Praxis werden Simulationen wegen des damit verbundenen hohen Aufwandes nicht häufig eingesetzt, obwohl die gewonnenen Erkenntnisse überzeugend sein können.

Literatur Allee V (2009) Value-creating networks: organizational issues and challenges. Learn Organ 16(6):427–442 Fleischmann A, Schmidt W, Stary C (Hrsg) (2015) S-BPM in the Wild. Springer International Publishing, Cham. http://link.springer.com/10.1007/978-3-319-17542-3 Giaglis GMR (2001) A Taxonomy of business process modeling and information systems modeling techniques. Int J Flex Manuf Syst 13(2):209–228. Überblick über Prozessmodellierungs-Ansätze Liebert W-A (2015) Metaphern der Selbstermächtigung Max Stirners Philosophie des Einzigen als Bezugsstelle einer diskursiven Bewegung der Spätmoderne. Diskurs – interdisziplinär. De Gruyter, Berlin Lin FR, Yang MC, Pai YH (2002) A generic structure for business process modeling. Bus Process Manag J 8(1):19–41 Muehlen MZ, Recker JC (2008) How much language is enough? Theoretical and practical use of the business process modeling notation. In: Seminal contributions to information systems engineering, vol. 5074 of Lecture notes in computer science. Springer, pp 465–479. http://link. springer.com/10.1007/978-3-540-69534-9_35 Oppl S (2016–2002) Articulation of work process models for organizational alignment and informed information system design. Inf Manag 53(5):591–608. http://www.sciencedirect.com/science/ article/pii/S0378720616300015

Literatur

267

Oppl S (2017) Supporting the collaborative construction of a shared understanding about work with a guided conceptual modeling technique. Group Decis Negot 26(2):247–283. http://link.springer. com/article/10.1007/s10726-016-9485-7 Oppl S, Hoppenbrouwers S (2016) Scaffolding stakeholder-centric enterprise model articulation. In: IFIP Working Conference on the Practice of Enterprise Modeling, vol. 267 of The practice of enterprise modeling. Springer, Berlin/Heidelberg, S 133–147 Oppl S, Stary C (2009) Tabletop concept mapping. In: Proceedings of the 3rd International Conference on Tangible and Embedded Interaction. Cambridge, United Kingdom, S 275–282 Oppl S, Stary C (2011) Effects of a tabletop interface on the co-construction of concept maps. In: IFIP Conference on Human-Computer Interaction. Springer, Berlin, S 443–460 Oppl S, Stary C (2014) Facilitating shared understanding of work situations using a tangible tabletop interface. Behav Inf Technol 33(6):619–635 Oppl S, Stary C, Vogl S (2016) Recognition of paper-based conceptual models captured under uncontrolled conditions. IEEE Trans Human-Mach Syst 47(2):206–220 Pinggera J, Soffer P, Fahland D, Weidlich M, Zugal S, Weber B, Reijers HA, Mendling J (2013) Styles in business process modeling: an exploration and a model. Softw Syst Model 14(3):1055– 1080 Recker JC, Rosemann M, Indulska M, Green P (2009) Business process modeling-a comparative analysis. J Assoc Inf Syst 10(4):1 Seel NM (1991) Weltwissen und mentale Modelle. Hogrefe, Göttingen Senge PM (1990) The fifth discipline: the art and practice of the learning organization. Doubleday/Currency, Doubleday/Currency. Stary C (2014) Non-disruptive knowledge and business processing in knowledge life cycles – aligning value network analysis to process management. J Knowl Manag 18(4):651–686 Weske M, Weidlich M, Mendling J (2012–2008) Propagating changes between aligned process models. J Syst Softw 85(8):1885–1898

7

Umsetzung

Die Ausführungen zur Modellbildung und Vorbereitung der Implementierung haben mit der Spezifikation effektiver und effizienter Prozesse die Grundlagen gelegt für deren Umsetzung in den operativen Betrieb. Das vorliegende Kapitel befasst sich folgerichtig mit dem Aufbau einer Ausführungsumgebung und der Abwicklung von Prozessinstanzen im Echtbetrieb. Die Überführung der Prozessspezifikation in einen ausführbaren Prozess umfasst die Aktivitätenbündel organisatorische Implementierung, IT-Implementierung und den laufenden Betrieb mit dem Monitoring. Abb. 7.1 zeigt die Einordnung dieser Aktivitäten in das Prozessmanagementmodell. Ausgangspunkt ist die Prozessdokumentation als Ergebnis der vorgelagerten Aktivitätsbündel. Bei der Umsetzung der Prozesse in der Unternehmensorganisation und -infrastruktur wird die Zuordnung der modellierten Prozessaktivitäten zu Aufgabenträgern (Menschen, Softwaresysteme, Maschinen und Kombinationen davon) vorgenommen, welche die Aktivitäten zur Laufzeit von Prozessinstanzen ausführen. Mit der Inbetriebnahme geht der organisatorisch und technisch in die Unternehmensumgebung eingebettete Prozess in das Tagesgeschäft über. Im Rahmen des Monitorings wird sein Verhalten mit Verfahren wie Process Mining beobachtet und analysiert. Auswertungen darüber koppeln Informationen für (kontinuierliche) Verbesserungen in relevante Aktivitätenbündel zurück. In den folgenden Abschnitten werden ausgewählte Methoden für die angesprochenen Themen der Umsetzung vorgestellt. Die Aktivitäten des Prozessmanagementmodells bieten den konzeptionellen Rahmen für die Umsetzung des Geschäftsprozessmanagements in ein Handlungssystem. Wie bereits in vorherigen Kapiteln diskutiert, stellen die Phasen zwar ein gewisses Ordnungskriterium dar, können aber grundsätzlich in beliebiger Reihenfolge durchlaufen werden. Jede der Phasen beinhaltet dabei ein Bündel an Aktivitäten, die typischerweise in ihr angewendet werden. Jeder Geschäftsprozess befindet sich in einem bestimmten

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_7

269

270

7 Umsetzung

Abb. 7.1 Einordnung der Umsetzung in das Prozessmanagementmodell

Augenblick in einer bestimmten Phase – oder in anderen Worten, in einem bestimmten Zustand: er ist modelliert, er ist in Kraft gesetzt, er wird ausgeführt, er wird analysiert. Das Lebenszyklusmodell definiert damit so etwas wie einen Phasen- oder Zustandsraum für Geschäftsprozesse.

7.1

Prozessdokumentation

Da die Geschäftsprozesse eines Unternehmens definieren, wie dort gearbeitet wird, insbesondere wie Produkte und Dienstleistungen entwickelt, hergestellt und geliefert werden, ist es zweckmäßig eine Prozessdokumentation zu erstellen. Diese sollte naturgemäß allen Mitarbeitern zentral zur Verfügung gestellt werden. Die Dokumentation muss spätestens zu Beginn der Umsetzung (Implementierung) vorliegen. Die Geschäftsprozessdokumentation ist das Ergebnis der Aktivitätsbündel während der Vorbereitung. Heutzutage bietet sich dazu die Form digitaler Dokumente an. Die Bereitstellung erfolgt dabei idealerweise über ein üblicherweise vorhandenes Intranet. Damit kann auch in groben Zügen eine einfache Zugriffskontrolle gestaltet werden. Die Dokumente selbst können beispielsweise nicht veränderbare PDF-Dateien (eventuell auch digital signiert), oder HTML-Dateien, die über einen Browser betrachtet werden können, sein. Für kleinere Organisationen und Unternehmen reicht es in der Regel aus, wenn für die Erstellung und Wartung der Prozessdokumentation die üblicherweise verwendete

7.1 Prozessdokumentation

271

Bürosoftware genutzt wird. Für umfangreichere Sammlungen erscheint die Nutzung spezifischer Software, sogenannter Business-Process-Management-Systeme (BPMS), überlegenswert. Jedenfalls muss die gewählte Form die Menschen, die damit arbeiten, und die darauf aufbauenden Managementsysteme bestmöglich unterstützen. Jedenfalls sollten die Dokumente eine eindeutige Bezeichnung, eine Versionsnummer und ein Datum beinhalten. Soll eine Textverarbeitung benutzt werden, empfiehlt sich eine Formatvorlage, um ein einheitliches Erscheinungsbild und definierte Inhalte vorzugeben. Des Weiteren empfiehlt sich eine Liste mit allen Dokumenten inklusive Historie, um einen allgemeinen Überblick zur Verfügung zu stellen. Verantwortlich für die Aktualität und Vollständigkeit einer Prozessdokumentation ist der Prozesseigner, bzw. Prozesskoordinator. Das Prozess-Office gibt vor, was die Prozessdokumentation beinhalten soll und stellt entsprechende Vorlagen und Erklärungen bereit. Falls ein dediziertes IT-System (BPMS) genutzt werden soll, kann die Schulung aller Mitarbeiter – abhängig davon, welche Rolle diese einnehmen – nur dringend angeraten werden. Im Sinne eines geplanten Veränderungsprozesses (Change Management), sollten die Mitarbeiter in angemessener Form auch in den Auswahl- oder Entwicklungsprozess eingebunden werden. Folgende Inhalte einer Prozessdokumentation haben sich im Allgemeinen bewährt: • Ziel des Prozesses – ein kurzer beschreibender Text, in dem der Bezug des Prozesses zu übergeordneten Unternehmenszielen erläutert wird (Strategiebeitrag). • Auslöser des Prozesses – Angabe, durch welches Ereignis eine Prozessinstanz gestartet wird und wer dieses Ereignis erzeugen kann. • Input – Auflistung und Beschreibung der Informationen, Dokumente und auch physikalischen Artefakte, die als Input benötigt werden und von wem sie bereitgestellt werden. • Output – Auflistung und Beschreibung der Informationen, Dokumente und physikalischen Artefakte, die vom Prozess erzeugt werden; eventuell auch Qualitätskriterien pro Kunde. • Gültigkeitsbereich und organisatorische Rahmenbedingungen – gegebenenfalls Abgrenzung zu anderen Geschäftsprozessen, oder organisatorische Einschränkung (z. B. nur gültig für den Geschäftsbereich Großkunden). • Definition der Begriffe und Abkürzungen – im Dokument verwendete Abkürzungen. Wenn man diese auch gleich in einem unternehmensweiten Verzeichnis konsolidiert sammelt, erhält man ein Glossar der wichtigsten Begriffe in einem Unternehmen, sowie einheitliche Definitionen in allen Prozessdokumentationen. • Übersichtsbeschreibung des Prozessmodells – textuelle Darstellung der Handelnden/Rollen und der Prozessschritte. • Prozessmodell – Ein Prozessmodell (grafische Darstellung), erstellt in einer vereinbarten Modellierungssprache; für die Erstellung der Prozessmodelle sollte es einheitliche Konventionen geben, um einen Wildwuchs zu vermeiden (z. B. bezüglich Farben und Beschriftung von Notationselementen).

272

7 Umsetzung

• Technische Rahmenbedingungen – Auflistung und Beschreibung technischer Hilfsmittel, die im Prozess benötigt werden. Darstellung der informationstechnischen Unterstützung bzw. Abhängigkeiten; z. B. der Verweis auf bestimmte Module eines ERP-Systems. • Feedback-Mechanismen – Darstellung, wie Prozessbeteiligte Probleme bei der Ausführung (z. B. falsch oder nicht ausreichend modellierte Logik) artikulieren oder Verbesserungsvorschläge einbringen können. Dies sollte eine im Geschäftsprozessmanagement implementierte Standardprozedur sein. • Ausnahmen – eventuelle Ausnahmen vom Prozessmodell, d. h. Aktivitäten, die nicht im Prozessmodell berücksichtigt werden, da entsprechende Fälle nur selten vorkommen. • Schnittstellen mit anderen Prozessen – eine Darstellung, in welchen anderen Geschäftsprozessen der Output eines Prozesses benötigt wird (definiert damit den Prozesskunden bzw. dessen Erwartung). • Kennzahlen (PPI) – Liste, Definition und Erklärung der vorgesehenen Prozesskennzahlen. Leistungsmessungen – Darstellung, wie und wann die Kennzahlen zu messen und zu berechnen sind. Verweis auf eventuell verfügbare andere Dokumente. • Berichtswesen – Darstellung, in welcher Form und wann die Prozesskennzahlen an wen zu berichten sind. Verweis auf eventuell verfügbare andere Dokumente. • Eskalationen – Definition von Prozeduren, die anlaufen sollen, wenn der Toleranzbereich von Kennzahlen verletzt wird. • Audits und Compliance – Verweis auf entsprechende Richtlinien. Falls einzelne Aktivitäten in einem Geschäftsprozess aus Gründen der Compliance aufgenommen wurden, sollte dies dokumentiert werden, damit diese nicht im Rahmen einer Effizienzverbesserung eliminiert werden. Es empfiehlt sich, solche Aktivitäten in einer visuellen Darstellung farblich zu markieren. Ferner hat sich in der Praxis als hilfreich erwiesen, (tabellarisch) zu dokumentieren, in welchen Geschäftsprozessen die Einhaltung welcher Normen und Gesetzte notwendig ist. Ähnliche Überlegungen gelten für externe (z. B. Qualitätsnormen) oder interne (z. B. Risikoanalysen) Audits. Selbstverständlich sind nicht immer alle Punkte für jeden Geschäftsprozess relevant und anderseits können bei Bedarf auch weitere Aspekte ergänzt werden.

7.2

Verknupfung von Elementen der Unternehmensarchitektur: organisatorische und IT-Implementierung

7.2.1

überblick

Wie in den Kap. 1 und 2 angesprochen sind Geschäftsprozesse Teil der Unternehmensarchitektur. Unternehmensarchitekturen gehen auf die internen Aspekte und Strukturen eines Unternehmens ein. Sie sind im Wesentlichem Modelle der Interna eines Unternehmens

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

273

Abb. 7.2 Vom Prozessmodell zur Prozessausführung

und umfassen nicht nur organisatorische, sondern auch technische Aspekte, insbesondere die eingesetzte IT. Bei der Umsetzung der Prozessmodelle gilt es nun den Bezug des Prozessmodells zu den vorhandenen Ressourcen herzustellen. Abb. 7.2 zeigt die einzelnen Stufen vom Prozessmodell zur auszuführenden Prozessinstanz. In einem Prozessmodell werden die Handelnden, die Handlungen, deren Reihenfolgen und die Objekte, auf denen die Handlungen ausgeführt werden, beschrieben. Handlungen (Aktionen, Aktivitäten) können von Menschen, Softwaresystemen, physikalischen Systemen oder einer Kombination aus diesen Grundtypen von Handelnden ausgeführt werden. Wir bezeichnen sie als Aufgabenträger. So kann ein Softwaresystem die Aktion „Berechnung des Steuersatzes“ automatisch erledigen, während ein Mensch in Kombination mit einem Programm die Aktivität „Erfassen der Bestellung“ ausführt. Der Mensch tippt dabei die Bestelldaten über eine Bildschirmmaske ein. Die Software prüft die eingegebenen Daten auf Plausibilität und speichert sie ab. Tätigkeiten können aber auch rein manuell ausgeführt werden, etwa wenn ein Lagerarbeiter einen Kommissionierungsauftrag auf Papier bekommt, diesen ausführt, auf dem Auftrag als ausgeführt kennzeichnet und an den Lagermeister zurückgibt. Bei der Erstellung eines Prozessmodells ist oft noch nicht bekannt, welche Typen von Handelnden welche Aktionen ausführen. Deshalb kann es sinnvoll sein, zu Beginn einer Prozessbeschreibung davon zu abstrahieren, in dem man abstrakte Handelnde einführt. Eine Modellierungssprache sollte erlauben, solche Abstraktionen zu verwenden. Dies bedeutet, es muss bei der Definition der Prozesslogik noch keine Aussage gemacht werden, durch

274

7 Umsetzung

welchen Typ ein Akteur realisiert wird. In S-BPM repräsentieren die Subjekte abstrakte Handelnde. In BPMN können Pools oder Swim Lanes als abstrakte Handelnde interpretiert werden, während man in EPKs dafür Rollen verwenden kann. In der Beschreibung der Ablauflogik eines Prozesses werden auch die einzelnen Aktivitäten noch unabhängig von ihrer Realisierung beschrieben. Beispielsweise wird bei einer Aktion „Erstellen eines Kommissionierungsauftrags“ nicht festgelegt, ob hier der Bearbeiter ein Papierformular oder eine Bildschirmmaske ausfüllt, oder ob ein Softwaresystem den Auftrag vollautomatisch erzeugt. Bei Aktionen wird also nicht beschrieben, mit welchen Mitteln etwas geschieht, sondern nur was geschieht. Dies steht natürlich in Zusammenhang mit dem Implementierungstyp für den Handelnden als Aufgabenträgertyp. Sobald festgelegt wird, welche Typen von Handelnden den einzelnen Aktionen zugewiesen werden, ist auch die Art der Realisierung einer Aktivität definiert. Darüber hinaus ist zu definieren, auf welchem logischen oder physischen Objekt eine Aktion ausgeführt wird. Logische Objekte sind Datenstrukturen, deren Daten durch die Aktivitäten manipuliert werden. Papierformulare stellen eine Mischung zwischen logischen und physischen Objekten dar, während ein Werkstück, auf dem die Aktion „Entgraten“ stattfindet, ein rein physisches Objekt ist. Es besteht also ein enger Zusammenhang zwischen dem Aufgabenträgertyp, den Aktionen und den zugehörigen Objekten, auf denen die Akteure Handlungen ausführen. Ein Prozessmodell kann in verschiedenen Bereichen einer Organisation zum Einsatz kommen. Die Prozesslogik wird dann in den jeweiligen Bereichen unverändert übernommen. Es kann allerdings nötig sein, die einzelnen Handelnden und Handlungen unterschiedlich zu implementieren. So können in einer Umgebung bestimmte Handlungen von Menschen und in einer anderen die gleiche Aktivität von Softwaresystemen ausgeführt werden. Wir bezeichnen solche verschiedenen Verwendungsumgebungen für ein Prozessmodell im Folgenden als Kontext. Für ein Prozessmodell kann es also variierende Kontexte geben, in denen die Realisierungstypen für Akteure und Aktionen voneinander abweichen können. In BPMN kann der Modellierer für jeden Task separat festlegen, ob es sich um eine sogenannte Human Task, Service Task oder User Task handelt. User Tasks führen Menschen zusammen mit Software aus, wie z. B. das Ausfüllen eines Kommissionierungsauftrags am Bildschirm. Dies bedeutet, die Beschreibung des Implementierungstyps ist in BPMN Teil der Prozesslogik. Da in BPMN Pools und Swim Lanes als Handelnde interpretiert werden können, muss darauf geachtet werden, dass keine Widersprüche mit dem Implementierungstyp von Tasks innerhalb z. B. eines Pools entstehen. Legt der Designer z. B. fest, dass ein Pool nur durch Menschen ausgeführt wird, kann dieser Pool keine Service oder User Tasks enthalten. Dadurch, dass in BPMN die Definition des Implementierungstyps Bestandteil des Ablaufmodells ist, muss unter Umständen für jeden Kontext ein eigenes Prozessmodell erstellt werden. In S-BPM werden Handelnde nicht einzelnen Aktivitäten zugeordnet, sondern der Typ des Handelnden einem gesamten Subjekt. Diese Zuordnung ist in S-BPM nicht Teil der Prozesslogik, sondern erfolgt je Prozess in einer separaten zweispaltigen Zu-

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

275

ordnungstabelle. In der linken Spalte findet sich der Subjektname und in der rechten der Implementierungstyp (Beispiel: Subjekt „Produktionsplanung“ –> Implementierungstyp „Software“). Gibt es für ein Ablaufmodell mehrere Kontexte, so wird für jeden von ihnen eine eigene Zuordnungstabelle erstellt. Die Zuordnung des Implementierungstyps bildet den Übergang zwischen der Prozesslogik und deren Implementierung. Anschließend muss noch definiert werden, welche Personen, Softwaresysteme und physikalischen Systeme die Handelnden repräsentieren, und wie die einzelnen Aktionen konkret realisiert werden. In den folgenden Unterkapiteln werden diese Aspekte detailliert beschrieben.

7.2.2

Menschen und Organisation

Für jeden Kontext gilt es für alle Handlungen, an denen Menschen beteiligt sind, die Aufgaben- oder Handlungsträger, und damit die konkreten ausführenden Personen oder Organisationseinheiten zu definieren. In Unternehmen und Verwaltungen gibt es Personen mit unterschiedlichen Ausbildungen, Qualifikationen, Neigungen und Interessen. Es gibt Kaufleute, Entwickler, Handwerker usw., welche die anfallenden Tätigkeiten erledigen. Organisationen kann man daher auch als strukturierte Ressourcenpools bezeichnen. Je nach Art und Umfang der Aufgaben bildet die Organisation Einheiten, in denen die jeweiligen Spezialisten dafür zusammengefasst werden. So existieren Abteilungen für den Einkauf mit Beschaffungsexperten, oder Entwicklungsabteilungen, die aus mehreren Entwicklungsingenieuren und sonstigen Fachleuten gebildet werden. Der Bezug zwischen den Personen und Organisationen in der Aufbauorganisation zu den abstrakten Handelnden in den Prozessen kann statisch oder dynamisch hergestellt werden.

7.2.2.1 Statische Zuordnung Im einfachsten Fall wird die bereits erwähnte zweispaltige Tabelle um eine Spalte ergänzt. Sie gibt dann Aufschluss darüber, welchem im Prozess definierten Akteur (Spalte 1) des Implementierungstyps Mensch (Spalte 2) welche Personen oder Rollen oder Organisationen bzw. Organisationseinheiten zugeordnet sind (Spalte 3). Enthält die dritte Spalte eine Organisation bzw. Organisationseinheit, sind alle deren Mitglieder dem abstrakten Handelnden (Subjekt) zugeordnet. Damit wird erreicht, dass bei Krankheit oder Urlaub eine beliebige Person aus der zugeordneten Organisation oder Einheit die im Prozess anfallenden Aufgaben übernehmen kann. Außerdem lässt sich so auch die Arbeitslast verteilen, wenn Handlungen aus mehreren Prozessabläufen (Prozessinstanzen) abgearbeitet werden müssen. Abb. 7.3 zeigt die Einbettung von Prozessaktionen in eine Organisation am Beispiel eines Dienstreiseantrags (siehe Pfeile im Organigramm). Dabei stellt Schwarz als Mitglied der Entwicklungsabteilung den Antrag (Aktion 1), Meier als vorgesetzte Instanz leitet den (genehmigten) Antrag weiter in die Personalabteilung (Aktion 2) zu Weg, wo die Abwesenheit vermerkt wird (Aktion 3). Mit Aktion 4 gelangt die Information

276

7 Umsetzung

Abb. 7.3 Einbettung von Prozessen in eine Organisation

über die Genehmigung zurück zu Schwarz, der die Reise plant (Aktion 5). An dem Beispiel wird auch deutlich, dass eine Workflow Engine zur Laufzeit Organisationswissen besitzen und auswerten muss. Je nach Zugehörigkeit des Antragstellers zu einer Einheit im Organigramm muss sie die Instanz des Reiseantrags an die passende vorgesetzte Instanz routen (z. B. die Anträge von Schulz und Huber zu Schmid). Statt einer einzelnen Aktionen können auch andere Strukturierungselemente der jeweiligen Modellierungssprache einem Aufgabenträger zugeordnet werden. Bei BPMN können Pools, Swim Lanes und einzelne Aktionen einem Ausführenden zugeordnet werden. Hier ist darauf zu achten, dass bei der Verwendung aller Zuordnungsmöglichkeiten keine Inkonsistenzen entstehen. Wenn ein Softwaresystem eine Swim Lane als Handelnder ausführt und in dieser Swim Lane eine Human Task liegt, die separat einem Aufgabenträger zugeordnet wird, so ist nicht klar, wer letztlich diese Aufgabe ausführt. Für das BPMN-basierte Werkzeug von Bonitasoft (siehe Bonitasoft 2022) wurden deshalb Actors eingeführt. Sie sind Platzhalter für Aufgabenträger, denen dann, ähnlich den Subjekten in der Subjektorientierung, konkrete Handelnde zugeordnet werden. Bei S-BPM wird jeweils ein komplettes Subjekt in die Organisation eingebettet, d. h. die Zuordnung gilt dann für alle Aktionen in einem Subjekt.

7.2.2.2 Dynamische Zuordnung In vielen Prozessen kann die Zuordnung der Handelnden aus dem Prozess zu Personen und Organisationen nicht statisch festgelegt werden. So kann bei einem Geschäftsreiseantrag der Bearbeiter davon abhängen, ob es sich um eine Inlands- oder Auslandsreise handelt. Während die Ablauflogik in beiden Fällen gleich sein kann, unterscheiden sich möglicher-

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

277

weise die ausführenden Personen, beispielsweise weil ein Mitarbeiter besondere Expertise für internationale Reisen mit Visaangelegenheiten besitzt. In solchen Fällen ist es sinnvoll, die handelnden Personen oder Organisationseinheiten erst beim Ablauf der Prozesslogik beispielsweise in Abhängigkeit von Datenwerten in Geschäftsobjekten (hier dem Reiseantrag) zu ermitteln und zuzuordnen. Für eine flexible dynamische Zuordnung der Bearbeiter sind in der Regel Tabellen nicht mehr ausreichend, sondern es sind programmiersprachliche Konstrukte notwendig. In Schaller (1998) und Lawall et al. (2013) wird gezeigt, wie eine solche Sprache verwendet werden kann, um subjektorientierte Prozessmodelle in Organisationen einzubetten. Diese Sprache erlaubt auch zu beschreiben wer welche Aufgaben im Falle von Urlaub oder Krankheit von welchem Kollegen übernimmt. Da in BPMN die Zuordnung der Bearbeiter über Pools, Lanes und Tasks möglich ist, gestaltet sich die Beschreibung der Zuordnung dort als sehr komplex. BPMN-basierte Werkzeuge integrieren Prozesse in die Organisation durch Programmierung in Java bzw. XML (siehe Abschn. 8.5).

7.2.3

Physikalische Infrastruktur

Insbesondere in Fertigungsprozessen sind physikalische Systeme als Handelnde beteiligt. So können einer Maschine Rohteile über ein Transportsystem zugeführt werden, die Maschine bearbeitet die Rohteile und die bearbeiteten Teile werden zum nächsten Bearbeitungsschritt weiter transportiert. Wird eine solche Maschine als Subjekt oder Pool betrachtet, so werden die zugeführten Teile als zu empfangende und die abtransportierten Teile als zu sendende Nachrichten modelliert. Der Modellierer stellt den Bearbeitungsschritt als einzelnen Task in einem Subjekt oder Pool dar.

7.2.4

IT-Infrastruktur

Digitalisierung in der Wirtschaft bedeutet, Prozesse mit möglichst umfassender Unterstützung durch IT-Systeme umzusetzen. In entsprechenden Szenarien erledigen weitgehend Rechnersysteme oder Maschinen die Tätigkeiten, menschliche Eingriffe werden soweit möglich und sinnvoll reduziert. Wesentliche Aspekte sind dabei: • Die Steuerung des Prozessablaufs: Die im Prozessablauf beschriebenen Handlungsfolgen werden automatisch durch Computerprogramme gesteuert. • Die Ausführung von Handlungen: Handlungen auf Datenobjekten können oft vollautomatisch durch entsprechende Computerprogramme ausgeführt werden.

278

7 Umsetzung

Softwaresysteme sind das Mittel zur Zusammenführung der verschiedenen Handlungstypen. So bindet beispielsweise eine Process Engine bei der Steuerung des Prozessablaufs die menschlichen und maschinellen Bearbeiter zur Laufzeit situationsgerecht in die Abarbeitung von Instanzen ein. In den folgenden Abschnitten wird auf die Steuerung des Prozessablaufs und die Manipulation der zugehörigen Geschäftsobjekte durch Informationstechnologie eingegangen ohne näher auf die Einbindung von Menschen oder physikalischen Systemen als Aufgabenträger abzustellen. Dies wird im Abschn. 7.2.5 erläutert.

7.2.4.1 Ablauf Die Prozesslogik entspricht der Ablauflogik eines Computerprogramms. Die automatische vollständige Ausführung der Prozesslogik durch ein Computerprogramm ist nur bei stark strukturierten Prozessen möglich. Alle denkbaren Ablaufmöglichkeiten müssen abgedeckt sein. Es sind keine menschlichen Eingriffe vorgesehen. Um zu vermeiden, dass die beschriebene Prozesslogik von der Ausführungslogik des Computerprogramms abweicht, ist es hilfreich, wenn das Computerprogramm automatisch aus der Beschreibung der Prozesslogik abgeleitet werden kann. Dafür müssen folgende Voraussetzungen vorliegen: • Die Syntax und Semantik der Sprache, in der die Prozesslogik beschrieben ist, muss präzise definiert sein. • Die Beschreibung des Prozessablaufs muss in elektronischer Form vorliegen. • Es muss ein Umsetzungsprogramm vorliegen, das die elektronische Form der Beschreibung der Prozesslogik liest und daraus, basierend auf der präzisen Semantik der Prozessbeschreibungssprache, ein Computerprogramm in einer geeigneten Programmiersprache erzeugt. Die Bedeutung bereits heute weit verbreiteter verteilter Systeme nimmt mit der Entwicklung zum Cloud und Edge Computing weiter zu. Dies kann bedeuten, dass auch Teile eines vollautomatisierten Prozesses in einem verteilten System auf verschiedenen Rechnerknoten zur Ausführung kommen sollen. Da diese auf unterschiedlichen Technologien basieren können, müssen unter Umständen entsprechende Varianten für die automatische Umsetzung einer Ablaufbeschreibung in ein Computerprogramm verfügbar sein. So können einzelne Subjekte einer S-BPM-Beschreibung eines Prozesses auf unterschiedlichen Rechnerknoten eines verteilten Systems ablaufen. Dies kann bedeuten, dass der Programmcode für jedes Subjekt separat generiert werden muss. Vermeiden lässt sich dies, wenn der generierte Zielcode auf möglichst allen Knotentypen des verteilten Systems zur Verfügung steht, und dieses Zielsystem über ein Framework verfügt, durch das die auf verschiedenen Knoten laufenden Programmteile zusammenarbeiten können. Die Softwarekomponenten synchronisieren ihre Zusammenarbeit in der Regel durch den Austausch von Nachrichten. Eine Programmiersprache, die dies ermöglicht, ist z. B. Java mit dem Framework AKKA, das den Nachrichtenaustausch über Rechnergrenzen hinweg erlaubt.

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

279

In BPMN können einzelne Pools prinzipiell auf verschiedenen Rechnerknoten ausgeführt werden. Dies setzt aber voraus, dass eine Kommunikation zwischen den Pools über Rechnergrenzen hinweg möglich ist. Eine Recherche nach Möglichkeiten einer entsprechenden Codegenerierung für BPMN-Modelle im Frühjahr 2018 brachte keine Ergebnisse.

7.2.4.2 Aktivitäten und Daten Bei vollständig digitalisierten Prozessen führen Computersysteme auch die im Prozessablauf enthaltenen Aktivitäten aus. Dies kann mittels Funktionen oder Services geschehen, die bereits in existierenden Anwendungsprogrammen verfügbar sind, und nur an den geeigneten Stellen in das Programm, das den Prozessablauf realisiert, eingefügt bzw. aufgerufen werden. Für die Integration neu entwickelter Software für Aktivitäten kommen häufig Technologien zum Einsatz wie Webservices, REST-Schnittstellen oder einfache APIs. Datenbankzugriffe zur direkten Manipulation von Daten können abhängig von den Schnittstellen der verwendeten Datenbanksysteme analog eingebunden werden. Bei der Verwendung von S-BPM gehören Daten zu einem Subjekt. Es ist nicht erlaubt, dass mehrere Subjekte auf gemeinsame Daten zugreifen. Möchten mehrere Subjekte die gleichen Daten z. B. in einer Datenbank nutzen, so muss diese in ein Subjekt eingepackt werden. Dieses Subjekt nimmt dann die entsprechenden Anfragen von den anderen Subjekten entgegen, führt die gewünschte Aktion aus und schickt das Ergebnis an das anfordernde Subjekt zurück. Aktivitäten zusammen mit ihren Daten werden in der Softwaretechnologie als Klassen bezeichnet. Mehrere solcher Klassen können zu Services zusammengeschlossen werden. In der IT wird dann von einer Serviceorientierten Architektur gesprochen. Die Services werden entsprechend der Ablauflogik des Prozesses aufgerufen. Tasks in BPMN können durch Services realisiert werden. Analog dazu können die Funktionen innerhalb eines Subjekts implementiert werden. Ein gängiges Konzept zur Strukturierung von Softwaresystemen sind Microservices (siehe z. B. Newman 2015). Damit soll komplexe Anwendungssoftware durch Bausteine über von der Programmiersprache unabhängige Schnittstellen realisiert werden. Da diese Microservices so weit wie möglich unabhängig voneinander sein sollen, kommunizieren sie meist durch den Austausch asynchroner Nachrichten. Dies entspricht auch dem Konzept des Reactive Programming (Bonér et al. 2014), dessen wesentliche Eigenschaft die Kopplung von Programmbausteinen durch asynchrone Nachrichten ist. In BPMN können Pools als Microservices implementiert werden, falls alle Tasks in einem Pool vom gleichen Aufgabenträger ausgeführt werden. Bei S-BPM sind Subjekte immer einem Aufgabenträger zugeordnet und kommunizieren über den asynchronen Austausch von Nachrichten. Deshalb entspricht ein subjektorientiert beschriebener Prozess mit Blick auf die IT-Architektur einer Microservice-orientierten Struktur, die den Anforderungen des Reactive Programming genügt.

280

7.2.5

7 Umsetzung

Kombinationen von Aufgabenträgern

Tasks werden häufig nicht von einem einzigen Aufgabenträgertyp ausgeführt. Mit der zunehmenden Digitalisierung werden z. B. die Aufgaben, die nur Menschen ausführen immer weniger. So erhält heute ein Lagerarbeiter seine Kommissionierungsaufträge häufig über ein Tablet, das mit einem IT-System verbunden ist. Nachdem er die Waren zusammengestellt hat, bestätigt er dies auch auf dem Tablet. Damit ist die Kommissionierungsaufgabe abgeschlossen. Das IT-System aktualisiert die Daten und stößt die Folgeaufgabe wie z. B. die Vorbereitung der Versanddokumente automatisch an. Die Kommissionierungsaufgabe wird also durch Mensch und IT als Typen von Aufgabenträgern ausgeführt, einer Kombination, die man in Geschäftsprozessen sehr häufig findet. Die IT übernimmt dabei zumindest die Steuerung der Prozesslogik und die Verwaltung der Daten, während Menschen Eingaben tätigen oder Maschinen bedienen. Von Kleinrechnern mit entsprechender Software gesteuerte Maschinen lösen zunehmend Maschinen als rein mechanische Aufgabenträger ab. Diese eingebetteten Systeme (Embedded Systems) steuern die Mechanik und wickeln die Kommunikation mit anderen Maschinen oder übergeordneten Geschäftsanwendungen ab. Die Kommunikation mit anderen intelligenten Maschinen wird als horizontale Kommunikation und diejenige mit Geschäftsanwendungen als vertikale Kommunikation bezeichnet. Letztere verknüpft Produktionssysteme mit Geschäftsprozessen und ist ein wesentlicher Bestandteil der Industrie 4.0 Initiative. In den folgenden Abschnitten wird nun detaillierter beschrieben wie die verschiedenen Aufgabenträger in die Implementierung der Prozessablauflogik integriert werden.

7.2.5.1 Kombination Mensch-IT Die Kombination von Mensch und IT bei der Ausführung von Geschäftsprozessen ist der Kern deren Digitalisierung. Die IT übernimmt dabei zumindest die Steuerung der Prozesslogik, d. h. sie veranlasst entsprechend der Prozesslogik, dass die vorgesehenen Aufgaben von den jeweiligen Aufgabenträgern erledigt werden. Zusätzlich können Aufgaben von der IT direkt als Aufgabenträger ausgeführt werden, ohne dass Menschen eingebunden werden müssen. Kann eine Aufgabe nur durch menschliche Unterstützung erledigt werden, fordert die für die Ablauflogik zuständige Software über eine entsprechende Benutzerschnittstelle den zuständigen menschlichen Aufgabenträger dazu auf. Dies kann die Eingabe von Daten sein, aber auch nur die Bestätigung des Benutzers, dass er eine manuelle Aktion ausgeführt hat. IT-Systeme als Steuerungssoftware und als Handlungsträger für Aktivitäten übernehmen in der Regel auch die Speicherung der während einer Prozessausführung anfallenden Daten, sowohl Inhalte von Geschäftsobjekten, als auch Metadaten wie Zeitstempel für Beginn und Ende von Instanzen und Ausführungsschritten. Eine umfassende Plattform zur Implementierung von Geschäftsprozessen, die Menschen und IT-Lösungen ausführen, wird als Workflow-Management-System bezeichnet. Die Workflow Management Coalition (WfMC) hat dafür ein Referenzmodell entwickelt. Abb. 7.4 zeigt die darin vorgesehenen Komponenten und Schnittstellen (siehe Hollingsworth 1996).

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

281

Abb. 7.4 Referenzmodell für Workflow-Management-Systeme (WFMS)

Die Schnittstellen zwischen den einzelnen Komponenten sind wie folgt definiert: • Prozessdefinition (Schnittstelle 1) Schnittstelle zwischen Prozessdefinition, Modellierungswerkzeugen und der Workflow Engine (Ausführungsumgebung) • Benutzerschnittstelle (Schnittstelle 2) APIs für Clients, um Dienste von der Workflow Engine anzufordern, damit der Prozessfortschritt und die Aktionen kontrolliert werden können. • Applikationsschnittstelle (Schnittstelle 3) APIs, die der Workflow Engine erlauben, Applikationen aufzurufen und zu nutzen. • Workflow-Management-System-Schnittstelle (Schnittstelle 4) Standard-Schnittstelle für den Austausch mit anderen Workflow-Systemen • Administration und Monitoring (Schnittstelle 5) Schnittstelle für Werkzeuge zur Kontrolle der Prozesse und zur Überwachung Die wesentlichen Komponenten im Referenzsystem der WfMC sind der Workflow Enactment Service und die Workflow Engine. Die Aktionen und ihre Reihenfolge werden in der Prozessdefinition festgelegt und durch die Workflow Engine gesteuert. In einem Unternehmen laufen in der Regel mehrere Instanzen eines Geschäftsprozesses gleichzeitig ab. Eine Prozessinstanz entsteht, wenn die Ausführung eines Geschäftsprozesses durch das dafür definierte Ereignis angestoßen wird. Prozessinstanzen folgen der einheitlichen Prozessbeschreibung, werden aber unabhängig voneinander ausgeführt.

282

7 Umsetzung

Beispielsweise können zwei verschiedene Kunden eine Bestellung tätigen. Jeder dieser individuellen Kundenaufträge erzeugt eine eigenständig abzuwickelnde Instanz des Geschäftsprozesses „Auftragsbearbeitung“. Das Management der einzelnen Instanzen übernimmt das Workflow Enactment System mit Hilfe von Workflow Engines. Eine Workflow Engine stellt die Ausführungsumgebung für eine Workflow-Instanz zur Verfügung. Ihre wesentlichen Aufgaben sind: • • • • • • • • •

Einordnung der Instanz in das organisatorische Umfeld Interpretation der Prozessdefinition Kontrolle der Prozessinstanzen Navigation zwischen sequenziellen oder parallelen Prozessaktivitäten Interpretation von Prozessdaten Identifikation der Benutzerschnittstellen Verknüpfung mit anderen Programmen/Anwendungssystemen Verknüpfung mit anderen Workflow-Systemen Übergeordnete Kontrollfunktion

Ein Workflow Enactment Service ist ein Dienst, der eine oder mehrere Workflow Engines startet, verwaltet und ausführt. Über Applikationsschnittstellen greifen Workflow-Systeme auf Funktionen von Anwendungssystemen zu, die in einem Prozess vorgesehene Aufgaben ausführen. Ein Worklist Handler ist eine Komponente, welche die Benutzer in einen Prozess einbindet. Er kann Teil eines Workflow-Management-Systems sein oder von einem Workflow-Experten definiert und programmiert werden. Durch den Worklist Handler wissen die beteiligten Aufgabenträger in welcher Prozessinstanz sie welche Aufgaben zu erledigen haben. Damit Benutzer bei der Bearbeitung von Prozessinstanzen eine einheitliche Arbeitsoberfläche haben, können Workflow-Funktionen in andere gebräuchliche Anwendungen eingebettet werden, beispielsweise in ein E-Mail-Programm. Für eine solche Integration muss zwischen dem Workflow Enactment Service und den anderen Anwendungen ein Kommunikationsmechanismus bestehen. Die Referenzarchitektur sieht auch eine Schnittstelle für Administration und Monitoring vor. Dort anknüpfende Software dient der Überwachung des gleichzeitigen Ablaufs verschiedener Instanzen von mehreren Geschäftsprozessen. Dieses Monitoring bezieht sich zum einen auf die fachliche Ebene der Abwicklung der Geschäftsfälle, beispielweise mit der Erfassung und Auswertung von Antwort- und Bearbeitungszeiten (vgl. Abschn. 7.3.3). Zum anderen sind auf der technischen Ebene die verwendeten ITSysteme zu überwachen, etwa bezüglich Last- und Fehlverhalten. Die meisten momentan am Markt angebotenen Workflow-Systeme unterstützen nur die Prozessorchestrierung, d. h. einen einzigen Kontrollfluss von Aufgaben. Für BPMN bedeutet dies, dass ein Workflow-System nur die Funktionen in einem Pool ausführen kann. Werden in einer BPMN-basierten Prozessbeschreibung mehrere Pools verwendet,

7.2 Verknupfung von Elementen der Unternehmensarchitektur: . . .

283

ist für jeden Pool eine eigene Workflow Engine nötig. Diese Workflow Engines müssen dann in der Regel durch Programmierung über die Schnittstelle 4 verbunden werden. Insbesondere wenn ein Prozess auf einer verteilten Infrastruktur ausgeführt werden soll, können solche Strukturen aufwändig und kostenintensiv werden, da viele Softwarehersteller Lizenzgebühren für jede installierte Instanz der Workflow Engine berechnen. Damit steigen neben den technischen Schwierigkeiten auch die Kosten. Subjektorientierte Prozessbeschreibungen sind Prozesschoreographien, d. h. die Subjekte werden unabhängig voneinander parallel ausgeführt, ohne dass es eine zentrale Steuerung für alle Subjekte gibt. Zur Koordination ihrer einzelnen Tätigkeiten tauschen die Subjekte asynchron Nachrichten aus. Eine Ausführungsumgebung für subjektorientiert definierte Prozesse ist deshalb genau genommen ein sogenanntes MultiworkflowSystem. Darin entspricht jedes Subjekt einer Orchestrierung, die von einem eigenen Workflow-System ausgeführt wird. Der asynchrone Nachrichtenaustausch zwischen mehreren Workflow-Systemen wird im subjektorientierten Prozessmanagement mithilfe des Inputpool-Konzepts realisiert. Für S-BPM wurde eine Reihe von Multiworkflow-Systemen entwickelt (siehe Fleischmann et al. 2017).

7.2.5.2 Kombination Physik-IT: Cyber Physical Systems In einem Prozess können Handelnde auch Maschinen sein, welche Aufgaben, rein mechanisch oder elektrisch gesteuert, vollautomatisch ohne menschliches Eingreifen erledigen. Die Maschinensteuerung erfolgt mechanisch, elektromechanisch oder, bei den bereits angesprochenen Embedded Systems, zunehmend rechner- und softwarebasiert. Sensoren kontrollieren den physikalischen Zustand von Maschine und Umgebungsbedingungen und Aktoren wie Stellmotoren, Schalter, Regler usw. greifen in den Betrieb der Maschine ein. Die Steuersoftware bestimmt weitgehend das Geschehen auf und an den intelligenten Maschinen und deren vertikale und horizontale Kommunikation mit anderen Systemen. Maschinen kommunizieren untereinander nicht nur durch den Austausch von Daten, sondern auch durch das Weiterleiten und Empfangen von physikalischen Artefakten. Die Nachricht „Zu entgratendes Werkstück“ kann dadurch realisiert sein, dass ein Werkstück von einer spanabhebenden Fertigungsmaschine automatisch weitertransportiert wird zu einer Maschine, die Kanten entgratet. Parallel dazu können bei der Entgratungsmaschine zusätzlich Nachrichten eintreffen, die eine nähere Beschreibung des Werkstücks enthalten sowie die Art der Entgratung spezifizieren. Kombinationen aus physikalischen und informationstechnischen Komponenten werden als Cyber Physiscal Systems (CPS) bezeichnet. Da sie Produktions- und Geschäftsprozesse zusammenführen sind sie von besondere Bedeutung für Industrie 4.0. In BPMN kann der Modellierer einen Task, der von einer Kombination aus Mensch und IT ausgeführt wird, als Service Task modellieren, und eine intelligente Maschine als eigenen Prozess in einem Pool beschreiben. Gibt es eine entsprechende Anzahl von Maschinen, die in einer komplexen Fertigungssituation zusammenarbeiten, so kann die Verwendung von zahlreichen Pools in BPMN zu Darstellungsproblemen führen. Der Grund liegt in der horizontalen Anordnung der Pools, so dass bei einer größeren Anzahl die

284

7 Umsetzung

Nachrichtenkanten zwangsläufig Pools kreuzen müssen, was Unübersichtlichkeit bewirkt. In S-BPM wird eine Maschine dagegen immer als Subjekt modelliert, da erst bei der Implementierung entschieden wird, durch welche Art von Aufgabenträger das Subjekt ausgeführt wird. Wird in einem Prozess ein physikalischer Aufgabenträger verwendet, kann es von diesem Prozess nicht beliebig viele parallele Instanzen geben. Eine physikalische Einheit kann nicht logisch aufgespalten werden, wie dies bei Aufgabenträgern der IT oder Menschen möglich ist. Auf diese Thematik werden wir im Abschn. 7.3.2 näher eingehen.

7.2.5.3 Kombination Mensch-Physik-IT Auch beim Einsatz intelligenter Maschinen gibt es Szenarien, bei denen der Mensch bestimmte Aufgaben ausführt. Beispielsweise erhält eine Maschine das Werkstück über ein Transportsystem und die dazugehörigen Informationen als Nachricht. Die Maschine und ein Bediener führen die vorgesehenen Aufgaben gemäß den Angaben auf den Begleitinformationen zusammen aus. Der Bediener bestätigt die Erledigung seiner Arbeiten über eine Benutzerschnittstelle. Anschließend werden das Werkstück abtransportiert und die aktualisierten Begleitinformationen an weitere involvierte Handelnde übermittelt. In solchen Situationen ist es das Bestreben, den Anteil der menschlichen Arbeit weiter zu reduzieren und durch ausgefeiltere Mechanik oder verbesserte Embedded Systems zu ersetzen. Dabei muss es nicht zwingend notwendig sein, die Prozesslogik zu verändern.

7.3

Betrieb und Monitoring

7.3.1

Inbetriebnahme

Nach der Festlegung der Aufgabenträger und der Implementierung der Handlungen gilt es den Prozess in Betrieb zu nehmen. Dazu müssen die Aufgabenträger vorbereitet werden, indem die physikalische und informationstechnische Infrastruktur aufgebaut und die menschlichen Aufgabenträger geschult werden. Informationstechnische Aufgabenträger werden mit den jeweiligen Programmen geladen und die Mechanik von Maschinen entsprechend eingestellt. Bei der Inbetriebnahme ist es wichtig, die Verknüpfung mit anderen Prozessen herzustellen. In einem Unternehmen sind Prozesse in ein zusammenhängendes Netzwerk von Prozessen eingebunden. Es sollte keine isolierten Prozesse geben. Wird z. B. ein neuer Prozess Versandvorbereitung eingeführt, muss dieser verknüpft sein mit dem Prozess Auftragsannahme. Bei kommunikationsorientierten Prozessbeschreibungen geschieht dies einfach durch den Austausch von Nachrichten. Ein andere Möglichkeit sind gemeinsame Daten, d. h. Prozesse schreiben Daten, die andere Prozesse benötigen, in eine gemeinsam genutzte Datenbank. Nach den Vorbereitungsarbeiten sollte der Prozess als Gesamtkonstrukt getestet werden. Vorteilhaft dazu wäre eine Testumgebung, die ein möglichst realistisches Abbild der

7.3 Betrieb und Monitoring

285

Einsatzumgebung darstellt. Allerdings ist diese Wunschsituation aus Kostengründen oft nicht gegeben. Unabhängig davon empfiehlt es sich den Prozess Schritt für Schritt einzuführen. Dabei ist von Vorteil, wenn ein Prozess als ein lose gekoppeltes System von kommunizierenden Aufgabenträgern beschrieben und umgesetzt wurde. Die einzelnen Handlungsstränge für die Handlungsträger können Schritt für Schritt in Betrieb genommen werden. Da sie durch den asynchronen Nachrichtenaustausch nur lose miteinander gekoppelt sind, kann man andere Aufgabenträger zunächst einfach simulieren. Bei BPMN wird somit Pool für Pool in Betrieb genommen. Sind die Pools allerdings sehr komplex mit mehreren Swim Lanes, gestaltet sich die Inbetriebnahme ebenfalls als komplex. Bei der Verwendung von S-BPM kann ein System durch das schrittweise Hinzunehmen der einzelnen Subjekte aufgebaut werden. Werden in BPMN nicht mehrere Pools verwendet, d. h., ein Prozess wird rein kontrollflussorientiert definiert und implementiert, kann dieser auch nur insgesamt in Betrieb genommen werden. Bei Choreographien, d. h. bei der Verwendung von Subjekten bzw. mehrerer Pools kann der Prozess ausgeführt werden, obwohl z. B. bei einem Pool die Software noch fehlerhaft ist. Die an diesen Pool gesendeten Nachrichten können ersatzweise von Menschen entgegengenommen, bearbeitet und das Ergebnis als Nachricht zurückgesendet werden. Die anderen Pools nehmen die beschriebene Ablauflogik wahr (beobachtbares Verhalten), die aber noch nicht in der endgültigen Form implementiert ist.

7.3.2

Prozessinstanzen

Die konkrete Ausführung eines Prozesses wird als Prozessinstanz bezeichnet. Eine Prozessinstanz entsteht, wenn das Startereignis eintritt. Dies kann der Anruf eines Kunden sein, der ein Produkt bestellen möchte. In diesem Fall kreiert ein Telefonverkäufer explizit eine Instanz indem er den digitalen Bestellvorgang startet und die notwendigen Daten eingibt. Bei Bestellungen in einem Online-Shop erfasst der Kunde die Auftragsdaten selbst und erzeugt eine Instanz, sobald er den Kauf bestätigt. Anschließend durchläuft eine Instanz in beiden Fällen die gemäß der definierten Prozesslogik vorgesehenen Bearbeitungsschritte und -stellen. Da in einem Unternehmen normalerweise zu einem bestimmten Zeitpunkt mehrere Bestellungen vorliegen, existieren gleichzeitig mehrere voneinander unabhängige Prozessinstanzen, die sich in verschiedenen Bearbeitungsstadien befinden. Mitarbeiter eines Unternehmens sind in der Regel in mehrere Prozessinstanzen eingebunden und führen darin jeweils die für sie vorgesehenen Aufgaben aus. Sie teilen sozusagen jeder Prozessinstanz eine Zeitscheibe ihrer Arbeitszeit zu. Analog geschieht dies bei IT-Systemen. Sowohl die Kapazität der Ressource Mensch als auch der IT-Systeme kann also in Zeitscheiben aufgeteilt werden, um mehrere Instanzen von gleichen oder unterschiedlichen Prozessen zu bearbeiten.

286

7 Umsetzung

Bei physikalischen oder cyber-physikalischen Systemen ist dies nicht so ohne weiteres möglich. Ein solches System kann zu einem Zeitpunkt nur in genau eine Instanz involviert sein. Eine Maschine kann nicht mehrfach instanziiert werden, sie ist eben nur einmal vorhanden. Erst wenn eine Maschine eine Aufgabe oder Aufgabenfolge in einer Prozessinstanz vollständig abgeschlossen hat kann sie für eine andere Prozessinstanz tätig werden. Zu einem bestimmten Zeitpunkt ist ein physikalisches System deshalb genau einer Prozessinstanz zugeordnet. Dieser Sachverhalt ist wichtig, wenn Prozesse, die problemlos instanziiert werden können, da sie keine physikalischen Aufgabenträger enthalten, mit Prozessen verknüpft werden, die physikalische Komponenten enthalten. Ein Fertigungssystem besteht nahezu vollständig aus physikalischen oder cyber-physikalischen Aufgabenträgern. Diese Prozesse werden zu Beginn instanziiert. Diese eine Instanz besteht dann bis die Fertigung abgeschaltet wird. Ein physikalischer Aufgabenträger kann nicht eine Zeitscheibe für eine Prozessinstanz 1 arbeiten, dann etwas für eine Prozessinstanz 2 tun und dann wieder für die Prozessinstanz 1 weiterarbeiten. Die Aktionen eines physikalischen Aufgabenträgers für verschiedene Prozessinstanzen wären nicht unabhängig voneinander. Soll z. B. ein Ventil für die Prozessinstanz 1 halb geöffnet werden und danach für die Prozessinstanz 2 ganz geöffnet werden, dann wird natürlich auch für die Prozessinstanz 1 das Ventil ganz geöffnet, was aber nicht sein soll. Wird in BPMN eine Maschine einem Task zugeordnet und kann der zugeordnete Pool mehrfach instanziiert werden, so muss die Maschine zur Laufzeit immer einer einzelnen Instanz zugeordnet werden. Die Maschine muss immer wissen, für welche Instanz sie tätig ist um die richtigen Begleitdaten aus dem allen Instanzen gemeinsamen Speicher zu holen und dann aus dem Werkstückbehälter das zu bearbeitende Werkstück zu entnehmen. Bei S-BPM ist die Maschine dem entsprechenden Subjekt zugeordnet. Dieses empfängt das Werkstück und die Begleitdaten als Nachricht. Die Begleitdaten enthalten auch eine Identifikation der zugehörigen übergeordneten Prozessinstanz, in der Regel die Auftragsnummer. Damit weiß die Maschine, für welche Prozessinstanz sie nun arbeitet. Die Nachricht, mit der eine Maschine ihre Arbeit für beendet erklärt, geht an eine Subjektinstanz in der beauftragenden Prozessinstanz.

7.3.3

Monitoring

Prozessbeteiligte führen im Tagesgeschäft Geschäftsprozesse gemäß des modellierten Designs in der bei der Umsetzung geschaffenen Umgebung aus Personal- und technischen Ressourcen aus (vgl. Abschn. 7.2). Jeder anfallende Geschäftsvorfall durchläuft als Instanz diese Ausführungsumgebung. Dabei zeichnen Transaktionssysteme wie Enterprise-Resource-Planning-Anwendungen (ERP) oder Workflow Engines das Verhalten der Instanz in Form von Einträgen in einem Log File (Event Log, Audit Log) auf. Ein Log-Datensatz enthält u. a. eine eindeutige Vorgangsidentifikation, Teilschrittidentifikation und Zeitstempel für Beginn und Ende.

7.3 Betrieb und Monitoring

287

So entstehen Rohdaten für die Berechnung von Prozesskennzahlen (Process Performance Indicators, PPIs). Verlässliche Managementinformation auf Basis solcher Kennzahlen ist die Voraussetzung für eine kontinuierliche Anpassung der Prozessgestaltung im Hinblick auf höhere Zielerreichungsgrade. Die periodische Ex-post-Auswertung über eine Vielzahl von Instanzen über längere Zeiträume wie Wochen, Monate, Quartale etc. dient dabei vorwiegend der Erkennung struktureller Verbesserungspotenziale, beispielsweise bezüglich planmäßigem Personaleinsatz, Ablauflogik oder Grad der IT-Abdeckung. Dieses traditionelle Monitoring und Reporting folgt dem Konzept der Business Intelligence mit dem Prinzip „Store and analyze“ und den Methoden des Data und Process Mining. Daraus resultierende Veränderungen sind eher mittel- und langfristiger Natur. Um auch den steigenden Echtzeitanforderungen Rechnung zu tragen, wird das traditionelle Prozessmonitoring deshalb mittlerweile ergänzt durch das Business Activity Monitoring (BAM), welches ereignisgetrieben nahezu in Echtzeit Daten auswertet, zeitnah Ergebnisse meldet und damit kurzfristige, instanzbezogene Maßnahmen ermöglicht (vgl. Schmidt 2013). Beispiel wäre die bevorzugte weitere Bearbeitung der Bestellinstanz eines A-Kunden, wenn das System erkennt und meldet, dass diese an einem Messpunkt hinter dem dort üblichen Bearbeitungsfortschritt hinterherhinkt und deshalb der zugesagte Liefertermin nicht zu halten ist (predictive analysis). BAM nutzt das Konzept des Complex Event Processing (CEP) mit dem Prinzip „Stream and analyze“ und Stream-Mining-Methoden. Dies bedeutet, dass das System im Strom von aufgezeichneten einzelnen Vorkommnissen (z. B. gesetzte Zeitstempel, passierte Messpunkte) permanent nach Mustern für komplexe Ereignisse sucht, die erst durch die Verknüpfung der einzelnen Ereignisse Relevanz für bestimmte Zwecke erlangen. Typisches Beispiel ist die Erfassung zweier Transaktionen mit derselben Kreditkarte in Hamburg und New York. Diese einfachen Einzelereignisse (low level events) werden im Ereignisstrom als normale Vorgänge registriert. Das CEP-System kombiniert sie erst zu einem komplexen Ereignis (complex event), wenn beide Transaktionen innerhalb eines kurzen Zeitraums stattfinden, im Beispiel etwa drei Stunden. In diesem Fall würde ein Ereignismuster aus geografischem und Zeitabstand zur Klassifikation als komplexer Event „angenommener Kreditkartenmissbrauch“ führen. Business Activity Monitoring soll permanent und gleichzeitig eine Vielzahl von Datenquellen überwachen. Zu den Erzeugern von Ereignisdaten gehören Anwendungen, die Prozessinstanzen verarbeiten (z. B. ERP, CRM, Workflow Engines) sowie andere Informationen von innerhalb oder außerhalb des Unternehmens liefern (z. B. Umgebungsbedingungen, Wetter- und Verkehrsdaten). Zunehmend zählen dazu auch (Sensor-)Daten, die smarte Geräte und Einrichtungen im Internet of Things produzieren. BAM analysiert und aggregiert die Datenflut mithilfe definierter Regeln und übermittelt Ergebnisse an berechtigte und interessierte Empfänger. Abb. 7.5 stellt das traditionelle und das komplementäre Business Activity Monitoring nebeneinander. Als Vergleichsmerkmal dienen die in der linken Spalte aufgeführten Aktivitäten (Schmidt 2013).

288

7 Umsetzung

Abb. 7.5 Eigenschaften von traditionellem und Business Activity Monitoring

Zeitpunkt und Art der Verwertung der aufgezeichneten/registrierten Daten hängen von der Ausgestaltung des Monitoring und Reporting gemäß der Anwenderanforderungen ab. Beim Pull-Prinzip ruft der Anwender die von ihm gewünschte Auswertung zu einem beliebigen Zeitpunkt ab. Nach dem Push-Prinzip erzeugt das System zeitgesteuert z. B. täglich, wöchentlich, monatlich, quartalsweise zu festgelegten Zeiten Auswertungen und informiert den vordefinierten Empfängerkreis davon. Beim Überschreiten von Grenzwerten oder Toleranzschwellen für Process Performance Indicators einzelner Instanzen zur Laufzeit können, ebenfalls per Push, Alarmmeldungen an Verantwortliche übermittelt oder gleich andere Vorgänge gestartet werden, z. B. ein umfangreicher Eskalationsprozess mit Korrekturmaßnahmen für den betreffenden Fall. Als Präsentationsform für die Auswertungen dominieren Management Cockpits mit Instrumententafeln (Dashboards). Dort finden sich meist Darstellungen in Form von Tachometern, Ampeln und Balken- oder Kreisdiagrammen. Für platzsparende Anzeigen mit hoher Informationsdichte kommen auch Wortgrafiken wie Sparklines oder Bullet Graphs zum Einsatz. Beispiele für Auswertungen und ihre Darstellung sind:

7.3 Betrieb und Monitoring

289

• Durchlaufzeit von laufenden und abgeschlossenen Instanzen. Der Status wird in Ampelfarben ausgedrückt, je nach Abweichung von definierten Soll-Werten bzw. Toleranzbereichen (vgl. Abb. 7.6). • Durchlaufzeit einer laufenden Instanz (absoluter Wert und Vergleich) mit Durchschnitt, chronologischer Ablauf und Dauer der Einzelschritte der Prozessbeteiligten (vgl. Abb. 7.7). • Abfolge der Prozessschritte einer laufenden Instanz mit Zeitstempeln für den Abschluss eines Schritts, d. h. für den Übergang von einem Zustand in den nächsten (vgl. Abb. 7.8). • Anzahl von Instanzen eines Prozesses pro Zeiteinheit, minimale, durchschnittliche und maximale Bearbeitungszeit pro Prozessbeteiligtem und -schritt (vgl. Abb. 7.9).

Abb. 7.6 Instanzbericht (Übersicht)

Abb. 7.7 Instanzbericht (einzelne Instanz)

290

7 Umsetzung

Abb. 7.8 Instanzbericht (aktueller Bearbeitungsstand)

7.3.4

Process Mining

Eine spezielle Form der Auswertung von Prozessdaten stellt das Process Mining dar. Dabei werden Log Files genutzt, um aus den Transaktionsdaten zentraler IT-Systeme (u. a. ERP, CRM und SCM) prozessbezogene Informationen zu extrahieren und so den tatsächlichen Prozessablauf visuell rekonstruieren und analysieren zu können. Dadurch können Erkenntnisse über das wirkliche Verhalten von abgewickelten Prozessinstanzen gewonnen werden (Van Der Aalst 2016). Häufig analysierte Unternehmensprozesse sind der Einkauf, Verkauf, Kreditoren-/Debitorenbuchhaltung sowie Ticketing-Systeme (z. B. im IT-Service Management). Ein Event Log enthält sequenziell aufgezeichnete Ereignisse (trace) mit Attributen wie Fall-ID (caseID), Prozessschritt (activity), Zeitstempel (timestamp), ausführender Einheit (resource) und bearbeitete Geschäftsobjekte (data elements). Je nach Prozess können weitere Informationen dazu kommen, wie z. B. der Name eines Kunden oder Lieferanten,

7.3 Betrieb und Monitoring

291

1

0.0

Ap

0

MIN

se

2

AVG

ou

3

W ar eh

4

120.0 100.0 80.0 60.0 40.0 20.0

er

5

as

6

Processing Duration AVG/MIN/MAX in Minutes by Subject

Pu rc h

Ja Fe nua Started Instances by Month br ry, ua ‘1 1 r M y, ar ‘1 c 1 Ap h, ‘ ril 11 M , ‘1 a 1 Ju y, ‘1 ne 1 Ju , ‘11 A Se ug ly, ‘ pt us 11 em t, ‘ O be 11 N cto r, ‘1 ov be 1 D em r, ‘1 ec b 1 D em er, ‘ ec b 1 em er 1 be , ‘11 r, ‘1 1

7

pr ov er

Procesing Duration in Minutes

Started Process Instances (per Month)

MAX

Pu rc ha se Ap Processing Duration r: pr Cr ov in Minutes ea er te : Pu R O e rd rc er ha ceiv Re se e O qu r: Ap rd S es pr er en t ov R d er eq O rd :C u e er he st R ck eq Ap O ue pr rd st ov er er R eq :S u en Ap es d W t pr Ap ar ov W eh p e r ar r: ov ou e Se al ho se nd :S us e: Pu ea D e R rc rc ni ec h ha al ei Fo se ve rO r: W O Fo ffe ar r de rw eh rs r ar ou an W d se d ar O P :C eh r d r ov er ou he id se ck e :P D St at o ro e ck vi of de D D el W Pu at ive e ar rc ry of eh ha D ou se e se liv r: er :S C he y en W ck ar d eh O D at rd ou e er se of W :W D ar el ai eh i ve tf ou or ry se Pu D :S el rc i up ve ha ry pl se y r: M Pu W at ai rc e tF r ia ha l or se r: An C sw he er ck D el ive ry

Processing Duration AVG/MIN/MAX in Minutes by Process Step 160.0

0.0

MIN

AVG

MAX

Abb. 7.9 Prozessbericht

Bestellmenge und -wert, Liefermenge etc. In Abb. 7.10 ist ein Beispiel für ein Event Log dargestellt. Mit Bezug solcher Protokolldaten für die Prozessausführung zu Prozessmodellen lassen sich drei wesentliche Arten von Process Mining identifizieren (Van Der Aalst 2016): • Entdeckung (Discovery): dabei rekonstruieren Algorithmen aus den Log-Daten ohne weitere Informationen den tatsächlichen Prozessablauf und dessen vielfältige Varianten. Damit lassen sich bereits gelebte, aber noch nicht dokumentierte Prozesse formal beschreiben. • Konformität (Conformance): dabei vergleichen Algorithmen ein vorhandenes, gültiges Prozessmodell mit dem tatsächlichen Ablauf wie er aus den Log-Daten abgeleitet wird. Festgestellte Abweichungen können Anhaltspunkte für Optimierungen liefern und Missbrauch oder Verstöße gegen Compliance-Regeln aufdecken. • Erweiterung (Enhancement): hier werden bestehende Modelle an die Realität der Vorgangsbearbeitung angepasst (Repair) oder dem Modell weitere Perspektiven wie Zeitdauern hinzugefügt (Extension).

292

7 Umsetzung

Abb. 7.10 Ausschnitt aus Event Log

Insbesondere die Überprüfung der Konformität sollte möglichst zur Laufzeit von Instanzen im Rahmen des Business Activity Monitoring durchgeführt werden, um Verstöße zeitnah zu entdecken und deren Folgen mildern zu können (z. B. Stoppen einer Überweisung bei Unregelmäßigkeiten bei der Zahlungsfreigabe). Das folgende Beispiel ist der Process-Mining Lösung der Celonis SE (www.-celonis.com) entnommen. Es zeigt ausgewählte Mining-Ergebnisse für einen Bestellabwicklungsprozess (Purchase to Pay), der mit einem ERP-System abgewickelt wird. Die Analyse des dazugehörigen Event Logs für einen bestimmten Zeitraum hat folgende Information hervorgebracht (vgl. Abb. 7.11): • 279.020 Instanzen des Prozesses mit einem Nettobestellwert von 539.180.072 • 107.688 Instanzen folgten dem normalen Ablauf des Prozesses (Happy Path), beginnend mit dem Erstellen einer Bestellanforderung und endend mit der Verbuchung der Rechnung (siehe CaseID 10002 in Abb. 7.10). Die durchschnittliche Durchlaufzeit beträgt 27 Tage. Diese Prozessvariante 1 deckt 39 % aller Instanzen ab, daneben existieren 527 andere Varianten.

7.3 Betrieb und Monitoring

293

Abb. 7.11 Übersicht über Prozessvarianten (rechts) und Happy Path (links)

Erweitert man den Betrachtungsraum beispielsweise auf die sieben am häufigsten vorkommenden Prozessvarianten, sieht man, dass damit 83 Prozent aller Instanzen abgedeckt sind. Im Prozessgraphen sind jetzt auch die sieben Pfade mit den dazugehörigen Häufigkeiten sichtbar (vgl. Abb. 7.12). Alternativ können auch die durchschnittlichen Dauern der Wege und Zustandsübergänge angezeigt werden. Bezüglich des Ablaufs fällt außerdem auf, dass eine nicht geringe Zahl von Instanzen (18.938) mit dem Scan der Rechnung beginnt und erst dann eine Bestellung im System angelegt wird (siehe CaseID 10003 in Abb. 7.10). Dies ist ein Indiz für sog. Maverick Buying, d. h. die Beschaffung von Fachabteilungen am Einkauf vorbei. Diesem i. d. R. unerwünschten Prozessverhalten kann im nächsten Schritt gezielt nachgegangen werden, um dessen Ursachen zu beseitigen. Mit der Einblendung zusätzlicher Informationen lassen sich Prozesse tiefergehend untersuchen. Abb. 7.13 gibt beispielsweise Auskunft über die auf Monate verteilte Anzahl von Bestellungsinstanzen mit den jeweiligen Wertangaben sowie deren Verteilung auf Lieferanten. Die vorgestellten Analysen betreffen nur einen kleinen Ausschnitt der vielfältigen Nutzungsmöglichkeiten der Celonis-Umgebung. So können die Anwender über die vom System vorgesehenen Auswertungen hinaus auf Basis ihrer individuellen Datenmodelle eigene Auswertungen durch Rückgriff auf eine Vielzahl vorhandener Analysekomponenten (wie verschiedene Diagrammtypen, Prozesskennzahlen und OLAP-Tabellen) definieren. Außerdem erlaubt die Software die Ausführung eigener Prozessauswertungen mit Hilfe der Process Query Language (PQL).

294

7 Umsetzung

Abb. 7.12 Anzeige der sieben häufigsten Prozessvarianten

Abb. 7.13 Einblendung zusätzlicher Information

Zusätzliche Funktionen erlauben etwa die Analyse der Konformität des tatsächlichen mit dem im Modell vorgesehenen Ablauf (Konformität) oder die parallele Visualisierung und damit die Gegenüberstellung unterschiedlicher Verhalten desselben Prozesses z. B. in zwei Niederlassungen (Benchmarking). Die Zukunft des Process Mining liegt in der Kombination der Prozessanalyse mit intelligenten Algorithmen. So integriert beispielsweise die Celonis Proactive Insights Engine (Pi) Machine Learning und Artificial Intelligence und identifiziert für den Nutzer automatisch Schwachstellen im Prozess sowie deren Ursachen

7.3 Betrieb und Monitoring

295

(Veit et al. 2017). Darauf aufbauend erhält der Nutzer zudem intelligente Empfehlungen zur Prozessverbesserung.

7.3.5

Optimierung und kontinuierliche Wartung

Ziel von Monitoring, Auswertung und Reporting des Prozessverhaltens ist es, Managementinformation zum Prozessverhalten zu erzeugen und bereitzustellen. Die Adressaten können diese analysieren, Ursachen für Abweichungen von Zielwerten erforschen und kurz-, mittel- und langfristige Handlungsbedarfe und Maßnahmen zur Restrukturierung daraus ableiten. Die folgenden Ausführungen erläutern typische Veränderungen der Prozessgestaltung, welche sich positiv auf das Prozessverhalten im Sinne einer Optimierung auswirken sollen. Wir beziehen uns dabei exemplarisch auf das Kreditantragsbeispiel aus Abschn. 5.2.2. • Parallelisieren und überlappte Ausführung: Logisch und technisch voneinander unabhängige Aktivitäten können ganz oder teilweise gleichzeitig und von verschiedenen Aufgabenträgern ausgeführt werden. Zwar kann die Zahl unterschiedlicher Aktivitäten durch die Aufspaltung ansteigen, die Parallelisierung bewirkt aber oft eine Prozessbeschleunigung. So könnte ein Prüfschritt bei der Kreditantragsbearbeitung in die dann parallel vorgenommene Bonitätsprüfung des Kunden und Werthaltigkeitsprüfung des Finanzierungsobjekts zerlegt werden. • Zusammenfassen von Aktivitäten: Zusammenfassen als Gegenteil von Aufspaltung bedeutet, dass ursprünglich getrennt und von verschiedenen Aufgabenträgern bearbeitete Aktivitäten nun durch einen Aufgabenträger ausgeführt werden. Diese Reintegration von Aufgaben führt Arbeitsteilung zurück und verringert dadurch beispielsweise Schnittstellen. Die Zahl der Aktivitäten in einem Geschäftsprozess und seiner Darstellung nimmt durch die Zusammenfassung ab und die Anordnungsbeziehungen zwischen den Aktivitäten des Geschäftsprozesses ändern sich. Im Kreditantragsprozess könnte die Zusammenfassung der beiden Prüfschritte wieder sinnvoll sein, wenn die weiter unten beschriebene Automatisierung der Kundenbonitätsprüfung den Zeitgewinn durch Parallelisierung relativiert. • Änderung der Reihenfolge: Die Anordnungsbeziehungen zwischen den Aktivitäten, oder zwischen Gruppen oder Bündeln von Aktivitäten, können eventuell vertauscht werden, was zeitliche, kostenmäßige oder kapazitätsmäßige Vorteile haben kann. Beim Kreditantragsbeispiel sollte die Prüfung der Bonität der Bewertung des Finanzierungsobjekts vorgezogen werden, denn letztere ist hinfällig bzw. der ganze Prozess endet, wenn der Interessent nicht kreditwürdig ist. Eine Sequenz der Prüfungen steht im Gegensatz zu der Parallelisierungsoption. Um eine Entscheidung für eine der Varianten zu treffen, wäre die Information hilfreich, wie oft ein Antrag wegen mangelnder Bonität abgelehnt wird und damit im Falle der parallelen Objektprüfung Ressourcen verschwendet werden.

296

7 Umsetzung

• Elimination von Aktivitäten: Verbale Diskussionen, Process Mining, Pfadanalyse und Simulationsexperimente geben Hinweise auf nicht benötigte Aktivitäten (tote Pfade), sehr selten ausgeführte Aktivitäten, auf Aktivitäten, bei denen kaum eine Wertschöpfung erzielt wird oder die unwirtschaftlich sind. Die Zahl der Aktivitäten eines Prozesses nimmt durch die Elimination ab und die Struktur der Anordnungsbeziehungen ändert sich. Beispiel für eine Elimination wenig wertschöpfender Aktivtäten könnte das in Abschn. 5.2.8.2 angesprochene Weglassen der zusätzlichen Genehmigung eines Kreditantrags über 200.000 durch die Abteilungsleitung sein. • Elimination oder Reduzierung von Zyklen: Wenn Geschäftstransaktionen Zyklen von Aktivitäten mehrfach durchlaufen, verlängert dies gewöhnlich die Durchlaufzeiten der Prozesse und führt oft zu Wartezeiten bei der Ausführung. Mit der Pfadanalyse können solche Zyklen identifiziert und lokalisiert und möglicherweise durch Änderung der Prozessgestaltung eliminiert werden. Bei der Kreditantragsbearbeitung kann es beispielsweise immer wieder zu Nachfragen der Sachbearbeiter beim Interessenten kommen, weil Informationen zur Beurteilung des Finanzierungsvorhabens fehlen. Sieht das elektronische Antragsformular Mussfelder und Anhänge für entsprechende Angaben vor, kann die Steuerung die Abgabe verhindern, so lange Information fehlt. Damit ist zwar nicht sichergestellt, dass der Antragsteller die richtige Information vollständig und valide übermittelt, aber die Wahrscheinlichkeit dafür steigt und Rückfrageschleifen dürften seltener nötig sein. • Insourcing und Outsourcing: Unter Umständen ist es sinnvoll, ganze Geschäftsprozesse oder Teile davon nicht in der eigenen Organisation, sondern von spezialisierten externen Dienstleistern ausführen zu lassen, welche dies z. B. aufgrund von Größenvorteilen (Economies of Scale) kostengünstiger und/oder schneller können. Damit lassen sich oft eigene Fixkosten durch variable Kosten für die Inanspruchnahme der Leistungen des Partners ersetzen. Beispielsweise könnte die Bank anstatt eigene Sachverständige für die Immobilienbewertung zu beschäftigen fallweise ein Architekturbüro damit beauftragen. Bei entsprechenden Voraussetzungen kann auch der umgekehrte Weg Vorteile bringen, etwa, wenn bisher ausgelagerte Aktivitäten z. B. wegen des Wegfalls von Schnittstellen und Transaktionskosten intern wirtschaftlicher organisierbar sind. • Automatisieren: Der technische Fortschritt eröffnet Möglichkeiten, manuelle Arbeitsschritte von IT-Anwendungen und Maschinen (z. B. Roboter) unterstützen oder komplett automatisch ausführen zu lassen. Dies ist insbesondere für zeitintensive, wenig motivierende und fehlerträchtige Tätigkeiten relevant. Zur Realisierung von Automatisierungsoptionen gilt es, die Entwicklung und den Markt für entsprechende Technologien dauerhaft zu beobachten, um passende Lösungsbausteine identifizieren und diese in Prozessanpassungen einbeziehen zu können. Als Beispiel kann der parametrisierbare Webservice der SCHUFA für die Auskunft über Kunden dienen, dessen Integration nicht nur Automatisierung fördert, sondern auch ein Beispiel für teilweises Outsourcing darstellt.

Literatur

297

• Reduktion von Schnittstellen: Arbeitsteilige Prozessabwicklung weist naturgemäß Schnittstellen auf organisatorischer und technischer Ebene auf. Sie involviert verschiedene Organisationseinheiten und externe Partner, die oft mit uneinheitlichen ITSystemen und Arbeitsmitteln mitunter an verschiedene Medien gebundene Zwischenergebnisse erzeugen und austauschen. Folgen sind Medienbrüche und damit verbundene Doppelarbeit, Übertragungsfehler, Zeitverluste, Kosten usw. Eine Verringerung der Schnittstellen wirkt diesen Nachteilen entgegen. Sie lässt sich erzielen durch organisatorische Veränderungen wie die Reintegration oder Eliminierung von Aktivitäten und die Änderung der Zuordnung von Aufgaben zu Aufgabenträgern. Auf der technischen Ebene helfen integrierte IT-Systeme wie Enterprise-Resource-Planning-Software und Workflow-Anwendungen. Beim Kreditantragsbeispiel hat die teilweise Verlagerung der Unterschriftenkompetenz auf die Sachbearbeitungsebene deren Aufgabenzuschnitt und denjenigen der Abteilungsleitung verändert. Als Konsequenz konnten ein Ablaufzweig eliminiert und die dazugehörigen Schnittstellen reduziert werden. Zu beachten ist, dass viele der genannten Optimierungsansätze interdependent sind, und deshalb immer Auswirkungen einer Maßnahme auf andere Faktoren der Gestaltung zu berücksichtigen sind. So kann beispielsweise das Outsourcing von Prozessteilen die Anzahl der Schnittstellen erhöhen und Aufwand für das Dienstleistungsmanagement verursachen. Diese Effekte wirken den Vorteilen der Auslagerung entgegen, so dass stets eine Abwägung nötig ist.

Literatur Bonitasoft (2022) Bonita camp -en – part 7 – user management. https://www.bonitasoft.com/videos/ bonita-camp-en-part-7-user-management. Zugegriffen am 15.03.2023 Hollingsworth D (1996) The workflow reference model document number tc00-1003; workflow management coalition Fleischmann A, Borgert S, Elstermann M, Krenn F, Singer R (2017) An overview to s-bpm oriented tool suites. In: Mühlhäuser M, Zehbold C (Hrsg) Proceedings of the 9th International Conference on Subject-oriented Business Process Management, S-BPM ONE. ACM, TU Darmstadt Bonér J, Farley D, Kuhn R, Thompson M (2014) The reactive manifesto. https://www. reactivemanifesto.org/. Zugegriffen am 15.03.2023 Lawall A, Schaller T, Reichelt D (2013) Integration of dynamic role resolution within the s-bpm approach; s-bpm one-running processes. In: Proceedings of the 5th International Conference on Subject-oriented Business Process Management. S-BPM ONE. Springer, Berlin Newman S (2015) Building Microservices. O’Reilly, Köln Schaller TW (1998) Organisationsverwaltung in CSCW-Systemen. Dissertation Universität Bamberg Schmidt W (2013) Business activity monitoring. In: Rausch P, Sheta AF, Ayesh A (Hrsg) Business intelligence and performance management – theory, systems and industrial applications. Springer, London Van Der Aalst W (2016) Process mining: data science in action, Bd 2. Springer, Berlin Veit F, Geyer-Klingeberg J, Madrzak J, Haug M, Thomson J (2017) The proactive insights engine: process mining meets machine learning and artificial intelligence. BPM (Demos)

8

Werkzeuge

Um wirklich effektiv zu sein, sollten die einzelnen Aktivitätenbündel des Vorgehensmodells durch digitale Werkzeuge unterstützt werden um Prozesse, bzw. die sie beschreibenden Modelle, flexibel zu halten und sie schnell an neue Anforderungen anzupassen oder gemachte Erfahrungen bei der Ausführung der Prozesse als Verbesserungen einfließen zu lassen. Abb. 8.1 zeigt die jeweiligen Werkzeugtypen, die für einzelnen Aktivitätenbündel eingesetzt werden könnten. Die Funktionen der einzelnen Werkzeuge hängen dabei natürlich stark von den jeweiligen Modellierungsmethoden ab. In den folgenden Abschnitten werden die Eigenschaften der Werkzeuge für die Unterstützung der jeweiligen Aktivitätenbündel beschrieben und mit einigen Beispielen illustriert. Damit soll ein Eindruck über die grundsätzlichen Funktionen von Werkzeugen vermittelt werden. Es handelt sich nicht um eine systematische Untersuchung und Bewertung von einzelnen Werkzeugen und es soll auch kein annähernd vollständiger Überblick über die Werkzeuglandschaft gegeben werden. Für die einzelnen Modellierungsmethoden gibt es in der Regel mehrere Werkzeuge, deren Anzahl und Verfügbarkeit sich auch laufend ändern, so dass jeder detaillierte Vergleich sich in kurzer Zeit überlebt hätte. Die vorgestellten Tools sind willkürlich ausgewählt und es ist keine Wertung damit verbunden. Sie sind allerdings alle prinzipiell gut dafür geeignet die angedachten Aufgaben zu erfüllen. Die Auswahl von Werkzeugen für eine Geschäftsprozessmanagementprojekt hängt stark vom organisatorischen Umfeld ab. Dieses umfasst beispielsweise die Qualifikation und die Vorzüge der am Projekt beteiligten Personen oder Organisationen, die nicht selten Vorgaben für die zu verwendende Software machen. Die folgenden Ausführungen liefern daher lediglich Anhaltspunkte für die Auswahl, falls keine solchen gegebenen Faktoren vorliegen.

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_8

299

300

8 Werkzeuge

Abb. 8.1 Werkzeuge zur Erfassung und Implementierung von Geschäftsprozessen

8.1

Erfassungs- und Modellierungswerkzeuge

Die zentrale Aktivität im Prozessmanagement ist die Definition der Prozessstrategie und Prozesslogik (siehe Abb. 1.2). Damit werden die Anforderungen an die spätere Prozessimplementierung definiert.1 Welche Eingabe erhält ein Prozess bzw. Prozessbeteiligter, wie interagiert er mit seinem Umfeld (andere Prozesse etc.), in welcher Reihenfolge werden die einzelnen Aktivitäten ausgeführt oder welches Ergebnis produziert er zur Befriedigung des Kundenbedürfnisses. Bei der Analyse der einzelnen Modellierungswerkzeuge wird dabei insbesondere auf folgende Aspekte eingegangen: • Beschreibung komplexer Prozesssyteme: Prozesse sind in der Regel sehr komplex, insbesondere wenn Organisations- oder sogar Unternehmensgrenzen überschritten werden. Kein Prozess steht für sich alleine. Er ist 1 Wenn die Definition als Teil eines Entwicklungsprojektes erfolgt, sind diese Werkzeuge dabei

essentiell und automatisch auch für die Konzipierung bzw. das Design in der Entwicklung von Prozessen wichtig.

8.1 Erfassungs- und Modellierungswerkzeuge

•

•

•

•

•

301

eingebettet in eine Landschaft anderer Prozesse. So geht einem Anlieferungsprozess ein entsprechender Bestellprozess voraus. Um diese Komplexität anschaulich zu beschreiben sind Hierarchisierungskonzepte und formale Abstraktionsmechanismen notwendig (siehe Abschn. 4.1 in Kapitel). Das verwendete Modellierungswerkzeug sollte solche enthalten bzw. unterstützen. Natürlich-sprachliche Anmerkungen in Modellen: Jedes Prozessmodell, egal in welcher Methode erstellt, bedarf relativ oft zusätzlicher Informationen, die in der Regel in natürlicher Sprache hinzugefügt werden um meistens anderen Menschen ein besseres Verständnis zu ermöglichen. Ein Modellierungswerkzeug sollte also die Möglichkeit bieten an allen Stellen des Modells solche Ergänzungen einzufügen. Ausdruck auf gängige Papierformate: Modelle werden digital am Bildschirm erstellt, der aufgrund von Scroll-Funktionen auf einem beliebig großen Zeichenblatt operiert. Für Diskussionen oder Kontrollaufgaben ist es trotz fortschreitender Digitalisierung immer noch praktisch und manchmal sogar z. B. aus Compliance-Gründen notwendig, Modelle sowie die natürlich-sprachlichen Ergänzungen auf Papier oder in einem von den klassischen Papierformaten inspirierten Format (z. B. ein A4-PDF) zur Verfügung zu haben. Dies bedeutet, dass es durch entsprechende Druckfunktionen möglich sein sollte, ein Modell auf verschiedene Seiten sinnvoll aber auch einfach aufzuteilen. Neben der Diskussion des Prozesses ist eine solche Funktion auch dann notwendig, wenn das Prozessmodell mit den Ergänzungen z. B. ein Teil von Ausschreibungsdokumentationen für die eigentliche digitale Umsetzung sein soll. Folglich sollte eine einfache Möglichkeit bestehen, Modelle in Dokumente in gängigen Office-Werkzeugen einfügen zu können. Austausch von Modellen zwischen verschiedenen Modellierungswerkzeugen: Für die einzelnen Aufgabenbündel werden verschiedene Werkzeuge verwendet, wobei diese idealerweise jeweils auf die Ergebnisse anderer Tools zugreifen können. So muss zur organisatorischen Implementierung neben dem Prozessmodell auch auf die Beschreibung der Organisationsstruktur zugegriffen werden. Dazu ist es notwendig, dass die Speicherstrukturen der jeweiligen Werkzeuge bekannt sind und zueinander passen. Darstellung verschiedener Modellaspekte: Modelle für Prozesse beschreiben verschiedene Aspekte. Werkzeuge sollten demnach die Struktur von Prozessen und Prozessakteuren, die Dynamik des Prozessablaufs und die Strukturen der im Prozess verwendeten Daten darstellen können. Art der Implementierung: Im Wesentlichem können Modellierungswerkzeuge als Stand-alone- Anwendungen oder als Web-Anwendungen realisiert sein. Bei einer Stand-alone-Anwendung ist das Werkzeug lokal auf dem benutzten PC installiert und auf diesen beschränkt. Die Modelle können damit in einem geschützten Umfeld gespeichert werden, müssen aber auch entsprechend exportiert und transportiert werden, falls der Bedarf besteht sie an anderen Stellen zu verwenden. Bei web-basierten Implementierungen lauft das Front

302

8 Werkzeuge

End der Anwendung als App lokal im Browser, während das eigentliche Programm und die Datenspeicherung auf einem dedizierten Computer im Netz laufen (Server), der im Besitz eines Service-Anbieters sein kann. Dadurch können mehrere geografisch verteilte Teilnehmer gleichzeitig auf eine Modellbeschreibung zugreifen und diese bearbeiten. Die genannten Eigenschaften von Werkzeugen für das Geschäftsprozessmanagement sind gemäß den praktischen Erfahrungen des Autors wesentlich für die Beschreibung komplexer Prozessysteme in einem industriellen Umfeld. Auf die Aspekte für die Handhabung der jeweiligen grafischen Editoren und sonstige Bedienfunktionen wird nicht eingegangen, da diese vom individuellen Geschmack des Anwenders abhängen und in der Regel häufigen Änderungen unterworfen sind. Im Folgenden werden willkürlich ausgewählte Werkzeuge für die Modellierungsmethoden aus Kap. 3 kurz an Hand der genannten Aspekte erläutert und ihre Funktionalität für die einzelnen Aktivitätsbündel exemplarisch illustriert .

8.1.1

Modellierung von Flussdiagrammen

Da Flussdiagramme zur ersten Generation von Prozessbeschreibungsmethoden gehören gibt es dazu zahlreiche Werkzeuge. Die Abb. 8.2 zeigt z. B. mit Miro2 ein web-basiertes, in einer reduzierten Version frei verfügbares Werkzeug mit einem einfachen Flussdiagramm. Auf der linken Seite sind die für Flussdiagramme erlaubten Symbole sichtbar. Die Möglichkeit von Prozesshierarchien wird dadurch unterstützt, dass in ein Subprozesssymbol ein Link auf die entsprechende Prozessbeschreibung eingefügt werden kann. Abb. 8.2 zeigt die Verwendung des Subprozesssymbols im Zweig „unclear“ der Entscheidung („angekoppelter Unterprozess“). Anmerkungen in natürlicher Sprache werden direkt in das Bild eingefügt. Damit sind längere Kommentare nur sehr eingeschränkt möglich. Wie in Abb. 8.2 zu sehen ist, gibt es mehrere Möglichkeiten Text in die Grafik einzufügen. Zum Export der Beschreibung stehen nur die Formate JPG und PDF, also reine Grafiken, zur Verfügung. Ein Prozessmodell kann also nicht direkt in ein Office-Dokument eingebunden werden, sondern es muss per Copy und Paste eingebaut werden. Das Werkzeug geht von einer beliebig großen Zeichenfläche aus. Um die Größe eines Modells für den Export aufzubereiten muss es vom Benutzer selbst in entsprechende DIN-A4-Seiten zerlegt werden. Das Werkzeug erlaubt die Beschreibung der Prozesslogik in Form von Flussdiagrammen, es gibt jedoch keine Funktionen um die Struktur der verwendeten Daten zu beschreiben. Eine allgemein zugängliche Definition des verwendeten Speicherformats

2 https://miro.com/de/diagramm/.

8.1 Erfassungs- und Modellierungswerkzeuge

303

Abb. 8.2 Werkzeug zum Zeichnen von Flussdiagrammen

konnte nicht gefunden werden, so dass eine direkte Weiterverwendung der erstellten Modellbeschreibungen in anderen Werkzeugen nicht ohne weiteres möglich ist. Ein weiteres betrachtetes Modellierungswerkzeug basiert auf dem DiagrammZeichenwerkzeug Visio von Microsoft. Dieses Tool kann als Erweiterung von Microsoft Office als Stand-alone-Anwendung erworben werden. Abb. 8.3 zeigt ein einfaches Flussdiagramm, das mit der entsprechenden Symbolpalette von MS Visio erstellt wurde. Bei der Verwendung von MS Visio mit den verfügbaren Standard Shapes (Standardsymbolpalette) für Flussdiagramme gelten ähnliche Einschränkungen wie für das oben beschriebene Miro-Werkzeug, die im Wesentlichen auf die Restriktionen der Flussdiagramme selbst zurückzuführen sind. Da MS Visio beliebige Symbolpaletten enthalten kann, besteht hier die Möglichkeit über passende Diagrammvarianten auch die jeweiligen Datenstrukturen zu modellieren. Die Grafiken mit den Beschreibungen der Datenstrukturen können dann durch Links mit den Ablaufelementen verknüpft werden, in denen die jeweiligen Daten verwendet werden. Dies muss jedoch manuell geschehen, da es keine automatische Unterstützung für dieses Vorgehen gibt

8.1.2

Modellierung von UML-Diagrammen

UML umfasst 14 verschiedene Diagrammarten. Insbesondere gibt es Diagramme zum Modellieren von (Daten-)Strukturen und Diagramme für dynamische Aspekte wie z. B. Aktivitätsdiagramme (Activity Diagram). Ein Beispiel für ein webbasiertes Zeichenwerkzeug

304

8 Werkzeuge

Abb. 8.3 Erstellen von Flussdiagrammen mit dem Universalzeichenprogramm MS Visio

zum Erstellen von Activitydiagrammen ist Lucidchart. Ein Screenshot um einen visuellen Eindruck von der Benutzeroberfläche zu bekommen konnte nicht eingefügt werden, da eine Freigabeanfrage von der Herstellerfirma nicht beantwortet wurde. Aktivitätsdiagramme ähneln den Flussdiagrammen, stellen aber auch Elemente zur Modellierung verteilter und paralleler Abläufe zur Verfügung (siehe Abschn. 3.4). Dadurch können Abstraktionskonzepte wie bei Flussdiagrammen, also Subprozesse, verwendet werden. Natürlich-sprachliche Erläuterungen können als Textannotationen in ein Diagramm eingefügt werden. Mit Lucidchart erstellte Diagramme können in verschiedene Formate wie PDF, JPEG usw. konvertiert werden. In der Premiumversion ist prinzipiell auch der Export in das MS-Visio-Format und damit die weitere Diagrammbearbeitung dort möglich. Die Qualität dieser Konvertierung konnte vom Autor nicht überprüft werden. In Lucidchart können Diagramme maximal die Größe von einem Zeichenblatt (DIN A4) haben. Dies erleichtert das Drucken und zwingt zur Strukturierung durch Verwendung von Subprozessen. Lucidchart erlaubt auch die Modellierung von Datenstrukturen, u. a. mit der typischen UML- Klassendiagramm-Notation. Die entsprechenden Symbolpaletten können bei der Modellierung von Activity Diagrams bereits mit verwendet werden (Leiste mit den Symbolpaletten am linken Rand der Benutzeroberfläche). Durch Verknüpfungen (Links) können Datenstrukturdiagramme mit Aktivitätsdiagrammen verbunden werden.

8.1 Erfassungs- und Modellierungswerkzeuge

305

Abb. 8.4 Erstellen von UML-Aktivitätsdiagrammen mit dem Universalzeichenprogramm MS Visio

Abb. 8.4 zeigt die Erstellung eines UML-Aktivitätsdiagramms mit MS Visio. Hier gelten die bereits bei der Anwendung von MS Visio für Flussdiagramme beschriebenen Eigenschaften.

8.1.3

Modellierung von Ereignisgesteuerte Prozessketten-Diagrammen (EPK)

Ereignisgesteuerte Prozesskettendiagramme sind im Wesentlichem Flussdiagramme, die durch weitere Informationen ergänzt werden (siehe Abschn. 3.3). Das Hinzufügen dieser zusätzlichen Informationen, wie z. B. verwendete Daten oder die ausführenden Organisationseinheiten, wird von allen Werkzeugen entsprechend unterstützt (siehe untere Hälfte der Symbolleiste des Werkzeugs ARIS BASIC3 in Abb. 8.5). Durch die in den EPKs möglichen Process Interfaces, die in ARIS Basic unterstützt werden, können komplexe Prozesse strukturiert werden. ARIS Basic erlaubt auch das Einbinden von verschiedenen Dokumenten einschließlich Videos. 3 https://www.softwareag.com/de_de/platform/aris/process-design.html.

306

8 Werkzeuge

Abb. 8.5 Erstellen von EPK-Diagrammen mit dem ARIS Basic Werkzeug

ARIS BASIC ist ein web-basiertes Werkzeug. Dies bedeutet, dass mehrere Personen gemeinsam an einem Modell arbeiten können. Die Modelle werden in der zugehörigen ARIS Cloud gespeichert. Prozessmodelle können nur grafisch im PNG-Format exportiert, lokal gespeichert und dann gedruckt werden. Andere Exportformate hat der Autor in ARIS Basic nicht gefunden. Wie ein Prozessmodell mit den hinzugefügten Informationen zu einem Gesamtdokument zusammengefasst werden kann, konnte vom Autor ebenfalls nicht herausgefunden werden. EPKs lassen sich auch durch entsprechende Paletten mit Hilfe von MS Visio erstellen. Diese Software ist weitverbreitet im Einsatz und der Umgang mit ihr vielen Anwendern vertraut, so dass der Trainingsaufwand für die Benutzung gering sein dürfte. Die Abb. 8.6 zeigt die Benutzeroberfläche für die Erstellung von EPK-Diagrammen mit Hilfe von MS Visio.

8.1.4

Modellierung von BPMN-Diagrammen

Eine Google-Suche zeigt, dass eine Vielzahl von Modellierungswerkzeugen existiert, die auf der Business Process Model and Notation (BPMN) basieren. Wie in Abschn. 3.5 beschrieben, gibt es in BPMN nur Hierarchien für die Beschreibung der Abläufe innerhalb eine Pools und dort auch nur innerhalb einer Lane. Es gibt keine Möglichkeit komplexe

8.1 Erfassungs- und Modellierungswerkzeuge

307

Abb. 8.6 Erstellen von EPK-Diagrammen mit dem Universalzeichenprogramm MS Visio

Kommunikationsstrukturen zwischen Pools zu beschreiben, so dass entsprechende Funktionen auch nicht in den jeweiligen Werkzeugen enthalten sind. Abb. 8.7 zeigt ein einfaches BPMN-Diagramm mit zwei Pools. Das Beispiel wurde mit dem Modeler von Camunda erstellt.4 Bei diesem Werkzeug sind sprachliche Ergänzungen nur direkt im Diagramm möglich (siehe „erklärender Text“ in Abb. 8.7). Größere Dokumente z. B. im PDF-Format können nicht hinzugefügt werden. Zum Ausdrucken muss ein Modells exportiert werden, z. B. im PNG-Format. Bereits beim Erstellen eines Modells muss darauf geachtet werden, dass es lesbar auf eine Standardseite ausgedruckt werden kann. Ein Zeichentableau im Modellierungswerkzeug entspricht einer DIN- A4-Seite beim Drucken. Der Camunda Modeler fokussiert die Modellierung auf die Ablaufaspekte eines Geschäftsprozesses. Es lässt sich zwar modellieren, dass für Aktionen bestimmte Daten benötigt werden (BPMN-Standard), aber die Struktur und Eigenschaften dieser Daten müssen mit anderen Werkzeugen definiert werden. Das web-basierte Tool erlaubt den Download der erstellten Prozessmodelle im BPMNXML-Standardformat, so dass Modelle theoretisch mit anderen Werkzeugen weiterverar-

4 https://camunda.com/de

308

8 Werkzeuge

Abb. 8.7 Erstellen von BPMN-Diagrammen mit einem BPMN-spezifischen Modellierungswerkzeug (Camunda Modeler)

beitet werden können, was in der Praxis aber oft mit Schwierigkeiten verbunden ist. Auch MS Visio enthält Shapes zum Erstellen von Prozessmodellen in BPMN (siehe Abb. 8.8). Hier gelten die gleichen Eigenschaften wie sie schon bei der Anwendung von MS Visio für Flussdiagramme oder Aktivitätsdiagramme beschrieben wurden. Allerdings benutzt MS Visio zur Speicherung der Modelle ein eigenes Format, so dass im BPMN-XML gespeicherte Modelle nicht nativ importiert werden können. Umgekehrt erlaubt es MS Visio nicht, Modelle in diesem Format abzuspeichern.

8.1.5

Modellierung von PASS-Diagrammen

In Abschn. 4.1.5.6 werden die Möglichkeiten der subjektorientierten Modellierungssprache PASS (Parallel Activity Specification Schema) für die hierarchische Beschreibung komplexer Prozesssysteme erläutert. Diese Möglichkeiten werden in unterschiedlichem Ausmaß durch verschiedene Werkzeuge unterstützt. Mit der auf der Eclipse-Entwicklungsumgebung basierenden Metasonic Suite als Bestandteil von Metasonic One der Firma Allgeier Inovar können Prozesssysteme hierarchisch beschrieben werden.5 Abb. 8.9 zeigt ein Prozesssystem, das mit der in der Suite enthaltenen Modellierungskomponente Metasonic Build erstellt wurde und aus

5 https://www.allgeier-inovar.de/de/produkte/ecm-loesungen/metasonic.html.

8.1 Erfassungs- und Modellierungswerkzeuge

309

Abb. 8.8 Erstellen von BPMN-Diagrammen mit dem Universalzeichenprogramm MS Visio

drei Prozessen besteht. Diese sind über einen Austausch von Nachrichten miteinander verknüpft. Jeder Subprozess besteht aus den jeweiligen Subjekten, welche Nachrichten austauschen. Werden Nachrichten an Subjekte in einem anderen Subprozess gesendet, dann werden diese Subjekte als sogenannte externe Subjekte modelliert. In Abb. 8.10 ist dies das Subjekt „Lieferant“. Für jedes Subjekt wird ein Verhalten definiert (siehe Abschn. 3.6), in dem die Ausführungsreihenfolge der Sende-, Empfangs- und internen Operationen definiert ist. Das Erstellen eines entsprechenden Verhaltensdiagramms zeigt Abb. 8.11. Allgeier Inovar bietet mit dem Produkt Metasonic Process Touch ein Werkzeug zur Verhaltensbeschreibung, das ein gewisses Alleinstellungsmerkmal hat.6 Die Modellierungsfläche ist ein Tisch, auf dem mit Bauklötzen, die den einzelnen Symbolen in der Verhaltensbeschreibung entsprechen, das Subjektverhalten spezifiziert wird (siehe Abb. 8.12). Die Modellierung gemeinsam an einem Tisch unterstützt die Kollaboration derjenigen, die an einem Prozess beteiligt sind, also der Repräsentanten der involvierten Subjekte. Am Tisch erzeugte Modelle können am Rechner weiterbearbeitet werden und umgekehrt.

6 Ein Video dazu findet sich unter https://www.youtube.com/watch?v=Yz2oRLQyHmw.

310

8 Werkzeuge

Abb. 8.9 Strukturbeschreibung komplexer Prozesssysteme in der Metasonic Suite

Die Metasonic Suite erlaubt die Eingabe von Text zu jedem Modellierungselement. So können Subprozesse, Subjekte, Nachrichten und Zustände kommentiert werden. Prozessmodelle können als PDF-Datei exportiert werden. In diesen PDF-Dokumenten sind auch alle Kommentare an geeigneter Stelle enthalten. Komplexe Grafiken werden automatisch aufgesplittet und auf mehrere Seiten verteilt, was die Grafiken natürlich nur bedingt leserlich macht. Das XML-Format, in dem das Werkzeug die Modelle speichert, kann direkt gelesen werden. Da dies allerdings ein proprietäres Format des Herstellers ist wird es nicht von anderen Werkzeugen unterstützt. Auch die Definition der in einem Prozess benutzten Datenobjekte (Geschäftsobjekte) ist mit der Metasonic Suite möglich. Abb. 8.13 zeigt die dafür genutzte Tabellenschreibweise.

8.1 Erfassungs- und Modellierungswerkzeuge

311

Abb. 8.10 Erstellen von Subjektinteraktionsdiagrammen (PASS SID) mit dem Werkzeug Metasonic Suite

Abb. 8.11 Erstellen von Subjektverhaltensdiagrammen (PASS SBD) mit dem Werkzeug Metasonic Suite

312

8 Werkzeuge

Abb. 8.12 Erstellen von Subjektverhaltensdiagrammen (PASS SBD) mit dem Werkzeug Metasonic Touch

Abb. 8.13 Erstellen von Geschäftsobjekten mit dem Werkzeug Metasonic Suite

8.1 Erfassungs- und Modellierungswerkzeuge

313

Abb. 8.14 Erstellen von Subjektinteraktionsdiagrammen (PASS SID) mit dem Werkzeug MS Visio

Ein weiteres Werkzeug zur subjektorientierten Modellierung von Geschäftsprozessen basiert auf MS Visio. Dieses unterstützt nativ kein PASS, aber durch entsprechende externe Symbolpaletten, die frei herunterladbar sind,7 kann die Funktion einfach nachgerüstet werden. Dabei wird MS Visio nicht nur um passive Symbole erweitert, sondern die Palette unterstützt die Modellierung aktiv durch hinterlegten Programmcode. Dies schließt viele Automatismen z. B. zum Namensmanagement von Nachrichten ein, aber auch Verifikationswerkzeuge für die Prüfung der syntaktischen Korrektheit. Abb. 8.14 zeigt das Subjektinteraktionsdiagramm (SID), eines einfachen Frager-Antworter-Prozesses. Auf der linken Seite des Bildes sind die verwendbaren Symbole sichtbar. Die obere Symbolleiste zeigt die möglichen Operationen, die auf einem Modell ausführbar sind, wie z. B. einfache Simulationsläufe (siehe Abschn. 5.2.4). Das entsprechende Verhaltensdiagramm (SBD) des Subjekts „Frager“ im gleichen Werkzeug zeigt Abb. 8.15.

7 https://subjective-me.jimdofree.com/visio-modelling/ bzw. https://github.com/I2PM/PASS-Modeling-Stencils-for-Microsoft-Office-Visio.

314

8 Werkzeuge

Abb. 8.15 Erstellen von Subjektverhaltensdiagrammen (PASS SBD) mit dem Werkzeug MS Visio

8.2

Validierungswerkzeuge

Beim Beschreiben von Prozessen ist man in der Regel bestrebt, ein effektives Prozessmodell zu erstellen, d. h. es wird versucht, mit dem Prozessmodell das gewünschte Ergebnis zu erreichen und den Aufwand dabei möglichst gering zu halten. Ausgehend vom Startereignis und den damit verknüpften Eingaben wird im Prozessmodell die sachlogische und zeitliche Reihenfolge der Operationen beschrieben, die von Handelnden z. B. auf Geschäftsobjekten ausgeführt werden, um das gewünschte Ergebnis zu erzielen. Das Prozessmodell wird dabei noch weitgehend unabhängig von seiner Realisierung betrachtet. Im Aktivitätenbündel Validierung wird überprüft, ob das Prozessmodell alle Aktionen in einer sinnvollen Reihenfolge sowie die notwendigen Geschäftsobjekte enthält.

8.2 Validierungswerkzeuge

315

Bei der Validierung werden also die Aspekte Handelnde, Aktionen und Objekte im Prozess betrachtet. Es gilt zu untersuchen ob alle möglichen Handlungsfolgen mit den Handelnden berücksichtigt und beschrieben wurden, und ob das Modell alle notwendigen Geschäftsobjekte mit ihrer Struktur enthält. Je nach Beschreibungsmethode für Prozessmodelle werden diese Aspekte mit unterschiedlicher Gewichtung betrachtet. In BPMN z. B. liegt der Schwerpunkt auf der Reihenfolge der Handlungen. Die Handelnden werden durch die Konstrukte Pool und Lane teilweise betrachtet. Geschäftsobjekte werden nur oberflächlich in ein Modell integriert. BPMN selbst unterstützt keine präzise Beschreibung von Geschäftsobjekten. Bisher kann kein Computersystem der Welt wirklich eigenständig die Realität erfassen. Deshalb ist die Überprüfung, ob ein Modell wirklich alle für den jeweiligen Anwendungsfall wichtigen Aspekte richtig abbildet, prinzipiell ein manuelle Aufgabe, bei der Prozessbeteiligte den Inhalt des Modells rezipieren und als richtig oder falsch betiteln können. Ausgehend von den Eigenschaften der verwendeten Modellierungssprachen unterstützen entsprechende Werkzeuge diese Aktivitäten mit den Aspekten der Handlungen, Handelnden und Geschäftsobjekte in unterschiedlichen Ausmaß. Oft kommt es zu einer Art des „Durchspielens“ des Prozesses. So unterstützt ein Plug In für den Camunda Modeler die Überprüfung der Reihenfolge der Handlungen innerhalb eines Prozesses, d. h. innerhalb eines Pools. Die Zusammenarbeit mehrerer Pools durch einen Nachrichtenaustausch wird nicht unterstützt. Abb. 8.16 zeigt ein Prozessmodell mit den jeweiligen Token für den Prozessablauf. Das ParallelGateway splittet den Ablauf in zwei parallele Ausführungsfolgen auf. Dies wird durch die zwei Token (grüne Punkte) veranschaulicht. Ein Token hat bereits das zusammenführende

Abb. 8.16 Token-Simulation im BPMN-Werkzeug von Camunda

316

8 Werkzeuge

Parallel-Gateway erreicht, während der zweite Token sich kurz vor der Ausführung der Aktion „Prepare Salad“ befindet. Datenobjekte und Handelnde werden in dieser TokenSimulation nicht betrachtet. In der Metasonic Suite wird die Prozessvalidierung durch die Komponente Metasonic Proof unterstützt. Da Metasonic die subjektorientierte Modellierung mit PASS als Paradigma nutzt, wird es hier unterschiedlichen Usern ermöglicht, das Verhalten einzelner Subjekte zu übernehmen und auszuführen. In einem IT-geführten Rollenspiel kann ein Prozess ausprobiert werden. Die Proof-Komponente erzeugt dabei aus dem PASS-Modell eine ablauffähige Version. Abb. 8.17 zeigt, wie eine Validierung aussieht. Als Beispiel wird der Frager-Antworter-Prozess aus dem Abschn. 8.1.5 (siehe Abb. 8.14 und 8.15) verwendet. Dazu wurde das bereits in MS Visio vorliegende Modell mit der Metasonic Suite nachmodelliert. Das war notwendig, weil die unterschiedlichen Speicherformate keine direkte Übernahme von MS Visio nach Metasonic erlauben.

Abb. 8.17 Validierung durch IT-unterstütztes Rollenspiel in der Metasonic Suite (Proof)

8.2 Validierungswerkzeuge

317

Die obere Hälfte von Abb. 8.17 zeigt die Eingaben für das Subjekt „Frager“ und die untere Hälfte für das Subjekt „Antworter“. Jeweils neben den Masken für die Benutzerinteraktion wird angezeigt, welche Pfade des Subjektverhaltens schon durchlaufen wurden (mit den jeweiligen Zustandsfarben) und welche noch nicht durchlaufen wurden (ausgegraut). In den Benutzerinteraktionen wird angezeigt, welches Subjekt bedient wird, in welchem Zustand es sich befindet, was der Folgezustand sein soll und auch, ob die Eingabe von Daten notwendig ist (der ganz rechte Knopf führt zur Eingabe der Parameterwerte). Dies ist beim „Antworter“ der Fall. Nach einem Klick auf den Knopf zur Parameterwerteingabe zeigt die Eingabemaske für den „Antworter“ den Fragentext und das Feld für die Eingabe der Antwort an (siehe Abb. 8.18). Der Validierer überprüft das Verhalten und den jeweiligen Datenbedarf. Die eingegebenen Werte können in der Implementierung natürlich auch durch Softwarefunktionen berechnet werden oder von Sensoren erfasste Werte sein. Der Validierer „simuliert“

Abb. 8.18 Eingabe von Parameterwerten bei der Validierung in der Metasonic Suite:

318

8 Werkzeuge

dadurch Softwarefunktionen, Sensoren und menschliche Eingaben. Die Validierung in der Metasonic Suite ermöglicht also die Prüfung, ob die Ablauffolgen und die Daten des Modells den Absichten für das Prozessmodell entsprechen.

8.3

Optimierungswerkzeuge

Bei der Optimierung werden die für die Prozessausführung notwendigen Ressourcen bzw. das Ausführungssystem des modellierten Prozesses untersucht. Hier wird also ermittelt, welche Ressourcen vorhanden und mit welchem zeitlichen Aufwand sie an einer Prozessausführung beteiligt sind. Aus den Kosten je Zeiteinheit und Ressource ergeben sich dann die Kosten für die Ausführung einer oder mehrerer Prozessinstanzen über einen bestimmten Zeitraum. Die Camunda-Werkzeuge unterstützen keine Simulationen, deshalb dient hier das Produkt Signavio von SAP als Beispiel für die Simulation mit BPMN-Modellen.8 Die Benutzeroberfläche des Signavio Simulators zeigt im oberen Teil das zu untersuchende Prozessmodell. Im unteren Teil können die notwendigen Parameter angegeben werden. Dort sind auch die Bearbeitungszeiten der Aktionen im Prozessmodell sichtbar (Ein Screenshot konnte nicht eingefügt werden, da eine Freigabeanfrage unbeantwortet blieb). Die Simulation mit dem Signavio-Werkzeug unterstützt Eingaben für die Kosten und Dauer einzelner Aktivitäten, die generellen Arbeitskosten einer Ressource pro Stunde, sowie die Wahrscheinlichkeit für die Wahl eines Pfades bei X-OR Entscheidungen. Es können sowohl feste Werte als auch verschiedene Wahrscheinlichkeitsverteilungen insbesondere für die Dauer von Aktivitäten eingegeben werden. Die Ergebnisse eines Simulationslaufs werden über das Prozessmodell angezeigt. Dort wird der Prozess in 5 Tagen 100-mal ausgeführt. Die Aktion „Antrag zurückstellen“ wird dabei 57 mal ausgeführt, genehmigt wird der Antrag 43 mal. Die Zusammenfassung auf der rechten Seite der Benutzerpberfläche zeigt, dass der Prozess keine Ressourcenengpässe enthält. Für die subjektorientierte Modellierung gibt es als Teil der in Abschn. 8.1.5 erwähnten MS Visio-Stencils das Werkzeug Simple Simulation (SiSi) (Elstermann und Ovtcharova 2018). Es erlaubt bei Bedarf die Ergänzung von PASS-Modellen z. B. um folgende Angaben: Dauer von Aktivitäten oder deren Verteilung (Do- und Send-States), Dauer der Übermittlung von Nachrichten, Fixkosten einer Ausführung (Do- und Send-States), Arbeitskosten, die ein Subjekt pro Zeit verursacht, Anteil der Wartezeiten in einem Empfangszustand, die für die Kosten mit berücksichtigt werden sollen,9 Wahrscheinlichkeiten für das Durchlaufen von Pfaden nach Verzweigungen in Do-States. Die Daten können 8 www.signavio.com. 9 Wenn eine reale Person in einer Prozessinstanz auf etwas warten muss, aber die Zeit produktiv

in einem anderen Prozess zur Verfügung steht, dann ist dieser Anteil 0 %. Wenn sie aber durch das Warten blockiert wird, dann muss diese Wartezeit, die von der Simulation berechnet wird, entsprechend zu 100 % auf die Kosten angerechnet werden.

8.3 Optimierungswerkzeuge

319

Abb. 8.19 Batch-Eingabe von Simulationsdaten in ein PASS-Modell mit dem Werkzeug SiSi

Abb. 8.20 Simulationsergebnisse von PASS-Modellen mit dem Werkzeug SiSi

einzeln oder als Batch für mehrere Zustände eingegeben werden. Abb. 8.19 zeigt die Batch-Eingabe der für die Simulation notwendigen Daten im Sisi-Werkzeug. Das Starten der Simulation so wie die erste Ausgabe bzw. Anzeige von Fehlern erfolgt über ein einfaches Fenster, wie es in Abb. 8.20 gezeigt wird.

320

8 Werkzeuge

Die Simulationsergebnisse des Signavio Simulators als auch von SiSi können im MS Excel-Format exportiert und damit weiterbearbeitet und analysiert werden. Einer der wichtigsten Unterschiede zwischen beiden Werkzeugen liegt in der subjektorientierten Natur von PASS begründet, die dafür sorgt, dass eine Auflistung von Aktivitäten nach Ressourcen in der Analyse unnötig wird, da das gesamte Modell bereits nach den Akteuren gestaltet worden ist. Ein tiefer gehender Vergleich zwischen beiden Werkzeugen und ihren Verwendungsmöglichkeiten findet sich in (Elstermann und Piller 2022).

8.4

IT-Implementierung

Geschäftsprozesse sind sozio-technische Systeme, d. h. es sind Menschen, Maschinen und Softwaresysteme an ihrer Ausführung beteiligt. Dabei steht im Zentrum meistens die mit IT realisierte Prozesslogik, in die menschliche Aktivitäten, physische Geräte oder Maschinen und bereits existierende oder neu zu erstellende Softwarebausteine integriert werden. Dieses Zusammenfügen solcher Elemente eines Geschäftsprozesses kann als IT-Implentierung interpretiert und durch passende Werkzeuge unterstützt werden. Ausgangspunkt ist die Implementierung der Prozesslogik, der darin verwendeten Geschäftsobjekte und der Softwarefunktionen, welche die gewünschten Aktionen auf diesen ausführen (siehe auch Abschn. 7.2). In das damit entstandene Softwaresystem werden dann physische Komponenten wie Sensoren, Aktoren oder auch komplexe Maschinen und Menschen als Benutzer eingebunden. Im Folgenden betrachten wir die Aspekte Prozesslogik, Geschäftsobjekte, Softwarefunktionen und physische Objekte. Der Einbindung von Menschen ist wegen ihrer Bedeutung für Geschäftsprozesse ein eigenes Kapitel gewidmet (siehe Abschn. 7.2.2).

8.4.1

Prozesslogik

Die beschriebene Prozesslogik kann abhängig von verwendeter Modellierungssprache mit den Fähigkeiten passender Werkzeuge direkt in ein weitgehend ausführbares Programm umgesetzt werden (siehe auch direkte vs. indirekte Ausführung in Abschn. 4.2.1). Plattformen mit dieser Fähigkeit werden heute auch als Low Code-Plattformen bezeichnet, bei denen diese Umsetzung nur sehr wenig (low) Programmieraufwand erfordert. Für EPK-Modelle sind dem Autor keine Low-Code-Plattformen bekannt. Dies gilt ebenso für UML-Aktivitätsdiagramme. Für BPMN gibt es ein standardisiertes XML-Format zur Speicherung der Modelle einschließlich einer Beschreibung der Ablaufsemantik. Letztere wird in natürlicher Sprache definiert. BPMN-basierte Werkzeuge können damit die Prozesslogik sofort ausführen, was schon die Validierung und Simulation ermöglicht (siehe Abschn. 8.2). Tools, die dies ermöglichen werden z. B. von den Firmen Camunda, Bizagi und Bonitasoft angeboten. Meist muss dazu lediglich eine Funktion in der Modellierungsumgebung aufgerufen werden.

8.4 IT-Implementierung

321

Zur automatischen Ausführung dürfen diese Prozesse allerdings keinen Nachrichtenaustausch enthalten. Dieser muss z. B. bei Camunda explizit programmiert werden. Dies wird durch Templates unterstützt.10

8.4.2

Formulare und Geschäftsobjekte

In die Prozesslogik, die auf einer entsprechenden IT-Plattform ausgeführt wird, müssen bei einzelnen Aktionen Menschen mit einbezogen werden. Sie werden z. B. aufgefordert, benötigte Daten über geeignete Formulare (Teile der grafischen Benutzeroberfläche der Ausführungsplattform) einzugeben. Erst wenn dies abgeschlossen ist wird die Folgeaktion angesteuert. Diese Formulare können bei den BPMN-basierten Werkzeugen in der Modellierungsumgebung direkt beschrieben und einzelnen Aktivitäten zugeordnet werden, in denen die Eingabeaufforderung erfolgen soll. Bei der Definition der Formulare legen die Werkzeuge auch entsprechende Geschäftsobjekte an, in denen die Eingaben zunächst gespeichert werden.11 Bei PASS-basierten Werkzeugen wird eine geringfügig andere Vorgehensweise verwendet, da hier die in der Ablauflogik verwendeten Datenobjekte Teil des Modells sind. Modelle die mit PASS-Diagrammen definiert wurden, enthalten auch die Beschreibung der benötigten Datenobjekte (siehe Abb. 8.13 für die Metasonic Suite und 8.21 für MS Visio). Die im Prozess verwendeten Datenobjekte sind also Bestandteil des Modells und werden zusammen mit der Ablaufbeschreibung in einem OWL-Format gespeichert (siehe Abschn. 4.2.2.5). In BPMN sind die in einem Prozess verwendeten Datenstrukturen nicht Teil des XML-Speicherstandards. Die Metasonic Suite generiert zusätzlich aus den in einer Funktion benötigten Geschäftsobjekten einen Formularvorschlag (siehe Abb. 8.22).

8.4.3

Einbettung von Softwarefunktionen

Während der Ausführung der Prozesslogik werden die definierten Geschäftsobjekte durch Benutzereingaben, Zugriffe auf bereits gespeicherte Daten oder Berechnungen mit Werten belegt. Außerdem können Werte von Geschäftsobjekten gespeichert werden um sie in nachfolgenden Prozessabläufen zu verwenden oder selbst Berechnungen auf ihnen zu auszuführen. Diese Operationen auf den Geschäftsobjekten werden mit den Aktivitäten im Prozessablauf verknüpft und ausgeführt, wenn die Ausführungsplattform beim Prozessablauf in diese Aktivität hineinläuft. Jede Aktion in einem Prozessablauf innerhalb einer

10 Siehe dazu die entsprechenden Videos auf der Camunda-Website https://camunda.com/de/. 11 Für Nutzer kann die Trennung von Formular (= GUI für individuellen Nutzer) und Geschäftsob-

jekte (= Daten-Objekt für Speicherung und Transport) ggf. irrelevant sein, da nur über Ersteres auf Zweites zugegriffen werden kann.

322

8 Werkzeuge

Abb. 8.21 Erstellen von Geschäftsobjekten bzw. Datentypen mit den ALPS-Shapes in MS Visio

digitalen Ausführungsplatform ist eine Softwarefunktion. Bei den genannten Funktionen handelt es sich zumeist um Standardfunktionen, die automatisch oder einfach per Dragand-Drop im Prozessmodell ergänzt werden (Low Code). Darüber hinaus gibt es jedoch meist abhängig vom Anwendungsfall und vor allem von den verwendeten IT-Systemen der Ausführungsorganisation eine Vielzahl von Funktionen oder Zugriffe auf Spezialsysteme. Diese sind nicht standardmäßig vorgegeben und müssen einzeln ergänzt, konfiguriert oder z. T. auch entwickelt werden.12 12 Meist ist dies auch der Punkt, an dem sich Werbeversprechen von Plattformanbietern als unrealistisch erweisen, weil die Entwicklung doch entsprechend aufwändig ist und zumeist nicht von Laien vorgenommen werden kann. Wie zuvor erwähnt sind diese ergänzenden Beschreibungen zu einem Prozessmodell meistens explizit auf eine Plattform bzw. auf eine einzelne Instanz für eine bestimmte Firma und deren IT-Ökosytem beschränkt. Eine einfache Verwendung in einem anderen Kontext ist nahezu ausgeschlossen.

8.4 IT-Implementierung

323

Abb. 8.22 Erstellen von Formularen aus Geschäftsobjekten mit der Metasonic Suite

BPMN-basierte Werkzeuge unterstützen in der Regel die Einbindung von entsprechenden Softwarebausteinen. Sie erlauben die Eingabe von Pfaden zu Software-Bibliotheken in nahezu alle gängigen Programmiersprachen (Java, Python, C++, C# usw.). Auch Frameworks wie Spring oder Programmierschnittstellen wie REST können genutzt werden, um Softwarefunktionen in eine Prozesslogik einzubauen. In der Metasonic Suite erfolgt die Einbindung von externen Softwarebausteinen oder auch Konnektoren über sogenannte Refinements. Jedem Zustand kann ein Refinement hinzugefügt werde. Das Refinement eines Subjekts, also der spezielle Softwarebaustein, kann dabei Zugriff auf alle Geschäftsobjekte, Formulare und Softwareefunktionen des Subjektes innerhalb einer Prozessinstanz erhalten. Abb. 8.23 zeigt, wie z. B. beim Do State Bestellantrag prüfen die entsprechend implementierte Funktion eingefügt werden kann. Natürlich können hier auch andere verfügbare Programme oder System-Calls eingebunden werden.

324

8 Werkzeuge

Abb. 8.23 Einbinden von Softwareteilen (Refinements) mit der Metasonic Suite

8.4.4

Physikalische Objekte

In Geschäftsprozessen können auch physikalische Komponenten wie Sensoren, Aktoren oder auch komplexe Maschinen eine Rolle spielen und müssen entsprechend eingebunden werden. Dies ist z. B. der Fall, wenn Aktivitäten durch physikalische Komponenten oder Maschinen ausgeführt werden. Diese Integration sollte bereits in den Modellen des zu implementierenden Prozesses berücksichtigt sein. Sie muss jedoch auch bei der Implementierung von Werkzeugen unterstützt werden, insbesondere dann, wenn es um die Automatsierung geht, und die entsprechenden Maschinen auch konkret angesteuert werden sollen (siehe z. B. die in Abschn. 4.3.1 behandelten Herausforderungen). Wenn für diese Komponenten entsprechende Softwaretreiber, oft Konnektoren genannt, existieren, kann ihre Einbindung analog der Integration von Softwarebausteinen stattfinden. Bei physikalischen Komponenten kann dies analog geschehen. Gibt es keine geeigneten Konnektoren, so kann die Integration indirekt erfolgen. Dabei fordert das Workflow-System einen Menschen auf, eine bestimmte Aktion auszuführen und das Ergebnis über ein entsprechendes Formular dem Workflow-System mitzuteilen.

8.5 Werkzeuge für die organisatorische Implementierung

325

Die Integration eines physikalischen Gerätes erfolgt also über eine organisatorische Integration (sozio-technisch).

8.5

Werkzeuge für die organisatorische Implementierung

Nach der Erstellung eines Modells für einen effektiven und effizienten Prozess gilt es dieses in die jeweilige Umgebung, also das sozio-technische System, in dem der Prozess ausgeführt werden soll, einzubetten. Die einzelnen Aktivitäten eines Prozesses werden durch Aufgabenträger ausgeführt, die entweder Menschen, Maschinen, Computerprogramme oder Kombinationen davon sein können (siehe dazu Abschn. 7.2). Die Zuordnung der Aufgaben zu ausführenden Aufgabenträgern bezeichnen wir als organisatorische Implementierung. Sie ist formal zu beschreiben. Die Zuordnung von Aufgabenträgern hängt davon ab, ob die Prozesslogik nach Vorgabe (Arbeitsanweisung), computergesteuert (Workflow Engine) oder aus einer Kombination aus beidem abgearbeitet wird. Bei einer Ausführung nach Vorgabe müssen entsprechende Arbeitsanweisungen erstellt werden. Werkzeuge, die deren Erstellung unterstützen, werden hier nicht betrachtet. Idealerweise können die Prozessmodelle selbst als entsprechende Anweisungen fungieren.13 Unser Fokus liegt auf der Digitalisierung, d. h. auf Szenarien bei denen die Prozesslogik computergesteuert ausgeführt wird. Die Zuordnung von Aufgabenträgern, in dem Fall Anwender der entsprechenden Softwareplattformen, zu den einzelnen Aufgaben muss hier formal erfolgen. Dies wird aber nur von sehr wenigen Werkzeugen unterstützt und dann meist auch als Zuordnung von Personen direkt zu einzelnen Aufgaben.14 Als einziges der in Abschn. 8.1 vorgestellten Modellierungswerkzeuge unterstützt die Metasonic Suite die Zuordnung von Personen zu Aufgabenbereichen, in diesem Fall zu Subjekten. Im Modellierungswerkzeug kann einem Subjekt eine Rolle zugeordnet werden. Diese kann als ein Aufgabenbereich in einer Organisation gesehen werden. Einer Rolle können mehrere Subjekte zugeordnet werden. Die Zuordnungen definieren den Aufgabenbereich einer Rolle. Abb. 8.24 zeigt, wie dem Subjekt „Frager“ die Rolle Fragesteller zugeordnet wird. Die Rolle Fragesteller wurde vorher mit dem Rolleneditor angelegt. Die Rolle ist das Bindeglied zur Aufbauorganisation. Die Metasonic Suite baut auf LDAP Directories (Lightweight Directory Access Protocol) auf. Sie beinhaltet einen Editor zur Verwaltung der Aufbauorganisation aus Benutzern, Gruppen und Rollen. Die Rollen, die den Subjekten im Modellierungswerkzeug zugeordnet wurden, müssen sich in dieser Organisationsbeschreibung wiederfinden. Abb. 8.25 zeigt, wie im Directory

13 Hier liegt u. a. eine der Stärken der subjektorientierten Beschreibung insbesondere mit PASS, bei der die Verhaltensdiagramme bereits konkrete Beschreibungen für einzelne Aufgabenbereiche darstellen und auch einzeln weitergegeben werden können. 14 Dies liegt zumeist an der Verwendung von Modellierungssprachen, die nur task-orientierter Logik folgen.

326

Abb. 8.24 Zuordnung von Subjekten zu Rollen mit der Metasonic Suite

Abb. 8.25 Anlegen einer Rolle in der Metasonic Suite

8 Werkzeuge

8.6 Werkzeuge für den Betrieb und das Monitoring

327

Abb. 8.26 Zuordnung von Rollen zu Gruppen in den Camunda-Werkzeugen

die Rollen angelegt werden, die im Modellierungswerkzeug bereits benutzt und dort Subjekten zugeordnet wurden. Durch die Zuordnung von Rollen zu Gruppen und von konkreten Benutzern zu Gruppen werden jedem Subjekt die Mitarbeiter zugewiesen, die das Subjektverhalten ausführen sollen. Diese im Editor der Metasonic Suite verwaltete Zuordnung erlaubt die einfache Änderung der Einbettung eines Prozesses in die Organisation, also beispielsweise bei Neueinstellungen, Freistellungen, Versetzungen oder Umgruppierungen ganzer Organisationseinheiten. Eine ähnliche Zuordnung findet in der Camunda-Suite statt, allerdings nicht orientiert an Subjekten, sondern auf Aktivitätenbasis bzw. auf Basis der Erlaubnis, einen Prozess mit der ersten Aktivität zu starten. Darüber hinaus werden bei Camunda bei der Zuordnung von Aufgabenträgern zwei Fälle hinsichtlich der technischen Autorisierung unterschieden, die für die Datensicherheit relevant sind. • Situationen/Aktivitäten, in denen eine Autorisierung notwendig ist: – Eine REST-API kann auch nach der Authentifizierung nur eingeschränkt verwendet werden. – Eine Web-Anwendung kann von Benutzern auch nach der Authentifizierung nur eingeschränkt verwendet werden. – Nicht vertrauenswürdige Nutzer können Abfragen und Kommandos auf der Workflow Engine ausführen. • Situationen, in denen eine Autorisierung nicht notwendig ist: – Eine externe Anwendung kann via API-Methode die Workflow Engine vollständig kontrolliert innerhalb des Prozesses aufrufen. – Benutzer haben nach der Authentifizierung vollen Zugriff auf die Workflow Engine via Web-Anwendung. Die Zuordnung der Aufgabenträger ist bei Camunda stark von den Anwendungen abhängig, in die die einzelnen Prozesse eingebettet sind. Abb. 8.26 zeigt wie der Prozess „invoice“ der Gruppe „Accounting“ zugeordnet wird.

8.6

Werkzeuge für den Betrieb und das Monitoring

Nahezu alle Geschäftsprozessmanagementplattformen erzeugen bei der Ausführung von Prozessen Daten, die für die Beurteilung der Effektivität und Effizienz der Prozesse verwendet werden können. Neben klassischen individuellen Process Performance Indicators

328

8 Werkzeuge

(PPIs), die sich auf eine einzelne Instanz beziehen, wie z. B. die Dauer eines Durchlaufes, gibt es auch viele Daten, die unabhängig von der spezifischen Aufgabe eines Prozesses sind. Beispiele sind die Anzahl der Instanzen für einen Prozess innerhalb eines bestimmten Zeitraums oder die durchschnittliche Ausführungszeit über mehrere Prozessinstanzen bzw. Aktionen hinweg. Diese Daten können dann mit entsprechenden Analysewerkzeugen, im einfachsten Fall mit MS Excel, ausgewertet werden. Bei den Camunda-Werkzeugen werden die Ausführungsinformationen der Prozessinstanzen von der Workflow Engine in einer Datenbank gespeichert. Von dort werden die Daten dann exportiert in ein Format, das vom Werkzeug Elasticsearch15 verstanden wird. Mit Elasticsearch werden dann die gewünschten Analysen durch geführt. Abb. 8.27 zeigt eine Analyse über die Häufigkeit, in der die Aktionen eines Prozesses ausgeführt werden. Dabei wird eine sogenannte Heat Map verwendet, die über das Prozessmodell gelegt wird. Die Farbe grün bedeutet eine niedrige Anzahl und rot eine hohe Zahl von Ausführungen der einzelnen Aktionen. Mehrere solcher Berichte, wie sie in Abb. 8.27 sichtbar sind, können von Camunda zu einem Dashboard zusammengeführt werden (vgl. Abb. 8.28). Die Metasonic Suite stellt ebenso Ablaufdaten der Prozessinstanzen zur Analyse in einer Datenbank bereit. Da es dort keine vordefinierten Analysewerkzeuge wie bei Camunda gibt müssen die Log-Daten in diesem Fall mit externer Software ausgewertet werden.

Abb. 8.27 Heatmap Overlay auf einem Prozessmodell in Camunda zur Analyse, wie oft bestimmte Aktionen ausgeführt werden

15 www.elasticsearch.com.

8.7 Zusammenwirken der Werkzeuge

329

Abb. 8.28 Zusammenfassung mehrerer Berichte zu einem Dashboard in Camunda Optimize

8.7

Zusammenwirken der Werkzeuge

Die einzelnen Aktivitäten aus den beschriebenen Aktivitätenbündeln werden mit Unterstützung durch die jeweiligen Werkzeuge ausgeführt. Je nach Vorgehensweise wird zwischen den Aktivitäten gewechselt. Dies bedeutet, dass die Ergebnisse der einzelnen Aktivitäten gespeichert und von anderen Werkzeugen aufgegriffen und mit weiteren Informationen angereichert werden. So werden z. B. die mit Modellierungswerkzeugen erstellten Prozessmodelle von Simulationswerkzeugen aufgegriffen, mit Daten zu Bearbeitungsaufwänden, Ressourcen etc. angereichert und in Simulationsläufen verwendet. Zur organisatorischen Implementierung werden die Informationen aus den Prozessmodellen mit Informationen zur Aufbauorganisation zusammengeführt. Durch Konnektoren werden Softwarefunktionen oder physikalische Geräte eingebunden. Abb. 8.29 zeigt, wie die einzelnen Werkzeuge für die jeweiligen Aktivitätenbündel zur Realisierung von Prozessen zusammenwirken. Ein zentraler Aspekt dabei ist das Speicherformat für die Prozessmodelle und die Bedeutung des gespeicherten Modells für den Prozessablauf (Ablaufsemantik). Das Speicherformat soll neben dem Ablauf auch die Struktur der im Prozess benötigten Geschäftsobjekte enthalten. Die benötigten Werkzeuge sind um das Speicherformat mit der zugehörigen Ablaufsemantik positioniert. Bisher existiert kein Standard für die Speicherung und die Ausführungssemantik von Prozessmodellen. Für BPMN gibt es ein XML-basiertes Speicherformat, allerdings nur teilweise eine formale Semantik (Kossak et al. 2014). Diese deckt jedoch nicht den Nachrichtenaustausch zwischen Pools ab. Dies führt dazu, dass die Werkzeughersteller diese Lücken mit proprietären Formaten abdecken, um eine integrierte Werkzeug-Suite zu ermöglichen. Dies wiederum birgt den Nachteil, dass bei Geschäftsprozessprojekten Werkzeuge von verschiedenen Hersteller nur bedingt interoperabel sind und zusammen eingesetzt werden können. Abb. 8.30 zeigt das

330

8 Werkzeuge

Abb. 8.29 Zusammenwirken von Werkzeugen zur Modellierung und Implementierung

Abb. 8.30 Zusammenwirken von Camunda-Werkzeugen zur Modellierung und Implementierung

8.8 Werkzeuge für das Management des Digitalisierungsprozesses

331

Zusammenwirken von Werkzeugen bei der Camunda-Plattform, wobei der Modeler die Grenze zu dem proprietären Bereich der Werkzeug-Suite bildet. Bei S-BPM wird der Versuch unternommen, sowohl eine Speicherstruktur als auch eine Ausführungssemantik zu definieren (siehe Abschn. 4.2.2.5). Dadurch wird die Voraussetzung geschaffen, um für ein Geschäftsprozessmanagementprojekt eine herstellerunabhängige Werkzeugauswahl treffen zu können.

8.8

Werkzeuge für das Management des Digitalisierungsprozesses

Die jeweiligen Aktivitäten innerhalb der Aktivitätenbündel werden also in einer geeigneten Reihenfolge ausgeführt, wobei die verwendeten bzw. in den vorherigen Abschnitten beschriebenen Werkzeuge dies unterstützen sollen. Dafür müssen natürlich zuerst die individuellen Werkzeuge ihren jeweiligen Zweck gut erfüllen. Viel wesentlicher sind aber die Wechsel zwischen den Aktivitätenbündeln. Die Beschreibung einer Reihenfolge, in der einzelne Aktivitätsbündel ausgeführt werden sollten, kann als Vorgehensmodell oder Process Management Life Cycle bezeichnet werden. Für solche Vorgehensmodelle gibt es unterschiedliche Ansätze. Beim sogenannten Wasserfallmodell werden die Aktivitätenbündel in der Reihenfolge Analyse-Modellierung, Validierung, Optimierung, Implementierung, und BetriebMonitoring ausgeführt. In der Realität wird sich diese starre Reihenfolge selten einhalten lassen. Es ist fast immer der Fall, dass man z. B. das Prozessmodell anpassen möchte und deshalb wieder zur Analyse wechselt, z. B. wenn während der Implementierung festgestellt wird, dass eine Änderung des Prozessmodells notwendig ist, weil eine einzelne Prozessaktion von zwei unterschiedlichen Organisationseinheiten ausgeführt werden soll und deshalb in zwei Aktionen aufgeteilt werden muss. Der Wechsel zwischen den Werkzeugen für die einzelnen Aktivitätenbündel setzt voraus, dass die Speichermodelle innerhalb der Aktivitätenbündel zueinander passen (siehe Abschn. 8.7). Sollte dies nicht der Fall sein, kann es dazu kommen, dass nachträgliche Änderungen nicht vollzogen werden können, weil alle Arbeiten dazwischen erneut angegangen werden müssen. Dies liegt daran, dass das veränderte Prozessmodell technisch nicht als eine Änderung des ursprünglichen Modells gilt, sondern als ein vollständig neues, für das sämtliche ergänzenden Beschreibungen hinsichtlich Zugriffen von und auf andere IT-Systeme, Graphical User Inerfaces (GUIs) oder Nutzer-Mappings neu erstellt werden müssten. Bei komplexen Prozessen kommt erschwerend hinzu, dass an deren Entwicklung mehrere Personengruppen beteiligt sind, wobei jede Gruppe einen gewissen Teil des Gesamtprozesses bearbeitet. Sollen diese halbwegs flexibel und unabhängig von einander agieren, um ggf. schneller zu Ergebnissen zu kommen und nicht immer auf andere Gruppen warten zu müssen, dann sollte es erlaubt und möglich sein, dass die Bearbeitung des jeweiligen Prozessteils, zu einem bestimmten Zeitpunkt, in unterschiedlichen Aktivitätenbündel erfolgt.

332

8 Werkzeuge

Wie einfach ein Wechseln zwischen Aktivitätenbündeln ist, hängt auch von der Modellierungsmethode ab. Bei flussdiagrammorientierten Methoden sind die auszuführenden Prozessaktionen durch den Kontrollfluss stark miteinander verknüpft, so dass Änderungen am Modell oder seiner Implementierung eng abgestimmt sein müssen und Wechsel zwischen Aktivitätenbündeln schwierig werden. Die Camunda-Werkzeuge sind auf die Orchestrierung ausgelegt, so dass eine Prozessentwicklung sehr zentral gesteuert werden muss. Es können zwar mehrere Parteien zentral an einem BPMN-Modell arbeiten, aber das Deployment eines Prozesses muss zentral erfolgen. Bei kommunikationsorientierten Modellen sind zumindest einige Modelle über ihre Kommunikationbeziehungen lose gekoppelt. So können in BPMN Pools und in S-BPM Subjekte sehr unabhängig voneinander bearbeitet werden. Es muss nur das Kommunikationsprotokoll zwischen den Pools bzw. Subjekten abgestimmt sein. Diese mehr technischen Aspekte für den Wechsel zwischen Aktivitätenbündeln werden innerhalb der jeweiligen Werkzeug-Suiten unterstützt. Die Camunda-Suite ermöglicht es, mehrere Versionen eines Prozesses ausführen zu lassen, d. h. es existieren parallele Prozessinstanzen, die auf unterschiedlichen Versionen eines Prozessmodells basieren. Dabei ist es möglich Prozessinstanzen einer Version in Prozessinstanzen der anderen Modell- bzw. Prozessversion zu überführen. Um dies umzusetzen wird eine entsprechende Abbildungsfunktion definiert (siehe Abb. 8.31). Durch diese Migrationsmöglichkeit kann ein Prozess kontinuierlich verändert werden und auch existierende Prozessinstanzen in neuere Prozessversionen überführt werden. Ausgehend von den im Internet gefundenen Informationen ist dies die einzige Funktionalität zur direkten Unterstützung einer iterativen Prozessentwicklung.

Abb. 8.31 Migration von Prozessinstanzen in Camunda von einer (Prozessmodell-)Version zu einer anderen

8.8 Werkzeuge für das Management des Digitalisierungsprozesses

333

Abb. 8.32 Unabhängige Entwicklung von Teilprozessen: Prozess Bestellung

Die in der Metasonic Suite unterstützten Prozessnetzwerke erlauben die nahezu voneinander unabhängige Entwicklung von Teilprozessen. Lediglich das Kommunikationsprotokoll zwischen den jeweiligen externen Subjekten muss abgestimmt werden (siehe Abschn. 4.1). Abb. 8.32 zeigt den Prozess „Bestellung“ mit dem externen Subjekt „Lieferant“. Dieses Subjekt ist Teil des Prozesses „Lieferung“ (siehe Abb. 8.33) und wird hier benutzt um den Prozess mit dem betrachteten Prozess „Bestellung“ zu verknüpfen. Umgekehrt ist das Subjekt „Lager“ aus dem Prozess Bestellung ein externes Subjekt im Prozess „Lieferung“. Alle Prozessmodelle sind zwar verknüpft, können aber einzeln angepasst und verändert werden. Analoge Mdoellierungsmöglichkeiten sind auch in dem auf MS Visio basierenden Modellierungswerkzeug enthalten. Anders sieht es bei Prüf- und Freigabe-Workflows aus und ebenso bei Aufforderungen zu Kenntnisnahmen, automatischer Revisionierung und Archivierung von Ergebnissen innerhalb der jeweiligen Aktivitätenbündel. Keine der untersuchten Werkzeug-Suiten unterstützt diese Aktivitäten direkt um verschiedene Entwicklungsprozesse zur Prozessentwicklung einfach zu etablieren. Dadurch wird der Auf- und Ausbau eines Managementsystems für Prozessoptimierungen erschwert.

334

8 Werkzeuge

Abb. 8.33 Unabhängige Entwicklung von Teilprozessen: Prozess Lieferung

Literatur Elstermann M, Ovtcharova J (2018) Sisi in the alps: A simple simulation and verification approach for pass. In: Stary C (Hrsg) Proceedings of the 10th International Conference on Subject-Oriented Business Process Management, S-BPM One ’18. Association for Computing Machinery, New York, NY, USA Elstermann M, Piller O (2022) A comparative study of simulation tools for business processes. In: Elstermann M, Betz S, Lederer M (Hrsg) Subject-Oriented Business Process Management: Dynamic Digital Design of Everything – Designing or being designed? Communications in Computer and Information Science. Springer, Cham Kossak F et al (2014) A Rigorous Semantics for BPMN 2.0 Process Diagrams. Springer, Cham

9

Beispiele aus der Praxis

Die vorangegangenen Kapitel stellen grundlegende Konzepte, Ideen und Methoden vor, die für eine erfolgreiche Digitalisierung von Prozessen notwendig sind. Sie beruhen nicht nur auf ausgearbeiteter Theorie sondern auch auf vielfältigen und langjährigen praktischen Erfahrungen und Good Practices. In diesem Kapitel werden drei Fallbeispiele vorgestellt, in denen die Konzepte, Methoden und Sprachen der vorherigen Kapitel in der betrieblichen Praxis angewendet wurden, um wesentliche Unternehmensprozesse in den jeweiligen Umständen bzw. Fragestellungen zu gestalten und zu verbessern. Für jedes Beispiel wird dabei auch untersucht, inwiefern propagierte Vorteile der Methoden dieses Buches, wie die einfache, verteilte oder inkrementelle Modellierung sowie die IT-Integration zutreffen.1 Ein wichtiger Punkt, der durch diese Fallbeispiele deutlich werden sollte und daher vorangestellt wird, ist, dass die einzelnen Aspekte der vorangegangenen Kapitel nicht streng getrennt voneinander geschehen und ausgeführt werden. Sie fließen in der Praxis ineinander über und müssen dies auch tun. Die ersten beiden Fallbeispiele zeigen Projekte, welche bei der ENGEL Austria GmbH umgesetzt wurden. Das erste Projekt ist ein klassisches Verbesserungsprojekt zur Reduzierung von Durchlaufzeiten in der Produktion. Das zweite Projekt behandelt die Einführung eines fahrerlosen Transportsystemsim Bereich der Intralogistik. ENGEL ist ein traditioneller Hersteller von Spritzgießmaschinen aus Österreich und wurde 1945 von Ludwig Engel gegründet. Nach Einführung der ersten Spritzgießmaschine

1 Die Berichte und Analysen basieren dabei u.a auf vorherigen Arbeiten der Autoren wie Moser

et al. (2022), Fleischmann et al. (2016), Moser und Ríha (2019), Moser und Kannengiesser (2019) und Kannengiesser und Müller (2018). © Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_9

335

336

9 Beispiele aus der Praxis

im Jahr 1952 hat sich ENGEL bis zum Jahr 2022 zu einem Unternehmen mit einem Gesamtumsatz von 1,5 Milliarden Euro entwickelt. Das vollständig eigentümergeführte Unternehmen beschäftigt weltweit ca. 7000 Mitarbeiter in neun Produktionswerken und über 85 Niederlassungen. ENGEL ist ein stark kundenorientiertes Unternehmen mit Fokus auf Flexibilität und Innovationen (ENGEL Austria 2022). Das dritte Fallbeispiel zeigt die Konzeption und Einführung eines Manufacturing Execution System (MES) bei der Firma PENEDER. Die Peneder Gruppe ist ebenfalls ein familiengeführter Betrieb mit Standorten u. a. in Atzbach und Fraham (Oberösterreich) sowie Vertriebsniederlassungen in mehreren europäischen Ländern. Von einer 1922 gegründeten Hufschmiede aus hat sich Peneder zu einer Firma mit 400 Mitarbeitenden entwickelt. Heute setzt sich die international tätige Unternehmensgruppe aus drei Bereichen zusammen: Brandschutztüren und -tore, Bau und Architektur für Industrie- und Gewerbebau sowie Facility Management und Facility Services (FIX). Im Geschäftsjahr 2021/2022 erwirtschaftete die Peneder Gruppe eine Betriebsleistung von 111 Mio. Euro (Peneder Bau-Elemente GmbH 2022).

9.1

Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion von Durchlaufzeiten

9.1.1

Ausgangssituation

Der Fokus von ENGEL auf die Kundenbedürfnisse und die fortschreitende Entwicklung hin zu kürzeren Lieferzeiten führten zur Definition eines unternehmensweiten Ziels: Reduzierung der gesamten Prozessdurchlaufzeit um 30 % für alle Varianten einer der Standardkomponenten. Ein Projektteam wurde geschaffen, um die bestehenden Produktionsprozesse zu erheben, zu analysieren und die erforderlichen Verbesserungen zu implementieren. Zum Zeitpunkt des Projektstarts gab es kaum explizite Informationen zum Gesamtprozess, den einzelnen Prozessschritten oder den beteiligten Prozessakteuren. Zu Beginn war nur bekannt, dass sich der Prozess über zwei Produktionsstandorte in zwei verschiedenen Ländern (im folgenden Fabrik A und Fabrik B genannt) erstreckt und aus drei relevanten Produktgruppen besteht: • Produkt 1: Bei Produkt 1 handelt es sich um den fertigen Rahmen, die Ausgangskomponente jeder Spritzgussmaschine. Rahmen werden in Fabrik A zusammengebaut und bestehen unter anderem aus Produkt 2. Die Gesamtdurchlaufzeit für Produkt 1 umfasst die Auftragsabwicklung, Produktion und Lieferung von Komponenten (Produkt 2) und Teilkomponenten (Produkt 3). • Produkt 2: Der sogenannte „rohe“ Rahmen mit Öltank. Diese Hauptkomponente ist noch mechanisch unbearbeitet und wird in Fabrik B aus Produkt 3 zusammengebaut. Es gibt mehrere Dutzend Varianten von Produkt 2, abhängig von den Anforderungen der Kunden.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

337

• Produkt 3: Eine Art Bausatz aus Sägezuschnitten, welche in Fabrik A für die jeweilige Variante aus Stangenmaterial abgesägt wird. Abb. 9.1 zeigt ein grobes Schema der Lieferkette. Der Startpunkt ist der Kundenauftrag für eine Spritzgießmaschine. Das fertige Produkt 1 wird an die Montagelinie in Fabrik A geliefert, die firmenintern als Kunde betrachtet wird. Dieser Prozess wird durch Bestellungen gesteuert, die zwischen den Fabriken ausgetauscht werden. Wenn eine Bestellung in einer Fabrik eintrifft, wird diese erfasst, und ein Fertigungsauftrag mit einem entsprechenden Lieferdatum erstellt. Erst nach der Erfassung ist die Bestellung als ein Auftrag produktiv wirksam. Wenn dieser Erfassungsprozess länger als 2 Arbeitstage dauert, trifft der Produktionsauftrag nicht rechtzeitig in der Produktion der jeweiligen Fabrik ein, da die Bestellvorlaufzeit auf zwei Arbeitstage festgelegt ist. In der Ausgangssituation wurden ca. 95 % aller Bestellungen zwischen den Fabriken zu spät erfasst, d. h. zwischen der Ankunft des Auftrages im System und der tatsächlichen Erfassung vergingen mehr als zwei Arbeitstage. Diese Aufträge mussten dann manuell mit enormem Mehraufwand bearbeitet werden, was für Produkt 2 zu einer internen Liefertreue von nur 39 % führte. Daraus resultierten Probleme bei der Produktionsplanung in Fabrik A und Verzögerungen bei der Produktion von Produkt 1.

9.1.2

Vorgehen

Um das vorgegebene Ziel der Durchlaufzeitenreduktion um 30 % zu erreichen, wurde ein Zeitrahmen von nur 10 Wochen vorgegeben. Die zwei Fabriken lagen dabei in zwei verschiedenen Ländern mit unterschiedlichen Sprachen und entsprechenden kulturellen und räumlichen Distanzen. Der enge Zeitrahmen führte zu weiteren Einschränkungen für das Projekt: Neue Softwarelösungen oder Technologien konnten nicht eingeführt werden, da eine solche Einführung weitreichende Veränderungen benötigt und entsprechende strategische Entscheidungen sowie viel Personaleinsatz, Geld, Risikomanagement und Zeit bedurft hätte. Dies bedeutete, dass Änderungen an den bestehenden Prozessen innerhalb der existierenden Organisationsstrukturen und IT-Umgebung implementiert werden mussten. Erst nach

Product 3

Factory A

Product 2

Factory B

Product 1

Factory A

breaking point

Abb. 9.1 Grobes Schema der Lieferkette zwischen den Werken A und B

Customer

338

9 Beispiele aus der Praxis

Erreichen des ursprünglichen Projektziels hätten weitere, für zusätzliche Verbesserungen notwendige Maßnahmen umgesetzt werden können. Bis auf eine oberflächliche Beschreibung des Materialflusses zwischen den Fabriken standen keine expliziten Prozessinformationen zur Verfügung. Daher war der erste Schritt dieses Optimierungsprojekts die Abbildung des Ist-Status, um detailliertere Kenntnisse über die Material- und Informationsflüsse sowie über alle Faktoren zu erhalten, die die Produktionsprozesse hätten beeinflussen können. Zuerst wurde versucht, diese Dokumentation und Analyse des bereits etablierten Produktionsprozesses mittels Wertstromanalyse (WSA)-Methodik nach Rother und Shook (2004) bzw. Erlach (2010) – einem Standardwerkzeug zur Dokumentation und Analyse von Produktionsprozessen innerhalb der Firma – zu erstellen. Für eine erste Abbildung des Prozesses war es notwendig, ein geeignetes, repräsentatives Produkt auszuwählen, das die grundlegenden Produktionsschritte umfasst und den größten Teil des Materialflusses abdeckt. Letztendlich wurde beschlossen eine Variante von Produkt 2 für eine erste Ist-Analyse zu verwenden. Diese Auswahl basierte auf einer ABC-Analyse aller Produktvarianten und der entsprechenden Arbeitspläne. Die ausgewählte Variante für Produkt 2 machte dabei 30 % der Gesamtproduktion aus, und hatte die komplexesten Arbeitspläne und die höchste Gesamtdurchlaufzeit der drei definierten Produktgruppen. Durch die Verfolgung des Materialflusses auf Werksebene durch beide Fabriken, die Erhebung relevanter KPIs (Lagerbestand, Produktionsdurchlaufzeiten, Kundentakt, etc.) und der persönlichen Befragung der verantwortlichen Mitarbeiter konnten wir ein Wertstrommodell (WSM)für Produkt 2 erstellen. Abb. 9.2 zeigt das WSM des Produktionsprozesses und seine hierarchische Struktur. Die Ergebnisse der Wertstromanalyse waren wie folgt: • Der Produktionsprozess des Produkts 2 besteht aus zwei Hauptschritten: Herstellung des Basisrahmens und Herstellung des Öltanks. Sobald der Öltank fertiggestellt ist, wird er an den Rahmen montiert um Produkt 2 herzustellen. • Der Öltank und der Rahmen werden getrennt gefertigt. Das bedeutet, dass es keine Abstimmung zwischen den beiden Produktionslinien gibt sobald der Auftrag gestartet wurde. • Aufgrund fehlender Produktionsplanung stapeln sich unfertige Bestände mit langen Wartezeiten. Nur ca. 10 % der gesamten Durchlaufzeit sind Produktionszeit. • Durch Optimierungen in der Produktionsplanung und den Arbeitsplänen kann die Durchlaufzeit verringert werden. Jedoch reichen die identifizierten Verbesserungen nicht aus, um das vorgegebene Ziel zu erreichen. • Wir haben ein großes Potenzial in der Auftragsverarbeitung des Informationsflusses identifiziert.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

339

Abb. 9.2 Wertstromanalyse der Fertigung von Produkt 2

Darüber hinaus wurden konkretere Informationen zum Bestellprozess zwischen den Fabriken gewonnen und die Prozessbeschreibung entsprechend erweitert: • Die Nachfrage nach Produkt 1 stammt von Fabrik A, von wo aus eine Bestellung für die erforderliche Variante von Produkt 2 an Fabrik B gesendet wird. • Die Bestellung für Produkt 2 wird bearbeitet und die Beschaffung der erforderlichen Komponenten, darunter Produkt 3, beginnt. • Fabrik B bestellt jetzt Produkt 3 von Fabrik A. • Die Bestellung für Produkt 3 wird in Fabrik A erfasst, die Teile zugeschnitten und an Fabrik B verschickt. • Sobald Produkt 3 in Fabrik B ankommt, beginnt die Produktion von Produkt 2 und das fertige Produkt 2 wird dann zu Fabrik A geliefert. • Sobald Produkt 2 in Fabrik A ankommt, beginnt die Fertigung von Produkt 1. • Dieser Prozess ist für jede Maschine gleich, unabhängig von der Variante von Produkt 1. Durch die relativ einfache Wertstromanalyse konnten bereits zwei Potenziale identifiziert werden: die fehlende Produktionssynchronisierung und die nicht optimierte Auftragsabwicklung. Die Produktionssynchronisation ist jedoch direkt mit dem jeweiligen Produktionsplanungsprozess verknüpft. Bei einer kurzen Analyse des Planungsprozesses kamen wir zu dem Schluss, dass langfristige Verbesserungen nur möglich sind, wenn die Abläufe im Prozess „Planung“ komplett reorganisiert und umstrukturiert werden und die Denkweise an sich verändert wird. Obwohl dies eine notwendige Änderung gewesen wäre, konnte dies im Zeitrahmen des Projekts nicht umgesetzt werden. Stattdessen wurde auf den

340

9 Beispiele aus der Praxis

Bestellprozess und sein Optimierungspotenzial fokussiert, da dies als möglicher „Quick Win“ für das Projekt betrachtet wurde. Unseren Erfahrungen aus früheren Anwendungen entsprechend, konzentriert sich die WSA auf Produktionsprozesse und ist vor allem dazu geeignet, einen relativ linearen Materialfluss zwischen einzelnen, physischen Herstellungsschritten zu beschreiben. Das von uns erstellte Wertstrommodell zeigt auf, dass viele Probleme in den Interaktionen und dem Austausch von Informationen liegen, jedoch keine (für unsere Anwendung) zufriedenstellende Grundlage zum Festhalten und Beschreiben derselben liefert. In den im Zuge der Werstromanalyse erstellten Beschreibungsmodellen fehlten dadurch relevante Prozessinformationen, um den Gesamtprozess und den entsprechenden Informationsfluss detailliert abzubilden und richtig zu verstehen. Dazu gehörten z. B. folgende Umstände: • keine Informationen über die Interaktionen zwischen den beteiligten Parteien • keine Informationen darüber, welche Schritte im Prozess automatisiert sind, und welche Schritte manuell durchgeführt werden • keine konkreten Informationen zu den im SAP-ERP2 -System verwendeten Transaktionen • keine Information über die Zeitlinien des Informationsflusses • keine Überprüfung der bereitgestellten Informationen Dies war der Ausgangspunkt dafür, einen neuen Ansatz für eine umfassende Prozesserhebung zu wählen: eine zusätzliche Methode, um den Informationsfluss in einem Detailgrad zu beschreiben, der es erlaubt, eine genaue Analyse durchzuführen und vor allem auch die oben genannten Punkte sauber abzubilden, zu verstehen und zu diskutieren. Dafür wurde auf die Methode des subjektorientierten Geschäftsprozessmanagements (S-BPM) als zusätzliches Modellierungswerkzeug zurückgegriffen (vgl. Fleischmann et al. (2012))(siehe Abschn. 3.6). Diese Wahl fiel aufgrund vorangegangener Erfahrungen und vor allem wegen Problemen, die in ähnlichen Kontexten mit anderen Modellierungssprachen (unter anderem Flussdiagrammen/Swimlane-Diagramme, eEPKs, BPMN, usw.) vorgekommen waren, wenn diese gelegentlich neben der WSA im Unternehmen verwendet wurden. Dabei hatten entsprechende Prozessmodelle entweder einen Überblick über den Prozess geliefert, waren aber nicht detailliert genug für eine gründliche Prozessanalyse, oder die Prozessmodelle waren so detailliert, dass es sehr schwierig wurde, den Überblick zu behalten bzw. das Modell zu lesen und zu verstehen. Zu den genannten Erfahrungen in vergangenen Projekten gehörten u. a., dass die an den Prozessen beteiligten Personen, ihre individuellen Ansätze, ihr Wissen und ihre Erfahrungen eine entscheidende Triebfeder und für erfolgreiche Prozesse unerlässlich sind – eine Erkenntnis, zu der auch andere Experten gekommen sind, z. B. Liappas (2006)

2 Enterprise Resource Planning (ERP) – Im Standardfall das zentrale IT-System zur geschäftlichen

Planung in jedem Unternehmen.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

341

oder Riempp (2012). Eine weitere Erfahrung, deren Indikatoren auch in den weiter oben angeführten Analysen des ursprünglichen WSM-Vorgehens gemacht wurde, ist, dass die Art und Weise, in welcher der Informationsfluss zwischen den Prozessakteuren organisiert ist, einen wesentlichen Einfluss auf die Geschäftsprozessleistung hat (vgl. z. B. auch Kock et al. (2009)). Dies sind wichtige Umstände, für deren Betrachtung die Methoden der Subjektorientierung bzw. die in den vorangegangenen Kapiteln dieses Buches vorgestellten Ansätze quasi prädestiniert und sehr gut geeignet sind. Der nächste Schritt bestand darin, detailliertere persönliche Interviews mit den entsprechenden Prozessbeteiligten durchzuführen und auf dieser Basis ein Subjektinteraktionsdiagramm (SID) der Ist-Situation der Logistik- und Produktionsprozesse zu erstellen, das – wie erwartet – sehr komplex war. Ungefähr 40 involvierte Subjekte verteilten sich auf die Produktion, Produktionssteuerung und Logistik aller drei Produkte in beiden Fabriken. Eine Skizze der endgültigen Version des resultierenden Ist-SID ist in Abb. 9.3 zu sehen. Das SID zeigt die allgemeine Kommunikationsstruktur des Prozesses, also welche Subjekte (Rechtecke) miteinander welche Nachrichten (auf den Pfeilen) austauschen. Abfrage: PL-AUF ohne APL (ZCCHKSA) Ergebnis: PL-AUF ohne APLs (ZCCHKSA) FE-AUF LJIT freigegeben

SAP System

Abfrage: PL-AUF ohne APL (ZCCHKSA) Abfrage: PL-AUF mit APL (COOIS) Abfrage: PL-AUF LJIT (COOIS) FE-AUF LJIT eröffnet FE-AUF eröffnet FE-AUF freigegeben (nicht LJIT)

BS-AVI Rahmen ROH

BS-EIN Rahmen ROH Buchung Wareneingang Rahmen ROH

?

AV & Fertigungssteuerung EMCZ

NR. 1: automatize order opening and release NR.2: document and rework exceptions

Info-Mail: APL erstellt

SAP System EMS PO: EMS

AR-RES Rahmen SPR

Ergebnis: PL-AUF ohne APLs (ZCCHKSA) Ergebnis: PL-AUF mit APLs (COOIS) Ergebnis PL-AUF LJIT (COOIS)

SAP System EMCZ PO: EMCZ

Fertigungssteuerung EMCZ PO: SJ

Arbeitsvorbereitung EMCZ PO: PD

Laufkarten FE-AUF (LASER)

K-AUFT Liste FE-AUF (LASER)

Bestellung Teile (nicht SCM)

Bedarfe

Fertigungssteuerung EMS BANF Rahmen PO: KS

Freigabe/Druck C-Blech

Materialdisposition EMS PO: LB

NR.9: automatized creation of BANF

Lauti arten FE-AUF

FE-AUF freigegeben

Autirag- und Lieferplanung (ALP) EMCZ PO: KM

Bestellung NR.10: automatized order creation EMS NR.11: automatized order acceptance and KAUFT creation

Laufkarten FE-AUF (LASER) Fertigungssteuerung EMCZ PO: IP K-AUFT nicht LJIT

SAP System

PL-AUF Sägeteil

Programmierung EMCZ PO: Name

Programm-Liste

FE-AUF freigegeben (nicht LJIT) Abfrage: Bedarfe (MD06)

Fertigung EMCZ

FE-AUF Sägeteil eröffnet

EK EMCZ

Laufkarten FE-AUF Rahmen

Laufkarten FE-AUF Öl-Tank

SK-BED Sägeteil BS-EIN Sägeteil Maerialbereitstellung EMS PO: AM

Fertigungssteuerung BANF Rohmaterial Sägeteil? EMS PO: SG

GPL PO: GA

INFO Sägeteil „eilt sehr“

NR.3: Storage Strategy of purchased components NR.4: Purchasing and storage strategy flame cut parts

Meister Fertigung Öl-Tank EMCZ PO: S

Meister Fertigung Rahmen EMCZ PO: V

NR.12: process simplification => detailed process survey necessary

Meister LASERFertigung PO: Meister

BS-AVI Sägeteil

K-AUFT Sägeteil

FE-AUF Sägeteil „eilt sehr“ freigegeben

Materialdisposition EMCZ PO: Name

Materialdisposition EMS SYSTEM

BS-EIN Sägeteil Ausdruck

BANF

NR.5: automatized order acceptance and K-AUFT creation NR.6: automatize order release

Autiragsbeginn/Programmstart FE-AUF Sägeteil freigegeben

Fertigungssteuerung EMS PO: NJ

Materialscheine FF

Einkauf EMCZ PO: Name

Vorarbeiter Produktionsbereiche Fertigung PO: Vorarbeiter

V Vorarbeiter Pro ProdProdProdProd Produktionsbereiche Fertigung P P P P PO PO: Vorarbeiter

LASER

WA Buchung Rahmen ROH

Sägeteile

Laufkarten FE-AUF Sägeteil

BS-EIN für Material

BS-AVI für Material

Aktualisierung TOPS Sägerei EMS PO: WH

Lieferant EMCZ

Freigabe/Druck Laufkarte Rahmen

Kommissioniertes Material (Palette) Materialscheine EF

Buchung WE Rahmen ROH Buchung WA Rahmen ROH

NR.7: direct printing of Lagerzugangsschein

Lagerzugangsschein

Zukautieile

Sägeteile Rahmen Lieferdokumente Sägeteile

Sägeteile Rahmen

Buchung WA Sägeteil Rahmen

PNL Versand PO: SM

WE EMS TOR 16 PO: WH

Lieferdokumente Sägeteile

Kommissionierung EMCZ

Buchung WE Sägeteile Rahmen

LKW

Sägeteile Rahmen Lieferdokumente Sägeteile

Kommissionierung EMCZ PO:

WE / Lager EMCZ PO: ZS

Rahmen ROH Lieferdokumente Rahmen ROH

Kommissioniertes Material (Palette)

Kommi-Liste

Kommi-Liste

Fertigung Rahmen EMS Laufkarte C-Blech Picking Confirmation

Liste disponierte Rahmen

BDE

Rahmen disponieren

Rahmen ROH Laufkarte Rahmen C-Blech ROH Laufkarte C-Blech

Lagerverwalter (LJIT)

Lagerverwalter (Zukautieile)

Kommissioniertes Material (Palette)

Lagerverwalter Lagerverwalter (Kommissionierlager (Kardex /Schütigut) )

Lieferdokumente Rahmen ROH

Rahmen ROH Lieferdokumente Rahmen ROH Fertigungssteuerung EMS PO: KS WA EMCZ

Liste FE-AUF Rahmen

Rüsten 259302 PO: F

Vorrichtung Liste FE-AUF Rahmen

Rahmen ROH

Produktion Rahmen ROH EMCZ

Gelaserte Teile

COBURG (257401 & 257402) PO: F /S Qualitätskontrolle Qualitätskontrolle anfordern

Aktualisierung TOPS

Rahmen Lauti arte Rahmen C-Blech ROH Qualitätskontrolle

Buchung Rahmen

WE NORD PO: S

Laufkarte Rahmen

TOPS

Ausfertigen PO: PA NR.8: improved communication with QC; QC integrated in WA?

Rahmen

Montage EMS

Abb. 9.3 Skizze der Kommunikationsstruktur (Subjektinteraktiondsdiagramm) der Produktion und des Bestellprozesses

342

9 Beispiele aus der Praxis

Um zwischen den beiden Fabriken zu unterscheiden, wurden die entsprechenden Subjekte farbig in grün für Fabrik A und orange für Fabrik B gekennzeichnet. Außerdem wurden Subjekte, welche Funktionalitäten von SAP-Systeme darstellen, mittels Schraffur (grau) gekennzeichnet, um die bereits digitalen Teile des bestehenden Prozesses hervorzuheben. Obwohl in beiden Werken das selbe ERP-System verwendet wird, wurde es für die strukturiertere Visualisierung entsprechend den drei Anwendungsbereichen aufgeteilt: SAP-System A, SAP-System B und SAP-System A Disposition. Aufgrund der hohen Anzahl der involvierten Subjekte und der Komplexität des gesamten Prozesses wäre es nicht praktikabel gewesen, alle Subjektverhalten (SBDs) ohne einen definierten Rahmen für unsere nächsten Schritte zu erheben und zu modellieren, bzw. war es für die zu klärende Fragestellung auch nicht notwendig.3 Um einen solchen Rahmen zu definieren, wurde das nun vorhandene SID verwendet, um die Hauptknoten und Engpässe im Prozess für das entsprechende Produkt zu identifizieren und zu analysieren (Abb. 9.4). Einzelne Subjektverhalten wurden nur nach Notwendigkeit innerhalb des definierten Rahmens detailliert modelliert. Der auffälligste Teil des Prozesses war die Auftragsabwicklung selbst. Die Abarbeitung der Bestellung von Produkt 1 durch Fabrik A, die Auftragsabwicklung und die Beschaffung von Produkt 2 durch Fabrik B und die Produktion von Produkt 3 in Fabrik A beschäftigte bis zu 12 Subjekte (3 SAP-Systeme und 9 Personen/Rollen) und nahm bis zu 15 Arbeitstage in Anspruch. Außerdem wurden nur 65 % des Produkts 2 pünktlich fertiggestellt weil die Auftragsabwicklung zu lange dauerte und die Aufträge im Produktionszentrum zu spät eingingen (ca. 95 % aller Aufträge). Dies hatte direkte Auswirkungen auf die Produktion von Produkt 1 und auf die Prozessstabilität. Die Lieferzeiten konnten nur mit viel Aufwand in der Produktion eingehalten werden. Es wurde entschieden, sich im weiteren Verlauf auf diesen Materialbeschaffungsprozess (ein Sub-Set der modellierten Subjekte) zu konzentrieren, da dieser Prozess selbst relativ zur Komplexität der bereitgestellten Komponenten (Produkt 3) sehr umständlich und zeitaufwendig war. Der Rahmen für diese Prozesserhebung ist wie folgt definiert: Der Fokus liegt auf den Logistikabteilungen von Fabrik A und Fabrik B. Dazu gehört auch die Produktion von Produkt 3 in der Fabrik A, da diese organisatorisch direkt in die Logistik integriert ist und somit Teil des Prozesses und der Produktion von Produkt 2 in Fabrik B ist. Die Materialbeschaffung in Fabrik A und die tatsächliche Montage von Produkt 1 in Fabrik A sind nicht mehr Teil der Erhebung (siehe Abb. 9.4 für eine Visualisierung des Prozesses und der entsprechenden Produkte).

3 Ausgearbeitete, detaillierte SBDs können helfen, den Inhalt des SIDs zu verifizieren bzw.

konsistenter zu machen. Der Aufwand dafür sollte jedoch gut überdacht sein und entsprechende (Zeit) Ressourcen sollten vorhanden sein.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

343

Abb. 9.4 Zusammenhang der Kommunikationsstruktur mit den jeweiligen Produkten

Es wurden die relevanten Prozessschritte untersucht, indem involvierte Mitarbeiter in Einzelinterviews direkt befragt wurden oder die Mitarbeiter während ihres eigenen Prozesses begleitetet und gleichzeitig, für die Interviewpartner sichtbar, die Subjektverhaltensdiagramme modelliert wurden. So konnte relativ schnell und effizient der Prozessverlauf für Produkt 3 (siehe Pfeile in Abb. 9.5) detailliert beschrieben, umfangreiche Informationen über das SAP-ERP-System und die verwendeten Transaktionen dokumentiert und den Interviewpartnern ermöglicht werden, die Prozessmodellierung direkt zu begleiten und das Modell zu verifizieren. Nachdem die SAP-Transaktionen im SID und den SBDs der Mitarbeiter klar beschrieben wurden und einem Dummy-Auftrag durch das System gefolgt wurde, wurden auch die verschiedenen Schritte des SAP-Systems modelliert. Dies erlaubte es uns, zwischen automatisierten (digitalen) und manuellen Schritten zu unterscheiden, das Prozessmodell zu verifizieren und die tatsächlichen Prozessdurchlaufzeiten zu dokumentieren. Abb. 9.6 visualisiert das Prozessverhalten eines Mitarbeiters, der die Bearbeitung von Fertigungsaufträgen in Fabrik B abwickelt. Dieser Mitarbeiter prüft, ob Produktionspläne

344

9 Beispiele aus der Praxis Abfrage: PL-AUF ohne APL (ZCCHKSA) Ergebnis: PL-AUF ohne APLs (ZCCHKSA) FE-AUF LJIT freigegeben

SAP System

Abfrage: PL-AUF ohne APL (ZCCHKSA) Abfrage: PL-AUF mit APL (COOIS) Abfrage: PL-AUF LJIT (COOIS) FE-AUF LJIT eröffnet FE-AUF eröffnet FE-AUF freigegeben (nicht LJIT)

BS-AVI Rahmen ROH

BS-EIN Rahmen ROH Buchung Wareneingang Rahmen ROH

?

AV & Fertigungssteuerung EMCZ

NR. 1: automatize order opening and release NR.2: document and rework exceptions

Info-Mail: APL erstellt

SAP System EMS PO: EMS

AR-RES Rahmen SPR

Ergebnis: PL-AUF ohne APLs (ZCCHKSA) Ergebnis: PL-AUF mit APLs (COOIS) Ergebnis PL-AUF LJIT (COOIS)

SAP System EMCZ PO: EMCZ

Fertigungssteuerung EMCZ PO: SJ

Arbeitsvorbereitung EMCZ PO: PD

Laufkarten FE-AUF (LASER)

K-AUFT Liste FE-AUF (LASER)

Bestellung Teile (nicht SCM)

Bedarfe

Fertigungssteuerung EMS BANF Rahmen PO: KS

Freigabe/Druck Lauti arte C-Blech

Materialdisposition EMS PO: LB

NR.9: automatized creation of BANF

Laufkarten FE-AUF

FE-AUF freigegeben

Autirag- und Lieferplanung (ALP) EMCZ PO: KM

Bestellung NR.10: automatized order creation EMS NR.11: automatized order acceptance and KAUFT creation

Laufkarten FE-AUF (LASER) Fertigungssteuerung EMCZ PO: IP K-AUFT nicht LJIT

SAP System

PL-AUF Sägeteil

Programmierung EMCZ PO: Name

Programm-Liste

FE-AUF freigegeben (nicht LJIT) Abfrage: Bedarfe (MD06)

Fertigung EMCZ

FE-AUF Sägeteil eröffnet

EK EMCZ

Laufkarten FE-AUF Rahmen Laufkarten FE-AUF Öl-Tank

SK-BED Sägeteil BS-EIN Sägeteil Maerialbereitstellung EMS PO: AM

Fertigungssteuerung BANF Rohmaterial Sägeteil? EMS PO: SG

GPL PO: GA

INFO Sägeteil „eilt sehr“

NR.3: Storage Strategy of purchased components NR.4: Purchasing and storage strategy flame cut parts

Meister Fertigung Rahmen EMCZ PO: V

Meister Fertigung Öl-Tank EMCZ PO: S

NR.12: process simplification => detailed process survey necessary

Meister LASERFertigung PO: Meister

BS-AVI Sägeteil

K-AUFT Sägeteil

FE-AUF Sägeteil „eilt sehr“ freigegeben

Materialdisposition EMCZ PO: Name

Materialdisposition EMS SYSTEM

BS-EIN Sägeteil Ausdruck

BANF

NR.5: automatized order acceptance and K-AUFT creation NR.6: automatize order release

Autiragsbeginn/Programmstart FE-AUF Sägeteil freigegeben

Fertigungssteuerung EMS PO: NJ

Materialscheine FF

Einkauf EMCZ PO: Name

Vorarbeiter Produktionsbereiche Fertigung PO: Vorarbeiter

Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Produktionsbereiche Produktionsbereiche Produktionsbereiche Produktionsbereiche Produktionsbereiche Produktionsbereiche Fertigung Fertigung Fertigung Fertigung Fertigung Fertigung PO:PO: Vorarbeiter Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter

LASER

WA Buchung Rahmen ROH

Sägeteile

Lauti arte FE-AUF Sägeteil

BS-EIN für Material

BS-AVI für Material

Aktualisierung TOPS Sägerei EMS PO: WH

Lieferant EMCZ

Freigabe/Druck Lauti arte Rahmen

Kommissioniertes Material (Paletie) Materialscheine EF

Buchung WE Rahmen ROH Buchung WA Rahmen ROH

NR.7: direct printing of Lagerzugangsschein

Lagerzugangsschein

Zukautieile

Sägeteile Rahmen Lieferdokumente Sägeteile

Sägeteile Rahmen

Buchung WA Sägeteil Rahmen

PNL Versand PO: SM

WE EMS TOR 16 PO: WH

Lieferdokumente Sägeteile

Kommissionierung EMCZ

Buchung WE Sägeteile Rahmen

LKW

Sägeteile Rahmen Lieferdokumente Sägeteile

Kommissionierung EMCZ PO:

WE / Lager EMCZ PO: ZS

Rahmen ROH Lieferdokumente Rahmen ROH

Kommissioniertes Material (Paletie)

Kommi-Liste

Kommi-Liste

Fertigung Rahmen EMS Lauti arte C-Blech Picking Confirmation

Liste disponierte Rahmen

BDE

Rahmen disponieren

Rahmen ROH Laufkarte Rahmen C-Blech ROH Laufkarte C-Blech

Lagerverwalter (LJIT)

Lagerverwalter (Zukautieile)

Kommissioniertes Material (Paletie)

Lagerverwalter (Kommissionierlager)

Lagerverwalter (Kardex /Schütigut)

Lieferdokumente Rahmen ROH

Rahmen ROH Lieferdokumente Rahmen ROH Fertigungssteuerung EMS PO: KS WA EMCZ

Liste FE-AUF Rahmen

Rüsten 259302 PO: F

Vorrichtung Liste FE-AUF Rahmen

Rahmen ROH

Produktion Rahmen ROH EMCZ

Gelaserte Teile

COBURG (257401 & 257402) PO: F /S Qualitätskontrolle Qualitätskontrolle anfordern

Aktualisierung TOPS

Rahmen Laufkarte Rahmen C-Blech ROH Qualitätskontrolle

Buchung Rahmen

WE NORD PO: S

Laufkarte Rahmen

TOPS

Ausfertigen PO: PA NR.8: improved communication with QC; QC integrated in WA?

Rahmen

Montage EMS

Abb. 9.5 Kommunikationsstruktur (SID) des Prozesses für die Produktion von Produkt 3

für geplante Fertigungsaufträge vorliegen. Anschließend werden alle geplanten Produktionsaufträge mit verfügbaren Produktionsplänen nach einem definierten Regelwerk zusammengefasst und zur Produktion freigegeben. Die Mitarbeiter erledigen dies manuell für jeden Produktionsauftrag, bei mehreren tausend Bestellungen pro Tag. Produkt 3 allein verursacht dadurch insgesamt eine Arbeitsbelastung von ca. sieben Stunden pro Tag. Der Gesamtaufwand für die Erhebung, alle Interviews und die Zeit, die für die Vervollständigung und Überprüfung der Prozessmodelle benötigt wurde, betrug ca. 200 geleistete Arbeitsstunden. Dies ist angesichts der Komplexität der Prozessmodelle und der untersuchten Detailtiefe ein relativ geringer Aufwand im Vergleich zu anderen Prozessoptimierungsprojekten. Mit dem nun vorhandenen detaillierten Wissen über die involvierten Subjekte und die im SAP-System dokumentierten Daten (Bestellzeiten, Lieferzeiten, etc.) wurde ein Zeitplan für den Prozess erstellt. Dieser Zeitplan enthält alle Organisations- und Produktionsschritte und deren jeweilige Durchlaufzeiten. Zum Beispiel betrug die Durchlaufzeit für eine der Produkt 1-Varianten, von der Bestellannahme in Fabrik B bis zur Lieferung des fertigen Produkts 1 an die Montagelinie in Fabrik A, ungefähr 30 Arbeitstage (Abb. 9.7).

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

INFO-Mail von AV A

PL-AUF: LJIT oder L100 umsetzen

LJITT not LJIT

345

LJIT (Sägeteile, Standard Rahmen)

VON: N: Arbeitsvorbereitung EMCZ Info-Mail: APL erstellt Abfrage PL-AUF ohne APL (ZCCHKSA)

Abfrage PL-AUF LJIT (COOIS): Eckstart TTa gesdatum +3 Wochen Tagesdatum

AN: SAP System EMCZ Abfrage: PL-AUF ohne APL (ZCCHKSA)

AN: SAP System EMCZ Abfrage: PL-AUF LJIT (COOIS)

Liste PL-AUF ohne APLs

Liste PL-AUF LJIT

VON: SAP System EMCZ Ergebnis: PL-AUF ohne APLs (ZCCHKSA)

VON: SAP System EMCZ Ergebnis: PL-AUF LJIT (COOIS)

Abfrage PL-AUF mit APL (COOIS): Eckstart T gesdatum +2d Ta Tagesdatum

PL-AUF zu FE-AUF eröffnen (Manuell)

AN: SAP System EMCZ Abfrage: PL-AUF mit APL (COOIS)

Aufträge eröffnet

Liste Liste PL-AUF mit APLL

FFE-AUF E-AUF LJIT eröffnet (automatisch in SAP)

VON: SAP System EMCZ Ergebnis: PL-AUF mit APL

PL-A PL AUF PL-AUF Zusammenfassen (Sonderregelungen beachten) und zu FE-AUF eröffnen (Manuell)

NR.2: document and rework exceptions

Aufträge umgese umgesetzt tzt

FFE-AUF E-AUF LJIT eröffnet (automatisch in SAP)

AN: SAP System EMCZ FE-AUF eröffnet

AN: SAP System EMCZ FE-AUF LJIT eröffnet

Umgesetzte FE-AUF Freigeben (manuell) Freigeben

AN: Fertigungssteuerung EMCZ FE-AUF freigegeben

END

Abb. 9.6 Beispiel für eine Verhaltensbeschreibung (SBD) eines Mitarbeiters

346

9 Beispiele aus der Praxis

Abb. 9.7 Zeitverbrauch im Ausgangsprozess

9.1.3

Erzielte Ergebnisse

Infolge der Analyse wurden in Zusammenarbeit mit den Mitarbeitern die bestehenden Arbeitspläne überarbeitet, aktualisiert und verbessert. Dies führte zu verkürzten Durchlaufzeiten für gleichbleibende Arbeitsschritte sowie zu einer reduzierten Anzahl von Arbeitsschritten durch Zusammenführung. In diesem Fall bedeutet eine reduzierte Anzahl von Arbeitsschritten sowohl weniger Subjekte als auch weniger Verhaltenszustände in den Subjektverhalten. Während der Analyse wurden auch mehrere ähnliche Prozessschritte identifiziert, die in Fabrik A und Fabrik B unterschiedlich durchgeführt werden. In einer Fabrik wurden z. B. bestimmte notwendige Prozessschritte manuell ausgeführt, die in der anderen Fabrik jedoch automatisch vom SAP-System ausgeführt werden konnten. Darüber hinaus wurden vorhandene automatisierte SAP-Batch-Jobs unterbrochen, wenn erforderliche manuelle Eingaben fehlten. Diese Batch-Jobs wurden zu zwei definierten Zeiten während des Arbeitstages eingeplant. Wenn zu diesem Zeitpunkt die manuelle Eingabe fehlte, musste die gesamte Bestellung bis zu einem ganzen Arbeitstag warten. Dies konnte bei jeder Bestellung mehrmals für verschiedene Jobs geschehen, was letztendlich zu einer Verzögerung von mehreren Arbeitstagen führen konnte. Die beschriebenen Subjekte lieferten präzise definierte Prozesse (SBDs), die alle relevanten Prozessschritte im SAP-System spezifizieren, insb. alle erforderlichen SAPTransaktionen, wer diese Transaktionen ausführt, und die Interaktion zwischen System und Mitarbeitern. Auf Grundlage dieser detaillierten Prozessdokumentation wurden notwendige Änderungen am System für einen optimierten Soll-Prozess identifiziert und beschrieben. Die für die Umsetzung des Soll-Prozesses notwendigen Anpassungen im ERP-System konnte die IT-Abteilung direkt implementieren, um neue standardisierte, digitalisierte und automatisierte Prozesse zu erstellen, Prozessschritte zu überarbeiten und den Verarbeitungsplan von bestehenden Batch-Jobs für beide Fabriken zu rationalisieren. Dies enthielt Schritte wie Auftragsannahme, Auftragserfassung, Auftragseröffnung, Auftragsfreigabe in beiden Werken und Lieferung der Fertigungspapiere an die Produktion. Die automatische Bestellabwicklung ermöglichte die auftragsbezogene und zeitnahe Bearbeitung von Produkt 3 in der Fabrik A, was wiederum die Einführung von KANBAN-Beständen mit definierten kritischen Teilen, die Reduzierung des Lagerbestands unkritischer Teile und den Versand von extern gekauften Teilen direkt in die Fertigung ermöglichte.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

347

Ein weiteres der erreichten Ergebnisse war eine neue Lagerstrategie und eine Neubewertung des Lagerbestandes, was ermöglichte, den gesamten Lagerbestand zu überarbeiten und ein KANBAN-System für kritische Teile von Produkt 3 zu implementieren. Der neu geschaffene KANBAN-Bestand und der höhere Wert der betroffenen Teile führten zu einer Gesamtsteigerung des Bestandes um ca. 209 %, was auf den ersten Blick eine enorme Zahl ist aber nur einem absoluten Anstieg von etwa 10.000 e des bestehenden Lagerwertes entsprach. Diese neue Strategie erhöhte die Verfügbarkeit und reduzierte die Lieferzeiten für alle zugekauften Teile. Die Unterbrechungen bei der Herstellung von Produkt 2 aufgrund fehlender Teile konnten ursprünglich bis zu 15 Arbeitstage dauern. Nach den implementierten Änderungen waren alle benötigten Komponenten innerhalb eines Arbeitstages entweder direkt vor Ort oder über den Sicherheitsbestand beim Lieferanten verfügbar. Dies bedeutete eine enorme Verbesserung der Prozessstabilität und Reduzierung des Umlaufbestandes gegenüber einem vergleichsweise geringen Anstieg des Lagerbestands. Die vorgenommene Umstrukturierung und Digitalisierung zuvor manueller Prozessschritte führte zu einem standardisierten Prozess und einer Reduktion der beteiligten Subjekte von zwölf auf acht (siehe Abb. 9.8). Weniger Subjekte bedeuten weniger Schnittstellen im Prozess, was wiederum die Prozesskomplexität reduziert und die Prozessstabilität und -transparenz erhöht. Darüber hinaus wurden die Mitarbeiter von zeitraubenden und sich wiederholenden Aufgaben befreit. Der erhöhte Digitalisierungsgrad und der neu geplante Ablauf führten zu einer neuen Prozessdurchlaufzeit von 2 Tagen für die Auftragsabwicklung von ursprünglich 5–10 Tagen. Aufgrund des detaillierten und klar definierten Prozesses konnte die IT-Abteilung die Prozessänderungen in der bestehenden Systemumgebung innerhalb von nur 3 Arbeitstagen umsetzen. Der Produktions- und Versandprozess für Produkt 3 konnte auf 3 Tage reduziert werden, von ursprünglich 5–6 Tagen. Dies bedeutet, dass wir die Gesamtdurchlaufzeit von 11–15 Arbeitstagen von Produkt 3 um 87% auf 2 Arbeitstage reduzieren konnten. Diese Änderungen führten zu einer erhöhten Liefertermintreue für Produkt 3: Die Liefertreue stieg bereits vier Wochen nach der Umsetzung auf 89 % und nach einem Jahr auf 97 %. Der relativ lange Zeitaufwand für die Auftragsabwicklung für Produkt 3 in der Anfangsphase führte dazu, dass die meisten Aufträge in der Fabrik A zu spät oder sehr kurzfristig ankamen. Die neu geschaffenen automatisierten SAP-Prozesse führten zu einer schnelleren Bearbeitung von Bestellungen der Fabrik A innerhalb der Abteilungen von Fabrik B. Dies hatte eine kürzere Bestellzeit für Produkt 3 und einem früheren Produktionsstart anderer Komponenten, die für Produkt 2 erforderlich waren, zur Folge. Das Ergebnis war eine Reduzierung von anfänglich 95 % der Bestellungen, die zu spät registriert wurden, auf nur 12 %, wodurch wiederum die Prozessstabilität und Prozessqualität stark erhöht wurden und der Bedarf für Fehlersuche in beiden Fabriken reduziert wurde. Die Gesamtdurchlaufzeit des Produktions- und Bestellprozesses von Produkt 2 konnte um 7 Arbeitstage (ca. 38 %) verkürzt werden, von 19–23 Tagen auf 12– 14 Tage. Die Umwandlung von manueller Arbeit in automatisierte, digitalisierte Prozesse

348

9 Beispiele aus der Praxis Abfrage: PL-AUF ohne APL (ZCCHKSA) Ergebnis: PL-AUF ohne APLs (ZCCHKSA) FE-AUF LJIT freigegeben

SAP System

AV & Fertigungssteuerung EMCZ

BS-AVI Rahmen ROH NR.12: Include „Technik“ in Process Survey

NR. 1: automatize order opening and release NR.2: document and rework exceptions BS-EIN Rahmen ROH Buchung Wareneingang Rahmen ROH

?

SAP System EMCZ PO: EMCZ

SAP System EMS PO: EMS

AR-RES Rahmen SPR

Arbeitsvorbereitung EMCZ PO: PD

FE-AUF freigegeben (nicht LJIT)

Laufkarten FE-AUF (LASER)

Programmierung EMCZ PO: Name

Programm-Liste K-AUFT Liste FE-AUF (LASER)

Bestellung Teile (nicht SCM)

Laufkarten FE-AUF

FE-AUF freigegeben

BANF Rahmen

Materialdisposition EMS PO: LB

Freigabe/Druck Laufkarte C-Blech

Auftrag- und Lieferplanung (ALP) EMCZ PO: KM

Bestellung

Laufkarten FE-AUF (LASER) Fertigungssteuerung EMCZ PO: IP

NR.10: automatized order creation EMS NR.11: automatized order acceptance and KAUFT creation

NR.9: automatized creation of BANF

K-AUFT nicht LJIT

SAP System

Fertigung EMCZ

EK EMCZ

Laufkarten FE-AUF Rahmen

Laufkarten FE-AUF Öl-Tank

SK-BED Sägeteil BS-EIN Sägeteil Materialdisposition EMCZ PO: Name

Materialdisposition EMS SYSTEM

NR.3: Storage Strategy of purchased components NR.4: Purchasing and storage strategy flame cut parts

Meister Fertigung Rahmen EMCZ PO: V

Meister Fertigung Öl-Tank EMCZ PO: S

NR.12: process simplification => detailed process survey necessary

Meister LASERFertigung PO: Meister

BS-AVI Sägeteil

NR.5: automatized order acceptance and K-AUFT creation NR.6: automatize order release (PL-AUF)

BANF Autiragsbeginn/Programmstart FE-AUF Sägeteil freigegeben

Fertigungssteuerung EMS PO: NJ

Materialscheine FF

Einkauf EMCZ PO: Name

Vorarbeiter Produktionsbereiche Fertigung PO: Vorarbeiter

Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Vorarbeiter Produk Produk Produk onsbereiche onsbereiche Produk onsbereiche Produk onsbereiche Produktionsbereiche onsbereiche Fer Fer gung Fer gungFer gunggung Fer gung Fertigung PO:PO: Vorarbeiter Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter PO: Vorarbeiter

LASER

WA Buchung Rahmen ROH

Sägeteile

Laufkarte FE-AUF Sägeteil

BS-EIN für Material

BS-AVI für Material

Aktualisierung TOPS Sägerei EMS PO: WH

Lieferant EMCZ

Freigabe/Druck Laufkarte Rahmen

Kommissioniertes Material (Palette) Materialscheine EF

Buchung WE Rahmen ROH Buchung WA Rahmen ROH

Zukaufteile

NR.7: direct printing of Lieferdocuments

Sägeteile Rahmen Lagerzugangsschein

Sägeteile Rahmen Lieferdokumente Sägeteile WE EMS TOR 16 PO: WH

Buchung WA Sägeteil Rahmen

Kommissionierung EMCZ

Buchung WE Sägeteile Rahmen

LKW

Sägeteile Rahmen Lieferdokumente Sägeteile

Kommissionierung EMCZ PO:

WE / Lager EMCZ PO: ZS

Rahmen ROH Lieferdokumente Rahmen ROH

Kommissioniertes Material (Palette)

Kommi-Liste

Kommi-Liste

Fertigung Rahmen EMS Laufkarte C-Blech Picking Confirmation

Liste disponierte Rahmen

BDE

Rahmen disponieren

Rahmen ROH Laufkarte Rahmen C-Blech ROH Laufkarte C-Blech

Lagerverwalter (LJIT)

Lagerverwalter (Zukaufteile)

Kommissioniertes Material (Palette)

Lagerverwalter (Kommissionierlager)

Lagerverwalter (Kardex /Schüttgut)

Lieferdokumente Rahmen ROH

Rahmen ROH Lieferdokumente Rahmen ROH Fertigungssteuerung EMS PO: KS WA EMCZ

Liste FE-AUF Rahmen

Rüsten 259302 PO: F

Vorrichtung Liste FE-AUF Rahmen

Rahmen ROH

Produktion Rahmen ROH EMCZ

Gelaserte Teile

COBURG (257401 & 257402) PO: F /S Qualitätskontrolle Qualitätskontrolle anfordern

Aktualisierung TOPS

Rahmen Laufkarte Rahmen C-Blech ROH Qualitätskontrolle

Buchung Rahmen

WE NORD PO: S

Laufkarte Rahmen

TOPS

Ausfertigen PO: PA NR.8: improved communication with QC; QC integrated in WA?

Rahmen

Montage EMS

Abb. 9.8 Kommunikationsstruktur des aktualisierten Prozesses für Produkt 3

im SAP-System führte zu einer reduzierten Arbeitsbelastung der beteiligten Mitarbeiter von 5–6 Stunden auf bis zu eine Stunde pro Tag. Die Mitarbeiter mussten nun die Bestellungen nur für sehr spezifische Komponenten bzw. Sonderfälle, die nicht vom SAP-System abgedeckt werden konnten, manuell bearbeiten. Die Auswirkungen dieser Änderungen addieren sich zu einer kalkulierten Prozesskostenreduktion von rd. 65.000 e pro Jahr. Die implementierten Verbesserungen und entsprechende Änderungen auf der Prozessebene reduzierten die Durchlaufzeiten für Produkt 2 und 3 und führten zu einer verkürzten Gesamtdurchlaufzeit für Produkt 1: von 26 bis 33 Arbeitstagen auf 18 bis 20 Arbeitstage. Dies ist eine Gesamtreduktion von ungefähr 60 % für den gesamten Bestellund Produktionsprozess (vergleiche Abb. 9.9 und 9.10). Es konnte nicht nur das gesteckte Ziel einer 30 %igen Durchlaufzeitverkürzung erreicht werden. Durch Digitalisierung und Automatisierung der Prozessschritte und des entsprechenden Informationsflusses konnte diese Reduzierung sogar mehr als verdoppelt werden. Dies führte darüber hinaus zu einer Verminderung des Umlaufbestandes mit einem Gesamtwert von mehreren hunderttausend Euro über den gesamten Prozess.

9.1 Fallbeispiel 1: Optimierung von Logistikprozessen zur Reduktion . . .

349

Abb. 9.9 Zeitbedarf im ursprünglichen Prozess

Abb. 9.10 Zeitbedarf im überarbeiteten Prozess

Diese Ergebnisse zeigen, dass es möglich ist, durch die Optimierung und Digitalisierung des Informationsflusses die Durchlaufzeit und die manuelle Arbeitsbelastung deutlich zu reduzieren. Der erhöhte Digitalisierungsgrad und die damit verbundene Prozesstransparenz kann dazu beitragen, weitere Verbesserungen zu erreichen und die Prozesse in zukünftigen Analysen besser zu verstehen (vgl. Parviainen et al. 2017).

9.1.4

Fazit der Methodenanwendung

Einfachheit der Modellierung: Die geringe Anzahl an verschiedenen Symbolen der PASS-Notation ermöglichte es den Prozessbeteiligten, die Prozessmodelle bereits nach einer kurzen, zehnminütigen Erklärung zu lesen und zu verstehen. Der Fokus dieser kurzen Einführung lag im Verstehen und Modellieren von Subjektverhalten, so dass die Prozessbeteilitgen ihren jeweiligen Prozess direkt aus ihrer Sicht (d. h. nur ihr eigenes Subjekt) beschreiben konnten. Das Ziel war es, es jedem zu ermöglichen, sein SBD strukturiert um drei Kernfragen herum aufzubauen: „Was benötige ich von jemand anderem?“ (Empfangen), „Was benötigt jemand anderes von mir?“ (Senden), und „Was muss ich tun?“(Funktionszustand). Die Einzelinterviews, kombiniert mit parallelem Modellieren, ermöglichte es den Prozessbeteiligten, einen direkten Bezug zwischen ihrem Prozesswissen und dem grafischen Modell herzustellen. Das reduzierte außerdem den Aufwand zur Nachbereitung der Dokumentation, da die Verhaltensdiagramme ein direktes Resultat aus den Interviews waren. Es wurde keine Textbeschreibung als Zwischenschritt benötigt. Während den

350

9 Beispiele aus der Praxis

Interviews begannen die Beteiligten sogar selbst das Modell (verbal) zu verifizieren und zu korrigieren. Dies kann als Bestätigung gesehen werden, dass die zu Beginn gegebene kurze Erklärung ausreichend war um die Notation zu verstehen und direkt selbst anzuwenden. Verteilte Modellierung: In jedem Interview wurde nur das einzelne Subjektverhalten modelliert, für das der Interviewte im Prozess verantwortlich war. Dies war ein großer Vorteil für den Projektverlauf, da individuelle Interviews einfacher zu vereinbaren sind als kollaborative Workshops mit allen Prozessbeteiligten aus verschiedenen Ländern gleichzeitig. Die Einzelinterviews resultierten auch in einem effizienteren Modellierungsprozess, da unnötige Wartezeiten für diejenigen vermieden wurde, welche nicht am gerade diskutierten Teil des Prozesses beteiligt waren. Diese Faktoren führten zu einer erhöhten Motivation und Akzeptanz der Beteiligten gegenüber der Prozesserhebung und dem Modellierungsprozess. Andererseits ergab sich ein Nachteil aus diesem Ansatz. Die chronologische Abfolge des Gesamtprozesses über alle Subjekte und Nachrichten hinweg war ohne tiefgreifendes und detailliertes Prozesswissen nur mehr sehr schwer nachvollziehbar. Zwar kann dieser Effekt etwas abgeschwächt werden, indem die Subjekte in chronologischer Reihe angeordnet oder entsprechend benannt werden, jedoch ist das nur für SIDs mit einer geringen Anzahl an Subjekten und Prozesschleifen wirklich möglich. Um die chronologische Reihenfolge nachvollziehbarer zu beschreiben, wurde das S-BPM-Modell noch einmal in einem (stark vereinfachten) Swimlane-Diagramm dargestellt. Ebenfalls reduziert eine große Anzahl an Subjekten und Nachrichten die Lesbarkeit des Prozessmodelles, ein Problem mit dem ab einer bestimmten Prozesskomplexität naturgemäß jede Modellierungsmethode konfrontiert ist. Die Pfeile, welche die Nachrichten darstellen, sind nur mehr schwer zu verfolgen was ihre Richtung (also Sender/EmpfängerSubjekt) und deren Inhalt angeht. Um dieses Problem etwas zu mildern wurde in früheren Anwendungsprojekten mit PASS eine einheitliche Form der Benennung von Subjekten und Nachrichten eingeführt: Subjekte erhielten einen Namen und eine einzigartige Nummer. Nachrichten wurden mit einem Namen bezeichnet und erhielten ein Prefix welches Sender und Empfänger beschreibt (z. B. „02_03 Nachrichtenname“ für Nachrichten von „02_Subjekt“ zu „03_Subjekt“). Kontinuierliche Veränderungen: Während des Projektverlaufs wurden die Prozessmodelle laufend erweitert, nachgearbeitet und korrigiert. Ältere Versionen des Modells wurden nicht verworfen sondern lediglich angepasst und als neue Version abgelegt, entsprechend des Ansatzes einer schrittweisen Veränderung. Anpassungen, um den SollProzess zu beschreiben, wurden durch Hinzufügen und Entfernen von individuellen Subjekten, Subjektverhalten oder Nachrichten visualisiert. Der Aufwand, um diese Anpassungen umzusetzen, war dadurch relativ gering. Das Modell selbst war also nicht nur eine reine Dokumentation eines (Zwischen-)Ergebnisses, sondern ein integrales Werkzeug der Arbeit. IT-Integration: Das Prozessmodell beschrieb konkrete Prozessse, inklusive der einzelnen Prozessschritte im ERP-System (SAP), also alle notwendigen SAP-Transaktionen,

9.2 Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems

351

und die Interaktionen zwischen dem System und den Mitarbeitern. Die sehr detaillierte grafische Beschreibung ermöglichte es der IT direkt die notwendigen neuen Prozesse zu implementieren, bestehende Prozesse anzupassen sowie die Prozessabläufe zu optimieren. Die umgesetzten Anpassungen in der bestehenden Systemumgebung konnten innerhalb einer einzelnen Arbeitswoche von einem IT-Spezialisten umgesetzt werden (ca. 38 Arbeitstunden). Die skeptische Frage der Geschäftsführung, ab wann die genannten Anpassungen denn umgesetzt sein werden, konnte das Projektteam mit „es läuft seit 2 Wochen“ beantworten. Die Änderungen umfassten Prozessschritte wie Auftragsbestätigung, Auftragsfreigabe in allen Werken, und Verteilen der Produktionsaufträge im ERP. Wie schon erwähnt, ermöglichte es die umgesetzte Automatisierung, die Produkte zeitgerecht zu fertigen.

9.2

Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems

Das zweite Projekt bei ENGEL Austria betraf die Digitalisierung von Prozessen in der Intralogistik, die für die Einführung eines fahrerlosen Transportsystems (FTS) notwendig waren. Während des gesamten Projektes wurde eine inkrementelle Strategie für die Umsetzung verfolgt. Die Anwendung von Methoden des S-BPM als generelles Werkzeug für die Analyse der Prozesse und Schnittstellen, Planung der individuellen Entwicklungsstufen des neuen Prozesses, und die Kommunikation zwischen den Beteiligten hat diese Strategie unterstützt.

9.2.1

Ausgangssituation

Strategisch verfolgt ENGEL eine hohe Produktionstiefe und ist prinzipiell in der Lage, jedes Fertigungsteil selbst zu herzustellen. Die Produktion wird in der Fertigungssteuerung durch ein Manufacturing Execution System (MES) koordiniert. Der interne Transport beliefert die Arbeitsplätze mit den notwendigen Rohmaterialien und Halbfabrikaten im 4-Schicht-Betrieb. Im Herbst 2018 startete das Unternehmen ein Pilotprojekt zur Einführung eines fahrerlosen Transportsystems mit dem Ziel, den internen Transport zu unterstützen und die Arbeit für die Staplerfahrer zu erleichtern. Die Umsetzung eines solchen FTS in einem Produktionswerk stellte ein hohes Risiko für ENGEL dar, da es mit hohen Investitionskosten verbunden und die Materialversorgung durch die Intralogisitk ein zentraler, produktionskritischer Prozess ist. Um das Risiko des Pilotprojektes zu reduzieren wurde entschieden, dass das FTS über mehrere kleine Schritte implementiert werden soll, welche einfacher zu validieren sind. Zur Definition der zukünftigen Soll-Prozesse und der notwendigen Umsetzungsschritte war es notwendig, die bestehenden (Ist-)Prozesse zu erheben und zu beschreiben. Zu Beginn des Projektes war jedoch keine explizite Prozessdokumentation über die betroffenen Transportprozesse und deren Ansteuerung vorhanden.

352

9.2.2

9 Beispiele aus der Praxis

Vorgehen

Um eine einheitliche Kommunikationsbasis innerhalb des Projektteams zu schaffen, musste der Prozess in einer Form beschrieben werden, die für alle Projektteammitglieder verständlich war. Das Projektteam bestand aus Mitarbeitern aus der Logistikplanung, Maschinenbedienern, Staplerfahrern, IT-Mitarbeitern sowie den externen Lieferanten für das MES und das FTS. Aufgrund der unterschiedlichen Arbeitsumfelder, Fachsprachen, Ausbildungen und Erfahrungen war es eine große Herausforderung, ein gemeinsames Prozessverständnis zu schaffen. Basierend auf positiven Erfahrungen aus früheren Projekten wurde wieder S-BPM/ PASS als Modellierungsansatz gewählt . Für die Erhebung kam entsprechend der gleiche Ansatz der Einzelinterviews und Modellierungsmethode wie in Fallbeispiel 1 zum Einsatz. Wenn sich während des Interviews herausstellte, dass zusätzliche Subjekte im Prozess notwendig waren, wurden diese dem SID hinzugefügt und ein Interview mit dem jeweiligen Prozessbeteiligten vereinbart, um das zugehörige SBD zu modellieren. Bei diesem Vorgehen wurden folgende Feststellungen gemacht: 1. Die Logistikprozesse bei ENGEL sind sehr informationsintensiv und werden grundsätzlich durch Interaktionen zwischen Maschinenbedienern, Staplerfahrern und MES gesteuert. Über Subjektinteraktionsdiagramme konnten all diese Prozessbeteiligten (Subjekte) und deren Interaktionen beschrieben werden, unabhängig davon, ob es sich um Menschen, Maschinen oder Softwareanwendungen handelt. 2. Die Trennung von Subjektverhalten (SBD) und SID reduziert das Risiko, dass Prozessbeteiligte von einer Fülle an (irrelevanten) Details überschwemmt werden, und verhindert Kontrollflussprobleme. Ein SID liefert eine effektive Grundlage für die Kommunikation innerhalb des sehr diversen Projektteams. 3. Die SIDs erlauben die Darstellung einer modularen Prozessstruktur, in der Subjekte und Nachrichten einfach verändert, gelöscht oder erweitert werden können, ohne dass der gesamte Prozess für jede Iteration komplett neu modelliert werden muss.4 Dies unterstützte den Ansatz der schrittweisen Einführung des FTS, indem sich das IstProzess-Modell graduell zu einem Soll-Prozess-Modell weiterentwickelte. Die Schritte sind im Folgenden detailliert beschrieben. Schritt 0: Modellierung des Ist-Prozesses Die erste Umsetzungsstufe des Projektes (im Projekt als „Schritt 0“ bezeichnet) bestand darin, den Ist-Prozess der internen Materialversorgung zu erheben und zu dokumentieren.

4 Dies ist ein Indikator für die Hypothese, dass es sich beim Subjekt um das natürliche Modu-

larisierungskonzept für Prozessbeschreibungen handelt – im Gegensatz zu willkürlich gewählten Aufgabengrenzen oder Versuche, mit dem Konzept von Unterprozessen etwas mehr Flexibilität in die Prozessbeschreibung hinein zu bekommen.

9.2 Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems

353

x 07_01 Production Order Saw 01_Sawing Center

x 01_96 Transportation Order Cut Parts (by acclamation) x 01_96 Cut Parts (Euro Pallet)

x 01_07 Production Order Saw Started x 01_07 Production Order Saw Finished

x 01_81 Small Cut Parts (by hand) 81_Shelf for Small Cut Parts

x 07_96 List Of Pending Material Requests x 81_96 Small Cut Parts (by hand) x 96_07 Request List Of Pending Material Requests x 96_07 Material Delivered

x 07_06 Synchronising Production Orders 07_Manufacturin g Execution System (MES)

06_SAP ERP System x 06_07 Synchronising Production Orders

x 96_02 Cut Parts (Euro Pallet) x 96_02 Small Cut Parts (by hand) x 96_02 Semi-Finished Product

x 07_02 Production Order

02_Workplace Production x 02_07 Request Material x 02_07 Production Order Started x 02_07 Production Operation Started x 02_07 Production Operation Finished x 02_07 Production Order Finished

x 96_80 Cut Parts (Euro Pallet) 80_Palet Rack For Cut Parts

96_Forklift Driver

x 02_96 Semi-Finished Product

x 80_96 Cut Parts (Euro Pallet)

Abb. 9.11 SID des Ist-Prozesses (Schritt 0)

Die resultierende Prozessbeschreibung sollte als Grundlage für ein gemeinsames Prozessverständnis dienen. Der in Schritt 0 beschriebene Ist-Prozess ist in Abb. 9.11 skizziert (die konkreten Bezeichnungen der Subjekte sind für die Nachvollziehbarkeit des Projektes nicht relevant): Im Modell werden Produktionsaufträge zur Koordination zwischen dem SAP-ERP-System und dem MES ausgetauscht. Wird ein Produktionsauftrag ausgelöst, erhält der Mitarbeiter im Sägezentrum den Auftrag, das benötigte Material zuzuschneiden. Kleinteile werden in einem Regal in der Nähe des Säge-Arbeitsplatzes gelagert und später von einem Staplerfahrer mitgenommen. Großteile werden auf Euro-Paletten in einem Regal zwischengelagert und von den Staplerfahrern transportiert. Die Staplerfahrer werden von dem jeweiligen Mitarbeiter an der Säge darüber informiert, ob ein Transport anfällt. Nach dem Ausliefern des Materials bestätigt der Staplerfahrer manuell im MES, dass das Material am entsprechenden Arbeitsplatz verfügbar ist. Die Maschinenbediener erhalten ihre Produktionsaufträge via MES und können die Produktionsreihenfolge innerhalb des Arbeitsvorrates selbst organisieren (z. B. zur Optimierung der Rüstzeiten). Sie melden den Status des jeweiligen Produktionsauftrags im MES zurück und lösen Bestellungen für Rohmaterial (bzw. Zuschnitte) für neue Produktionsaufträge aus. Transportaufträge werden entweder durch den Maschinenbediener angestoßen oder der Staplerfahrer erhält eine Bedarfsliste mit allen benötigten Materialien auf einem mobilen Tablet vom MES. Der Staplerfahrer entscheidet anhand eines vorgegebenen Regelwerks manuell, welchen der Transportaufträge er zuerst abarbeitet (z. B. geplanter Liefertermin). Anhand des SID konnten mehrere Bereiche des Prozesses identifiziert werden, in denen eine Automatisierung und Digitalisierung eine Verbesserung bewirken kann. Einer dieser Bereiche betraf die verfügbare Transportkapazität (Staplerflotte und Staplerfahrer). Die Staplerfahrer waren hauptsächlich mit „einfachen“ Transportaufträgen ausgelastet, also dem Transport von standardisierten Euro-Paletten und Kleinteilen. Allerdings sind Staplerfahrer in diesem Fall am effektivsten eingesetzt, wenn komplexere Transportaufgaben übernommen werden, wie etwa übergroße Teile (Abmessungen von mehreren Metern) und schwerem Material (bis zu mehreren Tonnen). Jedes Mal, wenn ein Kleinteil (Einzelteile

354

9 Beispiele aus der Praxis

bis zu 15 kg Gewicht) mit einem Stapler transportiert werden muss, werden wertvolle Transportkapazitäten verschwendet. Eine weitere Verbesserungsmöglichkeit zeigte sich in der Abarbeitung der Transportaufträge. Durch die manuelle Priorisierung entstanden Fehler im Ablauf, welche Koordinationsaufwand und sogar Verzögerungen in der Produktion nach sich zogen. Die hohe Anzahl an Transportaufträgen, zum Beispiel, machte es den Staplerfahrern sehr schwer, sich an vorgegebene Regeln zur Priorisierung zu halten. Ein Grund dafür war, dass die genannte Liste der Transportaufträge, mit der die Staplerfahrer arbeiteten, keine wirkliche Transportliste war. Es handelte sich um eine abgeänderte Liste der Produktionsaufträge, in der ein Feld „Materialbedarf“ vom Maschinenbediener manuell befüllt wurde, wenn das Material bestellt wurde. Das Resultat war, dass die Staplerfahrer keine expliziten Informationen darüber bekamen, wenn Änderungen in den Produktionsaufträgen die Reihung der Transportaufträge beeinflusste bzw. eine Neupriorisierung notwendig gemacht hätte. Grundsätzlich war zwar der geplante Starttermin (Tag und Uhrzeit) sichtbar, doch bei mehreren hundert Aufträgen pro Tag war eine manuelle Prüfung, ob es eine Änderung gab, schlicht nicht möglich. Zusätzlich fand die Kommunikation der Staplerfahrer mit den Maschinenbedienern auf Zuruf statt (Telefon oder direktes Ansprechen). Das hieß z. B., dass Maschinenbediener häufiger die Lieferung des Materials direkt dirigierten, aus Angst dass es nicht rechtzeitig geliefert wird. Dies konnte aber dazu führen, dass zu viel Material an den Arbeitsplätzen bereitgestellt wurde, was einerseits den Arbeitsplatz selbst einschränkte und andererseits unnötig Transportkapazitäten für andere Aufträge band. Basierend auf der Analyse des Ist-Prozesses wurde die Entscheidung getroffen bzw. freigegeben, ein FTS einzuführen um standardisierte Transportaufträge soweit wie möglich zu automatisieren. Langfristig sollten mindestens 80% aller internen Transporte über das FTS mit mehreren fahrerlosen Transportfahrzeugen (FTF) abgewickelt werden. Es wurde ein Pilotprojekt aufgesetzt, um die Umsetzung zu realisieren und die Prozessveränderungen schrittweise zu überwachen. Nach der Implementierung eines jeden Projektschrittes sollten die Auswirkungen, der Aufwand und der Nutzen verifiziert werden, um zu entscheiden ob der nächste Schritt umgesetzt wird. Für dieses Vorgehen wurden drei grobe Schritte ausgearbeitet und im Nachhinein auch angegangen. Als Teil der Ausarbeitung der Schritte entwickelte das Projektteam auch ein entsprechendes Lastenheft mit den Anforderungen an das umzusetzende FTS. Dieses Lastenheft war die Grundlage für die Kommunikation mit den unterschiedlichen FTS-Anbietern und letztendlich für die Auswahl des Lieferanten innerhalb der einzelnen Schritte. Schritt 1: Fahrerloses Transportsystem für Kleinteile In Schritt 1 des Projekts wurde ein FTS für den Transport von Kleinteilen im Produktionswerk eingeführt. Abb. 9.12 zeigt das Prozessmodell mit den Änderungen im Prozessablauf im Vergleich zum Ist-Prozess (vgl. 9.11) aus Schritt 0. Die Änderungen sind in unterschiedlichen Farben hervorgehoben (Grün für „hinzugefügt“, Rot für „entfernt“). Die Kleinteile werden im neuen Ablauf mittels FTS, geeignet für bis zu 100 kg, transportiert. Die Transportaufträge werden in einer standardisierten grafischen Benutzeroberfläche im IT-System erzeugt und verwaltet. Diese browserbasierte Nutzeroberfläche

9.2 Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems

355

• 01_98 Small Cut Parts (by hand) • 01_98 Confirm Loading (Press Button)

01_Sawing Center • 07_01 Production Order Saw • 07_1 List Of Pending Material Requests (Small Parts)

• 01_96 Transportation Order Cut Parts (by acclamation) • 01_96 Cut Parts (Euro Pallet)

• 01_07 Production Order Saw Started • 01_07 Production Order Saw Finished • 01_07 Request List Of Pending Material Requests (Small Parts)

• 81_01 Small Cut Parts (by hand)

• 07_96 List Of Pending Material Requests

• 01_81 Small Cut Parts (by hand)

81_Shelf for Small Cut Parts

• 81_96 Small Cut Parts (by hand) • 96_07 Request List Of Pending Material Requests • 96_07 Material Delivered

• 07_06 Synchronising Production Orders 07_Manufacturin g Execution System (MES)

06_SAP ERP System

• 96_02 Cut Parts (Euro Pallet) • 96_02 Small Cut Parts (by hand) • 96_02 Semi-Finished Product

• 07_02 Production Order

02_Workplace Production • 02_07 Request Material • 02_07 Production Order Started • 02_07 Production Operation Started • 02_07 Production Operation Finished • 02_07 Production Order Finished

• 06_07 Synchronising Production Orders

• 96_80 Cut Parts (Euro Pallet) 96_Forklift Driver

• 02_96 Semi-Finished Product

80_Palet Rack For Cut Parts • 80_96 Cut Parts (Euro Pallet)

• 02_99 Transportation Request (Browser GUI)

• 99_02 Transportation Request Confirmed (Browser GUI) • 02_98 Confirm Unloading (Press Button) • 02_98 Confirm Loading (Press Button)

• 98_02 Small Cut Parts (by hand)

• 01_99 Transportation Request (Browser GUI)

• 99_01 Transportation Request Confirmed (Browser GUI)

99_AGV Transportation Management System

• 99_98 Transportation Order

S

98_AGV - Small Sheet Parts

• 98_99 Transportation Order Confirmed • 98_99 Loading Confirmed • 98_99 Unloading Confirmed

Abb. 9.12 Prozessmodell Schritt 1 (hinzugefügte Elemente in Grün; entfernte Elemente in Rot)

war eine fertige, getestete Lösung des FTS-Lieferanten und konnte ohne zusätzliche Installation genutzt werden. Dadurch konnte jeder Arbeitsplatz mit einem Computer direkt angebunden werden. Sobald ein Maschinenbediener Material benötigt, legt er einen Transportauftrag mittels der Nutzeroberfläche an, welcher dann automatisch über die FTSSteuerung verarbeitet wird. Rein technisch wäre es möglich gewesen, das Be- und Entladen des transportierten Materials im Zuge des 1. Schrittes zu implementieren. Es wurde aber entschieden, dass das FTS manuell durch die Maschinenbediener be- und entladen werden soll, da der notwendige Automatisierungsschritt weitere sehr kostenintensive Investitionen erfordert hätte. Nach dem Ladevorgang bestätigt der jeweilige Mitarbeiter das Laden durch einen Knopfdruck direkt am FTS, welches dann den nächsten Transportauftrag abarbeitet. Während der Umsetzungsphase und den ersten Betriebswochen konnten viele Erfahrungen in der praktischen Umsetzung von FTS in einem laufenden Produktionsbetrieb gesammelt werden; insbesondere im Bezug auf die Akzeptanz dieser neuen Technologie, der Auftragsverwaltung, der Routenplanung, uvm. Das Ergebnis der Bemühungen von Schritt 1 war, dass tatsächlich alle Transportaufträge für Kleinteile durch das FTS abgearbeitet werden. Es wurde daher entschieden, auch Schritt 2 anzugehen. Schritt 2: Fahrerloses Transportsystem für Großteile Im Schritt 2 sollte der Transport von Rohmaterial für Großteile zwischen ausgewählten Arbeitsplätzen implementiert werden. Wie in den vorherigen Schritten wurden die Änderungen über ein Prozessmodell entwickelt und dargestellt, und das Modell bildete auch wieder die Grundlage der Kommunikation zwischen dem Projektteam und anderen beteiligten Bereichen. Der wichtigste Teil war die Verifikation des geplanten Prozesses

356

9 Beispiele aus der Praxis

durch die betroffenen Mitarbeiter aus der Logistik und den Produktionsbereichen. Die Hauptfrage, die dabei beantwortet werden musste, war gleichermaßen simpel und komplex: „Profitierst Du und deine Arbeit von diesem neuen Prozess?“ Das war besonders in Schritt 2 von großer Priorität, da die notwendigen Prozessänderungen tief in den Transportprozess der Intralogistik eingriffen und weitreichende Konsequenzen hatten. Hier hat sich das grafische Prozessmodell als „gemeinsame Sprache“ als unabdingbar für die Kommunikation erwiesen. Im neuen Prozess werden alle Teile bis zu 1500 kg auf Euro-Paletten transportiert. Das Rohmaterial wird im Sägezentrum zugeschnitten und händisch an definierten Ladestationen auf die Paletten geladen. Der Sägebediener legt dann einen Transportauftrag an, in dem die eindeutige Produktionsauftragsnummer eingescannt wird und diese mit der Nummer der Ladestation verknüpft wird. Dadurch wird ein Transportauftrag ausgelöst, und das Großteile-FTS transportiert die Palette zu einem Palettenregal, welches direkt im FTS verwaltet wird. Jeder Maschinenbediener kann nun an seinem Arbeitsplatz über die Nutzeroberfläche digital den benötigten Produktionsauftrag aus dem Regal anfordern. Der Transport wird durch das FTS ausgeführt und automatisch als abgeschlossen zurückgemeldet, sobald die Palette am entsprechenden Arbeitsplatz abgestellt wurde. Das entsprechende Prozessmodell wird in Abb. 9.13 gezeigt. Die inkrementellen Änderungen, diesmal im Vergleich zum Prozessmodell von Schritt 1, sind wieder farbig hervorgehoben.

x 01_97 Cut Parts (Euro Pallet)

x 01_98 Small Cut Parts (by hand) x 01_98 Confirm Loading (Press Button)

01_Sawing Center x 07_01 Production Order Saw x 07_1 List Of Pending Material Requests (Small Parts)

x 01_96 Transportation Order Cut Parts (by acclamation) x 01_96 Cut Parts (Euro Pallet)

x 01_07 Request List Of Pending Material Requests (Small Parts) x 01_07 Production Order Saw Started x 01_07 Production Order Saw Finished

x 81_01 Small Cut Parts (by hand)

x 07_96 List Of Pending Material Requests

x 01_81 Small Cut Parts (by hand)

81_Shelf for Small Cut Parts

x 96_07 Request List Of Pending Material Requests x 96_07 Material Delivered

x 07_06 Synchronising Production Orders

x 07_02 Production Order 07_Manufacturin g Execution System (MES)

06_SAP ERP System x 06_07 Synchronising Production Orders

x 02_07 Request Material x 02_07 Production Operation Finished x 02_07 Production Order Started x 02_07 Production Operation Started x 02_07 Production Order Finished

x 96_80 Cut Parts (Euro Pallet)

x 96_02 Cut Parts (Euro Pallet) x 96_02 Semi-Finished Product 02_Workplace Production

x 02_96 Semi-Finished Product

96_Forklift Driver

80_Palet Rack For Cut Parts x 80_96 Cut Parts (Euro Pallet)

x 02_99 Transportation Request (Browser GUI)

x 99_02 Transportation Request Confirmed (Browser GUI) x 02_98 Confirm Unloading (Press Button) x 02_98 Confirm Loading (Press Button)

x 98_02 Small Cut Parts (by hand)

x 01_99 Transportation Request (Browser GUI)

x 99_01 Transportation Request Confirmed (Browser GUI)

99_AGV Transportation Management System

x 99_95 Request Storage Location x 99_95 Storage Location Unloaded

x 99_98 Transportation Order

S

98_AGV - Small Sheet Parts x 98_99 Transportation Order Confirmed x 98_99 Loading Confirmed x 98_99 Unloading Confirmed

x 97_02 Cut Parts (Euro Pallet)

x 95_99 Available Storage Location x 99_97 Transportation Order 95_Storage Location Management AGV

x 97_99 Transportation Order Confirmed x 97_99 Loading Confirmed x 97_99 Unloading Confirmed

97_AGV - Large Parts

x 80_97 Cut Parts (Euro Pallet)

x 97_80 Cut Parts (Euro Pallet)

Abb. 9.13 Prozessmodell Schritt 2 (hinzugefügte Elemente in Grün; entfernte Elemente in Rot)

9.2 Fallbeispiel 2: Einführung eines fahrerlosen Transportsystems

357

Schritt 3: Automatisierte Steuerung der Transportaufträge In Schritt 3 wurde das FTS direkt an das bestehende MES angebunden, um automatisch Transportaufträge zu erzeugen und zu steuern. Das hei¨sst, dass nun das MES, wo vorgegeben, automatisch einen Transportauftrag anlegt, sobald ein Produktionsschritt als fertig gemeldet wird und das Material oder Halbfabrikat an einem anderen Arbeitsplatz benötigt wird. Im besten Fall bedeutet dies, dass keinerlei manueller Transport mehr zwischen den einzelnen Arbeitsplätzen stattfindet. Sollte ein Arbeitsplatz nicht an die FTS-Infrastruktur angebunden sein, wird automatisch ein Staplerfahrer über das MES benachrichtigt. Das entsprechende Prozessmodell für Schritt 3 wird in Abb. 9.14 gezeigt. Alle Änderungen, diesmal im Vergleich zu Schritt 2, sind wieder farbig hervorgehoben

9.2.3

Erzielte Ergebnisse

Im beschriebenen Pilotprojekt wurde eine inkrementelle Strategie genutzt, um das Risiko einer FTS-Einführung und der damit verbundenen massiven Prozessveränderungen zu reduzieren. Dass alle drei geplanten Schritte auch umgesetzt wurden, zeigt, dass die jeweils vorherigen Schritte erfolgreich abgeschlossen wurden.

• 01_97 Cut Parts (Euro Pallet)

• 01_98 Small Cut Parts (by hand) • 01_98 Confirm Loading (Press Button)

01_Sawing Center 07_01 Production Order Saw 07_1 List Of Pending Material Requests (Small Parts)

01_07 Production Order Saw Started 01_07 Production Order Saw Finished 01_07 Request List Of Pending Material Requests (Small Parts)

81_01 Small Cut Parts (by hand)

07_96 List Of Pending Material Requests

01_81 Small Cut Parts (by hand)

81_Shelf for Small Cut Parts

96_07 Request List Of Pending Material Requests 96_07 Material Delivered

• 07_06 Synchronising Production Orders

96_02 Semi-Finished Product

07_02 Production Order 07_Manufacturin g Execution System (MES)

06_SAP ERP System

02_Workplace Production

96_Forklift Driver

80_Palet Rack For Cut Parts

02_96 Semi-Finished Product 02_07 Request Material 02_07 Production Order Started 02_07 Production Operation Started 02_07 Production Operation Finished 02_07 Production Order Finished

06_07 Synchronising Production Orders

99_07 Material Delivered

07_99 Transportation Order

02_99 Transportation Request (Browser GUI)

99_02 Transportation Request Confirmed (Browser GUI) 02_98 Confirm Unloading (Press Button) 02_98 Confirm Loading (Press Button)

98_02 Small Cut Parts (by hand)

01_99 Transportation Request (Browser GUI)

99_01 Transportation Request Confirmed (Browser GUI)

99_AGV Transportation Management System

99_95 Request Storage Location 99_95 Storage Location Unloaded

99_98 Transportation Order

S

98_AGV - Small Sheet Parts

98_99 Transportation Order Confirmed 98_99 Loading Confirmed 98_99 Unloading Confirmed 97_02 Cut Parts (Euro Pallet) 97_02 Semi-Finished Product

95_99 Available Storage Location

02_97 Semi-Finished Product 99_97 Transportation Order 80_97 Cut Parts (Euro Pallet)

95_Storage Location Management AGV

97_AGV - Large Parts 97_99 Transportation Order Confirmed 97_99 Loading Confirmed 97_99 Unloading Confirmed

97_80 Cut Parts (Euro Pallet)

Abb. 9.14 Prozessmodell Schritt 3 (hinzugefügte Elemente in Grün; entfernte Elemente in Rot)

358

9 Beispiele aus der Praxis

Eines der Hauptwerkzeuge für die Umsetzung dieser Strategie war die subjektorientierte Modellierungsmethode, welche auf dem Informationsfluss zwischen Prozessbeteiligten aufbaut. Zusätzlich unterstützt der Ansatz modulare Prozessstrukturen. Veränderungen in den Logistikprozessen zwischen den Projektschritten konnten durch selektive Änderungen im bestehenden Prozessmodell dargestellt werden. Es war nicht notwendig, veränderte Prozessmodelle komplett neu zu modellieren. Die lose Verbindung (loose coupling) zwischen den Subjekten ermöglichte es, ein und dasselbe SID mit nur wenigen Ändrungen wiederzuverwenden, indem einzelne Elemente hinzugefügt oder entfernt wurden. Verhaltensdiagramme, die von Änderungen nicht betroffen waren, konnten vollständig unverändert gelassen werden. Dies sparte Zeit in der Planung und Validierung jeder Prozessveränderung. Die Prozesserhebung, -modellierung und -ausarbeitung aller einzelnen Projektschritte benötigte ca. 160 Arbeitsstunden. Projektschritte 1 und 2 wurden im Jahr 2020 umgesetzt und sind produktiv5 Zusätzlich haben detaillierte Daten- und Prozessanalysen, basierend auf den Erfahrungen aus den Schritten 1 und 2, gezeigt, dass es weitreichende und komplexe Änderungen an den bestehenden Datenstrukturen des ERP-Systems braucht, um den für Schritt 3 geplanten Automatisierungsgrad zu erreichen. Die hohen Implementierungskosten ergaben eine zu hohe Amortisationsdauer und zum aktuellen Zeitpunkt (Herbst 2022) ist die Umsetzung von Schritt 3 pausiert. Dies zeigt, dass die Strategie der schrittweisen Umsetzung, um das Projektrisiko zu reduzieren, richtig war.

9.2.4

Fazit der Methodenanwendung

Einfachheit der Modellierung: Alle Beteiligten konnten die verwendete Notation sehr schnell lernen und verstehen und beteiligten sich direkt an der Erstellung des Prozessmodells – unabhängig von vorherigen Erfahrungen und Wissensstand (vom IT-Spezialisten bis zum Staplerfahrer). Eines der Hauptwerkzeuge, welches zur Umsetzung der inkrementellen Strategie eingesetzt wurde, war der S-BPM-Ansatz. Dadurch konnte eine gemeinsame Projektsprache geschaffen werden, um die Informationsflüsse zwischen den Prozessbeteiligten in einer modularen Prozessstruktur zu beschreiben. Verteilte Modellierung: Veränderungen zwischen den einzelnen Projektschritten erforderten keine komplette Neugestaltung der Prozessmodelle. Die lose Verbindung der Subjekte über die Nachrichten ermöglichten es, die bereits erstellten SIDs mit nur wenigen Änderungen individuell anzupassen und dabei auch die Gesamtkonsistenz des Modells nicht zu gefährden.

5 Eine Vorführung findet sich unter folgendem Link: https://www.youtube.com/watch?v=

Mpds0goQpzo. Der FTS-Lieferant hat das Projekt als Referenz („Success Story“) veröffentlicht.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

359

Subjektverhalten sind innerhalb der jeweiligen Subjekte in sich geschlossen definiert, und für die Modellierung eines vollständigen SID ist es nicht notwendig, die Subjektverhalten zu kennen. Das ermöglichte es dem Projektteam, die Prozesse zu beschreiben ohne jedes Detail darstellen zu müssen. Zum Beispiel war es nicht notwendig (und auch nicht möglich), das Subjektverhalten des FTS („AGV Transportation Management System“ in Abb. 9.12) zu beschreiben. Allerdings war es möglich, die Interaktionen des Systems und die notwendigen, übertragenen Informationen zu spezifizieren, was wiederum die Grundlage zur Definition der Systemschnittstelle war. Kontinuierliche Veränderungen: Die relativ schnelle und einfache Visualisierung der möglichen Projektschritte und der notwendigen Änderungen waren eine zusätzliche Unterstützung dabei, die notwendigen Veränderungen und Anforderungen zu kommunizieren – intern und extern. Das sparte viel Zeit und Aufwand bei der Planung und Validierung jedes Projektschritts. Zusätzlich konnten die Implementierungskosten für jeden Schritt besser abgeschätzt werden. IT-Integration: Die PASS-Modelle dienten als wichtiges Kommunikationsmittel innerhalb des Projektteams. Ausschlaggebend dafür waren die leicht lesbaren SIDs welche für jeden Schritt des Projekts genutzt wurden. Das erleichterte die Erhebung und Kommunikation der Anforderungen zur Entwicklung der Mensch-Maschine- und MaschineMaschine-Schnittstellen. Zusätzlich wurden die Prozessmodelle genutzt, um das Konzept vor der Umsetzung zu verifizieren.

9.3

Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

9.3.1

Ausgangssituation

Im Frühjahr 2020 hat die Peneder Bau-Elemente GmbH ein umfangreiches Verbesserungsprogramm für die Produktion von Feuerschutzelementen gestartet. Basierend auf der Unternehmenstrategie, die Produktion ganzheitlich zu modernisieren, Ressourceneffizienz zu steigern und das geplante Wachstumsziel zu erreichen, sollten alle Planungs-, Logistik-, und Produktionsprozesse hinsichtlich möglicher Verbesserungspotenziale untersucht werden. Über mehrere Monate hinweg wurden umfangreiche Prozessanalysen durchgeführt und es konnten viele Verbesserungsmöglichkeiten mit unterschiedlichem Umsetzungsaufwand identifiziert werden. Als Verbesserungsmöglichkeit mit dem größten Potenzial, aber auch dem größten Umsetzungsaufwand, identifizierte das Projektteam die Digitalisierung des kompletten Produktionssystems durch die Einführung eines Manufacturing Execution System (MES). Ein eigenes Projektteam „Digitalisierung“ wurde gegründet mit dem Ziel, die Produktion und alle unterstützenden Prozesse (wie z. B. Produktionsdatenerfassung, Maschinendatenerfassung, Produktions- und Kapazitätsplanung, Materialmanagement, Logistik, etc.) zu digitalisieren, um so noch strukturiertere, effizientere und transparentere Produktionsprozesse zu schaffen.

360

9 Beispiele aus der Praxis

Die Einführung eines MES ist generell eine Veränderung mit hohem Ressourceneinsatz und weitreichenden Auswirkungen auf alle Unternehmensbereiche. Ein Wechsel zwischen unterschiedlichen MES-Lösungen ist mit noch höherem Aufwand verbunden, und das eingesetzte System muss für Jahrzehnte die Anforderungen des Unternehmens erfüllen und einsatzbereit sein. Das heißt, dass für die Wahl einer geeigneten Softwarelösung bereits vorab so viele aktuelle und auch zukünftige Anforderungen an das System wie möglich bekannt sein müssen. Dies galt natürlich auch für Peneder. Zusätzlich musste die Umsetzung des MES bei Peneder auf zwei unterschiedliche Weisen funktionieren: Zum einen musste es möglich sein, das MES in die bestehenden Prozess- und Softwarestrukturen zu integrieren; zum anderen sollten existierende Prozesse auch verändert werden, um besser und effizienter in die neue digitale MES-Umgebung zu passen. Um die richtigen Anforderungen für ein neues System zu definieren und ein aussagekräftiges Lastenheft zu erhalten ist ein detailliertes Prozessverständnis notwendig. Alle relevanten Prozessinformationen sowie Schnittstellen zwischen Systemen, Maschinen und Menschen sind ausschlaggebend für die Gestaltung eines produktionsbegleitenden MES. Zu Beginn des Projektes war jedoch keine explizite, aktuelle Prozessdokumentation vorhanden. Ähnlich wie schon in Fallbeispiel 2 bestand das Projektteam aus unterschiedlichen Mitarbeitern aus allen Bereichen: Produktionsmitarbeiter, IT- Berater, Produktionsplaner, Qualitätsmanagement, uvm. Auch hier war es unabdingbar, eine gemeinsame Kommunikationsbasis zu schaffen, um Missverständnisse zu vermeiden. Das war der Anlass, subjektorientierte Prozessmodellierung einzusetzen. Als weitere Herausforderungen kamen hinzu, dass im selben Zeitraum die komplette Neugestaltung eines Produktionsbereichs, der Neubau des Pulverbeschichtungsofens, sowie die Modernisierung der Steuerung der Fördertechnik geplant waren. Resultierende Änderungen daraus mussten ebenfalls in den MES-Anforderungen berücksichtigt werden, da eine neue Arbeitsplatzstruktur mit neuer Arbeitsplatzanordnung Auswirkungen auf die Stammdaten im ERP hat, auf die das MES zugreifen soll. Ebenso sollte für eine durchgängige Maschinendatenerfassung die Fördertechnik an das MES angebunden werden. Dementsprechend muss die resultierende MES-Fördertechnik Schnittstelle definiert werden, jedoch auch unter Berücksichtigung einer geplanten aber noch nicht umgesetzten Modernisierung der Fördertechnik.

9.3.2

Vorgehen

Wie in den vorherigen Projekten fanden Einzelinterviews mit den Projektbeteiligten statt. Das Prozessmodell und der Entstehungsprozess dazu konnten von allen Beteiligten jeweils live auf einem großen Bildschirm mitverfolgt werden. Dieses Vorgehen hatte sich bereits in der Vergangenheit bewährt, da die befragten Personen direkt sehen konnten, wie ihr jeweiliges Wissen in einem Prozessmodell abgebildet wird.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

361

Vor den eigentlichen Interviews erhielt jeder der Beteiligten eine vorbereitete, kurze Einführung in die S-BPM/PASS-Notation. Diese Erläuterung war für jede Person gleich, unabhängig von Funktion und vorheriger Erfahrung in Prozessmodellierung. Sie lautete wie folgt: „Die Prozesse werden subjektorientiert modelliert (S-BPM). D.h. der Fokus der Prozessdarstellung liegt auf der Sicht der Beteiligten und deren Position im Gesamtprozess. Die grafische Darstellung erfolgt deshalb über zwei Ebenen. Im SID werden die Prozessbeteiligten (Abstrakt: also Mensch, Maschine, System,. . . ) und deren Interaktionen miteinander dargestellt. Im SBD wird die konkrete Handlung des Prozessbeteiligten (Subjekt) aus dessen Sicht beschrieben. Das Subjektverhalten wird über drei Zustände beschrieben. Die Zustände sind zur besseren Unterscheidung eingefärbt (frei wählbar): Empfangen (ich brauche etwas, um arbeiten zu können), Senden (jemand braucht von mir etwas, um arbeiten zu können), DO (was muss ich tun).“ Diese Kurzbeschreibung entstand im Laufe der Zeit über eine Vielzahl von S-BPMProjekten hinweg, bei denen sie zur Anwendung kam. Es hat sich dabei immer wieder gezeigt, dass eine umfangreichere Beschreibung zum Verständnis der Prozessmodelle nicht notwendig war – und von den Prozessbeteiligten großteils auch gar nicht gewollt wurde. Die durch die Interviews entstandenen Prozessmodelle wurden genutzt, um ein gemeinsames Prozessverständnis zu schaffen und um die Schnittstellen zwischen Mitarbeitern, Produktionsmaschinen, Softwareanwendungen (Sonderlösungen und COTS), ERP-System, Sensoren und Track&Trace zu beschreiben. Während der Prozesserhebung wurden notwendige oder gewünschte Anpassungen an die Prozesse direkt in das Prozessmodell eingearbeitet. Das heißt, dass die Ist-Prozesse nicht separat dokumentiert und analysiert wurden, bevor Änderungen implementiert wurden. Stattdessen wurden direkt von Beginn an Soll-Prozesse modelliert. Dieser direkte Übergang in eine Soll-Modellierung ist eigentlich nicht üblich und war so auch nicht geplant. Während der Erhebung der Prozesse begannen die Befragten jedoch nicht nur ihre tägliche Arbeit zu beschreiben sondern formulierten auch sehr detaillierte Änderungen, welche ihre Arbeit verbessern oder erleichtern würden. Viele dieser Änderungsvorschläge hatten einen direkten Einfluss auf die Anwendung des neuen MES, weshalb das Projektteam beschloss, direkt die Soll-Prozesse zu modellieren. Zu Beginn der Erhebungs- und Modellierungsphase wurde ein Prozessmodell für jeden eigenen Produktionsbereich (also je ein SID für z. B. Logistik, Metallbearbeitung, Pulverbeschichtung, etc.) erstellt, da das die natürliche Art war wie die Teamleiter ihre Prozesse und Bereiche beschrieben. Jeder Teamleiter hat seine Arbeit dabei als einen fortlaufenden Prozess von Anfang bis Ende erläutert, ohne diesen in individuelle Unterprozesse aufzuteilen. Die resultierenden (jeweils bereichsspezifischen) Prozessmodelle bestehen insgesamt aus über 80 einzelnen Subjekten, mit entsprechend vielen Subjektverhalten, und mehreren hundert Nachrichten, welche zwischen den Subjekten ausgetauscht werden (Beispiele siehe Abb. 9.15, 9.16 und 9.17).

362

9 Beispiele aus der Praxis

S Sheet 14_Material versorgung

14_41 Pulverteile-Kleinteile 14_41 Pulverteile Fremdfertigung

S

42_41 Gehänge (leer) 41_42 Gehänge (beladen)

Sheet 41_Heber 2

S

30_41 Pulverteile 101_42 Anlagendaten 101_42 Jobliste (Heber 2) 101_42 Produktionsauftragsdaten 101_42 Farbenzuordnung OK 101_42 Farbenzuordnung NOK

Sheet 30_Zargenb au

42_44 Auftragsdaten Gehänge

41_101 Produktionsauftrag 41_101 Farbzuordnung Gehänge

S Sheet 24_Komplettie ren Basic

Abstimmung Farben zwischen Heber 1 und Heber 2?

24_40 Element

40_42 Gehänge (beladen)

S

S

S

Sheet 40_Heber 1

Sheet 42_Förderte chnik

43_44 Gehänge (gepulvert)

Sheet 43_Beschich tung

42_43 Gehänge (beladen)

S

S

S Sheet 44_Einbrenn ofen

44_45 Gehänge fertig

Sheet 45_Abkühlka mmer

45_60 Gehänge fertig

Sheet 60_Heber 3

42_40 Gehänge (leer)

40_101 Produktionsauftrag 40_101 Farbenzuordnung Gehänge

42_101 Anlagendaten FT

101_40 Jobliste (Heber 1) 101_40 Produktionsauftragsdaten 101_40 Anlagendaten FT 101_40 Farbenzuordnung OK 101_40 Farbenzuordnung NOK

S

101_42 Anlagedaten FT

43_101 Fertigmeldung Beschichten

101_43 Jobliste Beschichtung 101_43 Anlagendaten FT

44_101 MDE Einbrennofen

45_101 MDE Abkühlkammer

S

Sheet 101_Manufacturing Execution System (MES)

Sheet 49_Teamleit er

101_49 Anlagendaten FT 101_49 Jobliste Pulverei 101_49 MDE Einbrennofen 101_49 MDE Abkühlzone

Abb. 9.15 Prozess Pulverbeschichtung (SID)

Für die Modellierung der PASS-Notation kann prinzipiell jedes beliebige Werkzeug, welches Formen und Pfeile darstellen kann, genutzt werden. Im Zuge der Erhebung wurde für die Modellierung auf ein einfaches, spezielles MS Visio Plug-In für die subjektorientierte PASS-Modellierung zurückgegriffen6 (vgl. Abschn. 8.1.5). Neben der komfortableren Bedienung und Unterstützung, das Modell konsistent zu halten, besteht ein zusätzlicher Vorteil des Plug-In darin, dass das grafische Prozessmodell direkt in eine Textverarbeitung exportiert werden kann. Diese enthält auch eine umfangreiche Darstellung aller Subjekte, Subjektverhalten, Nachrichten, Zustände und deren Inhalte. Die resultierende Dokumentation war mit über 140 Seiten allerdings umfangreicher und komplexer, als dass diese für an der Erhebung unbeteiligte Dritte (z. B. Softwareanbieter) verständlich gewesen wäre (Abb. 9.18). Trotzdem ergänzte die Textbeschreibung das grafische Modell und half dabei, relevante Schnittstellen zwischen den Prozessakteuren zu identifizieren. Das war besonders hinsichtlich der geplanten Maschinendatenerfassung hilfreich, um die individuellen Maschinensteuerungen und -anbindungen zu beschreiben. Das so entstandene Prozessmodell war die Ausgangsbasis, um ein Lastenheft zu erstellen, mit dem die Anforderungen an die unterschiedlichen Schnittstellen sowohl intern, zwischen Produktion und IT, als auch extern, mit den verschiedenen Softwareanbietern, kommuniziert wurden. Die grafischen Prozessmodelle beschrieben direkt die 6 https://subjective-me.jimdofree.com/visio-modelling/.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

363

Abb. 9.16 SVD des Arbeitsplatzes „Heber 1“

R

Gehänge von Fördertechnik übernehmen

From: 42_Fördertechnik Msg: 42_40 Gehänge (leer)

R

Auftragsdaten (Jobliste) prüfen From: 101_Manufacturing Execution System (MES) Msg: 101_40 Jobliste (Heber 1)

D Gehängefarbe zuweisen Farbe zuweisen Farbe zuweisen

D

S

Farbe in System festlegen

Gehängefarbe korrigieren

To: 101_Manufacturing Execution System (MES) Msg: 40_101 Farbenzuordnung Gehänge

D

R

anderes Element aufhängen

Element übernehmen anderes Element nehmen

From: 24_Komplettieren Basic Msg: 24_40 Element

S

Element anscannen

To: 101_Manufacturing Execution System (MES) Msg: 40_101 Produktionsauftrag

R

Rückmeldung Farbprüfung From: 101_Manufacturing Execution System (MES) Msg: 101_40 Farbenzuordnung NOK

From: 101_Manufacturing Execution System (MES) Msg: 101_40 Farbenzuordnung OK

D

D Fehlersuche

Element aufhängen

Gehängefarbe falsch vergeben Fehler an Element

Do Transition

D Element vorbehandeln

Gehänge nicht fertig

Gehänge fertig

S

Element wegfahren

To: 42_Fördertechnik Msg: 40_42 Gehänge (beladen)

D Ende Heber 1

gewünschten Soll-Prozesse; allerdings wurden im Lastenheft die aktuellen Ist-Prozesse ebenfalls in Textform erläutert. Zusätzlich wurden für ein besseres Verständnis spezifisch gewünschte MES-Funktionen (z. B. Arbeitsabläufe, Reports, Dashboards, usw.) in Form

364

9 Beispiele aus der Praxis

Abb. 9.17 Beispiel Dateneingabe für Nachricht „Produktionsauftrag“

Abb. 9.18 Digital Transformation von Papier über Prozess zur Software

von klassischen Use Cases beschrieben. Ausgehend von den Use Cases wurden funktionsspezifische „Sub“-Prozessmodelle aus dem übergreifenden Prozessmodell abgeleitet (siehe Abb. 9.19). Der Gesamtaufwand für die Prozesserhebung und -modellierung betrug ca. 90 Arbeitsstunden und ca. 160 Arbeitsstunden um die finale Version des Lastenhefts fertig zu stellen. Dies war ein relativ geringer Arbeitsaufwand, wenn man die hohe Anzahl an Prozessbeteiligten, den hohen Detaillierungsgrad der Modelle und des Lastenhefts berücksichtigt, sowie dass bei der Erhebung von Null begonnen werden musste. Das Lastenheft und die Prozessmodelle wurden an alle MES-Anbieter ausgehändigt. Auf Basis des Lastenhefts sollten die Anbieter Rückmeldung geben, welche Anforderungen erfüllt werden können, ob diese im Standard enthalten sind oder über Sonderfunktionen gelöst werden müssen, und ein entsprechendes Angebot abgeben. Das Ziel war es, die einzelnen Leistungsumfänge, Implementierungskosten und laufenden Kosten der Anbieter miteinander vergleichen zu können.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

365

S 14_ Material versorgung

x 14_41 Pulverteile-Kleinteile x 14_41 Pulverteile Fremdfertigung x 42_41 Gehänge (leer)

S

x 41_42 Gehänge (beladen)

41_Heber 2

S

x 101_42 Anlagendaten x 101_42 Jobliste (Heber 2) x 101_42 Produktionsauftragsdaten x 101_42 Farbenzuordnung OK x 101_42 Farbenzuordnung NOK

x 30_41 Pulverteile

30_Zargenb au

x 41_101 Produktionsauftrag x 41_101 Farbzuordnung Gehänge

x 40_42 Gehänge (beladen)

S

S

24_Komplettie ren Basic

x 24_40 Element

S 42_Förderte chnik

40_Heber 1

x 42_40 Gehänge (leer)

x 40_101 Produktionsauftrag x 40_101 Farbenzuordnung Gehänge x 101_40 Jobliste (Heber 1) x 101_40 Produktionsauftragsdaten x 101_40 Anlagendaten FT x 101_40 Farbenzuordnung OK x 101_40 Farbenzuordnung NOK

x 101_42 Anlagedaten FT

x 42_101 Anlagendaten FT

I 101_Manufacturing Execution System (MES)

Abb. 9.19 Pulverbeschichtung „Sub“-Prozess (SID)

9.3.3

Erzielte Ergebnisse

Aufgrund der durch das Lastenheft definierten Anforderungen war es möglich, die erhaltenen Softwareangebote hinsichtlich des Leistungsumfangs und des Preises gegenüberzustellen und letzendlich eine Umsetzungs- bzw. Kaufentscheidung zu treffen. Mit dem so beauftragen Anbieter wurde in sogenannten „Lösungsworkshops“ die geforderte Umsetzung noch einmal im Detail durchbesprochen und verifiziert. Im Zuge dieser Work-

366

9 Beispiele aus der Praxis

shops merkte das Projektteam des Anbieters an, dass der Detailgrad des Prozessmodells und der Schnittstellenbeschreibungen sehr hoch sei und entsprechend bei der Ausarbeitung der Lösung helfe. Offene Fragestellungen konnten in wenigen Stunden oder sogar Minuten geklärt werden, wofür bei anderen Umsetzungen oftmals ganze Arbeitstage notwendig waren. Zum Verfassungszeitpunkt dieses Kapitels (Herbst 2022) war die Digitalisierung der Produktion zu ca. 90 % umgesetzt. Zu diesem Zeitpunkt war erkennbar, dass das prognostizierte Einsparungspotenzial von etwa 100.000 e pro Jahr erreichbar sein wird. Dies wird großteils dadurch erreicht, dass die Mitarbeiter relevante Informationen zum aktuellen Produktionsauftrag aus dem MES aufbereitet zur Verfügung gestellt bekommen. Täglich wurde sehr viel Produktionszeit für die Organisation und manuelle Auswertung von Auftragsdaten aufgewendet. Die realisierten Verbesserungen konnten direkt aus dem Prozessmodell heraus abgeleitet und umgesetzt werden. Hier einige Beispiele von umgesetzten Verbesserungen: • Auftragsdaten anfordern Vorher: An einem Arbeitsplatz erhalten mehrere Mitarbeiter unterschiedlichste Elemente zum Fertigmontieren. Nach Erhalten des Elementes sucht sich ein Mitarbeiter die passenden, gedruckten Auftragspapiere von einer Magnetwand (vgl. Abb. 9.20). Nachher: durch den Scan eines am Produkt angebrachten Barcodes werden automatisch alle Auftragsdaten auf einem Bildschirm angezeigt (vgl. Abb. 9.21, 9.22 und 9.23). • Sonderteile zählen Vorher: Ein Mitarbeiter benötigte 1 Std. pro Tag, um alle Auftragspapiere (ca. 150 Seiten) nach Sonderteilen zu durchsuchen und zu zählen (vgl. Abb. 9.24). Nachher: Durch einen automatischen Report im MES werden alle Teile ausgewertet und auf wenigen Seiten zusammengefasst (vgl. Abb. 9.25). • Reihenfolge der Farben im Pulverbeschichten Vorher: Zur Vorbereitung der benötigten Farben in der Pulverbeschichtung ist es notwendig, dass ein Mitarbeiter mehrmals pro Stunde die Fördertechnik abgeht, um die auf den Transportgehängen angebrachten Farbschilder zu lesen, damit die richtige Farbe vorbereitet werden kann. Nachher: Ein Dashboard auf einem Bildschirm direkt bei den Pulverkabinen zeigt den Status der Fördertechnik und der benötigten Farben in der richtigen Reihenfolge an (vgl. Abb. 9.26). Die strukturierte und zeitnahe Bereitstellung der notwendigen Produktionsdaten, zugeschnitten auf den jeweiligen Arbeitsplatz, reduziert den Organisationsaufwand über den gesamten Produktionsprozess hinweg und erhöht maßgeblich die Transparenz in der Fertigung. Zukünftig werden auch alle Produktionsaufträge am jeweiligen Arbeitsplatz gestartet und fertig gemeldet was eine genaue Erfassung der Bearbeitungszeiten ermöglicht. Zusätzlich können durch die Digitalisierungsschritte jährlich bis zu 800.000 Blatt Papier eingespart werden – ein Faktor, der auch dem Unternehmensziel der Nachhaltigkeit und CO2-neutralen Fertigung zugute kommt.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

367

Abb. 9.20 Bereitstellung der Auftragsdaten in Papierform

9.3.4

Fazit der Methodenanwendung

Die Ableitung des Lastenheftes und der notwendigen Spezifikationen basierend auf dem Prozessmodell konnte relativ einfach durchgeführt werden. Das 45-seitige Dokument bestand aus allgemeinen Zielen, grundlegenden Anforderungen für den Gesamtprozess, sowie mehreren Use Cases und User Stories zur Verdeutlichung der geplanten Anwendung. Obwohl diese Beschreibungen anders benannt waren, handelte es sich um direkte Auszüge aus den modellierten Subjektverhalten. Die vollständigen Prozessmodelle fanden sich noch einmal in einem Anhang des Lastenhefts wieder. Einfachheit der Modellierung: Keine der an der Erhebung beteiligten Personen (alle Teamleiter der unterschiedlichen Produktionsteams) hatte Vorkenntnisse oder Erfahrungen in Prozessmodellierung oder Prozessmanagement. Ähnlich wie in den Fallbeispielen 1

368

9 Beispiele aus der Praxis

Abb. 9.21 Auftragsdaten anfordern per SCAN und MES

Abb. 9.22 Auftragsdaten per MES an einem Bildschirm bereitstellen

und 2 bekamen die Interviewten eine kurze Einführung (siehe auch Abschn. 9.3.2) in die Notation. Die Teamleiter haben hauptsächlich mündlich beschrieben, welche Abläufe bei den einzelnen Arbeitsplätzen stattfanden. Ein Modellierungsexperte hat parallel dazu grafisch modelliert. Trotz der sehr einfachen Erklärung konnten alle Beteiligten das entstehende Prozessmodell lesen, interpretieren und auch verifizieren („[...] darum brauchen wir da noch ein grünes Kästchen, weil ich warte auf [...]“). Gleichzeitig haben die Teamleiter während der Modellierungsphase begonnen, ihren optimierten Wunschprozess zu beschreiben, indem sie das Prozessmodell veränderten. Mit der zunehmenden Komplexität des Prozessmodells entstanden die gleichen Probleme wie bei den vorhergehenden Projekten: die Nachrichten und ihre chronologische Reihenfolge konnten, zumindest im SID, nur mehr mit hohem Detailwissen nachvollzogen werden. Aufgrund des sehr linearen Produktionsprozesses war dies in Projekt 3 jedoch weniger ausgeprägt.

9.3 Fallbeispiel 3: Umsetzung eines Manufacturing Execution System

369

Abb. 9.23 Digitale Transformation des Prozesses

Verteilte Modellierung: Aufgrund des subjektorientierten Vorgehens konnte jeder Teamleiter einzeln interviewt werden, und trotzdem entstanden in sich geschlossene, syntaktisch korrekte Prozessbeschreibungen. Bei anderen gängigen Ansätzen, dem klassischen Modellierungsworkshop, wäre die Anwesenheit aller Teamleiter (6 Teamleiter im Produktionsbereich) gleichzeitig notwendig gewesen. Da die Teamleiter ihre produktiven (operatives Arbeiten in der Produktion) und nicht-produktiven Stunden (z. B. Zeiten für Projekte) berichten, hätte dies einen direkten Einfluss auf den wöchentlichen Werksbericht und die damit verbundenen Kennzahlen gehabt. Um das Prozessmodell übersichtlicher und einfacher lesbar zu gestalten, wurde das SID in mehrere Sub-SIDs zerlegt, d. h. in je ein Sub-SID pro Fertigungsbereich. Die Verbindungen der einzelnen Sub-Prozesse wurden über sogenannte Interface-Subjekte hergestellt. Ein Interface-Subjekt ist ein Subjekt ohne Subjektverhalten und wird als Platzhalter genutzt. Abb. 9.15 zeigt einen Produktionsbereich (dargestellt in Blau), welcher durch Interface-Subjekte mit vier anderen Bereichen verbunden ist (dargestellt in Orange, Grün, Pink und Rot). Kontinuierliche Veränderungen: Wie in den Projekten 1 und 2 wurden die Prozessmodelle während der Erhebung in mehreren Iterationen überarbeitet und schrittweise verfeinert, entsprechend der Idee der inkrementellen Veränderung. Veränderungen am Soll-Prozess wurden dargestellt, indem einzelne Subjekte, Subjektverhalten und/oder Nachrichten hinzugefügt, entfernt oder geändert wurden. Um die Nachvollziehbarkeit der Modelle für die Softwareanbieter zu erhöhen, wurden nur einzelne, spezifische Use Cases im Lastenheft dargestellt, und zwar in der Form der bereits erwähnten Sub-Prozesse. Diese Prozessabschnitte wurden praktisch aus dem Gesamt-SID „ausgeschnitten“ indem für die Beschreibung nicht relevante Subjekte,

370

9 Beispiele aus der Praxis

Abb. 9.24 Manuelles Zählen der Sonderteile (Beispielliste)

Nachrichten und Subjektzustände für diese Darstellung gelöscht wurden. Es war nicht notwendig, die einzelnen Prozessabschnitte neu zu modellieren (vgl. Abb. 9.19). IT-Integration: Die 140-seitige, automatisch aus den Modellen generierte Prozessbeschreibung war für die Zielerreichung des Projekts nicht direkt verwendbar. Obwohl die Softwareanbieter die Prozessmodelle als präzise, strukturiert und grundsätzlich verständlich beurteilten, verlangten die Anbieter nach einem kompakteren und traditionelleren Lastenheft für die Angebotserstellung und Leistungsbeschreibung. Während der Implementierungsphase erhielt das Projektteam sehr positives Feedback des Softwareanbieters bezüglich des Detailgrades und der Verständlichkeit der Prozessbeschreibungen. Datenspezifikationen (wie z. B. Arbeitsplatzstrukturen, Datenhierarchie, etc.) wurden in einigen kurzen Online-Workshops (bis zu 1 Stunde) besprochen und definiert – Aktivitäten welche laut Softwarelieferant normalerweise mehrere Personentage

9.4 Zusammenfassung

371

Abb. 9.25 Automatischer Report für Sonderteile

Abb. 9.26 Dashboard Beschichtung

über mehrere Wochen hinweg benötigten. Dies ermöglichte es, bereits 4 Wochen nach dem ersten technischen Workshop ein erstes Basissystem in der Testumgebung aufzusetzen – ein Schritt, welcher direkt die Projektdurchlaufzeit und Projektkosten reduzierte (der Softwareanbieter verrechnete nach Projektstunden).

9.4

Zusammenfassung

In den beschriebenen Projekten war die spezielle Verwendung von Prozessmodellen unterschiedlich. Die einzelnen Prozesse wurden analysiert, verbessert und aus den Prozessbeschreibungen die Anwendungsspezifikation abgeleitet. Die erstellten Prozessmodelle hatten nicht wie üblich als Hauptzweck die Dokumentation. Das Erstellen einer Dokumentation wird im Allgemeinen als Last angesehen, welche zum Abschluss eines Projektes

372

9 Beispiele aus der Praxis

bzw. einer Prozessimplementierung fällig wird und die nicht direkt zur Produktivität beiträgt. Das konnte in den drei Projekten nicht beobachtet werden. Hier wurde die Prozessmodellierung aktiv als operatives Werkzeug während des Änderungsprozesses und nicht als abschließende Dokumentation verwendet. Die erstellten PASS-Modelle waren lebendige Dokumente, die sich ständig weiterentwickelten, und ihr Erstellungsprozess war ein wesentlicher Bestandteil des Verständnisses und der Strukturierung komplexer Sachverhalte. Sie stellten zentrale Bezugspunkte für alle Beteiligten dar, nicht nur am Ende eines Projekts oder einer Projektphase, sondern jederzeit während der gesamten Laufzeit der Projekte. Die Prozessmodelle waren die Kristallisationspunkte für die laufende Diskussion für Prozessanpassungen während der Realisierungsphase und auch danach bei der kontinuierlichen Verbesserung.

Literatur ENGEL Austria (2022) Engel – hersteller im bereich kunststoff-spritzguss. https://www.engelglobal. com/de/at/unternehmen/daten-fakten.html. Zugegriffen am Oktober 2022 Erlach K (2010) Wertstromdesign, 2., bearb. u. erw. Aufl. LMI Forum GmbH, Meersbusch Fleischmann A, Schmidt W, Stary C, Obermeier S, Börger E (2012) Subject-oriented business process management. Springer, Berlin/Heidelberg. http://link.springer.com/10.1007/978-3-64232392-8 Fleischmann C, Riha K, Stangl G (2016) Logistics processes modelled in s-bpm and implemented in sap to reduce production lead times. In: Proceedings of the 8th International Conference on Subject-Oriented Business Process Management, S-BPM ’16. Association for Computing Machinery, New York, NY, USA. https://doi.org/10.1145/2882879.2882888 Kannengiesser U, Müller H (2018) Industry 4.0 standardisation: Where does S-BPM fit? In: Stary C (ed) In: Proceedings of the 10th International Conference on Subject-Oriented Business Process Management, S-BPM ONE 2018, Linz, Austria, 05–06 April 2018. ACM, pp 11:1–11:8. https:// doi.org/10.1145/3178248.3178255 Kock N, Verville J, Danesh-Pajou A, DeLuca D (2009) Communication flow orientation in business process modeling and its effect on redesign success: Results from a field study. Decis Support Syst 46(2):562–575 Liappas I (2006) Vom business zu den prozessen. In: AGILITÄT durch ARIS Geschäftsprozessmanagement. Springer, Berlin/Heidelberg, S 43–55 Moser C, Kannengiesser U (2019) Incremental implementation of automated guided vehicle-based logistics using s-bpm: experience report of a digitalization project at ENGEL Austria. In: Betz S (Hrsg) S-BPM ONE. ACM, New York, S 3:1–3:6 Moser C, Kannengiesser U, Elstermann M (2022) Examining the PASS approach to process modelling for digitalised manufacturing results from three industry case studies. Enterp Model Inf Syst Archit Int J Concept Model 17. https://doi.org/10.18417/emisa.17.1 Moser C, Ríha K (2019) Digitalization of information-intensive logistics processes to reduce production lead times at ENGEL Austria gmbh: Extending value stream mapping with subjectoriented business process management. In: Urbach N, Röglinger M (Hrsg) Digitalization cases, how organizations rethink their business for the digital age. Springer, Cham, S 293–312. https:// doi.org/10.1007/978-3-319-95273-4_15 Parviainen P, Tihinen M, Kääriäinen J, Teppola S (2017) Tackling the digitalization challenge: how to benefit from digitalization in practice. Int J Inf Syst Proj Manag 5(1):63–77

Literatur

373

Peneder Bau-Elemente GmbH (2022) Peneder – ein familienunternehmen mit dynamik. https:// www.peneder.com/de-at/unternehmen. Zugegriffen am Oktober 2022 Riempp G (2012) Integrierte Wissensmanagement-Systeme: Architektur und praktische Anwendung. Springer, Berlin/Heidelberg Rother M, Shook J (2004) Sehen lernen–mit wertstromdesign die wertschöpfung erhöhen und verschwendung beseitigen, dt. ausg., 1.0. Springer Verlag, Heidelberg

Resümee

10

Zum Abschluss fassen wir unsere wesentlichen Erkenntnisse sowie die Rahmenbedingungen ganzheitlicher Digitalisierung von Prozessen und deren Weiterentwicklung zusammen. Wir betten diese in Ausgangssituationen aus der Unternehmenspraxis ein und verdeutlichen den Bezug von Prozessmanagementaktivitäten zu sozio-technischer Systemgestaltung. Organisationsverantwortliche erfahren schließlich erfolgskritische Einflussfaktoren ganzheitlichen Vorgehens. „Das war schon immer so und es hat immer gut funktioniert!“ wird zu „Was war wie organisiert und hat wie funktioniert“, um schließlich zu „So wollen wir unseren Handlungsspielraum leben und selbstgesteuert weiterentwickeln“ transformiert zu werden. Es sind Werte, welche individuelle Handlungen und schließlich organisationalen Mehrwert begründen. Dieses Buch vermittelt in der Wirtschaft und Wissenschaft erprobte Konzepte und Vorgehensmodelle zur unternehmensgerechten und stakeholderorientierten Organisationsgestaltung und -entwicklung auf Basis digitaler Technologien. Es zeigt neben der praxisrelevanten Zerlegung komplexer Sachverhalte in überschaubare, d. h. durch Beteiligte gestaltbare Teile die vielfältigen Entwicklungsmöglichkeiten sozio-technischer Systeme, insbesondere wenn diese anhand der Kommunikation miteinander interagierender Akteure und Komponenten modelliert werden. Damit stehen bei der Gestaltung derartiger Systeme primär nicht Datenstrukturen und deren Modellierung, sondern vielmehr in sich schlüssige Verhaltensmuster und Aufgabenbündel im Sinne funktionaler Zusammenarbeit und sozialer Kooperation im Mittelpunkt. Agilität, Resilienz, wertebasiertes Design, sowie Composable Business werden im Rahmen der prozessbasierten Modellierung von Verhaltensmustern und Aufgabenbündeln durch das Zusammenwirken autonomer Einheiten darstellbar. Die so entstehenden netzwerkartigen Unternehmensarchitekturen erlauben die Zuordnung von Technologien als Mittel und Bindeglied zwischen menschlichen Akteuren oder Systemen zur Ausführung

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2_10

375

376

10 Resümee

von Aufgaben. Prozessmodelle schaffen die erforderliche Transparenz von Abläufen sowie die Verwertbarkeit von Informationen und Daten, welche intern sowie mit externen Partnern ausgetauscht werden. Struktur und Verhalten ergänzen einander und können integrativ zur Ausführung im Sinne der Ganzheitlichkeit gebracht werden. Die genannte Komplementarität erlaubt in digitalen Transformationsprojekten die Gestaltung und Umsetzung erforderlicher Wandlungsfähigkeit von Organisationen, um ihren gesellschaftlichen Wert zu sichern. Die Reflexion und gestaltungsorientierte Durchdringung von Produktentwicklungen und Verhaltensmustern beteiligter Partner im Sinne von Design Thinking sind entscheidend für die jeweils inhaltlich wie wirtschaftlich begründete Zielerreichung mittels digitaler Transformationsprozesse. Letztere werden von Anspruchsgruppen wie gesellschaftlichen Vertretungen, Kunden, Lieferanten, oder Mitarbeiter bestimmt, die beständig Anforderungen artikulieren, die Organisationen nur ganzheitlich und unter kontinuierlicher Zusammenarbeit beteiligter Stakeholder bearbeiten können. Dazu gesellt sich disruptiver Wandel, wie er beispielsweise durch Internet of Things, Cyber-Physische Systeme oder digitale Zwillinge ausgelöst wird. Diese Art von Veränderung braucht die in den vorangegangenen Abschnitten gezeigten, fokussierten aber dennoch ganzheitlichen Entwicklungstechniken und -technologien – sie berücksichtigen das Verhalten von Systemakteuren und -komponenten sowohl aus unterschiedlichen Perspektiven als auch in ihrem wechselseitigen Kontext. Die beteiligtenorientierte ganzheitliche Systemgestaltung hat, wie konzeptionell und praktisch gezeigt, dem Prinzip der Einfachheit zu folgen, und zwar auf mehreren Ebenen: • Einfachheit bei der Gewinnung und Darstellung von Wissen über Strukturen und Abläufe, im Sinne der Aspekte, welche für Stakeholder und deren Anliegen relevant sind • Einfachheit in der Darstellung und Entwicklung einer Systemarchitektur mit beteiligten Systemkomponenten und Stakeholdern, sowohl das gesamte System als auch die Betrachtung einzelner Systemkomponenten und deren Details inklusive Zusammenspiel mit anderen betreffend • Einfachheit von Transformationsprojekten durch Verhaltensmodelle als Referenzpunkt bei der erstmaligen Digitalisierung sowie darauf aufbauenden, weiterführenden Adaptierung von organisationalen Abläufen bzw. wirtschaftlich relevanten Aufgabenbündeln. Entscheidendes Hilfsmittel zur Umsetzung dieses Prinzips, um auch heterogene Systemstrukturen mit berücksichtigen zu können, ist die Wahl von Abstraktionsebenen. Sie müssen ausreichend Überblick über nebenläufige Prozesse aber auch vertiefende Verhaltensbetrachtung im Rahmen anwendungs- und beteiligtenorientierter Modellierung sowie von Wirtschaftlichkeitsüberlegungen bieten. Erst dann stellen sie eine transparente Grundlage zur Ausführung und weiterer Digitalisierungsschritte dar.

10 Resümee

377

Gestaltung und Umsetzung können dank entsprechender Modellierungsansätze mit automatisierbarer Ausführbarkeit ohne Medienbruch ineinandergreifen. Dabei stellen die von Beteiligten erstellten Modelle Referenzpunkte dar, die, zunächst nach individuellen Vorstellungen gestaltet, in ihrer Umsetzung von ausführenden Handlungsträgern selbst erfahren werden können. Darauf aufbauend können Erweiterungen in Richtung maschineller und künstlicher Intelligenz in strukturierter Form vorgenommen werden. Derartige Erweiterungen können sowohl Technologien betreffen, welche dem Kontext cyber-physischer Systementwicklung zuzurechnen sind, als auch die wirtschaftlich relevante Entwicklung von Unternehmen, und damit das organisationale bzw. soziale Verhalten von Beteiligten ansprechen, indem Modelle den Handlungsspielraum von Beteiligten in bestimmten Situationen vergrößern. In beiden Fällen kommt der Ausführbarkeit von Modellen entscheidende Bedeutung zu, da diese Simulationen erlaubt, welche vor dem Produktiveinsatz von Prozessen unabdingbar zur Abschätzung organisationaler und damit wirtschaftlich relevanter Effekte sind. Wie die empirischen Belege vom praktischen Einsatz von Modellierungssprachen und Entwicklungstechniken in Forschungs- und Unterehmensprojekten zeigen, sind nicht alle Maßnahmen und Werkzeuge im Rahmen organisationaler Transformation mit digitalen Technologien gleichermaßen hilfreich, selbst bei einem hohen Grad an Standardisierung von Notationen und integrativer Betrachtung unterschiedlicher Perspektiven. Dies bedeutet, dass bei ganzheitlicher Unternehmensgestaltung differenziert vorgegangen werden sollte, beginnend mit der Planung, welche Kernkompetenzen und zwischenmenschliche Kommunikation ebenso wie wirtschaftliche Rahmenbedingungen und technologische Kapazitäten berücksichtigen sollte. Der Gestaltungs- und insbesondere der Umsetzungsprozess sollte von Vielfalt und Variabilität geprägt – unter dem Motto „so lange wie möglich offenhalten, welche Aufgabenträger bzw. Systeme welchen Job erledigen“. Erst dann haben wir mit unseren Ausführungen die Grundlage geschaffen, die Organisationsverantwortliche benötigen, um mittels der Gestaltung von Strukturen und Prozessen zur Innovationsfähigkeit und wirtschaftlichen Nachhaltigkeit von Unternehmen und Institutionen beizutragen. Die damit verbundenen Abläufe sind insbesondere geprägt von den folgenden Merkmalen: • Lernen, Beteiligten vermehrt Verantwortung zu übertragen, ohne die gemeinsame, wirtschaftlich/technisch wie sozial relevante Zielfindung zu vernachlässigen. • Erfahrbare Modellierung und schließlich praktisch umsetzbare digitale Modelle – sie erhöhen die Sicherheit und Zuverlässigkeit von Ergebnissen in multidimensionalen Transformationsprozessen • Veränderliche Strukturen und anpassbares Verhalten – sie werden als Gegenstand kontinuierlicher, gestalterischer Auseinandersetzung etabliert. • Förderung von Konflikt- und Kommunikationsfähigkeit, und zwar als konstruktive Auseinandersetzung an Verhaltens- und Interaktionsmodellen – diese ermöglichen jene Transparenz von Abläufen, die Resilienz und Innovation begünstigt.

378

10 Resümee

Sobald der Mut zur Veränderung von Verhalten sichtbar wird, lohnt sich weiterer Technologieeinsatz, um schließlich den Blick auf mehrdimensionale Kennzahlensysteme wie die Balanced Scorecard zu richten. Mit Hilfe der durch die Modelle möglichen Transparenz finden Organisations- und die Lernprozesse nachvollziehbaren Niederschlag im Bereich der Finanzen, und erlangen so die erforderliche ökonomische Relevanz.

Stichwortverzeichnis

A Ablauforganisation 6 Ablaufsemantik 320, 329 Abstract Layered PASS 149 Abstract State Machine 60, 155, 156 Active Structure Elements 43 Activity Diagram 87, 303 Actor 65, 221, 276 Adaptive Case Management 10 ADM, siehe Architecture Development Method ADM Guidelines and Techniques 41 Agent 65 Aggregation 64 Agilität 216, 217 Akteur 5, 13 Aktivität 5 Aktivitätsbündel 12, 196 Aktivitätsdiagramm 87, 139, 154, 303 Aktivsatz, 247 Aktor 28, 45, 65, 159, 167, 283, 320 Aktuator 157, 167 ALPS 149 Alternativanweisung 60 Analyse 12, 226 und Modellierung 197 Anmerkung, natürlich-sprachliche 301 Anwendungsbeispiel 336, 351, 359 Application Architecture 41 Application Layer 44 Applikationsarchitektur 6 Arbeiter 27 geeigneter 27 Arbeitsplanung 27

Arbeitsteilung 29 Arbeitsunterstützungssystem 228 ArchiMate 43 Architecture Capability Framework 42 Architecture Content Framework 41 Architecture Development Method 41, 45 Architekturentwicklungsprozess 41 ARIS 46, 137, 154, 305 Artikulation 227 ASM siehe Abstract State Machine Assoziation 63 Attribut 24, 51 Attributklasse 24 Attributtyp 51 Aufbau- und Ablauforganisation 6 Aufbauorganisation 195, 275 Aufgabenträger 325 Aufgabenträgertyp 274 Ausführungsplattform 321 Ausführungssemantik 331 Ausführungssystem 318 Austausch von Modellen 301 Austauschbeziehung 237 Auswahl von Modellierungssprachen 128 Automatisierung 348

B Balanced Scorecard 33, 378 Befähiger 35 Behavior Elements 44 Benutzer 325 Benutzereingabe 321

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 M. Elstermann et al., Ganzheitliche Digitalisierung von Prozessen, https://doi.org/10.1007/978-3-658-41777-2

379

380 Benutzerzentriertheit 216, 217 Berechnungsschritt 61 Beschreibung, natürlich-sprachliche 248 Beschreibungsmodell 19, 340 Betrieb 12, 284 und Monitoring 205 Beziehungstyp 51 BizDevOps 222 BPM siehe Business Process Management BPMN siehe Business Process Model and Notation BPMN-Ausführung 154 BPMS 2 BSC siehe Balanced Scorecard Business Activity Monitoring (BAM) 287 Business Architecture 41 Business Engineering 6 Business Layer 44 Business Model Canvas 30 Business Process Management 2 Business Process Management System 2, 271 Business Process Model and Notation 10, 73, 92, 139, 154, 274, 306 Business-IT-Alignment 222

C CCS 56 Choreografiediagramm 112 COBIT siehe Control Objectives for Information and Related Technology Compare/WP 230 Complex Event Processing (CEP) 287 Concept Mapping 232 Conformance 291 Control Objectives for Information and Related Technology 10, 39 Controlled Functions 61 CPS siehe Cyber Physical System CSP 59 Customer/User Experience Journey 219 Cyber Physical System 10, 157, 159, 161, 283

D Data Architecture 41 Daten 49, 195 Datenmodell 50 Datensicht 46, 53, 141 Datenspezifikation 370

Stichwortverzeichnis Datenstrukturdiagramm 50, 141, 304 Define 213 Deliverable 239 Design Challenge 213 Design Thinking 195, 208 Digital Process Twin siehe Digitaler Zwilling Digital Twin siehe Digitaler Zwilling Digitaler Zwilling 160, 161, 165, 179 Digitalisierung 6, 335, 347–349, 351, 353, 359, 366 Digitalisierungsgrad 347, 349 Discovery 291 divergent 211 Diversität 210 Durchlaufzeit 335–338, 343, 344, 346–349, 371 Durchlaufzeitverkürzung 348 DV-Konzept 47 E EAM siehe Enterprise Architecture Management Eclipse-Entwicklungsumgebung 308 eEPK 53, siehe erweiterte Ereignisgesteuerte Prozesskette, 154 Effektivität 7, 201, 260, 327 Effizienz 7, 201, 260, 327 EFQM siehe European Foundation for Quality Management Einnahmequelle 32 Embedded Systems 280 Empathie 212 Empfänger 28 Empfangsaktion 57, 117 Enabling 222 Enhancement 291 Enterprise Architecture 39 Enterprise Architecture Management 9 Enterprise Continuum 41 Entität 51 Entitätstyp 51 Entity Relationship Model 46, 51, 61 Entity Sets 51 Entscheidung, pragmatische 20 EPK siehe Ereignisgesteuerte Prozesskette Ereignis 1 in BPMN 97 Ereignisgesteuerte Prozesskette 78, 137, 305 erweiterte 53, 84

Stichwortverzeichnis Ereignisklasse 2 Ereignisknoten 52 Erkentnislehre, neopragmatische 20 Erfahrungswissen 227 Erfolgsfaktor, kritischer 33 Erkenntnis 20, 23 Erkenntnisfunktion 23 Erkenntnisinteresse 49 Erlösmodell 32 ERM siehe Entity Relationship Model Ersatzkennzahl 8 Ersetzungsfunktion 24 Erstellungsprozess 372 European Foundation for Quality Management 9, 35 Event Log 176, 286 Exchange Analysis 240 Expert 221 Export 302 Externalisierung 235

F Führungsphilosophie 17 Fachkonzept 47 Facilitator 210, 221, 230 Flowchart siehe Flussdiagramm Flussdiagramm 10, 27, 52, 72, 73, 136, 153, 302 Formular 321 Front End 302 Funktionsknoten 52 Funktionssicht 46, 53

G Geschäftsereignis 2 Geschäftsfall 3, 286 Geschäftsmodell 6, 7, 11, 67 Geschäftsobjekt 120, 310, 315, 321 Geschäftsprozess 1, 5 Geschäftsprozessbeschreibung 5 Geschäftsprozessmanagement 3 Gesellschaft 27 Gesellschaftsphilosophie 25 Gestaltung der Wirklichkeit 23 Governor 221 Gruppe 325 Guarded Command 60

381 H Handarbeit 26 Handelnde 5 Handlung 315 Handlungsfolge 315 Handlungssystem 30 Handlungsträger 202 Heat Map 328 Hierarchie 29 Holomapping 239

I Ideate 213 Impact Analysis 241 Implementierung 47 organisatorische 12, 202, 325 Implementierungstyp 274 Individuum 24 Industrie 4.0 10, 167 Information, strategische 37 Informationsfluss 338, 340, 341, 348, 349, 358 Informationsgegenstand 50 Informationssystem 49 Informationsumwelt 50 Infrastruktur, physikalische 277 Innovation 209 Inputpool 120 Instanz 62, 153, 155 Intangibles 37, 237, 238, 247 Intention 20 interdisziplinär 209, 221 Internet of Things (IoT) 135, 157 IoT siehe Internet of Things IT Infrastructure Library 10, 38, 48 IT-Governance 10 IT-Implementierung 12, 203, 350, 359, 370 IT-Infrastruktur 195, 277 IT-Management 10 ITIL® siehe IT Infrastructure Library

K K-System 21 Künstliche Intelligenz (KI) 135, 169, 173, 176, 377 Kanal 31 Kartenlegetechnik 230 KEF 33

382

Stichwortverzeichnis

Kennzahl siehe Key Performance Indicator Kernprozess 2 Key Performance Indicator 7, 8, 14, 23, 33, 197, 262, 272, 287, 338, 369 KI siehe Künstliche Intelligenz Klasse 24, 62, 141 Klasse-Objekt-Beziehung 62, 141 Klassendiagramm 304 Kollaborationsdiagramm 139 Kommunikationsmodellierung 99, 116 Kommunikationsprotokoll 333 Komponente emotionale 37 physikalische 324 Komposition 64 Konnektor 52, 324 Konstruktion 258 konvergent 211 Konversationsdiagramm 139 Kopfarbeit 26 Kostenstruktur 33 KPI siehe Key Performance Indicator Kreativität 216 Kreativitätstechnik 11 Kundenbeziehung 32 Kundennutzen 31 Kundensegment 31

Mensch 17, 171, 177, 209 Mensch-Maschine-System siehe sozio-technisches System Menschenbild 17, 26 MES siehe Manufacturing Execution System Message Guard 122 Metasonic Touch 309 Methode 62 Minimum Viable Products 220 Modell 20, 23 kybernetisches 21 mentales 4, 227 Modellbegriff 23 Modellbildung 19, 21 Modellierung 12, 226, 349, 358, 367 verteilte 350, 358, 369 Modellierungssprache 71, 135, 255 Modellierungswerkzeug 340 Modellismus 20 Modelltheorie 23 Monitored Functions 61 Monitoring 12, 286 Motivator 22 MS Visio 303 Multiagentensystem 65 multidisziplinär 210 Multiworkflow-System 283

L Lösungsraum 211, 213 Lane 306 LDAP Directory 325 Leistung 195 Leistungsbeziehung 67 Leistungserbringung 5 Leistungslohn 27 Leistungssicht 46 Lernen 228 Low Code 320, 322

N Nebenläufigkeit 58 Nutzungsabsicht 50

M Managementphilosophie 17 Managementprozess 2 Manufacturing Execution System 336, 359 Marke 55

O Objekt 64 Objektorientierung 61, 141, 151 Objekttyp 51 Operation 62 Operator 22 Optimierung 12, 201, 265, 318 Organisationssicht 46, 53 Organisationssoziologie 29, 177 Organisationsstruktur 6, 29 Organisationstheorie 17, 26, 28 Organisationswissen 203 OWL 155, 321

Stichwortverzeichnis P Parallel Activity Specification Schema siehe PASS Parallel-Gateway 316 Parallelität 53, 56 PASS 115, 140, 155, 199, 308 Passive Structure Elements 43 People 209 Persona 213 Perzeptor 22 Physical Layer 45 Place 209 Plan-Do-Check-Act-Kreislauf 12 Planungswissen 37 Point of View 213 Pool 139, 306 PPI siehe Process Performance Indicator Predictive Twin 161 Problemraum 211, 213 Process 209 Process Mining 176, 290 Process Performance Indicator 7, 14, 197, 205, 262, 272, 287, 328 Produktionssynchronisierung 339 Produktivsetzung 202 Programmablaufplan 52 Projektkosten 371 Projektplan 13 Prototype 215 Prozess 66, 195, 209 Prozessakteur 336, 341, 362 Prozessanalyse 340, 358, 359 Prozessarchitektur 6, 136 Prozessausführung 152, 155 direkte 153 indirekte 152 Prozesscockpit 14 Prozessdigitalisierung 6, 152, 218 Prozessdokumentation 270 Prozessdurchlaufzeit 336 Prozessgestaltung 7 Prozessimplementierung 372 Prozessinformationen 338, 340, 360 Prozessinstanz 2, 5, 153, 285, 332 Prozesskennzahl siehe Process Performance Inidicator Prozesslogik 5, 66, 226 Prozessmanagement 1, 22 Prozessmodellierung 65, 71, 135, 255

383 Prozessnetzwerk 135, 333 Prozessrealisierung 5, 67 Prozessschritt 336, 343, 346–348, 350, 351 Prozessstrategie 66 Prozesssytem, komplexes 300 Prozesstransparenz 349 Prozessvalidierung 316

Q Qualität 34 Qualitätsmanagement 9 Qualitätsmanagementsystem 36

R Reference Model 41, 165 Refinements 323 Reflexion 235 Regelkreis 21 Ressource 5 Ressourcenzuordnung 6 Restriktion 259 Rolle 325 Rollenspiel 264, 316 Rundumbewertung 36

S S-BPM siehe Subjektorientiertes Business Process Management SBD siehe Subjektverhaltensdiagramm Schaltoperation 55 Schlüsselaktivität 33 Schlüsselpartner 33 Schlüsselressource 32 Scientific Management 26 Selbstermächtigung 236 Selektion 28 Sendeaktion 57, 117 Sender 28 Sensor 45, 157, 159, 162, 164, 167, 181 Simple Simulation (SiSi) 318 Simulation 201, 265, 318 Simulationsmodell 21 Soziologie 25, 177 Space 216 Speicherformat 329 Speicherstruktur 301, 331

384

Stichwortverzeichnis

Spezialisierung 29 St. Gallener Managementmodell 17 Stakeholder 30 Stand-alone-Anwendung 301 Stelle 55 Steuerungssicht 46, 53 Strategy Layer 44 Subject Behavior Diagram siehe Subjektverhaltensdiagramm Subject Interaction Diagram siehe Subjektinteraktionsdiagramm Subject-oriented Business Process Management siehe Subjektorientiertes Business Process Management Subjekt 49, 50, 116, 251 Subjektinteraktionsdiagramm 116, 141, 165, 175, 199, 311, 341, 352, 359 Subjektorientiertes Business Process Management 64, 73, 115, 140, 141, 155, 157, 159, 165, 217, 274, 283, 340 Subjektorientiertes Geschäftsprozessmanagement siehe Subjektorientiertes Business Process Management Subjektorientierung siehe Subjektorientiertes Business Process Management Subjektverhaltensdiagramm 116, 141, 156, 312, 313, 346, 352 Supportprozess 2 Symbolpalette 303 System arbeitsteiliges 29 parallel kommunizierendes 56 soziales 28 sozio-technisches 3, 16, 38, 177, 320, 325 vernetztes 56 System-Call 323

TOGAF siehe The Open Group Architecture Framework Token 55, 315 Total Quality Management 9, 34 TQM siehe Total Quality Management Transition 55, 116 Transitionsregel 60 Transportsystem, fahrerloses 335

T T-shaped people 210 tangible 37, 237 Tangibles 37, 240, 247 Technology Architecture 41 Technology Layer 44 Test 215 The Open Group Architecture Framework 9, 41, 45 tight coupling 137

W Wahrscheinlichkeitsverteilung 265, 318 Walk Through 263 Wasserfallmodell 331 Web-Anwendung 301 Werkzeug 299 Werkzeuglandschaft 299 Werteversprechen 31 Wertfluss 37 Wertschöpfung 30

U UML siehe Unified Modeling Language Unified Modeling Language 51, 62, 87, 139, 154, 303 Unternehmensarchitektur 6, 11, 272 Unternehmensarchitekturmanagement 9 Unternehmensgrenze 300

V Validierung 12, 201, 261, 315 Value Creation Analysis 243 Value Network Analysis 237 Value Network Map 245 Veränderungsprozess 227 Verbesserungsprojekt 335 Vererbung 63 Verhaltenerweiterung 125 Verhaltensausdruck 57 Verhaltensdiagramm 309 Verhaltensinterface 148 Vertreterregelung 202 Vertriebsweg 31 Virtual Twin siehe Digitaler Zwilling Vision 34 Vorgang, nicht-deterministischer 56

Stichwortverzeichnis Wertschöpfungskettendiagramm 138 Wertstromanalyse 338–340 Wertstrommodell 338, 340 Wirklichkeit 19, 20 Wirklichkeitsabbildung 20 Wissensmanagement 11 Wissensprozess 21 Workflow 204 Workflow Engine 6, 13, 153 Workflow-Management-System 280 WSM siehe Wertstrommodell

385 Z Zeichenfläche 302 Ziel bei der Modellbildung 21 Zielgruppe 31 Zielwert 8 Zuordnung dynamische 276 statische 275 Zuordnungstabelle 275 Zustand, nicht-deterministischer 55 Zustandsmaschine 60