Composable Enterprise: agil, flexibel, innovativ: Gamechanger für Organisation, Digitalisierung und Unternehmenssoftware [4., komplett überarbeitete Auflage] 3658424826, 9783658424824, 9783658424831

Citation preview

August-Wilhelm Scheer

Composable Enterprise: agil, flexibel, innovativ Gamechanger für Organisation, Digitalisierung und Unternehmenssoftware 4. Auflage

Composable Enterprise: agil, flexibel, innovativ

August-Wilhelm Scheer

Composable Enterprise: agil, flexibel, innovativ Gamechanger für Organisation, Digitalisierung und Unternehmenssoftware 4., komplett überarbeitete Auflage Die 1. und 2. Auflage des Werkes sind mit dem Titel „Unternehmung 4.0“ bei AWSi Publishing, AWS-Institut für digitale Produkte und Prozesse gGmbH, Uni Campus Nord, 66123 Saarbrücken erschienen.

August-Wilhelm Scheer IDS Scheer Holding GmbH Saarbrücken, Deutschland

ISBN 978-3-658-42482-4 https://doi.org/10.1007/978-3-658-42483-1

ISBN 978-3-658-42483-1 (eBook)

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020, 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. 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.

Über den Autor

Professor Dr. Dr. h.c. mult. August-Wilhelm Scheer gilt als einer der prägendsten Wissenschaftler und Unternehmer der deutschen Informationstechnik. Die von ihm entwickelte ARIS-Methode zur Enterprise Architecture und Prozessmanagement wird international eingesetzt. Seine Bücher zur Wirtschaftsinformatik haben das Fach wesentlich beeinflusst und sind in mehrere Sprachen übersetzt. Schwerpunkt seiner Forschung liegt im Informations-, Innovations- und Geschäftsprozessmanagement. Darüber hinaus ist Scheer Herausgeber der Fachzeitschrift IM+io. Er ist Gründer mehrerer erfolgreicher IT-Unternehmen. Seit 2010 ist Scheer Alleingesellschafter der IDS Scheer Holding GmbH. Zu dem Unternehmensnetzwerk mit über 1300 Mitarbeitern gehören als größere Unternehmen die Scheer GmbH, die imc AG und die Scheer PAS GmbH. Weiter gehören zu dem Unternehmensnetzwerk Beteiligungen an mehreren Start-Up-Unternehmen. 2014 hat Scheer das gemeinnützige Forschungsinstitut „August-Wilhelm Scheer Institut für digitale Produkte und Prozesse gGmbH (AWSi)“ gegründet. Scheer war über einen Zeitraum von 20 Jahren Mitglied des Aufsichtsrats der SAP AG. Von 2007 bis 2011 war er Präsident des Branchenverbandes Bitkom e. V. Als Unternehmer und Protagonist der IT arbeitete und arbeitet er als unabhängiger Politikberater. Scheer ist zudem versierter und angesehener Jazz-Baritonsaxophonist und fördert Kultur und Wissenschaft mithilfe der von ihm 2001 gegründeten August-Wilhelm Scheer Stiftung für Wissenschaft und Kunst. Er ist Inhaber zahlreicher nationaler und internationaler Ehrungen. 2017 wurde Scheer in die Hall of Fame der Deutschen Forschung aufgenommen. Seine Interpretation des Composable Enterprises ist seine Vision zur Gestaltung zukunftsorientierter digitalisierter Unternehmen, die er auch in den eigenen Unternehmen umsetzt.

V

Vorwort zur vierten, wesentlich neu gestalteten Auflage

Die vierte Auflage dieses Buches hat mit „Composable Enterprise“ einen neuen Titel gegenüber dem vorherigen Titel „Unternehmung 4.0“ bekommen. Der Zusatz 4.0 als Kennzeichen einer Digitalisierung wird inzwischen in vielen Zusammenhängen inflationär verwendet. Digitalisierung ist kein Selbstzweck. Erst wenn die Digitalisierung einen konkreten Nutzen nachweist, ist sie erfolgreich. Dazu wird in dieser Auflage dem von der Gartner Group eingeführten Begriff „Composable Enterprise“ als Ziel einer Digitalisierungsstrategie gefolgt. Ein Composable Enterprise ist fähig, durch Anwendung moderner Informationstechnik sein Businessmodell und seine Businessprozesse aus Komponenten flexibel zusammenzusetzen und dabei doch ganzheitlich zu arbeiten. Dadurch kann das Unternehmen schnell auf neue Situationen reagieren, neue Prozesse einführen oder austauschen. So kann es neue Produkte, Dienstleistungen, Partner, Lieferanten usw. schnell wechseln oder neue hinzufügen. Composable ist damit der Gegensatz zu monolithisch, das für starr und unflexibel steht. Der Begriff reicht von der Strategieebene bis zur Implementierung der Anwendungssysteme. Das Unternehmen ist deshalb von der Geschäftsstrategie bis zu den IT-Systemen „composable“. Das Konzept „Composable Enterprise“ spricht wichtige Anforderungen an ein modernes Unternehmen an und ist deshalb ein wertvoller Kompass für dessen IT-Entwicklung. Die zentralen Komponenten der Informationssysteme des Composable Enterprise sind die Plattformarchitektur mit der losen Kopplung von kleinen, weitgehend autonomen Softwareeinheiten, den „Packed Business Capabilities“. Diese Komponenten bilden gegenüber zentralen, monolithischen und starr integrierten Systemen ein neues Paradigma für die Anwendungsentwicklung. Grundgedanken einer Plattformarchitektur werden an praxisnahen Systemen und Anwendungsfällen erörtert. Als Demonstrationsobjekt wird mit der „Application Composition Platform“ ein konkretes System verwendet, das in über 10 Jahren von den Unternehmen des Verfassers entwickelt wurde und von dem Unternehmen Scheer PAS weiterentwickelt und vertrieben wird. Die über 10-jährige Entwicklungszeit bestätigt die Erfahrung des Verfassers, dass wirksame Innovationen eine lange Forschungs- und Vorlaufzeit benötigen. VII

VIII

Vorwort zur vierten, wesentlich neu gestalteten Auflage

Das Konzept des Composable Enterprise wird in ein Lifecycle-Modell eingebunden, das die Eigenschaft „composable“ in allen Stationen von der Innovationsentwicklung über die Prozess- und Enterprise-Architektur, die Plattformarchitektur, die Anwendungsentwicklung, die Prozessausführung, das Process Mining bis zur kontinuierlichen Verbesserung betont. Diese Stationen des Lifecycles bestimmen die Gliederung der Kap. 1–8. Die Ausführungen zu Innovation sind auf die Kap. 2 und 9 verteilt. In Kap. 2 werden einige auf den Lifecycle bezogene Ausführungen dazu gemacht. Da Innovationstreiber die Quelle für neue unternehmerische Ideen sind und das Composable Enterprise das Mittel für ihre erfolgreiche Umsetzung ist, werden die Innovationstreiber gegenüber den vorherigen Auflagen ausführlicher in Kap. 9 behandelt. Die Branchenkonzepte sind überarbeitet und auf das Konzept Composable Enterprise ausgerichtet worden. Sie sind an das Ende des Buches als 10. Kapitel gestellt. Dadurch bilden sie zusammenfassende Illustrationen der vorherigen Kapitel. Nicht alle Ausführungen des Buches haben den gleichen Detaillierungsgrad. Neuere Entwicklungen werden intensiver behandelt als gängige Themen, deren Bekanntheit vorausgesetzt werden kann. Leser, die weniger an den Details interessiert sind, sondern mehr an dem „roten Faden“ des Buches, können detaillierte Passagen überspringen, ohne den Faden zu verlieren. Diese sind durch kursive Schrift gekennzeichnet und beziehen sich insbesondere auf Texte zu Abbildungen und Beispielen. Jedem Kapitel ist zur Orientierung eine Zusammenfassung vorangestellt. Die Begriffswelt in der IT ist durch die englisch-amerikanische Sprache geprägt. Deshalb werden viele englische Begriffe eingesetzt, insbesondere, wenn sie im Zusammenhang mit anderen englischsprachigen Begriffen stehen. Gleichzeitig wird auch die deutschsprachige Version verwendet, wenn dieses im Zusammenhang sinnvoll ist. Dieses führt manchmal zu etwas gemischten Sprachkonstruktionen. Männliche und weibliche Formen von Begriffen werden so verwendet, wie es dem normalen Sprachgebrauch entspricht und dem Lesefluss dient. Eine gesellschaftspolitische Aussage ist damit nicht verbunden. In meinen Veröffentlichungen versuche ich, wissenschaftliche Erkenntnisse mit unternehmerischen Anwendungserfahrungen aus Beratungsprojekten und Produktentwicklungen zu verbinden. Gerade als Softwareunternehmer muss ich bei strategischen Entwicklungsentscheidungen Zukunftsentwicklungen hinsichtlich ihrer Bedeutung abschätzen, ohne mich von kurzfristigen Hypes lenken zu lassen. In die Darstellungen fließen deshalb auch Bewertungen von Technologien ein, so dass der Leser an unternehmerischen Überlegungen und Entscheidungen teilnimmt.

Vorwort zur vierten, wesentlich neu gestalteten Auflage

IX

Danksagungen Für intensive Gespräche zu dem Thema der Application Composition Platform danke ich Dr. Wolfram Jost, Chief Technology Officer (CTO) der IDS Scheer Holding GmbH. Er hat die Architektur der Plattform maßgeblich gestaltet und ist für mich immer ein wichtiger und kritischer Diskussionspartner. Robert Mueller, CEO der Scheer PAS GmbH und Jürgen Rombach, Geschäftsführer der Scheer PAS GmbH sowie allen an der PAS-Entwicklung beteiligten Softwareingenieuren danke ich für Anregungen zu diesem Buch, die sie mir durch ihre Arbeit gegeben haben. Weiter danke ich für Unterstützungen Dr. Dirk Werth, Tobias Greff, Dr. Christian Linn, Dr. Andreas Kronz und Dr. Olaf Homburg. Mario Baldi, CEO der Scheer GmbH, Christian Wachter, CEO der imc AG, Sven Becker, Vorstand der imc AG sowie allen Mitarbeiterinnen und Mitarbeitern der Unternehmungen des Scheer Netzwerkes danke ich für ihren großen Einsatz, Ideen erfolgreich in Produkte und am Markt umzusetzen. Besonders danke ich Sandra Ehlen für das sorgfältige Anfertigen der Abbildungen, die Organisation des Verlagsprozesses und ihre freundliche Geduld. Lucie Bender und Vera Chase danke ich für das umsichtige Korrekturlesen. Bei Rosemarie Clarner, Geschäftsführerin der Scheer Unternehmen, bedanke ich mich für die 25-jährige vertrauensvolle Zusammenarbeit und für die stetige Motivation. Saarbrücken Juni 2023

August-Wilhelm Scheer

Aus dem Vorwort zur ersten bis dritten Auflage

Im Jahre 1983 wurde der PC von dem TIME MAGAZIN als „Maschine des Jahres“ ausgezeichnet, obwohl normalerweise nur wichtige Menschen benannt werden. Damit wollte man bereits zu diesem Zeitpunkt die hohe Bedeutung des Computers herausstellen. Seitdem sind rund 20 Moore’sche Zyklen über die Entwicklung der Informationstechnik hinweggegangen, bei denen sich die Leistungsfähigkeit jeweils verdoppelte. Damit hat sich die Leistungsfähigkeit um das Millionenfache erhöht. Deshalb schlägt nun Quantität in Qualität um; es entstehen Möglichkeiten zur Entwicklung neuer Produkte und Prozesse, die vor wenigen Jahren noch undenkbar waren. Schlagwörter wie „Industrie 4.0“ oder „Software is eating the world“ (Andreessen 2011) sowie die Diskussion der künstlichen Intelligenz belegen die hohen Erwartungen, die von Wissenschaftlern und praktischen Experten an die Veränderungskraft der Digitalisierung gerichtet sind. Viele Veränderungen im privaten Bereich sind durch Social Media und Internet offensichtlich.

Abb. 1 Time Magazin 1983 und Moore’sche Zyklen. (Quelle: Time, USA LLC. 1983)

XI

XII

Aus dem Vorwort zur ersten bis dritten Auflage

In diesem Buch werden digitale Veränderungen von Unternehmen behandelt. Sie zeigen den tiefgreifenden Einfluss auf Strukturen und sollen den Leser zur Entwicklung von Konzepten seines eigenen Unternehmens inspirieren. Im Vordergrund steht die Betrachtung und Bewertung organisatorischer Auswirkungen der Digitalisierung, sodass technische Aspekte nur so tief behandelt werden, wie es zum Verständnis des Veränderungsprozesses erforderlich ist. Saarbrücken, Juli 2017 Literatur Einleitung Andreessen, M. (20. August 2011). Why Software is eating the world. The Wall Street Journal.

Inhaltsverzeichnis

1

2

Das Composable Enterprise als neues Paradigma . . . . . . . . . . . . . 1.1 Gründe für einen Paradigmenwechsel . . . . . . . . . . . . . . . . . . 1.1.1 Anforderungen an Agilität, Flexibilität, Innovationsfreude 1.1.2 Der Begriff Composable Enterprise . . . . . . . . . . . . . . 1.1.3 Wesentliche Komponenten der Informationssysteme des Composable Enterprise . . . . . . . . . . . . . . . . . . . 1.2 Organisationsstrukturen des „Composable Enterprise“ . . . . . . . . 1.2.1 Organisationsstrukturen . . . . . . . . . . . . . . . . . . . . . 1.2.2 Umsetzung der Organisationsstruktur in die Anwendungsarchitektur . . . . . . . . . . . . . . . . . . . . . 1.3 Der Composable Enterprise Lifecycle . . . . . . . . . . . . . . . . . . 1.3.1 Phase 1: Unternehmensanalyse . . . . . . . . . . . . . . . . . 1.3.2 Phase 2: Innovationsprozess . . . . . . . . . . . . . . . . . . . 1.3.3 Phase 3: Composable Process und Enterprise Architecture 1.3.4 Phase 4: Application Composition Platform . . . . . . . . . 1.3.5 Phase 5: Development und Implementation . . . . . . . . . 1.3.6 Phase 6: Execution und Case Management . . . . . . . . . . 1.3.7 Phase 7: Insight durch Mining . . . . . . . . . . . . . . . . . 1.3.8 Phase 8: Actions/Verbesserungen . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

11 15 15 15 17 18 20 21 22 22 23

Innovationsfreude als Merkmal des Composable Enterprise 2.1 Planung von Innovationen . . . . . . . . . . . . . . . . . . . 2.2 Geschäftsmodellinnovationen . . . . . . . . . . . . . . . . . 2.3 Innovator’s Dilemma vermeiden . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

25 26 27 30 30

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

1 2 3 4

.. .. ..

4 7 7

XIII

XIV

3

4

5

Inhaltsverzeichnis

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling im Metaverse . . . . . . . . . . . . . . . . . . . . . 3.1 Geschäftsprozessmodellierung . . . . . . . . . . . . . . . . . . . . . 3.2 Entwicklung Soll-Prozessmodell und Business Capabilities . . . 3.2.1 Soll-Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Fachliche Business Capabilities . . . . . . . . . . . . . . . 3.3 Enterprise-Architecture (EA) zur Beherrschung der Komplexität von Unternehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Wege zur automatisierten Enterprise Architecture . . . . . . . . . . 3.5 Erweiterung zu einem dynamischen automatisierten EA-System . 3.6 Digitaler Unternehmenszwilling im Metaverse . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Composition Platform Architecture . . . . . . . . . . . . . 4.1 Kennzeichnung der Plattform . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Der Integrationsanspruch der Application Composition Platform (ACP) . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Aufbau der Application Composition Platform und Anwendungsumgebung . . . . . . . . . . . . . . . . . . . . 4.2 Prozessautomation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Kennzeichnung der Prozessautomation . . . . . . . . . . . 4.2.2 Beispiele zur Prozessautomation . . . . . . . . . . . . . . . 4.3 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 API und API-Management . . . . . . . . . . . . . . . . . . 4.3.3 Monitoring des Integrationsprozesses . . . . . . . . . . . . 4.3.4 Anwendungsfall Integration . . . . . . . . . . . . . . . . . . 4.4 Low-Code Development . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Lösung für den Digitalisierungsstau . . . . . . . . . . . . . 4.4.2 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Typische Low-Code-Anwendungen und Erweiterungen . 4.4.4 Anwendungsfall Low-Code . . . . . . . . . . . . . . . . . . 4.5 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

31 32 37 37 39

. . . . .

. . . . .

. . . . .

40 42 44 46 51

... ...

53 54

...

54

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

57 60 60 62 63 64 65 70 71 74 74 75 78 79 80 83

Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Entwicklung der Packed Business Capabilities . . . . . . . . . . . . . . 5.2 Modellgestütztes Customizing von Standard-Unternehmenssoftware 5.3 Projektsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Schulung der Anwender . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

85 86 89 91 91

Inhaltsverzeichnis

XV

6

Execution und Operational Performance Support (Case Management) 6.1 Vom Soll-Prozessmodell zu Prozessinstanzen . . . . . . . . . . . . . . 6.2 Prozessplanung und -steuerung . . . . . . . . . . . . . . . . . . . . . . . 6.3 Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Complex Event Processing (CEP) . . . . . . . . . . . . . . . . . . . . . 6.5 Predictive Performance Support . . . . . . . . . . . . . . . . . . . . . . . 6.6 Real-Time-Lernhilfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Insight durch Process Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Mining auf der Basis von Logdateien . . . . . . . . . . . . . . . . . . . . 7.1.1 Aufbau der Logdatei . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Auswertungen der Logdatei . . . . . . . . . . . . . . . . . . . . . 7.1.3 Generierung des Ist-Modells . . . . . . . . . . . . . . . . . . . . 7.1.4 Vergleich Logdatei mit Prozessmodell . . . . . . . . . . . . . . 7.1.5 Vergleich generiertes Ist- mit Soll-Modell und Enhancement . 7.2 Task Mining und Desktop Activity Mining . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 108 110 111 112 114 116 118 121

8

Von Insight to Action: Robotic Process Automation . . . . . . . . 8.1 Organisatorische Verbesserungen . . . . . . . . . . . . . . . . . 8.2 Anpassung des Produktionsprogramms durch Kombination von Process und Product Mining . . . . . . . . . . . . . . . . . 8.3 Robotic Process Automation (RPA) . . . . . . . . . . . . . . . 8.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Anwendungsbeispiele und -gebiete . . . . . . . . . . 8.3.3 Intelligentes oder kognitives RPA . . . . . . . . . . . 8.3.4 Einbettung von RPA in das Composable Enterprise Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

125 127 127 130 133 135 136

Innovationstreiber für das Composable Enterprise . . . . . . . 9.1 Wirtschaftliche Innovationstreiber . . . . . . . . . . . . . . . 9.1.1 Personalisierung/Individualisierung . . . . . . . . . 9.1.2 Selbststeuerung . . . . . . . . . . . . . . . . . . . . . 9.1.3 Grenzkostenarme Produkte und Dienstleistungen . 9.1.4 Smart Services . . . . . . . . . . . . . . . . . . . . . . 9.1.5 Community-/Schwarm-Effekt . . . . . . . . . . . . . 9.1.6 Lean Organization und exponentielles Wachstum . 9.1.7 Plattformunternehmen . . . . . . . . . . . . . . . . . 9.2 Informationstechnische Innovationstreiber . . . . . . . . . . 9.2.1 Künstliche Intelligenz . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

139 140 140 142 143 144 146 146 147 151 151

9

. . . . . . . . . . .

. 93 . 94 . 96 . 97 . 98 . 100 . 103 . 106

. . . . . . 123 . . . . . . 124

XVI

Inhaltsverzeichnis

9.2.2

Blockchain-basierte Innovationen (von der BlockchainArchitektur zum Web3) . . . . . . . . . . . . . . . . . . . . 9.2.3 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Gesellschaftliche und politische Innovationstreiber . . . . . . . . . 9.3.1 New Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Bewältigung des Klimawandels . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Digitale Branchenkonzepte für das Composable Enterprise . . . . . . 10.1 Die composable Industrieunternehmung . . . . . . . . . . . . . . . . 10.1.1 Verbindungen zwischen der composable Industrieunternehmung und Industrie 4.0 . . . . . . . . . . 10.1.2 Architektur der composable Industrieunternehmung (Y-Modell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 Fabriksteuerung („Smart Factory“) . . . . . . . . . . . . . 10.1.4 Product Lifecycle Management (PLM) . . . . . . . . . . . 10.1.5 Smart Logistic . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.6 CATENA-X und MANUFACTURING-X: Strategische Zukunftsprojekte für die Industrie . . . . . . . . . . . . . . 10.1.7 Vorgehensweisen zur Einführung des composable Industrieunternehmens . . . . . . . . . . . . . . . . . . . . . 10.1.8 Roadmap zur composable Industrieunternehmung . . . . 10.2 Das Composable-Consulting-Unternehmen . . . . . . . . . . . . . . 10.2.1 Personalisierung/Individualisierung . . . . . . . . . . . . . 10.2.2 Selbststeuerung . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 Grenzkostenlose Dienstleistungen . . . . . . . . . . . . . . 10.2.4 Smart Services . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.5 Community-/Schwarm-Effekt . . . . . . . . . . . . . . . . . 10.2.6 Lean Organization und exponentielles Wachstum . . . . . 10.2.7 Künstliche Intelligenz . . . . . . . . . . . . . . . . . . . . . 10.2.8 Consulting-Plattformunternehmen . . . . . . . . . . . . . . 10.2.9 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.10 New-Work-Konzepte . . . . . . . . . . . . . . . . . . . . . . 10.3 Die composable Hochschule . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Studierendenzentrierte Anwendungen . . . . . . . . . . . . 10.3.2 Forschung in der composable Universität . . . . . . . . . . 10.3.3 Zentrale Dienste als Shared Services in der composable Hochschule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.4 Strategieentwicklung für die composable Hochschule . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

156 163 168 168 169 170

. . . 173 . . . 174 . . . 174 . . . .

. . . .

. . . .

176 184 187 189

. . . 193 . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

194 200 202 206 207 207 208 208 209 209 210 212 213 213 217 227

. . . 234 . . . 235 . . . 236

Literatur (Gesamt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

1

Das Composable Enterprise als neues Paradigma

Zusammenfassung Der Begriff Composable Enterprise ist von der Analysten-Organisation Gartner eingeführt worden und bezeichnet ein Unternehmen, das aufgrund seiner Informationssysteme agil, flexibel und innovationsfreudig ist. Die Komponenten des Informationssystems wie Packaged Business Capabilities und Application Composition Platform, die den Paradigmenwechsel von einer monolithischen Architektur zu der des Composable Enterprise begründen, werden vorgestellt. Gleichzeitig wird das Erfordernis für eine dezentral-prozessorientierte Organisationsstruktur begründet. In dem grafischen Lifecycle-Konzept der Abb. 1.11 wird der Innovationsprozess des Composable Enterprises mit den Stufen Innovationsidee, Prozessdefinition, Plattformarchitektur, Entwicklung, Ausführung, Prozessanalyse bis zur Prozessverbesserung beschrieben. Die 8 Stufen bilden den Leitgedanken für die Kap. 1–8 des Buches. Die grafische Darstellung des Lifecycles der Abb. 1.11 mit seiner Beschreibung sind gleichzeitig eine Kurzfassung dieser 8 Kapitel. Die in der Abb. 1.11 verwendeten grafischen Darstellungen der einzelnen Phasen werden bei den Zusammenfassungen jedes Kapitels zur Orientierung wiederholt. Die Abb. 1.1 demonstriert die erste Phase des Lifecycles als Unternehmensanalyse und gleichzeitig den Inhalt dieses ersten Kapitels.

Abb. 1.1 Unternehmensanalyse. (Quelle: Adobe Stock, PureSolution) © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_1

1

2

1

Das Composable Enterprise als neues Paradigma

1.1 Gründe für einen Paradigmenwechsel Die Situation der Informationsverarbeitung vieler Unternehmen kann durch folgende Eigenschaften beschrieben werden:  Um einer stärkeren organisatorischen Zentralisierung nachzukommen, sind monolithische zentrale ERP-Systeme im Einsatz, die möglichst einheitlich für alle Unternehmensgliederungen eingesetzt werden.  Spezialanwendungen werden notdürftig durch komplexe Punkt zu Punkt-Verbindungen mit den ERP-Anwendungen integriert.  Die Unternehmenssoftware ist schwerfällig und für Entwicklungen neuer Anforderungen und innovativer Anwendungen nicht aufgeschlossen.  Der IT-Fachkräftemangel begrenzt dringend erforderliche Erweiterungen.  Die IT-Architektur ist häufig nicht transparent; es fehlen aktuelle Dokumentationen.  An Altsysteme, die mit Programmiersprachen wie Cobol entwickelt wurden, traut man sich wegen fehlender Dokumentationen und fehlendem technischen Wissen kaum mehr heran, um notwendige Änderungen vorzunehmen.  Von Softwareanbietern erzwungene Umstellungen auf neue Infrastrukturen wie Datenbanken oder Cloud binden erhebliche Ressourcen.  Die IT wird eher zur Bremse als zum Treiber einer strategischen Weiterentwicklung des Unternehmens. Chancen durch Einsatz von Techniken wie KI oder Blockchain für neue Geschäftsmodelle und Geschäftsprozesse können aus Kapazitäts- und Kompetenzgründen nicht genutzt werden. Diese Situation trifft auf die Herausforderungen an Unternehmungen durch Pandemie, Krieg in Europa, Lieferengpässe, Energiekrise, Umweltschutz, Klimawandel, neue staatliche Vorschriften usw., die eine schnelle Anpassung von Unternehmen an geänderte Situationen erfordern. Gleichzeitig entstehen neue Unternehmen, die, ohne Rücksicht auf gewachsene Strukturen nehmen zu müssen, die Vorteile neuer Informationstechniken für digitale Geschäftsmodelle nutzen und bestehende Unternehmen bedrohen. Um sich aus diesen Engpässen zu befreien, genügt es nicht, einzelne Reparaturen auszuführen, sondern es bedarf einer Strategie, die beschreibt, auf welches Ziel sich das Unternehmen mit seiner Informationsverarbeitung entwickeln soll. Anschließend erfordert es eine praktikable Umsetzung durch Kenntnis der technischen Möglichkeiten und durch eine starke unternehmerische Führung. Es bestehen zahlreiche strategische Konzepte zur Ausrichtung von Unternehmen. Die sie kennzeichnenden Attribute reichen von modular, lean, fraktal, virtuell bis zu dem Zusatz „4.0“. Die Konzepte richten dabei jeweils ihr Vergrößerungsglas auf eine vermeintlich neu entdeckte oder besonders wichtige Herausforderung und stellen sie in den Mittelpunkt.

1.1

Gründe für einen Paradigmenwechsel

3

Bei der „Unternehmung 4.0“ war in den vorhergehenden Auflagen die generelle Betonung der Digitalisierung das Leitmotiv. Es wurden Einflüsse der Informationstechnik auf neue Businessmodelle untersucht und neue Techniken zur Automatisierung von Geschäftsprozessen vorgestellt. Dabei fehlte aber eine klare Definition des Zielsystems, auf die alle Maßnahmen ausgerichtet werden sollen. Denn Digitalisierung ist kein Selbstzweck, sondern muss ihren Nutzen nachweisen. Ein Digitalisierungsprojekt, bei dem lediglich die bestehenden Geschäftsprozesse eins zu eins in eine neue Technologie überführt werden, z. B. von einem Inhouse-System in eine Public Cloud Lösung, endet sonst häufig mit dem Ergebnis: „Projekt in Time, in Budget, in Quality beendet – aber NO Benefit für das Unternehmen“. Dieser Situation muss sich die Digitalisierungsstrategie im Unternehmen stellen und ihren Beitrag zur Unternehmenstransformation leisten. Dieses erfordert einen Paradigmenwechsel für Ziel, Architektur und Anwendungen der Informationsverarbeitung.

1.1.1 Anforderungen an Agilität, Flexibilität, Innovationsfreude Der Nutzen der Digitalisierung liegt nicht allein in dem Einsatz einer neuen Technik, sondern in organisatorischen Änderungen und neuen Geschäftsmodellen, die von ihr inspiriert werden und sich in Kostenreduktionen und/oder Umsatzsteigungen auszahlen. Diese monetären Effekte beruhen auf Eigenschaften, die ein Unternehmen befähigen, schnell neue Geschäftsprozesse und Geschäftsmodelle zu entwickeln und umzusetzen. Solche Eigenschaften sind vor allem Agilität, Flexibilität sowie Innovationsfreude. Ihre Forderung ist nicht neu, sie bekommt aber eine zunehmende Bedeutung im Wettbewerb. Agilität bezeichnet die Eigenschaft, rege zu sein, neue Wege frei von Angst zu beschreiten und ist damit eine aktive, suchende Vorgehensweise, die auch als Discovery bezeichnet wird. Flexibilität bezeichnet eine anpassungsfähige, also schnell adaptierende und reagierende Haltung. Beide Eigenschaften sind erforderlich, um innovationsfreudig zu sein, also offen und suchend nach neuen Ideen zu sein und sie umsetzen zu wollen. Dazu muss das Unternehmen wenig komplex sein, da Komplexität den genannten Eigenschaften entgegensteht. Monolithische Unternehmen mit einer Vielzahl ineinander verwobenen Untergliederungen und Prozessen unter zentraler Führung sind komplex. Dezentrale, unternehmerisch und autonom arbeitende modulare Einheiten mit lockerer Kopplung unterstützen dagegen die Anforderungen an Einfachheit. Der häufig verwendete Begriff Resilienz, der die Widerstandsfähigkeit gegenüber Angriffen von außen zum Ausdruck bringt, fügt eine weitere Eigenschaft hinzu.

4

1

Das Composable Enterprise als neues Paradigma

1.1.2 Der Begriff Composable Enterprise Das Konzept des „Composable Enterprise“ erfüllt die Forderungen nach Agilität, Flexibilität, Innovationsfreudigkeit, geringer Komplexität und Resilienz. Die Eigenschaft „composable“ wird am besten mit „zusammensetzbar“, „montierbar“, „kombinierbar“ oder eben „komponierbar“ übersetzt. Der Begriff Composable Enterprise wurde zuerst von der internationalen Analystenorganisation Gartner um das Jahr 2020 in mehreren Forschungsbeiträgen eingebracht und erfreut sich zunehmender Beachtung auch in der Praxis. Die Gartner Group definiert das Composable Enterprise wie folgt: „A composable enterprise is an organization that can innovate and adapt to changing business needs through the assembly and combination of packaged business capabilities“ (Gartner, 2021).

Dieser Definition wird sich im Folgenden weitgehend angeschlossen.

1.1.3 Wesentliche Komponenten der Informationssysteme des Composable Enterprise Zur Umsetzung der Eigenschaften des Composable Enterprise dienen vornehmlich seine Informationssysteme. Deren Architektur wird von Gartner durch die Abb. 1.2 beschrieben. Innerhalb des großen Fünfecks wird die technische Architektur für die Anwendungsinhalte angedeutet. Die Begriffe am Außenkranz bezeichnen die Sicht des Anwenders auf die Systeme und die Unternehmensumgebung. Obwohl die Abbildung auf den ersten Blick einfach aussieht, enthält sie wesentliche Aussagen, die Anregungen für die weiteren Ausführungen dieses Buches geben. Dieses

Abb. 1.2 Composable Business Architecture. (Quelle: Gaughan et al. 2020, S. 4)

1.1

Gründe für einen Paradigmenwechsel

5

gilt insbesondere für die Einführung der Definition von Packaged Business Capabilities (PBCs) und die Betonung der Bedeutung einer Plattformarchitektur. Das Business Ecosystem beschreibt das wirtschaftliche Umfeld des Unternehmens, das Anforderungen an Flexibilität und Agilität bestimmt, aber auch Chancen für Innovationen des Unternehmens bietet. Mit der umfassenden Ausgestaltung der Grundidee des Composable Enterprise wird in dieser Arbeit aber gegenüber dem Gartner Modell ein eigenständiger Weg verfolgt.

1.1.3.1 Packaged Business Capability (PBC) Innerhalb des großen Fünfecks der Abb. 1.2 sind die Business Capability (PBC) als Sechsecke dargestellt. Eine PBC ist eine in sich geschlossene (betriebswirtschaftliche) Anwendungsfunktion oder Geschäftsprozesseinheit, die aus feineren Anwendungseinheiten oder Services zusammengefügt (packaged) ist. Damit wird einem Modulierungskonzept für Anwendungen gefolgt. Die bisher veröffentlichen Ausführungen in der Literatur von Gartner lassen noch Spielraum für Interpretationen der PBCs. Trotzdem können einige Eigenschaften festgehalten werden. Eine PBC ist demnach eine gekapselte (autarke) Softwarekomponente mit ihren internen Services. Ein Service ist in Abb. 1.2 als Kreis mit Verbindungen zu den anderen Services der PBC dargestellt. Die Verbindungen werden durch den internen Prozess, genauer durch dessen Kontrollstruktur, begründet. PBCs können zu komplexeren PBCs zusammengesetzt werden. Die PBCs werden zu Anwendungen (Business Applications) komponiert oder orchestriert. Die Verbindungen zwischen den PBCs werden inhaltlich über die Kontrollflüsse der Geschäftsprozesse definiert und durch die benötigten Daten und Dienste spezifiziert. Die technische Integration wird über Schnittstellen wie APIs (Application Program Interface) oder Ereignissteuerung (Events) geregelt. Bei der Anwendung von APIs stellt eine PBC einen (Software-)Dienst bereit, über den eine andere PBC auf Daten und Funktionen des PBC zugreifen kann. Bei einer Ereignissteuerung (Event Driven Architecture EDA) meldet eine PBC Ereignisse, z. B. die Ankunft eines neuen Kundenauftrags in einem elektronischen Briefkasten, und die die Aufträge weiterverarbeitenden PBCs reagieren darauf. Beide Verfahren führen zu einer losen Kopplung der PBCs und damit zu einer höheren Flexibilität, da PBCs unabhängig voneinander weiterentwickelt, ausgetauscht oder angekoppelt werden können. 1.1.3.2 Application Composition Platform Die von Gartner in Abb. 1.2 bezeichnete „Digital Business Technology Platform“ wird in dieser Arbeit mit dem Begriff „Application Composition Platform“ belegt. Damit wird einerseits der grundsätzliche Bezug zum Gartner-Modell angedeutet, andererseits die eigenständige Interpretation und Ausgestaltung betont. Die Application Composition Platform ist ein Herzstück der Architektur des Composable Enterprise. Hier soll zunächst mit der Abb. 1.3 ein erster Eindruck von ihrer

6

1

Das Composable Enterprise als neues Paradigma

Abb. 1.3 Application Composition Platform. (Quelle: Adobe Stock, PureSolution)

Funktionalität vermittelt werden. Die Architektur wird im Kap. 4 ausführlich entwickelt und vertieft. Die Plattform enthält die Tools, mit denen die Business Capabilities entwickelt werden und ist damit die Umgebung des Entwicklers. Sie unterstützt, dass das Composable Enterprise in hohem Maße Anwendungssoftware selbst entwickelt, um innovative Ideen, für die keine Standardlösungen bereitstehen, umsetzen zu können. Auf der Plattform werden anschließend die einzelnen Business Capabilities zu Anwendungen komponiert oder montiert. Gleichzeitig werden sie auch mit vorhandenen Altsystemen, z. B. ERP-Systemen, und dem Business Ecosystem aus Systemen von Kunden, Lieferanten und Partnern verbunden. Die Plattform führt die Software auf einer Cloud-Infrastruktur aus. Neue Anwendungen werden in einer Cloud-Umgebung entwickelt und ausgeführt. Die Clouddienste werden über das Internet, mobil und IoT bereitgestellt. Mit Experience werden die Erfahrungen und das Erleben des Benutzers mit dem Anwendungssystem bezeichnet. Diese Schnittstelle betrifft insbesondere das User Interface eines Systems. Es bestimmt, ob es ihn motiviert, mit der Anwendung zu arbeiten oder ihn eher abschreckt. Erfahrungsgemäß ändern sich die Anforderungen für das Interface häufig, so dass Mitarbeiter der Fachabteilung diese selbstständig anpassen möchten. Zur Entwicklung der Experience stellt die Plattform Low-Code-Entwicklungswerkzeuge bereit, die auch für Mitarbeiter der Fachabteilung geeignet sind.

1.2

Organisationsstrukturen des „Composable Enterprise“

7

Zur Entwicklung der PBCs und ihre Komposition zu Anwendungen wird das Prozesswissen benötigt, das in Form von Prozessmodellen bereitgestellt wird.

1.2 Organisationsstrukturen des „Composable Enterprise“ Das Composable Enterprise ist ein Konzept, mit dem die Aufgaben einer Unternehmung möglichst einfach und schnell auf allen Ebenen aus modularen unternehmerischen Fähigkeiten zusammengesetzt, verbessert und innoviert werden können. Es reicht von der Unternehmensstrategie über die organisatorische Gestaltung bis zur IT-Ausführung. Bei den Darstellungen von Gartner werden lediglich allgemeine Ratschläge zur Entwicklung einer Unternehmensstrategie für das Composable Enterprise gegeben. Von diesen wird in einem großen inhaltlichen Schritt zur Informationstechnik gewechselt. Hinweise auf konkrete organisatorische Strukturen des composable Unternehmens fehlen aber bisher. Ein neues Informationssystem nutzt aber wenig, wenn es nicht zur Organisationsstruktur passt. Bei einer starren Unternehmensstruktur gehen dann Agilität und Flexibilität des Informationssystems durch Diskussionen über Zuständigkeiten und Abstimmungsrunden zwischen verschiedenen Organisationseinheiten verloren. Deshalb ist der Zusammenhang zur zweckmäßigen organisatorischen Strukturierung des Composable Enterprise wesentlich. Kenntnisse über organisatorische Kriterien und Begründungen liefern dem für die Informationssysteme zuständigen CIO (Chief Information Officer) in strategischen Diskussionen überzeugende Argumente für das Composable Enterprise.

1.2.1 Organisationsstrukturen Grundsätze der betriebswirtschaftlichen Organisationslehre sind bei der Gestaltung des Composable Enterprise hilfreich. Dabei sind die organisatorischen Gegensatzpaare „funktional gegenüber objektorientiert“, „zentral gegenüber dezentral“ und „Ressourcenoptimierung gegenüber Prozessoptimierung“ von Bedeutung. Für eine konkrete Organisationsstruktur müssen Vor- und Nachteile dieser Gestaltungsalternativen gegeneinander abgewogen werden. Eine generell „beste“ Organisationsstruktur für Unternehmen gibt es nicht, weil die Gewichtung der Vor- und Nachteile von der Zielsetzung und Situation des Unternehmens abhängt. Da die Zielsetzung des Composable Enterprise mit den Eigenschaften agil, flexibel und innovativ beschrieben ist, können daraus Tendenzen für die passende Organisationsstruktur abgeleitet werden. Im Folgenden werden einige Beispiele für Organisationsstrukturen angeführt und eine Tendenz für das Composable Enterprise gegeben.

8

1

Das Composable Enterprise als neues Paradigma

Bei einer funktionalen Organisation richtet sich die Aufbauorganisation an den Kernfunktionen des Unternehmens aus, bei einer objektbezogenen Organisation nach den zu bearbeitenden Produktgruppen und Absatzgebieten. Bei einer zentralen Organisation sind alle gestalterischen Funktionen und Entscheidungskompetenzen in einer Zentrale gebündelt. Nachgelagerte Einheiten haben lediglich ausführende Tätigkeiten. Bei einer dezentralen Organisation besitzen produkt- oder gebietsbezogene Einheiten eigene Entscheidungs- und Gestaltungsbefugnisse. Bei einer Ressourcenoptimierung richtet sich der Prozessfluss nach den Ressourcen, um diese hoch auszulasten. Bei einer Prozessorganisation werden die Ressourcen nach den Arbeitsschritten des Prozesses angeordnet, um kurze Durchlaufzeiten zu erzielen. In Abb. 1.4 ist eine funktionale, zentrale und ressourcenoptimierende Organisationsstruktur abgebildet. Alle Aufträge durchlaufen die zentralen Funktionen Vertrieb, Logistik (Einkauf), Leistungserstellung (Produktion) bis zur buchhalterischen Erfassung und Zahlung des Kunden. Dieser häufig verwendete anschauliche Prozess vom Auftragseingang bis zur Bezahlung wird auch als „order to cash“ bezeichnet. Zwei Abläufe für Ausprägungen zweier Produktgruppen A und B sind in Abb. 1.4 angegeben und zeigen gegenseitige Blockaden und Rücksprünge. Die funktionalen Einheiten sind für alle Produktgruppen zuständig. Dadurch können ihre Kapazitäten bei Auftragsschwankungen einzelner Produktgruppen gut ausbalanciert werden. Da alle Funktionen zentral angesiedelt sind, ist sichergestellt, dass alle gleichartigen Tätigkeiten bei den Produktgruppen auch in gleicher Weise durchgeführt werden. Diese Organisation besitzt allerdings erhebliche Nachteile. Wegen der gegenseitigen Behinderung heterogener Aufträge bei den gleichen Ressourcen entstehen lange Durchlaufzeiten. Sie erfordert wegen der Komplexität einen hohen Koordinationsbedarf. Sie

Abb. 1.4 Funktionale, zentrale, ressourcenoptimierende Organisation. Lange Durchlaufzeiten, hoher Koordinationsbedarf, fehlende Prozessverantwortung, geringe Flexibilität

1.2

Organisationsstrukturen des „Composable Enterprise“

9

besitzt geringe Kundennähe, geringe Flexibilität bei Änderungswünschen sowie geringe Agilität wegen des organisatorischen Beharrungsvermögens zentraler Einrichtungen. Diese Organisationsform ist deshalb für das Composable Enterprise nicht geeignet. Ohne auf alle möglichen Organisationsvarianten einzugehen, wird in Abb. 1.5 und 1.6 eine Organisationsstruktur vorgestellt, die den Kriterien des Composable Enterprise folgt. Um agil und flexibel zu sein, ist das Unternehmen in eigenständige modulare Einheiten gegliedert. Zur modularen Gestaltung können Kriterien wie Produkt-, Markt- oder Serviceorientierung, Technologien oder eigenständige Kosten-/Ergebnisverantwortung herangezogen werden (vgl. Wildemann, 1998, S. 48; Wildemann, o.J., S. 2). In Abb. 1.5 sind Einheiten für Produktgruppen gebildet. Den Process Ownern sind jeweils ihre Prozesse und unternehmerischen Gestaltungsmöglichkeiten zugewiesen.

Abb. 1.5 Objektbezogene, dezentrale (modulare) Prozessorganisation mit zentralen Diensten zur Ressourcenoptimierung Abb. 1.6 Prozessorganisation mit fraktaler Wiederholung

10

1

Das Composable Enterprise als neues Paradigma

Die Module bilden damit weitgehende autarke „Unternehmen“ innerhalb des Gesamtunternehmens mit eigener Leitungsinstanz des Process Owners. Die Einheiten können schneller auf Kundenwünsche eingehen oder neue Produktinnovationen an den Markt bringen. Gleichzeitig sind die jeweiligen Prozesse auf homogenere Objekte bezogen und damit gegenüber dem Gesamtprozess über alle Produktgruppen und Gebiete hinweg wesentlich weniger komplex. Dieses Prinzip der Vereinfachung durch Segmentierung wird auch in anderen Zusammenhängen in diesem Buch eine große Rolle spielen. Aus verhaltensökonomischen Erkenntnissen kommt hinzu, dass die Mitarbeiter wegen der höheren Autonomie, ihrer stärkeren kommunikativen Einbeziehung und leichteren Rückkopplung zu ihrem Arbeitsergebnis stärker motiviert sind. Sie identifizieren sich mehr mit ihrer Arbeit, sehen ihren Sinn (purpose) und entfalten Einfallsreichtum und Kreativität (Wildemann, 1998, S. 37 ff.). Diese Argumente spielen im Zeichen des Fachkräftemangels und der geänderten Arbeitseinstellungen der Y-Z-Generationen eine große Rolle. Mit dem Konzept „Zentrale Dienste“ werden in Abb. 1.5 für übergreifende Funktionen die Ressourcenoptimierung durch Nutzung von Synergien bei gleichartigen Vorgängen unterstützt. Dies bedeutet, dass zentral zur Verfügung gestellte Ressourcen von mehreren modularen Einheiten genutzt werden können, ohne dass deren operative Prozesse darunter leiden. Dieses gilt häufig für die mehr kaufmännischen Funktionen wie Einkauf, Personalabrechnung oder Rechnungswesen. Bei zentraler Bearbeitung kann z. B. die stärkere Marktmacht bei Preisverhandlungen mit Lieferanten genutzt werden. Diese Mischung zwischen dezentralen Modulen und zentralen Diensten kann sich in einem Unternehmen auf unterschiedlichen Organisationsebenen wiederholen. Dieses wird in Abb. 1.6 gezeigt. Zunächst ist die klassische Darstellung des Organigramms der Abb. 1.5 durch eine Netzwerk-Darstellung aufgelöst. Hierdurch soll anstelle der Hierarchie der Servicegedanke der Unternehmenszentrale stärker betont werden. Um die Geschäftsführung mit den zentralen Diensten sind die dezentralen Module gleichberechtigt angeordnet. Die Module nutzen die zentralen Dienste und entwickeln eigene wertschöpfende Prozesse. Dieses Netzwerkmodell kann sich in den Organisationsmodulen fraktal, also selbstähnlich, wiederholen. Innerhalb der Module werden dazu wiederum selbstständige Organisationseinheiten gebildet, die dem gleichen Prinzip von zentralen und dezentralen Funktionen folgen, wie dieses in Abb. 1.6 gezeigt ist. Dieses kann sich bis auf die Ebene des Arbeitsplatzes fortsetzen, indem jeweils zentrale Prozesse definiert sind, gleichzeitig aber auch individuelle Prozesse gestaltet werden. Dieses Wiederholungsprinzip der Selbstähnlichkeit wurde von Warnecke bereits 1992 in seinem Buch „Die fraktale Fabrik“ (Warnecke, 1992) herausgestellt und wird in dieser Arbeit häufig angewendet. Obwohl es für die Fabrikorganisation entwickelt worden ist, ist es eine gute Leitlinie für die Gestaltung des Composable Enterprise.

1.2

Organisationsstrukturen des „Composable Enterprise“

1.2.2

11

Umsetzung der Organisationsstruktur in die Anwendungsarchitektur

Eine zentrale Funktionsstruktur wie die der Abb. 1.4 neigt zu einem zentralen monolithischen Anwendungssystem für alle Produktgruppen und Marktgebiete. Änderungen in den Anwendungssystemen müssen dann mit den Anforderungen aller Produktgruppen und Gebiete abgestimmt werden. Dieses zeigt die Abhängigkeit zwischen Organisations- und Anwendungsstruktur. Die Organisationsstruktur des Composable Enterprise der Abb. 1.5, 1.6 mit stärkerer Agilität und Flexibilität erfordert deshalb auch eine flexiblere Anwendungsarchitektur des IT-Systems. Die Beziehung zwischen den PBCs und einer IT-Anwendung ist vom Typ n:m (vgl. Abb. 1.7). Das bedeutet, dass eine Anwendung aus mehreren PBCs bestehen kann und eine PBC in mehreren Anwendungen verwendet werden kann. Eine Anwendung kann einen gesamten organisatorischen (betriebswirtschaftlichen) Prozess abbilden oder in einem Prozess werden mehrere Anwendungen aufgerufen. Auch die Beziehung zwischen Anwendung und Prozess ist somit vom Typ n:m. Die Verbindung zwischen Anwendungen zu einem Prozess wird durch das betriebswirtschaftliche Prozesswissen in Form von Prozessmodellen hergestellt. Alle technischen Verbindungen zwischen PBCs und Anwendungen werden durch API- und/oder EDATechnologie über die Integrationsfunktion der Application Composition Platform realisiert. Diese Schnittstellen werden in dieser Arbeit durch die fett schwarz ausgezogenen Kanten dargestellt.

Abb. 1.7 n:m-Beziehungen zwischen PBCs, Anwendungen und Prozessen

12

1

Das Composable Enterprise als neues Paradigma

Abb. 1.8 zeigt eine mögliche Anwendungsarchitektur für die Organisationsstruktur der Abb. 1.5. Die Anwendungen der Organisationseinheit „Zentrale Dienste“ werden durch die Shared Services abgebildet, auf die alle Anwendungen der dezentralen Einheiten über die Plattform zugreifen. Alle Komponenten sind auf der gleichen Hierarchieebene angeordnet. Dies gilt im Prinzip auch für die Shared Services, die in Abb. 1.7 lediglich zur Annäherung an die Zentralen Dienste in das Zentrum gezeichnet sind. Elementare Bausteine für Anwendungen sind die PBCs, die die fachlichen Inhalte für eine Aufgabe als autonome Softwarekomponenten enthalten und sich durch API- und/oder EDA-Schnittstellen nach außen öffnen. Sie stellen die Bausteine der Anwendungen dar und sind über die Plattform verfügbar. Sie sind in Abb. 1.8 durch einen Fächer dargestellt. Die PBCs werden entsprechend dem Bauplan eines Prozessmodells über die Composition-Funktion der Plattform zu Anwendungen zusammengefügt oder komponiert. Dieses ist lediglich bei der Anwendung 1 durch drei PBCs grafisch angedeutet. Auch wird

Abb. 1.8 Mögliche Anwendungsarchitektur des Composable Enterprise aus Abb. 1.4

1.2

Organisationsstrukturen des „Composable Enterprise“

13

das User Interface als Grundlage der User Experience der Anwendung hinzugefügt. Die Anwendungen sind entweder bereits Geschäftsprozesse oder werden organisatorisch zu übergreifenden Geschäftsprozessen gebündelt. Die Bündelung wird in Abb. 1.8 durch rote Umrandung dargestellt. Die Umrandung der Anwendungen mit den Shared Services zu Prozessen wird aus Gründen der Übersichtlichkeit fortgelassen; sie ist in der Regel bei allen Prozessen gegeben und wird über die Plattform technisch realisiert. Für die Produktgruppe A ist in Abb. 1.8 lediglich ein einziger Geschäftsprozess definiert, der aus zwei Anwendungen besteht, die aus den PBCs komponiert werden. Für die Produktgruppe B sind zwei Geschäftsprozesse definiert, die jeweils aus einer für die Gruppe B zentralen und einer individuellen Anwendung bestehen. Die zentrale Anwendung ist dann ein Shared Service für die Produktgruppe B. Damit wird die Wiederholung von zentralen und dezentralen Funktionen bei den weiterführenden Organisationseinheiten herausgestellt. Durch die API- und EDA-Schnittstellen und die Plattform können PBCs neu verbunden, ersetzt, entfernt oder eingefügt werden, so dass die dezentralen Prozesse schnell geändert werden können. Die Schnittstellen werden durch die stark ausgezogenen schwarzen Umrandungen gekennzeichnet. In Abb. 1.9 ist der Bezug zu dem Beispiel fortgelassen und die prinzipielle Anwendungslogik dargestellt. Sie zeigt, wie sich die dezentralen Anwendungen um die zentralen Shared Services ranken. Die Shared Services repräsentieren dabei häufig die klassischen Funktionen von ERP-Systemen.

Abb. 1.9 Allgemeine Anwendungsarchitektur. (Quelle: Adobe Stock, PureSolution)

14

1

Das Composable Enterprise als neues Paradigma

Die dezentralen Anwendungen werden durch die Plattform aus den PBCs und dem Prozesswissen gebildet. Eine dezentrale Anwendung kann auf der Ebene eines organisatorischen Prozessmoduls als quasi eigener „Shared Service“ zentral eingesetzt werden, um die sich dann wiederum individuelle Anwendungen ranken. Damit wird der Ansatz einer fraktalen Organisation betont. Dieses ist in Abb. 1.9 angedeutet. Die Sicht des Benutzers ist auf die Prozesse und Anwendungen gerichtet. Die PBCs sind technische Bausteine und bleiben ihm verborgen. Die Infrastruktur wird durch die Cloud dargestellt, die alle Elemente über die Plattform miteinander verbindet. Auch externe Anwendungen von Kunden, Lieferanten oder Partnern verbinden sich über das Internet mit dem Cloud-basierten Informationssystem und greifen über das APIManagement auf Daten und Dienste des Unternehmens zu. Die Einführung des Composable Enterprise ist ein mehrjähriges Projekt, da bei einem bestehenden Unternehmen nicht gleichzeitig alle Systeme ersetzt werden können. Trotzdem kann in neu eingeführten organisatorischen Prozesseinheiten oder in besonders dringend nach mehr Flexibilität verlangenden Bereichen sofort begonnen werden. Hier ist dann die Integrationsmöglichkeit zu bestehenden Altsystemen der Shared Services über die Plattform besonders wichtig. Der Gedankengang von einer agilen, flexiblen und innovationsoffenen Unternehmensstruktur über die Application Composition Platform als Enabler bis zu der composable Anwendungsarchitektur wird in Abb. 1.10 zusammengefasst.

Abb. 1.10 Verbindung von Organisation, Plattform und Anwendungen. (Quelle: Adobe Stock, PureSolution)

1.3

Der Composable Enterprise Lifecycle

15

1.3 Der Composable Enterprise Lifecycle Nach der Begründung des Konzeptes des Composable Enterprise mit den Konsequenzen für Organisation und Anwendungsarchitektur wird es mit einem Lifecycle-Konzept verbunden. Das Lifecycle-Konzept reicht von der Entwicklung einer Innovationsidee über die Prozessmodellierung und Enterprise Architecture, dem Aufbau der Application Composition Platform, der Anwendungsentwicklung, dem Operational Performance Support der Ausführung, dem Process-Monitoring und -Mining bis zur kontinuierlichen Verbesserung der Innovation und ihrer Anwendungssysteme. Abb. 1.11 fasst die Phasen in einem Kreislaufbild zusammen. Diesen Phasen wird nach Vorstellung des Lifecycles jeweils ein ausführliches Kapitel gewidmet. Der Leser kann deshalb auch zunächst die Langfassungen der Kapitel lesen und den Lifecycle-Abschnitt als Zusammenfassung nutzen.

1.3.1 Phase 1: Unternehmensanalyse In der ersten Phase der Entwicklung zum Composable Enterprise wird der Bedarf für grundsätzliche Veränderungen in Organisation, Businessmodellen und Informationssystemen analysiert. Anlass dafür geben globale politische Entwicklungen, Marktveränderungen oder neue Ideen für Innovationen. Einige Beispiele wurden am Anfang des Kapitels genannt. Die Unternehmensanalyse zeigt dann die Notwendigkeit, flexibler, agiler und innovationsfreudiger zu werden, also mit der Transformation zum Composable Enterprise durch Dezentralisierung, PBCs, Plattformarchitektur und komponierbarer Anwendungsarchitektur zu beginnen.

1.3.2 Phase 2: Innovationsprozess Die Ergebnisse der Unternehmensanalyse sowie die Entwicklungen der Informationstechnik verlangen von dem Composable Enterprise strategische Innovationen. Dieses geschieht durch neue oder geänderte Businessmodelle und Geschäftsprozesse. Businessmodelle beschreiben, durch welche Produkte und Dienstleistungen mit welchen Ressourcen ein Unternehmen auf dem Markt erfolgreich sein will. Geschäftsprozesse dienen dabei einmal zur operativen Umsetzung neuer Businessmodelle, können aber bei Dienstleistungen selbst auch Geschäftsmodelle darstellen. Viele Innovationen, die digitale Unternehmen erfolgreich machen, beruhen auf dem Outside-in-Denken. Bei dem Outside-in-Ansatz dominiert die Frage: „Wie wird die Erfahrung (Experience) des Kunden mit dem neuen Produkt sein und welche Wünsche und Erwartungen hat er zusätzlich?“

1

Abb. 1.11 Composable Enterprise Lifecycle. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

16 Das Composable Enterprise als neues Paradigma

1.3

Der Composable Enterprise Lifecycle

17

Bei dem Inside-out-Vorgehen stehen dagegen die eigenen Erfahrungen und die eigenen Ideen und Fähigkeiten des Unternehmens im Vordergrund. Sie werden kontinuierlich ergänzt und verfeinert. Sprunghafte Innovationen sind dann eher selten. Das Outside-in-Denken fällt schwer, da man gewohnt ist, seine eigenen Ideen in den Vordergrund zu stellen. Viele Innovationen beruhen aber auf Änderungen der Beziehungen des Unternehmens zu Partnern außerhalb des Unternehmens, also zu den Kunden, Lieferanten, Bewerbern und Geschäftspartnern. Ihre Erfahrung mit dem Unternehmen, seinen Produkten und Dienstleistungen bestimmen den Geschäftserfolg. Es ergeben sich Fragen wie: welche Erlebnisse hat ein Kunde mit dem Produkt, besitzt er die Aufnahmefähigkeit für neue Funktionen, die ihm angeboten werden? Welche Erfahrungen macht ein Lieferant mit dem Unternehmen? Wie wird das Unternehmen für Bewerber attraktiver? Kann die Partnerschaft zu externen Stakeholdern verstärkt werden? Das sind Fragen, durch deren Beantwortung neue Businessmodelle entstehen, wie bekannte digitale Unternehmen, wie z. B. Airbnb oder Uber, zeigen. Airbnb ist nicht von einer bestehenden Hotelkette gegründet worden, sondern von Studenten, die überlegt haben, welche Dienste ein Kunde zum Übernachten in einer fremden Stadt bei einem begrenzten Budget benötigt: ein sauberes Zimmer mit einem akzeptablen Service und einer überprüfbaren Qualität. Dieses muss dann nicht ein professionelles Hotel sein, sondern kann auch ein Zimmer bei einer vertrauenswürdigen Privatperson sein. Ein einfacher digitaler Suchvorgang verbindet dann Bedarf und Angebot und die Bewertung der Services bietet die Vertrauensbasis. Aus solchen Überlegungen, unterstützt durch Kreativitätstechniken wie „Design Thinking“, können neue Businessmodelle entwickelt werden (Meinel & Krohn, 2022). Der „Composable“-Gedanke bezieht sich dann auf Fragen, aus welchen eigen- oder fremderstellten Geschäftsmodulen sich die Leistung zusammensetzen soll. Das Montieren neuer Produkte oder Dienstleistungen aus bereits am Markt befindlichen Komponenten kann die Innovationsgeschwindigkeit gegenüber einer reinen Eigenentwicklung erheblich steigern. Dieses setzt voraus, dass die IT-Systeme der Geschäftsprozesse die Eingliederung von Geschäftsmodulen unterstützen. Je mehr „composable“ deshalb ein Unternehmen bei der Informationsverarbeitung ist, umso mehr kann es flexibel agieren, indem z. B. neue Partner, Geschäftsteile oder Prozesse hinzugenommen oder ausgetauscht werden. Ergebnis der Überlegungen ist dann ein Businessplan für eine Innovation.

1.3.3 Phase 3: Composable Process und Enterprise Architecture Anhand der strategischen Überlegungen werden die benötigten Geschäftsprozesse definiert und in einer Architektur zusammengestellt. Diese enthalten noch keine IT-Begriffe, sondern werden zunächst organisatorisch-inhaltlich beschrieben und gegliedert. Durch eine klare Strukturierung der Module wird dabei dem Composable-Gedanken gefolgt.

18

1

Das Composable Enterprise als neues Paradigma

Bei der Beschreibung der Geschäftsprozesse steht die Reihenfolge der Funktionen, in der sie ausgeführt werden, im Vordergrund. Aber auch die verantwortlichen Organisationseinheiten, die verwendeten Daten und erzeugten Leistungen oder Produkte gehören zur Prozessbeschreibung. Zudem müssen die Prozesse in ein Rahmenkonzept, eine Enterprise Architecture (EA), eingeordnet werden, um Überlappungen, Inkonsistenzen und weiße Flecken der Prozesslandschaft zu entdecken. Mit dem ARIS-Haus hat der Verfasser eine Enterprise Architecture (EA) und mit den ereignisgesteuerten Prozessketten (EPK) eine Modellierungssprache für Geschäftsprozesse entwickelt, die international eingesetzt werden. Die Sichten des ARIS-Hauses aus Organisation, Daten, Funktionen, Produkten und Prozessen bilden den Rahmen der Enterprise Architecture, um ein Unternehmen in seiner Struktur und seinen Tätigkeiten zu beschreiben. Für jede der Sichten werden halbformale grafische Beschreibungssprachen eingesetzt. Auch die Methode BPMN zur Beschreibung von Geschäftsprozessen wird unterstützt. EA-Konzepte werden bereits seit längerem angewendet, sind zwischenzeitlich etwas zurückgenommen, werden aber aufgrund der Komplexität umfassender digitaler Transformationsprojekte wieder in den Fokus der unternehmensweiten Informationsverarbeitung gerückt. Eine EA schafft Übersicht über vorhandene Systeme, beschreibt also die Ausgangssituation für eine digitale Transformation und verbindet sie mit dem Zielbild. Es ist möglich, ein EA-Modell weitgehend aus generierten oder von Beratungsunternehmen und Softwareanbietern bezogenen Prozessmodellen automatisch zu füllen, sodass sein Erstellungs- und Pflegeaufwand reduziert werden. Prozessmodelle bilden Unternehmensabläufe digital ab und können deshalb als digitale Zwillinge (Digital Twins) des Unternehmens bezeichnet werden. Mit ihnen werden z. B. die Auswirkungen alternativer Prozesse simuliert. Die Prozessmodelle können durch digitale bildhafte Darstellungen, wie sie für Produkte und Fabriken bereits gebräuchlich sind, ergänzt werden. Dieses führt perspektivisch zu dem Ansatz Metaverse. Hiermit wird eine digitale Parallelwelt bezeichnet, die zwar z. Zt. mehr für konsumnahe Anwendungen diskutiert und entwickelt wird, aber auch für die Unternehmenswelt sinnvoll ist. Simulation, Virtual Reality, Augmented Reality und Avatare von Menschen verbinden dann virtuelle mit realer Welt.

1.3.4 Phase 4: Application Composition Platform Zur digitalen Umsetzung der Geschäftsprozesse des Composable Enterprise wird die Application Composition Platform eingesetzt. Sie stellt Funktionen zur Prozessautomatisierung, zur Integration, zur Entwicklung der PBCs und zu ihrer Komposition bereit. Die Plattform ist die Entwicklungsumgebung des Entwicklers für die PBCs und die Anwendungen. Eine PBC ist eine weitgehend autarke Programmeinheit, die auch als Building Block, Modul oder Service bezeichnet werden kann. Die Autarkie bezieht sich darauf, dass nur eine geringe Abhängigkeit zu Funktionen und Daten außerhalb der Ein-

1.3

Der Composable Enterprise Lifecycle

19

heit bestehen soll und eine eigene interne Datenverwaltung besteht. Dieses macht die PBCs in ihrer Entwicklungsgeschwindigkeit voneinander unabhängig. Aus den PBCs werden die Anwendungen zusammengestellt (komponiert). Die Anwendungen werden weiter zu Prozessen gebündelt. Die Anwendungen und Prozesse sind die Schnittstellen für den Benutzer, wobei diesem die darunterliegenden technischen Funktionen der Plattform und die PCBs verborgen sind. Zur Definition der Geschäftsprozesse ist in der Plattform ein Modellierungstool als Designer installiert. Workflow-Funktionalität der Plattform unterstützt die Ausrichtung auf eine Geschäftsprozessorganisation. Eine zentrale Funktion der Plattform ist die Integration und Montage der PBCs zu Anwendungen und Geschäftsprozessen. Die Integration der PBCs sowie die Integration externer Komponenten wird über APIs und/oder Event-Schnittstellen realisiert. Eine konsequente API-Strategie unterstützt auch die Zerlegung bestehender monolithischer Systeme in Building Blocks. Hersteller eher monolithischer Unternehmenssoftware wie SAP planen, ihre Systeme auf einer Business Technology Platform aufzusetzen, so dass eine Verbindung zwischen der Landschaft aus Alt- bzw. ERP-Systemen mit dem Composable-Ansatz hergestellt wird. Zur Softwareentwicklung stellt die Application Composition Platform neben Programmiersprachen (Professional Coding, auch als Pro-Code bezeichnet) eine Low-Code-Umgebung mit einem Durchgriff auf eine Standardprogrammiersprache bereit. Mit Low-Code werden einfach zu erlernende grafische Beschreibungssprachen bezeichnet, aus denen automatisch ausführbarer Code generiert wird. Hierzu werden auf der Application Composition Platform eine grafische und formularorientierte Beschreibungssprache (z. B. als Ausschnitt einer Modellierungssprache wie EPK oder BPMN) bereitgestellt. Mit LowCode können Mitarbeiter aus Fachabteilungen User Interfaces für die Experience eines Systems und einfache Anwendungen entwickeln. Damit wird das Problem des IT-Fachkräftemangels gemildert. Mit der Funktion Composition werden PBCs zu Anwendungen und Anwendungen zu Prozessen zusammengestellt. Weiterhin gehören Funktionen zum Monitoring der auszuführenden Prozessinstanzen und Process Mining zum Standard einer Application Composition Platform. Schnittstellen zu übergreifenden Analysefunktionen und KI-Algorithmen unterstützen eine intelligente Prozessautomatisierung. Die Plattform als Cloud-Lösung beschleunigt leichtere Implementierung, leichteres Management und Ressourcenskalierung einer Anwendung. Die Clouddienste werden über das Internet oder mobil angeboten. Die beschriebenen Funktionen einer Application Composition Platform sollten in integrierter Form bereitgestellt werden. Dadurch ist sichergestellt, dass die Entwickler alle Funktionen in der gleichen Umgebung zur Verfügung haben. Geschäftsprozesse werden dann in der gleichen Methodik beschrieben wie Integrationsprozesse oder Entwicklungs-

20

1

Das Composable Enterprise als neues Paradigma

prozesse von APIs. Dieses ist bei der „Scheer PAS Plattform“ des Unternehmens Scheer PAS GmbH in Saarbrücken Leitlinie der Architektur. Bei allen Schritten steht das Prinzip der Composability im Vordergrund; es muss also gewährleistet sein, dass PBCs und damit Anwendungen bis Prozesse einfach hinzugefügt, geändert oder entfernt werden können. In einem Softwarecontainer werden alle von der Anwendung benötigten Hilfen wie Betriebssystemfunktionen und Daten zur Verfügung gestellt. Damit ist die Anwendung auf beliebiger Hardware ablauffähig und autark. Mit den beschriebenen Fähigkeiten der Application Composition Platform können in der nächsten Phase die konkreten Anwendungen entwickelt werden.

1.3.5 Phase 5: Development und Implementation Nachdem die Funktionen Prozessautomatisierung, Integration, Entwicklungsunterstützung und Composition der Plattform zur Verfügung stehen, werden die PBCs entwickelt und zu Anwendungen und Prozessen zusammengefügt. Neben neu zu entwickelnden PBCs können auch Teile bestehender selbstentwickelter Software (Legacy) oder Standardsysteme (ERP) verwendet werden, indem diese Teile neu geordnet und gekapselt werden. Bei der Softwareentwicklung zeigt sich generell das Problem des Mangels an Informatikern und Systemspezialisten. Ein wichtiger Ausweg ist deshalb, die Entwicklung so zu vereinfachen, dass auch interessierte Mitarbeiter aus den Fachabteilungen Anwendungen mittels Low-Code-Funktionen der Plattform entwickeln können. Dieses besitzt neben der Kapazitätsausweitung den Vorteil, dass aus den Fachabteilungen ohnehin der fachliche Input gegeben wird. So entfallen weitgehend Pflichtenhefte und Abstimmungsrunden zwischen Fachbereich und IT. Damit können die betriebswirtschaftlich grob beschriebenen Prozesse von Mitarbeitern der Fachabteilung (Citizen Developern) weiter detailliert werden und aus ihnen automatisch ein Softwarecode in einer Programmiersprache wie Java oder Java Script generiert werden. Das Low-Code-System stellt dazu eine 1:1-Beziehung zwischen Elementen der Modellierungssprache und entsprechenden Programmierkonstrukten bereit. Low-Code unterstützt auch den Einsatz von Headless-Softwaresystemen. Hier stellt der Softwareanbieter lediglich den Verarbeitungsteil oder das Backend zur Verfügung. Das User Interface zu der Anwendung entwickelt der Anwender mit Low-Code dann selbst. Hiermit wird es ihm ermöglicht, sein individuelles Interface flexibel zu gestalten, ohne auf die Hilfe des Softwareanbieters warten zu müssen. Bei allen Prozessen sollte geprüft werden, an welchen Positionen sinnvoll KI-Algorithmen zur Automatisierung eingesetzt werden können. Dabei ist besonders darauf zu achten, dass diese keine Insellösungen innerhalb der Prozesse sind, sondern dass ihre Ergebnisse in den Workflow zur automatischen Weiterverarbeitung einfließen.

1.3

Der Composable Enterprise Lifecycle

21

Die drei Objekte PBCs, Prozesse und Applications bilden zusammen mit der Platform, der Cloud-Infrastruktur und der Verbindung zu der Außenwelt mit Kunden und Partnern die Anwendungsarchitektur. Bei größeren Projekten ist ein enges Projektmanagement wichtig, damit die geplante Zeit, Qualität und das Budget nicht aus dem Ruder laufen. Negative Beispiele sind hier zur Genüge bekannt. Auch das Reskilling und Upskilling der späteren Benutzer ist entscheidend für den Projekterfolg. Schon vor dem Betrieb eines Systems muss dafür gesorgt werden, dass die künftigen Anwender in der Lage sind, die neuen Geschäftsprozesse und Systeme zu verstehen, um sie richtig ausführen zu können. Wenn das nicht geschieht, können die Systeme zwar technisch einsatzfähig sein, aber nicht effektiv genutzt werden. Zur Qualifizierung der Mitarbeiter bieten sich digitale Lernhilfen an1 . Die fertigen Building Blocks werden in einem Katalog zusammengestellt und veröffentlicht. So wird Doppelentwicklungen vorgebeugt. Das aus den Building Blocks orchestrierte Anwendungssystem steht dann dem Anwender zur Prozessbearbeitung zur Verfügung. Ein Containeransatz macht Building Blocks unabhängig von technischen Trägersystemen der IT.

1.3.6 Phase 6: Execution und Case Management In der Ausführungsphase werden von den Anwendern die einzelnen Prozessinstanzen gemäß den modellierten und implementierten Abläufen bearbeitet. Die Steuerung der einzelnen Instanzen wird als Case Management bezeichnet. Dieses bietet insbesondere bei länger dauernden Prozessabläufen Hilfestellungen zur Lösung von Problemsituationen an. Auf der Ebene der einzelnen Instanz startet in Abb. 1.11 ein eigener Lifecycle vom Beginn der Bearbeitung bis zur Fertigstellung. Dieses wird durch den kleineren Kreislauf und den feineren Linienzug grafisch zum Ausdruck gebracht. Die Arbeitsergebnisse und Statusänderungen der Bearbeitung werden in Datenbanken gespeichert. Dabei gilt es zwei Datenarten zu unterscheiden. Einmal betrifft es die Anwendungsdaten. Beispielsweise werden von einem Auftragsbearbeitungssystem die Auftragsdaten des Kunden in der Auftragsdatei erfasst. Diese Daten stehen zur Weiterbearbeitung in der Produktion sowie für Auswertungen zur Verfügung. Eine zweite Datenart betrifft die Prozessausführung. Moderne Anwendungssoftware speichert z. B. Zeitstempel von Beginn und Ende einer Transaktionsbearbeitung, die einer Prozessfunktion entspricht, in sogenannten Logdateien.

1

Von der vom Verfasser gegründeten imc AG werden hierzu eine Lernplattform sowie digitale Inhalte und intelligente Entwicklungswerkzeuge für Inhalte angeboten.

22

1

Das Composable Enterprise als neues Paradigma

Aus den Prozessdaten der Logdateien können in Real-Time die Prozesszustände wie Zeiten, zuständige Bearbeiter und Arbeitsergebnisse der einzelnen Prozessinstanzen erkannt werden. Mit diesem Monitoring können z. B. Abweichungen zu den geplanten Vorgaben erkannt werden. Bei Zeitverzögerungen kann durch Algorithmen in Real-Time ein neuer Ablauf vorgeschlagen werden, um den Zeitverzug aufzuholen. Der Algorithmus verhält sich dann wie ein Navigationsinstrument eines Autos, das bei einer Straßensperrung für einen Fahrer automatisch eine individuelle neue Streckenführung vorschlägt. Bei auftretenden Problemen können während der Fallbearbeitung dem Bearbeiter Hilfestellungen (Support) durch auf die Situation bezogene Informationen oder Schulungsunterlagen gegeben werden.

1.3.7 Phase 7: Insight durch Mining Sowohl aus den Anwendungs- als auch aus den Prozessdaten der Logdateien können wertvolle Auswertungen generiert werden, die zunächst zu neuen Erkenntnissen (Insights) führen, aber in der nächsten Phase auch zur Prozessverbesserung genutzt werden. Zur automatischen Auswertung der Anwendungsdaten öffnet sich das Feld der „Analytics“, das ein ganzes Bündel statistischer Verfahren bereithält. Besonders interessant sind KI-Verfahren. Sie können Datenbestände automatisch nach in ihnen enthaltenen Mustern analysieren und Ausreißer erkennen. Dieses wird z. B. erfolgreich zur Betrugserkennung, Reisekostenprüfung und zu automatischen Marktanalysen eingesetzt. Aus den Prozessdaten der Instanzen eines Zeitraums kann durch Algorithmen des Process Minings das dazu passende reale Prozessmodell automatisch generiert werden (Model Discovery). Das generierte Modell kann mit dem geplanten Prozessmodell verglichen werden, um Abweichungen festzustellen (Model Comparison). Das generierte Modell zeigt die in dem Zeitraum tatsächlich durchgeführten Prozessabläufe in komprimierter Form. Die Anzahl der dabei durchlaufenen Wege können durch nachträgliches (simuliertes) Durchlaufen der realen Instanzen an dem Modell gezählt werden, um Standardabläufe und Ausreißer zu erkennen. Process Monitoring, Model Discovery und Model Comparison wurden bereits im Jahr 2000 mit dem Produkt ARIS-PPM (Process Performance Manager) der IDS Scheer AG entwickelt und in den Markt eingeführt. Die Konzepte wurden inzwischen von einer breiten Community aus Wissenschaft und Anwendern weiterentwickelt und erfahren seit dem Jahr 2010 auch durch neue Produkte wie Celonis und SIGNAVIO besondere Aufmerksamkeit.

1.3.8 Phase 8: Actions/Verbesserungen Sowohl aus der Analyse von Anwendungsdaten als auch aus Prozessdaten können Anregungen für Verbesserungen abgeleitet werden.

Literatur

23

Für einfache Automatisierungsaufgaben wie den Datenaustausch zwischen verschiedenen Datenbanken können mit Hilfe von RPA-Werkzeugen (Robotic Process Automation) von Mitarbeitern der Fachabteilung aus der Arbeitsplatzsicht kleine Programme erzeugt werden. Dabei werden keine neuen Anwendungen entwickelt, sondern lediglich manuelle Vorgänge der Datenübertragung zwischen verschiedenen Anwendungen automatisiert. Bei Analysen der Anwendungsdaten kann für bestimmte erkannte Datenmuster auf eine Falldatenbank zugegriffen werden, die Verbesserungsvorschläge anbietet. So kann bei einem zu hohen Lagerbestand ein neuer Bestellalgorithmus vorgeschlagen werden. Dieser kann durch vorgefertigte Apps direkt eingesetzt werden. Oder für ein identifiziertes Betrugsmuster wird eine App eingesetzt, die entsprechende Betrugsversuche abfängt. Aus den Abweichungen zwischen Ist-Prozessmodell und dem Soll-Modell können organisatorische Maßnahmen oder Schulungen für Mitarbeiter abgeleitet werden. Diese Aktionen initiieren neue Projekte, die wiederum die Phasen des Transformationskreislaufs durchlaufen und in der Regel zu einer weiteren Innovation und Automatisierung beitragen. Das kontinuierliche Durchlaufen des Transformationskreislaufs von der Innovation zur Ausführung und Verbesserung führt zu einer fortlaufenden Steigerung des Nutzens der digitalen Transformation und zur ständigen Weiterentwicklung des Composable Enterprise. Die Phasen des Composable Enterprise Lifecycle werden im Folgenden durch eigene Kapitel vertieft.

Literatur Gartner (2021). Future of applications: Delivering the composable enterprise ID: G00465932 (S. 3–4). Gaughan, D., Natis, Y., Alvarez, G., & O’Neill, M. (2020). Future of applications: delivering the composable enterprise. Meinel, C., & Krohn, T. (2022). Design Thinking in der Bildung, Innovation kann man lernen. Weinheim: Wiley. Warnecke, H.-J. (1992). Die Fraktale Fabrik. Berlin-Heidelberg: Springer. Wildemann, H. (1998). Die modulare Fabrik: Kundennahe Produktion durch Fertigungssegmentierung (5. Aufl.). München: TCW. Wildemann, H. (2008). Modulare Unternehmensorganisation, Leitfaden zur Einführung föderalistischer Organisationsprinzipien in Unternehmen (S. 2). München: TCW.

Weiterführende Literatur Scheer, A.-W. (1991). Architektur integrierter Informationssysteme – Grundlagen der Unternehmensmodellierung (1. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (2001). ARIS – Modellierungsmethoden, Metamodelle, Anwendungen (4. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (2002). ARIS – Vom Geschäftsprozess zum Anwendungssystem (4. Aufl.). Berlin, Heidelberg: Springer.

2

Innovationsfreude als Merkmal des Composable Enterprise

Zusammenfassung Es werden die Chancen für das „Composable Enterprise“ durch seine Innovationsfreudigkeit behandelt und damit das Konzept in den Gesamtzusammenhang der Unternehmensentwicklung gestellt. Dabei wird der „Outside-in“-Ansatz als besonderes Merkmal erfolgreicher Innovationen herausgestellt und die Eigenschaften eines Geschäftsmodells gekennzeichnet. Auf die Gefahren des Innovator’s Dilemma, zu lange an bewährten erfolgreichen Konzepten festzuhalten, wird hingewiesen. Um den Gedankenfluss des LifecycleKonzeptes nicht zu stören, werden die Ausführungen zur Innovation zunächst knapp gehalten. Wegen der Bedeutung der Innovation für das Composable Enterprise wird das Thema in Kap. 9 mit der Diskussion wichtiger Innovationstreiber weitergeführt. Die Abb. 2.1 stellt den Zusammenhang zu dem Lifecycle-Modell der Abb. 1.11 her.

Abb. 2.1 Innovationen führen zu neuen Businessmodellen. (Quelle: Adobe Stock, PureSolution)

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_2

25

26

2.1

2

Innovationsfreude als Merkmal des Composable Enterprise

Planung von Innovationen

Erst die erfolgreiche Umsetzung neuer Digitalisierungstechniken in neue Organisationsformen, Produkte und Prozesse ermöglichen ihre wirtschaftliche Durchsetzung und damit Innovationen. Typisch für neue Businessmodelle ist der Wandel von einer „Inside-out“- zu einer „Outside-in“-Betrachtung, also von der Innensicht des Unternehmens zur Erfahrungssicht, der „Experience“ des Kunden und weiterer Stakeholder mit dem Unternehmen und seiner Leistungen. Auf sich ändernde Bedürfnisse der Experience des Kundenmarktes muss ein Unternehmen aktuell und schnell reagieren können. Kunden müssen durch ad-hoc Marketingaktionen neue Produkte angeboten werden können, Lieferanten müssen zu Angeboten für Aktionen aufgefordert und ausgewählt werden können, Hochschulabsolventen müssen mit Motivationsaktionen zu Bewerbungen animiert werden oder Partner zu neuen Geschäftsideen und Logistikketten zusammengeführt werden können. Diesen Prozessen ist gemeinsam, dass sie für spezielle Zwecke kurzfristig entwickelt werden und sich schnell neuen Situationen anpassen müssen. Im Gegensatz zu ihnen stehen die administrativen Backoffice-Prozesse wie Finanzen, operativer Einkauf und Vertrieb, Logistik oder Personal, die durch Standardsoftware der ERP abgedeckt sind und eine nur geringe Änderungsfrequenz haben. Die beiden Ansätze können mit den Begriffen „build to change“ und „build to last“ gekennzeichnet werden. Die neuen Prozesse befinden sich an den Rändern des Unternehmens zu dessen externen Partnern, während die dauerhaften Anwendungen mehr die internen BackofficeProzesse betreffen. So ist die Auswahl neuer Lieferanten nach Preis, Qualität, Zuverlässigkeit und Wechselkurs des Herkunftlandes ein sich ständig ändernder agiler Prozess, während die täglichen administrativen Bestellvorgänge eine Routinefunktion sind. Die composable Unternehmung ist durch ihren modularen Aufbau und ihre Flexibilität besonders innovationsfreundlich. Sie kann leicht neue Geschäftsaktivitäten aufnehmen, löschen oder austauschen. Dabei muss ein Unternehmen nicht in einem Schritt zu einem composable Unternehmen werden. Zunächst kann es z. B. für ein neues Produkt mit dem Konzept starten und dann nach und nach das Konzept auf das gesamte Unternehmen übertragen. Im Zentrum steht aber immer, die Innovationskraft zu erhöhen. Es werden zunächst Ansatzpunkte für Geschäftsmodellinnovationen herausgestellt und auf die Gefahren des Innovator’s Dilemma für bestehende Unternehmen eingegangen, die gleichzeitig die Chancen für Start-Ups bilden.

2.2 Geschäftsmodellinnovationen

27

2.2 Geschäftsmodellinnovationen Besonders wirksame Innovationen beziehen sich auf das Geschäftsmodell eines Unternehmens, das auch zu neuen Geschäftsprozessen führt. Unter einem Geschäftsmodell wird vereinfacht die Art und Weise verstanden, wie ein Unternehmen sein Geld verdient. Dazu gehört z. B. ein Erlös-Modell, das beschreibt, wer die Erlöse für ein Produkt oder eine Dienstleistung bezahlt. Diese auf den ersten Blick einfache Frage ist in der digitalen Welt bereits komplizierter. Beispielsweise bekommen die Nutzer von sozialen Medien Leistungen des Providers quasi kostenlos, da der Anbieter die Erlöse durch Werbeeinnahmen von Dritten erzielt. Hier wird somit über Bande gespielt und dies macht die Frage der Erlöszuordnung komplizierter, als es auf den ersten Blick scheint. Weitere Aspekte eines Geschäftsmodells sind die Beschreibung der benötigten Ressourcen und die Angabe wichtiger Partner. Eine differenzierte Beschreibung weiterer Komponenten findet sich in (Osterwalder & Pigneur, 2011). Dort werden insgesamt 9 Bausteine für ein Geschäftsmodell beschrieben. Diese werden nachfolgend aufgeführt und ein Kurzkommentar mit Bezug zur Digitalisierung hinzugefügt: (1) Kundensegmente Bei der Digitalisierung ist eine Grundfrage, ob das Unternehmen den B2B-, den B2C- oder den B2B2C-Markt bedienen will. Generell besteht ein starker Trend zur Unterstützung des Endkunden. (2) Wertangebot (value proposition) Bei digitalen Geschäftsmodellen wird durch das Outside-in gegenüber Inside-out Denken stärker auf Kundenbedürfnisse eingegangen. (3) Verkaufskanäle Bei der Digitalisierung besteht die Forderung nach Omni-Channel-Funktionalität, bei denen alle Kanäle wie stationärer Vertrieb, Telefon-, Computer-, Internet-, Callcenter- und Mobil-Verbindungen integriert sind. (4) Kundenbeziehungen Diese werden in der digitalen Welt durch die Nutzung sozialer Medien intensiviert. (5) Einnahmequellen Diese betreffen die bereits angesprochenen komplexen Erlösmodelle von Plattformunternehmen. (6) Schlüsselressourcen Bei exponentiell wachsenden digitalen Unternehmen werden Ressourcen so gering wie möglich gehalten. Insbesondere sollen keine zeit- und kapitalintensiven materiellen Res-

28

2

Innovationsfreude als Merkmal des Composable Enterprise

sourcen in Form von Anlagen oder Gebäuden erstellt oder ein großer Mitarbeiterstamm aufgebaut werden, da dieses die Wachstumsgeschwindigkeit beeinträchtigen würde. (7) Schlüsselaktivitäten Diese beschreiben die Kernprozesse des Geschäftsmodells und definieren damit auch den Ressourcenbedarf. (8) Schlüsselpartnerschaften Hier gilt es, in der digitalen Welt viele Aktivitäten auszulagern (Outsourcing), um das Wachstum zu beschleunigen. Gleichzeitig kann durch Partnerschaften die Wertschöpfungskette zum Kunden erweitert werden. (9) Kostenstruktur Die Digitalisierung führt durch den Ersatz von Materie durch Information zu tendenziell geringeren Kosten als die analoge Welt. Dieses ist ein wichtiger Wettbewerbsvorteil bei der Einführung digitaler Produkte. Die Beschreibung von Osterwalder und Pigneur ist praxiserprobt und vermittelt gute Einsichten in die Struktur von Geschäftsmodellen. Ihre Elemente werden deshalb im Weiteren häufig angesprochen. Typisch für die Digitalisierung ist die Entwicklung disruptiver Geschäftsmodelle. Ein disruptives Geschäftsmodell bezeichnet den Fall, dass ein gegebenes Produkt oder eine gegebene Dienstleistung durch die Digitalisierung völlig neu definiert wird, bestehende Anbieter ihre wirtschaftlichen und technischen Kompetenzen verlieren und neue Anbieter auftreten, die die bisher erfolgreichen bedrängen. In Abb. 2.2 ist dies am Beispiel des Prozesses des Fotografierens zu sehen. In der analogen Welt benötigte man früher eine

Abb. 2.2 Disruptive Innovation: Fotografieprozess. (Quelle: piqsels)

2.2 Geschäftsmodellinnovationen

29

Kamera und einen Film. Man konnte dann ein Motiv fotografieren, musste allerdings mit der Entwicklung des Films so lange warten, bis dieser vollständig abgelichtet worden war. Dann musste der Film zum Entwickeln in ein Fotogeschäft gebracht werden, wobei Wartezeiten entstanden. Nach Erhalt der Abzüge wurden diese in ein Album geklebt. Bei benötigten weiteren Abzügen – etwa zum Versand an Freunde – mussten diese erneut von einem Fotogeschäft angefertigt und anschließend per Post versendet werden. Dieser Prozess ist heute in sich zusammengefallen. Bei einem Smartphone ist das Fotografieren lediglich eine von vielen Funktionen. Sie ist quasi ständig verfügbar und Bilder können sofort angesehen, gespeichert und per Knopfdruck in alle Welt versendet werden. Diese disruptive Innovation hat zu weitreichenden Veränderungen des Marktes geführt. Das Weltunternehmen Kodak, mit zigtausend Mitarbeitern, musste im Jahr 2012 Konkurs anmelden. Das Internetunternehmen Instagram zur Nachbearbeitung und zum Teilen digitaler Fotos und Videos wurde hingegen im gleichen Zeitraum für rund eine Milliarde US-Dollar an das Unternehmen Facebook verkauft. Dabei betrieben weniger als 20 Mitarbeiter den Online-Dienst. Eine besonders bittere Pointe ist dabei, dass das Unternehmen Kodak im Besitz der Patente für die digitale Fotografie war, diese aber nicht erfolgreich verwerten konnte. Hier wurde es Opfer des Innovator’s Dilemma Effektes. Abb. 2.3 zeigt weitere Beispiele für digitale oder stark digital unterstützte Geschäftsmodelle, die klassische analoge Produkte bedrängen. Nur flexibel aufgestellte Unternehmen wie das Composable Enterprise können diesen Wettbewerb bestehen.

Abb. 2.3 Disruptive Innovationen/Innovator’s Dilemma. (Quelle: siehe © pro Bild)

30

2.3

2

Innovationsfreude als Merkmal des Composable Enterprise

Innovator’s Dilemma vermeiden

Bestehende (noch) erfolgreiche Unternehmen haben Schwierigkeiten, ihre Geschäftsmodelle grundsätzlich zu ändern und öffnen damit Start-Up-Unternehmen die Möglichkeit, disruptiv und aggressiv den Markt zu verändern. Dieses von Christensen erkannte Phänomen wird als „Innovator’s Dilemma“ bezeichnet (Christensen, 1997). Dabei spielen auch menschliche Faktoren eine Rolle. Manager, die bisher in ihrem Umfeld und mit ihren Kompetenzen erfolgreich waren, sind nur schwer zu bewegen, jüngeren Mitarbeitern mit anderen und neuen Kompetenzen, ihren Platz zu überlassen. Die in Abb. 2.3 genannten Beispiele sind dazu typisch. Das Internetunternehmen Airbnb, das über keine eigenen Raumkapazitäten verfügt, sondern lediglich (private) Anbieter von Übernachtungsmöglichkeiten mit Interessenten verbindet, wurde von Studenten gegründet und besitzt bereits eine Marktkapitalisierung in der Größenordnung von bekannten internationalen Hotelkonzernen. In der Zeit, in der das Unternehmen Amazon aus einer Garagengründung zu einem Weltunternehmen aufstieg, musste das deutsche Traditionsunternehmen Quelle Konkurs anmelden. Beide hatten als Geschäftsmodell den Versandhandel – Quelle mehr auf Basis eines Papierkatalogs, während Amazon bereits die digitale Welt eroberte. Auch in der Automobilindustrie steht eine Revolution an. Zusammen mit der Digitalisierung von Infotainment-Anwendungen ist der Elektroantrieb mit seiner digitalen Unterstützung ein Game Changer. Der digitale 3D-Druck bedrängt klassische materialabhebende Verfahren. In der Finanzwelt bedrängen FinTechs und digitale Währungen klassische Geschäftsmodelle der Banken. Die Liste lässt sich fast beliebig für alle Branchen fortsetzen. Bestehende erfolgreiche Unternehmen sollten selbstkritisch das Phänomen des Innovator’s Dilemma beachten und durch mutige digitale Erweiterungen ihres Geschäftsmodells die digitale Welt annehmen. Dazu bietet das Composable Enterprise die Richtung und das geeignete Vorgehen, um das bestehende Unternehmen mit seinem Geschäftsmodell schrittweise zu transformieren.

Literatur Christensen, C. M. (1997). The innovator’s dilemma: When new technologies cause great firms to fail. Boston: Harvard Business School Press. Osterwalder, A., & Pigneur, Y. (2011). Business Model Generation: Ein Handbuch für Visionäre, Spielveränderer und Herausforderer. Frankfurt am Main: Campus.

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling im Metaverse

Zusammenfassung Die Nutzung von Innovationspotenzialen für neue Geschäftsideen erfordert die Kenntnis der bestehenden Ausgangssituation, also der bestehenden Geschäftsmodelle und -prozesse. Nur dann können schnell Änderungen oder Erweiterungen angefügt werden. Dieser Schritt trifft in vielen Unternehmen auf eine häufig über Jahrzehnte gewachsene Prozess- und IT-Landschaft aus heterogener Hard- und Software ohne ausreichende Dokumentation. Diese Landschaft muss gegebenenfalls soweit nachdokumentiert werden, dass die Schnittstellen zwischen Alt- und Neusystemen definiert werden können. Nur so kann die Transformation gelingen und Voraussetzung für ein composable Enterprise sein. Methoden wie ARIS-EPK und BPMN werden dazu vorgestellt und an einem Beispiel demonstriert. Die Erweiterung der Prozessmodellierung führt zur Beschreibung der gesamten Unternehmenszusammenhänge in einer Unternehmensarchitektur (Enterprise Architecture). Dazu wird das ARIS-Haus als Rahmenkonzept herausgestellt und Wege zur automatischen Erstellung und Pflege einer EA gezeigt. Technologien wie digitale Zwillinge und die virtuellen Welten des Metaverse eröffnen dazu fantasievolle Perspektiven. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Die Abb. 3.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_3

31

3

32

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Abb. 3.1 Process Model; Enterprise Architecture. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

3.1 Geschäftsprozessmodellierung Ein Geschäftsprozess ist eine Folge von Funktionen zur Erzeugung eines Mehrwertes für eine Organisation und seine Kunden. Typische Beispiele sind die Kundenauftragsabwicklung (order to cash) oder die Produktentwicklung. Die Prozessorganisation, also die Gestaltung von Geschäftsprozessen von ihren Startereignissen bis zu ihren Abschlüssen, als „end to end“ bezeichnet, hat seit Anfang der 1990er Jahre den Erfolg des ITEinsatzes in Unternehmen begründet und das bis dahin bestehende IT-Paradoxon gelöst (Solow, 1988). Dieses besagte, dass in den 80er Jahren des vorigen Jahrhunderts in den USA entgegen der Erwartung eine negative Korrelation zwischen den Aufwänden für IT und der Produktivitätsentwicklung beobachtet wurde. Der Grund dafür war nach Meinung des Verfassers, dass die bestehende funktionale Organisation beim Einsatz der IT nicht angepasst wurde. Es wurden zwar einzelne Funktionen unterstützt oder sogar automatisiert, aber es entstanden hohe Kosten für die häufig manuelle Datenübertragung zwischen den Funktionen, redundante Datenhaltungen und Doppelarbeiten durch das Nebeneinander von digitalen Funktionen und der bestehenden Papierorganisation. Erst die ganzheitliche Unterstützung der Prozesse durch integrierte Datenbanken und darauf aufbauende ERP-Systeme ermöglichten die Verschlankung der Prozesse, die Zusammenführung verschiedener Tätigkeiten an den Arbeitsplätzen sowie die Verringerung von Datenübertragungen und haben inzwischen dramatische Produktivitätssteigerungen erzeugt. Bei der Digitalisierungsstrategie des Composable Enterprise dürfen deshalb keine halbherzigen Entscheidungen getroffen werden, sondern konsequent Geschäftsmodell, Geschäftsprozesse, Organisation und Anwendungssysteme aufeinander ausgerichtet werden. Bereits in den 1980er Jahren wurden „bottom up“ bei der Implementierung von ITSystemen die Vorteile der Organisation ganzheitlicher Prozesse erkannt. Dabei war der Begriff Prozess noch nicht gebräuchlich und er wurde z. B. als Vorgangskette bezeichnet (Scheer, 1984). Dazu wurden konkrete Methoden zur Modellierung von Geschäftsprozes-

3.1 Geschäftsprozessmodellierung

33

Abb. 3.2 ARIS Bücher; 1. Auflage 1991; 4. Auflage 2002

sen entwickelt, die der Autor mit dem ARIS-Konzept und der darauf aufbauenden ARISSoftware maßgeblich mitgestalten konnte (Scheer, 1991; vgl. Abb. 3.2). Die Abkürzung ARIS steht für „Architektur integrierter Informationssysteme“ und betont die Integration der Funktionen zu Prozessen über eine gemeinsame Datenbank. Für die strategische Einführung einer Prozessorganisation wurden Anfang der 1990er Jahre „Top-down“-Ansätze entwickelt (Hammer & Champy, 1993) in denen z. B. diskutiert wurde, ob ein radikaler Ansatz „auf der grünen Wiese“ verfolgt werden soll – oder eher ein kontinuierliches Reengineering der Prozesse. Für die Entwicklung prozessorientierter Software und ihre Implementierung ist aber die operative Prozessmodellierung maßgeblich geworden. Das ARIS Konzept bildet einen Rahmen zur Modellierung von Geschäftsprozessen. Aus Modellen für Daten, Funktionen, Organisation und Produkten wird das Geschäftsprozessmodell gebildet (vgl. Abb. 3.3). Auf Basis des ARIS Konzeptes. wurde unter Leitung des Verfassers und Dr. Wolfram Jost von dem Unternehmen IDS Scheer AG das Softwareprodukt ARIS Toolset entwickelt. Mit ihm können grafische Modelle erstellt und verwaltet werden. Die erste Version erschien 1992 und wird nach dem Verkauf der IDS Scheer AG im Jahr 2009 von dem Unternehmen Software AG weiterentwickelt. Die Architektur der Software wurde methodenunabhängig gestaltet, so dass neben den ARIS-Standardmethoden auch kundenindividuelle Ergänzungen sowie andere Modellierungsmethoden unterstützt werden. Geschäftsprozesse haben sich als treibendes Prinzip einer modernen digitalen Anwendungsarchitektur in Theorie und Praxis durchgesetzt. Es existiert eine vielfältige Spezialliteratur und Prozessmodellierung ist einer der Leitgedanken von Standardwerken zur Wirtschaftsinformatik (Hansen et al., 2019; Leimeister, 2021; Krcmar, 2015). Aus dem ARIS-Konzept hat sich zur fachlichen Modellierung von Geschäftsprozessen die grafische EPK-Notation (Ereignisgesteuerte Prozesskette bzw. EPC = Event Dri-

34

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Abb. 3.3 Zusammensetzung eines EPK-Prozessmodells aus den einzelnen Sichtmodellen

ven Process Chain) zur Modellierung von Geschäftsprozessen besonders durchgesetzt (Fleischmann et al., 2020; Gadatsch, 2020; Weske, 2019; Weber et al., 2022; Laue et al., 2021). Das ARIS-Haus der Abb. 3.3 zeigt die Sichten Daten, Organisation, Funktionen und Produkte, und wie diese zu einem Geschäftsprozess in Form einer EPK zusammengesetzt werden.1 Ein EPK-Modell in Abb. 3.3 und 3.4 beschreibt den Kontrollfluss eines Geschäftsprozesses. Funktionen werden durch abgerundete Rechtecke, Ereignisse durch Sechsecke und logische Konnektoren durch Kreise dargestellt. Die logischen Konnektoren „und, oder und exklusives oder“ steuern das Teilen (Split) eines Prozesses in Prozessarme und das Zusammenführen (Join) von Prozessarmen. Die Elemente werden durch gerichtete Linien verbunden. Gerade die wenigen Konstrukte und damit die Einfachheit der EPK-Notation haben den Erfolg der Methode maßgeblich gefördert. Entsprechend den Sichten des ARIS-Hauses ist in EPK-Prozessmodellen die Zuordnung von Funktionen zu Organisationseinheiten, Datenobjekten und Arbeitsergebnissen (Deliverables) vorgesehen. Dieses wird häufig gegenüber dem reinen Kontrollfluss als erweiterte EPK (eEPK) bezeichnet. Diese Zuordnungen sind aber von vornherein im Sichtenkonzept von ARIS vorgesehen.

1

Siehe dazu auch ein Beispiel in Fleischmann et al., S. 47.

3.1 Geschäftsprozessmodellierung

35

Abb. 3.4 EPK-Prozessmodell einer einfachen Auftragsbearbeitung

In der Praxis sind weltweit zahlreiche EPK-Modelle erstellt worden und die Methode ist so zu einem de facto Standard geworden2 . Grundzüge der Methode werden an dem Beispiel einer Kundenauftragsbearbeitung erläutert, siehe Abb. 3.4. Das Beispiel der Abb. 3.4 wird später im Kap. 7 (Insight durch Process Mining) weiter verwendet. Ereignisse zeigen (Entscheidungs-)Ergebnisse von Funktionen und lösen neue Funktionen aus. Trivialereignisse, die lediglich den Start oder das Ende einer Funktion darstellen, können zur besseren Übersichtlichkeit fortgelassen werden. Anfangs- und Endereignisse starten bzw. beenden den Prozess. Neben der Kontrollstruktur sind den Funktionen die ausführenden Organisationseinheiten zugeordnet. Die erste Funktion ist die Kundenauftragserfassung. Nach ihrer Bearbeitung schließt sich entweder eine Kreditwürdigkeitsprüfung des Kunden an oder es beginnt sofort die Auftragsbearbeitung. Dieses wird während der Auftragserfassung, z. B. anhand der Auftragshöhe, entschieden. Beide Wege schließen sich gegenseitig aus (XOR). Damit teilt sich der Prozess. Bei negativem Ergebnis der Kreditprüfung wird der Auftrag abgelehnt. Anschließend wird der Kunde darüber informiert und der Prozess ist zu Ende. Bei positivem Prüfergebnis kann mit der Bearbeitung begonnen werden, ebenso, wenn der Auftragswert unter der Entscheidungsgrenze für eine Prüfung liegt. Beide Wege schließen sich aus (XOR). Mit dem Ende der Bearbeitung werden Kunde und der Finanzbereich für die buchhalterische Verfolgung informiert. Wenn Finanzbereich und (AND) Kunde informiert sind, ist auch dieser Prozessweg abgeschlossen. Das Modell umfasst alle drei möglichen Abläufe (Sofortbearbeitung, Ablehnung nach negativer Kreditprüfung, Bearbeitung nach positiver Kreditprüfung) und stellt sie komprimiert dar. Jede Funktion ist nur einmal, und damit redundanzfrei, aufgeführt. 2

Leider haben es der Verfasser und das Unternehmen IDS Scheer AG sowie nach 2009 die Software AG versäumt, die ARIS-EPK-Methode von einer internationalen Organisation wie der ISO oder OMG offiziell standardisieren zu lassen.

36

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Die Zusammenfassung aller Einzelfälle der Abläufe in einem Modell macht dann Sinn, wenn das Modell verständlich ist und die Verfolgung der Einzelfälle wegen ihrer hohen Anzahl zu unübersichtlich ist. In diesem Beispiel sind lediglich drei Prozessabläufe enthalten, deshalb ist die Modelldarstellung für den Sachverhalt eher zu komplex. Dieses ist aber lediglich auf die didaktische Ausrichtung des Beispiels zurückzuführen. In neuerer Zeit hat sich auch die Methode BPMN (Business Process Model and Notation) als von der OMG im Jahr 2008 als Standard anerkannte Modellierung von Geschäftsprozessen etabliert (vgl. OMG, 2008). Sie ist durch eine Vielfalt unterschiedlicher Symbole semantisch reichhaltiger als ARIS, aber damit auch komplexer. Die BPMN-Darstellung der Auftragsbearbeitung zeigt Abb. 3.5. Die Darstellungselemente der beiden Methoden sind ähnlich. Die Konnektoren werden bei BPMN als Diamanten dargestellt. XOR werden durch ein X und AND durch ein Plus ersetzt. Die Ereignisse werden durch Texte an die eingehenden oder ausgehenden Pfeile ersetzt. Ein Unterschied ist die Darstellung der organisatorischen Verantwortlichkeiten (Rollen). Bei der EPK werden Organisationseinheiten in einer gesonderten Sicht definiert und den Funktionen zugeordnet. Bei BPMN wird mit den Konstrukten Pool- und (Swim-)Lanes eine grafische Ordnung der Funktionen erreicht. Ein Pool bezeichnet übergeordnete Organisationseinheiten, hier Unternehmung und Kunde. Lines sind die Rollen (hier Vertrieb und Finanzabteilung) der Bearbeitungsinstanzen innerhalb eines Pools. Ihnen werden die Funktionen und Konnektoren zugeordnet. Pools und Lines gliedern die Prozesse anschaulich. Der Kontrollfluss wird durch Pfeile dargestellt und Informationsflüsse durch gestrichelte Linien. Bei dem Beispiel erscheint die BPMN-Darstellung gegenüber der EPK übersichtlicher. Dieser Eindruck wird bei der EPK hauptsächlich durch die explizite Darstellung der Ereignisse und Organisationseinheiten erzeugt, während von der umfangreichen BPMNNomenklatur nur ein geringer Teil verwendet wird.

Abb. 3.5 Auftragsbearbeitung als BPMN-Diagramm

3.2 Entwicklung Soll-Prozessmodell und Business Capabilities

37

Bei der Behandlung der Logdateien des Process Minings in Kap. 7 und generell bei einer technischen Ereignissteuerung von IT-Systemen ist aber die explizite Darstellung von Ereignissen bei der EPK von Vorteil. In der neueren Literatur zum Geschäftsprozessmanagement werden in der Regel beide Notationen erörtert. Bei Vergleichen komplexer Modelle mit Nutzung der vielfältigen BPMN-Symbole wird die Einfachheit der EPK-Notation als Vorteil herausgestellt (z. B. Laue et al., 2021, S. 151). Im Weiteren werden beide Notationen je nach ihren Schwerpunkten verwendet3 . Da in einem Unternehmen mehrere Hundert operative Geschäftsprozesse bestehen, ist ihre Strukturierung in einer Geschäftsprozessarchitektur sinnvoll. Diese kann z. B. nach fachlichen Gesichtspunkten in wertschöpfende (Kernprozesse) und in Unterstützungsprozesse gegliedert sein. Die einzelnen Prozesse werden dann hierarchisch in wertschöpfende Schritte untergliedert und mit Varianten versehen. In der feinsten Ebene können dann die operativen Arbeitsschritte mit den Transaktionen der ERP Software verbunden werden. Weitere Methoden zur Strukturierung von Geschäftsprozessen sind z. B. Wertschöpfungsnetzwerke über Unternehmensgrenzen hinweg zu Kunden und Lieferanten. Einen Überblick über aktuelle Entwicklungen zum Business Process Management geben Polyvyanyy et al., (2021).

3.2 Entwicklung Soll-Prozessmodell und Business Capabilities Bei der digitalen Transformation zum Composable Enterprise stehen die neu entwickelten Geschäftsprozesse als Soll-Prozesse im Vordergrund. Die bestehenden Prozesse werden deshalb nur soweit nachmodelliert oder automatisch durch Process Mining erhoben, wie sie für das Verständnis der Ausgangssituation und das Andocken der neu entwickelten Prozesse erforderlich sind. Bei der Architektur des Composable Enterprise vollzieht sich der Modellierungsprozess in zwei Stufen. Zunächst wird der gesamte Geschäftsprozess beschrieben und anschließend die Business Capabilities, also kleinere Subprozesse, die für sich eine betriebswirtschaftlich sinnvolle Einheit bilden, aber zu den Funktionen des Gesamtprozesses in einer n:m Beziehung stehen können.

3.2.1 Soll-Prozessmodell Das Soll-Prozessmodell ist eine Blaupause oder Template, nach der die einzelnen Ausprägungen der Prozesse (Prozessinstanzen) ablaufen sollen. Das Modell beschreibt keine ein3

In dem Softwaresystem ARIS, das seit 2009 von der Software AG weiterentwickelt und vertrieben wird, werden wegen seiner Methodenunabhängigkeit beide Ansätze unterstützt.

38

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

zelnen Abläufe, sondern das durch das Modell komprimierte erwünschte Prozessverhalten mit sinnvollen Varianten. Eine einzelne Prozessinstanz ist ein Weg durch das Modell vom Start bis zum Ende. In dem Modell der Abb. 3.4 sind es drei Instanzen. Von einigen Software- und Beratungsunternehmen werden vorgefertigte Prozessmodelle für verschiedene Branchen angeboten. Diese stellen typische Abläufe dar, die aus Projekterfahrungen abgeleitet werden. Mit dem SPR (Scheer Performance READY) der Scheer GmbH steht z. B. eine prozessorientierte Komplettlösung, bestehend aus Werkzeugen, Vorgehensweisen und eine Bibliothek von Branchen- und Best-Practice-Modellen zur Verfügung, die auch auf die Inhalte der SAP-Software ausgerichtet sind und den Kunden bei dem Entwurf ihrer individuellen Soll-Modelle unterstützen (vgl. Abb. 3.6) sollen. Für 9 Branchen bestehen Best-Practice-Lösungen für über 5000 Geschäftsprozesse. Sie werden von Übersichtskacheln schrittweise zu detaillierten Prozessmodellen verfeinert. Diese werden durch SAP-Referenzprozesse, Kennzahlen, Organisationsstrukturen und Datenobjekte ergänzt. Neben der branchenorientierten Sicht erlaubt die Architektur des SPR auch einen Zugang über eine Szenario-orientierte Sicht, in der über End-to-EndProzesse auf die detaillierten Prozessmodelle zugegriffen werden kann. In SPR spiegelt sich das Erfahrungswissen aus vielen Kundenprojekten wider, insbesondere im Zuge von SAP-Implementierungen. Auf Basis des in SPR hinterlegten Referenzmodells wird dann ein kundenspezifisches Modell entwickelt. Die SAP AG hat mit der Übernahme des Geschäftsprozess-Softwarehauses SIGNAVIO, der Entwicklung des OPAL (One Process Acceleration Layer) und ihrem RISEKonzept ein starkes Bekenntnis zu einem modellgestützten Geschäftsprozessmanagement gegeben. Dieses wird das modellgestützte Vorgehen in Unternehmen weiter verstärken.

Abb. 3.6 Scheer Performance Ready (SPR) – Referenzprozesse. (Quelle: Adobe Stock, siehe © pro Bild)

3.2 Entwicklung Soll-Prozessmodell und Business Capabilities

39

3.2.2 Fachliche Business Capabilities Ein entwickeltes Soll-Prozessmodell stellt die fachliche Prozesslösung für eine Innovationsidee dar und ist somit das Master-Prozessmodell der Gesamtlösung. Es soll flexibel für Änderungen und Erweiterungen sein. Deshalb wird das Modell in kleinere Einheiten, den fachlichen Business Capabilities, zerlegt, die unabhängig voneinander geändert werden können und über definierte fachliche Schnittstellen neu zusammengestellt werden können. Die Business Capabilities können nach dem gleichen Konzept und mit den gleichen Modellierungsmethoden entworfen werden wie das Mastermodell, lediglich auf einer differenzierteren Ebene. Im Vordergrund steht der interne Kontrollfluss, aber es können auch Datenobjekte und Organisationseinheiten hinzugefügt werden. Im Rahmen der Softwareentwicklung werden in Kap. 5 aus den fachlichen Business Capabilities die implementierbaren PBCs erstellt. Dazu wird für die Funktionen der Programmcode entwickelt sowie Dateizuordnungen, Betriebssysteme, Hardwareeinheiten sowie Hilfsprogramme hinzugefügt, zu einem (Micro-)Service zusammengestellt und in einem Software-Container abgelegt, der selbstständig auf unterschiedlicher Hardware ablauffähig ist. Das Master-Prozessmodell ist dann die Blaupause für die Montage oder Composition der Business Capabilities zu einer Anwendung und einem Geschäftsprozess. Die Hierarchie der Elemente mit ihren n:m-Beziehungen ist in Abb. 3.7 zusammengefasst.

Abb. 3.7 n:m-Beziehungen zwischen den Elementen

40

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

3.3 Enterprise-Architecture (EA) zur Beherrschung der Komplexität von Unternehmen Geschäftsprozessmodelle führen zu einer besseren Transparenz und einem besseren Verständnis des Unternehmens, bilden aber in ihrer Summe für ein Unternehmen selbst ein komplexes Gebilde und verlangen ein ordnendes Rahmenkonzept. Dieses wird als Enterprise Architecture (EA) bezeichnet. Prozesse spielen im EA-Konzept eine zentrale Rolle, das Konzept geht aber auch darüber hinaus. EA-Konzepte werden seit rund 4 Jahrzehnten entwickelt und eingesetzt. Sie dienen dazu, die Komplexität eines Unternehmens durch Strukturierung leichter verständlich und beherrschbar zu machen. Unter Architektur werden dabei einmal die grundlegenden Prinzipien verstanden, nach denen die Strukturierung erfolgen soll. Diese werden auch als Rahmenwerk bezeichnet. Zum anderen wird auch das Ergebnis eines Architekturentwurfs als Architektur bezeichnet. Eine Enterprise Architecture beschreibt damit den Zusammenhang zwischen den Strukturen und Prozessen eines Unternehmens. Über diese Zusammenhänge einen transparenten Überblick zu haben, ist gerade bei der Transformation zu einem Composable Enterprise besonders wichtig. Viele Unternehmen haben kein genaues Wissen über ihre bestehenden Informationssysteme, die in einem längeren Zeitraum entstanden sind. Auch kennen sie den Markt neu verfügbarer Lösungen nicht intensiv oder können deshalb nicht beurteilen, wie und mit welchem Aufwand sie in die bestehende Landschaft eingeführt werden können. Deshalb weckt der Plan, ein Transformationsprojekt zu starten, häufig eher Ängste als Begeisterung. Mit einem EA-System können diese Vorbehalte reduziert werden, indem Fragen folgender Art beantwortet werden können, die zu einem besseren Verständnis und besserer Transparenz der Situation führen: „Welche Organisationseinheiten arbeiten an einem bestimmten Geschäftsprozess; in welchen Geschäftsprozessen ist eine bestimmte Funktion enthalten; welche Daten werden für die Bearbeitung einer Funktion benötigt; auf welchen Servern ist ein bestimmtes Datenelement gespeichert; welche Anwendungssysteme unterstützen einen bestimmten Geschäftsprozess; welche Organisationseinheiten sind an einem bestimmten Geschäftsprozess beteiligt; welche Prozesse werden für ein bestimmtes Produkt benötigt usw.“ Diese Transparenz hilft, ein erfolgreiches Transformationsprojekt zu identifizieren, zu planen und zu implementieren. Gleichzeitig ist die dokumentierte neue Lösung eine gute Ausgangsposition für weitere Verbesserungen. Von J. Zachman wurde bereits 1987 ein EA-Konzept vorgestellt, das heute immer noch als Vergleichsreferenz für andere Ansätze herangezogen wird. Zachman gliedert sein Rahmenkonzept nach dem Informationsbedarf der Benutzertypen und der Art der benötigten Informationen (Zachman, 1987). Unabhängig von Zachman wurde 1991 von dem Verfasser das bereits eingeführte ARIS-Konzept veröffentlicht (vgl. das ARIS-Haus in Abb. 3.8). Obwohl das ARIS-Konzept, wie die Langfassung mit „Architektur integrierter Informationssysteme“ bezeichnet, für die Strukturierung von IT-Landschaften entwickelt wurde, erfüllt sie die Anforderun-

3.3 Enterprise-Architecture (EA) zur Beherrschung der Komplexität von Unternehmen

41

Abb. 3.8 ARIS-Konzept – Konzept zur Modellierung von Geschäftsprozessen. (Quelle: Scheer, 1991, 2001, 2002)

gen eines generellen EA-Ansatzes und wird in der Fachliteratur entsprechend eingeordnet und von Unternehmen eingesetzt4 . Inzwischen zählen Veröffentlichungen zu EA mehr als 100 Rahmenwerke auf, die sich nach Sichtenbildung, inhaltlicher Ausrichtung und Werkzeugverfügbarkeit nur geringfügig unterscheiden. Es gibt spezielle Konzepte für öffentliche Institutionen, Militär, IT-Unternehmen und wissenschaftliche Institutionen. Alle verfolgen aber den gleichen Zweck, die Komplexität des Beschreibungsobjektes „Enterprise“ besser beherrschen zu können, Beschreibungsmethoden zu standardisieren, die Kommunikation zwischen den Stakeholdern zu verbessern, das Datenmanagement und die Integration zu unterstützen und Unternehmensentscheidungen eine bessere Grundlage zu geben. Das ARIS-Konzept ist wegen seiner weiten Verbreitung, seinen vielen eingeflossenen Erfahrungen, verfügbaren Inhalten durch Referenzmodelle, sein breites Methodenangebot und seine erprobte Werkzeugunterstützung ein effektiver Ansatz.

4

Urbaczewski und Mrdalj (2006), Lankhorst et al. (2017), Matthes (2011).

42

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Eine erste Strukturierung wird im ARIS-Konzept durch die Aufteilung der Beschreibung in die bereits eingeführten fünf unterschiedlichen Sichten: Organisation (Ressourcen), Funktionen, Daten und Leistung (als Ergebnis einer Funktionsbearbeitung) erreicht. Die Verbindungen zwischen den Sichten, z. B. welche Daten von einer Funktion benötigt werden, wird durch die Prozesssicht hergestellt. Durch ein IT-Lifecycle-Konzept werden die einzelnen Sichten des Prozessmodells schrittweise von der organisatorisch-fachlichen Ebene über die Design-Phase in die ITImplementierung umgesetzt. Das Ebenenkonzept ist eine weitere Strukturierung der Prozessdarstellung. Das Fachkonzept kann dadurch auch mit technischen Objekten verbunden werden. So befindet sich eine technisch spezifizierte PBC auf der Designebene und eine konkret entwickelte PBC in einer bestimmten Version auf der Implementierungsebene. Somit kann z. B. die Frage beantwortet werden, welche Packed Business Capability in welchem Release der Implementierung eine bestimmte betriebswirtschaftliche Funktion in einem bestimmten Prozess unterstützt. In Abb. 3.8 sind den Sichten und Ebenen Symbole für Beschreibungsmethoden zugeordnet. Diese sind lediglich Stellvertreter für Beschreibungsmethoden, die entsprechend der Entwicklung der Informationstechnik auf den Ebenen eingesetzt werden. Gerade neuere Entwicklungen der IT wie Cloud und Edge Computing erhöhen die Komplexität und erfordern eine größere Transparenz der Struktur und Arbeitsweise eines Unternehmens, wie es ein EA-Konzept ermöglicht. Ein ERP-System umfasst einen großen Teil der Anwendungen eines Unternehmens. Ein Enterprise-Architecture-Konzept strukturiert es und erhöht die Transparenz der IT. Zusammengefasst besteht ein EA-Konzept aus einem Rahmenkonzept wie dem ARISHaus, das die grundsätzlichen Bauelemente und ihre Beziehungen beschreibt. Den Beschreibungssichten werden Beschreibungsmethoden zugeordnet. Die dabei verwendeten Konstrukte bilden das Datenmodell der Repositories. Dessen Ausprägungen bilden dann das Datenmodell eines konkreten EA für ein Unternehmen. Die nach dem Datenmodell konfigurierte Datenbank nimmt dann die entsprechenden Unternehmensmodelle auf. Zum Management des EA wird ein Werkzeug wie die ARIS-Software zum Anlegen der Modelle, zur Pflege und Auswertung benötigt.

3.4 Wege zur automatisierten Enterprise Architecture Manche Unternehmen fürchten einen hohen Aufwand zur Einführung eines kompletten EA-Systems. Der Aufwand besteht einmal in der Erstellung der Modelle und zum anderen in deren dauerhafter Pflege. Der Nutzen einer hohen Transparenz des Unternehmens, einer einheitlichen Sprachregelung und einer gut dokumentierten Ausgangslösung für geplante Unternehmensveränderungen wiegt nach der Meinung von Kritikern diesen Aufwand nicht auf. Die Transparenz würde nicht ständig gefordert, sondern eher fallweise für größere Reorganisationen oder Unternehmenszusammenschlüsse benötigt. Auch wären bei

3.4 Wege zur automatisierten Enterprise Architecture

43

kleineren Reorganisationen eher Ausschnitte erforderlich, für die sich der Aufwand für ein Gesamtmodell nicht lohnen würde. Ein wesentliches Element eines Composable Enterprise ist seine dezentrale modulare Struktur. Das Unternehmen wird also in kleinere selbstständige Einheiten aufgeteilt, für die jeweils überschaubarere EA-Modelle aufgestellt werden. Damit werden die Argumente der Komplexität bereits relativiert. Den kritischen Argumenten kann weiter durch eine stärkere Automatisierung von Erstellung und Pflege des EA-Ansatzes begegnet werden. Ziel ist eine nahezu automatische Entwicklung und Pflege der Enterprise Architecture. Hierzu gibt es mehrere Ansatzpunkte. Bei einer modellgestützten Einführung eines neuen Geschäftsprozesses sind mit den Modellen bereits Bausteine für eine EA enthalten. In dem Projekt werden Prozess-, Datenund Anwendungssoftwaremodelle von dem Berater oder Softwareanbieter mitgeliefert. Auch werden sie, wie bei dem genannten SPR-Ansatz der Scheer GmbH, bereits über mehrere Ebenen von der fachlichen Sicht bis zur Implementierung geführt. Auch neue Anwendungssysteme, die mit hier beschriebenen Plattformen entwickelt werden, dokumentieren sich automatisch in einer EA-gerechten Form. Diese Ansätze folgen schrittweise Top-Down vom Entwurf des Fachkonzeptes bis zur IT-Implementierung. Ein weiterer Ansatz zur Automatisierung des EA-Systems folgt einem Bottom-up-Ansatz. Dieser geht von der Ausführung der Geschäftsprozesse aus. Die dort eingesetzten Anwendungssysteme speichern Daten über die ausgeführten Transaktionen wie deren Start und Ende in sogenannten Logdateien. Die Transaktionen entsprechen weitgehend betriebswirtschaftlichen Funktionen. Aus den Zeitdaten können Vorgänger- und Nachfolgebeziehungen der Funktionen durch Algorithmen erkannt werden, kurz, es können aus den einzelnen ausgeführten Prozessinstanzen Prozessmodelle automatisch erstellt werden. Dieses Vorgehen wird als Process Mining bezeichnet und im Kap. 7 näher beschrieben. Aus den für einen Zeitraum gespeicherten Instanzenmodellen können dann pro Prozesstyp (wie Kundenauftragsbearbeitung oder Einkauf) automatisch die Prozessmodelle erstellt werden, die alle in dem Zeitraum angefallenen Prozesswege enthalten. Im Gegensatz zu den Top-down aufgestellten Prozessmodellen, die die gewünschten Abläufe eines Prozesstyps darstellen, bildet das durch Mining gewonnene Modell die realen Abläufe ab. Damit stehen prinzipiell sowohl Modelle aus der Top-down-Projektarbeit eines Transformationsprojektes als auch Bottom-up aus dem Prozess Mining der laufenden Prozessbearbeitung zur Verfügung. Leider werden diese Modelle aber nicht oder kaum in ein EA systematisch eingestellt und aktualisiert. Sie dienen lediglich nach Abschluss eines Einführungsprojektes der Projektdokumentation oder beim Process Mining einer kurzfristigen Prozessanalyse. Würden sie dagegen für ein EA-Konzept genutzt, könnten die Modelle längerfristig verwendet und der Betrieb der EA erheblich automatisiert werden.

44

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

3.5 Erweiterung zu einem dynamischen automatisierten EA-System In dem bisher beschriebenen EA-Konzept werden manuell oder automatisch erstellte Modelle eingebunden, also Ergebnisse von Modellierungsarbeiten oder des Process Minings. Die Entstehungsgeschichte dieser Modelle durch Handlungen, Entscheidungen und Verantwortlichkeiten innerhalb der Projekte werden dagegen nicht dokumentiert. Nachträgliche Fragen über Verantwortlichkeiten von Änderungen oder Entscheidungen im Projektablauf sind deshalb nur schwer festzustellen. Fragen wie „Ist eine bestimmte Schulung für ein konkretes Thema rechtzeitig zu einem bestimmten Projektzustand durchgeführt worden“ oder „Wer hat wann welche Modellierungsschritte ausgeführt?“ sind deshalb nicht zu beantworten. Es fehlt an dauerhafter Transparenz über den Projektablauf, Projektstand und die Projektzukunft. Bekannte digitale Projektplanungswerkzeuge bilden zwar Teilaspekte wie die Termin-, Kapazitäts- und Kostenplanung ab, aber in einer eigenen Systemumgebung. Modellierungswerkzeuge zur Prozessgestaltung besitzen ebenfalls eine eigene Datenhaltung. Auch die Systemdokumentationen und Schulungsdokumente von ERP-Systemen sind individuell vom Hersteller organisiert. Es besteht ein großes Bündel aus internen und externen Papier- und digitalen Dokumenten, die von unterschiedlichen Akteuren in unterschiedlicher Organisationsform erstellt und mehr oder weniger systematisch mit hohem Aufwand verwaltet werden. Es liegt deshalb nahe, den traditionellen Projektplanungsansatz auszuweiten und die genannten Dokumente laufend und systematisch in einem geschlossenen System zu erfassen und zu verwalten. Auf alle Dokumente kann so integriert zugegriffen und diese als Input der EA zugeführt werden. Das EA wird dynamisch aktualisiert und kann auch zeitlich zurückliegende Zustände aufrufen. Für diese Ausführungen wird ein konkreter Ansatz vorgestellt. Er beruht auf Erfahrungen aus Transformationsprojekten der Scheer GmbH. Das entwickelte Softwaresystem befindet sich bei Großprojekten zur Steuerung im praktischen Einsatz und soll perspektivisch zur dynamischen automatischen Nutzung von EA weiterentwickelt werden (Abb. 3.9). Während der Arbeit an einem Transformationsprojekt werden mit Modellierungswerkzeugen Prozessmodelle erstellt, mit Customizing-Software Anwendungssoftware implementiert, mit Projektsteuerungssoftware Projektpläne definiert sowie mit E-Learning-Systemen Schulungen durchgeführt. Die von diesen Werkzeugen erfassten Daten werden in ihren jeweiligen Dateien erfasst. Zusätzlich werden von dem System der Ablauf der Projektarbeit und die Verantwortlichkeiten der Akteure für die einzelnen Arbeitsschritte digital dokumentiert. Diese Daten werden dem System zur Verfügung gestellt. Kern des Systems ist die Event Database, in der alle Ereignisse der Projektarbeit weitgehend automatisch aus den benutzten Werkzeugen der Projektmitarbeiter erfasst werden. Es verweist über Events auf die Daten der einzelnen Systeme. Beteiligte Mitarbeiter sind externe Berater, Software- und Hardware-Lieferanten sowie die Projektmitarbeiter des Kunden. Sie bilden die Arbeitsebene mit ihren unterschiedli-

3.5 Erweiterung zu einem dynamischen automatisierten EA-System

45

Abb. 3.9 Architektur des Konzeptes „Digital Consulting“ zur Automatisierung der EA. (Quelle: Adobe Stock, PureSolution)

chen digitalen Werkzeugen wie Modellierungssoftware, Projektplanungssoftware, ELearning-Systeme oder ERP-Systeme. Die erzeugten Ereignisse sind Beginn des Customizings einer bestimmten Funktion einer Standard-Software, Verwendung eines Prozess-Referenzmodells, Anlegen eines Prozessmodells, Durchführung einer Schulungsmaßnahme, Abschluss eines Vorgangs in einem Projektsteuerungssystem oder Anlegen einer neuen Dokumentationsdatei. Ein Event umfasst im Wesentlichen die Art des Ereignisses, einen Zeitstempel, den Urheber des Events und verweist auf die Daten der Herkunftssysteme. Durch Verfolgung der Events kann die gesamte Entwicklung des Projektes mit allen Handlungen und Verantwortlichkeiten nachvollzogen werden. Auch kann nachträglich ein bestimmter Zustand des Projektes oder eines Teiles wieder hergestellt werden. Das technische Grundgerüst des Systems ist weit verbreitete Microsoft Software; die angeschlossenen Systeme, mit denen die Projektbeteiligten arbeiten, sind SAP, StandardPlanungssoftware und Werkzeuge der Unternehmen Scheer GmbH, Scheer PAS GmbH und imc AG. Mit der Integrationstechnik aus Scheer PAS werden einmal die Werkzeuge der Arbeitsebene integriert und zum anderen der Zugriff der Stakeholder für Auswertungen. Die Unternehmensleitung kann sich aktuell über Stand, Fortschritt und Zukunft des Projektes informieren. Die Projektleitung informiert sich z. B. über die weitere Planung und die Fachabteilung über die anstehende Arbeitsbelastung ihrer Mitarbeiter.

46

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Neben dem Monitoring sind wichtige Funktionen das Vergleichen mit den Projektverläufen ähnlicher Projekte (Benchmarking) sowie der Vergleich zwischen Ist- und Soll-Ablauf eines Projektes. Hierzu können entsprechende KPIs definiert und berechnet werden. Durch ein einheitliches Dashboard werden benutzerfreundliche übergreifende Analysen der Systeme möglich. Ein Transformationsprojekt ist in der Regel nicht mit dem „Go live“ abgeschlossen. Vielmehr finden laufend Releasewechsel und kleinere Änderungen der Software, inhaltliche Veränderung von Prozessen durch Aufnahme neuer Funktionen, organisatorische Veränderungen von Zuständigkeiten usw. statt. Deshalb kann das System vom Kunden über die Projektarbeit hinaus eingesetzt werden und wird damit zu einem echten automatisierten dynamischen Enterprise-Architecture-System. Es wird dabei keine EA-Datei im traditionellen Sinn erzeugt, sondern sie wird aus einer Ausgangslösung über die inzwischen eingetretenen Änderungsereignisse quasi „auf Knopfdruck“ generiert. So kann nachträglich auch ein früherer Zustand des EA hergestellt werden. Die Event-Datei wird dann zum Zentrum des EA-Ansatzes. So wird das EA-Modell aktuell gehalten und werden alle organisatorischen und technischen Änderungen über den gesamten Lifecycle des Unternehmens hinweg erfasst. Das Composable Enterprise erhält zur Unterstützung seiner Änderungsfreundlichkeit immer eine aktuelle Dokumentation. Diese hilft, neue Transformationsfelder zu entdecken, ihre gegenwärtigen Unterstützungssysteme mit ihrer Entstehungsgeschichte zu identifizieren sowie Schnittstellen zu angrenzenden Bereichen zu erkennen.

3.6 Digitaler Unternehmenszwilling im Metaverse Ein Digitaler Zwilling ist eine virtuelle Repräsentanz eines realen physischen Objektes oder eine Dienstleistung. Darüber hinaus kann der digitale Zwilling auch gegenüber der Realität zusätzliche Informationen als Augmented Reality (AR) enthalten. Bereits die behandelten Modelle eines EA-Ansatzes stellen einen statischen digitalen Zwilling eines Unternehmens dar. Mit dem Process Monitoring (siehe Kap. 7) wird sogar eine Real-Time-Lösung angenähert. Selbst das gesamte Informationssystem eines Unternehmens ist eine Art digitaler Zwilling, da es die Arbeitsrealität in den Statusänderungen seiner Daten widerspiegelt. In der Real-Time-Welt des Metaverse geht der Ansatz aber wesentlich weiter. Dazu wird ein digitaler Zwilling exakter definiert (Van der Valk et al., 2022). Es wird zwischen einem digitalen Modell, einem digitalen Schatten und einem „echten“ Digitalen Zwilling unterschieden. Bei einem digitalen Modell eines realen Objektes, wie einem Prozessmodel, wird lediglich die Realität beschrieben. Bei einem digitalen Schatten spiegelt das Modell in Echtzeit die Realität wider, beeinflusst aber die Realität nicht. Bei einem „echten“ digitalen Zwilling ist die Verbindung zweiseitig, d. h. auch Änderungen an dem Zwilling können auf die Realität übertragen werden.

3.6 Digitaler Unternehmenszwilling im Metaverse

47

Im Folgenden wird unter einem echten digitalen Zwilling in der Regel eine zweiseitig mit der Realität verbundene digitale Repräsentanz verstanden. Der digitale Zwilling eines Unternehmens umfasst dann Real-Time alle Zustände des Unternehmens. Änderungen in dem Realsystem werden unmittelbar auf den digitalen Zwilling übertragen und umgekehrt. Aber auch die Vorstufen geben bereits gute Einsichten. Die Architektur der Abb. 3.10 von Van der Valk et al. (2022) ist zwar für den digitalen Zwilling eines Produktionssystems wie eine Fabrik entwickelt worden, kann aber auch verallgemeinert werden. Ein digitaler Zwilling integriert Daten aus verschiedenen Datenquellen zur Steuerung und Auswertung (Simulation usw.) und besitzt eine bidirektionale Verbindung zwischen virtueller und realer Welt. Der Datenfluss synchronisiert die physische mit der virtuellen Welt Real-Time, so dass jede Zustandsänderung des realen Systems virtuell gespiegelt ist. Daten können als Rohdaten direkt von Sensoren aus einem physischen System (M2M), einem Process-Monitoring-System oder einem Real-Time-Projektsteuerungssystem geliefert werden. Auch können Daten durch externe Systeme aufbereitet und vorverarbeitet werden. In dem Repository ist der Zwilling digital gespeichert. Durch gespeicherte historische Daten können auch frühere Zustände aufgerufen werden. Der Mensch kann über eine Mensch-Maschine-Schnittstelle (HMI) weiterhin steuernd eingreifen. Bei einer noch weiterten Definition kann der digitale Zwilling unter Einsatz von KITechniken autonom arbeiten und allein die reale Welt steuern. Dieses entspricht dem Softwaresystem eines autonom fahrenden Autos, das ein reales Fahrzeug ohne Einfluss eines menschlichen Fahrers steuert. Eine fotorealistische Repräsentation des Digitalen Zwillings ist nicht zwanghaft nach dessen Definition erforderlich, wird aber in der Regel vorgesehen.

Abb. 3.10 Conceptual model of digital twin. (Quelle: Van der Valk et al., 2022)

48

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Ein Beispiel eines digitalen 3D-Zwillings ist die Abb. 3.11 eines Fabrikausschnitts mit seinen Maschinen in einer dreidimensionalen fotorealistischen Form mit allen Bewegungsabläufen wie Produktions- oder Transportvorgängen (vgl. auch Kap. 10 zu Industrieautomatisierung; hier wird auch Bezug genommen auf eine zukünftige industrielle Metaverse-Welt, in der virtuelle und reale Welt verschmelzen). Die Nutzung digitaler Zwillinge zur Fernüberwachung und -steuerung von Anlagen ist bereits Realität. Hier werden VR- und AR-Techniken gemeinsam eingesetzt (Cerniauskas & Werth, 2022). Häufig werden digitale Zwillinge bei der Produktentwicklung eingesetzt. Mit digitalen Zwillingen können Simulationen und Tests durchgeführt werden und deren Ergebnisse auf die Gestaltung der realen Systeme übertragen werden. Hierzu wird dann eine Kopie des digitalen Zwillings gezogen und an diesem Veränderungen durchgeführt. Der ursprüngliche Zwilling wird erst nach Entscheidungen aufgrund der Simulationsergebnisse verändert. Die Simulationen verbrauchen gegenüber realen Tests und Versuchen kein Material und können im Zeitraffer durchgeführt werden. Für pharmazeutische Versuche kann ein digitaler Zwilling eines Menschen mit allen Organfunktionen erstellt werden, dem eine Substanz (ebenfalls als digitaler Zwilling) gegeben wird, um dann die Wirkung der Substanz auf die Organe beobachten zu können. Während im technischen Umfeld der Produktentwicklung sowie von Produktion, Verfahrensabläufen und Logistik der Einsatz von digitalen Zwillingen bereits angewendet wird, ist dieses im Bürobereich mit seinen Geschäftsprozessen noch unüblich, aber ebenso möglich. Hier werden dann Büroräume mit ihren Mitarbeitern als Avatare abgebildet und ein Prozess wie z. B. der Ablauf einer Auftragsbearbeitung durch die Eingaben von Daten, fachlicher Arbeit und Kommunikation zwischen Mitarbeitern dargestellt. Die bisher vorhandenen Ansätze für digitale Zwillinge haben jeweils ihre eigenen Anwendungsfälle. Ihre Erweiterung, Generalisierung und Einfügung in den Rahmen der EA fügt die Teile dann zu einem Gesamtbild des Unternehmens.

Abb. 3.11 Digitaler Zwilling Produktionssystem. (Quelle: Adobe Stock, Gorodenkoff)

3.6 Digitaler Unternehmenszwilling im Metaverse

49

Der diskutierte EA-Ansatz entwickelt sich dann stufenweise von Prozessmodellen, dem Informationssystem bis zur Video-realistischen digitalen 3-D-Abbildung des gesamten Unternehmens. Abb. 3.12 zeigt detailliert das Konzept des unternehmensweiten digitalen Zwillings in seinen Entwicklungsschritten. Der Zwilling wird in drei Verdichtungsstufen dargestellt. Die Stufen 1 und 2 lehnen sich eng an die Ausführungen zur Entwicklung des traditionellen EA-Ansatzes an, während die Stufe 3 den echten digitalen Zwilling darstellt. Die Entwicklungsschritte sind umkreist nummeriert. Die fett ausgezogenen Pfeile zeigen die Richtung zur Erzeugung der Zwillinge an; die gestrichelten Pfeile die Richtung der Beeinflussung von Objekten. Je nach dem Interesse kann ein Zwilling das gesamte Unternehmen mit seinen Partnerbeziehungen umfassen oder einen Ausschnitt, z. B. einen Standort oder die an einem bestimmten Geschäftsprozess beteiligten Einheiten des Unternehmens. In Stufe 1 und Schritt 1a werden die Geschäftsprozesse des realen Unternehmens manuell modelliert, wobei vorhandene digitale Referenzmodelle genutzt werden können. Ergebnis ist dann eine modellierte EA. Sie enthält alle als sinnvoll erachteten Prozessalternativen in komprimierter Form sowie Daten-, Funktions-, Organisations- und Leistungsmodelle mit passenden KPIs.

Abb. 3.12 Entwicklungsstufen digitaler Unternehmenszwillinge

50

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Die Modelle sind allerdings statisch und werden nur von Zeit zu Zeit verändert. Deshalb fehlt die Real-Time-Aktualität und damit die 1:1-Entsprechung von Zwilling und Realität. In Schritt 1b wird das fotorealistische Abbild der Unternehmensstruktur modelliert, das als Ausgang für die späteren Real-Time-Abläufe der Stufe 3 dient. In Schritt 2 der Stufe 1 konfigurieren die Modelle teilautomatisch das reale Informationssystem aus Hard- und Software des Unternehmens. Das Informationssystem in seiner Build-Time-Version ist auch ein digitaler Zwilling der Stufe 1. Dabei enthält das Informationssystem technische Eigenschaften, die in den EA-Modellen nicht enthalten sind; umgekehrt sind in den Modellen Angaben über Zeiten, KPIs oder organisatorische Rollenmodelle enthalten, die nicht im realen Informationssystem erfasst sind. Insgesamt bildet das Build-Time-Informationssystem aber einen großen Ausschnitt der Struktur des realen Unternehmens digital ab. Es ist dabei sowohl Abbild der Unternehmensrealität als digitaler Zwilling als auch ihr Bestandteil. In der zweiten Stufe des digitalen Zwillings wechselt die Betrachtung auf die Ausführungsebene und damit zu den einzelnen Prozessinstanzen. Es ist damit der Wechsel von der Struktur- zur Verhaltensbetrachtung. Damit wird ein großer Sprung in der Detailliertheit vollzogen. In Schritt 3 der Stufe 2 werden die Prozessinstanzen des Unternehmens vom Informationssystem in der Run-Time ausgeführt. Dazu werden von Benutzereingaben (Dateninput) des realen Unternehmens die Prozesse ausgelöst (Schritt 4) und bearbeitet. Das Informationssystem steuert somit in Schritt 5 das reale Verhalten des Unternehmens. Da das Informationssystem die realen Prozesse in der Informationssicht spiegelt, kann es auch als digitaler Real-Time-Zwilling bezeichnet werden. Allerdings sind die digitalen Informationen dem Benutzer nur in einer technisch limitierten Form durch vorgefertigte Masken und weitgehend ohne Prozesszusammenhang verfügbar. In Schritt 6 werden durch das Process Mining die einzelnen Prozessinstanzen in benutzerfreundlicher Form durch Instanzenmodelle abgebildet. Hierzu werden Events der Anwendungssysteme aus Logdateien genutzt. Diese zeigen für jeden Prozessablauf die Reihenfolge der Bearbeitungen, den zeitlichen Ablauf und die ausführenden Organisationseinheiten Real-Time auf. Die Instanzenmodelle der Stufe 2 erfüllen somit die Forderung nach einer synchronen Darstellung des Realitätsausschnitts durch den digitalen Zwilling. Es kann auch in den Ablauf der einzelnen Instanzen eingegriffen werden, indem z. B. bei einer erkannten Verzögerung des zeitlichen Ablaufs ein neuer Weg für den weiteren Ablauf vorgeschlagen wird (Schritt 7). Damit wird über den digitalen Zwilling der Stufe 2 das reale Verhalten des Unternehmens beeinflusst. Auch kann der digitale Zwilling für Simulationen benutzt werden. Auf Basis des Modells der Stufe 1 können z. B. für einen Zeitraum die abgelaufenen Prozesse in einem Zeitraffer grafisch sichtbar gemacht werden. Damit nähert sich die Stufe 2 bereits eng an

Literatur

51

die Realität und den Anforderungen an einen echten Digitalen Zwilling an, es fehlt im Wesentlichen noch die dreidimensionale fotorealistische benutzerfreundliche Darstellung. Zunächst aber in Schritt 8 noch einen Gedankengang zurück. Durch Algorithmen des Process Mining werden in Schritt 8 aus den Instanzenmodellen durch Verdichtung Prozessmodelle generiert (Model Discovery). Diese können mit den in Schritt 1 entwickelten Modellen abgeglichen werden (Compliance Check). Dieses findet dann auf der Stufe 1 der digitalen Zwillinge statt. In der Stufe 3 wird der Übergang zu dem echten digitalen Zwilling vollzogen. Hier wird die Abbildung der Realität weiter verfeinert, zeitlich synchronisiert und damit der Abstraktionsgrad der Darstellung drastisch reduziert. In Schritt 9 wird aus der Realität automatisch über Sensoren (9a), aus den Run-TimeAnwendungen des Informationssystems (9b) sowie den Run-Time-Instanzenmodellen (9c) ein digitales fotorealistisches Abbild der Abläufe erzeugt. Die einzelnen Prozessinstanzen werden in Real-Time den Organisationsobjekten zugeordnet, so dass jederzeit die gerade aktiven Prozessinstanzen in ihrem Zustand bildlich sichtbar sind. Der digitale Zwilling der Stufe 3 zeigt damit den größten Komfort an benutzerfreundlicher Darstellung und Auswertungsmöglichkeiten. Gegenüber der Realität kann der Zwilling mit zusätzlichen Informationen versehen werden, wie in der Abbildung mit Ladeinformationen des Lastwagens als Augmented Reality angedeutet ist. Mit dem Zwilling können organisatorische Änderungen simuliert und Entscheidungsalternativen getestet werden. Eingriffe des Zwillings in die Realität werden über den Schritt 10 weitergegeben. Eingriffe in den Ablauf einer Prozessinstanz des Anwendungssystems werden über den Schritt 11 an die Run-Time-Version des Informationssystems gegeben. Die Entwicklung bidirektionaler fotorealistischer digitaler Zwillinge ist noch mit einem erheblichen Aufwand verbunden. Da aber bereits für Teile des Unternehmens, wie Produkte und Fabriken, auch fotorealistische digitale Abbildungen gelebte Praxis sind, können diese Daten übernommen werden. Zudem können Techniken des Virtual Reality und des Augmented Reality genutzt werden. Mit der Vision Metaverse als ein Ineinandergreifen von virtueller und realer Welt werden diese Gedanken in der nächsten Zeit weitere Unterstützung finden. Diese ist dann Basis für benutzerfreundliche Simulationen für neue Abläufe und dient als Grundlage für Entscheidungen eines innovativen, agilen und sich ständig neu erfindenden Unternehmens, also des Composable Enterprises.

Literatur Cerniauskas, T., & Werth, D. (2022). Industry goes Metaverse. Die Verschmelzung realer und virtueller Industriewelten am Beispiel der Abwasserwirtschaft. Fachmagazin IM+io, 37(2), 64–67. Fleischmann, A., Oppl, S., Schmidt, W., & Stary, Ch (2020). Contextual process digitalization: Changing perspectives – design thinking – value-led design. Cham: Springer.

52

3

Von der Process- und Enterprise-Architecture zum digitalen Unternehmenszwilling

Gadatsch, A. (2020). Grundkurs Geschäftsprozess-Management: Analyse, Modellierung, Optimierung und Controlling von Prozessen (9. Aufl.). Wiesbaden: Springer-Vieweg. Hammer, M., & Champy, J. (1993). Reengineering the corporation: A manifesto for business revolution. Business Horizons, 36(5), 90–91. Hansen, H. R., Mendling, J., & Neumann, G. (2019). Wirtschaftsinformatik (12. Aufl.). Berlin, Boston: De Gruyter. Krcmar, H. (2015). Informationsmanagement (6. Aufl.). Berlin Heidelberg: Springer Gabler. Lankhorst, M., et al. (2017). Enterprise architecture at work (4. Aufl.). Berlin Heidelberg: Springer. Laue, R., Koschmider, A., & Fahland, D. (Hrsg.). (2021). Prozess-Management und ProcessMining: Grundlagen. Berlin: De Gruyter. Leimeister, J. M. (2021). Einführung in die Wirtschaftsinformatik (13. Aufl.). Springer Gabler. Matthes, D. (2011). Enterprise Architecture Frameworks Kompendium (S. 72). Heidelberg: insb. OMG (2008). Business process modeling notation, V1.1, Technical Report, Object Management Group (OMG), January 2008. http://www.omg.org/spec/BPMN/1.1/PDF/ Polyvyanyy, A., Wynn, M. T., van Looy, A., & Reichert, M. (Hrsg.). (2021). Business process management. 19th International Conference, BPM, Rome. Cham: Springer. Proceedings Scheer, A.-W. (1984). EDV-orientierte Betriebswirtschaftslehre – Grundlagen für ein effizientes Informationsmanagement (1. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (1991). Architektur integrierter Informationssysteme – Grundlagen der Unternehmensmodellierung (1. Aufl.). Berlin: Springer. Scheer, A.-W. (2001). ARIS – Modellierungsmethoden, Metamodelle, Anwendungen (4. Aufl.). Berlin, Heidelberg: Springer. In erster Auflage erschienen 1991 Scheer, A.-W. (2002). ARIS – Vom Geschäftsprozeß zum Anwendungssystem (4. Aufl.). Berlin: Springer. Solow, R. M. (1988). Growth theory and after. The American Economic Review, 78(3), 307–317. Urbaczewski, L., & Mrdalj, St (2006). A comparison of enterprise architecture frameworks. Issues in Information Systems, 7(2), 18–23. Van der Valk, H., Haße, H., Möller, F., & Otto, B. (2022). Archetypes of digital twins. Business & Information Systems Engineering, 3(22), 375. insb. S. 377. Weber, P., Gabriel, R., Lux, Th., & Menke, K. (2022). Basiswissen Wirtschaftsinformatik (4. Aufl.). (S. 206). Weske, M. (2019). Business process management: Concepts, languages, architectures (3. Aufl.). Berlin Heidelberg: Springer. Zachman, J. A. (1987). A framework for information systems architecture. IBM systems journal, 26(3), 276–292.

Weiterführende Literatur Keller, G., Nüttgens, M., & Scheer, A.-W. (1992). Semantische Prozessmodellierung. Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi) Saarbrücken, Nr. 89. Nüttgens, M., & Rump, F. J. (2002). Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). In J. Desel & M. Weske (Hrsg.), Promise 2002 – Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen (S. 64). Bonn: Gesellschaft für Informatik e. V. Scheer, A.-W. (2020). Unternehmung 4.0 (3. Aufl.). Springer Vieweg: Wiesbaden. https://doi.org/ 10.1007/978-3-658-27694-2. Werth, D., & Linn, C. (2018). Der digitale Prozesszwilling – Vom klassischen Geschäftsprozessmodell zum steuerbaren, digitalen Abbild des Realprozesses. Fachmagazin IM+ io, 33(1), 38– 43.

4

Application Composition Platform Architecture

Zusammenfassung Die Besonderheit einer Entwicklungsplattform für das Composable Enterprise ist die Unterstützung des „Composable“-Paradigmas. Dies bedeutet die Bereitstellung von Methoden und Werkzeugen zur Entwicklung und Komposition von agilen, flexiblen und innovationsfreundlichen Anwendungen aus PBCs. Die Architektur der Application Composition Platform wird ausführlich dargestellt. Mit der Application Composition Platform werden PBCs entwickelt, zu Anwendungen komponiert, verwaltet, deployed und ausgeführt. Die Ausführung wird überwacht (Monitoring) und mittels Analytics wie z. B. Mining bearbeitet und durch Optimierungsansätze verbessert. Die Application Composition Platform steht im Zentrum der Unterstützung des Lifecycles des Composable Enterprise. Ihre Komponenten Prozessautomatisierung, Integration (API und API-Management), Low-Code-Entwicklung und Composition werden beschrieben und an Beispielen demonstriert. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Abb. 4.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_4

53

54

4

Application Composition Platform Architecture

Abb. 4.1 Application Composition Platform. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

4.1

Kennzeichnung der Plattform

Für innovative digitale Geschäftsprozesse steht Standardsoftware in der Regel nicht zur Verfügung. Diese ist auf bereits bekannte Businessmodelle ausgerichtet und unterstützt deren allgemein als sinnvoll akzeptierten Standardprozesse als „common practice“. Die Architektur von ERP-Systemen folgt wegen des Paradigmas eines unternehmensweiten Einsatzes eher einem zentralen Organisationsmodell von Unternehmen und widerspricht damit den Forderungen des Composable Enterprise nach autarker Dezentralisierung. Für disruptiv-innovative Anwendungen besitzt deshalb die Eigenentwicklung im Composable Enterprise eine große Bedeutung. Für diese Entwicklungen sind geeignete Methoden und Werkzeuge erforderlich. Die Zusammenstellung und Verfügbarkeit dieser Methoden und Werkzeuge auf einer einheitlichen Technologie wird als Plattform bezeichnet, ihre Strukturierung als Architektur der Plattform.

4.1.1 Der Integrationsanspruch der Application Composition Platform (ACP) Eine zu entwickelnde Anwendung, wie z. B. eine neuartige Auftragsbearbeitung, besteht aus mehreren Aufgaben oder Problemstellungen, für die PBCs entwickelt werden. Für jede Aufgabe werden spezielle Methoden und Werkzeuge auf der Plattform bereitgestellt. Diese Aufgaben als Bestandteile einer gesamten Anwendung sind (siehe Jost, 2022):

4.1 Kennzeichnung der Plattform

   

55

Prozessautomation, Integration von PBCs, Modulen und Anwendungsteilen, (Code-)Development als Pro-Code oder Low-Code, Komposition von PCBs zu einer Gesamtanwendung mit User Experience. Jede Aufgabe bildet einen eigenen Entwicklungs-Lifecycle aus:

    

Design, Development (z. B. Codierung), Monitoring, Analytics, Management (Rechteverwaltung, Katalogverwaltung, Wartung usw.).

In Abb. 4.2 sind diese Zusammenhänge verdeutlicht. Für jede der genannten vier Aufgaben besteht ein Entwicklungs-Lifecycle. Der Begriff Development tritt als Aufgabe und als Phase des Lifecycles auf. Für das Code Development als Aufgabe stellt die Plattform Entwicklungsmethoden und -werkzeuge wie Programmiersprachen oder Low-Code für die Anwendungscodierung bereit. Die Entwicklung eines konkreten Codes durchläuft den Lifecycle vom Design bis zum Management der Releases. Auch in jeder anderen Aufgabe, wie der Integration zwischen Modulen, gibt es CodeDevelopment als eine Phase des Lifecycles. Bei der Entwicklung von konkreten Anwendungen können die Schwerpunkte der Aufgaben unterschiedlich sein. Bei einer Anwendung überwiegt z. B. der Integrationsaspekt, bei einer anderen die Entwicklung von Softwarecode für neue Funktionen.

Abb. 4.2 Lifecycles der Aufgaben zur Anwendungsentwicklung

56

4

Application Composition Platform Architecture

In der ersten Generation von Entwicklungsplattformen wurden deshalb spezielle Plattformen für die einzelnen Aufgaben erstellt, z. B. Workflow-Plattformen für die Prozessautomatisierung, Integrationsplattformen für Integrationsprobleme und Low-Code-Plattformen für Codierung. Diese werden von spezialisierten Herstellern angeboten. Die Plattformen sind jeweils nur auf ihre speziellen Aufgaben ausgerichtet. Viele Unternehmen haben deshalb mehrere Plattformen im Einsatz. Es zeigt sich aber, dass die Aufgaben nicht scharf voneinander zu trennen sind. So kann eine Anwendung zur Prozessautomatisierung auch Codeentwicklung und Integrationsprobleme beinhalten. Die Anbieter reichern deshalb immer mehr ihre Spezialplattformen mit weiteren benötigten Funktionen der anderen Aufgaben an. Setzt ein Unternehmen mehrere Plattformen ein, kommt es zu Überschneidungen. Zudem besitzt jede Plattform ihre eigene Architektur mit wiederum unterschiedlichen Werkzeugen zur Unterstützung der Phasen Design, Entwicklung, Monitoring, Analytics und Management. Deshalb liegt es nahe, die Werkzeuge für die Phasen redundanzfrei unter einer einheitlichen Oberfläche (Experience) auf einer integrierten Plattform für alle Aufgaben bereitzustellen, wie Abb. 4.3 zeigt. Für die Aufgaben werden spezifische Methoden und Werkzeuge bereitgestellt; die benötigten Unterstützungen für den Lifecycle von Design bis Management werden aber einheitlich (integriert) eingesetzt. So werden innerhalb der Erstellung einer Integrationslösung oder einer Prozessautomatisierung das gleiche Design-Tool und die gleiche LowCode-Entwicklungsumgebung verwendet.

Abb. 4.3 Integrierte Application Composition Platform für Phasen und Aufgaben

4.1 Kennzeichnung der Plattform

57

Die Vorteile einer integrierten Application Composition Platform sind zusammenfassend1 : 1. Entwickler verwenden die gleichen Daten über alle Aufgaben einer Anwendungserstellung hinweg. Damit ist die Datenintegrität gesichert. 2. Entwickler arbeiten bei den unterschiedlichen Aufgaben in der gleichen Methodik und dem gleichen User Interface (GUI, Experience). 3. Werkzeuge für Design, Entwicklung, Monitoring, Analytics und Management, die für jede Aufgabe benötigt werden, werden dazu einheitlich in der Plattform verwendet. 4. Entwickler unterschiedlicher Aufgaben benötigen lediglich die Schulung in einer Plattform. 5. Eine einzige Systemumgebung erleichtert die Teamarbeit und Kommunikation zwischen Entwicklern unterschiedlicher Aufgaben. 6. Die Weiterentwicklung der Plattform ist auf alle Funktionen abgestimmt. 7. Die Benutzerfreundlichkeit des Systems fördert eine hohe Innovationsgeschwindigkeit des Composable Enterprise.

4.1.2

Aufbau der Application Composition Platform und Anwendungsumgebung

Abb. 4.4 zeigt die ausführliche Architektur der integrierten Plattform und die Einbettung in ihre Anwendungsumgebung2. Die Plattform ist die Werkzeugumgebung für Entwickler. Entwickler sind einmal Experten, die mit Programmiersprachen oder Low-Code die PBCs entwickeln sowie Composer, die die Anwendungen aus den Building Blocks zusammensetzen. Entwickler aus den Fachabteilungen entwickeln lediglich mit Low-Code. Die Anwender in den Fachbereichen greifen auf die erstellten komponierten Anwendungen, wie eine Kundenauftragsbearbeitung, zu. Die Anwendung bildet die Benutzersicht (Experience Layer), d. h. dem Endanwender bleiben die Entwicklungsfunktionen der Plattform verschlossen. Dieses ist grafisch durch die Umrandung zum Ausdruck gebracht, indem diese nicht mit dem Entwicklungsteil der Plattform verbunden ist.

1

Das Unternehmen Scheer PAS GmbH hat mit dem System „Scheer Process Automation Suite (PAS)“ in rund 10 Jahren eine integrierte Plattform entwickelt. Vorversionen wurden in vorhergehenden Auflagen dieses Buches angeführt. Diese wurden in Kundenprojekten erfolgreich eingesetzt. Unter Leitung des CTOs der IDS Scheer Holding GmbH, Dr. Wolfram Jost, wurde die Architektur des Systems auf die Anforderungen des Composable Enterprise ausgerichtet und kann als erste Plattform mit dieser Ausrichtung bezeichnet werden. Auch Softwareanbieter wie die SAP folgen mit ihrer Business Technology Platform (BTP) dem Konzept einer Plattform-orientierten Systemarchitektur. Diese bezieht sich aber vornehmlich auf die SAP-Anwendungssysteme. 2 Grundlage der Abbildung ist die Darstellung von Jost (2022). Application Composition Platforms, Vortrag vor den Mitgliedern des Feldafinger Kreises am 22. Juli 2022 in Feldafing.

58

4

Application Composition Platform Architecture

Abb. 4.4 Architektur der Application Composition Platform. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

Die Anwendungen selbst verwenden bei der Ausführung einer Anwendung die Plattform, weil diese neben der Entwicklungsversion (Build Time) auch die Run-Time-Version enthält, mit der die Anwendungen zur Laufzeit (Run-Time) ausgeführt werden. Die Entwickler als Spezialisten für Pro-Code oder Citizen Developer für Low-Code benutzen die Funktionen der Plattform, um neue Capabilities zu entwickeln und zu Anwendungen zusammenzusetzen. Der Entwickler erfährt damit die Benutzerfreundlichkeit (Experience) des Umgangs mit der Funktionalität der Plattform. Die Capabilities können nach ihren inhaltlichen Schwerpunkten auf Anwendungslogik, Datenlogik oder Analyticslogik ausgerichtet sein. Anwendungslogik sind betriebswirtschaftliche Prozesse, Verfahren und Algorithmen. Capabilities für Datenlogik sind Funktionen zum Speichern, Pflegen, Manipulieren von Daten und Datenschnittstellen. Capabilities für Analytics sind statistische Auswertungsverfahren und Anwendungen der Künstlichen Intelligenz (KI). Alle drei Ausprägungen sind damit Business Capabilities im Sinne der PBCs. Im Folgenden wird aus Gründen der Vereinfachung nicht mehr zwischen PBCs für Anwendungen, Daten und Analytics unterschieden, sondern alle unter dem Begriff PBC zusammengefasst.

4.1 Kennzeichnung der Plattform

59

Auf der unteren Ebene der Abbildung sind auch die in einem Unternehmen vorhandenen Unternehmenssoftware- und Altsysteme angegeben. Dieses sind Anwendungen wie ERP, CRM oder HR, bestehende Data Lakes (unstrukturierte Datenbanken) und bestehende Auswertungsanwendungen (Analytics). Zur Vereinfachung werden die drei Formen im Weiteren zu der Abkürzung ERP oder auch Shared Services zusammengefasst. Entwickler können aus der Plattform direkt auf Funktionen und Daten der bestehenden ERP-Anwendungen zugreifen, um sie in den Prozessablauf einzufügen. Von den Capabilities sind jeweils bidirektionale Zugriffe untereinander und auf die bestehenden ERPSysteme möglich. Dazu bieten beide Seiten APIs und oder Event-Schnittstellen an. Die Schnittstellen sind grafisch durch die fetten schwarzen Begrenzungskanten der Symbole gekennzeichnet. Die Funktionalität von APIs als ein Vertrag zwischen zwei Systemen zum Austausch von Daten und Nutzung von Services wird später wegen ihrer zentralen Bedeutung ausführlich behandelt. Bei einer Eventsteuerung (Event Driven Architecture (EDA)) wird die Verbindung zwischen den PBCs und den bestehenden Systemen über Ereignisse eines Systems ausgelöst, auf die andere Systeme reagieren. Das ein Ereignis auslösende System weiß dabei nicht, welche Systeme reagieren, sondern stellt lediglich das Ereignis in einer Eventdatei bereit. Insgesamt wird eine lose Kopplung erreicht und die Systeme können weitgehend unabhängig voneinander verändert werden. PBCs können mit allen benötigten Ressourcen wie Bibliotheken, Betriebssystem, Speicherplatz usw. in sogenannten Software-Containern gespeichert werden und sind dann hardwareunabhängig ablauffähig. Die Capabilities werden mit den benötigten Funktionen aus bestehenden ERP-Systemen auf der Plattform unter Nutzung der Composition-Funktion zu einer Application komponiert. Dabei wird das User-Interface, also die Benutzeroberfläche, die das Erlebnis des Anwenders (Experience) mit der Anwendung bestimmt, die Authentifizierung und Benutzerrechte sowie die Prozesslogik zwischen den PBCs festgelegt. Im Folgenden werden die genannten wesentlichen Funktionen der Plattform: Prozessautomatisierung, Integration, Low-Code-/Pro-Code-Entwicklung ausführlicher erläutert. Die in ihnen gemeinsam genutzten Werkzeuge für die Phasen Design, Entwicklung, Monitoring und Analytics werden nur einmal bei einer der wichtigsten Nutzung behandelt. Die Aufgaben werden jeweils durch praktische Anwendungsfälle demonstriert. Da in der Regel mehrere Aufgaben in einem Beispiel bearbeitet werden, sind sie nach ihrem Schwerpunkt zugeordnet.

60

4

Application Composition Platform Architecture

4.2 Prozessautomation 4.2.1

Kennzeichnung der Prozessautomation

Prozessautomatisierung ist die maschinelle Ausführung von Prozessfunktionen, die vorher durch Menschen bearbeitet wurden. Dabei gibt es unterschiedliche Ansatzpunkte. Zunächst kann der Prozessfluss (Workflow) automatisiert werden, indem von einer Workflow Engine die im Prozess zu bearbeitenden elektronischen Dokumente von elektronischen Postausgangskörben zu Posteingangskörben des nächsten Arbeitsschrittes weitergereicht werden. Dabei werden Papierdokumente durch digitale Dokumente ersetzt und der Dokumentenfluss beschleunigt. Zur Bearbeitung der digitalen Dokumente bestehen vielfältige Möglichkeiten:  Automatische Plausibilitätsprüfungen der Bearbeitungsschritte können die manuelle Dokumentenbearbeitung unterstützen.  Dem Sachbearbeiter können Daten aus verschiedenen Systemen automatisch zur Verfügung gestellt werden.  Umständliche Datenübertragungen zwischen verschiedenen Systemen können durch Softwareroboter automatisch ausgeführt werden.  Vorgänge, die durch Bearbeitungsregeln gut definiert sind, können direkt durch Programmcode ausgeführt werden, der z. B. durch eine Low-Code-Funktion erstellt wurde.  Die Bearbeitung heterogener Dokumente, wie Rechnungen, Lieferscheine oder Zollpapiere aus unterschiedlichen Quellen und mit unterschiedlichem Aufbau, kann durch Methoden der künstlichen Intelligenz (Mustererkennung, Bilderkennung, Sprachverarbeitung, Textanalyse) identifiziert, analysiert und zur elektronischen Weiterbearbeitung, z. B. durch ERP-Systeme, aufbereitet werden.  Komplexe Entscheidungen können durch Methoden der künstlichen Intelligenz automatisch getroffen und ausgeführt werden. Insgesamt reicht die Prozessautomatisierung von einfachen Unterstützungen des Sachbearbeiters in semi-automatisierten Prozessen bis zur vollautomatischen Ausführung der End-to-End-Bearbeitung. Die Process Automation der Application Composition Platform stellt dazu die Werkzeuge bereit und integriert Tools wie Robotic Process Automation (RPA) oder KI-Plattformen. Software Roboter verhalten sich wie Anwender, benutzen deren Benutzerschnittstelle und übernehmen z. B. den Datentransfer zwischen Anwendungen. RPA und KI werden in Kap. 8 und 9 näher behandelt. Auch die Integrationsfunktion und Low-CodeEntwicklung der Plattform, die in den nächsten Abschnitten behandelt werden, werden zur Automatisierung eingesetzt. Wesentlicher Bestandteil der Process Automation ist die Workflow Engine. Sie steuert den End-to-End-Prozess und ruft die Anwendungen über Ereignisse auf. Sie bildet

4.2 Prozessautomation

61

den Übergang von der betriebswirtschaftlichen Modellierung eines Geschäftsprozesses zu seiner Ausführung. Dazu gibt Abb. 4.5 einen visuellen Eindruck. Die Modelle werden mit dem Design-Werkzeug der Plattform erstellt. Das fachliche Soll-Prozessmodell als ARIS-EPK wird in BPMN verfeinert und das technische Modell in UML erstellt. Dieses ist direkt in Softwarecode umsetzbar. Bei einfachen Dokumenten-zentrierten Prozessen können bereits der Kontrollfluss und die Formularoberfläche eines Low-Code-Systems eine automatisierte Lösung erzeugen. Die digital erfassten Dokumente werden von der Workflowsteuerung automatisch aus digitalen Postausgangskörben zu den Posteingangskörben des nächsten Arbeitsschrittes weitergeleitet und dort von Sachbearbeitern digital bearbeitet oder durch den Aufruf von Anwendungsfunktionen weiter automatisiert. Einfache Anwendungsfunktionen können mit Hilfe von Low-Code von der Fachabteilung entwickelt werden. Das Ergebnis ist dann ein ganzheitlich durch Modelle definiertes ausführbares System.

Abb. 4.5 Architektur von Workflow-Systemen von der betriebswirtschaftlichen EPK-Prozessbeschreibung über die BPMN-Beschreibung zum Ausführungsmodell in UML

62

4.2.2

4

Application Composition Platform Architecture

Beispiele zur Prozessautomation

Abb. 4.6 zeigt einen Prozess zur automatischen Verarbeitung von eingehenden Rechnungen. Sie werden zunächst durch einen KI-Algorithmus aus dem Bereich der natürlichen Sprachverarbeitung und Visual Computing aus ungeordneten Dokumenten erkannt und selektiert. Zur Validierung werden die Rechnungsdaten mit den Bestelldaten verglichen und bei erfolgreicher Prüfung einem Softwareroboter zur Verbuchung übergeben. In einer Anwendung für eine Landespolizei wurden in der Ausgangssituation manuell von Polizisten erstellte Unfallberichte daraufhin von Sachbearbeitern auf ihre Plausibilität geprüft und anschließend an eine Statistikstelle weitergeleitet. Dieser aufwendige Prüfvorgang wurde durch eine automatische Prüfung abgelöst. Durch einen KI-Algorithmus werden die Unfallberichte analysiert und Fehler bei der Unfallaufnahme automatisch erkannt. 85 % der Unfallberichte müssen nicht mehr von Sachbearbeitern einzeln manuell geprüft werden. In beiden Beispielen sind die eingesetzten Bausteine für KI und RPA in den Gesamtprozess einer Lösung eingebettet. Als isolierte Bausteine ohne Vor- und Nachbearbeitung würden sie keine Wirkung entfalten.

Abb. 4.6 Prozessdarstellung der automatisierten Verarbeitung von Rechnungsdokumenten

4.3 Integration

4.3

63

Integration

Erfahrungswerte zeigen, dass bei Digitalisierungsprojekten 70 % der Aufwendungen durch die Integration von Systemen verursacht werden. Durch das Composition-Prinzip sowie „Best-of-breed“-Strategien bei der Softwareauswahl wird der Trend zum Einsatz vieler Programme im Unternehmen verstärkt. So sind an einem Geschäftsprozess in der Regel mehrere Anwendungen und PBCs beteiligt, die untereinander auf Daten und Funktionen zugreifen. Auch werden immer mehr externe Partner, wie Kunden oder Lieferanten, mobil oder über das Internet mit dem Informationssystem verbunden. Werden eingesetzte Systeme, wie CRM und ERP, nicht technisch integriert, so müssen Daten manuell aufwendig von einem System in das andere übertragen werden. Dieses stört den Prozessfluss, ist fehleranfällig und widerspricht der Prozessautomation. Die Kommunikation muss deshalb technisch organisiert werden. Leitgedanke der Integration ist der Geschäftsprozess, wie er durch eine EPK oder ein BPM Modell beschrieben ist. Er legt fest, welche Funktionen benötigt werden, wie sie untereinander verbunden sind und welche Daten benötigt werden. Die Datenintegration über eine zentrale Datenbank, wie sie Herzstück der ERP-Systeme ist, ist bei Einsatz mehrerer extern bezogener Anwendungssysteme mit eigener Datenhaltung nicht mehr möglich. Bei einer Punkt-zu-Punkt-Verbindung des Datenaustausches zwischen den Anwendungen entsteht eine unübersichtliche Vielzahl zu betreuender individueller Lösungen. Es bestehen dann in der Regel kein zentrales Monitoring, keine zentrale Security Policy und kein zentrales Wissen über die Verbindungen. Bei einer Integration über die Application Composition Platform mit dem modellbasierten Prozessansatz sowie der API-Technologie mit einem zentralen Management bestehen dagegen eine zentrale Security und eine transparente Dokumentation über die integrierten Daten, Anwendungen und Prozesse. Mit dem API-Management werden alle Schnittstellen aus selbst entwickelten sowie externen APIs verwaltet und für Entwickler und Kunden zur Verfügung gestellt. Neben Daten aus Softwaresystemen können auch Daten aus Geräten über Sensoren im Rahmen von IoT-Anwendungen einbezogen werden. Mit der Integrationsfunktion können Daten aus verschiedenen Systemen extrahiert, verändert, zu neuen Datenpaketen zusammengeführt werden (ETL = Extract, Transform, Load) und an interne und externe Partner sicher verteilt werden. Die Entwicklung eines APIs wird als ein Prozess betrachtet und von der Plattform in der gleichen Art des Lifecycles von Design bis Verbesserung unterstützt wie ein Businessprozess. Bei der Erstellung einer Anwendung können dann mit dem Designer-Editor und der Low-Code-Funktionalität Daten und Prozesse per drag & drop einfach verknüpft werden. Wegen der Einfachheit können auch Mitarbeiter der Fachabteilung diese Integrationsfunktion durchführen. Man spricht dann von Citizen Integrators.

64

4

Application Composition Platform Architecture

Abb. 4.7 Scheer PAS Capabilities

Die Integration wird durch eine Vielfalt an Methoden, Tools und vorgefertigten Services unterstützt. Einen Eindruck davon gibt Abb. 4.7. Dort wird z. B. auf die über 1000 vorgefertigten technischen Adapter und Konnektoren hingewiesen. Die innere Komplexität der Adapter und Konnektoren bleibt aber dem Integrator verborgen, da ihm lediglich die Funktionalität bekannt sein muss, nicht aber deren interne Ausführung. Auf die Capabilities Mapping, API und API-Management sowie Monitoring des Integrationsprozesses und der Einsatz von Low-Code wird in den nächsten Abschnitten eingegangen.

4.3.1 Mapping Die Integration unabhängig voneinander entwickelter Programme erfordert eine inhaltliche (semantische) und eine technische Verständigung. Die inhaltliche Integration bedeutet, dass die Programme sich untereinander „verstehen“, also z. B. unter dem Datenobjekt „Auftrag“ und unter der Funktion „Auftrag anlegen“ das Gleiche meinen. Dazu müssen die Objekte zwischen den austauschenden Parteien verglichen werden (Mapping). Dieses geht nicht ohne einen semantischen Vergleich mit menschlichem Eingriff. Bei Funktionen müssen die Funktionsinhalte zwischen der anfordernden und anbietenden Partei verglichen und die passenden Kommandos ausgewählt werden. Bei Daten müssen die Attribute der Datenobjekte miteinander verglichen und zugeordnet werden. In Abb. 4.8 ist die Daten-Mapping-Funktion der Plattform Scheer PAS gezeigt. Als Input ist der Aufbau der angebotenen Daten eines Systems angegeben und als Output die gewünschten Daten. Es handelt sich um Daten einer Materialdatei. Die Linien ordnen die Attribute zwischen der anfordernden Datei (output) und der anbietenden Datei (input) zu. Attribute wie Materialnummer, Brutto- und Nettogewicht werden durch den Befehl „schreibe Feld x in Feld y“ zugeordnet. Die umrandeten Funktionen in den Linien zeigen darüber hinaus Operationen, wie die Konvertierung einer Größe zu einem „String“. Diese Operationen werden von dem Modellierer angelegt. Weitere Umsetzungen können sein: „Attributwerte von Format v in Format z umformatieren“.

4.3 Integration

65

Abb. 4.8 Data Mapping – Funktion der Scheer PAS

Mit diesen Funktionen ist das Mapping mehr als eine reine Zuordnung, sondern unterstützt auch die Transformation der Formate von Input-Größen zu Output-Größen. Die Bereitstellung der angebotenen Daten wird über APIs geregelt.

4.3.2 API und API-Management Bei einer direkten Verbindung zwischen zwei Programmen greifen diese direkt auf Funktionen und Daten des anderen Programmes zu. Ein Application Program Interface (API) ist dagegen ein Programm, das als Vermittler zwischen zwei miteinander kommunizierende Programme geschaltet ist (vgl. Abb. 4.9). Es beschreibt, welche Daten und Funktionen einer Anwendung in welcher Form für die externe Kommunikation bereitgestellt werden. Über den Endpunkt greift das API über eine (URL-)Adresse auf den Service eines Programms zu. Die Regeln für den Austausch werden zwischen Anfrager und Anbieter ausgehandelt oder sind vom Anbieter fest vorgegeben. Das Programm A wendet sich mit einem Bedarf an das API von B, das dann den Dienst oder Daten über standardisierte Formate wie REST (Representational State Transfer) liefert. Dabei überprüft das API die Berechtigung

Abb. 4.9 Direkte und APIVerbindung

66

4

Application Composition Platform Architecture

des Anfragers oder ob mit der Datenanfrage ein vereinbarter Umfang des Datenstroms überschritten ist. Mit dem API-Konzept wird sichergestellt, dass ein Programm nicht direkt, und damit unkontrolliert auf ein anderes Programm zugreift, sondern nach festen Regeln (Policies). Damit bietet es Schutz vor unerlaubten Zugriffen. Dieses ist gerade bei zunehmender Kommunikation mit externen Partnern wichtig, die keinesfalls unkontrolliert direkt auf Daten und Funktionen eines internen Programms zugreifen sollten. Das API stellt dabei lediglich die von ihm festgelegten Daten oder Funktionen zur Verfügung. Auswahl und Transformation muss der Anfrager, wie beim Mapping beschrieben, selbst vornehmen. Ein API kann so konfiguriert werden, dass mit ihm auch auf mehrere Programme zugegriffen werden kann. Kommunizieren Programme eines unternehmensinternen Informationssystems über APIs miteinander, werden diese als private APIs bezeichnet. Werden sie auch externen Benutzern angeboten, werden sie offene (public) APIs genannt. APIs müssen langfristig stabil sein, damit sich die Partner mit ihren Anwendungen darauf verlassen können. Dieses gilt im B2B-Einsatz, aber vor allem bei dem Zugriff von Konsumenten über ihre (mobilen) Endgeräte auf Unternehmensdaten. Die Anzahl von APIs kann bei einem Unternehmen leicht mehrere Hundert umfassen. Nach einer Studie der Analystenorganisation Gartner sollen bereits über 50 % der B2BTransaktionen über APIs verlaufen (Gartner Inc., 2021). Dieses zeigt ihre Bedeutung. In Abb. 4.10a,b,c,d ist ein einfaches Beispiel für den Aufbau und die Funktion eines Services mit einer API angegeben. Das Beispiel bezieht sich auf eine Datenbank, in der Supportfälle, die gegenüber Kunden geleistet werden, erfasst sind. Dieses können z. B. Beanstandungen oder Fehlermeldungen sein, die Kunden dem Unternehmen melden und um Behebung bitten. Für diese Datenbank ist ein Service mit einer API-Schnittstelle entwickelt, mit der Mitarbeiter oder Softwaresysteme des Unternehmens über ein privates API auf die Daten zugreifen können. So können sie Auswertungen über die gespeicherten Supportfälle durchführen und z. B. Supportfälle pro Kunde, Dauer der Bearbeitung oder Ergebnisse ermitteln. Abb. 4.10a zeigt, wie die API-Struktur im User Interface des Scheer PAS Designers durch den Entwickler festgelegt ist. Bei der Entwicklung werden Standards wie REST und OpenAPI verwendet. Mit GET/, GET out, POST usw. sind die Methoden mit zugehörigen Parametern und Output angelegt, die dem Anfrager angeboten werden und stellen die Zugriffspunkte (Endpunkt) des API dar. APIs beschreiben die Methoden inhaltlich. Die Endpunkte verweisen über (URL) Adressen auf den Programmcode des von einem Anwendungsprogramm bereitgestellten Service. Abb. 4.10b zeigt, wie die im Designer definierte Struktur der Methoden der API in „Menschen lesbarer“ Form automatisch umgesetzt werden und Abb. 4.10c in die maschinenlesbare OpenAPI-Beschreibung. Wenn ein Mensch über die Befehle der Abb. 4.10b bzw. ein Programm über die Befehle der Abb. 4.10c auf die API zugreift, kann aus ihr

b c

d

Abb. 4.10 Beispiel für einen Service mit API (erstellt mit Scheer PAS). a Modellierung einer API im Scheer PAS Designer; Definition der Methodenstruktur. b Darstellung der API Spezifikation; Auflistung der Services mit Input und Output Parametern. c Darstellung der API Spezifikation in maschinell lesbarer Form im OpenAPI Standard. d Modell der Methode GET

a

4.3 Integration 67

68

4

Application Composition Platform Architecture

gelesen werden, welche Methoden mit welchen Input- und Output-Daten verfügbar sind und wie sie von Mensch oder Programm angesprochen werden. Jede Methode wird im Designer durch ein Low-Code-Modell beschrieben. Für das Beispiel ist in Abb. 4.10a die fett hervorgehobene Methode „GET output“ ausgewählt, die Informationen zu Supportfällen aus der Datenbank liefert. Das zugehörende Low-Code-Modell in UML bildet in Abb. 4.10d den Suchvorgang des Services ab: Der Anfrager sendet die Anfrage an den API Endpunkt, wonach ein Datenbankkonnektor „find“ ausgeführt wird. Dieser durchsucht die Datenbank und liefert alle vorhandenen Supportfälle als Output. Daraufhin wird mit den vorhandenen Supportfällen die Operation „getinfo“ gestartet, die Detailinformationen zu den Supportfällen extrahiert, wie Kundennamen usw., und dem Anfrager als Output zur Verfügung stellt. Sowohl das API in Abb. 4.10a als auch der Serviceinhalt in Abb. 4.10d werden in dem gleichen Designer der integrierten Plattform modelliert. Ein API-Lifecycle folgt wie jedes Programm den Phasen Design, Implementierung/Testing, Deployment, Run, Monitoring bis zur Löschung (Retirement) und muss entsprechend verwaltet werden. Um die Übersicht und Kontrolle über die APIs zu behalten – ein API ist quasi das Einfallstor zur Außenwelt des jeweilig angesprochenen Services – werden sie durch ein API-Managementsystem von der Planung bis zum Retirement verwaltet. Dieses besitzt innerhalb der IT-Architektur eine immer größere Beachtung. Abb. 4.11 zeigt den Fall, dass externe Nutzer (Clients) ohne ein API-Managementsystem direkt auf die APIs des Unternehmens in einer Punkt-zu-Punkt-Verbindung zugreifen. Die APIs definieren zwar die bereitgestellten Informationen, kontrollieren aber nicht, wie häufig und mit welchem Umfang die Daten genutzt werden. Diese Regeln werden in Policies festgelegt und vom API-Management verwaltet. Policies legen z. B. fest, auf welche Dienste zugegriffen werden darf, definieren den Umfang von abgerufenen Daten und den vereinbarten Zeitraum, in denen der Zugriff gestattet ist, sowie auch Entgelte für die Nutzung.

Abb. 4.11 n:m APIVerbindungen ohne Managementsystem

4.3 Integration

69

Die Architektur eines API-Managementsystems zeigt Abb. 4.12. Im Zentrum des API-Management-Systems steht ein Gateway, über das alle Anfragen nach Daten oder Services erfolgen. Es kontrolliert die Policies, z. B., ob ein Client bei einem API-Aufruf die vertraglich vereinbarte Datenmenge überschreitet. Weiter steuert es die Zugriffe auf die APIs. Die internen API-Developer entwickeln das API-Programm unter Nutzung eines Designers zur Modellierung und greifen dabei direkt auf das API zu. Sie übergeben es nach dem Testen an den API-Manager zum Freigeben und zur Veröffentlichung in einem Katalog oder Marktplatz und übergibt sie dem API Gateway. Es ist Aufgabe des API Managers zu entscheiden, welche dieser „native“ oder „inner“ APIs auch für die externe Nutzung zur Verfügung gestellt werden. Der externe Benutzer oder Consumer sieht nur diese „outer“ APIs im Gateway. Diese weichen von den „inner“ APIs ab, indem sie auf die API-Clients konfiguriert werden. Der API-Manager legt mit den externen Kunden die Policies zur Nutzung fest. Zudem analysiert er die Verwendung der APIs durch die Clients. Die Clients sind die Endnutzer der APIs, z. B. eine APP, die per Mobiltelefon auf das API zugreift. Externe Developer, die einen Client entwickeln und dazu ein API einsetzen möchten, wird ein Development Portal zur Verfügung gestellt. Damit können sie das API abrufen und mit ihrer Anwendung testen.

Abb. 4.12 Architektur eines API-Management-Systems. (Quelle: Adobe Stock, PureSolution)

70

4

Application Composition Platform Architecture

Der eigentliche Integrationsvorgang zwischen den anfordernden Clients und den anbietenden Systemen durch deren APIs findet in dem umzogenen Teil zwischen Clients, API-Gateway und den API-Endpoints als Verweis auf die Adresse des Services statt. Der API-Aufbau besteht damit aus den drei Ebenen: 1. Dem eigentlichen Service, der von einem Anwendungsprogramm bereitgestellt wird und auf den von den API-Endpunkten über eine Adresse zugegriffen wird. 2. Den „inner“ APIs, die vom Endwickler als native APIs angelegt werden. 3. Den „outer“ APIs, die im Gateway externen Anfragern zur Verfügung gestellt werden und auf diese aus den inner APIs konfiguriert sind. Zusammenfassend sind wesentliche Funktionen des API-Managementsystems (Mathijssen et al., 2020):        

Bereitstellung einer Entwicklungsumgebung zur Erstellung von APIs. Verwaltung von Versionen. Führung eines Katalogs mit allen APIs und Dokumentationen. Definition von Zugriffsberechtigungen (Authentifizierung) und weiterer Regeln (Policies) für Entwickler und Benutzer. Funktion zum Veröffentlichen (Publishing) von APIs an Benutzer. Installation (Deployment) von APIs. Monitoring und Controlling der Nutzung von APIs (wer, wann, was, wieviel). Analysefunktionen zur Nutzung der APIs in einem Zeitraum.

Insgesamt sind die API- und API-Management-Funktionalitäten ein wichtiger strategischer Baustein der Application Composition Platform. Sie entflechten Anwendungssysteme durch die indirekte Kopplung und führen zu größerer Flexibilität.

4.3.3 Monitoring des Integrationsprozesses Die Integration, also die Kommunikation zwischen Systemen, bildet selbst einen Prozess. Dieser kann auf der Ebene eines einzelnen Integrationsvorgangs verfolgt werden. Zwar verfolgen bereits die einzelnen beteiligten Anwendungssysteme die Ausführung ihrer Transaktionen und speichern Events über Start und Ende in Logdateien, aber bei Datenübertragungen innerhalb einer Transaktion können (z. B. bei einem Stromausfall) Daten auf dem Weg von einem System in das andere System verloren gehen. Deshalb kann parallel zu dem betriebswirtschaftlichen Prozessmodell auch der Integrationsprozess modelliert werden und in einem Monitoring-Programm umgesetzt werden. Abb. 4.13 zeigt dazu ein einfaches Beispiel. Der in BPMN modellierte zugrundeliegende Anwendungsprozess in Abb. 4.13a besteht lediglich aus zwei Funktionen: dem

4.3 Integration

71

a

b

Abb. 4.13 Modell eines BPMN-Geschäftsprozesses mit Monitoring der Integration. a Beispielprozess für Monitoring; b Anzeigen der Zustände der auszuführenden Instanzen

Empfangen (Lesen) von Daten und dem anschließenden Schreiben der Daten in eine andere Datei. Damit werden beide Dateien „integriert“. Abb. 4.13b zeigt das Monitoring der Ausführung des Übertragungsprozesses. Zu dem angezeigten Zeitpunkt sind 16 Prozessinstanzen in Bearbeitung. Davon ist eine Instanz bereits gelesen und wartet auf das Schreiben durch die Funktion „Sync Data“. Für sie sind ID und Zeitstempel angegeben. Die anderen 15 Instanzen warten noch vor der ersten Bearbeitung, dem Datenempfang. Der gesamte Zustand ist persistent gespeichert und kann bei einem Systemausfall rekonstruiert werden und die Bearbeitung nach der Unterbrechung fortgesetzt werden. Wird jede Integrationsinstanz in einem eigenen Prozessraum ausgeführt, so beeinflusst ihr Ausfall nicht die anderen Instanzen. So können Ausfallzeiten stark reduziert und der Effekt des „single point of failure“, dass ein einzelner Fehler das gesamte System ausfallen lässt, vermieden werden.

4.3.4 Anwendungsfall Integration Bei Norddeutschlands größtem Shopping Center Unternehmen dodenhof mit zwei stationären Standorten, einem eigenen Internet-Shop und diversen Marktplätzen waren insgesamt 5 Warenwirtschaftssysteme mit einem Kassensystem und einer Vielzahl von Spezialsystemen in einer Punkt-zu-Punkt-Verbindung verbunden, siehe Abb. 4.14.

72

4

Application Composition Platform Architecture

Abb. 4.14 IT-Landschaft vor der Systemintegration

Um eine Multi-Channel Lösung anbieten zu können, bei der ein Kunde von jedem Zugangskanal bestellen kann und dann von den stationären Standorten oder Lager persönlich oder über einen Logistikservice bedient werden kann, wurde in einem ersten Schritt eine umfassende Integrationslösung auf Basis der PAS-Plattform mit Schwerpunkt Integration entwickelt. Durch den modellorientierten Ansatz und die API-Technologie wurden die Punkt-zu-Punkt-Verbindungen durch eine Integrationsschicht der Plattform mit API-Konnektoren ersetzt (Abb. 4.15).

Abb. 4.15 IT-Landschaft nach der Systemintegration mit SAP Retail und Scheer PAS

4.3 Integration

73

In einem zweiten Schritt wurden eine neue Software für das Kassensystem und das SAP Retail-System als Kernsystem eingeführt. Die nummerierten Kreise kennzeichnen die Schnittstellen zwischen den Satellitensystemen und der Plattform. Die Integrationsfunktion der Plattform sorgt dafür, dass dann Sender und Empfänger miteinander verbunden werden. Abb. 4.16 zeigt einen Beispielablauf innerhalb des Zielsystems mit dem Ineinandergreifen der unterschiedlichen Systeme. Trotz der weiterhin bestehenden hohen Komplexität sorgt nun eine klare Architektur für Transparenz und Sicherheit. Aus dem zentralen SAP-Warenwirtschaftssystem stammende Informationen zu den verfügbaren Artikeln wie Preise, Lagerbestände und Artikelstammdaten werden über APISchnittstellen den einzelnen Marktplätzen zur Verfügung gestellt. Diese Daten werden zusätzlich mit Artikeldaten aus dem Produktinformationsmanagement (PIM) angereichert, um die Produkte in den einzelnen Marktplätzen ansprechend und detailreich zu präsentieren. Individuelle Mappings der Daten pro Marktplatz sowie das korrekte Ansprechen der marktplatzspezifischen Programmierschnittstellen garantieren hierbei einen korrekten Ablauf. Datenänderungen im SAP System werden über einen Deltamechanismus zeitnah an die angebundenen Systeme weitergegeben. Bestellungen aus einem der Marktplätze (hier Marktplatz 1) werden über den Bestellprozess in der Integrationsplattform weitergereicht, die dann die Kommunikation mit den weiteren Systemen übernimmt. Auf diese Weise werden Sendungsaufträge für den Logistikdienstleister, Zahlungsinformationen für den Zahlungsprovider und schließlich auch die Informationen für die Picker generiert, die die Ware für den Versand kommissionieren. Die modellbasierte PAS-Lösung erlaubte es, während der Transformationsphase Altund Neusysteme im Parallelbetrieb zu fahren. Insgesamt führt das neue Konzept zu einer starken Vereinfachung, höherer Flexibilität bei der Einbindung neuer Komponenten, mehr Agilität in der Weiterentwicklung, zu höherer Transparenz und Zuverlässigkeit des Systems.

Abb. 4.16 Shop und Marktplatzanbindung über eine Integrationsplattform

74

4

Application Composition Platform Architecture

4.4 Low-Code Development 4.4.1 Lösung für den Digitalisierungsstau In vielen Unternehmen klagen Benutzer über zu komplizierte und unübersichtliche Benutzeroberflächen, die aufgrund des Kapazitätsmangels in der IT nicht verbessert werden oder es können innovative Ideen für schnell zu entwickelnde Lösungen nicht realisiert werden. Hier bietet das Low-Code-Konzept einen Ausweg aus der Verklemmung: Wenn die ITAbteilung nicht liefern kann, können oder müssen Mitarbeiter der Fachabteilungen selbst ihre Probleme lösen, wenn sie die geeigneten Werkzeuge dazu bekommen. Dieser Gedanke ist nicht ganz neu, sondern ist auch schon bei dem Konzept des „Robotic Process Automation (RPA)“ die Triebfeder (vgl. Kap. 8). Nur werden dort lediglich manuelle Schnittstellen zwischen verschiedenen Anwendungssystemen durch von Mitarbeitern der Fachabteilung entwickelten Software-Robotern überbrückt. Es werden aber keine neuen Anwendungen entwickelt. Der Anspruch von Low-Code ist deshalb höher, indem neue Anwendungen von IT-interessierten Mitarbeitern der Fachabteilungen entwickelt werden können. Wenn die Fachabteilungen selbst Anwendungen entwickeln, entfallen auch die häufig schwierigen und langwierigen Abstimmungszyklen zwischen Fachabteilungen und ITSpezialisten. Beiden Effekten, dem Kapazitätsmangel und den Abstimmungsproblemen wird durch das Low-Code-Konzept entgegengewirkt. Low-Code-Systeme werden allgemein als Low-Code Development Platform (LCDP) bezeichnet. Dafür gibt es einen eigenen Softwaremarkt. Im Zusammenhang mit dem hier behandelten Ansatz einer integrierten Application Composition Platform ist Low-Code dagegen ein eingebettetes Element der integrierten Plattform. Dieses ist dadurch begründet, da in Low-Code entwickelte Lösungen in der Regel auch eine Integrationsproblematik enthalten und eine Workflow-Unterstützung mit Prozessbeschreibung benötigen. Diese Funktionalität unter einheitlicher Oberfläche und Unterstützung des Lifecycles bietet nur eine integrierte Plattform. Der grundsätzliche Ansatz besteht darin, IT-affine Mitarbeiter in den Fachabteilungen, sogenannte Citizen Developer oder Power User, in die Lage zu versetzen, kleine (flache) Anwendungen selbst zu entwickeln, ohne dass dazu tiefe technische Kenntnisse erforderlich sind. Die Begriffe klein oder flach bedeuten nicht, dass die Anwendungen von geringerer Wichtigkeit für ein Unternehmen sind. Die „tiefen“ digitalen Anwendungen wie Logistik, Personalabrechnung und Produktion mit komplexen Bearbeitungsregeln, langen Entwicklungszeiten und hohem Integrationsbedarf werden weiterhin von klassischen ERP-Systemen und IT-Spezialisten unterstützt. Sie besitzen nur eine geringe Änderungsgeschwindigkeit (built to last). Daneben gibt es aber viele wichtige „flache“ Anwendungen, wie schnelle Kundenaktionen, Ablösung umständlicher Papiervorgänge, freundlichere Benutzeroberflächen, Datenauswertungen oder Zusätze zu den tiefen An-

4.4 Low-Code Development

75

wendungen. Diese unterstützen das turbulente Tagesgeschäft und besitzen eine größere Änderungsgeschwindigkeit (built to change). Die Bezeichnung Low-Code bezieht sich darauf, dass die Anwendungen durch eine grafische Modellierungssprache entwickelt werden, die durch automatische Umsetzung in eine Programmiersprache oder durch die direkte Interpretation der Modelle zur Ausführung gebracht wird. Bei der Modellierung kommt es mehr darauf an, das „was“ zu beschreiben, also deklarativ, als das „wie“ der prozeduralen Ausführung, wie es beim klassischen Programmieren der Fall ist. Eine komfortable Benutzeroberfläche und viele vorgefertigte Widgets unterstützen den Entwickler bei der Erstellung durch „drag and drop“. Widgets sind kleine Programme, die häufig als Standardelemente einer Anwendung eingesetzt werden und deshalb bereits vorgefertigt sind. Dem Low-Code-Ansatz wird dadurch eine 10-fache Entwicklungsgeschwindigkeit gegenüber einer klassischen Programmierung zugeschrieben. Im Extrem kann ein Programm allein durch Widget-Bausteine zusammengestellt werden. Dann spricht man auch von No-Code. Bei komplexen Problemen kann Low-Code seine Grenzen finden, und algorithmische Teile müssen durch professionellen Code (Pro-Code) entwickelt werden. Dazu muss sich das Low-Code-System zu einer Programmiersprache wie Java oder Java Script öffnen. Da das Fachwissen aber weiterhin im Vordergrund steht, ist dann eine kooperative Zusammenarbeit zwischen Citizen Developer und IT-Mitarbeitern erforderlich. Generell sollten auch örtlich verteilte Mitarbeiter an einer gemeinsamen Aufgabe arbeiten können. Dieses ist für die zunehmenden Homeoffice-Tätigkeiten und interdisziplinären Teams wichtig.

4.4.2

Funktionen

Die Architektur und Funktionen einer Low-Code-Plattform können durch drei Ebenen charakterisiert werden (vgl. Abb. 4.17 nach Sahay et al., 2020). Die Ebene 1 der Anwendungsebene ist die Sicht des Entwicklers und steht im Vordergrund. Hier stehen die Funktionen zur Verfügung, mit denen der Entwickler seine Anwendung modellieren kann. In dem Beispiel der Abb. 4.18 wird dazu die Modellierung und die automatische Umsetzung in eine Programmiersprache des Systems Scheer PAS gezeigt. Es handelt sich um die Bearbeitung von Bewerbungsunterlagen aus dem Personalbereich. Der Low-CodeEntwickler arbeitet mit der Oberfläche des Designers, die auf der oberen Seite abgebildet ist. Am rechten Rand sind die Modellierungsobjekte und Widgets angegeben, die durch drag and drop auf den Arbeitsbereich in der Mitte übertragen werden können. Als Modellierungssprache wird eine Teilmenge einer Standard-Prozessmodellierung wie BPMN und UML eingesetzt. Mit BPMN ist der Prozess, also der Workflow, abgebildet. Hier werden Integrationsfunktionen über Adapter oder Konnektoren z. B. zu einem

76

4

Application Composition Platform Architecture

Abb. 4.17 Hauptkomponenten von Low-Code-Systemen. (Quelle: Sahay et al., 2020)

SAP-System definiert. Mit den Widgets am rechten Rand können Formulare gestaltet werden. Kompliziertere Konstrukte wie Datenmodelle und Operationen werden in UML modelliert. Auf Ebene 2 wird die modellierte Anwendung dem Compiler übergeben, der die Anwendung auf Richtigkeit überprüft und optimiert. Anschließend wird das Modell automatisch in eine Programmiersprache übersetzt. Dazu besteht eine 1:1-Beziehung zwischen den Modellobjekten des Low-Code-Ansatzes und Konstrukten der Programmiersprache. Als Programmiersprache sollte eine Standardsprache wie Java oder Java Script zur Verfügung stehen, da bei einer proprietären Sprache des Anbieters die Gefahr eines Vendor-Lock-in besteht, da dann der Quellcode nur auf der Plattform des Low-Code-Anbieters ablaufen kann. Vor allem ist durch eine Standardsprache bei Einsatz von Pro-Code das Zielprogramm in einer einheitlichen Programmiersprache und der Quellcode kann auch außerhalb der Low-Code-Plattform verwendet werden. Die Nutzung von Pro-Code ist erforderlich, wenn kompliziertere Funktionen entwickelt werden müssen, die den Rahmen des Low-Code-Ansatzes überschreiten. Dazu werden hybride Teams aus Citizen Developern und professionellen Entwicklern zusammengestellt. Wichtig ist, dass die Entwicklungsumgebung bestehen bleibt, so dass ein einheitliches Zielprogramm entsteht. Datenaufrufe und Funktionsaufrufe aus anderen Systemen werden über APIs angebunden. Das Programm wird dann vom Compiler in den ausführbaren Code übersetzt. Anschließend wird das Programm der Hardware- und Betriebssystemebene in der geeigneten Form zur Verfügung gestellt (deployed). Bei Low-Code-Systemen, bei denen das Modell ohne Übersetzung in eine Programmiersprache direkt interpretiert und ausgeführt wird, können Modelle noch während der

4.4 Low-Code Development

77

Abb. 4.18 Code-Generierung aus Low-Code-Modell

Ausführung (Run-Time) geändert werden. Hier ist also eine sehr hohe Flexibilität in Bezug auf kurzfristige Änderungen gegeben. Dieses besitzt aber die Nachteile, dass mit der Interpretation der Metadaten bei jeder Ausführung ein Performance-Nachteil gegenüber einer vorherigen Kompilierung des Programms besteht und die Flexibilität auch zur Fehleranfälligkeit und Unkontrollierbarkeit führt.

78

4

Application Composition Platform Architecture

Auf Ebene 3 werden Modelle und Code für eine Weiterverwendung in einer Bibliothek abgelegt. Über eine Kollaborationsplattform können bei der Modellerstellung örtlich verteilte Teams gemeinsam an der Modell- und Programmerstellung arbeiten. In der Regel werden Low-Code-Plattformen als Cloudlösungen angeboten, um deren Komfort der vereinfachten Administration zu nutzen. Aber auch die Ausführung auf lokaler Hardware ist möglich. Insgesamt unterstützen Low-Code-Plattformen den gesamten Software-Lifecycle von der Modellierung, Entwicklung, Deployment, Ausführung bis zum Monitoring.

4.4.3 Typische Low-Code-Anwendungen und Erweiterungen Typische Anwendungen für Low-Code sind die Ablösung von Papier-Dokumenten durch digitale Workflows. In einer Behördenorganisation konnten dadurch Hunderte von Formularen wie Urlaubsanträge, Krankmeldungen und Beschaffungsanträge ersetzt werden. Aber auch weitergehende Anwendungen mit komplexeren Geschäftsregeln werden durch Citizen-Developer entwickelt, wenn sich die Anwendungen häufig ändern und das Fachwissen im Vordergrund steht. So kann für die Auswahl von Lieferanten für eine spezielle Verkaufsaktion von der Fachabteilung eine Lieferantenplattform entwickelt werden. Typische Anwendungen ergeben sich auch im Marketing, indem Werbeaktionen geplant, durchgeführt und kontrolliert werden. Zur Akquisition neuer Mitarbeiter können Aktionen wie Wettbewerbe, Preisausschreiben oder Informationsveranstaltungen organisiert und durchgeführt werden. Da die Benutzeroberflächen von Standardsoftware, insbesondere Dashboards, besonders oft an neue Anforderungen angepasst werden müssen, besteht eine Tendenz für sogenannte „Headless“-Anwendungssoftware. Hier wird die Anwendungssoftware ohne Oberfläche ausgeliefert und der Anwender kann das User Interface mit Low-Code selbst entwickeln und ständig anpassen. Im Extremen kann die gesamte Benutzeroberfläche zu den tiefen Systemen durch eigene Low-Code-Anwendungen entwickelt werden. Die tiefen Systeme werden dann quasi hinter ihnen versteckt und sind für den Anwender unsichtbar. Low-Code-Anbieter stellen im Zuge der Weiterentwicklung der Systeme immer mehr vorgefertigte Lösungen zur Verfügung, die von Kunden als Ausgangslösung für ihre Anwendung genutzt werden können. Diese können in eine Bibliothek zur Weiterverwendung eingestellt werden. Bekannte Hersteller von Standardsoftware für ERP, CRM oder Office-Anwendungen bieten Low-Code-Zusätze zu ihren Systemen an, um vom Anwender individuelle Erweiterungen entwickeln zu lassen. Diese sind aber vor allem auf die jeweiligen Hauptsysteme bezogen und stellen damit keinen unabhängigen Low-Code-Ansatz dar. Insgesamt bekommt das Gebiet Low-Code-Entwicklung eine so große Bedeutung, dass es bereits als neues Berufsbild innerhalb der Digitalisierung diskutiert wird.

4.4 Low-Code Development

79

Die Entwicklung zur (teil-)automatischen Softwareentwicklung ist mit dem LowCode-Ansatz sicher noch nicht abgeschlossen. Insbesondere durch den Einsatz von KI können disruptive Innovationen erwartet werden. Viele Zeilen eines Programms sind nicht einmalig, sondern werden in vielen anderen Programmen ebenfalls verwendet. Es ist üblich, Programmzeilen in der Dokumentation verbal zu kommentieren. Aus einer großen Datenmenge aus Kommentaren können dann über ein KI-System aus einer verbalen Aufgabenbeschreibung die zugehörenden Programmierstatements zugeordnet werden. Dann wird natürlich-sprachige Prozessbeschreibung automatisch in eine Programmiersprache übersetzt. Dieses klingt wie Zukunftsmusik, ist aber durchaus realistisch, wenn die Fortschritte KI-gestützter Übersetzungssysteme natürlicher Sprachen betrachtet werden, bei denen ein ähnlicher datengetriebener Ansatz verfolgt wird. Die Diskussion um das System Chat GPT (Generative Pre-trained Tranformer) von OpenAI belebt dazu die KI-Szene.

4.4.4

Anwendungsfall Low-Code

Die Berliner Verkehrsbetriebe (BVG) sind der größte kommunale Verkehrsbetrieb in Deutschland mit über eine Milliarde Fahrten im Berliner Nahverkehr pro Jahr. Viele einfache interne Prozesse waren umständlich und papierbasiert. Professionelle Entwicklungskapazitäten standen zur Digitalisierung der Abläufe nicht ausreichend zur Verfügung. Mit dem Projekt „EasyUse“ wurden deshalb 100 interne Antragsprozesse überwiegend von internen Mitarbeitern aus den Fachabteilungen mit Low-Code der Scheer PAS Plattform digitalisiert. Dieses waren u. a. Dienstreiseantrag, Reisekostenabrechnung, Umzug, Hardwareantrag, Bestellung von Reisetickets und Beanstandungsformular usw. Die Projektschritte waren:     

Prozessanalyse, Definition des Soll-Prozesses, Digitalisierung des Workflows und der Formulare, Anbindung an bestehende IT-Systeme durch APIs, Einbindung in ein benutzerfreundliches Portal (vgl. Abb. 4.19), Erstellung eines Analytics Dashboards als Grundlage für organisatorische Managemententscheidungen.

Durch das neue Verfahren konnten die Bearbeitungszeiten und Fehlerquoten der Fälle signifikant gesenkt werden. Die externen Projektkosten wurden innerhalb eines Jahres amortisiert.

80

4

Application Composition Platform Architecture

Abb. 4.19 Benutzeroberfläche eines mit Low-Code entwickelten Formularsystems für einen Verkehrsbetrieb

4.5

Composition

Wenn die PBCs und weiteren Bausteine wie Legacy-Systeme mit ihren API- und EventKanälen bereitgestellt sind, können sie zu einer Anwendung komponiert werden. Der Begriff Composition Application ist nicht neu (vgl. Weske, 2019, S. 571 ff.; Hansen et al., 2019, S. 176). Dort bezeichnete er den Vorgang, dass aus Softwarekomponenten eines bestehenden Systems ein neues System gebildet wird, das auf das vorhandene aufgesetzt wird. Im Gegensatz dazu wird hier unter Composition die Verbindung entwickelter und vorhandener Bausteine einer Bibliothek zu einem neuen Anwendungssystem verstanden. Dazu stellt die Application Composition Platform Unterstützungen bereit. Dieses bedeutet, dass die Bausteine über ihre API-Schnittstellen unter Nutzung des Prozesswissens für den Workflow miteinander verbunden werden (vgl. Abb. 4.20). Zu dem Prozesswissen gehören neben dem Kontrollfluss zwischen den Bausteinen auch die benötigten Daten und das Rollenkonzept zur Definition von Verantwortlichkeiten und Berechtigungen. Das Prozesswissen innerhalb der Bausteine, das bei ihrer Entwicklung einbezogen wurde, wird also um das übergreifende Wissen des Geschäftsprozesses zwischen den Bausteinen ergänzt. Beides wird durch Prozessmodelle bereitgestellt. Die User Experience des Anwenders wird über das User Interface mit Look and Feel definiert. Der Benutzer soll die Funktionen möglichst intuitiv finden und bedienen können. Ihm sollen keine vollgestopften Bildschirmmasken angeboten werden, sondern sie sollen ergonomisch ansprechend und übersichtlich gestaltet sein. Der Anwender soll dadurch motiviert werden, gerne mit der Lösung zu arbeiten und nicht von ihrer komplizierten Handhabung abgeschreckt werden. Durch das Testen der Entwürfe können Eigenschaften wie Dauer des Auffindens von gesuchten Befehlen usw. empirisch erhoben und verbessert werden. Gerade die Low-Code-Funktionalität eignet sich, um schnell alternative Entwürfe zu erstellen und die Experience zu optimieren. Die komfortable User Experience gilt zunehmend als ein wichtiges Gestaltungskriterium von Anwendungen. Software soll von der Erlebnissicht des Anwenders ausgehend entwickelt werden. Da aber gerade an der Benutzeroberfläche bei Eingabemasken, Be-

4.5 Composition

81

Abb. 4.20 Application Composition. (Quelle: Adobe Stock, PureSolution)

richten und Cockpits ständig Änderungswünsche auftreten, ist die Oberfläche nicht lange stabil zu halten und deshalb der Einsatz von Low-Code durch Mitarbeiter der Fachabteilung besonders sinnvoll. Dabei gilt es, für alle Anwendungen ein einheitliches Corporate Design zu schaffen, so dass der Anwender einen Wechsel zwischen verschiedenen Anwendungssystemen nicht bemerkt. Eine konsequente Weiterführung der Anforderungen ist das Konzept von „Headless Applications“. Hier wird der algorithmische Teil einer Anwendung konsequent von dem Frontend getrennt und dann z. B. bei Standardsoftware nur eine magere Oberfläche als quasi Ausgangslösung mitgeliefert. Das eigentliche User Interface wird dann individuell von den Anwendern aus den Fachabteilungen nach den einheitlichen Vorgaben des Unternehmens entwickelt. Wichtig ist auch die Multi-Channel-Fähigkeit von Anwendungen, d. h., der Zugang zu einer Anwendung muss über alle möglichen Endgeräte von Terminal, PC, Laptop, Notebook, Smartphone bis zu Smart Watches und Displays in Geräten wie Auto oder Maschinen (IoT) möglich sein. Das User Interface muss sich automatisch den Eigenschaften der Endgeräte anpassen.

82

4

Application Composition Platform Architecture

Nach Abschluss der Composition Funktion stehen für den Benutzer die über den Geschäftsprozess integrierten Anwendungen bereit. In Abb. 4.21 sind die Zusammenhänge als allgemeine Anwendungsarchitektur zusammengefasst. In der Mitte der Abb. 4.21 sind die Shared Services der zentralen Dienste angegeben. Sie fassen die eingesetzte Standardsoftware ERP, CRM oder SCM sowie selbstentwickelte Altsysteme zusammen. Sie werden über APIs mit der Plattform verbunden. Die API- und EDA-Schnittstellen sind durch die stark ausgezogenen Kanten der Umrandungen gekennzeichnet. Die PBCs als elementare Entwicklungseinheiten werden von vornherein mit APIs und EDA versehen und sind mit der Plattform verbunden. Das Prozesswissen ist in Form von Prozessmodellen erfasst und steht der Plattform zur Verfügung. Aus der Verbindung von Prozesswissen und den Business Capabilities werden die dezentralen Anwendungen als Ziel der Entwicklungen komponiert. Alle Systeme sind über Cloud-Technologie und Internet technisch miteinander verbunden. Neben den internen Anwendern können auch externe Entwickler, Kunden, Lieferanten und Partner über die Cloud und APIs auf Anwendungen des Unternehmens zugreifen, um unternehmensübergreifende Prozesse zu gestalten.

Abb. 4.21 Allgemeine Anwendungsarchitektur. (Quelle: Adobe Stock, PureSolution)

Literatur

83

Mit der Application Composition Platform stehen nun alle Entwicklungswerkzeuge zur Verfügung, um für das Composable Enterprise flexible und agile Innovationen zu entwickeln. In Kap. 5 wird dazu der Lifecycle mit der Development-Phase fortgesetzt.

Literatur Gartner (Hrsg.). (2021). Market guide for application integration platforms, G00737100 Hansen, H. R., Mendling, J., & Neumann, G. (2019). Wirtschaftsinformatik (12. Aufl.). Berlin, Boston: De Gruyter. Jost, W. (2022). Application composition platforms. Vortrag vor den Mitgliedern des Feldafinger Kreises, Feldafing, 22. Juli 2022. Mathijssen, M., Overeem, M., & Jansen, S. (2020). Identification of practices and capabilities in API management: A systematic literature review. Tech. rep. Utrecht University. http://arxiv.org/ abs/2006.10481 Sahay, A., Indamutsa, A., Di Ruscio, D., & Pierantonio, A. (2020). Supporting the understanding and comparison of low-code development platforms. In 2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) (S. 171–178). IEEE. Weske, M. (2019). Business process management: Concepts, languages, architectures (3. Aufl.). Berlin Heidelberg: Springer.

Weiterführende Literatur Bock, C., & Frank, U. (2021). Low-code platform. Business Information System Engineering, 63(6), 733–2021. IDC (2022). Intelligent Process Automation in Deutschland 2022 Scheer PAS (2022). Diverse Firmenveröffentlichungen zu der Application Composition Platform Scheer PAS und Anwendungsfällen BVG. https://www.scheer-pas.com/wp-content/uploads/ 2021/03/Scheer-PAS-Whitepaper-Platform-DE.pdf

5

Development

Zusammenfassung Im Vordergrund der Darstellung der Entwicklung der Komponenten des composable Unternehmens stehen die Packaged Business Capabilities (PBC) als Services und ihre Zusammenstellung zu Anwendungen. Der Entwicklungsprozess unterscheidet sich nicht wesentlich von der klassischen Softwareentwicklung und wird deshalb kurz gehalten. Zudem sind wichtige Aspekte der Entwicklung, wie Workflowsteuerung, Integration, Low-Code und Composition bei der Beschreibung der Aufgaben der Application Composition Platform im vorhergehenden Kap. 4 behandelt worden. Eine Besonderheit ist das hybride Organisationsmodell im Composable Enterprise. Klassische Standardsoftware wie ERP-, CRM- oder Procurement-Systeme werden auch in dem Composable Enterprise als Lösungen für den Shared Service von Bedeutung bleiben, besonders, wenn sie sich ebenfalls der Plattformarchitektur zuwendet und flexibler wird. Deshalb wird das modellgetriebene prozessorientierte Customizing von Standardsoftware am Beispiel der SAP-Software behandelt. Abb. 5.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_5

85

86

5

Development

Abb. 5.1 Development/Implementation. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

5.1

Entwicklung der Packed Business Capabilities

Eine Business Capability ist eine betriebliche Funktion oder eine Prozesseinheit und ist bezüglich der Granularität nicht fest definiert. In einer PBC wird diese durch Software umgesetzt. Allgemein ist eine PBC eine in sich abgeschlossene Softwareeinheit mit weitgehend eigener Datenhaltung und benötigten Betriebssystemdiensten sowie Schnittstellen durch APIs und oder Eventsteuerung (EDA). PBCs können zu größeren PBCs verdichtet werden. PBCs reichen von feinen Microservices über betriebliche Teilprozesse bis hin zu kompletten Anwendungen und Unternehmensprozessen. Beispiele sind eine KI-Anwendung zur Dokumentenerkennung, eine Bonitätsprüfung in einem Vertriebsprozess, ein analytisches Auswertungsverfahren oder eine komplexe Auftragsbearbeitung. Um allerdings die Granularität möglichst klein zu halten und damit flexibel zu sein, neigen PBCs eher zu der Konzeption von Microservices. Sie werden dann erst durch die Komposition mehrerer PBCs zu einer Anwendung. Werden PBCs mit einer Containertechnologie (z. B. mit den Open-Source-Produkten Dogger und Kubernetes) verbunden, sind sie autark und auf beliebiger Hardware ablauffähig.

5.1 Entwicklung der Packed Business Capabilities

87

Ein Container ist eine technisch autarke Einheit aus Software, Daten, Betriebssystemfunktionen, Hilfsprogrammen, die auf unterschiedlicher Hardware ablauffähig ist. Er kann auf der Ebene von CBCs oder auch ganzen Anwendungen gebildet werden. Werden Anwendungen aus mehreren Containern zusammengesetzt, so kommunizieren sie über APIs. Z. B. ist es sinnvoll, Anwendungen in zwei Container aufzuspalten: einen für den Backend-Teil als quasi Headless Application und einen für den Frontend-Teil mit dem User Interface. Dadurch können beide Teile unabhängig voneinander weiterentwickelt werden. Dieses ist für den Frontend-Teil besonders wichtig, weil hier über Low-Code schnell Änderungen und Zusätze eingefügt werden können, um die User Experience zu verbessern. Eine PBC besteht somit aus einem Prozessmodell, Softwarecode, Daten und den Interfaces. Bei hoher Mächtigkeit einer PBC können auch das User Interface, Process Mining und Monitoring sowie das Management der Versionen und Berechtigungen Bestandteil sein. Um aber die letztgenannten Funktionen übergreifend zu gestalten, sollten sie in der Regel erst bei der Composition der PBCs zu einer Anwendung angefügt werden. Die entwickelten PBCs werden auf einem Marktplatz bereitgestellt, um ihre Mehrfachverwendung zu unterstützen. Auf diesem Marktplatz können auch von Anbietern bezogene Standard-PBCs aufgenommen und verwaltet werden, wenn sie die Anforderungen an Kapselung und Interfaces erfüllen. Wird eine Anwendung von der Fachabteilung mit Low-Code entwickelt, aber für komplizierte Teile auch professionelle Programmierung und Integration benötigt, wird ein hybrides Team aus Fachabteilung und IT gebildet. Projektleitung sollte wegen der Dominanz des fachlichen Inhalts die Fachabteilung einnehmen (vgl. Abb. 5.2). Bei der Entwicklung ist ein agiles Vorgehensmodell nach SCRUM sinnvoll, braucht aber wegen der im Allgemeinen gegenüber den tiefen Unternehmensanwendungen überschaubaren Größenordnung der Projekte nicht übertrieben formal gestaltet zu werden. Der Ablauf über das Process Modeling, der Entwicklung durch das hybride Team, dem Testen, Composition und dem Deployment (Bereitstellung) in die Cloud weicht kaum von dem klassischen Ablauf einer Anwendungsentwicklung ab. Die Inhalte sind aber, wie bei den Aufgaben der Plattform beschrieben, unterschiedlich. Zusammenfassend sind in Abb. 5.3 der Ablauf und die beteiligten Rollen der Akteure aufgeführt: Dabei sind Rücksprünge in dem Ablauf, z. B. nach einer Fehlererkennung möglich.

88 Abb. 5.2 Hybrides Projektteam aus Fachabteilung und IT

Abb. 5.3 Development Process. (Quelle: Adobe Stock, PureSolution)

5

Development

5.2 Modellgestütztes Customizing von Standard-Unternehmenssoftware

89

Die Funktionen der Akteure sind: Innovatoren (Innovators): Entwickeln im Team neue Geschäftsmodelle und -prozesse.

Unternehmensarchitekten (Enterprise Architects): Modellieren die modulare Architektur der Prozesse des Unternehmens und pflegen das EA-System. Software-Designer und Entwickler (Developer): Entwerfen und entwickeln die modularen Building Blocks (PBCs).

Kuratoren (Curators): Verwalten (Manage) den Marktplatz (Bibliothek) von Building Blocks. Komponisten (Composers): Benutzen Building Blocks und die Integrationsfunktion, um Building Blocks unter Nutzung des Prozesswissens zu Anwendungen zusammenzufügen. Anwender (Consumer): Benutzen Anwendungen, um Unternehmensziele zu erreichen.

Damit ist der erste Halbkreis des Composable Enterprise Lifecycles der Abb. 1.11 aus Sicht der Entwicklung von Composable Applications abgeschlossen.

5.2 Modellgestütztes Customizing von StandardUnternehmenssoftware Der Einsatz unternehmensweiter Standardsoftware wie ERP-Systeme wird insbesondere für die Shared Services weiterhin eine große Bedeutung behalten. Sie betreffen Anwendungen, die wenig individuelles Differenzierungspotenzial besitzen und sind bewährte und stabile Standardlösungen, die von Softwarehäusern eingesetzt werden. Werden diese Systeme unternehmensweit zentral eingesetzt, wird dabei dem Prinzip der Ressourcenoptimierung gefolgt. Auch Standard-Unternehmenssoftware wird sich in Zukunft dem hier verfolgten Paradigmenwechsel zu Plattform- und Modulkonzept annähern, um flexibler auf Erweiterungen und Änderungen eingehen zu können. Gleichzeitig können Softwarehäuser, die für neue Lösungen cloudbasierte Software zugekauft haben, das Integrationsproblem vereinfachen. Bei einer Integration über eine zentrale Datenbank müssen die zugekauften Systeme wesentlich überarbeitet und angepasst werden. Bei einer Integration über die Plattform können die individuellen Datenorganisationen beibehalten werden und weniger

90

5

Development

aufwendige API-Schnittstellen entwickelt werden. Anstelle einer festen Kopplung über eine zentrale Datenbank wird dann dem Prinzip einer lockeren Kopplung gefolgt. Hierdurch werden bei dem Softwarehersteller Entwicklungskapazitäten frei, die zur Entwicklung weiterer Anwendungen und damit auch höherem Nutzen für den Anwender führen. Das Softwareunternehmen SAP folgt mit seiner Business Technology Platform (BTP) bereits diesem Weg. Die Modellierung von Geschäftsprozessen ist heute Standard in Business-Process-Management (BPM)-Projekten und Grundlage der Dokumentation sowie des Customizings von Standard-Anwendungssoftware geworden. Insbesondere hat SAP dazu ein starkes Signal gegeben. Bei einer modellgestützten Einführung von Unternehmenssoftware wird zunächst das Soll-Prozessmodell mit den gewünschten Abläufen entwickelt. Ist über die einzuführende Standardsoftware bereits entschieden, ist es sinnvoll, das Soll-Modell bereits auf die Nomenklatur und die grobe Funktionalität der Software auszurichten. Dazu können Referenzmodelle der Softwareanbieter oder Beratungsunternehmen genutzt werden. Anschließend werden die Parameter der Standardsoftware auf das Soll-Modell eingestellt. Dazu wird das Soll-Modell in ihre Customizing-Tools importiert1 . Beim Customizing können vom Soll-Modell die benötigten Teilprozesse der StandardSoftware identifiziert und Parameter für Entscheidungsregeln in die Software übernommen werden, so z. B. Wertgrenzen für die Behandlung von Kreditwürdigkeitsprüfungen. Das Soll-Modell kann ebenfalls zur Unterstützung weiterer Parametrisierungen, Steuerung von Arbeitspaketen, Dokumentation der Abläufe und des Projektfortschritts, Unterstützung des Testens bis hin zur Schulung der Endanwender verwendet werden.

Abb. 5.4 Verbindung Scheer Referenzmodelle mit dem Solution Manager SAP AG 1

Die Scheer GmbH hat für mehrere Industrien Referenzmodelle unter der Bezeichnung „Scheer performanceREADY (SPR)“ entwickelt, die von Kunden an ihre Bedürfnisse zu einem individuellen, SAP-orientierten Soll-Modell angepasst und dann mit dem Solution Manager der SAP weiterverarbeitet werden können. Der SAP „Solution Manager 7.2“ besitzt eine offene API-Schnittstelle für Modellierungswerkzeuge, an die sich auch die ARIS-Werkzeuge andocken können, um Modelle auszutauschen (vgl. Abb. 5.4). So können z. B. in EPK oder BPMN erstellte Prozessmodelle sowie zusätzliche Informationsobjekte wie Projektdokumentationen oder Testfälle importiert und synchronisiert werden.

5.4 Schulung der Anwender

91

Es soll darauf hingewiesen werden, dass IT-Systeme zentral zur Verfügung gestellt werden können, aber für dezentrale Einheiten als Mandanten im Rahmen der Möglichkeiten des Customizings individuell konfiguriert werden können. Die autarke Steuerung der Module des Composable Enterprise geht aber darüber hinaus, indem eigenständige Lösungen entwickelt werden.

5.3

Projektsteuerung

Umfangreiche Projekte zur digitalen Transformation des Unternehmens können mehrere Monate bis Jahre umfassen. Entsprechend wichtig ist die Steuerung hinsichtlich Termintreue, Kosten und Qualität. Dazu werden spezielle Projektplanungssysteme eingesetzt. Diese besitzen wegen ihres Dokumentationswertes auch über das Projektende hinaus große Bedeutung. Die Projektdokumente sind Basisinformationen für spätere Änderungen und Erweiterungen und tragen zur Aktualisierung einer Enterprise Architecture bei. In Kap. 3 ist dazu ein Konzept vorgestellt worden, in dem ein Projektsteuerungsansatz auch als kontinuierliches Aktualisierungstool für eine dynamische Enterprise Architecture genutzt wird.

5.4

Schulung der Anwender

Eine Anwendung ist nur so gut, wie die Anwender sie benutzen. Verstehen sie ihre Inhalte und Nomenklatur nicht oder weicht die Benutzeroberfläche ungewohnt und stark von der bisherigen ab, so kann dieses zum Scheitern des Projektes führen, wenn die Benutzer nicht ausreichend geschult werden. Die Bedeutung des Benutzertrainings wird häufig unterschätzt, da Projekte vornehmlich auf die Entwicklung und Implementierung fokussiert werden. Dann scheint das Projekt mit dem „Go Life“ abgeschlossen. Dieses ist besonders dann der Fall, wenn das Projekt von der IT-Abteilung geleitet und verantwortet wird. Für die Anwender beginnt aber erst mit dem Go Life ihre Arbeit. Der Schulungsaufwand kann bei größeren Anwenderzahlen leicht 10 bis 20 % der Projektkosten betragen und wird deshalb gerne zunächst außer Acht gelassen, um die Projektkosten optisch zu drücken. Dieses kann sich später rächen. Sind die Anwender nicht in der Lage, das fertige System fachgerecht zu bedienen, müssen z. B. externe Berater als Coaches eingesetzt werden, um die Benutzer einzuarbeiten. Neben den klassischen Schulungsformaten durch Präsenzkurse und Schulungsunterlagen werden immer mehr Online-Schulungen genutzt. Da der Mensch vergesslich ist, sollten Schulungsunterlagen im Anwendungssystem digital hinterlegt werden und bei Bedarf kontextgesteuert dem Benutzer zugespielt werden. In Kap. 6 wird darauf unter dem Thema Case Management weiter eingegangen.

6

Execution und Operational Performance Support (Case Management)

Zusammenfassung Bei einer Prozessinstanz mit vielen menschlichen Entscheidungspunkten, Unsicherheiten, Fehlermöglichkeiten und Änderungen durch Kundenanforderungen ergibt sich ein eigenes Problemfeld der Prozesssteuerung. Dieses ist z. B. bei Produktions- und Logistikabläufen, aber auch beim Onboarding von Mitarbeitern, Kundenreklamationen innerhalb einer Auftragsabwicklung oder Kreditprüfungen der Fall. Mit dem Begriff Operational Performance Support wird die operative Unterstützung einzelner Prozessinstanzen während ihrer Ausführung behandelt. Ziel ist es, die Instanzen während ihrer Bearbeitung (pre mortem) durch weitgehend automatisierte Hilfen in RealTime zu unterstützen. Dies wird durch Assistenzsysteme, intelligente Algorithmen oder Künstliche Intelligenz auf Basis der Real-Time-Daten umgesetzt. Zur Demonstration von zufallsabhängigen Abläufen wird ein Logistikbeispiel mit der Reaktion auf das Eintreffen komplexer Ereignisse behandelt. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Die Abb. 6.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_6

93

94

6 Execution und Operational Performance Support (Case Management)

Abb. 6.1 Kreislauf einer Prozessinstanz. (Quelle: Adobe Stock, PureSolution und Gorodenkoff)

6.1

Vom Soll-Prozessmodell zu Prozessinstanzen

Die Unterstützung der Ausführung einzelner Prozessinstanzen wird als Operational Management, Operational Performance Support, oder auch Case Management bezeichnet. Mit der Implementierung und dem Deployment einer Prozesslösung ist der Weg von der Problemerkennung bis zum lauffertigen Anwendungssystem abgeschlossen. Aber erst die Ausführung der Prozesse zeigt, ob sich das geplante Ergebnis einstellt. Theoretisch sollte die Ausführung der Instanzen dem Soll-Geschäftsprozessmodell folgen. Dieses ist aber nur dann der Fall, wenn das Modell die Logik aller möglichen realen Geschäftsinstanzen umfasst, die Software das Modell exakt abbildet und bei der Ausführung keine Abweichungen auftreten. Alle Abläufe sind dann vordefiniert und laufen entsprechend ab. In der Realität treten dagegen Abweichungen vom „Happy Path“ auf, indem vorgesehene Zuordnungen von Organisationseinheiten wie Mitarbeiter oder Maschinen zu Funktionen geändert werden, Prioritäten zwischen den Aufträgen sich ändern, Bearbeitungen unterbrochen werden, zeitlich verschoben werden oder technische Störungen auftreten. Der Mensch greift dann ein und ändert ad-hoc Abläufe gegenüber dem Soll-Modell. In Abb. 6.2 sind die 3 möglichen Instanzenmodelle aus dem Beispiel der Auftragsbearbeitung mit Kreditprüfung der Abb. 3.4 in Kap. 3 dargestellt. Start- und End-Ereignisse der Funktionen sind dabei explizit angegeben, da diese ausführliche Schreibweise des Beispiels auch im nächsten Kapitel verwendet wird.

6.1 Vom Soll-Prozessmodell zu Prozessinstanzen

95

Abb. 6.2 Instanzenmodelle der Auftragsbearbeitung nach Abb. 3.4

Die Instanz 34711 beschreibt den Fall, dass die Kreditprüfung negativ verläuft, somit der Auftrag abgelehnt und der Kunde darüber informiert wird. Die Instanz 34712 führt aufgrund des geringen Auftragswertes zu einer Bearbeitung ohne Kreditprüfung. Der Kunde und die Finanzabteilung werden nach Abschluss der Bearbeitung informiert. Bei der Instanz 34713 verläuft die Kreditprüfung positiv, der Auftrag wird bearbeitet und Kunde sowie Finanzabteilung werden über das Ende der Bearbeitung informiert. Als logische Konnektoren sind nur noch die „AND“-Verknüpfungen enthalten, da bei Ist-Instanzen keine alternativen Abläufe und damit keine „XOR“-Verbindungen mehr vorkommen. In den Funktionen werden die Entscheidungen zur Laufzeit getroffen, die zu Verzweigungen führen. Dadurch sind die Abläufe gegenüber dem Prozessmodell mit seinen XOR-Beziehungen und damit verschachtelten Prozessen viel leichter zu verstehen. Darauf wird in Kap. 7 zurückgekommen. Mit dem Operational Performance Support beginnt ein neuer Kreislauf von dem Start der Instanzenbearbeitung bis zu ihrem Abschluss. Der Innovationskreislauf in Abb. 1.11 wurde dazu um den Ausführungskreis auf der linken Seite ergänzt. In Abb. 6.3 ist der Kreislauf der Ausführung mit den wichtigsten Datengruppen herausgestellt. Die Nähe zur Ausführung wird auch durch die Verbindung zu Produktionssystemen dargestellt. Da der einzelne Prozessablauf betrachtet wird, ist er durch einen dünneren Strich gegenüber dem Gesamtkreis gekennzeichnet. Ziel ist es, die Ausführung der Instanzen noch während ihrer Bearbeitung (pre mortem) durch weitgehend automatisierte Hilfen in RealTime zu steuern, verfolgen (monitoring) und intelligent zu leiten (navigieren). Die Instanz wird anschließend mit den anderen Prozessinstanzen einer Betrachtungsperiode gesammelt und (post mortem) periodisch durch das Process Mining ausgewertet. Dieses wird in Kap. 7 behandelt.

96

6 Execution und Operational Performance Support (Case Management)

Abb. 6.3 Prozesskreislauf einer Instanz im Rahmen des operational support

Der Operational-Performance-Support-Kreis wird durch die Real-Time-Daten der Instanzausführung, Daten des Prozessumfeldes, durch intelligente Algorithmen sowie durch fachlichen Content gesteuert. Zum Real-Time-Prozessumfeld gehören z. B. die Zustände der eingesetzten Ressourcen, Termine, Sensordaten oder die Verfügbarkeit benötigter Materialien. Die Funktionen des Ausführungskreislaufs umfassen die Planung und Steuerung der Instanz, die ereignisgesteuerte Reaktion auf Zustandsänderungen des Prozesses, vorausschauende Analysen und Handlungsvorschläge zur Vermeidung ungeplanter Effekte sowie Online-Lernhilfen für Benutzer in Problemsituationen.

6.2 Prozessplanung und -steuerung Für die industrielle Fertigungssteuerung sind zahlreiche Optimierungsverfahren im Rahmen der Operations Research entwickelt worden, die auch von übergreifenden Konzepten wie dem der Industrie 4.0 übernommen wurden und weiterentwickelt werden (Koop & Moock, 2018; Goel & Agarwal, 2021; Nickel et al., 2022). Der Fertigungsbereich besitzt einen Vorsprung in der Prozessplanung und -steuerung, weil schon früh die Ausnutzung der teuren und komplexen technischen Fertigungsanlagen eine sorgfältige Steuerung der Produktion erforderten. Nach Optimierungskriterien wie z. B. Minimierung der Durchlaufzeit der Instanzen oder Maximierung der Kapazitätsauslastung werden die einzelnen Arbeitsschritte einer Fertigungsinstanz (also eines Fertigungsauftrages oder -prozesses) in eine Reihenfolge geordnet und den Bearbeitungsplätzen zugeordnet. Dazu liegen in Industriebetrieben mit den Arbeitsplänen detaillierte Prozessbeschreibungen vor.

6.3 Process Monitoring

97

Im vergleichsweise einfacheren und ressourcenarmen Verwaltungsbereich wurde im Gegensatz zur Fertigung mehr auf die Selbststeuerungsfähigkeiten der Mitarbeiter gesetzt. Dieses reicht aber bei der zunehmenden Komplexität und dem Wettbewerbsdruck auf Kosten, Zuverlässigkeit, Qualität und Geschwindigkeit von Prozessen im modernen Verwaltungsbereich nicht mehr aus. Deshalb gewinnt die Prozesssteuerung eine generelle Bedeutung. Grundsätzlich können die Steuerungsverfahren der Industrie auch in Dienstleistungsunternehmen wie Krankenhäusern und Verwaltungsbereichen eingesetzt werden oder zumindest Anregungen für deren Lösungen geben. In diesen Bereichen stehen anstelle der Arbeitspläne dann Prozessmodelle mit ihren Funktionsbeschreibungen zur Verfügung. Dann besteht prinzipiell die gleiche Datengrundlage wie in der Fertigung und kann zur Anwendung von Steuerungsalgorithmen der Instanzen eingesetzt werden.

6.3

Process Monitoring

Während der Ausführung kann der Bearbeitungsfortschritt durch Monitoring in RealTime verfolgt werden. Moderne Anwendungssysteme geben Zustandsänderungen als Ereignisdaten in einer Logdatei bekannt, z. B. den Abschluss oder Beginn einer Aktivität, also die Änderung von „in Arbeit“ zu „Arbeit abgeschlossen“ oder von „wartend“ zu „in Arbeit“. Damit sind die Zustände aller einzelnen Prozesse auch bei Verwaltungsprozessen zu jedem Zeitpunkt bekannt. Damit können die in der Steuerung von Fertigungsprozessen bewährten Systeme prinzipiell für alle Prozesstypen, bei denen eine genaue Steuerung sinnvoll ist, eingesetzt werden. MES (Manufacturing Execution Systems) und Leitstandskonzepte gestatten im Fertigungsbereich einen transparenten Überblick über die gerade bearbeiteten und zur Bearbeitung anstehenden Arbeitsgänge. Damit können Arbeitsschritte, Aufträge und Ressourcen ständig überwacht, geplant und gesteuert werden. Im Zentrum steht dabei die grafische Plantafel, wie sie Abb. 6.4 zeigt. Diese Ansätze können prinzipiell auch in Dienstleistungs- und Verwaltungsbereichen zur Steuerung des Aufgabenflusses angewendet werden. Wertvolle Auswertungen sind Terminabweichungen zwischen Ist und Soll, die zu Neuund Umplanungen mit Hilfe der Optimierungsalgorithmen führen. Wird der Prozess in Real-Time verfolgt und als Prozessmodell abgebildet oder sogar fotorealistisch dargestellt, so bilden diese digitale Zwillinge (vgl. Kap. 3, Abschn. 3.6 sowie in Kap. 10 den Abschn. 10.1).

98

6 Execution und Operational Performance Support (Case Management)

Abb. 6.4 Leitstandsoberfläche für die Fertigungssteuerung. (SAP AG)

6.4 Complex Event Processing (CEP) Bei Prozessen im Verwaltungsbereich, wie sie von ERP-Systemen unterstützt werden, ist die kleinste Einheit die Funktion oder Aktivität. Die Prozesse werden durch den Kontrollfluss gesteuert. Entscheidungsregeln, die Verzweigungen in der Run-Time steuern, werden den Funktionen zugeordnet oder als quasi eigene „Funktion“ bei der Prozessmodellierung ausgegliedert. Mit dem Konzept DMN (Decision Model and Notation) gibt es einen Standard zur Modellierung von Entscheidungsregeln. Da Entscheidungen, z. B. bei einer Kreditprüfung, eine Vielzahl von Kriterien wie Bekanntheit der Person, früheres Zahlungsverhalten, Höhe des Betrages usw. umfassen können, besteht eine komplexe Situation, die auch nur teilweise formalisiert werden kann. Deshalb ist bisher Entscheidungsmodellierung keine zentrale Aufgabe der Geschäftsprozessmodellierung, sondern es werden nur die bekannten möglichen Ergebnisfälle, also Ablehnung oder Annahme, im weiteren Ablauf betrachtet. Anders verhält es sich im technisch nahen Umfeld mit gut strukturierten Entscheidungen, guter Datenqualität und hohem Automatisierungsgrad. Hier können die Entscheidungsregeln direkt in den Ablauf eingefügt werden. Da sich Verwaltungsprozesse durch zunehmende Automatisierung dieser Situation annähern, soll darauf eingegangen werden. Durch Konzepte wie IoT können auf feiner Granularebene in Fertigungs- und Logistikprozessen oder Anwendungen in Smart City, Smart Car oder Smart Home Monitoringund Steuerungsfunktionen durch Nutzung von Sensoren und Aktoren unterstützt werden. Sensoren liefern aus den Objekten (Geräten), die den Prozess ausführen, Ereignisse über Zustände und Zustandsänderungen. Diese können dann in Real-Time von einem Complex Event Processing (CEP)-System ausgewertet werden und als Grundlage für sofortige Entscheidungen (Real-Time Decision Support) genutzt werden. Die Vorgänge werden gegenüber den bisher betrachteten Geschäftsprozessen auf einer detaillierteren und mehr

6.4 Complex Event Processing (CEP)

99

technischen Ebene betrachtet. Es ist zu erwarten, dass CEP durch die Zunahme des Einsatzes von Sensoren eine immer größere Bedeutung in allen Branchen und Prozesstypen erlangen wird. Bei dem mehr betriebswirtschaftlichen Prozessmanagement steht der Kontrollfluss des Geschäftsprozesses, also die Reihenfolge der auszuführenden Funktionen mit logischen Verzweigungen, im Vordergrund. Bei CEP stehen die technischen Objekte und die Definition von interessierenden Ereignissen, ihre Zusammenfassung zu komplexeren Mustern (Pattern) und auszulösende Real-Time-Aktionen im Vordergrund. Damit ändert sich die Betrachtung der Funktionen zu Ereignissen bzw. zu Daten. Die Ereignisse sind dabei in ihrer Reihenfolge und ihres zeitlichen Auftretens stochastischen Einflüssen unterworfen. Wegen der fast unübersehbar hohen Anzahl kontinuierlich anfallender Daten werden im allgemeinen nur gefilterte Events mit ihren Reaktionen behandelt. Beispiele für Daten einer Logistikanwendung sind Erfassen der Transportgüter durch Radio Frequency Identification (RFID), gelieferte Messwerte von Sensoren für Start des Fahrzeuges, Messung der Temperatur im Laderaum, Standort des Fahrzeuges durch GPS usw. Da derartige Daten kontinuierlich verfolgt werden können und deshalb zu Massendaten führen, werden interessierende Ereignisse durch Entscheidungsregeln bestimmt. So ist nicht jedes Temperaturergebnis interessant, sondern nur die Überschreitung eines kritischen Wertes. Auch können einzelne Messwerte zu komplexen Ereignissen verdichtet werden, z. B. Überschreitung eines Temperaturwertes für eine bestimmte Zeitdauer. Event Based Systems (EBS) stellen u. a. kontinuierliche Monitoring-Funktionen bereit, um aus den Event Streams interessierende Muster (Patterns) zu filtern. Das mehr betriebswirtschaftlich ausgerichtete Process Management und das mehr technisch ausgerichtete CEP haben sich zunächst unabhängig voneinander entwickelt. Durch die zunehmende Automatisierung rücken beide Gebiete näher. Dadurch kann die betriebswirtschaftliche Prozessbeschreibung stärker differenziert und durch Entscheidungsregeln ergänzt werden. Die Modellierungssprachen müssen dazu entsprechend erweitert werden. Wegen der grundsätzlichen Bedeutung des Event-Processing wird das Prinzip von CEP in Anlehnung an ein Beispiel aus Pnina Soffer et al. (2017, S. 10) konkretisiert. In dem betriebswirtschaftlichen Logistikmodell der Abb. 6.5 ist die Funktion „Transport der Güter von einem Lager des Lieferanten zu dem Empfänger“ lediglich als eine einzige Funktion innerhalb des gesamten Prozesses dargestellt. Die umrandete Transportfunktion wird in Abb. 6.6 detailliert aufgelöst. An dem Transport sind drei Akteure beteiligt: Der Lastkraftwagen, das CEP-Monitoring-System und eine organisatorische Planungs- und Steuerungseinheit des Unternehmens.

Abb. 6.5 Betriebswirtschaftliches Transportmodell

100

6 Execution und Operational Performance Support (Case Management)

Abb. 6.6 Verfeinerter Transportprozess. (Nach Soffer et al., 2017)

Es wird damit angenommen, dass die Waren von dem bestellenden Unternehmen mit eigenem Fahrzeug selbst abgeholt werden. Bei der Beauftragung eines Fremdunternehmens würde die detaillierte Prozessverfolgung von diesem durchgeführt werden und die Funktion „Transport“ in dem Prozessmodell des Bestellers würde in der verdichteten Form der Abb. 6.5 bestehen bleiben. Bei dem Beispiel handelt es sich um den Transport von Arzneimitteln, bei denen eine maximale Fahrzeit sowie Bedingungen für Temperatur und Erschütterungen eingehalten werden müssen. Das Monitoring-System verfolgt die Fahrt und sendet Standortinformationen, Verkehrsdichte, Temperatur und Feuchtigkeit im Laderaum an das System des Planers. Diese Daten können dann zu Entscheidungen über zu ändernde Fahrtrouten genutzt werden. Auch werden Start und Ende der Fahrt automatisch erfasst und dem Planer übermittelt. Aus den Funktionen „Laden der Container“ und „Entladen der Container“ werden Statusmeldungen direkt an die Steuerungseinheit gegeben. Auch diese können automatisch, z. B. über RFID-Scanner erfasst und weitergegeben werden. Das CEP ist eine wertvolle Erweiterung der Prozesssteuerung sowohl im Rahmen des in Kap. 7 behandelten Process Mining als auch des Operational Performance Support.

6.5

Predictive Performance Support

Während der Bearbeitung einer Prozessinstanz können die Prozesszustände mit dem SollProzessmodell verglichen werden, um z. B. den zu erwartenden Endtermin des Prozesses zu ermitteln. Das Soll-Modell ist allerdings auf der Typ-Ebene erstellt und stellt einen gewünschten Ablauf dar. Von einem bestehenden Zustand einer Prozessinstanz aus be-

6.5 Predictive Performance Support

101

trachtet, enthält der weitere Ablauf noch Verzweigungen, die an Bedingungen geknüpft sind, die zum gegenwärtigen Zeitpunkt noch nicht bekannt sind. Für diese müssen bei einer Prognose des weiteren Ablaufs Erwartungswerte angesetzt werden. Auch können die Instanzen früherer gleichartiger Prozesse für Prognosen über den weiteren Ablauf ausgewertet werden. Bei einer Auftragsbearbeitung kann z. B. auf die gespeicherten Auftragsprozesse des gleichen Kunden und/oder auf Prozesse zu den gleichen bestellten Produkten anderer Kunden zugegriffen werden. Die dort realisierten Abläufe können dann zur Beurteilung des weiteren Ablaufs der gegenwärtigen Instanz dienen. Die historische Logdatei muss dazu entsprechend zugriffsfreundlich organisiert werden. Aufgrund der heute verfügbaren hohen Speicherkapazitäten ist die Speicherung umfangreicher historischer Prozessinstanzen wirtschaftlich vertretbar. In beiden Fällen ist das Ziel, für einen gegebenen Zustand einer Prozessinstanz den weiteren Ablauf zu prognostizieren und Handlungsempfehlungen für dessen Verbesserung zu ermitteln. Die Prognose des zu erwartenden Ablaufs und die daraus abgeleiteten Entscheidungsempfehlungen für den weiteren Ablauf können mit den Funktionen eines Fahrzeugnavigationssystems verglichen werden (van der Aalst, 2011). Dieses zeigt z. B. bei einer plötzlichen Straßensperrung sofort die geänderte erwartete Ankunftszeit an und schlägt für den gegebenen Zustand eine neue Route vor. Der Blick wird also von dem Bearbeitungszustand der Instanz nach vorne gerichtet, um sich auf neue Situationen einzustellen oder ungünstige Entwicklungen zu vermeiden. Dazu werden in dem Gebiet der Predictive Analytics, insbesondere des Machine Learnings der KI, entsprechende Algorithmen entwickelt. Machine Learning-Algorithmen „lernen“ aus Beobachtungen ein Systemverhalten, um es für Prognosen auszuwerten. An Produktionsanlagen werden zahlreiche Sensoren angebracht, die Temperatur, Schwingungen, Energieverbrauch usw. kontinuierlich messen. Diese Datenströme können von neuronalen Netzen ausgewertet und zu Prognosen für erforderliche Wartungsarbeiten genutzt werden. Bei einem hohen Automatisierungsgrad der Softwareunterstützung können Bots eingesetzt werden, d. h. autonom arbeitende Softwareprogramme, die ohne Interaktion mit Menschen das Verhalten einer Anlage überwachen, analysieren und auf zu erwartende Ereignisse aufmerksam machen oder selbst steuernd eingreifen. Die Application Composition Platform bietet hierzu Schnittstellen zu KI-Plattformen an, um entsprechende Algorithmen nutzen zu können. Gleichzeitig geben das API-Konzept und die Event-Steuerung die Voraussetzung zur Integration der Lösungen in den Prozessablauf. Abb. 6.7 und 6.8 zeigen ein Beispiel des Saarbrücker Unternehmens IS Predict GmbH, das zum Innovationsnetzwerk der IDS Scheer Holding GmbH gehört, zur vorausschauenden Qualitätssicherung. Ein Automobilzulieferant setzt 10 gleichartige Schleifmaschinen für hochpräzise Bearbeitungsvorgänge ein. Obwohl die Maschinen die gleichen Eigenschaften aufweisen und vom gleichen Hersteller stammen, treten unterschiedliche Qualitätseffekte auf.

102

6 Execution und Operational Performance Support (Case Management)

Abb. 6.7 Qualitätsprognose nach 5 s. (Quelle: ispredict)

Abb. 6.8 Qualitätsprognose nach 37 s. (Quelle: ispredict)

Ziele der Analyse sind, die Störfaktoren des Prozesses zu identifizieren und die Qualität der Bearbeitung einer Instanz fortlaufend zu prognostizieren, um bei schlechter werdender Qualität steuernd einzugreifen, da später entdeckte Qualitätsmängel zu hohen Ausschusskosten führen. Dazu werden für das mechanische Bearbeitungsergebnis 5 Kennwerte (KPIs) wie Rauheit der Oberfläche, Schleiftiefe, Schleifwinkel und Druck definiert, die in Real-Time für das Werkstück von Sensoren gemessen werden. Durch den KI-Algorithmus der Software wird der Zusammenhang zwischen diesen Werten und dem gesamten Qualitätsmerkmal „gut/schlecht“ ermittelt und während der Bearbeitung fortlaufend dazu eine Prognose erstellt. Der gesamte Bearbeitungsvorgang eines Werkstücks dauert eine Minute und umfasst 5 Arbeitsschritte. Nach einer Bearbeitungszeit von 5 s des ersten Arbeitsschrittes (vgl. Abb. 6.8) sind drei der Kennwerte im grünen Bereich, während jeweils ein Kennwert bereits rot bzw. gelb ist. Insgesamt wird prognostiziert, dass das Werkstück fehlerfrei sein wird. Dieses wird durch den oberen grünen Balken angezeigt. Nach 37 s sind zwei der

6.6 Real-Time-Lernhilfen

103

Indikatoren rot und einer gelb und das System prognostiziert, dass die gesamte Qualität noch ordnungsgemäß sein wird, gibt aber – wie der gelbe Balken anzeigt – eine Warnung an. Dies kann zum Anlass genommen werden, nach dem Bearbeitungsvorgang die Maschine bzw. das Schleifwerkzeug neu zu justieren oder auszutauschen. In dem System werden verschiedene Datenquellen (Sensoren) mit dem Modell verbunden. Das Modell wird laufend mittels Lernalgorithmen an neue Erkenntnisse angepasst. Es liefert Informationen über Anomalien (z. B. die Veränderung des Laufverhaltens einer Anlage), Prognosen (z. B. den günstigsten Wartungszeitpunkt der Anlage), kann für What-if-Simulationen genutzt werden (z. B. die Wirkung einer vorgezogenen Wartung auf den Produktionsplan erkennen) und schlägt Steuerungseingriffe vor (z. B. die Reduzierung der Produktionsgeschwindigkeit oder Wartungsmaßnahmen). Einige Beispielfälle sollen den Predictive- und Steuerungsansatz weiter illustrieren:  In einem Automobilwerk werden durch die Analyse von Sensordaten bereits nach dem Press- und Stanzvorgang kleinste Fehler in der Karosserie aufgedeckt, die bei späterer Entdeckung zu hohen Folgekosten führen würden. Werden z. B. die Haarrisse erst bei der Endmontage entdeckt, so wird die Fehlerbehandlung sehr teuer.  In einem Zementwerk wird aus Sensordaten frühzeitig prognostiziert, welche Qualität das Zementpulver nach dem letzten Prozessschritt erreichen wird. Die Maschinen können vorausschauend so eingestellt werden (Prescriptive Analytics), dass die gewünschte Qualität erreicht wird.

6.6 Real-Time-Lernhilfen Besonderes Augenmerk gilt auch Real-Time-Lernhilfen für Benutzer während der Bearbeitung einer Instanz. Trifft ein Bearbeiter auf eine Situation, die er nicht versteht, so können ihm direkt Informationen zugespielt werden, die bei der Bearbeitung weiterhelfen. Für die Hilfe-Unterstützung von IT-Systemen werden bisher Helpdesks eingerichtet, an die sich der Benutzer wenden kann oder er fragt Kolleginnen bzw. Kollegen. Zur Automatisierung dieser Helpdesk-Funktionen sollen neue Entwicklungen der digitalen Lernunterstützung dienen. Seit langem wird im Lernumfeld die 70:20:10-Regel diskutiert. Sie besagt, dass 70 % des Lernens beim „Doing“ stattfindet, 20 % durch Austausch mit Kollegen und nur 10 % durch formales Vorratslernen. Deshalb ist die Lernmotivation in einem konkreten Problemfall sehr hoch. Ein System, das dem Anwender kontextbezogen die jeweils benötigten Informationen zuspielt, muss die Anwendung und den gerade bearbeiteten Prozessschritt kennen sowie über Wissen (Content) über Unterstützungsmaßnahmen verfügen. Abb. 6.9 zeigt die Architektur des Systems „Process Guide“ des Unternehmens „imc AG“ in Saarbrücken. Das Unternehmen wurde vom Verfasser gegründet und gehört zum Innovationsnetzwerk der IDS Scheer Holding GmbH (imc AG, 2017a).

104

6 Execution und Operational Performance Support (Case Management)

Abb. 6.9 Architektur des Systems „Process Guide“ der imc AG

Mitarbeiter des Anwenderunternehmens erstellen zusammen mit externen Beratern mit dem Modul „Designer“ Micro-Inhalte und Hilfetexte, die mit dem Modul „Manager“ verwaltet werden. Dazu zerlegen sie Inhalte vorhandener Schulungsunterlagen, Benutzerhandbücher oder Systembeschreibungen in kleinere Einheiten. Auch können Texte, Bilder, Screenshots oder Videos erstellt werden. Hierzu wird das Erfahrungswissen besonders tüchtiger Mitarbeiter genutzt. Die gespeicherten Daten werden aufgrund neuer Erfahrungen ständig aktuell gehalten, sodass Lerneffekte entstehen. Mehrere Autoren können parallel über ihren jeweiligen Designer Inhalte erstellen und auch von anderen Autoren erstellte Inhalte einsehen und bearbeiten. Auf der Anwenderseite wird der Benutzer Schritt für Schritt durch den Prozess geführt (navigiert). Das Modul „Guide“ ruft in einer Problemsituation kontextsensitiv die passenden Hilfeinformationen automatisch vom Modul „Manager“ ab. Die Informationen sind individualisiert und auf das Bildungsniveau des Benutzers abgestimmt. Die Ausgaben werden auf die unterschiedlichen Endgeräte ausgerichtet. Werden systematische Wissensdefizite beim Benutzer festgestellt, so wird er gezielt gefördert. Zur Unterstützung von Compliance wird der Anwender in Real-Time über die Einhaltung relevanter Richtlinien informiert. Bei Bedarf werden Verbindungen zu menschlichen Experten und dem Helpdesk über Social-Media-Funktionen hergestellt. Das System unterstützt die Bearbeitungsprozesse sowohl im computerunterstützten Büro als auch in der Fertigung. Im Büro wird es insbesondere zur Benutzerunterstützung von Standard-Anwendungssoftware eingesetzt und hat dort erhebliche Rationalisierungserfolge erzielt, so in einer großen Versicherung bei der Einführung von SAP-Software und in der öffentlichen Verwaltung bei der Einführung von Microsoft-Software (imc AG, 2017b). In der Fertigung werden Mitarbeitern, z. B. bei einer Maschinenumstellung, Erläuterungstexte zu der Maschine auf sein Smartphone oder auf eine Augmented-Reality (AR)-

6.6 Real-Time-Lernhilfen

105

Brille eingeblendet. Augmented Reality besagt, dass der Anwender über die von ihm beobachtete Realität, also hier die Maschinensituation, aus einer Datenbank zusätzliche Informationen erhält. Mit der Kamera seines Smartphones kann er die Maschinensituation scannen, und das System ermittelt die sinnvollsten Hilfen. AR-Datenbrillen sind transparent, sodass der Mitarbeiter weiterhin sein Blickfeld sieht und die Hände für manuelle Tätigkeiten frei bleiben (vgl. Abb. 6.10). Eine weitere Anwendung in der Fertigung sind Reparaturanweisungen, die bei einem plötzlichen Maschinenausfall zugespielt werden. Neben Augmented Reality sind Virtual Reality (VR)-Anwendungen immer mehr von Bedeutung. Bei einer VR-Anwendung taucht der Anwender in eine virtuelle Welt ein und kann sich in ihr frei bewegen. Durch eine 360-Grad 3D-Kamera werden dem Anwender in Real-Time detaillierte Aufnahmen zur Verfügung gestellt, mithilfe derer er bereits geringfügige Materialfehler erfassen kann. In Abb. 6.11 ist eine Datenbrille mit dem Blick in ein Motorgetriebe dargestellt, in das eine Minikamera eingebaut ist.

Abb. 6.10 Anweisungen auf Smartphone oder einer ARDatenbrille. (Quelle: imc AG, 2017c)

Abb. 6.11 VR-Brille mit Blick in ein laufendes Getriebe. (Quelle: imc AG)

106

6 Execution und Operational Performance Support (Case Management)

Sogar im laufenden Betrieb kann er dann Wartungsarbeiten vornehmen. Durch Kombination mit AR werden auch Kommentare und Hilfstexte in Real-Time in die Bilder eingeblendet. Das Forschungsinstitut „August-Wilhelm Scheer Institut für digitale Produkte und Prozesse“ in Saarbrücken führt intensive Forschungsprojekte zu VR-Anwendungen in Bildung und Industrie 4.0 durch, aus denen auch die VR-Darstellung in Abb. 6.11 stammt (Linn et al., 2017). Der Einsatz von Hologrammtechnik durch Produkte wie die HoloLens von Microsoft eröffnet weitere Perspektiven. Damit werden Techniken und Funktionen angesprochen, die bei der Schilderung von Perspektiven des web3 und Metaverse in Kap. 9 behandelt werden. Insgesamt zeigen die vielseitigen Anwendungsfälle des Operational Performance Supports dessen breite Innovationskraft. Alle Anwendungen lösen Probleme der Fachabteilungen und sollten von diesen maßgeblich entwickelt werden. Die einzelnen Anwendungen bilden Application Capabilities, die über APIs auch mit den betriebswirtschaftlichen Backoffice-Anwendungen verbunden werden.

Literatur Goel, A., & Agarwal, R. (2021). Operation research. Technical Publications. imc (2017a). imc Process Guide – Produktpräsentation. https://www.im-c.com. Zugegriffen: 22. Mai 2018. imc (2017b). Informelles Lernen und Electronic Performance Support – So können Sie Ihre internen Helpdesk-Kosten um 40 % senken. https://www.im-c.com. Zugegriffen: 22. Mai 2018. imc (2017c). AR/VR Training – Zum Einsatz von Augmented & Virtual Reality im Corporate Training. https://www.im-c.com. Zugegriffen: 22. Mai 2018. Koop, A., & Moock, H. (2018). Lineare Optimierung – eine anwendungsorientierte Einführung in Operations Research. Springer Spektrum. Linn, C., Bender, S., Prosser, J., Schmitt, K., & Werth, D. (2017). Virtual remote inspection – A new concept for virtual reality enhanced real-time maintenance. In 2017 23rd International Conference on Virtual System & Multimedia (VSMM) (S. 1–6). IEEE. https://doi.org/10.1109/VSMM. 2017.8346304. Nickel, S., Rebennack, S., Stein, O., & Waldmann, K. H. (2022). Operations research. Berlin, Heidelberg: Springer. Soffer, P., Hinze, A., Koschmider, A., Ziekow, H., Di Ciccio, C., Koldehofe, B., Kopp, O., Jacobsen, A., Sürmeli, J., & Song, W. (2017). From event streams to process models and back: Challenges and opportunities. Information Systems. https://doi.org/10.1016/j.is.2017.11.002. van der Aalst, W. M. P. (2011). Process mining – Data science in action (2. Aufl.). Heidelberg: Springer.

7

Insight durch Process Mining

Zusammenfassung Anwendungssysteme speichern bei der Ausführung von Prozessen Daten über Start und Ende von Funktionen in sogenannten Logdateien. Die Verwaltung und Auswertung dieser Datenspuren von Geschäftsprozessen wird als Process Mining bezeichnet. Der Aufbau von Logdateien wird anhand eines Beispiels beschrieben und die wesentlichen Aufgaben des Process Minings wie Prozessmodellgenerierung und Prozessmodellvergleich werden behandelt. In der Regel bezieht sich das Process Mining auf die Datenquelle Logdateien. Aber auch die automatische Aufzeichnung von Benutzeraktivitäten am Frontend liefert Datenspuren zum Process Mining. Dieses Task-Mining wird am Ende des Kapitels behandelt. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Die Abb. 7.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_7

107

108

7

Insight durch Process Mining

Abb. 7.1 Process Mining. (Quelle: Adobe Stock, PureSolution)

7.1

Mining auf der Basis von Logdateien

Die automatische Suche in Datenbeständen, um Muster und Zusammenhänge zu erkennen und diese in gut verständlicher, häufig grafischer Form aufzubereiten, wird generell als Data Mining bezeichnet. Beim Process Mining wird dieses Vorgehen auf Geschäftsprozesse angewendet. Während der Ausführung von Prozessinstanzen werden Datenspuren über Start und Ende von Bearbeitungen, über ausführende Organisationseinheiten usw. hinterlassen. Anwendungssoftware speichert diese Ereignisse wie Start und Ende einer Transaktion (also einer Funktion) als Daten in sogenannten Logdateien. Eine andere, noch wenig verbreitete, Datenquelle ist die Beobachtung und Aufzeichnung der Benutzeraktivitäten (Tasks) am Frontend. Für das Process Mining steht Software zur Verfügung. Die häufig in der Literatur angegebene Jahreszahl 2008, in der ein erstes Process Mining Tool auf den Markt gebracht wurde (so z. B. Peters & Nauroth, 2019) entspricht nicht den Tatsachen und soll deshalb hier korrigiert werden1 . 1

Die Beschäftigung mit der Analyse von Prozessinstanzen wurde Mitte der 1990er Jahre von der ARIS-Entwicklungsgruppe der IDS Scheer AG begonnen. Insbesondere hatten Dr. Helge Hess und Dr. Wolfram Jost führenden Anteil an den kreativen Ideen. Das erste Process Mining System wurde von der IDS Scheer AG mit dem Produkt ARIS PPM (Process Performance Manager) im Jahr 2000 für den Markt freigegeben und konnte im gleichen Jahr bereits erste Anwender gewinnen und eine Partnerschaft mit der SAP AG schließen. Instanzenprozesse konnten visualisiert werden und das Ist-Prozessmodell generiert werden. Vergleiche zwischen Ist- und Soll-Modell wurden 2–3 Jahre später freigegeben. Das System ARIS PPM wird seit 2009 von der Software AG weiterentwickelt und weltweit vertrieben.

7.1 Mining auf der Basis von Logdateien

109

Ab 2008 ist eine Reihe erfolgreicher Process Mining Tools von Start-Ups entwickelt worden, die aber inzwischen zum großen Teil von Herstellern von Anwendungssoftware übernommen worden sind, da Process Mining als Standardfunktion Bestandteil jeder Anwendung erkannt wurde. Dies zeigt auch die Akquisition des Unternehmens Signavio im Jahr 2021 durch die SAP AG. Mit dem System Celonis ist ein Marktführer mit einem eigenständigen Produkt verblieben. Auch das von der IDS Scheer im Jahr 2000 eingeführte System ARIS PPM, das von der Software AG ab dem Jahr 2009 weiterentwickelt wird erreicht bei aktuellen Analystenbewertungen Spitzenplätze und wird international vertrieben. In der akademischen Anwendung dominiert das Open-Source-Produkt „Process Mining Framework (ProM)“ (Munoz-Gama, 2016; van der Aalst & Weijters, 2004), das aber in der Praxis kaum eingesetzt wird. In der Forschung hat sich das Process Mining zu einem mathematisch-formal arbeitenden Gebiet entwickelt. Insbesondere die Arbeiten von Wil van der Aalst mit einem großen internationalen Netzwerk von Autoren bestimmen es intensiv. Aufgrund der starken Formalisierung sind die Problemstellungen und Aussagemöglichkeiten vieler Arbeiten sehr speziell und treffen nicht immer auf eine den Aufwand rechtfertigende praktische Bedeutung. Als Standardaufgaben des Process Mining zählen:  Model Discovery (Ermittlung eines Ist-Prozessmodells aus Ereignisdaten),  Model Comparison (Vergleich von Ist-Modell mit anderen Prozessmodellen),  Model Enhancement (Verbesserung des Soll-Modells aufgrund der Ergebnisse). In der Praxis ist im dritten Punkt das Interesse nicht nur auf die Verbesserung des Modells gerichtet, sondern auch auf Maßnahmen zur Verbesserung des Prozessverhaltens durch Automatisierung und Organisationsänderungen. Das Task-Process Mining als ein alternativer Ansatz zum Log Datei Mining geht von der Sicht des Arbeitsplatzes des Anwenders aus, an dem unterschiedliche IT-Systeme eingesetzt sowie auch manuelle Tätigkeiten ausgeführt werden. Alle Tätigkeiten werden durch einen Softwarerecorder automatisch erfasst und aus ihnen Prozessmodelle generiert. Der Ansatz wird auch als Desktop-Activity Mining bezeichnet. Logdatei basiertes Mining und Task-Mining sollen zur Verbesserung des Prozessmanagements führen. Sie können Auskunft geben, ob bei der Prozessausführung Compliance-Regeln eingehalten oder verletzt wurden, an welchen Stellen Kapazitätsengpässe entstanden sind, ob von im Soll-Modell vorgesehenen Prozesswegen oder vorgesehenen Kapazitätszuordnungen abgewichen wurde oder wie sich Durchlaufzeiten verhielten. Daraus können Schlussfolgerungen zur Verbesserung der Prozesse durch organisatorische Änderungen, stärkere Automatisierung oder Schulung von Mitarbeitern gezogen werden. Treten gravierende Erkenntnisse über Mängel auf, die zur grundsätzlichen Überprüfung der Prozessstruktur Anlass geben, können Anwendungen zur Verbesserung entwickelt

110

7

Insight durch Process Mining

werden. Damit wird dann der Innovationskreislauf neu begonnen. Der Start des Kreislaufs kann demnach entweder durch eine Innovationsidee oder durch Verbesserungen bestehender Lösungen gestartet werden.

7.1.1

Aufbau der Logdatei

Ausgang des Process Mining sind Logdateien aus einem oder mehreren Anwendungssystemen, z. B. ERP-, CRM-Workflow oder eigenentwickelten Composite-Systemen. Diese speichern während der Laufzeit Ereignisdaten mit Attributen. Je nach System können diese nach Art, Granularität und Umfang unterschiedlich sein. Ereignisse sind Zeitpunktgeschehen und bezeichnen eine Zustandsänderung durch eine Funktion in einem Bearbeitungsprozess. Funktionen sind z. B. Anlegen eines Auftrages, Kreditprüfung oder Zahlung. Typische Ereignisse sind dann Start oder Ende einer Funktion. Bei immer wichtiger werdenden Logistik- oder IoT-Anwendungen wie Smart City, Smart Home oder Smart Car werden zunehmend Ereignisse einbezogen, die aus Sensoren, Bilderkennern oder RFID-Scannern geliefert werden (Soffer et al., 2017). Auch diese Ereignisse können in der Logdatei erfasst werden. Eine erste Aufgabe des Process Mining ist es, die Ereignisdaten eines Prozesses aus mehreren Anwendungen zu harmonisieren und in einer einheitlichen Datei zur Auswertung zur Verfügung zu stellen. Diese wird auch als Ereignisprotokoll bezeichnet. Zur Vereinfachung wird hier der Begriff Logdatei beibehalten. Bei der Harmonisierung können sich Probleme ergeben, indem Daten falsch, unwichtig oder unvollständig sind. Dieses wird als Rauschen (noise) bezeichnet (Burattin, 2015). Auch kann die Identifikation einer Prozessinstanz durch mehrere Ident-Nummern und unterschiedliche Namensgebungen in verschiedenen Systemen schwierig sein. Zur Lösung dieser Aufgaben werden spezielle Algorithmen entwickelt (Munoz-Gama, 2016). Der Aufbau einer Logdatei wird an dem einfachen Beispiel des Prozessmodells der bereits oben eingeführten Auftragsbearbeitung aus Abb. 3.4 und 6.2 gezeigt. In Abb. 6.2 sind die drei möglichen Instanzenmodelle: sofortige Bearbeitung, Bearbeitung nach Kreditprüfung und Ablehnung nach Kreditprüfung, mit den Start- und Endereignissen der Funktionen aufgeführt. Da die Ereignisse die Datenlieferanten der Logdatei sind, zeigt sich der Vorteil der EPK-Methode mit ihrer expliziten Darstellung. Als logische Konnektoren können nur noch die „AND“-Verknüpfungen auftreten, da bei Ist-Instanzen keine alternativen Abläufe mehr vorkommen können. In der Logdatei der Abb. 7.2 sind die von einem fiktiven Auftragsbearbeitungssystem erzeugten Ereignisdaten der drei Abläufe eingetragen. Pro Ereignis ist jeweils eine Zeile angelegt. Jedem Ereignis wird eine Ereignis-ID zugeordnet und bezeichnen entweder Start oder Ende einer Funktion. Die Instanzen sind nach ihren Fallnummern und Zeitstempeln gruppiert. Die Zeitstempel sind nach Tag, Monat

7.1 Mining auf der Basis von Logdateien

111

Abb. 7.2 Logdatei der fiktiven Auftragsbearbeitung

und Uhrzeit erfasst, die je nach System beliebig fein sein können, z. B. bis auf Millisekunden genau. Jedem Ereignis ist die bearbeitende Organisationseinheit zugeordnet. Die letzte Spalte steht stellvertretend für weitere beschreibende Attribute, z. B. Qualitätsangaben, Mengen, Kosten usw. Diese Daten stehen für Auswertungen zur Verfügung.

7.1.2

Auswertungen der Logdatei

Eine Logdatei nach der Struktur der Abb. 7.2 bietet bereits eine Basis für viele praktische Auswertungen über das reale Prozessverhalten, indem z. B. die statistischen Verteilungen der Bearbeitungszeiten pro Funktion dargestellt werden. Ebenso können Auslastungsstatistiken für Organisationseinheiten ermittelt werden. Erste Aufschlüsse geben auch DirektFolge-Graphen (Laue et al., 2021, S. 194). Die einzelnen Instanzen können nach ihren Start- und Endzeiten zeitlich grafisch dargestellt werden (vgl. Abb. 7.3 für die drei Instanzen des Beispiels). Dieser Auswertung fehlt aber der Bezug zu dem Prozessmodell, da der Kontrollfluss der Funktionen mit logischen Verzweigungen und Nebenläufigkeiten aus der Logdatei nicht intuitiv ersichtlich ist. Deshalb ist für prozessbezogene Auswertungen zusätzlich ein Prozessmodell erforderlich, das diese Informationen algorithmisch aus der Logdatei generiert.

112

7

Insight durch Process Mining

Abb. 7.3 Zeitlicher Ablauf der drei Beispielinstanzen

7.1.3 Generierung des Ist-Modells Das Ist-Modell wird aus den tatsächlichen bearbeiteten Prozessabläufen ermittelt und repräsentiert die reale Situation der Prozessausführung der betrachteten Periode. Es enthält deshalb keine Wege, die zwar grundsätzlich möglich, aber in der aktuellen Logdatei nicht enthalten sind. Zur Modellgenerierung sind Algorithmen entwickelt worden. Diese werden hier nicht im Einzelnen dargestellt (vgl. dazu aber z. B. Munoz-Gama, 2016; van der Aalst, 2011). Es werden nur einige Plausibilitätshinweise für das Vorgehen der Algorithmen gegeben. Wenn z. B. eine Funktion F1 in der Logdatei immer zeitlich vor der Funktion F2 ausgeführt wird, dann kann daraus die logische Anordnungsbeziehung F2 NACH F1, also eine Sequenz, angenommen werden. Wenn eine Funktion F3 immer nach Ausführung von F1 und F2 folgt, F1 und F2 aber zeitlich parallel ausgeführt werden, dann liegt die Vermutung einer UND-Verknüpfung zwischen (F1, F2) und dem Eingang von F3 vor. Treten bestimmte Funktionen in den Instanzen nach einer bestimmten Funktion auf, aber nie gemeinsam, so lässt dieses auf eine exklusive ODER (XOR)-Beziehung schließen. Treten Funktionen mal gemeinsam auf und mal nur einzeln, dann lässt dieses auf eine Inklusiv-ODER (OR)-Beziehung schließen. Auf Basis derartiger Überlegungen lässt sich ein Algorithmus zur Modellgenerierung entwickeln. Ein generiertes Modell ist immer nur so gut, wie es die Datenbasis zulässt und bezieht sich nur auf den Ermittlungszeitraum. Es ist umso repräsentativer, je mehr Instanzen ein-

7.1 Mining auf der Basis von Logdateien

113

bezogen werden. Deshalb sollte die Berechnung mit möglichst einer großen Anzahl (viele Hundert) durchgeführt werden. Eine grundsätzliche Problematik bei jeder Modellerstellung, sei sie manuell oder automatisch, sind die Effekte von Über- und Unterbestimmung (Overfitting, Underfitting). Bei Überbestimmung ist das Modell zu detailliert und enthält zu viele unwichtige Einzelfälle. Dies ist z. B. bei einem Auftragsprozess der Fall, wenn Aufträge für unterschiedliche Produktgruppen, sowie große und kleine Aufträge, Export- und Inlandsaufträge, Standard- und kundenbezogene Einzelaufträge, in einem gemeinsamen Modell erfasst werden. Die unterschiedlichen Bearbeitungswege führen dann zu einem unübersichtlichen Modell („Spaghetti“-Modell). Im Extrem verliert die Modellierung dann ihren Sinn. In Abb. 7.4 ist ein generiertes Spaghetti-Modell (aus van der Aalst, 2011) für den Behandlungsprozess in einem Krankenhaus wiedergegeben. Es ist aus einer Logdatei mit 24.331 Ereignissen, die zu 376 Funktionen gehören, ermittelt worden. Die Unübersichtlichkeit ist darauf zurückzuführen, dass unterschiedliche Krankheiten mit verschiedenen Verläufen in einem gemeinsamen Modell erfasst werden. Dieses führte zu dem genannten Effekt der Überbestimmtheit (Overfitting). Bei einer Aufteilung der Fälle nach den unterschiedlichen Krankheitsarten und dafür getrennt generierten Modellen würden sich klarere Modellstrukturen ergeben. Dazu muss neben der Logdatei auch Fachwissen zur Separierung der Fälle eingebracht werden. Die organisatorische Schichtung von Unternehmensprozessen nach Produktarten ist auch eine Grundhaltung der Organisation des Composable Enterprise zur Modularisierung, um Einfachheit und damit Flexibilität und Agilität zu erreichen. Bei Unterbestimmung ist ein Modell zu grob und damit wenig aussagekräftig. Dieses ist z. B. der Fall, wenn nur eine der drei Instanzen aus Abb. 7.2 als generelles Modell angesetzt würde.

Abb. 7.4 Generiertes „Spaghetti“-Modell aus van der Aalst (2011)

114

7

Insight durch Process Mining

Eine Balance zwischen Über- und Unterbestimmung zu finden, ist sowohl bei manueller Modellierung als auch bei der algorithmischen Generierung eine Herausforderung. Dazu sind Algorithmen entwickelt worden, die ein vorliegendes Modell bereinigen, indem z. B. Funktionen, die ganz selten benutzt werden, aus dem Modell entfernt werden oder Wege, die sich sehr ähneln, zusammengelegt werden. Als Ergebnis der Generierung und Überarbeitung liegt dann ein Modell vor, das die Kontrollstruktur der einbezogenen Prozessinstanzen komprimiert wiedergibt. Bei Anwendung eines Discovery-Algorithmus wird das Prozessmodell der Abb. 3.4 von der Logdatei der Abb. 7.2 komplett erfasst, da alle drei möglichen Instanzen als Input vorliegen. Dieses ist natürlich auf die Einfachheit des Beispiels zurückzuführen. Bei Hunderten Funktionen, vielen Instanzen und nicht beendeten Instanzen ergeben sich komplexere Probleme für eine Überarbeitung. Da das generierte Modell alle Ausnahmefälle und viele Einzelheiten enthält, sollte es durch Algorithmen automatisch auf wesentliche und benutzerfreundliche Strukturen überarbeitet werden. Dazu können unwichtige Elemente, die nur ganz selten auftreten und keinen Beitrag zum Prozessverständnis liefern, entfernt werden (Elimination) und ähnliche Objekte zu größeren Objekten zusammengefasst werden (Aggregation) (vgl. Tsagkani & Tsalgatidou, 2022). Auch können zum besseren Verständnis und zur Vereinfachung für unterschiedliche Fragestellungen einzelne Sichten (z. B. nach ARIS: Kontrollstruktur, Organisation, Daten, Leistung) auf das Modell gerichtet werden, um seine Komplexität zu reduzieren. Trotzdem soll der Inhalt der Logdatei weitgehend erhalten bleiben.

7.1.4

Vergleich Logdatei mit Prozessmodell

Durch Vergleich der in der Logdatei erfassten Prozessabläufe mit dem Prozessmodell kann geprüft werden, ob alle vom Modell geforderten Wege eingehalten wurden. Umgekehrt kann geprüft werden, ob alle im Modell enthaltenen Prozessabläufe in der Logdatei realisiert wurden. Abweichungen zum generierten Modell treten auf, wenn dieses nach der Generierung überarbeitet wurde und nicht nur eine andere Repräsentation der Inhalte der Logdatei ist. Bei einem vorgegebenen (manuell erstellten) Soll-Modell ergeben sich in der Regel Unterschiede. Es basiert auf externem Wissen des Modellierers und kann weniger und mehr Inhalte als die Logdatei enthalten. Für die Übereinstimmung von Modell und Logdatei können Maßzahlen herangezogen werden (vgl. die Formeln in Abb. 7.5 nach Laue et al., 2021, S. 204 und 206). Für eine Beurteilung, inwieweit ein generiertes Modell oder ein vorliegendes Soll-Modell die Instanzen der Logdatei repräsentieren, können die Maße Fitness und Präzision verwendet werden (Laue et al., 2021, S. 203 ff.). Fitness bezeichnet, wie groß der Anteil der Instanzenwege der Logdatei ist, die in dem Modell enthalten sind. Bei einem vollständig aus der Logdatei generierten Modell ohne

7.1 Mining auf der Basis von Logdateien

115

Abb. 7.5 Maßzahlen für Fitness und Präzision

Überarbeitung ist dieser Wert gleich 1. Bei einem kleineren Wert sind in dem Modell Abläufe der Logdatei nicht enthalten. Bei einem generierten Modell können z. B. hinterher bewusst Wege in dem Modell ausgeschlossen worden sein. Bei einem Vergleich mit einem Soll-Modell wird dieser Wert unter 1 sein, da das Modell nicht alle Sonderfälle der Realität umfassen kann und wegen des Problems des Overfitting auch nicht sollte. Bei einem Wert von 0,8 sind z. B. 20 % der Abläufe der Logdatei nicht in dem Modell vorhanden. Das Präzisionsmaß bezeichnet den umgekehrten Fall, wie hoch der Anteil der im Modell enthaltenen Abläufe in der Logdatei aufgezeichnet wurden. Bei einem vollständig generierten Modell ist der Wert gleich 1. Ist der Wert kleiner als 1, dann sind nach der Generierung Instanzen der Logdatei ausgeschlossen worden. Bei dem Vergleich mit einem Soll-Modell ist der Wert eher kleiner 1, da in einer Periode kaum alle möglichen Wege des Modells ausgeführt werden. Bei einem Wert von 0,8 sind 20 % der im Modell enthaltenen Wege in der Logdatei nicht aufgetreten. Ein Modell sollte sinnvolle Prozessabläufe enthalten, die über die in einem Periodenausschnitt realisierten Abläufe hinausgehen, es sollte also generellere Aussagen zulassen. Bei einem Wert knapp unter 1 liegt deshalb eher ein Underfitting vor. Da die Berechnung der möglichen Wege in einem Prozessmodell nicht einfach ist, sind die Formeln zu Fitness und Präzision eher erhellende Einsichten als praktische Berechnungsmöglichkeiten. Je nach Detailliertheit, der in der Logdatei zur Verfügung gestellten Attributdaten können auch inhaltliche Prüfungen vorgenommen werden, indem z. B. Abweichungen zwischen im Modell geplanten und tatsächlich angefallenen Kosten pro Instanz und Funktion ermittelt werden. Dazu kann, durch das Prozessmodell geführt, auf weitere Unternehmensdaten der Anwendungssysteme zugegriffen werden. Eine optisch eindrucksvolle Auswertung ist die animierte Simulation der abgelaufenen Prozesse, indem die einzelnen Instanzen im Zeitraffer das grafische Modell durchlaufen.

116

7

Insight durch Process Mining

Den Funktionen des Ist-Prozessmodells können aus der Logdatei gemittelte Ist-Werte für Attribute zugeordnet werden. Interessant sind z. B. Mittelwerte und Varianzen der Durchlaufzeiten der einzelnen Funktionen. Da aus dem Kontrollfluss die Folgefunktionen bekannt sind, können auch deren logisch früheste Startzeiten ermittelt werden, mit ihren tatsächlichen Startzeiten verglichen und daraus unerwünschte Wartezeiten sowie Engpässe erkannt werden. Wird eine Funktion wiederholt nacheinander in einem Zyklus bearbeitet, so weist dieses auf Qualitätsprobleme bei der Bearbeitung hin. Aus der Analyse von Verzweigungen können die Häufigkeiten der Ergebnisse von Entscheidungsregeln ermittelt und deren Sinnhaftigkeit überprüft werden. Eine weitere Auswertung betrifft die Kommunikationsbeziehungen zwischen Organisationseinheiten2 . Für die Fraud (Betrugs)-Analyse können durch Kombination von Prozessmodell, Logdatei und Unternehmensdaten der Anwendungssysteme spezielle Analysen durchgeführt werden. Für die Funktion „Bestellung“ geben z. B. die Erkenntnisse über überhöhte Preise, nicht autorisierte Lieferanten, soziale Verbindung von Lieferanten und Mitarbeitern aus Prozess- und Anwendungsdaten des Einkaufssystems Anlass zum Misstrauen. Die automatische Anomalieerkennung, also Erkennung gravierender Abweichungen von Einzelprozessen von den im Modell gekennzeichneten „preferred lines“, schaltet bei der Beurteilung den menschlichen Einfluss aus und objektiviert damit das Ergebnis. Die als anormale Instanzen erkannten Prozessabläufe können dann weiter nach Ursachen analysiert werden (Linn & Werth, 2016; Bezerra & Wainer, 2013).

7.1.5 Vergleich generiertes Ist- mit Soll-Modell und Enhancement Stehen ein generiertes Ist- und ein manuell erstelltes Soll-Modell zur Verfügung, so können diese miteinander verglichen werden. Da Modelle eine komprimierte Darstellung auf der Typ-Ebene sind, sind die Analysen auf einer höheren Aggregationsebene als bei dem Vergleich mit der Logdatei. Grundsätzlich ist zu untersuchen, ob sich bei Abweichungen das Soll-Modell das Soll-Modell nicht mehr aktuell ist oder ob sich die Prozessausführung nicht an die vorgesehenen Bearbeitungsregeln hält. Bei der Analyse können tote Zweige im Soll-Modell entdeckt werden, also Prozessabschnitte, die im Soll-Modell vorhanden sind, aber von echten Prozessinstanzen nicht durchlaufen werden. Es ist zu untersuchen, ob diese Teile dauerhaft deaktiviert sind und die Organisation durch Umverteilung von Kapazitäten darauf reagieren soll. Aber auch der umgekehrte Fall kann auftreten, dass neue Prozessarme im Ist-Modell aufgetreten sind, die im Soll-Modell nicht vorhanden sind.

2

Dieses war bereits in einer frühen Version des Produktes ARIS PPM enthalten und wurde in der Literatur fortgeführt (Ferreira, 2017; van der Aalst, 2011).

7.1 Mining auf der Basis von Logdateien

117

Diese Ergebnisse können im Rahmen des Model Enhancements zur Angleichung des Soll-Modells an das Ist-Modell genutzt werden. Es sollte aber nicht Aufgabe des Process Mining sein, das am besten passende Modell der Wirklichkeit zu erhalten, sondern Anregungen zu geben, wie der beste Ablauf der Wirklichkeit GESTALTET werden kann. Nicht das am besten passende MODELL der Wirklichkeit zu erstellen ist das Ziel, sondern die beste Wirklichkeit zu schaffen ist es! So ist auch nicht die Reduktion der Komplexität des Modells das Ziel, sondern die Reduktion der Komplexität der Realität. Wenn z. B. eine prozessorientierte modulare Produktorganisation eingeführt wird, reduziert sich automatisch auch die Komplexität der einzelnen Prozessmodelle und viele algorithmische Anstrengungen entfallen. Zur Bedeutung des Enhancements, also der Anpassung eines Soll-Modells an das generierte Ist-Modell können deshalb auch kritische Anmerkungen gemacht werden. Das SollModell repräsentiert den gewünschten und für sinnvoll erachteten Ablauf. Das Ist-Modell repräsentiert auch Ad-hoc-Reaktionen, zufällige organisatorische Änderungen, Fehlentscheidungen oder falsche Bearbeitungen. Werden deren Abläufe in das Soll-Modell übernommen, mag es bei der nächsten Analyse zwar weniger Modellabweichungen geben, aber es fehlt auch die Motivation, die Wirklichkeit zu verbessern. Man übernimmt den „Schlendrian der Wirklichkeit“, wie es der Nestor der Betriebswirtschaft, Eugen Schmalenbach, für einen Soll-Ist-Vergleich bezeichnet hat. Man kann den Eindruck bekommen, dass viele wissenschaftliche Arbeiten sich allein mit der Modellwelt beschäftigen. Diese ist leicht formal zu definieren und man kann sich dann mit komplexen Algorithmen zur Behandlung der Modelle beschäftigen, die aber für die Verbesserung der Prozesswirklichkeit wenig beitragen. Kommerzielle Process Mining Systeme bieten zur Unterstützung aller Auswertungsformen komfortable Dashboards an (Abb. 7.6 oder siehe auch Petermann, 2017; Software AG, 2017). Viele Analysen gelten als Standard und werden vorformuliert angeboten. Sie zeigen, welche mächtigen Auswertungen durch Kombination von Soll-Modell, Ist-Modell, Logdatei und Unternehmensdaten möglich sind. Eine eindrucksvolle Zusammenstellung praktischer Anwendungsfälle zum Process Mining gibt Reinkemeyer (2020a) und insb. Reinkemeyer (2020b) für einen Fertigungsprozess mit Bezug zum Digitalen Zwilling. Ein wichtiger Grund für den Erfolg des Logdatei-basierten Process Minings ist, dass Mining-Software ohne großen Aufwand implementiert werden kann und Bottom-up sofort interessante Auswertungen automatisch produziert. Bei einem Top-down-Ansatz mit vorheriger manueller Modellerstellung muss dagegen der Anwender erheblichen Aufwand mit hohem fachlichem und methodischem Einsatz zur Erstellung des Soll-Modells leisten. Allerdings bringt er dann seine Zielvorstellung in das Modell ein und reproduziert nicht nur die Realität.

118

7

Insight durch Process Mining

Abb. 7.6 Dashboard zu Process Mining

7.2 Task Mining und Desktop Activity Mining Ein Kritikpunkt des Process Minings auf Basis einer Logdatei ist, dass es von den Datenstrukturen der die Logdatei liefernden Anwendungssysteme abhängt. Die Mining Software muss deshalb eng an die jeweiligen Logdateien angepasst werden. Deshalb sind kommerzielle Mining-Systeme wie Celonis, ARIS-PPM oder SIGNAVIO eng mit ERPAnwendungssystemen wie z. B. SAP oder Service Now verknüpft, um sich auf deren Prozesssicht und Datenstrukturen auszurichten. Bei Anwendungssystem-übergreifenden Auswertungen muss die Mining-Software auf unterschiedliche Logdateien mit unterschiedlichen logischen und physischen Strukturen zugreifen und die prozessbedingten Übergänge zwischen den Systemen verstehen. Aus Sicht des Arbeitsplatzes eines Anwenders zeigt sich, dass in der Regel neben einem ERP-System weitere Systeme wie Office-Pakete oder eigenentwickelte Anwendungen benutzt werden. So werden für die Eingaben in ein ERP-System Mails gelesen oder Eingabedaten aus Excel-Tabellen ermittelt. Composable Unternehmen setzen zunehmend eigenentwickelte innovative Systeme ein. Auch kann der Anwender die Arbeit unterbrechen und z. B. eine private E-Mail schreiben. Die Ausrichtung des Process Mining allein auf eine einzelne Systemumgebung ist deshalb nicht ausreichend. Ein weiterer Kritikpunkt gegenüber dem Logdatei-bezogenen Process Mining ist, dass sich Verbesserungspotenziale häufig erst aus der Detailarbeit des Benutzers, also beispielsweise innerhalb der Bearbeitung einer ERP-Transaktion ergeben, das Mining aber als kleinste Einheit die Transaktion betrachtet.

7.2 Task Mining und Desktop Activity Mining

119

Um diesen Argumenten zu begegnen, wird mit dem Task-Mining ein systemübergreifender Ansatz vorgestellt, der von der Perspektive des Arbeitsplatzes ausgeht und einen tieferen Detaillierungsgrad bei der Funktionsbeschreibung nutzt. Anstelle der Auswertung der Logdateien von Anwendungssystemen werden deshalb die einzelnen Bearbeitungsschritte (Tasks) auf der Click-Ebene des Benutzers analysiert. Dazu werden von den Bildschirmfolgen von einem auf dem Endgerät installierten Software-Recorder Screenshots angefertigt und in einer eigenen Datenbank gespeichert (vgl. Abb. 7.7). Aus den Screenshots aller Bearbeitungsschritte werden mit Hilfe von KI-Algorithmen die verwendeten Anwendungssysteme identifiziert. Dazu kann einmal auf das Betriebssystem zugegriffen werden, das die bearbeiteten Systeme kennt oder über eine visuelle Komponente können aus den Elementen der Screens die bearbeiteten Anwendungssysteme erkannt werden. Hilfestellungen können dabei auch hörbare oder fühlbare Behindertenschnittstellen der Anwendungen geben. Das KI-System muss auf die Signale trainiert werden, so dass es die benutzten Systeme erkennt. Dieses ist ein für KI-Systeme typischer, mit Aufwand verbundener Vorgang. Sinnvoll wäre es deshalb, wenn die Anbieter von Anwendungssoftware die Annotation ihrer Icons selbst anbieten würden. Im Büro- und Dienstleistungsbereich finden immer noch viele manuelle Tätigkeiten zwischen den digitalisierten Arbeitsschritten statt. Durch Kamerasysteme können diese aufgezeichnet werden und ebenfalls über KI-Systeme erkannt werden. Die identifizierten Anwendungen werden anschließend zu einer Anwendungsarchitektur automatisch zusammengestellt (Application Discovery).

Abb. 7.7 Desktop Activity Mining

120

7

Insight durch Process Mining

Gleichzeitig wird aus der Reihenfolge der Screenshots automatisch ein Prozessmodell (Process Discovery) generiert, das aufgrund der Betrachtung der einzelnen Aktivitäten auf der Klick-Ebene eine feinere Granularität als ein aus Logdateien der Transaktionsebene generiertes Mining-Modell besitzt. Abb. 7.8 zeigt ein einfaches Beispiel eines generierten Prozessmodells als Direkt-Folge-Graph der Tätigkeiten und Abb. 7.9 die Abruffolge der verwendeten unterschiedlichen Anwendungssysteme. Diese feine Granularität gibt detaillierte Einsichten in Verbesserungsmöglichkeiten. Werden z. B. „händisch“ Daten von einem System in ein anderes übertragen, so kann sich die Entwicklung eines Robotic Process Automation (RPA)-Programms lohnen. Bei komplizierteren Problemen, z. B. der Erkenntnis, dass Aufträge an einer bestimmten Stelle innerhalb des Auftragsprozesses ständig lange unterbrochen werden, um offene Fragen zu klären, können Warnungen eingeblendet werden oder zur Problemlösung kleine Anwendungen mittels „Low-Code“ entwickelt werden. So kann eine Bibliothek von Verbesserungsprogrammen als digitaler Marktplatz für typische Schwachstellen in Geschäftsprozessen entstehen, die bei neuen Projekten automatisch erkannt und eingesetzt werden können. Die Zahlen an den Kanten zeigen die Anzahl der ausgeführten Prozessinstanzen, die bei diesem kleinen Demonstrationsbeispiel sehr niedrig sind. Ergänzend können den Schritten Screenshots und Beschreibungen manueller Tätigkeiten hinzugefügt werden.

Abb. 7.8 Desktop Activity Mining – Prozessmodell

Literatur

121

Abb. 7.9 Ablauf der verwendeten Anwendungssysteme

Logdatei-basiertes Mining und Task Mining haben in den letzten Jahren große Fortschritte erzielt. Beide Ansätze bilden eine gute Basis für weitere Automatisierungsschritte im Composable Enterprise.

Literatur Bezerra, F., & Wainer, J. (2013). Algorithms for anomaly detection of traces in logs of process aware information systems. Information Systems, 38(1), 33–44. Burattin, A. (2015). Process mining techniques in business environments: Theoretical aspects, algorithms, techniques and open challenges in process mining. Cham: Springer. Ferreira, D. R. (2017). A primer on process mining: Practical skills with python and graphviz. Cham: Springer. https://doi.org/10.1007/978-3-319-56427-2. Laue, R., Koschmider, A., & Fahland, D. (Hrsg.). (2021). Prozess-Management und ProcessMining: Grundlagen. Berlin Boston: De Gruyter. Linn, C., & Werth, D. (2016). Sequential anomaly detection techniques in business processes. In W. Abramowicz, R. Alt & B. Franczyk (Hrsg.), Business information systems workshops. BIS 2016 international workshops, Leipzig, July 6–8. (S. 196–208). Revised Papers. Munoz-Gama, J. (2016). Conformance checking and diagnosis in process mining: Comparing observed and modeled processes. Cham: Springer.

122

7

Insight durch Process Mining

Petermann, F. (2017). Einführung in Celonis Process Mining. www.celonis.com. Zugegriffen: 22. Mai 2018. Peters, R., & Nauroth, M. (2019). Process-Mining: Geschäftsprozesse: smart, schnell und einfach (S. 4). Wiesbaden: Springer Gabler. Reinkemeyer, L. (Hrsg.). (2020a). Process mining in action: Principles, use cases and outlook. Cham: Springer Nature. Reinkemeyer, L. (2020b). Purpose: Identifying the right use cases. In L. Reinkemeyer (Hrsg.), Process Mining in Action: Principles, Use Cases and Outlook (S. 21). Cham: Springer Nature. Soffer, P., Hinze, A., Koschmider, A., Ziekow, H., Di Ciccio, C., Koldehofe, B., Kopp, O., Jacobsen, A., Sürmeli, J., & Song, W. (2017). From event streams to process models and back: Challenges and opportunities. Information Systems. https://doi.org/10.1016/j.is.2017.11.002. Software, A. G. (2017). ARIS – Process Performance Manager (PPM) Tsagkani, C., & Tsalgatidou, A. (2022). Process model abstraction for rapid comprehension of complex business processes. Information Systems, 103, 101818. van der Aalst, W. M. P. (2011). Process mining – Data science in action (2. Aufl.). Heidelberg: Springer. van der Aalst, W. M. P., & Weijters, A. J. (2004). Process mining: A research agenda. Computers in Industry, 53(3), 231–244.

Weiterführende Literatur Bornet, P., Barkin, I., & Wirtz, J. (2021). Intelligent automation. Hackensack: Lulu.com. Cappiello, C., Comuzzi, M., Plebani, P., & Fim, M. (2022). Assessing and improving measurability of process performance indicators based on quality of logs. Information Systems, 103, 101874. IEEE Task Force on Process Mining (2012). Process mining manifesto. http://www.win.tue.nl/ ieeetfpm/doku.php?id=shared:process_mining_manifesto. Zugegriffen: 22. Mai 2018. Kryon www.Kryonsystems.com. Zugegriffen: 1. Juni 2021. Mans, R. S., van der Aalst, W. M. P., & Vanwersch, R. J. B. (2015). Process mining in healthcare: Evaluating and exploiting operational healthcare processes. Cham: Springer. https://doi.org/10. 1007/978-3-319-16071-9. Nalbach, O., Linn, C., Derouet, M., & Werth, D. (2018). Predictive quality: Towards a new understanding of quality assurance using machine learning tools. In 21th International Conference. BIS 2018. (S. 1–12). Berlin: Springer. forthcoming. Polyvyanyy, A. (Hrsg.). (2022). Process querying methods. Cham: Springer. Turner, C. J., Tiwari, A., Olaiya, R., & Xu, Y. (2012). Process mining: From theory to practice. Issues in Information Systems, 18(3), 493–512. Willcocks, L., Lacity, M., & Craig, A. (2015). Robotic process automation at Xchanging (15/03). Outsourcing Unit Working Research Paper Series. https://eprints.lse.ac.uk/64518/1/OUWRPS_ 15_03_published.pdf. Zugegriffen: 9. Aug. 2023.

Von Insight to Action: Robotic Process Automation

Zusammenfassung Bei der Darstellung des Process Mining wurde bereits auf einige organisatorische Möglichkeiten zur Verbesserung des Prozessmanagements eingegangen. Diese werden in diesem Kapitel um weitere organisatorische Maßnahmen und die Anpassung des Produktionsprogramms an Ergebnisse von Produkt- und Prozess-Mining ergänzt. Ausführlichen Raum mit Beispielen nimmt das Thema Robotic Process Automation (RPA) ein. Wenn Erkenntnisse auftreten, die zu grundsätzlichen Änderungen der Organisation oder der Anwendungssysteme führen, beginnt dann ein neuer Innovationszyklus entsprechend der Abb. 1.11 des Composable Enterprise. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Die Abb. 8.1 stellt den Zusammenhang zum Lifecycle der Abb. 1.11 her.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_8

123

8

124

8 Von Insight to Action: Robotic Process Automation

Abb. 8.1 Actions. (Quelle: Adobe Stock, PureSolution)

8.1 Organisatorische Verbesserungen Die strategisch wichtigste Herausforderung der Modellanalyse ist die Frage, ob die gegebene Organisationsstruktur des Unternehmens geändert werden soll. Diese Frage stellt sich besonders bei einer zentralen funktionalen Aufbauorganisation, wenn diese zu einem verschlungenen Spaghetti-Modell führt. Hier liegt es nahe, wie es für das Composable Enterprise bereits am Anfang des Buches dargelegt wurde, das Unternehmen in z. B. produktbezogene Prozessmodule zu segmentieren. Damit würden sich das Prozessmanagement und damit die Prozessmodelle pro Modul wesentlich vereinfachen. Es ist die Abwägung, ob hohe Komplexität durch großen Aufwand gemanagt werden soll oder lieber die Komplexität verringert und damit der Managementaufwand reduziert werden kann. Das Konzept des Composable Enterprise unterstützt den zweiten Weg. Auf operativer Ebene kann das Process Mining dann weiterhin wertvolle organisatorische Verbesserungen innerhalb der Module vorschlagen. Durch Process Mining erkannte Kapazitätsengpässe können durch Umverteilung von Ressourcen verringert werden, Bearbeitungsschleifen durch Einsatz präziserer technischer Verfahren oder bessere Ausbildung von Mitarbeitern reduziert werden. Auch können Prozesse verschlankt werden, indem überflüssige Funktionen und Wege eliminiert werden (IEEE Task Force on Process Mining 2012). Die Häufigkeiten, die angeben, wie oft be-

8.2 Anpassung des Produktionsprogramms durch Kombination von Process und Product Mining125

stimmte Verzweigungen durchlaufen werden, helfen, die Entscheidungsregeln zu präzisieren (van der Aalst 2011). Ein Vergleich der Ist-Modelle verschiedener Organisationseinheiten wie Niederlassungen oder Tochterunternehmen mit einem einheitlichen Soll-Modell hilft, „Best-Practice“Modelle zu identifizieren, von denen die anderen Einheiten lernen können (Mans et al. 2015). Lerneffekte können auch erzielt werden, indem z. B. die besten 10 Prozessinstanzen einer Periode identifiziert, analysiert und als „Best Practice“ den Mitarbeitern vorgestellt und vorgegeben werden. Die Analyse ergibt, welche Eigenschaften von Instanzen ihre Durchlaufzeiten bestimmen. Diese können zur Segmentierung von Prozessorganisationen, z. B. für einfache und komplexe Produkte oder Inlands- und Exportaufträge, genutzt werden (Mans et al. 2015). Diese Überlegungen sind für den Modularisierungsansatz des Composable Enterprise besonders hilfreich.

8.2 Anpassung des Produktionsprogramms durch Kombination von Process und Product Mining Das Process Mining nimmt den Vorrat der in einer Periode zu bearbeitenden Prozessinstanzen als gegeben hin. Es analysiert also nicht die Optimalität des Produktionsprogramms der Periode, sondern nur die Prozessabläufe des gegebenen Programms. Die Gestaltungsvariable ist demnach der Ablauf der Instanzen, nicht aber die Zusammensetzung der zu bearbeitenden Prozessinstanzen. Aber gerade hierzu kann ein erweitertes Mining dienen, indem aus Ergebnissen von Prozessabläufen Entscheidungen über die Zusammensetzung des Produktionsprogramms getroffen werden. In einem Prozessmodell wird zugelassen, dass unterschiedliche Typen einer Aufgabe bearbeitet werden, also bei der Auftragsbearbeitung Aufträge mit geringem und hohem Auftragswert und Aufträge mit kurzen und langen Durchlaufzeiten bearbeitet werden. Es ist deshalb zu untersuchen, ob aufgrund von Process-Mining-Ergebnissen das Produktionsprogramm geändert werden soll. Werden z. B. in einem Krankenhaus bei der Behandlung bestimmter schwerer Krankheitsfälle sehr schlechte Genesungsergebnisse erzielt, so kann man diese Krankheitsfälle an dafür besser ausgerüstete Krankenhäuser überweisen; trotzdem bleibt das Prozessmodell bestehen, da die Krankheit für leichtere Fälle weiter behandelt wird. Nur werden die Prozesswege der schweren Fälle weniger durchlaufen. Es wird also nicht das Prozessmodell verändert, sondern die Struktur des die Prozesse auslösenden Instanzenmix. Deshalb sollte Process Mining eng mit einem Product Mining verbunden werden. Das Fallbeispiel in Abb. 8.2 für das Product Mining, das am August-Wilhelm Scheer Institut (AWSi) erarbeitet wurde (Nalbach et al. 2018), kann den Gedankengang weiter verdeutlichen. In einem Textilunternehmen werden von der Qualitätsprüfung und von Kunden reklamierten Fällen (Retouren) die aufgetretenen Fehler an Kleidungsstücken wie Nahtfehler,

126

8 Von Insight to Action: Robotic Process Automation

Löcher, Farbfehler oder Flecken erfasst. Dieses wird beim Process Mining an den verschiedenen Endpunkten der Prozessinstanzen „Ausschuss“ oder „Gutware“ durch die Qualitätskontrolle erkannt oder aus der Reklamationsbearbeitung. Den Prozessinstanzen, also jeweils die Herstellung eines Kleidungsstückes, werden Merkmalswerte der Produkteigenschaften zugeordnet. Dieses sind z. B. Produktart (z. B. Hemd oder T-Shirt), Farbe, Kleidungsgröße, Herkunftsland des Stoffes, Herstellungsverfahren wie Stricken oder Nähen und Anteile von eingesetzten Rohstoffen wie Baumwolle oder Polyester. Je nach Zusammensetzung dieser Eigenschaften ergibt sich ein Prozessergebnis von Fehlern mit einer anderen Häufigkeit innerhalb des gleichen Prozessmodells. Die relativen Häufigkeiten werden dann für die Prognose künftiger Herstellungen als Wahrscheinlichkeiten angesetzt. So können z. B. die Wahrscheinlichkeiten für den Prozessausgang der Qualitätsprüfung „Gutware“ bei einem bestimmten Herkunftsland der Rohware höher sein als bei einem anderen oder der Fehler „Flecken“ bei einer Materialart höher sein als bei einer anderen Materialart. Mithilfe eines Machine Learning-Verfahrens (2-stufiges Künstliches Neuronales Netz) wurde der Zusammenhang zwischen den Fehlerarten und den Produkteigenschaften ermittelt. Zum Training des Systems standen über 2 Mio. Datensätze von Retouren und Qualitätsprüfungen zur Verfügung. In Abb. 8.2 ist die Ergebnismaske dargestellt. In dem oberen Bereich sind in zwei Zeilen die Produktmerkmale mit ihren Ausprägungsmöglichkeiten für zwei Produktalternativen angegeben. Sie unterscheiden sich in dem Beispiel lediglich in den Herkunftsländern Bangladesch beziehungsweise Portugal. Die anderen Merkmale wie Stoffzusammensetzung aus Baumwolle oder Polyester, Farbe, Größe und Produktart sind gleich. Im unteren Bereich sind die Fehlerarten mit ihren Auftretenswahrscheinlichkeiten für die zwei Kom-

Abb. 8.2 Verbindung von Process- und Product Mining

8.3 Robotic Process Automation (RPA)

127

binationen der Produktmerkmale angegeben. Den Ergebnissen sind durch Farbkennung Genauigkeitsangaben zugeordnet. Diese Zusammenhänge können zur Produktgestaltung genutzt werden und die Qualität der Produkte präventiv gesteuert werden, indem bei dem Entwurf eines neuen Produktes die Produktmerkmale so bestimmt werden, dass die jeweiligen Wahrscheinlichkeiten der Fehlerarten akzeptabel sind. Damit bestimmt das Produktprogramm die Prozesseigenschaften der Produktion. Neben den zwei gezeigten Alternativen können automatisch weitere Merkmalkombinationen getestet werden, bis eine Entscheidung für eine Alternative getroffen wird. Damit werden die Wege mit ihren Häufigkeiten innerhalb des Prozessmodells bestimmt, die später mit dem Process Mining analysiert werden. Der gleiche Ansatz kann anstelle von Qualitätsmerkmalen auch auf die für Prozesse gebräuchlichen Maßzahlen wie Durchlaufzeiten angewendet werden, um aus den Produkteigenschaften die erwarteten Durchlaufzeiten zu schätzen und durch eine bessere Zusammensetzung der Materialien und Bearbeitungen des Programms die Durchlaufzeiten zu reduzieren. Process und Product Mining dienen beide der generellen Performancesteigerung des Unternehmens und sollten deshalb in einem engeren Zusammenhang gesehen werden.

8.3

Robotic Process Automation (RPA)

8.3.1 Überblick Maschinelle Roboter dominieren in der Industrie bereits ganze Produktionsstraßen (vgl. Abb. 8.3). Sie arbeiten selbstständig rund um die Uhr, zeigen keine Ermüdung, arbeiten fehlerfrei in gleichbleibender Qualität, können ihre Arbeit vollständig dokumentieren und sind im Rahmen ihrer Funktionalität flexibel auf neue Tätigkeiten zu trainieren. In Büro- und Verwaltungsbereichen werden trotz IT-Unterstützung immer noch viele manuelle Tätigkeiten durchgeführt (Abb. 8.4). In den betrieblichen Funktionen Logistik, Einkauf, Vertrieb, Produktentwicklung, Rechnungswesen und Personal sind zwar in den letzten drei Jahrzehnten durch ERP erhebliche Rationalisierungserfolge erzielt worden. Aber diese Anwendungen benötigen zu ihrer Bedienung durch Dateneingaben und Auswahlentscheidungen immer noch den menschlichen Sachbearbeiter. Die Automatisierung durch Roboter lässt sich auch auf den Bürobereich übertragen, nur dass anstelle maschineller Roboter Softwareroboter eingesetzt werden. Abb. 8.5 zeigt zur Anschaulichkeit maschinelle Roboter, aber tatsächlich sind es „unsichtbare“ Softwareprogramme. Unter Robotic Process Automation (RPA) wird Software verstanden, die Tätigkeiten automatisiert, die vorher von Menschen mit Hilfe von definierten Regeln mit strukturierten Daten ausgeführt wurden.

128 Abb. 8.3 Roboter dominieren in der Fertigung bereits ganze Produktionsstraßen. (Quelle: Adobe Stock, Ivan Traimak)

Abb. 8.4 Für die Bedienung von ERP-Systemen wird noch menschliche Sacharbeit benötigt. (Quelle: Adobe Stock, ASDF)

Abb. 8.5 Mit Hilfe von Softwarerobotern (Bots) können Arbeitsschritte automatisiert werden. (Quelle: Adobe Stock, stockyme)

8 Von Insight to Action: Robotic Process Automation

8.3 Robotic Process Automation (RPA)

129

Mit RPA wird ein auf den Arbeitsplatz des Menschen bezogener Weg zur Automatisierung eingeschlagen. Deshalb eignen sich besonders Ergebnisse des Task- oder DesctopActivity Minings als Auslöser von RPA-Projekten (vgl. z. B. die Ansätze des Unternehmens Kyron, https://www.kyronsystems.com). RPA ist gleichzeitig ein Ansatz, einfache Softwarelösungen von Citizen Developern entwickeln zu lassen und ergänzt damit das in Kap. 4 vorgestellte Low-Code-Konzept. Für den Einsatz eignen sich einfache Anwendungsfälle, die sich häufig wiederholen, in großer Zahl anfallen, durch gesetzliche oder Geschäftsregeln gesteuert werden und nur wenige, unbedingt von Menschen zu bearbeitende Ausnahmen enthalten. Die für den RPA-Einsatz geeigneten Fälle können durch Process Mining erkannt werden. Beim Desktop Activity Mining zeigen häufige Systemwechsel mit jeweils kurzen Bearbeitungszeiten, dass mehr formale Übertragungen zwischen Anwendungssystemen ohne fachliche Arbeit stattfinden, die durch Bots automatisiert werden können. Die Softwareroboter übernehmen dann Passwörter der Sachbearbeiter, mit denen sie berechtigt sind, auf Anwendungen zuzugreifen. Typische Funktionen, die sie dann ausführen, sind (siehe z. B. Deloitte, 2017; Roboyo, 2017a, b):          

Anmelden, Abmelden, Masken ausfüllen, Lesen und Schreiben in Datenbanken, Daten extrahieren, Einloggen in ERP-Systeme und Zugriff über APIs auf deren Daten, Integrieren von Daten aus unterschiedlichen Systemen, If-Then-Regeln analysieren und befolgen, auf soziale Medien zugreifen, Berechnungen ausführen, E-Mails öffnen und verarbeiten.

Für diese Funktionen werden von RPA-Anbietern Softwarebausteine entwickelt und dem Anwender zur Konfiguration und Customizing der RPA zur Verfügung gestellt. Der Softwareroboter bedient sich dann z. B. einer virtuellen Tastatur oder einer virtuellen Maus. Da die Anwendungssysteme nicht verändert werden, wird die Softwarearchitektur des Unternehmens nicht berührt und führt zu keinem Aufwand und Entscheidungsbedarf des CIO des Unternehmens. Der Roboter dockt sich lediglich an die Benutzerschnittstellen und Oberflächen der Systeme an und führt die Arbeitsschritte so aus, wie sie bisher der menschliche Sachbearbeiter ausgeführt hat. Die genannten Vorteile eines Robotereinsatzes in der Fertigung, wie 24/7 Verfügbarkeit, gleichbleibende Qualität und lückenlose Dokumentation, sind dann auch im Verwaltungsbereich nutzbar. Kommerzielle RPA-Tools stellen Hilfen bereit, die es dem Fachbereich in relativ kurzer Zeit ermöglichen, RPA-Projekte selbst zu definieren, zu steuern und ohne professionelle Programmierkenntnisse selbst umzusetzen.

130

8 Von Insight to Action: Robotic Process Automation

Der zu erzielende Rationalisierungsgewinn durch RPA wird auf über 50 % gegenüber manueller Tätigkeit geschätzt. Auch können Tätigkeiten, die in den letzten Jahren in sog. „Billiglohnländer“ als Outsourcing verlagert wurden, wieder zurückgeholt werden. Beim Einsatz von Methoden der künstlichen Intelligenz kann der Roboter natürliche Sprachen verstehen, erkennt und interpretiert strukturierte und unstrukturierte Daten (z. B. E-Mails) und verfügt über kognitive Lernfähigkeiten. Mit diesem intelligenten RPA können auch komplexere Tätigkeiten automatisiert werden. Beispiele sind Kundendialoge (Chatbots) zur Vereinbarung von Serviceterminen oder Identifizierung von Kundenwünschen oder -reklamationen. Werden mehrere Roboter in einem Anwendungsfeld eingesetzt, dieses können leicht 10 bis mehrere Hundert Roboter sein, kann ein Robot Controller die einzelnen Bearbeitungsfälle den entsprechenden Robotern zuteilen. Er analysiert dann die Fälle nach inhaltlichen Kriterien, z. B. bei eingehenden E-Mails nach Anhaltspunkten für Beschwerden, Bestellungen, Änderung von Wartungsterminen oder Nutzungshilfen, und weist die E-Mails zur Bearbeitung den zuständigen Robotern zu. Durch die Dokumentation der Bearbeitungsschritte während der Ausführung wird von RPA ein detailliertes Process Mining seiner Anwendung unterstützt.

8.3.2 Anwendungsbeispiele und -gebiete RPA übernimmt häufig Funktionen, die bisher von Sachbearbeitern mit vielen Spreadsheet- und Datenbankanfragen ausgeführt wurden. Dazu wird als Beispiel die Prüfung von Lieferantenrechnungen betrachtet. Ein erster Ansatzpunkt ist die Identifizierung von Eingangsrechnungen, die in unterschiedlicher Form wie Papier oder elektronisch und mit anderen Dokumenten gemischt, ankommen. Hier kann ein KI-gestütztes System automatisch die Eingangsrechnungen an bestimmten Merkmalen wie Absender, Aufbau des Dokumentes usw. identifizieren. Nach der Identifizierung der Rechnungen folgt die Prüfung der eingehenden Lieferantenrechnungen durch ein ERP-System (Abb. 8.6). Hier muss auf vielfältige Daten der Bestellung, des Wareneingangs und der Qualitätsprüfung zugegriffen werden, um die Berechtigung des Rechnungsbetrages zu erkennen. Beispielsweise müssen Preis- und Mengenangaben der Bestellung mit den Rechnungsdaten übereinstimmen. Die vom ERP-System automatisch erkannten berechtigten Fälle können dann an die automatisierte Funktion „Zahlung“ weitergegeben werden. Stimmen die Daten dagegen nicht überein, müssen Sachbearbeiter diese Fälle durch Nachfragen beim Lieferanten und/oder bei internen Stellen klären. Die Anzahl dieser Sonderfälle hängt davon ab, wie fein im ERP-System die Entscheidungsregeln formuliert sind. Häufig bleibt ein erheblicher Klärungsbedarf zurück. Ein Softwareroboter kann diese Klärung durch ein feineres Regelwerk übernehmen. Durch Beobachtung der Sachbearbeiter können der Prüfablauf erfasst, die Bearbeitungs-

8.3 Robotic Process Automation (RPA)

131

Abb. 8.6 Prüfung der eingehenden Lieferantenrechnungen – manuell

vorgänge erkannt und dem Roboter übertragen werden; er wird dann quasi von dem BestPractice-Vorgehen des Sachbearbeiters trainiert. Die vom Roboter nicht zu bearbeitenden extremen Sonderfälle müssen dann weiter von Sachbearbeitern behandelt werden (Abb. 8.7), aber es sind dann weitaus weniger als vorher. In einem zweiten Beispiel werden bei einer polizeilichen Überprüfung von Personen Prüfaufträge von unterschiedlichen staatlichen Stellen erteilt (Rombach, 2017). In der Ausgangssituation werden Daten aus verschiedenen Datenbanken (z. B. Landes-, Bundes- und internationalen Datenbanken) aus unterschiedlichen Systemen abgefragt und von Sachbearbeitern ausgewertet. In der Regel ist das Ergebnis negativ, also der Antragsteller unbedenklich. Trotzdem muss jeder Fall manuell bearbeitet werden. Nur wenige Fälle müssen bei positivem Befund sorgfältig weiterbearbeitet werden. Mit einem RPA-Ansatz übernimmt der Roboter die Anfragen an die Datenbanken, führt regelgesteuert die Angaben zusammen und filtert damit die unbedenklichen Fälle aus, sodass nur für die wenigen intensiv zu überprüfenden Fälle Sacharbeit erforderlich ist.

Abb. 8.7 Prüfung der eingehenden Lieferantenrechnungen – RPA unterstützt

132

8 Von Insight to Action: Robotic Process Automation

Ein weiteres Beispiel ist das Homebanking. Hier werden die vom Kunden eingegebenen Daten (z. B. für eine Überweisung) häufig nicht direkt von dem Buchungssystem der Bank verarbeitet, sondern als E-Mail in ein elektronisches Postfach bei der Bank eingestellt. Die Trennung ist ein Schutz, da dann von außen nicht in das Bankensystem eingegriffen wird. Ein menschlicher Sachbearbeiter arbeitet die Fälle des Postfaches anschließend ab und überträgt die Daten in das eigentliche Buchungssystem. Dabei wendet er auch Plausibilitätsregeln an, um z. B. fehlerhafte Fälle auszusortieren. Bei einem RPA-Ansatz überwacht der Softwareroboter das elektronische Postfach, extrahiert automatisch die Buchungsdaten, startet das Bankensystem und führt die Buchungen aus. Der Roboter arbeitet damit genau die Schritte des Sachbearbeiters ab, einschließlich der durch programmierbare Regeln erfassbaren Plausibilitätsprüfungen und Sicherheitsregeln. Das eigentliche Buchungssystem wird nicht verändert. Die wenigen ausgesonderten Sonderfälle werden dann weiter von menschlichen Sachbearbeitern behandelt. Menschen und Roboter arbeiten in den Beispielen bei Ausnahmefällen kollaborativ zusammen. Ist eine Aufgabe vollständig durch Regeln zu beschreiben, kann sie auch völlig ohne Eingriff von Menschen durch RPA automatisiert werden. Da ein Softwareroboter in der Regel nur auf ein kleines Aufgabenspektrum ausgerichtet ist, besteht eine komplexe RPA-Aufgabe häufig aus der Verknüpfung mehrerer Roboter, wie dies auch in einer Fertigungsstraße mit maschinellen Robotern der Fall ist. Einige eindrucksvolle Beispiele, die die Anwendungsbreite von RPA-Anwendungen zeigen, sind:  In einer Bank in Großbritannien (Institute for Robotic Process Automation, 2015) wurden täglich von elf Mitarbeitern 2500 Konten manuell dahingehend überwacht, ob bestimmte Überweisungen wegen des geringen Kontostandes ausgeführt oder abgelehnt werden sollen. In wenigen Monaten wurde diese Aufgabe an zwanzig Roboter übertragen und die Arbeit, die vorher erst nachmittags um 15 Uhr erledigt war, konnte nun bereits um 11 Uhr abgeschlossen werden. Die Kosten wurden um 80 % gesenkt und die Mitarbeiter konnten für höherwertige Arbeiten in der Kundenbetreuung eingesetzt werden.  In einer Einkaufsabteilung (Institute for Robotic Process Automation, 2015) einer Autohändlerkette in Großbritannien wurde das Einkaufssystem um Roboter zur automatischen Bedarfserkennung, Verfügbarkeitsprüfung der Lieferanten und zur Bestellauslösung ergänzt.  In den USA (Institute for Robotic Process Automation, 2015) wurde in einer Versicherung das Management einer privaten Cloud-Umgebung, insbesondere die flexible Skalierung der virtuellen Maschinen, an Roboter übertragen. Das System wurde in 120 Tagen entwickelt und garantiert eine Verfügbarkeit von 99,99 %.  In Großbritannien hat ein Outsourcing-Unternehmen durch ein Team von 20 Mitarbeitern mit großem Erfolg seine Angebote für Versicherungskunden weitgehend durch Roboter ersetzt (Willcocks et al., 2015).

8.3 Robotic Process Automation (RPA)

133

 Bei einem europäischen Energieversorger werden 300 Roboter eingesetzt, die die Arbeit von 600 Mitarbeitern verrichten (Lacity et al., 2015). Dabei wurden in großem Umfang Arbeiten, die nach Indien outgesourced waren, durch Roboter ersetzt. Die Roboter wurden auch nach der Einführung eines neuen ERP-Systems zu dessen Ergänzung eingesetzt, z. B. für die Plausibilitätsprüfung bei Energieverbrauchsmessungen.  In (Fung, 2014) werden Anwendungsfelder innerhalb der Steuerung von IT-Systemen genannt wie der Einsatz von Robotern zur Steuerung von Servern, Speichersystemen, Netzwerken, Security, Passwortverwaltung und Job-Scheduling.  Die Deutsche Telekom setzt erfolgreich in großem Umfang Softwareroboter für Kundendienstleistungen ein (Abolhassan, 2017). Besonders geeignete Branchen mit RPA-Anwendungen sind Banken, Versicherungen, Telekommunikationsanbieter, Energieversorger und Internetshops bei kundenbezogenen Anwendungen. Bei den branchenunabhängigen betrieblichen Funktionen sind Vertrieb, Einkauf, Finanzen, Service und Personalanwendungen prädestiniert. Damit ergibt sich ein breites Anwendungsspektrum für RPA. Für das Composable Enterprise ist der RPA-Ansatz zur Verbesserung von Altsystemen geeignet, die nicht in kurzer Zeit ersetzt werden können.

8.3.3 Intelligentes oder kognitives RPA Insgesamt können vier Entwicklungsstufen des RPA unterschieden werden (Kutzner et al., 2022; Horvath & Partners, 2018). Stufe 1: Softwareroboter zur Automatisierung repetitiver und regelbasierter Prozesse unter Verwendung strukturierter Daten (Klassisches oder einfaches RPA). Stufe 2: Automatisierung komplexerer Prozesse unter Verwendung unstrukturierter Daten und unter Einsatz von Machine Learning (Cognitive Automation). Stufe 3: Einsatz sprach- und textbasierter Nutzerinterfaces (Chatbots) unter Einsatz von Natural Language Processing (Digital Assistent). Stufe 4: Komplexe Softwaresysteme, die unter Einsatz von DeepLearning selbstständig Entscheidungen treffen und Prozesse initiieren und damit Schlüsselfunktionen automatisieren können (Autonomous Agents). Der Automatisierungsgrad von Geschäftsprozessen nimmt mit den Stufen zu. Als Beispiel für die Stufe 2 bis 3 ist in Abb. 8.8 eine automatische Reisekostenabrechnung durch RPA dargestellt, die bereits komplexe Algorithmen der künstlichen Intelligenz einsetzt. Der Roboter sammelt und speichert alle anfallenden Dokumente, die der Reisende per Smartphone fotografiert und mobil an den Roboter sendet. Er erkennt die unterschiedlichen unstrukturierten Daten der Belegarten sowie die Zahlungsbeträge und -formen, berechnet die dem Reisenden zu erstattenden Beträge gemäß der Reisekostenrichtlinie und veranlasst den Überweisungsvorgang. Das System begleitet den Reisenden, verfolgt alle Reiseschritte, versteht Schriften sowie die natürliche Sprache

134

8 Von Insight to Action: Robotic Process Automation

Abb. 8.8 Automatische Reisekostenabrechnung mit RPA

bei Eingaben über das Mobiltelefon des Reisenden und fordert selbstständig erwartete Belege an. Am Ende der Reise befindet sich das Geld bereits auf dem Konto des Reisenden. Dieses Beispiel zeigt, dass selbst bei einer alltäglichen Anwendung wie einer Reisekostenabrechnung intelligente Funktionen vom RPA verlangt werden. Intelligente RPA-Systeme werden bereits bei der Portfolioverwaltung von Wertpapieren von Großbanken eingesetzt oder zur Unterstützung von Compliance-Prozessen (Deloitte, 2017). In Versicherungen können eingehende elektronische Kundenanfragen automatisch analysiert und in natürlicher Sprache beantwortet werden. Reisekostenabrechnungen können automatisch nach ungewöhnlichen Mustern zur Betrugsabwehr analysiert werden. Mit statistischen Auswertungen einer Vertriebsdatei können automatisch alle möglichen Korrelationen zwischen den Merkmalen Umsatz, Artikelgruppe, Verkaufsgebiet, Vertreter, Preis und Menge untersucht werden, um wesentliche Zusammenhänge zu erkennen. In Abb. 8.9 ist das Ergebnis der ausgewerteten Vertriebsdatenbank dargestellt. Das System hat selbstständig erkannt, dass im Jahresvergleich das größte Wachstum im Consumer-Kundensegment bei „treuen“ Kunden zu verzeichnen ist. Das System ist von dem Berliner Start-Up-Unternehmen Inspirient GmbH entwickelt worden, das zum Innovationsnetzwerk der IDS Scheer Holding GmbH gehört (Inspirient, 2017). Mit fortschreitender Entwicklung und Akzeptanz der KI werden RPA-Ansätze immer höhere Sachbearbeitertätigkeiten ersetzen. RPA-Anwendungen sollten nicht nach ihrer leichten Eignung und Umsetzung ausgewählt werden, sondern nach ihrem höchsten Unternehmensnutzen. So wirkt sich eine

8.3 Robotic Process Automation (RPA)

135

Abb. 8.9 Automatische Datenanalyse mit RPA. (Quelle: Inspirient, 2017)

Funktionsverbesserung nur dann auf die Prozesslaufzeit aus, wenn sie auf dem kritischen Weg liegt. Deshalb muss ein Prozessmodell den Zusammenhang und die Wirkung der Verbesserung eines Arbeitsplatzes auf den gesamten Prozessablauf erkennen.

8.3.4 Einbettung von RPA in das Composable Enterprise Trotz aller Euphorie um RPA gibt es auch Grenzen. Der RPA-Ansatz überschneidet sich mit dem API-Konzept, bei dem sich Programme durch Datenschnittstellen öffnen und dann durch programmierte Logik miteinander verbunden werden. Dieses soll bei RPA nicht erfolgen, da keine neuen Interfaces entwickelt werden sollen, sondern die für den Sachbearbeiter vorhandenen genutzt werden. Komplexere Anwendungen führen zu komplexen Integrationsproblemen zwischen unterschiedlichen Systemen, die nur durch zusätzlichen Entwicklungsaufwand gelöst werden können. Damit ist für komplexe Probleme eine Mischung aus RPA und einem APIAnsatz sinnvoll. Werden neue Anwendungen entwickelt, trifft sich RPA mit dem Low-Code-Ansatz. Beide folgen dem Prinzip der starken Fachabteilungsbeteiligung durch Citizen Developer. Insgesamt führen die Entwicklungen zwar in die gleiche Richtung einer zunehmenden Automatisierung unter Nutzung von intelligenten Algorithmen und Komponenten, aber auch zu Überschneidungen. Deshalb muss ein RPA-Ansatz in die IT-Architektur des Unternehmens sinnvoll eingefügt werden. Dazu wird in der Application Composition Platform der Anschluss von RPA durch vorgesehene Schnittstellen hergestellt. Die von RPA-Anbietern bereitgestellten Softwarebausteine können dann in die Katalogverwaltung der Business Capabilities übernommen werden.

136

8 Von Insight to Action: Robotic Process Automation

Literatur Abolhassan, F. (2017). Robotic Process Automation macht Unternehmen produktiver – wenn sie die Mannschaft mitnehmen. Fachmagazin IM+io, 32(3), 6–11. Deloitte (2017). Automate this – The business leader’s guide to robotic and intelligent automation: Service delivery transformation. https://www2.deloitte.com/content/dam/Deloitte/us/ Documents/process-and-operations/us-sdt-process-automation.pdf. Zugegriffen: 22. Mai 2018. Fung, H. P. (2014). Criteria, use cases and effects of Information Technology Process Automation (ITPA). Advances in Robotics & Automation, 3(3), 1–10. IEEE Task Force on Process Mining (2012). Process mining manifesto. http://www.win.tue.nl/ ieeetfpm/doku.php?id=shared:process_mining_manifesto. Zugegriffen: 22. Mai 2018. Inspirient (2017). Automated pattern recognition with Inspirient software RPA. www.inspirient. com. Zugegriffen: 22. Mai 2018. Institute for Robotic Process Automation (2015). Introduction to robotic process automation: A primer. Carnegie Mellon University, Institute for Robotic Process Automation. Horvath & Partners (2018). Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Frankfurt: Horvath & Partners. Kutzner, C., Jurisic, S., Stonis, M., Nyhuis, P., & Seiter, M. (2022). Robotergesteuerte Prozessautomatisierung zur softwarebasierten Automatisierung administrativer Prozesse der innerbetrieblichen Lieferkette (RPAlog). Logistics Journal. https://www.logistics-journal.de/not-reviewed/ 2022/12/5623/kutzner_2022-12.pdf. Zugegriffen: 9. Aug. 2023. Lacity, M. C., Willcocks, L. P., & Craig, A. (2015). Robotic process automation: Mature capabilities in the energy sector. Outsourcing Unit Working Research Paper Series No. 15/06. London: LSE Outsourcing Unit. Mans, R. S., van der Aalst, W. M. P., & Vanwersch, R. J. B. (2015). Process mining in healthcare: Evaluating and exploiting operational healthcare processes. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-16071-9. Nalbach, O., Linn, C., Derouet, M., & Werth, D. (2018). Predictive quality: Towards a new understanding of quality assurance using machine learning tools. In 21th International Conference, BIS 2018 (S. 1–12). Berlin: Springer. (forthcoming). Roboyo (2017a). Digitale transformation. www.roboyo.de/im-fokus/digitale-transformation. Zugegriffen: 22. Mai 2018. Roboyo (2017b). Robotic process automation. www.roboyo.de/robotic-process-automation. Zugegriffen: 22. Mai 2018. Rombach, J. (2017). Mehr Sicherheit durch Prozessautomatisierung – Automatische Datenanalyse bei der Polizei – ein Praxisbeispiel. Fachmagazin IM+io, 32(3), 70–75. van der Aalst, W. M. P. (2011). Process mining – Data science in action (2. Aufl.). Heidelberg: Springer. Willcocks, L., Lacity, M., & Craig, A. (2015). Robotic process automation at Xchanging (15/03). Outsourcing Unit Working Research Paper Series. London: LSE Outsourcing Unit.

Literatur

137

Weiterführende Literatur AWSi (2018). Paradigmen der Digitalisierung organisatorisch umsetzen. Fachmagazin IM+io, 33(1), 84–85. Heeg, T. (9. Juli 2017). Programme buchen 90 Prozent der Fälle korrekt – Die Genossenschaft Datev will die Finanzbuchhaltung der Unternehmen automatisieren. Frankfurter Allgemeine Zeitung (FAZ). Institute for Robotic Process Automation, & EdgeVerve (2017). Turbo-Charging your process automation. http://go.outsourcing.com/EdgeverveWP1. Zugegriffen: 22. Mai 2018. IS Predict (2017). Totalschaden durch vorausschauende Wartung vermeiden. www.ispredict.com/ri/ smart-production. Zugegriffen: 22. Mai 2018.

Innovationstreiber für das Composable Enterprise

Zusammenfassung In Kap. 2 wurde bereits auf die Bedeutung der Digitalisierung als Innovationstreiber für das Composable Enterprise eingegangen, aber nicht im Detail verfolgt, um zunächst den gesamten Lifecycle vorzustellen. In diesem Kapitel werden Innovationstreiber deshalb detaillierter behandelt. Neben Treibern, die wirtschaftliche Wirkungen wie exponentielles Wachstum oder grenzkostenarme Herstellung nutzen, werden Chancen der Informationstechnik wie KI oder Blockchain analysiert. Auch gesellschaftliche oder politische Entwicklungen können Unternehmen zu Innovationen inspirieren. Dieses wird an den Faktoren New Work und Klimawandel gezeigt. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren. Ein wesentlicher Grund für die Gestaltung des Composable Enterprise ist, dass es mit seiner Agilität und Flexibilität in der Lage ist, schnell neue Geschäftsideen zu realisieren. Es ist Innovationen gegenüber aufgeschlossen und sucht nach ihnen. Eine Innovationsidee ist deshalb der Auslöser des in diesem Buch verfolgten Lifecycles, wie er in der Abb. 1.11 im Kap. 1 vorgestellt wurde. Vielzahl und Vielfalt der Erfolgstreiber zeigen die revolutionäre Kraft der Digitalisierung (Brynjolfsson & McAfee, 2014). Durch unterschiedliche Zusammensetzung und Gewichtung von Treibern entsteht für aufgeschlossene Unternehmen in allen Branchen eine Vielzahl von Möglichkeiten für neue Geschäftsmodelle und die dafür benötigten Geschäftsprozesse. Dieses gilt sowohl für Unternehmensgründungen als auch für die Weiterentwicklung bestehender Unternehmen. Ziel des Composable Enterprise ist es, selbst Innovationstreiber zu sein und nicht auf die Übernahme von Ideen von Start-Ups angewiesen zu sein. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_9

139

9

140

9

Innovationstreiber für das Composable Enterprise

Es erhebt sich die Frage, ob Innovationen Ergebnis einer zufälligen Eingebung sind oder systematisch entwickelt werden können. Zur systematischen Entwicklung stehen mit Konzepten wie Brainstorming oder dem morphologischen Kasten seit langem Methoden zur Verfügung. In den letzten zwei Jahrzehnten ist das „Design Thinking“ besonders populär geworden. Bei diesem Ansatz ist vor allem die Teamarbeit und Interdisziplinarität zur Entwicklung neuer Ideen herauszuheben. In Sitzungen eines Innovationsteams werden Wirkungen und Möglichkeiten der Digitalisierung erörtert, kombiniert und zu neuen Businessmodellen und Geschäftsprozessideen zusammengesetzt. Im Folgenden werden wirtschaftliche, informationstechnische und gesellschaftliche Innovationstreiber vorgestellt. Insgesamt sollen die Ausführungen zeigen, welche Chancen sich einem Composable Enterprise bieten.

9.1

Wirtschaftliche Innovationstreiber

9.1.1 Personalisierung/Individualisierung Die Möglichkeit, Werbung, Produkte und Dienstleistungen auf die individuellen Wünsche, Bedürfnisse oder Fähigkeiten von Kunden auszurichten, öffnet neue Geschäftsmodelle (vgl. Abb. 9.1). So können Medien ihre Nachrichtendienste auf die persönlichen Interessen ihrer Kunden konfigurieren, indem beispielsweise Sportnachrichten sofort übermittelt werden, während kulturelle oder politische Ereignisse eher nachrangig angeboten werden.

Abb. 9.1 Personalisierung. (Quelle: Adobe Stock, Оксана Назарова)

9.1 Wirtschaftliche Innovationstreiber

141

Digitale Lernangebote können auf die Lerngeschwindigkeit und die speziellen Interessen und Fähigkeiten des Lernenden inhaltlich und bezüglich unterschiedlicher Lernmittel wie Texte, Videos oder Lernspiele ausgerichtet werden. Aber auch materielle Produkte sind individualisierbar. Gegenüber dem Leitspruch von Henri Ford in den 30er Jahren („Man kann bei mir jede Autofarbe bekommen, vorausgesetzt sie ist schwarz.“), hat in der Zwischenzeit die Automobilindustrie ihr Angebot zu einer fast unüberschaubaren Variantenvielfalt von Farben und Ausstattungswünschen erweitert. Dieser Trend zur Personalisierung wird durch die Digitalisierung erweitert. Beispielsweise können Möbel über das Internet vom Kunden entworfen werden, wie in Abb. 9.1 für ein Regal von dem System des Unternehmens Okinlab in Saarbrücken gezeigt ist. Der Kunde entwirft mit einem einfachen CAD-System im Internet das individuelle Produkt, dessen Geometrie dann in entsprechende NC-Programme umgesetzt und von Tischlern mit NC-gesteuerten Maschinen gefertigt wird. Auch Lauf- oder Skischuhe sind ein bekanntes Beispiel für individuelle Produkte. Der Kunde kann in einem Sportgeschäft die Füße scannen lassen, und dann wird die Fertigung passgenau auf seine individuellen Maße ausgerichtet. Das Internet sorgt für die schnelle Übermittlung der Daten und unterstützt die Logistik. Weitere Beispiele sind:  Im Kleidergeschäft wird der Kunde „gescannt“ und dann werden seinem digitalen Zwilling die ihn interessierenden Kleidungsstücke angepasst, ohne dass er diese physisch anziehen muss. Der Kunde betrachtet sein digitales Ebenbild von allen Seiten und kann die Kleidung auswählen, die ihm am besten gefällt.  In modernen Zahnarztpraxen wird ein künstlicher Zahn im Computer entworfen, durch Simulationen passgenau adjustiert und mit einem 3D-Drucker sofort individuell gefertigt. Für den Patienten entfallen lästige Arzttermine und Untersuchungen, da nahezu der gesamte Prozess digital abgewickelt wird. Die genannten Fälle zeigen nur eine kleine Auswahl. Weitere Beispiele sind individuelle Versicherungen, die sich an den persönlichen Verhaltensweisen des Kunden bezüglich seines Autofahrstils oder seinem gesundheitsbewussten Lebensstil orientieren. Oder eine Versicherungsleistung wird auf eine spezielle Situation wie eine antretende Skiabfahrt oder Antritt einer Flugreise direkt vor Ort über das Internet abgeschlossen. Bestehende Unternehmen sollten darüber nachdenken, wie ihre Produkte und Dienstleistungen weiter individualisiert werden können, indem mehr Varianten vorgedacht werden oder der Kunde direkt über das Internet in den Gestaltungsprozess einbezogen wird. Start-Up-Unternehmen können überlegen, wie sie Standardprodukte bestehender Unternehmen durch aggressive Individualisierung angreifen können.

142

9

Innovationstreiber für das Composable Enterprise

9.1.2 Selbststeuerung Immer mehr steuern sich Objekte selbst, sodass eine übergeordnete Steuerungsebene ausgedünnt wird oder sogar entfällt (vgl. Abb. 9.2). In dem Konzept Industrie 4.0 steuern sich intelligente Materialien und Ressourcen selbstständig. Die Maschinen kennen ihre technischen Fähigkeiten und ihre Kapazitäten. Intelligente Materialien wissen, welche technischen Operationen sie benötigen. Beide kommunizieren miteinander und koordinieren den Fertigungsablauf über eine Art Marktplatz. Eine übergeordnete Fertigungssteuerung greift nur in Sonderfällen ein. Im Haushaltsbereich ist der sich selbst steuernde Kühlschrank ein beliebtes Beispiel. Dieses zunächst belächelte Beispiel ist bereits Realität. Der Grundgedanke ist einfach: Warum soll ein Mensch die Kühlschranktür öffnen und z. B. die Eierpackung öffnen, um festzustellen, dass ein Bedarf besteht, wenn doch der Kühlschrank selbst weiß, was er beinhaltet. Der Kühlschrank kann selbstständig eine Bestellung über das Internet zum Auffüllen auslösen. Das autonom fahrende Auto, in Abb. 9.2 durch ein Tesla-Auto gekennzeichnet, ist ein weiteres Beispiel zur Selbststeuerung. Auch hier ist in den letzten Jahren eine zunächst futuristisch anmutende Vision weit fortgeschritten. Der Übergang von Assistenzsystemen zum vollständigen autonomen Fahren ist für Straßen-, Schienen- sowie Wasserfahrzeuge zumindest für ausgewählte Strecken bereits Realität. Aber nicht nur für Geräte gilt das Prinzip der Selbststeuerung, sondern auch der Mensch strebt nach mehr Autonomie durch Digitalisierung. Bei einem persönlichen Arztbesuch werden bei einem Patienten in der Regel nicht mehr als zehn Indikatoren über seinen Gesundheitszustand erfasst. Dies sind zum Beispiel Blutdruck, Herzfrequenz,

Abb. 9.2 Selbststeuerung

9.1 Wirtschaftliche Innovationstreiber

143

Temperatur, Augenreaktion, Zungenbelag usw. Viele dieser Messwerte und auch darüber hinaus können heute durch „Wearables“ – hier ist in Abb. 9.2 symbolisch die AppleWatch angegeben – erfasst werden. Diese Angaben können dezentral oder über das Internet ausgewertet und über Künstliche Intelligenz zu medizinischen Empfehlungen verarbeitet werden. Damit übernimmt der Patient mehr und mehr selbst die Verantwortung für seine Gesundheitssteuerung. Die Kontrollinstanz Arzt wird ausgedünnt. Selbstverständlich benötigt ein Patient bei einer Kniegelenktransplantation weiterhin einen Chirurgen oder zumindest einen Operationsroboter. Aber auch hier kann das künstliche Knie individuell und automatisch aus dem gescannten, digitalen 3D-Knie-Modell über CAD-/CAM-Prozesse und anschließendem 3D-Druck individuell und automatisch erstellt werden. Das Internet ermöglicht es, dass Menschen ihre beruflichen Tätigkeiten stärker selbst steuern. Sogenannte Internetnomaden bieten orts- und zeitunabhängig über Internetplattformen Leistungen wie beispielsweise das Programmieren von Apps an. Sie sind damit nicht mehr durch feste Anstellungsverträge in hierarchische Systeme eingebunden, sondern bestimmen Arbeitsformen, Arbeitgeber, Arbeitszeiten und Arbeitsumfang als Freelancer selbst. Durch die Corona-Pandemie hat das Homeoffice schon fast eine Standardarbeitsform erhalten und ist Teil des „New-Work“-Konzeptes. Damit sind einige Beispiele zusammengestellt, die das breite Spektrum von Möglichkeiten der Selbststeuerung andeuten. Wichtig ist, das dahinter liegende Prinzip zu erkennen, um es zur Veränderung der eigenen Geschäftsmodelle zu nutzen.

9.1.3 Grenzkostenarme Produkte und Dienstleistungen Jeremy Rifkin hat in seinem Buch „Die Null Grenzkosten Gesellschaft“ (Rifkin, 2014) herausgestellt, dass immer mehr materielle Produkte, aber vor allem Dienstleistungen, fast ohne Grenzkosten erstellt und verbreitet werden können. Das Internet zeigt dieses bei vielen informationsnahen Dienstleistungen gegenüber den analogen Produkten. Die Erstellung von Informationen kostet zwar nach wie vor Geld, aber ihre Verbreitung durch das Internet ist quasi zum Nulltarif möglich. Abb. 9.3 nennt dies für das Telefonieren und Fotografieren. Telefonieren per Internet ist sogar mit komfortabler Videounterstützung quasi zum Nulltarif der Grenzkosten über weite Entfernungen möglich. Auch das Fotografieren mit dem Smartphone verursacht für ein zusätzliches Foto fast keine Grenzkosten. Das Mitnehmen eines zusätzlichen Fahrgastes in einem Automobil ist ebenfalls quasi grenzkostenlos. Das Gleiche gilt für die Übernachtung eines Gastes in einem sonst leerstehenden Zimmer. Beim 3D-Druck werden materielle Produkte aus einfachen Materialien wie Sand erstellt. Auch hier sind die Grenzkosten der Produktion vergleichsweise gering. Der Effekt grenzkostenloser Produkte und Leistungen hat weitreichende Konsequenzen. Die Bereitstellung von Infrastruktur tendiert dann zu Gemeinschaftsaufgaben, wie es

144

9

Innovationstreiber für das Composable Enterprise

Abb. 9.3 Grenzkostenlose Produkte. (Quelle: Adobe Stock, Prostock-studio, stockphoto-graf, jh312 und Christoph Steinweg)

Aufbau und Unterhalt des Internets zeigen; die Nutzung ist dann weitgehend grenzkostenlos. Durch Nutzung grenzkostenloser Effekte können gerade Start-Ups etablierten Unternehmen mit hohen variablen Kosten Probleme bereiten, wie dieses z. B. Uber mit Fahrdienstleistungen für Taxiunternehmen oder Airbnb mit Übernachtungen für Hotelketten zeigen.

9.1.4 Smart Services Das Internet ermöglicht die leichtere Verknüpfung von Angebot und Nachfrage für Produkte und Dienstleistungen und eröffnet dadurch Chancen für neue Vermittlungsleistungen. Gleichzeitig können durch die leichte Erfassung vielfältiger Daten (Stichwort: Big Data) und deren intelligente Auswertung neue Geschäftsmodelle entwickelt werden. In Abb. 9.4 ist dazu die internetbasierte Mobilität als Dienstleistung aufgeführt. Immer mehr jüngere Menschen stellen fest, dass ihnen der Besitz von Objekten weniger wichtig ist als ihre Verfügbarkeit. Hier werden durch Carsharing-Ansätze Mobilitätsbedarfe über das Internet vermittelt. Dies bedeutet, dass die hohe Variantenzahl an Ausstattungen eines Fahrzeuges wahrscheinlich weniger wichtig wird und damit die materiellen Fahrzeuge mehr standardisiert werden. Somit verliert die Kompetenz der Hersteller, die Komplexität zur Fertigung hoher Variantenzahlen zu beherrschen, als Wettbewerbsvorteil an Bedeutung. Das Prinzip der Individualisierung muss dabei nicht bedeutungslos werden. Es wird vielmehr stärker auf digitale Dienstleistungen gelenkt. Das aus einem Pool bestellte auto-

9.1 Wirtschaftliche Innovationstreiber

145

Abb. 9.4 Smart Services

nom fahrende Fahrzeug erkennt dann z. B. automatisch den Besteller und stellt Funktionen des Infotainments – wie Lieblingssender im Rundfunk, Informationsdienste, beliebte Streckenführung usw. – selbstständig auf den Besteller ein. Die Tendenz, den Nutzen materieller Produkte vom Besitz zu Dienstleistungen zu transformieren, setzt sich fort und wird von Sharing-Modellen unterstützt. So bietet ein Hersteller von Kompressoren dem Kunden den Verbrauch von kompressierter Luft in Rechnung und nicht den Erwerb des Kompressors. Industrieunternehmen können die Wartungsprozesse für ihre Produkte verbessern, indem sie das Verhalten der bei ihren Kunden installierten Maschinen über Sensoren erfassen und über das Internet analysieren. Mit Vorhersagealgorithmen für Störungen können die Wartungsintervalle optimiert werden (Predictive Maintenance). Dabei kann der Hersteller Quervergleiche über alle von ihm installierten Maschinen bei vielen Kunden in unterschiedlichen Einsatzumgebungen anstellen und besitzt gegenüber einem einzelnen Kunden eine breitere Datenbasis. Auf das Geschäftsmodell „Predictive Maintenance“ wird im Kap. 10 zum Composable Industrial Enterprise näher eingegangen. Neue Architekturen wie Blockchain können über Kryptowährungen nicht nur die Finanzwelt radikal verändern, sondern können in Verbindung mit Smart Contracts weitere Branchen beeinflussen. Auch dieses wird später detaillierter ausgeführt. Die Entwicklung von Smart Services ist eines der wichtigsten Innovationsfelder für neue Geschäftsmodelle und das Composable Enterprise bietet hierzu mit seiner flexiblen Anwendungsarchitektur besonders gute Voraussetzungen.

146

9

Innovationstreiber für das Composable Enterprise

9.1.5 Community-/Schwarm-Effekt Der Community- oder Schwarmeffekt bedeutet, dass der Nutzen der Teilnahme an einer Gruppe umso höher ist, je mehr Mitglieder sie umfasst und dass in einem Team effektiver Lösungen entwickelt werden, als von einem Einzelnen. So kann mithilfe des Internets bei Produktentwicklungen nicht nur eine speziell dafür eingerichtete Entwicklungsabteilung des eigenen Unternehmens eingesetzt werden, sondern es können alle interessierten Mitarbeiter der eigenen Organisation – aber auch Kunden, Lieferanten oder Partner bis hin zu der anonymen Community aller interessierten Entwickler der Welt – angesprochen werden. Dieser als „Open Innovation“ bekannte Effekt hat bereits zu eindrucksvollen Ergebnissen geführt. Bei der Softwareentwicklung ist das Betriebssystem Linux ein bekanntes Beispiel. Die Motivation von Experten, sich an der Entwicklung eines neuen Produktes oder an der Lösung eines Problems zu beteiligen, kann durch Incentives, wie das Ausloben von Preisen oder geldähnlichen Token für erfolgreiche Lösungen, unterstützt werden. Über Internetplattformen können finanzielle Mittel zur Entwicklung von Ideen und Produkten eingesammelt werden (Crowdfunding). Mit Anzahlungen und Bestellungen für zu entwickelnde Produkte bei Plattformen wie kickstarter.com wird ein Anrecht auf bevorzugte Bedienung bei erfolgreicher Entwicklung erworben. Bei Kryptowährungen wird über das Initial Coin Offering (ICO) ein unreguliertes Verfahren zur Ausgabe einer neuen Währung im Gegensatz zum regulierten Initial Public Offering (IPO) bei einer traditionellen Börse angewendet. Der Kunde bekommt dann eine bestimmte Anzahl Coins der neuen Währung zum Vorzugspreis einer bestehenden Währung. Intermediäre, wie klassische Banken oder klassische Börsen, sind ausgeschaltet. Die Teilnehmer finanzieren dann durch den ICO die Entwicklung der Währung. Im Marketing können Influencer gezielt geworben und eingesetzt werden, um perspektivische Kunden von den Vorteilen eines Produktes zu überzeugen.

9.1.6 Lean Organization und exponentielles Wachstum Durch Nutzung des Internets können Organisationsstrukturen vereinfacht werden. In dem Fotografie-Beispiel in Kap. 2 über den Vergleich zwischen Kodak und Instagram wurde dieser Unterschied bereits deutlich. Während Kodak als Weltunternehmen über Fabriken und ausgedehnte Vertriebsorganisationen verfügte, in denen zigtausend Mitarbeiter beschäftigt waren, wurde das Unternehmen Instagram lediglich von zwölf Mitarbeitern gegründet. Während viele der klassischen Unternehmen im Automobilbau, der Elektro- oder Chemie-Industrie jeweils mehrere Hunderttausend Mitarbeiter beschäftigen, haben viele neu gegründete Internetunternehmen, gemessen an ihrem EBIT, Umsatz oder Unternehmenswert, lediglich eine geringe Anzahl von fest Beschäftigten, kaum eigene Fabriken oder stationäre Vertriebsorganisationen. Dadurch werden die Fixkosten der Organisation gering

9.1 Wirtschaftliche Innovationstreiber

147

gehalten. Gleichzeitig können sie ihren Mitarbeitern besonders aufwendige Betreuungen und Gehälter anbieten und sich im „war for talents“ bessere Chancen schaffen. Das Composable Unternehmen nutzt diese Vorteile durch seine Modularität, mit der es leicht Businesskomponenten von Partnern beziehen kann und dadurch die eigene Organisation schlank halten kann. Das Elektroautomobilunternehmen Tesla vertreibt seine Produkte nicht über klassische teure Niederlassungen oder Vertretungen, sondern vornehmlich direkt über das Internet. Auch neue internetbasierte Bankleistungen, wie sie von FinTechs entwickelt werden, oder Kryptowährungen benötigen keine Glashochhäuser oder umfangreiche Zweigstellen, sondern lediglich eine Internetplattform. Das Schlagwort „assetless organization“ kennzeichnet diese Tendenz plastisch. Durch die schlanken Organisationen entstehen hohe Wettbewerbsvorteile, die den klassischen Unternehmen Probleme bereiten. Die Reaktion von Großbanken, ihre Niederlassungsnetze zu reduzieren oder die Forcierung des Direktvertriebes in Industrieunternehmen, sind ein Indiz für die Ernsthaftigkeit der Bedrohung. Erfolgreiche digitale Unternehmen können extrem schnell im Umsatz wachsen. Ihr Wachstum ist nicht an die Einstellung von Mitarbeitern gebunden, sondern die Verbreitung von Informationen als Teil des Businessmodells geschieht nahezu ressourcenunabhängig. Dies erklärt z. B. den Wachstumserfolg von Unternehmen im Social Media-Bereich wie Facebook oder Instagram oder auch Unternehmen zur Vermittlung von Dienstleistungen wie Uber oder Airbnb. Dieses exponentielle Wachstum ist insbesondere von den Autoren Salim Ismail et al. in ihrem Buch „Exponential Organizations“ (Ismail et al., 2014) herausgestellt und detailliert beschrieben worden.

9.1.7 Plattformunternehmen Eine der größten Marktwirkungen durch die Digitalisierung haben Plattformunternehmen. Sie bündeln und nutzen viele der vorgestellten Digitalisierungstreiber und haben sich in kurzer Zeit in B2B- und B2C-Märkten zu dominanten Playern entwickelt. Sie besitzen die höchsten Börsenwerte und greifen klassische Wirtschaftsstrukturen an. Über das Internet können Kunden und Lieferanten gegenüber analogen Formen leichter identifiziert und verbunden werden. Plattformunternehmen stellen diese Vermittlung als Kern ihres Businessmodells heraus (Baums et al., 2015), indem sie sich zwischen eine Kunden-Lieferanten-Beziehung schalten (vgl. Abb. 9.5). Organisationen, deren Geschäftsmodell die Vermittlung zwischen Anbietern und Nachfragern ist, sind nicht neu. Analog arbeitende Waren- und Wertpapierbörsen gibt es seit Jahrhunderten und ihre bestehenden Prozesse sind heute bereits weitgehend digitalisiert. Diese Organisationen nutzen das Internet, um ihre bestehenden Strukturen zu verbessern. Banken vermitteln zwischen Menschen, die Geld verleihen möchten und Menschen, die Geld leihen möchten. Dabei bündeln sie die Einlagen und verleihen sie in neuen Tranchen. Auch diese gewachsenen Prozesse sind inzwischen weitgehend digitalisiert.

148

9

Innovationstreiber für das Composable Enterprise

Abb. 9.5 Plattformunternehmen schalten sich zwischen Kunden und Lieferanten. (Quelle: Adobe Stock, PureSolution)

Auch traditionelle Einzelhandelsunternehmen entwickeln sich tendenziell zu Plattformunternehmen, wenn sie ihren Kundenstamm durch Eröffnung eines Internetshops überregional ausweiten und dadurch interessanter für neue Lieferanten werden. Umgekehrt spüren sie eine höhere Konkurrenz durch die Markttransparenz, wenn Kunden an der Ladenkasse schnell im Internet einen Preisvergleich bei anderen Anbietern anstellen und den Verkäufer mit einem günstigeren Angebot konfrontieren. Die Architektur von Plattformunternehmen ist für eine Kunden-Lieferanten-Beziehung in Abb. 9.6 dargestellt. Je mehr Kunden über die Plattform des Unternehmens ihre Käufe tätigen, umso attraktiver ist es für Lieferanten, ihre Produkte auf der Plattform anzubieten. Umgekehrt ist die Plattform für Kunden umso interessanter, je mehr Lieferanten anbieten. Erfolgreiche Beispiele für Plattformunternehmen dieser Art sind Amazon, Apple Store, Zalando oder Ebay. Im Bereich Social Media werden Menschen mit gleichen Interessen verbunden. Hier „bezahlen“ die Teilnehmer durch Angabe ihrer persönlichen Daten. Hierdurch können sie Werbetreibenden gezielt Käufersegmente selektieren und Streuverluste von Werbeaktionen verringern. Neben der reinen Vermittlungsfunktion (Matchmaking) werden auch Dienstleistungen und materielle Produkte von Plattformunternehmen angeboten. Damit ergibt sich eine große Variabilität der Leistungen.

Abb. 9.6 Je größer die Anzahl von Kunden und Lieferanten (Ökosystem), desto mächtiger die Plattform

9.1 Wirtschaftliche Innovationstreiber

149

Plattformunternehmen digitalisieren nicht nur bestehende analoge Strukturen, sondern revolutionieren über neue Prozesse das Businessmodell. Der Fahrzeugvermittler Uber digitalisiert nicht die bestehende Taxivermittlung, sondern erschließt eine neue (private) Fahrergruppe. Airbnb digitalisiert nicht klassische Hotelprozesse, sondern öffnet neue Anbietergruppen von Übernachtungsmöglichkeiten. Die Plattform unterhält sowohl zu Kunden als auch zu Lieferanten eine Marktbeziehung (two-sided markets), für die sie ein Entgelt verlangt (Rochet & Tirole, 2003). Dieses Entgelt kann aus echtem Geld oder aus der Erlaubnis bestehen, die persönlichen Daten über getätigte Transaktionen für Businessmodelle wie Werbung zu nutzen. Deshalb besitzen aus Sicht der Plattform sowohl Kunden als auch Lieferanten Kundeneigenschaften. Start-Up-Plattformen unternehmen alles, um möglichst viel Traffic zu erzeugen, also möglichst viele Kunden und Lieferanten zu akquirieren. Teilweise wird dies auch durch kostenlose Nutzungsmöglichkeiten oder sogar durch Subventionierung erreicht. Beispielsweise subventionieren die Anbieter von Computerspielplattformen den Kauf von Spielkonsolen, um dann von den Anbietern von Spielen hohe Gebühren für die Nutzung ihres Plattformbetriebssystems zu erheben. Ein bestehendes Unternehmen muss sich entscheiden, wie es in eine Plattformarchitektur eingebunden werden kann. Strebt es selbst an, eine Plattform zu betreiben, so muss es dafür eine Software-Lösung einsetzen und möglichst viele Kunden und Lieferanten anwerben. Will es dagegen komplementäre Produkte oder Dienstleistungen für eine bestehende Plattform entwickeln, so nimmt es die Rolle eines Lieferanten ein. Es ist ersichtlich, dass der schwierigere Part die Betreibung der Plattform ist, allerdings, wie bereits durch Nennung der wertvollsten Unternehmen angedeutet wurde, ist es die lukrativste Rolle. Lieferanten können gegenüber dem Plattformunternehmen ihre Rolle verstärken, indem sie selbst Zulieferanten bündeln und eigene Kunden in die Zusammenarbeit mit den Plattformunternehmen einbringen. Sie bauen damit quasi ihre eigene (einfachere) Plattformunternehmung auf und vernetzen sich mit der darüber liegenden. Damit entstehen fraktale Netzwerke von Plattformunternehmen. Eine interessante Entwicklung ist zurzeit auf dem Automobilmarkt zu beobachten. Traditionell stand und steht bei den großen deutschen Automobilherstellern wie Volkswagen, BMW oder Daimler-Benz das materielle Fahrzeug im Mittelpunkt und definiert somit jeweils Automobil-Plattformunternehmen. Die Kunden sind die Käufer dieser Autos. Komplementäre Lieferanten sind z. B. Zulieferer für Komponenten wie Navigationssysteme oder lizensierte Ersatzteilproduzenten. Das Fahrzeug selbst wird durch eine festgelegte Hierarchie von Zulieferanten erstellt. Diese sind nicht Bestandteil des hier behandelten Plattformkonzeptes, sondern bilden eine Zuliefer-Pipe-Architektur. IT-Unternehmen wie Apple und Google bieten bereits digitale Leistungen für Automobile an und entwickeln damit quasi Betriebssysteme für Infotainment für Automobile. Sie verfolgen damit das Ziel, die Plattform für Anwendungen wie Navigation, Ladestationssuche, Restaurantsuche, Hotelsuche, Kommunikation und Arbeiten zu sein, aber auch zur Unterstützung des autonomen Fahrens. Damit wird die Software zur zentralen Verbin-

150

9

Innovationstreiber für das Composable Enterprise

dung zum Kunden und zur Einnahmequelle der Zukunft. Dies kann dazu führen, dass die Entscheidung eines Konsumenten primär anhand des präferierten Betriebssystems getroffen wird und damit das Hardware-Unternehmen aus Sicht des Kunden in die nachgeordnete Rolle gedrängt wird. Dies wäre mit einem erheblichen Machtverlust der OEMs verbunden. Inzwischen haben die Automobilhersteller diese Gefahr erkannt und entwickeln eigene Betriebssysteme für ihre Fahrzeuge. Von VW wird berichtet, dass pro Jahr rund 2,5 Mrd. C in Software der Tochterunternehmung Cariad investiert und so gesamt VW in ein Technologieunternehmen transformiert. Dieses ist ein dramatischer Wandel in der Unternehmenskultur. Zukünftig soll die Entwicklung der Software die Entwicklung von Hardwarefunktionen dominieren1 . Bekanntgewordene Änderungen in der Plattformstrategie zeigen aber, wie schwierig eine Eigenentwicklung ist. Die entscheidende Frage wird sein, ob Kunden proprietäre Systeme eines Automobilherstellers akzeptieren oder Plattformen, die von unabhängigen Softwareunternehmen angeboten werden und in Produkten unterschiedlicher Hersteller eingesetzt werden. Insgesamt wird der Kampf um die Softwarevorherrschaft den Automobilmarkt sehr verändern. Ähnliche Entwicklungen hat es auch in der Vergangenheit gegeben, speziell in der ITIndustrie. Das Unternehmen IBM war einst der größte Hardware-Hersteller der Welt. Als die IBM in die Entwicklung von Personal Computers einstieg, hatte sie als kleinen Partner das Unternehmen Microsoft einbezogen, der das Betriebssystem MS-DOS entwickelte. Damit waren die Rollen klar: Der Hardware-Hersteller fühlte sich als Plattforminhaber und das kleine Softwarehaus Microsoft als Lieferant komplementärer Software. Inzwischen hat sich gezeigt, dass der Konsument die Rollen anders sieht. Er entscheidet sich zunächst für das Betriebssystem von Microsoft und erst dann für den Hardwarehersteller. Die Konsequenz ist, dass das Weltunternehmen IBM mittlerweile als Hersteller aus dem PC-Markt ausgeschieden ist. Eine ähnliche Entwicklung zeigte sich auch bezüglich der Unternehmenssoftware von SAP. Das damals kleine Start-Up-Softwarehaus SAP in Walldorf bot in den 1980er Jahren seine betriebswirtschaftliche Software als komplementäres Produkt zu den Computern der Firmen Siemens und IBM an. Es war stolz, wenn es auf den großen Produktmessen dieser Unternehmen seine Software zeigen durfte. Auch hier hat sich die Rolle umgekehrt. Heute entscheiden sich Kunden zunächst für ihre Software-Strategie – also für SAP-, Microsoft-, Salesforce-, Workday- oder Oracle-Software – und erst dann für eine Hardware-Lösung. Die Unternehmen Siemens und IBM sind als Hardwarehersteller aus diesen Märkten ausgeschieden, während SAP und andere Softwareunternehmen zu Weltunternehmen geworden sind. Die Entwicklungen zeigen noch einmal deutlich zwei Effekte, die durch Anwendung der Erfolgstreiber der Digitalisierung entstehen: 1

Wie schwierig diese Transformation ist und zu welchen kontroversen Diskussionen dieses führt, zeigen Presseberichte über personelle Vorstandsveränderungen, Probleme mit dem Unternehmen Cariad sowie Spekulationen und Ankündigungen zu Kooperationen mit den großen amerikanischen Internetunternehmen.

9.2 Informationstechnische Innovationstreiber

151

 Bestehende Großunternehmen können nicht sicher sein, dass sie im Rahmen der Digitalisierung ihre Vormachtstellung behalten werden und aufkommende digitale Produkte lediglich als Ergänzung ihrer Leistungen ansehen können.  Start-Up-Unternehmen können in kurzer Zeit durch exponentielles Wachstum bestehende Weltmarktführer in ihren Marktpositionen erschüttern oder sogar verdrängen. Das Composable Enterprise kann in zwei Richtungen an diesen Entwicklungen teilnehmen. Als bereits bestehendes Unternehmen kann es ein zweites digitales Businessmodell aufbauen und mit diesem schrittweise das traditionelle Modell ablösen. Als Start-Up-Unternehmen kann es zunächst in einer kleinen Marktnische beginnen und das Businessmodell schrittweise auf weitere Marktsegmente ausweiten. In beiden Fällen bietet die Fähigkeit der Application Composition Platform, Lösungen schnell zu entwickeln sowie diese einfach zu ergänzen und zu integrieren, günstige Voraussetzungen.

9.2 Informationstechnische Innovationstreiber Wegen ihrer übergreifenden und medialen Bedeutung werden einige technische Entwicklungen etwas detaillierter vorgestellt. Sie entfalten in der Öffentlichkeit viel Fantasie und Spekulationen für Innovationen. Sie werden aber nur dann erfolgreich sein, wenn sie zu wirtschaftlichen Erfolgen führen. Deshalb besteht eine enge Verbindung zu den wirtschaftlichen Treibern. Technische Entwicklungen bilden quasi die Grundlagen für wirtschaftliche Erfolge. Diese wiederum machen technische Erfolge erst zu Innovationen.

9.2.1 Künstliche Intelligenz Unter dem Begriff Künstliche Intelligenz (KI) werden algorithmische Verfahren zusammengefasst, die kognitive Fähigkeiten des Menschen übernehmen. Dieses sind z. B. logisches Schließen, Entscheidungs- und Urteilsvermögen oder Analysefunktionen. Der Begriff wurde 1956 von John McCarthy auf der Dartmouth Conference in den USA kreiert. Maschinen (Computer) sollen sich so verhalten, als verfügten sie über menschliche Intelligenz. Das Gebiet hatte zunächst eine Blütephase auf dem Gebiet des maschinellen Übersetzens. Wegen Enttäuschungen durch überzogene Erwartungen wurden die Aktivitäten stiller und es begann die erste „Nacht der KI“. Mit den sogenannten Expertensystemen, in denen Wissen durch „Wenn-dann“-Regeln abgebildet werden sollte, begann ein zweiter Hype, der aber Ende der 80er Jahre abflachte und in die zweite „Nacht der KI“ mündete. Durch die inzwischen verbesserte Rechenleistung der Computer und weiterentwickelten Algorithmen bekam das Gebiet seit dem Jahr 2000 eine neue Dynamik.

152

9

Innovationstreiber für das Composable Enterprise

Unter KI wird eine Vielfalt mathematischer Verfahren erfasst, die wie Regressionsanalysen oder Dynamische Programmierung bereits in der mathematischen Statistik und dem Operations Research bekannt waren. Allerdings entwickelt die KI in großem Umfang auch eigene Verfahren. Mit dem Begriff Machine Learning wird der Prozess bezeichnet, aus Daten Zusammenhänge zu erkennen und diese auf neue Fälle anzuwenden. Mit „Deep Learning“ werden als Teil des „Machine Learnings“ mehrschichtige künstliche neuronale Netze (KNN) bezeichnet, von denen es eine Reihe von Unterformen und problembezogene Spezialisierungen gibt. Mit KNN werden in einfacher Form Eigenschaften des menschlichen Gehirns nachgebildet, konkret die Vernetzung und Informationssteuerung von Neuronen. Hier wurden in den Gebieten Bilderkennung, Spielen wie Schach, Go oder Jeopardy, Robotic, medizinischen Diagnosen, Spracherkennung, Sprachübersetzung und Fahrerassistenzsystemen in den letzten Jahren große Fortschritte erzielt. Das Gebiet wächst in vielen kommerziellen Anwendungsbereichen, führt zu neuen Geschäftsmodellen und wird auch weiterhin ein Treiber von Innovationen sein. Da KNN in vielen digitalen Anwendungen eingesetzt werden, soll das Prinzip an dem Beispiel einer automatischen Gesichtserkennung etwas näher erläutert werden (vgl. Abb. 9.7). Ausgangspunkt ist eine Datenbank mit Personenfotos und Personenbeschreibungen. Das KNN wird in der Trainingsphase durch Eingabe der Fotos der Datenbank in Form von Pixel-Vektoren für Augenfarbe, Nasenlänge und Augenabstand so trainiert, dass es die zugehörigen Fotos in der Datenbank möglichst fehlerfrei zuordnet. Es wird also mit dem KNN eine Funktion gesucht, die alle Eingabedatensätze auf die gespeicherten Fotos mit möglichst wenig Fehlern abbildet. Das KNN in Abb. 9.7 besteht aus einer Eingabe-

Abb. 9.7 Künstliches Neuronales Netz

9.2 Informationstechnische Innovationstreiber

153

schicht, in der die Pixelvektoren des vorliegenden Fotos, dessen Pendant in der Datenbank gesucht wird, eingegeben wird. Den Zwischenschichten sind jeweils Neuronen zugeordnet und den Verbindungen zwischen den Neuronen benachbarter Schichten Gewichtungskoeffizienten. In der Ausgabeschicht wird das Ergebnis erfasst. Das KNN wird somit durch die Anzahl der Zwischenschichten und die Anzahl der Neuronen pro Schicht modelliert. In jeder Schicht l + 1 werden für jedes Neuron xjlC1 die Werte der Neuronen xil der l multipliziert und über alle Neuronen der vorherigen Schicht l mit den Gewichten wi;j vorherigen Schicht addiert. (In den angezeigten Schichten des Beispiels ist nl gleich 3.) Dies ergibt den Ausgabewert xjlC1 des Neurons j der Schicht l + 1, der dann der Eingangswert für die Berechnung der nächsten Schicht ist. Auch hier ergibt sich der Wert eines Neurons aus der Summe der Produkte aus den Ausgangswerten der vorhergehenden Neuronen mit den Gewichten. Dieser Vorgang wird über die Schichten fortgesetzt bis zur Ausgabeschicht. Dabei werden die Werte der Schichten in der Regel auf den Bereich 0 bis 1 normiert. Auch können weitere Transformationen wie Eliminierung negativer Werte durchgeführt werden. Damit können komplexe nichtlineare Beziehungen erfasst werden. l und die Größen xil sind die während des Trainings zu bestimmenden Die Gewichte wi;j Variablen. Die Ausgabeschicht enthält das Ergebnis. Da bei jeder Eingabe eines Fotos in der Trainingsphase das richtige Trefferergebnis, also der Bild-Datensatz der Person in der Datenbank, bekannt ist, wird das System als überwacht (supervised) bezeichnet. Die Abweichungen, also ob das Bild erkannt wurde oder nicht, dienen während der Trainingsphase im Rahmen des sogenannten Backpropagation dazu, die Gewichte der vorhergehenden Schichten über mathematische Verfahren anzupassen und stellen damit den eigentlichen Lernvorgang des KNN dar (Ertel, 2016, S. 291 ff.). Am Anfang werden die Gewichte durch Zufallszahlen besetzt. Der gesamte Datenbestand wird in der Trainingsphase so häufig durchlaufen und die Koeffizienten angepasst, bis eine akzeptable Fehlerrate erreicht ist. In der Anwendungsphase wird dem KNN ein Foto einer gesuchten Person als Pixelvektor eingegeben, um zu prüfen, ob die Person in der Datei vorhanden ist. Dieser Vektor wird den Neuronen der ersten Schicht übergeben, dort mit den Koeffizienten gewichtet und an die Neuronen der nächsten Schicht weitergegeben. Dieser Vorgang wiederholt sich über mehrere Zwischenschichten bis zur Ausgabeschicht für das Suchergebnis, also hier die Wahrscheinlichkeiten für die Treffer der Personen in der Datenbank, im Idealfall eine 1 für den richtigen Datensatz und jeweils eine 0 für alle anderen. Ein KNN wird durch die Anzahl der Schichten und die Anzahl der Neuronen pro Schicht modelliert. Je komplexer die Aufgabe ist, desto mehr Schichten und Neuronen pro Schicht werden im Allgemeinen definiert, um möglichst viele Verknüpfungen zuzulassen. Weiterhin können manche Algorithmen durch Parameter gesteuert werden, die der Anwender festlegt. Damit besteht eine gewisse Manipulierbarkeit des ansonsten automatischen Verfahrens. Derartige Parameter werden deshalb als Hyperparameter bezeichnet und ihre Festlegung wird als eigene mathematische Optimierungsaufgabe behandelt, um die Subjektivität zu reduzieren.

154

9

Innovationstreiber für das Composable Enterprise

Ein Problem bei überwachten KNN ist die Annotation der Datensätze. Wenn sie nicht vorliegt, müssen die Labels im Data Preprocessing gegebenenfalls manuell vergeben werden. Sollen z. B. E-Mails automatisch nach rassistischen Inhalten durchsucht werden, so können für die Trainingsphase, in der eine Datenbank mit E-Mails vorliegt, diese häufig nur aufwendig händisch bewertet werden. Probleme für KNN sind auch die Effekte des Overfitting und Underfitting. Beim Overfitting ist das Modell so mächtig, dass es in der Trainingsphase quasi alle Beziehungen zwischen Ein- und Ausgabewerten „auswendig“ gelernt hat, aber schlecht bei neuen, unbekannten Dateneingaben ist. Beim Underfitting ist das Modell so grob, dass es auch in der Trainingsphase schlechte Ergebnisse gibt. Zur Vermeidung beider Fälle gibt es Hinweise und Regeln. Für den Fall, bei dem das Modell auf alle Datenausreißer eingeht, sollte das Modell vereinfacht werden, also weniger Schichten oder weniger Neuronen gewählt werden, um es zu generelleren Aussagen zu führen. Es gibt neben dem bisher beschriebenen Verfahren eine Vielzahl unterschiedlicher Ansätze für KNN, auf die hier kurz hingewiesen wird. Neben den überwachten KNN gibt es unüberwachte (unsupervised) KNN. Hier ist praktisch nur die Datenbank der Eingabedaten bekannt. Hierauf können Algorithmen zur Clusteranalyse und Hauptachsenverfahren angesetzt werden, um Strukturen zu erkennen. Bei dem verstärkenden (reinforced) Lernen wird dem System ein Ziel vorgegeben, der Weg dazu wird gesucht. Dazu werden schrittweise Züge belohnt oder bestraft, je nachdem, ob sie sich dem Ziel nähern oder nicht. Es werden dabei Anleihen an dem Behaviorismus der Psychologie gemacht. Darüber hinaus gibt es eine Vielzahl spezialisierter Ansätze, die sich auf Anwendungen wie Bilderkennung, Umsetzung von Texten in Bildern oder autonomes Fahren beziehen. Kritik an KNN oder generell an KI wird geübt, weil es ein Black-Box-Verfahren ist, das nur eine geringe Plausibilitätskontrolle oder inhaltliche Erklärungen der Ergebnisse für den Anwender anbietet. Deshalb wird versucht, durch Sensitivitätsanalysen wie Variierung der Eingabedaten oder der Anzahl Schichten und Neuronen, einen logischen Zusammenhang zwischen bestimmten Eingabedaten oder Modellteilen und dem Ergebnis herzustellen. Es stehen immer mehr Bibliotheken wie z. B. Tensorflow für die KI-Programmiersprache Python mit Algorithmen für KI-Anwendungen zur Verfügung. Auch gibt es für bestimmte Anwendungen bereits vortrainierte Modelle mit bekannten Gewichten, die als Ausgangslösung für das Training für einen speziellen Anwendungsfall genutzt werden können. Durch diese Hilfen verschiebt sich das Gebiet der KI von der Forschung und Entwicklung neuer Algorithmen zunehmend auf seine Anwendungen. Wird ein Modell zur Klassifizierung von Kunden bezüglich ihres Kaufverhaltens mit den Merkmalen „starke“, „mittlere“ oder „geringe“ Kundenbindung eingesetzt, so können individuelle Marketingmaßnahmen danach ausgerichtet werden. So kann man sich mit Maßnahmen auf die identifizierten mittleren Kunden konzentrieren, da die starken oh-

9.2 Informationstechnische Innovationstreiber

155

nehin bereits gute Kunden sind und die Fokussierung auf Kunden mit schwacher Bindung wenig Erfolg bei Maßnahmen verspricht (Finlay, 2017). KI-Verfahren werden zunehmend in digitalen Geschäftsprozessen eingesetzt, um Daten in Wissen zu überführen. Die Massendaten aus Kundenkontakten oder Social Media sowie die Sensordaten aus dem Internet of Things können nicht mehr von Menschen bewältigt und analysiert werden, sodass automatische Verfahren eingesetzt werden müssen. Unternehmen können damit ihre Kundenbeziehungen analysieren, um Ergebnisse für Marketingaktivitäten zu nutzen. IoT-Daten können zu neuen Dienstleistungen wie „Predictive Maintenance“ oder zur Verkehrssteuerung eingesetzt werden. In immer mehr materiellen Produkten wie Automobile zum autonomen Fahren und in digitalen Dienstleistungen wie Navigationssystemen oder Suchmaschinen sind Verfahren der künstlichen Intelligenz enthalten. Auch die Sprachsteuerung von Systemen ist nicht ohne KI vorstellbar. So ist KI ein wesentlicher Innovationstreiber neuer Geschäftsmodelle. Der Mensch hat in seinen Fähigkeiten zur Kreativität, zum Erkennen komplexer Situationen, zur Führung komplexer Konversation und zur Bewältigung vieler Alltagshandlungen (gesunder Menschenverstand) immer noch einen Vorsprung. Die Künstliche Intelligenz rückt aber der natürlichen Intelligenz näher. Sicher werden KI-Systeme den Menschen nicht völlig ersetzen – verfügt dieser neben der kognitiven Intelligenz doch auch über emotionale und soziale Intelligenz. So hat man – nach dem KI-Experten Wolfgang Wahlster – fußballspielenden Robotern erst mit großen Mühen das Doppelpass-Spielen trainieren können, da sie zunächst darauf trainiert waren, selbst den Torschuss zu suchen. Den Ball an einen anderen Roboter abzugeben, erfordert dagegen soziale Intelligenz. Inzwischen können allerdings KI-Systeme auch mit Emotionen umgehen. KI-Systeme beziehen sich noch auf spezialisierte Anwendungen und werden deshalb als schwache KI bezeichnet. Der Mensch hat aber ein Allroundwissen. Dieses wird auch versucht, KI-Systemen zu vermitteln, indem ein System nicht nur Gesichter erkennen kann, sondern auch Sprache erkennen, übersetzen und Autofahren kann. Dieses Forschungsfeld wird als starke KI bezeichnet. Einen guten Überblick über weitere Anwendungen in Marketing, Human Ressources, Gesundheitswesen, Einzelhandel, Finanzen, Logistik, Industrie, Landwirtschaft und Sicherheitstechnik gibt Phil Wennker (Wennker, 2020). Besondere mediale Aufmerksamkeit erreichen stets konsumnahe KI-Anwendungen. So hat das KI-gestützte Sprach- und Textsystem ChatGPT von Microsoft in nur zwei Monaten über 100 Mio. Nutzer erreicht. Dieses gelang zum Vergleich dem Erfolgsprodukt TikTok erst in 9 Monaten. Microsoft plant, das System in die Office-Software und ihre Suchmaschine Bing einzubringen. Google reagiert darauf mit dem Chatbot Bard auf Basis des Sprachmodells LaMDA. Der chinesische Suchmaschinenanbieter Baidu wiederum kündigt das System Ernie Bot an. Diese sich nahezu überschlagenden Entwicklungen zeigen deutlich die hohe Innovationswirkung der Künstlichen Intelligenz und ihre internationale Reichweite.

156

9

Innovationstreiber für das Composable Enterprise

Es ist auffällig, dass die Fachliteratur zu KI von Autoren ausländischer Universitäten, insbesondere aus den USA, dominiert wird. Auch werden wesentliche Entwicklungen von den Forschungslaboren der IT-Giganten wie DeepMind Google, Amazon, Facebook (Meta), IBM oder Microsoft getrieben. Es ist schwierig, die Bedeutung der deutschen Forschung für KI und KNN zu erfassen. Bei der KI-Anwendung bestehen in Deutschland in Öffentlichkeit und Unternehmen häufig noch Vorbehalte. So werden eher Misserfolge einzelner KI-Anwendungen oder Gefahren diskutiert, als Erfolge und die Mächtigkeit von KI zur Auslösung von Innovationen. Die Erkenntnis der Bedeutung von KI für das (teil-)autonome Fahren hat aber in der Fahrzeugindustrie zu einer größeren Akzeptanz von KI geführt. Das behandelte Beispiel zur Gesichtserkennung gehört zu dem Typ Klassifizierungsmodelle, bei denen Wahrscheinlichkeiten für Elemente als Ergebnisse ausgegeben werden. Daneben gibt es Modelle für automatische Vorhersagen, bei denen Merkmalswerte wie erwarteter Umsatz der nächsten Periode, prognostizierter Zeitpunkt eines Ereignisses o. ä. ausgegeben werden. Ein KI-System ist in der Regel keine isolierte Anwendung, sondern Teil eines Geschäftsprozesses. Die Eingabewerte stammen aus einem vorangegangenen Bearbeitungsschritt und die Ergebnisse werden weiterverarbeitet. Deshalb ist die Einbettung in den Prozesszusammenhang für den Erfolg einer KI-Anwendung entscheidend. Die Application Composition Platform stellt dazu Schnittstellen zu KI-Algorithmen und die Integration von KI-Modellen in Geschäftsprozesse bereit.

9.2.2

Blockchain-basierte Innovationen (von der Blockchain-Architektur zum Web3)

Die Blockchain-Architektur erweckt großes Interesse, weil sie nicht nur eine technische, sondern auch eine organisatorische disruptive Entwicklung ist. Durch sie werden neue Formen der Zusammenarbeit zwischen Partnern ermöglicht. Darüber hinaus ist sie auch eine ökonomische Innovation, da neue Geschäftsmodelle und mit ihnen neue Unternehmen entstehen. Besondere mediale Aufmerksamkeit hat die spektakuläre Kursentwicklung von Kryptowährungen, insbesondere Bitcoin, erzielt, die auf der Blockchain-Architektur aufbauen. In neuerer Zeit erhalten NFT (Non Fungible Token) in der Kunstszene große Aufmerksamkeit, indem digitale Kunstwerke als einzigartige Objekte auf einer Blockchain geschützt gespeichert sind und nicht austauschbar (non fungibel) sind. Die BlockchainTechnologie erhält eine umfassende Erweiterung durch das Konzept Web3 als eine Weiterentwicklung des Internets.

9.2.2.1 Eigenschaften der Blockchain-Architektur Bei Finanztransaktionen vermitteln traditionell Intermediäre wie Banken oder Börsen zwischen den beteiligten Verkäufern und Käufern. Dies benötigt Zeit und führt zu Kosten. Die

9.2 Informationstechnische Innovationstreiber

157

Intermediäre bieten dafür Vertrauen, dass die Transaktionen ordnungsgemäß ausgeführt werden. Der Beitrag dieser Intermediäre liegt vor allem in der Bildung von Vertrauen in die Sicherheit der durchgeführten Transaktionen. Sie sollen sicherer ausgeführt werden, als wenn sie von den Beteiligten selbst untereinander durchgeführt würden. Die Sicherheit betrifft dabei sichere Identitäten von Absender und Empfänger, die Unversehrtheit der Nachrichten und ihre Geheimhaltung. Der Finanzsektor hat aber durch die Finanzkrise Anfang des Jahrhunderts an Vertrauen eingebüßt. Das bei den digitalen Plattformunternehmen herrschende Prinzip „the winner takes it all“ zur Monopolisierung mit extrem schnell wachsenden Börsenwerten und vergleichsweise geringer Anzahl von Arbeitsplätzen wird ebenfalls kritisch betrachtet. Auch zeigen Datenschutzprobleme bei Plattformunternehmen Risse in deren Vertrauenspotenzial. Diese zentralen Intermediäre weitgehend auszuschalten und die Prozesse sicherer, transparenter, schneller und kostengünstiger zu machen, ist das Ziel der dezentralen Blockchain-Architektur. Abb. 9.8 verdeutlicht diese Argumentationskette. Im zentralen Ansatz können Transaktionen nur über den Intermediär abgewickelt werden und die Anwender sind von der digitalen Plattform abhängig. Im verteilten (dezentralen) Fall werden Transaktionen direkt zwischen einem Knoten und einem anderen Knoten (Peer-to-Peer) ausgeführt und sind damit souverän. Die Sicherheit der Transaktionsabwicklung wird einmal durch ausgeklügelte Verschlüsselungsverfahren und zum anderen durch Kontrollmechanismen der Netzteilnehmer gewährt, indem sie die Richtigkeit der Transaktionen überprüfen und bestätigen. Die Sicherheitsfunktion wandert damit von einer zentralen Instanz in die Zuständigkeit der dezentralen Netzteilnehmer. Das Netz steuert sich selbst.

Abb. 9.8 Paradigmenwechsel von Blockchain

158

9

Innovationstreiber für das Composable Enterprise

Anhand der Abb. 9.8 wird das Blockchain-Konzept etwas tiefer erläutert. Eine gut verständliche erweiterte Darstellung gibt Hansen et al. (2019, S. 406 ff.). Technisches Kernstück der Blockchain-Architektur ist das Konzept einer verteilten Datenbank, in die alle Transaktionen unveränderlich gespeichert werden. Dazu werden die vom Netz als richtig erkannten Transaktionen zu Blöcken zusammengefasst und über Hashwerte verkettet. Ein Hashwert ist ein durch einen Algorithmus erzeugter Transformationswert des Inhalts einer Transaktion, deren Veränderung sofort einen anderen Wert ergibt und damit erkannt würde. Der Hashwert des vorherigen Blocks und der Hashwert des betrachteten Blocks werden in dem Kopf eines Blocks gespeichert (vgl. Abb. 9.9). So entsteht eine wachsende Kette von Blöcken und gibt dem Konzept seinen Namen. Sogenannte Full-Node-Teilnehmer erhalten eine Kopie dieser Kette, sodass sie transparent alle Transaktionen einsehen können. Damit ist Blockchain eine redundante verteilte Datenbank und bei Ausfall eines Knotens bleiben die gespeicherten Transaktionen an den anderen Full-Node-Knoten verfügbar. Alle Benutzer greifen auf die gleichen Daten zu. Der Inhalt der Transaktionen kann offen oder verschlüsselt sein. Absender und Empfänger werden durch Kennungen identifiziert, die anonym sein können, indem die Zuordnung der Kennung zum Inhaber nur diesem bekannt ist. Eine asynchrone Verschlüsselung sorgt durch die Paare Private und Public Key dafür, dass die Identität der Teilnehmer gewährleistet wird. Jeder Teilnehmer besitzt einen privaten und einen öffentlichen Schlüssel, die zueinander passen. Jede Transaktion wird von dem Absender signiert. Diese Signatur wird mit dem Private Key des Absenders erzeugt und alle die im Besitz des Public Key des Absenders sind, können diese öffnen und damit den Absender authentifizieren. (Umgekehrt kann ein Absender mit dem öffentlichen Schlüssel des Empfängers eine Nachricht verschlüsseln, die nur der Empfänger mit seinem privaten Schlüssel öffnen kann.)

Abb. 9.9 Vereinfachter Aufbau des Blocks einer Blockchain

9.2 Informationstechnische Innovationstreiber

159

Das Konzept der Blockchain-Datenbank, in der alle Transaktionen zeitlich nacheinander erfasst sind, erinnert an das Grundbuch im Katasterwesen oder auch an das Hauptbuch (general ledger) der Finanzbuchhaltung. Deshalb wird die Blockchain-Architektur auch als Distributed Ledger Technology bezeichnet.

9.2.2.2 Kryptowährungen Die spektakulärste Anwendung der Blockchain-Architektur sind Kryptowährungen, insbesondere die Währung Bitcoin. In ihnen werden relativ einfache Transaktionen des Zahlungsverkehrs abgewickelt. Diese Anwendungen werden deshalb auch als Blockchain 1.0 bezeichnet. Es sei angemerkt, dass mit Kryptowährungen wegen der hohen Volatilität ihres Wertes gegenüber klassischen Währungen wie dem Dollar, noch relativ wenig Zahlungstransaktionen abgewickelt werden, sondern sie sind im Wesentlichen Spekulationsobjekte. Kryptowährungen benötigen keine Zentralbank für die Ausgabe von Geld. Da damit der staatliche Zugriff fehlt, besitzen sie auch keine staatliche Regulierung. Dies wird von staatlichen Institutionen kritisch gesehen und es gibt Bestrebungen, regulatorisch einzugreifen. Gleichzeitig haben auch staatliche Institutionen und insbesondere Zentralbanken begonnen, Konzepte für eigene Kryptowährungen oder digitale Währungen mit einigen Eigenschaften von Kryptowährungen zu entwickeln (z. B. Digitaler Euro). Da diese stärker reguliert sind, bleibt abzuwarten, inwieweit das Ursprungskonzept von Kryptowährungen durchlöchert wird. Eine richtig abgewickelte Zahlung bedeutet nicht, dass auch der Sachverhalt, der die Zahlung begründet, korrekt ist. Deshalb wird das Krypto-Währungskonzept erweitert, indem auch die Sachverhalte nach den gleichen Maßgaben als sogenannte „Smart Contracts“ gespeichert und ausgeführt werden können. Besondere Beachtung findet auch das Konzept DAO (Dezentrale Autonome Organisation), das quasi als Software eine vollautomatisierte Institution ohne Rechtsform ist und die Finanztransaktionen aufzeichnet. Die Tatsache, dass es inzwischen mehr als 18.000 Kryptowährungen und damit viele Start-Up-Unternehmen gibt, sowie die Abwehraktivitäten der klassischen Finanzwelt zeigen die Innovationskraft dieser Technologie. Trotzdem regt sich auch Kritik und Skepsis. Als überzogene politische Vision gilt z. B. die Idee einer Blockchain-Weltdatenbank, in der alle Finanztransaktionen der Welt sicher, unveränderlich, transparent, unreguliert, Peer-to-Peer und datengeschützt gespeichert werden sollen. 9.2.2.3 Non Fungible Token (NFTs) Neben den Kryptowährungen sind Non Fungible Token die bekanntesten Produktkonzepte auf Basis der Blockchain. Auch hier bestehen hohes mediales Interesse und viel Spekulation. Ein Token ist in einer Blockchain eine Art Container für digitale Anwendungsfälle. NFTs sind einzigartige digitale Dinge, die man besitzen kann, und, wie der Name sagt, nicht gegeneinander austauschbar sind. Fungible Dinge sind dagegen Massenwaren wie Währungsmünzen, deren Besitz nicht individualisiert ist.

160

9

Innovationstreiber für das Composable Enterprise

Erste wichtige Anwendungen beziehen sich auf den Kunstmarkt und führen dort zu strukturellen Veränderungen. Weitere Anwendungsgebiete sind bereits absehbar. Ein typisches Beispiel für ein NFT ist ein von einem Künstler erstelltes digitales Bild, das einem Käufer eindeutig über die Mechanismen der Blockchain zugeordnet ist. Wenn das NFT weiterverkauft wird, ist der Weg unauslöschlich über die Blockchain dokumentiert und zu verfolgen. Dadurch kann ein Künstler bei jedem Weiterverkauf finanziell beteiligt werden und sein Businessmodell ändert sich von einem Einmalverkauf zu einem verketteten Verkauf. Der Besitzer eines Bild-NFTs kann sich das Bild so lange ansehen, wie er das NFT besitzt. Verkäufe können vornehmlich mit Kryptowährungen, aber auch in klassischen Währungen bezahlt werden. Das NFT-Konzept kann auf weitere intangible Güter wie Patente, Rechte usw. ausgeweitet werden und übernimmt dann Notarfunktionen. Aber auch materielle Dinge können mit NFTs verbunden werden. Das materielle Produkt wird dadurch individualisiert und erhält einen NFT als Begleiter. Bei einer Übertragung des materiellen Produktes muss das zugehörige NFT mit übertragen werden. Der Eigentümer eines tokenisierten Produktes ist in der Blockchain festgeschrieben. Dadurch sind Besitzer des materiellen Produktes immer bekannt. Der Verkauf von Produktfälschungen ist nahezu ausgeschlossen. Deshalb sind z. B. Anbieter von modischen Luxusgütern an dem Konzept interessiert und ein Potenzial für wirtschaftliche Innovationen ist gegeben.

9.2.2.4 Geschäftsmodelle und -prozesse auf Basis von Blockchain Die Blockchain-Architektur inspiriert neben Finanzdienstleistern und der Kunstszene auch andere Branchen zu neuen Geschäftsmodellen und -prozessen. Mit Hilfe von Smart Contracts können generell Geschäftsprozesse über die Blockchain automatisiert werden, indem Intermediäre aus Geschäftsprozessen entfallen und die Abläufe durch dezentrale Peer-to-Peer-Verbindungen gestrafft werden. Bereits der Verkauf eines NFTs ist ein solcher Vorgang. Sicherheit und Vertrauen werden von den Intermediären in die Funktionen des Netzes verlagert und ersetzen sie. Komplexe Vorgänge, auch durch den Zusammenschluss mehrerer Unternehmen zu einer neuen virtuellen Einheit (Community), werden durch DAOs (Decentralized Autonomus Organization) abgewickelt. In der Industrie können Logistiknetzwerke zwischen OEMs und ihren Zulieferern über Blockchain gesteuert werden. Alle Transaktionen über Abrufe, Transportzustände, Verzögerungen usw. sind dann allen Partnern bekannt und dauerhaft festgehalten. Damit sind Verantwortlichkeiten dokumentiert und es herrscht für alle Teilnehmer volle Transparenz über alle Zustände des Logistiknetzwerkes. Dieser Beispielfall wird im Kap. 10 bei dem Branchenmodell der Industrie wieder aufgenommen. Weitere Blockchain unterstützte Geschäftsmodelle und -prozesse für unterschiedliche Branchen sind nach Giese (2016, S. 65), Grinschuk (2017, S. 66 ff.) und Kassen (2022, S. 1 ff.) aufgeführt:

9.2 Informationstechnische Innovationstreiber

161

 In der öffentlichen Verwaltung bieten sich das Katasterwesen und das Einwohnerwesen an. Als Vorbild gelten die Anwendungen des Staates Estland.  Im Versicherungswesen sind die Verwaltung der Verträge und die Führung einer elektronischen Gesundheitsakte geeignete Anwendungen.  Im Energiesektor können bei erneuerbaren Energiekonzepten Verbraucher zukünftig auch zu Erzeugern werden. Dieser Prozess kann, einschließlich der Zahlungen, über Blockchain abgewickelt werden.  In der Industrie können erzeugte Produkte über ihren gesamten Lebenszyklus hinweg transparent verfolgt werden. Diese Aufzählung lässt sich weiter fortsetzen. Viele der eher traditionellen Branchen setzen deshalb Forschungsprojekte, Studien und Pilotanwendungen auf, um Einsatzmöglichkeiten der Blockchain zu testen. Aber auch die Plattformunternehmen des Internets können revolutioniert werden. Hier könnten genossenschaftliche Strukturen die Macht der Monopolisten brechen. So könnten sich die Beteiligten im Bereich von Social Media selbst in der Blockchain organisieren und die mit ihren Daten erzielten Werbeerlöse dann unter sich aufteilen und nicht den Plattformunternehmen überlassen. Auch könnten die gegenwärtigen Plattformunternehmen mit ihrer zentralen Vermittlerfunktion durch dezentrale Koordinationsmechanismen abgelöst werden. Allerdings kann vor überzogenen Wirkungen gewarnt werden. Dieses betrifft insbesondere eine erhoffte politische Demokratisierung und Dezentralisierung. Auch das Internet wurde als eine Technologie zur weiteren Demokratisierung und Dezentralisierung eingeführt. Das Ergebnis ist aber, dass es stattdessen monopolartige und global agierende Unternehmen hervorgebracht hat. Trotzdem werden grundlegende Ideen der Transparenz, Sicherheit, Vernetzung und Dezentralisierung, die im Zusammenhang mit der Blockchain-Architektur entstanden sind, in die Weiterentwicklung klassischer Architekturen übernommen. Dieses ist vielleicht ihre größte Wirkung.

9.2.2.5 Metaversum und Web3 Der Begriff Metaversum oder Metaverse ist dem 1992 erschienenen Science-Fiction Roman „Snow Crash“ entnommen und bezeichnet virtuelle und digital erweiterte reale Welten, die untereinander vernetzt sind. In ihr sind mehrere Techniken enthalten. So z. B. AR (Augmented Reality) und VR (Virtual Reality), die auch zusammengefasst als XR bezeichnet werden. Bisher wurden diese Techniken vor allem in Spielen eingesetzt. Durch Ankündigungen von Facebook (Meta) sowie von Microsoft hat der Begriff einen Hype bei Investoren und Start-Up-Unternehmen ausgelöst (Oppermann & Prinz, 2022). Inzwischen gibt es praktische Anwendungen im Modebereich oder auch bei technischen Dienstleistungen. Ein Beispiel ist die Überwachung von Kläranlagen eines regionalen Entsorgungsverbandes (Cerniauskas & Werth, 2022). Hier wird mit einer Kombination aus AR und VR

162

9

Innovationstreiber für das Composable Enterprise

sowie 360 Grad Kameras die virtuelle Inspektion unbemannter Anlagen in Real-Time gesteuert. Auch dem digitalen Lernen öffnen sich neue Möglichkeiten (Knauer et al., 2022; Hegewald, 2022). Digitale Zwillinge werden bei der industriellen Produktentwicklung bereits für Simulationen und Prüftests verwendet. Ergebnisse der Simulationen werden dann zur Produktverbesserung in die reale Welt übertragen. Im konsumnahen Bereich steht vor allem die Verschmelzung realer und virtueller Welten im Mittelpunkt. Der Benutzer taucht quasi in seine immersive Welt als Avatar ein, kann Eigentum an virtuellen Gegenständen wie virtuellen Grundstücken erwerben und ein virtuelles Leben führen. Der Avatar als „zweites Ich“ kann mit gekauften virtuellen Accessoires ausstaffiert werden. Dazu haben bereits Modelabels Angebote entwickelt. Es ist eine Weiterführung des bereits früher entwickelten Systems „Second Life“. Metaverse besitzt eine eigene digitale Wirtschaft, in der reale Menschen kaufen und verkaufen können. Gegenwärtige Shopping-Plattformen können dann in ihr aufgehen. Die soziale Interaktion steht bei Metaverse im Vordergrund. Mehrere Freunde können durch ihre Avatare gemeinsam kulturelle Veranstaltungen besuchen oder gemeinsam eine Abenteuerreise erleben, ohne das eigene Haus zu verlassen. Das virtuelle Leben kann mit dem realen vermischt werden. Beispielsweise kann der Avatar zunächst wie der reale Mensch gekleidet sein, dann aber können an seiner Kleidung modische Veränderungen ausprobiert werden und diese nach Gefallen von dem realen Menschen übernommen werden. Als Web3 wird die nächste Generation des Internets bezeichnet, die Eigenschaften der Blockchain-Architektur mit den bereits genannten Anwendungen von Kryptowährungen, NFTs und Smart Contracts umfasst und diese um XR und weitere Funktionen erweitert. Im Vordergrund steht weiterhin die Dezentralisierung ohne Intermediäre und die Datenkontrolle und -hoheit durch Benutzer. In Abb. 9.10 (Welpe & Ziegler, 2022) sind Eigenschaften des gegenwärtigen Internets Web2 denen von Web3 gegenübergestellt. Es wird erwartet, dass sich die Konzepte Metaverse und Web3 in der Weiterentwicklung gegenseitig verstärken.

Abb. 9.10 Gegenüberstellung von Eigenschaften Web2 und Web3. (Quelle: Welpe & Ziegler, 2022)

9.2 Informationstechnische Innovationstreiber

163

Selbst wenn sich heute noch nicht absehen lässt, inwieweit die teilweise gewagten Visionen verwirklicht werden, bergen die Technologien und die sie treibenden wirtschaftlichen Interessen der Internetgiganten und Investoren große Innovationspotentiale. Auch hier werden Unternehmen nicht geschlossen in die virtuelle Welt eintauchen, sondern es werden Prototypen, Nischenanwendungen oder Erweiterungen entwickelt, die aber mit bestehenden Anwendungen verbunden werden müssen. Auch werden die Fachabteilungen mit ihrem Expertenwissen mit Technologen „demokratisch“ dabei zusammenarbeiten. Dieses erfordert flexible organisatorische und informationstechnische Strukturen und ist ein interessantes Feld für die Innovationsfreude des Composable Enterprise.

9.2.3 Infrastruktur Die von Anwendungssoftware ausgeführten Prozesse nutzen eine Infrastruktur aus Hardware- und Systemsoftware. Deren Eigenschaften beeinflussen die Geschwindigkeit der Ausführung von Transaktionen sowie die entstehenden IT-Kosten. Diese Größen entwickeln sich kontinuierlich mit der steigenden Leistungsfähigkeit der Systeme entsprechend dem Moore’schen Gesetz in Richtung „schneller und kostengünstiger“. Darüber hinausgehend können disruptive Architekturänderungen auftreten, die erheblichen strukturellen und organisatorischen Einfluss auf die Anwendungsgestaltung und -ausführung haben. Diese Änderungen begründen disruptive Innovationsmöglichkeiten.

9.2.3.1 Organisatorische Spannungspaare Wie bei der Organisation von Unternehmungen sind Änderungen von Infrastruktur-Architekturen auf die Einflüsse der Spannungspaare „Zentral – Dezentral“ und „Prozessoptimierung – Ressourcenoptimierung“ zurückzuführen. Zentral bedeutet, dass im wesentlichen gleiche Aufgaben von einer zentralen Einheit gleichförmig bearbeitet werden. Dezentral bedeutet, dass dezentrale Einheiten eine höhere Autonomie haben, mehr auf Varianten der Aufgaben eingehen und diese individueller bearbeiten. Bei einer Prozessoptimierung stehen die Verbesserung von Bearbeitungsdauern und Kundenzufriedenheiten im Vordergrund und bei Ressourcenoptimierung die Erhöhung von Auslastungskennzahlen der Ressourcen Maschinen, Material und Mitarbeiter. Die unterschiedlichen Gewichtungen dieser Zielgrößen begründen die Entwicklung und Bevorzugung unterschiedlicher IT-Infrastrukturen. Zentralisierung und Ressourcenoptimierung treten häufig zusammen auf; ebenso Dezentralisierung und Prozessoptimierung. Dieses muss aber nicht unbedingt der Fall sein. Auch zentral abgewickelte einheitliche Prozesse können zu besseren Prozessergebnissen führen als eine variantenüberladene dezentrale Prozessorganisation. Deshalb sind die Gewichtungen transparent zu machen.

164

9

Innovationstreiber für das Composable Enterprise

9.2.3.2 Cloud Computing/Edge Computing Am Anfang der IT-Entwicklung mit dem Einsatz von zentralen Großcomputern stand die Optimierung der IT-Ressourcen im Vordergrund. Die damals sehr teuren Rechner sollten möglichst hoch ausgelastet werden, möglichst nahe 100 %, und den Benutzerprozessen wurde über Timesharing die knappe Rechnerleistung zugeteilt. Entsprechend langsam wurden die Benutzerprozesse bearbeitet. Die zentrale Ressourcenoptimierung stand also im Vordergrund – zu Lasten der Optimierung der Benutzerprozesse. Zur Verbesserung deren Prozesse wurden den Anwendern mit der Client-Server-Architektur und den Personal Computern dezentrale Rechenkapazitäten zur Verfügung gestellt. Die Prozesse der Benutzer wurden dadurch wesentlich verbessert. Die Auslastung der Clients und Server liegen aber heute weit hinter den hohen Auslastungszahlen des zentralen Großrechnerkonzeptes. Nun dominierte also die Prozessoptimierung vor der geschwächten Ressourcenoptimierung und Dezentralisierung vor Zentralisierung. Diese Situation schafft wiederum Raum für eine Neuorientierung. Dieses ist eine Erklärung für den Erfolg des Cloud Computings. Anwendungen und Daten werden zentral in der Cloud gespeichert, die aus einem Netz verbundener Computer aus riesigen Serverfarmen besteht. Weltweite Anbieter wie Amazon, Microsoft, IBM, SAP oder T-Systems können damit hohe Economies-of-Scale-Vorteile nutzen. Es wird unterschieden zwischen einer Private Cloud, bei der die Cloud-Technologie auf der IT-Infrastruktur des Anwenders implementiert wird und der Public Cloud, bei der die Anwender die Cloud-Dienste von Cloud-Providern beziehen. Bei einer hybriden Cloud können Anwendungen aus der privaten Cloud und öffentlichen Cloud-Anbietern gemischt werden. Mit dem Public Cloud Computing besteht eine Tendenz zur stärkeren organisatorischen Standardisierung der Prozesse, da Veränderungen und Erweiterungen der Anwendungen mit erheblich höheren Kosten für den Anwender verbunden sind und auch von PublicCloud-Providern eher abgewehrt werden. Das Cloud-Konzept hat für Softwareanbieter zu erheblichen Innovationen geführt. Die Zentralisierung der Hardware in riesigen Serverparks hat dominierende Anbieter, sogenannte Hyperscaler, entstehen lassen. Bei Softwareanbietern hat sich das Geschäftsmodell von einer On-Premise-Zahlung des Preises beim Kaufabschluss zu einer mehrjährigen Mietzahlung (recurrend revenues) verändert. Anwender besitzen einen Liquiditätsvorteil, erkennen Vorteile zur Vereinheitlichung der Anwendungen und Investitionen werden zu periodisierten Mietzahlungen und damit zu Aufwendungen. Vor allem kann aber die leichte Vergrößerung von Speicherplatz und Rechenleistung genutzt werden, um schnell neue Anwendungen zu entwickeln, ohne selbst langwierige IT-Infrastrukturen aufzubauen. Deshalb ist für composable Unternehmen die Cloud-Architektur das Standardmodell.

9.2 Informationstechnische Innovationstreiber

165

Cloud-Computing führt zu einem hohen Datenverkehr zwischen den Servern und den Endgeräten. Wegen der begrenzten Übertragungsraten kann dieses die Geschwindigkeiten der Anwendungen beeinträchtigen. Dieses führt bereits in bestimmten Fällen zu einem Umdenken, und Anwendungen wandern wieder zur Prozessbeschleunigung zurück in dezentrale Systeme. Dieses gilt z. B. für Anwendungen der Fertigungsautomatisierung und IoT, indem die Verarbeitungsintelligenz in dezentrale Geräte implementiert wird. Dieses wird als Edge Computing bezeichnet. Maschinendaten werden dann dezentral erfasst und zur Steuerung verarbeitet und lediglich verdichtete Daten werden zu Planungszwecken an Cloudlösungen weitergegeben. In diesem Fall ändert sich das Paradigma wieder von der zentralen Ressourcenoptimierung zur dezentralen Prozessoptimierung.

9.2.3.3 GAIA-X Um die Vorherrschaft der Cloudanbieter aus den USA und China zu mindern, wurde von der deutschen Bundesregierung 2019 das Projekt GAIA-X zur Entwicklung einer europäischen Cloud-basierten IT-Plattform initiiert. Ein wesentlicher Grund ist dabei auch, dass außereuropäische Regierungen das Recht besitzen, auf Daten der Unternehmen ihres Landes zuzugreifen, unabhängig davon, wo sie gespeichert sind. Dieses gilt dann z. B. auch für Hyperscaler aus den USA. Bei Gaia-X sollen dagegen die europäischen Standards zum Datenschutz und zur Datensouveränität, wie sie z. B. in der Datenschutz-Grundverordnung (DSGVO) festgelegt sind, gewährleistet sein. Der Eigentümer von Daten soll die Kontrolle (Hoheitsrechte) über seine Daten besitzen. Er soll entscheiden können, wer auf seine Daten mit welchen Rechten zugreifen darf und die Rechte auch wieder entziehen können. Insgesamt bezieht sich die Datensouveränität auf die Bestimmung des Speicherortes, des Eigentums und der Verfügung (Zugriff) über die Daten. Zunächst bestand die Idee, in dem Projekt auch eine wettbewerbsfähige CloudInfrastruktur aufzubauen, indem die Computerkapazitäten der in Europa vorhandenen Unternehmen und Institutionen zu einem europäischen Serverpark zusammengeschaltet würden. Von dieser Absicht wurde aufgrund des Vorsprungs der Hyperscaler Abstand genommen. Diese werden stattdessen auf der Infrastrukturebene unter Beachtung der Datenschutzrichtlinien mit eingebunden. Das Forschungs- und Entwicklungsprojekt Gaia-X, das in Deutschland vom BMWK (Bundesministerium für Wirtschaft und Klimaschutz) finanziell unterstützt wird, ist deshalb auf die Entwicklung von Architektur, Standards, Regeln, Zertifizierungen und Software der Plattform ausgerichtet. Ziel ist es, auf der Cloud-Plattform die Datensouveränität des Einzelnen zu wahren, gleichzeitig aber einen gemeinsamen Datenraum zu schaffen, der nach festgelegten Regeln zum Datenaustausch genutzt werden kann. Es werden also Dezentralisierung und Zentralisierung miteinander verbunden. Dieses lehnt sich an dem politischen Begriff Föderalismus an, bei dem ein Bundesstaat bei weitgehender Eigenständigkeit der Einzel-

166

9

Innovationstreiber für das Composable Enterprise

staaten gebildet wird. Deshalb wird der Begriff föderal oder federated häufig bei GAIAX verwendet. Die Architektur soll offen und transparent sein. Dazu werden Standards, Open Source Software (OSS) und dezentrale Verteilung unterstützt. Im Gegensatz zu proprietären, geschlossenen und zentralisierten Systemen sollen Anwender der europäischen Cloudlösungen Komponenten und Anbieter leicht auswechseln und entwickelte Services frei kombinieren können. Zusammengefasst ist Gaia-X eine Plattform, auf der Cloud-Anwendungen entwickelt und ausgeführt werden, die dem Prinzip der Souveränität folgen. Abb. 9.11 gibt einen Überblick über die Architektur von GAIA-X. Sie besteht aus den drei Ebenen Infrastruktur, Föderation und Daten. Die Infrastrukturebene erfasst Angebote von Netzwerken, Cloud-Diensten (private, public, hybrid) und Edge-Diensten. Internationale Hyperscaler arbeiten insbesondere als Cloud-Provider auf dem Infrastruktur-Layer mit. Die Föderation (Federation) Ebene umfasst die wesentlichen Regeln und Dienste, nach denen die Daten der Anwendungen verwaltet werden. Sie bilden das Zentrum für die Unterstützung der digitalen Souveränität des GAIA-X-Konzeptes. Mit den dort angebotenen Diensten werden die GAIA-X konformen Anwendungen entwickelt. Sie unterstützen deshalb die Standardisierung. Solange die Dienste nicht zur Verfügung stehen, müssen fehlende Funktionen in den Anwendungen spezifisch entwickelt werden, was leider zur Verwässerung des Konzeptes führt. Der Identity & Trust Dienst umfasst die Authentifizierung, Autorisierung und das Identitätsmanagement.

Abb. 9.11 Architektur von GAIA-X

9.2 Informationstechnische Innovationstreiber

167

Der Sovereign-Data-Exchange-Dienst unterstützt den transparenten Datenaustausch zwischen Anwendungssystemen. Hier gilt es vor allem, eine Art standardisierter APIs zu entwickeln. Der Federated Catalogue enthält die GAIA-X-Angebote von Anbietern in der Cloud, aus denen Nutzer die für sie geeigneten auswählen können. Der Compliance-Dienst stellt sicher, dass alle angebotenen Services die Gaia-X-Regeln zu Datenschutz, -sicherheit und -souveränität einhalten. Auf der Federation-Ebene bauen die Daten-Spaces mit den Anwendungen auf. Innerhalb des GAIA-X-Projektes werden vom Bundesministerium für Wirtschaft und Klimaschutz (BMWK) Leuchtturmprojekte für Anwendungen gefördert, die weitere Projekte der Verwaltung und Wirtschaft motivieren sollen. Diese sind u. a.:  Marispace-X zur Digitalisierung des maritimen Raumes, speziell zur Bergung von Munition im Meer.  Das Projekt Health-X dataLOFT behandelt den Schutz personenbezogener Gesundheitsdaten.  Das Projekt Merlot entwickelt einen Marktplatz für Bildungsangebote, die Benutzer bei ihrer Karriereplanung lebenslang unterstützen sollen.  In dem Projekt Possible werden datensouveräne Dienste zum Datenaustausch zwischen Behörden, der Wirtschaft und Privaten entwickelt. Die Projekte haben bei den Federation Services unterschiedliche Schwerpunkte und sind deshalb ein breites Testbed für das GAIA-X-Konzept. Mit dem Projekt CATENA-X wird vom BMWK ein gemeinsamer Datenraum für die Logistik (Supply Chain) zur Vernetzung der Zulieferer in der Automobilindustrie gefördert (siehe auch den Abschnitt zum Composable Industrial Enterprise in Kap. 10). Ihm schließt sich mit dem Projekt PRODUCTION-X ein Projekt für die gesamte Industrie an. Gaia-X soll und kann der europäischen Softwareindustrie einen Entwicklungsschub geben und generell der europäischen softwareintensiven Wirtschaft durch Betonung der Datensouveränität international einen Wettbewerbsvorteil verschaffen. Insbesondere können bei mittelständischen Unternehmen die Vorbehalte gegenüber Cloud-Lösungen abgebaut werden. Zur Zeit kann noch nicht abgesehen werden, ob das Konzept die hohen Erwartungen erfüllen wird. Für das Jahr 2025 wird erwartet, dass die GAIA-X-Plattform unter den ersten 10 Plattformen der Welt sein wird. Dieses ist ein ehrgeiziges Ziel. Da viele europäische Großunternehmen aus der IT-Industrie sowie der Anwendungswirtschaft und Verwaltung engagiert mitarbeiten, kann dem Projekt durchaus eine hohe Erfolgswahrscheinlichkeit zugesprochen werden. Es ist anzuerkennen, dass Europa die Wichtigkeit der Digitalisierung erkannt und die Aufholjagd gegenüber Amerika und Asien begonnen hat. Vielleicht ergeben sich während der Projektarbeit auch neue Wege, die noch nicht absehbar sind. Schließlich hatte Columbus 1492 geplant, den Seeweg nach Indien zu finden und hat stattdessen Amerika entdeckt. Entscheidend für seinen Erfolg war

168

9

Innovationstreiber für das Composable Enterprise

aber, dass er sich in Bewegung gesetzt hat und sich nicht dem Müßiggang hingegeben hat. Allein deshalb ist das Projekt GAIA-X zu begrüßen.

9.3

Gesellschaftliche und politische Innovationstreiber

Zur Zeit zwingen politische Ereignisse und Strategien viele Unternehmen zu schnellen Reaktionen und zur Anpassung ihrer Strategien. Durch politische Sanktionen gegenüber Russland fallen Absatzmärkte aus, werden Supply Chains unterbrochen und Produktionsstandorte geschlossen. Hier müssen Unternehmen schnell durch Ersatzmaßnahmen reagieren, die auch eine IT-Unterstützung verlangen. Es kann nicht gewartet werden, bis ein monolithisches System neue Funktionalitäten dazu bereitstellt, sondern es müssen in der Regel neue Lösungen individuell entwickelt werden. Dazu ist ein Composable Enterprise in der Lage. Gesellschaftlichen Änderungen von Arbeitseinstellungen und -formen, wie sie durch die Begriffe „New Work“ oder „New Normal“ bezeichnet werden, führen zu grundsätzlichen Veränderungen von Arbeitsweisen in Unternehmen. Vorschriften der Europäischen Union zur Bekämpfung des Klimawandels fordern neue Prozess- und Produktinnovationen.

9.3.1 New Work Der Begriff „New Work“ wurde von F. Bergmann in seinem Werk „New work new culture“ (Bergmann, 2017) eingeführt. Da der Arbeitsplatz für viele Menschen der Lebensmittelpunkt ist, soll und muss die Arbeit dem Menschen dienen und ihm Sinnhaftigkeit, Selbstbestimmung und Kompetenzerwerb bieten. Diese Entwicklung hat zu konkreten Anforderungen an moderne Arbeitsund Führungsmodelle geführt, die mit Schlagwörtern wie Demokratisierung, Dezentralisierung, Digitalisierung oder die Ausrichtung an den Kategorien People, Technology und Space belegt werden. Die Knappheit an Fachkräften und die Covid-Pandemie haben den Themen eine gesteigerte Aktualität gegeben. Insgesamt führt dieses zu Forderungen an eine moderne Personalpolitik, die durch ITSysteme unterstützt werden muss:  Hybrides Arbeiten zwischen Homeoffice und Büro (Zeit- und Ortsunabhängigkeit);  Ergebnisorientierung gegenüber Arbeitszeitorientierung als Maß für die Arbeitsleistung;  Flache Hierarchien, Führung auf Augenhöhe, Transparenz;  Zugang zu Wissensquellen und kontinuierliches Lernen;  Kollaboration, Kommunikation, Projektarbeit.

9.3 Gesellschaftliche und politische Innovationstreiber

169

Die Unterstützung dieser Forderungen erfordert Systeme zum digitalen Lernen, Kommunikation zwischen remote arbeitenden Mitarbeitern und den Führungspersonen zur Unterstützung der Mitarbeiterbindung, zur Anwerbung und zum Onboarding neuer Mitarbeiter. Hierzu sind flexible Systeme mit hoher Personalisierung erforderlich. Die Eigenschaften der Informationssysteme des Composable Enterprise kommen diesen Erwartungen entgegen.

9.3.2 Bewältigung des Klimawandels Die EU hat mit dem Europäischen Klimagesetz das Ziel gesetzt, bis zum Jahr 2050 Klimaneutralität zu erreichen. Für das Jahr 2030 hat sie auf dem Weg dahin mit dem Programm „Fit für 55“ das Ziel formuliert, die Treibhausgasemissionen um mindestens 55 % gegenüber dem Vergleichsjahr 1990 zu senken. Dazu werden detaillierte Vorschläge für die strengere Überarbeitung von EU-Rechtsvorschlägen gemacht, die nach Diskussionen in verbindliche Vorschriften umgesetzt werden sollen. Die Gesetzesregelungen für Ziele werden Unternehmen aller Branchen betreffen und dort Innovationen in neue Technologien und organisatorische Prozesse mit neuen ITLösungen erfordern. Auch erhebliche staatliche Investitionen in die Infrastruktur und Förderungen werden Chancen für unternehmerische Innovationen zeigen. Insgesamt will die EU Vorreiter im weltweiten Kampf gegen den Klimawandel sein. Da die Klimaentwicklung nicht vollständig abzusehen ist, muss damit gerechnet werden, dass die Regelungen und Maßnahmen in kurzen Zeitabständen überarbeitet werden. Damit besteht eine hohe Dynamik für Anpassungen der Unternehmen, die flexible IT-Systeme erfordert. Um einen Eindruck von dem Ehrgeiz des Programmes zu zeigen, sind einige Vorschläge des Programms „Fit für 55“ kurz aufgeführt:  Das Emissionshandelssystem wird verschärft und auf weitere Sektoren wie den Seeverkehr ausgedehnt.  Die Erneuerbare-Energien-Richtlinie (EEG) wird überarbeitet und der Anteil aus erneuerbaren Energiequellen soll bis 2030 mindestens 40 % betragen.  Die Energieeffizienz soll auf 36 % für den Endenergiebereich steigen.  Der Aufbau der Infrastruktur für Lade- und Betankungsvorgänge mit alternativen Energiequellen wird für Fahrzeuge, Schiffe und Flugzeuge massiv unterstützt.  Ab dem Jahr 2035 sollen Personenkraftwagen mit Verbrennungsmotoren nicht mehr auf den Markt gebracht werden.  Ein Ausweichen auf ausländische Produktionsstandorte mit weniger strengen Regeln oder auf ausländische Lieferanten soll verhindert werden. Darüber hinaus kommen Nachweispflichten über den Ressourcenverbrauch von Produkten zu CO2-Ausstoß, Energieverbrauch oder Verbrauch von bestimmten Materialien über die gesamte Supply Chain hinweg. Hierzu muss der Ressourcenverbrauch über die

170

9

Innovationstreiber für das Composable Enterprise

gesamte Lieferkette lückenlos verfolgt werden können, um ihn dann in einem digitalen Produktpass zu dokumentieren. Selbst wenn diese Regelungen noch modifiziert werden sollten, zeigen sie, welche dramatischen Änderungen den Unternehmen bevorstehen. Um die Regelungen in Unternehmen umzusetzen, sind innovative IT-Systeme zur Steuerung, Optimierung, Überwachung und Messung der entsprechenden Prozesse erforderlich. Diese bestätigen wegen ihrer erforderlichen Flexibilität und Dynamik den Einsatz der Architektur eines Composable Enterprise.

Literatur Baums, A., Schössler, M., & Scott, B. (2015). Industrie 4.0: Wie digitale Plattformen unsere Wirtschaft verändern – und wie die Politik gestalten kann. Kompendium Digitale Standortpolitik, Bd. 2. Berlin: Stiftung neue Verantwortung e. V. http://plattform-maerkte.de/wp-content/uploads/ 2015/11/Kompendium-High.pdf. ZUgegriffen: 9. Aug. 2023. Bergmann, F. (2017). Neue Arbeit, Neue Kultur. Freiburg: Arbor. Brynjolfsson, E., & McAfee, A. (2014). The second machine age: Work, progress, and prosperity in a time of brilliant technologies. New York: Norton. Cerniauskas, T., & Werth, D. (2022). Industry goes Metaverse. Die Verschmelzung, realer und virtueller Industriewelten am Beispiel der Abwasserwirtschaft. Fachmagazin IM+io, 37(2), 64–67. Ertel, W. (2016). Grundkurs Künstliche Intelligenz: Eine praxisorientierte Einführung (4. Aufl.). Wiesbaden: Springer. https://doi.org/10.1007/978-3-658-13549-2. Finlay, S. (2017). Artificial intelligence and machine learning for business: A no-nonsense guide to data driven technologies (2. Aufl.). Preston: Relativistic Books. Giese, P. (2016). Die Blockchain Bibel: DNA einer revolutionären Technologie. North Charleston: Createspace Independent Publishing Platform. Grinschuk, E. (2017). Blockchain – Ein neuer GameChanger: Funktion, Kryptowährungen, Trends und Möglichkeiten – Kurze Einführung (2. Aufl.). Hansen, H. R., Mendling, J., & Neumann, G. (2019). Wirtschaftsinformatik (12. Aufl.). Berlin, Boston: De Gruyter. Hegewald, F. (2022). Gaming meets Learning. Was wir heute schon über das Lernen von morgen wissen. Fachmagazin IM+io, 37(2), 104–105. Ismail, S., Malone, M. S., van Geest, Y., & Diamandis, P. H. (2014). Exponential organizations: Why new organizations are ten times better, faster, and cheaper than yours (and what to do about it). New York: Diversion Books. Kassen, M. (2022). Blockchain and e-government innovation: Automation of public information processes. Information Systems, 103(101862), 1–11. Knauer, A., Stareprawo-Hofmann, M., & Mühl, K. Y. (2022). Smart, smarter, Mittweida! Eine Region wird zum Aushängeschild für Blockchain und Metaverse. Fachmagazin IM+io, 37(2), 78– 81. Oppermann, L., & Prinz, W. (2022). Vom Hier ins Metaverse über die Blockchain und zurück. Geschichte und Definition. Fachmagazin IM+io, 37(2), 52–55. Rifkin, J. (2014). Die Null Grenzkosten Gesellschaft – Das Internet der Dinge, kollaboratives Gemeingut und der Rückzug des Kapitalismus. Frankfurt: Campus. Rochet, J. C., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European Economic Association, 1(4), 990–1029.

Literatur

171

Welpe, I., & Ziegler, C. (2022). Web3: Wie Ihre Organisation in 10 Jahren aussehen wird – wenn es sie dann noch gibt. Fachmagazin IM+io, 37(2), 42–47. Wennker, P. (2020). Künstliche Intelligenz in der Praxis: Anwendung in Unternehmen und Branchen: KI wettbewerbs- und zukunftsorientiert einsetzen. Wiesbaden: Springer Gabler.

Weiterführende Literatur BMWi (2020). Gaia-x: Das europäische Projekt startet in die nächste Phase. https://www.bmwk.de/ Redaktion/DE/Dossier/gaia-x.html. Zugegriffen: 21. Febr. 2023. Christensen, C. M. (1997). The innovator’s dilemma: When new technologies cause great firms to fail. Boston: Harvard Business School Press. Europäischer Rat (2022). „Fit für 55“ Der EU-Plan für den grünen Wandel. https://www. consilium.europa.eu/de/policies/green-deal/fit-for-55-the-eu-plan-for-a-green-transition/. Zugegriffen: 21. Febr. 2023. Meinel, C., & Krohn, T. (2022). Design Thinking in der Bildung, Innovation kann man lernen. Weinheim: Wiley. Picot, A., Reichwald, R., & Wigand, R. T. (1998). Die grenzenlose Unternehmung – Information, Organisation und Management. Lehrbuch zur Unternehmensführung im Informationszeitalter. Wiesbaden: Gabler. https://doi.org/10.1007/978-3-322-93130-6. Russell, S., & Norvig, P. (2012). Künstliche Intelligenz: Ein moderner Ansatz (3. Aufl.). Hallbergmoos: Pearson. Schermuly, C. C. (2021). New Work – Gute Arbeit gestalten (3. Aufl.). Freiburg: Haufe. Weber, F. (2020). Künstliche Intelligenz für Business Analytics. Wiesbaden: Springer Fachmedien.

Digitale Branchenkonzepte für das Composable Enterprise

10

Zusammenfassung Durch unterschiedliche Digitale Treiber entsteht in allen Branchen eine Vielzahl von neuen Produkten und Prozessen. Sowohl Branchen, die „informationsnahe“ Produkte oder Dienstleistungen erzeugen (z. B. die Medien), als auch Branchen, die materielle Produkte erzeugen, sind diesen disruptiven Änderungen ausgesetzt. Im Folgenden wird aufgezeigt, wie sich daraus ganzheitliche disruptive Geschäftsmodelle für Unternehmen ergeben. Als erste Branche wird die Industrie betrachtet, für die mit dem Konzept Industrie 4.0 bereits ein Ansatz für einen digitalisierten Unternehmenstypen besteht. Dieses Konzept wird mit den Eigenschaften des Composable Enterprises verbunden und es werden Übereinstimmungen und Ergänzungen herausgestellt. Dabei wird den Hauptprozessen Logistik, Produktentwicklung und Fabriksteuerung gefolgt. Als Beispiel für eine Dienstleistungsbranche wird die IT- und Unternehmungsberatung behandelt. Hierbei wird systematisch den in Kap. 9 beschriebenen Innovationstreibern gefolgt. Als ein Beispiel aus dem öffentlichen Bereich werden Hochschulen untersucht, wie sich die Digitalisierung auf ihre Leistungsprozesse Forschung, Lehre und Verwaltung auswirken. Alle Ausführungen werden durch Beispiele illustriert. Mit den drei unterschiedlichen Branchen und Vorgehensweisen werden dem Leser Anregungen für sein eigenes Vorgehen gegeben. Ausführungen, die sehr speziell sind oder sich auf konkrete Systeme beziehen, sind durch Kursivschrift kenntlich gemacht. Der mehr an einem Überblick interessierte Leser kann diese Teile überspringen, ohne den inhaltlichen Leitfaden zu verlieren.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1_10

173

174

10

Digitale Branchenkonzepte für das Composable Enterprise

10.1 Die composable Industrieunternehmung Industrieunternehmungen besitzen gegenüber Unternehmungen anderer Branchen eine höhere Komplexität bei ihren Produkten und Prozessen:  Ihre Produkte bestehen aus einer Vielzahl eng miteinander verbundenen Komponenten, sodass die Produktentwicklung ein komplexer Prozess ist.  Im Produktionsprozess werden komplexe und teure Maschinen eingesetzt, die eine sorgfältige Einsatzplanung und Steuerung erfordern.  Die Beschaffung der Vielzahl benötigter Materialien und der Vertrieb der erklärungsbedürftigen Produkte und After-Sales-Betreuung sind ebenfalls außergewöhnlich aufwendig. Deshalb findet die Organisation von Industrieunternehmungen innerhalb von Betriebswirtschaftslehre, Arbeitswissenschaften, Ingenieurwissenschaften und Informationstechnik in Wissenschaft und Anwendung hohe Beachtung. Schlagwörter wie Lean Production, Kanban, Kaizen, Fraktale Fabrik oder Industrie 4.0 bezeichnen nur einige der entwickelten Konzepte. Davon ist für das composable Industrieunternehmen das Konzept Industrie 4.0 von besonderer Bedeutung.

10.1.1 Verbindungen zwischen der composable Industrieunternehmung und Industrie 4.0 Der Begriff Industrie 4.0 (I4.0) beschreibt die durch die Digitalisierung ausgelöste vierte industrielle Revolution. Die Zählweise wird dabei mit der Erfindung der Dampfmaschine, der Fließbandorganisation, der automatischen Maschinensteuerung und nun dem Internet of Things (IoT) begründet, das zur Abgrenzung von den mehr konsumnahen Anwendungen als Industrial Internet of Things (IIoT) bezeichnet wird. Der Begriff wurde 2011 von den Professoren Henning Kagermann, Wolfgang Wahlster und Wolf-Dieter Lukas in einem Presseartikel vorgestellt (Kagermann et al., 2011). Der Begriff Industrie 4.0 hat sich in den letzten Jahren schnell in Wissenschaft und Praxis durchgesetzt (vgl. z. B. Leimeister 2021, S. 481)1 . 1

Detaillierte Definitionen für I4.0 sind vielfältig und komplex. Viele erstrecken sich auf über eine halbe DIN-A4-Seite und sind sehr technisch ausgerichtet. Insbesondere wird häufig der Schwerpunkt einseitig auf die Fabrikautomation gerichtet. Im Folgenden soll dagegen gezeigt werden, wie sich die Digitalisierung auf alle wesentlichen Funktionen eines Industriebetriebs auswirkt und zu neuen Businessmodellen mit neuen Produkten sowie Dienstleistungen führt. Als wichtigstes Kennzeichen der 4. Industriellen Revolution gilt die Verbindung aller industriellen Objekte durch das Internet und die Nutzung von Internetdiensten. Die Verbindung wird durch zunehmende Standardisierung von Datentransfers unterstützt. Die datengetriebene Steuerung ist ein weiteres Merkmal von Industrie 4.0. Die Herausforderungen von Industrie 4.0 für die deutsche Industrie sind offen-

10.1 Die composable Industrieunternehmung

175

Die Wirtschaftsverbände ZVEI, VDMA und BITKOM erarbeiten unter dem Dach des BDI eine gemeinsame konzeptionelle Plattform für I4.0. Große Unternehmen wie Siemens AG, Bosch GmbH und SAP AG entwickeln eigene I4.0-Software-Plattformen und in nahezu jedem größeren Industrieunternehmen ist I4.0 ein Diskussionsthema. In den USA wird das Thema von dem Industrial Internet Consortium (IIC), dem die wesentlichen großen amerikanischen Industrie- und IT-Unternehmen angehören, bearbeitet. Auch deutsche Unternehmen arbeiten im IIC mit. Die EU veröffentlichte das Programm „Factories of the Future“ (2008–2020) und auch in Asien sind öffentlich unterstützte Programme gestartet (Toro et al., 2021, S. vii). Viele wissenschaftliche Fachorganisationen und Forschungsinstitute bearbeiten das Thema. Die für Industrie 4.0 entwickelten Konzepte, Prototypen sowie praktischen Beispiele zeigen große Ähnlichkeiten mit den Prinzipien des Composable Enterprise. Dieses wird deutlich, wenn die Treiber und Enabler von Industrie 4.0, wie sie in der anwendungsnahen Literatur und Fallbeispielen herausgestellt werden, mit den Eigenschaften des Composable Enterprise verglichen werden. Auch zeigt sich, dass nahezu alle in Kap. 9 herausgestellten Innovationstreiber einbezogen werden. Die im Folgenden aufgeführten Eigenschaften für I4.0 werden in dem Handbuch Industrie 4.0 genannt (Bauernhansl et al., 2017). Im Einzelnen sind es:  Infrastruktur bestehend aus Cloud-Edge Computing, Blockchain,  Organisatorische Dezentralisierung, Modularisierung, Autonomie, Fraktale, Prozessmodule,  Serviceorientierung der Software,  Flache Hierarchien,  Transparenz,  Vernetzung innerhalb der Unternehmung und zu Kunden und Partnern,  Verbindung materieller Produkte mit Smart Services,  Digitale Zwillinge für Produkt und Fabrik,  Individualisierung von Produkt und Fertigung (Losgröße 1)  Einsatz Künstlicher Intelligenz,  Monitoring,  Staatliche Einflüsse durch Vorschriften und Förderungen, sichtlich. Deutschland ist im Gegensatz zu vielen europäischen Ländern und den USA ein starkes Industrieland und muss aufpassen, dass es nicht „im Industriemuseum“ endet, weil es die Digitalisierung verpasst. So hat jedenfalls die ehemalige deutsche Bundeskanzlerin Angela Merkel gemahnt. Nicht nur Menschen kommunizieren über das Internet, sondern auch „Dinge“ wie Materialien, Produkte und Maschinen. Hierbei werden zur Kommunikation Konventionen des Internets (InternetProtokoll, kurz IP) verwendet, insbesondere erhält jedes „Ding“ eine IP-Adresse. Mit der Form IPv6 stehen 3,4 mal 10 hoch 38 Adressen zur Verfügung, sodass die Adressvergabe keine technische Hürde ist. Es wird deshalb auch in diesem Zusammenhang von dem „Internet of Everything“ gesprochen.

176

10

Digitale Branchenkonzepte für das Composable Enterprise

 Kollaboratives Arbeiten,  Schwarmeffekt. Die Eigenschaften zeigen große Übereinstimmungen mit denen des Composable Enterprise. Deshalb ist das Konzept des Composable Enterprise die konsequente Weiterentwicklung des Ansatzes von Industrie 4.0. Die ersten sechs Eigenschaften werden besonders beachtet, da sie darauf abzielen, die Komplexität von Industrieunternehmen durch Strukturierung und Segmentierung zu reduzieren und gelten generell für alle composable Unternehmen, unabhängig von der Branche. Auch das PBC-Konzept lässt sich in den Begriffen Modularisierung, Prozessmodule oder Serviceorientierung erkennen. Im Gegensatz zu dem hier entwickelten Konzept des Composable Enterprise werden keine ganzheitlichen Ansätze für die Informationsverarbeitung entwickelt. So fehlt ein Plattformkonzept mit den integrierten Aufgaben Prozessautomatisierung, Integration, Low-Code-Entwicklung und Composition sowie dem Lifecycle. Es werden lediglich einzelne Aspekte bei Bedarf herausgegriffen. Die mehr kaufmännischen Funktionen einschließlich der Logistik werden pauschal mit dem Kürzel ERP bezeichnet und als Black Box behandelt. Aber eine flexible Produktion verpufft in ihrer Wirkung, wenn sie auf eine starre Vertriebs- und Beschaffungslogistik sowie Verwaltung trifft. Industrie 4.0 ist deshalb ein wichtiger Schritt in Richtung eines Industrial Composable Enterprise. Deshalb wird das Konzept Industrie 4.0 auf alle Funktionen eines Industriebetriebes erweitert und um die Application Composition Platform-Architektur ergänzt.

10.1.2 Architektur der composable Industrieunternehmung (Y-Modell) In dem Y-Modell der Abb. 10.1 werden die drei operativen Hauptprozesse Fertigung in der Smart Factory, Produktentwicklung oder Product Lifecycle Management (PLM) und Logistik erfasst. Das Modell geht auf Arbeiten des Verfassers aus den 1980er Jahren zum Thema Computer Integrated Manufacturing (CIM) zurück (vgl. Scheer, 1987, 1990). In ihm wurde analysiert, wie ein Industrieunternehmen ganzheitlich durch den Einsatz der Informationstechnik unterstützt und verändert werden kann. Das CIM-Konzept konnte damals wegen unzureichender IT-Ressourcen nicht verwirklicht werden. Es gab keine standardisierten Betriebssysteme, keine Datenbanksysteme, keine Netzwerkstandards und generell eine zu geringe Computerleistung. Trotzdem bleiben konzeptionelle Gedanken weiter sinnvoll und gehen in dem Ansatz I4.0 auf. Das Y-Modell der Abb. 10.1 hilft als erste Übersicht, die Funktionen einer Industrieunternehmung einzuordnen und im Zusammenwirken zu verstehen. In Abb. 10.2 sind die Prozesse detaillierter beschrieben.

10.1 Die composable Industrieunternehmung

177

Abb. 10.1 Y-Modell für Industrial Enterprise

Die Logistik umfasst die Funktionen von dem Kundenauftragseingang bis zur Freigabe des Fertigungsauftrages in die Fabrik. Das Product Lifecycle Management beschreibt die technische Entwicklung des Produktes als Zeichnung und Stückliste über die Arbeitspläne zur Fertigung bis zur Entsorgung des Produktes. In der Fabrik fließen beide Stränge zusammen. Zur Fertigung müssen die technischen Informationen über das Produkt und die dazu notwendigen Fertigungsinformationen (Arbeitspläne) bekannt sein sowie aus dem Logistikprozess Auftragsdaten wie Mengen, Qualitäten und Termine. In der Factory werden die Fertigungsaufträge den Maschinen zugeordnet und produziert. Die oberen Teile des Y-Modells bezeichnen Planungsaktivitäten, der untere Teil die kurzfristige Real-Time-orientierte Realisierungsebene. Die grafische Faltung des Y-Modells weist auf die Dezentralisationsmöglichkeiten durch organisatorische Modularisierung hin. Die Prozesse des Y-Modells können sich je

Abb. 10.2 Detaillierte fachliche Prozesssicht auf ein Industrieunternehmen

178

10

Digitale Branchenkonzepte für das Composable Enterprise

nach Dezentralisierungsgrad des Unternehmens bei Tochterunternehmen, Fabriken oder Entwicklungszentren wiederholen. Finanzfunktionen, Personalmanagement usw. sind als zentrale Shared Services zur Ressourcenoptimierung mit den dezentralen produktiven Funktionen des Y-Modells über die Integrationsschicht der Application Composition Platform verbunden. Die Funktionen des Y-Modells folgen von oben nach unten einer logischen Reihenfolge. Diese wird allerdings später durch die Vernetzung aufgeweicht, indem auch Rücksprünge und Übersprünge durch direkte Kommunikation zwischen allen Funktionen zugelassen werden. Trotzdem hilft das Wasserfallmodell des logischen Flusses dem grundsätzlichen Verständnis. In der Abbildung kommen auch die häufig aus technischer Sicht angeführten drei Ebenen der Automatisierung zum Ausdruck: die eigentliche Automatisierung der Produktion in der Smart Factory, die MES-Steuerungsebene und die ERP- und PLM-Ebene, wobei ERP für die Logistik steht (Bauernhansl, 2017, S. 22). Es ist allerdings unverständlich, dass in vielen Ausführungen zu Industrie 4.0 die Produktentwicklung ausgespart wird. Dieses ist wohl auf die Dominanz der Fertigungstechnik innerhalb der Diskussion zurückzuführen. Es ist aber gerade die Produktentwicklung, die Grunddaten wie die Fertigungsstückliste (Bill of Material = BoM) sowie Arbeitspläne (Routings) erzeugt, die sowohl für die Fertigung als auch für die Planung und Steuerung der Logistik benötigt werden. Sie werden deshalb auch häufig in ERP-Systemen übernommen und verwaltet. In Abb. 10.2 sind sie als verbindende Elemente aufgeführt. Die drei Prozesse Logistik, Fertigung und Produktentwicklung des Y-Modells werden erläutert. Der linke Schenkel des Y-Modells kennzeichnet den durch Aufträge getriebenen Auftragsabwicklungsprozess. Aus den Kundenaufträgen des Customer Relationship Management Systems (CRM) werden für die benötigten Materialien (MRP = Material Resource Planning), die Beschaffungsaufträge und für die zu produzierenden Teile die Fertigungsaufträge abgeleitet. Die Beschaffungsaufträge werden vom Supply Chain ManagementSystem (SCM) weiterverarbeitet. Die Fertigungsaufträge werden mit den Kapazitäten im Production Planning (PP) abgeglichen und für die Fertigung freigegeben (Shop Order Release). Das Manufacturing Execution System (MES) übernimmt die freigegebenen Aufträge und steuert sie durch die Produktion. Das Supervisory Control and Data Acquisition (SCADA) sammelt Daten zum Monitoring und zu Analysen aus den Produktionsanlagen (auch zum remote Steuern von Anlagen). Das Qualitätsmanagementsystem prüft die Einhaltung von Vorgaben (QM). Versand (Shipment) steuert die Lieferung des Auftrages zum Kunden. Als externe Logistik bezeichnet man die Beziehungen zu Kunden und Lieferanten (CRM, SCM und Shipment). Die Steuerung der Aufträge innerhalb des Unternehmens wird als interne Logistik bezeichnet.

10.1 Die composable Industrieunternehmung

179

Der obere rechte Schenkel des Y-Modells beschreibt den Produktentwicklungsprozess. Die Forschungs- und Entwicklungsaktivitäten im rechten oberen Bereich erzeugen durch Einsatz von Computer aided Design bzw. Engineering und Planning (Arbeitsplanerstellung) CAD/CAE/CAP-Systemen (zusammengefasst als CAX) die geometrischen Produktbeschreibungen und durch die Arbeitsplanung die Fertigungsvorschriften (Arbeitspläne) und NC-Programme (Numerical Control). Das Prototyping prüft die Funktionalität des Produktes. Auch werden produktbezogene Services wie Wartung oder Finanzierung entwickelt. Die Verfolgung der Produkte über die Lebensdauer bis zur Entsorgung wird als Product Lifecycle Management (PLM) bezeichnet. Digitale Zwillinge unterstützen Simulationsuntersuchungen. Von der Fabrikplanung werden die benötigten maschinellen Ressourcen definiert. Die Prozesse in der Fabrik im rechten unteren Bereich des Y-Modells, sind eng mit den logistischen Prozessen des linken Schenkels verbunden. Die beiden Schenkel laufen deshalb grafisch zusammen. Das MES stellt die Verbindung über die Steuerung der Aufträge her. Hier werden die zu produzierenden Teile nach Art, Menge, Zeit und Qualität mittels der Fertigungsvorschriften den Ressourcen zugeordnet, die Fertigung zeitnah gesteuert, der Materialfluss über Lager- und Transportsysteme geleitet, durch Fertigungs- und Prüfsysteme behandelt sowie die Fertigungsergebnisse erfasst. Die automatisierten Systeme werden als Cyber Physical System (CPS) bezeichnet. Die erzeugten Produkte werden anschließend der Versandlogistik übergeben und an die Kunden ausgeliefert. Die beiden Schenkel sind im oberen Bereich durch die gemeinsam genutzten Daten der Stücklisten (Bill of Material – BoM) und Arbeitspläne (Routing) verbunden. Die Finanzbuchhaltung, das Personalmanagement und Controlling begleiten – aus der Wertesicht – alle Prozesse und sind in der Abbildung als Shared Services gekennzeichnet. Die Funktionen Einkauf und Vertrieb zählen zum ERP-Umfang, werden hier als Teil des operativen Leistungsflusses des Industrieunternehmens angesehen. Alle Anwendungen besitzen im Composable Enterprise Schnittstellen in Form von APIs, wie durch die stark ausgezogenen Striche zum Ausdruck kommt. Die Anwendungen selbst setzen sich wiederum aus PBCs zusammen. Das Y-Modell ist eine funktionale Sicht auf ein Industrieunternehmen. Die vertikale Anordnung der Funktionen beschreibt ihre grundsätzliche Ablauflogik. Bei dem automatisierten Industrie 4.0 Konzept und damit bei dem Composable Industrial Enterprise ändert sich das Konzept in drei Richtungen: Erstens: Das Y-Modell bildet bei einer periodischen Anwendung eine Batch-Verarbeitung ab. Das heißt, dass im Logistikprozess der Auftragsvorrat einer Periode, z. B. einer Stunde, eines Tages oder einer Woche, alle Funktionen nacheinander durchläuft. Das composable Unternehmen wird dagegen konsequent in Real-Time fallbezogen gesteuert, also jeder Auftrag wird nach seiner Ankunft sofort eingeplant und durch alle weiteren Schritte der Logistik bis zur Fertigung geführt. Zweitens: Das hierarchische Wasserfallmodell der Funktionen wird durch eine flache Struktur der Funktionsservices aufgelöst. Dieses bedeutet, dass die Funktionen in unterschiedlicher Sequenz situationsbezogen aufeinander folgen können. So kann bei einer

180

10

Digitale Branchenkonzepte für das Composable Enterprise

Verzögerung in der Fertigung direkt aus dem MES-System eine Nachricht an den Kunden versendet werden, ohne den Umweg über das Vertriebssystem zu nehmen. Damit befinden sich alle Funktionen quasi auf der gleichen Ebene. Die Ablauflogik zwischen den Funktionen des Y-Modells bleibt aber vom Grundsatz her gültig; nur können in bestimmten Fällen Funktionen übersprungen oder in anderer Reihenfolge ausgeführt werden. Die Ablauflogik, wie bei einem bestimmten Ereignis reagiert wird, muss dabei durch die Ereignissteuerung der Prozesse festgelegt werden. Generell führt aber die Vernetzung der Systemkomponenten und der Kommunikation von jedem Element mit jedem gegenüber dem hierarchischen Steuerungsprinzip zu einer höheren Komplexität. Drittens: Das monolithische zentrale Y wird modularisiert und damit in autonome selbstähnliche Fraktale aufgelöst. Dieses kann sich auf alle drei Hauptprozesse gleichzeitig oder auf unterschiedliche Kombinationen von ihnen beziehen. Die höhere Komplexität, die durch die flachere Systemstruktur der Vernetzung aller Funktionen entsteht, wird durch die Modularisierung wieder aufgehoben. Dieses ist ein wichtiges Element des Composable Enterprises: einerseits führt die hohe Flexibilität der Vernetzung zu einer höheren Komplexität in der Steuerung des Systems gegenüber einem hierarchischen Ansatz. Andererseits werden durch die Segmentierung kleinere Steuerungseinheiten geschaffen und damit der Komplexität entgegengewirkt. Abb. 10.3 zeigt dazu einige mögliche Beispiele zur Modularisierung. Die Verwaltungsfunktionen werden in allen Fällen zentral durch Shared Services ausgeführt. Im Fall a) besteht das Unternehmen aus drei Betrieben, die alle logistischen und produktbezogenen Funktionen selbstständig ausführen.

Abb. 10.3 Mögliche Modularisierung von Industrieunternehmen und Hierarchien

10.1 Die composable Industrieunternehmung

181

Abb. 10.4 Praktischer Fall aus der Prozessindustrie. Die Umkreisung der Systeme wurde vom Verfasser ergänzt. (Quelle: Pötter et al., 2017)

Im Fall b) werden die planerischen Logistikfunktionen und die Produktentwicklung zentral bearbeitet; die Fertigung aber in drei autonomen Fabriken ausgeführt. Abb. 10.4 zeigt dazu einen praktischen Fall aus der Prozessindustrie, bei dem sich drei Produktionssysteme jeweils autonom durch Manufacturing Execution Systems (MES) sowie Prozessleitsysteme (PLS) dezentral steuern und mit dem zentralen ERP-System über Services verbunden sind (Abb. 0.4 aus Pötter et al., 2017, S. 71). Im Fall c) werden die Produkte zentral entwickelt; die logistischen Prozesse und die Fertigung sind den drei autonomen Betrieben zugeordnet. Die Strukturen können sich in einem Unternehmen fraktal wiederholen, indem z. B. in einer autonom arbeitenden Fabrik autonom arbeitende Fertigungsbereiche bestehen, die wiederum aus autonom arbeitenden Subsystemen wie Fertigungsinseln oder Transportsystemen bestehen (siehe Abb. 10.3d). Auf jeder Ebene können Funktionen des YModells entsprechend dem Detaillierungsgrad der Aufgaben der Ebene nach dem Beispiel der Abb. 10.3a bis c verteilt werden. Dadurch entsteht eine Kaskade vernetzter Fraktale oder ein Systems of Systems. Das Grundprinzip muss dabei sein, alle Strukturen logisch und physisch so zu vernetzen, dass die Unternehmensprozesse ohne Informationsverluste oder Informationsbrüche über alle Ebenen transparent ausgeführt werden. Dazu ist eine einheitliche integrierte Plattformarchitektur erforderlich, wie sie hier durch die Application Composition Platform vorgestellt wurde. Durch die Low-Code-Funktionalität können die dezentralen Einheiten von den Fertigungs- oder Verfahrensingenieuren spezielle Auswertungen erzeugen und Dashboards entwickeln, die die Steuerung der einzelnen Systeme individuell unterstützen. Im Composable Enterprise werden dann neue Anwendungen als PBCs mit Hilfe der Application Composition Platform entwickelt und mit den Standardsystemen und Shared

182

10

Digitale Branchenkonzepte für das Composable Enterprise

Services zu Anwendungen komponiert. Fremdbezogene Anwendungen werden so ausgesucht, dass sie möglichst mit der Architektur konform sind. Die Plattform bietet Dienste zur Entwicklung der Services der Abb. 10.2, zur Verbindung mit der Infrastruktur, hier dem Edge/Cloud-System und zum Monitoring während der Ausführung an. Alle PBCs und Anwendungen sind mit API- und oder EDA-Services mit ihrer Außenwelt verbunden. Die Eventsteuerung spielt in der Fertigung bei der Real-Time-Verarbeitung eine besonders wichtige Rolle, um auf Störungen oder andere Ereignisse sofort reagieren zu können. Ereignisse werden dann in einer Ereignisdatenbank gespeichert, aus denen Anwendungen die für sie interessanten Ereignisse ermitteln oder die Ereignisse stoßen (triggern) selbst eine Anwendung in Real-Time an. Dazu kann ein gesonderter Manufacturing Service Bus (MSB) in der Fertigung dienen. Alle Verbindungen zwischen den Funktionen des Y-Modells und dem ERP-Finance werden über API bzw. EDA-Schnittstellen über ein gemeinsames Gateway der Plattform geführt. Auch die Verbindung zu den Kunden, Lieferanten und Communities wird über die Services der Plattform hergestellt. Externe Entwickler eines Kunden oder Partners können ebenfalls über das Internet und die Cloud auf die Plattform zugreifen, um Services des Unternehmens in eine eigene Anwendung einzubetten. Cloudtechnologie ist die IT-Infrastruktur, über die alle Rechen-, Speicher- und Kommunikationsdienste abgewickelt werden. Zur technischen Realisierung der Kommunikation zwischen den Komponenten und der Cloud siehe z. B. (Langmann, 2021). In Abb. 10.5 ist die Anwendungsarchitektur für das composable Industrieunternehmen zusammengefasst. Sie folgt dem Y-Modell und der Anwendungsarchitektur des Composable Enterprise der Abb. 1.9 bzw. 4.21. Die Architektur ist nach den drei Leistungszentren des Y-Modells in Logistik, Entwicklung und Factory gegliedert. Da die Bereiche jeweils weiter untergliedert werden können, werden die Symbole grafisch gefaltet. Die Faltungen der Anwendungen bedeuten, dass von ihnen Varianten bestehen. Diese beziehen sich auf die selbstständigen Organisationsmodule, für die z. B. individuelle User Interfaces (Frontends) entwickelt werden, aber auch auf unterschiedliche Abläufe. Um die Mehrfachverwendung von PBCs und Anwendungen zu unterstützen, werden alle Systemelemente auf einem internen Marktplatz verwaltet. Die Shared Services als übergreifende, mehr kaufmännische Anwendungen sind zentral und pauschal angegeben, können aber prinzipiell ebenfalls Varianten auf den Hierarchieebenen enthalten. Das in dem Y-Modell enthaltene Prozesswissen der Anwendungen ist in Prozessmodellen erfasst und steht im Rahmen der Composition Funktion bei der Zusammenstellung von PBCs zu Anwendungen in den Bereichen zur Verfügung. Dieses wird durch das YSymbol und das Aris-Haus angezeigt. Mit dem Y-Symbol wird ausgedrückt, dass die Semantik der technischen und organisatorischen Zusammenhänge der Leistungserstellung in den drei Bereichen nach wie vor vorhanden ist.

10.1 Die composable Industrieunternehmung

183

Abb. 10.5 Anwendungsarchitektur des Composable Industrieunternehmens. Die Anwendungen in Logistics, PLM und Factory können sich in den organisatorischen Modulen der Abb. 10.3 als Varianten wiederholen. (Quelle: Adobe Stock, PureSolution)

Die unternehmensweiten Prozessmodelle zur Verbindung der Shared Services mit den drei Bereichen sowie der Bereiche untereinander sind durch das ARIS-Haus als zentrales Prozesswissen der Enterprise Architecture gekennzeichnet. Die PBCs, Applications und Shared Services sind durch die Integrationsschicht der Application Composition Platform miteinander verbunden. Die Low-Code-Funktionalität ermöglicht es Ingenieuren oder anderen versierten Mitarbeitern, eigene maßgeschneiderte Apps oder Dashboards im laufenden Betrieb zu entwickeln und mit den Anwendungen zu integrieren. Damit wird dem composable Industrieunternehmen ein Höchstmaß an Flexibilität gegeben. Die drei Hauptprozesse Fabriksteuerung, Produktentwicklung sowie Logistik werden im Folgenden etwas genauer betrachtet. Dabei wird jeweils auf die besonders wirksamen Innovationstreiber hingewiesen.

184

10

Digitale Branchenkonzepte für das Composable Enterprise

10.1.3 Fabriksteuerung („Smart Factory“) Die wesentliche neue I4.0-Technologie in der Fabrik sind Cyber Physical Systems (CPS). Diese sind softwareintensive Systeme, die über Sensoren physikalische Daten erfassen und über Aktoren darauf reagieren. Sie sind über das Internet mit der Cloud verbunden und kommunizieren untereinander sowie mit ihrer Umgebung (Bauernhansl, 2017, S. 12; Vogel-Heuser, 2017, S. 33). Der Begriff CPS umfasst automatisierte Maschinen, Roboter, Lagersysteme, Transportsysteme, automatisierte Laborsysteme zur Qualitätskontrolle sowie auch intelligente Materialien. Hervorzuheben sind neuere Entwicklungen zur Steuerung der Systeme durch Gesten, visuelle Erkennung durch KI und Sprache. Eine tiefere technische Beschreibung von CPS findet sich bei (Langmann, 2021; Toro et al., 2021). Materialien werden als intelligent bezeichnet, wenn sie ihre Eigenschaften wie Qualität und benötigte Fertigungsschritte (Arbeitspläne) auf einem Datenträger (Chip) mit sich führen. Über Techniken wie Radio Frequence Identification (RFID) oder Bilderkennung können die Materialien selbstständig den Weg durch die Fertigung finden. Produktionsanlagen und Materialien koordinieren Kapazitätsbedarf und -angebot selbstständig. Fällt ein CPS aus, übernimmt ein anderes System automatisch dessen Aufgabe und das System reorganisiert selbstständig den Materialfluss. Der wichtigste Innovationstreiber in der Fabrik ist das Prinzip der Selbststeuerung. In den letzten 40 Jahren ist bereits ein Trend zur Dezentralisierung der Fabriksteuerung zu erkennen gewesen, der nun weiter geführt wird. Bis in die 1980er Jahre dominierte dagegen ein zentraler Ansatz, d. h. von einer zentralen Produktionsplanung wurden Fertigungsaufträge definiert, die dann in der Fabrik „abgearbeitet“ werden sollten. Wegen der vielfältigen Störungen in der Fabrik führte dieses aber zur schnellen Inaktualität der Planung und damit zum weitgehenden Scheitern des zentralen Ansatzes. Im nächsten Schritt wurde die Fabrik in dezentrale organisatorische Einheiten gegliedert (Fertigungsinseln, Leitstandsbereiche, flexible Fertigungssysteme, Bearbeitungszentren), die eine gewisse Autonomie zur Steuerung erhielten und flexibler auf Störungen reagieren konnten. Die Steuerungsfunktionen sollen der niedrigsten Ebene der Automatisierung zugeordnet werden, d. h. sie wandern tendenziell in die Microrechner der „Dinge“. Dieses bedeutet nicht, dass die Funktionen z. B. eines MES-Systems entfallen, sie werden nur neu verteilt (Büttner & Brück, 2017, S. 47). Die bei Industrie 4.0 angestrebte durchgehende Selbststeuerung der Produktion ist damit die logische Fortführung dieser Entwicklung. Wenn alle beteiligten Elemente des Systems ihren Zustand kennen und die Anforderungen der Aufgaben bekannt sind, ist die Steuerung ein algorithmisch zu lösendes Problem. Hierzu sind Verfahren der Operations Research und der künstlichen Intelligenz zunehmend in der Lage. Die Selbststeuerung führt im nächsten Schritt zur Selbstoptimierung. Wird z. B. erkannt, dass ein Werkzeug an einer Maschine abgenutzt ist, können automatisch nur Fertigungsteile zugewiesen werden, für die der Werkzeugzustand noch ausreicht.

10.1 Die composable Industrieunternehmung

185

Die hohe Flexibilität der CPS ermöglicht eine starke Individualisierung der Fertigung, da das Umrüsten des Systems nahezu ohne Zeitverlust und Kosten erfolgt. Damit ist das schon länger diskutierte Ziel der Fertigung mit Losgröße 1 zu den Kosten der Massenproduktion näher gerückt. Eine weitere wesentliche Technologie ist die kostengünstige Speicherung von Massendaten in der Fertigung, wie sie durch den Preisverfall von Speichermedien und neuen Datenbanktechnologien ermöglicht wird. Insbesondere ist die Speicherung der Daten im internen Speicher des Rechners (als „in memory“ bezeichnet) anstelle der Speicherung in externen Speichermedien hervorzuheben, die eine schnelle Verarbeitung ermöglicht. Durch Sensoren können Maschinen-, Material- und Umfeldzustände in „Real-Time“ erfasst werden. Analytische Auswertungsverfahren wie Process Mining können nicht nur das Verhalten der Vergangenheit erklären, sondern mit predictiven Verfahren der KI den Gegenwartszustand zum sofortigen Eingreifen nutzen und darüber hinaus Hinweise auf ein zu erwartendes zukünftiges Systemverhalten geben. Bekanntestes Beispiel ist das Predictive Maintenance, bei dem aus dem gegenwärtigen Verhalten des Systems auf Anomalitäten geschlossen wird, die zum Auswechseln einer Komponente in naher Zukunft raten. Hier öffnet sich ein Fenster für neue digitale Dienstleistungen. Ein Hersteller von Maschinen kann durch Sensoren während des Einsatzes seiner Maschinen beim Kunden alle relevanten Daten erfassen. Bereits heute werden häufig in Werkzeugmaschinen mehr als hundert Sensoren zur Erfassung von Temperatur, Geschwindigkeiten, Erschütterungen, Qualitäten, Stromverbrauch, usw. eingesetzt. Diese können vom Hersteller über das Internet in Real-Time verfolgt und mit allen in der Welt eingesetzten Systemen verglichen werden. Durch Auswertungen können individuell auf die einzelnen Einsatzorte und Bedingungen ausgerichtete Wartungspläne aufgestellt werden und damit die Wartungsprozesse des Herstellers optimiert werden. Damit entsteht für ihn neben dem Verkauf der Maschinen ein neues Geschäftsmodell für intelligente Wartungsleistungen. Das Geschäftsmodell kann durch Vermietung noch erweitert werden. Bei Flugzeugturbinen wird dieses Modell bereits genutzt (z. B. General Electric und Rolls Royce), indem Turbinen nicht mehr mit den Flugzeugen an Fluglinien verkauft werden, sondern im Eigentum der Hersteller verbleiben und lediglich die Nutzung nach Flugstunden bezahlt wird. Die Aggregate selbst werden über das Internet kontinuierlich verfolgt und vom Hersteller die erforderlichen Wartungsmaßnahmen gesteuert. Dieses Geschäftsmodell wird auch als „Build-Own-Operate (BOO)“ bezeichnet. In Abb. 10.6 ist ein praktisches Beispiel einer vorbeugenden Wartung mit dem System des Unternehmens IS Predict GmbH angegeben (IS Predict 2017), das zu Netzwerk der Scheer Gruppe zählt. Die Kennlinien bezeichnen Indikatoren, die das Laufverhalten von vier Motoren einer Lokomotive kennzeichnen. Jeder Indikator komprimiert bereits die Messdaten von mehreren Sensoren. Das selbstlernende System erkennt, wann sich die Indikatoren so verändern, dass eine genauere Beobachtung angebracht ist oder eine sofortige Maßnahme erforderlich wird. In dem Beispiel wurde nicht eingegriffen und der Motor fiel anschließend mit erheblichen Folgeschäden aus.

186

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.6 Predictive Maintenance mit dem KI-System des Unternehmens IS-Predict. (Quelle: IS Predict 2017)

Werden Spezialaggregate nur zu einem geringen Teil in einem Unternehmen genutzt, können sie mehreren Nachfragern über Sharing-Modelle angeboten werden. Dies erfordert, dass die Aggregate mobil sein müssen. Es ist vorstellbar, dass immer mehr Maschinen zu Einsatzorten gebracht werden, um dort ihre Funktionen als Dienstleistung anzubieten, anstatt dass Materialien zu den festen Einsatzorten von Maschinen wandern. Die Koordination von Bedarf und Angebot sowie die zeitliche und örtliche Steuerung der mobilen Einsatzgeräte sind dann eine Dienstleistung, die über eine Internetplattform vermittelt wird. Der Feinheitsgrad der Datenerfassung ist nahezu beliebig filigran. So können pro Anlage, z. B. einer Turbine oder einem Kompressor, 100 bis 200 Messpunkte definiert werden, die Real-Time abgefragt werden. Entsprechend hoch ist dann das zu bearbeitende Datenvolumen. Insgesamt wird die „Smart Factory“ vornehmlich durch Daten und Ereignisse als durch vordefinierte Abläufe getrieben. Eine Vorstufe zur autonomen Fabrik bildet das bereits genannten Manufacturing Execution System (MES), das als eine Schicht zwischen der Fabrik und den darüber liegenden Planungsfunktionen des Y-Modells eine Filterung und Verdichtung von Daten vornimmt. Für die Planung der Smart Factory stehen ebenfalls spezielle Methoden zur Verfügung. Besondere Bedeutung besitzt die digitale Abbildung der Fabrik als digitaler Zwilling. Alle Systeme der realen Fabrik sind digital abgebildet und nutzen die echten Stammdaten (Xu et al., 2018). Durch Zoomfunktionen kann in die Gebäude hineingesehen und beliebige Details dargestellt werden. Damit können Simulationen im Computer durchgeführt und für die Layoutplanung und die Prozessplanung von Fertigung und Transport genutzt werden (vgl. Abb. 10.7). Im laufenden Betrieb verhalten sich reale Fabrik und digitales Abbild synchron und die Fertigung kann ortsunabhängig aktuell verfolgt werden. Durch die Angabe von zusätzlichen Informationen über Mengen, Qualitäten, Auftraggeber mit Hilfe von Augmented

10.1 Die composable Industrieunternehmung

187

Abb. 10.7 Digitale Fabrik als digitaler Zwilling. (Quelle: elenabs)

Reality (AR), sind die Informationen wesentlich reichhaltiger als z. B. bei einer Videoüberwachung. Zu detaillierteren Ausführungen zum Digitalen Zwilling siehe Lim et al. (2021). Die CPS bilden für alle Auswertungen über das Fabriksystem die Datenquelle. Die Sensoren und Bilderkennungssysteme erfassen die Daten, leiten sie an die Edge-Computer und von diesen über die Plattform in die Cloud. Die Daten stehen der Werksleitung für vielfältige Auswertungen, auch mit Unterstützung von KI, zur Verfügung. Zur Gestaltung der Auswertungen und des Cockpits bietet die Low-Code-Funktionalität der Plattform Unterstützung. Die Ingenieure können für die dezentralen Fertigungssegmente die jeweils sinnvollsten Steuerungs- und Auswertungsverfahren individuell selbst zusammenstellen (siehe z. B. mehrere Beiträge in Toro et al., 2021). Insgesamt führen die Automatisierungsmöglichkeiten zu vollautomatisch arbeitenden Fabriken ohne menschlichen Eingriff. Dieses bringt der Begriff „dunkle Fabriken“ plastisch zum Ausdruck, da das Tageslicht für die Maschinen nicht benötigt wird.

10.1.4 Product Lifecycle Management (PLM) Der rechte obere Teil des Y-Modells kennzeichnet die Produktentwicklung sowie die Entwicklung produktnaher Dienstleistungen. Die stärkere Flexibilisierung der Fertigung bis hin zur Losgröße 1 fordert auch eine stärkere Flexibilisierung der Produktentwicklung. Dies bedeutet konkret, dass die Variantenzahl von Erzeugnissen gesteigert werden kann, bis hin zur rein kundenindividuellen Fertigung. Dieses führt zu weitreichenden Konsequenzen. Da Kunden auf ihre Produkte in der Regel nicht lange warten möchten, fordert die Individualisierung, dass die Produktion

188

10

Digitale Branchenkonzepte für das Composable Enterprise

näher an den Standort des Kunden rücken muss. Anders gesprochen, ein individueller Entwurf eines Laufschuhs nutzt wenig, wenn die Produktion in Asien durchgeführt wird und der Kunde Wochen oder Monate auf die Lieferung warten muss. Neue Technologien wie 3D-Druck, bei dem ein Erzeugnis aus einem geometrischen 3D-Modell durch Aufschichtung von Material gefertigt wird, erlauben die sofortige Produktion. Der 3D-Druck erhöht auch die Entwicklungsgeschwindigkeit neuer Produkte durch die schnellere Entwicklung von Prototypen (Rapid Prototyping). Die vertikale Integration von der Produktentwicklung, der Fertigung bis zum Kunden ist dafür die Voraussetzung. Dieses wird durch die Integrationskomponente und die Prozessautomation der Composable Application Platform unterstützt. Neue Produktideen können nicht nur von der eigenen Entwicklungsabteilung generiert werden, sondern auch durch die systematische Einbeziehung von weiteren Mitarbeitern des eigenen Unternehmens sowie Kunden und Lieferanten bis zur gesamten interessierten Welt (Open Innovation). Mit der Plattform-Umgebung und intelligenten Materialien und Maschinen können über die gesamte Lebenszeit jedes einzelnen verkauften Produktes alle Reparaturen, Wartungen, Ersatzteilwechslungen, Qualitätsprüfungen sowie die Einsätze und Einsatzbedingungen automatisch erfasst und gespeichert werden. Aus diesen Daten entsteht ein digitaler Zwilling des Produktes von seiner Entwicklung bis zur Entsorgung bzw. Recycling. Bei der Entwicklung werden mit Simulationen das Produktverhalten analysiert und Vorhersagen getroffen. Dadurch ersetzen virtuelle Prüfstände aufwendige reale Tests. Auch kann die Inbetriebnahme einer Anlage, die vor der Lieferung an den Kunden früher beim Hersteller real vollständig aufgebaut und getestet werden musste, nun mit dem Digitalen Zwilling beim Hersteller virtuell erfolgen. Mit Hilfe des digitalen Lifecycle-Product-Passes werden alle gesetzlich geforderten Daten über den Ressourcenverbrauch und CO2 -Ausstoß über die gesamte Kette der Produktentwicklung über alle Vorproduzenten bis zum Recycling oder zur Entsorgung verfolgt (vgl. Plociennik et al., 2022; Adisorn et al., 2021). Insgesamt führen die Entwicklungen zum Konzept des transparenten Product Lifecycle Managements und führen zu einer großen Datenfülle, die durch Analysetechniken ausgewertet werden kann. Die Analyse dieser Daten kann neben der rechtlich vorgeschriebenen Verfolgbarkeit im Rahmen von Gewährleistungen und Nachweispflichten zum Ressourcenverbrauch vor allem Anregungen für Produktverbesserungen geben. Dabei können die individuellen Produktdaten auf einem Chip im Produkt selbst fortlaufend gespeichert oder vom Hersteller in seiner Datenbank geführt werden. Die Auswertung der Daten durch den Hersteller bringt neue Anregungen für produktnahe Dienstleistungen wie das Predictive Maintenance. Erfasst ein Hersteller die Daten aller von ihm produzierten Maschinen, so kann er Quervergleiche über das Verhalten der Maschinen anstellen. Hat er Wartungsverträge mit seinen Kunden abgeschlossen, so kann er den Wartungsprozess optimieren, indem er bereits vor dem Besuch eines Technikers die erforderlichen Maßnahmen erkennt und den Besuchszeitpunkt bedarfsgerecht festlegt.

10.1 Die composable Industrieunternehmung

189

Eine Weiterentwicklung von Dienstleistungen ist die Übernahme des Betriebs der produzierten Anlagen durch den Hersteller selbst, die als Build-Own-Operate (BOO) bezeichnet wird. Der Hersteller von Maschinen kennt seine Produkte am besten und kann über die PLM-Daten ihr Verhalten in Abhängigkeit aller Einsatzbedingungen analysieren und ihren Einsatz optimieren. Deshalb liegt es nahe, dass er die Systeme beim Kunden oder in eigens von ihm eingerichteten Produktionsstätten selbst betreibt. Der Kunde kauft dann kein Aggregat mehr, sondern erhält und bezahlt eine Dienstleistung nach Inanspruchnahme. Hersteller medizinischer Geräte betreiben ihre Systeme (z. B. Dialysesysteme) in entsprechenden Zentren und verkaufen dann anstelle von Geräten Dienstleistungen wie Erhöhung der Lebensqualität oder gesäubertes Blut. Dieser Trend wird sich weiter fortsetzen und immer mehr Industrieunternehmen werden den Charakter von Dienstleistern annehmen. So verstehen sich Automobilhersteller bereits als Dienstleister für Mobilität und gründen Tochterunternehmen, mit denen sie ihre hergestellten Autos im Rahmen des Carsharings vermieten. Hersteller von Kompressoren verkaufen als Dienstleistung Luftdruck; Hersteller von Messgeräten zur Qualitätssicherung verkaufen Qualitätsgarantien und entscheiden selbst, ob sie diese durch Einsatz von Messgeräten oder durch den Einsatz von Prognoseverfahren der Künstlichen Intelligenz sichern wollen. Diese Vielfalt von neuen Geschäftsmodellen und neuen Prozessen zu gestalten und zu betreiben, erfordert die Agilität eines Composable Industrial Enterprises.

10.1.5 Smart Logistic 10.1.5.1 Schwerpunkte der Veränderungen in der Logistik Auch der linke obere Teil des Y-Modells, die Vertriebs- und Beschaffungslogistik sowie die Produktionsplanung (Supply Chain), werden stark verändert. Dieses betrifft vor allem die nach außen gerichteten Prozesse zu den Kunden, Lieferanten und Partnern. Zunächst kann ein Kunde über vielfältige Kanäle wie Standardcomputer, Laptops oder Smartphones einen Auftrag erteilen, stornieren oder ändern. Das Auftragserfassungs- und -verfolgungssystem des Herstellers muss sich gegenüber den unterschiedlichen Zugangskanälen transparent verhalten, es muss Omni-Channel-fähig sein. Alle Kanäle müssen durcheinander benutzbar sein, d. h., der Kunde kann z. B. den Auftrag mit dem Standardcomputer über das Internet erteilen, ihn dann aber über sein Smartphone ändern oder stornieren. Technisch bedeutet dieses, dass die Benutzeroberflächen der Anwendungen je nach Medium automatisch angepasst werden müssen. Der leichte Zugang des Kunden zum Hersteller führt zusammen mit der Individualisierung der Produkte zu einem verstärkten Änderungsanfall. Der Kunde kann dann bis kurz vor dem Beginn eines Fertigungsschrittes, z. B. der Lackierung der Karosserie eines Autos, die Farbe gegenüber seiner ursprünglichen Produktdefinition ändern. Die Individualisierung der Produkte durch höhere Variantenzahl bis zur kundenindividuellen Fertigung erhöht tendenziell die Zahl der Zulieferer und verringert die Ferti-

190

10

Digitale Branchenkonzepte für das Composable Enterprise

gungstiefe der Unternehmen. Dies bedeutet, dass das Logistiknetzwerk des Unternehmens schneller reagieren muss. Neue Lieferanten für Extrawünsche von Kunden müssen schnell identifiziert werden und sofort in das Netzwerk eingebunden werden. Störungen innerhalb der Supply Chain müssen frühzeitig erkannt und durch schnelle Maßnahmen abgefangen werden. Die Abrufe von Vorprodukten und Materialien werden kleinteiliger. Das gesamte Netzwerk muss für alle Beteiligten in jedem Augenblick transparent sein. Erst wenn die Flexibilität von allen drei Funktionen Auftragssteuerung, Produktentwicklung und Fertigung erreicht ist, kann sie dem Kunden den Nutzen höherer Automatisierung zeigen. Die gegenwärtig anzutreffenden Informationsbeziehungen von Abrufen zwischen direktem Zulieferer und Abnehmer reichen dann nicht aus. Vielmehr muss das gesamte Supply-Chain-Netzwerk transparent sein.

10.1.5.2 Ein Beispiel für die Anwendung von Blockchain in der Logistik Der Einsatz von Blockchain im Manufacturing Bereich wird in Forschung, aber auch in ersten Anwendungen behandelt (siehe z. B. Kurniawan et al., 2021, S. 337 ff.). In der Logistik bietet besonders die Sicherung von Verantwortlichkeiten innerhalb einer Logistikkette ein interessantes Anwendungsgebiet. Dazu wird das Beispiel zu „Complex Event Processing (CEP)“ wieder aufgenommen (siehe Gliederungspunkt 6.4.). Ein Hersteller bestellt bei einem verbundenen Transportunternehmen die Beförderung von Waren aus einem Lager zu dem Stammsitz des Unternehmens. Da beide Unternehmen eng zusammenarbeiten und die Waren sowohl wertvoll als auch empfindlich sind, haben sie eine private Blockchain-Lösung aufgebaut (vgl. Abb. 10.8).

Abb. 10.8 Logistikablauf über Blockchain

10.1 Die composable Industrieunternehmung

191

Alle Daten und Transaktionen werden in der Blockchain erfasst und mit Hilfe von Smart Contracts ausgeführt. In Abb. 10.8 bezeichnen einfache Linien den Kontrollfluss des Prozesses und Pfeilstriche Datenflüsse von und zur Blockchain. Beide Partner haben transparenten Zugriff auf die Blockchain. Der Hersteller sendet zunächst die Bestellung über die Blockchain als Transaktion an das Transportunternehmen. Die dazu benötigten Produktspezifikationen entnimmt er der Blockchain, in der die Produktdaten gespeichert sind. Das Transportunternehmen verwaltet seine Fahrzeugdaten ebenfalls in der Blockchain und prüft, ob ein geeignetes Fahrzeug verfügbar ist. Ist dies nicht der Fall, informiert er den Hersteller und der Vorgang ist erst einmal zu Ende. Im positiven Fall beginnt der Transporteur mit dem Beladen und sendet die Ladedaten an die Blockchain. Während der Fahrt werden Ereignisse wie Temperaturüberschreitungen der Waren usw. der Blockchain gemeldet. Bei einer Überschreitung wird ein Alarm von der Blockchain ausgelöst und die vom Hersteller für den Fall vorgesehene Bearbeitung ausgelöst und der Blockchain mitgeteilt. Nach Ankunft wird der Wagen entladen, der Status des Wagens aktualisiert und der Hersteller übernimmt die Funktion „Wareneingang“ mit Kontrolle und Erfassung. Der Vorteil dieser Bearbeitung ist, dass beide Parteien ständig transparent über den Status des Prozesses informiert und alle Bewegungen unauslöschlich dokumentiert sind. Streitigkeiten über Schuldfragen bei ungeplanten Abweichungen, wie falsche Warenauswahl oder Beschädigungen, sind deshalb nahezu ausgeschlossen. Das Beispiel zeigt einen vereinfachten Ausschnitt eines Logistikprozesses. Die Grundgedanken können aber leicht auf komplexere Szenarien angewendet werden. So könnten die Automobilhersteller mit ihren Zulieferern und Transportunternehmen eine private Blockchain für ihre „just in time“ Logistikketten einrichten, um die synchrone Fertigung zu organisieren. In dem im nächsten Abschnitt behandelten Projekt RAN wird ein solcher Ansatz über eine traditionelle zentrale Datenbank angestrebt. Es liegt nahe, dieses organisatorische Konzept mit einer Blockchain-Architektur zu unterlegen. Dieses würde Transparenz und Sicherheit weiter erhöhen. Da in der Application Composition Platform Schnittstellen zu externen Architekturen vorgesehen sind, können Blockchain-Anwendungen einbezogen werden. In dem Projekt Catena-X im Abschn. 10.1.6 werden ebenfalls Grundgedanken von Blockchain übernommen, aber bisher nicht über eine Blockchain-Architektur behandelt.

10.1.5.3 Das Konzept RAN zur Transparenz der Lieferketten In dem vom Bundesministerium für Wirtschaft (BMWi) ab Juli 2010 geförderten Forschungsprojekt RFID-based Automotive Network (RAN) ist durch Einsatz einer zentralen virtuellen Datenbank und RFID-Technologien prototypenhaft ein transparentes Zuliefernetzwerk für die Automobilindustrie entwickelt worden. Dieses wird von einigen Beteiligten auch real eingeführt (Lepratti et al., 2014). In Abb. 10.9 und 10.10 ist das RANKonzept dargestellt. Abb. 10.9 zeigt zunächst die bestehende Lösung, bei der höchstens die direkten Partner durch Electronic-Data-Interchange (EDI)-Informationsbeziehungen verbunden sind. Der

192

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.9 Bisheriger Informationsfluss im Logistiknetzwerk der Automobilindustrie. (Quelle: Lepratti et al., 2014, S. 21)

Abb. 10.10 Vision des transparenten Informationsflusses durch Einsatz von RFID-Techniken und einer zentralen virtuellen Datenbank. (Quelle: Lepratti et al., 2014, S. 22)

OEM (Automobilhersteller) verfügt damit über keine Real-Time-Informationen, wenn innerhalb der Lieferkette eine Verzögerung auftritt. In Abb. 10.10 ist die Lösung des RANProjektes dargestellt. Hier sind alle Partner über eine (virtuelle) zentrale Datenbank mit-

10.1 Die composable Industrieunternehmung

193

einander verbunden und alle Partner verfügen damit über Real-Time-Informationen über den Zustand des Logistiknetzwerkes. Die Materialbewegungen werden dabei automatisch von RFID-Scannern erfasst und an die Datenbank weitergegeben. Ebenso werden Störungen sofort übermittelt. Die Qualität der Materialien wird durch Sensoren überwacht und kontrolliert. Unerwünschte Wertüberschreitungen werden sofort übertragen. Grundlage für die Entwicklung des Konzeptes ist die Kenntnis der detaillierten Logistikprozesse. Diese wurden von den Partnern mit der ARIS-EPK-Methode modelliert.

10.1.6 CATENA-X und MANUFACTURING-X: Strategische Zukunftsprojekte für die Industrie Die Entwicklungen in Fertigung, Produktentwicklung und Logistik durch Automatisierung, Standardisierung, Vernetzung, Digitale Zwillinge usw. führen in ihrer Zusammenwirkung zu neuen Strukturen in Industrieunternehmen. Wegen der großen Bedeutung der Industrie für die deutsche Volkswirtschaft sind in den Jahren ab 2010 eine Reihe staatlich geförderter Forschungsprojekte unter intensiver Beteiligung von Unternehmen und Verbänden durchgeführt worden, deren Ergebnisse nunmehr mit den Bezeichnungen CATENA-X und perspektivisch MANUFAKTURING-X eine Erweiterung und Anwendung erfahren. Das Projekt RAN hat konzeptionelle Vorarbeiten für die Vernetzung der Partner einer Supply Chain in der Automobilindustrie erarbeitet. In dem Programm „Plattform Industrie 4.0“ wurde mit der Verwaltungsschale (oder auch AAS = Asset Administration Shell) ein Konzept zur Standardisierung von Datenformaten entwickelt, mit der Informationen zu einem industriellen Objekt (Maschine, Baugruppe, Komponente) erfasst werden. Aus dem Projekt GAIA-X werden die Ergebnisse für eine sichere und vernetzte Dateninfrastruktur für CATENA-X übernommen. In dem Programm CATENA-X werden diese Ergebnisse zur Entwicklung eines Datenraums für die Automobilindustrie mit ihrer Zulieferindustrie zusammengeführt und erweitert. An dem Projekt arbeiten über 100 Unternehmen aus Industrie und IT mit. Über die Supply Chain, Produktionsprozesse und den Ressourcenverbrauch wird ein offenes kollaboratives Datenökosystem geschaffen, auf das alle Beteiligten OEMs, Zulieferer bis Recycler zugreifen können. Die einzelnen Datenbestände der Beteiligten werden somit zu einem Gesamtsystem föderiert. Die Datensouveränität der Beteiligten bleibt erhalten, sie werden aber durch einen geregelten Austausch miteinander verbunden. Damit besteht hohe Transparenz. So können Qualitäts- und Terminprobleme innerhalb des Netzwerkes schnell erkannt und in ihren Auswirkungen analysiert werden. Wegen der Dominanz der wenigen großen Automobilhersteller (OEMs) ist auch ein Druck zur Standardisierung der Daten gegeben.

194

10

Digitale Branchenkonzepte für das Composable Enterprise

Insgesamt können mit dem Konzept die Herausforderungen der Automobilbranche zur Dekarbonisierung, Rückverfolgbarkeit von Materialien des ab 2023 geltenden Lieferkettengesetzes und die Kreislaufwirtschaft angenommen und umgesetzt werden. Um die gesamte Wertschöpfungskette für eine Kreislaufwirtschaft nutzen zu können und auch die Ressourcenbilanz, nicht nur CO2 , sondern auch Wasser, Energie usw. eines Autos aufstellen zu können, bietet sich das Konzept des digitalen Produktpasses an. Wenn für jede Komponente in der Lieferkette der Ressourcenverbrauch erfasst wird, z. B. in eine Blockchain eingetragen wird, können zu jedem Zeitpunkt die angefallenen Ressourcenverbräuche aus den Vorprodukten hinzuaddiert werden und zu dem digitalen Produktpass der Komponente konsolidiert werden. Dieses gilt dann auch für das Endprodukt, das gesamte Auto. Das Projekt ist 2020 gestartet und bereits fortgeschritten. Nicht alle beteiligten mittelständischen Zulieferer sind begeistert, weil sie die Transparenz gegenüber den OEMs befürchten und den Nutzen auch eher bei diesen sehen. Auf der anderen Seite besitzen sie den Vorteil der Transparenz auch gegenüber ihren Zulieferanten und schließlich hilft es der gesamten Industrie im globalen Wettbewerb. Neben dem Schwerpunkt Logistik soll später in dem Projekt auch die Fertigung und Produktentwicklung einbezogen werden. Dann wäre das Y-Modell geschlossen. Es ist geplant, den Ansatz von CATENA-X in dem Programm MANUFACTURINGX auf alle Industriezweige auszuweiten. Damit findet nicht nur eine vertikale Integration einer Industrie statt, sondern auch horizontal zwischen den Industriezweigen. Viele Industriezweige wachsen immer mehr zusammen. So ist z. B. die Halbleiterindustrie eine Zulieferindustrie für fast alle anderen Industrien. Es ist aber zum jetzigen Zeitpunkt die staatliche Anschubfinanzierung noch nicht sichergestellt. Da aber bereits starke Protagonisten aus IT, Verbänden und Industrieunternehmen ihre Unterstützung zugesagt haben, ist auch bei diesem Projekt eine gute Realisierungschance gegeben.

10.1.7 Vorgehensweisen zur Einführung des composable Industrieunternehmens Ein Industrieunternehmen, das sich in Richtung des composable Industrieunternehmens und damit auch Industrie 4.0 entwickeln will, kann unterschiedliche Strategien verfolgen. Hierzu werden in Abb. 10.11 einige Alternativen entwickelt und bewertet. Das grundsätzliche Vorgehen kann auch für Unternehmen anderer Wirtschaftszweige Anregungen geben. Die Vorgehensweisen werden in Abb. 10.11 auf der Abszisse danach eingeordnet, wie viel Investment für ihre Realisierung erforderlich ist. Die Höhe des Investments steht auch für das Ausmaß der Komplexität sowie des benötigten zeitlichen Aufwandes. Auf der Ordinate wird angegeben, wie weit das Ziel einer vollständigen Erfüllung der Vision von I4.0 erreicht werden kann.

10.1 Die composable Industrieunternehmung

195

Abb. 10.11 Strategische Vorgehensweisen für I4.0

Strategie 1: Blue-Ocean-Strategie: Organisatorische Veränderungen durch Dezentralisierung, Plattform, Software, Cloud, Edge Bei der Blue-Ocean-Strategie Nr. 1 in Abb. 10.11 wird eine disruptive Innovation angestrebt (vgl. Kim & Mauborgne, 2004). Dies bedeutet, dass mit dem Bestehenden völlig gebrochen wird und quasi auf der grünen Wiese ein neues Unternehmen mit neuem Businessmodell gegründet wird. Beispiel dafür kann das Konzept des visionären Google-Autos als Idee sein. Gegenwärtig steht ein PKW 95 % seiner Zeit still und wird nur zu 5 % gefahren. Beim Google-Auto soll dieses Verhältnis umgekehrt werden: Es soll 95 % der Zeit gefahren werden und nur 5 % ruhen. Dies führt zu der Verbindung von Carsharing und fahrerloser Bedienung, um ein am Ziel angekommenes Fahrzeug sofort selbstständig zum nächsten Benutzer zu führen. Anstelle des Eigentums an einem Auto tritt das Prinzip des Zugangs zur Mobilität. Von Google wird ausdrücklich das Ziel „10 x“ propagiert, d. h. Google strebt mit einer Innovation keine graduelle Verbesserung an, sondern sie soll zehnmal besser sein als das bestehende Konzept. Die Gründung des Unternehmens Tesla kann ebenfalls einer konkreten Blue-OceanStrategie zugeordnet werden. Hier sind alle Funktionen des Fahrzeugs neu durchdacht, ein internetbasiertes Vertriebskonzept entwickelt und eine eigene Elektro-Ladeorganisation aufgebaut worden. Das Mobilitätskonzept von Uber bricht mit dem Konzept eines kommerziellen Taxidienstes und nutzt damit das Konzept einer grenzkostenlosen Dienstleistung, während z. B. das System MyTaxi lediglich eine Digitalisierung der Taxizentrale darstellt und eher eine kontinuierliche Innovation ist. Disruptive Innovationen sind häufig mit einem hohen Kapitaleinsatz verbunden. Es steht von vornherein fest, dass erst nach mehreren Jahren ein Break-even erreicht werden kann. Die Finanzierung kann deshalb entweder aus einem sehr gewinnträchtigen unab-

196

10

Digitale Branchenkonzepte für das Composable Enterprise

hängigen Geschäftszweig erfolgen (Google-Modell) oder von dritten Investoren (TeslaModell) getätigt werden. In Deutschland ist gegenüber den USA die Blue-Ocean-Strategie weniger zu erkennen. Dieses mag daran liegen, dass die deutsche Industrie mit ihren traditionellen Businessmodellen (noch) sehr erfolgreich ist und deshalb aufgrund des Investor’s Dilemma-Effektes disruptive Konzepte scheut. Auch fehlt gegenüber den USA die hohe Bereitschaft zu sehr riskanten Investitionen durch Venture-Capital-Gesellschaften und vermögende Business Angels. Die deutsche Automobilindustrie verfolgt eher einen gleitenden Übergang zur Elektromobilität, wenn sich auch das Engagement in den letzten Jahren wesentlich beschleunigt hat. In Abb. 10.11 wird die disruptive Blue-Ocean-Strategie 1 durch einen hohen Kapitaleinsatz und einen hohen Realisierungsgrad für die Vision gekennzeichnet. Strategie 2: Lösung herkömmlicher Probleme mit I4.0-Technologien Einzelne Lösungen können für bekannte Probleme durch I4.0-Techniken neugestaltet werden. Hier gibt es bereits vielfältige Beispiele. Ein Maschinenbauer verringert durch die mobile Abfrage der Materialbestände vor Produktions- und Montagestationen die innerbetrieblichen Materialtransporte (Milkruns), indem von festen Tourenplänen auf bedarfsgesteuerte Fahrten übergegangen wird und Leerfahrten vermieden werden. Durch Einsatz eines 3D-Scanners verbessert ein Hersteller von Landmaschinen die Qualität bei der Verbindung von Karosserie mit dem Chassis (sogenannte Hochzeit) und vermeidet zeitraubende Nacharbeiten. Ein Hersteller von Schrauben verbessert sein Kanban-System, indem in die KanbanBehälter Sensoren und Kameras eingebaut werden, sodass die Bestände ohne menschliche Sichtkontrolle kontinuierlich erfasst werden. Ein Automobilzulieferer verbessert den Wareneingangsprozess durch Einsatz von RFID-Techniken, indem die Zählkontrolle und Lagerung automatisiert werden. In Abb. 10.11 sind diese Ansätze durch einen vergleichsweise überschaubaren Kapitaleinsatz, aber wegen ihrer Spezialisierung mit nur einem geringen Potenzial für die Vision charakterisiert. Strategie 3: Isolierte Musterlösungen in der Fertigung Ein Automobilzulieferer richtet eine neue Produktionsstraße ein, die quasi als Prototyp neben den bestehenden Linien betrieben wird. Alle Bearbeitungsstationen sind mit dem Internet verbunden und erfüllen die Kriterien von CPS. Über RFID-Techniken steuert sich der Materialfluss weitgehend selbst. Zwischen den Produktionssystemen besteht im Störungsfall eine hohe Substitutionsmöglichkeit. Durch Sensoren werden Material und Anlagen in Real-Time überwacht und vorausschauend gewartet (vgl. Lepratti et al., 2014). Dieses Beispiel ist für sich zwar bereits eindrucksvoll, hat aber für das gesamte Unternehmen nur einen Pilotcharakter.

10.1 Die composable Industrieunternehmung

197

Ein mittelständisches Gießereiunternehmen führt für einen Fertigungsbereich ein Manufacturing Execution System (MES) ein, um die Betriebsdatenerfassung (BDE) mit der Steuerungsebene zu verbinden und einen Datenfilter zu den darüber liegenden Planungssystemen zu bilden. Obwohl lediglich Teilaspekte verfolgt werden, erfordert die Strategie 3 einen höheren Kapitaleinsatz und kann Ausgangspunkt für weitere Schritte sein. Allerdings wird nur die Fabrikorganisation betrachtet, sodass neue Businessmodelle kaum generiert werden. Strategie 4: PLM und Open Innovation Ein Motorenhersteller richtet eine Datenbank für ein Produktgedächtnis im Rahmen des PLM ein. Gleichzeitig organisiert er den Entwicklungsbereich neu. Neben den Konstruktionsdaten werden auch die Fertigungsstücklisten und Arbeitspläne in einer neuen Produktdatenbank organisiert und damit dem ERP-System entzogen. Insgesamt deutet sich dadurch eine neue Architektur für die Informationssysteme des Unternehmens an. Die Erzeugung und Verwaltung produktbezogener Daten stehen im Vordergrund. Damit wird dem Trend zu höherer Variantenvielfalt und Individualisierung der Produkte Rechnung getragen. Die logistischen Funktionen aus Vertrieb und Beschaffung sowie Produktionsplanung sind dann Anwendungen, die auf die Produktdatenbank zugreifen, verwalten sie im Gegensatz zu den heutigen Enterprise Resource Planning (ERP)-Systemen aber nicht mehr selbst. Ein Spielzeughersteller bezieht seine Kunden in die Produktentwicklung mit ein, indem er Belohnungen für gute Produktideen aussetzt. Die Vorschläge können per Internet mittels eines einfachen CAD-Systems beschrieben und eingereicht werden. In Abb. 10.11 ist das erste Beispiel zum Maßstab genommen worden. Es führt zu einer durchgreifenden Flexibilisierung der Produktgestaltung und eröffnet neue Businessmodelle. Allerdings ist ein hoher Kapitalbedarf für die organisatorische und technische Neugestaltung des Entwicklungsprozesses erforderlich. Insgesamt wird die Strategie 4 genauso wie Strategie 3 eingeordnet. Strategie 5: Logistik Die durchgängige Neuorganisation des Supply-Chain-Managements erfordert auch die Einbeziehung der Kunden und Lieferanten, gegebenenfalls über mehrere Stufen hinweg, wie es oben mit dem RAN-Projekt gezeigt wurde. Aus Sicht eines einzelnen Unternehmens können aber bereits durch die Integration der direkten Zulieferer und Abnehmer sowie der Transportsysteme ein Flexibilitätsgewinn sowie Kosteneinsparungen erzielt werden. Der durchgängige Einsatz von elektronischen Erfassungstechniken sowie die Real-TimeVerfolgung der Transportstati informiert frühzeitig über die zu erwartenden Ankunftszeiten sowie die Inhalte nach Art, Abmessungen und Menge. Sensoren erfassen auf dem Transportweg besondere Vorkommnisse, wie außergewöhnliche Temperaturen oder Erschütterungen, die frühzeitig anzeigen, dass eine sorgfältige individuelle Eingangskontrolle erforderlich ist. Das RFID-gesteuerte Hofmanagement regelt den Transport vom

198

10

Digitale Branchenkonzepte für das Composable Enterprise

Eingangstor bis zur Ankunft am Lager. Dazu gehören die Avisierung des Transportmittels und die Zuweisung des Lagerortes. Ein Hersteller von technischen Konsumartikeln richtet neben seinen Verkaufskanälen zum Handel auch einen Direktvertrieb über einen E-Shop ein. Die Einrichtung eines Omni-Channel-Zugangs für die Kunden zu Auftragserstellung und -verfolgung ist ein hohes technisches Integrationsproblem. Weiter muss die Bestandsführung gegenüber der bisherigen Tagesaktualität nun sekundenaktuell sein. Der Versand ist kleinteilig und muss über neue Logistikdienstleister abgewickelt werden. Während das erste Beispiel mehr der Verbesserung der internen Logistikprozesse dient, eröffnet das zweite Beispiel auch ein neues Businessmodell. Insgesamt liegt der Investitionsbetrag im mittleren Bereich und die Strategie eröffnet wegen ihres punktuellen Ansatzes mittlere Entwicklungsperspektiven. Strategie 6: Anbieten von I4.0-Beratungsleistungen Industrieunternehmen, die als Pioniere I4.0-Erfahrungen mit neuen Technologien und Organisationsformen gesammelt haben, können diese an andere Unternehmen weitergeben. Dazu können eigene Consulting-Unternehmen gegründet werden. Dieses kann z. B. durch Ausgründung der IT-Abteilung geschehen, die ihre technischen und fachlichen Leistungen auf dem Markt anbietet. Das Costcenter IT wird dann zum Profitcenter. Ein weiterer Vorteil besteht darin, dass das Unternehmen neuen Kundenanforderungen gegenübersteht und damit eine höhere Innovationsgeschwindigkeit notwendig wird, die auch dem Stammunternehmen zugutekommt. Diese Entwicklung ist bereits deutlich zu beobachten. Im Kleinen werden solche Unternehmen z. B. Spezialisten für RFID-Techniken oder Materialflusssteuerung. Im Großen können beachtliche Dienstleister für die Gestaltung umfassender I4.0-Lösungen entstehen, wenn deutsche industrielle Weltmarktführer aus der Automobilindustrie oder dem Maschinenbau ihre mehrere Hundert oder sogar mehrere Tausend IT- und Fertigungsspezialisten in neue Dienstleistungen einbringen. Hierdurch kann I4.0 als Dienstleistung auch zu einem Exporterfolg aus Deutschland werden. Die Ausgründung ist ein organisatorisches und ein Investitionsproblem, da IT-Mitarbeiter eingestellt oder umgeschult werden müssen und auch Anlaufkosten auftreten. In Abb. 10.11 sind der Strategie 6 mittlere Investitionsausgaben, aber ein höheres Potenzial zur Erreichung umfassender I4.0-Konzepte zugeordnet. Strategie 7: Produktbezogene Dienstleistungen Die Verbindung der produzierten komplexen Produkte wie Werkzeug- oder Druckmaschinen mit dem Internet führt zu einem Informationsgewinn über das weltweite Verhalten dieser Produkte unter unterschiedlichen Einsatzbedingungen. Unternehmen haben häufig mehrere Tausend oder sogar Zehntausend Einheiten ihrer Produkte im aktiven Kundeneinsatz. Dieses Wissen kann von den Industrieunternehmen genutzt werden, um ihren Kunden Wartungsverträge zu besonders günstigen Konditionen anzubieten.

10.1 Die composable Industrieunternehmung

199

Allerdings sind z. Zt. noch erhebliche Schwierigkeiten zu überwinden. Erhält der Hersteller Maschinendaten von seinen Kunden, so muss er sich an die Formate, die seine Kunden verwenden, anpassen und sie bei der Benutzung durch seine eigenen Systeme entsprechend umformatieren. (Umgekehrt muss ein Industrieunternehmen, das für seine eigene Fertigung Maschinendaten von den Lieferanten angeboten bekommt, diese in seiner Datenorganisation umformatieren.) Es liegt auf der Hand, dass bei der Vielzahl der Datenarten und der unterschiedlichen Kunden und Lieferanten Datenstandards dringend erforderlich sind. Erste Ansätze liefert der UMCM (Universal Machine Connectivity for MES) vom MES D.A.CH Verband und die Architektur der OPCUA-Foundation. Allerdings sind weitere Arbeiten auf internationaler Ebene erforderlich. Wahrscheinlich werden sich am Ende Industriestandards durchsetzen, die von internationalen Marktführern aus der Informationstechnik oder der Ausrüsterindustrie getrieben werden. Auch Probleme der Datensicherheit sind zu lösen. Wenn Maschinen offene Schnittstellen zu ihren Steuerungen anbieten, so sind sie im Prinzip in beide Richtungen zu verwenden. Um hier Missbrauch – bis hin zu Sabotage – auszuschließen (man erinnere sich noch an die Cyberattacke Stuxnet in einem iranischen Atomkraftwerk) müssen komplexe Sicherungsmaßnahmen ergriffen werden. Für das Datenverwaltungskonzept sowie die darauf aufbauenden Dienstleistungen muss also eine komplexe weltweite Infrastruktur aufgebaut werden. In Abb. 10.11 wird deshalb ein mittlerer Investitionsbetrag angesetzt. Da über das Verhalten der Aggregate auch vielfältige Informationen, z. B. über ihre Beschäftigungssituation aber auch über Verbesserungsmöglichkeiten der Produkte entstehen, wird dieser Strategie ein gutes Entwicklungspotenzial zugeordnet. Strategie 8: BOO BOO beschreibt den Übergang des Industrieunternehmens zum Dienstleister. Es verkauft seine Produkte nicht mehr dem Kunden, sondern lediglich deren Funktionalität als Dienstleistung mit Abrechnung nach Inanspruchnahme. Ein Hersteller von Landmaschinen wird zum Anbieter von Erntedienstleistungen. Seine Kernkompetenz liegt in den informationstechnisch vernetzten Erntemaschinen mit der Logistik, z. B. zu Transportfahrzeugen für die geernteten Produkte. Im Bereich Smart Farming ist die Automatisierung weiter fortgeschritten als in der Verkehrssteuerung. Grund dafür ist, dass keine administrativen Hindernisse, wie die Verkehrsordnung, auf den Feldern bestehen und deshalb satellitengesteuerte fahrerlose Systeme leichter eingesetzt werden können. Bei Nutzung aller technischen und organisatorischen Möglichkeiten ergeben sich lohnende Businessmodelle. Der Hersteller entscheidet, wann und wie er seine Mähdrescher auf den Feldern seiner Kunden einsetzt. Neben der Optimierung dieser Leistung, auf Basis seiner Kenntnisse über seine Aggregate und den Einsatzbedingungen, kann er sogar selbst Flächen anmieten und die landwirtschaftlichen Produkte vermarkten. Über die per Internet weltweit verfügbaren Informationen über Klima und Ernteaussichten nach Men-

200

10

Digitale Branchenkonzepte für das Composable Enterprise

ge und Qualität kann er Prognosen über Preisentwicklungen anstellen. Daraus können neue Businessmodelle entwickelt werden. Auch in der Medizintechnik ergeben sich ähnliche Möglichkeiten. Durch die automatische Speicherung von (anonymen) Untersuchungsergebnissen in den Speichern medizinischer Geräte bestehen für den Hersteller Auswertungsmöglichkeiten zur Mustererkennung von Krankheiten, die den einzelnen Ärzten nicht zugänglich sind. Ein Paradigmenwechsel von Analysetechniken im Zusammenhang mit Deep Learning ist, dass hypothesenfrei analysiert wird. Dieses führt dazu, dass auch fachfremde Analysten wie Informatiker überraschende medizinische Zusammenhänge erkennen können. Daraus lassen sich wieder neue Businessmodelle ableiten, indem Hersteller medizinischer Geräte durch Nutzung der KI-Modelle zusammen mit Ärzten Diagnoseleistungen anbieten. In Abb. 10.11 wird der BOO-Strategie wegen des konsequenten Wechsels des Businessmodells und des Übergangs von Verkaufserlösen zu leistungsabhängigen Mieteinnahmen ein größerer Investitionsbetrag zugeordnet, der aber auch eine große Entwicklungsperspektive eröffnet. Die Verfolgung der vorgestellten einzelnen Strategien führt nicht automatisch zu einem Gesamtkonzept für die composable Unternehmung. Deshalb sollte eine Arbeitsgruppe des Unternehmens, unter Beteiligung externer Spezialisten, eine Unternehmensvision entwickeln, indem gefragt wird, welche Produkte das Unternehmen in Zukunft anbieten wird, wie die Erlöse zu erzielen sein werden, welche Kundengruppen zu bedienen sind, welche Ressourcen benötigt werden, kurz, wie das Businessmodell sein wird. In dieses Businessmodell können dann einzelne Projekte in eine Roadmap eingeordnet werden.

10.1.8 Roadmap zur composable Industrieunternehmung Zu der Roadmap gehören auch Entscheidungen über die Akquisition von Unternehmen, um nicht vorhandenes Know-how zu erhalten. Ein Hersteller von Elektro-Schaltkästen, der sich bisher vornehmlich als Produzent betrachtet hat, will sich künftig als Anbieter von Gebäudesicherheit und -steuerung positionieren und kauft deshalb ein Dienstleistungsunternehmen als Keimzelle auf. Oder ein Unternehmen, das bisher seine Stärke in der hohen Kompetenz seiner Entwicklungs- und Fertigungsingenieure gesehen hat, erkennt, dass in der Zukunft mehr Softwareingenieure benötigt werden und akquiriert ein Softwarehaus. Eine wichtige Organisationsfrage ist auch, ob neue Geschäftsfelder in der bestehenden Organisation des Unternehmens ausgeführt werden sollen oder dafür ein neues Unternehmen, das mehr wie ein Start-Up-Unternehmen agiert, gegründet werden soll. Durch die Ausgründung wird erreicht, dass die neuen Ansätze ohne Rücksicht auf die Vergangenheit des Unternehmens verfolgt werden und Beharrungseffekte des Innovator’s DilemmaPhänomens vermieden werden. Anregungen für die Bildung von Prioritäten der Implementierungsschritte können Reifegraddiskussionen geben. Ist das Unternehmen bei einem Gebiet gegenüber der Konkur-

10.1 Die composable Industrieunternehmung

201

renz bereits weit fortgeschritten, lohnt es sich nicht, hier noch massiv weiter zu investieren, wenn das Unternehmen in einem anderen Gebiet gegenüber der Konkurrenz im Nachteil ist. Dann sollte man lieber den Wettbewerbsnachteil gegenüber der Konkurrenz verringern. Bei der Modularisierung von Industrieunternehmen werden in die dezentralen Einheiten Planungs- und Steuerungsfunktionen verlagert, die vorher zentral zugeordnet waren. Dieses gilt auch für die Verwaltung von Stammdaten zu Ressourcen, Stücklisten und Arbeitsplänen. Da aber übergreifende Auswertungen sinnvoll sind, müssen die Datenbestände zusammengeführt werden. Dazu eignet sich ein Federated Konzept, das einerseits die Datensouveränität der dezentralen Einheiten unterstützt, aber auch den Datenverkehr zwischen den Einheiten regelt. Dieses kann mit dem API und dem API-ManagementKonzept der Application Composition Platform gelöst werden. Insbesondere in den fertigungsnahen Anwendungen muss die Software jederzeit ansprechbar (responsable) sein und Eingriffe in laufende Prozesse ermöglichen, also weitgehend ereignisgetrieben sein. Die hierarchischen Architekturen werden aufgehoben. Alle Prozesse greifen ineinander. Die traditionellen Pyramidenmodelle von der technischen Feldebene bis zur Unternehmensspitze verlieren ihre Bedeutung: Die Organisation des composable Industriebetriebes wird flach. Hierzu bietet die Application Composition Platform die passende Grundlage. Das Y-Modell dient aber weiter zum logischen Verständnis der Prozesse des gesamten Unternehmens und der Prozesse in den dezentralen Modulen. Obwohl die Organisation der Industrieunternehmen von neuen Produktions- und Informationstechniken getrieben wird, sind menschzentrierte Konzepte weiterhin von Bedeutung. Insbesondere Lean Management, Teambildung und emotionales Engagement der Mitarbeiter bleiben auch bei einer hochautomatisierten Fertigung wichtige Erfolgsfaktoren. Ausbildung und die Bereitschaft zum lebenslangen Lernen der Mitarbeiter sind gerade bei turbulenten Entwicklungen ein wichtiger Erfolgsfaktor. Hier bieten digitale Lernplattformen und die Einbettung von Lerninhalten in die Anwendungsprozesse wichtige Unterstützungen. Ein Ziel des composable Industrieunternehmens ist es deshalb, eine Synthese aus Nutzung der Informationstechnik und klassischen menschzentrierten Organisationsformen herzustellen. Die Vielfalt der Entwicklungen und ihre Komplexitäten erfordern eine modulare Organisation. Ein Modul ist jeweils für Planung und Steuerung einer relativ homogenen Untermenge verantwortlich. Damit wird die Komplexität innerhalb der einzelnen Module gegenüber einem monolithisch-zentralen Ansatz reduziert. Gleichzeitig wird unternehmerische Verantwortung zur Optimierung der Prozesse innerhalb der Module gestärkt. Diese Entwicklungen zeigen den Weg zu einem Composable Industrial Enterprise.

202

10

Digitale Branchenkonzepte für das Composable Enterprise

10.2 Das Composable-Consulting-Unternehmen Da Beratungsunternehmen informationsnahe Dienstleistungen erzeugen, sind sie ein naheliegender Kandidat für die digitale Transformation zu einem Composable Enterprise. Es werden die Herausforderungen und Chancen von Innovationstreibern herausgearbeitet, um Entwicklungsrichtungen für ein zukunftsfähiges Consulting-Unternehmen zu erkennen. Das traditionelle Basisgeschäft wird weniger intensiv behandelt. Der Markt für Consulting-Leistungen ist heterogen und umfasst u. a. Rechtsberatung, Steuerberatung, Wirtschaftsprüfung, Unternehmensberatung und IT-Beratung. Im Folgenden stehen die Unternehmens- und IT-Beratung im Vordergrund. Trotzdem sind viele Ausführungen auf andere Beratungsunternehmen übertragbar und geben generelle Anregungen für Dienstleistungsunternehmen. Die Digitalisierung treibt zwei Veränderungsrichtungen. Einmal verändern sich die Prozesse der Kunden von Beratungsunternehmen und fordern dazu angepasste neue Beratungsinhalte. Zum anderen werden die Beratungsmethoden und Arbeitsergebnisse der Berater selbst zunehmend digitalisiert. Beide Entwicklungen verstärken sich gegenseitig und begründen den Transformationsbedarf. Die Leistungsprozesse in einem Consulting-Unternehmen sind häufig in einer Matrixorganisation organisiert (vgl. Abb. 10.12). Um die fachlichen Probleme des Kunden zu verstehen, ist der Vertrieb primär nach den Branchen der Kunden organisiert. Die Vertriebsmitarbeiter müssen tiefes Branchenwissen besitzen, um Projektausschreibungen bearbeiten zu können. Zur Bearbeitung von Projekten wird den vertikalen Einheiten auch eine notwendige Zahl von Beratern zugeteilt, die über besondere spezifische Branchenkenntnisse verfügen. Die Mehrzahl der Berater sind aber nach branchenunabhängigeren Themen oder Kompetenzen gegliederten Delivery-Einheiten zugeordnet, aus denen die Projekte überwiegend besetzt werden. Die Themen können sich auf die Einführung bestimmter Softwareprodukte wie SAP, fachliche Gebiete wie Logistik, Vertrieb, Personal oder Methoden und Technologien wie KI oder Cloud Computing beziehen.

Abb. 10.12 Matrixorganisation eines Consulting-Unternehmens

10.2 Das Composable-Consulting-Unternehmen

203

Auch diesen horizontalen Einheiten können Vertriebsmitarbeiter zugeordnet werden, um ihnen unternehmerische Verantwortung zur Akquisition und Bearbeitung zu geben. Sie können dann nach Gewinn und Verlust gesteuert werden. Die bei einer Matrixorganisation üblichen Zuordnungsprobleme von Umsatz und Kosten sowie Akquisitionserfolge gilt es zu managen. Damit können beide Gliederungsarten prinzipiell nach Gewinn und Verlust gesteuert werden. Ein Kundenprojekt findet in der Kreuzung von Branchenwissen und Themenwissen statt. In Abb. 10.12 umfassen die Projekte 2 und 3 zwei Themen und gehören jeweils zu einer Branche. Das Projekt 6 erfordert das Wissen von zwei Branchen, weil der Kunde Produkte aus zwei Branchen (z. B. Lebensmittel und Pharmazie) anbietet, aber nur ein Thema bearbeitet haben möchte. Bei einer dezentralen Organisation, wie sie das Leitbild des Composable Consulting Enterprise ist, ergibt sich ein Organigramm der Abb. 10.13. Die zentralen Funktionen Rechnungswesen, Finanzen, Personal (Human Resources), Marketing und IT werden als Shared Services gestaltet. Für spezielle Branchencluster, Spezialthemen oder Ländergesellschaften können eigene Consulting-Einheiten (Module) gebildet werden, die als selbstständige operative Unternehmenseinheiten mit oder ohne

Abb. 10.13 Organigramm eines composable Beratungsunternehmens

204

10

Digitale Branchenkonzepte für das Composable Enterprise

eigene Rechtsstruktur gebildet werden. Besonders eignet sich die Modularisierung, wenn neben Beratungsleistungen auch Produkte als Standardsoftware entwickelt werden. Hier wird häufig für Marketing, Vertrieb und Produktentwicklung eine selbstständige Organisationseinheit gebildet, die auf die Besonderheiten eines Produktunternehmens gegenüber einer Dienstleistung eingeht. Die Abwägung zwischen dem Ausmaß an zentralen Funktionen und dezentralen Verantwortlichkeiten ist ein ständiges Diskussionsthema und muss offen mit den transparenten Argumenten bezüglich der Wirkung auf Ressourcen- und Prozesseffizienz entschieden werden. Im Mittelpunkt der Leistungserstellung eines Consulting-Unternehmens steht die Projektorganisation (vgl. Abb. 10.14). Das Staffing eines Kundenprojektes ist eine wichtige Aufgabe. Die Berater müssen mit ihren Kenntnisprofilen dem Kunden vorgestellt und von ihm akzeptiert werden. Zur Zuordnung von Beratern zu einem Projekt wird eine Skilldatenbank eingesetzt, in der die fachlichen Profile gespeichert und aktualisiert werden. Für Spezialkenntnisse und zum Ausgleich von Kapazitätsengpässen werden Mitarbeiter von Partnerunternehmen oder Freelancer eingesetzt, deren Profile ebenfalls in der Skilldatenbank erfasst sind.

Abb. 10.14 Struktur eines Beratungsprojektes als semantisches Netz

10.2 Das Composable-Consulting-Unternehmen

205

In der Regel werden in dem Projektteam auch Mitarbeiter des Kundenunternehmens eingesetzt, um die unternehmensindividuellen Besonderheiten einzubringen und für den Know-how-Transfer zum Kunden für den späteren Betrieb des Systems zu sorgen. Die Teammitglieder kommunizieren während der Projektarbeit intensiv in verschiedenen Arbeits- und Kommunikationsformen miteinander. Die Aktivitäten sind nach Projektsteuerung, Workshops, Process Modeling, Softwareentwicklung, Implementierung und Schulung eingeteilt. Während der Projektarbeit wird gespeichertes Wissen aus früheren Projekten in Form von Templates oder Referenzmodellen eingesetzt. Die Referenzmodelle können in Teilprozesse oder Prozessmodule gegliedert sein, die für ein konkretes Kundenprojekt zusammengefügt werden. Aus dem Projektergebnis werden das neue Wissen zu den Referenzmodellen und die Skillprofile der beteiligten Berater aktualisiert. Branchenprobleme, Beratungsthemen und Kundenprobleme bestimmen eine Vielfalt unterschiedlicher Projekttypen. Dieses sind z. B. Dienstleistungs- oder Werkvertragsprojekte, Entwicklungsprojekte oder Implementierungsprojekte, Großprojekte oder Kurzprojekte, strategische oder operative Beratungsprojekte, internationale Projekte oder lokale Projekte. Nach diesen Kategorien richten sich auch Projektrisiken. Die Application Composition Platform unterstützt die projektbezogene Montage von Wissen und Mitarbeiterskill sowie stellt Schnittstellen zu Unterstützungstools bereit. Der Projektleiter kann für individuelle Risikobetrachtungen Auswertungen mit Hilfe von LowCode erstellen und das generelle Projektsteuerungscockpit auf die Anforderungen des aktuellen Projektes anpassen. Die Anwendungsarchitektur auf Basis der Application Composition Platform in Abb. 10.15 bringt die Vielfalt der Anwendungen des Consulting-Unternehmens zum Ausdruck. Die PBCs und das Prozesswissen, aus denen die Anwendungen komponiert werden, sind pauschal angegeben. Sie werden auf dem internen Marktplatz verwaltet und durch die Composition-Funktion der Plattform zu Anwendungen montiert. Die noch nicht behandelten Anwendungen werden in den nächsten Abschnitten erläutert. Sie können entsprechend dem Dezentralisierungsgrad des Unternehmens in den Consulting-Modulen in Varianten entsprechend regionalen Anforderungen und Beratungsfeldern angepasst werden. Dieses wird grafisch durch die Faltung ausgedrückt. Bei einer extrem zentralen Organisation besteht jede Anwendung dagegen nur in einer Version. Die Anwendungen aus Finanz- und Rechnungswesen sowie Personalabrechnung werden zentral als Shared Services zur Verfügung gestellt. Über die Integrationsfunktion der Plattform sind alle Anwendungen untereinander und mit den Shared Services verbunden. Kunden, Lieferanten und Partner können über das Internet und die Cloud auf die Plattform und Anwendungen zugreifen, um an Kundenprojekten mitzuarbeiten.

206

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.15 Anwendungslandschaft des Composable Consulting-Unternehmens. Die durch die Faltung der Anwendungen ausgedrückten Varianten richten sich nach dem Dezentralisierungsgrad des Unternehmens, also nach der Gliederung in autarke modulare Geschäftseinheiten. (Quelle: Adobe Stock, PureSolution)

Im Folgenden wird systematisch untersucht, wie die in Kap. 9 behandelten Innovationstreiber die Geschäftsmodelle und die Geschäftsprozesse von Consulting-Unternehmungen verändern können. Die Anforderungen an Transformation werden dadurch deutlich gemacht. Dieses systematische Vorgehen eignet sich für alle Branchenkonzepte im Sinne des Composable Enterprises.

10.2.1 Personalisierung/Individualisierung Beratungsprojekte sind von Natur aus auf die individuellen Fragen des Kunden ausgerichtet. Allerdings besteht durch den Einsatz von Public-Cloud-Lösungen bei Kunden ein Trend zum Einsatz von Standardsoftware ohne tiefgreifende Anpassungen. Dieses bezieht sich aber mehr auf Standardprozesse des Backoffice, also auf die Shared Services des Kunden.

10.2 Das Composable-Consulting-Unternehmen

207

Für die Lösung individueller Probleme von Kunden muss das Beratungsunternehmen eine Vielfalt von Spezialwissen an Techniken und Softwareangeboten bereithalten. Hier ist der Zugriff auf ein Netzwerk aus Partnern und Freelancern erforderlich. Die Individualisierung von Beratungsleistungen bezieht sich auch auf stärker kundenorientierte Projektstrukturen. Kunden können ein Projekt komplett nach außen an Berater vergeben oder Leistungen selbst übernehmen und lediglich Tools oder Kernkompetenzen wie Projektmanagement und Spezialkenntnisse von externen Beratern beziehen. Auch kleinteiligere Beratungsformen entstehen. Zurzeit werden IT-Projekte in der Einheit „Beratungstage“ gemessen. Es können aber auch „Nano“-Leistungen gefragt werden, indem Kunden ad-hoc Spezialfragen in kurzer Zeit beantwortet haben möchten. Derartige Leistungen können in Stunden- oder Minuteneinheiten abgerechnet werden. Dazu sind neue Vertriebswege wie Internet-Consulting-Shops und neue Vertragsbeziehungen wie Consulting-Abonnements mit Ticketabrechnung einzurichten.

10.2.2

Selbststeuerung

Wollen Kunden in höherem Maße Eigenleistungen bei kleineren Projekten einbringen, nutzen sie den Innovationstreiber der Selbststeuerung von Consulting, sogenanntes SelfConsulting. Mit der Nutzung von Process Mining Tools können sie Probleme ihrer Prozessorganisation fast automatisch erkennen. Durch KI-Einsatz werden dazu automatische Verbesserungsvorschläge möglich. Für ein Consulting-Unternehmen bedeutet dieses, dass es einerseits Unterstützungsaufgaben verliert, die es aber durch neue Produkte und Dienstleistungen ausgleichen kann:  Es kann Tools wie Process Mining bei Kunden einführen und bei der Ergebnisanalyse unterstützen.  Es kann sich auf Spezialwissen konzentrieren, das ein Kunde nicht in der Tiefe für ein Projekt aufbauen kann.  Es kann die Projektleitung übernehmen.  Es kann den Kunden mehr coachen als die operative Projektarbeit zu leisten.  Es kann Wissen in Form von Referenzmodellen, Projektberichten bis hin zu halbfertigen Projekten (Greff et al., 2022) als Produkt einer Ausgangslösung über einen Consulting-Shop vertreiben.

10.2.3 Grenzkostenlose Dienstleistungen Werden aus Beratungsprojekten Erfahrungs- oder Wissensdatenbanken aufgebaut, so ist deren Erstellung mit erheblichen Kosten verbunden. Ihre Benutzung in nachfolgenden Projekten verursacht dagegen wenig Kosten, ist also quasi grenzkostenlos. Das Gleiche

208

10

Digitale Branchenkonzepte für das Composable Enterprise

gilt für die Anwendung von Algorithmen in der Auswertung von Datenbeständen. Beispielsweise können automatisierte Auswertungen von Vertriebsdaten Schwachstellen einzelner Vertriebsmitarbeiter zeigen oder einen Nachholbedarf im Marketing in bestimmten Vertriebsgebieten zeigen. Eine einfache, aber durchaus wirkungsvolle Unterstützung können Frequently-AskedQuestions (FAQ)-Dokumentationen von Kunden geben. Auch hier ist der Aufbau mit Kosten verbunden, die Benutzung aber nahezu kostenfrei (Greff et al., 2018). Das Angebot von entsprechenden Wissensdatenbanken und Auswertungstools könnte sogar das Kerngeschäft eines neuen Beratungstyps sein, wenn Consulting-Unternehmen sich darauf konzentrieren, das Selbst-Consulting von Unternehmen zu unterstützen oder andere Beratungsunternehmen mit diesen Tools zu beliefern.

10.2.4 Smart Services Durch Einsatz von Datenanalysten für spezielle Fragestellungen mit hoher Branchenkompetenz können Consulting-Unternehmen neue Geschäftsfelder eröffnen. Hier geht es weniger darum, Algorithmen selbst zu entwickeln, als bestehende (KI-)Algorithmen-Datenbanken kompetent auf Fragestellungen des Kunden anzuwenden. Das Ergebnis einer solchen Beratung ist dann inhaltlicher Art und kann nur aus einem Mix aus algorithmischen Kenntnissen sowie fachlichem Problem- und Branchenverständnis erbracht werden. Während gegenwärtig häufig Berater erst gerufen werden, wenn der Kunde ein Problem erkannt hat, kann durch Process Mining der Kundenprozesse durch Berater ein Problem bereits vorausschauend erkannt werden. Damit kann das Beratungsunternehmen seine Wertschöpfungskette in die Vorphasen verlängern. Durch Speicherung von Daten mehrerer Kundenfälle kann es Wissen zur Beurteilung von einzelnen Kundenproblemen im Verhältnis zur gesamten Branche aufbauen und dieses monetarisieren.

10.2.5 Community-/Schwarm-Effekt Traditionell wird ein Beratungsprojekt von einem fest definierten Team durchgeführt. Durch die erweiterte mediale Kommunikation kann dieses Team durch virtuelle Mitarbeiter ergänzt werden. Das Beratungsunternehmen kann um sich herum eine Community aus User Groups, externen Spezialisten bis hin zu Fachleuten aus der ganzen Welt aufbauen und diese bei Spezialfragen situativ heranziehen. Dadurch wird Spezialwissen zu geringen Kosten flexibel verfügbar gemacht. Gleichzeitig wird der Effekt genutzt, dass viele Urteile von Beteiligten aus unterschiedlichen Lebens- und fachlichen Hintergründen bis hin zu Laien bei einer Verdichtung deren Ergebnisse zu besseren Einschätzungen führen als die Einzelmeinung eines sogenannten „Experten“.

10.2 Das Composable-Consulting-Unternehmen

209

10.2.6 Lean Organization und exponentielles Wachstum Durch die verbesserten technischen Kommunikationsformen können örtliche Niederlassungen reduziert und entfernt wohnende Mitarbeiter direkt einer Zentrale zugeordnet werden. Bei einer engen medialen Verbindung zum Kunden, die durch die Erfahrungen der Corona Epidemie gestützt ist, können aufwendige Reisekosten reduziert werden. Komfortable Videokonferenzen – bis hin zum Einsatz von 3D-Brillen oder HoloLens – erzeugen eine Atmosphäre, als ob sich alle Teilnehmer im gleichen Konferenzraum befinden würden. Derartige n:m-Kommunikationssysteme zwischen Beratern und Kunden verbreiten sich zunehmend. Auch wird eine stärkere Identifizierung von örtlich verteilten Mitarbeitern mit dem Gesamtunternehmen erreicht, da Niederlassungen häufig ein Eigenleben führen. In die gleiche Richtung führen auch die bereits aufgeführten Punkte des verstärkten Einsatzes von Freelancern und Partnern, die, ohne Fixkosten zu verursachen, mit dem Unternehmen zusammenarbeiten können. Ein hemmender Faktor ist die verminderte örtliche Nähe zu Kunden, die regionale Verbundenheit häufig als Zeichen des Vertrauens werten. Gleichzeitig kann eine zu geringe Face-to-Face-Kommunikation zwischen den Mitarbeitern ihre Bindung an das Unternehmen erschweren und den Aufbau einer einheitlichen Unternehmenskultur behindern. Ein exponentielles Wachstum wird bei Beratungsunternehmen aufgrund des Fachkräftemangels durch das nur langsame Wachstum von Neueinstellungen erschwert. Hier hilft die forcierte Einbindung von Freelancern und Partnern, Aufbau von Nearshore-Ressourcen bis zu einem Franchising- oder Plattform-Konzept. Auch können Berater skalieren, indem sie parallel mehrere Aktivitäten betreuen. Ein Beispiel geben Greff et al. (2022), indem ein Berater mehrere parallellaufende Webinare remote leitet und hauptsächlich für die Beantwortung von Fragen zur Verfügung steht. Die eigentlichen Inhalte werden automatisiert über digitale Video-Formate vermittelt. Auch der Vertrieb von Erfahrungsdatenbanken, Referenzmodellen, Modellierungs- und Auswertungstools sowie vortrainierte KI-Modelle unterstützen exponentielle Wachstumsmöglichkeiten.

10.2.7 Künstliche Intelligenz Auswertungsalgorithmen und Methoden der künstlichen Intelligenz wurden bereits mehrfach angesprochen und zeigen ihre Bedeutung für das digitale Consulting. Andererseits gibt es auch Begrenzungen. So ist der Mensch nach wie vor in der Kreativität, dem Erkennen komplexer Muster und Führung komplexer Diskussionen überlegen. Dieses sind Eigenschaften, die bei strategischen Beratungsprojekten benötigt werden. Auch die Verteidigung der Argumente in einer hitzigen Diskussion ist weiterhin eine Domäne des Menschen.

210

10

Digitale Branchenkonzepte für das Composable Enterprise

Das Charisma eines Leaders mit seinen Motivationseigenschaften ist noch durch keine Maschine zu ersetzen. Auch der hypothesenfreie Ansatz von Deep Learning erweckt Kritik, da sich eine Unternehmensleitung bei strategischen Entscheidungen kaum auf ein Ergebnis stützen wird, das es nicht plausibel erklären kann und eventuell durch Zufallserscheinungen oder Effekte des Overfittings erzielt wurde (Weißenberger, 2018). Anders ist es aber bei mehr operativen Aufgaben eines Beraters. KI-Methoden sind hier ein Rationalisierungsinstrument. Juniorberater, die bisher vor einer Präsentation Tage und Nächte mit der Analyse von Excel-Tabellen und dem Anfertigen von PowerPoint-Abbildungen verbracht haben, um endlich ein überraschendes Ergebnis zu erkennen, können sich aufgrund automatisch erkannter außergewöhnlicher Datenmuster stärker deren inhaltlichen Interpretation widmen. Auch das Customizing von Anwendungssoftware kann unterstützt werden, wenn aus vielen Einzelfällen abgeschlossener Projekte bestimmte Parameterwerte für Unternehmenstypen erkannt werden. Neben der Rationalisierungswirkung eröffnet KI aber auch neuartige Geschäftsmodelle für Berater, die ihr Wissen zum Einsatz von KI-Methoden und dem Aufbau entsprechender Modelle vermarkten. Insgesamt wird mit einer schnellen Verbreitung von KI-Methoden in der Beratung gerechnet, so dass diese zum Handwerkszeug eines Beraters werden wie heute Excel und PowerPoint (Neuscheler, 2018). Insbesondere generative KI-Systeme wie Chat GPT wecken viele Phantasien, wie sich das Arbeitsumfeld des Beraters verändern wird.

10.2.8 Consulting-Plattformunternehmen Die Entwicklung von Plattformunternehmen gewinnt besondere Beachtung. In diesem Unternehmenstyp bündeln sich mehrere Innovationstreiber. Es können zwei unterschiedliche Plattformtypen entstehen: 1. Plattformen für Consulting-Unternehmen und Anwender Dieser Unternehmenstyp bietet keine eigenständige Consulting-Dienstleistungen an, sondern entwickelt Softwaresysteme, die er auf seiner Plattform zur Unterstützung von Beratungsprojekten anbietet. Dieses können Prozess-Modellierungstools, Auswertungsalgorithmen, Monitoring Tools oder Wissensdatenbanken sein. Die Kunden sind dann Consulting-Unternehmen, aber auch Anwender im Rahmen des Self-Consultings. Diese Unternehmensform eignet sich besonders für Start-Up-Unternehmen. Sie starten zunächst als Lieferanten zu traditionellen Consulting-Unternehmen. Wenn sich ihre Methoden und Werkzeuge durchsetzen, können sie den Markt dominieren. 2. Consulting-Plattformunternehmen Dieser Unternehmenstyp setzt den Schwerpunkt auf inhaltliche Consulting-Leistungen, bietet sie aber – unter Nutzung der Digitalisierung – in neuer Form an. Er nutzt dazu eigenentwickelte Tools oder Standardtools von Unternehmen des Typs (1), reichert sie

10.2 Das Composable-Consulting-Unternehmen

211

mit eigenen Inhalten an und entwickelt ein Ökosystem aus Kunden und Partnern. Dieser Typ nutzt vor allem die Erfolgstreiber: Personalisierung durch flexible Projektstrukturen; Smart Services durch neue Beratungsangebote für Datenanalyse und Prozess Monitoring; Community-Effekte durch Nutzung von User Groups und Expertennetzwerken; Lean Organization durch Homeoffice-Lösungen und eine virtuelle Unternehmensform. Exponentielles Wachstum strebt er durch den schnellen Aufbau seines Ökosystems aus Partnern an. In Abb. 10.16 ist die Struktur dieses Plattformunternehmens dargestellt. Im roten Feld sind die Leistungen angegeben, die von dem Unternehmen angeboten werden. Diese können von dem Unternehmen selbst stammen oder von externen Lieferanten. Dazu zählen: Organisationsmethoden zur Prozessoptimierung, Expertenwissen für inhaltliche Fragestellungen und Branchen-Know-how sowie Kompetenzen zur Steuerung komplexer Projekte. Das Öko-System des Beratungsunternehmens besteht dann aus seinen Kundenbeziehungen sowie aus dem Umfeld von externen Spezialisten, Partnern, Freelancern, Forschungsinstituten usw. Je größer dieses Umfeld ist, umso flexibler kann das Beratungsunternehmen auf unterschiedliche Fragestellungen und Ressourcenbedarfe des Kunden reagieren. Neben dem Kern der Plattform und dem Öko-System aus Kunden und Lieferanten ist in Abb. 10.16 auch die Einbettung des Unternehmens durch das Partner-Symbol in ein Netzwerk von Plattformbeziehungen angedeutet. Ein Consulting-Unternehmen kann ein Projekt verantwortlich leiten und in einem anderen Kundenprojekt Zulieferer eines anderen Consulting-Unternehmens sein. Bei dieser Vernetzung von Consulting-Unternehmen ist die wirtschaftliche Position eines Mitglieds umso höher, je größer das eigene Ökosystem und die eigenen Kernkompetenzen sind. Entsprechend höhere Preise kann das Unternehmen für seine Beratungsleistungen auch gegenüber einem größeren Partner fordern.

Abb. 10.16 Consulting-Plattform-Architektur. (Quelle: Adobe Stock, PureSolution)

212

10

Digitale Branchenkonzepte für das Composable Enterprise

10.2.9 Infrastruktur In Abb. 10.17 ist die digitale Infrastruktur des Composable Consulting-Unternehmens skizziert. Im rechten Teil ist der Aufbau der Kommunikationsinfrastruktur angegeben. Alle Berater werden durch Voice-over-IP (VoIP)- und Videokonferenz-Systeme unabhängig von ihrem Standort unterstützt. Gleichfalls werden auch die Projektmitarbeiter des Kunden in diese Kommunikationsinfrastruktur eingebunden, um Reisetätigkeiten zu verringern. Im nächsten Schritt kann diese Infrastruktur auch auf Partner- und SpezialistenNetzwerke weltweit ausgedehnt werden. Dabei wird Cloud-Lösungen der Vorzug gegeben. Video-Conferencing, Groupware-Technologien, 3D-Brillen, Virtual Reality, Augmented Reality sowie Analysealgorithmen der Künstlichen Intelligenz werden zum Standardinstrumentarium in Beratungsleistungen. Auch private Blockchain-Architekturen können für Netzwerke aus Beratern und Kunden zum Austausch vertraulicher Daten gebildet werden. In Abb. 10.17 ist links unten der Aufbau von Wissensdatenbanken zur Speicherung von Erfahrungswissen aus Projekten und deren Wiederverwendung angegeben. Im Rahmen des Nano-Consulting werden kleinere Beratungseinheiten angeboten. Durch Tools zum Process Mining können das Prozessverhalten des Kunden analysiert und Schwachstellen erkannt werden. Damit kann die Wertschöpfung der Beratung verlängert werden und bereits mit der Problemerkennung beginnen.

Abb. 10.17 Digitale Consulting Infrastruktur. (Quelle: Adobe Stock, PureSolution)

10.3 Die composable Hochschule

213

10.2.10 New-Work-Konzepte Der Fachkräftemangel ist im Beratungsmarkt besonders stark ausgeprägt. Gleichzeitig stellen Work-Life-Balance und Purpose-Orientierung der jüngeren Generationen erhöhte Anforderungen an das Recruiting. Homeoffice-Angebote werden von vielen Mitarbeitern verlangt. Gleichzeitig nimmt aber die Akzeptanz der Kunden für Remote-Beratung durch die insgesamt positiven Erfahrungen der Corona-Zeit zu. Aus Sicht eines Beratungshauses ist die Selbststeuerung von Mitarbeitern von besonderer Bedeutung. Viele qualifizierte Mitarbeiter wollen selbst bestimmen, in welche Projekte sie eingebunden werden möchten, um ihre Fähigkeiten am wirkungsvollsten einsetzen zu können. Gleichzeitig spielen auch neue Arbeitsformen wie Freelancer oder Internetnomaden im IT-Consulting eine größere Rolle. Durch Einsatz der neuen Medien können sie ihre Leistungen zeit- und ortsunabhängig erbringen. Hier müssen Consulting-Unternehmen die Fähigkeit professionalisieren, kompetente Freelancer anzuwerben, in Projekte einzugliedern, zu steuern und ihre Qualität zu sichern. Innovative Beratungsthemen, die auch einen gesellschaftlichen Impact haben, wie Energieversorgung oder Kreislaufwirtschaft, können junge Menschen, die nach Purpose streben, motivieren, den Consulting-Beruf zu ergreifen. Den aufgeführten vielfältigen Herausforderungen der Consulting-Branche bietet das Konzept des Composable Enterprise durch die Unterstützung von Innovationsfreude gute Möglichkeiten, sich schrittweise durch Experimentieren, Ausgründung von Spezialthemen oder Zusammenarbeit mit Start-Ups neu zu erfinden.

10.3 Die composable Hochschule In der Wirtschaft hat die Digitalisierung bereits zu erheblichen Marktveränderungen geführt. Gegenüber diesen Änderungen zeigen Hochschulen, obwohl ihre wissensorientierten Leistungen Forschung und Lehre einer Digitalisierung nahestehen, in Deutschland bisher eine geringere Digitalisierungsgeschwindigkeit. Dies liegt an ihrem Traditionsbewusstsein, einem langsamen Generationswechsel der Professoren, wenig Wettbewerb innerhalb und zwischen Hochschulen und einem wegen gesicherter staatlicher Finanzierung geringen Finanzdruck. So sehen heute noch viele Hörsäle aus wie vor 20 Jahren, während sich Bankschalter, Zahnarztpraxen, Versandhandel und Fabriken dramatisch gewandelt haben. Nun zeigt sich bei Hochschulen ein Umbruch. Die Corona Epidemie hat dem digitalen Unterricht einen großen Schub gegeben. Neue Informationstechniken wie Cloud Computing, Data Science, Social Media, Smartphones usw. dringen in die Leistungsprozesse von Forschung und Lehre ein und verändern sie. Anforderungen der Gesellschaft, die nach der gesellschaftlichen Wirkung der hohen staatlichen Forschungsausgaben fragen, setzen Hochschulen in einen Begründungsdruck für ihre finanziellen Forderungen.

214

10

Digitale Branchenkonzepte für das Composable Enterprise

Globale Rankings zeigen, dass deutsche Universitäten nicht mehr in der ersten Liga spielen. Die am besten gerankten deutschen Universitäten werden nach dem internationalen Shanghai Ranking in 2022 mit der TU München an 56ster und mit der LMU München an 57ster Stelle aufgeführt. Andere europäische Universitäten wie die ETH Zürich (20ster Stelle) liegen weit vorne. In osteuropäischen Ländern wie Ungarn und Slowenien haben sich halbprivate Universitäten mit internationaler Ausrichtung schnell einen guten Namen gemacht und sind speziell in den Medizinfächern mit einer studentenzentrierten Lehre ein starker Anziehungspunkt für in Deutschland aufgrund des Numerus Clausus abgewiesene Studenten. Dieses sind nur wenige Anmerkungen. Die Überdenkung der Businessmodelle der deutschen Hochschulen ist deshalb mehr als angebracht. Der Begriff Businessmodell mag für Hochschulen im ersten Moment ungewohnt sein. Bei einer näheren Betrachtung hat er aber seine Berechtigung. Auch eine Hochschule hat ein Erlösmodell, sei es, dass sie der Staat, Forschungsorganisationen, Studiengebühren oder Sponsoren finanzieren. Diesen Geldgebern muss sie ihre Leistungsfähigkeit nachweisen, sonst sind die Erlöse auf Dauer gefährdet. Auch die anderen Komponenten eines Geschäftsmodells, wie Ressourcenmodell, Partnermodell usw., haben für Hochschulen ihre Gültigkeit. Die digitale Agenda der Bundesregierung und landesweite Initiativen fördern inzwischen finanziell die Digitalisierung des Forschungs- und Bildungssystems. Im „Hochschulforum Digitalisierung“ erarbeiten rund siebzig Experten Handlungsempfehlungen für Hochschulleitungen, Lehrende und die Politik. Trotzdem ist die Ausgangssituation für Veränderungen eher schwerfällig. Die Organisation einer Hochschule ist mit ihrer Untergliederung in Präsidium, Fakultät, Fachbereich, Lehrstuhl (vgl. Abb. 10.18) hierarchisch gegliedert. Die Lehrstühle als operative Leistungsträger von Forschung und Lehre sind mit ihrer geringen Ausstattung von in der Regel zwischen 2 und 5 wissenschaftlichen Mitarbeitern pro Professor auf kleine fachliche Segmente spezialisiert. Für ressourcenintensive und interdisziplinäre Forschungsprojekte ist diese Gliederung nicht geeignet. Dies erkennen inzwischen einige Universitäten. Ein Beispiel ist die Technische Universität München. Sie hat ihre bisherigen 15 Fakultäten zu 6 Schools und zwei Fakultäten gebündelt, um komplexe Themen ganzheitlicher bearbeiten zu können. Zum Beispiel vereint die „School of Computation, Information and Technology (CIT)“ die ehemaligen Fakultäten Mathematik, Informatik und Elektrotechnik und soll zukunftsorientierte Studienprofile und die vernetzte Forschung und Lehre unterstützen. Zielsetzung ist jeweils eine stärkere Ressourcenbündelung und intensivere interdisziplinäre Zusammenarbeit. Die Zusammenarbeit richtet sich dabei an übergreifenden fachlichen Themen wie z. B. Klimaschutz, Erneuerbare Energien, Quantencomputing, NanoBiomedizin aus, die mehrere fachliche Kompetenzen erfordern. Gleichzeitig besitzen diese Themen eine hohe Dynamik in Bearbeitungsformen, Methoden und damit auch in digitaler Unterstützung.

10.3 Die composable Hochschule

215

Abb. 10.18 Traditionelle Fakultätengliederung

Bei diesen tiefgreifenden Transformationen bietet das Composable Enterprise eine gute Leitlinie für die Struktur der zukunftsorientierten agilen Hochschule. Traditionell wurden die Zuständigkeiten des Präsidiums einer Hochschule in Verwaltung, Forschung und Lehre gegliedert. Heutige Gliederungen sind differenzierter. Sie umfassen Forschung, Wissenstransfer, Student-Lifecycle-Management, Digitale Lehre, Internationale Partnerschaften und Talentmanagement. Dabei stehen als zentrale Dienste die Funktionen Verwaltung, Finanzen, Beschaffung, Personalverwaltung und Digitalisierung allen Leistungszentren zur Verfügung. Wegen ihrer besonderen Bedeutung können einzelne Funktionen ausgegliedert und einem eigenen Vizepräsidenten zugeordnet werden, wie z. B. das Thema Digitale Lehre aus dem Student-Lifecycle-Management, da dieses Thema für einen Umbruch der Lehre steht. In Abb. 10.19 ist aus den Aufgaben die Anwendungsarchitektur einer Hochschule abgeleitet. Sie folgt den bisherigen Darstellungen, indem aus den PBCs unter Nutzung des Prozesswissens prozessorientierte Anwendungen gebildet werden, die durch die Plattform miteinander und der Cloud-Infrastruktur über API-Technologie verbunden sind. Studenten, externe Wissenschaftler und Partner sind ebenfalls über die Cloud und API-Schnittstellen mit den Anwendungen verbunden. Der Struktur der Abb. 10.19 wird bei den weiteren Ausführungen gefolgt. Für viele Aufgaben von Hochschulen steht Standardsoftware zur Verfügung. Diese kann als Rückgrat einer Anwendungsarchitektur und zur Unterstützung der zentralen

216

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.19 Allgemeine Anwendungsarchitektur Hochschulen. (Quelle: Adobe Stock, PureSolution)

Dienste eingesetzt werden. Um sie herum werden aber für viele Ergänzungen, neue Funktionen und zur Steigerung der Nutzer-Experience eigene Anwendungen entwickelt. Die Beziehung zwischen gemeinsam genutzten Anwendungen und den individuell entwickelten Anwendungen folgt dem Gedanken fraktaler Organisationen. Dieses bedeutet, dass auf jeder Organisationsstufe von übergeordneten Organisationseinheiten Shared Services in Anspruch genommen werden können, darüber hinaus aber auch eigene Entwicklungen möglich sind. Dieses gilt für School- bzw. Fakultätsanwendungen für die Anwendungen der zentralen Dienste auf der obersten Ebene und für Lehrstühle bezüglich zentraler Funktionen der School bzw. Fakultät. Die Application Composition Platform ist dazu insbesondere mit ihren Funktionen Low-Code für dezentrale Entwicklungen und Integration zu anderen Anwendungen die passende Grundlage. Im Folgenden werden die Prozesse um Studenten, Forschung und zentrale Dienste genauer betrachtet.

10.3 Die composable Hochschule

217

10.3.1 Studierendenzentrierte Anwendungen Bei den studierendenzentrierten Anwendungen bildet die Lehre den Mittelpunkt des Studierenden Lifecycle Managements. Die gegenwärtige Lehre an Hochschulen ist durch folgende Eigenschaften gekennzeichnet:  Lehrleistungen werden an Universitäten gegenüber Forschungsleistungen bei der Beurteilung von Professoren geringer gewertet.  In vielen Fächern wie Rechts- und Wirtschaftswissenschaften dominieren Massenvorlesungen mit geringem persönlichem Kontakt zwischen Dozent und Student.  In den MINT (Mathematik, Informatik, Naturwissenschaft, Technik)-Fächern besteht einerseits Mangel an Absolventen, gleichzeitig werden hohe Abbrecherquoten und ein zu geringer Anteil weiblicher Studierender beklagt.  In einigen Fächern wie Medizin besteht ein enger Numerus Clausus und Studierende suchen Ausweich-Studienplätze im Ausland.  Hochschulen konzentrieren sich auf die Erstausbildung und bieten kaum Weiterbildungsleistungen an. Auch die Alumni-Betreuung ist im Vergleich zu den USA wenig ausgeprägt.  Den universitären Lehrinhalten und Dozenten wird häufig Praxisferne vorgeworfen.  Eine geringe Anzahl an Laborplätzen oder Patienten pro Medizinstudenten begrenzt die praktische Ausbildung.  In vielen Studiengängen dominiert das Selektionsprinzip beim Studienfortschritt und nicht die individuelle Förderung. Diesen Punkten kann durch eine fortschrittliche Strategie und intensive Nutzung der Digitalisierung begegnet werden, die den gesamten Studierenden Lifecycle umfasst und durch digitale Lehre eine disruptive Verbesserung anbietet.

10.3.1.1 Studierende Lifecycle Management Abb. 10.20 zeigt die Anwendungen des Studierenden Lifecycle vom Marketing zur Akquisition von Bewerbungen bis zur Exmatrikulation und weiter zur lebenslangen Lernund Alumnibetreuung. Die PBCs und das Prozesswissen sind nicht nach Anwendungen gegliedert, sondern pauschal angegeben. Da sie Grundlage der Anwendungen sind, sind sie grafisch herausgestellt. Die Faltung der Anwendungen bezieht sich auf Varianten, die je nach dem Dezentralisierungsgrad der Hochschule für einzelne Einheiten wie Schools oder Fachbereiche entwickelt werden können. Die Anwendungen werden kurz erläutert. Das Studierendenmarketing muss Omni-Channel-fähig sein. Der Kontakt zu den Studierenden muss während des gesamten Zyklus aktuell und eng gehalten werden. Die aufgebaute enge Bindung zur Universität während der Studienzeit fördert später die Be-

218

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.20 Anwendungen des Studierenden Lifecycle. Rot hinterlegte Funktionen werden durch die digitale Lehre unterstützt. Die Faltungen der Anwendungen drücken Varianten aus, die je nach Dezentralisierungsgrad autonomen Einheiten wie Schools oder Fakultäten zugeordnet werden. (Quelle: Adobe Stock, PureSolution)

reitschaft, sich als Alumni und Sponsor bei der Universität zu engagieren. Zeugnisdaten können über Blockchain-Architekturen fälschungssicher verwaltet werden. Die elektronische Verwaltung von Studierendendaten hat in den letzten Jahren bereits durch den Einsatz von Standardsoftware große Fortschritte erzielt. Die Warteschlangen von Studenten vor dem Studentensekretariat beim Einschreiben oder Rückmelden sind weitgehend verschwunden. Viele Funktionen können vom Studenten eigenständig per Internet durchgeführt werden. Dieser Self-Service entlastet die Universität und erhöht gleichzeitig wegen seiner Orts- und Zeitunabhängigkeit die Zufriedenheit der Studierenden. Bietet die Hochschule Weiterbildungsmöglichkeiten an, können Studenten lebenslang im Sinne des Lifelong Learning (LLL) betreut werden. Die Treiber neuer Anwendungen sind die Steigerung des Self-Service der Studierenden, benutzerfreundliche Oberflächen zur Verbesserung der Experience der Studierenden

10.3 Die composable Hochschule

219

bei der Nutzung vielfältiger digitaler Dienstleistungen und eine gesteigerte Serviceorientierung zu den Studierenden als Kunden der Hochschule.

10.3.1.2 Digitale Lehre Der Einsatz von E-Learning ist seit über 20 Jahren in der Erprobung. Die meisten deutschen Hochschulen nutzten bis zum Ausbruch der Corona-Epidemie jedoch erst einen kleinen Teil der Möglichkeiten digitaler Lerntechnologien (Wannemacher et al., 2016). Sie wurden dann mit dem Lockdown ins kalte Wasser geworfen und haben notdürftige Lösungen entwickelt. Im Wesentlichen wurde der frontale Vorlesungsstil beibehalten und analoge Unterlagen wie Übungsblätter usw. lediglich digitalisiert versendet. Über Chat- und Kommentierungsfunktionen von Standard-Videokonferenz-Systemen wie Teams wurden der persönliche Kontakt und Kommunikationsmöglichkeiten hergestellt. Vereinzelt wurde auch die Veranstaltungsstruktur verändert, indem z. B. der Inhalt der nächsten Vorlesungsstunde vorab versendet wurde, am Beginn der digitalen Vorlesung ein Verständnis- und Vorbereitungstest für alle Teilnehmer gemacht wurde und während der Veranstaltung der nun bekannte Inhalt diskutiert und durch Fallbeispiele vertieft wurde. Dieses sind erste Schritte zur Nutzung der Möglichkeiten einer digitalen Lehre. Im Grunde war man aber auf dem Niveau der Anfangsphase der Filmtechnik, als zunächst Theaterstücke, die auf der Bühne aufgeführt wurden, abgefilmt wurden. Die Entwicklung zu den heutigen Möglichkeiten der Filmtechnik zeigt, welche Potenziale auch in der Entwicklung der digitalen Lehre vorhanden sind. Insgesamt kann zum gegenwärtigen Zustand festgestellt werden:  Digitale Lerntechnologien sind erst seit der Corona-Epidemie Teil einer Universitätsoder landesweiten Digitalisierungsstrategie.  An einer Hochschule werden häufig mehrere Systeme zur Verwaltung von Kursen und Studenten eingesetzt.  Eigenentwicklungen erschweren die dauerhafte Wartung.  Die Erstellung von professionellen digitalen Kursen ist sehr kostenintensiv und aus den Lehrstuhletats kaum zu finanzieren.  Auf digitales Learning ausgerichtete pädagogische Konzepte sind noch in der Entwicklung.  Bei vielen Dozenten bestehen Vorurteile, dass digitales Lernen zu Lasten des persönlichen Kontaktes zwischen Dozent und Student führe.  Individuelle Interessen von Dozenten haben bereits zu guten Beispielen für einen echten Einsatz digitaler Lerntechnologien geführt. Diese generell noch zögerliche Situation ändert sich gegenwärtig:  Das veraltete E-Learning-Konzept mit dem Fokus auf die Verwaltung von elektronischen Inhalten, wird um neue, auf den Lernenden konzentrierte, Ansätze erweitert und verbessert.

220

10

Digitale Branchenkonzepte für das Composable Enterprise

 Neue Techniken wie Cloud Computing, Social Media, Big Data, mobile Geräte wie Tablets und Smartphones erleichtern den Zugang zu Lerninhalten.  Formate wie E-Books, Lernvideos, Gamification und Individualisierung verbessern die User Experience und erhöhen die Akzeptanz.  Neue Tools zum Erstellen von Lerninhalten, auch durch die Lernenden selbst, reduzieren die Kosten der Content-Erstellung.  Digitalisierungsprogramme von Bund und Ländern stellen finanzielle Mittel für den Bildungsbereich bereit. Damit nimmt die Digitalisierungsgeschwindigkeit der Lehre an Hochschulen an Fahrt auf. Im Vordergrund steht das Prinzip, die gesamte Journey des Lernenden zu unterstützen. Sie beginnt damit, ihn für einen Lernstoff zu sensibilisieren, also neugierig zu machen. Dann wird er über ein Thema überblicksartig informiert, und er erkennt die Erwartungshaltung an seinen Einsatz. Mit der Wissensvermittlung wird erreicht, dass der Lernende über theoretische Grundlagen verfügt, mit dem Thema vertraut wird und die Inhalte versteht. In der nächsten Stufe soll der Lernende das erlernte Wissen anwenden können und zum Abschluss der Journey das Wissen dauerhaft verinnerlichen, verbessern und aktualisieren. Ein weiteres Prinzip ist, die Selbstmotivation des Lernenden zu stärken.

Abb. 10.21 Learning Journey. (Quelle: Adobe Stock, PureSolution und stonepic)

10.3 Die composable Hochschule

221

Die Lernexperience soll sicherstellen, dass dem Lernenden ein digitales Umfeld des User Interfaces gegeben wird, das ihn wegen des Komforts, Übersichtlichkeit, Einfachheit und Einheitlichkeit der Corporate Identity zum digitalen Lernen motiviert. In Abb. 10.21 sind wesentliche Eigenschaften des digitalen Lernens um den Studierenden gruppiert, die die Learning Journey unterstützen. In Abb. 10.22 sind daraus die wesentlichen Anwendungssysteme abgeleitet, die von der Hochschule zentral oder von ihren dezentralen Einheiten entwickelt und betreut werden. Die PBCs und das Prozesswissen sind pauschal für alle Anwendungen angegeben. Die Faltung der Anwendungen bezieht sich auf Varianten, die je nach dem Dezentralisierungsgrad einzelnen organisatorischen Modulen wie Schools, Fakultäten oder Fachbereichen zugeordnet werden. Eine zentrale Rolle spielt das Learning Management System (LMS) zur Verwaltung der Lerninhalte und Steuerung der Lernprozesse. Weiter folgen die Anwendungen zur Erstellung von Lerninhalten und Durchführung von Veranstaltungen als Conferencing. Die Learning Journey wird im Folgenden kurz beschrieben.

Abb. 10.22 Digital Learning Applications. Die Faltung der Anwendungen kennzeichnet Varianten für selbstständige organisatorische Einheiten wie Schools. (Quelle: Adobe Stock, PureSolution)

222

10

Digitale Branchenkonzepte für das Composable Enterprise

10.3.1.2.1 Neue Lernformate In der ersten Phase des digitalen Lernens wurden lediglich vorhandene Lernmaterialien wie Vorlesungen, Folien und Papierdokumente digital aufbereitet. Heute stehen bereits mit Simulationsmodellen, E-Books, interaktiven Videos, Serious Games oder MOOCs (Massive Open Online Courses) neue Lernformate bereit, deren Entwicklung sprunghaft weitergeht. Mit komplexen Simulationsmodellen können Laborversuche durchgeführt werden, die in der Realität zu gefährlich sind oder für die keine Apparaturen vorhanden sind. In Fächern wie Konstruktionstechnik können Systeme digital konstruiert und Crashtests durchgeführt werden, ohne Ressourcen zu verschwenden oder die Umwelt zu belasten. E-Books bieten ein Format, das eng an das bestehende Format von Lehrbüchern angelehnt ist und deshalb keiner Umstellung seitens des Lernenden bedarf. Serious Games übertragen die Prinzipien von digitalen Spielen auf Lernsituationen, um schnell Feedback zu getroffenen Entscheidungen zu geben. MOOCs-Inhalte sind von vornherein auf eine große Teilnehmerschaft ausgerichtet, und Lernende können weltweit darauf zugreifen. Bekannt geworden sind MOOCs durch Sebastian Thrun von der Stanford University, der 2011 eine Vorlesung über Künstliche Intelligenz über das Internet angeboten und damit eine große Diskussion entfacht hat. Ist ein MOOC erst einmal produziert, wofür allerdings erhebliche technische Einrichtungen wie Videostudios erforderlich sind, entstehen für die Anbieter kaum weitere Grenzkosten. Es ist für den Anbieter gleich, ob tausend oder eine Million Teilnehmer den Kurs „besuchen“. Jeremy Rifkin (2014) sieht darin einen Beitrag zur grenzkostenlosen Gesellschaft, in der Bildung quasi kostenlos wird. Dieses ist für US-Hochschulen, die sich durch Studiengebühren finanzieren, kein einfaches Geschäftsmodell. In den USA werden MOOCs deshalb wirtschaftlich eher als Marketing-Instrument zur Anwerbung zahlender, residenter Studenten angesehen oder es werden dafür neue Geschäftsmodelle durch die Verwertung von Teilnehmerprofilen an Unternehmen zur Unterstützung deren Recruitings entwickelt. In Deutschland wird dagegen die Hochschulbildung überwiegend vom Staat finanziert. Trotz einsetzender Kritik haben MOOCs die Lernwelt verändert. Allerdings hat sich gezeigt, dass nur rund 10 % der Beginner eines Kurses ihn auch erfolgreich beenden. Dies ist als Gegenargument zu MOOCs gewertet worden, kann aber auch als ein neues Lernverhalten interpretiert werden. Vielen Lernenden genügt eine Information über ein Lerngebiet, sie geben sich also mit einem Schnuppereindruck zufrieden oder sie unterbrechen den Kurs, da sie ihn jederzeit fortsetzen können. Eine Gegenbewegung zu MOOCs sind SPOCs (Small Private Online Courses), die auf kleine Themeneinheiten und begrenzte Gruppen zugeschnitten und dann auch mit Bezahlmodellen versehen sind. Durch die Erfassung des Benutzerverhaltens der Studierenden können Erfolgsfaktoren für bestimmte Lerninhalte und Lernformen analysiert werden. Dabei gilt es allerdings, Anonymitätserfordernisse im Rahmen des Datenschutzes einzuhalten.

10.3 Die composable Hochschule

223

10.3.1.2.2 Orts- und Zeitunabhängigkeit Präsenzveranstaltungen werden an einer Hochschule weiterhin ihre Bedeutung behalten. Deshalb ist der Student in Abb. 10.21 einer realen Heimat-Universität (Saarbrücken) mit Hörsälen zugeordnet. Darüber hinaus ist er über das Internet auch virtuell mit anderen Hochschulen verbunden. Über ein mobiles Endgerät kann der Studierende von jedem Ort und rund um die Uhr auf Lerninhalte zugreifen oder mit Mitgliedern der Hochschule kommunizieren. Dies gibt ihm eine größere Flexibilität der Lebensgestaltung. So kann er seinen Tagesablauf unabhängig von festen Vorlesungszeiten organisieren und Lernen besser mit beruflichen Tätigkeiten, Familienverpflichtungen oder Hobbys koordinieren. Studierende können auch während eines Auslandspraktikums oder -studiums weiterhin virtuell mit ihrer HeimatUniversität verbunden sein. 10.3.1.2.3 Individualisierung Zur Berücksichtigung unterschiedlicher individueller Eigenschaften der Lernenden bieten Hochschulen gegenwärtig Wahl- und Pflichtfächer oder Wiederholungsmöglichkeiten von Prüfungsleistungen an. Es bleiben jedoch feste Hürden durch obligatorische Prüfungsleistungen bestehen. Dadurch werden Studierende nach festgelegten Prüfungsordnungen selektiert, obwohl in dem weiteren Studium oder der späteren beruflichen Tätigkeit viele der geforderten Spezialkenntnisse nicht benötigt werden. Digitale Lerninhalte können in kleine Lerneinheiten wie Nanoeinheiten oder Lernnuggets angeboten und auch zertifiziert werden. Dadurch können Studiengänge wesentlich differenzierter gestaltet werden. Im Extremfall kann ein Student aus dem modularisierten Angebot an Lerninhalten sein individuelles Studium zusammenstellen. Natürlich müssen Rahmenbedingungen festgelegt werden, z. B. die Anzahl der zu erlangenden Credit Points (Leistungspunkte) für einen Studienabschluss, aber dieses in einer viel flexibleren Form. Auch die Lerngeschwindigkeit kann der Student individuell regeln. Durch in den Lerninhalt eingefügte Prüffragen mit sofortiger Auswertung bekommt er Real-Time Feedback und kann bei Bedarf sofort den Lernstoff wiederholen und die Lerngeschwindigkeit verringern. Begabtere können im Gegenzug die Lerngeschwindigkeit individuell erhöhen. Weitere Möglichkeiten für die Individualisierung ergeben sich durch die Auswahl verschiedener Lernformate (Videovorlesungen, Serious Games, E-Books usw.) oder den Einsatz intelligenter analytischer Verfahren, um dem Studierenden Inhalte gemäß seinen Präferenzen und Fähigkeiten automatisch zu empfehlen. Die Individualisierung des Inhaltes und der Lernformen ist der zentrale Ansatz zur Verbesserung der Learner Experience. Die Aufgabe eines Dozenten oder eines entsprechenden KI-Systems besteht dann darin, das unübersichtliche Angebot von Inhalten zu filtern, zu kuratieren und zu katalogisieren, um es nach Relevanz für den Lernenden zu priorisieren. Die digitale Übersetzung einer klassischen Literaturliste ist wegen ihrer zu groben Sicht lediglich ein Vergleichsbeispiel, aber keine Vorlage.

224

10

Digitale Branchenkonzepte für das Composable Enterprise

10.3.1.2.4 Globalisierung Über das Internet können Hochschulen ihre Lehrangebote Studierenden in der ganzen Welt anbieten. Jede Hochschule hat damit die Möglichkeit, eine globale Fernuniversität zu sein. Gleichzeitig kann dieses Angebot auch für Marketingzwecke genutzt werden. Die Hochschule macht sich international bekannt und zieht ausländische Studenten zum Präsenzstudium an. Der internationale Bekanntheitsgrad beeinflusst das internationale Ranking und macht die Hochschule attraktiv für qualifizierte Forscher. Umgekehrt können heimische Studenten Lehrangebote fremder Universitäten nutzen. Ein globaler Wettbewerb zwischen den Hochschulen ist die Folge. Zu klären ist die Anerkennung von Leistungen, die an anderen Hochschulen (z. B. über elektronische Tests) erworben wurden. Hier müssen internationale Regeln definiert werden. Das europäische ECTS (European Credit Transfer and Accumulation Systems) ist eine gute Basis. Aber selbst ohne formale Anerkennung erhält der Student einen Vorteil bei späteren Bewerbungen. Insgesamt stellt sich die Frage, welchen Wert Zertifizierungen in der Zukunft noch besitzen. Ist ein vor vielen Jahren erworbenes Hochschuldiplom mehr wert als eine Bescheinigung über den Abschluss aktueller Fachkurse auch von universitätsfernen kompetenten Anbietern? In den USA hat eine generelle Diskussion über den Nutzen der für die Studierenden teuren Hochschulausbildung (Higher Education) eingesetzt. Vorteilhaft für Hochschule und Studierende sind Kooperationsmodelle, in denen mehrere Hochschulen einen verteilten Studiengang anbieten und betreuen – jede Hochschule gemäß ihren besonderen Kompetenzen. Damit verbreitert und vertieft jede Hochschule ihr Angebot. Mehrere Hochschulen können gemeinsam hochwertige digitale Kurse entwickeln, die die Dozenten von zeitraubenden Massenveranstaltungen entlasten und ihnen somit mehr Zeit für die individuelle Betreuung geben. 10.3.1.2.5 Lernmotivation Der Lernende soll intrinsisch motiviert und neugierig auf den Lehrstoff sein. In Lerntechnologien werden dazu z. B. zunehmend spielerische Elemente eingesetzt (Serious Games), um schwierigen Stoff attraktiv zu vermitteln. Unternehmensplanspiele und Rollenspiele werden auch im traditionellen akademischen Unterricht bereits seit langem eingesetzt. Durch neue Techniken bekommen sie aber einen Qualitätssprung. An hochwertigen Simulationsmodellen können Entscheidungsstrategien geübt werden. Sofortiges Feedback über die Konsequenzen einer Entscheidung erhöhen den Lernerfolg. Die Lernmotivation des „moments of need“ wird dadurch spielerisch genutzt. Je schneller das Gelernte angewendet werden kann, desto höher ist die Motivation. In Laborumgebungen können bei der Übertragung eines realen Versuchs über Datenbrillen Lerninhalte und Erklärungen (Augmented Reality) hinzugespielt werden, sodass der Lernende quasi „on the job“ des Versuchs lernt.

10.3 Die composable Hochschule

225

In der klassischen akademischen Ausbildung dominiert dagegen das „Vorratslernprinzip“. Es wird Wissen vermittelt, das später einmal angewendet werden soll. Dabei besteht die Gefahr des Veraltens und Vergessens. Neue Technologien ermöglichen die unmittelbare Anwendung von Wissen und schulen somit Fähigkeiten der Interpretation und des Zusammenwirkens von Fakten (Prozesslernen). Bei immer kürzer werdender Halbwertzeit von Faktenwissen kommt der Vermittlung von solchen Fähigkeiten eine größere Bedeutung zu. Vorlesung, Übung und Seminar erreichen dies an Massenuniversitäten gegenwärtig nur sehr bedingt. 10.3.1.2.6 Fähigkeiten Auch bei der Umsetzung von Wissen bieten Lerntechnologien Unterstützung, nicht nur über simulierte Anwendungsumgebungen wie Lernspiele, sondern indem Freiräume für Dozenten zu Face-to-Face-Diskussionen geschaffen werden. Hier setzt sich das Prinzip der Individualisierung auch in der Face-to-Face-Kommunikation fort. Wenn die Vermittlung des notwendigen Faktenwissens mehr und mehr in das Internet verlagert wird, entstehen mehr zeitliche Freiräume für Kommunikationsmöglichkeiten zwischen Studierenden und Dozenten. Die Kombination von Klassenraumunterricht und Lerntechnologien wird als „Blended Learning“ bezeichnet. Der Klassenraum dient dann aber nicht zur Vermittlung von Faktenwissen, sondern zur Übung von Fähigkeiten. Beispielsweise kann zunächst über das Internet in einem Kurs über „Unternehmensgründung“ ein Businessplan für ein fiktives Start-Up-Unternehmen erstellt werden. Die Studentengruppe kann dann in einer Präsenzveranstaltung den Entwurf diskutieren und die Studenten anschließend remote das Projekt weiterbearbeiten. Die zum Teil den Lerntechnologien vorgehaltene Entfremdung vom Menschen führt in diesen Modellen gerade zum Gegenteil: Standardisierbare Wissensvermittlung wird digital durchgeführt, um mehr Zeit für direkte menschliche Kommunikation zu erhalten. Konsequenzen hat dieses Konzept auch für die räumliche Ausstattung. Anstelle großer Hörsäle müssen kleinere Arbeitsräume und Besprechungsräume für „One-on-One“-Gespräche bereitstehen. Soziale Medien tragen ergänzend dazu bei, Kommunikation und Kollaboration zwischen den Studenten über Orts- und Zeitgrenzen hinweg zu unterstützen. Möglich ist sogar die Verbesserung und Ergänzung der im Netz leicht zugänglichen Lerninhalte durch Studenten selbst (user generated content). Damit wird die Rollentrennung zwischen Dozent und Student verkehrt (Flipped Classroom oder Inverted Classroom). Ein gewünschter Effekt der stärkeren Vermittlung von Fähigkeiten anstelle von Faktenwissen ist, dass Studenten häufiger Unternehmen gründen, wenn sie in ihrem Studium mit der Erarbeitung und Diskussion von Businessplänen vertraut gemacht wurden. So soll nach Medienberichten z. B. jeder sechste Absolvent der Stanford University ein Start-UpUnternehmen gründen.

226

10

Digitale Branchenkonzepte für das Composable Enterprise

10.3.1.2.7 Lebenslanges Lernen Die in einem Studium erworbenen Kenntnisse müssen während einer über 30-jährigen Berufstätigkeit aufgefrischt und erweitert werden. Aktuell ist in Deutschland der Anteil der Hochschulen am Weiterbildungsmarkt allerdings gering (Schmid et al., 2016). Für Unternehmen wird die Weiterbildung ihrer Mitarbeiter im digitalen Wandel immer wichtiger und deshalb werden auch die Möglichkeiten von Lerntechnologien professioneller eingesetzt als im Hochschulbetrieb. Neben der Vermittlung von Grundlagenwissen kann schneller und organisatorisch einfacher auf aktuelle Schulungsbedarfe eingegangen werden. Hochschulen würde eine stärkere Beteiligung an Weiterbildungsmaßnahmen die Chance eröffnen, für die Erstausbildung erstellte elektronische Lerninhalte in der Weiterbildung wirtschaftlich zu verwerten, Partnerschaften zu Unternehmen einzugehen sowie eine dauerhafte Verbindung zu den ehemaligen Studenten zu unterhalten. Hochschulen können im Extremfall einen lebenslangen Bildungsvertrag mit ihren Studierenden abschließen und sie lebenslang individuell betreuen. Durch die analytische Auswertung der Profile der Teilnehmer können ihnen Bildungsangebote gemacht werden, die auf ihre gegenwärtige Karrieresituation ausgerichtet sind und den gewünschten nächsten Karriereschritt vorbereiten. Durch Quervergleiche mit Teilnehmern der gleichen Peergroup können sich die Teilnehmer einordnen und z. B. erfahren, womit sich andere Teilnehmer in einer ähnlichen Karrieresituation aktuell beschäftigen. Andererseits können Weiterbildungsinstitutionen der Wirtschaft auch in Wettbewerb zu Hochschulen treten. Bei aktuellen Themen können sie früher Inhalte anbieten und auch über ihr Image, z. B. als internationaler Technologieführer, anderen Hochschulen bei der Zertifizierung Konkurrenz machen. Hochschulen sind deshalb gut beraten, Kooperationsmodelle mit Unternehmen zu erarbeiten, in denen gemeinsam Lerninhalte erstellt und vertrieben werden. Dies gilt nicht nur für die Weiterbildung, sondern kann auch zu gemeinsamen Studiengängen zwischen Hochschulen und Unternehmen in der akademischen Erstausbildung führen. Generell führt die Digitalisierung der Lehre zu flexibleren Ausbildungs- und Weiterbildungsformen und diese vermischen sich untereinander. So können z. B. während der Berufstätigkeit leichter grundständige Studiengänge nachgeholt werden. Insgesamt können das Ausbildungssystem durchlässiger gestaltet und individuelle Bypass-Möglichkeiten geschaffen werden. 10.3.1.2.8 Analytics Universitäten nennen zur Demonstration ihres generellen Lehrerfolges häufig besonders erfolgreiche Lebenswege von Absolventen. Diese sind als Einzelfälle aber wenig aussagefähig für die generelle Erfolgswirkung. Um die Wirksamkeit von Lernformen zu untersuchen und für die Verbesserung der Lehre zu nutzen, sind deshalb statistische Verfahren bis hin zu KI-Systemen einzusetzen. Abbruchquoten von Studierenden bei bestimmten Kursen oder Veranstaltungen, Schnelltests nach kurzen Lerneinheiten, Befragungen der Studierenden über Verständnisschwierigkeiten usw. können analysiert und als Verbesserungspotenziale erarbeitet werden.

10.3 Die composable Hochschule

227

Mit Hilfe von Kameraaufnahmen der Augenbewegungen und Beobachtung der Körpersprache von Studierenden während eines Classroom-Trainings oder eines Videoconferencing können nachlassende Aufmerksamkeit bei bestimmten Lernsequenzen erfasst werden und daraufhin die Präsentation verbessert werden. Die Anwendung und Akzeptanz von analytischen Auswertungsverfahren betont die Wichtigkeit, die eine Hochschule ihrer Lehrfunktion beimisst. 10.3.1.2.9 Der Zeitdruck zur Transformation der Lehre wächst Bei einer Gegenüberstellung des gegenwärtigen Zustands der Lehre mit den digitalen Herausforderungen und Perspektiven zeigt sich, dass Hochschulen vor einem drastischen Transformationsprozess der Lehre stehen. Schließlich stammt der zentrale Begriff „Vorlesung“ aus dem Mittelalter, als es noch keine gedruckten Bücher gab und deshalb wertvolle Manuskripte von wandernden Professoren vorgelesen werden mussten. Trotzdem sind Vorlesungen heute immer noch zentrale Lernformen. Wenn aber beachtet wird, dass Hochschulen durch die Digitalisierung in zunehmend globalem Wettbewerb mit anderen Hochschulen stehen, neue Lern- und Betreuungsformen entstehen, dafür eine neue Infrastruktur aufgebaut werden muss, Studenten lebenslang durch Weiterbildung betreut werden können, neue, auf digitale Lernformate konzentrierte Hochschulen entstehen, Akademien aus der Wirtschaft in den Bildungsmarkt der Hochschulen eindringen und ihr Zertifizierungsmonopol aufweichen, dann hat der Begriff Zeitdruck zur Transformation seine Berechtigung. Die plattformorientierte IT-Architektur des Composable Enterprise hilft Hochschulen, den vielfältigen Anforderungen für neue studentenzentrierten Anwendungen nachzukommen.

10.3.2 Forschung in der composable Universität Durch die enge Verbindung von Forschung und Lehre sind einige der bei der Lehre aufgeführten Treiber der Digitalisierung auch für die Forschung gültig. Es werden deshalb vor allem zusätzliche forschungsspezifische Faktoren behandelt, die in Abb. 10.23 als Journey eines modernen Forschers dargestellt sind. Abb. 10.24 zeigt die daraus abgeleitete Anwendungsarchitektur. Die PBCs sind wiederum pauschal angegeben. Die um die Shared Services angeordneten Anwendungen können je nach Organisationsmodell dezentral in Varianten entwickelt und betrieben werden, wie ihre Faltung andeutet. Die digitale Forschungsunterstützung ist an Hochschulen weiter fortgeschritten als die Lehre. Gründe dafür sind, dass Forscher über Drittmittel mit eigener Verwendung verfügen, Forschung einen höheren Stellenwert besitzt und der einzelne Forscher bestrebt ist, sein Arbeitsumfeld so effektiv und effizient wie möglich zu gestalten, um sich in seiner wissenschaftlichen Community zu profilieren.

228

10

Digitale Branchenkonzepte für das Composable Enterprise

Abb. 10.23 Forschungs-Journey. (Quelle: Adobe Stock, PureSolution)

Abb. 10.24 Forschungsanwendungen. Die Faltung der Anwendungen kennzeichnet Varianten für selbstständige organisatorische Einheiten. (Quelle: Adobe Stock, PureSolution)

10.3 Die composable Hochschule

229

Trotzdem ist es für eine Hochschule wichtig, eine übergreifende Digitalisierungsstrategie für die Forschung zu erarbeiten. Viele Anwendungen, z. B. zur Datenauswertung, zur Plagiatserkennung usw., können hochschulweit eingesetzt werden und reduzieren die Kosten. Eine Hochschule, die ein überzeugendes Digitalisierungskonzept der Forschung besitzt, macht sich attraktiv für moderne Forscher und schafft sich damit einen Vorteil im internationalen Wettbewerb um die besten Forscherköpfe. Innerhalb einer Gesamtstrategie sollten in der composable Hochschule den Forschergruppen viel Freiraum zur Gestaltung ihrer digitalen Arbeit gegeben werden. Dazu ist die Nutzung der Application Composition Platform die passende Grundlage.

10.3.2.1 Neue Forschungsformate Die Geschwindigkeit der globalen Kommunikation zwischen Forschern nimmt durch das Internet drastisch zu. Es darf daran erinnert werden, dass das Internet, bzw. seine Erfolgskomponente World Wide Web (WWW) an dem Forschungsinstitut CERN in Genf zur Kommunikation zwischen Wissenschaftlern entwickelt wurde. Spezielle Internetplattformen wie beispielsweise ResearchGate oder Academia.edu verbinden weltweit Forscher. Der Forscher stellt seine Forschungsergebnisse in diese Forschungsplattformen ein und erhöht damit seine Visibilität. Es können Fragen an die Community gestellt werden, die umgehend beantwortet werden. Dies beschleunigt den Forschungsprozess. Auch müssen Ergebnisse nicht mehr in formalen Formaten wie Zeitschriftenaufsätzen oder Büchern veröffentlicht werden, sondern können in kleinen ergebnisbezogenen Darstellungen (Nanoergebnisse) über das Internet verbreitet werden. Forscher sind nicht mehr auf zeitraubende Begutachtungen ihrer bei „renommierten Zeitschriften“ eingereichten Beiträge angewiesen, sondern können ihre Beiträge eigenständig vorab veröffentlichen. Neben Textbeiträgen können dies z. B. auch selbst aufgenommene Videos von Fachvorträgen sein. Durch Plagiatssoftware können Veröffentlichungen automatisch auf ihre Originalität überprüft werden. Klassische Zeitschriften und Konferenzen mit ihren Begutachtungsverfahren wird es weiter geben, aber auch hier werden die Prozesse mehr und mehr digitalisiert und beschleunigt. Daneben bilden sich neue Formen der digitalen Evaluation von Forschern und Forschungsergebnissen heraus. Die Anzahl der Views, Downloads und Zitate sind Indikatoren der Wirksamkeit ihrer Arbeiten. Der bekannte H-Index misst die Wirkung, die ein Forscher auf die Forscher-Community anhand der Zitationen seiner Veröffentlichungen ausübt. Ähnlich werden auch Forscher in sozialen Netzen wie ResearchGate bewertet. Es ist zu erwarten, dass bei der Vergabe von Forschungsmitteln und Berufungen diese Messgrößen eine zunehmende Bedeutung finden. Diese werden die Veröffentlichungsstrategien von Forschern entsprechend beeinflussen und nicht nur positive Wirkungen besitzen.

230

10

Digitale Branchenkonzepte für das Composable Enterprise

10.3.2.2 Virtuelle Forschergruppen Forschungsministerien auf Länder-, Bundes- oder EU-Ebene fördern immer mehr Verbundprojekte, bei denen Forschungsinstitute und Wirtschaftsunternehmen zusammenarbeiten. Damit soll einerseits die interdisziplinäre Forschung gefördert werden und zum anderen eine schnellere Umsetzung der Ergebnisse in Produkte durch Kooperation mit Unternehmen erreicht werden. Die Zusammenstellung eines Forscherkonsortiums für eine Forschungsausschreibung ist ein komplexer Vorgang. Hier helfen Internetkontakte zum Auffinden entsprechender Partner, zur Abstimmung der Kompetenzen, der Antragserstellung und später auch zur Durchführung des Projektes. Videokonferenzen, verteiltes Arbeiten am gleichen Objekt durch Groupeware vereinfachen und beschleunigen den Bearbeitungsprozess. Es entstehen dadurch örtlich verteilte Forschergruppen aus unterschiedlichen Ländern und unterschiedlichen Organisationen, die sich über digitale Medien koordinieren und damit eine virtuelle Einheit bilden. 10.3.2.3 Datenmanagement Forschungsergebnisse werden häufig in Form von Daten dargestellt. Dieses können Messdaten aus naturwissenschaftlichen Versuchen sein, Statistikdaten über Patienten von medizinischen Untersuchungen usw. Bei dem „Open Data“-Ansatz sollen nicht nur verdichtete Daten zum offenen Zugriff für andere Forscher veröffentlicht werden, sondern auch die Rohdaten. Dadurch können Analysen jederzeit von anderen Forschern wiederholt werden. Dieses Konzept ist im akademischen Umfeld bei staatlich finanzierten Forschungsprojekten und auch bei staatlichen Datenbanken relativ leicht umsetzbar. Bei der Zusammenarbeit mit Wirtschaftsunternehmen ergeben sich aber Probleme mit dem Eigentumsrecht an Daten und deren Schutz. Hier müssen vor Beginn eines gemeinsamen Projektes entsprechende Vereinbarungen getroffen werden, die die Rechte der Partner an den Daten und ihre Veröffentlichung regeln. Neue Datenbankkonzepte (inmemory, non SQL, Data Lake) ermöglichen die RealTime-Auswertung auch großer Datenbestände. Hier eröffnen sich für die Forschung durch Paradigmenwechsel neue Wege. Einmal können für große Versuchsreihen die erhobenen Daten unverdichtet gespeichert und alle Analysen in Real-Time auf den Rohdaten in einem Data Lake durchgeführt werden. Alle verdichteten Daten werden aus der gleichen Quelle der Urdaten bei Bedarf in Real-Time erzeugt. Der Vorteil liegt darin, dass bei Änderungen der Rohdaten keine verdichteten Zwischenergebnisse nachkorrigiert werden müssen. Der zweite Paradigmenwechsel besteht darin, dass mittels Deep Learning Daten hypothesenfrei auf Muster oder Korrelationen untersucht werden können. So können auch fachfremde Forscher Zusammenhänge in Daten erkennen, die Fachspezialisten aufgrund ihrer einschränkenden Hypothesenorientierung nicht entdeckt hätten. Daten können aus klassischen Versuchen an realen Objekten (Patienten, technischen Versuchsanlagen) erhoben werden. Immer mehr werden aber auch die Forschungsobjekte

10.3 Die composable Hochschule

231

digital abgebildet und die Daten werden durch digitale Versuche in Form von Simulationen erhoben.

10.3.2.4 Projektmanagement Komplexe Forschungsprojekte mit vielen Beteiligten erfordern ein professionelles Projektmanagement. Die zeit- und kostengerechte Erstellung der Deliverables und korrekte Abrechnung der Fördermittel sind Voraussetzung für den Erhalt weiterer Unterstützungen. Moderne IT-Werkzeuge stehen zum Projektmanagement zur Verfügung. 10.3.2.5 Wissens- und Forschungstransfer Forschungseinrichtungen werden von ihren Förderern zunehmend hinsichtlich ihrer Nützlichkeit hinterfragt. Das bezieht sich insbesondere auf die Weitergabe von Wissen in Form von Weiterbildung und die wirtschaftliche Verwertbarkeit ihrer Forschungsergebnisse. Dies bedeutet keinen Gegensatz zur zweckfreien Grundlagenforschung, sondern zu einer Gesamtbetrachtung des Innovationszyklus von Grundlagenforschung, Anwendungsforschung, Produktentwicklung und erfolgreicher Vermarktung (vgl. Abb. 10.25). Die Grundlagenforschung entwickelt generische Erkenntnisse, die von der Anwendungsforschung in Anwendungsszenarien überführt werden, also z. B. Erkenntnisse der Physik in neue Fahrzeugantriebe. In der Forschung werden keine Produkte entwickelt, sondern höchstens Prototypen. Diese können von Start-Up-Unternehmen zu einsatzfähigen Produkten weiterentwickelt werden und durch eigenes Wachstum oder Kooperationen mit Großunternehmen zu einem internationalen Markterfolg geführt werden. In Deutschland besteht mit öffentlich geförderten Forschungsorganisationen wie der Max-Planck-Gesellschaft und Universitätsinstituten eine gute Infrastruktur für die Grundlagenforschung. Für die Anwendungsforschung stehen stellvertretend die Institute der

Abb. 10.25 Innovationsprozess

232

10

Digitale Branchenkonzepte für das Composable Enterprise

Fraunhofer Gesellschaft oder der Helmholtz Gemeinschaft. Danach tut sich aber eine Lücke in der Weiterverwertung der Forschungsergebnisse auf. So finden sich für die öffentlichen Informatikausgaben in Milliardenhöhe keine entsprechenden Erfolgsunternehmen für Hard- oder Softwareprodukte aus Deutschland. Vielmehr wird dieser Markt in Software von den USA und im Bereich Hardware von Asien dominiert. Zwar hat sich mit Gründerzentren, staatlicher finanzieller Unterstützung, Investorenkapital und hoher medialer Aufmerksamkeit das Gründungsklima für Start-Up-Unternehmen in Deutschland verbessert, aber es sind noch immer zu wenig international bedeutende Unternehmen daraus hervorgegangen. Die schnell genannten Unternehmen SAP AG oder Software AG zeigen nur, dass es keine mehrstellige Anzahl an Erfolgsbeispielen gibt. Die drei beteiligten Strukturen – Forschung, Start-Up- und Großunternehmen – weisen unterschiedliche Vor- und Nachteile auf (vgl. Abb. 10.26). Die (akademische) Forschung ist flexibel bei der Behandlung neuer Themen. Da sie maximal Prototypen erstellt, kann sie schnell neue Themen aufnehmen. Die Wissenschaftler sind hoch motiviert und haben deshalb eine hohe Geschwindigkeit bei der Erzielung von Ergebnissen. Sie sind in internationale Netzwerke eingebunden und erfahren dadurch die neuesten Forschungstrends. Start-Up-Unternehmen starten auf der grünen Wiese und vermeiden deshalb den Innovator’s Dilemma-Effekt. Sie erfahren aufgrund ihres beschränkten Budgets schnell, ob ihre Idee Erfolg verspricht oder ob sie das Geschäftsmodell ändern müssen (fast fail). In Großunternehmen werden dagegen einmal aufgesetzte Entwicklungsprojekte von den Verantwortlichen immer wieder neu zu verlängern versucht, obwohl die geplanten Ziele nicht erreicht wurden. Allerdings sind die Gründerteams von Start-Ups häufig fragil, da sich nach einiger Zeit unterschiedliche Interessen herausstellen, die zu einem Scheitern führen können. Abb. 10.26 Promotoren des Innovationsprozesses

10.3 Die composable Hochschule

233

Großunternehmen besitzen hohe Ressourcen in Form von Vertriebsstrukturen, Kundenbeziehungen und Kapital. Es liegt nahe, die Vorteile der drei Strukturen miteinander zu verbinden. Eine Hochschule sollte deshalb bei der Verwertungsabsicht von Forschungsergebnissen alle drei Komponenten beachten. Allein die Gründung von Start-Ups herauszustellen ist wenig eindrucksvoll, wenn diese nicht auch langfristig wachsen und Arbeitsplätze schaffen. Sie sollte deshalb ein Innovationsnetzwerk aus den drei Typen aufbauen. Der dargestellte Innovationsprozess zeigt einen sequenziellen Ablauf. Die zunehmende Geschwindigkeit schiebt aber die Kreise immer mehr zusammen zu dem Modell der Abb. 10.27. Forschung, Unternehmensgründungen sowie starke Ressourcen und Vertriebswege großer Unternehmen vernetzen sich und arbeiten zeitlich eng zusammen. Universitäten bewerben sich um die Auszeichnung als Gründeruniversität, um ihren Innovationsbeitrag zu demonstrieren. Sie unterstützen Unternehmungsgründungen und sind stolz auf erfolgreiche Beispiele. Das Unternehmen Google ist aus der Stanford University hervorgegangen, indem der zunächst für die Verwaltung der Universitätsbibliothek entwickelte Suchalgorithmus zu einem allgemeinen Produkt weiterentwickelt wurde. Auch Facebook war zunächst von dem Studenten Marc Zuckerberg als eine Campus-Lösung für die Harvard University entwickelt worden. Auch der Autor hat mit seinen Ausgründungen aus der Universität des Saarlandes gezeigt, dass Spin-offs aus deutschen Universitäten international erfolgreich sein können. Dieses zeigen auch die Technologieparks um Hochschulen in Berlin, Aachen, München oder Karlsruhe. Hochschulen können diese Tendenz unterstützen, indem sie ihre eigene Struktur als Testbett für innovative Lösungen zur Verfügung stellen. Dieses ist nach den Erfahrungen des Verfassers wirksamer als finanzielle Hilfen. Abb. 10.27 Vernetzter Innovationsprozess

234

10

Digitale Branchenkonzepte für das Composable Enterprise

10.3.3 Zentrale Dienste als Shared Services in der composable Hochschule In Abb. 10.28 sind die Anwendungen der zentralen Dienste angegeben. Da die Anwendungen zentral zur Verfügung gestellt werden, sind keine Varianten vorgesehen und deshalb nicht gefaltet. Im Zentrum steht das Rechnungswesen, das alle Geschäftsvorfälle in der Wertebene erfasst. In vielen Hochschulen ist bereits für die Digitalisierung ein CIO (Chief Information Officer) eingeführt. Häufig ist er dem Vizepräsidenten für Verwaltung zugeordnet. In Hochschulen, die den strategischen Einfluss der Digitalisierung erkannt haben, besitzt er auch selbst die Stellung eines Vizepräsidenten. Er kann dadurch Treiber der Digitalisierung sein, indem er die gesamte Digitalisierungsstrategie der Hochschule verantwortlich entwickelt, die Infrastruktur bereitstellt und betreibt, die Softwarestrategie definiert sowie den Fakultäten und Dozenten Anregungen für ihre dezentralen Anwendungen gibt.

Abb. 10.28 Zentrale Dienste als Shared Services. Da die Anwendungen der Shared Services nur einmal (zentral) bestehen, sind sie nicht gefaltet. (Quelle: Adobe Stock, PureSolution)

10.3 Die composable Hochschule

235

Für die Funktionen Haushalt- und Drittmittelmanagement, Personalwesen, Beschaffung und Gebäudemanagement ist an vielen Hochschulen in den letzten Jahren Standardsoftware, insbesondere integrierte ERP-Software, eingesetzt worden. Gleichzeitig wurde der Übergang von der kameralistischen zur kaufmännischen Buchführung vollzogen, sodass Hochschulen auch einen betriebswirtschaftlichen Jahresabschluss erstellen können. Die Bezüge der Zentralen Dienste bzw. Shared Services zu den Leistungsprozessen Lehre und Forschung sind offensichtlich. Müssen Studenten für bestimmte Leistungen der Hochschule, wie Parkplatznutzung, Mensaessen usw. Beiträge bezahlen, so besteht eine Verbindung zwischen Campusmanagement und Finanzsoftware. Werden bei Weiterbildungsmaßnahmen Gebühren erhoben, so ist eine Verbindung zwischen Teilnehmerverwaltung und Finanzsystem gegeben. Forscher sind als Mitarbeiter der Hochschule im Personalsystem erfasst. Das Talentmanagement umfasst die Personalbeschaffung sowie -entwicklung von wissenschaftlichen und nichtwissenschaftlichen Mitarbeitern. Für die zur Lehre und Forschung anzuschaffenden Ressourcen wird das zentrale Beschaffungssystem genutzt. Die Prognose der Gebäudebelegung aus der Auswertung von Daten des Campusmanagements und der Lernsysteme ist wichtig für das Facility-Management. Diese wenigen Beispiele zeigen, wie eng die Leistungsprozesse einer Hochschule Forschung und Lehre mit Verwaltungsfunktionen verknüpft sind. Nur wenn die Verwaltung innovativ ist, können auch die Bereiche Lehre und Forschung in die digitale Zukunft schreiten. Dieses wurde bei den Anwendungen zu Lehre und Forschung deutlich gemacht, indem das Ressourcenmanagement als Shared Services in den Mittelpunkt gestellt wurden.

10.3.4 Strategieentwicklung für die composable Hochschule Die Digitalisierung umfasst alle Bereiche einer Hochschule und deshalb kann auch nur eine ganzheitliche Strategie erfolgreich sein. Durch das „Hinterherhecheln“ bei einer einzelnen Komponente, z. B. der schnellen Anfertigung eines MOOCs für die Lehre, kann man nicht mehr Erster im Innovationswettlauf werden. Deshalb ist es sinnvoller, die Erfolgstreiber der Digitalisierung zu identifizieren, mit den Chancen der Hochschule zu ihrer Nutzung zu gewichten und daraus das Profil der Hochschule zu entwickeln. Allein aus Sicht der Lehre können unterschiedliche Profile gebildet werden. So kann sich eine Hochschule auf die Individualisierung der Lehre, die Betonung der Fähigkeiten anstelle von Faktenwissen bei der Ausbildung und die lebenslange Betreuung konzentrieren. Ein anderer Hochschultyp betont die Internationalität, bietet ihren digitalen Lehrstoff mehrsprachig an, akquiriert durch einen interessanten Internetauftritt viele ausländische Studenten für ihre digitalen Lehrangebote und ist dadurch auch stolz auf viele internationale Präsenzstudenten.

236

10

Digitale Branchenkonzepte für das Composable Enterprise

Ein dritter Hochschultyp kann sich auf die Entwicklung und den Einsatz neuester Lerntechnologien konzentrieren und damit eine Technologieführerschaft anstreben. Ein vierter Hochschultyp kooperiert besonders intensiv mit der Wirtschaft und führt gemeinsame Studiengänge ein. Er nutzt damit auch aktuelles Lehrmaterial der Unternehmen und gestaltet die Ausbildung besonders anwendungsnah. Eine extreme Strategie kann sein, eine Start-Up-Hochschule als Tochterunternehmen zu gründen, die von vornherein nur digitale Lehre als digitale Fernhochschule anbietet. Dies kann auch von Privatinvestoren als private Hochschule initiiert werden. Auch bezüglich der Digitalisierung der Forschung sind unterschiedliche Profilierungen von Hochschulen möglich. Als „Digitalisierungshochschule“ führt sie Forschungsprojekte möglichst digital durch, d. h. anstelle von Versuchen mit realen Geräten und Substanzen arbeitet sie mit deren digitalen Zwillingen. Sie umgeht damit teure Investitionen in reale naturwissenschaftliche Werkstätten oder Laboratorien und konzentriert sich auf die nächste Generation digitaler Forschungsmöglichkeiten. Diese Strategie ist gerade für Einsteiger in neue Disziplinen interessant. Eine andere Strategie besteht darin, internationale, virtuelle Forschernetze zu pflegen und damit auf internationalem Spitzenniveau neueste Themen zu bearbeiten. Die großen digitalen Veränderungen in allen Gebieten der Hochschule erfordern somit eine Zukunftsvision, auf die sich alle Aktivitäten ausrichten können. Credo der Branchenkonzepte Die Ausführungen zu den Branchenkonzepten haben den erheblichen Innovationsdruck, aber auch die Chancen der digitalen Transformation gezeigt. Die Architektur der Application Composition Platform bietet dafür die nötige Flexibilität, um Unternehmen in die Lage zu versetzen, die Herausforderungen zu bestehen und die Chancen zu nutzen.

Literatur Adisorn, T., Tholen, L., & Götz, T. (2021). Towards a digital product passport fit for contributing to a circular economy. Energies, 14(8), 2289. Bauernhansl, T. (2017). Die Vierte Industrielle Revolution – Der Weg in ein wertschaffendes Produktionsparadigma. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 12). Wiesbaden: Springer Vieweg. Bauernhansl, T., Ten Hompel, M., & Vogel-Heuser, B. (Hrsg.). (2017). Allgemeine Grundlagen. Handbuch Industrie 4.0, Bd. 4 (S. 1–285). Wiesbaden: Springer Vieweg. Büttner, K. H., & Brück, U. (2017). Use Case Industrie 4.0 – Fertigung im Siemens Elektronikwerk Amberg. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 45–70). Wiesbaden: Springer Vieweg. Greff, T., Winter, F., & Werth, D. (2018). Digitale Geschäftsmodelle in der Domäne wissensintensiver Dienstleistungen – Stand der Forschung und Transfer in die Unternehmensberatung. In P.

Literatur

237

Drews, B. Funk, P. Niemeyer & L. Xie (Hrsg.), Tagungsband der Multikonferenz Wirtschaftsinformatik (MKWI) 2018 (S. 1316–1328). Lüneburg: Leuphana University. Greff, T., Schäfer, S., & Werth, D. (2022). Schritt für Schritt zur Digitalen Transformation der Unternehmensberatung. In T. Deelman & D. M. Ockel (Hrsg.), Handbuch der Unternehmensberatung (HdU). 7318. IS Predict. (2017). Künstliche Intelligenz (KI) zur vorausschauenden Analyse und Steuerung. https:// www.ispredict.com/download/IS%20Predict%20-%20Flyer%20-%20DE.PDF. Zugegriffen: 9. Aug. 2023. Kagermann, H., Lukas, W. D., & Wahlster, W. (2011). Industrie 4.0: Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution. VDI nachrichten, 13(1), 2–3. Kim, W. C., & Mauborgne, R. (2004). Blue ocean strategy: How to create uncontested market space and make the competition irrelevant. Boston: Harvard Business School Publishing. Kurniawan, E., Benda, D., Sun, S., Tan, S. G., & Chin, A. (2021). Blockchain for secure and transparent track-and-trace in manufacturing. Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing (S. 337–376). Langmann, R. (2021). Vernetzte Systeme für die Automatisierung 4.0: Bussysteme – Industrial Ethernet – Mobile Kommunikation – Cyber-Physical Systems. München: Hanser. Leimeister, J. M. (2021). Einführung in die Wirtschaftsinformatik (13. Aufl.). Springer Gabler. Lepratti, R., Lamparter, S., & Schröder, R. (Hrsg.). (2014). Transparenz in globalen Lieferketten der Automobilindustrie: Ansätze zur Logistik- und Produktionsoptimierung. Erlangen: Publicis Publishing. Lim, K. Y. H., Le, N. T., Agarwal, N., & Huynh, B. H. (2021). Digital twin architecture and development trends on manufacturing topologies. Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing (S. 259–286). Neuscheler, T. (2018). Unternehmensberater – Die Stunde der Algorithmen. Frankfurter Allgemeine Zeitung (FAZ). http://www.faz.net/-gym-97fbt. Zugegriffen: 1. März 2018. Plociennik, C., Pourjafarian, M., Nazeri, A., Windholz, W., Knetsch, S., Rickert, J., & Weidenkaff, A. (2022). Towards a digital lifecycle passport for the circular economy. Procedia CIRP, 105, 122–127. Pötter, T., Folmer, J., & Vogel-Heuser, B. (2017). Enabling Industrie 4.0 – Chancen und Nutzen für die Prozessindustrie. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 71–83). Wiesbaden: Springer Vieweg. Rifkin, J. (2014). Die Null Grenzkosten Gesellschaft – Das Internet der Dinge, kollaboratives Gemeingut und der Rückzug des Kapitalismus. Frankfurt: Campus. Scheer, A.-W. (1987). CIM Computer integrated manufacturing: Der computergesteuerte Industriebetrieb (1. Aufl.). Berlin: Springer. Scheer, A.-W. (1990). CIM Computer integrated manufacturing: Der computergesteuerte Industriebetrieb (4. Aufl.). Berlin: Springer. https://doi.org/10.1007/978-3-642-61510-8. Schmid, U., Thom, S., & Görtz, L. (2016). Ein Leben lang digital lernen – neue Weiterbildungsmodelle aus Hochschulen. (Arbeitspapier No. 20). Berlin: Hochschulforum Digitalisierung. https:// hochschulforumdigitalisierung.de/de/ein-leben-lang-digital-lernen-arbeitspapier-20. Toro, C., Wang, W., & Akhtar, H. (2021). Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing. Cham: Springer. Vogel-Heuser, B. (2017). Herausforderungen und Anforderungen aus Sicht der IT und der Automatisierungstechnik. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 33). Wiesbaden: Springer Vieweg. Wannemacher, K., Jungermann, I., Scholz, J., Tercanli, H., & Villiez, A. (2016). Digitale Lernszenarien im Hochschulbereich. Arbeitspapier No. 15. Berlin: Hochschulforum Digitalisierung. https://hochschulforumdigitalisierung.de/de/studie-digitale-lernszenarien-hochschulbereich.

238

10

Digitale Branchenkonzepte für das Composable Enterprise

Weißenberger, B. (12. März 2018). Es geht um Wahrheit – Nicht um Mehrheit. Frankfurter Allgemeine Zeitung (FAZ), S. 18. Xu, L., Cabri, G., Aiello, M., Mecella, M., & de Vrieze, P. (2018). Twin planning: Virtual and real factory planning. Fachmagazin IM+io, 33(1), 70–73.

Weiterführende Literatur Breyer-Mayländer, T. (2022). Industrie 4.0 bei Hidden Champions. Wiesbaden: Springer Gabler. Forschungsbeirat der Plattform Industrie 4.0/ acatech (2021). Impulsbericht Industrie 4.0 – Forschung für die Gestaltung der Zukunft Greff, T., & Werth, D. (2015). Auf dem Weg zur digitalen Unternehmensberatung. Fachmagazin IM+io, 30(1), 30–34. IT-Gipfel (2016). IT-Gipfel 2016 mit Thema digitale Bildung als Schwerpunkt. www.it-gipfel.de. Zugegriffen: 18. Juli 2016. Scheer, A.-W. (2015). Hochschule 4.0. Saarbrücken: Scheer. Scheer, A.-W. (2017). Hochschule 4.0. In E-Learning 4.0 (S. 101–123). Oldenbourg: De Gruyter. Scheer, A.-W., & Wachter, C. (Hrsg.). (2018). Digitale Bildungslandschaften (2. Aufl.). imc. Udacity (2018). Online-Kurse, die mehr sind als nur Lerninhalte. https://de.udacity.com/nanodegree. Zugegriffen: 22. Mai 2018. Wahlster, W. (2017). Industrie 4.0: das Internet der Dinge kommt in die Fabriken. Universität Mainz. Vorlesungsreihe. Werth, D., & Greff, T. (2017). Und sie skaliert doch! – Skalierbarkeit als erfolgskritischer Faktor auch in der Digitalen Beratung. Fachmagazin IM+io, 31(1), 64–69. Werth, D., Greff, T., & Scheer, A.-W. (2016). Consulting 4.0 – Die Digitalisierung der Unternehmensberatung. HMD Praxis Der Wirtschaftsinformatik, 53(1), 55–70. Werth, D., Zimmermann, P., & Greff, T. (2017). Self-service consulting: Conceiving customeroperated digital IT consulting services. In Twenty-second Americas Conference on Information Systems AMCIS 2017 (S. 1–10).

Literatur (Gesamt)

Abolhassan, F. (2017). Robotic Process Automation macht Unternehmen produktiver – wenn sie die Mannschaft mitnehmen. Fachmagazin IM+io, 32(3), 6–11. Adisorn, T., Tholen, L., & Götz, T. (2021). Towards a digital product passport fit for contributing to a circular economy. Energies, 14(8), 2289. Andreessen, M. (20. August 2011). Why Software is eating the world. The Wall Street Journal. Auberger, L., & Kloppmann, M. (2017). Digital process automation with BPM and blockchain, Part 1: Combine business process management and blockchain. AWSi (2018). Paradigmen der Digitalisierung organisatorisch umsetzen. Fachmagazin IM+io, 33(1), 84–85. Bauernhansl, T. (2017). Die Vierte Industrielle Revolution – Der Weg in ein wertschaffendes Produktionsparadigma. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 12). Wiesbaden: Springer Vieweg. Bauernhansl, T., Ten Hompel, M., & Vogel-Heuser, B. (Hrsg.). (2017). Allgemeine Grundlagen. Handbuch Industrie 4.0, Bd. 4 (S. 1–285). Wiesbaden: Springer Vieweg. Baums, A., Schössler, M., & Scott, B. (2015). Industrie 4.0: Wie digitale Plattformen unsere Wirtschaft verändern – und wie die Politik gestalten kann. Kompendium Digitale Standortpolitik, Bd. 2. Berlin: Stiftung neue Verantwortung e. V. http://plattform-maerkte.de/wp-content/uploads/ 2015/11/Kompendium-High.pdf. ZUgegriffen: 9. Aug. 2023. Bergmann, F. (2017). Neue Arbeit, Neue Kultur. Freiburg: Arbor. Bezerra, F., & Wainer, J. (2013). Algorithms for anomaly detection of traces in logs of process aware information systems. Information Systems, 38(1), 33–44. BMWi (2020). Gaia-x: Das europäische Projekt startet in die nächste Phase. https://www.bmwk.de/ Redaktion/DE/Dossier/gaia-x.html. Zugegriffen: 21. Febr. 2023. Bock, C., & Frank, U. (2021). Low-code platform. Business Information System Engineering, 63(6), 733–2021. Bornet, P., Barkin, I., & Wirtz, J. (2021). Intelligent automation. Hackensack: Lulu.com. Breyer-Mayländer, T. (2022). Industrie 4.0 bei Hidden Champions. Wiesbaden: Springer Gabler. Brynjolfsson, E., & McAfee, A. (2014). The second machine age: Work, progress, and prosperity in a time of brilliant technologies. New York: Norton. Bundesministerium für Bildung und Forschung (BMBF) (Ed.) (2017). Digitale Innovationen – Neue Dimensionen von Bildung und Wissenschaft erschließen. Abschlussbericht der Plattform „Digitalisierung in Bildung und Wissenschaft“. September 2017. Burattin, A. (2015). Process mining techniques in business environments: Theoretical aspects, algorithms, techniques and open challenges in process mining. Cham: Springer. Burgwinkel, D. (Ed.) (2016). Blockchain Technology: Einführung für Business- und IT Manager. Oldenbourg: Walter de Gruyter. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 A.-W. Scheer, Composable Enterprise: agil, flexibel, innovativ, https://doi.org/10.1007/978-3-658-42483-1

239

240

Literatur (Gesamt)

Büttner, K. H., & Brück, U. (2017). Use Case Industrie 4.0 – Fertigung im Siemens Elektronikwerk Amberg. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 45–70). Wiesbaden: Springer Vieweg. Cappiello, C., Comuzzi, M., Plebani, P., & Fim, M. (2022). Assessing and improving measurability of process performance indicators based on quality of logs. Information Systems, 103, 101874. Cerniauskas, T., & Werth, D. (2022). Industry goes Metaverse. Die Verschmelzung realer und virtueller Industriewelten am Beispiel der Abwasserwirtschaft. Fachmagazin IM+io, 37(2), 64–67. Christensen, C. M. (1997). The innovator’s dilemma: When new technologies cause great firms to fail. Boston: Harvard Business School Press. Deloitte (2017). Automate this – The business leader’s guide to robotic and intelligent automation: Service delivery transformation. https://www2.deloitte.com/content/dam/Deloitte/us/ Documents/process-and-operations/us-sdt-process-automation.pdf. Zugegriffen: 22. Mai 2018. EFI (2015). Expertenkommission Forschung und Innovation (EFI), Jahresgutachten zu Forschung, Innovation und technologischer Leistungsfähigkeit Deutschlands 2015. http://www.e-fi.de/ gutachten.html. Zugegriffen: 22. Mai 2018. Ertel, W. (2016). Grundkurs Künstliche Intelligenz: Eine praxisorientierte Einführung (4. Aufl.). Wiesbaden: Springer. https://doi.org/10.1007/978-3-658-13549-2. Europäischer Rat (2022). „Fit für 55“ Der EU-Plan für den grünen Wandel. https://www. consilium.europa.eu/de/policies/green-deal/fit-for-55-the-eu-plan-for-a-green-transition/. Zugegriffen: 21. Febr. 2023. Ferreira, D. R. (2017). A primer on process mining: Practical skills with python and graphviz. Cham: Springer. https://doi.org/10.1007/978-3-319-56427-2. Finlay, S. (2017). Artificial intelligence and machine learning for business: A no-nonsense guide to data driven technologies (2. Aufl.). Preston: Relativistic Books. Fleischmann, A., Oppl, S., Schmidt, W., & Stary, Ch (2020). Contextual process digitalization: Changing perspectives – design thinking – value-led design. Cham: Springer. Forrester Research (2011). The Role of IT in Business-Driven Process Automation (Forrester Consulting Thought Leadership Paper). Cambridge. Forrester Research (2014). Building a Center of Expertise to Support Robotic Automation - Preparing for the Life Cycle of Business Change. https://www.blueprism.com/wpapers/forresterreport-building-center-expertise-support-robotic-automation. Zugegriffen: 22. Mai 2018. Forschungsbeirat der Plattform Industrie 4.0/ acatech (2021). Impulsbericht Industrie 4.0 – Forschung für die Gestaltung der Zukunft Fung, H. P. (2014). Criteria, use cases and effects of Information Technology Process Automation (ITPA). Advances in Robotics & Automation, 3(3), 1–10. Gadatsch, A. (2020). Grundkurs Geschäftsprozess-Management: Analyse, Modellierung, Optimierung und Controlling von Prozessen (9. Aufl.). Wiesbaden: Springer-Vieweg. Gartner (Hrsg.). (2021). Market guide for application integration platforms, G00737100 Gartner (2021). Future of applications: Delivering the composable enterprise ID: G00465932 (S. 3–4). Gaughan, D., Natis, Y., Alvarez, G., & O’Neill, M. (2020). Future of applications: delivering the composable enterprise. Giese, P. (2016). Die Blockchain Bibel: DNA einer revolutionären Technologie. North Charleston: Createspace Independent Publishing Platform. Goel, A., & Agarwal, R. (2021). Operation research. Technical Publications. Greff, T., & Werth, D. (2015). Auf dem Weg zur digitalen Unternehmensberatung. Fachmagazin IM+io, 30(1), 30–34.

Literatur (Gesamt)

241

Greff, T., Schäfer, S., & Werth, D. (2022). Schritt für Schritt zur Digitalen Transformation der Unternehmensberatung. In T. Deelman & D. M. Ockel (Hrsg.), Handbuch der Unternehmensberatung (HdU). 7318. Greff, T., Winter, F., & Werth, D. (2018). Digitale Geschäftsmodelle in der Domäne wissensintensiver Dienstleistungen – Stand der Forschung und Transfer in die Unternehmensberatung. In P. Drews, B. Funk, P. Niemeyer & L. Xie (Hrsg.), Tagungsband der Multikonferenz Wirtschaftsinformatik (MKWI) 2018 (S. 1316–1328). Lüneburg: Leuphana University. Grinschuk, E. (2017). Blockchain – Ein neuer GameChanger: Funktion, Kryptowährungen, Trends und Möglichkeiten – Kurze Einführung (2. Aufl.). Hammer, M., & Champy, J. (1993). Reengineering the corporation: A manifesto for business revolution. Business Horizons, 36(5), 90–91. Hansen, H. R., Mendling, J., & Neumann, G. (2019). Wirtschaftsinformatik (12. Aufl.). Berlin, Boston: De Gruyter. Heeg, T. (9. Juli 2017). Programme buchen 90 Prozent der Fälle korrekt – Die Genossenschaft Datev will die Finanzbuchhaltung der Unternehmen automatisieren. Frankfurter Allgemeine Zeitung (FAZ). Hegewald, F. (2022). Gaming meets Learning. Was wir heute schon über das Lernen von morgen wissen. Fachmagazin IM+io, 37(2), 104–105. Horvath & Partners (2018). Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Frankfurt: Horvath & Partners. IBM (2016). Robotic Process Automation – Leading with Robotics and Automation in a fastpaces, digitally disruptive environment. IDC (2022). Intelligent Process Automation in Deutschland 2022 IEEE Task Force on Process Mining (2012). Process mining manifesto. http://www.win.tue.nl/ ieeetfpm/doku.php?id=shared:process_mining_manifesto. Zugegriffen: 22. Mai 2018. imc (2017a). imc Process Guide – Produktpräsentation. https://www.im-c.com. Zugegriffen: 22. Mai 2018. imc (2017b). Informelles Lernen und Electronic Performance Support – So können Sie Ihre internen Helpdesk-Kosten um 40 % senken. https://www.im-c.com. Zugegriffen: 22. Mai 2018. imc (2017c). AR/VR Training – Zum Einsatz von Augmented & Virtual Reality im Corporate Training. https://www.im-c.com. Zugegriffen: 22. Mai 2018. Inspirient (2017). Automated pattern recognition with Inspirient software RPA. www.inspirient. com. Zugegriffen: 22. Mai 2018. Institute for Robotic Process Automation (2015). Introduction to robotic process automation: A primer. Carnegie Mellon University, Institute for Robotic Process Automation. Institute for Robotic Process Automation (2016). Smart Process Automation: The Why, What, How and Who of the Next Quantum Leap in Enterprise Productivity. WorkFusion. Institute for Robotic Process Automation, & NICE (2016). RPA is Transforming Business Processes - Delivering Fast, Accurate Service, and Improving Customer Experience. https://www.nice. com/websites/rpa/white_paper.html. Zugegriffen: 22. Mai 2018. Institute for Robotic Process Automation, & EdgeVerve (2017). Turbo-Charging your process automation. http://go.outsourcing.com/EdgeverveWP1. Zugegriffen: 22. Mai 2018. Ismail, S., Malone, M. S., van Geest, Y., & Diamandis, P. H. (2014). Exponential organizations: Why new organizations are ten times better, faster, and cheaper than yours (and what to do about it). New York: Diversion Books. IS Predict (2017). Totalschaden durch vorausschauende Wartung vermeiden. www.ispredict.com/ri/ smart-production. Zugegriffen: 22. Mai 2018.

242

Literatur (Gesamt)

IS Predict. (2017). Künstliche Intelligenz (KI) zur vorausschauenden Analyse und Steuerung. https:// www.ispredict.com/download/IS%20Predict%20-%20Flyer%20-%20DE.PDF. Zugegriffen: 9. Aug. 2023. IT-Gipfel (2016). IT-Gipfel 2016 mit Thema digitale Bildung als Schwerpunkt. www.it-gipfel.de. Zugegriffen: 18. Juli 2016. Jost, W. (2022). Application composition platforms. Vortrag vor den Mitgliedern des Feldafinger Kreises, Feldafing, 22. Juli 2022. Kaplan, J. (2017). Künstliche Intelligenz - Eine Einführung (1. Aufl.). Frechen: mitp Verlag. Kagermann, H., Lukas, W. D., & Wahlster, W. (2011). Industrie 4.0: Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution. VDI nachrichten, 13(1), 2–3. Kassen, M. (2022). Blockchain and e-government innovation: Automation of public information processes. Information Systems, 103(101862), 1–11. Keller, G., Nüttgens, M., & Scheer, A.-W. (1992). Semantische Prozessmodellierung. Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi) Saarbrücken, Nr. 89. Kim, W. C., & Mauborgne, R. (2004). Blue ocean strategy: How to create uncontested market space and make the competition irrelevant. Boston: Harvard Business School Publishing. Kirchmer, M. (2017). High Performance Through Business Process Management. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-51259-4. Knauer, A., Stareprawo-Hofmann, M., & Mühl, K. Y. (2022). Smart, smarter, Mittweida! Eine Region wird zum Aushängeschild für Blockchain und Metaverse. Fachmagazin IM+io, 37(2), 78– 81. Koop, A., & Moock, H. (2018). Lineare Optimierung – eine anwendungsorientierte Einführung in Operations Research. Springer Spektrum. Krcmar, H. (2015). Informationsmanagement (6. Aufl.). Berlin Heidelberg: Springer Gabler. Kruse, R., Borgelt, C., Braune, C., Klawonn, F., Moewes, C., & Steinbrecher, M. (2015). Computational Intelligence: Eine methodische Einführung in Künstliche Neuronale Netze, Evolutionäre Algorithmen, Fuzzy-Systeme und Bayes-Netze (2. Aufl.). Wiesbaden: Springer Vieweg. https:// doi.org/10.1007/978-3-658-10904-2. Kryon www.Kryonsystems.com. Zugegriffen: 1. Juni 2021. Kurniawan, E., Benda, D., Sun, S., Tan, S. G., & Chin, A. (2021). Blockchain for secure and transparent track-and-trace in manufacturing. Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing (S. 337–376). Kutzner, C., Jurisic, S., Stonis, M., Nyhuis, P., & Seiter, M. (2022). Robotergesteuerte Prozessautomatisierung zur softwarebasierten Automatisierung administrativer Prozesse der innerbetrieblichen Lieferkette (RPAlog). Logistics Journal. https://www.logistics-journal.de/not-reviewed/ 2022/12/5623/kutzner_2022-12.pdf. Zugegriffen: 9. Aug. 2023. Lacity, M. C., Willcocks, L. P., & Craig, A. (2015). Robotic process automation: Mature capabilities in the energy sector. Outsourcing Unit Working Research Paper Series No. 15/06. London: LSE Outsourcing Unit. Langmann, R. (2021). Vernetzte Systeme für die Automatisierung 4.0: Bussysteme – Industrial Ethernet – Mobile Kommunikation – Cyber-Physical Systems. München: Hanser. Lankhorst, M., et al. (2017). Enterprise architecture at work (4. Aufl.). Berlin Heidelberg: Springer. Laue, R., Koschmider, A., & Fahland, D. (Hrsg.). (2021). Prozess-Management und ProcessMining: Grundlagen. Berlin: De Gruyter. Leimeister, J. M. (2021). Einführung in die Wirtschaftsinformatik (13. Aufl.). Springer Gabler. Lepratti, R., Lamparter, S., & Schröder, R. (Hrsg.). (2014). Transparenz in globalen Lieferketten der Automobilindustrie: Ansätze zur Logistik- und Produktionsoptimierung. Erlangen: Publicis Publishing.

Literatur (Gesamt)

243

Lim, K. Y. H., Le, N. T., Agarwal, N., & Huynh, B. H. (2021). Digital twin architecture and development trends on manufacturing topologies. Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing (S. 259–286). Linn, C., & Werth, D. (2016). Sequential anomaly detection techniques in business processes. In W. Abramowicz, R. Alt & B. Franczyk (Hrsg.), Business information systems workshops. BIS 2016 international workshops, Leipzig, July 6–8. (S. 196–208). Revised Papers. Linn, C., Bender, S., Prosser, J., Schmitt, K., & Werth, D. (2017). Virtual remote inspection – A new concept for virtual reality enhanced real-time maintenance. In 2017 23rd International Conference on Virtual System & Multimedia (VSMM) (S. 1–6). IEEE. https://doi.org/10.1109/VSMM. 2017.8346304. Mans, R. S., van der Aalst, W. M. P., & Vanwersch, R. J. B. (2015). Process mining in healthcare: Evaluating and exploiting operational healthcare processes. Cham: Springer. https://doi.org/10. 1007/978-3-319-16071-9. Mathijssen, M., Overeem, M., & Jansen, S. (2020). Identification of practices and capabilities in API management: A systematic literature review. Tech. rep. Utrecht University. http://arxiv.org/ abs/2006.10481 Matthes, D. (2011). Enterprise Architecture Frameworks Kompendium (S. 72). Heidelberg: insb. McGann, B. S. (2015). Where is the Action Today in Intelligent Automation? https://irpaai.com/ where-is-the-action-today-in-intelligent-automation/. Zugegriffen: 22. Mai 2018. Meinel, C., & Krohn, T. (2022). Design Thinking in der Bildung, Innovation kann man lernen. Weinheim: Wiley. Meinel, C., Gayvoronskaya, T., & Schnjakin, M. (2018). Blockchain: Hype oder Innovation (Technische Berichte des Hasso-Plattner-Instituts für Digital Engineering an der Universität Potsdam No. 113). Potsdam. Multiply (2016). Wodurch unterscheidet sich der Transaction Monitor von anderen Ansätzen. Munoz-Gama, J. (2016). Conformance checking and diagnosis in process mining: Comparing observed and modeled processes. Cham: Springer. Nalbach, O., Linn, C., Derouet, M., & Werth, D. (2018). Predictive quality: Towards a new understanding of quality assurance using machine learning tools. In 21th International Conference. BIS 2018. (S. 1–12). Berlin: Springer. forthcoming. Neuscheler, T. (2018). Unternehmensberater – Die Stunde der Algorithmen. Frankfurter Allgemeine Zeitung (FAZ). http://www.faz.net/-gym-97fbt. Zugegriffen: 1. März 2018. Nickel, S., Rebennack, S., Stein, O., & Waldmann, K. H. (2022). Operations research. Berlin, Heidelberg: Springer. Nüttgens, M., & Rump, F. J. (2002). Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). In J. Desel & M. Weske (Hrsg.), Promise 2002 – Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen (S. 64). Bonn: Gesellschaft für Informatik e. V. OMG (2008). Business process modeling notation, V1.1, Technical Report, Object Management Group (OMG), January 2008. http://www.omg.org/spec/BPMN/1.1/PDF/ Oppermann, L., & Prinz, W. (2022). Vom Hier ins Metaverse über die Blockchain und zurück. Geschichte und Definition. Fachmagazin IM+io, 37(2), 52–55. Osterwalder, A., & Pigneur, Y. (2011). Business Model Generation: Ein Handbuch für Visionäre, Spielveränderer und Herausforderer. Frankfurt am Main: Campus. Petermann, F. (2017). Einführung in Celonis Process Mining. www.celonis.com. Zugegriffen: 22. Mai 2018. Peters, R., & Nauroth, M. (2019). Process-Mining: Geschäftsprozesse: smart, schnell und einfach (S. 4). Wiesbaden: Springer Gabler.

244

Literatur (Gesamt)

Picot, A., Reichwald, R., & Wigand, R. T. (1998). Die grenzenlose Unternehmung – Information, Organisation und Management. Lehrbuch zur Unternehmensführung im Informationszeitalter. Wiesbaden: Gabler. https://doi.org/10.1007/978-3-322-93130-6. Plociennik, C., Pourjafarian, M., Nazeri, A., Windholz, W., Knetsch, S., Rickert, J., & Weidenkaff, A. (2022). Towards a digital lifecycle passport for the circular economy. Procedia CIRP, 105, 122–127. Polyvyanyy, A. (Hrsg.). (2022). Process querying methods. Cham: Springer. Polyvyanyy, A., Wynn, M. T., van Looy, A., & Reichert, M. (Hrsg.). (2021). Business process management. 19th International Conference, BPM, Rome. Cham: Springer. Proceedings Pötter, T., Folmer, J., & Vogel-Heuser, B. (2017). Enabling Industrie 4.0 – Chancen und Nutzen für die Prozessindustrie. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 71–83). Wiesbaden: Springer Vieweg. Reinkemeyer, L. (Hrsg.). (2020a). Process mining in action: Principles, use cases and outlook. Cham: Springer Nature. Reinkemeyer, L. (2020b). Purpose: Identifying the right use cases. In L. Reinkemeyer (Hrsg.), Process Mining in Action: Principles, Use Cases and Outlook (S. 21). Cham: Springer Nature. Rifkin, J. (2014). Die Null Grenzkosten Gesellschaft – Das Internet der Dinge, kollaboratives Gemeingut und der Rückzug des Kapitalismus. Frankfurt: Campus. Roboyo (2017a). Digitale transformation. www.roboyo.de/im-fokus/digitale-transformation. Zugegriffen: 22. Mai 2018. Roboyo (2017b). Robotic process automation. www.roboyo.de/robotic-process-automation. Zugegriffen: 22. Mai 2018. Rochet, J. C., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European Economic Association, 1(4), 990–1029. Rombach, J. (2017). Mehr Sicherheit durch Prozessautomatisierung – Automatische Datenanalyse bei der Polizei – ein Praxisbeispiel. Fachmagazin IM+io, 32(3), 70–75. Russell, S., & Norvig, P. (2012). Künstliche Intelligenz: Ein moderner Ansatz (3. Aufl.). Hallbergmoos: Pearson. Sahay, A., Indamutsa, A., Di Ruscio, D., & Pierantonio, A. (2020). Supporting the understanding and comparison of low-code development platforms. In 2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) (S. 171–178). IEEE. Scheer, A.-W. (1984). EDV-orientierte Betriebswirtschaftslehre – Grundlagen für ein effizientes Informationsmanagement (1. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (1987). CIM Computer integrated manufacturing: Der computergesteuerte Industriebetrieb (1. Aufl.). Berlin: Springer. Scheer, A.-W. (1990). CIM Computer integrated manufacturing: Der computergesteuerte Industriebetrieb (4. Aufl.). Berlin: Springer. https://doi.org/10.1007/978-3-642-61510-8. Scheer, A.-W. (1991). Architektur integrierter Informationssysteme – Grundlagen der Unternehmensmodellierung (1. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (1997). Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsmodelle (7. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (2001). ARIS – Modellierungsmethoden, Metamodelle, Anwendungen (4. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (2002). ARIS – Vom Geschäftsprozess zum Anwendungssystem (4. Aufl.). Berlin, Heidelberg: Springer. Scheer, A.-W. (2013a). 16 Tipps für Start-ups in der High-Tech-Industrie. (Scheer Group Whitepaper). Saarbrücken. Scheer, A.-W. (2013b). Industrie 4.0 – Wie sehen Produktionsprozesse im Jahr 2020 aus? (A.-W. Scheer, Ed.). Saarbrücken: imc AG. https://www.researchgate.net/profile/August_Wilhelm_

Literatur (Gesamt)

245

Scheer/publication/277717764_Industrie_40_-_Wie_sehen_Produktionsprozesse_im_Jahr_ 2020_aus/links/55ee9e5608ae0af8ee1a1d72/Industrie-40-Wie-sehen-Produktionsprozesse-imJahr-2020-aus.pdf Scheer, A.-W. (2015). CeBIT Global Conferences 2015 – Industrie 4.0 oder wie transportiert man einen Elefanten? https://www.youtube.com/watch?v=SQp-fLAjx2c. Zugegriffen: 22. Mai 2018. Scheer, A.-W. (2015). Hochschule 4.0. Saarbrücken: Scheer. Scheer, A.-W. (2016). How to develop digitized disruptive business models“. Vortrag auf der Global Conference der CEBIT 2016. https://www.youtube.com/watch?v=Fu_4qH6PaBI. Zugegriffen: 22. Mai 2018. Scheer, A.-W. (2017). Hochschule 4.0. In E-Learning 4.0 (S. 101–123). Oldenbourg: De Gruyter. Scheer, A.-W. (2020). Unternehmung 4.0 (3. Aufl.). Springer Vieweg: Wiesbaden. https://doi.org/ 10.1007/978-3-658-27694-2. Scheer PAS (2022). Diverse Firmenveröffentlichungen zu der Application Composition Platform Scheer PAS und Anwendungsfällen BVG. https://www.scheer-pas.com/wp-content/uploads/ 2021/03/Scheer-PAS-Whitepaper-Platform-DE.pdf Scheer, A.-W., & Wachter, C. (Hrsg.). (2018). Digitale Bildungslandschaften (2. Aufl.). imc. Schermuly, C. C. (2021). New Work – Gute Arbeit gestalten (3. Aufl.). Freiburg: Haufe. Schmid, U., Thom, S., & Görtz, L. (2016). Ein Leben lang digital lernen – neue Weiterbildungsmodelle aus Hochschulen. (Arbeitspapier No. 20). Berlin: Hochschulforum Digitalisierung. https:// hochschulforumdigitalisierung.de/de/ein-leben-lang-digital-lernen-arbeitspapier-20. Slaby, J. R., & Fersht, P. (2012). Robotic automation emerges as a threat to traditiomal low- cost outsourcing. Hfs Research Ltd. https://www.horsesforsources.com/wp-content/uploads/2016/ 06/RS-1210_Robotic-automation-emerges-as-a-threat-060516.pdf. Soffer, P., Hinze, A., Koschmider, A., Ziekow, H., Di Ciccio, C., Koldehofe, B., Kopp, O., Jacobsen, A., Sürmeli, J., & Song, W. (2017). From event streams to process models and back: Challenges and opportunities. Information Systems. https://doi.org/10.1016/j.is.2017.11.002. Software, A. G. (2017). ARIS – Process Performance Manager (PPM) Solow, R. M. (1988). Growth theory and after. The American Economic Review, 78(3), 307–317. Tapscott, D., & Tapscott, A. (2016). Die Blockchain Revolution: Wie die Technologie hinter Bitcoin nicht nur das Finanzsystem, sondern die ganze Welt verändert. Kulmbach: Plassen Verlag, Börsenmedien AG. Toro, C., Wang, W., & Akhtar, H. (2021). Implementing Industry 4.0: The model factory as the key enabler for the future of manufacturing. Cham: Springer. Tsagkani, C., & Tsalgatidou, A. (2022). Process model abstraction for rapid comprehension of complex business processes. Information Systems, 103, 101818. Turner, C. J., Tiwari, A., Olaiya, R., & Xu, Y. (2012). Process mining: From theory to practice. Issues in Information Systems, 18(3), 493–512. Udacity (2018). Online-Kurse, die mehr sind als nur Lerninhalte. https://de.udacity.com/nanodegree. Zugegriffen: 22. Mai 2018. Urbaczewski, L., & Mrdalj, St (2006). A comparison of enterprise architecture frameworks. Issues in Information Systems, 7(2), 18–23. van der Aalst, W. M. P. (2011). Process mining – Data science in action (2. Aufl.). Heidelberg: Springer. van der Aalst, W. M. P., & Weijters, A. J. (2004). Process mining: A research agenda. Computers in Industry, 53(3), 231–244. Van der Valk, H., Haße, H., Möller, F., & Otto, B. (2022). Archetypes of digital twins. Business & Information Systems Engineering, 3(22), 375. insb. S. 377.

246

Literatur (Gesamt)

Vogel-Heuser, B. (2017). Herausforderungen und Anforderungen aus Sicht der IT und der Automatisierungstechnik. In T. Bauernhansl, M. Ten Hompel & B. Vogel-Heuser (Hrsg.), Allgemeine Grundlagen. Handbuch Industrie 4.0, (Bd. 4, S. 33). Wiesbaden: Springer Vieweg. Wahlster, W. (2017). Industrie 4.0: das Internet der Dinge kommt in die Fabriken. Universität Mainz. Vorlesungsreihe. Wannemacher, K., Jungermann, I., Scholz, J., Tercanli, H., & Villiez, A. (2016). Digitale Lernszenarien im Hochschulbereich. Arbeitspapier No. 15. Berlin: Hochschulforum Digitalisierung. https://hochschulforumdigitalisierung.de/de/studie-digitale-lernszenarien-hochschulbereich. Warnecke, H.-J. (1992). Die Fraktale Fabrik. Berlin-Heidelberg: Springer. Weber, F. (2020). Künstliche Intelligenz für Business Analytics. Wiesbaden: Springer Fachmedien. Weber, P., Gabriel, R., Lux, Th., & Menke, K. (2022). Basiswissen Wirtschaftsinformatik (4. Aufl.). (S. 206). Weißenberger, B. (12. März 2018). Es geht um Wahrheit – Nicht um Mehrheit. Frankfurter Allgemeine Zeitung (FAZ), S. 18. Welpe, I., & Ziegler, C. (2022). Web3: Wie Ihre Organisation in 10 Jahren aussehen wird – wenn es sie dann noch gibt. Fachmagazin IM+io, 37(2), 42–47. Wennker, P. (2020). Künstliche Intelligenz in der Praxis: Anwendung in Unternehmen und Branchen: KI wettbewerbs- und zukunftsorientiert einsetzen. Wiesbaden: Springer Gabler. Werth, D., & Greff, T. (2017). Und sie skaliert doch! – Skalierbarkeit als erfolgskritischer Faktor auch in der Digitalen Beratung. Fachmagazin IM+io, 31(1), 64–69. Werth, D., & Linn, C. (2018). Der digitale Prozesszwilling – Vom klassischen Geschäftsprozessmodell zum steuerbaren, digitalen Abbild des Realprozesses. Fachmagazin IM+ io, 33(1), 38– 43. Werth, D., Greff, T., & Scheer, A.-W. (2016). Consulting 4.0 – Die Digitalisierung der Unternehmensberatung. HMD Praxis Der Wirtschaftsinformatik, 53(1), 55–70. Werth, D., Zimmermann, P., & Greff, T. (2017). Self-service consulting: Conceiving customeroperated digital IT consulting services. In Twenty-second Americas Conference on Information Systems AMCIS 2017 (S. 1–10). Weske, M. (2019). Business process management: Concepts, languages, architectures (3. Aufl.). Berlin Heidelberg: Springer. Wildemann, H. (1998). Die modulare Fabrik: Kundennahe Produktion durch Fertigungssegmentierung (5. Aufl.). München: TCW. Wildemann, H. (2008). Modulare Unternehmensorganisation, Leitfaden zur Einführung föderalistischer Organisationsprinzipien in Unternehmen (S. 2). München: TCW. Willcocks, L., Lacity, M., & Craig, A. (2015). Robotic process automation at Xchanging (15/03). Outsourcing Unit Working Research Paper Series. https://eprints.lse.ac.uk/64518/1/OUWRPS_ 15_03_published.pdf. Zugegriffen: 9. Aug. 2023. Xu, L., Cabri, G., Aiello, M., Mecella, M., & de Vrieze, P. (2018). Twin planning: Virtual and real factory planning. Fachmagazin IM+io, 33(1), 70–73. Zachman, J. A. (1987). A framework for information systems architecture. IBM systems journal, 26(3), 276–292.