Cloud-Transformation : Wie die Public Cloud Unternehmen verändert [1. Aufl. 2019] 978-3-658-27324-8, 978-3-658-27325-5

Table of contents :
Front Matter ....Pages I-XXI
Erinnern Sie sich noch an Daimler, RTL und Siemens? (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 1-14
Alles wird digital (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 15-47
Der Weg in die Null-Grenzkosten-Ökonomie (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 49-84
Cloud – Die automatisierte IT-Wertschöpfung (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 85-126
Cloud-IT vs. klassische IT – Kalkulation für den Controller (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 127-147
Software als Kernkompetenz beherrschen (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 149-188
Sinkende Transaktionskosten und die neue Netzwerkökonomie (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 189-224
Die Cloud-Transformation (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 225-272
Cloud-Transformation – Wie die Public Cloud Unternehmen verändert (Roland Frank, Gregor Schumacher, Andreas Tamm)....Pages 273-290
Back Matter ....Pages 291-294

Citation preview

Roland Frank Gregor Schumacher Andreas Tamm

Cloud-Transformation Wie die Public Cloud Unternehmen verändert

Cloud-Transformation

Roland Frank · Gregor Schumacher · Andreas Tamm

Cloud-Transformation Wie die Public Cloud Unternehmen verändert

Roland Frank Mediadesign Hochschule München München, Deutschland

Gregor Schumacher Berlin, Deutschland

Andreas Tamm München, Bayern, Deutschland

ISBN 978-3-658-27324-8 ISBN 978-3-658-27325-5  (eBook) https://doi.org/10.1007/978-3-658-27325-5 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Gabler © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 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 Gabler 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

Geleitwort

Wer glaubt, dass „Cloud-Transformation – Wie die Public Cloud Unternehmen verändert“ nur einen weiteren Versuch darstellt, CIOs dazu zu bewegen, Cloud-Infrastruktur-Dienste anstelle eigener Rechenzentren zu nutzen, liegt vollkommen daneben. Die drei Autoren vereinenen eine seltene Mischung aus volkswirtschaftlichem Verständnis, Corporate Strategy-Erfahrung und moderner IT-Architektur in einem Buch. Es richtet sich deshalb besonders an interdisziplinär denkende Leser, sowohl in etablierten Unternehmen als auch in Start-Ups. Zu Beginn der Cloud-Computing Ära hielten besonders viele IT-Leiter in Europa Public Clouds für eine kontinuierliche Weiterentwicklung traditioneller IT Betriebs- und Outsourcing Angebote. Der „Infrastructure as Code“ Ansatz, der voll-automatisierte Beschaffung von Infrastrukturen über eine API in wenigen Minuten oder sogar Sekunden anbietet, zeigte aber wie radikal und neu Public Clouds wirklich waren. Obgleich ihre IT-Infrastruktur zu Anfang noch mit traditionellen IT-Dienstleistungen vergleichbar war, ist das Geschäftsmodell die eigentliche disruptive Innovation. So ist die „Cloud-Transformation“ in den meisten Branchen der wichtigste Enabler innovativer, digitaler Geschäftsmodelle geworden. Das aktuelle Werk von Frank, Schumacher und Tamm hilft Unternehmens-Strategen in der amerikanischen Standardliteratur der Tec-Industrie zu navigieren und im Kontext ihrer Branche die sinnvolle Richtung einer eigenen Digital-Strategie zu finden. Dabei geht es nicht nur um neue digitale Produkte, mit denen – losgelöst vom Kerngeschäft – kaum ein konservative Investor oder Eigentümer in Europa zu überzeugen ist. In etablierten Unternehmen ist die Digitalisierung bestehender Produkte oder Dienstleistungen der Schlüssel zum Erfolg. Dabei können bestehende Produkte eine unterschiedliche „digitale Intensität“ bekommen. Besonders wenn eine Branche durch Angebote einer sehr hohen Digital-Intensität ernsthaft verändert wird, wie es die Online-Retailer im Einzelhandel erlebt haben, müssen Unternehmen radikal die eigene Wertschöpfung hinterfragen. Notfalls muss sich ein etabliertes Unternehmen dabei auch selbst kannibalisieren um die Disruption durch einen New-Comer zu vermeiden. Deshalb engagieren sich beispielsweise konkurrierenden Automobil-Giganten wie Daimler und BMW plötzlich gemeinsam als innovativer Mobilitäts-Dienstleister. Auch wenn dadurch sicher einige Autos weniger V

VI

Geleitwort

verkauft werden, wird eine neue Nutzerschicht adressiert die lieber Fahrzeuge kurzfristig mietet als zu kaufen. Bücher wie „Cloud-Transformation“, die den Brückenschlag zwischen Technologie und Business meistern, sind deshalb so wichtig für die Neuausrichtung jeder Branche. Die Grundsätze der digitalen Geschäftsmodelle sind überall gleich, egal ob sie bisher Computer-Infrastruktur oder Autos verkauft haben. Die allgemeine Verfügbarkeit von Cloud-Native Technologien, mit Machine Learning und IoT-Backends, beschleunigt die Marktveränderung. Damit wird ihre Digital-Strategie nicht nur zur Firmen-Strategie sondern zur Überlebens-Strategie – selbst als heutiger Marktführer! Dr. Ried ist Principal Analyst beim unabhängigen Analysten Haus Crisp Research und betreibt Marktforschung um Cloud Computing und IoT. Neben leitenden Rollen bei Software Herstellern verantwortete Dr. Ried über sieben Jahre die globale Marktforschung und Strategieberatung für Cloud-Anbieter bei Forrester Research. Bilder: https://www.stefan-ried.de/#publicimages.

Vorwort

Im Jahr 2010 erschien der Animationsfilm „Cloudy – with a Chance of Meatballs“, in der deutschen Fassung: „Wolkig mit Aussicht auf Fleischbällchen“. In diesem Film geht es um einen genialen Erfinder, dessen Ideen bislang nicht gewürdigt wurden, seien es Schuhe zum Aufsprühen oder Geräte, mit denen die Gedanken von Affen gelesen werden können. Erst als er eine Maschine erfindet, die Wasser in Essen verwandeln kann und die plötzlich ein Eigenleben entwickelt und schließlich in den Wolken („Cloud“) verschwindet, gewinnt er die Aufmerksamkeit der Öffentlichkeit. Denn nun können alle von den Vorteilen der „Cloud“ profitieren: Jeder Bewohner der Stadt erhält einen Zugang, mit dem er Essensbestellungen auslösen kann. Pizza, Hamburger, Spaghetti mit Tomatensauce und Fleischbällchen sind nun für jeden und zu jedem Zeitpunkt verfügbar. So ähnlich ist es auch mit der Public Cloud: Software und IT-Infrastruktur aus der Public Cloud bedeuten einen unglaublichen Komfortgewinn, denn sie sind jederzeit und für jeden verfügbar – und das gilt sowohl für die privaten Nutzer dieser Dienste als auch für Unternehmen. Dropbox, Lieferheld, Spotify und Co. sind aus unserem Alltag nicht mehr wegzudenken. Alle diese Cloud-Anwendungen haben sich unauffällig, aber bestimmt in das Leben der Menschen integriert. Das Gleiche gilt für zahlreiche Unternehmensanwendungen, die über die Public Cloud verfügbar sind: Die Effizienzsteigerungen und der Komfortgewinn sind so groß, dass sich Unternehmen, die den Umstieg in die Public Cloud bereits gewagt haben, eine Rückkehr in vielen Fällen nicht mehr vorstellen können. Erstaunlicherweise haben diese Vorteile aber noch nicht dazu geführt, dass Unternehmen die Cloud schon intensiv nutzen. Zwar setzen laut einer Umfrage von Bitkom bereits 73 % der Unternehmen in Deutschland Cloud Computing ein, allerdings beschränkt sich die Nutzung bislang in der Regel auf die Bereiche Datenspeicherung (61 %), E-Mail-Anwendungen (48 %) oder Office-Anwendungen (34 %). Die wirklichen Vorteile, die durch die Nutzung der Cloud realisiert werden können, spielen nur eine untergeordnete Rolle: beispielsweise agile Software-Entwicklung, digitale Geschäftsmodelle, neue Arbeitsprozesse und flexible Kostenstrukturen.

VII

VIII

Vorwort

Kein Wunder also, dass für viele Manager das Thema Public Cloud bis heute eher zur Pflicht als zur Kür der täglichen Arbeit gehört. In vielen Fällen müssen einzelne technologie-affine Mitarbeiter den Großteil des Unternehmens vor sich hertreiben. „Cloud-Transformation – Wie die Public Cloud Unternehmen verändert“ möchte den Cloud-Experten helfen, die Vorteile der neuen Technologie besser zu kommunizieren – und Manager dabei unterstützen, sich in die neuen Themen einzuarbeiten. Von einem Vertriebsmitarbeiter zu erwarten, dass er alle juristischen Vertragsdetails verstehen und beurteilen kann, wäre zu viel verlangt. Genauso wenig ergibt es Sinn, den Buchhalter das UX-Design seiner neuen Analyse-Software selbst erstellen zu lassen. Die Spezialisierungsvorteile in diesen Teilbereichen sind so groß, dass es eine Vollzeitaufgabe ist, die Tätigkeiten dahinter professionell umzusetzen. Die Ausgangslage für Manager ist aber eine andere: Zwar kann auch von ihnen nicht erwartet werden, dass sie selbst Software entwickeln oder den Code ihrer Entwickler bewerten können – aber sie sollten die großen ökonomischen und unternehmerischen Zusammenhänge der genutzten IT-Architekturen kennen und richtig einordnen können. Denn daraus resultieren Entscheidungen, welche die Wettbewerbsfähigkeit ihrer digitalen Geschäftsmodelle stark beeinflussen – und davon hängt letztlich der Fortbestand all der anderen Aufgaben und Tätigkeiten in einem Unternehmen ab. Um eine Verantwortung dieser Tragweite übernehmen zu können, werden in Zukunft immer stärker grundlegende Kenntnisse in den Bereichen Digitalisierung von Geschäftsmodellen, Cloud Computing sowie Software- und Organisationsentwicklung erwartet werden. Wenn es Managern gelingt, diesen Überblick zu erlangen, können sie als Ansprechpartner zwischen den unterschiedlichen Abteilungen vermitteln – und last but not least: die richtigen Entscheidungen treffen. Diesen vier Bereichen – digitale Geschäftsmodelle, Cloud Computing, Software- und Organisationsentwicklung – widmet sich dieses Buch. Manager bekommen damit ein Werkzeug an die Hand, das ihnen ermöglicht, den Dialog mit den Fachabteilungen (wieder) aufzunehmen und die Cloud-Transformation innerhalb des Unternehmens voranzutreiben. Das Buch wurde so geschrieben, dass IT-Laien den Ausführungen folgen können – gleichzeitig können aber auch IT-Fortgeschrittene neue Ideen und Konzepte für die Führung und Neuausrichtung von Unternehmen für ihre tägliche Arbeit mitnehmen. An der Entstehung dieses Buchs war eine ganze Reihe von Personen beteiligt, bei denen wir uns an dieser Stelle ganz herzlich bedanken möchten: • Der erste Dank geht an Frau Wiegmann, unsere Lektorin bei Springer, die die Entstehung dieses Buchs von der ersten Idee bis zur Veröffentlichung intensiv begleitet hat. • Darüber hinaus geht ein Dank an die Mitarbeiter und Manager von Arvato Systems, die mit der Cloud-Transformation in ihrem Unternehmen die Vorlage für dieses Buch geliefert haben.

Vorwort

IX

• Darüber hinaus möchten wir uns bei unserer Lektorin und unserem Lektor bedanken: Dolores Omann und Jan-Erik Strasser, denen wir mit unseren engen Zeitfenstern einiges zugemutet haben. Zum Schluss aber möchten wir unser wichtigstes Dankeschön aussprechen. Es richtet sich an die Menschen in unserem privaten Umfeld, die die Anstrengungen der letzten Monate miterlebt haben und ohne deren Unterstützung das Buch nicht zustande gekommen wäre: Fabiola, Valentin, Daniela, Tina und Jutta: vielen Dank. Euch ist dieses Buch gewidmet. München Juli 2019

Prof. Dr. Roland Frank Gregor Schumacher Andreas Tamm

Inhaltsverzeichnis

1 Erinnern Sie sich noch an Daimler, RTL und Siemens?. . . . . . . . . . . . . . . . . 1 1.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Das Innovator’s Dilemma kann jedes Unternehmen treffen . . . . . . . . . . . . 2 1.3 Disruptive Technologie Public Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Das Ziel dieses Buchs: Surfbrett statt Rettungsring . . . . . . . . . . . . . . . . . . 8 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 Alles wird digital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Die technische Digitalisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Die Folgen der Digitalisierung: Dezentralisierung, Kommunikation, Konvergenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Die völlige Digitalisierung der Wertschöpfung. . . . . . . . . . . . . . . . . . . . . . 22 2.4 Die Plattformökonomie – Daten sind das neue Öl. . . . . . . . . . . . . . . . . . . . 24 2.5 Bedingungen für den erfolgreichen Betrieb digitaler Plattformen . . . . . . . 28 2.6 Erfolgsfaktoren für den Einsatz digitaler Plattformen. . . . . . . . . . . . . . . . . 35 2.7 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3 Der Weg in die Null-Grenzkosten-Ökonomie. . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1 Big is beautiful. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Null-Grenzkosten-Geschäftsmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3 Wann lohnt sich der Einstieg in digitale Technologien? . . . . . . . . . . . . . . . 65 3.4 Die Ausbreitung der Null-Grenzkosten-Geschäftsmodelle – Beispiel Automobilindustrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.5 Big stays beautiful – vom vermeintlichen Abstieg der großen Konzerne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.6 Künstliche Intelligenz für das Lektorat. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4 Cloud – Die automatisierte IT-Wertschöpfung . . . . . . . . . . . . . . . . . . . . . . . . 85 4.1 It’s the software, stupid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 XI

XII

Inhaltsverzeichnis

4.2 4.3 4.4 4.5 4.6 4.7 4.8

Der klassische IT-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Der Stack – Die IT und ihre Wertschöpfungskette . . . . . . . . . . . . . . . . . . . 93 Die Cloud-Transformation in der IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Der cloudbasierte IT-Prozess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Public Cloud vs. Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Sicherheit in der Public Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Fallbeispiel: Ein teures Missverständnis im IT-Einkauf eines Großkonzerns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.9 Von der klassischen IT zur Cloud – auf einer Seite und in einem Bild erklärt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

5 Cloud-IT vs. klassische IT – Kalkulation für den Controller. . . . . . . . . . . . . 127 5.1 Ein praktisches Beispiel: Outsourcing des Rechnungsmanagements. . . . . 127 5.2 Leistungsmerkmale der klassischen Applikation. . . . . . . . . . . . . . . . . . . . . 130 5.3 Die Cloud-Transformationder Applikation. . . . . . . . . . . . . . . . . . . . . . . . . 135 5.4 Leistungsmerkmale der cloudbasierten Anwendung. . . . . . . . . . . . . . . . . . 139 5.5 Vor- und Nachteile der Transformation im Überblick. . . . . . . . . . . . . . . . . 144 5.6 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6 Software als Kernkompetenz beherrschen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.1 Alles wird Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.2 Warum Software für Manager eine so große Herausforderung ist . . . . . . . 151 6.3 Virtualisierungsebenen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.4 Sourcing-Optionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.5 Software-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 6.6 Prozessabläufe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 6.7 Menschen und Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 6.8 Praxisbeispiel ING DiBa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 6.9 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7 Sinkende Transaktionskosten und die neue Netzwerkökonomie. . . . . . . . . . 189 7.1 Transaktionskosten halten klassische Wertschöpfungsketten zusammen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 7.2 Exkurs: Interne Transaktionskosten bremsen die Skaleneffekte der Produktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 7.3 Integratoren, Orchestratoren und Layer Player – wie Transaktionskosten ökonomische Strukturen beeinflussen. . . . . . . . . . . . . 195 7.4 Schnelle Kommunikation und einfache Automatisierung – die Transaktionskostenhebel der Digitalisierung. . . . . . . . . . . . . . . . . . . . . . . . 199 7.5 Neue Make-or-Buy-Entscheidungen durch die Digitalisierung. . . . . . . . . . 202

Inhaltsverzeichnis

XIII

7.6 Die Auswirkungen der Cloud-Revolution auf die Transaktionskosten bei der Software-Nutzung . . . . . . . . . . . . . . . . . . . . . . 207 7.7 Praxisbeispiel: Wie der Softwareeinkauf via Cloud die Transaktionskosten senkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 7.8 Auf dem Weg zur Netzwerkökonomie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.9 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 8 Die Cloud-Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 8.1 Wissenschaftliche Modelle zur digitalen Transformation. . . . . . . . . . . . . . 225 8.2 Die drei Ebenen der Cloud-Transformation. . . . . . . . . . . . . . . . . . . . . . . . . 229 8.3 Das Infrastrukturmodell umstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 8.4 Das Betriebsmodell umstellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 8.5 Das Geschäftsmodell umstellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 8.6 Die Auswirkungen der Cloud-Transformation auf die potenziellen Mitarbeiter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 8.7 Eine erfolgreiche Cloud-Transformation – in einem Bild erklärt. . . . . . . . 267 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 9 Cloud-Transformation – Wie die Public Cloud Unternehmen verändert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 9.1 Unternehmen scheitern – auch wenn Manager scheinbar alles richtig machen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 9.2 Digitalisierung als bestimmender Trend der Wirtschaft . . . . . . . . . . . . . . . 276 9.3 Grenzkosten bestimmen die Wettbewerbsfähigkeit. . . . . . . . . . . . . . . . . . . 277 9.4 Cloud als Schlüsseltechnologie der Digitalisierung . . . . . . . . . . . . . . . . . . 279 9.5 Klassische Applikationen können auf Cloud-Technologien umgestellt werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 9.6 Mit Software- und Cloud-Kompetenzen wettbewerbsfähig für die digitalen Welt werden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 9.7 Sinkende Transaktionskosten ermöglichen mehr Outsourcing und verändern die Volkswirtschaft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 9.8 Die Cloud-Transformation betrifft alle Unternehmen mit digitaler Wertschöpfung – auf drei unterschiedlichen Ebenen. . . . . . . . . . . . . . . . . . 287 9.9 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Stichwortverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Abbildungsverzeichnis

Abb. 1.1 Abb. 1.2 Abb. 1.3 Abb. 1.4 Abb. 1.5 Abb. 1.6 Abb. 2.1 Abb. 2.2 Abb. 2.3 Abb. 2.4 Abb. 2.5 Abb. 2.6 Abb. 2.7 Abb. 2.8 Abb. 2.9 Abb. 2.10 Abb. 2.11 Abb. 2.12 Abb. 2.13 Abb. 2.14 Abb. 3.1 Abb. 3.2 Abb. 3.3 Abb. 3.4 Abb. 3.5

Vergleich der Marktführer in der Computer-Wertschöpfungskette – Mainframe vs. PC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Innovator’s Dilemma nach Clayton Christensen . . . . . . . . . . . . . . . . . . 4 Transformierende Wirkung von Cloud-Technologien. . . . . . . . . . . . . . 6 Zielsetzung des Buches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Vorgehen des Buches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Gartner Hypecycle 2018 (Panetta 2018). . . . . . . . . . . . . . . . . . . . . . . . . 13 Der technische Prozess der Digitalisierung. . . . . . . . . . . . . . . . . . . . . . 17 Auswirkungen der Digitalisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Die Digitalisierung verändert die ökonomischen Paradigmen. . . . . . . . 24 Datensammlung führt zu wissensbasierten Wettbewerbsvorteilen. . . . . 24 Die Wertschöpfungsbeziehung zwischen Kunden und Anbieter. . . . . . 27 Digitale Plattformen verändern die Wertschöpfungsbeziehungen der Anbieter zum Kunden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Die ökonomische Macht digitaler Plattformen. . . . . . . . . . . . . . . . . . . . 28 Prognostizierter Anstieg des weltweiten Datenvolumens (Reinsel et al. 2018). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Der Loyalty Loop bei Tesla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Netflix verdoppelt die Anzahl der gewonnenen Emmys (Loesche 2017). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Der Netzwerkeffekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Two-sided Markets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Die Erfolgsfaktoren für digitale Plattformen. . . . . . . . . . . . . . . . . . . . . 35 Portfoliotheorie nach Markowitz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Boston Consulting Group Portfolio-Analyse. . . . . . . . . . . . . . . . . . . . . 53 Physische vs. digitale Produkte – Durchschnittskosten und Grenzkosten im Vergleich (Clement und Schreiber 2016) . . . . . . . 55 Grundelemente der Wertschöpfungskette. . . . . . . . . . . . . . . . . . . . . . . . 63 Geschäftsmodell-Analyse nach Gassmann. . . . . . . . . . . . . . . . . . . . . . . 67 Start von Null-Grenzkosten-Geschäftsmodellen . . . . . . . . . . . . . . . . . . 74 XV

XVI

Abb. 3.6 Abb. 3.7 Abb. 3.8 Abb. 3.9 Abb. 3.10 Abb. 4.1 Abb. 4.2 Abb. 4.3 Abb. 4.4 Abb. 4.5 Abb. 4.6

Abb. 4.7 Abb. 4.8 Abb. 4.9 Abb. 4.10 Abb. 4.11 Abb. 4.12 Abb. 4.13 Abb. 4.14 Abb. 4.15 Abb. 4.16 Abb. 4.17 Abb. 4.18 Abb. 4.19 Abb. 4.20 Abb. 5.1 Abb. 5.2 Abb. 5.3 Abb. 5.4 Abb. 5.5

Abbildungsverzeichnis

Digitale Märkte – Marktanteile und Mitarbeiteranzahl. . . . . . . . . . . . . 75 Tatsächliche Verteilung der Marktanteile in digitalen Märkten. . . . . . . 77 Wertschöpfungskette Buch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Künstliche Neuronale Netze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Demo-Showcase zur Lektorats-KI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Der Zyklus eines Software-Projekts. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Geflecht von bekannten und unbekannten Abhängigkeiten in der IT-Wertschöpfungskette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Unregelmäßige Auslastungskurve einer Applikation. . . . . . . . . . . . . . . 92 Die IT-Wertschöpfungskette (Stack) . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Interesse am Suchbegriff „Cloud“ im zeitlichen Verlauf seit 2004 laut Google Trends. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Schematischer Ablauf der Nutzung einer Programmierschnittstelle (API) am Beispiel der OpenWeatherMap.org. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Beispiel für einen API-Call einer Datenbank. . . . . . . . . . . . . . . . . . . . . 104 IT-Wertschöpfung wird zum Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . 105 Verschiedene Abstraktionsgrade der cloudbasierten IT-Wertschöpfung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Cloud ermöglicht die einfache Fokussierung auf das Kerngeschäft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Software erstellen unter Nutzung von Cloud-Services. . . . . . . . . . . . . . 109 Software betreiben in der Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Software skalieren in der Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Basis-Leistungsumfang der Private Cloud. . . . . . . . . . . . . . . . . . . . . . . 112 Private Cloud und Public Cloud im Vergleich . . . . . . . . . . . . . . . . . . . . 113 Differenzierung der Grundbegriffe Compliance und Sicherheit . . . . . . 115 Ebenen der technischen Sicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Verantwortungsbereiche für Sicherheit beim Outsourcing in die Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Infrastruktur-Komponenten sind bei Plattform-Services nicht mehr erkennbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Von der klassischen IT zur cloudbasierten IT-Wertschöpfung. . . . . . . . 122 Geschäftsmodell eines Dienstleisters zum „Prozess-Management für Einkaufsrechnungen“. . . . . . . . . . . . . . . . . . 128 Herausforderungen des globalen Outsourcings des Managements von Einkaufsrechnungen. . . . . . . . . . . . . . . . . . . . . . . . . 129 Logische Architektur der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Anzahl der Transaktionen und monatliche Kosten für IT . . . . . . . . . . . 133 Durchschnittskosten je Monat sowie Kapazitätsgrenzen der alten Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Abbildungsverzeichnis

Abb. 5.6 Abb. 5.7 Abb. 5.8 Abb. 5.9 Abb. 5.10 Abb. 5.11 Abb. 5.12 Abb. 6.1 Abb. 6.2 Abb. 6.3 Abb. 6.4 Abb. 6.5 Abb. 6.6 Abb. 6.7 Abb. 6.8 Abb. 6.9 Abb. 6.10 Abb. 6.11 Abb. 6.12 Abb. 6.13 Abb. 6.14 Abb. 6.15 Abb. 6.16 Abb. 6.17 Abb. 6.18 Abb. 6.19 Abb. 6.20 Abb. 6.21 Abb. 6.22 Abb. 6.23 Abb. 6.24 Abb. 6.25 Abb. 6.26

XVII

Grenzkosten in der alten Applikation. . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Migrationskonzept für die Outsourcing-Anwendung. . . . . . . . . . . . . . . 136 Monatliche Kosten der neuen Applikation. . . . . . . . . . . . . . . . . . . . . . . 138 Monatliche Gesamtbetriebskosten einschließlich Projekte . . . . . . . . . . 141 Durchschnittskosten in Abhängigkeit von den Transaktionen. . . . . . . . 142 Summierte Kosten über den gesamten Applikationslebenszyklus. . . . . 143 Relevante Preis- und Qualitätsunterschiede in einem Bild. . . . . . . . . . . 145 Der Software-Prozess greift auf die IT-Wertschöpfung zu. . . . . . . . . . . 151 Monolithische Software beinhaltet viele Abhängigkeiten. . . . . . . . . . . 152 Monolithische Software – die Hydra im Unternehmen. . . . . . . . . . . . . 153 Die Abhängigkeiten innerhalb der Software bremsen die Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Faktoren, die die Leistungsfähigkeit von Software beeinflussen. . . . . . 155 Entkopplung ermöglicht Skalierungseffekte . . . . . . . . . . . . . . . . . . . . . 155 Virtualisierung der IT-Wertschöpfung am Beispiel eines Container-Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Beispielhafte Kalkulation einer Webseite mit schwankendem Nutzungsverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Make-or-Buy-Frage in der Übersicht. . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Die wichtigsten Sourcing-Optionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Faktoren bei der individuellen Abwägung der Sourcing-Optionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Client-Server-Architektur – Download eines Fotos vom FTP-Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Mehrschichten-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Service Oriented Architecture (SOA). . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Microservices-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Herausforderungen bei verteilten Systemen. . . . . . . . . . . . . . . . . . . . . . 164 Reduktion von Abhängigkeiten und Komplexität . . . . . . . . . . . . . . . . . 167 Vom Monolith zu Microservices – wirtschaftliche Auswirkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Prozessabläufe von der Idee bis zum Betrieb. . . . . . . . . . . . . . . . . . . . . 169 Agil als schrittweise und kollaborative Softwareentwicklung. . . . . . . . 170 Agiles Vorgehen ist für nicht-materielle Güter besonders gut geeignet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Scrum als erfolgreiches Modell am Anfang der Software-Wertschöpfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Klassischer Prozess der Software-Bereitstellung mit hohen Kommunikations- und Verwaltungsaufwänden. . . . . . . . . . . . . . 175 DevOps als agile Form der Bereitstellung von IT . . . . . . . . . . . . . . . . . 176 DevOps – die vier charakterisierenden Begriffe. . . . . . . . . . . . . . . . . . . 177 Agiles Arbeiten mit Squads, Tribes und Chapters. . . . . . . . . . . . . . . . . 184

XVIII

Abb. 7.1 Abb. 7.2 Abb. 7.3 Abb. 7.4 Abb. 7.5 Abb. 7.6 Abb. 7.7 Abb. 7.8 Abb. 7.9 Abb. 7.10

Abb. 7.11 Abb. 7.12 Abb. 7.13

Abb. 7.14 Abb. 7.15 Abb. 8.1 Abb. 8.2 Abb. 8.3 Abb. 8.4 Abb. 8.5 Abb. 8.6 Abb. 8.7 Abb. 8.8 Abb. 8.9 Abb. 8.10

Abbildungsverzeichnis

Die Arten von Transaktionskosten – Beispiel Motorenherstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Hohe Transaktionskosten halten die Wertschöpfungskette zusammen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Vergleich der im Kontext des Produkts entstehenden Zusatzkosten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Interne Transaktionskosten nehmen mit steigender Ausbringungsmenge zu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Fallende Kommunikationskosten nach Philip Evans (Evans 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Reduzierte Transaktionskosten durch Digitalisierung – Beispiel Aktienhandel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Kerngeschäft zwischen Digitalisierung und Automatisierung. . . . . . . . 204 Nutzung der Vorteile der Cloud mit geringen Transaktionskosten. . . . . 207 Kernkompetenzen und Core Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Die digitale Make-or-Buy-Entscheidung: Beispielhafte Positionierung für ein Unternehmen mit physischen Produkten und zunehmender Relevanz digitaler Geschäftsmodelle. . . . . . . . . . . . 210 Hohe interne Transaktionskosten in der klassischen IT. . . . . . . . . . . . . 213 Niedrige externe Transaktionskosten bei der Nutzung von Software-Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Auf dem Weg zur Netzwerkökonomie: beispielhafte Darstellung der Auflösung klassischer Wertschöpfungsketten durch sinkende Transaktionskosten in der Digitalwirtschaft. . . . . . . . . 218 Von der klassischen zur netzwerkartigen Wertschöpfung . . . . . . . . . . . 220 Die durch Cloud-Technologien sinkenden Transaktionskosten verändern die Unternehmenswelt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Three Horizons of Growth nach McKinsey und Baghai, Coley & White. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Zone to win nach Geoffrey Moore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Ebenen der Disruption nach Geoffrey Moore . . . . . . . . . . . . . . . . . . . . 230 Vorbereitungsphase der Cloud-Transformation. . . . . . . . . . . . . . . . . . . 231 Cloud-Strategie-Team: Organisatorische Aufhängung und voraussichtlicher Scope des Changes je Ebene. . . . . . . . . . . . . . . . 232 Die vier Schritte der Cloud Transformation im Infrastrukturmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Die 5R nach Gartner: Migrationsszenarien von Applikationen. . . . . . . 234 Analyse der Applikationslandschaft vor einer Cloud-Migration nach Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Evaluation und Priorisierung der Applikationslandschaft nach Briggs/Kassner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Benötigte Skills je Migrations-Typ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Abbildungsverzeichnis

XIX

Abb. 8.11 Framework für Governance, Risk und Compliance nach Michael South (AWS) vereinfacht und übersetzt. . . . . . . . . . . . . . 240 Abb. 8.12 Vorgehen zur Applikations-Migration nach Microsoft. . . . . . . . . . . . . . 242 Abb. 8.13 Durchführung der Cloud-Transformation im Infrastrukturmodell. . . . . 243 Abb. 8.14 Infrastrukturmodell umstellen – die grundlegenden Schritte der Cloud-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Abb. 8.15 Nutzung der Cloud zur Verbesserung der Geschäftsmodelle. . . . . . . . . 245 Abb. 8.16 Migrationstyp und Chancen für das Geschäftsmodell. . . . . . . . . . . . . . 246 Abb. 8.17 Migrationsaufwände und Nutzenfaktoren . . . . . . . . . . . . . . . . . . . . . . . 247 Abb. 8.18 Kosten versus Nutzen einer Cloud-Migration . . . . . . . . . . . . . . . . . . . . 249 Abb. 8.19 Konsequenter Fokus auf den Kunden. . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Abb. 8.20 Ebenen der Unternehmensanwendungen nach Rava Kalakota. . . . . . . . 252 Abb. 8.21 Feature-Team für „Hassbotschaften erkennen“ – beispielhafte Zusammensetzung eines Teams . . . . . . . . . . . . . . . . . . . . 254 Abb. 8.22 Betriebsmodell modernisieren mit Cloud-Technologie erfordert echte Veränderungen im Unternehmen. . . . . . . . . . . . . . . . . . 257 Abb. 8.23 Transformation als Führungsaufgabe nach Geoffrey Moore. . . . . . . . . 259 Abb. 8.24 Zone Offense – Als Disruptor auftreten nach Geoffrey Moore . . . . . . . 260 Abb. 8.25 Zone Defense – Der Disruption begegnen nach Geoffrey Moore . . . . . 261 Abb. 8.26 Public Cloud Transformation – Zusammenfassung der wichtigsten Punkte je Ebene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Abb. 9.1 Cloud-Transformation – Wie die Public Cloud Unternehmen verändert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Abb. 9.2 Innovator’s Dilemma nach Clayton Christensen am Beispiel von „Mainframe Computer versus Personal Computer“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Abb. 9.3 Cloud als Digitalisierung der IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Abb. 9.4 Cloud-Technologien als mehrfacher Disruptionsfaktor. . . . . . . . . . . . . 276 Abb. 9.5 Die Digitalisierung verändert die ökonomischen Paradigmen. . . . . . . . 276 Abb. 9.6 Erfolgsfaktoren in der digitalen Welt. . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Abb. 9.7 Die Entstehung von Null-Grenzkosten-Geschäftsmodellen bei gleichzeitiger Digitalisierung von Produktion, Produkt und Verkauf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Abb. 9.8 Digitalisierung der Softwareprozesse durch Cloud . . . . . . . . . . . . . . . . 280 Abb. 9.9 Konkrete wirtschaftliche Effekte der Cloud-Transformation. . . . . . . . . 281 Abb. 9.10 Umstellung einer einfachen Applikation auf Cloud Native. . . . . . . . . . 281 Abb. 9.11 Cloud-Transformation einer geschäftsmodell-relevanten Applikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Abb. 9.12 Die Software-Wertschöpfung als Faktor im digitalen Wettbewerb . . . . 283 Abb. 9.13 Relevante Einflussfaktoren auf die Performanz der Software-Wertschöpfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

XX

Abbildungsverzeichnis

Abb. 9.14 Transaktionskosten sind der Kleber, der Unternehmen zusammenhält . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Abb. 9.15 Sinkende Transaktionskosten verändern die Unternehmenswelt. . . . . . 286 Abb. 9.16 Ebenen der Disruption nach Geoffrey Moore . . . . . . . . . . . . . . . . . . . . 287 Abb. 9.17 Infrastrukturmodell umstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Abb. 9.18 Betriebsmodell modernisieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Abb. 9.19 Gesamt-Portfolio transformieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Tabellenverzeichnis

Tab. 5.1 Kalkulation der alten Applikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Tab. 5.2 Veränderte Kostenstrukturen in der neuen Applikation. . . . . . . . . . . . . . . 137 Tab. 5.3 Überblick über die Migrationsaufwände. . . . . . . . . . . . . . . . . . . . . . . . . . 138 Tab. 5.4 Kalkulation der neuen Applikation für drei Millionen Transaktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Tab. 5.5 Vergleich der wichtigsten Kostenkomponenten. . . . . . . . . . . . . . . . . . . . . 144

XXI

1

Erinnern Sie sich noch an Daimler, RTL und Siemens?

Zusammenfassung

Infrastrukturelle Revolutionen haben in der Regel einen großen Einfluss auf Unternehmen: Die Dampfmaschine, der elektrische Strom und der Personal Computer veränderten die Art und Weise des wirtschaftlichen Handelns radikal. Heute steht den Unternehmen mit der Cloud-Technologie wieder solche Revolution ins Haus. Der Unterschied zu den vorherigen Umbrüchen ist die Geschwindigkeit, mit der die Änderungen heute adaptiert werden können und müssen. Und das betrifft nicht nur Software- und IT-Unternehmen, sondern nahezu alle Unternehmen und Branchen. Das bringt die beteiligten Mitarbeiter in eine knifflige Situation. Denn einerseits haben viele Unternehmenslenker verstanden, dass sie sich mit dem Thema Cloud-Transformation auseinandersetzen müssen – und zwar aktiv. Gleichzeitig wissen viele Manager nicht, wie sie diesen Prozess angehen sollen. Ziel des Buchs ist es, den Managern einen Leitfaden für die Cloud-Transformation an die Hand zu geben. Das erste Kapitel stellt Unternehmensumbrüche durch sogenannten Disruptionen in einen historischen Kontext und liefert anschließend einen Überblick über die wichtigsten Themen und Hilfsmittel, die dieses Buch den Mitarbeitern und Unternehmenslenkern zur Verfügung stellt.

1.1 Einleitung Erinnern Sie sich noch an Daimler, RTL und Siemens? Diese Frage ergibt auf den ersten Blick wenig Sinn. Denn allen drei Unternehmen geht es gut – zumindest momentan, im zweiten Quartal 2019. Doch schon in wenigen Jahren könnte diese Frage durchaus berechtigt sein. Und wenn nicht für diese drei, dann für viele andere Unternehmen, die nicht den Mut hatten, sich zu verändern. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_1

1

2

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

2018 musste mit General Electric das letzte Gründungsmitglied den amerikanischen Aktienindex Dow Jones verlassen. Seit 1976 hat sich die Zusammensetzung des Dow Jones nahezu vollständig verändert.1 Die teuersten Unternehmen der Welt von heute betreiben digitale Geschäftsmodelle: Apple, Amazon, Alphabet (Steinharter 2018). Firmen wie Kodak, Motorola, Netscape und Nokia sind hingegen warnende Beispiele: Sie zeigen, wie schnell Unternehmen, die lange Zeit große Marktanteile in innovativen Branchen für sich beanspruchten, innerhalb kürzester Zeit vom Markt verschwinden können. Jetzt werden Sie als kritischer Leser2 einwenden, dass in den genannten Unternehmen schwerwiegende Managementfehler begangen wurden und ihr Ausscheiden aus dem Markt daher unvermeidbar war. Das ist richtig. Richtig ist aber auch, dass diese Unternehmen von erfahrenen Managern geleitet wurden, die ihr ganzes Wissen in die Waagschale geworfen hatten, um ihre Organisationen auf Erfolgskurs zu halten. Die Ausgangssituation war für viele dieser Unternehmen durchaus komfortabel: Sie kannten ihre Märkte, sie kannten ihre Kunden und wussten, welche Produkte in Zukunft von den Kunden gewünscht werden. Genau dieses angesammelte Wissen war der Grund, warum sie schlussendlich untergingen. Klingt paradox? Das ist es auch.

1.2 Das Innovator’s Dilemma kann jedes Unternehmen treffen Der amerikanische Wirtschaftswissenschaftler Clayton Christensen hat dieses Phänomen bereits 1997 in seinem Buch „The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail“ beschrieben (Christensen 1997). Als Innovator’s Dilemma bezeichnet Christensen die Falle, in die Unternehmen tappen, wenn sie zu genau auf Kundenwünsche eingehen – denn dieses Vorgehen macht sie zu Opfern des Fortschritts. IBM ist ein Paradebeispiel für diese Zwickmühle: Mehr als zwei Jahrzehnte beherrschte IBM das Geschäftsmodell der Großrechenanlagen (die sogenannten Mainframes). Das Unternehmen deckte die gesamte Wertschöpfungskette ab, von der Herstellung der Prozessoren über das Design, die Fertigung, die Herstellung der Software bis hin zum Vertrieb der Großrechenanlagen (s. Abb. 1.1). Während der Dominanzphase von IBM im Bereich der Großrechenanlagen wuchsen die Datenspeicher immer weiter. Als Beispiel nennt Christensen den MainframeComputer IBM 305 RAMAC, der einen Speicher von 4,38 Mbyte hatte und 1956 etwa 200.000 US-Dollar (USD) kostete (THOCP 2011), was heute etwa 1,9 Mio. USD entspricht.3 IBM plante für sein damals aktuelles Modell die Produktion von 1800 Geräten.

1Exxon

Mobile ist das einzige Unternehmen, das länger dabei ist. Der Ölkonzern wird bereits seit 1928 im Dow Jones gelistet. 2Aus Gründen der Lesbarkeit wurde im gesamten Buch die männliche Form gewählt, nichtsdestoweniger beziehen sich die Angaben durchgängig auf Angehörige beider Geschlechter. 3Die Berechnung erfolgte mithilfe des Inflationsrechners fxtop.com.

1.2  Das Innovator’s Dilemma kann jedes Unternehmen treffen

3

Wertschöpfungskee

Prozessoren

Zeitalter

Design

Produkon

Mainframes

PCs

Soware

Vertrieb Weltmarkührer über die komplee Wertschöpfung

IBM

1960-1980

1990-2010

Betriebssystem

AMD, Intel

Apple, Lenovo

Compaq, Foxconn

Apple, Microso

Adobe, SAP

Amazon

Verlust der Führungsposion in allen Bereichen der Wertschöpfung

Abb. 1.1   Vergleich der Marktführer in der Computer-Wertschöpfungskette – Mainframe vs. PC

Um einen solchen Computer aufzubauen, zu betreiben und zu bedienen, wurden hochqualifizierte Mitarbeiter gebraucht, außerdem waren dafür zusätzliche Investitionen in Räumlichkeiten sowie Kühl- und Stromanlagen notwendig. Das konnten sich nur wenige Organisationen leisten und Anbieter-Unternehmen – wie eben IBM – konnten mit ihrem Geschäftsmodell große, risikoarme Umsätze und Gewinne je Kunde erwirtschaften. Was also besiegelte den Niedergang von IBM im Bereich der Rechenanlagen? Die Antwort lautet: ein disruptives Produkt. Clayton Christensen unterscheidet in „The Innovator’s Dilemma“ zwischen zwei Produktkategorien: aufrechterhaltende Produkte und Technologien („sustaining technologies“) und disruptive Produkte („disruptive technologies“). Der Unterschied zwischen den beiden Produktkategorien besteht darin, dass disruptive Technologien zunächst belächelt werden, wenn sie zum ersten Mal auf dem Markt erscheinen. Das liegt daran, dass die Marktteilnehmer – allen voran die potenziellen Kunden – die marktverändernde Kraft der Produkte zu Beginn unterschätzen. Doch die Einschätzung der Kunden ändert sich im Laufe der Zeit. Mit zunehmendem Erfolg verändern disruptive Technologien die Marktlogik ganzer Branchen (Fleig 2017). Akteure scheiden aus dem Markt aus, neue Akteure betreten den Markt, Produktion, Vertrieb und das Produkt selbst verändern sich. Am Ende bleibt in der betroffenen Branche kein Stein auf dem anderen. Der Prozess, in dem disruptive Produkte die vorherrschenden (aufrechterhaltenden) Produkte ablösen, läuft dabei immer nach dem gleichen Schema ab: Zunächst sind die neuen (disruptiven) Produkte kaum marktfähig. Sie werden von sogenannten „Early Adopters“ entdeckt, also Kunden, die sich für neue Produkte und Technologien begeistern bzw. diese in spezifischen Anwendungsbereichen für sich nutzen. Zu diesem frühen Zeitpunkt liegen die Performance und der Nutzungskomfort des neuen Produkts noch weit unterhalb der Performance des vorherrschenden Produkts. In dieser sogenannten Dilemma-Zone (s. Abb. 1.2) ist es für das bislang erfolgreiche Unternehmen schlicht nicht rational, in einen solchen Markt einzutreten (Harrison 2018). Das ist der Grund, warum etablierte Unternehmen den Anschluss verpassen. Genau das ist IBM passiert, als die Personal Computer (PCs) am Markt auftauchten. Die Technologie und marktverändernde Kraft eines Rechners, der auf den Schreibtisch passt, wurde schlichtweg unterschätzt. IBM war so großzügig (bzw. aus der heutigen

4

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

Geschäsentwicklung

Neues Geschä

mit disrupver Technologie und erweiterten Zielgruppen S-Kurve

Sustaining Innovaon

Dilemma Zone

Disrupve Innovaon

Aktuelles Geschä

mit bestehender Technologie und bekannten Kunden

Zeit

Innovator´s Dilemma Nach Clayton Christensen Abb. 1.2   Innovator’s Dilemma nach Clayton Christensen

Perspektive: so wahnsinnig), die Vermarktungsrechte an dem frisch entwickelten Betriebssystem für Personal Computer mit dem Namen MSDOS einer jungen Garagenfirma zu überlassen. Für einen Kaufpreis von damals 75.000 USD hatte dieses Startup zuvor die Rechte am Betriebssystem QDOS dem Unternehmen Seattle Computer Products abgekauft und das Betriebssystem in MSDOS umbenannt (Borchers 2011). Der Inhaber dieser Firma war Bill Gates, das Unternehmen heißt Microsoft. Auch und gerade durch den Fehler von IBM ist Bill Gates heute einer der reichsten Menschen der Erde. Die ersten PCs mussten noch aus Bausätzen zusammengelötet werden. Steve Jobs und Steve Wozniak – die beiden Gründer von Apple und die großen Konkurrenten von Microsoft – weigerten sich zunächst, fertig zusammengestellte PCs an die Geschäfte zu liefern (Vollmer 2018). Aus ihrer Sicht verstieß ein bereits zusammengebauter Rechner gegen das Prinzip des Produkts: Sie wollten einer technikaffinen Fan-Gemeinde ein neues Spielzeug bieten, an dem sie sich austoben konnte. Nach Diskussionen mit einem örtlichen Händler bot Apple schließlich 1976 den „Apple I“ für 666,66 USD an. Im Jahr darauf folgte der Apple II für 1300 USD (entspricht ca. 2600 USD nach heutiger Kaufkraft). Der Rechner war kostengünstig, bereits zusammengebaut und wesentlich einfacher zu bedienen. Der Apple II kostete nur etwa ein bis zwei Prozent des Preises eines Mainframes. Die Margen lagen im PC-Geschäft bei lediglich 34 % im Vergleich zu 56 % im Mainframe-Geschäft (Christensen 1997). Bereits 1979 verkaufte Apple 35.000 Geräte des neuen Typs und nur wenige Jahre später

1.2  Das Innovator’s Dilemma kann jedes Unternehmen treffen

5

bevölkerten Milliarden von PCs die Büros und Schreibtische der Nutzer weltweit. 2016 gab es nach Untersuchungen des Marktforschungsunternehmens Gartner knapp 1,5 Mrd. installierte PCs weltweit (Gartner 2016). Gleichzeitig veränderte sich das Vertriebsmodell von B2B auf B2C, Investitionen in eine neue Art von Marketing und Vertrieb waren notwendig und das kundenindividuelle Consulting erübrigte sich. Mit einem Schlag war IBM ein Geschäftsmodell abhandengekommen. Wozu sollte sich ein Unternehmen noch Großrechenanlagen leisten, wenn die Datenverarbeitung genauso gut dezentral auf den Schreibtisch-PCs stattfinden konnte? IBM ist aus dem tiefen Tal, das es nach dem teilweisen Verlust des eigenen Geschäftsmodells durchwandern musste, längst wieder aufgetaucht. Neben dem Geschäftsmodell mit Großrechenanlagen wurden Beratung und Dienstleistungen immer wichtiger. Aus dem unprofitablen Geschäft mit PCs verabschiedete sich IBM im Jahr 2004 und verkaufte die Sparte an Lenovo (Windeck 2014). Aus IBM wurde eines der größten digitalen Beratungsunternehmen und einer der wichtigsten Anbieter externer Rechenzentren weltweit. Das gelang dem Unternehmen aber nicht, weil es an den aufrechterhaltenden Technologien („sustaining technologies“) festgehalten hat, sondern weil es sich und seine Produkte neu erfunden hat. Die Gefahr, Entwicklungen falsch zu beurteilen, ist für ein Unternehmen aber auch dann nicht gebannt, wenn es sich einmal aus dem Innovator’s Dilemma freigestrampelt hat. Insbesondere im Bereich der Dienstleistungen für Rechenzentren befindet sich IBM dank der disruptiven Cloud-Technologien wieder in einem Innovations-Dilemma und versucht sich mit dem Kauf des Unternehmens RedHat daraus zu befreien (Grüner 2018). Die Produktgeschichte der letzten Jahrzehnte ist voll von Beispielen, wie disruptive Technologien am Markt etablierte Technologien ersetzen und ablösen können. Als die ersten Mobiltelefone Anfang der 1980er-Jahre auf den Markt kamen, wurden sie weltweit belächelt. Die alte (aufrechterhaltende) Technologie Telefon schien für den täglichen Bedarf auszureichen. Wenn der Nutzer doch einmal unterwegs telefonieren wollte, gab es schließlich Telefonzellen. In Deutschland brach geradezu eine Anti-Handy-Stimmung aus, Nutzer von mobilen Kommunikationsgeräten wurden jahrelang als Yuppies verunglimpft (Hackmann und Bremmer 2012). Damals jungen Unternehmen wie Nokia gelang es, die unhandlichen Geräte der Anfangszeit rasch durch deutlich kleinere Mobiltelefone zu ersetzen, die für den Massenmarkt tauglich waren. 1994 hatten gerade einmal 4,6 % der Deutschen einen Handyvertrag. Zehn Jahre später war der Anteil auf 86,4 % gestiegen (Bundesnetzagentur 2018). Die Ironie der Geschichte besteht darin, dass Nokia selbst wenige Jahre später zum Opfer des „Innovator’s Dilemma“ wurde. Mit den iPhones von Apple war 2007 eine neue Produktkategorie am Endkundenmarkt erschienen, die in kürzester Zeit die Nutzungsweise von Mobilfunkgeräten revolutionierte. Heute dominieren Smartphones von Apple, Samsung und Huawei die Mobilfunkmärkte, für das Jahr 2025 werden 5,8 Mrd. Mobiltelefone weltweit prognostiziert (GSMA 2019). Erinnern Sie sich noch an Nokia?

6

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

1.3 Disruptive Technologie Public Cloud Zahlreiche etablierte Unternehmen sind momentan dabei, in die Falle des Innovator’s Dilemma zu tappen. Die disruptive und damit zunächst leicht zu unterschätzende Technologie heißt dieses Mal „Cloud“. Gemeint ist damit eine Technologie, die eine dezentrale, automatisierte Bereitstellung von Rechenleistung, Speicher und weiteren IT-Komponenten ermöglicht. Wie in den beschriebenen Szenarien besitzt die Cloud-Technologie die disruptive Kraft, Märkte und Geschäftsmodelle grundlegend zu verändern. Cloud-Ansätze werden – ähnlich wie andere infrastrukturelle Innovationen der letzten Jahrhunderte – aufgrund ihrer einfachen Bedien- und Nutzbarkeit das Wirtschaften revolutionieren. Der Unterschied zu früheren Revolutionen wie Straßen, Stromnetzen und Wasserleitungen besteht darin, dass nicht mehr physische Produkte auf der neuen Infrastruktur transportiert werden, sondern digitale Rechenleistung in Form von Bits und Bytes. Um die Thesen dieses Buchs bereits jetzt zu „spoilern“: Die Cloud – so sie entsprechend genutzt wird – macht Unternehmen fit für das digitale Zeitalter. Und das auf allen Ebenen: vom grundlegenden Geschäftsmodell des Unternehmens über die Herstellung und den Vertrieb des Produkts bis hin zur internen Zusammenarbeit der Mitarbeiter (s. Abb. 1.3). Die Möglichkeiten der disruptiven Cloud-Technologie wurden bereits in den 1950er-Jahren von Herb Grosch erkannt, einem Mitarbeiter von – und hier schließt sich ein Kreis – IBM (Hühn 2018). Er träumte davon, Rechenleistung nicht mehr stationär vorzuhalten, sondern an riesige externe Rechenanlagen abzugeben. Technisch war der Aufbau eines dezentralen Rechenleistungsnetzes bereits zu dem Zeitpunkt möglich, als Herb Grosch die Idee hatte. Allerdings fehlten die nötigen technischen Bandbreiten, um die Daten in einer akzeptablen Geschwindigkeit via Telefonnetz zu übertragen und die verteilte Rechenleistung damit effizient nutzen zu können. Erst als sich die Breitbandtechnologie flächendeckend durchsetzte, konnte ein dezentrales Netz entstehen, in dem jeder Anbieter Rechenleistung in das Netz einspeisen und gegen ein Entgelt zur Verfügung stellen konnte (Lauchenauer 2016). SaaS Machine Learning

Transformierende Wirkung auf:

Geschäsmodelle

Internet of Things

Cloud-Technologien Social Media Serverless PaaS

Data Analycs

Digitale Transformaon

Mobile IaaS

Abb. 1.3   Transformierende Wirkung von Cloud-Technologien

Produkte Infrastruktur Mitarbeiter

1.3  Disruptive Technologie Public Cloud

7

Der Grundstein für den ökonomischen Erfolg der Cloud-Technologie war damit gelegt. Ein wichtiger Treiber hinter dieser Entwicklung war das Unternehmen Salesforce, dem es gelang, Unternehmenssoftware als Pakete im Netz anzubieten (sogenannte Software-as-a-Service). Dienste wie Software für die Verwaltung von Kundendaten mussten nicht mehr langwierig geplant und bestellt werden, sondern waren per Mausklick im Netz verfügbar. Genauso einfach wie Kunden heute Spotify nutzen. Internetgiganten wie Amazon, Microsoft und Google bauen seitdem riesige Rechenzentren – die sogenannten Hyperscaler – an unterschiedlichen Standorten weltweit auf. Auf der Größe mehrerer Fußballfelder werden abertausende Kleinstcomputer zu einem Netzwerk zusammengeschlossen und ans Netz gebracht. Ähnlich wie bei einem Stromnetz können die Kapazitäten dieser Rechenzentren je nach Auslastung hoch- oder heruntergefahren werden. Ein aktuelles Beispiel für die Anwendungsszenarien, die mithilfe der Cloud-Technologie möglich sind, liefert Alphabet, der Mutterkonzern von Google. 2019 steigt Alphabet mit einem Software-Streaming-Dienst namens „Stadia“ in den hart umkämpften Markt für Spielekonsolen ein. Stadia verdeutlicht das disruptive Potenzial der Cloud-Technologie: Die Nutzer dieses Dienstes sind nicht mehr darauf angewiesen, eine leistungsstarke Spielkonsole zu erwerben – es reichen eine schnelle Internetverbindung, ein Monitor und ein Eingabegerät. Die Rechenleistung bei der Bereitstellung des Spiels kommt aus dem Netz. Damit können Spieler an jedem Ort der Welt auf hochwertige Spiele mit aufwendiger Grafik zugreifen. Mit wenigen Mausklicks ist der Dienst im Netz geordert, die Bereitstellung und Abrechnung der Dienstleistung erfolgen automatisiert (Heuzeroth 2019). Allen diesen Vorteilen zum Trotz hat sich die Cloud-Technologie in Europa bislang nicht vollends durchgesetzt. Die Empfehlung von Beratern, mehr Ressourcen in die Implementierung von Cloud-Technologie zu investieren, löst in hiesigen Vorstandsetagen nach wie vor Beklommenheit aus (Holland 2016). Einerseits spüren die Manager intuitiv, dass dieser Trend in der Zukunft eine wichtige Rolle spielen wird. Gleichzeitig überlassen sie dieses Feld unternehmensintern lieber den IT-Leitern und CIOs, den technischen Direktoren (CTOs) oder schlicht der „Schatten-IT“. Bei der Schatten-IT handelt es sich um jene verdeckte IT-Organisation, die sich in Unternehmen entwickelt, wenn die offizielle IT-Abteilung den Wünschen der Fachabteilungen nach neuen Funktionen und Lösungen nicht nachkommt. Anwender aus den Fachabteilungen wie Marketing, Produktion oder Logistik nutzen dann – meist unter Umgehung interner Regelungen und Informationspflichten – die im Netz verfügbaren Cloud-Angebote, um ihre Fachprobleme selbst zu lösen (Manhart 2015). So ist es keine Überraschung, dass die Potenziale der Cloud-Technologie in Europa bislang vielerorts brachliegen. Das ist aber kein spezifisch europäisches Problem – auch auf anderen Kontinenten haben erst wenige Unternehmen die Möglichkeiten der Technologie erkannt und mit Vehemenz vorangetrieben. Vorreiter sind die USA, und hier

8

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

speziell die großen Internet-Unternehmen der amerikanischen Westküste wie Google, Amazon und Salesforce. Aber auch China treibt die „Cloudifizierung“ der heimischen Unternehmen von staatlicher Seite kräftig voran (s. Kap. 2). Bildlich gesprochen rollt mit der Cloud-Technologie eine Welle der Digitalisierung auf die Unternehmen zu, die wie Nichtschwimmer mit großen Augen den Aufprall erwarten. Sie haben zwar verstanden, dass die Welle groß ist und sie mitreißen wird, sie wissen aber nicht, wie sie mit dieser Erkenntnis umgehen sollen. Wie es bei Ertrinkenden zu beobachten ist, machen sie in dieser Situation alles falsch, was falsch gemacht werden kann. Statt nach dem Rettungsring zu greifen, der ihnen zugeworfen wird, schubsen sie ihn weg, halten die Luft an und hören auf zu schwimmen.

1.4 Das Ziel dieses Buchs: Surfbrett statt Rettungsring Dieses Buch richtet sich an jene Verantwortlichen in Unternehmen, die auf der Digitalisierungswelle reiten und nicht darin untergehen wollen. Daher dreht sich hier alles um die Chancen der Cloud-Technologie. Sie birgt das Potenzial, die Produktpalette an die Bedingungen der Digitalisierung anzupassen und neue digitale Geschäftsmodelle in kürzester Zeit nicht nur zu entwickeln, sondern auch online zu stellen – ohne große Investitionsrisiken. Das verändert ein Unternehmen von Grund auf, nämlich in seinem Selbstverständnis und seinen Arbeitsweisen. „Cloud-Transformation – wie die Public Cloud Unternehmen verändert“ liefert in diesem Zusammenhang Hilfe zur Selbsthilfe. Es versetzt die verantwortlichen Personen in die Lage, die Potenziale der Cloud-Transformation zu erkennen und für das eigene Unternehmen zu nutzen. In diesem Buch werden zunächst die wichtigsten Methoden und Tools der Softwareentwicklung beschrieben und hinsichtlich ihrer Wirkung auf die Transaktionsund Grenzkosten analysiert. Aus den Erkenntnissen wird ein konkreter Leitfaden für die Cloud-Transformation entwickelt, der Unternehmenslenkern hilft, die richtigen Schritte zur Digitalisierung ihres Geschäfts in die Wege zu leiten. Damit liefert das Buch die Grundlagen für den richtigen Umgang mit der heranrollenden Welle (s. Abb. 1.4). In diesem Sinne ist dieses Buch kein Rettungsring, der den Unternehmen zugeworfen wird. Vielmehr gleichen die Inhalte einem Surfboard, das Unternehmen nicht nur ergreifen können, sondern mit dem sie auf der heranrauschenden Welle reiten können. Ist das Surfen einfach? Nein, natürlich muss es erlernt werden. Die besten Surfer der Welt trainieren hart und viel – das bleibt auch Cloud-Surfern nicht erspart. Nur wenn ein Unternehmen bereit ist, sich auf den Prozess der Cloud-Transformation einzulassen und die nötige Begeisterung und Ausdauer mitbringt, kann der Prozess schlussendlich erfolgreich sein.

1.4  Das Ziel dieses Buchs: Surfbrett statt Rettungsring

Cloud senkt Grenzkosten

Die Welt wird digital

Einfluss auf die Webewerbssituaon Cloud senkt Transakonskosten Zusammenhänge erkennen

9

Intelligentes Outsourcing

Ausrichtung

Moderne Soware

Geschäsmodelle

Agile Organisaon Cloud-Transformaon lernen

Infrastruktur

Unternehmen digitalisieren

Abb. 1.4   Zielsetzung des Buches

1.4.1 Methodische Vorgehensweise Landauf und landab versprechen Unternehmensberater derzeit die Rundum-Digitalisierung eines Unternehmens innerhalb kürzester Zeit – zum Beispiel in nur 18 Monaten. Diese Versprechen lassen IT-Experten und CIOs einigermaßen ratlos zurück. Wie soll ein solches Konzept funktionieren? Werden da einige Monate lang sämtliche Abteilungen auf den Kopf gestellt und am Stichtag drückt der Vorstand den Alles-digital-Knopf?4 Wenn Ihr Unternehmen in kürzester Zeit digital werden soll, dann versuchen Sie doch Folgendes: Zücken Sie einfach Ihre Kreditkarte und besuchen Sie die Website von Azure oder AWS, den Cloud-Angeboten von Microsoft respektive Amazon. Nachdem Sie den kostenlosen Probemonat ausgewählt haben, können Sie innerhalb von fünf Minuten Ihren eigenen Server konfigurieren und bereitstellen. Sie brauchen dafür keine Schulung, sondern folgen einfach den Anweisungen. Mit etwa 20 Klicks haben Sie Ihre IT-Prozesse digitalisiert – und das in 30 min.5 Die Vorschläge zur Digitalisierung von Beraterseite gleichen in vielen Fällen den Diättipps, wie sie in Fitnesszeitschriften Monat für Monat zu finden sind. Dort werden Vorschläge unterbreitet („Die neue Ananas-Diät“), ohne dass bei den Diätinteressierten ein grundlegendes Verständnis für die Mechanismen des menschlichen Stoffwechsels entwickelt wird.

4Am

25. August 1967 drückte der damalige deutsche Kanzler Willy Brandt während einer Live-Übertragung von der Berliner Funkausstellung auf einen roten Knopf, um das Farbfernsehen in Deutschland zu starten. Die für die Umstellung verantwortlichen Techniker waren aber etwas übereifrig, sodass die neuen Farbtöne bereits Sekunden vor dem Drücken des Knopfes auf den Bildschirmen erkennbar waren. 5Eine Anleitung zur Durchführung einer kostenlosen Installation eines Cloud-Servers in 30 min finden Sie unter (Tamm und Frank 2019).

10

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

Dieses Buch liefert keine einfachen Rezepte und macht keine Vorschriften, welche Ziele Unternehmen in welchem Zeitraum erreichen müssen. Vielmehr geht es darum, die grundlegenden Zusammenhänge der digitalisierten Wirtschaft zu verstehen. Oder um in der Diät-Analogie zu bleiben: Der Leser soll verstehen, wie der digitale Stoffwechsel funktioniert und was diese Zusammenhänge für die Fitness eines Unternehmens bedeuten. Erst wenn die Digitalisierung als treibende Kraft für die Entwicklung der Geschäftsmodelle der Zukunft nicht nur akzeptiert, sondern auch die dahinterliegenden Mechanismen der IT verstanden wurden, können Unternehmen erfolgreich Fett ab- und Muskeln aufbauen. Daher beginnt dieses Buch mit der Darstellung der theoretischen Grundlagen, aus denen anschließend praktische Lösungsszenarien abgeleitet werden. Es wird dem Leser nicht vorgeschrieben, ob er Cloud-Anbieter A oder B wählen soll. Für den Muskelaufbau ist es auch erstmal nicht relevant, in welchem Fitness-Studio Sie trainieren – vorausgesetzt die Geräte funktionieren. Vielmehr soll der Leser verstehen, wo die Vorteile der Cloud liegen und worauf bei der Cloud Transformation zu achten ist. Mit dieser Herangehensweise richtet sich das Buch an zwei Zielgruppen: Es soll zum einen ein Leitfaden für Praktiker sein, die mit der Aufgabe der Cloud-Transformation betraut sind. Das sind Geschäftsführer, IT-Leiter und Mitarbeiter des Bereichs HR. Es spielt dabei keine Rolle, ob es sich um ein mittelständisches Unternehmen oder einen global agierenden Großkonzern handelt. Die grundlegenden Maßnahmen, die aus den theoretischen Vorüberlegungen abgeleitet werden, gelten für alle Unternehmensgrößen und über alle Branchen hinweg. Darüber hinaus richtet sich das Buch an Forscher und Wissenschaftler, die sich mit dem Thema der Cloud-Transformation beschäftigen. Für sie bietet das Buch zahlreiche eigene Modelle und Rechenbeispiele, die eine wissenschaftliche Einordnung des Themas ermöglichen. Gleichzeitig knüpft das Buch an bereits etablierte Ideen und Modelle an, die es den interessierten Forschern ermöglichen, die Themen aufzugreifen und weiter zu bearbeiten.

1.4.2 Wegweiser durch das Buch Der Aufbau des Buchs orientiert sich am „Golden Circle“ des britisch-amerikanischen Autors Simon Sinek. Die Basis jeder strategischen Entscheidung sollten die Antworten auf die drei Fragen „Warum tun wir etwas“, „Wie tun wir es“ und „Was tun wir“ sein (Sinek 2014). Erst wenn Sie verstanden haben, „warum“ Sie sich mit der Cloud-Technologie beschäftigen sollen, können Sie sich anschließend mit dem „Wie“ – also mit den zu ergreifenden Maßnahmen – und dem „Was“ beschäftigen, d. h. mit den Prozessen, die angestoßen werden müssen (s. Abb. 1.5). Kap. 2 beschäftigt sich mit der Frage nach dem Warum: Warum ist die Digitalisierung eine so mächtige Naturgewalt, die über die Unternehmen hereinbricht? Kurz gesagt

1.4  Das Ziel dieses Buchs: Surfbrett statt Rettungsring

11 Warum müssen wir handeln?

• Die Digitalisierung als dominierender Megatrend • Der strategische Einfluss der Cloud auf die Grenzkosten bei digitalen Geschäsmodellen

Wie sollten wir vorgehen?

Why How What

• Die Cloud als Automasierung der IT • Senkung der globalen Grenzkosten durch die Cloud-Transformaon auf nahezu Null • Cloud- und Soware-Know-how als Schlüssel zur We€bewerbsfähigkeit im digitalen Zeitalter • Redukon der Transakonskosten und netzwerkarge Wertschöpfungske€en

Was sollten wir tun?

• Bewährte Vorgehensmodelle je nach Intensität der Cloud-Transformaon • Die häufigsten Fragen rund um die Cloud-Transformaon

Abb. 1.5   Vorgehen des Buches

lässt die Digitalisierung mittelfristig in der Wirtschaftswelt keinen Stein auf dem anderen. Alle Produkte, die digitalisiert werden können, werden in den kommenden Jahren auch digitalisiert werden – oder wurden es bereits. Wenn eine Digitalisierung des Kernprodukts oder der Kerndienstleistung nicht möglich ist, werden alle Prozessschritte rund um die Erstellung und den Vertrieb des Produkts digitalisiert. Kap. 3 beleuchtet die Grenzkostenanalyse. Während bei Produktkategorien wie zum Beispiel Autos die Grenzkosten in der Regel nur bei sehr großen Produktionsmengen und sehr langsam sinken, ermöglichen digitale „Null-Grenzkosten-Produkte“ eine nahezu unendliche Skalierung. In den Kap. 4 bis 7 wird eine Antwort auf die Frage „Wie sollen wir vorgehen?“ gegeben. Digitale Geschäftsmodelle benötigen Software und diese muss erstellt, betrieben und skaliert werden. Mithilfe der Cloud lassen sich daraus weltweit skalierende Null-Grenzkosten-Geschäfte machen. Kap. 4 führt in die Herausforderungen der klassischen IT-Wertschöpfung ein und erklärt, wie die Cloud eben diese Wertschöpfung revolutioniert. Die wichtigsten Virtualisierungsstufen der Cloud werden dargestellt und Begriffe wie API und Microservices werden, für den technischen Laien verständlich, erklärt. Im Kap. 5 wird die Cloud-Transformation konkret anhand einer klassischen Applikation dargestellt. In der begleitenden Kostenanalyse wird ersichtlich, wie aus einer fixkostenintensiven, monolithischen Applikation eine global skalierende Cloud-Applikation mit Grenzkosten nahe Null werden kann. Kap. 6 beschreibt die wichtigsten Kompetenzen, die Unternehmen aufweisen sollten, wenn sie Software im Kern ihres digitalen Geschäftsmodells erfolgreich nutzen möchten. In Kap. 7 wird beschrieben, wie Cloud-Technologien und -Methoden die Transaktionskosten relevant senken. Outsourcing wird dadurch einfacher und risikoärmer, der Trend zum Outsourcing der sekundären IT-Wertschöpfung wird faktisch zur Pflicht. Der

12

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

Fokus von Unternehmen auf spezialisierte, aber weltweit skalierende Services führt zu einer Netzwerkökonomie, in der auch kleine Unternehmen überleben können. Kap. 8 beleuchtet das konkrete Vorgehen – das „Was“ – bei der Cloud-Transformation. Hier werden die Umsetzungsprinzipien nur angerissen, denn konkretere Ausführungen zu den Details der möglichen Cloud-Transformationen würden den Rahmen dieses Buchs sprengen. Kap. 9 stellt die Thesen des Buches abschließend in kompakter Form vor. Damit integriert dieses Buch drei Sichtweisen, die üblicherweise getrennt beschrieben werden: Ökonomie, Technologie und Organisationsentwicklung. Die Entscheidung, ob und wann eine tiefgreifende Transformation eines Geschäftsmodells notwendig ist, lässt sich durch eine Grenzkostenanalyse von Vertrieb und Produktion eines Produkts erkennen – sie liegt also im Bereich der Ökonomie. Ob ein Unternehmen fähig ist, sein Produkt zu wettbewerbsfähigen Grenzkosten anzubieten, hängt maßgeblich davon ab, wie gut es die Entwicklung, den Betrieb und die Skalierung von Software beherrscht – hier kommt die Technologie ins Spiel. Das Unternehmen mit seinen Mitarbeitern, Führungskräften, Prozessen, Kultur und Zusammenarbeit auf das neue digitale Geschäftsmodell auszurichten, um die Chancen der Technologie wirklich zu nutzen, ist ein Thema der Organisationsentwicklung. Das Marktforschungsunternehmen Gartner gibt jedes Jahr einen Bericht über den Entwicklungsstand disruptiver Technologien heraus. Dabei verwendet Gartner einen interessanten Ansatz: Es kombiniert die wachsende ökonomische Relevanz einer neuen Technologie über die Zeit mit dem Interesse, das der Technologie vonseiten der Öffentlichkeit entgegengebracht wird. Die daraus gewonnene Erkenntnis der Analysten lautet, dass sich eine disruptive Technologie in fünf Phasen – in einem „Hype Cycle“ – entwickelt. Nachdem die interessierte Öffentlichkeit auf die Technik aufmerksam geworden ist („Technologischer Auslöser“), steigt die Erwartungshaltung rasch an. So erreicht eine Technologie schnell den „Gipfel der überzogenen Erwartungen“. Zu diesem Zeitpunkt ist die ökonomische Rentabilität der Technologie allerdings noch nicht gesichert. Sie muss daher eine Zeit lang durch das „Tal der Desillusionierung“ wandern, bevor schließlich der „Pfad der Erleuchtung“ und das „Plateau der Produktivität“ erreicht werden. Im Gartner Hype Cycle für Emerging Technologies aus dem Jahr 2018 befinden sich die neuen Cloud-Technologien („Serverless PaaS“) noch auf der ersten Stufe (s. Abb. 1.6). Das heißt, dass vielen Unternehmen noch gar nicht bewusst ist, welche Chancen sich hinter der Anwendung der neuen Technologien verbergen. Gartner schätzt, dass bereits in zwei bis fünf Jahren diese neue Technologie als Mainstream-Technologie adaptiert wird. Deutsche Unternehmen haben mit der aktuellen Welle der Cloud-Technologie eine zweite Chance erhalten. Die zweite Welle der Cloud-Entwicklung mit den neuen „as-a-Service“-Themen bietet ihnen die Chance, von Gejagten zu Jägern zu werden. Ergreifen müssen die Verantwortlichen diese Chance selbst. Die folgenden Kapitel sollen Sie in die Lage versetzen, die Geschichte der Cloud-Gewinner selbst mitzuschreiben, statt in der Welle unterzugehen.

Literatur

13 Gipfel der überzogenen Erwartungen

Serverless PaaS

2-5 Jahre bis zur allgemeinen Adopon im Markt Plateau der Produkvität Pfad der Erleuchtung

Technologischer Auslöser

Tal der Desillusionierung

Abb. 1.6   Gartner Hypecycle 2018 (Panetta 2018)

Voraussetzung für eine erfolgreiche Cloud-Transformation sind drei Dinge: 1. Das Verständnis für die bahnbrechende Gewalt der Digitalisierung 2. Das Verständnis der eigenen Geschäftsmodelle 3. Der unternehmerische Wille, sich die für die Transformation notwendigen Skills in den Bereichen moderne Software, intelligentes Outsourcing und agile Organisation anzueignen. Ausgehend von diesem Ansatz kann die eigentliche Transformation beginnen: der durchaus nicht einfache Wandel etablierter Unternehmen als Grundlage für eine erfolgreiche Zukunft. Denn an Ihr Unternehmen soll sich niemand wie an ein Exponat aus dem Wirtschaftsmuseum erinnern müssen. Ihr Unternehmen soll auch in der Netzwerkökonomie der Zukunft eine Rolle spielen – weil es den Mut zur ständigen Erneuerung hat.

Literatur Borchers, Detlef (2011): 30 Jahre MS-DOS, erschienen in: heise.de, https://www.heise.de/newsticker/meldung/30-Jahre-MS-DOS-1286525.html. Bundesnetzagentur (2018): Jahresbericht, erschienen in: bundesnetzagentur.de, https://www. bundesnetzagentur.de/SharedDocs/Downloads/DE/Allgemeines/Bundesnetzagentur/Publikationen/Berichte/2019/JB2018.pdf?__blob=publicationFile&v=5, abgerufen im Juni 2019. Christensen, Clayton M. (1997): The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business Review Press, Boston. Fleig, Jürgen (2017): 3 Beispiele für eine disruptive Innovation, erschienen in: business-wissen. de, https://www.business-wissen.de/artikel/innovationen-3-beispiele-fuer-eine-disruptive-innovation/, abgerufen im Mai 2019.

14

1  Erinnern Sie sich noch an Daimler, RTL und Siemens?

Gartner (2016): Installed base of personal computers (PCs) worldwide from 2013 to 2019, erschienen in statista.de, https://www.statista.com/statistics/610271/worldwide-personal-computers-installed-base/, abgerufen im Juni 2019. Grüner, Sebastian (2018): Die riskante Wette auf die Cloud, erschienen in: golem.de, https://www. golem.de/news/ibm-kauft-red-hat-die-riesige-verzweifelte-wette-auf-die-cloud-1810-137384. html, abgerufen im Mai 2019. GSMA (2019): The Mobile Economy, erschienen in: gsmaintelligence.com, https://www.gsmaintelligence.com/research/?file=b9a6e6202ee1d5f787cfebb95d3639c5&download, abgerufen im Juni 2019. Hackmann, Joachim und Manfred Bremmer (2012): Funkstille war einmal, erschienen in computerwoche.de, https://www.computerwoche.de/a/funkstille-war-einmal,2516580. Harrison, Chris (2018): The HCI Innovator’s Dilemma, erschienen in: interactions.acm.org, https:// interactions.acm.org/archive/view/november-december-2018/the-hci-innovators-dilemma#R10. Heuzeroth, Thomas (2019): Google läutet das Ende der Spielkonsole ein, erschienen in: welt.de, https://www.welt.de/wirtschaft/webwelt/article190597597/Google-Playstation-Xbox-Mit-Stadia-gegen-Konsolen.html. Holland, Martin (2016): Umfrage: Deutsche Firmen scheuen „Cloud“ auch wegen „Bauchgefühls“, erschienen in: heise.de, https://www.heise.de/newsticker/meldung/Umfrage-Deutsche-Firmen-scheuen-Cloud-auch-wegen-Bauchgefuehls-3358260.html, abgerufen im Mai 2019. Hühn, Silvia (2018): Cloud Computing, erschienen in: ingenieur.de, https://www.ingenieur.de/ technik/fachbereiche/cloud/cloud-computing/, abgerufen im Mai 2019. Lauchenauer, David (2016): Die Entwicklung von Cloud ERP – Nutzung & Fakten, erschienen in: myfactory.com, http://www.myfactory.com/blogbeitrag/infografik-cloud-entwicklung.aspx, abgerufen im Mai 2019. Manhart, Klaus (2015): IT-Services in der Besenkammer, erschienen in: computerwoche.de, https://www.computerwoche.de/a/it-services-in-der-besenkammer,3214123. Panetta, Kasey (2018): 5 Trends Emerge in the Gartner Hype Cycle for Emerging Technologies, erschienen in: gartner.com, https://www.gartner.com/smarterwithgartner/5-trends-emerge-ingartner-hype-cycle-for-emerging-technologies-2018/, abgerufen im Mai 2019. Sinek, Simon (2014): Frag immer erst: warum: Wie Top-Firmen und Führungskräfte zum Erfolg inspirieren, Redline Verlag, München. Steinharter, Hannah (2018): Das sind die zehn wertvollsten Unternehmen der Welt, erschienen in: handelsblatt.de, https://www.handelsblatt.com/finanzen/anlagestrategie/trends/apple-googleamazon-das-sind-die-zehn-wertvollsten-unternehmen-der-welt/22856326.html?ticket=ST-3067435-Tu7M2KViYcSsmoUvbDh1-ap4, abgerufen im Mai 2019. Tamm, Andreas und Roland Frank (2019): In 30 Minuten in die Cloud, erschienen in:cloud-blog. arvato.com, https://cloud-blog.arvato.com/in-30-minuten-in-die-cloud, zum Zeitpunkt der Drucklegung noch nicht abrufbar. THOCP (2011): Mainframe, erschienen in: thocp.net, https://www.thocp.net/hardware/mainframe.htm. Vollmer, Jan (2018): Apple-Chronik: Von der Beinahe-Pleite zur wertvollsten Firma der Welt, erschienen in: t3n.de, https://t3n.de/news/apple-chronik-von-der-beinahe-pleite-zur-wertvollsten-firma-der-welt-1099260/, abgerufen im Mai 2019. Windeck, Christof (2014): IBM-PC-Sparte ist seit zehn Jahren bei Lenovo, erschienen in: heise. de, https://www.heise.de/newsticker/meldung/IBM-PC-Sparte-ist-seit-zehn-Jahren-bei-Lenovo2482096.html, abgerufen im Mai 2019.

2

Alles wird digital

Zusammenfassung

Der technologische Fortschritt ist Treiber des gesellschaftlichen und ökonomischen Wandels. Sowohl die zwischenmenschliche Kommunikation als auch die Arbeitsprozesse in Unternehmen – und in der Konsequenz das Leben jedes Einzelnen in einer vernetzten Gesellschaft – sind von den Veränderungen durch die Digitalisierung betroffen. Dieser Wandel verlangt ein Umdenken. Unternehmen müssen ihre Wertschöpfungsprozesse anpassen, um nicht als Verlierer aus dem disruptiven Wettbewerb hervorzugehen. Digitale Plattformen, die moderne Technologien effizient einsetzen und an das veränderte Nutzungsverhalten der Konsumenten angepasst sind, verdrängen klassische Geschäftsmodelle. Gleichzeitig sinkt die Bedeutung der physischen Produktion. Dadurch wird die Digitalisierung zu einem Katalysator für die Modernisierung von Unternehmen. In der Konsequenz stehen viele Unternehmen vor schmerzlichen Einschnitten. Die Umsetzung dieses Wandels erfordert Mut und Weitsicht. Diese Einschätzung wird mittlerweile auch von der Politik geteilt (BMWi 2019). In dieser Hinsicht kann die europäische Industrie sowohl von den Vorreitern der Digitalisierung im Silicon Valley als auch von den digitalen Jägern aus Fernost lernen.

2.1 Die technische Digitalisierung Wer den Newsfeed seines LinkedIn-Kontos öffnet, wird mit den Buzzwords der modernen Unternehmensführung „vollgespammt“: Chatbots, Blockchain, Internet of Things und Industrie 4.0 dominieren die Debatte (Bergmann 2017).

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_2

15

16

2  Alles wird digital

Die Digitalisierung ist zum heiligen Gral der Unternehmensführung geworden. Kein Meeting und keine Sitzung, die nicht mit einem Bekenntnis zu den neuen Bedingungen und Zielen des Marktes schließt. Der Begriff der Digitalisierung hat längst seine Griffigkeit verloren und ist bis zu einem gewissen Grad beliebig und austauschbar geworden. Wenn Sie sich einen Spaß daraus machen wollen, spielen Sie eine Runde Bullshit-Bingo1 – damit wird das nächste Strategiemeeting garantiert lustiger.2 Woher stammt die Bedeutung, die der Digitalisierung zugeschrieben wird, und welche Konsequenzen ergeben sich für die Unternehmensführung aus dieser Erkenntnis?− Zahlreiche Trendforscher haben die Digitalisierung zum wichtigsten gesellschaftlichen Trend des 21. Jahrhunderts ausgerufen (Schmidt und Drews 2016). In ihrer Bedeutung für die (Weiter-)Entwicklung der Gesellschaft wird die Digitalisierung längst mit der Industrialisierung des 18. und 19. Jahrhunderts und der Elektrifizierung des 20. Jahrhunderts gleichgesetzt. Der Begriff Digitalisierung besetzt unterschiedliche Bedeutungsebenen: Neben dem technischen Begriff ist Digitalisierung längst ein Synonym für den mit der technischen Revolution einhergehenden gesellschaftlichen und ökonomischen Wandel. In seiner ursprünglichen Bedeutung meint Digitalisierung einen technischen Prozess, der ein analoges Signal in ein digitales Signal umwandelt. Analoge Signale umgeben uns permanent, wir nehmen sie mit unseren Sinnen akustisch und optisch wahr. Der Prozess der Digitalisierung verläuft dabei in drei Stufen (s. Abb. 2.1): 1. Zunächst werden die analogen Signale von einem Analog-Digital-Wandler aufgezeichnet und in ein Datensystem aus Nullen und Einsen umgewandelt. 2. Diese digitalen Signale können gespeichert werden. 3. Durch einen Digital-Analog-Wandler können bei Bedarf die digitalen Signale wieder in ein analoges Signal rückgewandelt werden. Filtersysteme helfen dabei, die Signale zu „glätten“. Lange Zeit wurde die Entwicklung von Digitalisierungsprozessen kaum vorangetrieben – es gab schlicht keinen Bedarf dafür. Spricht ein Mensch beispielsweise in ein Mikrofon, so gibt es zunächst keinen Grund, das Signal digital zu wandeln. Ein Verstärker kann das analoge Signal der Tonwellen, das vom Mikrofon aufgefangen und weitergeleitet

1Ein Anbieter

für Bullshit-Bingo zum Thema Cloud ist beispielsweise Bullshitbingo.net. ist die Bezeichnung für eine Spielvariante des klassischen Bingo-Spiels. Dabei werden in allen Spalten und Zeilen einer Tabelle Begrifflichkeiten aufgeführt, die im Laufe des Business-Meetings verwendet werden könnten. Wenn ein Begriff gefallen ist, darf der Spieler diesen Begriff markieren. Der erste Spieler, dem es gelingt, eine ganze Zeile oder eine ganze Spalte mit markierten Begriffen zu füllen, hat gewonnen und darf laut „Bingo“ rufen. Ob eine Partie Bullshit-Bingo aus innerbetrieblicher Sicht tatsächlich zu empfehlen ist, bleibt dem Leser überlassen.

2Bullshit-Bingo

17

2.2  Die Folgen der Digitalisierung: Dezentralisierung …

Analoges Signal

Digitales Signal

Analoges Signal

Speicherung Abb. 2.1   Der technische Prozess der Digitalisierung

wurde, verstärken und an einen Lautsprecher zur Ausgabe weiterleiten. Das Ergebnis: Die Stimme des Menschen wird akustisch verstärkt, ohne dass ein digitaler Zwischenschritt notwendig gewesen wäre. Die Technologie akustischer Tonträger wie Schallplatte und Musikkassette basiert auf analogen Signalen. Auch das Radio verwendete lange Zeit ein analoges Signalsystem, dabei wurden für Radioübertragungen akustische Signale in elektromagnetische Wellen überführt. Diese konnten wiederum von Empfangsgeräten in hörbarer Form ausgespielt werden. Die Digitalisierung der Musikindustrie begann erst mit dem Zeitalter der Musik-CD Fahrt aufzunehmen. Erstmals wurden analoge Musiksignale in digitale Signale umgewandelt und auf digitalen Medien (z. B. CDs und Rechenanlagen mit Festplatten) gespeichert.

2.2 Die Folgen der Digitalisierung: Dezentralisierung, Kommunikation, Konvergenz Die Vorteile, die sich durch eine Digitalisierung für die Musikproduktion und den -vertrieb ergaben, wurden rasch deutlich: In komprimierter Form konnten Musikdateien auf immer kleineren Systemen gespeichert, getauscht und bearbeitet werden. Gleichzeitig konnten die digitalen Signale wesentlich effizienter weiterverarbeitet werden. Heute erledigen Software-Applikationen auf PCs und mobilen Endgeräten die Aufgabe von Musikstudios: das Aufnehmen und Bearbeiten der eingespielten Musik. Mit dem Format MP3 hat die Digitalisierung in der Musikindustrie einen vorläufigen Höhepunkt erreicht. Ein vierminütiges Musikstück braucht zum Beispiel statt etwa 50 MB nur noch 4 MB Speicherplatz. Dadurch konnten Musikdateien so stark

18

2  Alles wird digital

komprimiert werden, dass sie zu Beginn der 2000er-Jahre millionenfach auf illegalen Online-Plattformen wie Napster getauscht werden konnten (Fritz 2018). Diese Entwicklung stellte die Musikbranche aus ökonomischer Perspektive zunächst vor große Herausforderungen, da an diesem neuen Vertriebsweg weder die Künstler noch die Musikverlage beteiligt waren. Der Musikindustrie war „über Nacht“ das Geschäftsmodell abhandengekommen. Die finanziellen Auswirkungen waren enorm. Das traditionelle Geschäftsmodell stand vor dem Zusammenbruch: Immer weniger Endkonsumenten nutzten die klassischen Vertriebswege, um sich ein Musikstück auf einem Datenträger zu kaufen. Erst Apple gelang es, ein neues Geschäftsmodell für die Musikindustrie zu entwickeln und sie in ruhigeres Fahrwasser zu steuern. Der Launch des MP3-Players iPod im Jahr 2001 und der Plattform iTunes im selben Jahr überzeugten die Endkonsumenten, wieder Geld für den Kauf und den Konsum von Musikstücken auszugeben. Inzwischen wurde die Musikbranche ein zweites Mal innerhalb eines Jahrzehnts disruptiert. Heute ersetzen Streaming-Dienste den Kauf von Musik auf digitalen Vertriebswegen. Die Kunden schließen Abos ab und greifen im Gegenzug frei auf große Musikbibliotheken zu. Auch durch diese zweite Disruption des Musikmarktes betraten neue Akteure die Bühne und die Erlösmodelle der Branche wurden über den Haufen geworfen. Diese zweite Disruption hat dazu geführt, dass eine digitale Wertschöpfungskette aufgrund der besseren Nutzerfreundlichkeit eine zweite Wertschöpfungskette ersetzt hat. Die Vorteile der Digitalisierung, die in kürzester Zeit die gesamte Musikbranche veränderten, wurden auch von anderen Branchen aufgegriffen. Ausgelöst durch die bessere Speicher-, Übertrag- und Wandelbarkeit der digitalen Daten änderten sich in der Folge zahlreiche gesellschaftliche und technologische Prozesse. Jene Unternehmen, die als erste die neue Technologie übernahmen, standen an der Spitze des Wandels. Denn sie hatten erkannt, dass sich durch die Digitalisierung die Produktivität extrem steigern ließ. Natürlich blieb diese erste Digitalisierungswelle nicht folgenlos – im Wesentlichen beschleunigte sie drei Entwicklungen (s. Abb. 2.2):

Digitalisierung

Komprimierung

Personal Computer

Dezentrales Arbeiten

Übertragbarkeit

Internet

Neue gesellschaliche Kommunikaonsformen

Prozessierbarkeit

Smartphone

Konvergenz der Medien

Abb. 2.2   Auswirkungen der Digitalisierung

2.2  Die Folgen der Digitalisierung: Dezentralisierung …

19

1. Die Komprimierung von Daten sowie die höhere Leistungsfähigkeit der Endgeräte ermöglichte das dezentrale Arbeiten via Desktop PC. 2. Die einfachere Übertragbarkeit der Daten veränderte schlagartig die Bedeutung des Internets, das sich seit den 1980ern aus dem institutionellen Bereich hinausentwickelt hatte. Damit veränderte sich die Form der gesellschaftlichen Kommunikation massiv. 3. Die einfache Prozessier- und Kombinierbarkeit digitaler Daten durch Software führte zur Konvergenz der Medien, die ihren physischen Ausdruck in den Smartphones findet.

2.2.1 Digitalisierung als Bedingung des dezentralen Arbeitens Bevor sich die Desktop-PCs verbreiteten, wurden unternehmerische Datenverarbeitungsprozesse zentral in großen Rechenanlagen gesteuert. Anders wäre digitales Arbeiten zu diesem Zeitpunkt auch nicht möglich gewesen: Die Datenspeicher und Rechenanlagen waren schlicht zu groß, um sie ins Büro zu stellen. Stattdessen füllten die Datenspeicher und Datenverarbeitungssysteme ganze Kellerräume. Wollte ein Mitarbeiter einen Datensatz berechnen lassen, musste er sich mit diesem Anliegen an die Leiter der zentralen Rechenzentren wenden. Dieser interne Verwaltungsakt blockierte über Jahrzehnte die Möglichkeiten, die sich durch die Digitalisierung an nahezu jedem Arbeitsplatz ergeben. Umso erstaunlicher, dass die dominierenden Datenverarbeitungs-Unternehmen – allen voran IBM – nicht rechtzeitig erkannten, welche Vorteile eine dezentrale Datenverarbeitungsstruktur in einem Unternehmen bietet (Kap. 1). Die Vorteile der Komprimierung, Übertragbarkeit und Prozessierbarkeit von Daten revolutionierten das Arbeiten – doch möglich war das erst, als die Speicher handlich genug waren, um auf einen durchschnittlichen Büroschreibtisch zu passen. Beispiel Textverarbeitung: Ab Mitte der 1980er-Jahre eroberten Programme wie Word von Microsoft aufgrund ihrer massiven Produktivitätsvorteile die Büros (Hülsbömer und Dirscherl 2019). Statt den Text mühsam mit der Schreibmaschine aufzusetzen und möglichst auf Anhieb fehlerfrei verfassen zu müssen, konnte der Text am PC vorbereitet, überprüft, verbessert oder völlig umgebaut werden. Erst wenn das Dokument in seiner endgültigen Fassung („First Copy“) vorlag, wurde es ausgedruckt. Das „Speichermedium“ Papier verlor dadurch seine Bedeutung, denn die Daten wurden auf Disketten und Floppy-Harddiscs abgelegt. Bis zum papierlosen Unternehmen war es aber in den 1980er Jahren – und in manchen Unternehmen und Institutionen ist es das noch heute – ein weiter Weg. Einige der Leser werden sich an die Zeit vor der Digitalisierung der Büroarbeit erinnern können. Also an eine Zeit, in der Autoren die Fehler auf dem fertigen Dokument mit weißer TipEx-Farbe verbesserten, statt ein neues Dokument zu verfassen. Für jüngere Leser klingen diese Darstellungen möglicherweise wie Geschichten aus einer anderen Epoche. Das Spannende: Diese andere Epoche ist gerade einmal 30 Jahre her.

20

2  Alles wird digital

2.2.2 Digitalisierung als gesellschaftliches (Kommunikations-) Phänomen Die Komprimierung von Daten machte vor allem ihre Übertragung in Kommunikationsnetzwerken wesentlich einfacher. Vor allen anderen machten sich militärische und universitäre Institutionen Gedanken zum Datenaustausch über Telekommunikationsnetze. 1969 schlossen sich die ersten vier Universitäten zum sogenannten ARPA-Netzwerk zusammen (Rouse 2015). Ein Team rund um Tim Berners Lee, der für die Europäische Organisation für Kernforschung (CERN) in Genf arbeitete, erfand schließlich 1989 die technischen Standards zur Übertragung (http) und Darstellung (HTML) von Daten, der sich in der Folgezeit rasch am Markt durchsetzen sollte (Podbregar 2019). Für das Kommunikationsverhalten der Menschen war das revolutionär: Immer mehr Server wurden miteinander verbunden und so entstand ein Kommunikationsnetz, das den Datenaustausch per Telefonleitung mit den entlegensten Regionen ermöglichte. Vorbote dieser weltumspannenden Entwicklung war der Einsatz von E-Mail-Kommunikationssystemen ab Mitte der 1990er-Jahre. Das von Marc Andreesen und James H. Clark gegründete Unternehmen Netscape brachte bereits 1994 den ersten Webbrowser auf den Markt. Damit war es auch für Endkonsumenten möglich, Webseiten zu besuchen und eigenen Content zu verbreiten. Die ersten populären Anwendungsfelder der neuen technischen Möglichkeiten waren die Chatrooms, in denen sich wildfremde Menschen verstreut über die ganze Welt zu allen möglichen und unmöglichen Themen austauschten. Ergänzt wurden die Chatrooms ab Ende der 1990er Jahre durch Messaging-Dienste wie ICQ und MSN. 2004 gründete schließlich Mark Zuckerberg mit Kommilitonen an der Harvard University Facebook (FB). Obwohl es zu diesem Zeitpunkt bereits andere Social-Media-Plattformen gab, entwickelte sich Facebook rasch zum globalen Kommunikationsinstrument, das heute 2,38 Mrd. Menschen verbindet (Facebook 2019). Obwohl immer wieder neue Plattformen aufgetaucht sind, dominiert der Facebook-Konzern das globale Kommunikationsverhalten mit seinen Online-Messagingdiensten (WhatsApp, Facebook Messenger) und Social-Media-Kanälen (Facebook und Instagram). Mit der Digitalisierung von Inhalten und den neuen Kommunikationsplattformen veränderten sich also auch die gesellschaftlichen Kommunikationsprozesse. Der amerikanische Medientheoretiker Marshall McLuhan erkannte die Folgen der Digitalisierung für die Kommunikationsbeziehungen bereits 1962, als er in seinem Buch „The Gutenberg Galaxy“ die Entstehung einer neuen globalen Kommunikationsstruktur durch die digitale Vernetzung voraussagte (McLuhan 1962). McLuhan prognostizierte, dass durch die neuen Kommunikationsmittel Menschen zu jedem Zeitpunkt und von jedem Ort der Welt aus miteinander kommunizieren würden. Damit entstünde ein globales Dorf („global village“), in dem die Gesetzmäßigkeiten der Kommunikationsprozesse von kleinen Menschenansammlungen auf das digitale Zeitalter übertragen würden.

2.2  Die Folgen der Digitalisierung: Dezentralisierung …

21

Diese Entwicklung hatte weitreichende gesellschaftliche Implikationen. Beispielsweise wurden durch das freie Tauschen von Inhalten unterdrückte soziale Gruppen weltweit ermutigt, sich gegenseitig zu informieren und gemeinsam für die eigenen Interessen einzutreten. Der arabische Frühling im Jahr 2011 und die #Metoo Bewegung 2018 sind nur zwei von zahlreichen Beispielen für die demokratisierende Wirkung, die sich durch die Digitalisierung der Inhalte ergeben hat (Kneuer und Demmelhuber 2012). Gleichzeitig machen diese Kommunikationstools aber die Verbreitung von Fehlinformation (Fake News) wesentlich einfacher und sie öffnen die Tür für exzessive Überwachung – weiterführende Literatur zu diesem Thema finden Sie im Literaturverzeichnis am Ende dieses Kapitels.

2.2.3 Konvergenz der Medien Konvergenz meint das technische Zusammenwachsen von vormals getrennten (Medien-) oder Inhalts-Ökosystemen (Wagler 2018). Während vor der technischen Konvergenz die unterschiedlichen Medienformen und -inhalte getrennt voneinander konsumiert und vertrieben wurden, sank die Zahl der notwendigen Endgeräte für das Abspielen von Medien in den vergangenen Jahren rapide. Denken Sie an Ihr eigenes mediales Konsumverhalten: Noch vor Jahren trugen Sie möglicherweise einen MP3-Player, eine Digitalkamera, Bücher und einen Kalender mit sich herum. Heute verbinden sich alle diese Systeme in den Smartphones von weltweit etwa 5 Mrd. registrierten Anschlüssen (GSMA 2019). Das heißt, dass ca. 67 % der Weltbürger heute dieses Kommunikationsinstrument besitzen. Für die Medienkonsumenten ist dieser Wandel äußerst komfortabel, denn sie müssen entsprechend wenig Gewicht mit sich herumschleppen, um auf mediale Inhalte zugreifen zu können. Aus wirtschaftlicher Sicht ist aber spannend, dass mit dem Smartphone neue digitale Produkte und Vertriebswege für mediale Inhalte entstanden sind. 2008 launchte Google die Applikationsplattform „Android Market“, die 2012 in „Google Play Store“ umbenannt wurde. Auf dieser Plattform können die Nutzer neben Applikationen auch eBooks, Filme und Musikdateien erwerben und herunterladen. Apple hatte seine Konkurrenzprodukte iTunes und iPod bereits sieben Jahre zuvor gestartet und war damit ein Vorreiter der digitalen Konvergenz. Der iPod und später das iPhone revolutionierten die Art und Weise, wie Menschen Medieninhalte konsumieren. Durch die zunehmende Konvergenz steigt auch die Prozessierbarkeit medialer Inhalte. Mit den entsprechen Applikationen können Anwender mediale Inhalte kombinieren und eigenen Content produzieren. So macht das Internet aus passiven Konsumenten sogenannte „Prosumenten“ (Prosumer), die eigenständig Inhalte erstellen, bearbeiten und in sozialen Netzwerken teilen – seien es Selfies, kurze Videoclips oder Memes. Alles, was wir dazu brauchen, tragen wir inzwischen in der Jackentasche mit uns herum. Private und öffentliche Ereignisse können wir sofort mit der ganzen Welt teilen – und manchmal werden damit sogar Revolutionen koordiniert.

22

2  Alles wird digital

Hintergrundinformation: Konvergenz im TV Bereits 1995 stellte der Harvard-Professor Nicolas Negroponte eine interessante Frage, die sich aus der Digitalisierung von Fernsehsignalen ergab (Negroponte 1995): „Werden Fernseher PCs oder PCs Fernseher?“ Negroponte erkannte damals, dass die Digitalisierung von TV-Signalen zu einem Zusammenwachsen der beiden vormals getrennten Systeme PC und TV führen würde. Er sah voraus, dass TV-Geräte notwendigerweise in der Lage sein müssten, Datenströme zu verarbeiten. Gleichzeitig war er sich bewusst, dass PCs zum Abspielen von TV-Inhalten verwendet werden könnten. Es war daher aus der Perspektive des Jahres 1995 eine spannende Frage, welcher der beiden Standards sich in den Wohnzimmern der Konsumenten durchsetzen würde. Das Wettrennen zwischen den beiden Standards um die Vorherrschaft im Wohnzimmer startete bereits vor der Digitalisierung. Die ersten TV-Signale waren noch analog und wurden über Fernsehantennen übertragen, die lange Zeit das Landschaftsbild in Deutschland prägten. Anschließend wurde das analoge TV-Signal via Kabel von der Antenne an die Fernseher weitergeleitet und ausgestrahlt. War der Signalübertragungsprozess gestört, kam es zum berüchtigten „Weißen Rauschen“. Auch das Kabelnetz brachte zunächst noch keine Digitalisierung der Fernsehsignale. Selbst die TV-Signale, die über Satelliten wie ASTRA oder Eutelsat verbreitet wurden, waren zunächst nicht digital. Erst als den Betreibern der TV-Infrastruktur und -Netzwerke klar wurde, welche Vorteile eine digitale Übertragung mit sich bringen würde, kam die Veränderung in Gang: Durch die Digitalisierung der Signale konnten die Bandbreiten der Übertragungswege deutlich effizienter genutzt werden. Statt 20 Kanälen konnten nun via Satellit und Kabel hunderte Kanäle gleichzeitig übertragen werden. Ab den 2000er-Jahren hielten die ersten digitalen Receiver Einzug in die deutschen Haushalte, 2012 wurde die Verbreitung analoger TV-Signale über Satelliten beendet (Landesanstalt für Medien NRW 2012). 2008 wurde das analoge TV-Signal in Deutschland abgeschaltet und durch das DVBT-Signal ersetzt. Inzwischen (Stand 2019) müssen Fernsehgeräte auf den Standard DVBT 2 umgerüstet werden, um das digitale TV-Signal in Deutschland empfangen zu können (Verbraucherzentrale 2019). Es ist unklar, welche Zukunft diesen neuen digitalen Formaten beschieden sein wird. Denn voraussichtlich wird sich ein anderes Format weltweit durchsetzen: das sogenannte Internet Protocol Television (IPTV). Wie der Name schon sagt, wird bei diesem Standard das digitale TV-Signal über das Internet verbreitet. Konkret wird das Signal in einzelne IP-Pakete zerlegt und auf unterschiedlichen Übertragungswegen (5G, Kabelnetz, Telefonnetz) an den Zuschauer weitergeleitet. Neue SmartTVs sind technisch darauf vorbereitet, die IP-Signale zu empfangen und in ein analoges Bild auf dem Bildschirm umzuwandeln (Gründerszene 2019). Die Frage von Nicolas Negroponte aus dem Jahr 1995 kann heute also abschließend beantwortet werden. Die Antwort lautet: Inzwischen sind beide Entwicklungspfade eingetreten. Der Fernseher ist als Smart TV zum PC geworden, der mit integrierten Prozessoren und Applikationen in der Lage ist, digitale Formate auszuspielen. Das bedeutendste Format ist in Europa der HBBTV-Standard, der in nahezu allen aktuellen Smart-TV-Systemen integriert ist. Gleichzeitig ist es inzwischen üblich, TV-Inhalte auch über Laptops, Tablets oder Smartphones zu konsumieren.

2.3 Die völlige Digitalisierung der Wertschöpfung Die bisher dargestellten Veränderungen sind nur Vorboten einer deutlich gravierenderen Auswirkung der Digitalisierung. In komprimierter Form lautet die These: Alles wird digital.

2.3  Die völlige Digitalisierung der Wertschöpfung

23

Natürlich ist das überspitzt formuliert – nicht alle physischen Produkte lassen sich „wegdigitalisieren“. Dennoch wird es in der physischen Produktion einen großen digitalen Anteil geben, nur eben auf jenen Wertschöpfungsstufen, die der eigentlichen Produktion vor- und nachgelagert sind. Zweifellos ist die Industrie auch in diesem Zusammenhang Vorreiter: Die Digitalisierung macht es möglich, dass Unternehmen ihren gesamten Fertigungs- und Vertriebsprozess in digitaler Form und in Realzeit (Real-Time) abbilden können. Dadurch entstehen sogenannte „Digitale Zwillinge“ („Digital Twins“). Diese liefern die Grundlage für einen fertigungsübergreifenden Austausch und die Analyse der darin abgebildeten (Meta-) Daten (Sauer 2019). Bildlich gesprochen entsteht auf den Servern eines Unternehmens ein digitales Spiegelbild der realen Produktionssituation, das permanent neben der echten Welt „mitläuft“, die Eigenschaften und Prozesse abbildet und diese an Informationssysteme und digitale Datenbanken weiterleitet. Denken Sie beispielsweise an den öffentlichen Personennahverkehr. Noch vor wenigen Jahren war es undenkbar, dass ein Linienbus in Deutschland eine digitale Spur hinterlässt. Inzwischen sind die Busse durch die mobile Datenübertragung mit dem Internet verbunden. Zahlreiche Sensoren sind in den Bussen verbaut, die eine Repräsentation der Fahrzeuge in der digitalen Parallelwelt ermöglichen. Anhand von GPS-Daten wird der genaue Standpunkt des Busses ermittelt, Sensoren erfassen die Betätigung der Einund Ausstiegknöpfe durch die Fahrgäste. Inzwischen können auch der Ölstand und der Reifendruck per Sensoren erfasst und kontrolliert werden. In Summe entsteht ein digitaler Zwilling des Busses, der alle wertschöpfenden Funktionalitäten des Fahrzeugs in der digitalen Welt abbildet. Durch dieses digitale Spiegelbild sind neue Einsatzszenarien für die Kontrolle und Steuerung von städtischen Busflotten denkbar, die zum Teil bereits umgesetzt wurden. So können anhand der analysierten Daten die Ankunftszeiten der Busse prognostiziert und per App oder über digitale Anzeigetafeln an den Haltestellen an die Fahrgäste kommuniziert werden. Langzeitanalysen des Nutzungsverhaltens der Fahrgäste können dabei helfen, Fahrpläne zu optimieren und damit Kosten zu sparen. Auch die Abrechnung der Dienstleistung wird in naher Zukunft nicht mehr von Menschen oder Automaten, sondern durch bargeldlose Bezahlsysteme durchgeführt werden, die per Sensoren erkennen, wann ein Fahrgast ein- und aussteigt und welchen Tarif er dafür bezahlen muss. Übrig bleibt am Ende nur das physische Produkt, eingebettet in einen digitalen Prozess der Erstellung und des Vertriebs. Für die Wertschöpfung in Unternehmen bedeutet dies, dass zukünftig alle Stufen der Wertschöpfung dem Digitalisierungsprozess unterliegen. Die Formel für die Grenzen der Digitalisierung lautet daher: Ist das Produkt digitalisierbar, dann wird es auch digitalisiert. Das gilt heute bereits für Produkte wie Versicherungen oder Bankservices. Ist das Produkt nicht digitalisierbar, dann werden alle vor- und nachgelagerten Produktionsschritte digitalisiert. Wenn Sie im Jahr 2029 zum Friseur gehen, wird der Prozess des Waschens, Schneidens und Föhnens voraussichtlich noch von einem Menschen durchgeführt werden. Aber alle Wertschöpfungsschritte rund um die Dienstleistung werden digital ablaufen: Sie haben die Dienstleistung auf einer

24

2  Alles wird digital

Leistungsfähige digitale Endgeräte

Omnipräsentes Internet

Plaormbasierte Geschäsmodelle

Die Welt wird digital

Massendatenbasierte Individualisierung

Digitalisierung der Produkte Digitalisierung der Prozesse

•

Zunehmende wirtschaliche A rak­vität

•

„Winner takes all“Märkte

•

Verändertes Risikoprofil von Inves­­onen

Abb. 2.3   Die Digitalisierung verändert die ökonomischen Paradigmen

Verknüp mit historischen Informaonen und Kontext ergibt sich Wissen

Wissen

Informaonen Plaormen sammeln Daten

Das Wissen verhil Plaormen zu signifikanten Webewerbsvorteilen

Analysen geben den Daten Bedeutung

Daten Zeichen

Abb. 2.4   Datensammlung führt zu wissensbasierten Wettbewerbsvorteilen

digitalen Plattform eingekauft, digital bezahlt und bewertet. Auch die Information, wie der Schnitt aussehen soll, wurde dem Friseur auf dem Bildschirm eines digitalen Endgeräts angezeigt. Zusammengefasst eröffnet die Kombination aus leistungsfähigen digitalen Endgeräten, einem omnipräsenten Internet und der damit einhergehenden Individualisierung von Konsumprodukten eine neue Sichtweise auf die ökonomischen Paradigmen (s. Abb. 2.3). Diese neue Form der Digitalwirtschaft verändert auch die Wertschöpfungsprozesse von Unternehmen. Die Profiteure dieser Entwicklung sind digitale Plattformen, die immer größere Bereiche der Wertschöpfung auf sich vereinen (s. Abb. 2.4). Die großen Verlierer sind die Produzenten physischer Waren und Dienstleistungen.

2.4 Die Plattformökonomie – Daten sind das neue Öl Die deutsche Fachzeitung für Marketing „Horizont“ titelte am 21. März 2019 (Horizont 2019) „Alle wollen Plattform sein“. Der Artikel bezieht sich auf die Transformation des deutschen E-Commerce-Anbieters Otto, der sich als einziges deutsches Unternehmen im hart umkämpften Markt als E-Commerce-Anbieter behaupten konnte. Nun plant

2.4  Die Plattformökonomie – Daten sind das neue Öl

25

das Management einen neuen Schritt: Otto soll ab 2019 zu einer digitalen Plattform für Markenanbieter werden. Der ehrgeizige Plan sieht vor, dass bereits im Jahr 2020 rund 3000 Markenhersteller die neue Plattform nutzen (Campillo-Lundbeck 2019). Diese Transformation ist nur ein aktuelles Beispiel von vielen, das zeigt, wie groß die wirtschaftliche Bedeutung digitaler Plattformen geworden ist. Warum sind digitale Plattformen aus ökonomischer Perspektive so attraktiv? Die Wertschöpfung digitaler Plattformen unterscheidet sich grundlegend von den Wertschöpfungsprozessen herstellender Unternehmen. Sie basiert nämlich auf der Zusammenführung von Anbietern und Nachfragern auf einem gemeinsamen Marktplatz. Das Geschäftsmodell besteht also darin, die Daten von Kunden und Anbietern zu sammeln, zusammenzuführen und auf Passung („Matching“) zu überprüfen. Die physische Produktion von Produkten oder Dienstleistungen oder der physische Besitz von Waren und Betriebsstätten ist dabei keine Voraussetzung für den Erfolg von Plattformen. Airbnb ist als digitale Plattform der größte Anbieter von Hoteldienstleistungen weltweit – und das ohne eigene Hotels zu betreiben. Uber ist der größte weltweite Anbieter von Taxi-Dienstleistungen – ohne eigene Taxis zu besitzen. Diese Liste könnte endlos fortgesetzt werden (Urbach und Ahlemann 2016). Den Vorteil, den Wertschöpfungsmodelle, die auf Datensammlung basieren, gegenüber Geschäftsmodellen aufweisen, die auf physischer Produktion basieren, hat Marc Uri Porat bereits 1977 in seinem Buch „The Information Economy“ beschrieben (Porat 1977): Daten, die Zusammenhänge über Produktionsprozesse enthalten, können durch kognitive Prozesse in Informationen umgewandelt werden (s. Abb. 2.4). Verknüpft mit historischen Informationen und Kontext entsteht aus den Informationen Wissen über die Herstellung von Produkten und Dienstleistungen. Herstellungsverfahren können daher nicht verbessert werden, solange das Wissen über sie nicht zunimmt. Wenn aber nun Plattformen das Wissen über Produktionsprozesse anhäufen, dann sind sie auch die Träger und Überbringer möglicher Effizienzgewinne. Daten und Informationen, die auf Plattformen gesammelt werden, werden damit zu den Effizienztreibern der Produktion, und die Produktivitätsgewinne fließen zunehmend in die Kassen der Plattformbetreiber. Deshalb besitzen digitale Plattformen auch eine so große ökonomische Anziehungskraft: Eine Plattform wie „booking.com“ weiß mehr über das Nutzungs- und Buchungsverhalten von Gästen als die Hotelbetreiber. Diesen Vorsprung nutzt booking.com, um den Kunden die richtigen Angebote zum richtigen Zeitpunkt zukommen zu lassen. Sie wissen besser, welcher Gast welches Hotel haben will, und diesen Vorteil lassen sich die Plattformbetreiber von den Hotelanbietern teuer bezahlen. Was sind digitale Plattformen? Die Nutzung digitaler Plattformen ist für drei Marktseiten von Vorteil: Für die Nutzer bzw. Endkonsumenten sind Plattformen einfach bequem. Statt sich auf unterschiedlichen Anbieterseiten informieren zu müssen, reicht der Besuch der zentralen Plattform aus, um alle Angebote abrufen zu können. Die Anbieter der Ware oder der Dienstleistung haben ebenfalls Vorteile: Sie können

26

2  Alles wird digital

ihre Angebote einem viel größeren Nutzerkreis zugänglich machen. Die dritte Marktseite sind die Betreiber der Plattform. Sie finanzieren den Betrieb in der Regel durch Provisionen, Abonnements oder Werbeeinschaltungen. Dadurch ergibt sich also eine WIN-WIN-WIN-Situation. Ein Beispiel für diesen Erfolg liefert das Unternehmen Valve mit seiner 2003 gegründeten Plattform „Steam“, auf der Computer- und Videospielproduzenten ihre Spiele zum Download bereitstellen können. Spieler aus aller Welt können sich mit wenigen Klicks ein Nutzerkonto zulegen – Ende 2018 nutzten ca. 90 Mio. Menschen dieses Angebot und konnten so auf eine Bibliothek mit über 30.000 Spielen zugreifen (Computerbild 2019). Valve erhält als Betreiber der Plattform ca. 30 % des Umsatzes, die restlichen 70 % fließen an die Spieleproduzenten (Börner 2017). Digitale Plattformen gibt es in drei Ausprägungsformen: 1. Digitale Marktplätze Physische Waren oder Dienstleistungen werden Unternehmen oder Endkunden angeboten. Erfolgreiche digitale Marktplätze sind aktuell Alibaba aus China, Amazon, eBay oder Airbnb. 2. Streaming und Download-Plattformen Anbieter wie Spotify, Netflix oder Steam bündeln die medialen Angebote unterschiedlicher Produzenten auf einem gemeinsamen digitalen Marktplatz. Der Nutzer hat den Vorteil, dass ihm ohne großen Aufwand die wichtigsten Angebote an einem zentralen Ort zur Verfügung stehen und er die freie Wahl hat. Dabei unterscheiden sich die Refinanzierungsformen in Abo-Modelle (z. B. Spotify) und Einzelnutzung (z. B. Steam) 3. Digitale Service-Plattformen Digitale Service-Plattformen richten sich zumeist an Unternehmen. Sie vereinen auf der Plattform Angebote, die in die digitale Wertschöpfungskette integriert werden können. So gründete das deutsche Maschinenbauunternehmen Trumpf im Jahr 2017 die digitale Plattform AXOOM, auf der herstellende Unternehmen ihre Wertschöpfungskette integrieren und mit digitalen Angeboten erweitern können (Automationspraxis 2018). Andere Anbieter digitaler Serviceplattformen sind Cloud-Anbieter wie Microsoft oder Salesforce, die den Zugriff auf digitale Dienste ermöglichen.

Digitale Plattformen wären ohne die Produktion physischer Produkte und Dienstleistungen nicht denkbar, sie sind auf die reale Her- und Bereitstellung als Grundlage für die eigene ökonomische Wertschöpfung angewiesen. Dadurch entstehen symbiotische Beziehungen zwischen den digitalen Plattformen und den Herstellern. Ein Beispiel für die sich verändernden Beziehungen liefert das Unternehmen Tado aus München. Das 2011 von Christian Deilmann, Johannes Schwarz and Valentin Sawadski gegründete Startup bietet Haushaltsgeräte an, die per WLAN mit dem Internet verbunden werden können. Ein zentrales Produkt in der Angebotspalette ist der digital steuerbare Thermostat (Gat 2014). Bevor Tado und andere Unternehmen aus dem Bereich „Internet of Things“ (IoT) mit ihren digitalen Haushaltssteuerungsangeboten den Privatkundenmarkt betraten, gab es eine direkte Beziehung zwischen dem Heizungsnutzer und dem Heizungsanbieter (s. Abb. 2.5). Um die Einstellungen der Heizungsanlage zu ändern, musste der Kunde früher in den Keller und über eine – in der Regel nicht intuitive – Benutzeroberfläche mit der Heizung kommunizieren. Hatte der Kunde eine Frage oder ein Problem, musste er sich an den telefonischen Kundenservice des herstellenden Unternehmens wenden.

2.4  Die Plattformökonomie – Daten sind das neue Öl

27

Wertschöpfung Kunde

Abb. 2.5   Die Wertschöpfungsbeziehung zwischen Kunden und Anbieter

Wertschöpfung

Plaorm

Kunde

Abb. 2.6   Digitale Plattformen verändern die Wertschöpfungsbeziehungen der Anbieter zum Kunden

Mit digitalen Thermostat-Plattformen von Tado ändert sich das Prinzip der Wertschöpfung: Zwischen den Hersteller der Heizungsanlagen und den Endkonsumenten hat sich nun ein digitales System zur Bedienung des Produkts geschaltet (s. Abb. 2.6). Aus technischer Sicht erfolgt diese „Zwischenschaltung“ durch ein digitales Steuerelement, das an der Heizung des Nutzers angebracht werden muss. Sobald das Steuerungselement installiert ist, kann die Heizungsanlage mit digitalen Endgeräten gesteuert werden. Konkret können Sie als Endnutzer Ihre Heizung nun beliebig hochund runterfahren – und zwar von überall auf Welt, vorausgesetzt Ihr Smartphone ist mit dem Internet verbunden. Durch Machine-Learning-Algorithmen ist die Thermostat-Software von Tado darüber hinaus in der Lage, die Nutzungsgewohnheiten des Endkonsumenten zu speichern. Das System merkt sich, wann der Nutzer die Wohnung verlässt oder wieder betritt. Sobald es Muster in den Konsumgewohnheiten erkannt hat, beginnt das System eigenständig die Heizung zu steuern. Eine halbe Stunde, bevor der Wohnungsbesitzer nach Hause kommt, hat die Software die Heizung hochgedreht und die Wohnung vorgeheizt. Ökonomisch gesprochen wird der Hersteller des Systems durch die intuitive Nutzbarkeit der Plattform-Software vom Endkonsumenten entkoppelt. Die direkte Kommunikation zwischen den beiden Marktparteien entfällt und wird durch die digitale Plattform von Tado ersetzt.

28

2  Alles wird digital Transport

Medien

Unterkun

• NYCTaxi

• AT&T

• Hilton

• YellowCab

• Comcast

• Marrio

Uber

Nelix

airbnb

Abb. 2.7   Die ökonomische Macht digitaler Plattformen

Für die Heizungshersteller hat diese Entkopplung drastische ökonomische Konsequenzen. So ist es durchaus denkbar, dass über die Plattform von Tado in Zukunft weitere Dienstleistungen und Transaktionen abgewickelt werden. So könnte das System zum Beispiel den Füllstand eines Öltanks überprüfen und gleichzeitig einen Preisvergleich unter den regionalen Heizöl-Anbietern anstellen. Wenn das Heizungssystem das nächste Mal ausgetauscht werden soll, wird sich der Endkonsument möglicherweise aufgrund der besseren Kompatibilität zur Tado-Plattform für einen anderen Anbieter entscheiden. In den vergangenen Jahren haben es zahlreiche Unternehmen geschafft, solche Plattform-Positionen auf vormals „analogen“ Märkten zu besetzen. Digitale Plattformen besitzen damit eine ökonomische Sprengkraft, die ganze Branchen und Märkte disruptieren kann (s. Abb. 2.7). So wurde die Taxibranche durch Uber disruptiert, die klassischen Fernsehanstalten und Kinos durch Netflix und die Hotelbranche durch Airbnb und Booking.com. Zusammenfassend lässt sich feststellen: Die Digitalisierung sorgt dafür, dass sich Wertschöpfungsprozesse von der realen in die digitale Welt verlagern. Digitale Plattformen nehmen dabei eine Scharnierposition zwischen der realen Produktion und dem Endkonsumenten ein. Damit gelingt es den digitalen Plattformen, immer größere Teile der Wertschöpfung für sich zu beanspruchen.

2.5 Bedingungen für den erfolgreichen Betrieb digitaler Plattformen So verlockend das Geschäftsmodell zunächst aussehen mag, so schwierig ist es, am Konsumentenmarkt erfolgreich eine digitale Plattform zu platzieren. Die Gründe sind zahlreich: Als Voraussetzung muss es eine ausreichende Datenmenge („Big Data“) geben, dann muss überlegt werden, wie die durch die Daten geschaffenen Vorteile genutzt werden sollen („Data Leveraging“), und natürlich muss die schwierige Marktsituation mitbedacht werden („Winner takes all“).

2.5  Bedingungen für den erfolgreichen Betrieb digitaler Plattformen

29

2.5.1 Big Data

Weltweites Datenvolumen in Zeabyte

Daten sind der Rohstoff, den (digitale) Plattformen für den Betrieb von Geschäftsmodellen benötigen. Lange Zeit waren diese Daten aber nicht verfügbar bzw. wurden schlicht nicht aus ihrer analogen in die digitale Form überführt. Wie in den technischen Grundlagen der Digitalisierung beschrieben (Abschn. 2.2), müssen Daten zunächst digitalisiert werden, bevor sie in digitalen Systemen weiterverarbeitet werden können. In den vergangenen beiden Jahrzehnten ist die Zahl der digitalisierten Daten weltweit explodiert. Aktuelle Prognosen gehen davon aus, dass sich durch zusätzliche Sensoren und Digitalisierungsverfahren das Volumen der jährlich generierten Datenmenge vom Jahr 2016 (16,1 Zettabyte Daten) bis zum Jahr 2025 (163 Zettabyte) mehr als verzehnfachen wird (s. Abb. 2.8). Diese Zahlen sind mit dem menschlichen Verstand kaum vorstellbar. So entspricht ein Zettabyte gleich 10^21 Bytes, also einer Zahl mit 21 Nullen: 1.000.000.000.000.000.000.000. Der ehemalige Vorstandsvorsitzende von Google, Eric Schmidt, hat diese Entwicklung bereits 2010 kommentiert. Er stellte auf der Techonomy Konferenz in Lake Tahoe (Kalifornien) fest, dass die gesamte Menschheit gegenwärtig alle zwei Tage 5 Exabyte an Information erzeuge. Das ist so viel wie seit Menschheitsbeginn bis ins Jahr 2003 produziert wurde (Siegler 2010). Daten sind aber nicht nur der Rohstoff, der für den effizienten Betrieb digitaler Plattformen eingesetzt werden kann. Auch AI- und Machine Learning-Systeme benötigen große Datenmengen, um ihre Leistung zu verbessern. Damit sind all jene Unternehmen im Vorteil, die frühzeitig diesen Trend erkannt und mit der Speicherung von Daten begonnen haben. Sie können diese Daten bereits nutzen, um ihre digitalen Services und Dienstleistungen immer weiter zu verbessern.

163

150

Entspricht ca. 30% Wachstum pro Jahr

100

50 16

2016

2025

Abb. 2.8   Prognostizierter Anstieg des weltweiten Datenvolumens (Reinsel et al. 2018)

30

2  Alles wird digital

2.5.2 Data Leveraging Digitale Plattformen haben einen entscheidenden Vorteil gegenüber ihren analogen Konkurrenten: Sie können die Kundendaten nutzen, um damit die eigene Servicequalität und die eigenen Geschäftsmodelle voranzutreiben. Diese wertvolle Ressource lag in vielen Unternehmen jahrelang brach und wurde nicht genutzt. Inzwischen sind sich viele Unternehmen der Bedeutung der intern generierten Kundendaten bewusst und versuchen gezielt, diese Daten für die Verbesserung der Servicequalität ihrer Produkte einzusetzen. Ein Vorläufer dieses Trends waren die Customer-Relations-Management-Systeme (CRM), in denen Kundendaten von Unternehmen zentral gespeichert wurden und dann dezentral abgerufen und bearbeitet werden konnten. Diese CRM-Software-Systeme kamen in den 1990er-Jahren in Mode (Reissmann 2013). Sie basieren in der Regel auf einer Verknüpfung der digitalen Arbeitsoberflächen der Mitarbeiter mit einer Datenbank, die eine Übersicht über alle Kundenbeziehungen und -kontakte ermöglicht. Mit der Unterstützung durch CRM-Systeme konnten Synergien in der gemeinsamen Betreuung von Kunden genutzt und Redundanzen in der Ansprache vermieden werden. Die Internetunternehmen aus dem Silicon Valley sind längst einen Schritt weiter und haben sich zu wahren Spezialisten für die Monetarisierung des Datenschatzes entwickelt, auf dem sie sitzen. Dazu bauen sie einen Kreislauf zwischen kontinuierlicher Datensammlung, Datenauswertung und Produktverbesserung auf: den „Loyalty Loop“. Ziel dieses Verfahrens ist es, die Produkte und Dienstleistungen kontinuierlich zu verbessern und auf die Wünsche der Kunden auszurichten. Wesentlich ist, dass die Daten genutzt werden, um direkt Änderungen des Produkts bzw. der Dienstleistungen auszulösen und diese damit kontinuierlich anzupassen. Ein Beispiel dafür, wie der Loyalty Loop funktioniert, ist Tesla (s. Abb. 2.9). • 2018 hatte Tesla in seinen Fahrzeugen mit der „Over-the-Air“-Funktion – siehe Punkt 1 – die kostenlose Testversion der Autopilot-Software installiert (Pillau 2019). • Social-Media-Auswertungstools von Tesla zeigten, dass Insassen die Geschwindigkeit, mit der der Autopilot die Fahrzeuge durch scharfe Kurven steuerte, als zu hoch einstuften (Punkt 2). • Diese Erkenntnisse wurden durch die Auswertung der Telemetrie-Daten bestätigt, die aus den Autos permanent an das Unternehmen zurückgespielt werden. Es wurde deutlich, dass die Fahrer in scharfen Kurven häufig manuell eingreifen mussten (sogenanntes „overriding“ – Punkt 3). • Daraufhin entschied sich Tesla dazu, den Autopiloten anzupassen und eine neue „Kurvengeschwindigkeits-Adaption“ in den neueren Versionen zu integrieren. Die Systemupdates konnten wieder „over the air“ kostenfrei und parallel auf allen Tesla-Fahrzeugen installiert werden (Punkt 5).

2

1

Abb. 2.9   Der Loyalty Loop bei Tesla

Die Fernanalyse des Autopiloten ergibt tatsächlich, dass die Fahrer den Autopiloten häufig übersteuern.

In den sozialen Netzwerken gibt es Beschwerden über ein gefährliches Fahrverhalten bei scharfen Kurven.

Tesla gibt den neuen Autopiloten probeweise an Bestandskunden frei.

Kunde 3 6

Produkt

4

Schon ausgelieferte Autos werden im laufenden Betrieb mit der neuen Funkonen ausgestaet Nutzungsdaten der Fahrzeugfloe werden erhoben, um den Autopiloten weiter zu verbessern.

5

Tesla entwickelt „Curve Speed Adaptaon“ um das Fahrverhalten in Kurven besser zu steuern.

2.5  Bedingungen für den erfolgreichen Betrieb digitaler Plattformen 31

32

2  Alles wird digital 100 90

Nelix

80

Gewonnene Emmys

Anzahl

70

Nominierungen

60 50 40 30 20 10 0

2013

2014

2015

2016

2017

Abb. 2.10   Netflix verdoppelt die Anzahl der gewonnenen Emmys (Loesche 2017)

In Summe entstand so ein Kreislauf zwischen dem von den Kunden genutzten Produkt, einer immer genaueren Datenlage über die Funktionalitäten des Produkts und der Möglichkeit, das Produkt anhand der vorliegenden Daten zu verbessern. Auch viele andere Unternehmen setzen Data Leveraging ein. Amazon nutzt beispielsweise die Kundendaten für ein Vorschlagssystem, das Kunden darüber informiert, was andere Kunden mit ähnlichen Interessen einkaufen. Inzwischen ist Amazon sogar in der Lage, mit den vorliegenden Daten das Kaufverhalten der Konsumenten vorherzusagen. Beim sogenannten Preemptive Shipping erstellen Machine-Learning-Algorithmen eine Prognose, wie wahrscheinlich ein Kauf aus dem Warenkorb des Konsumenten ist. Diese Information kann dabei helfen, die interne Logistik zu verbessern und beispielsweise ein Produkt, das mit einer hohen Wahrscheinlichkeit vom Kunden gekauft wird, bereits in die richtige Region zu bringen – und das noch bevor der Kauf vom Konsumenten ausgelöst wurde. Auch Netflix greift auf den Loyalty Loop zurück. Konstant werden Kommentare, Bewertungen und Abbruchzeitpunkte in den unterschiedlichen Serien und Shows aufgezeichnet.3 Diese Daten werden eingesetzt, um die produzierten Formate noch besser an die Kundenwünsche anzupassen. Dadurch ist es Netflix gelungen, die Zahl der gewonnenen Emmy Awards – den „Oscars“ für Fernsehserien – zwischen 2013 und 2017 mehr als zu versechsfachen (s. Abb. 2.10).

3Auf Netflix wird mit Blick auf die hoch-skalierbare Leistungserbringung noch einmal ausführlicher in Kap. 8 eingegangen.

2.5  Bedingungen für den erfolgreichen Betrieb digitaler Plattformen

33

2.5.3 Winner takes all Ein entscheidender Nachteil der digitalen Plattformen sind die Netzwerkeffekte und die damit verbundenen Größenvorteile. Netzwerkeffekte treten immer dort in der Wirtschaft auf, wo der Wert eines Gutes durch seine zunehmende Verbreitung steigt. Ein Beispiel für diesen Zusammenhang liefert die Ausbreitungsgeschwindigkeit des Telefons. 1881 erschien in Berlin das erste Telefonbuch – mit gerade einmal 187 Einträgen. Bis 1885 tat sich wenig: Im Durchschnitt hatte bis dahin nur einer von 306 Berlinern einen Telefonanschluss registrieren lassen (Schwender 2019). Hauptsächlich wurde das Telefon für den Echtzeit-Austausch zwischen Institutionen wie Banken oder Ministerien eingesetzt. Erst als immer mehr Haushalte an das Telefonnetz angeschlossen wurden, setzte der Netzwerkeffekt ein, denn der derivate Nutzen des Produkts stieg für jeden weiteren Nutzer. 1900 gab es in Berlin knapp 35.000 Anschlüsse – damit war eine Kommunikation zwischen Endverbrauchern möglich und sinnvoll geworden. Robert Metcalf fand 1980 die passende Formel zu dieser Idee. Metcalf war zu diesem Zeitpunkt Entwickler am Forschungszentrum XEROX Parks in San Francisco und unter anderem an der Entwicklung des technischen LAN-Standards beteiligt. Seine Theorie: Im Gegensatz zu normalen Produkten, bei denen der Nutzen maximal linear zunimmt, wächst der Nutzen von Produkten mit Netzwerkeffekt exponentiell. Die Formel lautet:

N ∗ (N − 1)/2 Übertragen auf die Technologie Telefon bedeutet dies, dass bei 5 Telefonanschlüssen 10 Verbindungsmöglichkeiten existieren. Bei 105 Telefonanschlüssen sind es bereits 5460 (s. Abb. 2.11).

Abb. 2.11   Der Netzwerkeffekt

34

2  Alles wird digital

Die Wirtschaftlichkeit digitaler Plattformen folgt dem Netzwerkeffekt, denn auch hier wächst der Nutzen einer Plattform exponentiell mit der Zahl der Konsumenten. Stellen Sie sich einfach vor, bei WhatsApp gäbe es nicht Millionen von Nutzern, sondern gerade einmal fünf. Wäre es Ihnen da nicht schon zu viel, auch nur die Startseite der Applikation aufzurufen? Das Größenwachstum einer Plattform steigert ihre Attraktivität – und das lockt wiederum neue Nutzer an. Was dann folgt, ist ein Verdrängungswettbewerb zwischen den Plattformen: Die Plattform mit den meisten Anbietern zieht mehr Nachfrager an, was wiederum die Attraktivität der Plattform für die Anbieter steigert. Diese Form des Dualismus einer digitalen Plattform heißt „Two-sided Market“. Dahinter steckt die Annahme, dass die Plattform für die jeweils gegenüberliegende Marktseite nur dann attraktiv ist, wenn auf der anderen Marktseite bereits eine kritische Masse erreicht wurde (s. Abb. 2.12). Am Ende beißt sich die Katze in den Schwanz: mehr Anbieter führen zu mehr Nachfragern führen zu mehr Anbietern. Wenn es vonseiten der staatlichen Marktaufsicht keine Eingriffe gibt, besteht bei digitalen Plattformen die Gefahr von Monopolbildungen. Hat es erstmal eine Plattform geschafft, den Spitzenplatz zu erobern, haben es andere Plattformen deutlich schwerer, in den umkämpften Markt einzutreten. Die digitale Plattform eBay ist dafür ein gutes Beispiel: Die 1995 von Pierre Omidyar gegründete Online-Auktionsplattform schaffte es rasch, einen großen Teil des Marktvolumens für private Auktionen im Internet auf sich zu vereinen. Bis heute fällt es anderen Wettbewerbern schwer, auf diesem Markt Anteile zu gewinnen. Der Nachteil für die Kunden ist immens: Sobald das Monopol besteht, kann der Monopolist die Preise und Konditionen diktieren – und diese Situation wird von den Monopolanbietern auch ausgenutzt. So stiegen die Gebühren für das Einstellen einer Auktion auf eBay im Laufe der Zeit auf 10 % des Verkaufspreises an (Höwelkröger 2014).

Anbieter profieren von mehr Kunden

Pla orm Anbieter

Kunde Kunden profieren von mehr Anbietern

Abb. 2.12   Two-sided Markets

35

2.6  Erfolgsfaktoren für den Einsatz digitaler Plattformen

Insgesamt führt der Kampf um die Vorherrschaft auf den digitalen Marktplätzen zu einem Verdrängungswettbewerb. Darin besteht auch die Gefahr, denn langfristig können erfolgreiche Plattform-Anbieter die Marktkonditionen bestimmen, unter denen die Hersteller von Produkten und Dienstleistungen anbieten müssen.

2.6 Erfolgsfaktoren für den Einsatz digitaler Plattformen Aus den Schwierigkeiten, eine digitale Plattform erfolgreich am Markt zu etablieren, ergeben sich gleichzeitig jene kritischen Erfolgsfaktoren (Szczutkowski 2018), die für eine erfolgreiche Umsetzung einer Plattform-Strategie ausschlaggebend sind. Die neun Erfolgsfaktoren für den Einsatz digitaler Plattformen sind in Abb. 2.13 zusammengefasst: 1. Nützlichkeit Der Grundstein jeder erfolgreichen digitalen Plattform ist die Lösung eines bestehenden Kundenproblems. Dabei spielt es keine Rolle, ob der Kunde Probleme bei der Parkplatzsuche, bei der Terminierung von Arztbesuchen oder bei der Bestellung von Taxis hat, oder ob es um das Hören der Lieblingsmusik geht. Für Ingenieure und Techniker steht Problemlösung im Zentrum des eigenen Denkens und Handelns. Absolventen dieser Studienrichtungen wollen in vielen Fällen, dass ihre Ideen und ihre Arbeit nach dem Wert für die Gesellschaft beurteilt werden. Damit unterscheiden sich diese Studenten von Absolventen aus wirtschaftlichen Studiengängen, für die häufig die Profitabilität eines Geschäftsmodells im Vordergrund steht. Daher ist es kein Wunder, dass viele der erfolgreichen digitalen Plattformen von Ingenieuren gegründet wurden. Sie suchen nach Lösungen, die das Leben der Menschen verbessern und viele von ihnen haben erkannt, dass die Digitalisierung und digitale Plattformen dieses Potenzial besitzen. Jeff Bezos, der Gründer von Amazon, hat an der

Einfachheit der Bedienung Digitale Ökosysteme Risikobereitscha

Nützlichkeit

Individualisierbarkeit

Erfolgsfaktoren für digitale Plaormen

Agile Arbeitsmethoden

Abb. 2.13   Die Erfolgsfaktoren für digitale Plattformen

Geschwindigkeit Change-Mentalität Gesellschaliche Rahmenbedingungen

36

2  Alles wird digital

Princeton University Elektrotechnik und Informatik studiert, die Gründer von Google (heute Alphabet) – Larry Page und Sergey Brin – haben in Stanford Informatik studiert. Die Liste der Vertreter von Unternehmensgründern aus technischen Studiengängen ließe sich weiter fortsetzen (Frank 2017). 2. Einfachheit der Bedienung Digitale Plattformen erleichtern das Leben der Konsumenten, indem sie Datensätze und Informationen der Anbieter und Kunden so miteinander verknüpfen, dass dem Kunden exakt jene Dienstleistung oder jenes Produkt angeboten wird, die oder das er zu diesem Zeitpunkt benötigt. Und zwar mit möglichst wenigen (Maus)-Klicks. Zur Einfachheit der Bedienung gehören die Faktoren Zeit (jederzeit abrufbar), Ort (von überall abrufbar) und Cross-Devices (mit allen Geräten abrufbar). Unauffällig integrieren sich die digitalen Plattformen so in das Leben und die Handlungsabläufe der Menschen, ohne dass deren Nutzung als Hürde wahrgenommen wird. Denken Sie an Ihr eigenes Konsumverhalten: Bestellen Sie noch eine Pizza am Telefon? In der Regel nicht. Sie nutzen einen digitalen Plattformdienst via Browser oder in einer mobilen App. Der Verdrängungswettbewerb zwischen den Plattformen ist daher nicht nur ein Wettbewerb um die meisten Nutzer (Netzwerkeffekt), sondern auch ein Wettbewerb der einfachsten und intuitivsten Nutzbarkeit. Gleichzeitig verändert diese Entwicklung das Nutzungsverhalten der Konsumenten. Inzwischen erwarten Kunden eine einfache Benutzerführung nicht nur, sie fordern sie aktiv ein. Aus einer historischen Perspektive haben sich die Angebote der Plattformanbieter daher von Push- zu Pull-Märkten verändert. Während in der Anfangszeit der Komfortgewinn dadurch entstanden ist, dass die Plattformen überhaupt lanciert wurden, kümmern sich heute Techniker und Grafik-Designer um die möglichst intuitive Bedienbarkeit. Gelingt es den Plattformanbietern nicht, den Kunden in kürzester Zeit von der einfachen Handhabung zu überzeugen, kann dieser mit einem Mausklick zum nächsten Anbieter wechseln. „Komfort“ ist durch die Digitalisierung also zum festen Bestandteil des Konsumprozesses geworden. Den Kampf um das am intuitivsten nutzbare Produkt hat Eric Ries 2011 in seinem Buch „The Lean Startup“ beschrieben (Ries 2011). Ries propagiert, dass ein junges Unternehmen seine Ressourcen auf das Erstellen eines „Minimum Viable Product“ (MVP) konzentrieren soll: Für einen kleinen Markt werden funktionierende Prototypen gebaut, anhand des Kundenfeedbacks laufend verbessert und schließlich in ein breit vermarktungsfähiges Produkt gegossen. Die These von Ries lautet, dass es nicht entscheidend sei, ob ein Produkt beim Markteintritt bereits perfekt ist. Viel wichtiger sei es, dass ein Produkt beim Markteintritt seine Hauptfunktion für den Nutzer erfüllt. Durch die Erfahrungen am Markt könne das Produkt dann „iterativ“ weiterentwickelt werden. Eric Ries’ Empfehlungen an die Plattform-Gründer lauten:

2.6  Erfolgsfaktoren für den Einsatz digitaler Plattformen

37

• Teste deine Produkte am Markt, bevor du dich mit der Marktkapitalisierung beschäftigst. • Höre nicht auf Marktanalysten und Fokusgruppen. • Schau dir an, was deine Kunden sagen, die das Produkt täglich nutzen. 3. Individualisierbarkeit Die digitalen Plattformen beeinflussen auch die Produktionsentscheidungen von Unternehmen direkt. Bevor es digitale Plattformen gab, mussten Unternehmen für die Produktion umfangreiche und aufwendige Kapazitätsplanungen durchführen – heute können sie mithilfe der Plattformen viel einfacher und schneller die Angebotsmengen skalieren. Durch den schnellen Informationsaustausch mit den Konsumenten können Hersteller direkt auf die Bestellprozesse reagieren und müssen erst im Fall einer getätigten Transaktion mit dem Herstellungsprozess beginnen. Dadurch wird die Produktion immer individueller. Bücher und digitale Fotoalben werden erst gedruckt, wenn das Buch bestellt wurde. Autos laufen erst dann vom Band, wenn der Kunde die Farbe und die Ausstattung definiert hat. Dell hat daraus bereits in den 1990er-Jahren ein eigenes Geschäftsmodell entwickelt: den sogenannten negativen Kapitalumsatz („Negative Cashflow“). Dabei vereinbart ein Unternehmen mit den Lieferanten und Kunden unterschiedliche Zahlungsziele. Während der Kunde in der Regel direkt bezahlt und das Geld – beispielsweise via Kreditkarte oder PayPal – in Sekundenschnelle auf das Konto des Herstellers fließt, werden bei den Lieferanten möglichst lange Zahlungsziele angestrebt. Dadurch entsteht zwischen dem Zahlungseingang durch den Kauf und dem Zahlungsausgang für die Herstellung ein zeitlicher Abstand. In dieser Zeit kann der Hersteller produktiv mit dem erworbenen Kapital arbeiten, neue Investitionen tätigen oder das Geld gewinnbringend anlegen. 4. Digitale Ökosysteme Erfolgreiche digitale Plattformen bleiben in der Regel nicht bei einem einzelnen digitalen Angebot stehen, sondern erweitern im Laufe der Zeit ihre Palette an Dienstleistungen, damit der Anwender immer mehr Zusatznutzen durch neue Funktionen erhält. Dadurch entstehen digitale Nutzungs-Ökosysteme: Die Auswahl ist so allumfassend, dass es für den Kunden keinen Anreiz mehr gibt, die Webseite des Anbieters zu verlassen. Apple und Google sind solche Anbieter, aber auch Amazon oder Microsoft versuchen, immer größere Anteile der digitalen Dienstleistungen über die eigenen Plattformen anzubieten. So kann ein Kunde von Amazon mit der digitalen Assistentin Alexa heute bereits Flugtickets buchen, Reisen planen und Terminkalender verwalten. Das System warnt vor Staus auf dem Weg zur Arbeit und unterstützt bei der Lösung technischer Probleme im Haushalt. Google Maps wurde ebenfalls immer weiter funktional aufgewertet. Im Laufe der Jahre hat es sich zu einer Multifunktions-Applikation entwickelt, die in zahlreichen Systemen und Anwendungen integriert wurde. Inzwischen fungiert Google Maps

38

2  Alles wird digital

als digitaler Reiseführer, Veranstaltungskalender und Notfallplaner, etwa bei Überschwemmungen oder Erdbeben. Alle diese Funktionen können mittlerweile auch über den digitalen Assistenten Google Now abgerufen werden. 5. Geschwindigkeit Die Neuerungen auf digitalen Plattformen kommen in immer kürzeren Abständen auf den Markt – diese kurze „Time-to-Market“ ist ein wesentlicher Faktor für den Erfolg eines digitalen Plattform-Modells. Kunden erwarten heute, dass sie mit ihren Applikationen und Anwendungen permanent auf dem neuesten Stand der technischen Entwicklung sind. Um diesen Ansprüchen zu genügen, werden in rascher Folge Software-Updates entwickelt und automatisch auf den Endgeräten der Kunden installiert. Kenneth Kaufman von der Universität Stanford bringt diese Idee auf den Punkt (zitiert nach Keese 2016): „Drei Monate im Silicon Valley sind eine Ewigkeit.“ Für die Anbieter digitaler Softwarelösungen gilt also, nicht nur nützliche und einfache Produkte zu schaffen, sondern diese auch schnell am Markt bereitzustellen. Der Vorteil für die Anbieter ist, dass sie durch die hohe Geschwindigkeit auch schnelles Feedback vom Markt erhalten. Ob eine neue Funktionalität einer Plattform-Applikation angenommen wird oder nicht, zeigt sich bereits in den ersten Tagen nach der Installation. Das gibt Unternehmen die Gelegenheit, die eigene Herangehensweise an die Produktion zu verändern. Statt in umfangreichen Testläufen den Perfektionsgrad eines Produkts zu überprüfen, wird die Überprüfung dem Markt selbst überlassen. Es gilt daher: schnell scheitern, schnell lernen („Fail fast, learn fast“). Unternehmen, die nach dem neuen Paradigma agieren, entwickeln dadurch eine neue Fehlerkultur. Fehler werden nicht nur akzeptiert, sondern explizit als notwendiger Schritt zum Erfolg betrachtet (s. Abschn. 6.6). Portfoliotheorie Der US-amerikanische Ökonom Harry M. Markowitz hat 1952 in seiner Portfoliotheorie das optimale Investitionsverhalten von Anlegern an Aktienmärkten mit unterschiedlichen Risikopräferenzen dargestellt (Markowitz 1952). Die zentrale Aussage des Modells besteht darin, dass Anlageportfolios durch die Diversifikation von Risiken hinsichtlich ihrer Risiko-ErtragsSituation analysierbar sind und mit diesem Wissen optimiert werden können. Übertragen auf die Portfolio-Analyse eines Unternehmens können mithilfe dieser Theorie ineffiziente Risiko-ErtragsSituationen eines Unternehmens erkannt werden. Abb. 2.14 stellt diesen Zusammenhang dar. Im Modell von Markowitz kann sich ein Anleger entscheiden, in welchem Mischungsverhältnis er sein Kapital auf zwei unterschiedliche Anlagearten verteilt: zum Beispiel auf vergleichsweise sichere Anleihen mit kleinerer Verzinsung oder auf vergleichsweise risikobehaftete Aktien, die dafür aber eine potenziell höherer Rendite aufweisen. Steckt der Anleger sein gesamtes Kapital in Anleihen (Punkt A), ist das aus ökonomischer Perspektive ineffizient. Mischt er – ausgehend von Punkt A – seinem Portfolio Aktien bei, dann steigt zunächst seine mögliche Rendite bei sinkendem Risiko. Ein Beispiel für diesen Zusammenhang liefert die Finanzkrise im Jahr 2009/2010. Zu diesem Zeitpunkt waren die griechischen

2.6  Erfolgsfaktoren für den Einsatz digitaler Plattformen

39

Staatsanleihen aufgrund der mangelnden Solvenz des griechischen Staates von einem Totalausfall bedroht (Höhler 2016). Und das, obwohl Staatsanleihen als eine der sichersten Anlageklassen weltweit gelten. Aus Anlegersicht ist es daher ökonomisch nicht sinnvoll, einen Punkt zwischen A und B zu wählen. Punkt E steht für ein Depot des Anlegers, das zu 100 % aus Aktien besteht. Auch dieser Punkt ist aus der Perspektive der Portfoliotheorie ineffizient, da zwischen den Punkten D und E eine etwas höhere Renditeaussicht mit einer viel höheren Ausfallwahrscheinlichkeit einhergeht. Die Logik des Risikomodells der Portfoliotheorie von Markowitz lautet daher: „Don’t lay all your eggs in one basket.“ (Deutsche Übersetzung: „Nicht alles auf eine Karte setzen“). Punkt B bezeichnet den Punkt der geringsten Wertschwankung. Fügt der Anleger seinem Depot – ausgehend von Punkt B – weitere Aktien hinzu, so erkauft er sich entlang der sogenannten Grenzeffizienzlinie eine potenziell höhere Rendite mit einem höheren Risiko. Ein rationaler Anleger wählt somit einen Punkt zwischen C und D in Abhängigkeit seiner eigenen Risikobereitschaft. Mithilfe der kombinierten Erkenntnisse der Portfoliotheorie und der BCG-Matrix (s. Kap. 3) können Produktportfolios von Unternehmen analysiert und optimiert werden. So ist es aus ökonomischer Perspektive weder ratsam, alle zukünftigen Investitionen in die bislang erfolgreichen Cash-Cows zu stecken (das entspräche Punkt A), noch sollten alle bisher erfolgreichen Produkte über Bord geworfen und alle Hoffnungen (und die damit verbundenen Geldmittel) auf junge Question-Mark-Produkte gesetzt werden.

6. Risikobereitschaft Im Sinne der Portfoliotheorie von Markowitz sollten sich Unternehmen bei ihrem Einstieg in digitale Plattform-Geschäftsmodelle bewusst sein, dass das Eingehen von Risiken zur Plattform-Ökonomie dazugehört. Der Erfolg einer digitalen Plattform hängt von zahlreichen Faktoren ab, unter anderem von der Fokussierung der Kunden auf die größten Anbieter („Winner takes all“). Unternehmen, die in den Plattform-Wettbewerb

Abb. 2.14   Portfoliotheorie nach Markowitz

E

Rendite

10%

D

C

5%

B

5%

A

10%

Risiko

15%

20%

40

2  Alles wird digital

einsteigen wollen, müssen also kurzfristig durch Investitionen das unternehmerische Risiko erhöhen – gleichzeitig steigen dadurch die potenziellen Erträge in der Zukunft. Sie verschieben daher ihr eigenes Produktportfolio im Sinne der Portfoliotheorie von Markowitz von Punkt C in Richtung Punkt D (s. Abb. 2.14). Mit der größeren Risikobereitschaft der Unternehmen ist die zur Verfügung stehende Menge an einsetzbarem Risikokapital eng verbunden. Nehmen wir als Beispiel ein Startup, das eine digitale Plattform auf den Markt bringt: Die Finanzierung von Startups wird meistens durch Risikokapitalgeber (Venture Capital) gesichert. In der Regel tauschen die Venture Capitalists ihre Investitionen gegen Anteile am Startup. Sind die jungen Unternehmen erfolgreich, steigt auch der Wert der Anteile. Nichtsdestotrotz ist es ein riskantes Spiel: Etwa 80 % der Startups, deren Markteintritt von Venture-Capital-Unternehmen mitfinanziert wurde, scheitern innerhalb der ersten drei Jahre (Kucklick 2013). Etablierten Unternehmen geht es nicht anders: Sie müssen die Gefahr des Scheiterns und eines Totalausfalls ihrer Investitionen einkalkulieren. Aufgrund der in Abschn. 2.4 beschriebenen Marktbesonderheiten („Data Leveraging“, „Winner takes all“) ist die Gefahr des Scheiterns im Bereich digitaler Plattformen sogar deutlich höher als bei anderen Investitionsformen. 7. Change-Mentalität Mit der Risikobereitschaft geht auch die Bereitschaft einher, innerhalb des Unternehmens etwas zu verändern. Das Prinzip, das über viele Jahre für erfolgreiche Unternehmen galt – nämlich die Pflege der eigenen Cash Cows – gilt unter den Voraussetzungen der Digitalisierung nur noch eingeschränkt. Steve Jobs hat diese Bereitschaft zum Wandel im Laufe seiner Tätigkeit mehrfach unter Beweis gestellt: Und zwar indem er permanent die Erfolgsprodukte der Vergangenheit infrage stellte – und zwar auch und gerade dann, wenn die Umsätze sprudelten (Gassmann et al. 2013). Mit diesem Vorgehen ist es Steve Jobs gelungen, im Laufe seines Lebens gleich vier Märkte mit seinen Produkt- und Geschäftsideen zu disruptieren: 1. Den Markt für Großrechenanlagen (mit dem Apple Home Computer) 1. Die Musikindustrie (mit Apple iTunes und dem IPod) 2. Die Filmindustrie (mit dem von ihm geführten Unternehmen Pixar) 3. Den Mobilfunkmarkt (mit dem Apple iPhone) Im Geschäftsleben wird die Bereitschaft zum Wandel als „Pivoting“ bezeichnet. Das bedeutet, dass Unternehmer die Bereitschaft aufweisen, eine ursprünglich eingeschlagene Richtung vollständig zu ändern und sich den Bedingungen des Marktes anzupassen. Tesla ist das beste Beispiel für dieses Pivoting: Gründer Elon Musk war bereit, sein ursprüngliches Konzept für die Produktion von E-Autos über Bord zu werfen und stattdessen mit einem völlig neuen Produkt in einem zweiten Anlauf den Markt zu erobern.

2.6  Erfolgsfaktoren für den Einsatz digitaler Plattformen

41

Ein weiteres Beispiel für ein riskantes, aber schließlich erfolgreiches Pivoting ist Instagram, das heute zur Facebook-Gruppe gehört. Das Unternehmen startete zunächst unter dem Namen „Burbn“ mit einer mobilen Applikation, die es Usern ermöglichte, Bilder zu posten und in Lokalitäten „einzuchecken“. Doch die Applikation war ein Flop, obwohl sie kräftig von Venture Capitalists finanziert wurde. Das Problem war, dass die Applikation vor Features nur so strotzte und sich nicht klar genug von Konkurrenten wie Foursquare unterschied. Auch die zweite, völlig neu programmierte Version der App, die sich nur auf das Hochladen von Fotos konzentrierte, scheiterte. Erst nach dem dritten völlig frischen Anlauf enthielt die App neben der Hochladefunktion auch unterschiedliche Filter für die Fotobearbeitung – und nun war der Erfolg nicht mehr aufzuhalten. Instagram wurde so erfolgreich, dass das Unternehmen bereits zwei Jahre nach dem Start für eine Milliarde Dollar an Facebook verkauft wurde (Techcrunch 2019). 8. Agile Arbeitsmethoden Die Hochburg der weltweiten Digitalisierungsbewegung ist bis heute San Francisco bzw. das angrenzende Silicon Valley. Im Umfeld dieses ehemaligen Militärforschungsstandorts hat sich ein kreativer Cluster gebildet, durch den ein ökonomischer und sozialer Netzwerkeffekt ausgelöst wurde. Im Silicon Valley befinden sich Investoren und Gründer in unmittelbarer Nähe zueinander, und das zieht wiederum weitere Gründer und Investoren an. Ironischerweise ist eine Grundlage des Erfolgs im Silicon Valley die „analoge“ Arbeitskultur. Wichtige Meetings werden von Angesicht zu Angesicht abgehalten und wichtige Geschäfte ebenso auf diese Art abgeschlossen. Ingenieure und Investoren suchen in erster Linie das persönliche Gespräch – das prägt den Arbeitsalltag. Gearbeitet wird in der Regel in kleinen Teams, die interdisziplinär besetzt sind und in kurzen Sprints konkrete Software erzeugen (Abschn. 6.4). Agile Arbeitsmethoden wie Design Thinking prägen die Zusammenarbeit. Gelehrt werden diese Arbeitsmethoden bereits in der universitären Ausbildung vor Ort. Das Vorbild ist in diesem Zusammenhang die Stanford University, wo bereits 2005 ein Institut für Design Thinking unter Professor David M. Kelly gegründet wurde: die Stanford d.school. Heute heißt diese Einrichtung zu Ehren des deutschen Stifters und SAP-Gründers „Hasso Plattner Institute of Design“ (HPI 2019). Es verwundert daher auch nicht, dass zahlreiche digitale Geschäftsmodelle von Absolventen oder zumindest Studierenden der Stanford University entwickelt wurden: Hewlett Packard, Cisco, Google, Yahoo, Sun Microsystems, eBay, Netflix, Electronic Arts, Silicon Graphics, LinkedIn und PayPal. Die Professoren sehen sich hier als „Geburtshelfer“, die das unternehmerische Denken ihrer Studenten fördern und bei den Ausgründungen helfen. Nach einer Studie der Stanford University in eigener Sache sind aus Stanford etwa 40.000 Unternehmen hervorgegangen, die zusammen 5,4 Mio. Arbeitsplätze geschaffen haben und einen Umsatz von jährlich 2,7 Billionen USD erwirtschaften (Keese 2016).

42

2  Alles wird digital

9. Gesellschaftliche Rahmenbedingungen Die gesellschaftlichen Rahmenbedingungen tragen maßgeblich zum Erfolg einer digitalen Plattform bei. Dazu zählen externe Faktoren des Marktes und die Einflussnahme der Politik auf den ökonomischen Prozess. Auf Kundenseite stellt sich die Frage, inwieweit innerhalb der Gesellschaft eine Nachfrage nach neuen, digitalen Angeboten herrscht. Amerikanische und chinesische Unternehmen haben im digitalen Wettbewerb beispielsweise den Vorteil der Größe des Heimatmarktes. Aktuell leben in den USA rund 327 Mio. Menschen. Das entspricht etwa 150 Mio. Haushalten, die ohne Sprachbarrieren auf einem gemeinsamen Markt angesprochen und umworben werden können. In China sind die Zahlen noch weit beeindruckender: 2020 werden voraussichtlich über 300 Mio. Haushalte allein in den Städten Chinas angesiedelt sein. Davon verfügt über die Hälfte über ein Haushaltseinkommen von umgerechnet mehr als 16.000 USD pro Jahr (Atsmon et al. 2012). Auf beiden Märkten – sowohl in China als auch in den USA – hat sich auf Kundenseite eine digitale Euphorie breit gemacht. So stieg in China die Anzahl der Nutzer digitaler Dienste im Jahr 2018 auf über 800 Mio. Menschen (Kroll 2018). Zweifellos spielt die staatliche Unterstützung für den Erfolg von digitalen Plattformen eine große Rolle. Das fängt bei einer staatlich bereitgestellten, funktionierenden Infrastruktur an und zieht sich bis zu der Frage, wie innovationsfreundlich das Klima in einem Land ist und wie groß die finanzielle Unterstützung ist. Die USA und China haben in diesem Punkt eine weitere Gemeinsamkeit: Die Regierungen beider Staaten signalisieren seit Jahren ganz klar, dass Investitionen in digitale Angebote gefördert und durch staatliche Programme unterstützt werden. Allerdings gehen die USA und China dabei unterschiedlich vor. In den USA werden Unternehmen und Gründungsvorhaben steuerlich anders beurteilt als beispielsweise in Europa. So erhielt Amazon im Jahr 2018 eine Steuergutschrift über 129 Mio. USD – und das bei einem ausgewiesenen Jahresgewinn von 10,1 Mrd. USD (boersenblatt 2019). Das entspricht einer Steuerrate von – 1 %. Mit diesen Zahlen steht Amazon aber nicht allein da. Rund 100 Unternehmen aus dem Börsenindex Fortune 500 konnten 2018 ihre Steuern auf Null senken oder erhielten sogar Steuergutschriften (Firlus 2019). China hat im Gegensatz zu den USA einen anderen Entwicklungspfad eingeschlagen. Um den Aufholprozess zu beschleunigen, ist die chinesische Regierung bereit, große Summen in die finanzielle Unterstützung von digitalen Initiativen zu stecken. So unterstützt die „National Informatization Strategy“ (2016–2020) chinesische Unternehmen dabei, ausländische Märkte mit ihren digitalen Produkten zu erobern. Das Ziel der Regierung ist eine „digitale Seidenstraße“. Darüber hinaus wurden 2015 die beiden Programme „Made in China 2015“ und „Internet Plus“ gestartet, die dabei helfen sollen, die inländische Innovationskraft im Bereich der Digitalisierung zu stärken (Shi-Kupfer und Ohlberg 2019).

2.7 Fazit

43

So gelang es in den vergangenen Jahren Unternehmen wie Alibaba, Tecent und Huawei, auch in den westlichen Digitalmärkten immer größere Anteile zu gewinnen. Ein aktuelles Beispiel für diese Entwicklung ist das chinesische Unternehmen Bytedance, das unter anderem die in Westeuropa und den USA populäre Social-Media-Applikation „TikTok“ auf den Markt gebracht hat. Dabei setzt das Unternehmen konsequent auf künstliche Intelligenz, um das Nutzererlebnis mit den gesammelten Kundendaten zu verbessern. Mit seinem Erfolg ist Bytedance aktuell das teuerste Startup der Welt mit einem geschätzten Marktwert von 75 Mrd. USD (Byford 2018). Mit dieser national getriebenen Strategie war es möglich, dass sich China innerhalb von zwei Jahrzehnten von der verlängerten Werkbank der westlichen Welt zum Innovator im Digitalbereich entwickelt hat. China ist damit neben den USA ein globales Gravitationszentrum der digitalen Dynamik.

2.7 Fazit Die Digitalisierung ist der dominierende technologische und gesellschaftliche Trend der Gegenwart. Dieser Trend wird große gesellschaftliche Folgen haben, die über das kollektive Starren auf Smartphones in öffentlichen Transportmitteln weit hinausgehen. Die Thesen dieses Kapitels können in drei zentralen Aussagen zusammengefasst werden: 1. Alles wird digital. 2. Digitale Plattformen sind das erfolgreiche Geschäftsmodell der Gegenwart. 3. Für die Umsetzung von digitalen Plattform-Geschäftsmodellen sind zahlreiche Erfolgsfaktoren zu berücksichtigen. Mit der griffigen These „Alles wird digital“ wird betont, dass immer größere Anteile der gesamten Wertschöpfung aus dem physischen Herstellungsprozess in die digitale Datenprozessierung abwandern. Die Produktions- und Kapitalströme der Zukunft werden jene Unternehmen bestimmen, die die Kundenwünsche am besten kennen und befriedigen können. Damit stehen digitale Plattformen in der Pole Position der ökonomischen Entwicklung der nächsten Jahre. Denn die Betreiber dieser Plattformen haben in der Speicherung und Verarbeitung von Kundendaten die größten Erfahrungen erworben und haben dadurch das Konsum- und Nutzungsverhalten neu ausgerichtet. Die digitalen Märkte sind attraktiv, dementsprechend ist der Wettbewerb härter geworden. Zahlreiche Faktoren bestimmen über den Erfolg bzw. Misserfolg bei der Lancierung neuer Plattformen. Nur wenn Unternehmen diese Faktoren begreifen und geschickt einsetzen, können sie am Markt bestehen.

44

2  Alles wird digital

Europäische Unternehmen sind amerikanischen und chinesischen Unternehmen in puncto Digitalisierung aktuell unterlegen. Die USA und China haben schneller begriffen, wie sich die digitalen Märkte entwickeln werden und was die Erfolgsfaktoren der digitalen Märkte sind. Mit den passenden Förderprogrammen haben sich sowohl die USA also auch China im Bereich der digitalen Plattformen einen beträchtlichen Vorsprung herausgearbeitet. Viele Indikatoren deuten darauf hin, dass sich dieser Vorsprung in der Digitalisierung in den kommenden Jahren verfestigen wird. So haben die chinesischen Patentbehörden im Jahr 2017 über 420.000 Patente angemeldet. Das entspricht gegenüber 2016 einem Wachstum von 3,9 %. Dagegen wurden in den USA nur knapp 320.000 Patente erteilt, das Europäische Patentamt vergab gerade einmal knapp 106.000 Patente (Krempl 2018). Allerdings gibt es auch Indizien, die positiv für die europäischen Herausforderer gedeutet werden können: Je schneller sich die Technologie entwickelt, desto geringer wird der notwendige Aufwand, um Aufholprozesse einzuläuten. Das Beispiel China verdeutlicht, dass mit einer klaren Strategie und einem eindeutigen Ziel auch große Vorsprünge anderer Länder in digitalen Teilbereichen kompensiert werden können. Damit kann China als Wegweiser für die europäische Wirtschaft aufgefasst werden, mutig mit der digitalen Transformation voranzuschreiten. Wie dieses Szenario in den Unternehmen umgesetzt werden kann, wird in den folgenden Kapiteln untersucht.

Literatur Atsmon, Yuval, Max Magni, Lihua Li und Wenkan Liao (2012): Meet the 2020 Chinese Consumer, erschienen in: mckinsey.com, https://www.mckinsey.com/~/media/mckinsey/featured%20 insights/asia%20pacific/meet%20the%20chinese%20consumer%20of%202020/mckinseyinsightschina%20meetthe2020chineseconsumer.ashx, abgerufen im Juni 2019. Automationspraxis (2018): Axoom nun serienmäßig in Trumpf-Maschinen, erschienen in: automationspraxis.de, https://automationspraxis.industrie.de/news/axoom-nun-serienmaessig-intrumpf-maschinen/, abgerufen im Juni 2019. Bergmann, Thomas (2017): Digitalisierung – Hype oder kalter Kaffee?, erschienen in: linkedin.com, https://www.linkedin.com/pulse/digitalisierung-hype-oder-kalter-kaffee-thomas-bergmann/?originalSubdomain=de, abgerufen im Mai 2019. BMWi (2019): Bundesministerium für Wirtschaft und Energie – Nationale Industriestrategie 2030. Strategische Leitlinien für eine deutsche und europäische Industriepolitik. Als Download unter https://www.bmwi.de/Redaktion/DE/Publikationen/Industrie/nationale-industriestrategie-2030. pdf?__blob=publicationFile&v=24, abgerufen im Mai 2019. Börner, Yannik (2017): Steam: So hoch ist der Umsatz von Valve und Entwicklern, erschienen in: chip.de, https://praxistipps.chip.de/steam-so-hoch-ist-der-umsatz-von-valve-und-entwicklern_98293. Boersenblatt (2019): Amazon verdreifacht den Gewinn, erschienen in: boersenblatt.net, https:// www.boersenblatt.net/2019-02-01-artikel-jahresbilanz_2018.1592168.html, abgerufen im Mai 2019.

Literatur

45

Byford, Sam (2018): How China’s Bytedance became the world’s most valuable startup, erschienen in: theverge.com, https://www.theverge.com/2018/11/30/18107732/bytedance-valuation-tiktok-china-startup, abgerufen im Mai 2019. Campillo-Lundbeck, Santiago (2019): Wie die Marke Otto zur Plattform werden will, erschienen in: horizont.de, https://www.horizont.net/marketing/nachrichten/exklusiv-interview-wie-diemarke-otto-zur-plattform-werden-will-173696, abgerufen im Mai 2019. Computerbild (2019): Steam: Nutzerzahlen veröffentlicht – alle Werte im Überblick, erschienen in: computerbild.de, https://tipps.computerbild.de/unterhaltung/gaming/steam-nutzerzahlen-636561.html, abgerufen im Mai 2019. Facebook (2019): Facebook Q1 2019 Results, erschienen in: investor.fb.com, https://s21.q4cdn. com/399680738/files/doc_financials/2019/Q1/Q1-2019-Earnings-Presentation.pdf, abgerufen im Juni 2019. Firlus, Thorsten (2019): Amazon bekommt Steuern zurück, erschienen in: wiwo.de, https://www. wiwo.de/unternehmen/dienstleister/unternehmenssteuern-in-den-usa-amazon-bekommt-steuern-zurueck-/24007498.html, abgerufen im Mai 2019. Frank, Roland (2017): Vom CEO zum CTO – Sind Techniker die besseren Chefs?, erschienen in: cloud-blog.arvato.com, https://cloud-blog.arvato.com/vom-ceo-zum-cto-sind-techniker-die-besseren-chefs/, abgerufen im Mai 2019. Fritz, Stefan (2018): Worüber wir statt der Digitalisierung sprechen sollten, erschienen in: computerwoche.de, https://www.computerwoche.de/a/worueber-wir-statt-digitalisierung-sprechen-sollten,3544566, abgerufen im Mai 2019. Gassmann, Oliver, Karolin Frankenberger und Michaela Csik (2013): Geschäftsmodelle entwickeln: 55 innovative Konzepte mit dem St. Galler Business Model Navigator, Carl Hanser Verlag, München. Gat, Aviva (2014): Munich startup Tado keeps your house cool when no one is home, erschienen in: geektime.com, http://www.geektime.com/2014/04/21/munich-startup-tado-keeps-your-house-cool-when-no-one-is-home/, abgerufen im Juni 2019. Gründerszene (2019): IPTV, erschienen in: gruenderszene.de, https://www.gruenderszene.de/lexikon/begriffe/iptv?interstitial, abgerufen im Mai 2019. GSMA (2019): The Mobile Economy, erschienen in: gsmaintelligence.com, https://www.gsmaintelligence.com/research/?file=b9a6e6202ee1d5f787cfebb95d3639c5&download, abgerufen im Juni 2019. Höhler, Gerd (2016): So begann die Krise in Griechenland, erschienen in: rp-online.de, https:// rp-online.de/politik/ausland/der-23-april-2010-so-begann-die-krise-in-griechenland_aid9645883, abgerufen im Mai 2019. Horizont (2019): Alle wollen Plattform sein, erschienen in: Horizont, Ausgabe 12, 21.03.2019. Höwelkröger, Robert (2014): eBay erhöht seine Verkaufsprovision auf 10%, erschienen in: heise.de, https://www.heise.de/newsticker/meldung/eBay-erhoeht-seine-Verkaufsprovision-auf-10-Prozent-2086004.html, abgerufen im Mai 2019. HPI (2019): Geschichte des Hasso Plattner Instituts, erschienen in: hpi.de, https://hpi.de/das-hpi/ organisation/geschichte.html, abgerufen im Juni 2019. Hülsbömer, Simon und Hans-Christian Dirscherl (2019): Die Geschichte von Microsoft Office, erschienen in: pcwelt.de, https://www.pcwelt.de/ratgeber/Microsoft-Office-Mit-einer-Mausfing-alles-an-6091613.html, abgerufen im Mai 2019. Keese, Christoph (2016): Silicon Valley – Was aus dem mächtigsten Tal der Welt auf uns zukommt, Penguin Verlag, München. Kneuer, Marianne und Thomas Demmelhuber (2012): Die Bedeutung Neuer Medien für die Demokratieentwicklung, erschienen in: Medien und Politik, Bd. 35, Innsbruck-Wien-Bozen.

46

2  Alles wird digital

Krempl, Stefan (2018): Patente – China etabliert sich als Großmacht, erschienen in: heise.de, https://www.heise.de/newsticker/meldung/Patente-China-etabliert-sich-als-Grossmacht4239326.html, abgerufen im Mai 2019. Kroll, Sonja (2018): Mehr als 800 Millionen Internetnutzer in China, erschienen in: internetworld. de, https://www.internetworld.de/e-commerce/zahlen-studien/800-millionen-internetnutzer-inchina-1574347.html, abgerufen im Mai 2019. Kucklick, Christoph (2013): Schluss mit dem Scheitern, erschienen in: zeit.de, https://www.zeit. de/2014/01/scheitern-misserfolg, abgerufen im Juni 2019. Landesanstalt für Medien NRW (2012): Der TV-Satellitenempfang wird digital – Tipps für den Umstieg, erschienen in: medienanstalt-nrw.de, https://bit.ly/2YMsvnR, abgerufen im Mai 2019. Loesche, Dyfed (2017): Netflix verdoppelt seinen Gewinn bei den Emmys, erschienen in: de.statista.com, https://de.statista.com/infografik/11130/nominierungen-und-gewonnene-emmys-vonnetflix-produktionen/, abgerufen im Juni 2019. Markowitz, Harry M. (1952): Portfolio Selection, erschienen in: Journal of Finance, Nr. 7, S. 77 – 91. McLuhan, Marshall (1962): The Gutenberg Galaxy, Toronto. Negroponte, Nicholas P. (1995): Being Digital, Vintage Books, New York. Pillau, Florian (2019): Updates für Teslas „Navigate on Autopilot“, erschienen in: heise.de, https://www.heise.de/autos/artikel/Update-fuer-Teslas-Navigate-on-Autopilot-4359926.html, abgerufen im Mai 2019. Podbregar, Nadja (2019): Happy Birthday World Wide Web, erschienen in: scinexx.de, https:// www.scinexx.de/news/technik/happy-birthday-world-wide-web/. Porat, Marc Uri (1977): The Information Economy, Michigan. Reinsel, David, John Gantz, und John Rydning (2018): The Digitization of the World From Edge to Core, erschienen in: seagate.com, https://www.seagate.com/files/www-content/our-story/ trends/files/idc-seagate-dataage-whitepaper.pdf, abgerufen im Juni 2019. Reissmann, Frank (2013): Geschichte der CRM-Software von Microsoft, erschienen in: blog.rrcg. de, https://blog.rrcg.de/2013/10/15/geschichte-der-crm-software-von-microsoft/, abgerufen im Mai 2019. Ries, Eric (2011): The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Currency, New York. Rouse, Margaret (2015): Definition Arpanet/Darpanet, erschienen in: computerweekly.com, https:// www.computerweekly.com/de/definition/ARPANET-DARPANET, abgerufen im Mai 2019. Sauer, Olaf (2019): Digitaler Zwilling, erschienen in: iosb.fraunhofer.de, https://www.iosb.fraunhofer.de/servlet/is/80212/, abgerufen im Mai 2019. Schmidt, Julian und Paul Drews (2016): Auswirkungen der Digitalisierung auf die Finanzindustrie – eine strukturierte Literaturanalyse auf der Basis der Business Model Canvas, erschienen in: researchgate.net, https://bit.ly/2EiYAvl, abgerufen im Mai 2019. Siegler, M. G. (2010): Every 2 Days We Create as much Information as We Did up to 2003, erschienen in: techcrunch.com, https://techcrunch.com/2010/08/04/schmidt-data/, abgerufen im Juni 2019. Shi-Kupfer, Kristin und Mareike Ohlberg (2019): China’s Digital Rise – Challenges for Europe, Merics Papers on China, No 7 – April 2019, https://www.merics.org/sites/default/files/2019-04/ MPOC_No.7_ChinasDigitalRise_web_final.pdf, abgerufen im Mai 2019. Schwender, Clemens (2019): Chronologie von Fernsprechwesen und Telefonbuch in Berlin, erschienen in: schwender.in-berlin.de, https://www.schwender.in-berlin.de/, abgerufen im Mai 2019. Szczutkowski, Andreas (2018): Kritische Erfolgsfaktoren, erschienen in: wirtschaftslexikon. gabler.de, https://wirtschaftslexikon.gabler.de/definition/kritische-erfolgsfaktoren-38219/version-261645.

Literatur

47

Techcrunch (2019): Pivoting to success: Agile founders who turned their companies on a dime, erschienen in: techcrunch.com, https://tcrn.ch/2WZj2ZQ, abgerufen im Mai 2019. Urbach, Nils und Frederik Ahlemann (2016): IT-Management im Zeitalter der Digitalisierung, Springer Gabler, Wiesbaden. Verbraucherzentrale (2019): Die Empfangsarten – analog oder digital?, erschienen in: verbraucherzentrale.de, https://www.verbraucherzentrale.de/wissen/digitale-welt/fernsehen/die-empfangsarten-analog-oder-digital-6438, abgerufen im Mai 2019. Wagler, Alexandra (2018): Die Auswirkungen der Konvergenz der Medien auf den öffentlich-rechtlichen Rundfunk, insbesondere auf die Regelungen im Rundfunkstaatsvertrag, Berlin.

Weiterführende Literatur zu Digitalisierung & Gesellschaft Jungherr, Andreas (2017): Das Internet in der politischen Kommunikation: Forschungsstand und Perspektiven, erschienen in: PVS Politische Vierteljahresschrift, Jahrgang 58 (2017), Heft 2, S. 284 – 315. Schweiger, Wolfgang und Klaus Beck (Hrsg.) (2010): Handbuch Online-Kommunikation, VS Verlag, Wiesbaden. Wallner, Regina Maria (2017): Digitale Medien zwischen Transparenz und Manipulation: Internet und politische Kommunikation in der repräsentativen Demokratie, Springer VS, Wiesbaden.

3

Der Weg in die NullGrenzkosten-Ökonomie

Zusammenfassung

Die Grenzkosten von Unternehmen aus der Digitalbranche laufen gegen Null. Damit grenzen sich die Geschäftsmodelle von Facebook oder Google deutlich von den Geschäftsmodellen der Old Economy ab. Während bei Industriegütern die Grenzkosten erst bei großen Produktionsmengen und langsam sinken, ermöglichen es digitale „Null-Grenzkosten-Produkte“ bereits bei geringen Ausbringungsmengen, die Gewinnschwelle zu erreichen – und das bei einer nahezu unendlichen Skalierbarkeit. Für Unternehmen aus der Güter- oder Dienstleistungsbranche ist es schwierig, mit solchen Geschäftsmodellen zu konkurrieren. Das Modell zur disruptiven Veränderung von Märkten hin zu Null-Grenzkosten-Geschäftsmodellen (Abschn. 3.6) beantwortet die Frage, unter welchen Voraussetzungen sich Investitionen in neue digitale Technologien lohnen. Zusätzlich kann mithilfe des Modells untersucht werden, welche Märkte und Branchen in den kommenden Jahren eine digitale Disruption durchlaufen werden.

3.1 Big is beautiful Für viele Unternehmen gilt bis heute der Grundsatz: big is beautiful (oder auf Deutsch: je größer, desto besser). Im Laufe des 20. Jahrhunderts wuchsen die Unternehmen: Aus Fabriken und Manufakturen wurden zunächst national agierende Unternehmen und Kapitalgesellschaften. Nach und nach wuchsen diese zu international agierenden Multi-Milliarden-Konzernen heran, die heute die wirtschaftliche Entwicklung dominieren. Diese Tendenz zeigte sich in den sieben großen Wellen von Unternehmenszusammenschlüssen im Laufe der letzten 120 Jahre (Wirtz 2012; Hinne 2007):

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_3

49

50

3  Der Weg in die Null-Grenzkosten-Ökonomie

1897–1904 Die Industrialisierung erreichte Ende des 19. Jahrhunderts einen ersten Höhepunkt. Die damit einhergehenden Überkapazitäten führten zum Preisverfall auf den Konsumgütermärkten. Häufig fanden horizontale Zusammenschlüsse zwischen Unternehmen statt, mit der Absicht, die Marktpreise zu stabilisieren. Diese erste Merging-Welle endete mit dem Börsencrash von 1904 in den USA. 1916–1929 Die Wettbewerbshüter in den USA erließen in den „Roaring Twenties“ zahlreiche Anti-Trust-Gesetze, um marktbeherrschende Stellungen einzelner Unternehmen zu unterbinden. Trotzdem strebten zahlreiche Unternehmen weiterhin nach einer Monopolstellung in den jeweiligen Märkten. Vertikale Zukäufe entlang der Wertschöpfungskette ermöglichten es Unternehmen, die Auflagen der Anti-Trust-Gesetzgebung zu umgehen. Auch diese zweite Fusionswelle endete mit einem Börsencrash, dem „Black Friday“ von 1929. 1965–1969 In den 1960er-Jahren entstanden zahlreiche Konglomerate und Mischkonzerne. Ziel der Unternehmenslenker in dieser Zeit war die Portfolioerweiterung und die Diversifikation der Risiken. Die Ergebnisse dieser Entwicklung belasten bis heute die wirtschaftliche Entwicklung der japanischen Volkswirtschaft. Dort dominieren noch immer Unternehmen, die ein breites und diversifiziertes Produktportfolio aufweisen. Ende der 1960er-Jahre wurden auch Unternehmen in Deutschland immer größer und die Zahl der Mischkonzerne wuchs. Ein Beispiel für diesen Trend ist die Expansion von Siemens in den 1960er-Jahren. 1984–1989 Die 1980er-Jahre waren die Zeit der „Merger Mania“. Auslöser war u. a. die politische Liberalisierung in den USA und Großbritannien (Reagan- und Thatcher-Ära), die den Unternehmen mehr Freiheiten bei der Ausgestaltung von Unternehmensübernahmen bot. In dieser Zeit stieg die Anzahl der „Leverage Buyouts“ und „Unfriendly Takeovers“ sprunghaft an. Die Rezession ab Ende der 1980er-Jahre beendete diese Phase. 1993–2001 Befeuert durch große Mergers & Acquisitions, wie zum Beispiel die Fusion von Daimler und Chrysler, wuchs der Aktienmarkt in den 1990er-Jahren sprunghaft an. Zudem verbanden die Aktionäre mit den neu aufkommenden Technologien Biotech und Internet hohe Erwartungen. Das vorhandene Investorenkapital verwendeten die Unternehmenslenker für die Schaffung großer globaler Konzerne. Ein Beispiel für diese Entwicklung ist der Zusammenschluss von AOL und Time Warner. Der Börsencrash an der NASDAQ in den USA und am Neuen Markt in Deutschland im Jahr 2001 beendete diese Entwicklung.

3.1  Big is beautiful

51

2003–2007 Vor allem große Hedgefonds spielten im ersten Jahrzehnt des neuen Jahrhunderts eine entscheidende Rolle. Mit ihrer enormen Kaufkraft waren die Investoren in der Lage, große Übernahmen zu finanzieren. Zudem traten auf den westlichen Märkten für Unternehmenszusammenschlüsse erstmals Länder wie China und Indien als Käufer in Erscheinung. Die Weltwirtschaftskrise ab dem Jahr 2007 bremste diese Entwicklung zunächst. 2008 – heute Seit dem Jahr 2008 steigt die Anzahl der Unternehmenszusammenschlüsse wieder an (Imaa 2018). Der Wert der weltweiten Umsätze durch Mergers & Acquisitions verdoppelte sich von 2009 (weltweites Volumen: 2,19 Billionen USD) bis 2015 (weltweites Volumen: 4,76 Billionen USD). Seit 2015 pendelt sich das Volumen der weltweiten Transaktionen unterhalb der Schwelle von 4 Billionen USD ein (2017: 3,68 Billionen USD). Befeuert wird der Trend zu größeren Unternehmen durch Private-Equity-Firmen, die ihre Geschäftsmodelle unter anderem auf der Basis der sogenannten Skaleneffekte betreiben. Der Zusammenhang zwischen zunehmenden Unternehmensgrößen und steigenden Skaleneffekten wird in Abschn. 3.1.1 untersucht.

3.1.1 Skaleneffekte und Erfahrungskurven Große Unternehmen haben eine Reihe strategischer und taktischer Vorteile gegenüber kleinen Unternehmen. Sie nutzen in erster Linie ihre Größenvorteile und Marktanteile, um deutlich günstiger als die Konkurrenz ihre Produkte und Dienstleistungen herzustellen. In der klassischen Güter- und Industrieproduktion gilt die Regel: Jedes neu produzierte Auto, jede neu erstellte Dienstleistung kostet annähernd so viel, wie das Auto oder die einzelne Dienstleistung, die direkt davor produziert wurde. Die Kosten für die Erstellung des letzten Produkts bzw. der letzten Dienstleistung (die Grenzkosten, siehe Abschn. 3.1.2) sinken langsam. Erst bei großen Produktionsmengen profitieren Unternehmen von den sinkenden Grenzkosten. Dass Güter billiger werden, wenn mehr davon produziert wird, war bereits zu Beginn der Industrialisierung bekannt. In der industriellen Produktion gilt folgender Zusammenhang: Die Einzelkosten der Fertigung sinken in der Regel um 20 bis 30 %, wenn sich die Ausbringungsmenge verdoppelt (Dreiskämper 2018). In strategischen Management-Modellen wurde dieser Zusammenhang aufgegriffen und es wurden eigene Ansätze entwickelt, um den Vorteil größerer Marktanteile herauszuarbeiten. Bruce Henderson – einer der Gründer der Boston Consulting Group – revolutionierte die Sicht auf das strategische Denken im Management: Aus der grundlegenden Erkenntnis des Vorteils größerer Marktanteile entwickelte er die strategischen Management-Tools der „Erfahrungskurve“ und der „Boston-Consulting-Matrix“ (Henderson 1968, 1984; siehe Hintergrundinformation zur Boston-Consulting-Matrix). Vor diesem

52

3  Der Weg in die Null-Grenzkosten-Ökonomie

theoretischen Hintergrund unterstützten Kapitalgeber und Banken die Unternehmenslenker beim Aufbau immer größerer Unternehmen, um so die strategische Ausgangsposition der Unternehmen zu verbessern. Die Erfahrungskurve von Bruce Henderson verdeutlicht, dass Unternehmen mit zunehmender Ausbringungsmenge von sinkenden Herstellungskosten pro Einheit profitieren. Die Voraussetzung dafür ist, dass im Laufe der Zeit und mit zunehmender Ausbringungsmenge auch Effizienzsteigerungen eintreten. Diese Effekte werden als dynamische Skaleneffekte bezeichnet. Dazu zählen u. a. Lerneffekte durch Wiederholung der Produktionstätigkeit, die Einführung effizienzsteigernder Produktionstechniken, Automatisierungen und Rationalisierungen. Auch die gesteigerte Marktmacht von Unternehmen, die sich durch Größenvorteile auf den Faktormärkten ergibt, trägt zur Entstehung von Erfahrungskurven bei. Ein Beispiel für den Größenvorteil durch Erfahrungskurven ist das Geschäftsmodell der Textilbranche. Allein durch die Mengenrabatte, die Zulieferer den großen Textilherstellern bei der Abnahme großer Mengen gewähren, sinken die Herstellungskosten mit größerer Ausbringungsmenge sukzessive. Zudem werden Automatismen und Arbeitsabläufe im Laufe der Zeit feiner aufeinander abgestimmt. So ergeben sich Einsparpotenziale bei jedem weiteren gefertigten Kleidungsstück. Auch eine zunehmende Effizienz entlang der Wertschöpfungskette, zum Beispiel durch die Einführung von Just-in-time-Produktion oder Kanban, spart mit zunehmender Unternehmensgröße weitere Kosten. Die strategischen Implikationen der Erfahrungskurve lauten: Unter der Voraussetzung von Kosteneinsparpotenzialen ist es vorteilhaft, in umkämpften Märkten schnell große Marktanteile zu gewinnen. Den Vorteil einer besseren Kostenstruktur können Großkonzerne an die Kunden weitergeben. Marktbeherrschende Unternehmen drängen auf diese Weise langfristig ihre Wettbewerber aus dem Markt. Bis heute ist die Unternehmensgröße ein wichtiger strategischer Faktor, um Wettbewerbsvorteile gegenüber der Konkurrenz zu erreichen. Investoren stellen daher große Mengen an Kapital zur Verfügung, um größere Kapitalgesellschaften entstehen zu lassen. Dargestellt werden die Effekte der Erfahrungskurve u. a. anhand einer sinkenden Grenzkostenkurve. Um diesen Zusammenhang zu verdeutlichen, werden in Abschn. 3.1.2 zunächst die Kostenkurven von Unternehmen und anschließend deren Grenzkostenkurven näher betrachtet. Die Boston-Consulting-Matrix 1970 entwickelte Bruce Henderson, der Gründer der Boston-Consulting Group, ein strategisches Management-Tool, das sich bis heute bei Analysten großer Beliebtheit erfreut (Baum et al. 2013). Das Modell basiert auf zwei Ausgangsüberlegungen: 1. Je mehr Marktanteile ein Unternehmen hat, desto größer sind seine Vorteile gegenüber der Konkurrenz. Die Gründe dafür sind vielfältig: Skaleneffekte, Verbundvorteile und eine bessere Verhandlungsmacht gegenüber Lieferanten, Partnern und Kunden lassen die Gewinnmargen von Unternehmen mit hohen Marktanteilen wachsen. Diese bessere Ausgangsposition kann in Form günstigerer Marktpreise an die Kunden weitergereicht werden.

3.1  Big is beautiful

53

2. Der Markterfolg von Produkten und Produktklassen verändert sich im Zeitablauf. Der ­Produktlebenszyklus, den Raymond Vernon in seinen Arbeiten dargestellt hat, beschreibt die unterschiedlichen Phasen, die jedes Produkt und jede Produktklasse durchläuft. Langfristig scheiden alle Produkte aus dem Markt aus und werden durch neue Produkte ersetzt (Appleyard et al. 2006). Um den Erfolg eines Produkts und dessen Zukunftsfähigkeit zu ermitteln, wurden beide Erkenntnisse in das Portfolio-Modell der Boston-Consulting-Matrix (BCG-Matrix) überführt. Die Positionierung des Produkts auf der x-Achse erfolgt anhand des relativen Marktanteils des produzierenden Unternehmens. Der relative Marktanteil ist der Quotient aus dem eigenen Marktanteil und dem Marktanteil des stärksten Konkurrenten. Die Positionierung des Produkts auf der y-Achse erfolgt anhand des aktuellen Marktwachstums der Produktklasse. Zusammengefasst ergeben sich im Portfolio-Modell von Bruce Henderson vier Quadranten, die eine Erfolgsprognose für einzelne Produkte eines Unternehmens zulassen. In Quadrant 1 befinden sich die „Question Marks“ (Fragezeichen) eines Unternehmens. Diese Produkte weisen ein hohes Marktwachstum auf. Allerdings ist es dem Unternehmen noch nicht gelungen, für das Produkt große Marktanteile zu sichern. In Quadrant 2 stehen die „Stars“: Das sind Produkte, die sich durch einen hohen Marktanteil und ein hohes Wachstum der Produktklasse auszeichnen. Quadrant 3 umfasst Produkte, mit denen das Unternehmen einen signifikant hohen Marktanteil erreicht hat, allerdings lässt das Wachstum der Produktklasse bereits nach oder ist sogar rückläufig. Diese Produkte werden als „Cash Cows“ (Melkkühe oder Goldesel) bezeichnet. Weist ein Produkt eines Unternehmens geringe Marktanteile auf und befindet es sich gleichzeitig in einem schrumpfenden Teilmarkt, werden diese Produkte als „Poor Dogs“, also arme Hunde, bezeichnet. Der Produktlebenszyklus eines Produkts durchläuft idealtypisch alle vier Phasen im Uhrzeigersinn von Quadrant 1 bis Quadrant 4 (s. Abb. 3.1).

10

E Question Marks

B

Stars

Marktwachstum

In Prozent

D

C

A Dogs

Cash Cows

0 0

Relaver Marktanteil

Im Verhältnis zum größten Webewerber

Abb. 3.1   Boston Consulting Group Portfolio-Analyse

2

54

3  Der Weg in die Null-Grenzkosten-Ökonomie

Aus der Einordnung der Produkte in die Klassen der BCG-Matrix ergeben sich für Unternehmenslenker mögliche Normstrategien: Question Marks stellen potenzielle Investitionsziele dar. Das Management der Stars ist eine zentrale Aufgabe der Unternehmensführung. Cash Cows und Poor Dogs sind dagegen Kandidaten für eine Desinvestitionsstrategie. Die BCG-Matrix ist durch ihre Aussage- und Prognosekraft bis heute ein wichtiges Modell, um Marktstrukturen zu verstehen und zukünftige Erfolgspotenziale zu ermitteln.

3.1.2 Grenzkostenanalyse Wie sich die Kosten in Abhängigkeit von der Ausbringungsmenge verändern, wird in der Kostenkurve eines Unternehmens dargestellt. Insgesamt werden sechs unterschiedliche idealtypische Kostenverläufe unterschieden. proportional (linear) Bei der proportionalen Kostenkurve gibt es eine lineare Abhängigkeit der Kosten von der Herstellungsmenge. Die Kosten steigen in direkter Relation zur Ausbringungsmenge. degressiv (unterproportional) Die Kosten der Produktion steigen mit zunehmender Ausbringungsmenge langsamer. Das heißt, die Einzelkosten der Herstellung sinken bei größeren Quantitäten. Ein Grund für diese Entwicklung ist u. a. der Lernkurveneffekt. progressiv (überproportional) Bei einem progressiven Kostenverlauf steigen die Kosten schneller als die Ausbringungsmengen. Das heißt, die Kosten für die Herstellung des letzten Guts/der letzten Dienstleistung werden exponentiell teurer. Verteuert sich zum Beispiel die Arbeitsleistung, weil Überstunden ausbezahlt werden, entstehen progressive Kostenverläufe. regressiv (abnehmend) Sinken die Herstellungskosten mit zunehmender Ausbringungsmenge, entsteht eine regressive Kostenkurve. So sinken zum Beispiel die Heizkosten für einen Raum mit der Menge der Menschen, die sich im Raum befindet. fix Fixe Kosten verändern sich nicht. Jedes produzierte Gut und jede Dienstleistung kostet so viel wie die Einheit davor oder die Einheit danach. Dieser Zusammenhang gilt unabhängig von der produzierten Ausbringungsmenge. sprungfix Innerhalb von abgegrenzten Intervallen verändern sich sprungfixe Kosten nicht. Erst wenn die Schwelle der jeweiligen Ausbringungsmenge erreicht wird, verändern sich die Kosten der Herstellung sprunghaft. Ein Beispiel für die sprungfixe Veränderung von Kosten ist die Anschaffung oder die Zuschaltung neuer Maschinen, um die Kapazität zu steigern.

3.1  Big is beautiful

55

In der Realität sind Kostenkurven komplizierter als die sechs dargestellten idealtypischen Kostenverläufe. Eine detailliertere Betrachtung der Kostenkurven wird möglich, wenn sie in variable und fixe Kosten aufgeteilt werden. Variable Kosten entstehen für ein Unternehmen, wenn ein Gut oder eine Dienstleistung tatsächlich produziert wird. Siemens ist beispielsweise seit vielen Jahren Zulieferer der Deutschen Bahn. Für jeden ICE, den Siemens herstellt, benötigt es zahlreiche Einzelkomponenten: Wagen, Räder, Triebwerke, Sessel etc. Als Hersteller beschafft Siemens diese Komponenten vor dem Produktionsprozess bei seinen Zulieferern. Somit verteuert sich die Erstellung der Endprodukte. Fixe Kosten entstehen den Unternehmen dagegen unabhängig vom Produktions- und Beschäftigungsvolumen. Zu den Fixkosten zählen in der Regel Mieten und Löhne. Für Siemens bedeutet das, dass die Fixkosten (Kosten für die Bezahlung der Mitarbeiter sowie die Instandhaltung und die Miete der Fertigungsanlagen) auch bezahlt werden müssen, wenn in einem Produktionszeitraum kein neuer Zug produziert wird. Die Summe aus variablen Kosten und Fixkosten sind die Gesamtkosten des Unternehmens. Durch die Division der Gesamtkosten (K) durch die Ausbringungsmenge (x) ergeben sich die Durchschnittskosten (DK) eines Unternehmens (s Abb. 3.2). Es gilt folgender Zusammenhang:

Kosten der ersten Kopie

Durchschniskosten (DK) Grenzkosten (GK)

DKphysisch

GKphysisch

DKdigital

GKdigital Ausbringungsmenge

Abb. 3.2   Physische vs. digitale Produkte – Durchschnittskosten und Grenzkosten im Vergleich (Clement und Schreiber 2016)

56

3  Der Weg in die Null-Grenzkosten-Ökonomie

DK = K ÷ x

(3.1)

Eine Erhöhung der Ausbringungsmenge verringert die Durchschnittskosten. Damit sinkt der Fixkostenanteil, der pro verkauftem Produkt mitfinanziert werden muss. Dieser Zusammenhang wird als Fixkostendegression bezeichnet (Clement und Schreiber 2016). Was sind Grenzkosten?

Aus mathematischer Perspektive sind die Grenzkosten die erste Ableitung der Gesamtkosten. Damit gibt die Grenzkostenfunktion Auskunft über die Steigung der Kostenfunktion in jedem Punkt. Anders formuliert liefert die Grenzkostenfunktion Information über jene Kosten, die dem Unternehmen für die Ausbringung einer zusätzlichen Einheit entstehen. Es gilt folgender Zusammenhang: ′

∧

K (x) = Grenzkosten(GK)

(3.2)

Das Beispiel eines Unternehmens aus der Druckbranche verdeutlicht diesen Zusammenhang. Die Fixkosten der Produktion sind in einer Druckerei in der Regel hoch. Die Produktionsräume werden unabhängig vom Auftragsvolumen bereitgestellt und instandgehalten. Gleichzeitig fallen Lohnkosten für die Bezahlung der Beschäftigten an. Diese Kosten entstehen unabhängig von der Anzahl der verarbeiteten Druckaufträge. Erhält die Druckerei einen Druckauftrag, zum Beispiel für eine bestimmte Anzahl von Informationsbroschüren, gibt es eine enge Korrelation zwischen der bestellten Menge und dem Preis pro Mengeneinheit. Dies liegt unter anderem an den Einkaufsrabatten, die eine Druckerei von ihren Zulieferern erhalten kann. Je mehr Papier das Unternehmen bei einem Papierproduzenten ordert, desto billiger wird die Bearbeitung eines einzelnen Druckauftrags. Angenommen die Fixkosten der Druckerei belaufen sich pro Monat auf 100.000 EUR. Bei der Abnahme von 1000 Druckbögen zahlt die Druckerei an den Papierhersteller 2 EUR pro Bogen. Bei der Abnahme von 1.000.000 Druckbögen zahlt das Unternehmen noch 1 EUR pro Bogen. Werden im Laufe eines Monats die 1000 Druckbögen bedruckt und ausgeliefert, belaufen sich die Durchschnittskosten pro Bogen auf 10 EUR (Fixkosten geteilt durch Ausbringungsmenge)  +  2 EUR (variable Kosten) = 12 EUR. Werden im Laufe des Monats eine Million Druckbögen bedruckt, sinken die Durchschnittskosten auf 1,1 EUR (0,1 EUR + 1 EUR). Die Durchschnittskosten sind also um 10,90 EUR gesunken. Die Grenzkosten sind von 2 EUR auf 1 EUR gesunken. Diese Kostenvorteile, die der Druckerei durch die Ausweitung der Produktion entstehen, kann das Unternehmen an seine Auftraggeber weiterreichen. Daher ist es deutlich billiger, große Druckaufträge an Druckereien zu vergeben. Die Betrachtung der Grenzkosten ist geeignet, um die Kostenstruktur eines Unternehmens zu analysieren. Niedrige Grenzkosten erlauben es einem Unternehmen, schnell den sogenannten „Break-Even-Punkt“ zu erreichen: Dieser bezeichnet jene Ausbringungsmenge, bei der die Kosten der Herstellung (also die Summe der

3.2 Null-Grenzkosten-Geschäftsmodelle

57

v­ ariablen Kosten und der Fixkosten) gleich dem Umsatz des Unternehmens mit dem Produkt sind. Falls der Umsatz je Einheit größer ist als die Grenzkosten in diesem Punkt, steigert jede weitere produzierte Einheit den Gewinn des Unternehmens. Die Digitalisierung führt zu einer Dominanz neuer Geschäftsmodelle: der Null-Grenzkosten-Geschäftsmodelle. Null-Grenzkosten-Geschäftsmodelle zeichnen sich dadurch aus, dass ein Unternehmen aufgrund der günstigen Kostenstruktur bereits bei geringem Umsatz die Gewinnschwelle erreicht. Wie diese Geschäftsmodelle entstehen und welche Branchen von dieser Entwicklung betroffen sind, wird in Abschn. 3.2 dargestellt.

3.2 Null-Grenzkosten-Geschäftsmodelle Die Digitalisierung markiert einen Übergang zwischen der traditionellen Industrie- und Dienstleistungsproduktion des 20. Jahrhunderts und der Digitalwirtschaft des 21. Jahrhunderts. Während Unternehmen der Güter- und Dienstleistungsbranchen ihre internen Wertschöpfungsprozesse entlang der Erfahrungskurven effizienter ausgestalten, um ihre Marktposition zu verbessern, hat eine neue Generation von Unternehmen ein eigenständiges Betätigungsfeld für sich entdeckt: die Bereitstellung und Verarbeitung digitaler Informationen. Mit dieser neuen Positionierung verändern die Unternehmen der Digitalbranche die Spielregeln der Konsumgütermärkte. Denn die Grenzkosten von Unternehmen, die auf digitale Geschäftsmodelle setzen, belaufen sich vom ersten Produkt bzw. der ersten Dienstleistung an auf nahezu Null – und das auch bei geringen Ausbringungsmengen. Während viele europäische Konzerne darauf spezialisiert sind, physische Produkte und Dienstleistungen anzubieten, sind amerikanische Konzerne aus dem Silicon Valley durch die Bereitstellung digitaler Plattformen und Verbreitung und Analyse von Bits und Bytes groß geworden (Kap. 2). Durch die Digitalisierung kommt es zu einer Machtverschiebung zwischen diesen beiden Produktionsformen. Während digitale Geschäftsmodelle und die Erstellung von Software zum Treiber für die wirtschaftliche Entwicklung geworden sind, spielen physische Produktionsprozesse eine zunehmend untergeordnete Rolle. Wie erfolgreich Geschäftsmodelle aus der Digitalbranche aktuell sind, verdeutlicht das Beispiel des Online-Spiels Fortnite. Das Geschäftsmodell des Online-Spiels Fortnite

„Fortnite: Battle Royale“ ist aktuell – Stand 2019 – eines der erfolgreichsten OnlineSpiele aller Zeiten. 2018 verkündete das Softwareunternehmen Epic, dass 125 Mio. Spieler weltweit das Spiel nutzten. Damit hat das Spiel den Branchenprimus League of Legends überholt (Albrecht 2018). Fortnite ist ein Multiplayer-Spiel, bei dem gleichzeitig 100 Online-Spieler miteinander darum konkurrieren, als Letzter auf einer virtuellen Insel zu überleben. Wie bei anderen Battle-Royal-Shootern geht es darum, sich als Spieler mit Gegenständen und Waffen auszurüsten und möglichst schnell alle anderen Mitspieler zu eliminieren.

58

3  Der Weg in die Null-Grenzkosten-Ökonomie

Das Besondere an Fortnite ist das ausgefeilte Geschäftsmodell. Nach dem Kauf des Startpakets steht den Online-Spielern eine Reihe von optischen und funktionalen Erweiterungen für ihre Charaktere zu Verfügung, die sie während des Spielens kaufen können (sogenannte In-App-Käufe). So wird beispielsweise den Spielern die Möglichkeit geboten, wechselnde Spieleroutfits (Skins) für 20 USD zu kaufen, die zeitlich nur begrenzt verfügbar sind. So wird der Kaufanreiz für die Spieler stärker. Auf Basis dieses Geschäftsmodells, das in erster Linie auf den In-App-Käufen während des Spiels beruht, hat Epic mit Fortnite im Jahr 2018 geschätzte 3 Mrd. USD Gewinn erwirtschaftet (Rüther 2018). Die Kosten für die Bereitstellung der Software und der Server sind dabei marginal im Vergleich zu den Umsätzen, die die Online-Spieler generieren. Das Risiko für die Hersteller von Online-Spielen liegt daher nicht im Betrieb der digitalen Plattform, sondern in den Kosten, die das Unternehmen in die Entwicklung des Spiels investieren muss. Sobald das Spiel erfolgreich auf dem Markt etabliert ist, entstehen dem Hersteller nahezu keine Kosten mehr. Ein Null-Grenzkosten-Geschäftsmodell ist entstanden. Zwar ist davon auszugehen, dass sich auch in den kommenden Jahrzehnten ein Großteil des menschlichen Konsumverhaltens auf physische Produkte beziehen wird. Aber rund um diese physischen Prozesse und Produkte werden alle Wertschöpfungsstufen schrittweise digitalisiert werden – vom Einkauf über den Vertrieb bis hin zum Support. Ein Beispiel für diesen Zusammenhang liefert die Entwicklung der Filmindustrie in den vergangenen 20 Jahren. Noch bis Mitte der 1990er-Jahre war der Farbfilm (35 mm) der Standard der Abspielformate im Kino. Digitale Filmeffekte (Digital Visual Effects) waren zu diesem Zeitpunkt bereits bekannt. Um diese Effekte einzufügen, wurde der Film digitalisiert und am Computer bearbeitet, anschließend wurde der digital veränderte Film auf eine physische 35 mm-Filmrolle ausgespielt. Der Filmvertrieb vervielfältigte die Filmrollen in großen Kopierwerken tausendfach und lieferte die Kopien anschließend an die Kinos aus. Für viele Jahrzehnte war die Distribution von Kinofilmen ein vollständig physischer Prozess. Mit dem Aufkommen digitaler Filmkameras und Kinoprojektoren änderte sich das Geschäftsmodell der Filmindustrie und speziell das Geschäftsmodell des Filmvertriebs. Heute werden die Filmdateien via Datentransfer von den Produktionsfirmen auf die Festplatten der Kinobetreiber übertragen. So sinken die Grenzkosten für die Distribution eines Films durch die Digitalisierung auf nahezu Null. Die Anzahl der Mitarbeiter, die für die Umsetzung von Null-Grenzkosten-Geschäftsmodellen benötigt wird, ist klein. In vielen Fällen ist mit der Bereitstellung der Software der Kernprozess der Wertschöpfung bereits abgedeckt. So läuft der Algorithmus der Suchmaschine von Google ohne menschliches Eingreifen. Die Aufgaben der Mitarbeiter beschränken sich nach der Herstellung und Weiterentwicklung der Software auf die vorund nachgelagerten Prozessstufen, wie Marketing und Kundensupport.

3.2 Null-Grenzkosten-Geschäftsmodelle

59

Die Digitalisierung hat damit eine neue Form von Erfolgsmodellen hervorgebracht: kleine Startups, die es schaffen, mit wenigen Mitarbeitern Milliarden von Dollar umzusetzen. Instagram erschien am 6. Oktober 2010 im App-Store von Apple. Bereits zwei Jahre später wurde Instagram von Facebook für 1 Mrd. USD gekauft. Zu diesem Zeitpunkt waren gerade einmal 12 Mitarbeiter bei Instagram beschäftigt. Heute erzielt die Plattform einen jährlichen Werbeumsatz von 4,1 Mrd. USD und hat – mit Stand 2017 – weltweit 594 Mio. Nutzer (McCarthy 2017). Der Betrieb der digitalen Geschäftsmodelle folgt der Logik der Digitalisierung. Ist der Algorithmus der Software oder der Plattform entwickelt und programmiert, entstehen dem Betreiber der digitalen Dienstleistung ausschließlich jene Kosten, die für die Bereitstellung der digitalen Dienstleistung im World Wide Web anfallen. Um Informationen auf digitalen Plattformen anbieten zu können, sind drei Prozessschritte notwendig: die Verarbeitung, die Speicherung und die Übertragung der Daten. Die Übertragungskosten für die Online-Kommunikation in B2C-Modellen tragen sowohl die Kunden als auch die Anbieter. Die Kunden finanzieren mit ihren Verträgen für Breitbandanschlüsse und mit ihren Mobilfunkverträgen einen Großteil des laufenden Betriebs der Mobilfunk- und Netzbetreiber in Europa. Die Anbieter digitaler Produkte und Dienstleistungen zahlen in der Regel die Anbindung der Serveranlagen über einen sogenannten Point of Presence (Isberto 2018). Diese Einwahlkosten können den Fixkosten des Unternehmens zugerechnet werden. Darüber hinaus tragen die Unternehmen nur jene Kosten, die für die Bereitstellung und den Betrieb der Datenspeicher und Serveranlagen anfallen. Die Durchschnittskosten, also die Gesamtkosten für den Betrieb der Serveranlagen geteilt durch die Anzahl der Nutzer und damit auch die Grenzkosten, laufen unter diesen Voraussetzungen gegen Null. Damit sind digitale Produktionsprozesse gegenüber industriellen Produktionsprozessen im Vorteil. Bereits bei geringen Produktionsmengen erwirtschaften die Anbieter digitaler Produkte Gewinne. Ein Zahlenbeispiel für diesen Zusammenhang liefert die Kostenrechnung von Facebook. Um die spezifische Kostenstruktur von Facebook zu verstehen, gilt es zu analysieren, welche Kosten Facebook durch einen zusätzlichen Kunden entstehen. Die Antwort lautet: nahezu keine. Zwar addieren sich die Kosten für den Betrieb der Server im Laufe eines Jahres und „heavy user“ mit hohen Upload-Datenmengen kosten Facebook mehr als ein Gelegenheitskonsument. Dennoch stehen die aufaddierten Energie- und Serverkosten in keinem Verhältnis zu den Werbeumsätzen, die ein einzelner Nutzer dem Unternehmen durchschnittlich einbringt. Um diesen Zusammenhang zu verdeutlichen, reicht es aus, die aktuellen Werbeumsätze (2017: 10,1 Mrd. USD) durch die Anzahl der regelmäßigen User (2,2 Mrd. monatliche Nutzer) zu teilen. Das Ergebnis: Mit jedem User macht Facebook einen Werbeumsatz von knapp 5 EUR pro Jahr. Vor dem Hintergrund, dass es sich um ein Null-Grenzkosten-Geschäftsmodell handelt, ist es lukrativ, das soziale Netzwerk zu betreiben. Facebook wies 2017 einen Gewinn von fast 5 Mrd. USD aus (Weddeling 2018).

60

3  Der Weg in die Null-Grenzkosten-Ökonomie

3.2.1 Null-Grenzkosten-Geschäftsmodelle und klassische Geschäftsmodelle im Vergleich Die Geschäftsmodelle von Google, Facebook etc. unterscheiden sich von den Geschäftsmodellen von Industrieunternehmen wie General Electric oder Siemens durch ihre spezifische Kostenstruktur. Industrieunternehmen verwenden einen nicht unerheblichen Teil ihres Umsatzes für die Finanzierung der Produktion und für die Herstellung der Güter und Dienstleistungen. Digitalen Unternehmen entstehen für die Produktion selbst praktisch keine Kosten. Wie groß die Unterschiede sind, lässt sich anhand eines Zahlenbeispiels verdeutlichen. Dazu wird die Grenzkostensituation von Google untersucht. Den variablen Kosten des Suchmaschinenanbieters stehen die Umsätze gegenüber, die er durch die Bereitstellung des Angebots erzielen kann. Anschließend werden diese Zahlen mit den variablen Kosten und den Umsätzen von VW verglichen. Um die Grenzkosten zu bestimmen, die Google bei der Bereitstellung der Dienstleistung „Suchanfrage“ entstehen, werden zunächst die beteiligten Akteure in diesem Prozess identifiziert. Der Nutzer einer Suchmaschine betritt via Internetbrowser die Webseite der Suchmaschine. Zu diesem Zeitpunkt sind Google noch keine variablen Kosten entstanden. Mit der Eingabe der Suchanfrage und dem Betätigen des „Suchen“-Buttons löst der Kunde eine Rechenoperation aus, die auf den Servern von Google durchgeführt wird. Nun entstehen zum ersten Mal Kosten. Aktuelle Schätzungen gehen davon aus, dass die Verarbeitung einer einzelnen Suchanfrage beim Betreiber der Server mit 0,0003 Kilowattstunden zu Buche schlägt (Ostendorf 2017). Hochgerechnet auf den Strompreis (Stand Januar 2019), der in einschlägigen Vergleichsportalen mit 0,13 EUR pro Kilowattstunde angegeben wird, ergeben sich damit für eine einzelne Suchanfrage Kosten in Höhe von 0,000039 EUR. Dass ein Unternehmen wie Google aufgrund der hohen Nachfrage nach Strom mit Mengenrabatten kalkulieren kann, beziehungsweise eigenen Strom produziert, wird an dieser Stelle nicht in die Überlegungen einbezogen (Heuzeroth 2011). Um die Frage nach der Relation zwischen Grenzkosten und Umsatz des Unternehmens zu beantworten, wird zusätzlich eine verlässliche Aussage über den Umsatz benötigt, den Google mit einer Suchanfrage erzielen kann. Den Umsatz auf den Suchmaschinenportalen generiert Google durch die Applikation Google AdWords: Dabei handelt es sich um eine Werbeplattform für Unternehmen, die ihre Angebote auf den Suchmaschinenseiten von Google platzieren möchten. Google AdWords zeigt dem Konsumenten oberhalb seiner Suchergebnisse die Links zu den werbetreibenden Unternehmen an. Auf den deutschen Ergebnisseiten von Google werden diese Einblendungen mit dem Zusatz „Anzeige“ gekennzeichnet. Mithilfe der Kennzahl „Prozentzahl der Klicks, die nach einer Suchanfrage auf Google auf Google-AdWords-Anzeigen landen“ kann ein Wert für den durchschnittlichen Umsatz von Google pro Suchanfrage ermittelt werden. Laut einer Untersuchung von Sistrix aus dem Jahr 2018 folgt auf 1,68 % aller Suchanfragen ein Klick auf eine Google AdWords-Anzeige (Beus 2018). Auf den ersten Blick scheint das kein Wert zu sein, mit dem sich ein erfolgreiches Geschäftsmodell betreiben lässt.

3.2 Null-Grenzkosten-Geschäftsmodelle

61

Durch die Multiplikation der Klickwahrscheinlichkeit mit dem potenziellen Umsatz, den ein erfolgter Klick für Google erbringt, ergibt sich der durchschnittliche Umsatz der Suchmaschine pro Suchanfrage. Aktuelle Markteinschätzungen (Stand 2018) zeigen, dass sich ein Großteil der Pay-per-Click-Kosten zwischen 0,4 und 2,0 EUR bewegt. Anhand des Mittelwerts 1,2 EUR ergibt sich für Google ein durchschnittlicher Umsatz von 0,02016 EUR (also etwa 2 Cent) je Suchanfrage. Der Vergleich zwischen den Kosten und dem Umsatz verdeutlicht das große Potenzial des digitalen Geschäftsmodells von Google. Da die Kosten bei 0,000039 EUR liegen, übersteigen die durchschnittlichen Umsätze die Kosten um den Faktor 500. Mit solchen Zahlen kann ein Industrieunternehmen nicht konkurrieren. Da es sich bei der Autoproduktion um einen physischen Prozess handelt, werden die Einzelbestandteile des Fahrzeugs am freien Gütermarkt eingekauft, bevor sie im Produktionsprozess eingesetzt werden. Die fixen Kosten der Autoproduktion setzen sich aus den Löhnen der Mitarbeiter sowie aus den Mieten und Instandhaltungskosten zusammen, die für die Bereitstellung der Fertigungsanlagen aufzubringen sind. Auch wenn in die Analyse der Grenzkosten der Autoproduktion wichtige Faktoren wie der Energieverbrauch pro produzierter Einheit nicht einfließen, zeigt sich in der Analyse der Nachteil der Industrieproduktion gegenüber digitalen Geschäftsmodellen. Brancheninsider gehen davon aus, dass die Höhe der Materialkosten für die Produktion eines Autos mit ca. 50 % des Verkaufspreises des Autos zu Buche schlagen (Anker 2013). Die detaillierte Zusammensetzung der Kostenstruktur ist in der Regel für Außenstehende nicht nachvollziehbar. Auch wenn Schwankungen zwischen Modellen der Ober- und Mittelklasse berücksichtigt werden (die Oberklasse erzielt in der Regel die höheren Margengewinne), so kann ein Industrieprodukt nicht mit den Gewinnmargen eines digitalen Produkts mithalten. Bei Materialkosten in Höhe von 50 % des Verkaufspreises übersteigt der Umsatz die Kosten nur um den Faktor 2. Eine detaillierte Betrachtung des Jahresabschlusses von VW bestätigt diese Tendenz: Im Jahr 2017 belief sich der Gesamtumsatz des Unternehmens auf 76,73 Mrd. EUR. Die Materialkosten in der Gewinn- und Verlustrechnung belaufen sich im gleichen Jahr auf 49,8 Mrd. EUR. Das heißt, in der Bilanzperiode 2017 wendete VW fast 65 % seines Umsatzes für die Beschaffung der benötigten Produktionsmaterialien auf (VW 2018). Im Fazit fällt der Vergleich zwischen den alten, industriellen Geschäftsmodellen und den neuen, digitalen Geschäftsmodellen ernüchternd für die Vertreter der Old Economy aus. Während ein Industrieunternehmen einen Großteil des Umsatzes in die Finanzierung des Materialverbrauchs stecken muss, laufen die Grenzkosten der digitalen Geschäftsmodelle gegen Null. Mit diesem Ansatz ist es den Unternehmen mit digital basierten Geschäftsmodellen nicht nur möglich, die eigene Branche weiterzuentwickeln, sie besitzen auch die Technologie, um fremde Branchen mit digitalen Plattformen anzugreifen (Kap. 2). Im Jahr 2014 kaufte Google das Unternehmen Nest Labs für 3,2 Mrd. USD. Nest Labs ist auf die Entwicklung von digitalen Haushaltsgeräten, zum Beispiel von Thermostaten spezialisiert. Mit seiner digitalen Plattform, die u. a. auch auf mobilen Endgeräten installiert werden kann, erkämpfte sich das Unternehmen

62

3  Der Weg in die Null-Grenzkosten-Ökonomie

einen signifikanten Marktanteil in der Branche der Heizungsanlagen. Und das, ohne jemals selbst eine Heizungsanlage gebaut zu haben. Nach diesem Vorbild disruptieren die digitalen Unternehmen aus dem Silicon Valley oder aus China weltweit Branchen, mit der Folge, dass sich eine immer größere Anzahl von Märkten in die Richtung von Null-Grenzkosten-Geschäftsmodellen entwickelt. Um einen theoretischen Zugriff auf die Frage zu erhalten, wann eine Markt- oder Branchendisruption vorliegt, wird in Abschn. 3.2.2 ein eigenständiges Modell entwickelt. Dieses Modell betrachtet die unterschiedlichen Akteure und die zwischen diesen Akteuren stattfindenden Austauschprozesse.

3.2.2 Das Modell zur Analyse von disruptiven Marktveränderungen hin zu Null-GrenzkostenGeschäftsmodellen Das Modell zur Analyse der disruptiven Änderung von Märkten hin zu Null-Grenzkosten-Geschäftsmodellen dient dazu, diejenigen Branchen zu identifizieren, die in Zukunft von den Marktveränderungen durch die Digitalisierung betroffen sein werden. Mit dem Modell wird der gesamte Wertschöpfungsprozess eines Unternehmens – unabhängig davon, ob es sich um industrielle oder digitale Herstellungsprozesse handelt – zunächst in seine Prozessschritte zerlegt. In einem zweiten Schritt werden die Digitalisierungsgrade der einzelnen Stufen näher bestimmt. Das Modell 1986 veränderte das ökonomische Modell der Wertschöpfungskette von Michael E. Porter das strategische Denken im Management nachhaltig (Porter 1986). Seine These lautet, dass Unternehmen nur dann erfolgreich sind, wenn es ihnen gelingt, die Prozesse, die für die Wertschöpfung notwendig sind, zu identifizieren und effizienter auszugestalten als die Konkurrenz. Nach seinem Modell kann ein Unternehmen besser als ein anderes Unternehmen sein, wenn es entweder Qualitäts- oder Preisführer in der jeweiligen Branche ist (oder beides gleichzeitig). Größere Effizienz entlang der Wertschöpfungskette senkt die Durchschnittskosten. Daher besteht eine wichtige Aufgabe für Unternehmenslenker darin, ihre Aufmerksamkeit auf die bestmögliche Ausgestaltung der Wertschöpfungsprozesse zu legen: Ultimately, all differences between companies in cost or price derive from the hundreds of activities required to create, produce, sell, and deliver their products or services, such as calling on customers, assembling final products, and training employees. Cost is generated by performing activities, and cost advantage arises from performing particular activities more efficiently than competitors. Similarly, differentiation arises from both the choice of activities and how they are performed. Activities, then, are the basic units of competitive advantage. Overall advantage or disadvantage results from all a company’s activities, not only a few. (Porter 1996, 2002).

63

3.2 Null-Grenzkosten-Geschäftsmodelle

Bis heute hat das Modell der Wertschöpfungskette nichts von seiner universalen Aussagekraft verloren. Um das Modell auf die Ausgangssituation der digitalen Wertschöpfungsprozesse anzuwenden, wird hier das Modell abstrahiert. Heruntergebrochen auf die wesentlichen Prozessschritte lässt sich jedes Wertschöpfungsverfahren (egal ob physisch oder digital) eines Produkts oder einer Dienstleistung in zwei zentrale Tätigkeiten zerlegen: in die Herstellung und in den Vertrieb. Übertragen auf die Wertschöpfungsaufgaben der Digitalisierung, ergeben sich folgende Austauschprozesse, die potenziell für eine Digitalisierung infrage kommen: • Der Hersteller ist sowohl für die Erstellung des Produkts als auch für den Vertrieb zuständig. • Gekauft werden die Produkte vom Endkunden, der mit dem Kauf seine spezifischen Bedürfnisse befriedigt. Zwischen dem Produzenten und dem Endkunden liegen damit drei Marktebenen, die für eine Digitalisierung infrage kommen: die Herstellung, das Produkt und der Vertrieb. Dabei spielt es keine Rolle, ob die Produktion und der Vertrieb vom gleichen Marktakteur durchgeführt werden, oder ob auf einer Austauschebene mehrere wirtschaftliche Akteure beteiligt sind. Diese Darstellung gilt unabhängig von der betrachteten Güterart und den beteiligten Marktakteuren. Es handelt sich um die universale Darstellung einer Markttransaktion (s. Abb. 3.3). Die Entstehung von Null-Grenzkosten-Geschäftsmodellen setzt voraus, dass die digitale Wertschöpfungskette über alle drei Austauschebenen aufrechterhalten wird. Verbleibt eine der Austauschebenen auf einer physischen Ebene, schnellen die Grenzkosten auf dieser Stufe sprunghaft in die Höhe. Es gilt folgender Zusammenhang für alle Branchen: Erst wenn alle Wertschöpfungsschritte in Zukunft digitalisierbar sind, entstehen in den jeweiligen Branchen Null-Grenzkosten-Geschäftsmodelle. Diese Aussage verdeutlicht die Grenzen der Digitalisierung: Einige Produkte und Prozesse sind nur bedingt oder nicht digitalisierbar. Lebensmittel oder Textilien werden nie digitale Produkte werden. Zudem befinden sich viele Herstellungs- und Vertriebsprozesse in Übergangsstadien auf dem Weg von einer physischen zu einer digitalen Bereitstellung. Das bedeutet, dass zwar ein Teil der Herstellungs- bzw. Vertriebsprozesse

Hersteller

Produkon

Produkt

oder Dienstleistung

Abb. 3.3   Grundelemente der Wertschöpfungskette

Verkauf

Kunde

64

3  Der Weg in die Null-Grenzkosten-Ökonomie

digitalisierbar ist, Zwischenstufen der Produktion oder des Vertriebs verbleiben aber in der physischen Wertschöpfung. Beispielsweise kann mit dem Einsatz eines 3D-Druckverfahrens die Vorlage für ein physisches Produkt digital erstellt werden. Das eigentliche Druckverfahren bleibt dennoch physisch. In solchen Fällen werden die Austauschebenen als „teilweise digitalisiert“ eingestuft. Beispiel Banking

Die Bankenbranche eignet sich gut, um die Auswirkungen der Digitalisierung auf die Wertschöpfungskette zu verdeutlichen. Bereits 1990 prognostizierte der damalige Vorstand der Deutsche Bank, Ulrich Cartellieri, massive Einschnitte im Geschäftsmodell der Banken. „Die Banken sind die Stahlindustrie der 1990er-Jahre“, lautete sein Credo, das von vielen Bankvorständen zum damaligen Zeitpunkt massiv kritisiert wurde (Meifert 2016). Der Anfang der Digitalisierung bzw. Automatisierung der Bankenbranche kann aber bereits deutlich früher datiert werden. Die Kreissparkasse Tübingen installierte 1968 den ersten Geldautomaten in Deutschland an den Außenmauern der eigenen Zentrale. Allerdings stand dieser Service zunächst nur ausgewählten Kunden und nur mit der Benutzung spezieller Lochkarten zur Verfügung. Erst mit der Einführung der EC-Karte und der Ausstattung dieser Karten mit einem Magnetstreifen und einem PIN-Verschlüsselungsverfahren stieg die Nutzung der Geldautomaten ab Mitte der 1980er-Jahre rasant an. Den Zenit erreichte die Anzahl der Bankautomaten in Deutschland im Jahr 2015, als 61.100 Bankautomaten aufgestellt waren. Seitdem sinkt die Zahl langsam wieder – unter anderem, weil die Bankkunden heute immer öfter bargeldlos bezahlen (Pöltzl 2018). Den Grundstein für den bargeldlosen Zahlungsverkehr legten die ersten digitalen Online-Überweisungsverfahren, die via BTX vom Fernseher der Bankkunden aus durchgeführt werden konnten. BTX ist die Abkürzung für Bildschirmtext. Dabei handelte es sich um ein interaktives Online-Kommunikationssystem für Fernsehgeräte, das 1983 flächendeckend in Deutschland eingeführt wurde. Am 12. November 1980 startete die Deutsche Bundespost einen Feldversuch, an dem unter anderem die Versandhäuser Otto und Quelle sowie 2000 Testhaushalte aus Nordrhein-Westfalen teilnahmen. Erst 2007 wurde das BTX-Netzwerk in Deutschland abgeschaltet (Schmidt 2013). Aber erst mit der flächendeckenden Nutzung des Internets ab Mitte der 1990er-Jahre begann der Siegeszug des Online-Bankings. 1995 erhielt mit der Security First Network Bank in den USA die erste rein virtuelle Bank ihre Banklizenz. Bewusst verzichtete das Unternehmen auf den Betrieb eines eigenen Filialnetzes, um so die Kosten für Filialräume und Mitarbeiter einzusparen (Jaskulla 2015). Vier Jahre später startete mit der Netbank die erste deutsche Bank, die ausschließlich online betrieben wurde. Neben der Kontoführung erweiterten die Online-Banken ihr digitales Dienstleistungsspektrum zum Beispiel um die Bereiche Online-Aktienverwaltung, Aktienhandel (Brokerage) und Online-Kreditvergabe. 2001 nutzten acht Großbanken in den USA das System des digitalen Geldtransfers via Webbrowser. Ein Gang zur Bankfiliale wurde damit überflüssig, denn

3.3  Wann lohnt sich der Einstieg in digitale Technologien?

65

die Kunden konnten ihre Überweisungen vom heimischen Rechner aus tätigen. Zu diesem Zeitpunkt wurde das System von 19 Mio. Haushalten aktiv genutzt. Zehn Jahre später waren es bereits 54 Mio. Haushalte, die in den USA Online-Banking nutzten. Inzwischen ist die Verwendung von digitalen Bankdienstleistungen Standard geworden. Etwa die Hälfte der deutschen Bevölkerung nutzte 2018 nach Angaben des Bundesverbands deutscher Banken regelmäßig das Online-Banking (Bundesverband deutscher Banken 2018). 2018 war auch das Jahr, in dem in Deutschland erstmals die Summe der Einkäufe mit EC-Karte die Summe der bar bezahlten Einkäufe überstieg (Panagiotis und Wegmer 2019). Bezogen auf die Wertschöpfungskette der Banken sind längst alle drei Stufen digitalisiert: Die Produktion (die Bankdienstleistungen), das Produkt (Geld) und der Vertrieb (Online-Plattformen) können ohne physische Zwischenstufe abgewickelt werden. Das hat enorme Konsequenzen für das Geschäftsmodell der Banken: Schätzungen gehen davon aus, dass Online-Banken bei gleichem Umsatz nur ein Drittel des Personals einer Filialbank beschäftigen. Gleichzeitig sinken die Kosten für Miete sowie Betriebs- und Geschäftsausstattung. Die verbesserte Kostensituation kann in Form von geringeren Bankgebühren und Zinsen an die Kunden weitergereicht werden. Und so verwundert es nicht, dass beispielsweise die deutschen Volks- und Raiffeisenbanken planen, bis 2021 in Deutschland etwa 2000 Filialen zu schließen (Meifert 2016). Dieser Trend wird in den kommenden Jahren durch die zunehmende Automatisierung von IT-Dienstleistungen und Transaktionen noch weiter verstärkt werden. Damit erfüllt sich – zeitverzögert – im zweiten Jahrzehnt des 21. Jahrhunderts die Prognose des ehemaligen Deutschbankers Cartellieri.

3.3 Wann lohnt sich der Einstieg in digitale Technologien? Viele Unternehmen stehen bei der Beantwortung der Frage, wann sich die Integration neuer digitaler Technologien in das eigene Unternehmen lohnt, vor einem Rätsel. Zu groß ist die Menge der Optionen, die sich ihnen bietet, denn die Anzahl der möglichen digitalen Betätigungsfelder hat in den vergangenen Jahren stark zugenommen. Die folgende Liste gibt einen Überblick über aktuelle Anwendungsszenarien: • Internet of Things • Machine Learning • Deep Learning • Big Data • Conversational Bots • Mobile Communication • Cloud Computing • Blockchain • Virtual Reality/Augmented Reality

66

3  Der Weg in die Null-Grenzkosten-Ökonomie

Mit dem Modell zur Analyse von disruptiven Marktveränderungen hin zu Null-Grenzkosten-Geschäftsmodellen kann die Frage beantwortet werden: Zunächst ist es die Aufgabe des Unternehmens, das eigene, aktuelle Geschäftsmodell zu verstehen. Erst wenn das eigene Geschäftsmodell klar ist, ist ein Unternehmen in der Lage, sich einen Überblick darüber zu verschaffen, wann sich der Einsatz digitaler Technologien lohnt. Wenn sich die Wertschöpfungsprozesse des Kerngeschäfts weiter digitalisieren lassen, entstehen innerhalb des Unternehmens neue Kostenstrukturen. Diese Kostenvorteile können das Kosten-Umsatz-Verhältnis (Cost-Income-Ratio) verbessern und gegebenenfalls an die Kunden weitergereicht werden. Erfolgreich sind Digitalisierungsmaßnahmen also dann, wenn sich die Grenzkosten der Herstellung oder des Vertriebs in die Richtung eines Null-Grenzkosten-Geschäftsmodells verändern lassen. Ein Beispiel: Uber ist eine mobile Plattform, die Beförderungsdienste zwischen Fahrern und Kunden vermittelt. Die Plattform von Uber erreicht hunderttausende Mitarbeiter und Millionen von Kunden über mobile Kommunikationskanäle – und das nahezu zum Nulltarif. Damit ist Uber ein Paradebeispiel dafür, wie eine digitale Technik (in diesem Fall „Mobile Communication“) gewinnbringend in die Wertschöpfungskette integriert werden kann. Dieses Praxisbeispiel verdeutlicht, dass sich der Einstieg in die Digitalisierungstechnik „mobile Kommunikation“ für Unternehmen lohnt, die via App oder Webbrowser ihre digitale Dienstleistung an den Endkunden bringen möchten. Denn durch mobile Kommunikation sinken die Grenzkosten für die Ansprache potenzieller Kunden über mobile Endgeräte auf nahezu Null. Das kann für eine Vermittlungsplattform für Waren oder Dienstleistungen interessant sein (Bsp. eBay), aber auch für Suchmaschinen (Bsp. Google), E-Commerce-Unternehmen (Bsp. Zalando) oder Content-Anbieter (Bsp. Sky). Ein weiteres Beispiel für eine gelungene digitale Transformation hin zu einem Null-Grenzkosten-Geschäftsmodell liefert Netflix. Bis 2006 beschränkte sich das von Reed Hastings und Marc Randolph 1997 gegründete Unternehmen auf den Versand von DVDs. Das Geschäftsmodell war also in der Old Economy verhaftet: Es bestand darin, die Logistik für den Versand von mehr als einer Milliarde DVDs bereitzustellen und zu steuern. 2006 erkannte Reed Hastings, dass die Zukunft des privaten Filmkonsums nicht an den Vertrieb physischer Datenträger gebunden ist. Die Streaming-Technologie brachte audiovisuelle Inhalte und Filme via Internet (IPTV) in die Wohnzimmer der Zuschauer. In der Anfangszeit behinderten die geringen Bandbreiten eine schnellere Verbreitung des digitalen Streaming-Angebots. Aber mit dem Ausbau von Breitband-Zugängen in den westlichen Industrieländern etwa ab 2005 veränderte sich die Ausgangslage. Heute ist ein Großteil der Wertschöpfungskette von Netflix digitalisiert. Speziell der Vertrieb der Produkte läuft über die Plattform „Netflix.com“, die aktuell von 135 Mio. Menschen genutzt wird (Stand 2019).

3.3  Wann lohnt sich der Einstieg in digitale Technologien?

67

Wann lohnt sich für Ihr Unternehmen die Integration digitaler Technologien?

Die folgende Anleitung soll Ihnen dabei helfen, potenzielle Investitionen in Digitalisierungstechnologien zu evaluieren. Die Analyse ist in fünf Stufen aufgeteilt: 1. Verstehen des eigenen aktuellen Geschäftsmodells 2. Status quo der Digitalisierung innerhalb der Branche 3. Anwendungsszenarien für Digitalisierungstechnologien entlang der Wertschöpfungskette im eigenen Kerngeschäft 4. Überprüfen der eigenen Kostenstruktur: Entwicklung zum Null-Grenzkosten-Geschäftsmodell möglich? 5. Folgeabschätzung 1. Verstehen des eigenen aktuellen Geschäftsmodells Für das bessere Verständnis des eigenen, aktuellen Geschäftsmodells eignet sich das Modell des magischen Dreiecks, das von Oliver Gassmann entwickelt wurde (Gassmann et al. 2013, s. Abb. 3.4). • Wer ist die Zielgruppe? Für einen Streamingdienst wie Spotify sind das zum Beispiel gleich zwei unterschiedliche Gruppen: die Hörer, die ein Musikabo kaufen, und die werbetreibende Industrie. • Was ist das Produkt/die Dienstleistung und wie unterscheidet sich dieses Produkt von den Angeboten der Konkurrenz? Spotify bietet eine Plattform für Musikliebhaber, die es den Nutzern ermöglicht, auf komfortable Weise durch Streaming auf eine digitale Musikbibliothek zuzugreifen. Spotify hebt sich durch den Nutzungskomfort, die Individualisierbarkeit des Angebots und durch die Größe der Musikbibliothek von anderen Unternehmen ab. Abb. 3.4   GeschäftsmodellAnalyse nach Gassmann

Was?

Nutzenversprechen

Wer? Ertragsmechanik

Wert?

Wertschöpfungske e

Wie?

68

3  Der Weg in die Null-Grenzkosten-Ökonomie

• Wie entsteht Gewinn? Der Gewinn bleibt über, nachdem vom Umsatz die Kosten abgezogen wurden. Laufende Kosten entstehen für Spotify durch den Betrieb der digitalen Plattform, die Marketingaufwendungen und den Einkauf der Musiklizenzen. Umsatz generiert das Unternehmen durch die Abonnementzahlungen der Kunden und die Werbegelder der Unternehmen, die Werbespots zwischen den Songs schalten. • Welche Prozesse sind notwendig, um das Produkt herzustellen und zu vertreiben? Dazu wird die Wertschöpfungskette des Unternehmens analysiert (s. Abschn. 3.2.2). 2. Status quo der Digitalisierung innerhalb der Branche Vergleichen Sie nun Ihr Unternehmen mit anderen Unternehmen der Branche. Untersuchen Sie den Status der Digitalisierung bei Ihrer Konkurrenz entlang der Wertschöpfungskette. • Wie weit ist die Digitalisierung der Marktstufen in Ihrer Branche vorangeschritten? • Ist die Herstellung digitalisierbar? Und wenn ja: mithilfe welcher Digitalisierungstechnologien? • Wie weit ist die Digitalisierung der Herstellung vorangeschritten: Vollständig? Teilweise? Oder noch gar nicht? • Ist das Produkt digitalisierbar? Und wenn ja: mithilfe welcher Digitalisierungstechnologien? • Wie weit ist die Digitalisierung des Produkts vorangeschritten: Vollständig? Teilweise? Oder noch gar nicht? • Ist der Vertrieb digitalisierbar? Und wenn ja: mithilfe welcher Digitalisierungstechnologien? • Wie weit ist die Digitalisierung des Vertriebs vorangeschritten: Vollständig? Teilweise? Oder noch gar nicht? 3. Anwendungsszenarien für Digitalisierungstechnologien entlang der Wertschöpfungskette im eigenen Kerngeschäft Ausgehend von der Wertschöpfungskette werden im dritten Schritt Anwendungsszenarien für die Einbindung digitaler Technologien in die Prozesse der Erstellung und des Vertriebs überprüft. Die folgende Liste mit Digitalisierungstechnologien wird dazu als Checkliste verwendet: • Internet of Things • Machine Learning • Deep Learning • Conversational Bots • Big Data • Mobile Communication • Cloud Computing • Blockchain • Virtual Reality/Augmented Reality

3.3  Wann lohnt sich der Einstieg in digitale Technologien?

69

Für eine Mediaplanungsagentur ergibt es beispielsweise Sinn, die möglichen Werbeplatzierungen mit Hilfe von KI-Algorithmen bestimmen und evaluieren zu lassen (s. Abschn. 3.6). Durch den Einsatz von KI-Algorithmen kann ein Prozess, der vormals menschliche Arbeitskräfte gebunden hat, automatisiert ablaufen und so die Kosten der Dienstleistungserstellung senken. Für einen Software-Spielehersteller ist es dagegen möglicherweise sinnvoll, das bereits produzierte Online-Spiel nicht nur auf den traditionellen Spieleplattformen wie PC oder Spielkonsolen anzubieten, sondern das Angebot auf Apps für mobile Endgeräte auszuweiten. Welche der dargestellten Technologien unterstützt das Geschäftsmodell des von Ihnen untersuchten Unternehmens? Lassen Sie sich bei Ihren Überlegungen von anderen Branchen und deren Digitalisierungsansätzen inspirieren. 4. Überprüfen der eigenen Kostenstruktur: Entwicklung zum Null-Grenzkosten-Geschäftsmodell möglich? Überprüfen Sie im nächsten Schritt, wie sich die Kostenstruktur innerhalb Ihres Unternehmens durch die Digitalisierung verändert. Nur wenn sich die Kostenstruktur in Richtung Null-Grenzkosten-Geschäftsmodell bewegt, ergibt eine Investition Sinn. Digitale Finanzberater verändern zum Beispiel für Banken den Vertrieb von Finanzprodukten. Statt im persönlichen Gespräch in der Filiale informieren sich Kunden bei einem digitalen Finanzberater online über mögliche Anlagestrategien und suchen das passende Produkt für sich aus. Der Vertrieb von Finanzprodukten entwickelt sich dadurch in Richtung „Null-Grenzkosten-Geschäftsmodell“. Sobald der digitale Finanzberater entwickelt und programmiert wurde, ändert sich die Kostensituation der Bank erheblich. Statt wie bisher die Beratungsleistung auf Basis von Festgehältern und Provisionen für die Bankangestellten zu entlohnen, kostet der digitale Finanzberater die Bank nur noch die Serverbetriebskosten. Die höhere Gewinnmarge kann von den Banken an die Käufer der Finanzprodukte weitergereicht werden. 5. Folgeabschätzung Nicht immer ist es der Weisheit letzter Schluss, in Digitalisierungsprojekte zu investieren. Denn der laufenden Kostenreduktion durch die Digitalisierung stehen die Entwicklungs- und Implementierungskosten gegenüber. Daher sollten zum Abschluss der Analyse folgende Fragen beantwortet werden: • Wieviel kann dadurch in Zukunft eingespart werden? • Was kostet die Investition heute? Führen Sie zu diesem Zweck eine interne Finanzierungsrechnung durch. Nur wenn die potenziellen Einsparungen in der Zukunft, abgezinst auf die Gegenwart, die Investitionen übersteigen, lohnt es sich, über eine Investition in die Implementierung digitaler Technologien nachzudenken.

70

3  Der Weg in die Null-Grenzkosten-Ökonomie

3.4 Die Ausbreitung der Null-Grenzkosten-Geschäftsmodelle – Beispiel Automobilindustrie Null-Grenzkosten-Geschäftsmodelle werden zukünftig nicht auf digitale B2C-Unternehmen beschränkt bleiben, sondern sich auf weitere Branchen ausweiten. Die Taxibranche (siehe das Beispiel Uber) und die Entertainmentbranche haben diese Entwicklung bereits hinter sich. Inwieweit andere Branchen von dieser Entwicklung zum Null-Grenzkostenmodell betroffen sein werden, kann anhand des Modells zur Analyse der disruptiven Marktveränderung hin zu Null-Grenzkosten-Geschäftsmodellen dargestellt werden. Wie kommt die deutsche Automobilindustrie wieder auf die Überholspur?

Ein interessantes Beispiel für die Ausbreitung von Null-Grenzkosten-Geschäftsmodellen bietet die deutsche Automobilindustrie. Sie steht momentan – Stand 2019 – unter großem Druck. Sowohl kurz-, als auch mittel- und langfristig drohen Gefahren. Kurzfristig belasten die Fragen rund um den Dieselskandal und das fragwürdige Vorgehen deutscher Manager das Image der Autokonzerne. Mittelfristig ist folgendes Problem erkennbar: Bis heute ist es der deutschen Automobilindustrie nicht gelungen, auf die Herausforderungen durch Neo-Autobauer wie Tesla eine überzeugende Antwort zum Thema E-Mobilität zu geben. Alle großen deutschen Autokonzerne haben umfangreiche E-Mobilitätsprogramme aufgesetzt, doch ob diese ausreichen, um in Zukunft mit den Herausforderern aus Amerika und Asien zu konkurrieren, ist noch nicht abzusehen und keine ausgemachte Sache. Die größten Gefahren für die deutsche Autoindustrie drohen langfristig. Während Dieselskandal und E-Mobilität die Geschäftsmodelle marginal verändern, deuten sich mit der voranschreitenden Entwicklung von KI-Systemen, dem dadurch möglichen autonomen Fahren und dem industriell angewendeten 3D-Druck-Verfahren disruptive Veränderungen des Automobilmarktes an. Ein Beispiel dafür liefert Local Motors Industries (Sommer 2018): Die Geschäftsidee dieses Unternehmens besteht darin, Autoteile in lokalen Firmengaragen auf 3D-Druckern auszudrucken. Gleichzeitig wird die entstehende Community aufgefordert, sich beim Design der Autos einzubringen. So wird auf lange Sicht die Massenproduktion von Autos in großen Fabriken überflüssig. Die Folge: Mit der Perfektionierung der 3D-Drucktechnik in der Automobilbranche steigt der Digitalisierungsgrad des Herstellungsprozesses. Zwar wird auch in Zukunft die Herstellung der Karosserie eines Automobils ein physischer Prozess bleiben, doch durch die neuen Technologien verlagert sich die Kernaufgabe der Produktion weg vom physischen Herstellungsprozess hin zur digitalen Erstellung der

3.4  Die Ausbreitung der Null-Grenzkosten-Geschäftsmodelle …

71

3D-Vorlage. Die Produktion der Autos kann dezentral, weltweit und in kleinen Stückzahlen erfolgen. Unabhängige 3D-Druck-Anlagenbetreiber stellen das gleiche Auto anhand der Vorlage zeitgleich in Kapstadt und Singapur her. Mithilfe des Modells zur Analyse disruptiver Marktveränderungen hin zu Null-Grenzkosten-Geschäftsmodellen lässt sich die Entwicklung der Automobilbranche verdeutlichen. Die einzelnen Stufen der technischen Weiterentwicklung werden im Folgenden auf ihr disruptives Potenzial zur Weiterentwicklung der Automobilbranche hin zu Null-Grenzkosten-Geschäftsmodellen analysiert. 1. Stufe: Elektromobilität Elektromobilität ist keine disruptive Veränderung der Wertschöpfung der Automobilbranche. So wie die CD die Schallplatte abgelöst hat, wird sich im Fall der Elektromobilität nur das Produkt ändern, die grundlegenden Herstellungs- und Vertriebsprozesse werden sich hingegen kaum verändern. Bereits heute beginnen Automobilhersteller ihre Produktionstätigkeiten zu verlagern: weg von Kraftstoff-Motorenwerken hin zum Bau von Batterie- und E-Antriebswerken. Dieser Prozess ist längst im Gange. Weder für die Hersteller noch für den Endkunden verändert sich der Warenaustauschprozess. Die gleichen Akteure, die den Markt für Benzin- und Dieselmotoren dominiert haben, sind in der Lage, auch in Zukunft den Markt für Antriebstechnologien zu bearbeiten. 2. Stufe: Autonomes Fahren Derzeit – 2019 – kann kein Experte zuverlässig prognostizieren, wann die ersten autonomen Fahrzeuge als Massenprodukt auf den Markt kommen werden. Die Technik steht in den Startlöchern und hat in den letzten Jahren große Entwicklungssprünge gemacht. Längst fahren Testserien großer Automobilanbieter über die Straßen – seien es Google Cars in San Francisco oder Lkw-Kolonnen auf deutschen Autobahnen. Dennoch sind vor einer Markteinführung noch zahlreiche technische, rechtliche und ethische Fragen zu lösen. Sobald diese Hürden überwunden sind, wird es zu einer absehbaren Disruption des Automobilmarktes kommen (Soller 2018). Vergleichbar mit der Ablösung der CD durch MP3 im Musikmarkt betritt mit dem autonomen Fahren ein neues Produkt den Markt. Das autonome Fahren verändert das Konsumverhalten des Endverbrauchers. Statt wie bisher eine aktive Rolle bei der Verwendung einzunehmen, kann sich der Konsument im autonomen Automobil zurücklehnen und die Maschine für sich arbeiten lassen. Das gibt dem Konsumenten die Möglichkeit, seine Zeit im Auto anders zu nutzen. Das Auto wird zu einer fahrenden Informations- und Entertainment-Einheit. Aus Konsumentensicht wird das Auto der Zukunft damit austauschbarer. So wie es für den städtischen

72

3  Der Weg in die Null-Grenzkosten-Ökonomie

Taxi-Kunden unerheblich ist, ob er mit einem Hyundai oder einem Daimler in der Stadt von Punkt A nach Punkt B gebracht wird, wird der Fokus von Fahrern eines autonomen Fahrzeugs nicht mehr auf Karosserie und Motorleistung liegen. Wichtiger werden in Zukunft die digitalen Dienstleistungen sein, die der Kunde während der Fahrt konsumieren kann. Gleichzeitig entscheidet die Qualität der Informationen und des Entertainments maßgeblich über den Nutzen, den das neue Produkt Automobil erzeugt. Das K ­ erngeschäftsmodell der Branche wandelt sich damit: Es geht in erster Linie nicht mehr um die Bereitstellung des physischen Produkts, sondern um die Herstellung und den Vertrieb digitaler Informationen. Aus dem physischen Gut Auto wird eine digitale Abspiel-Plattform. Damit verändert autonomes Fahren die grundlegende Natur des Produkts Automobil. Gleichzeitig verschiebt sich die Wertschöpfungskette der Automobilindustrie in Richtung „Null-Grenzkosten-Geschäftsmodell“. Das heißt, das physische Produkt (die Stahlhülle des Autos) verliert an Bedeutung. Der eigentliche Wettbewerb zwischen den Automobilherstellern wird sich auf die Nutzungsdaten der Kunden und deren Verarbeitung beziehen. Die Folgen dieses Trends sind aktuell beobachtbar. Automobilhersteller wie BMW oder General Motors treten inzwischen auf Consumer Electronic- und Technologie-Messen wie der CES in Las Vegas auf. Gleichzeitig sinkt die Bedeutung klassischer Messen wie der IAA in Frankfurt oder der Automobilmesse in Detroit (Schmidt 2018). Für die deutsche Automobilbranche liegt hier die Gefahr, denn sie ist auf diese Entwicklung nicht gut vorbereitet. Das liegt daran, dass die deutsche Wirtschaft zwar stark im industriellen Sektor ist, aber den Anschluss an die „Null-Grenzkosten-Geschäftsmodelle“ verpasst hat. Diese Ausgangsposition bietet aber auch eine Reihe von Chancen für die Zukunft. Denn noch bleibt den deutschen Autobauern Zeit, um ihre schlechte Ausgangsposition im Wettbewerb um die Befriedigung der zukünftigen Nutzerbedürfnisse zu verbessern. Die Frage, die sich für die deutschen Automobilhersteller stellt, lautet: Werden sie in der Lage sein, das Informations- und Konsumbedürfnis genauso überzeugend zu befriedigen wie die amerikanischen Internet-Konzerne? Inwieweit die deutsche Automobilindustrie diese Herausforderung meistern kann, wird sich erst in den kommenden Jahren zeigen. Langfristig besteht die realistische Gefahr, dass deutsche Automobilhersteller durch die Disruption des Marktes schwere Nachteile erleiden und ihre dominierende Position in der Herstellung und im Vertrieb von Pkws und Lkws verlieren werden. Im Umgang mit den disruptiven Herausforderungen und den potenziellen Herausforderern aus dem Silicon Valley gibt es für die deutsche Automobilbranche zwei Handlungsoptionen:

3.4  Die Ausbreitung der Null-Grenzkosten-Geschäftsmodelle …

73

1. Die Verantwortlichen der Branche erkennen, dass sich das Kerngeschäft der Zukunft wandelt und beginnen damit, eigene Null-Grenzkosten-Geschäftsmodelle voranzutreiben und in das Kerngeschäftsmodell einzubinden. Eine Lösung für ein solches Szenario wäre zum Beispiel die Entwicklung eigener digitaler Assistenten, die den Fahrzeuginsassen bei der Informationsbeschaffung und Mediennutzung unterstützen. Damit erhalten die Autokonzerne Zugriffsrechte auf die Nutzungsdaten und Informationsgewohnheiten und haben damit die besten Voraussetzungen, um das Medien- bzw. Content-Angebot für die Nutzer im Auto zu verbessern. 2. Möglich ist aber auch, dass die deutsche Automobilindustrie den Wandel des eigenen Kerngeschäftsmodells nicht vorantreiben wird. Unter den Bedingungen des autonomen Fahrens und des Wandels des Konsumentenverhaltens werden die Hersteller zu Zulieferern der amerikanischen Informations- und Entertainmentunternehmen degradiert. Wenn digitale Produkte und Dienstleistungen den klassischen Wertschöpfungsprozess ablösen, würde sich das Aufgabenspektrum verändern, und das würde mit einem erheblichen ökonomischen Bedeutungsverlust der deutschen Autobranche einhergehen. Im Laufe der letzten Jahrzehnte hat es unterschiedliche Einstiegszeitpunkte gegeben, zu denen eine technologische Entwicklung die einzelnen Branchen disruptiert und den Weg zu Null-Grenzkosten-Geschäftsmodellen geebnet hat. Den Anfang machte – wie in Abschn. 3.2.2 dargestellt – die Bankenbranche. Die ersten digitalen Online-Banken betraten bereits Mitte der 1990er-Jahre den Markt. Es folgte die Werbebranche: Digitale Werbung und Bannerschaltung auf Websites waren von Beginn an ein digitales Geschäftsmodell mit Null-Grenzkosten. Andere Beispiele wurden im Laufe des Kapitels bereits diskutiert: die Filmbranche, die Musikbranche, die TV-Branche. Abb. 3.5 gibt einen kurzen Überblick, wann die Digitalisierung in welchen Branchen Einzug gehalten hat. Durch die Digitalisierung ändern sich nicht nur die Wertschöpfungsketten, auch die Produkte werden anders genutzt. Mit dieser Veränderung wandelt sich die Funktion von Produkten: Statt für den Endverbraucher Produkte physisch bereit zu stellen, werden Leistungen digital angeboten. Diese Entwicklung und die damit verbundenen notwendigen Anpassungen führen zu schmerzhaften Umstellungsprozessen in den Unternehmen. Das Modell zur Analyse disruptiver Marktveränderungen hin zu Null-Grenzkosten-Geschäftsmodellen liefert die Grundlage, um die Auswirkungen für ein Unternehmen individuell zu analysieren und entsprechende Gegenstrategien zu entwickeln.

1990

1995

2005

2010

2015

Digitalisierung des Markts

Streaming Spofy

2020

2025

Uber, Ly, MyTaxi, …

Bandbreite steigt Nelix stellt Vertrieb um

eBooks Kindle von Amazon

Downloads ITunes

Streaming startet ZDF Mediathek

Napster

E-Paper-Ausgaben

Online-Werbebanner Ad-Server

Steigende Verbreitung des Internets Gründung der ersten Online-Bank

Online News

2000

PDF von Adobe

CD Ära

Erste B2B-Transakon einer Bank

1985

MP3 erfunden

Digitale Herstellung Digitaler Vertrieb

1980

Abb. 3.5   Start von Null-Grenzkosten-Geschäftsmodellen

IndividualVerkehr (Auto)

TV-Branche

Buchbranche

Musikbranche

Zeitung

Werbebranche

Banken

Branche

Autonomes Fahren

74 3  Der Weg in die Null-Grenzkosten-Ökonomie

75

3.5  Big stays beautiful – vom vermeintlichen Abstieg der großen Konzerne

3.5 Big stays beautiful – vom vermeintlichen Abstieg der großen Konzerne Sind die Zeiten der großen Konzerne mit der Digitalisierung vorbei? Die bisherigen Argumente deuten darauf hin: Große Umsätze können in Zukunft, dank der Skalierbarkeit der Geschäftsmodelle, durch kleine Teams erzielt werden. In einem solchen Szenario entwickeln sich vormals oligopolistische oder monopolistische Branchen zu polypolistischen Märkten. Aus einem Markt mit wenigen großen Playern und ihren jeweiligen Wertschöpfungsketten würden lebendige Branchen voll innovativer Startups und Einzelunternehmen. Die Zeit der großen Konzerne ist in einem solchen Szenario durch die Veränderung der Grenzkosten hin zu Null-Grenzkosten-Geschäftsmodellen abgelaufen. Grafisch wird ein solches Szenario in Abb. 3.6 dargestellt. Die Entwicklung der vergangenen Jahre zeigt aber in eine andere Richtung, und das gilt im Speziellen für die Digitalbranche. Immer größer werden die Konzerne, die für die Umsetzung der digitalen Wertschöpfungskette verantwortlich sind. Denn Märkte, auf denen Null-Grenzkosten-Geschäftsmodelle dominieren, besitzen die Tendenz zur Monopolbildung. Die Gründe für diese Konzentrationstendenzen sind vielfältig und wurden teilweise bereits im zweiten Kapitel dargestellt: Die Ausnutzung der digitalen Netzwerkeffekte, das Data Leveraging und die Winner-Takes-All-Problematik können von großen Unternehmen besser gelöst werden (Kap. 2). Neben diesen Effekten führen die Skaleneffekte (Economies of Scale) zu verringerten Grenzkosten und verbessern so die Kostenstrukturen großer Unternehmen. Dieser Zusammenhang wurde in Abschn. 3.1.1 dargestellt. Zusätzlich treten auf digitalen Märkten sogenannte Verbundeffekte (Economies of Scope) auf, wenn Ressourcen von unterschiedlichen Unternehmenseinheiten gemeinsam genutzt werden. In der

G L

Anzahl Mitarbeiter

E

W

F R

M Q K

B

H

C A 0

D

O

J

E

N

V

T P

I

S

U

Relaver Marktanteil

Im Verhältnis zum größten Webewerber

Abb. 3.6   Digitale Märkte – Marktanteile und Mitarbeiteranzahl

2

76

3  Der Weg in die Null-Grenzkosten-Ökonomie

Digitalwirtschaft entstehen solche Effekte zum Beispiel durch die Bereitstellung großer Rechenkapazitäten, auf die unterschiedliche Unternehmensbereiche zugreifen. Die gemeinsame Nutzung von Serveranlagen in Unternehmen wie Google, Amazon oder Microsoft ist ein Beispiel für die Ausnutzung von Verbundeffekten. Im Ergebnis weisen digitale Märkte eine Tendenz zur Subadditivität auf. Subadditivität bezeichnet die Fähigkeit eines einzelnen Unternehmens, die Nachfrage auf einem gesamten Markt abzudecken. Durch die hohe Skalierbarkeit von Null-Grenzkosten-­ Geschäftsmodellen ist das möglich. Beispielsweise ist es Google gelungen, nahezu das gesamte Geschäft mit Suchanfragen im Internet seit vielen Jahren zu dominieren. Alphabet, der Mutterkonzern von Google, besaß 2018 in Deutschland einen Marktanteil von 85,78 % im Bereich der Desktop-Suchmaschinenanfragen und 98,3 % bei den mobilen Suchanfragen (Seo-Summary 2018). Eine zweite Suchmaschine ist nicht erforderlich, um die Nachfrage am Markt zu bedienen. Wenn es einem aufstrebenden, jungen Unternehmen doch einmal gelingt, den Branchengrößen Paroli zu bieten und relevante Marktanteile eines Digitalmarkts auf sich zu vereinen, so wird es in vielen Fällen rasch von den Branchengiganten aufgekauft. Der Messagingdienst WhatsApp ist ein gutes Beispiel: 2014 kaufte der Facebook-Konzern das von den beiden ehemaligen Yahoo-Mitarbeitern Jan Koum und Brian Acton gegründete Unternehmen um 19 Mrd. USD. (Graupner 2019). Damit wurde der aufstrebende Messagingdienst für Smartphones ein Teil des Produktportfolios des Mediengiganten Facebook. In der Folge konnte Facebook alle Vorteile, die sich in Null-Grenzkosten-Geschäftsmodellen für große Unternehmen ergeben, auf WhatsApp übertragen. WhatsApp konnte weiterhin wachsen und gleichzeitig von der Rechenleistung profitieren, die Facebook auf den weltweiten Serveranlagen vorhält. Zusätzlich trägt WhatsApp zum Anwachsen des gemeinsamen Datenpools des Mutterkonzerns bei (Skalen- und Verbundeffekte). Durch die große Skalierbarkeit konnte WhatsApp in Deutschland zum uneingeschränkten Marktführer aufsteigen (Subadditivität). So verwenden zum Beispiel 63 % der deutschen Onlinenutzer regelmäßig WhatsApp (Brandt 2016). Da immer mehr Menschen das Produkt verwendeten, wurde die Nutzung auch für andere Nutzer attraktiv (Netzwerkeffekt). Heute ist es für neue Messaging-Anbieter wie Threema oder Telegram schwer, relevante Marktanteile zu erobern (WinnerTakes-All-Problematik). Das Besondere an der Übernahme von WhatsApp war die Art und Weise, wie Facebook mit der Akquisition umging: Statt lediglich die Technologie für das eigene Produkt Facebook Messenger zu übernehmen und das Produkt WhatsApp selbst einzustellen, wurden sowohl das Produkt als auch das Team in seiner Eigenständigkeit beibehalten. Bis heute arbeitet WhatsApp innerhalb des Facebook-Konzerns als autonom agierende Geschäftseinheit. Der Verlauf der Übernahme verdeutlicht einen Zusammenhang, der für die gesamte Digitalbranche relevant ist: Zum einen lernen die großen Unternehmen, dass kleine Einheiten effizienter arbeiten und übertragen diese Idee auf die eigene Unternehmens-

3.5  Big stays beautiful – vom vermeintlichen Abstieg der großen Konzerne

77

führung (s. Kap. 7). Zum anderen profitieren die digitalen Medienkonzerne des Silicon Valley vom Prinzip der Subadditivität und vom Prinzip des natürlichen Monopols auf Medienmärkten. Sie besitzen die Daten und die Finanzkraft, um neue Marktakteure frühzeitig mit lukrativen Angeboten aufzukaufen. Gleichzeitig haben sie verstanden, dass Null-Grenzkosten-Geschäftsmodelle in kleinen autonomen Einheiten effizienter umgesetzt werden als in starren Unternehmenshierarchien. So entstehen Unternehmen, die optimal an die Bedingungen der Digitalisierung angepasst sind. Sie vereinen die Vorteile aus den beiden Welten Startup und Konzern. Die digitalen Medienkonzerne besitzen gleichzeitig die Marktanteile, um die Größenvorteile, Skaleneffekte und die gemeinsame Datenverarbeitung für sich zu nutzen. Andererseits funktionieren sie in ihren organisatorischen Teileinheiten eher wie ein Netzwerk als ein klassisch hierarchisch orientierter Konzern. Damit nutzen sie die Agilität und Innovationskraft kleiner Einheiten für sich. Abb. 3.7 verdeutlicht diesen Zusammenhang grafisch. Setzt sich diese Entwicklung in den kommenden Jahren ungebremst fort, werden die großen digitalen Konzerne weiterwachsen. Damit wären Konzentrationstendenzen auf einzelnen Teilmärkten verbunden. Inwieweit die Wettbewerbshüter sich mit dieser Entwicklung verstärkt auseinandersetzen werden und welche regulatorischen Folgen sich daraus ergeben werden, wird die Zukunft zeigen. Zum Abschluss dieses Kapitels wird ein praktisches Beispiel für die Entwicklung von Null-Grenzkosten-Geschäftsmodellen vorgestellt. Anhand der Verlagsbranche wird deutlich, wie es gelingen kann, die Digitalisierung unter Beachtung der eigenen Wertschöpfungskette erfolgreich voranzutreiben.

Anzahl Mitarbeiter

Facebook

Facebook

Instagram Whatsapp Oculus K

A 0

J H

C D

B

I E

Relaver Marktanteil

Im Verhältnis zum größten Webewerber

Abb. 3.7   Tatsächliche Verteilung der Marktanteile in digitalen Märkten

2

78

3  Der Weg in die Null-Grenzkosten-Ökonomie

3.6 Künstliche Intelligenz für das Lektorat Ein Geschäftsmodell, das bis heute nicht vollständig digitalisiert wurde – und das damit erst an der Schwelle zu Null-Grenzkosten-Geschäftsmodellen steht – ist das Verlagsgeschäft mit Büchern. Dieser Zusammenhang soll im Folgenden anhand des dreistufigen Modells zur Analyse von disruptiven Marktveränderungen hin zu Null-Grenzkosten-Geschäftsmodellen untersucht werden. Auf der mittleren Stufe (das Produkt) gilt: Das Erzeugnis „Buch“ ist heute vollständig digitalisierbar, das erste E-Book mit zugehörigem E-Book-Reader wurde von Sony bereits 1990 veröffentlicht. Mit dem Aufkommen großer E-Commerce-Plattformen wie Amazon wurde auch die nachgelagerte Stufe (der Vertriebsprozess) digitalisiert. Zwar werden Bücher noch physisch ausgeliefert, der gesamte Bestellprozess vom Eingang der Bestellung bis zur Bezahlung und Abwicklung läuft aber digital ab. Einzig die erste Stufe, also der Herstellungsprozess von Büchern ist eine bis heute nur teilweise digitalisierbare Stufe der Transaktionen auf dem Buchmarkt. Der Herstellungsprozess von Büchern lässt sich entlang der Wertschöpfungskette in seine Einzelbestandteile aufspalten: Aus einer Idee wird ein fertiges Manuskript. Der Lektor prüft und korrigiert das Manuskript und entscheidet darüber, wann die Textvorlage freigegeben und in die finale Druckvorlage (Satz) überführt wird. Anschließend kann das Werk gedruckt und an den Einzelhandel ausgeliefert werden. Die Wertschöpfungskette des Buchhandels ist in Abb. 3.8 dargestellt. Die Content-Erstellung – der Prozess von der ersten Idee bis zum fertigen Manuskript – wird auf absehbare Zeit eine Domäne menschlicher Autoren bleiben. Zwar sind hochspezialisierte Algorithmen – sogenannte Roboterjournalisten – in der Lage, kurze Texte auf Basis neuer Datenlagen zu erstellen, zum Beispiel für Wettervorhersagen, Börsenberichte und für die Sportberichterstattung. Zur technischen Umsetzung werden dafür digitale Datenbanksysteme mit einer Textgenerierungssoftware verbunden. Bereits 2014 wurde der erste algorithmisch generierte Text über ein Erdbeben in Kalifornien online publiziert. Inzwischen veröffentlicht die Nachrichtenagentur Associated Press ca. 4400 automatisch generierte Finanzberichte pro Quartal (Technikjournal 2018). Allerdings stoßen diese Technologien bei der Erstellung neuer und kreativer Texte schnell an ihre Grenzen. Zu komplex sind die zu beschreibenden Phänomene der Welt, als dass ein Algorithmus eigenständig in der Lage wäre, Texte über diese Phänomene zu

Idee generieren

Text schreiben

Abb. 3.8   Wertschöpfungskette Buch

Buch redigieren und setzen

Buch drucken

Buch vertreiben

3.6  Künstliche Intelligenz für das Lektorat

79

verfassen. Kurz gesagt: Das Schreiben komplexer und kreativer Texte setzt einen Verständnisgrad der Außenwelt voraus, der von heutigen KI-Systemen nicht abgebildet werden kann (siehe Hintergrundinformation zur Künstlichen Intelligenz). Ein zweiter Teilbereich im Wertschöpfungsprozess „Buch“, der bislang von der Digitalisierung nahezu unberührt geblieben ist, ist das Lektorat von Büchern. Der Aufwand, der für die Lektorierung eines Buchs betrieben werden muss, ist enorm. Vom Lesen bis zum Überarbeiten der Manuskripte ist alles manuelle Arbeit, die bis heute als nicht durch Maschinen ersetzbar gilt. Wäre ein Algorithmus in der Lage, die Arbeit eines Lektors zu ersetzen, hätte das massive Auswirkungen auf die Kostenstruktur des Verlags. Die Grenzkosten des Lektorats würden gegen Null sinken und die Verlagsbranche hätte einen großen Schritt in Richtung Null-Grenzkosten-Geschäftsmodelle getan. Das deutsche Unternehmen Arvato Systems ist 2017 angetreten, um dieses Problem zu lösen. Im Rahmen eines Hackathons, an dem 20 Entwickler an drei Wochenenden teilnahmen, wurde eine Software entwickelt, die kurzfristig als digitale Ergänzung zum menschlichen Lektorat dienen kann. Langfristig könnten vergleichbare Systeme den Prozess der Lektorierung weiter digitalisieren und Schritt für Schritt menschliche Lektoren ersetzen. Die Frage, mit der sich die Entwickler im Rahmen der Softwareerstellung befassten, lautete: Wie kann eine Künstliche Intelligenz (KI) die Arbeit eines Lektors imitieren? Dazu musste zunächst geklärt werden, welche Arbeitsschritte ein Lektor durchführt, d. h. welche Bearbeitungsschritte ein Manuskript von dessen Einreichung bis zur letzten Fassung durchläuft. Künstliche Intelligenz Künstliche Intelligenz ist der Sammelbegriff für eine Vielzahl eigenständiger digitaler Programme (sogenannte Narrow KIs), die entwickelt werden, um spezifische Probleme zu lösen. Narrow KIs spielen Schach, erkennen Verkehrsschilder oder kommunizieren mit uns als Sprachassistenzsysteme. Bislang handelt es sich bei KI-Anwendungen um Insellösungen, sie spiegeln (noch) keine generellen menschlichen Kompetenzen und Fähigkeiten wider. Ein System, das auf eine Aufgabe trainiert wurde, kann auch nur für diese Aufgabe eingesetzt werden (Iskender 2018). Die meisten dieser Systeme basieren auf der technischen Grundlage der sogenannten künstlichen neuronalen Netze (KNN). Künstliche neuronale Netze imitieren mit ihrer Funktionalität eine grundlegende Fähigkeit des Gehirns: die Konditionierung. Geprägt wurde dieser Begriff vom Biologen Iwan Pawlow. 1905 setzte er in einem Versuch mit Hunden gekoppelte Reize, indem er den Tieren gleichzeitig mit dem Futter einen Klingelton präsentierte. Dabei beobachtete Pawlow den Effekt auf den Speichelfluss der Hunde. Nach mehreren Wiederholungen setzte der Speichelfluss ein, auch wenn nur der Klingelton zu hören, aber kein Futter zu sehen war. Diesen Effekt machen sich auch KNN zunutze: Bei erfolgreichen Versuchen stärken sie die erfolgreichen Verbindungen zwischen den digitalen Neuronen, weniger erfolgreiche Verbindungen werden nach erfolglosen Versuchen abgeschwächt (s. Abb. 3.9). Um die neuronalen Netze zu trainieren, erhalten KNNs einen Input und lernen im Laufe der Zeit, einen passenden Output zu liefern. Der Input ist häufig ein digitales Signal. Beim Output handelt es sich um die Beantwortung einer vordefinierten Fragestellung. KNNs liefern als Ergebnis Wahrscheinlichkeiten aus. Ein Beispiel: Der Input ist ein Foto. Die Fragestellung an das KNN lautet: Befindet sich auf dem eingespeisten Foto ein Gesicht? Output: Ja (mit 85 % Wahrscheinlichkeit).

80

3  Der Weg in die Null-Grenzkosten-Ökonomie

Abb. 3.9   Künstliche Neuronale Netze Wie gut ein künstliches neuronales Netz seine Aufgabe löst, hängt von der Qualität des Trainings ab. Je mehr Daten in ein neuronales Netz eingespeist werden, desto sicherer kann das ­System die ihm gestellte Aufgabe lösen. Der Grad der Komplexität der Aufgaben, die ein KNN bewältigen kann, ist in den vergangenen Jahren deutlich gestiegen. Voraussichtlich wird aber noch viel Entwicklungsaufwand notwendig sein, um KNNs komplexe menschliche Tätigkeiten und Interaktionen beizubringen.

Wie sieht der Arbeitsprozess eines Lektors aus? Als Input dient dem Lektor zunächst das vorliegende Manuskript. Dieses wird auf seine Tauglichkeit für das Verlagsportfolio untersucht. In einem zweiten Schritt wird die Qualität des Manuskripts geprüft (Textqualität, Fehler, Sprachstil, Lesbarkeit, roter Faden). In einem dritten Schritt wird vom Lektor eine Wirtschaftlichkeitsanalyse erstellt, bei der die Qualität des Buchs mit den Anforderungen der potenziellen Zielgruppe abgeglichen wird. Jeder dieser drei Schritte kann potenziell damit enden, dass ein Manuskript aussortiert wird. Um die Tätigkeit eines Lektors zu imitieren, muss die Software lernen, auf die Informationen und Daten, die einem Lektor zur Verfügung stehen, zuzugreifen und diese miteinander abzugleichen. Das ist zunächst das Ausgangsmanuskript. Dieses muss in einer analysier- und bearbeitbaren digitalen Fassung vorliegen. Darüber hinaus greift ein Lektor auf eine Reihe zusätzlicher Datenquellen zu: Daten aus der Buchhaltung, dem Controlling und der Warenwirtschaft des Verlags. Wie gut haben sich andere Bücher des Autors verkauft? Welche vergleichbaren Bücher wurden

3.6  Künstliche Intelligenz für das Lektorat

81

in den vergangenen Jahren produziert? Wie viele Auflagen haben diese Bücher erzielt? Aber auch Presseberichte, Rezensionen und Marktforschungsergebnisse fließen in die Analyse des Lektors ein (Stegen 2017). Will eine Lektorats-Software die Arbeit eines Lektors imitieren, benötigt eine solche KI neben dem eigentlichen Manuskript daher Zugriff auf digitale Datenquellen. Das Problem ist, dass diese Daten zum Teil auf unterschiedlichen Systemen gespeichert sind. Die Lösung für dieses Problem sind vereinheitlichte Datenstrukturen, die von einem KI-Lektorats-System eingelesen und verarbeitet werden können. Um den Lektorats-Prozess imitieren zu können, muss eine potenzielle Lektorats-Software trainiert werden. Arvato Systems hat daher zunächst große Datenmengen – sprich: zahlreiche Bücher und Metadaten – eingespeist und mit der realen Situation abgeglichen. Durch diesen Abgleich wurde die Lektorats-KI darauf trainiert, die ihr gestellten Aufgaben besser zu lösen. Anhand interner Rechenprozesse wurde die KI in die Lage versetzt, immer wieder aufs Neue Eintritts- und Erfolgswahrscheinlichkeiten auf Basis der eingespeisten Inputs zu prognostizieren. Die von Arvato Systems entwickelte Lektorats-KI „Manuscript Inside“ weist unterschiedliche Funktionalitäten auf, die den Lektor bei seiner täglichen Arbeit unterstützen (s. Abb. 3.10). Die Software erkennt eigenständig handelnde Akteure und Orte und kann die Relation zwischen diesen Entitäten grafisch darstellen. Darüber hinaus ist das System in der Lage, durch eine Sentiment-Analyse den Spannungsbogen des Manuskripts in grafischer Form darzustellen. Als Output generiert das System einen Prozentwert der Komplexität und es prognostiziert die Erfolgswahrscheinlichkeit des Manuskripts. Bei diesem Projekt von Arvato Systems handelt es sich um eine Zwischenstufe auf dem Weg zur vollständigen Digitalisierung der Arbeit von Verlagslektoren. Das Training des Systems kann noch nicht die Erfahrung eines menschlichen Lektors ersetzen, aber es kann die Arbeit des Lektors unterstützen. Im Zusammenspiel zwischen Menschen und Algorithmen entstehen sogenannte Zentauren-Teams.

Abb. 3.10   Demo-Showcase zur Lektorats-KI. (Quelle: Arvato Systems S4M GmbH)

82

3  Der Weg in die Null-Grenzkosten-Ökonomie

In der Öffentlichkeit wurden Zentauren-Teams durch ein inzwischen legendäres Schachduell bekannt. 1996 schlug erstmals ein Computersystem, Deep Blue von IBM, den damals amtierenden Weltmeister Garri Kasparow aus Russland. Heute sind digitale Schachalgorithmen so weit entwickelt, dass kein menschlicher Spieler mehr mit ihnen konkurrieren kann. Nach diesen ersten Erfolgen der Schachprogramme bildeten sich Zentauren-Teams, also Mannschaften, die ihre Entscheidungen in gemischten Teams aus Schachspielern und Computerprogrammen trafen. Diese Zentauren-Teams konnten eine ganze Zeit lang die rein algorithmisch basierten Programme besiegen. In eigens dafür angesetzten Turnieren setzten sich die Zentauren-Teams regelmäßig durch. Ende 2017 ging auch diese Entwicklung mit der Vorstellung des Schachalgorithmus Alpha Zero von Google zu Ende. Alpha Zero wurde nicht mehr auf Basis menschlicher Turniererfahrungen programmiert. Die Software brachte sich das Spiel durch die Technologie „Unsupervised Learning“ innerhalb von vier Stunden selbst bei. Diese neuen Algorithmen sind so spielstark, dass ein menschlicher Spieler keine Hilfe für das System mehr darstellt (Parsch 2018). Bezogen auf die Entwicklung der Null-Grenzkosten-Geschäftsmodelle liefert die Zusammenarbeit zwischen Mensch und Maschine wertvolle Hinweise: Da reale Arbeitsprozesse um vieles komplizierter als Schachspiele sind, werden Algorithmen auf absehbare Zeit die Menschen nicht von ihren Arbeitsplätzen verdrängen. Gleichzeitig werden viele Wertschöpfungsstufen Schritt für Schritt weiter digitalisiert. In der Zusammenarbeit zwischen Mensch und Maschine verändern sich die Aufgaben, die an die menschlichen Mitarbeiter gestellt werden: Viele einfache Prozessschritte werden an die Maschinen ausgelagert und damit bleibt den Mitarbeitern mehr Zeit, sich auf die komplexeren Aufgaben im Prozess zu konzentrieren, für die kognitive Leistungen notwendig sind. Damit sinken bereits mittelfristig die Grenzkosten der Produktion und des Vertriebs. Die Anwendung von KI im Arbeitsprozess – wie am Beispiel der Lektoratssoftware von Arvato Systems dargestellt – ist eine Möglichkeit, wie eine Branche sich in Richtung der Null-Grenzkosten-Geschäftsmodelle entwickeln kann. Kap. 4 zeigt, wie der Einsatz der Cloudtechnologie dazu beitragen wird, Null-Grenzkosten-Geschäftsmodelle in modernen Unternehmen umzusetzen.

Literatur Albrecht, Robert (2018): Fortnite hat jetzt 125 Millionen Spieler, erschienen in: mein-mmo.de,, https://mein-mmo.de/fortnite-125-millionen-spieler/, abgerufen im Januar 2019. Anker, Stefan (2013): Das Geheimnis der Gewinnspanne beim Autokauf, erschienen in: welt.de, https://www.welt.de/motor/article116695390/Das-Geheimnis-der-Gewinnspanne-beim-Autokauf.html, abgerufen im Januar 2019. Appleyard, Dennis, Alfred J. Field Jr. und Steven L. Cobb (2006): International Economics, McGraw-Hill, Boston. Baum, Heinz-Georg, Adolf Coenenberg und Thomas Günther (2013): Strategisches Controlling, Schäffer-Poeschel, Stuttgart.

Literatur

83

Beus, Johannes (2018): Nur 6,8 % aller Google-Klicks gehen auf AdWords-Anzeigen, erschienen in: sistrix.de, https://www.sistrix.de/news/nur-6-prozent-aller-google-klicks-gehen-auf-adwords-anzeigen/, abgerufen im Januar 2019. Brandt, Mathias (2016): Diese Messenger nutzen die Deutschen regelmäßig, Infografik, erschienen in: statista.de, https://de.statista.com/infografik/6344/diese-messenger-nutzen-die-deutschen/, abgerufen im Januar 2019. Bundesverband deutscher Banken (2018): Online Banking in Deutschland, erschienen in: bankenverband.de,  https://bankenverband.de/media/files/2018_06_19_Charts_OLB-final.pdf, abgerufen im Juni 2019. Clement, Reiner und Dirk Schreiber (2016): Internet-Ökonomie – Grundlagen und Fallbeispiele der vernetzten Wirtschaft, Springer Gabler, Berlin. Dreiskämper, Thomas (2018): Grundfragen der Medienbetriebslehre, De Gruyter Oldenbourg, Berlin. Gassmann, Oliver, Karolin Frankenberger und Michaela Csik (2013): Geschäftsmodelle entwickeln: 55 innovative Konzepte mit dem St. Galler Business Model Navigator, Carl Hanser Verlag, München. Graupner, Hardy (2019): Vor fünf Jahren: Facebook kauft WhatsApp, erschienen in: dw.com, https://www.dw.com/de/vor-fünf-jahren-facebook-kauft-whatsapp/a-47569526. Henderson, Bruce (1968, 1984): Die Erfahrungskurve in der Unternehmensstrategie, 2. überarbeitete Auflage, Campus, Frankfurt. Heuzeroth, Thomas (2011): Wie Google gegen seinen Stromhunger ankämpft, erschienen in: welt. de, https://www.welt.de/wirtschaft/article13437833/Wie-Google-gegen-seinen-Stromhunger-­ ankaempft.html, abgerufen im Juni 2019. Hinne, Carsten (2007): Mergers & Acquisitions Management – Bedeutung und Erfolgsbeitrag unternehmensinterner M&A Dienstleister, Gabler, Wiesbaden. Imaa (2018): Number & Value of M&A worldwide, https://imaa-institute.org/mergers-and-acquisitions-statistics/, abgerufen im Januar 2019. Isberto, Michael (2018): What is a Point of Presence, erschienen in: colocationamerica.com, https://www.colocationamerica.com/blog/point-of-presence, abgerufen im Juni 2019. Iskender, Dirik (2018): Deep Learning einfach gemacht, erschienen in: medium.com, https:// medium.com/@iskender/whitepaper-the-simple-guide-to-deeplearning-8229f87dbe66, abgerufen im Januar 2019. Jaskulla, Ekkehard M. (2015): Direct Banking im Cyberspace, erschienen in: Zeitschrift für Bankrecht und Bankwirtschaft, Band 8, Heft 3, Seiten 214–224. Mazzucato, Mariana (Hrsg.) (2002): Strategy for Business, Sage, London. McCarthy, John (2017): Instagram Ad Revenue to Double, erschienen in: thedrum.com, https:// www.thedrum.com/news/2017/12/17/instagram-ad-revenue-double-1087bn-2019-says-emarketer, abgerufen im Januar 2019. Meifert, Matthias (2016): Wie sich die Banken noch retten können, erschienen in: manager-magazin.de, https://www.manager-magazin.de/unternehmen/banken/wie-sich-die-banken-noch-ret­ ten-koennen-a-1106596.html, abgerufen im Juni 2019. Ostendorf, Sebastian (2017): Unersättlicher Hunger nach Strom: Warum der Datenverkehr im Internet so viel Energie verschlingt, erschienen in: stern.de, https://www.stern.de/digital/online/ google–wieviel-energie-verschlingt-eine-suchanfrage-8397770.html, abgerufen im Januar 2019. Panagiotis, Fotiadis und Michael Wegmer (2019): Deutsche zahlen erstmals mehr mit Karte, erschienen in: swrfernsehen.de, https://www.swrfernsehen.de/marktcheck/aktuell/Bargeld-­ vs,deutsche-zahlten-2018-erstmals-oefter-mit-karte-106.html, abgerufen im Juni 2019.

84

3  Der Weg in die Null-Grenzkosten-Ökonomie

Parsch, Stefan (2018): AlphaZero spielt Schach, Go und Shogi – und schlägt alle seine Vorgänger, erschienen in: welt.de, https://www.welt.de/wissenschaft/article185109198/Vergesst-AlphaGoder-neue-Held-heisst-AlphaZero.html, abgerufen im Januar 2019. Pöltzl, Norbert (2018): Geld aus der Wand holen – wie alles begann, erschienen in: spiegel.de, https://www.spiegel.de/einestages/1968-in-tuebingen-deutschlands-erster-geldautomat-a­1208937.html, abgerufen im Juni 2019. Porter, Michael Eugene (1986): Wettbewerbsvorteile (Competitive Advantage). Spitzenleistungen erreichen und behaupten, Campus, Frankfurt. Porter, Michael Eugene (1996, 2002): What is Strategy?, erschienen in: Mazzucato (2002), S. 10–32, Sage, London. Rüther, Robin (2018): Reich durch Fortnite, erschienen in: gamestar.de, https://www.gamestar. de/artikel/reich-durch-fortnite-epic-games-erwirtschaftet-2018-drei-milliarden-us-dollar-gewinn,3338773.html, abgerufen im Januar 2019. Schmidt, Herbie (2018): Die Detroit Auto Show will sich per Terminverlegung retten, erschienen in: nzz.ch, https://www.nzz.ch/mobilitaet/auto-mobil/der-detroit-auto-show-will-sich-per-terminverlegung-retten-ld.1369614, abgerufen im Januar 2019. Schmidt, Volker (2013): Die ersten Online-Gehversuche der Deutschen, erschienen in: zeit.de, https://www.zeit.de/digital/internet/2013-09/30-jahre-btx, abgerufen im Juni 2019. Seo-Summary (2018): Entwicklung der Marktanteile der beliebtesten Suchmaschinen in Deutschland, erschienen in: seo-summary.de, https://seo-summary.de/suchmaschinen/, abgerufen im Januar 2019. Soller, Gregor (2018): Bosch und Daimler starten automatisiertes Fahren in Kalifornien, erschienen in: vision-mobility.de, https://www.vision-mobility.de/de/news/bosch-und-daimlerstarten-automatisiertes-fahren-kalifornien-1882.html, abgerufen im Januar 2019. Sommer, Sarah (2018): Die Macht der Visionen, erschienen in: brandeins 12/18, S. 24–43, brandeins Medien, Hamburg. Stegen, Klaus-Peter (2017): Was verstehen wir unter KI?, erschienen in: boersenblatt.net, https:// www.boersenblatt.net/artikel-kuenstliche_intelligenz_____der_versuch_einer_aktuellen_einsortierung_der_moeglichkeiten_fuer_verlage_und_buchhandel.1363770.html, abgerufen im Januar 2019. Technikjournal (2018): Schreib-Maschinen: Voll im Trend, erschienen in: technikjournal.de, https:// technikjournal.de/2018/08/14/schreib-maschinen-voll-im-trend/, abgerufen im Juni 2019. VW (2018): Abschluss Volkswagen – Bilanz der Volkswagen AG zum 31. Dezember 2017, erschienen in: volkswagenag.com, https://www.volkswagenag.com/presence/investorrelation/ publications/annual-media-conference/2018/jahresabschluss/Abschlu%C3%9F_VWAG_2017_ de.pdf, abgerufen im Januar 2019. Weddeling, Britta (2018): Datenskandal kann Facebook nicht stoppen, erschienen in: handelsblatt. de, https://www.handelsblatt.com/unternehmen/it-medien/aktienkurs-legt-kraeftig-zu-datenskandal-kann-facebook-nicht-stoppen-gewinn-steigt-auf-fast-5-milliarden-dollar/21215764.html abgerufen im Januar 2019. Wirtz, Bernd W. (2012): Mergers & Acquisitions Management, Wiesbaden.

4

Cloud – Die automatisierte IT-Wertschöpfung

Zusammenfassung

Weltweit skalierende Null-Grenzkosten-Geschäftsmodelle führen Unternehmen im Zeitalter der Digitalisierung zum Erfolg. Um solche Geschäftsmodelle für das eigene Unternehmen aufbauen zu können, ist es wichtig, die Transformation der klassischen Informationstechnologie hin zur cloudbasierten IT zu verstehen. In den drei Kernprozessen der IT-Wertschöpfung – Software erstellen, betreiben und skalieren – ergeben sich durch neue Technologien massive Einsparungs- und Optimierungspotenziale. Während in der klassischen IT der Weg zur einsatzbereiten und skalierbaren Software abstimmungsintensiv, langwierig und mit hohen Investitionen verbunden ist, können cloudbasierte digitale Geschäftsmodelle deutlich schneller und risikoärmer entwickelt werden. Betrieb und Skalierung werden günstiger und orientieren sich an der tatsächlichen Nutzung einer beinahe unbegrenzt skalierbaren Infrastruktur.

4.1 It’s the software, stupid Den Präsidentschaftswahlkampf 1992 gewann Bill Clinton mit dem Slogan „It’s the economy, stupid“ (Kelly 1992). Damit meinte er: Nach der Invasion im Irak habe George H. W. Bush 1991 in der Bevölkerung zwar noch enorme Zustimmung gefunden – doch schlussendlich würde die Wirtschaftslage über die Wählergunst entscheiden. Und so kam es auch: Schon 12 Monate später war die Popularität des amtierenden US-Präsidenten so weit gesunken, dass Bill Clinton die Wahl gewann (Hart 2017). Eine ähnliche Botschaft lässt sich auch auf digitale Geschäftsmodelle anwenden: Eine gute Idee, eine erfolgreiche Werbekampagne oder eine im Moment attraktive Applikation reicht im digitalen Zeitalter nicht, um dauerhaft erfolgreich zu sein. Nur jene © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_4

85

86

4  Cloud – Die automatisierte IT-Wertschöpfung

Unternehmen überleben in der digitalen Welt, die Software schnell, zuverlässig und nutzerfreundlich erstellen, sie agil und kundenorientiert weiterentwickeln, sie günstig und zuverlässig betreiben und sie bei Bedarf schnell weltweit skalieren können. It’s the software, stupid! Software – mitunter auch Applikation, Anwendung, Programm oder App genannt – ist der Mittelpunkt jedes digitalen Geschäftsmodells. Software nimmt die Daten von Wetterstationen entgegen, berechnet die Wettermodelle und erstellt daraus Vorhersagen für jede Stadt. Software kombiniert diese Vorhersagen basierend auf den individuellen Nutzerdaten der Smartphone-Apps mit personalisierter Werbung. Digitale Assistenten wie Siri und Alexa sind Software, jedes Gerät im Internet der Dinge kommuniziert dank Software. Unternehmensanwendungen wie SAP und Salesforce sind Software, Handy-Apps sind Software, Internet-Seiten sind Software und auch die Künstliche Intelligenz ist nichts anderes als eine mit vielen Daten gefütterte Software. Wenn Software der Kern aller digitalen Geschäftsmodelle ist, liegen die Wettbewerbsvorteile für ein Unternehmen im Kontext der Digitalisierung auch in der Art und Weise, wie Software erstellt und eingesetzt wird.

4.2 Der klassische IT-Prozess Betriebswirtschaftlich betrachtet wird die IT-Wertschöpfung bei der Entwicklung und Anwendung von Software durch drei Kernprozesse bestimmt: 1. Software erstellen: Basierend auf einer Idee wird eine Applikation entwickelt, die den angestrebten Geschäftszweck erfüllt. 2. Software betreiben: Diese Applikation wird auf einer Hardware-Infrastruktur installiert und dort ohne Ausfälle funktionsfähig gehalten. 3. Software skalieren: Abhängig von der Nutzung der Applikation werden Ressourcen hinzugefügt oder abgebaut. Diese Kernprozesse verändern sich durch die Cloud-Technologie grundlegend und schaffen dadurch die Vorrausetzung, um Geschäftsprozesse und -modelle erfolgreicher zu digitalisieren. Um die Unterschiede zwischen klassischen und modernen IT-Wertschöpfungsketten hervorzuheben, wird in den nächsten drei Abschnitten zunächst der klassische IT-Prozess beschrieben. Danach wird aufgezeigt, wie sich dieser Prozess durch die Cloud verändert und welche die wichtigsten Merkmale einer cloudbasierten IT sind.

4.2.1 Software erstellen Der Weg von der Idee bis zu einem funktionierenden, software-basierten Geschäftsmodell ist nicht einfach. Auf diesem Weg treffen viele und häufig gegenläufige Interessen innerhalb eines Unternehmens aufeinander: Der Visionär und Ideengeber ­

4.2  Der klassische IT-Prozess

87

möchte ein neues, bisher unbekanntes Geschäftsmodell entwickeln. Der Finanzcontroller möchte niedrige Projekt- und Betriebskosten, zumindest aber die Sicherheit, dass das investierte Kapital auch wieder eingespielt wird. Der Vertriebsmitarbeiter möchte mit der Software möglichst viele Kunden gleichzeitig erreichen, der Kundenverantwortliche dagegen hat eher die speziellen Wünsche eines einzelnen Kunden im Blick. Der Software-Entwickler möchte die neuesten Entwicklungs-Tools nutzen, der Infrastruktur-Administrator möchte nur bekannte und erprobte Technologien verwenden. All diese unterschiedlichen Interessen müssen in dem gemeinsamen Prozess „Software erstellen“ unter einen Hut gebracht werden. Der Prozess „Software erstellen“ lässt sich in zwei Phasen unterteilen (s. Abb. 4.1): • Sondierung und Spezifizierung: In dieser Phase klären die Beteiligten miteinander ab, welche Funktionalitäten die Software enthalten soll. • Umsetzung und Test: Hier findet die eigentliche Entwicklung, das Programmieren und Testen der Software-Funktionen statt. Danach erfolgen die Prozessschritte „Betrieb“ und „Kundenbetreuung“. Sobald der sogenannte „Go-Live“ stattgefunden hat, wird die Software in ihrer aktuellen Form für den vorgesehenen Zweck eingesetzt und die bestehenden Kunden werden bei der Arbeit mit der Software betreut. In der letzten Phase des Prozesses treten in der Regel Änderungswünsche auf, und dadurch beginnt der Prozess der Sondierung und Spezifizierung erneut: Möchte das Unternehmen diese neuen Funktionen in die Software einfließen lassen, was kosten diese, wer bezahlt sie und wie genau sollen sie aussehen? Das bekannteste und wohl älteste Modell der Software-Entwicklung ist das sogenannte „Wasserfallmodell“ (Royce 1970). Streng linear werden zunächst die Anforderungen aufgenommen und in Form eines Lastenhefts fixiert. Auf diese Anforderungen antworten die Entwickler und Infrastruktur-Verantwortlichen mit einem Pflichtenheft und einer Kostenkalkulation, d. h. mit einem Vorschlag, wie die gewünschten Funktionen umgesetzt werden könnten. Wird das Pflichtenheft vom KunTypischer Zyklus für große, klassische Soware-Projekte: 6-24 Monate

Budgereigabe

Idee Nutzer Ideengeber Management

Kundenbetreuung

Sondierung & Spezifizierung

Soware-Entwickler

Umsetzung Betrieb

Infrastruktur-Verantwortliche

Änderungen

Abb. 4.1   Der Zyklus eines Software-Projekts

Go-Live

88

4  Cloud – Die automatisierte IT-Wertschöpfung

den akzeptiert, beginnt die Implementierung, also die Entwicklung der Software und der Aufbau der Infrastruktur, die für den Betrieb der Software notwendig ist. In den letzten Phasen der Entwicklung wird die Software getestet und schließlich an den Betrieb übergeben. Änderungen im Nachhinein sind nicht möglich bzw. lösen wieder die erste Kaskade des Wasserfalls aus. Das Wasserfallmodell ist intuitiv leicht verständlich und erscheint auch logisch, denn es ist an das Vorgehen beim Hausbau angelehnt: Ein Haus wird vom Architekten entworfen, die Baukosten werden kalkuliert und mit dem Bauherrn abgestimmt und dann werden die Pläne den Behörden vorgelegt. Erst danach werden die Handwerker und Materialien bestellt. Wenn der Rohbau fertig ist, wird das Dach aufgesetzt, und es werden die Fassade und der Innenausbau gemacht. Auch wenn die eigentliche Motivation des Bauherrn für ein eigenes Haus die große Wohnküche mit Blick auf die spielenden Kinder im Garten war, gibt es keinen realen Weg, das Bauprojekt zuerst mit der Wohnküche und dem Garten zu beginnen. Der klassische Prozess der Softwareerstellung weist also folgende kritischen Merkmale auf1: • Es dauert lange, bis große Applikationen erstellt sind. Aufgrund der langen Projektlaufzeiten sind die meisten Funktionalitäten zu diesem Zeitpunkt bereits veraltet. Und das bedeutet: Mit einem klassischen Prozess kann nicht flexibel auf die aktuellen Marktgegebenheiten reagiert werden. • Auf dem Weg von der Idee bis zur ersten Nutzung durch den Kunden sind innerhalb eines Unternehmens viele verschiedene Akteure beteiligt. Der Aufwand, der direkt mit der Geschäftsidee und deren Erstellung zu tun hat, ist im Verhältnis zu den planerischen und steuernden Aufgaben relativ gering. • Durch eine intensive und detaillierte Vorausplanung aller Angelegenheiten rund um das Geschäftsmodell soll Investitionssicherheit geschaffen werden.

4.2.2 Software betreiben Sobald die Software erstellt ist und vom Kunden abgenommen wurde, wird sie im internen oder externen Rechenzentrum bei einem Provider installiert und für die Nutzer verfügbar gemacht. Neben der physischen Hardware wie Netzwerkkabel, Speicherplatte und Rechner, werden weitere Komponenten wie Betriebssysteme und Datenbanken benötigt. Da die Software nur dann zuverlässig verfügbar ist, wenn gleichzeitig alle anderen Komponenten funktionieren, ergeben sich für den Software-Betrieb einige Herausforderungen.

1Welche Herausforderungen bei der Herstellung von Software zu meistern sind, wird in Kap. 6 noch einmal detailliert betrachtet.

4.2  Der klassische IT-Prozess

89

Ungleichmäßige Auslastung Eines der Ziele der klassischen IT ist es, dass jede Komponente so konstant wie möglich läuft. Die Kennzahl dafür ist das sogenannte Service Level Agreement (SLA): Dadurch wird beschrieben, wie hoch die Verfügbarkeit eines bestimmten Services ist (Hiles 2016). Eine Verfügbarkeit von 99,9 % bedeutet zum Beispiel, dass es bei 365 Tagen pro Jahr und 24 h pro Tag eine jährliche ungeplante Ausfallzeit von ca. neun Stunden gibt. Bei zehn Komponenten, die gleichzeitig laufen und jeweils zu 99,9 % verfügbar sind, verringert sich die Verfügbarkeit auf etwa 99,0045 %2, was im Detail drei Tage, 15 h und 10 min pro Jahr Ausfallzeit bedeutet. Um ungeplante Ausfälle zu reduzieren, gibt es sogenannte Wartungsfenster: In diesen Zeiträumen werden die Komponenten kontrolliert heruntergefahren und überprüft. Wartungsfenster werden daher außerhalb der üblichen Geschäftszeiten angesetzt und gelten im Sinne der SLAs nicht als Ausfallzeit. Die Herausforderungen des klassischen IT-Betriebs sind nicht zu unterschätzen: Jede Komponente benötigt spezielle Ressourcen, bevor sie installiert werden kann, jede dieser Ressourcen kann ausfallen oder sich durch Updates in ihren Eigenschaften verändern. Aus Sicherheitsgründen werden die Komponenten immer wieder aktualisiert oder mit sogenannten Patches (Korrekturen) versehen, die sich wiederum auf nachfolgende Komponenten auswirken können. Wenn Software bei Kunden bereits mehrere Jahre im Einsatz ist, werden teilweise veraltete Versionen von Komponenten benötigt, die parallel zu den aktuellen Komponenten weitergepflegt werden müssen. Tendenziell verursacht der klassische IT-Betrieb also hohe Kosten. Data Center versuchen, die Anzahl der Komponenten sowie der parallel betriebenen Varianten von Komponenten zu reduzieren. Mit dieser Standardisierung sollen Aufwände gespart und die Kosten des IT-Betriebs reduziert werden. Für die Applikationsverantwortlichen bedeutet eine geringere Auswahl an Komponenten und deren Varianten, dass sie möglicherweise ihre Applikation anpassen müssen. Für sie entstehen also wieder Zusatzaufwände und Projektrisiken. Abb. 4.2 stellt beispielhaft Abhängigkeiten zwischen den Komponenten in der IT-Wertschöpfung dar. Da jede der Komponenten potenziell von separaten Teams mit möglicherweise konfliktierenden Zielen betreut wird, entstehen zusätzlich zu den komplizierten technischen Abhängigkeiten auch noch komplexe soziale Dynamiken. Die Bandbreite existierender Rollen im Umfeld von Rechenzentren ist groß. Walter Abel kommt in seinem Glossar allein auf 60 verschiedene Aufgabenstellungen (Abel 2011) – vom Process Manager und Transition Manager bis zum Change Advisory Board, dem Compliance Manager und dem Knowledge Manager. Auch wenn diese

2Die

Formel zur Berechnung dieses Werts lautet: Verfügbarkeit [%] ^ Anzahl der Komponenten.

90

4  Cloud – Die automatisierte IT-Wertschöpfung

Geschäsmodell

IT-Wertschöpfungskee

Soware Integra„on

Datenbank 2 Betriebssystem 1 Server 2

…

Libraries

Server 1

Datenbank 1 Betriebssystem 2

Loadbalancer

Run„mes

Server 4

Server 3 Network

Storage

Abb. 4.2   Geflecht von bekannten und unbekannten Abhängigkeiten in der IT-Wertschöpfungskette

nicht in jedem Anwendungsfall benötigt und teilweise mehrere Rollen in Personalunion ausgeführt werden, ist dies ein klares Indiz für die Größe der menschlichen Steuerungsherausforderungen. Aus der strategischen Sicht des Betriebswirts ist die Botschaft einfach: Im klassischen IT-Betrieb besteht die Aufgabe der vielen Beteiligten darin, die installierte Software am Laufen zu halten und die übergreifende Funktionsfähigkeit des Systems zu garantieren. Für jede Komponente gibt es Spezialisten, die versuchen, die Software möglichst ausfallfrei, kostenoptimiert und sicher zu betreiben. Das spiegelt sich im Arbeitsalltag dieser Spezialisten wider: Sie arbeiten teilweise in Schichten, um einen 24-Stunden-Betrieb zu gewährleisten. • Wartungs- und Migrationstätigkeiten werden gebündelt außerhalb der normalen Geschäftszeiten angesetzt, damit der Kunde die Applikation ständig nutzen kann. • Fällt eine Komponente ungeplant aus oder gibt es Sicherheitsprobleme, kommt es zu Sonderschichten. • Der Betrieb eines Rechenzentrums orientiert sich also nicht an der optimalen Auslastung der Mitarbeiter, sondern an der Verfügbarkeit der Services. Für Lastspitzen werden viele und teure Spezialistenrollen vorgehalten und zusätzlich ist die Vorhaltung von Personal notwendig, das für die Koordination der Einzelteile, die Bestellung und Abrechnung verantwortlich ist.

4.2  Der klassische IT-Prozess

91

Teure Hardware-Ressourcen Der möglichst reibungslose Betrieb von Software in einem Rechenzentrum ist auch eine Frage des sogenannten „Sizings“, also des Anpassens der On-Premises-Systeme an die Anforderungen, die an sie gestellt werden. Als „On-Premise“ wird die Nutzung von Software-Komponenten auf den lokalen Servern eines Unternehmens bezeichnet. In der Regel werden diese Serveranlagen in den Räumlichkeiten des Unternehmens betrieben und von den eigenen IT-Mitarbeitern betreut. Damit grenzt sich der Begriff On-Premise (oder kurz: OnPrem) von den in diesem Buch vorgestellten Public-Cloud-Anwendungsszenarien ab (Fisher 2018). Einen durchschnittlichen Auftraggeber einer Data-Center-Leistung kann die Frage „Wie leistungsstark sollen die Rechner sein, welche und wie viele brauchen Sie genau?“ durchaus überfordern. Mitarbeiter aus dem Marketing oder dem Fachbereich hatten vielleicht die fachliche Idee für eine Applikation, sie kennen sich zum Beispiel mit Versicherungsvergleichen oder Energiedaten-Management aus. Doch in den meisten Fällen haben sie weder die Erfahrung mit noch das Wissen zu Applikations-Servern, Datenbank-Servern, Front-End und Back-End-Servern, zu Speichertechnologien oder Netzwerken. Davon abgesehen haben diese Entscheidungen eine große finanzielle Tragweite. Ein Server kann 50, 1500 EUR oder mehr pro Monat kosten. Bei jeder Komponente gibt es große finanzielle Bandbreiten, viele Abhängigkeiten und zusätzliche Optionen wie Hochverfügbarkeit (besonders hohe Ausfallsicherheit) oder Georedundanz (Verteilung der Applikation auf mehrere, örtlich unabhängige Rechenzentren). Mit etwas Ausprobieren gelingt das Sizing meistens gut, da sich die Infrastruktur-Ressourcen an den erfahrungsgemäß erwarteten Bedarfen orientieren. Wird beispielsweise eine Applikation betrieben, deren Hauptlast immer am „Cyber Monday“ anfällt (Weidemann 2018), werden Ressourcen vorgehalten, von denen die IT-Verantwortlichen annehmen, dass sie dem erwarteten Nutzeransturm auch standhalten werden. Ein Nachteil dieses klassischen Sizing-Ansatzes ist, dass zu viele Infrastruktur-Ressourcen vorgehaltenen werden – dadurch fällt die durchschnittliche Auslastung deutlich unter den Maximalwert (s. Abb. 4.3). Das bedeutet, dass ein Großteil der Kapazität des Systems das ganze Jahr über nicht genutzt wird. Umgekehrt ist es für Kunden und Nutzer nicht akzeptabel, wenn sich die Ressourcen am Durchschnittswert orientieren. Dieses Vorgehen hätte nämlich zur Folge, dass gerade an den nachfragestärksten Tagen im Jahr das System ausfällt oder langsamer wird. Das Unternehmen, das die Applikation auf klassische Art und Weise im Rechenzentrum betreibt, hat daher kaum eine andere Wahl, als ein hohes monatliches Fixum für ihre Infrastruktur-Ressourcen zu bezahlen, auch wenn diese durch das digitale Geschäftsmodell gar nicht genutzt werden und demnach auch keinen Nutzen stiften. Das Zwischenfazit lautet daher: Die Kosten der klassischen IT orientieren sich im klassischen IT-Betrieb nicht an der realen Nutzung der digitalen Geschäftsmodelle. Viele Infrastruktur-Ressourcen werden verfügbar gehalten und unabhängig von ihrem Nutzen für den Kunden bezahlt. Auch die hohe Anzahl an Personen, die sich um Updates, Sicherheit und interne Kommunikation kümmern, erzeugt fixe Kosten – unabhängig davon, ob

92

4  Cloud – Die automatisierte IT-Wertschöpfung

Cyber Monday

Maximale Auslastung

Page Visits

Zu viel vorgehaltene Ressourcen Durchschniliche Auslastung

1. Quartal

2. Quartal

3. Quartal

4. Quartal

Abb. 4.3   Unregelmäßige Auslastungskurve einer Applikation

die bereitgestellte digitale Leistung überhaupt am Markt nachgefragt wird. Die beiden wichtigsten weiteren – meist fixen – Kostenkomponenten im klassischen Rechenzentrum fallen für Strom und für die Lizenzen der Betriebssoftware an. Auf den Punkt gebracht lässt sich als wichtiges Merkmal der klassischen IT festhalten: Ein Großteil der Kosten entsteht nicht aufgrund der tatsächlichen Nutzung.

4.2.3 Software skalieren Ist die Software erstellt und wird sie erfolgreich betrieben, lautet das Motto fälschlicherweise oft „Never change a running system“ (Kaczenski 2010). In der Praxis funktioniert das selten, schließlich brauchen alle Komponenten ihre Fehlerbehebungen („Bugfixes“) und Sicherheitsupdates, die Hardware muss alle drei Jahre ausgetauscht werden und regelmäßig gibt es neue Software-Versionen mit neuen Anforderungen. Oder das digitale Geschäftsmodell ist erfolgreich und braucht mehr Ressourcen in Kombination mit optimierten Komponenten. Wie sieht in diesem Fall der Prozess der Software-Skalierung in der Realität klassischer Rechenzentren aus? Die Information Technology Infrastructure Library (ITIL) vereinigt die Beschreibungen der wichtigsten IT-Steuerungsprozesse, die in der Erstellung, dem Betrieb und der Skalierung von Software eine Rolle spielen (Kurzlechner 2019). Bei der Software-Skalierung handelt es sich nach der ITIL-Terminologie handelt um einen „Change“-Prozess: Ziel dieses

4.3  Der Stack – Die IT und ihre Wertschöpfungskette

93

Prozesses ist es, Änderungen an der IT-Infrastruktur risikoarm zu steuern. Änderungsanträge sollen daher bewertet, genehmigt und dokumentiert werden und die Änderungen selbst sollen geplant und kontrolliert durchgeführt werden. Für jede Änderung müssen die vielen Abhängigkeiten und Zusammenhänge im IT-Betrieb individuell berücksichtigt werden, denn es sind „viele andere Prozesse mittelbar und unmittelbar involviert“ (Olbrich 2004, S. 51). Dazu gehören etwa die Auswirkungen auf Service Level Agreements und die Sicherheit, auf Kapazitätsplanungen, Release-Stände, Kostenstrukturen, Reports, Statusinformationen für Kunden und vieles mehr. Zwar soll in erster Linie das Risiko für den Betrieb der Applikation minimiert werden, doch die gesamte IT-Landschaft des Unternehmens muss im Auge behalten werden. Schließlich können schlecht koordinierte Änderungen zu teuren Störungen und Ausfällen führen. Daher sind auch hier wieder viele verschiedene Akteure involviert: Change Manager, Change Advisory Board, Configuration Manager, Knowledge Manager, Projekt-Manager, Release-Manager, Test-Manager. Alleine diese Aufzählung gibt eine Vorstellung davon, wie aufwendig, zeitintensiv und teuer so ein Change werden kann. Bleibt der Erfolg der Applikation nach der durchgeführten Anpassung hinter den Erwartungen zurück, tritt der umgekehrte Fall ein: In diesem Fall wird IT-Infrastruktur vom Unternehmen vorgehalten, ohne dass sie zum Einsatz kommt. Auch wenn einige Arten von Change-Prozessen grundsätzlich schnell und unkompliziert durchführbar sind, ist davon auszugehen, dass es sich in klassischen Rechenzentren nicht lohnt, beispielsweise für den Cyber Monday (s. Abb. 4.3) Infrastruktur aufzubauen, nur um sie wenige Tage später wieder abzubauen und gebraucht zu verkaufen. Noch herausfordernder wird es, wenn ein Unternehmen mit seinem digitalen Angebot einen globalen Hype ausgelöst hat. Innerhalb eines Monats stieg zum Beispiel die Zahl der Nutzer des Smartphone- und Tablet-Spiels Pokémon Go von wenigen Tausend im Juni 2016 auf fast 30 Mio. weltweit Ende Juli 2016 (Siegman 2017). Im Herbst des gleichen Jahres stabilisierten sich die Zahlen bei etwa 7,5 Milo. Nutzern. Wie kann die IT-Abteilung mit vielen Mitarbeitern und aufwendig zu beschaffender Hardware einen globalen Ansturm binnen weniger Tage erfolgreich und ohne Kapazitätsengpässe managen? Würden die gleichen Mitarbeiter zwei Monate später die Rechner wieder abbauen und gebraucht auf einem Internet-Marktplatz verkaufen? Solche anspruchsvollen Skalierungsszenarien sind unter den Voraussetzungen der klassischen IT so gut wie undenkbar.

4.3 Der Stack – Die IT und ihre Wertschöpfungskette Der IT-Stack gibt eine Übersicht über die unterschiedlichen technologischen Ebenen, die für den Betrieb eines digitalen Geschäftsmodells bzw. einer digitalen Applikation erforderlich sind. Im Folgenden (s. Abb. 4.4) wird der sogenannte IT-Stack vorgestellt und nach betriebswirtschaftlichen Maßstäben bewertet.

94 Abb. 4.4   Die IT-Wertschöpfungskette (Stack)

4  Cloud – Die automatisierte IT-Wertschöpfung

Geschäsmodell Anwendung Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher Netzwerk

4.3.1 Die Ebenen des Stacks Der IT-Stack ist unterhalb der Software-Applikation in acht Ebenen eingeteilt (s. Abb. 4.4) Die unterste Stufe des Stacks wird vom Netzwerk (Network) gebildet: Diese Ebene des Stacks ermöglicht es der Software, Informationen und Daten mit anderen Rechnern auszutauschen. Die nächste Ebene bildet der Speicher (Storage), in dem die anfallenden Daten der Applikation, aber auch des Betriebssystems gespeichert werden. Die Rechner (auch Compute oder Server genannt) stehen auf der nächsten Ebene. Die Rechner auf dieser Ebene ähneln den üblichen Desktop-PCs: Je mehr Central Processing Units (CPUs) und Arbeitsspeicher ein Rechner hat, desto schneller arbeitet er. In klassischen Rechenzentren werden die Rechner allerdings nicht direkt an einen Kunden verkauft oder vermietet. Stattdessen wird auf einer ganzen Reihe solcher Rechner eine Virtualisierungsumgebung installiert, die aus einer Anzahl physischer Server eine noch größere Anzahl von virtuellen Servern erzeugt. Dem Kunden werden somit vCPUs (virtuelle CPUs) auf virtuellen Maschinen (VMs) verkauft. Diese Entkoppelung des physischen Rechners von der tatsächlich genutzten virtuellen Maschine wird als Virtualisierung bezeichnet und bietet sowohl dem Anbieter als auch dem Kunden viele Vorteile (Wiehr 2015). Neben der Tatsache, dass Platz und Energie gespart werden, sind vor allem die sinkenden Kosten und die erhöhte Verfügbarkeit ein Argument für die Virtualisierung der Ebene der Rechenleistung.

4.3  Der Stack – Die IT und ihre Wertschöpfungskette

95

Die nächste Ebene des Stacks bildet das Betriebssystem (OS oder Operating System). Die bekanntesten Betriebssysteme weltweit sind Linux und Windows. Beide bieten ein großes Portfolio an Varianten, die im Detail jeweils eigene Anforderungen für die Betreiber von Rechenzentren mit sich bringen (z. B. Wartungszeiträume, Kompatibilität, Kosten, Systemanforderungen). Auf der Ebene der Datenbanken ist eine effiziente, widerspruchsfreie und dauerhafte Speicherung großer Datenmengen das Ziel (Lackes et al. 2018). Die bekanntesten Anbieter von relationalen Datenbanken sind Oracle DB, Microsoft SQL und IBM DB2. Darüber hinaus gibt es viele weitere Datenbanken mit jeweils unterschiedlichen Profilen: Einige sind besonders günstig, andere besonders schnell, manche wiederum besonders skalierbar oder flexibel, was die Datenformate betrifft. Auf der Ebene der Runtimes (Laufzeitumgebungen, ITWissen 2014) werden gewisse Programmierschnittstellen und Grundfunktionen standardisiert zur Verfügung gestellt. Das sorgt dafür, dass die Anwendung unabhängig vom verwendeten Peripheriegerät ausgeführt werden kann. Eine bekannte Runtime ist Java3 oder auch „JRE – Java Runtime Environment“ (Tyson 2018). Auf derselben Ebene finden sich auch sogenannte Software-Bibliotheken („Libraries“) (Metzger 2001). Diese Bibliotheken bestehen aus Hilfsprogrammen, die zwar nicht eigenständig lauffähig sind, dem Programmierer aber mit vorgefertigten Funktionen die Arbeit erleichtern. Ein Beispiel hierfür sind die Toolkits für grafische Benutzeroberflächen (GUI). Diese Toolkits stellen standardisierte Grafikelemente zur Verfügung, wie etwa Auswahlfenster, Buttons, Pfeile, Schieberegler etc. Die Einheitlichkeit der Angebote in den Libraries ist auch der Grund, warum sich die meisten Programme auf Windows optisch sehr ähneln. Als oberste Ebene dient der Security & Integration Layer dazu, die Applikation vor unberechtigten Zugriffen zu schützen. Ein bekannter Service in dieser Ebene ist das Identitätsmanagement „Active Directory“ von Microsoft (Barghava 2017). Richtig eingesetzt sorgt er dafür, dass nur berechtigte Nutzer auf die Applikation zugreifen können. Auf allen diesen Ebenen setzt schlussendlich die Software mit der eigentlichen Logik des Geschäftsmodells auf – meist Anwendung, Programm oder Applikation genannt.

4.3.2 Variantenvielfalt der Komponenten erzeugt zahlreiche Abhängigkeiten Auf den ersten Blick wirken die gestapelten Ebenen des Stacks überschaubar. Tatsächlich aber gibt es innerhalb jeder Ebene eine Vielzahl von Alternativen, die jeweils unterschiedliche Varianten mitbringen, die von der Applikation in unterschiedlichen 3Ab

und an rufen sich fehlende Runtimes auch dem Endnutzer einer Software in Erinnerung: Bis 2013 musste vor der Installation des Steuererklärungsprogramms „Elster“ noch die Java Runtime installiert werden.

96

4  Cloud – Die automatisierte IT-Wertschöpfung

Versionsständen angefragt werden. Eine Datenbank kann etwa eine relationale oder eine hierarchische Datenbank sein. Eine der relationalen Datenbanken wird von Microsoft (MS SQL) angeboten, es gibt sie aber auch als Open-Source-Variante (MySQL). MySQL wird seit 2003 verwendet, inzwischen gibt es Versionen von MySQL 4.0 bis MySQL 5.7. Um reibungsfrei zu funktionieren, kann jede Variante spezifische Anforderungen an die darunterliegenden Ebenen des Stacks (Network, Storage, Rechner, Betriebssystem) mitbringen. Jede Variante stellt möglicherweise auch spezifische Anforderungen an die darüberliegenden Ebenen wie Runtimes, Security & Integration sowie an die Applikation. Das zeigt exemplarisch, wie komplex die Abhängigkeiten sind, die durch das Service Management zu steuern sind. Wie wird diese komplexe Wertschöpfung organisiert? Meist wird für jedes Spezialgebiet (z. B. Linux Server, Oracle DB, Netzwerk) das benötigte Expertenwissen in kleinen spezialisierten Teams gebündelt. Diese kümmern sich um Sicherheit, Verfügbarkeit und Kosten ihrer jeweiligen Spezialservices. Die teamübergreifenden Aufgaben werden durch steuernde Rollen wie das „Service Delivery Management“ koordiniert oder durch Workflow-Tools automatisiert. Die Prozessabläufe werden dennoch meist per Hand definiert oder zumindest beeinflusst. Besonders aufwendig ist in der Regel die Klärung der Kundenanforderungen und deren Übersetzung in Formate, die von den Tools verstanden werden. Dieser streng arbeitsteilige Aufbau von IT-Organisationen erinnert an den Taylorismus (Gaugler 2002), bei dem jeder Mitarbeiter exakt für einen vorgeschriebenen Handgriff im Prozess verantwortlich ist. Wenn Änderungen vorgenommen werden müssen, sind viele kleine Teilaufgaben zu erledigen. Die Anzahl der benötigten Arbeitsstunden ist häufig gar nicht hoch. Da die Aufgaben aber auf viele unterschiedliche Teams verteilt sind, die jeweils ihre eigene optimierte Terminplanung haben, steigt der Koordinationsaufwand – das kann die Durchlaufzeit einer Änderung einer Software-Applikation signifikant erhöhen.

4.4 Die Cloud-Transformation in der IT Die in Abschn. 4.2 und 4.3 dargestellten klassischen Ansätze, IT-Leistungen in Unternehmen zu erbringen und Software zu betreiben, besitzen Schwächen, die Ihnen nicht entgangen sein dürften: Sie sind zeitraubend, kostspielig und arbeitsintensiv. Damit sind diese Ansätze kaum mit den Anforderungen vereinbar, die digitale Geschäftsmodelle an die IT eines Unternehmens stellen. Um zu verstehen, warum „die Cloud“ ein Ausweg aus diesem Dilemma bietet, wird in den nächsten Abschnitten beschrieben, was die Cloud ist, wie sie funktioniert und wie ein cloudbasierter IT-Prozess aussieht.

4.4.1 Die Cloud als Trendbegriff Welche Bedeutung das Thema „Cloud Computing“ innerhalb kurzer Zeit gewonnen hat, lässt sich mit Hilfe von Google Trends nachvollziehen (s. Abb. 4.5). 2007, etwa ein Jahr

Abb. 4.5   Interesse am Suchbegriff „Cloud“ im zeitlichen Verlauf seit 2004 laut Google Trends

Interesse am Thema „Cloud Compung“ im zeitlichen Verlauf

Quelle: hps://www.google.com/trends

4.4  Die Cloud-Transformation in der IT 97

98

4  Cloud – Die automatisierte IT-Wertschöpfung

nach dem Marktstart des Cloud-Pioniers AWS (Rojas 2017), wuchs das Interesse rasant. Und dieses Wachstum hält bis heute an. Der Begriff „Cloud“ wurde ab 2010 von immer mehr Unternehmen aufgegriffen, um neue Services anzubieten: • Die Deutsche Telekom spricht seit 2011 von der TelekomCLOUD oder später der MagentaCLOUD (Deutsche Telekom 2019) als „kostenlosem Cloud-Speicher“. • Microsoft bietet seit 2010 die „Azure Cloud Platform“ für die Zielgruppe der Software-Entwickler an (Luber und Karlstätter 2017a). • Salesforce spricht von der „Marketing Cloud“ als Plattform für „intelligente Customer Journeys“ (Salesforce 2019). Zahlreiche weitere Unternehmen setzen auf das Zukunftsthema Cloud: Es gibt eine Creative Cloud, eine für die Energiewirtschaft (Powercloud), es gibt eine Media Cloud (Mediacloud), eine Commerce Cloud (SAP 2019), IBM hat die eigene Applikation „Watson“ in die Cloud gebracht (IBM 2019). Google spricht von „Cloud AI“ und meint damit künstliche Intelligenz in der Cloud (Google 2019). Die Liste ließe sich noch um zahlreiche Beispiele fortsetzen. Was ist also diese Cloud und warum ist sie für Unternehmen aus unternehmerischer Perspektive so interessant? Diese Frage wird in den folgenden Abschnitten beantwortet.

4.4.2 Was ist die Cloud? Die Definition des Begriffes „Cloud“ nach Fehling und Leymann lautet: Cloud Computing beinhaltet Technologien und Geschäftsmodelle, um IT-Ressourcen dynamisch zur Verfügung zu stellen und ihre Nutzung nach flexiblen Bezahlmodellen abzurechnen. Anstelle IT-Ressourcen, beispielsweise Server oder Anwendungen, in unternehmenseigenen Rechenzentren zu betreiben, sind diese bedarfsorientiert und flexibel in Form eines dienstleistungsbasierten Geschäftsmodells über das Internet oder ein Intranet verfügbar. Diese Art der Bereitstellung führt zu einer Industrialisierung von IT-Ressourcen, ähnlich wie es bei der Bereitstellung von Elektrizität der Fall war. Firmen können durch den Einsatz von Cloud Computing langfristige Investitionsausgaben (CAPEX) für den Nutzen von Informationstechnologie (IT) vermindern, da für IT-Ressourcen, die von einer Cloud bereitgestellt werden, oft hauptsächlich operationale Kosten (OPEX) anfallen. (Fehling und Leymann 2018)

Das National Institute of Standards and Technology (NIST) hat fünf Kriterien für Cloud Computing definiert (Mell und Grance 2011): • On-demand self-service: Die Leistungen müssen durch den Nutzer ohne Mittelsmann nutzbar sein. Endkunden erledigen dies in der Regel über eine grafische

4.4  Die Cloud-Transformation in der IT

• • • •

99

Benutzeroberfläche (Graphical User Interface – GUI) und Software-Entwickler über eine Programmier-Schnittstelle (Application Programming Interface – API). Broad Network Access: Die Leistungen müssen über bekannte Standardmechanismen allgemein verfügbar sein. Resource Pooling: Im Hintergrund werden die IT-Ressourcen zwischen verschiedenen Projekten und Kunden geteilt. Rapid Elasticity: Die Ressourcen können je nach Bedarf automatisch und im Grunde unbegrenzt hoch- und heruntergefahren werden. Measured Service: Die tatsächliche Nutzung der Ressourcen wird gemessen und dient in der Regel als Grundlage für die Abrechnung.

Vor dem Hintergrund dieser Definitionen lässt sich das Cloud Computing aus einer betriebswirtschaftlichen Perspektive folgendermaßen definieren:   Cloud Computing ist die Automatisierung der IT-Wertschöpfung. Die Cloud bietet ein breites Portfolio an IT-Leistungen, das ohne menschliches Zutun über eine Programmierschnittstelle (API) oder grafische Nutzeroberfläche (GUI) genutzt werden kann. Dieses Angebot ist faktisch unbegrenzt und kann in beliebig kleinen und großen Mengen geliefert und nach der tatsächlich genutzten Menge abgerechnet werden. Daraus ergibt sich der Vorteil der Cloud-Nutzung: Unternehmen, die auf diese Dienste zugreifen, können in immer stärkerem Maße ihre IT-Prozesse automatisieren. Automatisierung bedeutet in diesem Zusammenhang, dass bei der spezifischen Nutzung der Leistung keine menschlichen Tätigkeiten mehr notwendig sind. Die Cloud löst dadurch einen alten Widerspruch auf, der noch aus dem Industriezeitalter stammt. Henry Ford stimmte im Jahr 1909 seine Vertriebsmitarbeiter mit den folgenden Worten ein (Hart 2015): „Any customer can have a car painted in any colour that he wants so long as it is black.“ Er stellte damit die Produktionsvorteile, die durch die Standardisierung der Leistung bei hohen produzierten Mengen entstehen, über die Individualisierungswünsche seiner Kundschaft. Das war aus der Perspektive der damaligen Zeit und mit den zur Verfügung stehenden technologischen und organisatorischen Möglichkeiten durchaus pragmatisch gedacht. Über 100 Jahre später vermag es nun die Cloud, beide Ansprüche zu vereinen und damit das zur Zeit der Massenindustrialisierung vorherrschende Paradigma zu durchbrechen: Unter den Bedingungen einer cloudbasierten IT-Wertschöpfung ist es möglich, sowohl automatisierte Standardleistungen herzustellen als auch beliebig kleine und große Mengen dieser Leistungen in individuellen Kombinationen zu liefern und abzurechnen. Die folgenden Eigenschaften der Cloud sind für Unternehmen besonders relevant:

100

4  Cloud – Die automatisierte IT-Wertschöpfung

• Viele IT-Fertigteile: Unternehmen können unkompliziert Komponenten ihrer IT-Wertschöpfung aus der Cloud beziehen. • Mikrotransaktionen: Diese Komponenten sind in kleinen bis sehr kleinen Einheiten konsumierbar. • Globale Skalierung: Bei Bedarf können diese IT-Komponenten global zur Verfügung gestellt werden. • Nutzungsbasierte Abrechnung: Alle IT-Komponenten können nutzungsbasiert abgerechnet werden. Auf diese Weise sind Geschäftsmodelle möglich, die Kosten nur dann erzeugen, wenn die genutzte IT auch unternehmerischen Nutzen erbringt. Wie also passen die in Abschn. 4.4.1 genannten Cloud-Beispiele zur wirtschaftlichen Definition? • Die Telekom spricht vom „kostenlosen Cloud-Speicher“. Gemeint ist damit ein Service, über den Fotos, Videos und Musik online gespeichert werden können und der über eine grafische Benutzeroberfläche nutzbar ist. Die Telekom hat somit die IT-Wertschöpfung rund um die Nutzung der Cloud-Datenspeicher automatisiert. • Microsoft bietet mit der „Azure Cloud Platform“ ein breites Portfolio an Komponenten aus dem gesamten Stack an (Abschn. 4.3.1), die über eine Programmierschnittstelle von Software-Entwicklern nutzbar sind. Die IT-Wertschöpfung hinter jeder dieser Komponenten ist jeweils vollständig automatisiert und weltweit skalierbar. • Salesforce hat sich auf Sales-Prozesse fokussiert und bietet hierfür vorgefertigte IT-Prozesse und Applikationen. Auch hier ist die Wertschöpfung hinter der Nutzeroberfläche komplett automatisiert. Zusammengefasst automatisiert die Cloud also die bisher von vielen Personen ausgeführten Aufgaben in der IT-Wertschöpfungskette. Sie erzeugt diese Automatisierung, ohne dass die Möglichkeit der Individualisierung für das Geschäftsmodell verloren geht und bringt Unternehmen Vorteile hinsichtlich nutzbarer Fertigteile, Mikrotransaktionen, globaler Skalierung und nutzungsbasierter Abrechnung. Die Cloud verhält sich damit zur klassischen IT wie die Zustellung einer E-Mail zu der eines Briefs: Von der Bestellung bis zur Lieferung und Abrechnung eines cloudbasierten Services ist kein einzelner Handgriff eines Menschen mehr notwendig.

4.4.3 Die API als Game Changer Der Begriff „Game Changer“ kommt aus dem Sport. Er wird verwendet, wenn eine scheinbar kleine Veränderung eine große Wirkung auf das gesamte Spiel hat. Das kann etwa ein frisch eingewechselter Spieler sein, der Kraft seines Spielverständnisses oder seiner Sturmqualitäten einen Rückstand aufholt oder ein vom Trainer taktisch eingesetztes „Time Out“, das den aktuellen Spielfluss unterbricht. Auch Regeländerungen

4.4  Die Cloud-Transformation in der IT

101

können Spiele beeinflussen. Ein eindrucksvolles Beispiel ist die Einführung der 3-Punkte-Regel im Basketball (Mather 2016). Bis 1979 zählten noch alle Feldwürfe zwei Punkte, was zu einer Dominanz sehr großer Spieler und einer Zentrierung des Spiels in der Nähe des Korbes führte. Durch die Einführung der 3-Punkte-Linie veränderte sich das Spiel: Verhältnismäßig kleine Spieler wie Stephen Curry (1,91 m) spielen jetzt mit ihren Distanzwürfen eine viel größere Rolle (Haberstroh 2016). Warum ist das Cloud Computing der Game Changer in der IT-Industrie? Die Antwort lautet: Weil die digitalen Dienstleistungen, die in der Cloud verfügbar sind, über ein simples Application Programming Interface (API) abrufbar sind (Luber und Augsten 2017). Das Prinzip: Applikationen können über APIs Anfragen stellen und erhalten exakt die Antworten, die sie für den Betrieb der Software benötigen. Über eine solche API stellt beispielsweise Applikation A ihre Funktionen Applikation B zur Verfügung, ohne dass Applikation B über die wahre Komplexität der in Applikation A ablaufenden Prozesse informiert werden muss. In Abb. 4.6 wird anhand der OpenWeatherMap schematisch dargestellt, wie via API Wetterinformationen aus London abgerufen werden können. Die eigene Software-Applikation benötigt kein Wissen darüber, wie eine Wetter-Messstation auf der Zugspitze ausgelesen werden muss, der Anwendungsentwickler muss sich nicht mit den Unterschieden der Kommunikationsprotokolle der Messstationen von der Zugspitze und jener der Messstation in Salzburg auseinandersetzen. Ein neuer Nutzer eines Services muss in der Regel nicht einmal mit einem Mitarbeiter eines API-Anbieters kommunizieren. So reicht es beispielsweise beim Wetterdaten-Anbieter OpenWeatherMap aus, sich

Ihre Soware Anfrage

Antwort

Wie ist das Wetter in London?

Hier sind die aktuellen Wetterdaten aus London! […]

api.openweathermap.org/d ata/2.5/weather?q=London

"weather":[{"id":804,"main":"clouds","description":"overcast clouds","icon":"04n"}], "main":{"temp":289.5,"humidity":89,"pressure":1013,"temp_min":287.04,"temp_max":292.04}, "wind":{"speed":7.31,"deg":187.002}, "rain":{"3h":0}, "clouds":{"all":92}, "dt":1369824698, […]

API

Anforderungen an API-Aufrufe dokumentiert unter https://openweathermap.org/current

Soware-Service der OpenWeatherMap

Die automatisierte Leistungserbringung hinter der API bleibt dem Nutzer verborgen (Abstraktion)

Abb. 4.6   Schematischer Ablauf der Nutzung einer Programmierschnittstelle (API) am Beispiel der OpenWeatherMap.org

102

4  Cloud – Die automatisierte IT-Wertschöpfung

als Nutzer zu registrieren und je nach Abonnement-Modell die Zahlungsdaten zu hinterlegen, um auf die Funktionalitäten der Applikation zugreifen zu können. Änderungen hinter der API werden durchgeführt, ohne dass dies Auswirkungen auf den Nutzer hat. Es werden keine individuellen Abrechnungsprozesse etabliert oder spezifische Haftungsklauseln vereinbart. Derjenige Entwickler, der Wetterdaten in seiner Applikation nutzen möchte, integriert lediglich den Aufruf der OpenWeatherMap-API in seiner Anwendung. Es reicht, wenn er sich dabei an die in der Dokumentation beschriebenen Vorgaben zum Aufruf der API hält. Das Ergebnis: Die eigene Applikation kann auf weltweite Daten zur Wettervorhersage zugreifen und diese den Endkunden zugänglich machen. Und das, ohne dass sich die eigenen Entwickler mit den Details der durchaus komplizierten Informationsbeschaffung im Bereich der Wetterdaten auseinandersetzen müssen. Das API Manifest Amazon gehört zu den Vorreitern beim Orchestrieren von Software-Services mittels API. Laut dem ehemaligen Amazon-Ingenieur Steve Yegge verkündete Jeff Bezos, CEO von Amazon, im Jahr 2002 ein sogenanntes „API Manifesto“ (Lane 2012). Darin postulierte er: Alle Teams stellen fortan ihre Daten und Funktionen über Service-Schnittstellen (API’s) zur Verfügung. Teams kommunizieren miteinander über diese Schnittstellen. Keine weitere Form der übergreifenden Kommunikation ist erlaubt: Keine direkten Links, keine direkten Datenbankzugriffe, keine Shared-Memory-Modelle und keine anderweitigen Hintertüren. Die einzige erlaubt Form der Kommunikation ist jene über Aufrufe der Service-Schnittstellen über das Netzwerk. Welche Technologie die Teams einsetzen, ist egal. […] Alle Service-Schnittstellen müssen ausnahmslos so gestaltet werden, dass sie auch extern verwendet werden können. Das Team muss also ihren Service so planen und gestalten, dass die Schnittstelle auch von externen Entwicklern genutzt werden kann. Keine Ausnahmen.

Bezos schloss sein Manifest mit den Worten: „Jeder, der sich nicht daran hält, wird entlassen.“ Ihm war es also ernst damit, sein Anliegen in der Praxis umzusetzen. Obwohl es in diesem Manifest eigentlich um ein IT-Thema ging, nutzte Bezos gleich vier Mal das Wort „Teams“ und drei Mal das Wort „Kommunikation“ – Technologie spielt dagegen eine untergeordnete Rolle. Darin steckt die zentrale Botschaft hinter der API: Wenn Unternehmen ihre Services – egal auf welcher Technologie diese basieren – auf die richtige Art und Weise zur Verfügung stellen, entsteht eine neue Art der Zusammenarbeit. Global verteilte Teams können miteinander interagieren, ohne miteinander sprechen zu müssen. Die unternehmensweite Kommunikation und Zusammenarbeit erfolgt automatisiert durch den Aufruf der API des jeweils anderen Teams. Die Fülle der Angebote in der Cloud entsteht durch die unendliche Zahl an Services, die sich

4.4  Die Cloud-Transformation in der IT

103

aufeinander beziehen. So entsteht ein heute für jedes Unternehmen verfügbares Netz an global verteilten und skalierbaren Service, die jeweils für sich schnell und agil einsetzbar sind. Der Name dieses Netzes: Public Cloud. Virtualisierung und Abstraktion In Abschn. 4.3.1 wurde die Virtualisierung der Rechenleistung bereits beschrieben: Aus den realen Rechnern werden „virtuelle Maschinen“. Die Idee von Jeff Bezos geht aber über die Idee der Virtualisierung eines physischen Gutes hinaus. Er möchte, dass alle Teams ihr Wissen und ihre Services digital einfach konsumierbar bereitstellen. Dazu gehören etwa Informationen über Lagerbestände, Vorhersagen über das Kundenverhalten und Profile zu Einkaufspräferenzen. Aufgrund dessen wird im Zusammenhang mit APIs häufig der Begriff „Abstraktion“ verwendet. Abstraktion meint die Betrachtung einer Sache oder einer Idee von einem höheren Blickwinkel und die Reduktion dieser Sache auf das Wesentliche (Alt 2008). APIs stellen ihren Anwendern somit nur das Wesentliche zur Verfügung – eben genau die Funktionalität, für die der Service benötigt wird. Informationen zur inneren Struktur und zu Abhängigkeiten zwischen einzelnen internen Komponenten bleiben verborgen. Am Beispiel einer Datenbank lässt sich dies gut erklären. Wofür benötigt der Entwickler einer Applikation die Datenbank? Im Wesentlichen möchte er die Daten seiner Applikation dort dauerhaft ablegen und bei Bedarf abrufen können. Was aber ist notwendig, damit die Datenbank diese Aufgabe tatsächlich erfüllen kann? Sie muss – dem IT-Stack folgend – erst einmal installiert sein, und dafür benötigt sie eine virtuelle Maschine, die wiederum ein Betriebssystem benötigt. Auf den untersten Ebenen des Stacks müssen Netzwerk und Speicher verfügbar sein. Jede Komponente für sich benötigt Software-Updates und hat geplante Auszeiten, mitunter auch Ausfälle. Soll die Datenbank während dieser Auszeiten weiterhin verfügbar sein, müssen die Komponenten jeweils redundant angelegt werden. Für die intelligente Verteilung der Last sind also weitere Komponenten nötig. Zudem erzeugt jedes Element Kosten, die intern verursachungsgerecht verrechnet werden müssen. Informationen über den Zustand jedes Elements müssen gesammelt und bewertet werden. Alle diese Informationen interessieren den Entwickler allerdings nicht. Er möchte Daten in der Datenbank ablegen und wieder abrufen oder auch ihren Speicher erweitern. Abb. 4.7 zeigt den API-Call für den Fall „Speicher der MySQL-Datenbank auf 7 GB erweitern“. Jene Komplexität, die in Abschn. 4.2 beschrieben wurde, bleibt unsichtbar für den Anwender der API. Die Leistung ist abstrahiert, dem Nutzer genügt das Wesentliche – in diesem Fall also die Option, mithilfe eines kurzen Sprachbefehls mehr Speicher zu nutzen. Fertige Bauteile, Mikrotransaktionen und globale Netzwerke Die Verantwortlichen der Datenbank-Services müssen unter den Bedingungen des Cloud Computing ebenfalls umdenken. Zu Zeiten der klassischen IT gab es die Möglichkeit, einer erhöhten Nachfrage mit dem Hinweis „Wir sind zurzeit überlastet. Ich

104

4  Cloud – Die automatisierte IT-Wertschöpfung

API-Call zur Erweiterung des Speichers auf 7GB az mysql server update \ --resource-group myresourcegroup \ --name mydemoserver \ --storage-size 7168

API

MySQL Datenbank-Service Abb. 4.7   Beispiel für einen API-Call einer Datenbank

schätze, nächsten Monat werden wir uns darum kümmern“ an den Service Manager zu begegnen. Im Cloud-Zeitalter wird erwartet, dass die Leistung binnen Sekunden oder Minuten lieferbar ist. Das lässt sich erreichen, indem der Datenbankservice ebenfalls wie eine Software aufgebaut wird. Im Software-Code ist festgelegt, wie der Service bei erhöhter Nachfrage reagiert und welche zusätzlichen Ressourcen der Code über andere Cloud-Services bezieht. So entsteht ein automatisiert interagierendes Netzwerk, das flexibel auf Nachfrageschwankungen reagieren kann (s. Abb. 4.8). Ein weiterer Vorteil dieses Ansatzes besteht darin, dass diese Services aufgrund ihrer Softwareeigenschaften feingranular heruntergebrochen und vermarktet werden können. Die Nutzung einer Datenbank kann nach der Anzahl der Datenbanktransaktionen abgerechnet werden, ein Speicher nach der Anzahl der gespeicherten Dokumente, ein Rechner nach der tatsächlich genutzten CPU-Kapazität. So entstehen neue Geschäftsmodelle, bei denen jede Suchanfrage in Mikro-Cent-Beträgen abgerechnet wird, die aber am Ende – aufgrund der weltweiten Skalierbarkeit – Milliarden-Profite abwerfen (Novet 2019). Vier Jahre nach der Veröffentlichung des API Manifests stellte Amazon seine intern entwickelten IT-Services dem Rest der Welt zur Verfügung – unter dem Namen Amazon Web Services (AWS). Damit konnten Kunden nicht nur Bücher und CDs bei Amazon bestellen, sondern über APIs die Komponenten der den Geschäftsfeldern von Amazon zugrundeliegenden IT-Wertschöpfungskette nutzen. Die gleichen Serverdienste, die

4.4  Die Cloud-Transformation in der IT

105 API

Ihre Soware

„Visitor Guide London“

IT-Wertschöpfung wird zum Netzwerk

API

• Jede Komponente kapselt ihre innere Komplexität gegenüber den anderen über die API (Abstrakon).

API

TrafficInfoApp

OpenWeatherMap

Staus in London

• Jede Komponente kann für sich von unendlich vielen anderen Services genutzt werden. • Zur kombinierten Nutzung mehrerer Komponenten wird eine So­ware geschrieben – die wiederum selbst als Komponente unendlich wiederverwendet werden kann.

WeŽer in London API

API Service X

API Service Y

API Storage

Service Y

API Compute

API Service Y

Abb. 4.8   IT-Wertschöpfung wird zum Netzwerk

Amazon für sein Video-Geschäft nutzt, verwendet nun auch Netflix für seine Streaming-Daten (Macaulay 2018). Die Datenbank-Services, die Airbnb bei Amazon nutzt (Hu und Guo 2018), stehen auch dem Wettbewerber Booking.com offen. AWS wurde auf diesem Weg zu einem „Baumarkt“ für IT-Fertigteile in der Cloud (Abschn. 4.4.4).

4.4.4 Cloud ist nicht gleich Cloud Der Begriff „Cloud“ steht aus einer betriebswirtschaftlichen Perspektive zunächst nur für die Idee einer „automatisierten IT-Wertschöpfung“. Die Vielzahl der Komponenten in der IT-Wertschöpfungskette bedingt auch, dass es viele Varianten von Cloud-Anwendungsszenarien gibt, die sehr unterschiedliche Leistungsspektren abdecken. Entscheidend für den sinnvollen Einsatz der Cloud in Unternehmen ist der Abstraktionsgrad des jeweiligen Services. Je nachdem auf welcher Ebene des IT-Stacks die Automatisierung beginnt, werden spezifische Cloud-Anwendungen unterschieden. Abb. 4.9 gibt einen Überblick über die wichtigsten Ansätze. Klassische IT Beim klassischen Ansatz der „Dedicated IT“ werden keinerlei Ressourcen virtualisiert. Stattdessen werden für den einzelnen Kunden dedizierte Ressourcen aufgestellt und individuell betrieben. Bei „Virtualized IT“ wird mindestens die Rechenleistung virtualisiert und geteilt. Dieses Modell wird mitunter schon als Cloud bezeichnet.

106

4  Cloud – Die automatisierte IT-Wertschöpfung

Dedicated

Virtualized

Anwendung

IaaS

Runmes & Libraries Datenbanken

Virtualisierung

PaaS API

Manuelle Tägkeiten involviert.

Security & Integraon

Betriebssystem

Container

Serverless

SaaS

API

API API

API

Automasierte IT-Wertschöpfung

Rechenleistung Speicher Netzwerk Klassische IT

Cloud IT

Cloud Nave IT

Abb. 4.9   Verschiedene Abstraktionsgrade der cloudbasierten IT-Wertschöpfung

Infrastructure-as-a-Service und Container Die Virtualisierung der IT-Rechenleistung, Speicher und Netzwerke heißt „Infrastructure-as-a-Service“ (IaaS). Alle drei Infrastruktur-Komponenten sind komplett automatisiert und über eine API zugänglich. Eine Applikation aus einem klassischen Rechenzentrum auf eine „IaaS-Cloud“ zu heben, ist vergleichsweise schnell und unkompliziert möglich. In den wenigsten Fällen sind komplexere Anpassungen der Applikation oder größere Migrationsaufwände notwendig. Eine solche Migration nennt sich „Rehost“ oder „Lift & Shift“. Platform-as-a-Service und Serverless Einen sehr großen Schritt in der Automatisierung machen die Platform Services (PaaS – Platform-as-a-Service). Bei dieser Form der Cloud werden umfangreiche Funktionalitäten bereitgestellt, wie beispielsweise Datenbanken, Machine-Learning-Services, Internet-Of-Things-Features, Bots, Videoservices und vieles mehr. Software-Entwickler bedienen sich der Platform-Services, da sie ihnen viele Aufgaben abnehmen und sie mit ihrer Hilfe sehr schnell sehr umfangreiche Applikationen erstellen können. Diese vorgefertigten Bausteine haben die Geschwindigkeit, mit der Software entwickelt werden kann, deutlich erhöht. Erste funktionsfähige Prototypen von digitalen Geschäftsmodellen können von kleinen Teams häufig binnen weniger Tage entwickelt werden. Serverless Computing, auch Function-as-a-Service genannt, ist die neueste Abstraktionsebene der Cloud. Traditionell müssen sich Software-Entwickler, neben der eigentlichen Geschäftslogik ihrer Anwendung, auch um Kapazitätsplanung, Skalierbarkeit, Flexibilität und Fehlertoleranz kümmern (Büst 2016). Im Serverless Computing werden dem Entwickler auch diese Aufgaben abgenommen. Der Anteil der Aufwände des Software-Entwicklers in der primären Wertschöpfung (mit direktem Wertbeitrag für das Geschäftsmodell) kann somit noch weiter zunehmen (s. Abb. 4.10). Die Abrechnung von Serverless erfolgt meist feingranular im Mikro-Euro-Bereich auf Basis der Menge der tatsächlich genutzten CPU-Kapazität.

4.4  Die Cloud-Transformation in der IT

107 Ihr sowarebasiertes Geschäsmodell

Ihre sekundäre Wertschöpfung •

… können Sie wie aus einem riesigen Baumarkt mit Fer gteilen beziehen

API

API

Service X

Service Y

API

API

• … kostet nur, wenn Sie Ihnen auch etwas nutzt • … ist in Mikrotransak onen nutzbar, skaliert aber trotzdem weltweit

Fokus auf primäre Wertschöpfung

Service Z

API Service B

API Storage

Service A

API Compute

API Service C

Abb. 4.10   Cloud ermöglicht die einfache Fokussierung auf das Kerngeschäft Die Angebotspalette der PaaS-Anbieter Der Katalog der Platform-Services (PaaS) der Cloud-Provider ist riesig. Neben den Angeboten der Hyperscaler Microsoft, Google, Amazon und Alibaba gibt es branchenspezifische Anbieter wie Zalando oder Spotify, die eigene Services für ihre jeweilige Nische anbieten. Allgemeine IT-Services Um dem Bedarf der Unternehmen nachzukommen, ihre IT-Landschaft in der Cloud abzubilden, bieten die Cloud-Provider eine Vielzahl grundlegender IT-Services an. Dazu gehören insbesondere Container-Services, Datenbank-Services und Services für Web-Applikationen. Der Nutzen der vielen weiteren IT-Services lässt sich dem technischen Laien nur mit umfangreicheren Ausführungen erläutern, wichtig ist daher die folgende Kernbotschaft: Alle gängigen Anforderungen an IT-Landschaften lassen sich mit dem in der Cloud vorhandenen Service-Portfolio abdecken. Analytics Hinter dem Begriff „Big Data“ verbirgt sich ein globaler Trend: Durch die immer größer werdende Anzahl der Datenquellen und die immer günstigeren Möglichkeiten der Datenspeicherung entstehen riesige Datenpools. Mit den Tools, die Hyperscaler im Bereich Analytics bereitstellen, können diese Datenpools in Millisekunden miteinander kombiniert, migriert und analysiert werden. Beispielsweise können Daten über das Onlineverhalten von Konsumenten so miteinander abgeglichen werden, dass via Realtime-Advertising jeder Kunde die für ihn relevante Werbung ausgespielt bekommt. Artificial Intelligence (AI) und Machine Learning Eines der spannendsten Anwendungsgebiete von Platform-Services sind die Bereiche künstliche Intelligenz (Artificial Intelligence – AI) und Machine Learning. Zu den etablierten Services zählen die Gesichtserkennung in Bildern und Videos, die Inhaltsanalyse von Texten oder das Erkennen

108

4  Cloud – Die automatisierte IT-Wertschöpfung

von gesprochener Sprache bzw. die Umwandlung gesprochener in geschriebene Sprache („Speechto-Text“). Solche Machine-Learning-Algorithmen kommen zum Beispiel beim Betrieb der Sprachassistenten Siri (Apple), Alexa (Amazon), GoogleNow (Alphabet) und Cortana (Microsoft) zum Einsatz. Blockchain Die Blockchain-Technologie ist eine dezentrale, chronologisch aktualisierte Datenbank, die eine digitale Verbriefung von Eigentumsrechten ermöglicht (Mitschele 2018; Pilkington 2016). Blockchain-Angebote aus der Cloud erlauben es, die entsprechenden Netzwerke relativ schnell herzustellen und zu betreiben. Mit cloudbasierten Blockchains können dann beispielsweise Lieferketten der Lebensmittelindustrie einfach und fälschungssicher dokumentiert und dargestellt werden (Zores und Koppik 2019). Internet der Dinge Der Sammelbegriff „Internet der Dinge“ (im Englischen: Internet of Things, abgekürzt „IoT“) vereint Services und Angebote, die sich auf die Zusammenführung und gemeinsame Steuerung unterschiedlicher Endgeräte bezieht. So können im Haushalt die Funktionen von Endgeräten wie Wecker, Stereoanlage, Kaffeemaschine und Heizung miteinander gekoppelt werden. Mit den IoT-Produkten von PaaS-Anbietern können Milliarden von IoT-Ressourcen bzw. Endgeräten miteinander vernetzt, administriert und die Sicherheit gewährleistet werden. Media Services Die Provider bieten ein spezielles Service-Portfolio, das auf die Verarbeitung von Mediendaten ausgerichtet ist. Dazu gehört etwa ein Content Delivery Network (CDN), das die Verteilung großer Mengen an Videodaten vereinfacht. Des Weiteren gibt es Encoding-Services zur Umrechnung von Bildformaten und -auflösungen sowie weitere medienoptimierte Streaming- und Analytics-Services. Sicherheit/Security Ein weiterer Schwerpunkt sind die sicherheitsbezogenen Services. In Abschn. 4.7 gehen wir auf dieses Thema gesondert ein. Diese Liste bietet eine erste Übersicht über die aktuellen Möglichkeiten. Natürlich erhebt sie aber keinen Anspruch auf Vollständigkeit, denn die Angebote wandeln sich viel zu schnell und sind noch wesentlich vielfältiger als hier dargestellt.

Software-as-a-Service Bei Software-as-a-Service (SaaS) handelt es sich um eine fertige Software mit einer für Endkunden nutzbaren grafischen Oberfläche. Ein gutes Beispiel hierfür ist Slack, eine Software für die Zusammenarbeit und Kommunikation in Gruppen. Diese ist für jeden auch ohne Programmierkenntnisse im Browser und als App nutzbar. Die Anmeldung funktioniert einfach über die Webseite, der Basisservice ist kostenlos. Es gibt aber auch Bezahlversionen mit erweiterten Features ab 6,25 EUR pro Monat. Das Preismodell macht es deutlich: Die Wertschöpfungskette dahinter ist voll automatisiert. Häufig bieten SaaS-Anbieter auch Teilfunktionalitäten ihrer Services als PaaS an. Über eine API stehen Features wie Messaging-Dienste, Workflow-Tools und Werkzeuge zur Erstellung von Bots (Chat-Robotern) zur Verfügung.

109

4.5  Der cloudbasierte IT-Prozess

Geschäsmodell

Nähe der Soware-Entwickler zum Fachverantwortlichen

API

API

Service Y

Service X

API

Großer Katalog einfach nutzbarer IT-Fergteile

F

Datenbank

API Service B

Entwickler können selbst alle IT-Fergteile ansteuern

API Storage

API Service A

API Compute

API Service C

Abb. 4.11   Software erstellen unter Nutzung von Cloud-Services

4.5 Der cloudbasierte IT-Prozess Aufbauend auf den Möglichkeiten der Nutzung von API-basierten Software-Lösungen und der Automatisierung der IT mit Hilfe von Cloud-Technologien kann der dreiteilige Software-Prozess („Erstellung“, „Betrieb“ und „Skalierung“) über alle Stufen hinweg neu gedacht werden. Wie sich eine solche Neuausrichtung in der Praxis auswirkt, wird in den folgenden Abschnitten dargestellt.

4.5.1 Software erstellen Die wichtigste Veränderung in der cloudbasierten Software-Erstellung betrifft die Software-Entwickler. Sie können in der Cloud-Umgebung alle für die Erstellung einer Software notwendigen IT-Komponenten selbst ansteuern. Dabei nutzen sie die geschilderten Programmierschnittstellen (APIs) und können zu diesem Zweck aus dem reichhaltigen Katalog aus IT-Fertigteilen der Cloud-Provider schöpfen. Alle Fertigteile sind sofort und in faktisch beliebiger Menge vorhanden. Aufgaben, die hinter der API anfallen, bleiben für den Ersteller der Software unsichtbar. Die Cloud gibt dem Entwickler somit eine neue kreative Macht, die vorher auf viele Rollen und Akteure in der Unternehmensorganisation verteilt war. Der Entwickler kann nun – gemeinsam mit dem Kunden oder dem Fachverantwortlichen für die Software – schnell und mit wenig Abstimmungsaufwand neue Features entwickeln, demonstrieren und veröffentlichen (s. Abb. 4.11).4

4In

Abschn. 6.6 wird der Prozess der Software-Entwicklung von der Idee bis zum Betrieb der Anwendung ausführlich beschrieben.

110

4  Cloud – Die automatisierte IT-Wertschöpfung

4.5.2 Software betreiben Die Aufwände für den Betrieb einer Anwendung in der Cloud hängen stark von dem in Abschn. 4.4.4 geschilderten Abstraktionsgrad ab. Es gilt der einfache Zusammenhang: Je mehr IT-Wertschöpfung an den Cloud-Provider abgegeben wird, desto geringer ist der eigene Betriebsaufwand. Die großen Cloud-Provider bringen im Vergleich zu kleinen Rechenzentren die folgenden grundlegenden Vorteile mit: • Je mehr Kunden die gleichen IT-Services nutzen, desto größer sind die auftretenden Skaleneffekte. Das Team, das einen Container-Service betreibt, wird nur unwesentlich größer, wenn es statt fünf Kunden die zehnfache Menge an Kunden betreut. Gleiches gilt für alle anderen Services auf allen Ebenen des Stacks. • Anwendungen folgen individuellen Lastverläufen. Je mehr Anwendungen auf der gleichen Infrastruktur betrieben werden, desto besser kann deren Auslastung auf einem wirtschaftlich attraktiven Niveau gehalten werden. Die Risiken einer Unterauslastung sinken ebenso wie die Wahrscheinlichkeit, dass einzelne Anwendungen die gesamte Infrastruktur an ihre Leistungsgrenze bringen (s. Abb. 4.12). Bei hohen Abstraktionsebenen wie Serverless oder SaaS können die Cloud-Provider auf allen Ebenen des Stacks die Ressourcen teilen und Auslastungsoptimierungen vornehmen. Entsprechend weniger Infrastruktur-Ressourcen müssen sie fest vorhalten, ihre internen Kosten sinken. Einen Teil dieser Kosteneinsparungen geben sie über attraktive, nutzungsabhängige Preise an ihre Kunden weiter. Vorausgesetzt, der Kunde stellt seine Applikation so um, dass diese die hohen Abstraktionsebenen tatsächlich nutzt (siehe Kap. 5), sinken für ihn die Kosten signifikant. Er spart sich nicht nur die Investitionen in das eigene Rechenzentrum mit dessen

Keine Auslastungsrisiken

Kostensenkung durch geteilte Ressourcen und Skaleneffekte auf allen Ebenen des Stacks

Abb. 4.12   Software betreiben in der Cloud

Geringe Bindung von Kapitel und Mitarbeitern in der sekundären Wertschöpfung

111

4.5  Der cloudbasierte IT-Prozess

Liegenschaften und der notwendigen Hardware, er benötigt auch signifikant weniger qualifizierte Mitarbeiter, um die notwendigen IT-Services bereitzustellen. Zudem werden aus den vorher fixen Kosten für den IT-Betrieb variable Kosten, die sich weitestgehend parallel zur tatsächlichen Nutzung der Software entwickeln. Die Risiken für Unterauslastung sowie Überlastung der eigenen Infrastruktur sinken ebenfalls.

4.5.3 Software skalieren Ein großes Thema zu Beginn jeder Neueinführung von Software ist die Frage, wie stark sie genutzt werden wird. Manager müssen in der klassischen IT in einer frühen Phase die Entscheidung treffen, welche IT-Ressourcen in welcher Höhe für den erwarteten Nutzeransturm vorgehalten werden sollen. Daraus resultieren dann eine Investition mit einem entsprechenden Anschaffungs- und Installationsprojekt sowie fixe, monatliche Kostenblöcke. Diese bestehen aus den Abschreibungen für die Hardware sowie den monatlichen Pauschalen für den Betrieb jeder genutzten IT-Komponente auf allen betroffenen Ebenen des Stacks. An genau dieser Stelle spielt die Cloud ihre Vorteile aus. Eine Cloud-Anwendung kann so gestaltet werden, dass sie mit keinen oder nur sehr geringen Fixkosten beginnt – denn sie belegt ja aufgrund des in der Cloud möglichen Auslastungsmanagements beim Provider keine festen Ressourcen. Steigt die Nutzung der Applikation nun schrittweise an, kann der Cloud-Provider dank der vollständigen Automatisierung der Cloud-Services feingranular nur genau so viel Rechenpower zur Verfügung stellen, wie eben benötigt wird (s. Abb. 4.13). Die weltweite Infrastruktur vieler Cloud-Anbieter ermöglicht es Kunden zudem, ihre Anwendung einfach global auszurollen. Um für Erstellung, Betrieb und Skalierung von Software die Vorteile der Cloud zu nutzen, ist es essenziell, dass sich die Applikation der höheren Cloud-Abstraktionsebenen bedient. Dann entfallen viele manuelle Schritte in der IT-Wertschöpfung, es entstehen kundenübergreifende Skaleneffekte und Investitions- und Auslastungsrisiken sinken.

Global erweiterbar F

Kosten nur bei Nutzung

Abb. 4.13   Software skalieren in der Cloud

Sehr feingranulare Skalierung

112

4  Cloud – Die automatisierte IT-Wertschöpfung

4.6 Public Cloud vs. Private Cloud Das Fraunhofer Institut definiert die Public Cloud als „ein Angebot eines frei zugänglichen Providers“, die Private Cloud dagegen werde nur „den eigenen Mitarbeitern zugänglich“ gemacht (Fraunhofer 2019). Diese Definition geht davon aus, dass die Private Cloud vom Unternehmen selbst betrieben wird. Üblicherweise lautet die erweiterte Definition, dass die „Private Cloud nicht für die Allgemeinheit über das Internet erreichbar“ (Luber und Karlstetter 2017b), also „exklusiv für einzelne Organisationen“ verfügbar ist. Somit müssen Unternehmen die Private Cloud nicht selbst betreiben; es reicht, wenn dies ein Dienstleister für sie übernimmt. Mit welcher Variante können Unternehmen digitale Geschäftsmodelle nun erfolgreicher etablieren – mit der Public oder der Private Cloud? Für die Antwort auf diese Frage ist es sinnvoll, sich die großen generellen Vorteile der Cloud als automatisierte IT in Erinnerung zu rufen: • Unternehmen können viele IT-Fertigteile nutzen. • Diese Nutzung kann in Mikrotransaktionen erfolgen. • Unternehmen können im Erfolgsfall global skalieren. • Wird die Anwendung nicht genutzt – etwa im Falle eines Misserfolgs – müssen Unternehmen auch keine IT-Nutzung zahlen. Hinsichtlich der Nutzbarkeit dieser vier Vorteile ergeben sich große Unterschiede zwischen der Private und der Public Cloud. Abb. 4.14 zeigt die verschiedenen Virtualisierungsgrade der IT-Wertschöpfung. Private Clouds beinhalten üblicherweise die vier Ebenen Netzwerk, Speicher, Rechenleistung und Virtualisierung – also die Ebene Infrastructure-as-a-Service (IaaS). Darauf basierend können sowohl in der Private Cloud als auch in der Public Cloud spezialisierte Services betrieben werden – Beispielkategorien hierfür sind Container Services, Platform Services, Serverless und Software-Services. In großen IT-Landschaften mit vielen Applikationen wird eine sehr breite Auswahl dieser Services in vielen unterschiedlichen Varianten benötigt. Dedicated

Virtualized

IaaS

Container

Anwendung

API

Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher

PaaS

API API

Serverless

Vielzahl spezialisierter Services mit hohem Einfluss auf das Geschä

API

Basis-Leistungsumfang von Private Clouds

Netzwerk

Abb. 4.14   Basis-Leistungsumfang der Private Cloud

SaaS

API

4.6  Public Cloud vs. Private Cloud

113

Für jeden dieser Services bedarf es für einen erfolgreichen Betrieb in der Private Cloud zweierlei: ein eingearbeitetes und verfügbares Betriebsteam, das den Service installiert und betreibt sowie ausreichend Infrastruktur, damit der Service bei Bedarf gut skalieren kann. Die Größe des Betriebsteams bleibt mit steigender Anzahl der Kunden weitestgehend konstant, die Infrastruktur dagegen wächst mit der Höhe der größten Gesamtauslastung über alle Nutzer hinweg. Damit befindet sich die Private Cloud auch in ihrem Polylemma: Einerseits sind möglichst viele Kunden nötig, um die fixen Kosten des Betriebsteams zu refinanzieren. Andererseits ist die zugrundeliegende Infrastruktur für die Spitzenauslastung über mehrere Kunden meist zu klein. Wird mehr Infrastruktur in der Public Cloud bereitgestellt, erhöht sich das Risiko der Unterauslastung. Abb. 4.15 vergleicht die Vor- und Nachteile der Private-Cloud-Nutzung mit jenen der Public-Cloud-Nutzung. Die Private Cloud ist somit in vielen Bereichen gegenüber der Public Cloud im Nachteil. Im Wesentlichen gibt es dafür zwei Ursachen: • Auslastungsmanagement: Die Cloud-Provider investieren einmalig in ihre globalen Rechenzentren. Alle angebotenen Services für alle ihre Kunden nutzen die gleiche Infrastruktur. Die Provider haben somit ganz andere Möglichkeiten, ihre Auslastung zu optimieren, mit weniger tatsächlicher Hardware mehr virtuelle Services zu verkaufen, die Preise zu senken und gleichzeitig ihre Margen zu verbessern. • Portfolio-Breite: Für jeden Service in der Private Cloud wird ein fixer Betriebsaufwand gebraucht. Um die Breite der Service-Portfolios eines Public-Cloud-Anbieters in der Private Cloud abbilden zu können, fallen somit hohe einmalige und monatliche Aufwände an. Die wichgsten Chancen für Unternehmen entstehen durch …

µ€

Private Cloud

Public Cloud

… die vielen IT-Fergteile

Hohe Invests oder wenig Auswahl

Keine eigenen Invests und trotzdem große Auswahl

… die Nutzbarkeit in Mikrotransakonen

Risiko der HardwareAuslastung selbst tragen

Auslastungsrisiko trägt der Cloud Provider

… die Möglichkeit der globalen Skalierung

Nur mit hohen Invests möglich

Auf Abruf beim Public Cloud Provider

… direkte Synchronisaon von Kosten und Nutzen

Kaum möglich bei geringer Nutzung

Einfach möglich

Dem stehen auch Risiken gegenüber

Kein Einfluss auf Technologie und Prozesse hinter der API Cloud-Leistungen werden meist teurer bei sehr großer Skalierung

Abb. 4.15   Private Cloud und Public Cloud im Vergleich

114

4  Cloud – Die automatisierte IT-Wertschöpfung

Die Vielzahl der Services, gepaart mit dem schwankenden Lastverhalten von Cloud-Anwendungen, macht den Betrieb einer Private Cloud mit vielen Platform-Services zum großen Risiko. Kunden, die weltweit skalierende, digitale Geschäftsmodelle mit Null-Grenzkosten aufbauen und betreiben wollen, werden also in der Regel auf die Public Cloud zurückgreifen: Diese bietet mehr Auswahl an Services, die Auslastungsrisiken trägt der Anbieter und sie können investitionsfrei weltweit skalieren. Erst wenn Kunden eine nennenswerte Größe erreicht haben, können eigene Hardware-Infrastrukturen und der Eigenbetrieb der jeweils benötigten Platform- und Software-Services ihre Vorteile ausspielen (Kap. 5).

4.7 Sicherheit in der Public Cloud Eine der zentralen Fragen der Cloud-Gegner in Unternehmen lautet: Ist die Cloud denn überhaupt sicher? Gemeint ist damit meistens die Public Cloud, also jene global verteilten Rechenzentren der amerikanischen Großunternehmen Amazon, Google und Microsoft. Diese Frage ist durchaus berechtigt: Sollen europäische Unternehmen ihre Daten wirklich gerade bei jenem Unternehmen ablegen, die häufig als „Datenkraken“ bezeichnet werden (Strathmann 2015)? Möchte das Unternehmen seine Applikationen mit zu schützenden Kreditkarteninformationen wirklich in gerade jene Cloud legen, die das Wort „öffentlich“ schon in ihrem Namen trägt? Und können nicht die Hacker der chinesischen Konkurrenten besonders einfach die eigenen Applikationen kompromittieren, wenn die Unternehmens-IT in der Cloud mit ihnen die Ressourcen teilt? Der nun folgende Abschnitt gibt einen kurzen Einblick in die Sicherheitsvorkehrungen und -mechanismen der Public-Cloud-Provider. Das Ziel dieses Abschnitts ist es, Sie in die Lage zu versetzen, selbst eine grundlegende Abwägung der zugrundeliegenden Risikofaktoren treffen zu können. In einem ersten Schritt ist dabei zwischen den Begriffen „Compliance“ und „IT-Sicherheit“ zu differenzieren (s. Abb. 4.16). Ersteres fokussiert sich auf das Verhalten des Unternehmens: Es möchte sich an Gesetze, Regeln und Normen interner wie externer Art halten. Bei IT-Sicherheit dagegen geht es darum, sich vor dem betrügerischen Verhalten anderer zu schützen. Dabei werden einerseits die physischen Anlagen wie Rechenzentren und Serverräume vor unberechtigtem Zutritt geschützt. Andererseits geht es um den Schutz vor Manipulation von außen mithilfe technischer Mittel. Informationssicherheit beinhaltet die IT-Sicherheit und ergänzt diese um analoge Themen wie die Aufbewahrung von Papierakten.

4.7.1 Betrügergruppen und Beispiele für Gefahren Die drei typischen Betrügergruppen, vor denen sich Unternehmen schützen müssen, sind:

115

4.7  Sicherheit in der Public Cloud Eigenes korrektes Verhalten sicherstellen

Gegen Kriminelle schützen

Compliance

IT-Sicherheit

Informaonssicherheit

Einhaltung von Gesetzen, Regeln und Normen

Schutz von Computersystemen vor betrügerischen Handlungen

Umfasst auch den Schutz von nicht-technischen Systemen (wie etwa Papierablagen)

Physische Sicherheit

Technische Sicherheit

Wenn Hacker Kreditkartendaten erbeuten, kann dies zu einem Compliance-Verstoß führen.

Abb. 4.16   Differenzierung der Grundbegriffe Compliance und Sicherheit

• Vandalen ohne größere kriminelle oder langfristige Ambitionen. Ein gutes Beispiel ist der 20-jähriger Schüler aus Hessen, der personenbezogene Daten ausgespäht und veröffentlicht haben soll (Kling 2019). Der Schüler hatte sich über bestimmte Meinungsäußerungen seiner Opfer geärgert. • Gewöhnliche Kriminelle, die sich bestimmte finanzielle Vorteile durch das Eindringen in fremde Computersysteme erhoffen. Ein typisches Beispiel ist Ransomware. Dabei geht es darum, den Zugriff von Unternehmen auf ihre eigenen Daten zu unterbinden, um diesen dann – gegen Lösegeld – wieder freizugeben (Rouse 2016). • Staatliche Akteure, die in Rechenzentren eindringen, um etwa Wirtschaftsspionage zu betreiben (Dams 2017). Unabhängig von der Motivation der betrügerischen Akteure gibt es verschiedene Ebenen, über die diese versuchen, in IT-Systeme (in der Cloud wie auch in herkömmliche Rechenzentren) einzudringen (s. Abb. 4.17). Ein klassischer Weg ist jener über das physische Netzwerk. Ein Beispiel hierfür ist die sogenannte „Distributed Denial of Service“-Attacke (DDoS). Die Angreifer senden dabei von vielen verteilten Stellen im Internet gleichzeitig Anfragen an die gleiche Internetadresse. Dadurch ist das angegriffene System überlastet und somit nicht mehr nutzbar. Gleichzeitig können dadurch Fehler entstehen, die der Angreifer nutzen kann, um sich dauerhaft im Netzwerk des Opfers festzusetzen (Luber und Schmitz 2017). Auf der nächsten Ebene, der physischen Hosts (Rechner), versuchen die Betrüger, manipulierte Hardware auf den Rechnern des Opfers zu installieren. Ein Beispiel ist eine Aktion der amerikanischen National Security Agency (NSA) im Jahr 2010. Dabei wurden Pakete der Firma Cisco an ihre Kunden abgefangen, geöffnet und die darin enthaltene Hardware mit Spionage-Hardware („Trojanische Pferde“) versehen. Auf diese Weise konnte der Geheimdienst über die beim Kunden installierten Geräte jegliche Kommunikation mithören (Gallagher 2014). Im Jahr 2019 sind nun die USA in Sorge, ihnen könnte ähnliches passieren, wenn sie die 5G-Hardware des chinesischen Unternehmens Huawei einsetzen (Kühl 2018).

116

4  Cloud – Die automatisierte IT-Wertschöpfung

Physische Sicherheit

Ebene

Technische Sicherheit

Beispiel für ein Sicherheitsproblem

Zugriffspunkte der Endnutzer

Das Handy wird gehackt und als Zugang genutzt

Identätsmanagement

Jemand hackt das Account-Passwort eines anderen

Applikaon

Die Anwendung selbst erzeugt gefährliche Fehler

Betriebssysteme, Datenbanken

Jemand probiert Passwörter durch bis er drin ist

Physische Rechner

Maliziöse Hardware wird eingeschmuggelt

Physisches Netzwerk

Der Zugang zum Data Center wird durch viele gleichzeige Aufrufe gestört

Abb. 4.17   Ebenen der technischen Sicherheit

Auch die Middleware kann ein Einfallstor für Betrüger sein. Wie jede Software, können auch Betriebssysteme und Datenbanken Fehler („Bugs“) enthalten, die dann von Kriminellen ausgenutzt werden. Ein bekanntes Beispiel ist das Schadprogramm „WannaCry“, das eine Lücke im Windows-Betriebssystem ausnutzt, um dort Ransomware zu installieren. Microsoft reagierte und schloss die Lücke mit einem entsprechenden „Patch“ (spiegel.de 2017) – also einem Sicherheits-Update auf das Betriebssystem. Nutzer müssen diesen Patch allerdings auch installieren, um sich zu schützen. Auf der Ebene der Applikation können Betrügergruppen ebenfalls zuschlagen. So kann die unternehmenseigene Applikation unter Umständen so programmiert sein, dass sie direkt sicherheitsrelevante Informationen über ihre normale Oberfläche freigibt. Dies passiert etwa, wenn darauf mehrere Kunden arbeiten, diese aber in der Software-Architektur nicht systematisch getrennt werden („Mandantentrennung“). Kunden erhalten dann möglicherweise Einsicht in Daten von Wettbewerbern, die beim gleichen Dienstleister Kunde sind. Auch können Applikationen Fehler in ihren Programmcode enthalten, die es Angreifern ermöglichen, die Anwendung zu kompromittieren und damit Zugriff auf relevante Daten zu bekommen. Eine große Schwachstelle vieler Applikationen ist das sogenannte Identitätsmanagement. Dabei geht es um die Identität des Nutzers, der sich bei einer Applikation anmeldet. Ist es wirklich Heinz Mustermann, der sich aus dem Internet-Café aus Kairo anmeldet, oder handelt es sich um einen sogenannten „Identitätsdiebstahl“? Wurde das Passwort im falschen Browser gespeichert und später von einem Betrüger ausgelesen? Hat der Nutzer seine Daten auf einer gefälschten Internetseite seiner Bank eingetragen und nutzt es jetzt ein Krimineller? Diese gehackten Passwörter sind dann möglicherweise in einem speziellen Teil des Internets – dem Darknet – gegen Bezahlung erhältlich (Schirrmacher 2019).

4.7  Sicherheit in der Public Cloud

117

Auf der nächsthöheren Ebene geht es um die Zugriffspunkte der Endnutzer, also beispielsweise um deren Handys oder PCs. Wurden diese von Angreifern gehackt, können die Geräte genutzt werden, um wiederum in die Netzwerke und auf die Applikationen des Zielunternehmens zu gelangen.

4.7.2 Gegenmaßnahmen der Cloud-Provider Die Cloud-Provider sind sich der in Abschn. 4.7.1 beschriebenen Gefahren bewusst und setzen zahlreiche Maßnahmen, um die Sicherheit ihrer Systeme und jene ihrer Kunden zu erhöhen. Der erste große Themenbereich ist die Sicherung gegenüber interner Sabotage und Fehlverhalten. Um zu verhindern, dass die eigenen Mitarbeiter ihre Zugänge zu den Systemen ausnutzen, gibt es strikt getrennte Aufgabenbereiche. Es gibt Mitarbeiter mit Zugang zur Hardware in den Rechenzentren. Eine weitere Gruppe, die Betriebsmitarbeiter, arbeitet stets außerhalb des physischen Rechenzentrums über Remote-Zugriff und kann selbst keine Hardware manipulieren. Diese Mitarbeiter arbeiten nicht alleine und dürfen auf Kundensysteme und -daten nur über spezifische Freigaben ihrer Kunden zugreifen. Die Software, die diesen Zugriff steuert und dokumentiert, wird wiederum von einer weiteren Gruppe von Mitarbeitern entwickelt. Durch diese getrennte Verantwortung wird es Kriminellen erschwert, über Bestechung oder Erpressung einzelner Mitarbeiter Zugang zu Daten und Systemen zu erhalten. Das Thema DDoS-Attacken wird auf zwei Wegen angegangen. Zum einen erkennen die Cloud-Provider diese Attacken und lenken den entstehenden Traffic über sehr große Datenleitungen um. Friedliche Anfragen an das eigentliche System werden weiterhin durchgelassen. Die Anwendung bleibt also verfügbar und es entstehen keine Fehler, die dem Angreifer das Einnisten ermöglichen. Zudem unterhalten die Provider eigene „Cyber-Defense“-Einheiten, die sich unter anderem damit beschäftigen, sogenannte „Botnetze“ zu finden und diese zu übernehmen. Dies sind Computer-Netzwerke, die von den Online-Kriminellen gekapert wurden und für solche Angriffe genutzt werden. Auf www.digitalattackmap.com können die aktuellen Angriffe des Tages beobachtet werden. Die Manipulation der physischen Rechner versuchen die Cloud-Provider zu umgehen, indem sie die Wertschöpfungskette von der Entwicklung der Hardware (Ostler 2018) über die Herstellung bis zur Lieferung der Komponenten selbst übernehmen oder eng mit eigenen Mitarbeitern überwachen. Zudem werden Hardwarekomponenten in die Rechner eingebaut, die sicherstellen, dass sich keine ungeplante Hardware auf der Platine befindet.

118

4  Cloud – Die automatisierte IT-Wertschöpfung

Auf der Ebene der Middleware nutzen die Cloud-Provider ein striktes Rechtemanagement zwischen den genutzten Services. Dabei wird der Zugang der Komponenten zum Internet unterbunden und Zugriffe nur von bestimmten anderen Komponenten über vordefinierte Wege erlaubt. Auf diese Weise wird sichergestellt, dass etwa Datenbanken nicht von außen abgerufen werden können. Früher lag der größte Schwerpunkt auf der Verhinderung von Sicherheitsvorfällen auf der bereits geschilderten Netzwerk-Ebene. Seit aber Mitarbeiter und Führungskräfte darauf bestehen, möglichst viele Unternehmensanwendungen auf vielen verschiedenen Endgeräten zu nutzen, hat sich der Schwerpunkt der IT-Sicherheit verlagert. Es geht jetzt mehr darum sicherzustellen, dass der Nutzer, der sich an einer Applikation anmeldet, auch derjenige ist, der er vorgibt zu sein. Der Begriff hierfür ist Identitätsmanagement. Eine häufige und sehr sichere Methode, um die Identität eines Benutzers sicherzustellen, ist die Multi-Factor Authentication (MFA). Dabei muss sich ein Benutzer über zwei unterschiedliche Faktoren authentifizieren (ACSC 2019). Der erste Faktor ist in den meisten Fällen das Passwort – ist dieses korrekt, wird der zweite Faktor angewandt. Dies kann eine SMS mit einem generierten Nummerncode sein, eine Applikation, die einen zeitlichen begrenzten Code erzeugt, oder ein Anruf auf dem Smartphone des Benutzers. Die Cyber-Defense-Einheiten der Cloud-Provider gehen hier allerdings noch weiter. Sie sind ebenfalls im Darknet aktiv und beobachten die dort illegal gehandelten Identitäten. Wird auf diese Weise erkannt, dass eine Benutzername-Passwort-Kombination gehackt wurde, kann der Provider die Nutzer innerhalb seiner Domäne zu einem Passwortwechsel auffordern. Die genannten Beispiele sind lediglich ein Ausschnitt der bekannten Aktivitäten der Provider, die tatsächlichen Aktivitäten gehen wohl darüber hinaus. Es handelt sich um einen Rüstungswettlauf zwischen den IT-Anbietern und ihren betrügerischen Gegnern. Microsoft etwa investiert über eine Milliarde Dollar jährlich in die Cyber-Security-Forschung (Cohen 2017). Google wiederum investiert intensiv in seine Cyber-SecurityTochterfirma Chronicle (Brewster 2019) und möchte damit den Markt der IT-Sicherheit in Unternehmen revolutionieren.

4.7.3 Geteilte Verantwortung von Kunde und Cloud-Provider Sobald ein Unternehmen die Public Cloud in seiner IT-Wertschöpfungskette nutzt, teilt es sich mit dem Cloud-Provider die Verantwortung für die IT-Sicherheit. Hinter der API bzw. der GUI ist der Provider für alle Belange der Sicherheit zuständig. Nutzt ein Unternehmen etwa die Adobe Marketing Cloud als Software-Service (SaaS), ist Adobe dafür zuständig, dass die Applikation sicher entwickelt wurde, die Betriebssysteme immer auf dem aktuellsten Stand sind, die Datenbanken von außen nicht zugänglich

4.7  Sicherheit in der Public Cloud

119

sind, die Rechner-Hardware nicht kompromittiert ist und das physische Netzwerk nicht durch Attacken lahmgelegt wird. Kunden dieser Software-Services haben im Regelfall keine Möglichkeit, die Wertschöpfung dahinter zu kontrollieren, sie benötigen damit ein Mindestmaß an Vertrauen in ihren Provider. Im Gegenzug bieten diese eine Vielzahl von Sicherheits- und Compliance-Zertifizierungen, die von unabhängigen Prüfinstituten vergeben werden. Microsoft stellt auf seiner Webseite etwa 90 Zertifizierungen dar (Microsoft 2019), Google und AWS bewegen sich auf ähnlichem Niveau. Abb. 4.18 zeigt, wie sich die Grenze der Verantwortung mit der Cloud-Virtualisierungsebene verschiebt. Es bleiben somit in allen Fällen noch Sicherheitsthemen, die in der Verantwortung des Kunden liegen, insbesondere sind dies die Bereiche Identitätsmanagement und Zugriffspunkte der Endnutzer. Die Cloud Provider bieten für ihren Kunden Tools zur Absicherung ihres eigenen Verantwortungsbereichs. Dazu gehören unter anderem Firewalls, einfach nutzbare Verschlüsselungs-Services, verschiedene Methoden zur Aufbewahrung der Schlüssel, Tools zum Umgang mit DDoS-Attacken, Möglichkeiten zum feingranularen Rechtemanagement und Services für Identitätsmanagement. Interessant sind zudem Analyse und Monitoring-Tools, die mit Hilfe von Machine-Learning-Algorithmen die IT-Landschaft nach verdächtigen Mustern durchleuchten und auf diese Weise Angreifer entdecken. Ob die Public Cloud jetzt sicherer ist als die Private Cloud oder ein klassisches Rechenzentrum, lässt sich pauschal nicht sagen. Dies hängt sehr stark davon ab, welche Aufgaben das im Vergleich stehende Rechenzentrum erfüllt und wie ausgebildet dessen Security-Maßnahmen bereits sind. Insgesamt bleiben auch im Bereich Sicherheit die bisher genannten Vorteile der Public Cloud bestehen: Kunden können ohne eigene Investitionen in Cybersecurity-Teams, Verschlüsselungs-Services und Netzwerksicherheit einfach die vorhandenen Security-Services und -vorkehrungen nutzen. Nutzen sie diese konsequent, können sie ein hohes Maß an Sicherheit schneller und mit weniger Aufwand erzeugen, als ihnen dies in Eigenverantwortung möglich wäre.

Sicherheitsebenen

Classic Zugriffspunkte der Endnutzer Identätsmanagement Applikaon

Werkzeuge und Mechanismen des eigenen Unternehmens

Werkzeuge des Providers, um eigenen Verantwortungsbereich zu schützen

SaaS

oder des klassischen Dienstleisters

Betriebssysteme, Datenbanken

PaaS IaaS

Physische Rechner Physisches Netzwerk

Cloud

Dedicated

Vertrauen in Provider und Zerfizierungen

Abb. 4.18   Verantwortungsbereiche für Sicherheit beim Outsourcing in die Cloud

120

4  Cloud – Die automatisierte IT-Wertschöpfung

4.8 Fallbeispiel: Ein teures Missverständnis im IT-Einkauf eines Großkonzerns Die Herausforderungen, vor denen Unternehmen im Kontext der Cloud-Transformation stehen, sollen im Folgenden anhand eines fiktiven Szenarios dargestellt werden. Als Beispiel dient ein europäischer Großkonzern mit 10 Mrd. EUR Umsatz pro Jahr und 500 Milo. EUR IT-Ausgaben. Dieser Konzern besitzt europaweit vier eigene Rechenzentren und hat seit einigen Jahren für mehrere Geschäftsbereiche Data-Center-Leistungen an zwei klassische Lieferanten ausgelagert. Der IT-Einkäufer des Unternehmens hat erfahren, dass sich mit der Cloud deutlich Kosten sparen lassen. Er identifiziert die größte Einzelposition im IT-Budget: Von den 500 Milo. EUR gibt der Konzern etwa 130 Milo. EUR für Infrastruktur-Leistungen (Rechner, Speicher, Netzwerk), über alle Rechenzentren verteilt, aus. Dort sind die größten Positionen wiederum die virtuellen Maschinen (Rechner). Er beschließt, die Kosten dieser größten Einzelposition zwischen den Cloud-Providern und auch mit den eigenen, klassischen Rechenzentren zu vergleichen. Die eigene IT ist diese Vergleiche aus der Vergangenheit gewohnt und schickt sofort eine Liste der wichtigsten VM-Typen mit Monatspreisen. Alle drei Cloud-Provider legen Einspruch gegen dieses Vorgehen ein. Sie bringen technische Experten mit zu den Einkaufsverhandlungen. Diese sprechen über Themen wie Auto-Elasticity, AWS Lambda und Container. Sie dozieren über eine neue Kultur und neues Denken. Kosten hingegen seien kein guter Grund, um in die Cloud zu gehen, es gehe eher um Agilität und Time-to-Market, Innovationen und Artificial Intelligence. Der IT-Einkäufer hält das für das geschäftsübliche Verhalten von Unternehmen, die eben nicht verglichen werden möchten, und drängt auf die Einhaltung seines Vorgehens: Alle teilnehmenden Cloud-Provider müssen exakt die gleichen virtuellen Maschinen anbieten, zu den exakt gleichen Rahmenbedingungen wie das interne Rechenzentrum. Wie sieht das Ergebnis aus? Die Cloud-Provider unterscheiden sich kaum, aber überrascht stellt der IT-Einkäufer fest: Viele Rechnertypen bietet das klassische Rechenzentrum sogar billiger an. Der Einkäufer kann es kaum glauben und geht wieder ins Gespräch mit den Cloud-Anbietern. Wie können so große Rechenzentren mit solchen Größenvorteilen ernsthaft teurer sein als seine eigenen, kleinen Data Center? Die Cloud-Provider erhöhen ihre Anstrengungen noch einmal: Sie wollen die komplette Führungsriege des Konzerns zu einem „Executive Briefing“ an die amerikanische Westküste einladen. Sie bieten kostenlose Architektur-Schulungen an, Governance-Seminare, gar kostenlose erste Projekte, und sie bieten sogar eigene Experten an, die diese Aufgaben übernehmen sollen. Nur: Die Preise wollen sie nicht senken. An welcher Stelle haben der IT-Einkäufer und die Cloud-Provider aneinander vorbeigeredet? Abb. 4.19 gibt einen Hinweis: Der IT-Einkäufer wollte eine wichtige Komponente der klassischen Wertschöpfung mit ihrem Pendant in der Cloud-IT vergleichen. Diese Komponente gibt es dort zwar, das Vorgehen aber hätte zur Folge, dass die Chancen der automatisierten IT-Wertschöpfung kaum genutzt würden – alle anderen Leistungen der

121

4.9  Von der klassischen IT zur Cloud – auf einer Seite …

Klassische Soware

Cloud-basierte Soware

Applikaonsbetrieb

Account Management

Betrieb der Betriebssysteme Datenbankbetrieb

Web App PaaS

Systembetrieb

Network

Storage

DatenbankCluster

Backup

VM1

VM2

Virtuelle Maschinen (VM) Compute

Diesen Vergleich wollte der ITEinkäufer anstellen.

Hiervon haben die CloudProvider gesprochen.

MySQL PaaS

?

Abb. 4.19   Infrastruktur-Komponenten sind bei Plattform-Services nicht mehr erkennbar

klassischen IT blieben ja weiterhin notwendig. Die Cloud-Provider haben also vergeblich versucht, den IT-Einkäufer von den Vorteilen der neuen Cloud-Welt zu überzeugen – eine IT-Welt, in der nicht nur zahlreiche Infrastrukturressourcen automatisiert genutzt werden können, sondern in der die ganze IT-Wertschöpfung automatisiert wird. Letztlich bleiben auf diese Weise die Optimierungspotenziale in vielen Unternehmen ungenutzt. Sie verbleiben auf ihren veralteten Software-Architekturen und verpassen gleichzeitig die Chancen zur Kostensenkung und Steigerung ihrer Innovationskraft. Im schlimmsten Falle wird der Wandel so lange hinausgezögert, bis neue Wettbewerber den Markt disruptieren und es zu spät für eine wirksame Wende ist.

4.9 Von der klassischen IT zur Cloud – auf einer Seite und in einem Bild erklärt Software bildet den Kern jedes digitalen Geschäftsmodells. Der Weg aber von der Geschäftsidee bis zu der dafür benötigten Software ist steinig. Unabhängig davon, ob die Software in einer klassischen IT-Umgebung oder in einer Cloud-Umgebung entwickelt wird, werden die drei Stufen: Software-Erstellung, Software-Betrieb und Software-Skalierung durchlaufen (s. Abb. 4.20). Die Cloud automatisiert die IT-Wertschöpfung. Möglich wird dies, indem die weiterhin notwendigen Infrastrukturressourcen (Rechner, Speicher, Netzwerk) über eine Software virtualisiert werden. Aus drei physischen Servern aus Blech, die im Keller des Unternehmens stehen, können 10 oder 20 virtuelle Rechner werden, die weiterhin alle Kalkulationen ausführen. Alle anderen Komponenten der IT-Wertschöpfung (wie etwa Datenbanken, Machine Learning Funktionen etc.) können in der Cloud abstrahiert, automatisiert und als Service angeboten werden. Jegliche Kommunikation zwischen diesen Wertschöpfungskomponenten läuft über definierte Programmierschnittstellen (APIs), die die Komplexität des Services kapseln und nur die benötigten Funktionalitäten den externen Anwendern zur Verfügung stellen.

122

4  Cloud – Die automatisierte IT-Wertschöpfung

Wie verändert die Cloud die Welt der digitalen Geschäsmodelle?

Klassische IT-Wertschöpfung

Cloud-basierte IT-Wertschöpfung

Soware erstellen …

Die vielen Fergteile beschleunigen die Entwicklung, verbliebene Tägkeiten fokussieren sich auf die primäre Wertschöpfung. Frühe Kundenfeedbacks geben InvestSicherheit.

Cloud automasiert die IT

… dauert lange, ist teuer und mit einem hohen Invest-Risiko verbunden.

Die wichgsten Chancen für Unternehmen entstehen durch: … die vielen IT-Fergteile

Soware betreiben …

µ€

… bedeutet meist ungenutzte Infrastruktur und viele Mitarbeiter in Supportprozessen.

Es wird keine ungenutzte Hardware mehr vorgehalten, ebenso sind kaum Mitarbeiter für IT-Supporunkonen notwendig. Vorhandene Mitarbeiter können auf die primäre Wertschöpfung fokussiert werden.

… die Nutzbarkeit in Mikrotransakonen … die Möglichkeit der globalen Skalierung

∝

Soware skalieren … … ist aufwendig in Absmmung und Umsetzung. Es lohnt kaum für kleine Änderungen.

Ressourcen werden automasiert nach Bedarf erhöht oder reduziert – jeweils in Mikrotransakonen. Die Grenzkosten für zusätzliche Nutzung und neue Kunden sinken auf faksch Null.

… direkte Synchronisaon von Kosten und Nutzen

Welche technischen Ansätze haben die Cloud-Welt ermöglicht?

Die Cloud Services nutzen vorhandene Hardware-Infrastrukturen und können somit jederzeit weltweit skalieren.

Netzwerk von CloudServices Ihre Soware

API

Verkehrs-

API Service

Compute

API

API

Weerservice

Ihre Soware Anfrage

Die API abstrahiert die dahinterliegende Komplexität und macht den Service effizient nutzbar.

Der Service ist selbst Soware und damit unendlich skalierbar.

Wie ist das Wetter in London?

API

Datenbank Service A

API

Storage

API Backup

Network

Antwort

Wolkig, 23° C und 80% Luftfeuchte

API Wetterservice in der Cloud

Bestellung, Konfiguraon und Skalierung erfolgen ebenfalls durch sowarebasierte Services – die wiederum von anderen Services genutzt werden können.

Jedes Element der IT-Wertschöpfung kann ein CloudService sein

Abb. 4.20   Von der klassischen IT zur cloudbasierten IT-Wertschöpfung

Diese Aufteilung der IT-Wertschöpfung in kleine, automatisierte Services sowie die Möglichkeit, aus der Kombination bekannter Services neue Services zu erstellen und diese weltweit auf der bestehenden Infrastruktur der Cloud-Provider zu skalieren,

Literatur

123

schafft eine komplett neue Welt der digitalisierten IT-Wertschöpfung. Auf diese Weise steht jedem Unternehmen ein reichhaltiger „Baumarkt“ an IT-Fertigteilen zur Verfügung, der investitionslos für den Aufbau digitaler Geschäftsmodelle genutzt werden kann. Die Leistungen werden in Mikrotransaktionen abgerufen. Der Vorteil: Kosten entstehen in der Public Cloud in der Regel nur bei tatsächlicher Nutzung des Leistungsspektrums. Die neue Welt der cloudbasierten IT verändert die Software-Prozesse radikal. Software-Erstellung ist deutlich schneller möglich (wegen der vielen Fertigteile) und gleichzeitig risikoärmer (Bezahlung nur bei Nutzung). Der Fokus der beteiligten Entwickler liegt bei der Nutzung der Cloud-Ressourcen voll auf den für das Geschäftsmodell relevanten Funktionen, die umfangreichen Supportaufgaben werden in die Cloud ausgelagert. Ist die Software im Betrieb angelangt, hält das Unternehmen selbst keine Hardware-Ressourcen für Lastspitzen mehr vor – die Skalierung der Ressourcen erfolgt automatisch. Darüber hinaus sind keine Mitarbeiter mehr für den aufwendigen Betrieb von IT-Komponenten notwendig. Das Geschäftsmodell kann dabei von Beginn an mit Null-Grenzkosten arbeiten und – im besonderen Erfolgsfall – auch weltweit problemlos skalieren. Unternehmen, die sich auf die neue Welt der automatisierten IT-Wertschöpfung einlassen, sind in der Lage, deutlich schneller, kostengünstiger, risikoärmer und innovativer digitale Geschäftsmodelle zu bauen, auszuprobieren und weltweit erfolgreich zu vermarkten.

Literatur Abel, Walter (2011): ITSM Rollen nach ITIL 2011, erschienen in: itsmprocesses.com, https:// www.itsmprocesses.com/Dokumente/ITIL%202011%20Glossar%20Rollen.pdf, abgerufen im Juni 2019. ACSC (2019): Implementing Multi-Factor Authentication, erschienen in: cyber.gov.au, https:// www.cyber.gov.au/publications/multi-factor-authentication, abgerufen im Juni 2019. Albach, Horst, Bernd Kaluza und Wolfgang Kersten (Hrsg.) (2002): Wertschöpfungsmanagement als Kernkompetenz, Gabler, Wiesbaden. Alt, Oliver (2008): Car Multimedia Systeme modellbasiert testen mit SysML, Vieweg und Teubner, Wiesbaden. Bhargava, Rajat (2017): Why Google IAM is Afraid of AD, erschienen in: jumpcloud.com, https:// jumpcloud.com/blog/google-identity-management-active-directory/, abgerufen im Juni 2019. Brewster, Thomas (2019): Alphabet’s Chronicle Startup Finally Launches—It’s Like Google Photos For Cybersecurity, erschienen in: forbes.com, https://www.forbes.com/sites/thomasbrewster/2019/03/04/alphabets-chronicle-startup-finally-launchesits-like-google-photos-for-cybersecurity/#5353d23d79c5, abgerufen im Juni 2019. Büst, René (2016): Serverless Infrastructure: Der schmale Grat zwischen Einfachheit und Kontrollverlust, erschienen in: crisp-research.com, https://www.crisp-research.com/serverless-infrastructure-der-schmale-grat-zwischen-einfachheit-und-kontrollverlust/, abgerufen im Juni 2019.

124

4  Cloud – Die automatisierte IT-Wertschöpfung

Cohen, Dova (2017): Microsoft to continue to invest over $1 billion a year on cyber security, erschienen in: reuters.com, https://www.reuters.com/article/us-tech-cyber-microsoft-idUSKBN15A1GA, abgerufen im Juni 2019. Dams, Jan (2017): So spionieren Geheimdienste deutsche Firmen aus, erschienen in: welt.de, https://www.welt.de/wirtschaft/article162217929/So-spionieren-Geheimdienste-deutscheFirmen-aus.html, abgerufen im Juni 2019. Deutsche Telekom (2019): Magenta Cloud, erschienen in: cloud.telekom-dienste.de, https://cloud. telekom-dienste.de/, abgerufen im Juni 2019. Fehling, Christoph und Frank Leymann (2018): Cloud Computing, erschienen in: wirtschaftslexikon.gabler.de, https://wirtschaftslexikon.gabler.de/definition/cloud-computing-53360/version-276453, abgerufen im Juni 2019. Fisher, Cameron (2018): Cloud vs. On-Premise Computing, erschienen in: American Journal of Industrial and Business Management, Nr. 8/2018, S. 1991–2006. Fraunhofer (2019): Was bedeutet Public, Private und Hybrid Cloud?, erschienen in: cloud.fraunhofer.de, https://www.cloud.fraunhofer.de/de/faq/publicprivatehybrid.html, abgerufen im Juni 2019. Gallagher, Sean (2014): Photos of an NSA „upgrade“ factory show Cisco router getting implant, erschienen in: arstechnica.com, https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsaupgrade-factory-show-cisco-router-getting-implant/, abgerufen im Juni 2019. Gaugler, Eduard (2002): Taylorismus und Technologischer Determinismus, erschienen in: Albach et al. (2002), S. 165-181. Google (2019): AI and machine learning products, erschienen in: cloud.google.com, https://cloud. google.com/products/ai/, abgerufen im Juni 2019. Haberstroh, Tom (2016): The Year of Steph Curry, erschienen in: espn.com, http://www.espn.com/ espn/feature/story/_/id/15492948/the-numbers-steph-curry-incredible-mvp-season, abgerufen im Juni 2019. Hart, John (2017): It’s Still The Economy, Stupid, erschienen in: forbes.com, https://www.forbes. com/sites/johnhart/2017/12/27/its-still-the-economy-stupid/#722176512c9a, abgerufen im Juni 2019. Hart, Mark A. (2015): The truth about „any color so long as it is black“, erschienen in: oplaunch.com, http://oplaunch.com/blog/2015/04/30/the-truth-about-any-color-so-long-as-it-is-black/, abgerufen im Juni 2019. Hiles, Andrew (2016): The Complete Guide to I.T. Service Level Agreements: Aligning It Services to Business Needs (Service Level Management), Rothstein Publishing, Brookfield. Hu, Xinyao und Liang Guo (2018): A Chronicle of Airbnb Architecture Evolution, Vortrag im Rahmen der Konferenz AWS re: Invent, erschienen in: de.slideshare.net, https://de.slideshare.net/ AmazonWebServices/a-chronicle-of-airbnb-architecture-evolution-arc407-aws-reinvent-2018, abgerufen im Juni 2019. IBM (2019): Nutzen Sie das Potenzial von KI mit IBM Watson, erschienen in: ibm.com, https:// www.ibm.com/de-de/cloud/ai, abgerufen im Juni 2019. ITWissen (2014): RTE (runtime environment), erschienen in: itwissen.info, https://www.itwissen. info/RTE-runtime-environment-Laufzeitumgebung.html, abgerufen im Juni 2019. Kaczenski, Nils (2010): Never change a running system? Bullshit!, erschienen in: faq-o-matic.net, https://www.faq-o-matic.net/2008/02/20/never-change-a-running-system-bullshit/, abgerufen im Juni 2019. Kelly, Michael (1992): THE 1992 CAMPAIGN: The Democrats – Clinton and Bush Compete to Be Champion of Change; Democrat Fights Perceptions of Bush Gain, erschienen in: nytimes. com, https://www.nytimes.com/1992/10/31/us/1992-campaign-democrats-clinton-bush-compete-be-champion-change-democrat-fights.html, abgerufen im Juni 2019.

Literatur

125

Kling, Bernd (2019): Daten-Leak: 20-jähriger Hacker geständig, erschienen in: zdnet.de, https:// www.zdnet.de/88351153/daten-leak-20-jaehriger-hacker-gestaendig/, abgerufen im Juni 2019. Kühl, Eike (2018): Wer hat Angst vor Huawei?, erschienen in: zeit.de, https://www.zeit.de/digital/mobil/2018-02/smartphones-china-huawei-zte-mate-10-spionage-risiken/komplettansicht, abgerufen im Juni 2019. Kurzlechner, Werner (2019): Was ist was bei ITIL und ITSM?, erschienen in: cio.de, https://www. cio.de/a/was-ist-was-bei-itil-und-itsm,3258078, abgerufen im Juni 2019. Lackes, Richard, Astrid Meckel und Markus Siepermann (2018): Datenbank, erschienen in: wirtschaftslexikon.gabler.de, https://wirtschaftslexikon.gabler.de/definition/datenbank-30025/version-253619, abgerufen im Juni 2019. Lane, Kin (2012): The Secret to Amazon’s Success–Internal APIs, erschienen in: apievangelist.com, https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/, abgerufen im Juni 2019. Luber, Stefan und Stephan Augsten (2017): Was ist eine API?, erschienen in: dev-insider.de, https://www.dev-insider.de/was-ist-eine-api-a-583923/, abgerufen im Juni 2019. Luber, Stefan und Florian Karlstetter (2017a): Was ist Microsoft Azure?, erschienen in: cloudcomputing-insider.de, https://www.cloudcomputing-insider.de/was-ist-microsoft-azure-a-667912/, abgerufen im Juni 2019. Luber, Stefan und Florian Karlstetter (2017b): Was ist eine Private Cloud?, erschienen in: cloudcomputing-insider.de, https://www.cloudcomputing-insider.de/was-ist-eine-private-cloud-a-631415/, abgerufen im Juni 2019. Luber, Stefan und Peter Schmitz (2017): Was ist ein DDoS-Angriff?, erschienen in: security-insider.de, https://www.security-insider.de/was-ist-ein-ddos-angriff-a-672826/, abgerufen im Juni 2019. Macaulay, Tom (2018): Ten years on: How Netflix completed a historic cloud migration with AWS, erschienen in: computerworlduk.com, https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/, abgerufen im Juni 2019. Mather, Victor (2016): How the N.B.A. 3-Point Shot Went From Gimmick to Game Changer, erschienen in: nytimes.com, https://www.nytimes.com/2016/01/21/sports/basketball/how-thenba-3-point-shot-went-from-gimmick-to-game-changer.html, abgerufen im Juni 2019. Mell, Peter und Tim Grance (2011): The NIST Definition of Cloud Computing, erschienen in: csrc. nist.gov, https://csrc.nist.gov/publications/detail/sp/800-145/final, abgerufen im Juni 2019. Metzger, Axel (2001): Software-Bibliotheken, erschienen in: linux-magazin.de, https://www. linux-magazin.de/ausgaben/2001/03/freiheit-den-bibliotheken/, abgerufen im Juni 2019. Microsoft (2019): Compliance Offerings, erschienen in: microsoft.com, https://www.microsoft. com/en-us/trustcenter/compliance/complianceofferings, abgerufen im Juni 2019. Mitschele, Andreas (2018): Blockchain, erschienen in: wirtschaftslexikon.gabler.de, https://wirtschaftslexikon.gabler.de/definition/blockchain-54161/version-277215, abgerufen im Juni 2019. Novet, Jordan (2019): Amazon Web Services reports 45 percent jump in revenue in the fourth quarter, erschienen in: cnbc.com, https://www.cnbc.com/2019/01/31/aws-earnings-q4-2018. html, abgerufen im Juni 2019. Olbrich, Alfred (2004): ITIL kompakt und verständlich: Effizientes IT Service Management – Den Standard für IT-Prozesse kennenlernen, verstehen und erfolgreich in der Praxis umsetzen, Vieweg und Teubner, Wiesbaden. Olleros, Xavier F. und Majlinda Zhegu (Hrsg.) (2016): Research Handbook on Digital Transformations, EE Publishing, Cheltenham.

126

4  Cloud – Die automatisierte IT-Wertschöpfung

Ostler, Ulrike (2018): Die Plusserver GmbH bietet eine Bare-Metal-Cloud und Cloud-Optimierung, erschienen in: DataCenter Insider, https://www.datacenter-insider.de/die-plusservergmbh-bietet-eine-bare-metal-cloud-und-cloud-optimierung-a-724682/. Pilkington, Marc (2016): Blockchain Technology: Principles and Applications, erschienen in: Olleros, Zhegu (2016), S. 225–253. Rojas, Alec (2017): A Brief History of AWS, erschienen in: mediatemple.net, https://mediatemple. net/blog/news/brief-history-aws/, abgerufen im Juni 2019. Rouse, Margaret (2016): Ransomware, erschienen in: computerweekly.com, https://www.computerweekly.com/de/definition/Ransomware, abgerufen im Juni 2019. Royce, Winston W. (1970): Managing the development of large software systems, erschienen in: IEEE WESCON, S. 328–338. Salesforce (2019): Entdecken Sie die weltweit führende Marketingplattform für intelligente Customer Journeys, erschienen in: salesforce.com, https://www.salesforce.com/de/products/marketing-cloud/overview/#, abgerufen im Juni 2019. SAP (2019): SAP Hybris – Commerce Cloud, erschienen in: sap.com, https://www.sap.com/germany/documents/2017/08/d0f22d3d-cd7c-0010-82c7-eda71af511fa.html, abgerufen im Juni 2019. Schirrmacher, Dennis (2019): Gehackte Websites: 620 Millionen Accounts zum Verkauf im Darknet, erschienen in: heise.de, https://www.heise.de/security/meldung/Gehackte-Websites-620-Millionen-Accounts-zum-Verkauf-im-Darknet-4305517.html, abgerufen im Juni 2019. Siegmann, Nate (2017): Pokemon GO Paved Way for Mobile Gaming, erschienen in: mynorsecode.com, http://mynorsecode.com/2017/10/17/pokemon-go-paved-way-for-mobile-gaming/, abgerufen im Juni 2019. Spiegel.de (2017): „WannaCry“-Attacke – Fakten zum globalen Cyberangriff, erschienen in: spiegel.de, https://www.spiegel.de/netzwelt/web/wannacry-attacke-fakten-zum-globalen-cyber-angriff-a-1147523.html, abgerufen im Juni 2019. Strathmann, Marvin (2015): Google weiß, was Sie letzten Sommer getan haben, erschienen in: focus.de, https://www.focus.de/digital/internet/datenkrake-ueberlisten-google-weiss-was-sie-letzten-sommer-getan-haben_id_4037493.html, abgerufen im Juni 2019. Tyson, Matthew (2018): What is the JRE? Introduction to the Java Runtime Environment, erschienen in: javaworld.com, https://www.javaworld.com/article/3304858/what-is-the-jre-introduction-to-the-java-runtime-environment.html, abgerufen im Juni 2019. Weidemann, Tobias (2018): Cyber Monday und Co.: Wie sich Kunden optimal auf die Verkaufsschlacht vorbereiten, erschienen in: t3n.de, https://t3n.de/news/cyber-monday-kunden-shopping-1125845/, abgerufen im Juni 2019. Wiehr, Hartmut (2015): Die 10 größten Vorteile von Server-Virtualisierung, erschienen in: computerwoche.de, https://www.computerwoche.de/a/die-10-groessten-vorteile-von-server-virtualisierung,2296941, abgerufen im Juni 2019. Zores, Robert und Marco Koppik (2019): Multi-Cloud Blockchain in the Food Sector, Vortrag im Rahmen einer gemeinsamen Konferenz von Rewe und Arvato, erschienen in: logistik.tu-berlin.de, https://www.logistik.tu-berlin.de/fileadmin/fg175/Downloads/190412_09_Koppik_Multi-Cloud_Blockchain_in_the_Food_Sector-TU_Berlin-short.pdf, abgerufen im Juni 2019.

5

Cloud-IT vs. klassische IT – Kalkulation für den Controller

Zusammenfassung

Software-Applikationen haben einen großen Einfluss auf die Kostenstruktur der Geschäftsmodelle von Unternehmen. Die Kosten, die bei der Entwicklung der Applikation entstehen, bestimmen wesentlich das Investitionsrisiko. Die fixen Kosten für den Betrieb und das Vorhalten von IT-Ressourcen beeinflussen vor allem die frühen Phasen der Geschäftsentwicklung. Die Grenzkosten werden besonders relevant, wenn das Geschäftsmodell skaliert, also wächst – zum Beispiel global: Sind die Grenzkosten niedriger als jene der Wettbewerber, wird bei gleichen Marktpreisen ein höherer Gewinn erwirtschaftet und Preiskämpfe können besser durchgestanden werden. Alle genannten Kostenfaktoren können durch die Transformation einer OnPrem-Applikation in eine Cloud-Applikation maßgeblich verbessert werden. Der durch die Migration anfallende Aufwand wird in der Regel nach einer gewissen Zeit durch die Vorteile überkompensiert – insbesondere dann, wenn die durch die Transformation entstehenden Wettbewerbsvorteile für das Kerngeschäft besonders relevant sind.

5.1 Ein praktisches Beispiel: Outsourcing des Rechnungsmanagements Die veränderten Erträge und Kosten entscheiden letztlich über die Frage, ob ein Geschäftsmodell in der Cloud aufgebaut werden soll oder nicht. Im Zweifelsfall steht der Kollege aus dem Controlling in Ihrer Tür und bittet Sie um eine Kalkulation der wirtschaftlichen Parameter, die sich durch die Nutzung einer Unternehmens-Applikation in der Cloud verändern. Eine solche Kalkulation wird im folgenden Abschnitt anhand eines realen Beispiels dargestellt: Dazu beschreiben wir zunächst das Geschäftsmodell eines Dienstleisters, der eine spezifische Applikation auf einer klassischen, logischen © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_5

127

128

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Internaonaler Kunde

Rechnungen

Scannen

Zuordnen

Prüfen

Bearbeiten Überweisung

€

Prozess-Management für Einkaufsrechnungen

Abb. 5.1    Geschäftsmodell eines Dienstleisters zum „Prozess-Management für Einkaufsrechnungen“

Architektur betreibt. In einem zweiten Schritt wird diese Applikation einer Cloud-Variante gegenübergestellt. Dazu werden die relevanten Maßnahmen der Cloud-Migration kurz erläutert, die neuen Kostenstrukturen1 dargestellt und mit jenen der klassischen Anwendung verglichen. Abb. 5.1 zeigt den Wertschöpfungsprozess eines Dienstleisters, der für seine Kunden das Management der Einkaufsrechnungen übernimmt: Ein Kunde übergibt die in Papierform und digital eintreffenden Rechnungen seiner Lieferanten an den Dienstleister. Dieser scannt – falls notwendig – die Belege und bringt sie in eine einheitliche Form. Danach werden die grundlegenden Informationen zu den Rechnungen erfasst, damit sie den richtigen Sachbearbeitern je nach Fachgebiet, Land und Sprache zugeordnet werden können. Die Sachbearbeiter prüfen die Rechnungen und entscheiden über das weitere Vorgehen: Entweder werden Überweisungen veranlasst, die Belege intern anderen Mitarbeitern zugeordnet oder an den Kunden zurückgeschickt. Der Dienstleister hat in diesem Geschäftsmodell einige Herausforderungen zu bewältigen (s. Abb. 5.2), bei denen ihn seine IT-Applikation unterstützt: • Viele unterschiedliche Kunden: Der Dienstleister möchte gleichzeitig mehr als nur einen Kunden bedienen. Einerseits müssen bei der Verarbeitung die Informationen zu den einzelnen Kunden strikt getrennt bleiben, andererseits soll die Anwendung aus

1Die

genannten Kosten für die alte Applikation basieren auf tatsächlichen Kalkulationen eines klassischen Rechenzentrums aus dem Jahr 2015. Die Kosten der neuen Applikation basieren auf den Preisen von Microsoft Azure im April 2019.

5.1  Ein praktisches Beispiel: Outsourcing des Rechnungsmanagements

Viele und unterschiedliche Kunden

129

Global verteilte Delivery

Schwankende Aufgabenlast

Viele individuelle Skills Sehr spezifische Prozesse

Abb. 5.2   Herausforderungen des globalen Outsourcings des Managements von Einkaufsrechnungen

•

• •

•

Kostengründen nicht für jeden Kunden separat betrieben werden. Zudem hat jeder Kunde unterschiedliche Anforderungen an den Prozess, und vor allem müssen diese Prozesse mit den IT-Systemen der Kunden kompatibel sein. Schwankende Aufgabenlast: Die Menge der zu bearbeitenden Vorgänge schwankt stark. Am höchsten ist die Last im Zuge der Quartals- und Jahresabschlüsse, in den Monaten dazwischen ist die Auslastung eher niedrig. Die Aufgabenlast muss zu jedem Zeitpunkt von der Belegschaft abgearbeitet werden können. Spezifische Prozesse: Die Prozesse sind für jeden Kunden und für jeden Lieferanten des Kunden individuell und hängen von vielen weiteren Faktoren ab. Unterschiedliche Skills: Es gibt sehr vielfältige Anforderungen an die Fähigkeiten der Mitarbeiter. Einige Aufgaben sind sehr einfach und verlangen nur wenige Qualifikationen, für andere ist wiederum eine spezifische Ausbildung nötig und dementsprechend können sie nur von wenigen Mitarbeitern ausgeführt werden. Global verteilte Delivery: Die Kunden selbst sind globale Unternehmen und benötigen einen Dienstleister, der ebenso globalisiert aufgestellt ist. Die Einkaufsrechnungen müssen in unterschiedlichen Sprachen und nach spezifischen rechtlichen Rahmenbedingungen bearbeitet werden.

Die Software hat maßgeblichen Einfluss auf die Art und Weise, wie der Dienstleister auf diese Herausforderungen reagieren kann. Werden die IT-Schnittstellen des Kunden gut bedient, sinkt der Aufwand zu Beginn des Projekts, sowohl beim Kunden als auch beim Dienstleister. Werden die Kunden auf Software-Ebene sicher getrennt (eine sogenannte „Mandantentrennung“), müssen nicht verschiedene Hardware-Umgebungen bereitgehalten werden und die Gesamtkosten für den laufenden Betrieb sinken deutlich.

130

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Lassen sich die individuellen Prozesse des Kunden gut in der Software berücksichtigen, kann stärker automatisiert werden und der Personalaufwand sinkt. Sofern die Mitarbeiter und ihre Fähigkeiten gut im System abgebildet werden können, lässt sich die schwankende Arbeitslast besser über die vielen Delivery-Standorte verteilen und die Gesamtkosten sinken. Die Qualität dieser Prozess-Management-Anwendung hat demnach großen Einfluss auf die Wettbewerbsfähigkeit des Dienstleisters.

5.2 Leistungsmerkmale der klassischen Applikation Die Applikation des Dienstleisters besteht aus sechs logischen Einheiten (s. Abb. 5.3): • Über die Darstellungsschicht können die Mitarbeiter der Kunden mit der Anwendung interagieren • Eine zweite Darstellungsschicht unterstützt die Mitarbeiter des Dienstleisters bei ihrer Arbeit • Ein Bereich kümmert sich um die Integration der Anwendung in die IT-Landschaft des Kunden • Mit umfassenden Reporting-Funktionen wird die Transparenz für alle Stakeholder sichergestellt

Darstellungsschicht

Darstellungsschicht

für den Kunden

Integraon in Kundensysteme

für den Mitarbeiter

Reporng

Prozesslogik

KundenSysteme

Datenhaltung Abb. 5.3   Logische Architektur der Applikation

Speicher

Datenbanken

5.2  Leistungsmerkmale der klassischen Applikation

131

• In der eigentlichen Prozesslogik sind die Prozessschritte der Rechnungsbearbeitung abgebildet und teilweise automatisiert • Auf der Ebene der Datenhaltung werden die Dokumente im Speicher abgelegt und die Vorgangsdaten in Datenbanken vorgehalten

5.2.1 Architektur und fixe Betriebskosten Im Ausgangsszenario wird die Applikation in einem klassischen Rechenzentrum betrieben, gemäß Abb. 4.9 in Abschn. 4.4.4 handelt es sich um den Automatisierungsgrad „Virtualized“. Dies bedeutet, dass lediglich die Rechenleistung mithilfe sogenannter Virtual Machines (VM) virtualisiert und mit anderen Kunden geteilt wird. Alle anderen Komponenten wie Netzwerk, Speicher, Datenbanken und Betriebssystem werden – ­einhergehend mit den in Kap. 4 beschriebenen Nachteilen – auf klassische Art und Weise bereitgestellt. Für diese Anwendung bedeutet das konkret, dass 20 Server mit insgesamt 120 Prozessoren, 686 GB Arbeitsspeicher und 22 TB Datenspeicher zur Verfügung gehalten werden. Diese Kapazitäten werden unabhängig von der tatsächlichen Nutzung der Anwendung bereitgestellt und basieren weitestgehend auf einer Abschätzung des erwarteten maximalen Bedarfs. Dieser Bedarf wurde, anhand der Erfahrungen der beteiligten Personen, auf etwa drei Millionen Transaktionen pro Monat angesetzt. Tab. 5.1 zeigt eine beispielhafte Kalkulation für den Betrieb dieser Applikation. Die dafür angesetzten Kosten entsprechen Erfahrungswerten und basieren auf einer aktuellen Kalkulation (Stand 2019). Die mit Abstand größte einzelne Kostenposition ist mit fast 30.000 EUR der BizTalk-Server. Dabei handelt es sich um ein von Microsoft bereitgestelltes Werkzeug, das speziell darauf ausgelegt ist, Nachrichten zwischen verschiedenen Anwendungen innerhalb großer Unternehmen auszutauschen (Huffmann 2009). Der BizTalk-Server ist also die Grundlage für die Automatisierung von applikationsübergreifenden Prozessen. Die nächstgrößeren Kostenpositionen sind die Datenbanken (SQL Server) mit etwa 5000 EUR sowie der Betrieb der Gesamtapplikation mit etwa 4500 EUR. Weitere Systemkomponenten wie Firewalls und Tools für das Nutzermanagement (Active Directory) summieren sich auf über 7000 EUR. Der Gesamtbetrag von über 50.000 EUR ist weitestgehend ein fixer Kostenblock. Der Dienstleister ist also in seinem Geschäftsmodell auf hohe und fest planbare Einnahmen angewiesen, oder er geht das Risiko ein, defizitär und ineffizient zu arbeiten, wenn es weniger Eingangsrechnungen gibt. Aufgrund seiner fixkostenorientierten Kostenstruktur wird der Dienstleister versuchen, mit seinen Kunden möglichst hohe Fixpreise zu vereinbaren. Diese sind wiederum ein Risiko für den Kunden, denn er kann sich nicht sicher sein, ob das Outsourcing des Rechnungsmanagements tatsächlich die erhofften inter-

132

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Tab. 5.1  Kalkulation der alten Applikation Bis zu 3 Mio. Transaktionen pro Monat

Anzahl

CPU

RAM GB

GB

Darstellungsschicht – Web Server

2.569,60 € 4

4

14

2.569,60 €

Prozesslogik – Biztalk Server

29.900,80 € 4

64

512

29.900,80 €

Datenhaltung – SQL Server

Gesamt

7.774,60 € 6

16

80

– Storage

4.905,60 € 22.000

Weitere Systemkomponenten

2.869,00 € 7.189,05 €

– MSMQ (Message Queue)

2

4

16

350,40 €

– Active Directory

2

16

32

934,40 €

– Active Directory B2C

2

16

32

934,40 €

– Load Balancer

1

990,09 €

– Firewall

2

2.586,20 €

– DDOS Protection

1

1.026,15 €

– Private Network DMZ

1

367,41 €

Operations

5.726,84 €

– Betrieb der Anwendung – Support der Nutzer Summen

4.470,44 € 1

1.256,40 € 120

686

22.000

53.160,89 €

nen Einsparungen bringt. Diese gegensätzlichen Interessen verursachen in klassischen Vertragsverhandlungen einige Diskussionen und nehmen dementsprechend viel Zeit in Anspruch.

5.2.2 Aufbau und Ausbau der Applikation Bis die Applikation an die Bedürfnisse eines neuen Kunden angepasst ist, vergehen im positiven Falle etwa sechs Monate. Meistens benötigen Kunde und Dienstleister etwa sechs Wochen, um die richtigen Mitarbeiter für das Team zu finden, von den aktuellen Aufgaben zu befreien und das Projekt zu beginnen. Dazu kommen weitere sechs Wochen für Detailplanung und Bestellprozesse sowie weitere zwei Monate für die Projektdurchführung. Ein zusätzlicher Monat ist eingeplant für Tests und die Durchführung von

6

Betrieb und Projekte

90,000 €

Monatliche Kosten

80,000 €

5

70,000 €

4

60,000 € 50,000 €

3

40,000 € 30,000 €

2

Transakonen

20,000 €

1

Transakonen (in Millionen)

100,000 €

Millions

133

5.2  Leistungsmerkmale der klassischen Applikation

10,000 € - €

Jul-18

Jan-19

Jul-19 Jahr 1

Jan-20

Jul-20 Jahr 2

Jan-21

Jul-21 Jahr 3

0

Abb. 5.4   Anzahl der Transaktionen und monatliche Kosten für IT

Änderungen. Die kostenintensiven Infrastruktur-Ressourcen müssen schon früh im Projekt bereitstehen, um die Prozesse einzurichten und die Durchführung der Transaktionen zu testen. Erst wenn die Anwendung in den Echtbetrieb geht, steigt die Anzahl der Transaktionen auf jenes Niveau, für das die Infrastruktur ausgelegt ist (s. Abb. 5.4). Ein typischer Transaktionsverlauf sieht etwa so aus: Ab Januar des ersten Jahres beginnt der Kunde, eine relevante Anzahl von Transaktionen auf dem System durchzuführen. Gegen Jahresende gibt es aufgrund des Jahresabschlusses die meisten Transaktionen, in den Sommermonaten hingegen die wenigsten. Im Verlauf des zweiten Jahres bezieht der Kunde mehr Ländergesellschaften in das Outsourcing des Einkaufsprozesses ein. Dadurch erreicht die Anzahl der Transaktionen im Dezember des zweiten Jahres mit über fünf Millionen ihren vorläufigen Höhepunkt. Die IT-Gesamtkosten setzen sich aus den monatlichen IT-Betriebskosten (Abschn. 5.2.1) und den anfallenden Projektkosten zusammen. Neben dem Aufbauprojekt vor Beginn des ersten Jahres (Kosten: 210.000 EUR) gibt es eine zweite größere Aufgabe für die Mitarbeiter im Systembetrieb: Im Laufe des zweiten Jahres steigt durch das Onboarding der zusätzlichen Ländergesellschaften des Kunden die Anzahl der Transaktionen über die Drei-Millionen-Marke. Im zweiten Halbjahr beginnt der Dienstleister daher, die Infrastruktur auszubauen: In einem etwa drei Monate dauernden Projekt wird die Anwendung an den Bedarf der zusätzlichen Ländergesellschaften angepasst – das kostet rund 105.000 EUR. Dieser Aufwand verteilt sich einerseits auf Mitarbeiter, die sich um die Beschaffung und den Aufbau der zusätzlichen Infrastruktur kümmern (Einkäufer, Administratoren, Infrastruktur-Architekten und Projektleiter) und andererseits auf Mitarbeiter, die sich um die Einrichtung der neuen Einkaufssteuerungsprozesse kümmern (Prozessexperten, Entwickler, Projektleiter).

134

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Abb. 5.4 zeigt, dass sich die Kosten über die gesamte Laufzeit von dreieinhalb Jahren weitestgehend unabhängig von der Anzahl der Transaktionen bewegen. Am Anfang gibt es einen großen Kostenblock bei vergleichsweise geringem Geschäftsnutzen. Es handelt sich dabei um sprungfixe Kosten, die anfallen, wenn die Infrastruktur ausgebaut wird und/oder die Outsourcing-Prozesse um ein Projekt ergänzt werden.

5.2.3 Durchschnitts- und Grenzkosten Eine relevante Größe bei der Skalierung von klassischen Applikationen ist die Kapazitätsgrenze der bestehenden Infrastruktur. In diesem Beispiel wurde sie zunächst auf drei Millionen Transaktionen pro Monat geschätzt und muss gegen Ende des zweiten Jahres auf sechs Millionen erweitert werden. In der Realität sind solche Abschätzungen deutlich schwieriger zu treffen, da die Transaktionen nicht gleichmäßig über die Tage eines Monats und die Stunden eines Tages verteilt sind. Zudem können Engpässe auch in einzelnen Komponenten wie etwa der Benutzeroberfläche oder der Datenbank auftreten und alle anderen Teile der Applikation in ihrer Funktionsfähigkeit lähmen. Dieses Problem tritt vor allem bei monolithischen Applikationen auf, auf die in Kap. 6 eingegangen wird. Sowohl theoretisch wie auch praktisch ist davon auszugehen, dass durch die höhere Auslastung Probleme auftreten: Die Anwendung wird langsamer, möglicherweise fällt das System auch immer wieder zur Gänze aus – der Ausbau lässt sich also nicht mehr vermeiden. Mit zunehmender Nutzungsdauer sinken die Durchschnittskosten stark und schwanken entgegengesetzt zur Entwicklung der Transaktionen (s. Abb. 5.5). Die Aufbaukosten zu Beginn der Vertragslaufzeit fallen stark ins Gewicht, der Aufwand für den Ausbau der Infrastruktur ändert die Durchschnittskosten dagegen kaum. 6

Transakonen

Kapazitätsgrenze

1

4 3 2

0.1

Durchschniskosten 0.01

Jul-18

Jan-19

Jul-19 Jahr 1

Jan-20

Jul-20 Jahr 2

Jan-21

Jul-21 Jahr 3

Abb. 5.5   Durchschnittskosten je Monat sowie Kapazitätsgrenzen der alten Applikation

1 0

in Millionen

10

Transakonen

5

pro Transkaon

Durchschniliche Kosten (€)

100

5.3  Die Cloud-Transformationder Applikation

135

100

6

Kapazitätsgrenze

1

3

Anzahl Transakonen

0.1

2

Grenzkosten 0.01

Jun-18

Dec-18

Jun-19 Jahr 1

Dec-19

Jun-20 Jahr 2

Dec-20

Jun-21

in Millionen

4

Transakonen

Grenzkosten (€)

5 10

1 0

JahrDec-21 3

Abb. 5.6   Grenzkosten in der alten Applikation

Die Grenzkosten des Unternehmens im Ausgangsszenario lassen sich nicht sinnvoll genauer analysieren. Die Kostenstruktur ist weitestgehend fix. Lediglich zum Zeitpunkt des Ausbaus der Infrastruktur ergibt sich ein sehr hoher Ausschlag von zusätzlich 20.000 EUR pro Monat. Danach lassen sich bis zu sechs Millionen Transaktionen pro Monat abbilden und die Grenzkosten liegen wieder eine gewisse Zeit lang bei Null (s. Abb. 5.6). Zusammenfassend lässt sich sagen, dass die alte Applikation zwar einerseits in einem definierten Bereich mit Null-Grenzkosten operieren kann, dieser Vorteil wird aber durch hohe Einmalaufwände in der Vorbereitungsphase sowie mit hohen fixen Kosten in der Betriebsphase erkauft.

5.3 Die Cloud-Transformationder Applikation In der Praxis beginnt der Prozess der Cloud-Transformation mit einer Applikationsanalyse durch den Cloud-Solution-Architect. Dieser untersucht die Anforderungen des Kunden, das Geschäftsmodell, die aktuelle Preis- und Kostenstruktur, die Anforderungen des Betriebs sowie Sicherheits- und Compliance-Themen. Abhängig von der aktuellen Architektur der Anwendung und von den Chancen, die sich aus den bestehenden Services der Cloud-Provider ergeben, werden dann verschiedene Migrationsoptionen durchgespielt. Für den beschriebenen Fall ergibt sich eine klare Empfehlung (s. Abb. 5.7): Fünf der sechs Teile der Applikation können mit wenigen Änderungen von klassischen Infrastrukturkomponenten (z. B. WebServer, SQL Server, Firewall) auf entsprechende Platform-Services der Cloud-Provider überführt werden. Diese Platform-Services bieten

136

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller Alle Teile der Applikaon werden auf jeweils passende Plaorm-Services gehoben.

Plaorm-Services PaaS

Prozesslogik muss neu erstellt werden

Abb. 5.7   Migrationskonzept für die Outsourcing-Anwendung

mehrere Vorteile: Zum einen lassen sie sich so programmieren, dass sie ihre Leistung automatisch an die tatsächliche Nachfrage anpassen („Autoscaling“), zum anderen entfallen durch den Übergang in die Cloud große Teile des Betriebsaufwands. Eine 1:1-Überführung („Rehost“) des BizTalk-Servers, der die Prozesslogik abbildet, auf Infrastruktur-Services (IaaS) wäre zwar technisch möglich, die eingehende Analyse der Situation eröffnet aber eine weitere Option. Der Cloud-Provider Microsoft bietet für die Abbildung von Prozesslogiken sogenannte „Logic Apps“ (Microsoft 2019). Diese dienen dazu, komplexe unternehmerische Prozesse übergreifend über verschiedene Anwendungen abzubilden und – soweit möglich – zu automatisieren. Um Abläufe zu erstellen und zu verbessern, waren in der alten Anwendung noch teure Programmierer notwendig – mit Logic Apps hingegen können die Prozessexperten ohne bzw. mit wenigen Programmierkenntnissen („Low Code“) selbst Änderungen vornehmen. Eine Migration der BizTalk-basierten Anwendung bietet demnach zwei Vorteile: • Der Fixkostenblock wird zugunsten von Platform-Services aufgelöst, die transaktionsbasiert abgerechnet werden. Der Preis je Aktion liegt bei 0,000.022 EUR (Stand Mai 2019). • Da ausgebildete Sachbearbeiter ihre eigenen Prozesse anlegen und verbessern können, wird ein unternehmerischer Engpass im Tagesgeschäft aufgelöst. Dadurch fällt der abteilungsübergreifende Kommunikationsaufwand mit den Programmierern weg. Wenn Änderungen notwendig sind, können sie schneller und mit weniger Aufwand durchgeführt werden. Insgesamt verändern sich die Kostenstrukturen der Anwendung deutlich. Tab. 5.2 zeigt, dass die meisten Kostenkomponenten im zweiten Anwendungsszenario in der neuen cloudbasierten Applikation nutzungsbasiert abgerechnet werden.

5.3  Die Cloud-Transformationder Applikation

137

Tab. 5.2  Veränderte Kostenstrukturen in der neuen Applikation Kostenstruktur der alten Applikation

Kostenstruktur der neuen Applikation

Darstellungsschicht Web Server

Fixe Kosten pro Monat Web Server

Basis-Leistung als fixe Kosten. Zusätzlich benötigte Leistung wird sekundengenau abgerechnet

Biztalk Server

Fixe Kosten pro Monat Logic Apps

Kosten abhängig von der Anzahl der Transaktionen sowie von der Anzahl der Konnektoren

Message Queue (MSMQ)

Fixe Kosten pro Monat Service Bus

Kosten abhängig von der Anzahl der Nachrichten

Fixe Kosten pro Monat Azure SQL Database

Fixe Kosten pro Monat (transaktionsbasierte Varianten sind ebenfalls möglich)

Prozesslogik

Datenhaltung SQL Server

Storage Fixe Kosten pro Monat Storage Weitere Systemkomponenten

Nach Usage

Active Directory

Fixe Kosten pro Monat Azure Active Directory

Nach Anzahl der User

Active Directory B2C

Fixe Kosten pro Monat Azure Active Directory B2C

Nach Anzahl der Authentifikationen

Load Balancer

Fixe Kosten pro Monat Application Gateway

Nach Stunden und Menge des Datentransfers

Firewall

Fixe Kosten pro Monat Azure Firewall

Nach Stunden und Menge des Datentransfers

DDOS Protection

Fixe Kosten pro Monat Azure DDoS Protection

Fixe Kosten pro Monat zzgl. Anzahl der zu schützenden Ressourcen (wenn mehr 100)

Private Network DMZ Fixe Kosten pro Monat Outbound Traffic Operations

Abhängig vom Traffic

Betrieb der Anwendung

Fixe Kosten pro Monat Betrieb der Anwendung

Fixe Kosten pro Monat

Support der Nutzer

Fixe Kosten pro Monat Support der Nutzer

Fixe Kosten pro Monat

Monatliche Betriebskosten, ohne Projekte

100,000 €

6

90,000 €

Transakonen

80,000 €

5

70,000 €

4

60,000 €

Alte Applikaon

50,000 €

3

40,000 € 2

30,000 € 20,000 €

1

Neue Applikaon

10,000 € - €

Millions

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Transakonen (in Millionen)

138

Jul-18

Jan-19

Jul-19

Jan-20Zeit

Jul-20

Jan-21

Jul-21

0

Abb. 5.8   Monatliche Kosten der neuen Applikation

Wie in Abb. 5.8 dargestellt, ergeben sich für alle technischen Komponenten somit einfache Szenarien für die Migration auf Platform-Services (PaaS). Der Aufwand hierfür liegt geschätzt bei 20 Personentagen (bei 1000 EUR pro Personentag entspricht dies 20.000 EUR), einschließlich Test, Migration und besonders intensiver Betreuung in der Startphase nach der Migration. Die Überführung der Prozesslogik in den neuen Platform-Service ist technisch nicht möglich. Die insgesamt 180 Abläufe müssen vom Outsourcing-Dienstleister in der neuen Anwendung neu aufgesetzt werden. Der geschätzte Aufwand pro Ablauf liegt bei einem Personentag. In Summe ergeben sich also 180 Personentage für die Überführung der fachlichen Prozesse der Rechnungsbearbeitung in die Cloud. Der finanzielle Aufwand liegt somit bei 120.000 EUR, denn für Prozessexperten wird ein niedrigerer Tagessatz als für Programmierer berechnet (Abschn. 5.2.2). Dazu kommen Schulungen, Aufwände für die Projektleitung und für den Test der neuen Abläufe in Höhe von 90.000 EUR und 90 Personentagen (s. Tab. 5.3).

Tab. 5.3  Überblick über die Migrationsaufwände

Technische Migration

20.000 €

20 PT

Migration der Prozesslogik

120.000 €

180 PT

Projektmanagement, Schulungen etc.

90.000 €

90 PT

230.000 €

290 PT

5.4  Leistungsmerkmale der cloudbasierten Anwendung

139

Die technischen Aufwände der Cloud-Migration sind konservativ geschätzt, machen aber ohnehin nur einen kleinen Teil der Gesamtkosten aus. Die Migration der Prozesslogik ist der aufwendigste Teil. Im Vergleich zu einem Projekt, das auf klassische Art und Weise mit einem siloübergreifenden Team aus Entwicklern, Projektleitern und Fachexperten umgesetzt wird, fallen die 180 Personentage noch immer relativ „günstig“ aus. Der Aufwand für das Projektmanagement und für Schulungen hängt letztlich davon ab, wie gut die Prozessexperten ausgebildet sind und wie eigenständig sie sind – dementsprechend kann der Aufwand schwanken.

5.4 Leistungsmerkmale der cloudbasierten Anwendung Die logische Software-Architektur der Anwendung ändert sich durch die Cloud-Transformation nicht. Die Applikationsteile Darstellungsschicht, Integration in Kundensysteme, Reporting, Datenhaltung und Prozesslogik bleiben bestehen. Die darunterliegende physische Architektur ändert sich dagegen grundlegend: Der Dienstleister für das Einkaufsrechnungs-Outsourcing muss nun keine einzige Infrastruktur-Komponente mehr selbst betreiben oder betreuen. Er benötigt somit keine Spezialisten mehr für Server, Speicher, Netzwerk, Active Directory, Load Balancer und netzwerkorientierte Sicherheitsthemen. Auf ein eigenes Rechenzentrum kann er ebenfalls verzichten – zumindest benötigt er es nicht mehr für die wichtigste Anwendung in seinem Kerngeschäft. Die verbleibenden Betriebsleistungen fokussieren sich auf die Ebene der Anwendung. Sie sind damit wesentlich einfacher automatisierbar und orientieren sich deutlich stärker an den Bedürfnissen des Kerngeschäfts.

5.4.1 Fixe Betriebskostenund Gesamtkosten Die Kalkulation der neuen Anwendung gestaltet sich in der neuen Applikation wie in Tab. 5.4 dargestellt. Waren in der alten Applikation noch alle 13 Elemente der Kostenkalkulation fixe Kosten, sind es in der neuen, cloudbasierten Applikation nur noch fünf: Webserver, SQL-Datenbank, Firewall sowie Anwendungsbetrieb und Support. Insgesamt summieren sich die Fixkosten auf 17.365 EUR pro Monat, sie bleiben bei dieser Anwendung auch bei einer höheren Anzahl von Transaktionen konstant. Alle weiteren Kosten orientieren sich am Grad der Nutzung der Plattform. Die in Abb. 5.8, 5.9 dargestellte lineare Verknüpfung der Kosten mit der Anzahl der Transaktionen ist allerdings eine Vereinfachung. In Tab. 5.2 werden je Service die tatsächlichen Skalierungsfaktoren dargestellt. In der Praxis kann diese Vereinfachung der

140

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Tab. 5.4  Kalkulation der neuen Applikation für drei Millionen Transaktionen Komponente

Preis der CPU

Darstellungsschicht Web Server

Gesamt 2.073,20 €

Premium V2 Tier; 4 P3V2 (4 Core(s), 14 GB RAM, 250 GB Storage) × 730 h; Linux OS

Prozesslogik

2.073,20 € 2.518,04 €

Logic Apps

100.000 Action Executions × 30 day(s)

1.548,60 €

Service Bus

Premium tier: 2 daily message units, 730 h

969,44 €

Datenhaltung

13.897,94 €

Azure SQL Database

Elastic Pool, vCore Purchase Model, Business Critical Tier, Provisioned, Gen 5, 2 32 vCore instance(s), 3 year reserved, 1,000 GB Storage, 2500 GB Backup Storage

13.443,68 €

Storage

Block Blob Storage, General Purpose V2, ZRS Redundancy, Hot Access Tier, 20 TB Capacity

454,26 €

Weitere Systemkomponenten

4.918,34 €

Azure Active Di-rectory

Premium P1 tier, per-user MFA billing model, 50 512,28 € MFA user(s), 25.001–100.000 directory objects, 730 h

Azure Active Di-rectory B2C

50,000 authentication(s), 1,000 authentication(s)

Application Gate-way

Web Application Firewall tier, Large In-stance 680,88 € size: 2 Gateway hours instance(s) × 730 h, 0 GB Data processed unit(s), 1 TB Zone unit(s)

Azure Firewall

Logical firewall units × 730 h, 2 TB Inbound data transfer, 2 TB Outbound data transfer

1.361,10 €

Azure DDoS Pro-tection

Protection for 100 resources, 4 TB Data processed

2.206,02 €

Outbound Traffic

Virtual Network with outbound traffic

145,41 €

12,65 €

Operations

2.021,46 €

Betrieb der Anwendung

1.021,46 €

Support der Nutzer

1.000,00 € Summe

25.428,98 €

Kostenkalkulation durchaus problematisch sein: Werden zu Beginn unrealistische Annahmen darüber getroffen, wie stark die jeweiligen Services in Anspruch genommen werden, kann es zu unerwarteten Änderungen der Kostenstruktur kommen – im positiven wie im negativen Sinn.

5.4  Leistungsmerkmale der cloudbasierten Anwendung

141 6

90,000 € 5

80,000 € 70,000 €

4

60,000 €

Transakonen

Alte Applikaon

50,000 €

3

40,000 € 2

30,000 €

Neue Applikaon

20,000 €

Transakonen (in Millionen)

Monatliche Gesamtkosten, mit Projekten

100,000 €

1

10,000 € - €

Jul-18

Jul-19

Zeit

Jul-20

Jul-21

0

Abb. 5.9   Monatliche Gesamtbetriebskosten einschließlich Projekte

Abb. 5.8 zeigt die Entwicklung der Kostenkomponenten der neuen Applikation in Abhängigkeit zu den Transaktionen. Am Anfang spielen die Fixkosten noch eine große Rolle, mit zunehmender Anzahl von Transaktionen nimmt der Anteil der variablen ­Kosten zu.

5.4.2 Aufbau und Ausbau der Applikation Die Aufwände für die Migration von der alten Architektur auf eine cloudbasierte Architektur wurden schon in Abschn. 5.3 beschrieben. Würden die Prozesse für einen zweiten, ähnlichen Kunden in der gleichen Anwendung neu eingerichtet, würde ein deutlich geringerer Aufwand anfallen. Da es sich in allen Bereichen der Applikation um software-definierte Services handelt, lässt sich deren Einrichtung wiederum als Software-Code beschreiben und immer wieder neu aufrufen. Die technische Einrichtung für den neuen Kunden würde somit nur wenige Minuten bis Stunden benötigen – und es wären dafür kaum Menschen nötig. Zudem entfallen händische Bestellprozesse und Wartezeiten für physische Lieferprozesse. Die eigentliche Skalierung der IT-Komponenten kann in 11 der 13 Fälle automatisiert erfolgen, gemäß der zuvor definierten Methoden und Grenzen. Die Dokumentenablage (Storage) wird einfach genutzt und hinterher auf Basis des tatsächlichen Verbrauchs bezahlt, ebenso werden die Logic Apps nach den tatsächlich ausgeführten Transaktionen

6

8.000 €

Transakonen

Durchschniliche Kosten (kumuliert)

4.000 €

5

2.000 € 1.000 €

Alte Applikaon

4

0.500 € 3

0.250 € 0.125 €

2

0.063 € 0.031 €

Millions

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

Transakonen (in Millionen)

142

1

0.016 €

Neue Applikaon

0.008 €

0

Zeit

Abb. 5.10   Durchschnittskosten in Abhängigkeit von den Transaktionen

abgerechnet. Die Server für die Darstellung der Benutzeroberfläche sowie für die Datenbanken können nach individuell definierbaren Regeln automatisiert werden und schnell auf zusätzliche Nachfrage reagieren („Autoscale“). Die Prozesse für die zusätzlichen Ländergesellschaften müssen weiterhin in eigenen Projekten manuell eingerichtet werden. Fachexperten legen diese Prozesse zu je 1000 EUR pro Tag für neue Kunden an. Für neue Kunden müssen der Leistungsumfang, der Prozessablauf und das zu integrierende System spezifiziert werden. Insgesamt wird in diesem Fall von einem Projektaufwand von 60.000 EUR zum Ende des zweiten Jahres ausgegangen. Damit verbessert sich die Wettbewerbssituation der neuen Applikation gegenüber der alten. Dieser Unterschied tritt besonders deutlich zu Beginn der Skalierung in Erscheinung (s. Abb. 5.9).

5.4.3 Durchschnittliche Kosten und Gesamtkosten Ein wesentlicher Vorteil der Cloud-Applikation gegenüber der klassischen Applikation ist, dass die Cloud-Applikation schon in der Anfangsphase zu deutlich geringeren Durchschnittskosten operieren kann. Die klassische Applikation hingegen erreicht erst bei einer sehr hohen Transaktionszahl die Durchschnittskosten der Cloud-Applikation. Abb. 5.10 stellt die kumulierten Durchschnittskosten je Transaktion nach dem „Go-Live“ der Applikation dar.

3.0 €

6

2.5 €

Transakonen

2.0 €

1.5 €

5

4

Alte Applikaon

3

1.0 €

2

Neue Applikaon 0.5 €

1

0.0 €

0

Millions

143

Transakonen (in Millionen)

Millions

Kumulierte Gesamtkosten, mit Projekten

5.4  Leistungsmerkmale der cloudbasierten Anwendung

Zeit

Abb. 5.11   Summierte Kosten über den gesamten Applikationslebenszyklus

Die Einzelkosten der neuen Applikation liegen von Beginn an konstant bei 0,0027 EUR pro Transaktion. Sie sinken auch erst einmal nicht, wenn es mehr Transaktionen gibt, denn der Cloud-Provider verlangt für jeden der genannten Services feste Beträge je Nutzung. Ab einer sehr großen Anzahl von Transaktionen sind die Cloud-Provider dazu bereit, über Mengenrabatte zu verhandeln (Linthicum 2019). Bevor es so weit ist, versuchen Cloud-Architekten zunächst, die Kosten durch Verbesserungen in der Software-Architektur zu senken. Zum Beispiel werden günstigere Speicherkomponenten eingesetzt oder die gleichen Kalkulationen werden mit weniger Arbeitslast ausgeführt. Erst wenn der Bedarf an IT-Services wirklich sehr groß ist, kann sich das Insourcing wieder lohnen – mitunter aus Kostengründen, häufig aber auch, um spezifische technische Anforderungen besser umsetzen zu können. Dropbox etwa hat 2017 beschlossen, in eigene Rechenzentren zu investieren und einen Großteil seiner Anwendungen und Daten von AWS zurückzuholen (Miller 2017). Ein Blick auf die summierten Kosten über den gesamten Verlauf des Applikationszyklus zeigt die Unterschiede am deutlichsten auf (s. Abb. 5.11). Die neue Applikation lässt sich mit weniger Aufwand einführen als die alte. Sie beginnt direkt mit niedrigeren Fixkosten und gibt ihren Vorsprung aufgrund der durchschnittlich niedrigeren Grenzkosten nicht mehr ab.

144

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

5.5 Vor- und Nachteile der Transformation im Überblick Im Vergleich der wichtigsten Wettbewerbsfaktoren schneidet die Cloud-Applikation in den meisten Aspekten deutlich besser ab. Sie bringt aber auch einige spezifische Nachteile mit sich.

5.5.1 Vergleich der finanziellen Faktoren Der Aufwand für die Einrichtung der Cloud-Applikation ist deutlich geringer, Tab. 5.5 zeigt eine Kostenreduktion um 62 %. Im Wesentlichen liegt das daran, dass Cloud-Ressourcen schneller und günstiger aufgebaut werden können und dass neue Einkaufsprozesse von den Fachexperten selbst eingerichtet werden können. Die Gesamtkosten für die gesamte dreieinhalbjährige Laufzeit sind ebenfalls deutlich geringer. Das liegt hauptsächlich daran, dass die alte Applikation zu Beginn schon hohe Fixkosten mitbringt, ohne dass die vorgehaltenen Ressourcen tatsächlich genutzt werden. Tab. 5.5  Vergleich der wichtigsten Kostenkomponenten Klassische Appli- Cloud-Applikakation tion

Kosten-reduktion Kommentar

Anzahl Transaktionen über die Laufzeit

80.750.001

Projektkosten (in Summe)

315.000 €

120.000 €

61,9 %

Gesamtkosten über die Laufzeit

2.734.596 €

1.048.732 €

61,6 %

Durchschnittliche 0,0339 € Kosten pro Transaktion

0,0130 €

Durchschnittliche 0,0069 € Grenzkosten

0,0042 €

39,2 %

Günstigste Einzelkosten

0,0027 €

−439,0 %

0,0005 €

Die Kosten der Transformation von der neuen in die alte Applikation sind nicht eingerechnet

Die Cloud-Provider verdienen bei jeder Transaktion mit. Dem stehen bei der klassischen Applikation im Wesentlichen die Stromkosten gegenüber

Transakonen 5

4 0.391 € 3

3

2

0.039 €

Transakonen (in Millionen)

Durchschni liche monatliche Kosten

3.906 €

6

Alte Applikaon

Millions

145

5.5  Vor- und Nachteile der Transformation im Überblick

1

0.004 €

1

2

Neue Applikaon 0

Zeit

Abb. 5.12   Relevante Preis- und Qualitätsunterschiede in einem Bild

Die durchschnittlichen Grenzkosten der Cloud-Applikation sind ebenfalls deutlich günstiger. Besonders relevant ist für den Dienstleistungsanbieter aber, dass die durchschnittlichen Kosten schon sehr früh im Prozess auf das Zielniveau fallen. In Abb. 5.12 ist diese Stelle durch den ersten Pfeil gekennzeichnet. Die Nachteile der Cloud werden sichtbar, wenn die Einzelkosten betrachtet werden: Der Cloud-Provider lässt sich grundsätzlich jede Transaktion bezahlen, die klassische Applikation hingegen operiert unter bestimmten Bedingungen mit Einzelkosten, die faktisch bei Null liegen. Bewegt sich die Anzahl der Transaktionen unterhalb der Maximalauslastung (s. Abb. 5.6), fallen im klassischen Rechenzentrum tatsächlich nur die zusätzlichen Stromkosten für die Durchführung der Rechenoperation an. Steigt die monatliche Auslastung der Applikation in die Nähe der Kapazitätsgrenze, sinken die durchschnittlichen Kosten deutlich und erreichen fast das Niveau der Cloud-Applikation (s. Pfeil 2 in Abb. 5.12). Wenn die Anzahl der Transaktionen hoch und gleichmäßig verteilt ist und die Infrastruktur entsprechend optimiert wird, kann es deutlich günstiger sein, das Geschäftsmodell nicht in der Cloud, sondern auf die klassische Art zu betreiben.

5.5.2 Vergleich funktionaler Faktoren Eine Applikation am Rande der Kapazitätsgrenzen der Infrastruktur zu betreiben und damit die wirtschaftlichen Faktoren zu optimieren, ist ein verlockendes Spiel. Dieses Vorgehen birgt aber die Gefahr, dass die Anwendung gerade dann nicht mehr

146

5  Cloud-IT vs. klassische IT – Kalkulation für den Controller

performant funktioniert, wenn besonders viele Nutzer ihre Funktionen benötigen. Bei Pfeil 3 in Abb. 5.12 existiert eine solche Situation: Die Zahl der Transaktionen übersteigt die Kapazitätsgrenze der Infrastruktur. Für den Anbieter des Rechnungsservices würde dies bedeuten, dass die Sachbearbeiter ihre Aufgaben nicht mehr oder nur sehr viel langsamer durchführen können. Eine kleine Kostenersparnis in der IT würde also die Produktivität an einer anderen Stelle des Prozesses einbrechen lassen. Die Tatsache, dass die Cloud ein Unternehmen dabei unterstützt, die Ressourcenlage schnell und feingranular an die aktuelle Bedarfslage anzupassen, führt also in der Praxis dazu, dass Cloud-Applikationen seltener an Kapazitätsgrenzen stoßen und somit in den besonders nutzungsintensiven Phasen performanter sind. Besonders vorteilhaft wirkt es sich in der Praxis dieses Geschäftsmodells aus, dass die Prozessverantwortlichen ihre eigenen Prozesse definieren können. Mit den entsprechenden Werkzeugen können sie sowohl gegenüber dem Kunden als auch nach innen für die Umsetzung die volle Verantwortung für den Prozess übernehmen. Waren sie vorher immer auf die Verfügbarkeit von IT-Experten angewiesen, können sie nun selbst und ohne aufwendige interne Abstimmung den Kundenbedarf im System abbilden.

5.6 Fazit Klassische Applikationen und Cloud-Applikationen unterscheiden sich, selbst bei möglicherweise gleichem Funktionsumfang, deutlich in ihren wirtschaftlichen Eigenschaften. Keine der beiden Varianten kann pauschal als besser bezeichnet werden. Die klassische IT bringt vor allem dann Vorteile mit sich, wenn der Großteil der Investitionen in die Infrastruktur und in die Betriebsorganisation bereits getätigt wurde, die Nachfrage nach Rechenleistung hoch und gleichmäßig über Tag und Jahr verteilt ist und für die Zukunft keine großen Änderungen zu erwarten sind. Die Cloud-IT spielt ihre Vorteile dagegen in den frühen Phasen einer Software sowie bei großen Lastschwankungen aus. Die Durchschnittskosten je Transaktion fallen sehr früh auf niedrige Werte und Änderungen lassen sich schneller und günstiger durchführen. Die Schadenshöhe bei Fehlinvestitionen ist geringer, denn Unternehmen können schnell und ohne Verpflichtungen für Betriebsmitarbeiter oder Liegenschaften des Rechenzentrums das Geschäft wieder zurückbauen.2

2Zu

beachten ist an der in diesem Kapitel gewählten Darstellungsweise, dass hier nicht digitale mit nicht-digitalen Geschäftsmodellen verglichen wurden, wie dies in Kap. 2 und 3 der Fall war. Vielmehr wurde hier ein bereits digitalisiertes Geschäftsmodell, das auf einer OnPrem-Lösung betrieben wurde, mit einer Auslagerung dieses Geschäftsmodells in die Cloud verglichen. Wird ein Geschäftsmodell gemäß Kap. 3 mit Hilfe von Cloud-Technologien vollständig digitalisiert, entstehen ebenfalls die in diesem Kapitel aufgezeigten Kostenstrukturen mit faktisch Null-Grenzkosten.

Literatur

147

Literatur Huffman, Clint (2009): Microsoft BizTalk Server Explained in Simple Terms, erschienen in: blogs. technet.microsoft.com, https://blogs.technet.microsoft.com/clint_huffman/2009/03/18/microsoft-biztalk-server-explained-in-simple-terms/, abgerufen im Juni 2019. Linthicum, David (2019): The CFO Guide to Cloud, erschienen in: deloitte.com, https://www2. deloitte.com/de/de/pages/finance-transformation/articles/CFO-Cloud-leitfaden.html, abgerufen im Juni 2019. Microsoft Azure (2019): Logic Apps, erschienen in: azure.microsoft.com, https://azure.microsoft. com/de-de/services/logic-apps/, abgerufen im Juni 2019. Miller, Ron (2017): Why Dropbox decided to drop AWS and build its own infrastructure, erschienen in: techcrunch.com, https://techcrunch.com/2017/09/15/why-dropbox-decided-to-drop-awsand-build-its-own-infrastructure-and-network/?guccounter=1&guce_referrer_us=aHR0cHM6Ly93d3cuZ29vZ2xlLmRlLw&guce_referrer_cs=vXaxNCwK4KTN0zHe-5VzSw, abgerufen im Juni 2019.

6

Software als Kernkompetenz beherrschen

Zusammenfassung

Die Software-Wertschöpfungskette steht im Zentrum jedes digitalen Geschäftsmodells: Software wird erstellt, betrieben und skaliert. Je besser das Unternehmen diese Wertschöpfung beherrscht, desto überlebensfähiger ist es im digitalen Wettbewerb. Die wichtigsten Stellschrauben für die Optimierung der Software-Wertschöpfung sind die genutzten Virtualisierungsebenen, die gewählten Sourcing-Optionen, die verwendete Software-Architektur, die Prozessabläufe in Betrieb und Entwicklung sowie die Art des Umgangs mit den beteiligten Menschen im Kontext der eigenen Organisation.

6.1 Alles wird Software Wie können traditionelle Unternehmen in einem Markt überleben, der von digitalen Disruptoren mit neuen Geschäftsmodellen, Produkten und Prozessen aufgemischt wird? Diese Disruptoren haben einen entscheidenden Vorteil: Sie werden im wahrsten Sinne des Wortes auf der grünen Wiese geplant. Von der Auswahl der Mitarbeiter über die Arbeitsprozesse bis hin zur Ausstattung starten alle Organisationsbereiche bei Null. Und: Sie haben die Freiheit, alles neu und gänzlich anders zu denken, als es bisher in ihrer Branche üblich war. Je nach Risikobereitschaft kann der Unternehmer das Tempo des Wachstums beliebig verändern. Er kann nach Bedarf langsam oder schnell skalieren. Neue Geschäftsmodelle werden als Minimum Viable Products (MVPs) am Markt getestet. So findet das Unternehmen schnell heraus, was am Markt und bei den Kunden funktioniert – und was nicht. Die investierten „sunk costs“ bleiben damit überschaubar. Diese Disruptoren besitzen einen weiteren Vorteil: Sie bauen auf den technischen und organisationalen Möglichkeiten der Gegenwart auf. Das ist die beste Ausgangssituation, um traditionelle Unternehmen mit ihren gewachsenen – und manchmal verwachsenen – Strukturen unter Druck zu setzen. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_6

149

150

6  Software als Kernkompetenz beherrschen

Viel schwieriger als etwas gänzlich Neues zu bauen ist es, ein bestehendes Unternehmen zu leiten und unter den Bedingungen der Digitalisierung zu transformieren. Die Führung muss mit den gegebenen Mitteln arbeiten: Mitarbeiter, Technik und Arbeitsabläufe haben sich jahre- und manchmal jahrzehntelang auf eine bestimmte Art, das Geschäft zu betreiben, ausgerichtet – da fällt jede Veränderung schwer. Traditionelle Unternehmen stehen vor der Herkulesaufgabe, einen digitalen Transformationsprozess durchlaufen zu müssen (Frank 2019). Um diesen Transformationsprozess zielführend steuern zu können, müssen Manager die Zusammenhänge in zwei Teilbereichen verstehen: • Sie sollten die Einsatzmöglichkeiten und geschäftlichen Potenziale moderner Software-Architektur kennen. • Sie sollten wissen, wie agile Arbeitsmethoden funktionieren und wie sie am sinnvollsten eingesetzt werden können, um Produkte rasch am Markt zu platzieren. In beiden Teilbereichen herrscht bei vielen Managern ein Nachholbedarf, da diese Inhalte weder Teil ihrer Ausbildung waren, noch in ihren bisherigen Aufgabenfeldern eine übergeordnete Rolle gespielt haben. Diese Lücke soll in diesem Kapitel geschlossen werden. Zu diesem Zweck bietet es einen Einblick in die wichtigsten Zusammenhänge zwischen der eingesetzten Technologie, den Prozessen der Organisation und der Wettbewerbsfähigkeit eines Unternehmens. Die Software-Wertschöpfung und die IT-Gesamtsicht Der „Stack“ – also die Elemente der IT-Wertschöpfung von der Infrastruktur über die Betriebssysteme bis zur Anwendung – wurde in Abschn. 4.3 beschrieben. Die Software-Wertschöpfung mit den Schritten „Software erstellen“, „Software betreiben“ und „Software skalieren“ bewegt sich auf der Ebene der Anwendung (Applikation) und wurde in den Varianten „ohne Cloud“ in Abschn. 4.2 und „mit Cloud“ in Abschn. 4.5 beschrieben. An jeder Stelle des Softwareprozesses wird auf die darunterliegenden IT-Komponenten zugegriffen (s. Abb. 6.1): In der Software-Erstellung werden die IT-Komponenten ausgewählt, aufgebaut und der Software-Code wird darauf ausgespielt. Im Software-Betrieb werden die Komponenten aufrechterhalten und gewartet, und in der Skalierung werden Ressourcen hinzugenommen oder wieder abgebaut. Im Zeitalter der Cloud verlieren die unter dem Software-Prozess liegenden IT-Ressourcen-Ebenen zunehmend an Bedeutung. Aus unternehmerischer Perspektive wird daher die Beherrschung des Software-Prozesses zur entscheidenden Variablen. Die Cloud verändert den Software-Prozess grundlegend. Denn in der Cloud können alle relevanten Eigenschaften der benötigten IT-Komponenten automatisiert definiert und gesteuert werden. Mit Hilfe des sogenannten „Infrastructure-as-a-Code“ wird beschrieben, welche Rechnertypen in welcher Menge gestartet werden und welche Datenbanken wie genutzt werden. Es kann dort ebenfalls hinterlegt werden, wie reagiert werden soll, wenn IT-Komponenten ausfallen, oder wenn wegen eines Kundenansturms mehr Ressourcen benötigt werden.

6.2  Warum Software für Manager eine so große Herausforderung ist

151

Geschäsmodell Anwendung

„Stack“

IT-Wertschöpfungskee

Soware erstellen

Soware betreiben

Soware skalieren

Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher Netzwerk

Die Soware-Wertschöpfung bedient sich der Infrastrukturund Middleware-Komponenten aus dem „Stack“

Soware-Wertschöpfungskee

Abb. 6.1   Der Software-Prozess greift auf die IT-Wertschöpfung zu

Im Zeitalter der software-definierten IT wird die Software-Anwendung zum Steuerungszentrum für alle anderen IT-Komponenten. Alle nun folgenden Erläuterungen beziehen sich darauf, wie Unternehmen Einfluss auf softwarebezogene Themen nehmen können, um ihre Geschäftsmodelle zu optimieren.

6.2 Warum Software für Manager eine so große Herausforderung ist Oberflächlich betrachtet scheint das Verhalten von Software eine berechenbare Sache zu sein: Sie sagen „Alexa, mach das Licht an“, und das Licht geht an. Sie nähern sich der Garageneinfahrt, und das Tor geht auf. Bei Ihrem PC wird es mitunter schon schwieriger: Wenn Sie den alten Drucker am neuen Rechner anschließen, kann das Ausdrucken entweder sofort funktionieren – oder auch nicht. Manchmal ist der Drucker nur mit einem alten Betriebssystem kompatibel, und dafür ist ein zusätzlicher Treiber nötig. Damit eine Software aus Kundensicht zuverlässig und vorhersagbar funktioniert, müssen alle relevanten Komponenten funktionieren. Im Falle des Druckers also die Hardware des PCs, das Betriebssystem, der Drucker und der Druckertreiber. Diese Verantwortungsbereiche lassen sich relativ gut abgrenzen: Lenovo liefert beispielsweise den PC, Microsoft das Betriebssystem und die Druckerlösung stammt möglicherweise von Canon. Das Betriebssystem von Microsoft stellt klar definierte und allgemein bekannte APIs zur Verfügung, auf deren Basis die Entwickler von Lenovo und Canon ihre Hardware und Treiber entwickeln und herstellen können. Die Prozesse zwischen diesen Unternehmen sind seit Jahren eingespielt, die Wahrscheinlichkeit, dass der Installationsprozess reibungslos funktioniert, ist daher relativ hoch.

152

6  Software als Kernkompetenz beherrschen

Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher Netzwerk

WorkflowSteuerung

Video-AusspielFunkonen

VideoEdierung

RechteManagement

Anwendung

NutzerOberfläche

Innerhalb ein und desselben Unternehmens gestalten sich diese Zusammenhänge deutlich schwieriger. Der Grund dafür ist zumeist im Entstehungsprozess der Unternehmensapplikationen zu finden. Im oben genannten Beispiel hat Microsoft von Beginn an die Hersteller von Druckern im Blick gehabt. Es wurde überlegt: Wie können die Produkte unabhängiger Dritter auf einfache und zuverlässige Art und Weise mit unserem Betriebssystem zusammenzuarbeiten, ohne dass wir mit jedem Hersteller individuelle Projekte durchführen müssen? Die typische Unternehmensapplikation hingegen wurde in der Regel für eine spezifische, geschäftliche Fragestellung entwickelt. Meistens entstehen solche Anwendungen im Rahmen eines einzelnen Projekts, in dessen Rahmen die lokalen und kurzfristigen Anforderungen an die Software definiert werden. Die Software wird erstellt, ohne auf die langfristigen organisatorischen Implikationen sowohl auf die interne als auch externe Zusammenarbeit zu achten. Diese innere Abschottung des Projektes führte zu einer monolithischen Unternehmensapplikation. In der Software-Entwicklung versteht man unter einem „Monolithen“ eine Applikation, deren funktionale Elemente nicht voneinander trennbar sind (ITWissen 2019). Wird eine solche monolithische Applikation um eine kleine Funktion ergänzt, hat das im schlechtesten Fall Auswirkungen auf die gesamte Software. Bei jeder Änderung muss die Software wieder vollständig getestet und neu ausgerollt werden. In dieser Wartungszeit ist sie nicht verfügbar, weder für Kunden noch für Mitarbeiter. Tritt in einem Teil der Software ein Fehler auf oder ist eine Teilkomponente der Infrastruktur überlastet, funktioniert in der Regel die gesamte Anwendung nicht (Abb. 6.2). In vielen Fällen sind monolithische Applikationen mehrere Jahrzehnte alt und wurden von Menschen entworfen, die möglicherweise gar nicht mehr im Unternehmen arbeiten. Über Jahre hinweg wurde dieser behäbige Software-Klotz von unterschiedlichen Teams und/oder unterschiedlichen Lieferanten betrieben und weiterentwickelt. Der Code ist kaum oder schlecht dokumentiert.

Monolith Teams auf Feature-Ebene können nur schwer entkoppelt arbeiten

Viele und teilweise unbekannte Abhängigkeiten auf allen Ebenen des Stacks.

Abb. 6.2   Monolithische Software beinhaltet viele Abhängigkeiten

Erhöhte organisatorische Komplexität

Langwierige Entwicklungs- und Testprozesse

6.2  Warum Software für Manager eine so große Herausforderung ist

153

Bildlich gesprochen gleichen monolithische Software-Architekturen einer Kirche, an der über Jahrhunderte unterschiedliche Baumeister gebaut haben – jeder hat sich darin selbst verwirklicht. Die Applikation funktioniert nur im Zusammenspiel mit ganz bestimmten IT-Komponenten, die in bestimmten Versionen vorliegen müssen. Das Betriebsteam ist so sehr mit der Aufrechterhaltung beschäftigt, dass kaum neue Funktionen implementiert werden können. Daher haben die Anwender ein aufwendiges Ökosystem aus Excel-Listen und Prozesslogiken angelegt, mit dem sich zumindest ein Teil ihrer Probleme im Zusammenspiel mit der Applikation lösen lässt. Für bestimmte Schlüsselfunktionen in der Software bleibt nur die Hoffnung, dass der bereits pensionierte Freelancer dem Unternehmen noch zur Verfügung steht, da er als Einziger in der Lage ist, Veränderungen vorzunehmen. Kein Manager traut sich, solche Applikationen anzufassen oder gar von Grund auf neu programmieren zu lassen. Der Aufwand dafür würde in kein Jahresbudget passen und auf der persönlichen Ebene würde es sich um ein Projekt handeln, mit dem ein Manager nur verlieren kann: Eine erfolgreiche Neuprogrammierung würde lediglich den alten Funktionsumfang wiederherstellen. Ein erfolgloses Projekt dagegen würde die Prozesse des Unternehmens ordentlich durcheinanderbringen. Mit schlecht programmierter Software verhält es sich daher so, wie mit der neunköpfigen Hydra aus der griechischen Mythologie (s. Abb. 6.3): Wenn ein Kopf abgeschlagen wird, wachsen zwei neue nach. Halbherzige Versuche, das Ungetüm unter Kontrolle zu bekommen, machen die Schlange nur noch komplizierter und gefährlicher. Daher lässt der weise Unternehmenslenker sie am besten ganz in Ruhe oder er zerschlägt sie in einer gemeinsamen, konzertierten Aktion – ganz so wie es Herakles und Iolaos getan haben. Software-Monolithen sind Bottlenecks der Organisation Je erfolgreicher und wichtiger eine Software für ein Unternehmen ist, desto häufiger und relevanter sind in der Regel die Änderungswünsche der Kunden und der internen Stakeholder. Es gibt neue Compliance-Anforderungen, der Kunde verlangt schnellere

SowareMonolith

Abb. 6.3   Monolithische Software – die Hydra im Unternehmen

154

6  Software als Kernkompetenz beherrschen Schnellere Antwortzeiten Neue Funkonen Bessere Nutzeroberfläche

Weniger Abstürze

HardwareUpdates

• Updates alle 6-12 Monate

Neue ComplianceAnforderungen

• Fokus auf Aufrechterhaltung

SowareUpdates

• Wenig neue Features

Kostensenkung Neuer Mandant

Boleneck der Komplexität

Management der Abhängigkeiten in Entwicklung, Test und Betrieb

Abb. 6.4   Die Abhängigkeiten innerhalb der Software bremsen die Organisation

Antwortzeiten, der Wettbewerber hat ein neues Feature entwickelt, das die eigene Software ebenfalls bieten soll. Außerdem sollen die Kosten gesenkt werden und es soll weniger Abstürze geben. Kommt das Entwicklungsteam einigen dieser Anforderungen nach, müssen die neuen Funktionen ausführlich getestet werden, denn: Jede einzelne Änderung kann Auswirkungen auf alle anderen Elemente der Anwendung haben, und jedes nicht funktionsfähige Feature kann die gesamte Anwendung lahmlegen. Änderungen werden daher von den Software-Verantwortlichen nicht gerne gesehen. Sie werden gebündelt, gemeinsam getestet und in einem großen, seltenen Update veröffentlicht (s. Abb. 6.4). Dieses Vorgehen schafft einen organisatorischen Engpass (Bottleneck). Die unterschiedlichen Anspruchsgruppen im Unternehmen wünschen sich mehr Änderungen, als sie von den Anwendungsverantwortlichen erhalten. Die Anzahl der Mitarbeiter zu erhöhen, die an der Software arbeiten, hilft nur selten, denn meist ist das notwendige Wissen um die Abhängigkeiten auf wenige, ohnehin überlastete Mitarbeiter verteilt. Selbst bei optimal dokumentierten Monolithen gibt es nur eine begrenzte Möglichkeit, Komplexitäts-Bottlenecks durch mehr Mitarbeiter aufzulösen, da menschliche Organisationen mit zunehmender Größe ganz einfach weniger effizient werden. Um den Überblick zu behalten, müssen dann Entscheidungsbäume gezeichnet, Governance-Richtlinien entworfen und Gremien gebildet werden. Ob den garantierten Mehrkosten dann in gleichem Maße mehr Geschwindigkeit und neue Funktionen gegenüberstehen, ist ungewiss. Die Leistungsfähigkeit der Software bestimmt maßgeblich die Leistungsfähigkeit des darauf basierenden Geschäftsmodells. Wie aber können Unternehmen die Leistungsfähigkeit von Software verbessern? Die folgenden fünf Abschnitte beschreiben die wesentlichen unternehmerischen und technischen Faktoren, die Einfluss auf die Leistungsfähigkeit von Software haben (s. Abb. 6.5). Dabei werden zunächst die Virtualisierungsebenen und Sourcing-Optionen eines Unternehmens vorgestellt. Danach folgen die Bereiche Software-Architektur, Prozessabläufe und die Unternehmensorganisation. In allen Bereichen wird dargestellt, wie der Entwicklungsschritt weg von den Monolithen hin zu agilen Software-Prozessen aussehen kann.

6.3 Virtualisierungsebenen

155

Menschen & Organisaon Prozessabläufe Soware-Architektur Organisatorisch komplexe Soware

Sourcing-Oponen Virtualisierungsebenen

Abb. 6.5   Faktoren, die die Leistungsfähigkeit von Software beeinflussen

6.3 Virtualisierungsebenen Auf der Ebene der Infrastruktur wird mit Hilfe von APIs und der entsprechenden Cloud-Software die Hardware virtualisiert. Auf den Ebenen darüber – also bei den Betriebssystemen und Datenbanken – geht es streng genommen eher um Abstraktion, denn es handelt sich um Software, die sowieso nicht physisch in Erscheinung tritt. In diesem Buch werden die Begriffe Virtualisierung und Abstraktion synonym ­verwendet. Aus wirtschaftlicher Sicht entscheidend ist die durch die Software-Schnittstelle mögliche Entkopplung (s. Abb. 6.6) der jeweils darüberliegenden Ebene der IT-Wertschöpfung von den Ebenen darunter. Nach unten erfolgt die Wertschöpfung automatisiert, wodurch die Abrechnung in Mikrotransaktionen möglich wird. Die Nutzung der Services durch viele Kunden ermöglicht eine gleichmäßig hohe Auslastung der bestehenden Infrastruktur. Dies führt zu durchschnittlich niedrigen Kosten je Transaktion. Bei der Wahl der richtigen Virtualisierungsebene ist also abzuwägen: zwischen dem notwendigen Grad der Individualisierung (oberhalb der API) und der Nutzung von Skaleneffekten durch die mit anderen Kunden geteilte ­Infrastruktur.

Anwendung Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung

API

Auf diesen Ebenen bleibt Individualisierung weiterhin möglich

API

API

Virtualized

IaaS

Entkopplung durch Soware-Schnistelle

API

Automasierung und Verteilung über viele Kunden ermöglichen nutzenbasierte Abrechnung und niedrige Kosten je Transakon.

API

Rechenleistung Speicher Netzwerk

Container

PaaS

Abb. 6.6   Entkopplung ermöglicht Skalierungseffekte

Serverless

SaaS

156

6  Software als Kernkompetenz beherrschen

Anwendung Security & Integraon Runmes & Libraries Datenbanken

API

Applikaon bleibt in ihrer Komplexität weitestgehend bestehen Entkopplung durch Soware-Schnistelle

Betriebssystem

Virtualisierung

Unabhängiges Management unterhalb der API

Rechenleistung

Das Betriebs-Team des Container-Services steuert in eigener Verantwortung die Wertschöpfung unterhalb der API. Dazu gehören Technologien, Tools, Provider, Sicherheit etc.

Speicher Netzwerk

Abb. 6.7   Virtualisierung der IT-Wertschöpfung am Beispiel eines Container-Services

Abb. 6.7 konkretisiert die Abwägung anhand des Beispiels „Container-Service“: Container (Abschn. 4.4.4) virtualisieren die Ebene der Betriebssysteme. Mit diesem Service kann ohne Auswirkungen auf die höheren Ebenen des Stacks die Infrastruktur ausgetauscht, heruntergefahren oder wieder hochgefahren werden. Je nach Bedarf können günstigere und kleinere Serverinstanzen (ein Flussschiff) oder große und teure virtuelle Maschinen (ein Ozean-Containerschiff) genutzt werden. Der Austausch erfolgt binnen weniger Sekunden, die Applikation liegt darüber abgekapselt in einem „Container“. Dabei spielt es keine Rolle, welches Betriebssystem (Schiff) den Container aufgeladen hat. Ein Unternehmen, das für seine Applikation die Container-Technologie nutzt, kann die vorgehaltenen IT-Ressourcen möglichst exakt an den tatsächlichen Bedarf anzupassen. Um in der Metapher zu bleiben: Es wird immer das kleinstmögliche Schiff eingesetzt, um im aktuellen Seegebiet bei gegebener Wetterlage den Container effizient zu transportieren. Es gilt dabei die Daumenregel: Je höher die Ebene der Abstraktion, desto besser kann der Cloud-Provider die Auslastung der darunterliegenden Ebenen managen und desto geringer sind die Fixkosten. Die Kalkulation in Abb. 6.8 verdeutlicht die Zusammenhänge. Betrachtet wird in dieser Abbildung der Betrieb einer Webseite mit schwankendem Nutzungsverlauf. Die Seite wird unter der Woche wenig besucht, an den Samstagnachmittagen schießt hingegen die Zahl der Nutzerzugriffe regelmäßig in die Höhe. Auf diese Spitzenauslastung werden in der Variante mit niedrigem Virtualisierungsgrad alle Systemkomponenten ausgerichtet und ständig bereitgehalten (Virtualized, IaaS). Die Kosten sind entsprechend hoch, die durchschnittliche Auslastung der Komponenten ist gering. In den Varianten mit hohen Virtualisierungsgraden (Container, PaaS, Serverless, SaaS) kümmert sich der Cloud-Provider um die intelligente Verteilung der Auslastung. Es werden kaum Ressourcen vorgehalten, dennoch steht zu Peak-Zeiten ausreichend Rechenleistung zur Verfügung. Da der Cloud-Provider einen Teil seiner Optimierungserfolge an den Kunden weitergibt, sinkt für die auf hohen Virtualisierungsebenen betriebene Anwendung der Preis deutlich.

Monatliche Kosten

IaaS

PaaS

Virtualisierungsgrad

Container

Serverless

Abb. 6.8   Beispielhafte Kalkulation einer Webseite mit schwankendem Nutzungsverlauf

Virtualized

SaaS

500 €

1.000 €

Beispiel: Blogger.de oder Jimdo Fixbetrag pro Monat: ~0-10 €

Beispiel: Azure Funcons Fixbetrag pro Monat: ~0 € Kosten je Ausführungszeit: €0,000014/GB-s Kosten je Millionen Ausführungen: 0,169€

Beispiel: Individuelle IT im Rechenzentrum Fixbetrag pro Monat: >1000€ Unabhängig von der tatsächlichen Nutzung

6.3 Virtualisierungsebenen 157

158

6  Software als Kernkompetenz beherrschen

Mit den niedrigen Kosten auf höheren Virtualisierungsebenen gehen auch Nachteile einher. Kostenlose Software-Services (SaaS) wie der Webseiten-Anbieter blogger.de können zwar den gezeigten Nutzungsverlauf problemlos abbilden, bieten aber nur wenige Einstell- und Konfigurationsmöglichkeiten, meist nur im Bereich der grafischen Templates. Je niedriger der Betreiber der Anwendung den Virtualisierungsgrad wählt, desto mehr Einstellungen kann er selbst treffen. Auf der Ebene von PaaS und Container können noch umfangreiche Individualprogrammierungen erfolgen, auf der Ebene Virtualized können noch Speicher-, Netzwerk- und Datenbankkomponenten individualisiert werden.

6.4 Sourcing-Optionen Beim Einflussfaktor „Sourcing-Optionen“ geht es um die Frage, wo und auf welche Weise die IT-Komponenten bezogen werden. Im Kern ist die Frage zu beantworten, ob die IT-Komponenten selbst hergestellt oder bei einem Anbieter gemietet werden. Bei einem Insourcing der Komponenten geht das Unternehmen mittel- bis langfristig eine hohe Bindung ein. Dies betrifft das eingesetzte Kapital, die inhaltliche Bindung von Führungskräften an IT-Infrastruktur-Themen und die Bindung von Mitarbeitern, um die IT-Leistungen aufzubauen und weiterzuentwickeln. Abb. 6.9 visualisiert die Makeor-Buy-Entscheidung aus operativer Sicht, in Kap. 7 wird sie noch einmal aus unternehmensstrategischer Sicht erläutert. Die Entscheidung für Insourcing oder Outsourcing innerhalb der Unternehmens-IT ist keine 0/1-Entscheidung, sondern zeigt zahlreiche Abstufungen. Für fast jede IT-Komponente können separate Entscheidungen getroffen werden. Beispielsweise kann ein Unternehmen einen sogenannten „Housing-Anbieter“ nutzen, der die Gebäudeinfrastruktur wie Kühlung, Strom und physische Sicherheitseinrichtungen zur Verfügung stellt. In diesem externen Rechenzentrum stehen aber die eigenen Server- und Speicher-Anlagen des Unternehmens. Andersherum können Unternehmen eigene Räumlichkeiten als Rechenzentrum nutzen und eigene Server anschaffen, aber den Container-Service von einem Dienstleister betreiben und weiterentwickeln lassen. Insourcing Auau eigener Rechenzentren, Anschaffung eigener Hardware, Ausbildung von Mitarbeitern, Auf- und Ausbau der Services, Steuerung der Auslastung

Klassische IT

Outsourcing Nutzung der Gebäude anderer Anbieter, Konsum der ITKomponenten als Cloud-Service, keine eigenen Betriebsteams, kein Auslastungsrisiko

Public Cloud Private Cloud

Abb. 6.9   Make-or-Buy-Frage in der Übersicht

Private Cloud

159

6.4 Sourcing-Optionen

Eine Private Cloud muss ebenso nicht selbst aufgebaut und betrieben werden. Es gibt die Möglichkeit, diese bei einem Dienstleister zu beauftragen und betreiben zu lassen oder diese mit einer begrenzten Anzahl anderer Kunden des Dienstleisters gemeinsam zu nutzen. Die Public Cloud dagegen steht allen zahlenden Unternehmen zur Benutzung offen. Eine hybride Cloud im engeren Sinne gibt es nicht, der Begriff „Hybrid Cloud“ wird verwendet, wenn Applikationen IT-Komponenten sowohl aus der Private Cloud als auch aus der Public Cloud nutzen (Rouse 2019). Dies ist häufig dann sinnvoll, wenn interne Compliance-Richtlinien die Nutzung der Private Cloud vorschreiben, weniger kritische Teile der Applikation – wie etwa Test- und Entwicklungssysteme – aber die Vorteile der Public Cloud nutzen möchten (Raza 2018). IT-Mitarbeiter sprechen immer öfter von der „Multi-Cloud“, meist im Zusammenhang mit großen IT-Landschaften. Dieser Begriff beschreibt die Tatsache, dass ein Unternehmen viele Clouds parallel verwendet. Dies ist selten das Ergebnis der aktiven Umsetzung einer Multi-Cloud-Strategie, sondern entspricht der natürlichen Entwicklung von IT-Landschaften im Kontext des Megatrends Cloud. Ein mögliches Multi-Cloud-Szenario sieht folgendermaßen aus: Microsoft gewinnt ein Unternehmen als Kunden für seine Bürosoftware Office365-Cloud. Darüber hinaus bietet Oracle für die Nutzung seiner Cloud-Angebote kaum schlagbare Konditionen für Oracle-intensive Anwendungen. Die Sales-Abteilung hat sich für eine CRM-Lösung von Salesforce entschieden. Die IT-Abteilung hat eine Private-Cloud aufgebaut und die Entwickler der E-Commerce-Anwendung nutzen schon seit langem AWS. Die jungen Mitarbeiter lieben Slack – ein SaaS-Tool für die Team-Kommunikation – und die Marketing-Abteilung kann ohne das Cloud-Tool Google Analytics nicht arbeiten. Ohne dass bewusst darauf hingearbeitet wurde, entsteht so aus den verschiedenen fachlichen Notwendigkeiten heraus ein Multi-Cloud-Szenario. Abbildung Abb. 6.10 liefert einen Überblick über die wichtigsten Sourcing-Optionen von Unternehmen. Die entscheidende Frage im Kontext der Sourcing-Optionen ist, wer welche Investitionen und welche Risiken übernimmt (s. Abb. 6.11). Die wichtigsten Faktoren bei der Abwägung der Sourcing-Optionen sind:

Applikaon

Die IT-Komponenten sind nur besmmten Unternehmen zugänglich.

Eine Applikaon nutzt IT-Komponenten aus beiden Cloud-Typen.

Hybrid Cloud

Private Cloud Abb. 6.10   Die wichtigsten Sourcing-Optionen

Der IT-Provider bietet seine Komponenten allen Unternehmen gleichermaßen an.

Public Cloud

160

6  Software als Kernkompetenz beherrschen

€ Fix

Invesonen in Hardware

Abwägung

Auau der Services

Auslastung im Betrieb

Private Cloud

Verantwortung für Risiken

Hybrid Cloud

Nutzen der Individualisierung

Public Cloud

Abb. 6.11   Faktoren bei der individuellen Abwägung der Sourcing-Optionen

• • • • •

Investitionen in die Anlagen und die Hardware-Infrastruktur Aufbau der Cloud-Services Betrieb der Cloud-Services und Übernahme der dazugehörigen Auslastungsrisiken Übernahme der Performance- und Sicherheitsrisiken Nutzen der Individualisierung für das Geschäftsmodell

Die Investitionen in Hardware sind hoch und der Aufbau der vielen, notwendigen Services gestaltet sich aufwendig. Die ausreichende Auslastung von Hardware und Services im Betrieb bei schwankender Nachfrage sicherzustellen, bringt finanzielle Risiken mit sich. Zusätzlich besteht das Risiko, dass die selbst erbrachten Services ausfallen und Folgeschäden in den Anwendungen verursachen. Sicherheitsrisiken gibt es ebenfalls: Wer die Services zur Verfügung stellt, ist auch dafür zuständig, dass dort niemand unberechtigt eindringt. Demnach sprechen einige Argumente für das Outsourcing der Services an externe Cloud-Provider. Entsprechend geht das Marktforschungsinstitut Gartner davon aus, dass bis 2025 etwa 80 % der Unternehmen ihre Rechenzentren abschaffen werden (Cappuccio 2018). Umgekehrt gibt es einige Argumente für das Insourcing von IT-Komponenten. Vor allem für große Unternehmen mit eigener IT-Kompetenz und einem klaren Fokus auf bestimmte IT-Services können sich die Investitionen finanziell und funktional lohnen. Apple etwa hat angekündigt, 10 Mrd. USD in eigene Rechenzentren in den USA zu investieren (Donath 2018), verteilt aber weiterhin auch Anwendungen auf die Cloud-Provider AWS und Google (Nickel 2018). Osram entwickelt eine eigene IoT-Platform, nutzt dafür aber die Cloud-Infrastruktur von Microsoft (Osram 2019). Netflix setzt auf die Cloud seines Streaming-Konkurrenten AWS, betreibt aber eigene Services für spezielle Video-Aufgaben (Hahn 2016).

161

6.5 Software-Architektur

6.5 Software-Architektur Ein Faktor, der die Wettbewerbsfähigkeit von Unternehmensapplikationen am stärksten beeinflusst, ist die Software-Architektur. Der Begriff der Software-Architektur wurde erst in den 1990er-Jahren als eigenständiger Bereich in die Software-Entwicklung aufgenommen. Die Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“ (Balzert 2011, S. 580). Seit dieser Zeit werden viele andere Bereiche der Software-Entwicklung der Software-Architektur untergeordnet. In den folgenden Abschnitten wird der Begriff Software-Architektur innerhalb des engen Begriffsverständnisses erläutert, es werden die zeitlich aufeinanderfolgenden Entwicklungsstufen dargestellt und die wichtigsten Zusammenhänge erläutert.

6.5.1 Monolithische Architekturen In den 1990er-Jahren dominierten die sogenannten Client-Server-Architekturen. Zahlreiche Softwareapplikationen, die auf Basis dieser Architekturen entwickelt wurden, werden bis heute aktiv in Unternehmen verwendet (Calcott 2018). Beim Client-Server-Architekturmuster (s. Abb. 6.12) stellt in der Regel der Server einen Dienst zur Verfügung, der von einem Client genutzt werden kann. Der Client und der Server werden dabei üblicherweise auf unterschiedlichen Computern ausgeführt. Ein einfaches Beispiel ist der Datei-Server, der Dateien über eine Schnittstelle zur Verfügung stellt. Die Client-Komponente interagiert über diese Schnittstelle, um bereitgestellte Dateien zu verarbeiten. Ende der 1990er-Jahre veränderten sich die Software-Architekturen zu sogenannten Multi-Tier-Architekturen (Mehrschicht-Architekturen, s. Abb. 6.13). Hierbei werden die einzelnen Komponenten auf verschiedene logische Schichten verteilt, die dann auf einem oder mehreren Computern ausgeführt werden. Das Schichtenmodell kann von zwei bis zu n Schichten variieren. Eine häufig verwendete Variante ist die 3-Schichten-Architektur (ITWissen 2018). Bei dieser Variante ist auf der ersten Schicht die Darstellungsebene verortet, die zweite Schicht stellt die fachliche Logik („Wie funktioniert das System?“) zur Verfügung und auf der dritten Schicht liegt die Datenhaltung (Datenbank). Dass die Funktionsbereiche der Software über die Schichten nicht klar entkoppelt sind,

Server

Client

Abb. 6.12   Client-Server-Architektur – Download eines Fotos vom FTP-Server

162

6  Software als Kernkompetenz beherrschen

Darstellungsschicht

Fachliche Logik

Datenhaltung Abb. 6.13   Mehrschichten-Architektur

führt dazu, dass bei einer Veränderung der Applikation immer alle Teile der Architektur gleichzeitig angepasst werden müssen. Während dieser Wartungszeit steht die Applikation nicht für Dritte zur Verfügung. Anfang der 2000er-Jahre wurde ein Protokoll entwickelt, das als Basis für ein neues Software-Architekturmuster diente (Drilling und Augsten 2017a): das sogenannte SOAP-Protokoll (Simple Object Access Protocol). SOAP ermöglichte es verschiedenen Diensten, über einen bestimmten Nachrichten-Typ (XML) miteinander zu kommunizieren. Das Protokoll wird auch heute noch eingesetzt und war der Wegbereiter für das Architekturmuster verteilter Systeme, das unter dem Begriff „Service Oriented Architecture“ (SOA) bekannt ist (s. Abb. 6.14). Bei diesem Architekturmuster werden einzelne

Darstellungsschicht

Legende XML-Nachrichten Datenbank Fachliche Logik

Abb. 6.14   Service Oriented Architecture (SOA)

163

6.5 Software-Architektur

fachliche Funktionen gekapselt und als Dienst zur Verfügung gestellt, wobei die einzelnen Dienste auf unterschiedlichen Computern ausgeführt werden können. Dieses Architekturmuster hat sich bewährt und wurde bis heute ständig weiterentwickelt.

6.5.2 Verteilte Systeme Ein aktueller Trend im Bereich der Software-Architekturmuster sind die sogenannten Kleinstdienste oder „Microservices“ (Wolff 2018a). Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus voneinander unabhängigen Diensten komponiert wird, die untereinander über sprachunabhängige Programmierschnittstellen kommunizieren (Wolff 2018b; Newman 2015). Die Unterscheidung zwischen Microservices und SOA ist nicht immer eindeutig. Ein zentraler Unterschied besteht darin, dass Microservices – im Gegensatz zu SOA – in der Regel ohne schwergewichtigen Applikationsserver auskommen und ihre eigene Infrastruktur autark steuern (Biske 2015). Die Dienste sind weitgehend entkoppelt und erledigen jeweils kleine Aufgaben (s. Abb. 6.15). So ermöglichen sie einen modularen Aufbau von Anwendungssoftware. Dieser modulare Aufbau hat wesentliche Vorteile gegenüber den bisher dargestellten Varianten: • Die Funktion des Gesamtsystems ist von der Funktion einzelner Teilservices unabhängig. Diese können ausfallen oder ausgetauscht werden, die Applikation insgesamt steht trotzdem zur Verfügung. • Ein einzelner Dienst kann verändert werden, ohne damit andere Dienste zu beeinflussen. • Applikationen können untereinander auf ihre Dienste zugreifen. Sie arbeiten auf diese Weise zusammen, ohne die Gesamtkomplexität zu erhöhen.

Darstellungsschicht Applikaon A

Microservice

Microservice

Darstellungsschicht

Microservice

Microservice

Microservice

Microservice

Microservice

Applikaon B

Abb. 6.15   Microservices-Architektur

164

6  Software als Kernkompetenz beherrschen

Applikationen, die auf der Basis von Microservices entwickelt werden, heißen verteilte Systeme. Bei deren Entwicklung sind bestimmte Eigenheiten zu beachten, die im sogenannten CAP-Theorem beschrieben werden (Nazrul 2018). Dieses besagt, dass in verteilten Systemen nur zwei der drei folgenden Eigenschaften gleichzeitig erfüllt sein können: 1. Verfügbarkeit: Das System ist verfügbar im Sinne schneller Antwortzeiten. 2. Ausfalltoleranz: Das System arbeitet weiter, auch wenn die Kommunikation zwischen seinen Teilen gestört ist oder verzögert wird. 3. Datenkonsistenz: Alle Datensätze sind über alle verteilten Systeme hinweg konsistent. Abb. 6.16 stellt die Herausforderungen beim Betrieb einer Microservice-Software-Architektur anhand des Beispiels einer mobilen Wetterservice-Applikation dar. Fällt beispielsweise die Datenverbindung der Software-Architektur nach New York aus, kann der aktuelle Temperaturwert von New York nicht an die Wetterservice-Applikation übertragen werden. Die Microservice-Lösung: Der Nutzer erhält auf seiner Handy-App den veralteten Wert für New York, die Applikation bleibt aber trotz des Ausfalls verfügbar. Alle weiteren Services der Applikation sind vom Ausfall nicht betroffen, zum Beispiel liefert die Applikation die aktuellen Wetterdaten für Berlin und spielt die Bannerwerbung korrekt ein. Ein monolithisches System dagegen wäre vollständig ausgefallen, bis die Netzwerkverbindung nach New York wieder funktioniert hätte. In der Anfangszeit der verteilten Software-Architekturmuster erfolgte die Kommu­ nikation zwischen den Teilsystemen meist auf Basis des SOAP-Protokolls über XML-­ basierte Nachrichten. Um diese Nachrichten zu erstellen, musste von den zuständigen Programmierern vergleichsweise viel Entwicklungsarbeit geleistet werden. Die Nachrichten enthielten zudem viele zusätzliche Informationen (Metainformationen) bei wenig Inhalt (Drilling und Augsten 2017b).

Beispiel

Alte Temperatur

49°F Messstelle Berlin

Netzwerk-Ausfall Neue Temperatur

Messstelle 52°F New York

„Weer-Service“

CAP-Theorem

HandyApp

Verfügbarkeit

WerbeService WeerService

49°F

Alte Temperatur

Abb. 6.16   Herausforderungen bei verteilten Systemen

DatenKonsistenz

Ausfalltoleranz

6.5 Software-Architektur

165

Um diesem Problem zu begegnen, entwickelte Roy Fielding im Zuge seiner Doktorarbeit (Srocke und Karlstetter 2017) den Architekturansatz ReST (Representational State Transfer). Dieser nutzt vorhandene Formate des Internets (insbesondere HTTP) und vereinfacht die Kommunikation zwischen verteilten Ressourcen und Services. Faktisch alle großen IT-Unternehmen setzen mittlerweile auf dieses Konzept und ermöglichen damit die übergreifende Zusammenarbeit verteilter Systeme. Insbesondere der Zugriff auf die in Kap. 4 geschilderten Cloud-Services ist auf diese Weise einfach und performant möglich (Drilling und Augsten 2017b).

6.5.3 Cloud-Native-Architekturen In Kap. 4 wurden die Vorteile für die Entwicklung und den Betrieb einer Software-Architektur aus der Cloud ausführlich beschrieben. Die Idee hinter CloudNative-Architekturen ist es, die der Cloud angeborenen („nativen“) Vorteile für die unternehmenseigenen Applikationen zu nutzen. • Einfach nutzbare Fertigteile: Die Cloud-Provider bieten eine Vielzahl fertiger Services auf allen Ebenen der IT-Wertschöpfung. Diese können ohne eigene Investitionen und Betriebsaufwände schnell in die Applikationen eingebaut und genutzt werden. • Abrechnung in Mikrotransaktionen: Je höher die Virtualisierungsebene des Cloud-Services, desto kleiner werden in der Regel die Abrechnungseinheiten. Damit sinken die Grenzkosten für neue Kunden in den digitalen Geschäftsmodellen auf faktisch Null. • Globale Skalierbarkeit: Cloud-Anwendungen können ihre Leistungsfähigkeit an die tatsächliche Nachfrage anpassen. Steigt diese global an, können auch die Applikationen automatisiert und unter Beibehaltung der niedrigen Grenzkosten global skalieren (Gannon et al. 2017). • Kosten nur bei Nutzung: Die Abrechnung von Cloud-Services erfolgt in der Regel gemäß der tatsächlichen Nutzung. Kostenstrukturen können somit am Erfolg des digitalen Geschäftsmodells ausgerichtet werden und damit Investitionsrisiken deutlich senken. Die folgenden Architektur-Ideen stehen bei der Entwicklung von Cloud-Native-Software im Vordergrund (Kratzke 2018): Distributed – Verteilte Services Die Anwendung soll auf viele verschiedene Services oder Microservices mit jeweils einer eigenen Datenhaltung verteilt sein. Dies ist die Grundlage, um die Komplexität in Entwicklung und Betrieb zu reduzieren.

166

6  Software als Kernkompetenz beherrschen

Loosely coupled – Lose gekoppelt Die verteilten Services sollen lediglich lose untereinander gekoppelt sein. Dies bedeutet, dass die Services nur über definierte APIs miteinander kommunizieren und keinerlei Direktzugriffe auf Komponenten innerhalb des Services möglich sind. Auf diese Weise kann der Service-Verantwortliche sicher sein, dass er hinter der API – frei von jeglichen Abhängigkeiten zu anderen Teilen der Applikation – Änderungen an seinem Service durchführen kann. Dies gilt natürlich nur unter der Voraussetzung, dass er die in der Schnittstellendokumentation definierten Funktionen nach außen weiterhin bedient. Stateless – Zustandslose Anwendungen Eine Anwendung ist zustandsbehaftet („stateful“), wenn der Server eine zweite Anfrage nur bearbeiten kann, wenn er auch die erste Anfrage bearbeitet hat. Diese Situation ist vergleichbar mit der Memory-Funktion eines analogen Taschenrechners: Errechnet und speichert man dort eine Zwischensumme, müssen auch alle weiteren Berechnungen genau auf diesem Taschenrechner weitergeführt werden. Zustandslos („stateless“) ist eine Anwendung, wenn es keine Abhängigkeiten zwischen aufeinanderfolgenden Anfragen gibt. Die Anfragen enthalten dann alle für diese Interaktion relevanten Daten (Fielding 2017) und somit gibt es keine Bindung mehr an einen bestimmten ausführenden Server. Jeder Server kann jede Anfrage bearbeiten. Stateless-Applikationen können somit flexibel über unterschiedliche Server skalieren und reduzieren damit interne Abhängigkeiten in der Anwendung. Automated – Automatisierung der Prozesse Die Prozesse im Lebenszyklus einer Applikation sollen automatisiert sein. Dies fängt bei der Bereitstellung der Infrastruktur an und reicht bis zum Aktualisieren der bereitgestellten Applikationen. Automatisierte Abläufe ermöglichen es, die genutzte Infrastruktur an die Applikationen in Echtzeit und ohne menschliche Aufwände anzupassen sowie die Anzahl der ungenutzt vorgehaltenen Ressourcen zu minimieren. Die Skalierung zu faktisch Null-Grenzkosten wird somit möglich. Elastic – Elastische Skalierung jedes einzelnen Services Elastizität bedeutet, dass jeder Dienst unabhängig von den anderen seinen Bedarf an Ressourcen an die jeweilige Nachfrage anpassen kann. Dies ermöglicht eine kostensparende Skalierung der Infrastruktur. Resilience – Widerstandsfähigkeit bei Ausfällen Die Anwendung soll robust mit Fehlern in Soft- und Hardware umgehen. Resilient entwickelte Applikationen bleiben insgesamt funktionsfähig, auch wenn einige ihrer Services ausgefallen sind oder nicht antworten. Dank dieses Prinzips benötigen Cloud-Native-Applikationen keine Wartungsfenster, sondern stehen auch zur Verfügung, wenn Updates eingespielt oder Wartungsarbeiten durchgeführt werden. Zudem haben resiliente Anwendungen weniger harte Anforderungen an die Ausfallsicherheit von Infrastrukturkomponenten – was sich positiv auf deren Betriebskosten auswirkt.

6.5 Software-Architektur

167

Werden alle diese Architektur-Richtlinien bei der Entwicklung umgesetzt, so entstehen Applikationen, die darauf ausgerichtet sind, die Vorteile der Cloud zu nutzen. Jeder Microservice nutzt für sich ein autarkes Set an Middleware und Infrastruktur und bedient sich dabei der einfach nutzbaren IT-Fertigteile. Relevante Kosten entstehen nur in jenen Microservices, die tatsächlich genutzt werden. Die Anpassung der Ressourcen erfolgt automatisch in der Größe von Mikrotransaktionen. Im Erfolgsfall werden elastisch beliebig viele weitere IT-Ressourcen bis hin zur globalen Skalierung hinzugenommen. Fallen Ressourcen aus, werden automatisch neue gestartet.

6.5.4 Gegenüberstellung von Monolithen und Cloud-Native-Architekturen Die Entwicklung der Software-Architektur von monolithischen Anwendungen hin zu auf Microservices basierenden Cloud-Applikationen hatte enorme Auswirkungen auf die wirtschaftlichen Metriken von digitalen Geschäftsmodellen. Aus großen Software-Monolithen mit vielen und häufig schwer durchschaubaren Abhängigkeiten wurden Anwendungen, die aus vielen kleinen Komponenten bestehen und deren Abhängigkeiten transparent und beherrschbar sind (s. Abb. 6.17). Abhängigkeiten bestehen in Monolithen in den folgenden drei Dimensionen: 1. IT-Stack – von der Infrastruktur über die Middleware bis hin zur Anwendung 2. Prozess – vom Setup der Anwendung und der Komponenten über den Betrieb bis zur Weiterentwicklung 3. Software-Funktionalität – von der Datenhaltung über die fachliche Logik bis zur Darstellungsebene.

Weiterentwicklung

Betrieb

Große Soware mit komplexen Abhängigkeiten

Darstellung

Fachliche Logik

Datenhaltung

Setup

Moderne Cloud-Architekturen reduzieren die Abhängigkeiten, indem

Kleine Komponenten mit beherrschbaren Abhängigkeiten

Abb. 6.17   Reduktion von Abhängigkeiten und Komplexität

168

6  Software als Kernkompetenz beherrschen

Microservice

Microservice

Microservice

Geringere organisatorische Komplexität Resilienz sta hohe Komponenten-Verfügbarkeit Skalierung je Teilkomponente und in feinen Stufen

Senkung der Fixkosten Senkung der Grenzkosten

Abb. 6.18   Vom Monolith zu Microservices – wirtschaftliche Auswirkungen

• ein möglichst großer Teil der IT-Wertschöpfung über die IT-Fertigteile in die Public Cloud outgesourct wird; • in einem Microservice die Gesamtverantwortung für einen kleinen Teil der fachlichen Logik und Datenhaltung sowie teilweise der Darstellungsebene zusammengeführt wird; • dieser Microservice dann von einem kleinen Team aufgebaut, betrieben und weiterentwickelt wird; • die Microservices untereinander entkoppelt über ReST-APIs kommunizieren. Bezogen auf den Verbrauch von IT-Infrastruktur-Ressourcen hat das dezentrale Modell die größeren Vorteile (s. Abb. 6.18). Es muss wesentlich weniger Rechenkapazität vorgehalten werden und Kosten entstehen nur bei jenen Microservices, die tatsächlich genutzt werden. Der Umgang mit Ausfällen ist bei klassischen Ansätzen von der Idee der Fehlervermeidung geprägt. Komponenten werden mit hohen fixen Kosten so gut wie möglich verfügbar gehalten. Cloud-Native-Architekturen verfolgen dagegen die Idee der Resilienz: Die Gesamtanwendung soll verfügbar bleiben, auch wenn es einzelne Komponenten nicht sind. Auf diese Weise werden fixe Kosten reduziert und in Einzelfällen sogar die Gesamtverfügbarkeit erhöht.

6.6 Prozessabläufe Eine funktionierende Software-Architektur alleine reicht aber nicht aus, um ein Unternehmen an die Bedingungen des digitalen Wettbewerbs anzupassen. Um eine erfolgreiche Cloud-Transformation durchzuführen, müssen auch die Prozesse innerhalb eines Unternehmens angepasst werden. Im Bereich der Software können zwei Prozessarten unterschieden werden (s. Abb. 6.19): 1. Zum einen können jene Prozesse untersucht werden, die von der Idee bis zur allseitig geklärten technischen und funktionalen Anforderung zwischen den beteiligten ­Menschen vor sich gehen. 2. Darüber hinaus gibt es in Unternehmen, die Software herstellen, Entwicklungs- und Betriebsprozesse – von der Planung des Software-Codes über deren Erstellung bis zum sicheren und agilen Betrieb der Anwendung.

6.6 Prozessabläufe

169

Prozesse zwischen den beteiligten Menschen …

Endnutzer

Kunde

Product Owner

Product Manager

SowareArchitekt

ProjektLeiter

Chef

Chef

Tester

BetriebsMitarbeiter

SowareEntwickler

… und Entwicklungs- und Betriebsprozesse. … über die Entwicklung des Codes …

Effizient und sicher vom Bauchgefühl …

… zum sicheren und agilen Betrieb der Anwendung.

… bis zur allseig geklärten technischen Anforderung …

Plan

Code

Build

Test

Release

Deploy

Operate

Abb. 6.19   Prozessabläufe von der Idee bis zum Betrieb

Beide Bereiche hängen eng zusammen und werden im DevOps-Ansatz direkt verzahnt.

6.6.1 Agil von der Idee bis zur Entwicklung des Codes Agilität meint die Fähigkeit einer Institution bzw. eines Unternehmens, flexibel auf Änderungen am Markt zu reagieren, sich in schneller Folge an diese Veränderungen anzupassen und dabei nach innen hin Zusammenhalt und Strukturen aufrechtzuerhalten (MacCormack et al. 2017). Dies wird unter anderem dadurch ermöglicht, dass interne Prozesse und Bürokratieaufgaben minimiert werden und die einzelnen Mitarbeiter gleichzeitig mit größerer Verantwortung für das Endprodukt ausgestattet werden. Die Software-Entwicklung nimmt in der Umsetzung von agilen Arbeitsmethoden in vielen Unternehmen eine Vorreiterrolle ein (Jacobs 2017). Wie in Abschn. 4.2.1 beschrieben, wurde Software früher auf klassische Art und Weise nach dem Wasserfallmodell oder vergleichbaren, planungsorientierten Ansätzen entwickelt. Allen diesen planungsorientierten Ansätzen sind einige Grundprobleme gemein: • Gruppen von Menschen fällt es schwer, ein gemeinsames Bild einer abstrakten und vielschichtigen Software zu entwickeln und dieses so genau zu beschreiben, dass es von einer anderen Gruppe risikolos umgesetzt werden kann. • Im Wissen darum entstehen immer umfassendere Leistungsbeschreibungen. Zudem versuchen die Beteiligten, die Verträge so zu formulieren, dass Risiken jeweils von der anderen Partei getragen werden müssen. Diese Dynamik erzeugt hohe bürokratische Aufwände und verlangsamt die Umsetzung enorm. Ist die Software dann tatsächlich gemäß der ursprünglichen Beschreibung umgesetzt, haben sich die Anforderungen des Marktes und die Wünsche der Kunden häufig schon wieder geändert, es entstehen weitere, kostenintensive Änderungen.

170

6  Software als Kernkompetenz beherrschen

ProjektLeiter

Endnutzer

Lieferant / Soware-Team

…

Kunde

Kunde / Nutzer

Menschen schauen sich konkrete Software an und verbessern diese schrittweise und gemeinsam.

Product Manager

…

BetriebsMitarbeiter SowareEntwickler

Soware Abb. 6.20   Agil als schrittweise und kollaborative Softwareentwicklung

Das agile Modell der Software-Entwicklung stellt die Antwort auf die genannten Probleme dar (Abb. 6.20). Die Leitlinien des agilen Modells lauten (Agile Manifesto 2001): • • • •

Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans

Die Projektrisiken werden nicht durch Vertragsverhandlungen und abstrakte Leistungsbeschreibungen reduziert, sondern durch frühes Feedback der beteiligten Menschen zu nutzbaren Prototypen einer Software. Das Problem, dass Stakeholdergruppen oft Schwierigkeiten haben, sich auf ein klares und spezifisches Bild einer Software zu einigen, wird dadurch gelöst, dass neue Ideen und Wünsche in kurzen Zyklen umgesetzt werden und dadurch besser miteinander diskutiert werden können. Agiles Vorgehen ist ideal für die Entwicklung von Applikationen, denn es nutzt die Eigenheiten des nicht-physischen Produktes „Software“ besonders gut: Software erlaubt die Entwicklung von Funktionen in beliebiger Reihenfolge. Es könnte

6.6 Prozessabläufe

171

Materielle Güter

Soware

Erst wenn das Fundament steht, kann der erste Stock gebaut werden.

versus

Funkonen können in beliebiger Reihenfolge entwickelt werden.

Erste funkonsfähige Hardware herzustellen ist teuer, sie zu verändern o nicht möglich.

versus

Erste, funkonsfähige Soware ist günsg erstellt und einfach veränderbar.

Hardware ist anfassbar und Zusammenhänge sind einfacher vorstellbar.

versus

Soware-Artefakte sind für Laien kaum vorstellbar.

Schnelle und anfassbare Prototypen sowie systemasche Kommunikaon zwischen den Beteiligten reduzieren Missverständnisse und erzeugen konstanten Fortschri.

Abb. 6.21   Agiles Vorgehen ist für nicht-materielle Güter besonders gut geeignet

beispielsweise erst die grafische Oberfläche der Applikation entwickelt werden, die Funktionalitäten dahinter werden dagegen vorerst mit einfachen Mitteln simuliert. So können die Nutzer einer Applikation digitale Arbeitsschritte besser verstehen und ihre Anforderungen treffender beschreiben, bevor aufwendige Back-End-Funktionen dafür entwickelt werden. Es können auch erste voll funktionsfähige Anwendungen mit wenig Leistungsumfang (Bsp: „Nachricht versenden“) entstehen. Diese minimal überlebensfähigen Produkte nennen sich in der Fachsprache „Minimum Viable Products“ (MVPs). Bevor komplizierte und teure Komponenten ergänzt werden (Bsp: „Verschlüsselung“) wird zunächst das Marktfeedback abgewartet. So trägt agiles Arbeiten in der Software-Entwicklung maßgeblich dazu bei, den Zeitraum zwischen der Idee und dem Go-Live einer Software zu verkürzen (s. Abb. Abb. 6.21).

6.6.2 Mit Scrum Software agil entwickeln Eine agile Methode der Software-Entwicklung, die bereits seit den 1990er-Jahren in der Projektentwicklung und -umsetzung Anwendung findet, heißt Scrum (Schwaber und Sutherland 2013). Bei dieser grundsätzlich teamorientierten Vorgehensweise werden drei Rollen, fünf unterschiedliche Ereignisse und drei Artefakte unterschieden. Scrum als Verfahren und Regelwerk definiert das Zusammenspiel zwischen diesen Akteuren, Ereignissen und Artefakten. Die Rollen lauten Product Owner, Entwicklungsteam und Scrum Master. Zusammen bilden diese drei Rollen das Scrum-Team. • Der Product Owner ist für das Produkt, die Umsatzentwickung des Produkts und dessen Weiterentwicklung verantwortlich. • Für die Erstellung und Weiterentwicklung des Produkts ist das Entwicklungsteam zuständig. Es arbeitet in dieser Funktion selbstbestimmt und ohne von außen

172

6  Software als Kernkompetenz beherrschen

v­orgegebene Hierarchie. Je nach Umfang des Projekts kann die Größe des Entwicklungsteams variieren. • Der Scrum Master hat die Funktion eines Coaches und unterstützt das Team auf dem Weg zum selbstbestimmten und effizienten interdisziplinären Arbeiten. Vor allem kümmert er sich darum, dass das Team die idealen Rahmenbedingungen bekommt und sorgt dafür, dass Hindernisse beseitigt werden. Die fünf Ereignisse heißen: • Entwicklungssprint: Die eigentliche Produktentwicklung innerhalb eines Scrum-Teams findet im Rahmen sogenannter Entwicklungssprints statt. Diese Sprints sind üblicherweise zwischen zwei Wochen und einem Monat lang und dienen der Fertigstellung oder Verbesserung eines vorher definierten und klar umrissenen Produkts bzw. Produktinkrements. • Sprint Planning: Im Sprint Planning arbeiten die Teammitglieder die Aufgabenstellungen für die zukünftigen Entwicklungssprints aus und verpflichten sich dazu („Commitment“) – d. h. sie geben eine verbindliche Zusage, welchen Funktionsumfang sie im kommenden Sprint umsetzen wollen. In vielen Unternehmen wird für das Sprint Planning ein Arbeitstag angesetzt, an dem das Team zusammenkommt und gemeinsam die Zielausrichtung des Sprints bestimmt. • Daily Scrum: Das Daily Scrum ist ein täglich durchgeführtes Ereignis. Dabei kommt das Scrum-Team zusammen, um die Arbeit zu koordinieren und den Zwischenstand für alle Mitglieder transparent zu machen. Um den Umfang dieser Daily Scrums zu beschränken, wird in der Regel ein rigides Zeitfenster festgelegt. Je nach Teamgröße sollte dieser Event nicht länger als 15 bis 20 min dauern. • Sprint Review: Am Ende des Sprints steht der sogenannte Sprint Review. Hier kommen die Teammitglieder zusammen, um die Ergebnisse des Sprints zu evaluieren und die Learnings für die kommenden Sprints festzuhalten. Zu diesem Zweck werden die Ergebnisse des Sprints den Stakeholdern und vor allem den Nutzern vorgestellt und ein Feedback eingeholt. Die Zusammenfassung bildet die Ausgangslage für die Formulierung neuer Ziele im Sprint Planning. • Sprint Retrospective: Die Sprint Retrospective findet zeitlich zwischen dem Sprint Review und dem darauffolgenden Sprint Planning statt. Sie gibt allen Teammitgliedern die Möglichkeit, die gesammelten Erfahrungen zu reflektieren und Wünsche und Erwartungen an die kommenden Entwicklungssprints zu formulieren. Diese werden in konkrete Verbesserungsvorschläge umgewandelt. In der Regel ist ein Zeitraum von bis zu drei Stunden für die Sprint Retrospective vorgesehen. Die drei Artefakte sind das Product Backlog, das Sprint Backlog und das Product Increment:

6.6 Prozessabläufe

173

• Das Product Backlog ist eine Liste mit angestrebten Produkteigenschaften, an der sich das Entwicklungsteam orientieren kann. Die Inhalte des Product Backlogs sind nach ihrer Wichtigkeit geordnet, d. h. die zentralen Elemente und Anforderungen an das Produkt stehen am weitesten oben in der Liste. Geführt wird das Product Backlog vom Product Owner des Scrum-Teams. Er ist auch für die Anpassung des Backlogs verantwortlich, wenn sich während des Entwicklungs- und Verbesserungsprozesses Änderungen einstellen. • Sprint Backlog: Das Sprint Backlog legt fest, welche Punkte des Product Backlogs in einem anstehenden Entwicklungssprint bearbeitet bzw. verbessert werden sollen. Darüber hinaus enthält das Sprint Backlog Informationen darüber, wie das vorgegebene Ziel in der beabsichtigten Zeit und mit den gegebenen Ressourcen erreicht werden soll. Für das Führen und Updaten des Sprint Backlogs ist das gesamte ScrumTeam zuständig. Im Idealfall zeichnet das Sprint Backlog ein Echtzeit-Bild des Fortschritts eines Teams bei seiner Arbeit innerhalb eines Entwicklungssprints. • Product Increment: Das Inkrement wird auch als „Done“ bezeichnet. Es ist das Ergebnis, das von den Teammitgliedern am Ende des Entwicklungssprints abgeliefert wird. Ziel des Sprints sollte es unter allen Umständen sein, ein veröffentlichungsfähiges Inkrement zu erzeugen. Diese Fähigkeit des Inkrements ist unabhängig davon, ob das finale Produkt wirklich ausgeliefert wird oder nicht. Die Durchführung eines Scrum-Prozesses basiert auf drei idealtypischen Säulen: Transparenz, Überprüfung und Anpassung. Das heißt, jeder Einzelschritt, den ein Teammitglied im Rahmen eines Scrum-Prozesses erledigt, sollte auch an diesen drei Bedingungen ausgerichtet und messbar sein. Im Idealfall sollte jedes Teammitglied permanent in der Lage sein, die Arbeitsschritte der anderen Teammitglieder einzusehen und einer kritischen Überprüfung zu unterziehen. Bei der Einführung von Scrum geht es nicht darum, einen idealtypischen Prozess zu implementieren. Kern von Scrum ist die ständige Verbesserung: Ergebnisse, Vorgehensund auch Verhaltensweisen im Team werden immer wieder hinterfragt, um sich so an die Bedingungen im Unternehmen, vor allem aber an die Bedingungen des Marktes anzupassen. Der Scrum-Prozess ist daher immer „Work in progress“, oder anders gesagt: eine permanente Verbesserungsaufgabe. Speziell im Bereich der Softwareentwicklung spielt die Srum-Methode heute eine große Rolle (Luber und Augsten 2017). Abb. 6.22 verdeutlicht das Zusammenspiel der drei Scrum-Rollen im Prozess der Software-Wertschöpfung: Der Scrum-Master ist dafür verantwortlich, dass das Entwicklungsteam und der Product-Owner in den Phasen „Plan“, „Code“ und „Build“ vor den Einflüssen der team-externen Stakeholder geschützt werden. Nur so kann gewährleistet werden, dass das Scrum-Team als selbstbestimmte Einheit innerhalb des Unternehmens agieren kann.

174

6  Software als Kernkompetenz beherrschen

6.6.3 Mit CI/CD Software automatisiert testen und bereitstellen Das Kürzel „CI/CD“ steht für „Continuous Integration“ (Augsten 2018) und „Continuous Deployment“. Es bezeichnet die Automatisierung von Teilen des Software-Erstellungsprozesses, wobei folgende Schritte durchlaufen werden (s. Abb. 6.23): • • • • • •

Plan: Die zu erstellende Software und deren Features werden geplant. Code: Der eigentliche Software-Code wird geschrieben. Build: Der Code wird kompiliert, also in Maschinensprache umgewandelt. Test: Der neu geschriebene Code wird getestet. Release: Die getestete Software wird zur weiteren Verwendung veröffentlicht. Deploy: Die Software wird auf der Live-Infrastruktur installiert und ist damit für die Nutzer verwendbar. • Operate: Der laufende Betrieb der Software wird sichergestellt. Continuous Integration (CI) betrifft den Prozess von der Planung bis zum Testen der Software. Der besondere Schwerpunkt liegt dabei in der Automatisierung der Integrations-Tests. Neu erstellter Code eines Entwicklers wird kontinuierlich in die Gesamt-Codebasis integriert und auf dessen Funktionsfähigkeit im Kontext der Gesamtanwendung geprüft. Continuous Deployment (CD) umfasst zusätzlich die Schritte „Release“ und „Deploy“. Die neuen Funktionen der Software werden in einer CD-Umgebung automatisiert auf die Live-Umgebung ausgespielt. Um die Relevanz dieser beiden Vorgehensweisen zu verstehen, ist ein Ausflug in die klassischen Software-Erstellungsprozesse notwendig. Wie schon in Abschn. 4.3 beschrieben, dauert es sehr lange, bis aus einem geplanten Feature eine tatsächlich nutzbare

Kunde Bereichsleiter Endnutzer Beachtung der menschlichen Aspekte Understand

Agree Sozialer Kontext

Andere Projekte

Controller

Teamleiter

Berater Scrum Master

Product Owner

Designer

Entwickler

Selbstbesmmtes Team

Entwickler

Plan

Code

Schutz des Teams vor äußeren Einflüssen

Architekt Experte

Build

Test

Release

Deploy

Prozess der Sowareentwicklung

Abb. 6.22   Scrum als erfolgreiches Modell am Anfang der Software-Wertschöpfung

Operate

6.6 Prozessabläufe

Plan

175

Code

Build

Test

Release

Deploy

Operate

Connuous Integraon Connuous Deployment

Abb. 6.23   Klassischer Prozess der Software-Bereitstellung mit hohen Kommunikations- und Verwaltungsaufwänden

Funktion im Live-System wird. Der Grund für diese langen Releasezyklen liegt darin, dass in der klassischen IT viele Planungs-, Bestell- und Delivery-Prozesse manuell und über verschiedene Organisationseinheiten getrennt durchgeführt werden. Ein solcher Releaseprozess kann in der Realität wie folgt aussehen: Die Planung und die damit einhergehende Kalkulation der neuen Funktionalitäten erfolgt in der Fachabteilung. Diese übergibt ein Anforderungsdokument an die Entwickler. Diese sind, der niedrigeren Tagessätze wegen, an einem Offshore-Standort lokalisiert – gesteuert werden diese Kollegen aber von einer Projektleitungsabteilung am Heimat-Standort des Unternehmens. Der Code wird erstellt und an ein Test-Team übergeben, das zwei Wochen daran arbeitet. Die gefundenen Fehler werden an das Entwicklungsteam zurückgemeldet, das sich nun – anstatt neue Funktionen zu erstellen – um die fehlerhaften, alten Funktionen kümmert. Ist der Code zum Deployment freigegeben, erstellt das Entwicklungsteam ein Deployment-Dokument sowie ein Betriebshandbuch und übergibt diese Unterlagen an ein weiteres Team. Dieses ist in einem ganz anderen Bereich des Unternehmens verortet, dem IT-Infrastruktur-Betrieb. Treten in diesem Prozess an einer beliebigen Stelle zwischen Fachabteilung und Endnutzer Probleme auf, wird die gesamte Prozesskette über die verschiedenen Abteilungen und Bereiche hinweg nach Fehlern und Schuldigen durchsucht. Zu diesem Zweck lesen unabhängige Dritte wie Controller und Juristen Anforderungsdokumente, Testprotokolle und Betriebshandbücher und moderieren die in Erscheinung tretenden, meist konfligierenden Sichtweisen der Beteiligten. Dank der durch Cloud-Technologien entstandenen Möglichkeit, alle IT-Komponenten per Software-Code über eine API anzusprechen, können von der ersten Stufe des Softwareprozesses (Erstellung des Codes) bis zum Deployment des Codes auf der Live-Infrastruktur alle Prozessschritte automatisiert werden. Dies führt zu deutlichen Verbesserungen im gesamten Prozess: • Neue Funktionen werden kontinuierlich in die Gesamt-Code-Basis integriert. • Fehlerhafter Code wird früh erkannt und kann schnell verbessert werden. • Entwickler müssen nicht mehr auf die Fertigstellung benötigter Software-Teile ­anderer Teams warten.

176

6  Software als Kernkompetenz beherrschen

• Anzahl und Umfang der durch Menschen durchgeführten Tests kann stark oder auf Null reduziert werden. • Entwickler können selbst die Software auf die Infrastruktur ihrer Wahl ausspielen. • Die Dauer von der Anforderung einer neuen Funktion bis zu deren Veröffentlichung reduziert sich enorm – mitunter auf einen Tag. • Es entfallen die Kommunikations- und Verwaltungsaufwände sowie die Übergaberisiken zwischen den Abteilungsgrenzen von Code bis Deploy.

6.6.4 Mit DevOps und Feature-Teams den gesamten Prozess abdecken Der Begriff DevOps ist ein Kunstwort. Es besteht aus den zwei Begriffen Development (Softwareentwicklung) und Operations (Betrieb). Rob England hat auf seinem Blog eine Zusammenschau von Definitionen des Begriffs erstellt und daraus eine eigene Definition entwickelt, die an dieser Stelle übernommen wird (England 2014): „DevOps is agile IT operations delivery, a holistic system across all the value flow from business need to live software.“ Frei übersetzt heißt das:   „DevOps ist die agile Bereitstellung von IT, welche die Wertschöpfung vom laufenden Geschäft bis zur funktionierenden Software ganzheitlich unterstützt.“ England führt in seinem Beitrag aus, dass es sich bei DevOps nicht um einen bloßen Werkzeugkoffer oder ein Automatisierungstool handelt, sondern um eine Philosophie. Bei der Implementierung von DevOps in Unternehmen geht es um die Zusammenführung von Software-Entwicklung und IT-Betrieb auf den Ebenen von Kultur, der Systeme, Praktiken und Werkzeuge (s. Abb. 6.24). Ziel dieser Umstellung ist die Orientierung der IT am Bedarf des Kunden, um die Verbesserung der Qualität und der Geschwindigkeit.

Das DevOps-Team teilt Systeme, Werkzeuge, Prozesse und eine gemeinsame Kultur.

Ideate

Plan

Code

Build

Test DevOps

Feature Teams

Abb. 6.24   DevOps als agile Form der Bereitstellung von IT

Release

Deploy

Operate

6.6 Prozessabläufe

177 Kunde oder Markt Lernen Kultur

Gesamtverantwortung Fluss

Abb. 6.25   DevOps – die vier charakterisierenden Begriffe

Die ideale Team-Größe für DevOps-Teams sind fünf bis zehn Mitarbeiter (Choi 2018). Im amerikanischen Sprachgebrauch heißen diese Teams daher auch Zwei-Pizza-Teams, da alle Mitglieder des Teams von zwei amerikanischen Pizzen satt werden sollten. Die Mitglieder von DevOps-Teams werden im Idealfall organisatorisch zusammengeführt. Aus jeweils reinen Entwickler- und Operations-Abteilungen („Silos“), die für viele Kunden und Services kleine Teilaufgaben erledigen, werden kleine und fachübergreifend besetzte Teams, die sich vollverantwortlich auf einen oder wenige Services fokussieren. Die DevOps-Philosophie lässt sich gut mit den folgenden vier Begriffen charakterisieren: Gesamtverantwortung, Fluss, Lernen und Kultur (s. Abb. 6.25). Gesamtverantwortung – klarer Fokus auf den Kunden Der Schlüssel zu DevOps ist der neue Zuschnitt der Aufgaben: Das Team erhält eine Ende-zu-Ende-Verantwortung (end-to-end) für einen oder wenige Services mit klarem Fokus auf den Kunden. Der Verantwortungsbereich ist über die Software-Schnittstellen (APIs) sowohl gegenüber den Lieferanten als auch gegenüber den Kunden klar abgrenzbar. Diese Gesamtverantwortung bedingt eine interdisziplinäre Zusammensetzung. Grundsätzlich werden Entwickler (Dev) und Betriebsmitarbeiter (Ops) gebraucht, je nach Service kommen noch Security-Experten oder Designer hinzu. Häufig werden jene Kollegen involviert, welche die fachlichen Anforderungen stellen. Handelt es sich zum Beispiel um eine Übersetzungssoftware, könnten das Linguisten sein; geht es um die Bewertung von Büchern, könnten es Lektoren sein. Teams mit solchen Fachexperten nennen sich auch „BizDevOps“ oder „Feature Teams“. Ein häufig verwendeter Leitspruch, der die Gesamtverantwortung illustrieren soll, ist „You build it, you run it“. Das heißt: Das Team, dass die Funktionalität entwickelt hat, ist auch dafür verantwortlich, wenn sie einmal nicht funktioniert. Früher wurden in solchen Fällen die Kollegen aus dem „Betriebs-Silo“ angerufen, jetzt muss ein Kollege aus dem Team selbst nachts aufstehen und den Code reparieren.

178

6  Software als Kernkompetenz beherrschen

Fluss – Einfachheit, Geschwindigkeit und Automatisierung Die Prozessoptimierungsideen bei DevOps orientieren sich stark an Modellen, die in der produzierenden Industrie entwickelt wurden. Es geht wie bei „Lean“ (Produktion 2017a) darum, die Verschwendung zu reduzieren. Es wird kein Code in großen Softwarepaketen „auf Lager“ produziert, sondern fertige, kleine Funktionen werden sofort durchgetestet und veröffentlicht. Die Wartezeiten sinken, weil die Teams klein sind und die Zusammenarbeit vertrauensvoll ist. Durch Automatisierung und die Nutzung möglichst vieler IT-Fertigteile aus der Cloud werden Arbeitsschritte vereinfacht. Nach dem Pull-Prinzip der Kanban-Produktionssteuerung (Lean Production 2019) entnehmen Entwickler Funktionen aus dem Aufgabenbestand und begleiten diese im Sinne des OnePiece-Flows (Produktion 2018) – analog zur Optimierung von Montagelinien – bis zum Release. Dies senkt die Durchlaufzeit, reduziert den Bestand halbfertiger Funktionen und fördert die Identifikation des Mitarbeiters mit seiner Arbeit – es ist ja „sein“ Feature. Lernen – schnelle und datenbasierte Feedback-Schleifen Ein weiteres Element von DevOps ist das ständige Lernen. Jede Funktion wird sofort automatisiert getestet. Erzeugt sie nach dem Release trotzdem Probleme, werden diese schnell behoben und die Testverfahren werden erweitert. Beim A/B-Testing werden zwei Varianten einer Funktion erzeugt und an unterschiedliche Nutzergruppen ausgespielt. Aus den daraus entstehenden Daten werden dann objektive Entscheidungen getroffen. Funktionierende DevOps-Teams leben die kontinuierliche Verbesserung – wiederum eine Parallele zum „Kaizen-Gedanken“ in der Industrieproduktion (Produktion 2017b). Überwindung des Silo-Denkens in Unternehmen Die Überwindung des Silo-Denkens spielt eine sehr große Rolle bei der Umsetzung von DevOps. Um die Relevanz des Themas zu verstehen, ist ein Ausflug in die Welt der klassischen IT notwendig. Die in Abb. 6.23 visualisierten Mauern sind oft Mauern, an denen das Vertrauen endet. Der Kunde vertraut nicht darauf, dass die Entwickler wirklich die gewünschten Funktionen erzeugen – und wenn doch, dann nicht zum gewünschten Preis. Daher werden Juristen und Controller involviert, die versuchen, die Risiken zu verlagern, statt sie zu reduzieren. Schließlich programmieren die Entwickler den Code, die Betriebs-Kollegen aber vertrauen nicht darauf, dass der Code auch stabil laufen wird. Häufig zurecht, denn die Entwickler müssen die Funktionen unter Zeitdruck entwickeln – ob sie dann zuverlässig betrieben werden können, liegt nicht mehr in ihrer Verantwortung. Die Interessenlagen der drei wichtigsten Stakeholdergruppen – Kunde, Entwickler und Betriebs-Mitarbeiter – sind in der klassischen IT nicht synchronisiert. Diese Trennung manifestiert sich auch organisatorisch und zuweilen arbeiten diese Silos auf gegenläufige Ziele hin. Mitarbeiter, die dieses von Misstrauen geprägte Miteinander jahrelang erlebt und gelebt haben, nehmen das Kulturthema sehr ernst. Sie wissen, dass eine Kultur des Vertrauens, des Empowerments, des professionellen, konstruktiven Miteinanders für alle Beteiligten nicht nur angenehmer ist, sondern auch zu besseren Ergebnissen führt.

6.7  Menschen und Organisation

179

DevOps in Reinform sind in vielen Fällen schwer implementierbar. Es gibt zum einen technische Voraussetzungen, damit die Schritte vom Test bis zum Deployment tatsächlich vollautomatisiert ablaufen können. Bei einigen Anwendungen sind Unternehmen auf externe Standardsoftware angewiesen, deren Entwickler weder rechtlich noch logistisch in ein solches Team integriert werden können. Auch Kunden lassen sich nicht organisatorisch integrieren. DevOps ist daher nicht als eine Art ISO-Norm zu betrachten, die das Unternehmen erfüllt oder eben nicht. Es ist tatsächlich eher ein Idealbild, das es anzustreben lohnt.

6.7 Menschen und Organisation Für den Erfolg der digitalen (Cloud-)Transformation eines Unternehmens spielen die Faktoren Virtualisierung, Sourcing, Software-Architektur, Prozessabläufe und Unternehmensorganisation eine herausragende Rolle (Abschn. 6.2 bis 6.4). Was in der bisherigen Darstellung allerdings fehlt, ist der Faktor Mensch – und hier gilt im wahrsten Sinne des Wortes: last but not least. Der aktuelle Digitalisierungsmonitor des Beratungsunternehmens BearingPoint weist darauf hin, dass der für die Digitalisierung notwendige Kulturwandel in zahlreichen Unternehmen in Deutschland noch nicht – oder nur zögerlich – umgesetzt wird (Broj und Schulz 2017) Die Integration der Mitarbeiter in den Prozess der Transformation ist in der Regel nicht einfach und verläuft in vielen Fällen „holprig“. Grund für diese Holprigkeit sind Fehler des Managements im Umgang mit den (potenziellen) Mitarbeitern in den drei Teilbereichen Mitarbeiterführung, Anpassung der Unternehmenskultur und Beschäftigungssituation.

6.7.1 Mitarbeiterführung Eine erfolgreiche digitale Transformation beginnt im Organigramm ganz oben: beim Management, und zwar am besten beim Top-Management, d. h. bei der Geschäftsleitung bzw. beim Vorstand. Die Mitglieder des Top-Managements sollten nicht nur davon überzeugt sein, dass eine agile Transformation die richtige Entscheidung für das Unternehmen ist. Sie sollten auch verstehen, warum diese Transformation für das Unternehmen wichtig ist. Denn nur, wenn das Management das argumentative Rüstzeug und das intuitive Verständnis für die notwendige Transformation hat, können die Verantwortlichen glaubhaft die Veränderungen gegenüber der Belegschaft vertreten und umsetzen. Bezogen auf den digitalen Transformationsprozess bedeutet dies: Die Pläne der Unternehmensstrategen für eine interne Anpassung des Unternehmens an die Digitalisierung können noch so durchdacht und rational sein. Wenn es nicht gelingt, die Mitarbeiter des Unternehmens kommunikativ auf den Wandel vorzubereiten, werden Change- bzw. Transformationsprozesse notwendigerweise scheitern.

180

6  Software als Kernkompetenz beherrschen

Im Rahmen dieses Vermittlungsprozesses müssen sich die Mitarbeiter mit ihren Ängsten vom Management abgeholt fühlen und verstehen, in welche Richtung das Unternehmen steuert. Hier sind insbesondere die kommunikativen Fähigkeiten des Top-Managements, der Kommunikationsabteilung und der Personalabteilung gefragt. Bewährt haben sich zum Beispiel Infoveranstaltungen und Treffen zwischen den verschiedenen Hierarchieebenen. In einem informellen Rahmen kann die Führungsriege besser vermitteln, warum der Wandel notwendig ist (Nadella 2017). Neben der Information der gesamten Belegschaft rücken einige Stakeholder-Gruppen in das Zentrum der kommunikativen Bemühungen, da diese in der Lage sind, mit ihrem unternehmensinternen Einfluss den Transformationsprozess zu bremsen oder zu stoppen. Ein guter Manager fungiert in der Kommunikation mit diesen Stakeholder-Gruppen wie ein Hausarzt, der die Probleme, die mit der digitalen Transformation auf das Unternehmen zukommen, rechtzeitig erkennt und die Stakeholder darauf vorbereitet. Es ist wie bei einer Impfung: Der Patient wird davor geschützt, dass eine Krankheit überhaupt auftritt oder zumindest werden die Folgen gemildert (Moore 2016). Bei diesem Impfprozess werden die Stakeholder-Gruppen informiert und im besten Fall auch überzeugt. Beispielsweise sollte die Controlling-Abteilung verstehen, wie wichtig der Transformationsprozess für das Fortbestehen des Unternehmens ist. Das bedeutet auch, dass bei der Erfassung der Leistungsziele eines Unternehmens neue Sichtweisen integriert werden sollten. Damit gehen möglicherweise neue KPIs einher, mit denen der Erfolg des Unternehmens über die üblichen Finanzkennzahlen hinaus gemessen wird. So kann das Controlling um „weiche“ Kenngrößen erweitert werden, die den Transformationserfolg in Zahlen abbilden: Zum Beispiel kann gemessen werden, wie gut der interne Informationsaustausch funktioniert oder wie weit die Vereinheitlichung und Automatisierung von Tools und Prozessen zwischen den Unternehmensabteilungen fortgeschritten ist. Darüber hinaus sollte das Top-Management das Controlling darüber informieren, dass ein Transformationsprozess die Entwicklung der traditionellen Finanzkennzahlen zunächst negativ beeinflussen kann. Wenn das Controlling auf diese Entwicklung vorbereitet wird und dadurch seine Erwartungshaltungen anpassen kann, können „Abstoßungsreaktionen“ gegenüber neuen Ideen, Technologien und Prozessen zumindest eine Zeit lang gelindert werden.

6.7.2 Unternehmenskultur Peter Drucker, der Pionier der modernen Managementlehre, prägte den Satz „Culture eats strategy for breakfast“ (zitiert nach Cave 2017). Was hat er damit gemeint? Seine These lautet: Damit eine interne oder externe Strategie eines Unternehmens erfolgreich sein kann, muss die Unternehmenskultur mit den formulierten Zielen übereinstimmen. Ist dies nicht der Fall, wird die Umsetzung erschwert oder gar unmöglich. Die Anpassungsfähigkeit der gelebten Unternehmenskultur an die Arbeitsbedingungen der DevOps-Kultur wird damit zum Schlüsselfaktor für deren erfolgreiche Adaption.

6.7  Menschen und Organisation

181

Agile DevOps-Teams, die neue Arbeitsprozesse leben, lassen auf Dauer im gesamten Unternehmen eine neue Arbeitskultur entstehen. Dabei verändert sich auch die Sichtweise des einzelnen Mitarbeiters auf seinen Tätigkeitsbereich, denn je mehr sich der DevOps-Gedanke durchsetzt, desto größer wird der Verantwortungsbereich des einzelnen Mitarbeiters. Er kann immer mehr Prozesse selbst auslösen, ohne Rücksprachen mit der Administration halten zu müssen. Unterordnung und Befehlsausführung weichen einem selbstständigen Planungs-, Durchführungs- und Überwachungsprozess. Kurz gesagt wird der Mitarbeiter zum Unternehmer im Unternehmen. Das gibt ihm einerseits größere Freiheiten, andererseits aber eine größere Verantwortung für das Produkt, das er betreut. Bei der Gestaltung dieses Wandlungsprozesses sind die Mitarbeiter gefordert. Sie müssen diese neue Rolle im Unternehmen verstehen, verinnerlichen und mit Leben füllen – wenn sie es denn wollen. Der Wandel der Geisteshaltung kann aber nur gelingen, wenn dieser von einer neuen Fehlerkultur im Unternehmen begleitet wird. Klassische Hierarchien dienen unter anderem dazu, die Leistungen anderer zu kontrollieren und ihre Fehler aufzudecken. Deswegen herrscht in vielen Unternehmen eine Angstkultur: Es darf kein Fehler passieren und schon gar nicht ist es klug, einen Fehler zuzugeben. Das schafft mehr Probleme als Vorteile, da kreative und vor allem wirklich innovative Ideen im Keim erstickt werden. Die Entwicklung einer offenen Fehlerkultur ist daher ein weiterer Baustein im DevOps-Ansatz: Fehler dürfen nicht nur gemacht werden, sie sind sogar der Motor für die Weiterentwicklung des Unternehmens. Denn: Nur wer keine Angst hat Fehler zu machen, hat auch den Mut, neue Dinge auszuprobieren und Probleme anzusprechen. Innovation braucht den Rückhalt der Kollegen und die Courage jedes Einzelnen, um etwas Neues schaffen zu können. Nicht umsonst lautet eines der Prinzipien einer erfolgreichen DevOps-Implementierung „fail fast, learn fast“ (Booth 2014). Für diese Entwicklung ist es wichtig, dass die Fehler im Team und zwischen den Teams sanktionsfrei kommuniziert werden dürfen, damit alle Beteiligten daraus lernen können. Gelingt dieser Wandel, dann setzt diese Entwicklung ein enormes Kreativitätspotenzial im Unternehmen frei. Denn der einzelne Mitarbeiter begreift sich in diesem neuen Umfeld nicht mehr als Rädchen einer Maschinerie, in der ihm seine Aufgaben und sein Platz zugewiesen werden. Vielmehr wird er zum Erfinder, Tüftler, Entwickler und Manager im Unternehmen, der eigenverantwortlich innerhalb seines DevOps-Teams Projekte beginnt, umsetzt und verantwortet. Diese neuen Arbeitsprinzipien in die täglich gelebte Unternehmenskultur zu übernehmen, ist der wichtigste Schritt für eine Integration der Mitarbeiter in den Transformationsprozess. Es ist gleichzeitig der schwierigste Schritt, da er für viele Mitarbeiter mit dem schmerzhaften Abschied von Verhaltensweisen einhergeht, die im traditionellen unternehmerischen Hierarchiesystem eingeübt wurden. Agile Coaches können dabei helfen, die Integration der neuen Arbeitsideen in den Arbeitsalltag zu begleiten.

182

6  Software als Kernkompetenz beherrschen

6.7.3 Beschäftigungssituation Die zunehmende Automatisierung von Prozessabläufen innerhalb der Wertschöpfungsketten verändert die Beschäftigungssituation. Die Folge ist unter anderem ein sinkender Bedarf der Unternehmen an Mitarbeitern, deren Tätigkeit in wiederholbaren und automatisierbaren Arbeitsschritten besteht. Bezogen auf die IT-Abteilungen in Unternehmen ergibt sich damit eine interessante Ausgangssituation. Intuitiv spricht vieles dafür, die Zahl der Arbeitsplätze in der IT zu reduzieren – schließlich können klassische Aufgaben wie der Betrieb und die Wartung des Stacks ja von Algorithmen und Software gesteuert werden. Genau das Gegenteil ist aber der Fall: IT-Mitarbeiter sind aktuell so gesucht wie noch nie. Der Fachverband Bitkom meldete im Jahr 2018 rund 82.000 offene IT-Stellen in Deutschland (Bitkom 2018). Auch die Entwicklung der Einstiegsgehälter im IT-Bereich spricht Bände. So sind die Gehälter der Absolventen von IT-Studiengängen längst an jenen von BWL-Absolventen vorbeigezogen (Frank 2017). Ein Grund für diese Entwicklung ist der steigende Bedarf der Unternehmen an gut ausgebildeten Mitarbeitern, die die kreativen und damit in Zukunft wertschöpfenden Tätigkeiten im Bereich von Softwareentwicklung, -herstellung und –betrieb übernehmen können. Dieser zunehmende Bedarf übertrifft aktuell bei Weitem die möglichen Einsparpotenziale an Arbeitskräften, die sich durch eine Automatisierung des IT-Betriebs in der Cloud ergeben. Statt IT-Mitarbeiter abzubauen, besteht die aktuelle Herausforderung vielmehr darin, die vorhandenen IT-Arbeitskräfte an das Unternehmen zu binden und sie auf die veränderten Aufgaben vorzubereiten. Fähigkeiten in der Wartung der IT-Hardware und der klassischen IT-Komponenten werden durch Fähigkeiten entlang des cloudbasierten Software-Prozesses ersetzt – von der Entwicklung bis zum Betrieb. Um diesen Wandel zu gewährleisten, müssen Unternehmen rechtzeitig damit beginnen, die Skills der vorhandenen Mitarbeiter zu entwickeln und ihnen entsprechende Ausbildungsoptionen und -zeiträume zur Verfügung zu stellen. Was ist die Alternative? Natürlich können Unternehmen auch bereits ausgebildete Fachkräfte für die cloudbasierte Software-Wertschöpfung einkaufen. Bis zu einem gewissen Grad werden Unternehmen in der Zukunft auf Wissenszuwachs und Expertise von außerhalb angewiesen sein. Potenzielle Mitarbeiter, die sich in den vergangenen Jahren eine Expertise in den Bereichen Software-Entwicklung und Software-Architektur aufgebaut haben, können diese Ausgangssituation für sich nutzen. Sie können ihre Verdienstmöglichkeiten in den kommenden Jahren massiv ausweiten und ihre neue Verhandlungsmacht gegenüber potenziellen Arbeitgebern ausspielen. Um genügend Potenzial in petto zu haben, werden Unternehmen beides brauchen: die erfolgreiche Weiterbildung ihrer aktuellen IT-Mitarbeiter und ein erfolgreiches Recruiting, das sich im Kampf um die Arbeitskräfte gegen die Mitbewerber durchsetzen kann.

6.8  Praxisbeispiel ING DiBa

183

Die Personalabteilungen spielen also eine zentrale Rolle: Sie müssen ihre Recruiting-Strategien und -Maßnahmen an die neue Ausgangssituation anpassen und gleichzeitig die entsprechenden Fort- und Weiterbildungsmaßnahmen für die Mitarbeiter einkaufen oder sogar selbst entwickeln. Das setzt voraus, dass HR die Digitalisierung und die Cloud-Transformation als kritische Variablen für die anstehenden Entscheidungen begreift. Führung, Kultur und Beschäftigung – das sind die drei Gestaltungsfelder für die Arbeitswelt der Zukunft. Das Augenmerk muss auf allen drei Bereichen liegen, wenn die Transformation nicht scheitern soll. Ein Beispiel für eine gelungene Transformation der Unternehmensprozesse und -kultur liefert die holländische Direktbank ING DiBa, das im folgenden Abschnitt vorgestellt wird.

6.8 Praxisbeispiel ING DiBa Banken hatten bisher nicht den Ruf, agil oder schnell zu sein. Sie waren eher für lange, komplizierte Prozesse und stark ausgeprägte Hierarchien bekannt. Mit ihrem agilen Transformationsprozess zeigt die ING Bank, dass das heute nicht mehr der Fall sein muss (Thienel 2018). Die großen Veränderungen am Finanzmarkt waren einer der Ausgangspunkte für die Überlegung der niederländischen Bank, einen Transformationsprozess zu starten. Durch die junge Generation von Bankkunden änderte sich zudem die Wahrnehmung, was eine Bank anbieten und leisten sollte. Und schließlich blieb auch der traditionsreiche Bankensektor nicht von Startups – in diesem Fall „Fintechs“ – verschont: Junge Unternehmen wie N26 wagten den Markteintritt und stellten damit die schwerfälligen Wertschöpfungsprozesse infrage. Als Reaktion darauf begann ING im Jahr 2015, die interne Organisation an die agilen Richtlinien der DevOps-Strukturen anzupassen. Im Zuge dessen wurden große Teile des Headquarters in Amsterdam umstrukturiert. Gestartet wurde der Prozess mit der Ankündigung, dass mit Beginn der Transformation allen Mitarbeitern ein „mobiler Status“ zugewiesen würde (Jacobs 2017). Das bedeutete, dass nahezu die vollständige Belegschaft „ohne Job“ war und sich innerhalb des Unternehmens neu bewerben musste. So konnte ein vollständig neues Matching zwischen den Interessen und Fähigkeiten der Mitarbeiter und deren zukünftigen Aufgaben erreicht werden. Dieser Prozess war für die Bank und ihre Mitarbeiter durchaus schmerzhaft. Etwa 40 % der Mitarbeiter waren nach der Umstellung in neuen Positionen und Bereichen tätig. Voraussetzung für die erfolgreiche Umstellung der Tätigkeitsbereiche der Mitarbeiter war, dass die Bank bei der Umstellung das richtige „Mindset“ und die Transformationsbereitschaft der Mitarbeiter höher gewichtete als das Wissen und die Erfahrungen in den Teilbereichen. Innerhalb von acht bis neun Monaten wurden 350 Neun-Mann-Teams (sogenannte „Squads“) gebildet und in 13 Teilbereichen (sogenannte „Tribes“) strukturiert (Jacobs 2017).

184

6  Software als Kernkompetenz beherrschen

Die Devise der ING DiBa lautet seitdem: „One agile way of working“. Diese Devise wird mit den folgenden acht Kernpunkten beschrieben: 1. Wir arbeiten in starken und kompetenten Teams. 2. Wir fördern Autonomie und Selbstbestimmung in Teams. 3. Wir fördern Talent und fachliche Expertise. 4. Wir lernen von unseren Kunden und nutzen dieses Wissen, um uns zu verbessern. 5. Wir setzen klare Prioritäten, um unsere übergeordneten Ziele zu erreichen. 6. Wir haben ein einheitliches Organisationsdesign und einheitliche Arbeitsweisen. 7. Wir arbeiten einfach, unkompliziert und verständlich. 8. Wir verbessern Bestehendes, anstatt alles neu zu erfinden. In diesen acht Punkten sind einige wichtige Aussagen enthalten, durch die sich die Arbeitsweise in Unternehmen radikal verändert. Auf zwei dieser Punkte – Autonomie und Selbstbestimmung in Teams – gehen wir hier speziell ein, da diese die größten Veränderungen auslösen. Für die Umsetzung begann die ING damit, ein komplett neues Modell des Arbeitens einzuführen (s. Abb. 6.26). Die größte Veränderung für die Mitarbeiter war die Einführung sogenannter Squads. Die ING Bank beschreibt ein Squad so: „In Squads arbeiten Mitarbeiter aus unterschiedlichen Bereichen und mit verschiedenen Kompetenzen daran, gemeinsam ein Projekt bzw. eine Aufgabe erfolgreich zu lösen“ (ING 2019). Squads werden mit unterschiedlichen kundenzentrierten Aufgabenstellungen betraut. Zur Erfüllung dieser Aufgaben arbeiten Mitarbeiter aus den unterschiedlichsten Fachrichtungen in einem Team zusammen. Mitarbeiter aus dem Marketing mit Mitarbeitern aus der IT, Banker mit Kollegen aus dem Vertrieb. Die Squads bei ING zeichnen sich durch eine End-to-end-Verantwortung der Teammitglieder aus. Dies setzt ein hohes Maß an Vertrauen in die Mitarbeiter voraus. Eine einzelne Squad könnte beispielsweise dem Bereich „Suchmaschinen“ zugewiesen werden

Chapter für Web-Designer Agile Coach

Chapter für Cloud-Architekten

Chapter für das Thema X

Chapter Lead Product Owner

Squad

Squad

für Consumer Online-Banking

für den digitalen Finanz-Check

Squad für die Aufgabe X

Abb. 6.26   Agiles Arbeiten mit Squads, Tribes und Chapters

Squad für die Aufgabe Y

Tribe Lead

6.9 Fazit

185

und mit der Verantwortung für alle Suchmaschinen-Applikationen im gesamten Endkonsumentenbereich betraut werden. Aufgabe dieser Squad wäre es in einem solchen Szenario, möglichst funktionale und kundenfreundliche Suchmaschinendienste über die unterschiedlichen Applikationen des Unternehmens hinweg bereitzustellen. Innerhalb der Squads wird einem Teammitglied die sogenannte „Product Ownership“ übertragen. Dieser Product Owner entscheidet, welche Produkte das Team herstellt. Er betreut darüber hinaus das Backlog und die To-do-Listen des Unternehmens. Das bedeutet aber nicht, dass er den anderen Teammitgliedern gegenüber weisungsbefugt ist. Die Kommunikation über die Squadgrenzen hinaus erfolgt in sogenannten „Chapters“. In den Chapters tauschen sich Mitarbeiter der unterschiedlichen Fachbereiche über die Grenzen der Squad hinweg in regelmäßigen Abständen aus. So kann es beispielsweise ein Chapter „Datensicherheit“ oder ein Chapter „Marketing“ innerhalb des Unternehmens geben. Die Koordination zwischen Squads wird über sogenannte Tribes ermöglicht. Tribes bestehen aus Squads, die alle einem gemeinsamen Ziel zugeordnet werden können. In der Struktur der ING DiBa sind diese Tribes an den Produktklassen der Bank orientiert: Kredite, Girokonten, Hypotheken. In der Regel sollen diese Tribes nicht mehr als 150 Mitarbeiter umfassen. Verantwortlich für das Funktionieren des Tribes ist der Tribe-Lead, der für die Setzung der richtigen Prioritäten, die Budgetverteilung und die Allokation von Wissen innerhalb des Tribes verantwortlich zeichnet. Um die Umsetzung innerhalb der Organisation zu begleiten, wurden in jeden Tribe Agile Coaches in das Konstrukt aufgenommen. Sie haben die Aufgabe, die Teams sowie die einzelnen Teammitglieder bei der Transformation in das neue Modell zu coachen und zu unterstützen. Der Erfolg der Transformationsbemühungen im Headquarter in Amsterdam war so groß, dass die neuen Arbeitsmethoden nun schrittweise auf andere Bereiche und Abteilungen übertragen wird. So plant die deutsche Tochter der ING DiBa, dass bereits 2019 alle Organisationseinheiten agil arbeiten (ING Deutschland 2019).

6.9 Fazit Wie das Beispiel der ING DiBa verdeutlicht, ist die Umsetzung von agilen Arbeitsmethoden eine Aufgabe, die an die spezifischen Bedürfnisse des Unternehmens und der jeweiligen Kunden der Branche angepasst werden sollte. Es gibt daher keine Onesize-fits-all-Lösung bei der Implementierung von digitalen Transformationsprozessen in Unternehmen. Dass eine solche Umstellung in der digitalen Wirtschaftswelt notwendig ist, zeigt die Bedeutung, die Unternehmen aus unterschiedlichen Branchen dem Prozess beimessen. Nicht nur die ING Bank setzt auf neue Modelle der Arbeit – auch Unternehmen wie General Electrics, BMW oder Microsoft haben diese Veränderungen zu einem gelebten Teil ihrer Unternehmensphilosophie erklärt. Alle genannten Unternehmen haben in ­vielen Bereichen die Art, wie sie arbeiten, grundlegend verändert.

186

6  Software als Kernkompetenz beherrschen

Doch die großen (Digital-)Konzerne werden nicht die Einzigen bleiben, die sich verändern. Inzwischen hat der Wandel der Arbeitswelt hin zu agilen Modellen eine Dynamik erreicht, die auf Unternehmen aller Branchen und Größenordnungen überschwappt. Manager bekommen in diesem Transformationsprozess neue Rollen zugewiesen. Um die klassischen Führungs- und Entscheidungsaufgaben in vollem Umfang wahrnehmen zu können, müssen Manager damit beginnen, ihre Kenntnisse des Software-Prozesses über die Bereiche Erstellung, Betrieb und Skalierung zu erweitern. Auch sollten ihnen die Grundlagen der Software-Architektur bekannt sein, um mit den technischen Mitarbeitern gemeinsam die Potenziale und Einsatzszenarien der Software zu definieren und steuern. Schließlich sollten sich Manager auch mit den neuen agilen Arbeitsmethoden und deren Implementierung in Unternehmen beschäftigen. Bleiben diese Kompetenzen bei der Ausbildung zukünftiger Manager außen vor, dann werden in Zukunft immer stärker die technischen Leiter und Ingenieure die Geschicke der Unternehmen leiten ­(müssen) (Frank 2017).

Literatur Agile Manifesto (2001): Manifesto for Agile Software Development, erschienen in: agilemanifesto.org, https://agilemanifesto.org/, abgerufen im Juni 2019. Augsten, Stephan (2018): Was ist Continuous Integration?, erschienen in: dev-insider.de, https:// www.dev-insider.de/was-ist-continuous-integration-a-690914/, abgerufen im Juni 2019. Balzert, Helmut (2011): Lehrbuch der Softwaretechnik. Bd. 2: Entwurf, Implementierung, Installation und Betrieb, Spektrum Akademischer Verlag, Heidelberg. Biske, Todd (2015): Was ist der Unterschied zwischen SOA und einer Microservice Architektur?, erschienen in: computerweekly.com, https://www.computerweekly.com/de/meinung/ Was-ist-der-Unterschied-zwischen-SOA-und-einer-Microservice-Architektur, abgerufen im Juni 2019. Bitkom (2018): 82.000 freie Jobs: IT-Fachkräftemangel spitzt sich zu, erschienen in: bitkom. org, https://www.bitkom.org/Presse/Presseinformation/82000-freie-Jobs-IT-Fachkraeftemangel-spitzt-sich-zu, abgerufen im Juni 2019. Booth, Janice Holly (2014): Failure is the New Success, erschienen in: aarp.com, https://www. aarp.org/work/working-at-50-plus/info-2017/fail-fast-learn-fast.html#slide1, abgerufen im Juni 2019. Broj, Alexander und Carsten Schulz (2017): Roboter, Rebellen, Relikte.Überkommene Strukturen behindern die Digitale Transformation, erschienen in: bearingpoint.com, https://www.bearingpoint.com/files/Digitalisierungsmonitor_2017.pdf?hash=b7cb75f6419d778cc06f875c48d6ba6caa6a73073b45e47f, abgerufen im Juni 2019. Calcott, Gary (2018): Microservices vs. Monolithische Architekturen: ein Leitfaden, erschienen in: silicon.de, https://www.silicon.de/41666855/microservices-vs-monolithische-architekturen-einleitfaden, abgerufen im Juni 2019. Cappuccio, Dave (2018): The Data Center is Dead, erschienen in: gartner.com, https://blogs.gartner.com/david_cappuccio/2018/07/26/the-data-center-is-dead/, abgerufen im Juni 2019. Cave, Andrew (2017): Culture Eats Strategy For Breakfast. So What’s For Lunch?, erschienen in: forbes.com, https://www.forbes.com/sites/andrewcave/2017/11/09/culture-eats-strategy-forbreakfast-so-whats-for-lunch/#6705be097e0f, abgerufen im Juni 2016.

Literatur

187

Choi, Janet (2018): Why Jeff Bezos’ Two-Pizza Team Rule Still Holds True in 2018, erschienen in: blog.idonethis.com, http://blog.idonethis.com/two-pizza-team/, abgerufen im Juni 2019. Donath, Andreas (2018): Apple investiert 1 Milliarde US-Dollar für texanischen Campus, erschienen in: golem.de, https://www.golem.de/news/expansion-apple-investiert-1-milliarde-us-dollar-fuer-texanischen-campus-1812-138247.html, abgerufen im Juni 2019. Drilling, Thomas und Stephan Augsten (2017a): Entstehung, Aufbau und Funktionsweise von SOAP, erschienen in: dev-insider.de, https://www.dev-insider.de/entstehung-aufbau-undfunktionsweise-von-soap-a-602380/, abgerufen im Juni 2019. Drilling, Thomas und Stephan Augsten (2017b): Konzept, Aufbau und Funktionsweise von REST, erschienen in: dev-insider.de, https://www.dev-insider.de/konzept-aufbau-und-funktionsweisevon-rest-a-603152/, abgerufen im Juni 2019. England, Rob (2014): Define DevOps, erschienen in: itskeptic.org, http://www.itskeptic.org/content/define-devops, abgerufen im Juni 2019. Fielding, Roy T. (2017): Statelessness, erschienen in: restfulapi, https://restfulapi.net/statelessness/, abgerufen im Juni 2019. Frank, Roland (2017): Vom CEO zum CTO – Sind Techniker die besseren Chefs?, erschienen in: cloud-blog.arvato, https://cloud-blog.arvato.com/vom-ceo-zum-cto-sind-techniker-die-besseren-chefs/, abgerufen im Juni 2019. Frank, Roland (2019): Unternehmensgründung vs. Unternehmenstransformation, erschienen in: cloud-blog.arvato.com, https://cloud-blog.arvato.com/unternehmenstransformation/, abgerufen im Juni 2019. Gannon, Dennis, Roger Barga und Neel Sundaresan (2017): Cloud Native Applications, erschienen in: IEEE Cloud Computing, Nr. 5/2017, S. 16–21. Hahn, Dave (2016): How Netflix Thinks of DevOps, Vortrag auf den DevOp Days Rockies 2016, erschienen in: youtube.com, https://www.youtube.com/watch?reload=9&v=UTKIT6STSVM, abgerufen im Juni 2019. ING (2019): One agile Way of Working, erschienen in: ing.jobs, https://www.ing.jobs/Oesterreich/ Warum-ING/So-arbeiten-wir/One-agile-Way-of-Working.htm, abgerufen im Juni 2019. ING Deutschland (2019): Die erste agile Bank Deutschlands, erschienen in: ing.de, https://www. ing.de/ueber-uns/menschen/agile-bank/, abgerufen im Juni 2019. ITWissen (2018): Three-Tier-Architektur, erschienen in: itwissen.info, https://www.itwissen.info/ Three-Tier-Architektur-three-tier-architecture.html, abgerufen im Juni 2019. ITWissen (2019): Monolithische Software-Architektur, erschienen in: itwissen.info, https://www. itwissen.info/Monolithische-Software-Architektur.html, abgerufen im Juni 2019. Kratzke, Nane (2018): Cloud Native Applikationen, erschienen in: slideshare.net, https://de.slideshare.net/QAware/cloudnative-applikationen, abgerufen im Juni 2019. Jacobs, Peter (2017): ING’s agile transformation, erschienen in: mckinsey.com, https://www. mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation, abgerufen im Juni 2019. Lean Production (2019): Kanban, erschienen in: lean-production-expert, http://www.lean-production-expert.de/lean-production/kanban-beschreibung.html, abgerufen im Juni 2019. Luber, Stefan und Stephan Augsten (2017): Was ist Scrum?, erschienen in: devinsider.de, https:// www.dev-insider.de/was-ist-scrum-a-575361/, abgerufen im Juni 2019. MacCormack, Alan, Robert Lagerstrom, Martin Mocker und Carliss Y. Baldwin (2017): Digital Agility: The Impact of Software Portfolio Architecture on IT System Evolution, erschienen in: Harvard Business School Technology & Operations Mgt. Unit Working Paper, Nr. 17-105, https://ssrn.com/abstract=2974405, abgerufen im Juni 2019. Moore, Geoffrey (2016): Zone to Win, Vortrag im Rahmen der GoTo Konferenz, erschienen in: youtube.com, https://www.youtube.com/watch?v=fG4Lndk-PTI&t=2885s, abgerufen im Juni 2019.

188

6  Software als Kernkompetenz beherrschen

Newman, Sam (2015): Microservices: Konzeption und Design, mitp, Frechen. Nadella, Satya (2017): Hit Refresh – The Quest to Rediscover Microsoft’s Soul and Imagine a better Future for Everyone, William Collins, London. Nazrul, Syed Sadat (2018): CAP Theorem and Distributed Database Management Systems, erschienen in: towarddatasince.com, https://towardsdatascience.com/cap-theorem-and-distributed-database-management-systems-5c2be977950e, abgerufen im Juni 2019. Nickel, Oliver (2018): AWS und Google hosten die iCloud, bestätigt Apple, erschienen in: golem. de, https://www.golem.de/news/cloud-computing-aws-und-google-hosten-die-icloud-bestaetigtapple-1802-133003.html, abgerufen im Juni 2019. Osram (2019): Redefining IoT for Lighting Business and Beyond, erschienen in: osram.com, https://www.osram.com/cb/applications/lightelligence/index.jsp, abgerufen im Juni 2019. Produktion (2017a): Die 7 Verschwendungsarten und was Sie dagegen tun können, erschienen in: produktion.de, https://www.produktion.de/technik/die-7-verschwendungsarten-und-was-sie-dagegen-tun-koennen-335.html, abgerufen im Juni 2019. Produktion (2017b): Kaizen: Lean-Philosophie in der Produktion anwenden, erschienen in: produktion.de, https://www.produktion.de/technik/kaizen-lean-philosophie-in-der-produktion-anwenden-106.html, abgerufen im Juni 2019. Produktion (2018): One-Piece-Flow: Beispiel aus der Praxis, erschienen in: produktion.de, https:// www.produktion.de/technik/one-piece-flow-beispiel-aus-der-praxis-106.html, abgerufen im Juni 2019. Raza, Muhammad (2018): Public Cloud vs Private Cloud vs Hybrid Cloud: What’s The Difference?, erschienen in bmc.com, https://www.bmc.com/blogs/public-private-hybrid-cloud/, abgerufen im Juni 2019. Rouse, Margaret (2019): Hybrid Cloud, erschienen in: searchcloudcomputing.techtarget.com, https://searchcloudcomputing.techtarget.com/definition/hybrid-cloud, abgerufen im Juni 2019. Schwaber, Ken und Jeff Sutherland (2013): Der Scrum Guide – Der gültige Leitfaden für Scrum, erschienen in: scrumguides.org, https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf, abgerufen im Juni 2019. Srocke, Dirk und Florian Karlstetter (2017): Was ist eine REST API?, erschienen in: cloudcomputing-insider.de, https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/, abgerufen im Juni 2019. Thienel, Albert (2018): Banken auf dem Weg zur digitalen Transformation, erschienen in: qualiero. com, https://www.qualiero.com/community/digitalisierung/allgemeines/auf-dem-weg-zum-digitalen-unternehmen-z-b-die-ing-diba-direktbank.html, abgerufen im Juni 2019. Wolff, Eberhard (2018a): Microservices? Oder lieber Monolithen?, erschienen in: heise.de, https://www.heise.de/developer/artikel/Microservices-Oder-lieber-Monolithen-3944829.html, abgerufen im Juni 2019. Wolff, Eberhard (2018b): Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt Verlag, Heidelberg.

7

Sinkende Transaktionskosten und die neue Netzwerkökonomie

Zusammenfassung

Aus unternehmerischer Perspektive war es lange Zeit sinnvoll, einen Großteil der Prozesse entlang der Wertschöpfungskette zu internalisieren. Mit der Digitalisierung sinken die Transaktionskosten und damit steigt gleichzeitig die Zahl der Möglichkeiten, standardisier- und automatisierbare Prozesse von externen Anbietern zu beziehen. Unternehmen können diese Chance ergreifen und vermehrt Prozesse auslagern, die nicht zum Kerngeschäft gehören. Zusätzlich bietet ihnen die Cloud die Chance, selbst als Anbieter digitaler Dienstleistungen am Markt aufzutreten und sich in die entstehende digitale und globale Netzwerkstruktur aus digitalen Anbietern und Nachfragern einzugliedern. Aus ehemaligen Disruptoren oder Konkurrenten (Enemies) können so potenzielle Kooperationspartner (Frenemies) werden.

7.1 Transaktionskosten halten klassische Wertschöpfungsketten zusammen 1991 erhielt der britische Wirtschaftswissenschaftler Ronald Coase den Wirtschaftsnobelpreis für die Beantwortung einer scheinbar simplen Frage: „Warum gibt es Unternehmen?“ Diese auf den ersten Blick einfache Frage weist auf einen komplexen ökonomischen Sachverhalt hin (Littmann 2013). Schon früh in seiner wissenschaftlichen Karriere störte sich Coase an einer der zentralen Annahmen der klassischen Wirtschaftstheorie, und zwar an der Annahme, dass ein Tauschprozess zwischen zwei Parteien ohne auftretende Zusatzkosten, d. h. „kostenlos“ abläuft. Wäre diese Annahme richtig, dann entstünden bei einer Transaktion zwischen zwei Parteien am Markt weder beim Käufer noch beim Verkäufer über den Kaufpreis hinaus weitere Kosten. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_7

189

190

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Die Folgen wären frappant: Es gäbe für einen Unternehmer keinen Grund, einen einzelnen Prozessschritt – und sei er noch so klein – zu internalisieren, also selbst zu erledigen. Warum sollte zum Beispiel ein Arbeitsvertrag mit einem Mitarbeiter geschlossen werden, wenn doch jeder einzelne Handgriff „kostenlos“ am Markt eingekauft werden kann? Ein Unternehmen, das Möbel herstellt, könnte beispielsweise das Zuschneiden der Bretter bei Anbieter A einkaufen, die Schrauben und Nägel bei Anbieter B und C und die Fertigung des Tisches bei Anbieter D bestellen. Da alle Transaktionen kostenlos sind, kann sich der Möbelhersteller jeweils den Anbieter mit dem besten Preis-Leistungs-Verhältnis aussuchen und so seine eigene Wertschöpfungskette über alle Stufen optimieren. In der Folge entstünde der optimale Tisch zum optimalen Preis. Aufgabe des Unternehmens wäre es in diesem Szenario nur noch, die einzelnen Prozessschritte zu orchestrieren. In der Realität geschieht dies (noch) nicht. Große Möbelunternehmen wie Segmüller aus Bayern versuchen im Gegenteil, möglichst viele Prozessschritte zu internalisieren. Von der Herstellung und Beschaffung der Materialien über die Designs bis hin zur Fertigung der Vorprodukte wird bei Segmüller alles zentral gesteuert. Der Grund, warum sich die Internalisierung für ein Unternehmen wie Segmüller lohnt, ist die Existenz von Transaktionskosten. Diese Kostenart wurde erstmals von Ronald Coase in seinem 1937 erschienen Aufsatz mit dem Titel „The Nature of the Firm“ erwähnt, für den er 60 Jahre später den Nobelpreis erhalten sollte (Coase 1937). In seinem Aufsatz stellte Coase fest, dass die Annahme der klassischen Ökonomik von kostenlosen Markttransaktionen hinfällig sei. Vielmehr entstehe rund um den Vorgang des Einkaufs eine Reihe von Zusatzkosten, die zum Kaufpreis addiert werden müssen. Mit dieser Feststellung gelang es Ronald Coase, eine Antwort auf die Frage „Warum gibt es Unternehmen?“ zu geben. Die Antwort lautet: Weil die Kosten, die zusätzlich zum Kaufpreis entstehen – eben die Transaktionskosten – zu hoch sind, lohnt es sich für Unternehmer, Hierarchien zu schaffen, um damit interne Arbeitsprozesse zu steuern. Zwar werden die wegfallenden Transaktionskosten nun durch interne Transaktionskosten abgelöst (s. Abschn. 7.2 zu den internen Transaktionskosten), die sich aus den Aufbau- und Betriebskosten ergeben – doch im Ergebnis sind diese internalisierten Prozesse günstiger als der Einkauf der Prozesse. Dieser Zusammenhang lässt sich anhand eines einfachen Beispiels verdeutlichen: Welchen Aufwand müssten Unternehmen betreiben, um jedes Jahr die Bilanzierung der Unternehmenszahlen am freien Markt einzukaufen? Allein die Auswahl und die Kontrolle der Arbeitsleistung des Buchhalters würden hohe Kosten erzeugen. Damit nicht genug: Nach Abschluss der Bilanz wäre das gesamte Wissen wieder verloren. Daher lohnt es sich für Unternehmen, eine administrative Aufgabe wie die Buchhaltung, die nichts mit dem Kerngeschäft des Unternehmens zu tun hat, von eigenen Mitarbeitern erledigen zu lassen. Es werden Stellen für Buchhalter geschaffen, Arbeitsverträge unterschrieben und die Tätigkeit in den Ablaufprozess des Unternehmens eingebunden – eine eigene Abteilung innerhalb des Unternehmens ist entstanden. Und das obwohl die

191

7.1  Transaktionskosten halten klassische Wertschöpfungsketten …

Anbahnungs- und Informaonskosten • Handelsmessen besuchen • Vorbereitende Diskussionen mit Lieferanten

Vereinbarungskosten • Preisverhandlungen • Kosten für rechtliche Beratung

Kontrollkosten • Wareneingangsprüfung • Qualitätsmanagement in der Produkon und danach

Durchsetzungskosten • Anwaltskosten • Gerichtskosten

Anpassungskosten • Anpassungen an den spezifizierten Leistungen • Lieferantendialog zur ständigen Verbesserung

Abb. 7.1   Die Arten von Transaktionskosten – Beispiel Motorenherstellung

k­ lassische Theorie vorhersagt, dass diese Tätigkeit genauso gut am Markt hätte eingekauft werden können. Insgesamt werden fünf Formen von Transaktionskosten unterschieden (s. Abb. 7.1). Dazu ein Beispiel: Das Management eines Maschinenbaukonzerns beschließt, in den Anlagen einen neuen Motor zu verwenden. Bevor der neue Motor aber in den Maschinen eingebaut werden kann, entstehen dem Unternehmen neben den Kosten für die Anschaffung eine Reihe von Transaktionskosten: 1. Anbahnungskosten Bevor sich der Vorstand des Maschinenkonzerns für einen neuen Motor entscheidet, gleicht er – wie jeder gewissenhafte Einkäufer – den eigenen Bedarf mit den am Markt vorhandenen Möglichkeiten ab. Dazu besuchen Mitarbeiter des Unternehmens Handelsmessen und laden potenzielle Lieferanten ein, um verschiedene Produkte kennenzulernen. 2. Vereinbarungskosten Die Angebote der einzelnen Hersteller werden vor Vertragsabschluss geprüft und verglichen. Anschließend finden Vertragsverhandlungen über die Vertrags- und Lieferkonditionen statt. Bis zum eigentlichen Vertragsschluss entsteht so eine Reihe weiterer Kosten. 3. Kontrollkosten Wenn der Motor geliefert wird, ist es die Aufgabe des Unternehmens, den ordnungsgemäßen Zustand des Gerätes zu überprüfen. Die dabei auftretenden Arbeitskosten sind Teil der Transaktionskosten. 4. Durchsetzungskosten Ist eine der beiden Vertragsparteien mit der Vertragserfüllung unzufrieden, kann es zu juristischen Auseinandersetzungen kommen. Die Kosten für Rechtsanwälte und Verhandlungen werden ebenfalls zu den Transaktionskosten addiert.

192

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Externe IT

Unternehmensinfrastruktur HR

Transakonskosten

Forschung & Entwicklung

Beschaffung

Transakonskosten

Interne Logisk

Produkon

Externe Logisk

Markeng und Verkauf

Services

Transakonskosten

Externes Lager

Externes Call Center

Abb. 7.2   Hohe Transaktionskosten halten die Wertschöpfungskette zusammen

5. Anpassungskosten Während die Motoren in die Maschinen eingebaut werden, ergibt sich möglicherweise ein Anpassungsbedarf. Die Kosten für diese Anpassungen werden nach der Vertragsunterzeichnung ebenfalls zu den Transaktionskosten hinzugerechnet. Die Anschaffung des Fertigungsteils zeigt, dass nicht nur der Einkauf des Motors selbst, sondern auch die dabei auftretenden Transaktionskosten den gesamten Fertigungsprozess verteuern. Dadurch wird der Zukauf am Markt unattraktiver. Wenn es einem Unternehmen gelingt, durch die Internalisierung von Prozessschritten die Kosten für die Erstellung des Fertigungsteils „Motor“ unter die Kosten des Kaufs inklusive der Transaktionskosten zu senken, lohnt sich die Integration der Motorfertigung in das Unternehmen. Damit ist auch theoretisch geklärt, warum Unternehmen mit internen Wertschöpfungsketten entstehen. Denn in der industriellen Fertigungsökonomie ist es wirtschaftlich häufig nicht sinnvoll, die hohen Transaktionskosten für die externe Erstellung von Gütern und Dienstleistungen auf sich zu nehmen. Die Überwachungsund Kontrollkosten für die Akquisition von Prozessschritten am Markt sind schlicht zu hoch. Damit bilden die Transaktionskosten den Kitt bzw. den Kleber, der traditionelle Wertschöpfungsketten zusammenhält. Unternehmen sparen Geld, wenn sie nicht jede Dienstleistung am Markt einkaufen müssen, sondern diese in den Arbeitsablauf des Unternehmens integrieren können (Abb. 7.2).

7.2 Exkurs: Interne Transaktionskosten bremsen die Skaleneffekte der Produktion Wenn sich ein Unternehmen für die Internalisierung eines Prozesses entscheidet, verändert diese Entscheidung die interne Kostenstruktur. Neben die Kosten der eigentlichen Produkt- oder Dienstleistungserstellung treten zahlreiche weitere Kosten, die mit dem

193

7.2  Exkurs: Interne Transaktionskosten bremsen die …

Aufbau eines Unternehmens verbunden sind – das ist die ökonomische Kehrseite der Internalisierung von Arbeitsprozessen. Der arbeitsteilige Prozess in Unternehmen bleibt nicht ohne Folgen: Zwischen den beteiligten Akteuren werden Informationen ausgetauscht, die einzelnen Stufen der Produktion werden überwacht und kontrolliert, Entscheidungen über Produktionsformen und -kapazitäten müssen getroffen werden und schließlich werden die Prozessschritte administriert und verwaltet. Es entstehen also „interne Transaktionskosten“, von denen es vier Arten gibt (die sogenannten „IKEA-Kosten“): 1. Informationskosten 2. Kontrollkosten 3. Entscheidungskosten 4. Administrationskosten Michael Porter bezeichnet diese durch die Internalisierung von Arbeitsprozessen entstehenden Aktivitäten als sekundäre Tätigkeiten. Für Porter sind dies Tätigkeiten, die nicht der eigentlichen Produktion oder dem Vertrieb zugeordnet werden können, sondern durch die interne Informationsbeschaffung, Entscheidungsfindung, Kontrolle und Administration entstehen (s. Abb. 7.3). Mit zunehmender Ausbringungsmenge eines Unternehmens wachsen die internen Transaktionskosten an. Daher entstehen einem Unternehmen neben den (Größen-) und Skalierungsvorteilen (s. Kap. 3) auch Nachteile, wenn es seine Produktionsmenge steigert. Abb. 7.4 verdeutlicht diesen Zusammenhang. Während mit steigender Ausbringungsmenge die Durchschnittskosten der Produktion natürlich sinken, steigen die Kosten für den Betrieb der sekundären Aktivitäten an. Grund dafür sind in der klassischen Industrieproduktion der zunehmende Koordinationsaufwand und die immer komplexere Granularität der internen Teilprozesse, die aufeinander abgestimmt werden müssen.

Externe Transakonskosten Anbahnungs- und Informaonskosten

Vereinbarungskosten

Informaonskosten

Entscheidungskosten

Kontrollkosten Einkaufskosten

Herstellkosten

Durchsetzungskosten

Anpassungskosten

Kontroll- und Administraonskosten

Kosten für die Weiterentwicklung

Interne Transakonskosten

Abb. 7.3   Vergleich der im Kontext des Produkts entstehenden Zusatzkosten

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Kosten

194

Variable Kosten pro Einheit

Interne Transakonskosten

Ökonomisch opmaler Grad

Durchschniskosten Menge

Abb. 7.4   Interne Transaktionskosten nehmen mit steigender Ausbringungsmenge zu

Trotz der in Kap. 3 beschriebenen Skaleneffekte und Erfahrungskurven gibt es damit eine natürliche Grenze des Wachstums von Unternehmen in der klassischen Güterproduktion: Sobald die Summe aus den Grenz-Internen-Transaktionskosten pro produzierter Einheit (beziehungsweise dem Fixkostenanteil) plus den Grenzkosten den Marktpreis des Produkts übersteigt, lohnt sich der Aufbau von weiteren Kapazitäten nicht mehr. Damit wird in die Entwicklung der Gesamtkosten auch einberechnet, dass die internen Transaktionskosten bei zunehmender Ausbringungsmenge steigen. Dieser Faktor der steigenden internen Transaktionskosten pro Einheit klärt die Frage, welches Produktionsoptimum sich für Unternehmen im Zeitalter der Digitalisierung ergibt. Wenn sich die Kostenstruktur eines modernen Unternehmens aus Fixkosten (KFix), einer abnehmenden Kurve der Grenzkosten (KProd) und einer zunehmenden Kurve der variablen IKEA-Kosten (Kvar) zusammensetzt, lautet die neue Formel für die Gesamtkosten (K):

K(x) = Kfix (x) + Kvar (x)

(7.1)

Kvar (x) setzt sich dabei aus den variablen Kosten pro produzierte Einheit zuzüglich dem variablen Kostenanstieg der internen Transaktionskosten pro Einheit zusammen.

Kvar (x) = Kprod (x) + KintTAK (x)

(7.2)

Damit verändert sich im digitalen Zeitalter die klassische Formel zur Gewinnermittlung eines Unternehmens. Würde die klassische Formel zur Ermittlung des Gewinnoptimums gelten, nämlich Preis = Grenzkosten, dann würden die Unternehmen bei sinkenden Grenzkosten die Produktion ins Unendliche ausweiten. Mit der Anpassung der Kostenformel ist das Gewinnmaximum erreicht, wenn gilt: Grenzkosten plus Grenz-Interne-Transaktionskosten gleich dem Marktpreis (p*).

7.3  Integratoren, Orchestratoren und Layer Player – wie …

195

p∗ = Kprod ′ (x) + KintTAK ′ (x) Auf den Punkt gebracht: Die steigenden internen Transaktionskosten der sekundären Tätigkeiten im Unternehmen verhindern das unbegrenzte Wachstum von klassischen Industrie- und Herstellungsunternehmen. Subadditivität, also die Befähigung eines einzelnen Unternehmens, die gesamte Marktnachfrage abzudecken, ist in der Industriegüterproduktion daher eher die Ausnahme. Wie in Kap. 3 dargestellt, unterscheiden sich die Digitalgüterproduktion und die Industriegüterproduktion in diesem Punkt. Denn im Gegensatz zu den Industriegütern ist die Gefahr einer Subadditivität durch einen einzelnen Marktanbieter bei digitalen Gütern äußerst real.

7.3 Integratoren, Orchestratoren und Layer Player – wie Transaktionskosten ökonomische Strukturen beeinflussen Vom Mittelalter bis in die Gegenwart gab es immer wieder Phasen, in denen Unternehmen verschiedene Arbeitsschritte entweder integriert (Insourcing) oder ausgelagert haben (Outsourcing). Um diese historischen und damit auch die aktuellen Verschiebungen einordnen zu können, ist es hilfreich, drei Unternehmenstypen zu unterscheiden. Jede Organisation kann einem dieser drei Typen zugeordnet werden oder eine Mischform repräsentieren: 1. Integratoren 2. Orchestratoren 3. Layer Player Als Integratoren werden Unternehmen bezeichnet, die ein Interesse daran haben, aus ökonomischen Gründen große Teile der Wertschöpfungsprozesse zu internalisieren. Ein bis heute aktuelles Beispiel für Integratoren sind die global agierenden Mineralölkonzerne (Gassmann et al. 2013). Die Wertschöpfungskette dieser Unternehmen erstreckt sich von der Auswahl der Ölfördergebiete über die Förderung des Öls mit Bohrtürmen und Bohrinseln bis hin zum Betrieb der Raffinerien und Tankstellen. Selbst die Logistik, mit der das Öl zu den Endverbrauchern transportiert wird, wird in der Regel von den Ölkonzernen gesteuert. So kontrolliert ein Ölkonzern die Wertschöpfungskette vom ersten Rohöl-Tropfen, der aus der Erde kommt, bis zu dem Moment, in dem das Öl den Zapfhahn an der Tankstelle verlässt. Die volle Kontrolle über die gesamte Wertschöpfungskette ist der ökonomische Vorteil dieser Unternehmen. Es fallen keine Transaktionskosten an und die internen Kontrollkosten bleiben durch eingespielte Abläufe niedrig. Gleichzeitig ist es den Unternehmen so möglich, rasch auf Nachfrage- und Preisänderungen zu reagieren.

196

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Eine zweite Form von Unternehmen sind die sogenannten Orchestratoren. Im Gegensatz zu den Integratoren lagern Orchestratoren Teile der eigenen Wertschöpfungskette gezielt aus und konzentrieren sich auf die eigentlichen Kernaufgaben des Unternehmens. Zahlreiche Orchestratoren gibt es heute in der westlichen Konsumgüterindustrie. So lagern Textilunternehmen wie adidas oder Nike ihre Produktion nach Asien aus, weil dort die Herstellung der Textilien billiger ist. Aber auch Unternehmen wie Walmart, Apple oder Sony stellen die von ihnen vertriebenen Produkte nicht in den eigenen Fabriken her, sondern lagern die Produktion an Fremdfirmen im Ausland aus. Die dritte Unternehmensform sind die Layer Player. Dabei handelt es sich um Unternehmen, die sich aus der Perspektive eines Orchestrators auf eine Stufe innerhalb einer Wertschöpfungskette spezialisieren und diese Tätigkeit für unterschiedliche Firmen anbieten. Ein Beispiel für einen Layer Player ist der Online-Bezahldienst PayPal. Statt alle Stufen der Wertschöpfungskette zu durchlaufen und dem Kunden ein fertiges Endprodukt anzubieten, konzentriert sich das Unternehmen auf den Ausschnitt „Bezahlvorgang“. Es bietet also eine Dienstleistung an, die in den Wertschöpfungsketten von Unternehmen eine eigene Stufe darstellt und wickelt sie für eine Reihe von (Online-) Händlern weltweit ab. Lange Zeit waren die Integratoren auf dem Vormarsch. Durch die Digitalisierung hat sich das geändert: Das Pendel schlägt seit Jahrzehnten in die Richtung der Orchestratoren aus – und die immer günstiger werdenden Transaktionskosten beschleunigen diese Entwicklung. Insgesamt lassen sich in der Wirtschaftsgeschichte sechs Phasen der Integrationsverschiebung unterscheiden: 1. Bis zum 16. Jahrhundert: Zeit der Einzelunternehmer und des Handels 2. 17. bis 19. Jahrhundert: Kolonialisierung 3. Ab 1890: Aufstieg der Integratoren – Entstehung von Großunternehmen 4. Ab 1950: Erste Outsourcing-Welle 5. Ab 1980: Zweite Outsourcing-Welle 6. Ab 2010: Digitale Auslagerung Die Zeit der Einzelunternehmer und des Handels (bis zum 16. Jh.) Vom Mittelalter bis in die Neuzeit dominierten in der westlichen Welt Einzelunternehmen das Wirtschaftsleben. Ein Hufschmied zum Beispiel kaufte das Eisenerz ein, verarbeitete es selbstständig und beschlug schließlich die Hufe der Pferde. Da bei vielen Waren die Hersteller und Produzenten getrennt von den Ressourcen waren, traten Händler auf den Plan, die als „Layer Player“ die Logistik des Warentransports aus den entlegenen Regionen übernahmen. So waren etwa Ingwer und Gewürze im Mittelalter stark nachgefragte Güter, die Beschaffung aus den Ländern des nahen und fernen Ostens war aber mit großen Gefahren verbunden. Entsprechend hoch waren die Margen, die die Händler für die Bereitstellung der Rohstoffe von ihren Kunden verlangten (Gildhorn 2019). Transaktionskosten spielten zu diesem Zeitpunkt aufgrund der Einfachheit der angebotenen Produkte noch keine Rolle. Die ­mittelalterliche

7.3  Integratoren, Orchestratoren und Layer Player – wie …

197

Wirtschaft war daher von Integratoren (Einzelunternehmen) und Layer Playern ­(Händler) geprägt. Die Kolonialisierung (17.–19. Jh.) Die großen Gewinnmargen der Händler riefen spätestens nach der Entdeckung des amerikanischen Kontinents die Nationalstaaten als Layer Player auf den Plan. Statt die Gewinne bei den Händlern zu belassen, gründeten sie eigene Unternehmungen und begannen damit, gezielt die Rohstoffe der Länder in Übersee auszubeuten und bereitzustellen. Wie das Beispiel Spanien und die Ausbeutung des südamerikanischen Kontinents ab dem 16. Jahrhundert verdeutlicht, beschränkte sich das Interesse der Nationalstaaten zunächst auf besonders wertvolle Güter wie Gold, Silber und Edelsteine (Glüsing 2009). In der Folge weitete sich der national betriebene Handel auf immer mehr Güterarten aus. Tee wurde von indischen Teeplantagen importiert und Baumwolle aus Nordamerika. Die Nationalstaaten agierten zu diesem Zeitpunkt als eigenständige Layer Player, die einen Teil der Wertschöpfung – die Logistik – und damit auch einen Teil des Gewinns für sich beanspruchten. Als die Transportkosten sanken und die Unsicherheit nachließ, rückten auch margenschwächere Produkte wie Lebensmittel immer stärker in den Handelsfokus der Nationalstaaten. Zur gleichen Zeit breiteten sich in Europa Manufakturen – also Integratoren – aus, die in der Produktion von Gütern die Einzelunternehmen ablösten. Für die Herstellung der neuen Produkte war eine immer stärkere Arbeitsteilung notwendig: Feine Gewänder, Waffen oder Kutschen konnten nicht mehr von einzelnen Personen gefertigt werden. Allein ein Perückenmacher des 18. Jahrhunderts beschäftigte zahlreiche Mitarbeiter für die aufwendige Erstellung der Haartracht (Pröve 1995). Schon damals lohnte sich die Internalisierung von Prozessen und damit der Aufbau von Unternehmen, um Transaktionskosten am Markt zu vermeiden. Aufstieg der Integratoren –Entstehung der Großunternehmen (1890 – heute) Etwa in dem gleichen Zeitraum, in dem sich die Nationalstaaten langsam aus ihren kolonialen Bemühungen zurückzogen, entdeckten Unternehmer die Vorteile, die sich aus der Massenproduktion ergaben. Die elektrische Revolution und die dadurch immer komplexer werdenden Produkte (Automobile, Radios, Kühlschränke) ließen die Transaktionskosten für die Produktion der Güter weiter ansteigen. So verteuerten die Kosten der Nacharbeit, aber auch die Kosten für das Anwerben neuer Mitarbeiter den externen Einkauf. Wären die Arbeitgeber zu diesem Zeitpunkt darauf angewiesen gewesen, jeden einzelnen Arbeitsschritt am freien Markt einzukaufen, hätte sich die Produktion für sie nicht mehr gelohnt. Daher reagierten die Unternehmen mit einer Internalisierungswelle und veränderten die Form der Arbeit. Der Produktionsprozess wurde in immer kleinere Teilschritte zerlegt, und damit stieg der Grad der Spezialisierung von Arbeit sprunghaft an. Ein Beispiel für diese Entwicklung ist das Fließband: Henry M. Ford setzte es ab 1913 zur Fertigung des Model T eins (Dombrowski und Mielke 2015). Damit erreichte

198

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

die Entwicklung der Massenproduktion einen vorläufigen Höhepunkt. In kürzester Zeit wurden so aus Manufakturen weltweit große Konzerne. Unternehmen wie die Standard Oil Company, die 1870 unter anderem von John D. Rockefeller gegründet wurde, spielten in dieser Zeit ihre Größenvorteile am Markt voll aus. Durch das Ausnutzen der Skaleneffekte wurden Konkurrenten zunächst durch Preisdumping aus dem Markt gedrängt, anschließend wurde bei der Preissetzung der Vorteil des Marktmonopols ausgespielt. Das war der staatlichen Marktaufsicht in den USA ein Dorn im Auge, deren Ziel es war, dominierende Positionen einzelner Unternehmen auf den Gütermärkten zu verhindern. Im Jahr 1910 wurde Standard Oil in 34 Einzelunternehmen zerschlagen (Gerste 2019). Dass die Aufsichtsbehörden tatsächlich zum Mittel der Zerschlagung griffen, führte dazu, dass Unternehmen ihre vertikale Dominanz entlang der Wertschöpfungskette ausbauten (Wirtz 2012). Geeint wurden sie in dieser Phase von dem Willen, die vollständige Wertschöpfungskette zu kontrollieren. Die erste Outsourcing-Welle (ab 1950) Nach der Hochphase der Integratoren wuchs ab der Mitte des 20. Jahrhunderts die Bedeutung der Orchestratoren – und diese Entwicklung hält bis heute an. Angetrieben von günstigeren Lohnverhältnissen im Ausland, guten Produktionsbedingungen, sinkenden Transportpreisen und neuen Transportmöglichkeiten hat der Grad der internationalen Arbeitsteilung ein neues Niveau erreicht. Selbst aus entlegenen Gebieten konnten Güter immer günstiger und schneller zu den weiterverarbeitenden Fabriken und Endkunden gebracht werden. So lohnte es sich für Unternehmen zunehmend, die Lebensmittelproduktion in weiter entfernte Regionen der Erde zu verlegen. Seit den 1950er-Jahren wurden immer neue Südfrüchte Teil der westlichen Konsum- und Massenmärkte (Putschögl 1993). Was 100 Jahre zuvor noch ein Luxus war, war spätestens ab der Zeit des Wirtschaftswunders normal. Auch in der industriellen Fertigung wurde der Anteil der im Ausland gefertigten Güter immer größer. Zu den Opfern der ersten Auslagerungswelle zählten die textilherstellenden Unternehmen in Europa. Zunächst wurden die Fabriken von Deutschland nach Italien verlagert, doch schon bald zogen die Textilhersteller von dort weiter in Gebiete mit noch günstigeren Arbeitsbedingungen. Am schnellsten entwickelte sich Südostasien zur verlängerten Werkbank der Produzenten aus Europa und Nordamerika. Immer mehr Hersteller von Textilien und Elektronikprodukten verlagerten ihre Produktionsstätten nach Asien. Damit begann auch der Aufstieg der sogenannten Tigerstaaten (Kirchberg 2007). Die zweite Outsourcing-Welle (ab 1980) Ab den 1980er-Jahren rückte die Welt durch den zunehmenden Luftverkehr nicht nur physisch, sondern durch den Siegeszug der Computertechnologie auch kommunikativ immer enger zusammen. Die sinkenden Kommunikationskosten erweiterten das

7.4  Schnelle Kommunikation und einfache Automatisierung – die …

199

­ pektrum der Outsourcing-Möglichkeiten für Unternehmen. Nicht mehr nur LebensS mittel und industrielle Güter konnten im Ausland produziert werden. Durch die verbesserten Ausbildungsbedingungen in einigen Entwicklungsländern konnten auch Dienstleistungen im Bereich der Informationsverarbeitung, im Service und in der Kommunikation ins Ausland verlagert werden. Für westliche Konzerne lohnte es sich nun, Bürotätigkeiten und Call Center zum Beispiel in Indien oder Pakistan zu betreiben. (Fründt 2009). Phase der digitalen Auslagerung (ab 2010) Die dritte Auslagerungswelle, die zeitlich mit einem deutlich gestiegenen Automatisierungsgrad der IT ab dem Jahr 2010 zusammenfällt, unterscheidet sich deutlich von den beiden Auslagerungswellen davor. Ein Beispiel für solch eine Entwicklung ist der Übergang von automatisierten Installationen einzelner Softwarekomponenten hin zur automatisierten Bereitstellung von kompletten IT-Infrastrukturen in der Cloud. Arbeit wird in diesen Szenarien nicht mehr an Menschen an anderen Produktionsstandorten ausgelagert, stattdessen können Software und Algorithmen vor Ort oder aus der Cloud immer mehr Tätigkeiten übernehmen. Damit gewinnt das Outsourcing eine neue Qualität. Unternehmen stehen in der Zukunft vor der Frage, welche Arbeitsprozesse sie noch intern durchführen wollen, welche sie digitalisieren und welche sie auslagern wollen.

7.4 Schnelle Kommunikation und einfache Automatisierung – die Transaktionskostenhebel der Digitalisierung Dass menschliche Tätigkeiten durch Software und Algorithmen ersetzt werden können, ist keine Erfindung des 21. Jahrhunderts. Bereits mit der Entwicklung der ersten Großrechenanlagen übernahmen Computer Aufgaben entlang der Wertschöpfungskette von Unternehmen. Großrechner schlugen ihre menschlichen Konterparts von Beginn an im Bereich der Datenspeicherung und in der Geschwindigkeit der Datenverarbeitung. Entsprechend wurden die Aufgaben, für die Software verwendet wurde, auf diese Bereiche spezialisiert: Tabellenkalkulation, Datenspeicher, Bildbearbeitung etc. In den letzten zehn Jahren haben die Möglichkeiten, menschliche Tätigkeiten an Software auszulagern, neue Dimensionen angenommen. Die beiden entscheidenden Faktoren für diese Entwicklung sind die sinkenden Kommunikationskosten und die Automatisierbarkeit von Geschäftsprozessen.

7.4.1 Sinkende Kommunikationskosten Lange Zeit war es für Unternehmen schlicht zu teuer, Rechenleistung aus der Cloud zu beziehen. Ökonomisch relevant wurde die Umsetzung dieser Idee erst ab Mitte der 2000er-Jahre. Das Problem bis zu diesem Zeitpunkt waren die Verbindungskosten bzw.

200

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

die Kosten für die Datenübertragung – also die Preise pro übertragenem Bit. Das Phänomen der sinkenden Datenübertragungskosten soll im Folgenden anhand des technischen Ausbaus des deutschen Festnetzes dargestellt werden. Den Anfang des Breitband-Netzausbaus in Deutschland bildete die Einführung von DSL durch die Telekom im Jahr 1999 (Reinhardt 2019). Ein DSL-Anschluss mit einer Downloadrate von 1 Mbit/s kostete zu diesem Zeitpunkt 917 Deutsche Mark pro Monat. Noch 2005 hatten nur 62 % Prozent der Unternehmen in Deutschland einen Breitbandanschluss. Zehn Jahre später waren es bereits 95 % (Eurostat 2017). Die verfügbaren Bandbreiten stiegen deutlich, als 2006 VDSL eingeführt wurde. Durch VDSL wurde das Internet sowohl für Privat- als auch für Unternehmenskunden bedeutend schneller. Seit diesem Zeitpunkt hat sich die verfügbare Geschwindigkeit der Anschlüsse im Privatbereich auf aktuell 100–150 Mbit/s erhöht (Stand 2019). Unternehmen mit einem höheren Datenumsatz setzen seit dieser Zeit verstärkt auf sogenannte Standleitungen (SDSL) ins Internet mit festdefinierten Bandbreiten. Bei der SDSL-Technik wird keine Einzelverbindung zum Netz aufgebaut, sondern die Verbindung zum Internet-Einwahlpunkt dauerhaft aufrechterhalten. Die von der Telekom angebotenen Geschwindigkeiten für Standleitungen bewegen sich aktuell zwischen 2,2 Mbit/s und 1 Gbit/s (Telekom 2019). Mit der flächendeckenden Einführung von Glasfasernetzen wären ganz neue Übertragungsgeschwindigkeiten möglich. Glasfasernetze ermöglichen Upload- und Downloadraten von 100 GBit/s und mehr. Allerdings waren 2018 gerade einmal 2,8 % der gesamten Internet-Anschlüsse mit dem Glasfasernetz der Telekom verbunden. Damit liegt Deutschland weit abgeschlagen hinter Ländern wie Südkorea oder Schweden (Brandt 2019). Diese rasante Entwicklung der Datenübertragungsraten ermöglichte vielen Unternehmen den Einstieg in die Cloud. Seit Mitte der 1990er-Jahre übertrifft die Geschwindigkeit, mit der sich die Datenübertragungsraten ins Internet entwickeln, die Geschwindigkeit des Wachstum der Rechenleistung neuer Prozessorgenerationen (Evans 2013, s. Abb. 7.5). Andere Übertragungsformen haben ähnliche Entwicklungen genommen. So entwickelten sich bspw. die mobilen Datenübertragungsraten in den vergangenen Jahren deutlich, Mit der Technologie 5G steht nun ein Übertragungsstandard in den Startlöchern, der mobile Datenkommunikation mit einer Geschwindigkeit von bis zu 10 Gbit/s ermöglicht (Schanze 2018). Das führt dazu, dass es in den vergangenen Jahren erst möglich wurde und in der Zukunft immer attraktiver wird, Rechenleistung aus der Cloud zu beziehen.

7.4.2 Automatisierung der Geschäftsprozesse Der zweite wichtige Faktor, der zu einer Senkung der Transaktionskosten beigetragen hat, ist die zunehmende Automatisierung von Geschäftsprozessen. Speziell im Bereich der Markttransaktionen konnten durch die Digitalisierung zahlreiche standardisierbare Prozesse durch immer neue Software-Lösungen automatisiert werden.

109 108 107 106 105 104 103

Transistoren in Mikroprozessoren

7.4  Schnelle Kommunikation und einfache Automatisierung – die …

2006

201

2009

2011

2003 2000 1995

1997

1992

1982

1985

1978 1971 1972

1974

Bereitgestellte Kommunikaonsgeschwindigkeit (bps)

1965

103

104

105

106

107

Abb. 7.5   Fallende Kommunikationskosten nach Philip Evans (Evans 2013)

Ein Beispiel für diese Entwicklung ist die Abwicklung von Aktienkäufen und -verkäufen an den internationalen Kapitalmärkten durch das sogenannte „Algorithmic Trading“. Dabei werden die Kauf- oder Verkaufsangebote für einzelne Aktien nicht mehr von Menschen, sondern von Algorithmen durchgeführt. Diese Algorithmen sind in der Lage, Entscheidungen über Transaktionen an den Finanzmärkten innerhalb von Millisekunden zu treffen und die entsprechenden Orders auf den digitalen Marktplätzen zu platzieren. Diese automatisierte Form des Aktienhandels hat in den vergangenen Jahren die Transaktionsprozesse zwischen Börsenbetreibern, Investoren und Aufsichtsbehörden deutlich verändert. Aktuelle Schätzungen gehen davon aus, dass etwa 50 % der am Markt getätigten Transaktionen inzwischen von Algorithmen getätigt werden (Bundesbank 2016). Auch die Aufrechnung der Forderungen und Verbindlichkeiten, die sich aus den Transaktionen der Marktteilnehmer ergeben – in der englischen Fachsprache als Clearing bezeichnet – erfolgt längst ohne menschliches Zutun. Dazu wird zwischen dem Anbieter und dem Verkäufer von Wertpapieren eine zentrale Clearing-Stelle als Treuhänder zwischengeschaltet. Der Austausch der Wertpapiere (Clearing) und die abschließende Verrechnung (Settlement) erfolgen in der Regel, ohne dass ein Mensch die Teilprozesse steuert. In Europa sind aktuell zwei Unternehmen mit dem Clearing betraut: Clearstream und Euroclear (Segna 2018). So wie der Kaufprozess und das Clearing einer Aktientransaktion automatisiert wurden, können immer mehr Einzelschritte entlang der Online-Transaktionen automatisiert ablaufen. Dabei spielt es keine Rolle, ob ein Algorithmus die Angebotspreise an die

202

Anbahnungs- und Informaonskosten Vergleich der Kauf- und Verkaufsangebote durch Algorithmen

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Vereinbarungskosten Automasiert auf Basis standardisierter Verträge

Kontrollkosten Einkaufskosten Über elektronisches Monitoring

Durchsetzungskosten Zentrale, automasierte Clearing-Stelle

Anpassungskosten Keine Anpassungskosten

Transakonskosten im Online-Handel Beispiel

Abb. 7.6   Reduzierte Transaktionskosten durch Digitalisierung – Beispiel Aktienhandel

aktuelle Nachfragesituation anpasst, oder ob ein Algorithmus eigenständig entscheidet, welchem Online-Nutzer welche Werbung angezeigt wird (s. Abb. 7.6). Das Zusammenspiel von sinkenden Kommunikationskosten und einer voranschreitenden Automatisierung von Geschäftsprozessen führt dazu, dass die Transaktionskosten beim Outsourcing von Arbeitsprozessen immer weiter gegen Null laufen – und damit verändert sich die Arbeitswelt der Zukunft.

7.5 Neue Make-or-Buy-Entscheidungen durch die Digitalisierung Die beiden Autoren Carl Frey und Michael Osborne von der Universität Oxford haben 2013 mit ihrer Studie über die Zukunft der Arbeit weltweit Aufsehen erregt. Das Ergebnis ihrer Untersuchung lautete, dass in den kommenden 20 Jahren etwa die Hälfte der aktuellen Arbeitsplätze automatisiert bzw. durch Roboter und Maschinen ersetzt werden könnte (Frey und Osborne 2013). Die beiden Autoren gehen davon aus, dass zwei schwer voneinander zu trennende Entwicklungen die Arbeitswelt in den kommenden Jahren verändern werden: die zunehmende Digitalisierbarkeit und die Automatisierbarkeit von Arbeitsschritten. Ein Arbeitsschritt in der Wertschöpfungskette ist dann automatisierbar, wenn er immer wieder gleich ausgeführt wird. Die Automobilindustrie ist hier ein Vorreiter: So hat Tesla seine Karosserieproduktion bei der Fertigung des Model-3 nach eigenen Angaben zu 95 % automatisiert (Donath 2018). Doch auch Deutschland belegt in dieser Entwicklung weltweit einen der Spitzenplätze. Auf 10.000 Mitarbeiter kommen in Deutschland 309 Industrieroboter (Stand 2018). Das ist weltweit der dritte Platz hinter Südkorea (631) und Singapur (488). Durchschnittlich kommen weltweit 74 Industrieroboter pro 10.000 Mitarbeiter zum Einsatz (Eisenkrämer 2018). In der modernen Wertschöpfungskette ist ein Arbeitsschritt dann digitalisierbar, wenn die Tätigkeit des Menschen in einem Prozess abbildbar ist, der von einem Algorithmus

7.5  Neue Make-or-Buy-Entscheidungen durch die Digitalisierung

203

ausgeführt werden kann. Ein weiteres Beispiel für die Automatisierung von einzelnen Stufen der Wertschöpfungskette ist die sogenannte „Robotic Process Automation“ (RPA). Bei der klassischen Automatisierung von Arbeitsabläufen in Produktionsanlagen werden in der Regel die menschlichen Arbeitsschritte von Robotern kopiert. Zu diesem Zweck werden die menschlichen Aktionen analysiert und anschließend in Listen abgebildet, um sie mittels Programmierung der Roboter über API-Schnittstellen zu imitieren. Im Gegensatz dazu beobachten RPA-Systeme, wie Nutzer die ihnen gestellten Aufgaben in der grafischen Benutzeroberfläche (GUI) lösen. Die neuronalen Netze von RPA-Anlagen sind in der Lage, eigenständige Listen der Tätigkeiten zu erstellen und diese selbstständig in der GUI zu wiederholen. Beispielsweise können zahlreiche Arbeiten, die traditionell dem Back-Office zugerechnet werden, durch RPA automatisiert werden – etwa die Übertragung von Daten aus Kunden-E-Mails in die CRM- und ERP-Systeme eines Unternehmens (Willcocks et al. 2015). Der digitale Jackpot: automatisier- und digitalisierbare Prozesse Interessant wird es für Unternehmen immer da, wo Prozessschritte sowohl automatisierbar als auch digitalisierbar sind – diese Arbeitsschritte lassen sich in der Zukunft vollständig auslagern – und zwar zu Null-Grenzkosten. Die Versicherungsbranche ist dafür ein gutes Beispiel: Bis heute dominieren Menschen diesen Bereich, doch eine individuelle Beratung zur effizienten Versicherungsabdeckung möglicher Schäden folgt sich wiederholenden Arbeitsschritten, die digital in Algorithmen abbildbar sind. Die notwendigen Berechnungen und Analysen im Vorfeld der Beratung können von Software durchgeführt werden. Die eigentliche Beratungsleistung kann via Eingabeoberflächen direkt am Monitor erfolgen. Digitale Versicherungsberater können in Zukunft für Versicherungskunden das passende Produktportfolio ermitteln, ohne dass ein Mensch in diesen Prozess eingreifen muss. Prozesse, die weder digitalisierbar noch automatisierbar sind, werden in der Regel dem Kerngeschäft des Unternehmens zugerechnet. In diese Kategorie fallen zum Beispiel in einem herstellenden Unternehmen die Teilbereiche Entwicklung, Design, Forschung und Management. Diese Prozesse sind in der Regel nicht standardisiert, weil sie für den Erfolg die menschliche Kreativität brauchen, daher können sie nicht automatisch von Maschinen übernommen werden. Wenn Tätigkeiten zwar automatisierbar, aber nicht digitalisierbar sind, handelt es sich um Prozessschritte, die möglicherweise von Maschinen und Robotern durchgeführt werden können. Tätigkeiten, die dagegen digitalisierbar, aber nicht automatisierbar sind, können in der Regel den Teilbereichen Vertrieb bzw. Kundenberatung zugeordnet werden. Sie sind immer dann anzutreffen, wenn über die standardisierten Prozesse hinaus zwischenmenschliche Fähigkeiten gefragt sind. So basieren bis heute viele Vertragsabschlüsse zwischen Unternehmen auf der menschlichen Interaktion und dem Vertrauen zwischen Vertriebs- und Einkaufsabteilungen. Aber auch hier sorgt die Digitalisierung

204

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie automasierbar So ware-Services

Robok

Physische Automasierung Physische Akvität erforderlich

Typische Posionierung Typische Posionierung des Kerngeschä s, wenn das Unternehmen nicht selbst zu einem digitalen „Pure Player“ werden möchte.

Fließband

Plaorm-Services

IT-Services Infrastructure-Services

IT-Betrieb

So ware-Entwicklung DevOps

Menschen im Vordergrund Feature Teams

digitalisierbar

Vertrieb Vertragsprüfung Kundenberatung

Künstliche Intelligenz Markeng

Unternehmenssteuerung Forschung & Entwicklung Nicht automasierbar

Abb. 7.7   Kerngeschäft zwischen Digitalisierung und Automatisierung

für eine Veränderung der Aufgaben (Frank 2018). Abb. 7.7 gibt einen Überblick über die Automatisierbarkeit und Digitalisierbarkeit von Arbeitsschritten. Die graue und dunkelgraue Fläche zeigt jenen Bereich an, in dem es sich für Unternehmen lohnt, einzelne Prozessschritte zu internalisieren. Hier überwiegen die Vorteile des Spezialwissens die Nachteile der internen Transaktionskosten. Die typische Positionierung dieser Tätigkeiten kann im unteren linken Quadranten verortet werden. Hier stehen die Menschen im Vordergrund bei der Durchführung der Tätigkeiten. Kreativität, abstraktes Verständnis der Situation und strategisches Denken sind in diesem Bereich gefragt. Zu diesen „nicht-auslagerbaren“ Tätigkeiten gehört unter anderem die Arbeit der Feature- und DevOp-Teams. Aber auch die Bereiche Unternehmenssteuerung und Forschung werden zunächst menschliche Domänen bleiben. Dennoch werden selbst klassische Bereiche des Kerngeschäfts mit jeder technologischen Neuerung immer stärker digitalisier- und automatisierbar. Ein spektakuläres Beispiel für diese Entwicklung liefert das System AutoML von Google. Noch vor wenigen Jahren war es undenkbar, dass Algorithmen die Aufgaben eines Programmierers übernehmen könnten. Zu komplex schien die Aufgabe, zum Beispiel Machine-Learning-Algorithmen für unterschiedliche Aufgabenfelder zu programmieren und zu trainieren. Mit AutoML hat Google ein System erarbeitet, das Algorithmen befähigt, eigene Machine-Learning-Codes zu entwickeln und diese zu testen. Dabei stützt sich das System von Google auf das sogenannte „bestärkende Lernen“ (Reinforcement Learning): Durch vorgegebene digitale Belohnungssysteme sind Algorithmen bei diesem Modell in der Lage, eigenständig die Qualität der Aufgabenerfüllung zu überprüfen und so die nächste Generation der entwickelten Machine-Learning-Algorithmen anzupassen.

7.5  Neue Make-or-Buy-Entscheidungen durch die Digitalisierung

205

Bereits 2017 gelang es AutoML, mithilfe dieser Verfahren Machine-Learning-Codes zu entwickeln, die in ihrer Qualität die von menschlichen Entwicklern programmierten Systeme übertrafen. In einer Bilderkennungsaufgabe erreichte der von den Algorithmen entwickelte Machine-Learning-Code eine Genauigkeit der Vorhersage von 82 %. Das war ein besserer Wert als jener, den die von menschlichen Entwicklern entworfenen und trainierten Systeme erreicht hatten (Greene 2017). Durch die Möglichkeit der automatisierten Programmierung wird sich Arbeit der Programmierer aus Fleisch und Blut künftig verändern. Sie werden in Zukunft weniger Zeit für „Fließbandaufgaben“ aufwenden, die sich in ihrer Struktur immer wiederholen. Stattdessen können sie sich stärker auf die komplexen Entwicklungsaufgaben bei der Erstellung von Software und Algorithmen fokussieren. Übertragen auf die Grafik in Abb. 7.7 werden sich die Aufgaben der Entwicklung von standardisierten Softwareteilen aus dem Kerngeschäft der Software-Entwickler in den rechten oberen Quadranten herausentwickeln. Eine solche Verabschiedung von Tätigkeiten aus dem Kerngeschäft wird es in Zukunft immer häufiger geben. So ist es unter anderem denkbar, dass die Überprüfung von Verträgen, Managemententscheidungen, aber auch das Erstellen von Werbeclips zukünftig von Maschinen übernommen werden. Beispielsweise hat das Unternehmen Deep Knowledge Ventures bereits 2014 einen Algorithmus namens Vital in den Vorstand aufgenommen (Wile 2014). Wann lohnt sich die Auslagerung von Prozessschritten – und wann nicht? Dass ein Prozessschritt automatisierbar bzw. digitalisierbar ist, bedeutet nicht zwangsläufig, dass er ausgelagert werden sollte – unabhängig davon, ob es sich um ein Outsourcing an externe Anbieter oder einen Algorithmus handelt. Im Gegenteil: Gelingt es einem Unternehmen, durch seine Erfahrung in diesem Bereich Prozessschritte besser zu automatisieren oder zu digitalisieren als die Konkurrenz und führt diese Internalisierung zu einem wesentlichen und wahrnehmbaren Zusatznutzen für den Kunden, dann spricht vieles dafür, die jeweiligen Tätigkeiten im Unternehmen zu belassen. Ein Beispiel: Aktuell wäre es fahrlässig, wenn Automobilkonzerne ihr Wissen über die Automatisierung von Arbeitsschritten in der Fertigung über Bord schmeißen und diese Tätigkeiten an externe Unternehmen auslagern würden. So haben im Jahr 2019 BMW und Microsoft die Schaffung einer gemeinsamen und offenen Plattform zur Steuerung von digitalen Produktionslösungen bekanntgegeben. Damit verdeutlicht BMW seinen Anspruch, auch in Zukunft Kapazitäten und Ressourcen in den Aufbau von Wissen über Fertigungsschritte zu investieren (Blackman 2019). Je weiter aber die technologische Entwicklung voranschreitet, desto kleiner werden die spezifischen Vorteile, die sich durch das intern erworbene Wissen ergeben. Ab einem gewissen Reifegrad der Automatisierung sinkt der Zusatzumsatz, der durch die Fertigung mit Spezialwissen generiert werden kann. So sind die Qualitätsunterschiede bei der Herstellung von Baumwoll-T-Shirts seit Jahren so gering, dass sich die Auslagerung der Herstellungsprozesse lohnt. Auch ein Unternehmen wie Apple kann es sich leisten, die

206

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Fertigung seiner komplexen Geräte an seinen chinesischen Zulieferer Foxconn auszulagern, ohne dass die Kunden das Produkt deshalb schlechter beurteilen. Es existiert also eine Wahrnehmungsschwelle beim Kunden, die für Unternehmen bei der Entscheidung über Make-or-Buy äußerst relevant ist: 

Bemerkt der Kunde den Unterschied vor und nach der Auslagerung, oder nicht?

Für Textilhersteller ist diese Schwelle der Wahrnehmbarkeit der Produktunterschiede bereits seit Jahrzehnten unterschritten. Die notwendigen Produktionsschritte sind deutlich einfacher und austauschbarer und daher übersteigen die Vorteile der Internalisierung der Produktion schon seit langem nicht mehr die Kosteneinsparungen, die sich durch die Auslagerung der Produktion in günstigere Fertigungsgebiete und an günstigere Hersteller ergeben. Dieser Zusammenhang ermöglichte den Aufstieg der Tigerstaaten seit den 1960er-Jahren (Abschn. 7.3). Die Entscheidung zwischen Insourcing und Outsourcing wird damit um einen wichtigen Faktor erweitert: um den zusätzlichen Umsatz, den das Unternehmen am Markt mit seinen durch Spezialwissen erstellten Produkten erzielen kann. Zwei Gleichungen stehen sich also gegenüber: .. Gewinn1 = Umsatzder mit Spezialwissen hergestellten Guter − HK − TAKintern

(7.3)

.. Gewinn2 = Umsatzder am Markt eingekauften Guter − Kaufpreis − TAKextern

(7.4)

Dabei gilt folgender Zusammenhang: 

Je digitalisierbarer und automatisierbarer ein Prozess ist, desto standardisierbarer ist er und desto geringer sind die Unterschiede zwischen den Herstellern.

Um es in der Sprache der Modeindustrie auszudrücken: Das Produkt kommt „von der Stange“ und ist kein Einzelstück. Damit steigen die Möglichkeiten der Auslagerung. Umgekehrt wird aber auch klar, wann sich die Rückverlagerung von Tätigkeiten in das eigene Unternehmen lohnt – nämlich dann, wenn das interne Digitalisierungswissen wächst und jenes der Zulieferer übertrifft. KI-basierte Software-Lösungen können dabei helfen, diesen Weg einzuschlagen. Beispielsweise hilft die Applikation Hiro Unternehmen dabei, ihre Business- und IT-Prozesse eigenständig zu optimieren. Das Unternehmen Arago bietet diese Software als SaaS-Lösung an, die über APIs in die IT-Prozesse der Unternehmen integriert werden kann. Mit Hiro lassen sich Geschäfts- und IT-Prozesse in Unternehmen durch Künstliche Intelligenz steuern und automatisieren. Gelingt es zum Beispiel einer deutschen Bank, eigenständig digitale Finanzberater zu entwickeln und weiterzuentwickeln, kann dieser Bereich als Kernaufgabe im Unternehmen verbleiben (Arago 2019).

7.6  Die Auswirkungen der Cloud-Revolution auf die …

207

automasierbar So ware-Services

Robok

Fließband

Plaorm-Services

IT-Services

IT-Betrieb

So ware-Entwicklung DevOps

Menschen im Vordergrund Feature Teams

Großer Katalog mit IT-Fergteilen

Infrastructure-Services

Vertrieb Vertragsprüfung Kundenberatung

Künstliche Intelligenz

Digitalisierbar

Physische Akvität erforderlich

Physische Automasierung

Cloud-Leistungsumfang Umfangreiches Porolio an IT-Fergteilen in der Cloud verfügbar.

Nutzbar in Mikrotransakonen

µ€ Global skalierbar

Kosten nur wenn Nutzen

Markeng

Unternehmenssteuerung Forschung & Entwicklung Nicht automasierbar

Abb. 7.8   Nutzung der Vorteile der Cloud mit geringen Transaktionskosten

Abb. 7.8 gibt einen Überblick über die Digitalisierungs- und Automatisierungsleistungen, die aus der Public Cloud bezogen werden können. Das Portfolio der Cloud Provider umfasst ein umfangreiches Portfolio an IT-Fertigteilen. Im Vordergrund stehen dabei Lösungen aus den Bereichen Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS), die gleichzeitig global skalierungsfähig sind und nur dann bezahlt werden, wenn sie auch wirklich genutzt werden (Kap. 4). Dargestellt werden die möglichen Einsatzbereiche dieser Cloud-Produkte in den grauen und dunkelgrauen Flächen in der Matrix in Abb. 7.8. Damit ergänzen sich in Zukunft die Kernaufgaben des Unternehmens (dunkelgraue Flächen in Abb. 7.7) und die Outsourcing-Optionen in die Public Cloud: Die Kernaufgaben verbleiben in den Unternehmen, während die digitalisier- und automatisierbaren Bereiche ausgelagert werden können. Der folgende Abschnitt liefert ein Beispiel dafür, wie eine Auslagerung in die Public Cloud die Transaktionskosten senkt und somit große Kosteneinsparmöglichkeiten gehoben werden können.

7.6 Die Auswirkungen der Cloud-Revolution auf die Transaktionskosten bei der Software-Nutzung Die Cloud-Transformation in Unternehmen lässt nicht nur die Grenzkosten für die Entwicklung und den Betrieb von Software sinken (Kap. 4, 5 und 6), sondern auch die Transaktionskosten bei der Nutzung von Software, da diese nicht mehr auf den eigenen Servern installiert, betrieben und gewartet werden muss. Dank schneller Datenübertragung und die durch die Automatisierung sinkenden Transaktionskosten können ganze Software-Suites via SaaS in der Cloud erworben und betrieben werden. Diese Lösungen

208

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

decken viele Standardbereiche von Unternehmenssoftware ab, von der Bereitstellung der Serverkapazität bis zur einfachen Tabellenkalkulation. Die Entscheidung, welche Teile der IT-Wertschöpfung „inhouse“ erbracht werden und an welcher Stelle externe Services genutzt werden, ist nicht einfach. Es handelt sich dabei nicht um eine punktuelle Entscheidung mit einer begrenzten Auswirkung – vielmehr beeinflusst sie den Fortbestand des Unternehmens maßgeblich. Bevor das Management eines Unternehmens diese Entscheidung treffen kann, sollte es sich Klarheit über fundamentale Fragen zum eigenen Kerngeschäft verschaffen. Wo wird (bezogen auf Abb. 7.8) die dunkelgraue Fläche des Unternehmens verortet? Ausgangspunkt der Positionierung dieses dunkelgrauen Rechtecks ist die Beantwortung der folgenden beiden Fragen: Was sind die Kernaufgaben und die wichtigsten Vermögenswerte (Core Assets) des Unternehmens? Als Core Assets werden alle dem Unternehmen zur Verfügung stehenden Ressourcen bezeichnet, die für die Herstellung des Produkts essenziell sind. Innerhalb der Core Assets können vier Formen unterschieden werden: 1. Physische Ressourcen wie Maschinen, Server, Produktionsmittel 2. Finanzielle Ressourcen (Guthaben, Kreditwürdigkeit) 3. Menschliche Ressourcen (das Wissen der Mitarbeiter) 4. Immaterielle Ressourcen (Lizenzen, Zugang zu Rohstoffmärkten, Patente, Algorithmen, Software) Um festzustellen, ob ein von Ihnen identifizierter Asset wirklich ein Core Asset der Unternehmens-Wertschöpfungskette ist, können Sie folgende Frage beantworten: 

Ist der Asset für die Erstellung des Produkts/der Dienstleistung wertvoll?

Wenn Sie diese Frage mit „Ja“ beantworten, haben Sie in der Regel einen Core Asset Ihres Unternehmens identifiziert. Kernkompetenzen werden als die Fähigkeit eines Unternehmens definiert, die Core Assets so miteinander zu kombinieren, dass daraus eine funktionierende Wertschöpfungskette und im Idealfall ein tragfähiges Geschäftsmodell wird. Das strategische Potenzial einer Kernkompetenz hängt davon ab, inwieweit durch den Einsatz der Kernkompetenz relevante Wettbewerbsvorteile gegenüber Wettbewerbern am Markt geschaffen werden können. Folgende Merkmale zeichnen Kernkompetenzen aus (Prahalad und Hamel 2006): 1. Kundenrelevanz: Die angebotene Leistung/das Produkt ist für den Kunden relevant und wahrnehmbar und der Kunde ist bereit, dafür zu zahlen. Beispiel: das Produktdesign von Apple. 2. Dauerhaftigkeit: Es ist für andere Unternehmen schwierig, die Kernkompetenz zu imitieren. Beispiel: die Marke Coca-Cola und die „Idee“ einer Geheimrezeptur.

7.6  Die Auswirkungen der Cloud-Revolution auf die …

209

3. Transferierbarkeit: Der Wettbewerbsvorteil ist auch auf andere Märkte übertragbar. Beispiel: die Feinmechanik, die von Canon in Druckern, Kopierern und Digitalkameras eingesetzt wird. Daher sollten Sie bei der Feststellung der internen Kernkompetenzen folgende Fragen möglichst mit Nein beantworten: • Kann das Unternehmen die Dienstleistung/das Produkt auch ohne die Kernkompetenzen herstellen? • Wären die Kunden ohne die Kernkompetenz genauso zufrieden mit dem Produkt oder der Dienstleistung? • Steht die Kernkompetenz auch anderen Unternehmen zur Verfügung? • Ist die Kernkompetenz einfach imitierbar? • Ist die Kernkompetenz einfach übertragbar? Aus der Kombination von Core Assets und Kernkompetenzen ergibt sich die Eigenständigkeit der Wertschöpfungskette eines Unternehmens. Abb. 7.9 verdeutlicht diesen Zusammenhang. Wenn die Frage nach den Kernkompetenzen und Core Assets für das Unternehmen geklärt ist, kann es mit der Frage nach dem In- oder Outsourcing der IT-Wertschöpfung beginnen. Auch hier helfen wieder zwei einfache Fragen bei der Beantwortung der Ausgangsfrage:  Wichtig  Gehört der infrage stehende Teil der IT-Wertschöpfung zu den Kernkompetenzen des Unternehmens? Wie hoch ist der zeitliche und finanzielle Aufwand, wenn die IT-Wertschöpfung intern erbracht wird?

Haben Sie für beide Fragen eine Antwort gefunden, hilft Ihnen Abb. 7.10, sich der Makeoder der Buy-Entscheidung zu nähern.

Core Assets

Physische Ressourcen

Finanzielle Ressourcen

Maschinen, Server, Produkonsmi
el, …

Guthaben, Kreditwürdigkeit, …

Menschliche Ressourcen

Immaterielle Ressourcen

Wissen der Mitarbeiter

Lizenzen, Zugang zu Märkten, Patente, …

Kernkompetenzen

verbinden Core Assets zu einer funkonierenden Wertschöpfung Relevant für den Kunden

Dauerha„ und schwer imierbar

Abb. 7.9   Kernkompetenzen und Core Assets

Auf andere Märkte übertragbar

Tragfähiges Geschäsmodell

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Sehr niedrig

210

Einzelfall Grafische Benutzeroberfläche

Make

für wich‚ge Unternehmens-App

Webserver

Vertriebsprozesse

Aufwand

Für Internetau ri

für Steuerung der Sales-Mitarbeiter

Buy Eigenes Rechenzentrum

betreiben und weiterentwickeln

Sehr hoch

Fachanwendung

Kubernetes-Service betreiben und weiterentwickeln

Büro-Soware

für eigene Fer‚gungs-Steuerung

Neue Wege

selbst programmieren

Generische Anwendung

We
bewerbsvorteile erzeugen So ware-Kompetenzen erlernen und die Plaorm-Services der Public Cloud nutzen, um Webewerbsvorteile zu erzeugen.

Neue Wege finden • Intelligente Partnerscha en schaffen • Geschä smodell verändern Autonomes Fahren für Autohersteller

• Winner-takes-it-all-Strategie versuchen

Sehr relevant für das Kerngeschä

Kernaufgabe

Abb. 7.10   Die digitale Make-or-Buy-Entscheidung: Beispielhafte Positionierung für ein Unternehmen mit physischen Produkten und zunehmender Relevanz digitaler Geschäftsmodelle

Auf der x-Achse der Matrix wird die Relevanz der IT-Leistung für das Kerngeschäft (Core Asset oder Kernkompetenz) aufgetragen. Auf der Y-Achse wird der zeitliche und finanzielle Aufwand beschrieben, den die eigenverantwortliche Herstellung des IT-Services verursachen würde. In die Matrix können nun die einzelnen unternehmerischen Wertschöpfungsaktivitäten eingetragen werden, die mittels Software durchgeführt werden können. Je weiter eine Aktivität nach rechts unten wandert, desto weniger wird sie dem Kerngeschäft des Unternehmens zugeordnet und desto geringer ist der Aufwand, sie selbstständig zu erstellen. In diesem Bereich sollten sich Unternehmen für den Einkauf der Software-Lösung aus der Cloud entscheiden, denn hier liegt nicht der Fokus der unternehmerischen Tätigkeit. Auch kann sich das Unternehmen in diesem Bereich nicht von seinen Konkurrenten und Mitbewerbern am Markt abheben, denn der Betrieb der Software verschafft dem Unternehmen keinen Wettbewerbsvorteil. Zu diesen Bereichen gehört u. a. die Bürosoftware, aber auch in immer mehr Fällen der Betrieb eines eigenen Rechenzentrums. Im rechten oberen Quadranten sind jene Tätigkeiten aufgetragen, deren Entwicklung zwar einerseits einen großen Aufwand bedeuten, aber gleichzeitig dem Kernbereich des Unternehmens zugeordnet werden können. Hier sind die Aktivitäten verortet, die ein Unternehmen beherrschen muss, um sich auch in Zukunft von seinen Mitbewerbern abzugrenzen und als eigenständiger Anbieter mit einem diversifizierten Produktangebot wahrgenommen zu werden. Das kann beispielsweise eine Risikokalkulations-Soft­ ware für einen Versicherer sein, eine Vorschlags-AI für individualisierten Medien­ konsum für digitale Musikplattformen oder die eigenständige Software-Entwicklung für selbstfahrende Autos.

7.7  Praxisbeispiel: Wie der Softwareeinkauf via Cloud die …

211

Ist der Aufwand für die Entwicklung niedrig und verspricht es dennoch einen signifikanten Wettbewerbsvorteil, so bieten sich Freiräume für Einzelfall-Entscheidungen. So kann es beispielsweise sinnvoll für ein Unternehmen sein, die grafische Benutzeroberfläche für eine wichtige Unternehmensapplikation selbst zu erstellen und so die digitalen Kompetenzen im eigenen Unternehmen im Bereich der Nutzerführung (UX) zu stärken. Gehört die wertschöpfende Tätigkeit zu den Kernaufgaben des Unternehmens und ist die Entwicklung gleichzeitig mit einem prohibitiv hohen Aufwand verbunden, dann ist das Unternehmen möglicherweise gezwungen, über neue Wege nachzudenken. Denkbar sind in diesem Fall beispielsweise Partnerschaften mit Unternehmen, die sich intensiv mit der Lösung des Problems auseinandersetzen. Beispiele für solche neuen Kooperationsformen werden in Abschn. 7.9 vorgestellt. Diese Matrix zielführend auszufüllen, ist keine triviale Aufgabe. Für ein Unternehmen mit einem eigenen Rechenzentrum und entsprechend qualifizierten Mitarbeitern scheint es möglicherweise verlockend einfach und kostengünstig, die CRM-Applikation auf den eigenen Systemen laufen zu lassen. Wie aber werden die Opportunitätskosten in die Kalkulation eingebunden? Schließlich könnten die durch diesen administrativen Prozess gebundenen Mitarbeiter auch in den Primärprozessen eingesetzt werden. Und ist die dauerhafte Bindung von Kapital und Know-how im Rechenzentrum insgesamt sinnvoll in der Aufwandberechnung berücksichtigt? Bei der Aufwandsberechnung bleibt einem Unternehmen viel Spielraum. Perspektivisch sollte es bei seiner Kalkulation davon ausgehen, dass die Public-Cloud-Provider in den nächsten Jahren weiterhin ihre Preise senken werden. Die drei großen Anbieter AWS, Microsoft und Google kämpfen intensiv um Marktanteile und haben dank ihrer Skalenvorteile noch Luft für weitere Kostensenkungen (Joos und Karlstetter 2018).

7.7 Praxisbeispiel: Wie der Softwareeinkauf via Cloud die Transaktionskosten senkt Die Veränderungen, die sich durch die Digitalisierung beim Software-Einkauf ergeben, werden im Folgenden anhand der Implementierung einer Customer-Relationship-Management-Software (CRM) geschildert. Dazu wird zunächst der Aufwand der traditionellen Beschaffung und Implementierung eines CRM-Systems wie SAP CRM oder Oracle Siebel dargestellt. Dieser Aufwand wird mit dem Prozess der Implementierung eines CRM-Systems als Software-Service (SaaS) verglichen. Beispiele hierfür sind Salesforce oder Microsoft Dynamics 365.

7.7.1 Der Einkaufsprozess eines klassischen CRM-Systems im eigenen Rechenzentrum Customer-Relationship-Management-Systeme (CRM-Systeme) bilden in vielen Unternehmen das Herzstück der (digitalen) Kommunikation mit den Kunden. In diesen

212

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Systemen sind in der Regel sämtliche Kundendaten, Kommunikationsverläufe und Kontaktdaten entlang des Kundenlebenszyklus abgelegt. Die gespeicherten Daten dienen als Grundlage für die effiziente Ausgestaltung der Kundenbeziehungen (Möhring et al. 2018). Im folgenden Beispiel wird davon ausgegangen, dass ein Fachbereich eines großen Unternehmens ein neues CRM-System anschaffen möchte, weil das bestehende System die Anforderungen des neuen Geschäfts nicht abbildet. Weitere Fachbereiche des gleichen Unternehmens sind grundsätzlich auch an neuen CRM-Funktionen interessiert und behalten sich vor, zu einem späteren Zeitpunkt einzusteigen. Sie streben somit keinen sofortigen Wechsel an, werden aber am Neuanschaffungsprozess beteiligt, um möglichst alle Anforderungen an das neue System berücksichtigen zu können. Weitere Beteiligte im Auswahlverfahren sind: • Fachexperten aus Marketing und Sales: Diese haben den eigentlichen Auswahlprozess angestoßen, um ihr neues, digitales Geschäftsmodell mit automatisierten Sales-Prozessen zu unterstützen. • Mitarbeiter aus dem IT-Betrieb: Diese sollen sicherstellen, dass das neue System im Rechenzentrum des Unternehmens gut und günstig betrieben werden kann. • Mitarbeiter der Software-Entwicklung: Das aktuelle System bedurfte einiger Spezialentwicklungen, um die besonderen Bedürfnisse des aktuellen Geschäfts in den CRM-Prozessen zu berücksichtigen. Die Software-Entwickler sollen dieses Knowhow in das Auswahlverfahren einbringen. • Enterprise-Architekt: Dieser IT-Architekt hat die gesamte IT-Landschaft des Unternehmens im Blick und soll sicherstellen, dass das neue CRM-System gut alle aktuellen Schnittstellen bedienen kann. • Einkaufsabteilung: Diese bringt ihre Erfahrung bei der neutralen und objektiven Steuerung von Einkaufsprozessen ein. • Manager: Da es sich voraussichtlich um eine große Investitionsentscheidung handeln wird, werden Control-Boards mit den relevanten Entscheidern eingerichtet. • Projektleiter: Die Anzahl der beteiligten Mitarbeiter und Abhängigkeiten ist groß, daher wird ein Projektleiter gebraucht. Gemäß Abb. 7.11 beschreiben wir modellhaft den internen Prozess der Transaktion „Neues CRM-System anschaffen“. Informationskosten Die Transaktion beginnt mit der Gründung eines Projektteams. Dieses sammelt alle Anforderungen der Stakeholder und erstellt daraus ein Lastenheft. Nun wird auf Basis öffentlich verfügbarer Informationen eine Erstauswahl möglicher Anbieter erstellt und deren Eignung grob mit den Anforderungen des Lastenheftes abgeglichen. Es entsteht eine zweite Vorauswahl von meistens drei bis sechs Anbietern. Diese werden eingeladen,

213

7.7  Praxisbeispiel: Wie der Softwareeinkauf via Cloud die … Großer Entscheidungsumfang Fachprozesse CRM-Applikaon Middleware

• Ganzer Stack: Alle Ebenen des Stacks, von Infrastruktur bis Fachexperten sind betroffen. • Maximaler Bedarf: Die IT-Wertschöpfung wird am maximalen Bedarf ausgerichtet. • Lange Dauer: IT-Mitarbeitern und -Ressourcen sind über mehrere Jahre gebunden.

Viele Beteiligte

Sales & Markeng Controlling, Einkauf & Legal

Anbieter A Anbieter B Anbieter X

Höhere Risiken IS

Management

• Theoresche Analyse: Entscheidung auf Basis von theoreschen Analysen und Demo-Daten der Hersteller. • Viele Parteien: In Umsetzung und Betrieb sind viele Stakeholder mit unterschiedlichen Interessen involviert. • Manuelle Prozesse: In Umsetzung und Betrieb gibt es viele menschen-bedingte Fehlerquellen.

CRM

IT-Architektur IT-Projekt & Betrieb IT-Infrastruktur

Hohe Transakonskosten Es entstehen hohe Managementund Koordinaons-Aufwände im kompleen Prozessablauf.

Abb. 7.11   Hohe interne Transaktionskosten in der klassischen IT

um ihr jeweiliges System persönlich vorzustellen. Bei diesen Präsentationen sind dann viele der intern im Unternehmen betroffenen Stakeholder anwesend. In einer weiteren Phase stellen die Anbieter ein abgeschottetes System als Demonstrations-Umgebung zur Verfügung. Die Nutzer können nun in kleinem Umfang und auf Basis von Demo-Daten des Anbieters ihre Prozesse ausprobieren. Auf Basis der gesammelten Informationen erstellt das Projekt-Team eine Entscheidungsvorlage für die Geschäftsleitung. Darin sind alle voraussichtlichen Kosten der Einführung des CRM-Systems für die nächsten Jahre aufgeführt. Dies beinhaltet die Kosten für den Aufbau und den Betrieb aller Ebenen des Stacks, einschließlich der Infrastruktur, der Middleware, der Applikation sowie der Einrichtung der Fachprozesse. Die Infrastruktur ist dabei auf die maximal erwartete Auslastung ausgelegt und wird meist über drei bis fünf Jahre abgeschrieben. Entscheidungskosten In Summe handelt es sich um eine große Investition, die Kapital und Mitarbeiter mindestens über die Dauer der Abschreibung bindet. Da die CRM-Applikation bisher nur in einer Demonstrationsumgebung und nicht mit den tatsächlichen Daten und Prozessen des Unternehmens ausprobiert werden konnte, besteht zudem ein höheres Risiko einer Fehlentscheidung. Weitere Risiken gibt es in der Implementierung des Systems, denn keiner der Beteiligten im Unternehmen hat echte Erfahrungen mit dem neuen CRM-System. Ein weiteres, wenngleich internes, Entscheidungsproblem birgt die Einbindung derjenigen Fachbereiche, die das neue System nicht sofort einführen möchten. Sollen nun ihre Fachanforderungen bei der Entscheidung berücksichtigt werden oder nicht? Wie viele Lizenzen sollen gekauft und wie viel IT-Infrastruktur soll vorgehalten werden? Den Entscheidern wird es demnach nicht leicht gemacht: Der Entscheidungsumfang ist groß, die Risiken sind hoch. Um dennoch die richtige Wahl treffen zu können, werden weitere Informationen eingeholt. Zudem wird versucht, die Risiken auf die jeweils andere Partei zu übertragen: Das Unternehmen versucht, den CRM-Anbieter auf einen

214

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Festpreis im Implementierungsprojekt festzulegen. Der CRM-Anbieter wiederum versucht, eine Mindestabnahme an Software-Lizenzen zu vereinbaren, um seine eigenen hohen Vertriebsaufwände zu refinanzieren. In diesem Klima der gegenläufigen Interessen werden entsprechend häufig die Anwälte und Finanzcontroller in den Entscheidungsprozess miteinbezogen. Kontroll- und Administrationskosten Aufgrund der vielen involvierten Stakeholder entstehen hohe Kontroll- und Administrationskosten. Die erste Kontrollinstanz ist in der Regel der Projektleiter: Er plant, steuert und kontrolliert die Akteure während der Herstellung. Er selbst wiederum berichtet an das Control Board des Projekts. Je nach Größe und Konstellation des Projekts gibt es mehrere Ebenen (mittlere Hierarchie und Top-Management) und Varianten (mit und ohne externe Lieferanten). Der Projektleiter wird meist administrativ durch Project Management Offices (PMO) unterstützt. Die in die Herstellung involvierten Mitarbeiter werden von weiteren Kontroll- und Administrationsprozessen begleitet. Dazu gehört neben den üblichen HR-Prozessen (wie Bewertung, Feedback, Abrechnung) auch die Sicherstellung der Auslastung der Mitarbeiter mit verrechenbaren Aufgaben. Wurde das System erfolgreich implementiert, geht es in den Betrieb über (Abschn. 4.2). Kontroll- und Administrationsaufgaben werden dort von den Rollen „Service Manager“ und „Service Delivery Manager“ übernommen. Kosten für die Weiterentwicklung Kosten für Änderungen am bestehenden System entstehen insbesondere durch • • • •

Ausfälle und Fehler, die während des Betriebs entstehen notwendige Systemupdates auf allen Ebenen des IT-Stacks zusätzliche Infrastrukturressourcen Wünsche nach neuen inhaltlichen Funktionen

Alle diese Aufwände müssen ebenfalls vom Unternehmen selbst übernommen werden. Ausnahmen sind jene inhaltlichen Funktionalitäten, die vom CRM-Anbieter im Rahmen seiner regelmäßigen Updates hinzukommen. Zusammengefasst kann eine Anschaffung eines CRM-Systems zu einer unternehmensinternen „Never-Ending-Story“ werden, an der sich zahlreiche Abteilungen über Jahre die Zähne ausbeißen, ohne dass eine befriedigende Lösung für das Unternehmen gefunden wird. Die internen Transaktionskosten bei der Implementierung von großen Software-Anwendungen im eigenen, klassischen Rechenzentrum sind hoch. Dies trifft insbesondere dann zu, wenn sich interne Stakeholdergruppen noch nicht darüber im Klaren sind, welche zukünftige Anforderungen sie an das System haben werden.

7.7  Praxisbeispiel: Wie der Softwareeinkauf via Cloud die …

Wenige Stakeholder involviert

Entwickler

Sales-Experte BetriebsMitarbeiter

215

Feature Team

Ausprobieren mit Echtdaten Cloud-Architekt

Geringere Transakonskosten

Automasierte Steuerungsprozesse

Service A

Versteckte ITKomplexität

Geringes Investrisiko

CRM

Service B

Service C

Kleiner Entscheidungsumfang

Weniger involvierte Menschen

Kleinere Risiken

Abb. 7.12   Niedrige externe Transaktionskosten bei der Nutzung von Software-Services

7.7.2 Nutzung von Software-Services (SaaS) für CRM Entscheidet sich ein Unternehmen für die Nutzung eines CRM als Software-Service, so ändern sich die Transaktionskosten relevant (s. Abb. 7.12). Auch in diesem Falle geht die Initiative zur Erneuerung der CRM-Software von der gleichen Abteilung aus, der Prozess unterscheidet sich dennoch wesentlich. Häufig beginnt dieser mit einem kostenlosen Test des SaaS-Angebots im Netz. Viele Anbieter solcher Software-Services bieten den ersten Monat kostenlos an. Hat sich die Software mit den ersten Echt-Daten bewährt, ist der Umstieg auf eine kostenpflichtige Variante verlockend einfach: Die Einstiegspreise liegen in einem Bereich, den viele Team- und Abteilungsleiter noch ohne Einbindung des Top-Managements, des Einkaufs und der Rechtsabteilung genehmigen können.1 Auf diese Weise entsteht die von IT-Leitern so gefürchtete „Schatten-IT“ (Herrmann 2017) – also die autonome Beschaffung und Entwicklung von IT durch einzelne Mitarbeiter oder Fachbereiche ohne Einbindung der IT-Abteilung (Rentrop und Zimmermann 2015). In diesem Abschnitt wird der zu empfehlende, offizielle Weg der Transaktion „Nutzung eines CRM-SaaS“ beschrieben. Anbahnungs- und Informationskosten Geht der Fachbereich den offiziellen Weg der Softwarebeschaffung auch für Cloud-Services, ist es wichtig, erst einmal die dafür geltenden, internen Regelungen herauszufinden. Dies betrifft insbesondere Compliance-Richtlinien über die erlaubten Orte der Datenspeicherung – in der Regel ist die Nutzung von europäischen Cloud-Services

1Der

Marktführer Salesforce bietet (Stand Juni 2019) ein Basis-System für 300 EUR pro Nutzer und Jahr bei jährlicher Kündigungsfrist an.

216

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

problemlos möglich. Die Entscheidungsobergrenzen bei der Beschaffung von Software geben Aufschluss darüber, ob und in welchem Umfang Einkaufs-, Controlling- und Rechtsabteilung eingebunden werden müssen. Die eigentliche Software-Auswahl beginnt meistens mit der testweisen Nutzung der infrage kommenden Systeme durch den Hauptbedarfsträger selbst. Nachdem mehrere Anbieter getestet wurden, entwickeln sich schnell Präferenzen. Bezogen auf die favorisierten Anbieter geht es dann darum, die Preismodelle zu verstehen: Sind die Kosten abhängig von der Anzahl der Nutzer? Oder eher von Transaktionen? Wenn ja, von welchen Transaktionen genau und wie häufig werden diese voraussichtlich auftreten? Gibt es Unterteilungen nach Fachbereich, werden also für Marketing-Funktionen zusätzliche Kosten fällig? An dieser Stelle sollte der Fachbereich unterschiedliche Szenarien durchrechnen. Eine einfache Daumenregel der Cloud wird aber in den meisten Fällen weiterhin Bestand haben: Die Kosten korrelieren stark mit der tatsächlichen Nutzung des Systems. Bei Software-Services sind die Synergien mit den anderen Fachabteilungen – insbesondere, wenn sie selbst noch nicht genau wissen, ob und wie genau sie den Service nutzen wollen – beschränkt. Hohe Mengenrabatte lassen sich in der Cloud nur selten verhandeln und die benötigte Infrastruktur wird sowieso erst mit der tatsächlichen Nutzung hochgefahren. Nutzen Unternehmen schon Feature Teams oder DevOps, sind diese ohnehin weitestgehend frei in der Auswahl ihrer spezifischen Software-Tools. Eine weitere relevante Frage darf in der Informationsphase nicht vergessen werden: Wie passt der neue Service in die vorhandene IT-Architektur? Der neue CRM-Service wird wichtige Daten erzeugen – wie genau kann das Unternehmen darauf zugreifen und sie mit anderen relevanten Informationen zusammenführen? Welche Abhängigkeiten entstehen durch diesen Service und wie können diese durch geschickte Architektur-Entscheidungen reduziert werden? Die Anbieter von Cloud-Services unterscheiden sich diesbezüglich substanziell. Cloud-Solution-Architects sollten hier entsprechende Entscheidungsvorlagen erstellen. Entscheidungskosten Die Entscheidung ist bei Software-Services vergleichsweise einfach. Sie betrifft im Wesentlichen drei Punkte: • Fachlicher Funktionsumfang: Die eigentlichen Features, nach denen sich die CRM-Anbieter unterscheiden • Preismodell: Die Struktur der Preise, nach denen sich die Gesamtkosten gemäß der Nutzung entwickeln. • IT-Architektur: Wie gut bettet sich der Service in die IT-Landschaft ein und welche technische Flexibilität (Schnittstellen, Abhängigkeit) ergibt sich langfristig? Der Entscheidungsumfang ist insgesamt kleiner, da es weder um langjährig abzuschreibende Hardware-Investitionen noch um größere Implementierungsprojekte auf

7.7  Praxisbeispiel: Wie der Softwareeinkauf via Cloud die …

217

den Ebenen Infrastruktur, Middleware und Applikation geht. Die Risiken sind insgesamt auch niedriger, da die Services mit realen Daten und in kleinem Umfang ausprobiert werden können, bevor größere Mengen davon abgenommen werden müssen. Die geringere Anzahl der involvierten Stakeholdergruppen reduziert Missverständnisse und Abhängigkeiten, und die Automatisierung der Umsetzung auf IT-Ebene senkt die Projektrisiken. Einkaufs- und Kontrollkosten Die Einkaufskosten – also die Preise der Software-Services – sind keine Transaktionskosten, deren Kontrolle dagegen schon. Da die Leistungserbringung des SaaS vollständig automatisiert und software-definiert erfolgt, kann auch die Kontrolle komplett automatisiert in Form eines Monitoring-Tools erfolgen. Dieses kann nach Belieben den gesamten Service, verschiedene Teile des Services oder bestimmte Prozessabläufe monitoren und – bei Bedarf – Warnmeldungen versenden oder andere Aktionen auslösen. Durchsetzungskosten Streitigkeiten zwischen Unternehmen und Software-Anbietern sind bei der Nutzung von SaaS relativ selten. Dies liegt einerseits daran, dass die meisten Software-Services resilient entwickelt wurden (Kap. 6) und somit auch funktionsfähig bleiben, wenn die darunterliegende Infrastruktur für eine gewisse Zeit nicht verfügbar ist. Andererseits erstatten die Anbieter – wenn überhaupt – zeitgenau nur jenen Anteil der Kosten, an denen der Service nicht verfügbar war. Hier lohnt es sich kaum, hohe Aufwände für die Durchsetzung eigener Ansprüche auf sich zu nehmen. Anpassungskosten Das einzelne Unternehmen hat faktisch keine Möglichkeit, Anpassungen an der gelieferten Leistung vorzunehmen. Der Software-Service, den es erhält, wurde automatisch erzeugt und wurde vor der Bezahlung vom Unternehmen selbst schon genutzt. Es hat keinerlei Einblick in oder individuelle Verfügungsmacht über die hinter den APIs bzw. der GUI gekapselte IT. Somit können auch keine nachvertraglichen Anpassungskosten entstehen. Unternehmen können zwar die meisten Software-Services einfach um eigene Funktionen ergänzen, diese fallen aber nicht unter den geschuldeten Leistungsumfang des Anbieters und somit entstehen dort keine externen Transaktionskosten. Abschließend lässt sich formulieren, dass die externen Transaktionskosten bei der Nutzung eines CRM-Software-Services deutlich geringer ausfallen als die internen Transaktionskosten bei Anschaffung und Betrieb eines klassischen CRM-Systems. Hauptursache hierfür ist der große Umfang der Entscheidung im klassischen Ansatz sowie die größere Unsicherheit bei der Entscheidung selbst. In Summe führt dies zu einer Einbindung von mehr Menschen mit teilweise divergierenden Zielen, die dann über den gesamten Zeitraum der Transaktion mehr Aufwand und Kosten erzeugen.

218

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

7.8 Auf dem Weg zur Netzwerkökonomie Die Beachtung der Transaktionskosten im Kontext der IT-Wertschöpfung ist für Unternehmen von fundamentaler Bedeutung. Doch was für jedes einzelne Unternehmen gilt, besitzt auch Sprengkraft im Verhältnis der Unternehmen untereinander. Die zu Beginn des Kapitels beschriebenen Möglichkeiten, die Transaktionskosten durch die Digitalisierung zu senken, führen in ihrer Gesamtheit zu einer neuen Form des Wirtschaftens (s. Abb. 7.13). Die hohen Transaktionskosten der nicht-digitalen Wirtschaft waren der Kleber, der die Wertschöpfungsketten zusammengehalten hat. Sie ermöglichten es Unternehmen, eine stabile Positionierung innerhalb der Wertschöpfung zu finden und in diesem Rahmen Produkte und Dienstleistungen selbst herzustellen, anstatt sie zu kaufen. Mit der Digitalisierung sinken die externen Transaktionskosten schneller als die internen Transaktionskosten. In der Folge lohnt sich in immer mehr Bereichen die Auslagerung von Tätigkeiten und damit löst sich der Kleber auf, der die traditionellen Wertschöpfungsketten zusammengehalten hat. Aus Integratoren können zunehmend Orchestratoren werden, die ihrerseits wiederum Layer Player für die einzelnen Stufen der Wertschöpfung beschäftigen. Als Folge entstehen Netzwerkstrukturen, die sich grundlegend von den hierarchisch organisierten internen Wertschöpfungsketten unterscheiden. Immer neue Kombinationsmöglichkeiten werden in Zukunft die Arbeitswelt bestimmen. Produkt A kann mit Zulieferer B und dem Software-Angebot beispielsweise aus der Google-Cloud erstellt werden. Produkt B dagegen greift auf das Logistik-Unternehmen C zu und ist damit unabhängig vom Logistik-Anbieter, mit dem das Unternehmen bisher immer gearbeitet hat. Das Unternehmen, das beispielsweise einen eigenen digitalen Uploadfilter für seine Kommentarfunktionen auf der Unternehmenswebseite entwickeln möchte, kann sich

Fachliche Services für das Kerngeschä

Kerngeschä

Fachliche Services für Supportprozesse Allgemeine IT-Services Video-Indexer

Umfangreiches Outsourcing in Netzwerkstruktur

Schlüsselfunkonen der Soware, Architektur, Daten, Integraon, Oberfläche und Analycs

Fokus auf die Orchestrierung externer Services sowie eigene Herstellung weniger Kernfunkonen

Zahlungsabwicklung Identätsmanagement Reisekostenmanagement Bürosoware Collaboraons-Soware CRM-System

Rechenleistung Speicher Container

…

Core Services …

Layer Player liefern spezielle Teile der Wertschöpfung für fast alle Markeilnehmer

…

Abb. 7.13   Auf dem Weg zur Netzwerkökonomie: beispielhafte Darstellung der Auflösung klassischer Wertschöpfungsketten durch sinkende Transaktionskosten in der Digitalwirtschaft

7.8  Auf dem Weg zur Netzwerkökonomie

219

dafür entscheiden, den Basis-Service eines Cloud-Providers zu nutzen und nur die Benutzeroberfläche und das Nutzermanagement selbst zu programmieren. Es kann aber auch selbst einen entsprechenden Indexer erstellen und diesen an andere Unternehmen vermarkten, die den gleichen Bedarf haben. Diese Entscheidungen können wiederum alle Beteiligten im Wertschöpfungsnetzwerk für sich treffen. Dank der digitalen Vertriebsstrukturen der Null-Grenzkosten-Geschäftsmodelle kann sich ein solches Angebot schon ab kleinen Abnahmemengen für das anbietende Unternehmen lohnen. Es entsteht eine neue Form der wirtschaftlichen Zusammenarbeit: Über die Unternehmen spannt sich ein feines Netz aus Kooperationen, das bei Bedarf immer neu geknüpft und aufgebrochen werden kann. Die Unternehmen agieren in diesem Szenario als Orchestratoren, die sich auf die Umsetzung ihrer eigenen Kernkompetenzen konzentrieren. Zur Umsetzung von spezifischen Aufgaben können die unterschiedlichen Angebote der Layer Player (Agenturen, Hyperscaler) miteinander kombiniert werden. Für jedes neuerstellte Produkt eines Unternehmens gilt daher die Suche nach der richtigen Zusammenstellung von eigenen Tätigkeiten (Insourcing) und Aufgaben, die extern gelöst werden können (Outsourcing). Langfristig entstehen so digitale Netzwerke rund um die Datenpools der großen Unternehmen und die Infrastrukturen der Cloud-Hyperscaler und Layer Player (Toth 2015). Aus Enemies werden Frenemies Die neue Form der Netzwerkökonomie hat relevante Auswirkungen auf die Zusammenarbeit von Unternehmen. Während sich Unternehmen aus einer Branche bis heute als Wettbewerber sehen, denen es Marktanteile „abzuringen“ gilt, ändert die Netzwerkökonomie schrittweise die Regeln. Durch die Aufsplittung der Tätigkeiten im digitalen Raum ergeben sich für Unternehmen unterschiedliche Einsatzbereiche und Rollen. So kann es sein, dass ein Unternehmen, das ein wichtiger Konkurrent in Branche A ist, in Branche B Dienstleistungen anbietet, die in den Unternehmensprozess integriert werden können. Ein zweites Unternehmen, das bisher als Wettbewerber betrachtet wurde, kann zu einem Kunden werden. Aus ehemaligen Konkurrenten werden Frenemies: also Unternehmen, die gleichzeitig Freund und Feind sind. Dieser Trend ist längst in der Realwirtschaft angekommen. Immer mehr Unternehmen erkennen die Bedeutung, die eine verstärkte externe Kooperation bietet. Hier einige Beispiele: • Otto nutzt als E-Commerce-Anbieter den Cloud-Provider AWS für das Hosting seiner Online-Shops. AWS ist ein Tochterunternehmen von Amazon – dem schärfsten Konkurrenten im Online-Shopping (Aberle 2018). • Netflix nutzt die AWS-Cloud für Rechenleistung und Speicherplatz, die Video-Streaming-Leistungen erfolgen über das eigene Content Delivery Network (Hahn 2016). Die Muttergesellschaft von AWS ist mit Amazon Prime Video einer der schärfsten Konkurrenten im Videostreaming.

220

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Klassische Wertschöpfung

Integrator bei hohen Transakonskosten

TAK

TAK

Netzwerkarge Wertschöpfung Orchestrator mit niedrigen Transakonskosten

A B Supportprozesse C D 1 2 3 4 5 Kernprozesse

TAK

Digitales Unternehmen

1

…

2

A

3

B

C

D

…

4 E

…

…

…

Abb. 7.14   Von der klassischen zur netzwerkartigen Wertschöpfung

• Microsoft, SAP und Adobe haben 2018 die „Open Data Initiative“ gegründet (Nickel 2018). Dadurch wird das Management der Daten zwischen den unterschiedlichen Anwendungen des Kunden vereinfacht. Microsoft und SAP konkurrieren in einigen Bereichen ihrer Wertschöpfung, unter anderem im Bereich CRM-Systeme, Analytics-Anwendungen und Datenbanken. • Drei Konkurrenten im Cloud-Geschäft – Google, Microsoft und IBM – haben sich zur sogenannten „Bandwith-Alliance“ zusammengeschlossen. Dadurch ermöglichen sie Kunden einen kostengünstigeren Transfer der Daten zwischen ihren jeweiligen Clouds und grenzen sich von AWS ab (FAZ 2018). • BMW und Daimler kooperieren bei der Entwicklung selbstfahrender Autos und schließen sich damit unter anderem gegen Google zusammen (manager magazin 2019). Gleichzeitig lassen beide die Nutzung des Google Assistants in ihren Autos zu. Viele Beispiele für den Trend zur Optimierung der Wertschöpfungsnetzwerke mit Hilfe von Frenemies stammen von der amerikanischen Westküste. In Europa dominierte lange Zeit (und bis heute) die Optimierung der Prozesse entlang der klassischen, linearen Wertschöpfungskette. Jetzt, da die internen Abläufe immer austauschbarer werden, ist es die Aufgabe der Manager, ihre Unternehmen auf neue Formen der externen Zusammenarbeit auszurichten. Aus klassischen Insourcing-Szenarien und der Optimierung der eigenen Wertschöpfungskette werden Outsourcing-Szenarien, bei denen es darum geht, das eigene Netzwerk zu pflegen (s. Abb. 7.14).

7.9 Fazit Die Rekombinationsmöglichkeiten in einer Netzwerkstruktur sind enorm. Bei einem Prozess mit drei Teilschritten und jeweils 20 eigenständigen Anbietern je Prozessschritt sind bereits 8000 Netzwerkkombinationen möglich. Unternehmen haben nun nicht nur

7.9 Fazit

221

die Möglichkeit, sondern die Verpflichtung, bei der Entwicklung neuer Produkte und Dienstleistungen interne Abläufe neu zu strukturieren. Sie können dabei für jede einzelne Prozessstufe wählen, ob sie die Tätigkeit selbst erstellen oder an einen anderen Anbieter auslagern. Die Digitalisierung weist dabei in eine klare Richtung: Immer mehr Prozesse

Die IT-Wertschöpfung wird mit Hilfe von Cloud-Technologien zunehmend automasiert.

Dedicated

IaaS

PaaS

SaaS Großer Katalog mit IT-Fergteilen

API

Make

Buy

API

Die via API bestellbare Cloud-IT senkt die Transakonskosten signifikant.

Je geringer die Transak onskosten, desto aƒrak ver ist Outsourcing. Aus MAKE wird BUY: Unternehmen können güns ger und besser einkaufen als selbst herstellen

Integratoren Unternehmen, die Wertschöpfung in sich vereinen

werden zu

Orchestratoren Unternehmen, die ihr Netzwerk orchestrieren

Unsere Volkswirtscha entwickelt sich in Richtung Netzwerk-Ökonomie. Unternehmen fokussieren sich stark auf ihren Kern … … und orchestrieren ein komplexes Wertschöpfungs-Netzwerk

… mit komplementären aber auch konkurrierenden Anbietern von Cloud-Services (Frenemies).

Abb. 7.15   Die durch Cloud-Technologien sinkenden Transaktionskosten verändern die Unternehmenswelt

222

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

werden durch Softwarelösungen automatisier- und digitalisierbar. Diese Argumentationskette wird in Abb. 7.15 zusammengefasst: • Aufgrund der sinkenden Transaktionskosten können IT-Prozesse, die nicht zu den Kernkompetenzen des Unternehmens gehören, verstärkt ausgelagert werden. • Dadurch werden Unternehmen in die Lage versetzt, sich von der vollständigen vertikalen Integration der eigenen Wertschöpfung zu verabschieden (Integratoren) und sich voll den eigentlichen Kernkompetenzen zu widmen. • Im Ergebnis entsteht eine neue Form der globalen und digitalen Zusammenarbeit zwischen Unternehmen in Netzwerkstrukturen, die die klassischen vertikal-integrierten Unternehmen aus dem Industriezeitalter allmählich ablösen. Damit verändern sich auch die Spielregeln der Wirtschaft, denn die Make-or-Buy-Entscheidung muss neu gedacht werden. Wesentlich stärker als bisher können Prozesse, die nicht zum Kerngeschäft gehören, ausgelagert werden. So werden in Zukunft alle Prozesse, die digitalisierbar und/oder automatisierbar sind, auf den Prüfstand gestellt werden. Gleichzeitig wird die Frage nach der Fähigkeit, eigene Softwareapplikationen zu erstellen, zur Gretchenfrage der Unternehmen. Um eigene Anwendungen entwickeln zu können, gilt es, das Unternehmen und die Abläufe zu restrukturieren. Das wiederum setzt die Cloud-Transformation im Unternehmen voraus. Wie eine solche Transformation aussieht und wie sie in der Praxis implementiert wird, wird in Kap. 8 dargestellt.

Literatur Aberle, Sebastian (2018): Otto goes AWS – Teil 2, erschienen in: dev.otto.de, https://dev.otto. de/2018/12/03/otto-goes-aws-teil-2/. Arago (2019): Künstliche Intelligenz – KI mit arago HIRO, erschienen in: sysback.de, https:// www.sysback.de/portfolio/it-automatisierung/kuenstliche-intelligenz-mit-arago-hiro.html, abgerufen im Juni 2019. Blackman, James (2019): Microsoft and BMW corral industry around open platform for digital factory solutions, erschienen in: enterpriseiotinsights.com, https://enterpriseiotinsights. com/20190405/channels/news/microsoft-and-bmw-corral-industry, abgerufen im Juni 2019. Brandt, Matthias (2019): Deutschland bleibt Glasfaser-Entwicklungsland, erschienen in: statista.de, https://de.statista.com/infografik/3553/anteil-von-glasfaseranschluessen-in-ausgewaehlten-laendern/. Bundesbank (2016): Bedeutung und Wirkung des Hochfrequenzhandels am deutschen Kapitalmarkt, erschienen in: Deutsche Bundesbank Monatsbericht Oktober 2016, S. 37–61, https:// www.bundesbank.de/resource/blob/665078/544876d8a09dd548ed15bd74ce14281f/mL/201610-hochfrequenzhandel-data.pdf. Coase, Ronald (1937): The Nature of the Firm, erschienen in: Economica, Ausgabe 4, S. 386–405, London. Dombrowski, Uwe und Tim Mielke (Hrsg.) (2015): Ganzheitliche Produktionssysteme – Aktueller Stand und zukünftige Entwicklungen, Springer Vieweg, Berlin, Heidelberg.

Literatur

223

Donath, Andreas (2018): Tesla hat Karosseriefertigung zu 95 Prozent automatisiert, erschienen in: golem.de, https://www.golem.de/news/autofabrik-tesla-hat-karosseriefertigung-zu-95-prozent-automatisiert-1806-134870.html. Eisenkrämer, Sven (2018): Deutsche Industrie liegt bei Automatisierung weit vorne, erschienen in: springerprofessional.de, https://www.springerprofessional.de/automatisierung/industrieroboter/ deutsche-industrie-liegt-bei-automatisierung-weit-vorne/15446374. Eurostat (2017): Unternehmen, die einen Breitbandzugang haben, erschienen in: ec.europa.eu, https://ec.europa.eu/eurostat/tgm/table.do%3Ftab=table%26tableSelection=1%26labeling=labels%26footnotes=yes%26language=de%26pcode=tin00090%26plugin=0, abgerufen im Juni 2019. Evans, Philip (2013): Wie Daten die Wirtschaft verändern, Vortrag im Rahmen eines TED-Talks, erschienen in: ted.com, https://www.ted.com/talks/philip_evans_how_data_will_transform_ business?source=twitter&language=de, abgerufen im Juni 2019. FAZ (2018): Microsoft, Google und IBM verbünden sich gegen Amazon, erschienen in: faz.net, https://www.faz.net/aktuell/wirtschaft/diginomics/microsoft-google-und-ibm-verbuenden-sich-gegen-amazon-15808145.html. Frank, Roland (2018): Beratung ist der neue Vertrieb – Wie die Digitalisierung den Sales-Prozess verändert, erschienen in: cloud-blog.arvato.com, https://cloud-blog.arvato.com/beratung-istder-neue-vertrieb-wie-die-digitalisierung-den-sales-prozess-veraendert/. Frey, Carl Benedikt und Michael A. Osborne (2013): The Future of Employment: How Susceptible Are Jobs to Computerisation?, erschienen in: Technological Forecasting and Social Change, Ausgabe: 114, Amsterdam. Fründt, Steffen (2009): Wie deutsche Unternehmen Jobs ins Ausland verlagern, erschienen in: welt.de, https://www.welt.de/wirtschaft/article3505965/Wie-deutsche-Konzerne-Jobs-ins-Ausland-verlagern.html. Gassmann, Oliver, Karoline Frankenberger und Michaela Csik (2013): Geschäftsmodelle entwickeln – 55 innovative Konzepte mit dem St. Galler Business Model Navigator, Carl Hanser Verlag, München. Gerste, Ronald (2019): Roosevelt vs. Rockefeller, erschienen in: cicero.de, https://www.cicero.de/ wirtschaft/roosevelt-vs-rockefeller/37712. Gildhorn, Kai (2019): Pfefferhandel im Mittelalter, erschienen in: schwarzerpfeffer.de, https:// www.schwarzerpfeffer.de/pfefferhandel-im-mittelalter/. Glüsing, Jens (2009): Der Fluch des Silbers, erschienen in: spiegel.de, https://www.spiegel.de/ spiegelgeschichte/a-638682.html. Greene, Tristan (2017): Google’s AI can create better machine-learning code than the researchers who made it, erschienen in: thenextweb.com, https://thenextweb.com/artificial-intelligence/2017/10/16/googles-ai-can-create-better-machine-learning-code-than-the-researchers-who-made-it/, abgerufen um Juni 2019. Hahn, Dietger und Bernard Taylor (Hrsg.) (2006): Strategische Unternehmungsplanung – Strategische Unternehmungsführung: Stand und Entwicklungstendenzen, Springer, Berlin, Heidelberg. Hahn, Dave (2016): How Netflix Thinks of DevOps, erschienen in: youtube.com, https://www. youtube.com/watch%3Fv=UTKIT6STSVM. Joos, Thomas und Florian Karlstetter (2018): Microsoft Azure versus Amazon Web Services, erschienen in: cloudcomputing-insider.de, https://www.cloudcomputing-insider.de/microsoftazure-versus-amazon-web-services-a-724581/. Herrmann, Wolfgang (2017): Die unsichtbaren Risiken der Schatten-IT, erschienen in: computerwoche.de, https://www.computerwoche.de/a/die-unsichtbaren-risiken-der-schatten-it,3331969, abgerufen im Juni 2019.

224

7  Sinkende Transaktionskosten und die neue Netzwerkökonomie

Kirchberg, Dennis (2007): Der Aufstieg der Tigerstaaten im 20. Jahrhundert: Eine historische Analyse, Akademiker Verlag, Saarbrücken. Littmann, Saskia (2013): Wirtschaftsnobelpreisträger Ronald Coase ist gestorben, erschienen in: wiwo.de, https://www.wiwo.de/politik/konjunktur/oekonom-wirtschaftsnobelpreistraeger-ronald-coase-ist-gestorben/8731904.html. Möhring, Michael, Rainer Schmidt und Barbara Keller (2018): CRM in der Public Cloud: Praxisorientierte Grundlagen und Entscheidungsunterstützung, Springer Gabler, Wiesbaden. manager magazin (2019): Daimler und BMW bilden Allianz bei Roboterautos, erschienen in: manager-magazin.de, https://www.manager-magazin.de/unternehmen/autoindustrie/daimlerund-bmw-bilden-allianz-bei-roboterautos-und-autonomen-fahren-a-1255576.html. Nickel, Oliver (2018): Adobe, Microsoft und SAP vereinheitlichen Kundendaten, erschienen in: golem.de, https://www.golem.de/news/azure-adobe-microsoft-und-sap-teilen-ihre-kundendaten-1809-136758.html. Prahalad C.K. und Hamel G. (2006): The Core Competence of the Corporation, erschienen in: Hahn, D. und B. Taylor (Hrsg.): Strategische Unternehmungsplanung — Strategische Unternehmungsführung, S. 275 – 292, Springer, Berlin, Heidelberg. Pröve, Ralf (1995): Stehendes Heer und städtische Gesellschaft im 18. Jahrhundert: Göttingen und seine Militärbevölkerung 1713-1756, Beiträge zur Militärgeschichte Band 47, Oldenbourg, München. Putschögl, Monika (1993): Karriere eines grünen Früchtchens, erschienen in: zeit.de, https://www. zeit.de/1993/50/karriere-eines-gruenen-fruechtchens. Reinhardt, André (2019): Breitbandausbau-Historie: Festnetz von 2009 bis heute, erschienen in: teltarif.de, https://www.teltarif.de/bandbreite-festnetz-geschwindigkeit-historie/news/75604. html. Rentrop, Christopher und Stephan Zimmermann (2015): Schatten-IT, erschienen in: gi.de, https:// gi.de/informatiklexikon/schatten-it/, abgerufen im Juni 2019. Segna, Ulrich (2018): Bucheffekten: Ein rechtsvergleichender Beitrag zur Reform des deutschen Depotrechts, Mohr Siebeck, Tübingen. Schanze, Robert (2018): 5G: Wann kommt der LTE-Nachfolger? Und wie schnell ist er?, erschienen in: giga.de, https://www.giga.de/extra/5g/. Telekom (2019): DeutschlandLAN Connect IP – Das Tor zur Digitalisierung, erschienen in: geschaeftskunden.telekom.de, https://geschaeftskunden.telekom.de/startseite/festnetz-internet/ tarife/internet-telefonie/312348/deutschlandlan-connect-ip.html. Toth, Stefan (2015): Die umgekehrte Architekturbewertung, erschienen in: embarc.de, https:// www.embarc.de/netflix-architektur-blogserie-teil-1-die-umgekehrte-architekturbewertung/. Willcocks, Leslie, Mary Lacity und Andrew Craig (2015): Robot Process Automation at Xchanging, erschienen in: The Outsourcing Unit Working Research Paper Series, Paper 15/03, http:// www.xchanging.com/system/files/dedicated-downloads/robotic-process-automation.pdf, abgerufen im Juni 2019. Wile, Rob (2014): A Venture Capital Firm Just Named An Algorithm To Its Board Of Directors – Here’s What It Actually Does, erschienen in: businessinsider.com, https://www.businessinsider. com/vital-named-to-board-2014-5?IR=T. Wirtz, Bernd M. (2012): Mergers & Acquisitions Management: Strategie und Organisation von Unternehmenszusammenschlüssen, Wiesbaden.

8

Die Cloud-Transformation

Zusammenfassung

Der erste Schritt, um die Grenz- und Transaktionskosten eines Unternehmens auf das Niveau jener Konkurrenten zu senken, die bereits mit neuen Technologien arbeiten, ist die Migration der klassischen IT-Infrastruktur eines Unternehmens in die Cloud (Infrastruktur optimieren). Die Wettbewerbsfähigkeit wird zusätzlich gestärkt, wenn das Unternehmen seine Applikationen auf cloud-native Software-Architekturen umstellt und die Prozesse der Software-Entwicklung modernisiert. Im nächsten Schritt werden die Geschäftsmodelle inhaltlich verbessert (Betriebsmodell modernisieren), und zwar durch datenbasierte Analysen des tatsächlichen Kundenbedarfs. In kurzen Zyklen stellen die verantwortlichen Teams immer bessere Funktionen zur Verfügung. Für diesen Zweck können die Teams aus dem großen Portfolio fertiger Bauteile der Cloud schöpfen. Dazu gehören unter anderem Services für Machine Learning oder Internet-of-Things. Der herausforderndste Schritt ist die Veränderung des gesamten Geschäftsportfolios des Unternehmens (Portfolio transformieren). Meist passiert das unfreiwillig, wenn externe Disruptoren das Kerngeschäft bedrohen. Freiwillig ist eine Transformation dann, wenn das Unternehmen im neuen Geschäftsmodell eine besondere Chance sieht und bereit ist, die großen Transformationsrisiken einzugehen.

8.1 Wissenschaftliche Modelle zur digitalen Transformation In der Praxis der digitalen Transformation spielen drei ökonomische Modelle eine große Rolle. Im bereits diskutierten Buch „The Innovator’s Dilemma“ beschäftigt sich Clayton Christensen mit der Frage, warum gerade erfolgreiche Unternehmen immer wieder daran scheitern, neue Technologien zu adaptieren und die eigenen Geschäftsmodelle damit © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_8

225

226

8  Die Cloud-Transformation

weiterzuentwickeln (Thrasyvoulou 2014) Der zweite bedeutsame Ansatz ist das ökonomische Modell der drei Horizonte (Three Horizons of Growth) von McKinsey (Coley 2009). Es beschreibt, wie unterschiedliche Denk- und Handlungshorizonte in Unternehmen nebeneinander existieren, gleichzeitig miteinander um Ressourcen konkurrieren und doch aufeinander angewiesen sind. Geoffrey Moore schließlich greift beide Ansätze auf und zeigt Unternehmen mit dem von ihm entwickelten Modell „Zone to win“ (Moore 2015) wie die digitale Transformation gelingen kann.

8.1.1 Three Horizons of Growth von McKinsey In ihrem Buch „The Alchemy of Growth“ stellen sich die ehemaligen McKinsey-Berater Mehrdad Baghai, Stephen Coley und David White die Frage, wie Unternehmen dauerhaft und profitabel wachsen können (Baghai et al. 2000). Sie analysieren, welche Voraussetzungen für das Wachstum erfüllt sein müssen und welche Modellstrategien ein Unternehmen zum Erfolg führen können. Kern des Modells ist die Unterteilung der Planungszeiträume eines Unternehmens in drei sogenannte „Horizonte“ (s. Abb. 8.1).

Geschäswert

Horizont 1: Profitables Kerngeschäft aufrechterhalten (12–18 Monate) Mitarbeiter, Abteilungen und Prozesse von Geschäften, die dem Zeitraum des ersten Horizonts zugerechnet werden, beschäftigen sich mit der Aufrechterhaltung und Weiterentwicklung der aktuellen Geschäfte. Es geht darum, die Umsatz- und Kostenplanungen des aktuellen Monats oder Quartals zu erreichen sowie um Effizienz, Kostenreduktion und die inkrementelle Verbesserung des bewährten Geschäftsmodells. Üblicherweise lassen die Wachstumsaussichten und die Profitabilität dieses Bereichs mit der Zeit nach und die alten Geschäftsmodelle müssen durch neue ersetzt werden.

Horizont 3

Neue Geschäsideen entwickeln

Horizont 2

Mit neuen Geschäen relevant wachsen

Horizont 1

Profitables Kerngeschä aufrechterhalten

Zeit

Abb. 8.1   Three Horizons of Growth nach McKinsey und Baghai, Coley & White

8.1  Wissenschaftliche Modelle zur digitalen Transformation

227

Horizont 2: Mit neuen Geschäften relevant wachsen (18–36 Monate) Für die wirtschaftliche Zukunft sorgen die Geschäfte aus Horizont 2. Dort liegt der Fokus auf Wachstum – Prozesse und Organisation sind agil. Die Mitarbeiter verkörpern den Typ Entrepreneur und möchten möglichst schnell einen großen Anteil des wachsenden Marktes erobern. In die Geschäfte in diesem Bereich muss zu Beginn noch kräftig investiert werden. Die Aufgabe dieser Bereiche ist es, umsatzseitig stark zu wachsen und nach spätestens drei Jahren profitabel zu werden. Die Mittel werden nicht für Forschung und Entwicklung aufgewandt, sondern für Marketing, Sales und Partner-Management – also für die Skalierung des neuen Geschäftsmodells (Hill 2017). Horizont 3: Neue Geschäftsideen entwickeln (> 36 Monate) Im dritten Horizont geht es darum, mit neuen Ideen langfristige Optionen für das Unternehmen zu schaffen. Viele dieser Ideen werden zwischenzeitlich wieder verworfen, aber einige der Ideen und Konzepte können in 5 bis 12 Jahren zum neuen Fundament des Unternehmens werden. Die Mitarbeiter in diesem Bereich sind kreativ, neugierig, agil und wenig regelorientiert. Sie unterscheiden sich dadurch von den „Unternehmern“ in Horizont 2 und den „Machern“ in Horizont 1. Die Investitionsmittel für diesen Bereich sind begrenzt: Mit einem definierten Budget werden Technologien und Konzepte geprüft, verworfen oder weiterentwickelt. Zeichnet sich mit dem Einsatz der neuen Technologien und Konzepte ein neues Geschäftsmodell ab, das ein Kundenproblem löst, technisch machbar ist und sich finanziell als Wachstumsmotor eignet, wird es in Horizont 2 ­überführt. Das Modell der drei Horizonte hilft dabei, bewusste Entscheidungen zur Ressourcen- und Aufgabenverteilung zu treffen (Ryan 2018). Geoffrey Moore erläuterte dies einprägsam in seinem Vortrag auf der GOTO-Konferenz 2016 in London (Moore 2016). Er beschreibt, wie unterschiedlich die Menschen in den einzelnen Horizonten agieren und wie wichtig es für die Funktionsfähigkeit eines Unternehmens ist, dass diese Silos im Alltag mit Bedacht voneinander abgegrenzt werden. McKinsey-Autoren betonen zudem den Reflex in Organisationen, die Mittel für die Horizonte 2 und 3 zugunsten einer kurzfristigen Steigerung der Profitabilität zu kürzen. Dieser Instinkt sei nur durch intensive Aufmerksamkeit des Senior Managements – insbesondere des CEOs persönlich – überwindbar.

8.1.2 Zone to win von Geoffrey Moore In seinem Buch „Zone to Win“ beschäftigt sich Geoffrey Moore mit der Frage, wie sich Unternehmen im Zeitalter disruptiver Innovationen am besten im Wettbewerb verhalten sollten (Moore 2015). Er kombiniert dabei die Horizonte-Theorie von McKinsey mit der Dilemma-Analyse von Christensen und unterteilt das betroffene Unternehmen in eine Matrix mit vier Zonen. Auf der X-Achse unterscheidet er zwischen disruptiven und

228

8  Die Cloud-Transformation

Wirtscha lich performant

Abb. 8.2   Zone to win nach Geoffrey Moore

Disrupve Innovaon

Erhaltende Innovaon

TransformaonsZone

PerformanzZone

Unterstützend

Innovator´s Dilemma

InkubaonsZone

ProdukvitätsZone

erhaltenden Innovationen (Christensen 1997) und auf der Y-Achse zwischen wirtschaftlich performanten und unterstützenden Unternehmensbereichen (s. Abb. 8.2). Die Performanz-Zone entspricht dem Horizont 1 des McKinsey-Modells. Dort werden die meisten Umsätze erzeugt und der mit Abstand größte Teil des Gewinns. Sie wird von der Produktivitäts-Zone unterstützt, die mit nicht-disruptiven Innovationen die Produkte inkrementell verbessert und die Herstellungskosten optimiert. Als aktuelles Beispiel (Stand 2019) kann das iPhone von Apple angeführt werden: Es erzeugt in der Performanz-Zone einen Großteil des Umsatzes und Gewinns von Apple (Weddeling 2018) und wird mithilfe der Produktivitätszone (Produktentwicklung, Einkauf, IT-Abteilung) schrittweise optimiert – es erhält also größere Bildschirme, mehr Kameras und mehr ­Speicher. In der Inkubationszone wird, gemäß Horizont 3, an den Innovationen der langfristigen Zukunft getüftelt. Bei Microsoft und Google ist dies unter anderem der Quantencomputer (Krauter 2018), bei Apple das selbstfahrende Auto (Hawkins 2019). Diese Forschungsund Entwicklungsabteilungen stiften keinen direkten, wirtschaftlichen Nutzen im Sinne von Umsatzsteigerung oder Gewinn. Sie beobachten Technologien, prüfen sie, entwickeln sie weiter, testen und verwerfen sie auch wieder. Ein berühmtes und sehr erfolgreiches Beispiel eines solchen Horizont-3-Teams ist Xerox Parc (DeCarlo 2018). 1970 gegründet, war es an der Entwicklung einiger Technologien beteiligt, die heute aus dem alltäglichen Gebrauch nicht wegzudenken sind: das Ethernet, grafische Benutzeroberflächen, Laserdrucker und mobile Endgeräte mit Touchscreen. Interessanterweise profitierten andere Unternehmen als Xerox von den Erfolgen des Forschungsinstituts. So wurden die Ideen und Patente zu einer wichtigen Inspirationsquelle für Unternehmen wie Apple oder Microsoft. Xerox Parc wurde 2002 als Tochter von Xerox ausgegründet und ist bis heute Kooperationspartner von Großkonzernen und Unternehmen (Dernbach 2019).

8.2  Die drei Ebenen der Cloud-Transformation

229

Die Transformations-Zone orientiert sich an Horizont 2 des McKinsey-Modells. Dort geht es um Produkte, die in der nahen Zukunft – in einem Zeitraum von einem bis drei Jahren – relevante Umsatzzuwächse erzeugen und die Grundlage für die zukünftige S-Kurve des Unternehmens (siehe Innovator’s Dilemma in Kap. 1) bilden sollen. Geoffrey Moore spricht von einem Zielwert von 10 %, den die neuen Geschäftsbereiche am Gesamtumsatz des Unternehmens erreichen sollten. Nur wenn dieser Wert erreicht wird, würden alle Stakeholdergruppen die Ernsthaftigkeit des neuen Geschäfts erkennen und es entsprechend unterstützen (Moore 2015). Die Transformations-Zone soll gemäß dem Modell lediglich temporär existieren. Moore geht davon aus, dass Unternehmen nur in drei von zehn Geschäftsjahren tatsächlich eine solche Zone benötigen (Moore 2016). In den übrigen sieben Jahren kann es ganz ohne Transformationszone lediglich mit den anderen drei Zonen operieren. Ein bekanntes Transformationsbeispiel liefert Microsoft, das in dieser Phase von Geoffrey Moore selbst beraten wurde, mit seinen Cloud-Produkten Azure und Office 365. War der Anteil von Cloud-Leistungen am Gesamtgeschäft 2011 noch kaum messbar (Dediu 2011), machte er im zweiten Quartal 2018 schon fast ein Drittel der Umsätze aus (Protalinski 2019). Moore empfiehlt ein gezieltes Management der vier Zonen. In „guten Jahren“ sollte die Transformationszone gar nicht existieren und die übrigen drei Zonen getrennt gesteuert werden. Diese Separierung sei die effizienteste Methode, um das reguläre Geschäft eines Unternehmens profitabel zu managen. Der Preis dafür seien erhöhte Aufwände in Zeiten der Transformation, wenn diese Silos überwunden werden und zu einer wiederum profitablen Firma neu zusammengesetzt werden müssen. Hierfür sei die besondere Aufmerksamkeit des CEOs und ein gemeinsamer Kraftakt der gesamten Organisation nötig.

8.2 Die drei Ebenen der Cloud-Transformation Nicht jedes Unternehmen muss sein Geschäftsmodell vollständig umstellen, um mit den eigenen Produkten und Dienstleistungen die nächste Welle disruptiver Technologien zu nutzen. Es kann beispielsweise auch ausreichen, „nur“ die eigenen Infrastruktur- und Betriebsmodelle auf die neuen Technologien umzustellen. Um diese Aussage zu erläutern, unterscheidet Geoffrey Moore drei unterschiedliche Szenarien (s. Abb. 8.3): In Szenario 1 ist nur die Infrastruktur des Unternehmens betroffen. In Szenario 2 wird das Betriebsmodell des Unternehmens transformiert. In Szenario 3 ist das gesamte Geschäftsmodell vom Wandel betroffen. Sind Produktion, Produkt und Vertrieb in einem Geschäftsmodell vollständig digitalisierbar, dann tritt Szenario 3 in Kraft. Dann wird der gesamte Markt disruptiert und das Unternehmen muss komplett neue Märkte und Geschäfte finden und betreten. Dies ist bei weitem die aufwendigste und risikoreichste Art der Transformation. Hier ist die Cloud-Transformation nur ein relativ kleiner Teil der Herausforderung. Vergleichbar mit Microsoft muss sich das Unternehmen neu erfinden (Nadella et al. 2017).

230

8  Die Cloud-Transformation

SaaS Machine Learning Internet of Things Data Analycs Cloud Social Media

Neue Märkte und Webewerbsvorteile

Betriebsmodell

Produkvität und Effekvität

Porolio der Geschäsmodelle transformieren

Beispiel: Vom Betriebssystem-Hersteller zum Cloud-Anbieter

Wertschöpfung modernisieren

Beispiel: Mit einer Mobile-App das Taxi einfacher bestellen

Mobile

Serverless PaaS

Geschäsmodell

IaaS

Infrastrukturmodell Effizienz und Preis/Leistung

Back-End-Systeme opmieren

Beispiel: SAP-System in die Cloud migrieren

Abb. 8.3   Ebenen der Disruption nach Geoffrey Moore

Bleibt das Geschäftsmodell im Zusammenspiel mit Kunden, Lieferanten und der Organisation weitgehend stabil, muss lediglich das Infrastrukturmodell umgestellt werden (Szenario 2). Dies betrifft die IT-Abteilung in fast allen Bereichen und ist dementsprechend mit großen Änderungen verbunden, während diese in den anderen Teilbereichen oder in der Organisation des Unternehmens ausbleiben. Ein Beispiel für einen Infrastrukturwandel ist die Data Center Migration, wie sie TUI auf dem AWS-Summit 2019 in Berlin ankündigte. Dies geht einher mit dem allgemeinen Trend, dass große Unternehmen Anzahl und Umfang ihrer Rechenzentren reduzieren (Hushon 2018; Braddy 2018). Helfen die cloudbasierten Technologien, ein Geschäftsmodell qualitativ zu verbessern, ohne es zu zerstören, dann handelt es sich um eine Veränderung des Betriebsmodells. Data Analytics kann zu besseren Geschäftsentscheidungen führen, Machine Learning kann aus standardisierten Massendienstleistungen individuelle Services erzeugen. Die Nutzung mobiler Endgeräte kann Services besser erreichbar oder einfacher nutzbar machen. Das Cloud-Strategie-Team als Wegbereiter der Transformation In der Vorbereitung der Cloud-Transformation sind einige Überlegungen anzustellen, um das Umsetzungsprojekt erfolgversprechend auszurichten (s. Abb. 8.4). Ziel der digitalen Transformation auf allen drei Ebenen ist es, manuelle oder teilautomatisierte Tätigkeiten auf vollautomatisierte IT umzustellen. Gleichzeitig wird diese Transformation zum „Mittel zum Zweck“, denn sie soll neue Geschäftsmodelle möglich machen. Aufgaben, die vorher einzelne Menschen oder Teams erbracht haben, werden jetzt durch Software abgebildet. Diese Änderung kann dazu führen, dass einzelne Rollen überflüssig werden – meist sind aber ganze Teams mit ihren Prozessen, Vorgehensmodellen und mit ihrer Organisation betroffen. Nur wenn diese Änderungen auch umgesetzt werden, stiftet Cloud tatsächlich Nutzen. Wird Cloud stattdessen eingeführt, ohne die alten Prozesse und Funktionen abzulösen, steigt die Komplexität des Gesamtsystems und damit steigen auch dessen Kosten (Moore 2016).

231

8.2  Die drei Ebenen der Cloud-Transformation

Scope besmmen

Passende Führungsebene idenfizieren

Zentrales, interdisziplinäres Team etablieren

Anfassbare Prototypen erzeugen Au
rag konkresieren

Geschä
smodell

CEO

Transformaon Lead

Experimeneren

Betriebsmodell

CxO

Enterprise-Architekten

Transformaon erfahrbar machen

Infrastrukturmodell

CIO

Fachexperten

Stakeholder mitnehmen

Cloud-SoluonArchitekten

Engagement erzeugen

Kommunikaonsexperten „Company Skills“

Abb. 8.4   Vorbereitungsphase der Cloud-Transformation

Werden Rollen, Teams, Prozesse, Teile der Organisation und Altsysteme überflüssig und können diese nicht parallel zum neuen Vorgehen weitergeführt werden, handelt es sich um eine umfassende, unternehmerische Veränderung. Die hierfür notwendigen Entscheidungen können in der Regel nicht demokratisch herbeigeführt oder konsensual mit allen Stakeholdern getroffen werden. Die Führung eines solchen Projekts muss bei jenen Führungskräften verortet sein, die das Veränderungsmandat für alle betroffenen Bereiche haben. Handelt es sich um eine Transformation des Infrastrukturmodells, kann also der CIO ausreichend sein. Wenn die Änderungen größere Teile der Organisation betreffen, sollte ein entsprechend höhergestellter Manager mit der Aufgabe betraut ­werden. Genau hier liegt das Problem: Die verantwortliche Führungskraft hat meistens selbst weder das notwendige technologische und methodologische Sachwissen, noch kann sie genug Zeit aufbringen, um sich selbst einzuarbeiten. Daher braucht sie als Unterstützung ein direkt an sie berichtendes, interdisziplinäres Team, das die notwendigen Entscheidungen vorbereitet, die beteiligten Manager schult, die Ergebnisse im Unternehmen vermittelt und die Umsetzung der getroffenen Entscheidungen vorantreibt. Dieses Cloud-Strategie-Team sollte in sich alle für die Transformation relevanten Skills vereinen. Essenziell für den Erfolg ist ein erfahrener Enterprise-Architekt. Dieser versteht gleichermaßen die Geschäftswelt und die Welt der Informationstechnologie, er kann die gegenseitigen Abhängigkeiten beschreiben, funktionsfähige Gesamtlösungen gemeinsam mit weniger vielseitigen Stakeholdern erarbeiten und die Umsetzung vorantreiben. Sollte diese Position im Unternehmen nicht besetzt sein, muss das Team versuchen, diese Rolle in Arbeitsteilung zu übernehmen. Weiterhin notwendig sind Business Professionals, also Experten aus dem Tagesgeschäft, die sich idealerweise sowohl mit dem bestehenden Geschäftsmodell als auch mit dem neuen Geschäftsmodell auskennen. Die Cloud-Solution-Architects des Teams entwerfen die konkreten Lösungen für die neue Cloud-IT. Davon gibt es, im Vergleich zum Enterprise-Architekten, mehr Vertreter, da sie weniger Business-Know-how und Erfahrung brauchen.

232

8  Die Cloud-Transformation

Eine nicht zu unterschätzende Relevanz haben die Kommunikationsexperten: Nach innen gibt es einen großen Bedarf an Change-Kommunikation und internem Recruiting, nach außen geht es vor allem um die glaubwürdige Neupositionierung der Leistungen bei den Kunden. Zu guter Letzt sind die sogenannten „Company Skills“ nicht zu vergessen, also das Wissen um die spezifische Kultur des Unternehmens, die Fallstricke in den Prozessen, die persönlichen Eigenheiten besonders relevanter Führungskräfte und die informellen Entscheidungsprozesse. Satya Nadella konnte bei der Transformation von Microsoft nicht zuletzt deswegen so schnell Erfolge erzielen, weil er den Konzern als Insider seit mehr als 22 Jahren in unterschiedlichen Funktionen und Bereichen mit seinen Stärken und Schwächen kennt (Kurtuy 2019). Sobald das Cloud-Strategie-Team in seinen Grundzügen steht, kann es damit beginnen, funktionierende Prototypen zu entwickeln. Geht es zum Beispiel um neue Geschäftsmodelle, sollte zuerst nachgewiesen werden, ob die Kundenbeziehungen rund um diese neuen Produkte und Dienstleistungen auch wirklich funktionieren. Geht es um die Migration von Infrastruktur, sollten erste Applikationen erfolgreich in die Cloud migriert worden sein. Diese Prototypen demonstrieren die Vorteile der neuen Welt. Anhand konkreter Projekte und Erfolge lassen sich auch skeptische Kollegen meist besser überzeugen als durch theoretische Erläuterungen und PowerPoint-Präsentationen. Abb. 8.5 verdeutlicht noch einmal, wie relevant die organisatorische Einbindung des Cloud-Strategie-Teams ist: • Infrastrukturmodell umstellen: Die Transformation der IT-Infrastruktur in Cloud-Technologien und -Methoden wird alle Teams, Prozesse und Skills in der bestehenden IT-Organisation betreffen und eine Reorganisation notwendig machen. Das Team sollte an den Manager berichten, der alle IT-Bereiche verantwortet. • Betriebsmodell umstellen: Wird das Betriebsmodell durch Cloud-Technologien optimiert, geht es in der Regel um das effektive Zusammenspiel von IT- und fachlichen

CEO

Strategie-Team (GM) Bei Umstellung des Geschäsmodells

CIO

CxO

Strategie-Team (IM)

Strategie-Team (BM)

Bei Umstellung des Infrastrukturmodells

…

Bei Umstellung des Betriebsmodells

…

Applikaonen

Infrastruktur

Change (IM)

Projekte

… Change (BM)

…

…

…

…

…

Change (GM)

Abb. 8.5   Cloud-Strategie-Team: Organisatorische Aufhängung und voraussichtlicher Scope des Changes je Ebene

8.3  Das Infrastrukturmodell umstellen

233

Skills. Die Führung sollte beim Fachverantwortlichen für das zu modernisierende Geschäft liegen. Zu beachten ist, dass aller Voraussicht nach IT-Mitarbeiter in die Fachabteilung wechseln oder neu eingestellt werden und relevantes IT-Know-how in dieser Abteilung aufgebaut wird. Dies sollte dem entsprechenden CxO klar sein, CEO und CIO müssen einen adäquaten Change unterstützen. • Geschäftsmodell umstellen: Muss sich das Unternehmen in seiner Gesamtheit den disruptiven Technologien stellen, wird das Strategie-Team beim CEO angesiedelt sein. Ist das Cloud-Strategie-Team mit den notwendigen Ressourcen etabliert und wurde ihm ein entsprechender Auftrag erteilt, kann es seine Arbeit aufnehmen. In den folgenden drei Abschnitten werden die dafür empfohlenen Vorgehensmodelle je nach Ausgangssituation beschrieben.

8.3 Das Infrastrukturmodell umstellen Die Applikation ist der Dreh- und Angelpunkt der Cloud-Transformation. Sie erzeugt den Geschäftsnutzen für ihre Anwender, und dieser soll nach Möglichkeit erhalten bleiben. Ausgetauscht werden die zugrundeliegende Infrastruktur sowie möglicherweise die dazugehörige Middleware wie Datenbanken und Betriebssysteme. Zunächst werden die grundlegenden Migrationsoptionen je Applikation beschrieben und nach ihren wichtigsten Unterschieden eingeordnet. Danach werden die vier Schritte (s. Abb. 8.6) einer Umstellung des Infrastrukturmodells im Detail erläutert.

8.3.1 Die typischen Migrations-Szenarien für Applikationen Im Detail sieht jede Migration einer Applikation in die Cloud unterschiedlich aus. Dennoch lassen sich bestimmte Typen von Migrationen identifizieren. Das grundlegende Konzept hierzu lieferte Gartner im Jahr 2010 mit seinem „5R-Modell“ (SA Technologies 2018):

Planen

Die bestehende Applikaonslandscha analysieren und die benögten Commitments einholen.

Auauen

Die neue cloud-basierte Landscha vorbereiten und Governance- und Compliance-Fragen klären.

Migrieren

Die eigentliche Migraon je Applikaon testen und durchführen.

Weiterentwickeln

Die Applikaons-Landscha weiterentwickeln und Compliance & Governance aktuell halten.

Abb. 8.6   Die vier Schritte der Cloud Transformation im Infrastrukturmodell

234

8  Die Cloud-Transformation

Rehost Anwendung Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung

Refactor Revise Rebuild

Replace

Manuelle Tägkeiten involviert.

Rechenleistung

Automasierte IT-Wertschöpfung

Speicher Netzwerk

Virtualized

IaaS

PaaS

SaaS

Abb. 8.7   Die 5R nach Gartner: Migrationsszenarien von Applikationen

Diese Migrationsszenarien lassen sich im Hinblick auf Abschn. 4.4.4 folgendermaßen erklären (s. Abb. 8.7): • Rehost ist die Migration einer Applikation aus der klassischen IT (Dedicated oder Virtualized) auf eine Cloud-Infrastruktur (IaaS). Die Applikation bleibt weitgehend unangetastet, nur Netzwerk, Speicher und Rechenkapazität werden durch Cloud-IT ausgetauscht. Der Aufwand ist gering, der direkte Nutzen ist vorhanden, aber nicht disruptiv. Viele SAP-Applikationen etwa können nur auf diese Weise migriert werden, weil der Anbieter keinen Eingriff in die Architektur der Anwendung ermöglicht. • Replace ist die vollständige Ablösung einer Applikation durch einen cloudbasierten Software-Service (SaaS). Der Nutzen ist oft sehr groß, da das outsourcende Unternehmen auf sämtliche eigenen IT-Ressourcen verzichten kann. Genutzt wird dieses Modell häufig in Anwendungsbereichen, die sich branchenübergreifend ähneln. Beispiele hierfür sind die Ablösung der unternehmensinternen E-Mail-Server oder von Bürosoftware durch Office365. • Bei Refactor und Revise wird die Architektur der Applikation verändert. Je nach individuellem Bedarf des Geschäftsmodells werden die Platform Services der Cloud genutzt, um dem Cloud-Native-Ideal (Abschn. 6.5.3) einer skalierenden, elastischen und verteilten Applikation zu genügen. Beispielhaft wurde das Vorgehen in Kap. 5 beschrieben. Revise führt zu mehr Änderungen als Refactor. Gerade Spezialanwendungen, die das Unternehmen angepasst auf seine Prozesse geschrieben hat, bieten sich für diese Migrationsmodelle an. Hier hat das Unternehmen die Gestaltungsfreiheit bei der Architektur der Anwendung, und die speziell auf die Prozesse angepasste Software ist relevant genug, um einen aufwendigen Umbau zu rechtfertigen.

8.3  Das Infrastrukturmodell umstellen

235

• Bei einem Rebuild wird die Applikation mit identischem Geschäftsnutzen basierend auf den cloud-nativen Technologien neu aufgebaut. Das kann sinnvoll sein, wenn die alte Anwendung nicht gut dokumentiert ist oder auf derart alten Technologien basiert, dass der Neuaufbau einfacher ist. Der in Abschn. 4.4.4 beschriebene Katalog der IT-Fertigteile senkt die Kosten für eine Neuentwicklung signifikant. Angelehnt an die 5R von Gartner hat Amazon Web Service (AWS) ein eigenes Modell entwickelt, die sogenannten „6R“ (Orban 2016). Die sechs Migrationsstrategien heißen: • • • • • •

Rehosting entspricht dem Rehost Replattforming entspricht dem Refactor Repurchasing entspricht dem Replace Refactoring entspricht dem Revise Retire: Die Applikation wird abgeschafft. Retain: Die Anwendung verbleibt auf der angestammten Infrastruktur.

8.3.2 Planen – Applikationen analysieren und Commitments einholen Im eBook „Enterprise Cloud Strategy“ geben Barry Briggs und Eduardo Kassner einen Einblick in die Cloud-Transformation von Microsoft selbst (Briggs und Kassner 2017). In einem ersten großen Schritt analysierte das Cloud-Strategie-Team die vielen Applikationen des Unternehmens und ordnete sie den einzelnen Migrationsszenarien zu. Abb. 8.8 illustriert dieses Vorgehen. Das Unternehmen konnte durch die Umsetzung des ersten Schrittes auf 30 % seiner Applikationen verzichten, da deren Funktionen von anderen Systemen übernommen oder gar nicht genutzt wurden. Software-Services wie Office365 oder Sharepoint Online konnten 15 % der Applikationen komplett ersetzen. Lediglich 5 % der Applikationen waren nicht sinnvoll in die Cloud migrierbar, wobei Microsoft dafür keine genaueren Begründungen anführt. Die übrigen 50 % der Applikationen wurden entweder 1:1 in die Cloud überführt (Rehost), neu gebaut (Rebuild) oder mehr (Revise) oder weniger (Refactor) für die Nutzung von Platform-Services (PaaS) optimiert. Letzteres ist einfach und wirkungsvoll für Web-Applikationen oder Applikationen mit anderen, modernen Architekturen. Bei Microsoft betraf dies etwa 35 % aller Anwendungen. Die übrigen 20 % verteilten sich auf geschäftskritische Applikationen wie ERP-Systeme (15 %) und Hochverfügbarkeits-Systeme sowie Anwendungen mit Public-Key-Infrastruktur (5 %). Eine weitere wichtige Erkenntnis: Unternehmen sollten nicht alle Applikationen gleichzeitig migrieren. Ein solcher Big Bang ist in der Regel nicht möglich, da zu wenige Mitarbeiter mit den notwendigen Schlüsselkompetenzen verfügbar sind und die Gesamtorganisation mit einem solchen Projekt überfordert wäre. Stattdessen sollte eine

236

8  Die Cloud-Transformation

30%

Rere

15%

Replace

Office 365

Sharepoint Online

CRM Online

Visual Studio Online

Azure Data Lake

3rd Party SaaS

Rehost 50%

Refactor Revise

Rebuild 5%

Remain

35%

Erster Schri Webapplikaonen, Portale und Applikaonen mit modernen Architekturen

10%

Zweiter Schri Applikaonen mit sehr hoher Geschäsrelevanz sowie viel Input-/Output-Traffic

5%

Spätere Schrie HVA- und PKI-Systeme sowie Applikaonen mit Legacy Source Control

Anteil der Applikaonen

Abb. 8.8   Analyse der Applikationslandschaft vor einer Cloud-Migration nach Microsoft

sinnvolle Reihenfolge für die Migrationsschritte festgelegt werden (Briggs und Kassner 2017). Jede Anwendung, die für eine Migration infrage kommt, wird auf folgende Faktoren untersucht: • Performance-Anforderungen des Workloads bzgl. Elastizität, Skalierung, Ressourcen-Intensität, Latenz und Datendurchsatz • Finanzielle Rahmenbedingungen, Ist-Kosten und Geschäftsnutzen • Architektur der Applikation hinsichtlich User Interface, der Applikation selbst, der Daten und der Infrastruktur • Risikobewertung bezogen auf die Organisation insgesamt, auf ihre Geschäftsmodelle sowie auf Technologie, Ressourcen und Verträge • Operative Betriebsthemen • Security- und Compliance-Themen wie Datenschutz, Verschlüsselung und Regulierung An dieser Stelle kann das interdisziplinäre Cloud-Strategie-Team seine Stärken ausspielen. Für die Performance-Anforderungen wie die finanziellen Rahmenbedingungen und die Bewertung des Geschäftsnutzens werden Kollegen gebraucht, die sich mit dem Geschäftsmodell auskennen, das der Applikation zugrunde liegt. Um hingegen die Architektur zu bewerten und die Auswirkungen auf die Betriebsthemen abzuschätzen, ist die Expertise technischer Kollegen gefragt. Um Risiken zu bewerten sowie Security und Compliance-Herausforderungen abzuschätzen, sind technische und kaufmännische Ressourcen sowie ein fundiertes Wissen über die Spezifika des Unternehmens notwendig („Company Skills“). Wurden mehrere Applikationen dem Bewertungsprozess unterzogen, lässt sich eine einfache Matrix nach den Kriterien „Nutzen der Migration“ (X-Achse) und „Schwierigkeit der Migration“ (Y-Achse) erstellen (s. Abb. 8.9). Zwar wird das Vorgehen hier linear dargestellt, doch in der Praxis können die Analyse und die Umsetzungsphase parallel ablaufen. Sobald die grundlegenden Governance- und Compliance-Themen geklärt sind und der Nutzen der Übertragung der Applikation in die Cloud geklärt ist, kann mit der Migration begonnen werden.

8.3  Das Infrastrukturmodell umstellen

237 Applikaonsporolio

Applikaonsanalyse

Migraonstyp

Individuelle Evaluaon je Applikaon (Workload)

Empfehlung eines Migraons-Typs

• Architektur • Risiken • Betrieb

Rere Replace Rehost Refactor

• Security

Revise

• Compliance

Rebuild Remain

Nutzen der Migraon

• Finanzen

niedrig

LangzeitWeen

Hier starten

Zuletzt angehen

Quick-Wins

niedrig

• Performance

Aufwand der Migraon

hoch

hoch

Abb. 8.9   Evaluation und Priorisierung der Applikationslandschaft nach Briggs/Kassner

In der Planungsphase wird – neben der Analyse und Priorisierung der Applikationslandschaft – auch die Führungsebene des Unternehmens abgeholt. Jede zu migrierende Applikation muss vor dem Go-Live von den Anwendern getestet werden. Zum richtigen Zeitpunkt müssen diese Anwender natürlich genügend Zeit für die Tests aufwenden können, daher müssen bei der Migrationsplanung etwa saisonale Besonderheiten berücksichtigt werden (zum Beispiel Jahres- oder Quartalsabschluss oder die Weihnachtssaison). Was sollte außerdem noch beachtet werden? • Auswahl des Dienstleisters: Die meisten IT-Abteilungen können eine solche Transformation nicht ohne externe Hilfe durchführen. Der Dienstleister sollte schon in der Planungsphase einbezogen werden. • Wirtschaftliche Planung: Eine Cloud-Transformation verändert die Kostenstrukturen (Kap. 5). Kurzfristig entstehen Mehraufwände (Projektaufwände, Ausbildung, OPEX, Primärprozesse), während an anderen Stellen Einsparungen möglich sind (Data Center, CAPEX, Steuerung, Sekundärprozesse). Die Finanzplanung des Unternehmens sollte an die geänderten Rahmenbedingungen angepasst werden. • Recruiting und Ausbildung: Nach der Cloud-Transformation benötigen Unternehmen andere Fähigkeiten und anderes Wissen als vor der Transformation. Die entsprechenden Weiterbildungsprogramme und Rekrutierungsinitiativen sollten intern frühzeitig angestoßen werden. Abb. 8.10 stellt schematisch dar, wie sich die benötigten Mitarbeiterprofile je nach Migrationstyp unterscheiden. Bei einem Remain werden weiterhin die Mitarbeiter für den klassischen Betrieb und Projektleiter für die Durchführung von Änderungen benötigt. Eine Anwendung stillzulegen (Retire) ist in der Regel nicht auf Knopfdruck möglich. Dazu müssen fachliche Experten (Business Professionals) befragt und einige Prozesse so verändert werden,

238

8  Die Cloud-Transformation Remain

Rere

Replace

Rehost

Refactor

Revise

Rebuild

Classic Operaons Projektleiter Fachexperte

Cloud-Soluon-Architekt Sowareentwickler Cloud Operaons

Scrum Master, Product Owner Annahme: Evaluaon von Nutzen/Aufwand der Migraon ist bereits erfolgt.

Abb. 8.10   Benötigte Skills je Migrations-Typ

dass andere Applikationen die verbleibenden Funktionen der abgeschalteten Software übernehmen können. Für diese Projekte werden häufig Projektleiter gebraucht. Replace bedeutet das vollständige Outsourcen einer Anwendung. Hier kommt es wieder auf die Fachverantwortlichen an, die das Überführungsprojekt inhaltlich leiten müssen, damit die Geschäftsanforderungen tatsächlich von den externen Software-Services abgedeckt werden. Ein Rehost benötigt neue Ressourcentypen, wie etwa den Cloud-Solution-Architect und Cloud Operations für die Infrastrukturebene (IaaS). Für die darüberliegenden Datenbanken und Betriebssysteme werden aber weiterhin klassische Betriebsexperten benötigt. Von Refactor über Revise bis Rebuild nimmt die Bedeutung der klassischen Rollen immer stärker ab. Bei Rebuild werden zusätzlich Entwickler benötigt, denn in der Regel entsteht ein agil erstelltes Softwareprodukt. Für diesen Fall werden zusätzlich auch Scrum Master und Product Owner benötigt werden.

8.3.3 Aufbauen – Die neue Landschaft vorbereiten Die Cloud bietet eine riesige Menge an IT-Fertigteilen, die schnell und unkompliziert mit wenig Know-how bestellt werden können. Diese Einfachheit hat den Nachteil, dass Organisationen auch schnell den Überblick verlieren können. Was passiert, wenn viele Ressourcen für eine kurze, intensive Massendatenverarbeitung hoch-, aber nicht wieder heruntergefahren werden? Welche Abteilung übernimmt welche Kosten für welche Applikation? Weltweite Skalierung ist gut und schön, aber soll ein Video millionenfach in den USA herunterladbar sein, wenn das Unternehmen dort gar keine Produkte ­verkauft? Cloud-Ressourcen administrierbar machen Um den Überblick zu behalten, bieten die Cloud-Provider umfassende Möglichkeiten, um die Organisationsstruktur eines Unternehmens mit in der Cloud-Landschaft abzubilden. Dafür werden Firmenkonten (Accounts) eröffnet, innerhalb dessen mit Abonnements (Subscriptions) und Schlagworten (Tags) auch komplizierte Leistungsbeziehungen

8.3  Das Infrastrukturmodell umstellen

239

abgebildet werden können. Es können feingranular Verbräuche zugeordnet, getrackt und mit Regeln versehen werden. Cloud-Provider und Partner helfen Anfängern dabei, die richtigen Einstellungen von Beginn an zu treffen. Diese zusätzliche Arbeit sollten Unternehmen immer miteinplanen, um Risiken in der Umsetzung und im Betrieb zu vermeiden. Landschaft vorbereiten Relevante Core Services der Provider können pro Subscription oder auch übergreifend genutzt werden. Dazu gehören: • • • • •

Netzwerk (Software Defined Network) Management der Nutzer-Identitäten (Identity Management) Verschlüsselung von Daten (Encryption) Reporting (Log & Report) Verwendete Software-Werkzeuge (Toolchain)

Diese Vorbereitung der Landschaft auf den späteren Gebrauch hat viele Auswirkungen auf die tatsächliche Sicherheit der Systeme. Es wird festgelegt, welche Netzwerke in welchem Grad voneinander abgeschottet sind, wer mit welchen Identitäten auf welche Bereiche des Unternehmens Zugriff hat und wie Verschlüsselungsmechanismen genutzt werden. Governance und Compliance herstellen Für die Begriffe Governance und Compliance gibt es keine einheitliche oder gesetzliche Definition. Daher ist es umso schwerer, beide Begriffe mit dem Blick auf die Cloud-Transformation voneinander abzugrenzen (Siriu 2018). Im Kern geht es bei Compliance darum sicherzustellen, dass das Unternehmen den internen Regularien sowie externen Gesetzen und Vorschriften folgt. Governance folgt der Sichtweise der Eigentümer, um sicherzustellen, dass sich das Unternehmen in ihrem Sinne sicher und erfolgreich weiterentwickelt. Die Cloud-Provider haben diesbezüglich komplexe Frameworks entwickelt, an denen sich die Transformationsverantwortlichen orientieren können. Abb. 8.11 zeigt eine vereinfachte Version des GRC-Programms (Governance, Risk, Compliance) von AWS (South 2018). Jedes Cloud-Projekt kann scheitern, wenn die GRC-Themen vorab nicht sachgemäß berücksichtigt wurden. Es empfiehlt sich, die bestehenden Compliance-Prozesse des Unternehmens aktiv zu nutzen, um die notwendigen Freigaben für das Cloud-Projekt zu erhalten. Agieren die Kolleginnen und Kollegen aus den Compliance-Abteilungen projektverhindernd skeptisch, empfiehlt es sich, externe Unterstützung einzuholen. Die Cloud-Provider halten für solche Fälle ausreichend Informationsmaterial vor und vermitteln gerne den Austausch mit anderen Unternehmen. Ein Gespräch zwischen GRC-Verantwortlichen verschiedener Unternehmen kann in einer solchen Situation sehr hilfreich sein.

240

8  Die Cloud-Transformation

Governance

Risk

Compliance

Gesetze & Regulierung

Assessment

Automasches Monitoring

Standards

Risikobewusste Entscheidungen

Selbst-Evaluaonen

Interne Richtlinien

Individualverträge

Verantwortungsvolle Mitarbeiter

Sichere Systeme

Risk Management Framework

Konnuierliche Verbesserung

Resiliente Organisaon

Externe Audits Reporng

Steuerungselemente Konnuierliche Compliance

Abb. 8.11   Framework für Governance, Risk und Compliance nach Michael South (AWS) vereinfacht und übersetzt

Im Aufsatz „Governance und Compliance im Cloud Computing“ geben Khaled Bagban und Ricardo Nebot von der Otto GmbH folgende konkreten Empfehlungen (Bagban und Nebot 2016): • Zertifizierte Provider: Nur nach ISO 27001 zertifizierte Cloud-Anbieter nutzen.1 • Verschlüsselung: Alle unternehmenskritischen Daten sollen verschlüsselt in die Cloud übertragen und dort gespeichert werden. • Datensparsamkeit: Es sollen so viele Daten wie nötig und so wenige wie möglich in die Cloud übertragen werden. Die Übertragung sollte immer einem konkreten Zweck dienen. • Datenrückholung: Vor der Migration soll es ein geplantes Vorgehen zur Datenrückholung geben. • Notfallkonzept: Die Cloud-Lösungen sollen jeweils ein Notfallkonzept für Infrastruktur-Ausfälle oder verloren gegangene Daten erhalten. • Information: Die betroffenen Stakeholdergruppen sollen vor der Cloud-Migration informiert werden. • Zugriff: Beim Zugriff auf die Cloud-Services sollen sichere Browser und Endgeräte genutzt werden. • Analyse und Planung: Bei großen oder komplexen Vorhaben soll ordentlich analysiert und geplant werden.

1Stand

März 2019 sind alle drei großen Provider – Google, AWS und Azure – nach ISO27001 zertifiziert.

8.3  Das Infrastrukturmodell umstellen

241

Die Vorschläge stammen aus dem Jahr 2014, sie sind also im digitalen Zeitalter vergleichsweise alt. Mark Ryland von AWS argumentiert, dass Daten in der Public Cloud faktisch sicherer aufgehoben seien, da sich Kunde und Cloud-Provider die Sicherheitsaufgaben teilen (Ryland 2018). Der Provider könne seine Infrastruktur mit viel mehr Aufwand absichern als die meisten Kunden ihre eigenen Rechenzentren. Kunden könnten zudem ihre Applikation in der Public Cloud wesentlich einfacher und professioneller schützen. Bei dieser durchaus nachvollziehbaren Argumentation stellt sich die Frage, ob die Daten im eigenen Rechenzentrum wirklich besser gesichert sind. Zusammenfassend lässt sich feststellen, dass sich GRC-Anforderungen mit der Cloud grundsätzlich abbilden lassen (siehe dazu auch Abschn. 4.7). Diese Fragen sollten aber je Einzelfall im Planungsprozess und vor der eigentlichen Migration geklärt werden.

8.3.4 Migrationen durchführen Der Aufwand der technischen Migration hat in den vergangenen Jahren stark abgenommen. AWS bietet seine Cloud-Dienste seit 2006 an, Microsoft Azure und Google Cloud seit 2010/2011. Cloud-Provider wie Migrationsdienstleister sind dem Experimentierstadium entwachsen, der Gartner-Quadrant für „Public Cloud Professional and Managed Services“ verzeichnet weltweit viele Unternehmen mit entsprechenden Kompetenzen (Rackspace 2019). Für Deutschland gibt es analog dazu Auswertungen des Beratungsunternehmens CRISP Research für Managed Public Cloud Services mit kleineren und lokalen Anbietern (Nordcloud 2018). Die technischen Herausforderungen der Migration sind demnach aus aktueller Perspektive gut plan- und testbar. Microsoft schlägt in seinem Cloud Adoption Framework einen Management-Circle aus „Architektur erstellen“, „Änderungen umsetzen“, „Tests durchführen“ und „Live schalten“ vor (Microsoft Azure 2019). Abb. 8.12 enthält dazu weitere Details. Aus den noch zu migrierenden Applikationen des Backlogs wird eine Applikation ausgewählt, die dann die folgenden Schritte durchläuft: • Assess: Die Anwendung wird im Detail auf die verwendeten Ressourcen (virtuelle Maschinen, Daten, Netzwerk, Berechtigungen) hin analysiert. • Architect: Der Cloud-Solution-Architect analysiert Abhängigkeiten und entwirft die neue Cloud-Architektur der Applikation. • Remediate: Je nach Migrationstyp sind mehr oder weniger Änderungen an der Applikation notwendig, wie zum Beispiel Änderungen am Netzwerk-Design, am Betriebssystem oder an den genutzten Services. • Replicate: Die Applikation wird in der Cloud repliziert, dies kann manuell oder durch existierende Tools erfolgen. • Stage: Die Applikation wird in einer möglichst realitätsnahen Umgebung zum Testen bereitgestellt.

242

8  Die Cloud-Transformation

Migriert

im Test

Applikaonsporolio

In Arbeit

To do

Migraon Backlog

Hier starten

Assess Promote Finalize Adopt Test

Architect Remediate Replicate Stage

Migraon & Tests

Abb. 8.12   Vorgehen zur Applikations-Migration nach Microsoft

• Tests: Die Nutzer testen die Applikation hinsichtlich Performanz und Vollständigkeit und bereiten sich auf die neue Cloud-Umgebung vor. • Adopt: Falls notwendig, werden die Endnutzer auf Änderungen und eine mögliche Übergangsphase vorbereitet. • Finalize: Die letzten Änderungen, wie etwa die Ergebnisse der User-Tests, werden in die Applikation eingepflegt. • Promote: Die Applikation wird live geschaltet, die ungenutzten Altressourcen werden abgebaut.

8.3.5 Weiterentwickeln – Die Landschaft aktuell halten und sichern AWS benennt in seinem Cloud Adoption Framework vier Reifegrade der Cloud-Adoption (Orban 2016): Project, Foundation, Migration und Reinvention. Etwas Eigenwerbung ist darin enthalten, schließlich hat der Cloud Provider kein Interesse daran, dass die Cloud-Projekte mit der Migration enden. Im Kern aber entspricht es den Tatsachen moderner Cloud-Applikationen, dass sie immer weiterentwickelt werden. Auf den wichtigsten Grund wird im nächsten Abschnitt näher eingegangen: Der Wettbewerb zwingt Unternehmen dazu, immer schneller immer mehr neue Funktionen in ihren Geschäftsmodellen aufzunehmen – und dies verlangt entsprechende Veränderungen an der Applikation.

243

8.3  Das Infrastrukturmodell umstellen

Planen Auauen Migrieren

Weiterentwickeln

Applikaonen evaluieren und priorisieren Subscripons & Tagging einstellen

Architektur erstellen

Applikaon technisch & inhaltlich weiterentwickeln

Führungsebene mitnehmen

Wirtschaliche Rahmenbedingungen festlegen

Recruing und Ausbildung angehen

Landscha vorbereiten Network

Identy

Encrypon

Cloud-bezogene Änderungen durchführen

Log & Report

Governance & Compliance herstellen

Toolchain

User-Tests durchführen

Live bringen

Governance & Compliance for…ühren IT-Ressourcen- und Konfiguraons-Management

Kosten-Management

Sicherheits- und IdentätsManagement

Abb. 8.13   Durchführung der Cloud-Transformation im Infrastrukturmodell

Aber auch ohne inhaltliche Veränderungen gibt es ständig Handlungsbedarf in der IT-Landschaft. Die Cloud Provider bieten ständig neue Services an, die vormals optimal erscheinende Architekturen schon nach kürzester Zeit veralten lassen. So hat AWS allein im Jahr 2014 ganze 516 Innovationen auf den Markt gebracht, Microsoft brachte es 2016 ebenfalls auf über 500 Innovationen (Lorusso 2016). Dazu kann es Veränderungen bei internen Compliance-Richtlinien und externen Anforderungen wie Gesetzen und Regulierungen geben. Die folgenden Bereiche sollten regelmäßig überwacht und weiterentwickelt werden: • Cost Management: Die Kosten der Anwendungen überwachen und die Infrastrukturen entsprechend der tatsächlichen Bedarfe anpassen. • Security Management: Die Sicherheitsmaßnahmen aktuell halten und weiterentwickeln, um Netzwerk, Assets und Daten zu schützen sowie Sicherheitsvorfälle bearbeiten und lösen. • Resource Management: Den Zustand der Assets wie Server und Datenbanken im Blick behalten und an die aktuellen Anforderungen anpassen. • Identity Management: Die Nutzerkonten managen, bereichs- und firmenübergreifend Nutzer-Identitäten managen und überwachen. • Configuration Management: Die Assets bereitstellen, updaten und optimieren. Abb. 8.13 zeigt in einem Überblick die Herausforderungen und Aufgaben bei einer Data Center Migration.

8.3.6 Zusammenfassung – Cloud und moderne Software-Ansätze Das Infrastrukturmodell eines Unternehmens mithilfe disruptiver Technologien zu modernisieren bedeutet zunächst, Cloud als automatisierte IT in möglichst vielen Applikationen auf möglichst hoher Virtualisierungsebene zu nutzen (s. Abb. 8.14). Die Herausforderung einer solchen Umstellung ist es, eine effiziente wirtschaftliche

244

8  Die Cloud-Transformation Container Cloud Nave Cloud Serverless

PaaS

IaaS

Mobile

… in die Cloud … Vom klassischen Data Center …

Microservices Automated Distributed

Rest API

Elasc DevOps Isolated State Loosely Coupled

… mit modernen So wareArchitekturen und Ansätzen.

Abb. 8.14   Infrastrukturmodell umstellen – die grundlegenden Schritte der Cloud-Transformation

Abwägung von Kosten und Nutzen für die gesamte IT-Landschaft, aber auch für jede einzelne Applikation zu treffen. Eine Abschaffung des klassischen Rechenzentrums lohnt sich meist nur dann, wenn ohnehin größere Investitionen in das Rechenzentrum anstehen. Eine Umstellung der Applikationen in Richtung Cloud-Native-Architekturen (Refactor, Revise, Rebuild) ist teurer als eine 1:1-Migration der bestehenden Applikation auf Cloud-Infrastrukturen (Rehost). Letztere kann je nach Anwendungsszenario wiederum mehr Nutzen stiften. Ungeachtet der Einzelfall-Entscheidungen je Applikation sollte sich das Unternehmen darüber im Klaren sein, dass mit dem Austausch der klassischen IT durch Cloud die IT-Infrastruktur zur Software wird. Somit nimmt auch die Relevanz von Software im Unternehmen insgesamt zu. Mitarbeiter müssen lernen, wie Software entworfen und entwickelt wird und wie sich Prozesse und Vorgehensmodelle von jenen in der Welt der manuellen IT unterscheiden (siehe dazu Kap. 6).

8.4 Das Betriebsmodell umstellen Moore spricht bei der Umstellung des Betriebsmodells von einer Modernisierung der Wertschöpfung, ohne das Geschäftsmodell selbst infrage zu stellen. Er nennt dabei das Beispiel eines Bostoner Taxi-Unternehmens, das – im Gegensatz zu Uber – weiterhin Taxis besitzen und Fahrer anstellen möchte, aber sich durch die wachsende Konkurrenz gezwungen sieht, seine Wertschöpfungsprozesse- und -systeme („Systems of Engagement“) zu modernisieren (Moore 2016). Das Unternehmen könnte etwa durch eine Mobile-App die Bestellprozesse für die Kunden vereinfachen und ihnen durch eine Taxi-Nachverfolgung auf dem Bildschirm einen besseren Service bieten. Zudem könnte das Unternehmen auf diese Weise die Zahl der Call-Center-Mitarbeiter reduzieren und möglicherweise sogar mit weniger Taxis mehr Kunden transportieren.

245

8.4  Das Betriebsmodell umstellen Durch die Umstellung des Infrastrukturmodells werden die Grundlagen für mehr Funkonen, Skalierbarkeit und Flexibilität geschaffen.

Vom eigenen Data Center

In die Cloud & zu Cloud Nave

5R

mit moderner Soware

Betriebsmodell InfrastrukturModell

Wie kann man die Potenale der Cloud im Geschäsmodell am besten nutzen?

Abb. 8.15   Nutzung der Cloud zur Verbesserung der Geschäftsmodelle

Beispiele dafür, wie kundenorientierte Applikationen Geschäftsmodelle verschlanken und die Kundenerfahrung besser gestalten können, gibt es inzwischen viele: Lagerbestände einsehen, per App bezahlen, Empfehlungen geben, Bestellprozesse nachverfolgen, Lebensmittel online bestellen, Weine im Laden fotografieren und Bewertungen erhalten, einfach und verständlich eine Steuererklärung abgeben und direkt Feedback erhalten – viele Anwendungen existieren bereits. Darüber hinaus kann aber noch viel weiteres Potenzial gehoben werden. In Abschn.  4.4 wurde ausführlich darüber gesprochen, wie mit Hilfe von Cloud-Technologien und modernen Software-Ansätzen die IT-Infrastruktur von der tatsächlichen Hardware entkoppelt wird. Dieser Abschnitt beschreibt nun, wie das Unternehmen die dadurch entstehenden Potenziale am besten für seine bestehenden Geschäftsmodelle nutzen kann (s. Abb. 8.15).

8.4.1 Fokus auf geschäftsrelevante Applikationen Welche Potenziale für die schnelle Entwicklung neuer Funktionen, Skalierbarkeit und Flexibilität entstehen, hängt vom genutzten Migrationstyp ab. Als Daumenregel gilt: Je höher der Anteil der automatisierten IT an der gesamten IT-Wertschöpfung ist, desto größer sind die Nutzenpotenziale. Abb. 8.16 zeigt schematisch den Zusammenhang zwischen dem Grad der Automatisierung der IT und den Chancen für das Geschäftsmodell. Bei Retire wird die Applikation abgeschafft. Sie erzeugt somit keinen Nutzen mehr für das Geschäftsmodell. Bei Remain bleibt die Applikation in ihrer originalen Form bestehen und unterstützt weiterhin die laufenden Geschäfte. Die Nachteile klassischer IT (siehe Kap. 4) bleiben weiterhin vollständig bestehen. Bei Replace wird ein Software-Service (SaaS) aus der Cloud genutzt. Dies senkt meistens die Kosten deutlich und lässt das Unternehmen sofort von den angebotenen Features profitieren. Der hohe Standardisierungsgrad dieser Services beschränkt die Nutzung meistens auf generische Anwendungsbereiche wie Office365 für Bürosoftware, Slack für Team-Kollaboration oder Concur für die Reisekostenabrechnung. Einen Wettbewerbsvorteil können Unternehmen selten auf diese Weise erreichen, nicht zuletzt, weil auch alle Wettbewerber auf die gleichen Angebote zurückgreifen können. Bei Rehost wird die Applikation unver-

246

8  Die Cloud-Transformation Migra onstyp

Wie wurde das Infrastrukturmodell migriert?

Re re

Auswirkung auf Applika on

Chancen für das Geschäsmodell

Die Applikaon … … exisert nicht mehr

Replace

… wird durch einen für alle nutzbaren Soware-Service ersetzt

We‚bewerber haben den gleichen Zugang zum Service mit den gleichen Vorteilen.

Rehost

.. bleibt unverändert, ihre Infrastruktur wird automasiert

Veränderungen an der Soware sind weiterhin sehr teuer

Refactor Revise

… nutzt die Vorteile der automa sierten IT (Cloud Na ve)

Rebuild Remain

• • • •

Schneller neue Features entwickeln Wenig Risiko bei Misserfolg Globale Skalierung bei Erfolg Fak sch Null-Grenzkosten je Neukunde

Basiert weiterhin voll auf klassischer IT

Abb. 8.16   Migrationstyp und Chancen für das Geschäftsmodell

ändert auf eine automatisierte Infrastruktur (IaaS) migriert. Unternehmen können somit auf den unteren Ebenen der IT-Wertschöpfung von der Cloud profitieren. Meist wird dies für Applikationen genutzt, deren Architektur nicht von einem einzelnen Unternehmen verändert werden kann (Beispiel: SAP ERP). Kosten können hauptsächlich dadurch gespart werden, dass die Anwendung nachts heruntergefahren wird und Test- und Entwicklungssysteme nur auf Nachfrage zur Verfügung gestellt werden. Änderungen an der Funktionalität und somit am Geschäftsmodell sind bei Rehost aber ähnlich aufwendig wie bei klassischen Systemen. Die drei Migrationstypen, welche die Applikation so verändern, dass diese die Vorteile der Cloud nativ nutzen kann (Cloud Native) sind Refactor, Revise und Rebuild. Die Anwendung kann sich aus dem großen Katalog der IT-Fertigteile bedienen, eine globale Skalierung ist einfach möglich, die Abrechnung erfolgt in kleinen Einheiten und nur bei tatsächlicher Nutzung. Diese Vorteile spielen besonders dann eine Rolle, wenn a. das Geschäftsmodell starken Lastschwankungen unterliegt, b. eine globale Skalierbarkeit relevant ist, c. schnell neue Features ausprobiert und entwickelt werden sollen oder d. Teile der Anwendung selten genutzt werden. Abb. 8.17 zeigt, wie Migrationstypen, Migrationsaufwände und Nutzen einer Migration zusammenhängen. Dabei muss berücksichtigt werden, dass die Darstellung die Zusammenhänge vereinfacht aufzeigt. In der Praxis sind die Migrationstypen nicht immer klar voneinander zu unterscheiden.

247

8.4  Das Betriebsmodell umstellen Migraonsaufwände

Nutzen Resilienter Umgang mit Ausfällen Schnell und kundenorienert neue Features entwickeln Lastschwankungen in einzelnen Applikaonsteilen individuell abfedern

Hohe Migraonsaufwände lohnen sich nur für besmmte Applikaonen und Geschäsmodelle

Global skalieren Nutzen entsteht je Applikaon, unabhängig von einer Data-Center-Migraon.

Ganze Applikaonen an-/abschalten oder „rightsizen“ Mitarbeiter auf Primärprozesse fokussieren

Tri ein, wenn vorher noch ein eigenes Data Center betrieben wurde.

CAPEX in OPEX verwandeln Rehost

Refactor

Revise

Rebuild

Migraonstypen

Abb. 8.17   Migrationsaufwände und Nutzenfaktoren

Die wesentlichen Vorteile einer Rechenzentrumsmigration in die Cloud bestehen darin, dass die Kapitalbindung auf die Betriebskosten reduziert wird und dass Mitarbeiter von Supportprozessen befreit werden und sich auf direkt wertschöpfende Tätigkeiten im Primärprozess fokussieren können. Um von dieser Möglichkeit zu profitieren, muss in beiden Fällen das eigene klassische Rechenzentrum aufgegeben werden. Wurde die klassische IT bereits vorher an einen Lieferanten ausgelagert, können diese Potenziale auch dort gehoben werden. Ganze Applikationen flexibel an- und abschaltbar zu machen und auf diese Weise Kosten zu sparen und die Systemleistung zu verbessern, ist ein Nutzen, den die Cloud in der Regel immer erzeugt. Ähnlich funktioniert das sogenannte „Rightsizing“. Dabei wird das tatsächliche Lastverhalten einer Applikation analysiert und überdimensionierte Systeme auf das richtige Maß reduziert. Auch die globale Skalierbarkeit einer Anwendung ist in der Regel schon bei einem Rehost mit wenig Aufwand möglich. Die drei darüber hinausgehenden Nutzenfaktoren sind meist nur mit einem deutlich höheren Entwicklungsaufwand erzeugbar. Lastschwankungen in Applikationsteilen Um Lastschwankungen in einzelnen Applikationsteilen individuell abfedern zu können, wird die Anwendung in voneinander entkoppelte Bereiche (Microservices) geteilt (Kap. 6). Beispielsweise kann auf diese Weise die Benutzeroberfläche von der Steuerung der Supply-Chain im Hintergrund getrennt werden. Gibt es dann eine erhöhte Nachfrage nach der Benutzeroberfläche, wird lediglich die Rechenkapazität für genau diesen Service aufgestockt. Die Supply-Chain-Kalkulation im Back-End wird durch den Nutzeransturm im Front-End nicht negativ beeinträchtigt. Zusätzliche Kosten entstehen so nur an einer Stelle im System.

248

8  Die Cloud-Transformation

8.4.2 Resilienter Umgang mit Fehlern Applikationen, die nicht aus mehreren Microservices bestehen, sondern ein geschlossenes Gebilde mit vielen Abhängigkeiten darstellen, werden Monolithen genannt (Kap. 6). Fällt bei einer monolithischen Software eine Komponente aus, so ist die gesamte Software nicht mehr nutzbar. Wird eine Komponente überplanmäßig beansprucht, verlangsamt dieser Engpass häufig die gesamte Anwendung. Der klassische Umgang mit diesem Problem ist, die Verfügbarkeit und Ressourcenlage jeder einzelnen Komponente des Systems zu verbessern. Dies führt gemäß den Schilderungen in Kap. und dem Beispiel in Kap. 6 zu immer höheren fixen Kosten und zu einem zunehmend restriktiven Umgang mit Änderungen. Anschaulich vergleichen lässt sich dies mit dem Management von potenziellen Waldbränden in der Umgebung einer Stadt: Die klassische IT versucht, die Wahrscheinlichkeit eines Waldbrands zu reduzieren, indem weniger Besucher zugelassen werden (weniger Änderungen) und für den Fall des Waldbrands mehr Löschflugzeuge bereitgehalten werden (mehr Infrastruktur-Ressourcen). Die Cloud-Native-IT dagegen versucht, die Systeme voneinander unabhängig zu bauen (damit nicht alle Häuser gleichzeitig brennen) und sie möglichst schnell wiederaufzubauen (damit niemand die Ergebnisse des Waldbrands bemerkt). Diese Ansätze nennen sich „designed for failure“. Anstatt Fehler zu vermeiden, wird das Fehler-Management verbessert. Unternehmen wie Netflix gehen sogar soweit, einen „Chaos Monkey“ einzuführen: Dabei werden gezielt Abstürze von Komponenten hervorgerufen, um zu prüfen, ob die darauf basierenden Systeme ausreichend resilient reagieren (Grüner 2016). Schnell neue Features entwickeln Wird eine Applikation nach den Prinzipien von Cloud Native (Kap. 6) verändert (Revise) oder neu aufgebaut (Rebuild) werden die Entwicklungsprozesse deutlich schneller und kostengünstiger. CRISP Research geht in einer Studie für Arvato Systems davon aus, dass auf hohen Abstraktionsebenen der Cloud (PaaS und Serverless) Features um 70 % schneller und 80 % günstiger entwickelt werden können als in der klassischen IT (Schumacher 2018). Diese Verbesserungen lassen sich nicht allein durch die Nutzung der Cloud erzeugen. Der Schlüssel für die Schaffung dieser Effizienzvorteile ist die Einführung der in Kap. 6 geschilderten Software-Methoden und Vorgehensweisen. Wann sich eine Cloud-Native-Transformation lohnt Den größten Nutzen bieten Cloud-Technologien, wenn eine Umstellung der Applikation auf die Cloud-Native-Prinzipien erfolgt (Kap. 4). Dann allerdings entstehen auch die größten Kosten für die Migration der Anwendung. Ein teures Rebuild oder Revise ergibt also nur dann Sinn, wenn es für das Geschäftsmodell tatsächlich nützlich ist, schnell neue Features zu entwickeln, fehlerresilient zu sein und Lastschwankungen innerhalb der Applikation individuell managen zu können. Kein Unternehmen wird in seinem

Strategisch / dauerhaft Operativ / einmalig

Nutzen einer Migration

8.4  Das Betriebsmodell umstellen

249

unwahrscheinlich Modernisierung der Schlüssel-Applikaonen für das Kerngeschä

Anwendungsgebiet für Cloud Nave Transformaon

Umstellung auf branchenübergreifende Soware-Services Applikaonen an-/abschalten und Ressourcen „Rightsizen“

Fehlinvesonen

Niedrig

Hoch

Kosten einer Migraon Abb. 8.18   Kosten versus Nutzen einer Cloud-Migration

Überleben gefährdet, weil Microsoft nicht schnell genug neue Features in seine Bürosoftware implementiert hat. Auch niedrigere Infrastrukturkosten durch die Möglichkeit, Testsysteme flexibel abschalten zu können, werden ein Unternehmen strategisch kaum weiterbringen. Relevanter sind die Vorteile von Cloud Native, wenn die Wettbewerbsfähigkeit des eigenen Unternehmens von eben jener Applikation abhängt (s. Abb. 8.18). Ein Glücksspielunternehmen möchte immer online sein, der Lieferdienst hat stark schwankenden Traffic je nach Tageszeit, und das Unternehmen für Musik-Streaming möchte ständig bessere Funktionen in seiner App liefern als seine Wettbewerber. Die Nachteile klassischer IT mit ihren langen Entwicklungszyklen und hohen Grenzkosten bei der Skalierung würden diese Unternehmen früher oder später in eine signifikant schlechtere Wettbewerbsposition bringen.

8.4.3 Kundenfokus und Datenanalyse Die Modernisierung der Schlüsselapplikationen für das Kerngeschäft steht im Mittelpunkt dieses Abschnitts. Entscheidend für den Unternehmenserfolg ist es, wie gut diese Schlüsselapplikationen die Kundenbedarfe in der Benutzeroberfläche berücksichtigen und wie wirksam die Software die Kundennachfrage insgesamt in ein funktionierendes Geschäftsmodell übersetzt (s. Abb. 8.19). Die drei großen Cloud Provider betonen das Thema „Kundenfokus“ konsequent. Amazon etwa listet an erster Stelle seiner Führungsprinzipien (Amazon 2019): „Customer Obsession – 100 % kundenorientiert.“ Google schreibt auf seiner Webseite: „Customer Focus as the key to digitalization“ (Merks-Ben-

250

8  Die Cloud-Transformation

Individuum

Betriebsmodell Infrastrukturmodell

Kontext

Fokus auf den Kunden Kerngeschäsanwendung wird Cloud Nave

Konsequenter Fokus auf den Kunden und seine Daten Abb. 8.19   Konsequenter Fokus auf den Kunden

jaminsen 2017). Satya Nadella, der CEO von Microsoft, formuliert es so (Weinberger 2015): „We no longer talk about the lagging indicators of success, […], which is revenue, profit. What are the leading indicators of success? Customer love.“ Was meinen die Provider, wenn sie von Kundenfokus sprechen? In der klassischen IT gab es in Unternehmen noch viele Sekundärprozesse – also Mitarbeiter, die nicht direkt für den externen Kunden arbeiteten, sondern ihren Kollegen zuarbeiteten. Die Cloud automatisiert die IT und führt zu mehr Outsourcing. Dave Hahn beschreibt in seinem Vortrag auf den DevOpsDays Rockies 2016 eindrücklich, wie Netflix seine eigenen Rechenzentren abgeschafft hat und nun, dank der Nutzung der externen Cloud-Partner Akamai und AWS, mit weniger als hundert Mitarbeitern im IT-Betrieb mehrere Milliarden Videostunden pro Quartal an 81 Mio. Kunden ausliefert (Hahn 2018). Unternehmen können also ihre Mitarbeiter auf die primäre Wertschöpfung fokussieren – hierfür beschäftigt Netflix über 500 Entwickler (Stand 2016). Dave Hahn beschreibt, wie dies bei Netflix aussieht (Kap. 2): keine Schätzungen, kein Bauchgefühl, keine Tradition, sondern „We focus on data“. Die Feature-Teams fokussieren sich auf den Kunden, vor allem auf dessen Daten. Zach Bulygo beschreibt in einem Blogbeitrag, wie Netflix seine Kunden kennenlernt (Bulygo 2013): Wie viele der 130 Mio. Kunden beginnen, sich die Serie „Arrested Development“ anzuschauen? Wie viele sehen sich eine Folge bis zum Ende an? Wohin sind jene Nutzer gewechselt, die sich die Serie nicht zu Ende angesehen haben? Wie lange dauerte es, bis sich der Konsument die nächste Folge der gleichen Serie angeschaut hat? Weitere Daten werden hinzugezogen: Wann

8.4  Das Betriebsmodell umstellen

251

wurde pausiert, zurückgespult und nach vorne gesprungen? An welchen Tagen wurde geschaut und um welche Uhrzeit? Wo und auf welchem Endgerät wurde gestreamt? Was wurde gesucht? Wie wurde in der Suche gescrollt? Es gibt auch Statistiken darüber, unter welchen Umständen Kunden kündigen: 95 % der Kunden verlassen Netflix, wenn sie weniger als fünf Stunden pro Monat konsumieren. Kunden auf diese Weise quantitativ zu analysieren, ist der Weg der Wahl in der digitalen Transformation: Die Daten spiegeln das tatsächliche Verhalten des Kunden deutlich akkurater wider als die Selbstaussagen von Menschen in Interviews. Die Kundendaten können also in den verschiedenen Apps oder Benutzeroberflächen gesammelt werden, in denen der Nutzer aktiv ist. Darauf basierend kann dessen tatsächliches Verhalten herangezogen werden, um die Benutzeroberfläche zu verbessern oder ihm andere Inhalte zu zeigen. Darüber hinaus können Unternehmen Kontextdaten wie etwa Twitter-Trends oder regionale Informationen zu Wetter und Staus einbeziehen, um relevanter für den Kunden zu werden: In der Fachterminologie wird das als „Engagement erhöhen“ und „Customer Experience verbessern“ bezeichnet.

8.4.4 Machine Learning und künstliche Intelligenz Die Menge der Daten, die bereits heute von Unternehmen erhoben werden können, übersteigt schnell die Vorstellungs- und Steuerungskraft von Menschen. Nehmen wir an, die Anwendung hat 10.000 Nutzer weltweit und relevante Einflussfaktoren auf das „User Engagement“ sind das Land, Uhrzeit, Wetter, Art und Inhalt lokaler Veranstaltungen, Religion sowie Beziehungsstatus des Nutzers. Wie können alle Abhängigkeiten zwischen allen Faktoren und ihren Ausprägungen von Menschen erkannt, als Software entwickelt und weltweit aktuell gehalten werden? Selbst wenn dies grundsätzlich möglich ist, würde es doch die Kernvorteile solcher Cloud-Lösungen gefährden: schnelle Skalierbarkeit bei Null-Grenzkosten. Die Lösung liegt in den sogenannten „Systems of Intelligence“. Das von Ravi Kalakota genutzte Modell (Kalakota 2015) wird in Abb. 8.20 dargestellt. Die historischen Systeme basieren auf klassischen IT-Architekturen. Sie können nur in langen Zyklen mit viel Aufwand verändert werden, der Trend geht hier lediglich zum Rehost in die Cloud. Die kundenorientierten Systeme basieren häufiger auf CloudNative-Technologien – weitergehende Services wie Mobile, Social Media und IoT einzubauen ist einfacher und schneller. Es werden deutlich mehr Daten produziert, die zur Optimierung der Kundenorientierung genutzt werden können. Um die großen Datenmengen für eine weitere Verbesserung der Geschäftsmodelle nutzen zu können, wird Data Science im Zusammenspiel mit Machine Learning eingesetzt. Die Public Cloud ist auch hier der Schlüssel für den Aufbau der „Systems of Intelligence“ für viele Unternehmen. Cloud Provider wie Google, Microsoft, AWS und IBM haben in den letzten Jahren ein großes Angebot an Platform-Services (PaaS) für Machine

252

8  Die Cloud-Transformation

Systems of Intelligence

Trend

Data Science, Machine Learning

Beispiele: Markeng, Sales, Kundenservice

Trend

Mobile, Social, Cloud Nave

Beispiele: ERP, CRM, HR, SCM

Trend

Cloud, IaaS, Container

Erkenntnisbasierte Systeme

Systems of Engagement Kundenorienerte Systeme

Systems of Record Historische Systeme

Ebenen der Unternehmensanwendungen Nach Rava Kalakota

Abb. 8.20   Ebenen der Unternehmensanwendungen nach Rava Kalakota

Learning (ML) aufgebaut. Meist gehören diese zur Kategorie „Narrow AI“ und können bestimmte Aufgabenstellungen lösen: • • • • • • •

Sprache in Text umwandeln Text in Sprache umwandeln Gegenstände auf Bildern erkennen Gesichter und gezeigte Emotionen erkennen Sprachsyntax erkennen Sprache übersetzen Text-Dialoge führen (Chatbots)

Alle diese Services sind ohne großen Aufwand über eine API ansprechbar und können kostengünstig im Pay-per-Use-Modell ohne eigene Investitionen genutzt werden. Mit etwas Kompetenz in Software-Entwicklung können Unternehmen daraus eigene intelligente Anwendungen erstellen. Kunden sind dabei nicht darauf angewiesen, die vordefinierten ML-Algorithmen zu nutzen – sie können auch eigene Modelle erstellen. Hierfür bieten die Public Cloud Provider Frameworks wie Tensorflow (von Google, inzwischen OpenSource; siehe Geißler und Litzel 2018) oder Sagemaker (AWS). Auf diese Weise können Unternehmen individualisiert auf ihre Bedürfnisse Machine Learning Modelle entwickeln, beispielsweise Modelle zur Erkennung von Hautkrebs oder Genanalysen in der Medizintechnik.

8.4.5 Menschen und Kultur Die Nutzung der Public Cloud und moderner Architekturen hat einen großen Einfluss darauf, wie schnell neue Features eines digitalen Geschäftsmodells entwickelt werden

8.4  Das Betriebsmodell umstellen

253

und welche Qualität sie haben. Mindestens ebenbürtig in ihrer Wirkung sind menschliche Faktoren, wie die Zusammensetzung eines Teams und die Kultur einer Organisation. Interdisziplinäre und agile Feature-Teams Möchte das Unternehmen seine Geschäftsmodelle mithilfe disruptiver Technologien verbessern, ist interdisziplinäres und agiles Arbeiten eine wichtige Voraussetzung. In Kap. 6 wurde auf das Thema DevOps und Feature-Teams schon einmal im Detail eingegangen, an dieser Stelle wird die Idee anhand eines Beispiels konkretisiert. Gut zusammengesetzt sind die sogenannten „Feature-Teams“, wenn in ihnen alle Fähigkeiten vertreten sind, die einen Service Ende-zu-Ende erfolgreich machen können. Dazu gehören insbesondere das Verständnis für den Markt und die Kunden, Architekturfertigkeiten für die Cloud- und Software-Entwicklung sowie Kompetenzen in der Entwicklung und im Betrieb. Teams mit zehn oder weniger Mitgliedern können dank der vielen Fertigteile in der Cloud, deren Automatisierungsfähigkeiten und durch das Outsourcing der sekundären IT-Prozesse große Applikationen betreuen und weiterentwickeln. Abb. 8.21 zeigt die Zusammensetzung eines solchen Feature-Teams für den beispielhaften Service „Hassbotschaften erkennen“, der beispielsweise von einem Webseitenbetreiber im Kommentarbereich genutzt werden kann. Die Vielzahl der involvierten Professionen zeigt eindrücklich, wie sich die Arbeit in Teams durch die digitale Transformation verändert. Einige wenige Software-Entwickler könnten den Service zwar problemlos in ihrem Silo entwickeln, sie wüssten allerdings kaum, wie man Sprache analysiert, um Hass darin zu erkennen. Sie benötigen politische und historische Kontext-Informationen, um Hassbotschaften mit einer höheren Wahrscheinlichkeit als solche zu erkennen. Hierfür ist eine Integration von Sprachwissenschaftlern und Lektoren in das Team notwendig. Machine-Learning-Spezialisten wissen, wie leistungsfähig die aktuellen Modelle sind und wie man sie baut, verbessert und trainiert. Data Scientists helfen bei der Datenanalyse und -bereinigung, Software-Architekten sorgen für die Skalierbarkeit, Performanz und Wirtschaftlichkeit des Gesamtsystems. Erwartet wird, dass Änderungen schnell implementiert werden: ein weiterer Terroranschlag oder ein Tweet eines Präsidenten – schon verändert sich der Inhalt von Hassbotschaften. Auf solche Entwicklungen sollte der Service vorbereitet sein. Wären Lektoren in einem eigenständigen Lektoren-Team, die Data Scientists unter sich und die Software-Entwickler gar in einer ganz anderen Firma angestellt, würden das Tempo und die Qualität des Service leiden – ohne erkennbare, positive Effekte an anderer Stelle. Die wesentlichen Optimierungspotentiale und -effekte werden nicht dadurch erreicht, dass die Auslastung von Software-Entwicklern oder Fachexperten nach oben geschraubt wird. In der softwaredefinierten IT liegt der große wirtschaftliche Nutzen in der Kombination des datenbasierten Verstehens der Kundenbedürfnisse und der technologiebasierten Erstellung skalierbarer Lösungen. Sind beide Voraussetzungen erfüllt, skaliert der Service dank der zur Verfügung stehenden Technologien weltweit nach Belieben.

254

8  Die Cloud-Transformation

API Feature-Team mit 10 Mitarbeitern für den beispielha en Service:

„Hassbotschaen erkennen“

Ständige Verbesserungen in kurzen Zyklen

Lektor, Linguist, Historiker Polikwissenscha ler Machine-Learning-Spezialist/ Data Scienst, So wareArchitekt So ware-Entwickler mit und ohne Betriebsfokus API

API

Infrastruktur (IaaS)

API

API

Datenbanken

Daten

Weitere Services

Abb. 8.21   Feature-Team für „Hassbotschaften erkennen“ – beispielhafte Zusammensetzung eines Teams

Kultur als Misserfolgsfaktor Ein schwieriges, aber gleichzeitig wichtiges Thema bei der Modernisierung des Geschäftsmodells mithilfe disruptiver Technologie ist die Unternehmenskultur. Schwierig deshalb, weil es schwer zu greifen und aktiv zu managen ist; wichtig, weil es wie kaum ein anderes Thema Einfluss auf die Umsetzung der Strategie hat. Die Bedeutung der Unternehmenskultur wurde bereits in Kap. 6 herausgearbeitet. Laut Gerhard Schewe ist Unternehmenskultur ein „System geteilter Muster des Denkens, Fühlens und Handels sowie der sie vermittelnden Normen, Werte und Symbole innerhalb einer Organisation“ (Schewe 2018). Eine Strategie ist zunächst einmal nur eine PowerPoint-Präsentation – wie soll sich diese gegen das seit Jahren geteilte Fühlen und Handeln vieler Menschen in einer Organisation durchsetzen? Im Konkreten geht es – bezogen auf die Unternehmenskultur – bei der Modernisierung des Geschäftsmodells meist um die folgenden Themen: • Zusammenarbeit von Entwicklern und Systemadministratoren: Entwickler und Administratoren (Operations) arbeiten in der klassischen IT in getrennten Abteilungen mit stark unterschiedlichen Zielsystemen. Entwickler entwickeln neue

8.4  Das Betriebsmodell umstellen

•

•

•

•

255

Software-Funktionen, möchten immer die neuesten Tools nutzen und ihr Projekt schnell abschließen. Administratoren sind für die Verfügbarkeit eines Systems verantwortlich und sorgen sich bei jeder Änderung um die Sicherheit und Stabilität einer Applikation. Unter dem neuen DevOps-Dogma müssen die Operations-Kollegen das Entwickeln von Software lernen, die Software-Entwickler dagegen müssen lernen, auch Verantwortung für die Stabilität und Sicherheit ihres Codes zu übernehmen. Umgang der Entwickler mit Kunden: Sowohl Entwickler als auch Administratoren werden in der klassischen IT-Organisation durch die Projektleiter und Kundenmanager weitestgehend vom Kunden abgeschirmt. Im Cloud-Zeitalter sollen sie aber „customer-focused“ sein – sie sollen den Kunden also kennenlernen und sich mit seinen Interessen und Anforderungen auseinandersetzen. Dies ist fachlich wie sozial mitunter eine Herausforderung. Denken in Automatisierung und Datenanalyse bei Fachexperten: Fachlichen Experten ohne IT-Hintergrund fällt es häufig schwer, wenn sie gemeinsam mit IT-Experten eine Software für einen Prozess entwickeln sollen, den sie bis jetzt selbst händisch durchgeführt haben. Einerseits ist es für sie keine angenehme Vorstellung, dass ihr Job durch IT-Applikationen abgelöst wird. Andererseits glauben sie auch nicht immer, dass eine solche Umstellung überhaupt möglich ist. Eigene Services anderen zugänglich machen: Viele Menschen, unabhängig von ihrer Profession und ihrem Ausbildungsgrad, teilen die Ergebnisse ihrer Arbeit ungerne. Sie freuen sich darüber, gefragt zu werden, wenn es um ihr jeweiliges Spezialthema geht. Stellen sie ihr Wissen aber über eine API zur Verfügung, werden sie nicht mehr gefragt – die Programmierschnittstelle übernimmt ihre Funktion. Sind sie im Urlaub oder verlassen sie gar das Unternehmen, gibt es keinerlei Einbußen in der Servicequalität. Dass ihre Produktivität enorm steigt, wenn ihre Leistung mit einer Software weltweit skalierbar wird, und dass der ökonomische Wert eines Mitarbeiters eng mit dessen Produktivität zusammenhängt, ist für viele Kolleginnen und Kollegen ein unbekanntes Konzept. Auf Services anderer aufbauen: Ein weiteres Phänomen betrieblicher Tätigkeit ist das „Not-Invented-Here-Syndrom“ (Möhrle und Specht 2018; Gairing und Weckmüller 2019). Mitarbeiter lehnen es ab, die Entwicklungen externer Partner oder anderer Teams im selben Unternehmen zu nutzen – entweder weil sie diese nicht suchen und damit auch nicht kennenlernen, oder weil sie der Qualität nicht trauen. Sie wissen ja schließlich nicht im Detail, wie diese Entwicklungen funktionieren. Die Cloud-Transformation basiert aber gerade auf der Idee, die Services der anderen zu nutzen, ohne zu wissen, wie diese hinter der API funktionieren.

Auch Führungskräfte sind von der kulturellen Transformation betroffen: • Software-Erstellung als primärer Geschäftsprozess: Das Entwickeln von Software tritt in den Vordergrund und wird zum primären Geschäftsprozess. In Zeiten von Uber ist es für ein Taxi-Unternehmen möglicherweise wichtiger, eine gut f­unktionierende

256

•

•

•

•

8  Die Cloud-Transformation

App mit schnellem Dispositionsmanagement als wirklich alle Fahrzeuge zu besitzen. Ein Software-Unternehmen zu sein aber birgt eigene Herausforderungen. Führungskräfte müssen lernen, Software-Architekturen zu bewerten, sie müssen neue Jobfamilien einführen und den Software-Entwicklern umfassende Rechte gewähren, damit sie die notwendigen Soft- und Hardware-Tools nutzen können. Agiles Denken: Als Software-Unternehmen zu handeln bedeutet auch, agil zu denken und zu handeln. In Abschn. 6.6.1 wird auf die Vorteile des agilen Vorgehens im digitalen Kontext gesondert eingegangen. Den verantwortlichen Teams Entscheidungsfreiheit überlassen: Ein wichtiges Element der DevOps ist die Gesamtverantwortung des Teams für sein Produkt (Abschn. 6.6.4). Dieser Verantwortung können die Teams aber nur nachkommen, wenn sie sich für alle Entscheidungen die Freigabe übergeordneter Hierarchieebenen abholen müssen. Unternehmen können somit die volle Kraft der DevOps erst nutzen, wenn sie diesen ausreichend Freiraum für eigene Entscheidungen geben. Inspirieren statt steuern: Wie aber sollen Führungskräfte auf die unabhängigen Teams Einfluss nehmen? Es gibt viele Vorschläge aus der Welt der Tech-Berater. Simon Sinek schlägt vor, „das Warum“ eines Unternehmens zu klären und auf dieser Basis zu führen (Sinek 2011). Andy Grove hat bei Intel das OKR-Modell entwickelt, von Google wurde es etwa 20 Jahre später aufgenommen. Das Modell fokussiert sich neben den wirtschaftlichen Resultaten auch auf die Einbeziehung der Mitarbeiter und die Herstellung von hierarchieübergreifender Transparenz. Im Trend liegt auch „New Work“, ein Konzept, das den Freiraum für die persönliche Entfaltung der Mitarbeiter betont (Haufe Akademie 2019). Jedem Manager steht es frei, diese Ansätze skeptisch zu betrachten. In seine Bewertung einbeziehen sollte er dabei folgende Überlegungen: Die Schlüsselmitarbeiter der Cloud-Transformation – die Cloud-Solution-Architects – sind eine begehrte Ressource am Arbeitsmarkt, und die Mitarbeiter in diesem Bereich sind sich ihrer Verhandlungsposition durchaus bewusst. Denn wenn es ihnen gelingt, erfolgreich einen global skalierenden Cloud-Service zu entwickeln, erreichen sie damit ein Verhältnis von Wertschöpfung zu Arbeitszeit, das in der klassischen Service- oder Fertigungsindustrie kaum vorstellbar ist. Zusammenarbeit vorleben: Einer der wichtigsten Faktoren ist die Zusammenarbeit innerhalb der Teams, zwischen den Teams innerhalb des Unternehmens und nach außen mit Partnern, Kunden und Lieferanten. In Kap. 7 wurde von Wertschöpfungsnetzwerken gesprochen, die dank der niedrigen Transaktionskosten entstehen. Mitarbeiter beobachten sehr genau, wie ihre Vorgesetzten mit anderen Vorgesetzen zusammenarbeiten. Sie haben einen guten Blick dafür, wie ernst die berechtigten Interessen von Partnern und Kunden im Unternehmen genommen werden. Zusammenarbeit muss daher vorgelebt werden – vom CEO über die Top-Manager bis zu den Stäben und den mittleren Führungskräften.

Unternehmen, die eine kulturelle Transformation und agiles Arbeiten systematisch angehen möchten, finden am Markt zahlreiche Anbieter, die Hilfestellungen bei diesen

8.4  Das Betriebsmodell umstellen

257

Vorhaben leisten. Sehr spannend und aufschlussreich kann insbesondere eine quantitative Kulturanalyse sein. Das Unternehmen Human Synergistics etwa analysiert Unternehmenskulturen nach 12 Kriterien von Wettbewerbsorientierung über Perfektionismus bis hin zur Ausweichverhalten und Sicherheitsorientierung (Schwitter et al. 2007). Das Unternehmen misst mit Hilfe von Fragebögen die genannten Faktoren und vergleicht sie mit den über 10.000 anderen Unternehmen die insgesamt über 2 Mio. Fragebögen ausgefüllt haben. Basierend auf diesen Daten hat Human Synergistics statistische Zusammenhänge zwischen bestimmten Kulturvarianten und wirtschaftlichem Erfolg erkannt: Unternehmen, deren Kulturen in den Faktoren Leistung, Selbstverwirklichung, Menschlichkeit und Kontaktfreudigkeit besonders ausgeprägt sind, sind statistisch deutlich erfolgreicher als Unternehmen mit einer starken Neigung zu Ausweichverhalten, Perfektionismus und Macht. Diese Analysen ermöglichen im Change-Prozess einen faktenbasierten Dialog. So können objektive Ziele gesetzt werden und die erzielten Fortschritte werden messbar. Fazit – Echte Veränderung im Unternehmen Wenn Betriebsmodelle mit disruptiven Technologien modernisiert werden, gehen damit fast ausnahmslos große Veränderungen für die Betroffenen einher (s. Abb. 8.22). Die enge Ausrichtung aller für den Erfolg des Geschäfts zuständigen Mitarbeiter auf den Kunden ist für viele die erste große Umstellung. Der Fokus der Analyse verschiebt sich weg von den Branchenerfahrungen der Experten oder den Aussagen der Kunden und hin zur Auswertung der tatsächlichen Kundendaten. Das führt zur Etablierung von neuen Best Practices in Unternehmen, deren Einführung von den Fachexperten in der Regel skeptisch beäugt wird. Dazu kommen viele kulturelle und menschliche Herausforderungen: Die neuen agilen Teams sind viel heterogener als früher. Sie arbeiten möglicherweise örtlich verteilt und tauschen ihre Arbeitsergebnisse über IT-Tools aus. Erfahrungswissen wird durch Technologiewissen abgelöst, Perfektionismus wird durch Ausprobieren im Rahmen kontrollierter Risiken abgelöst.

Mit Fokus auf den Kunden, …

... Datenanalyse und Machine Learning, …

… und interdisziplinären & agilen Teams …

Betriebsmodell Infrastrukturmodell

… zu global skalierenden Geschäsmodellen mit Null-Grenzkosten

Abb. 8.22   Betriebsmodell modernisieren mit Cloud-Technologie erfordert echte Veränderungen im Unternehmen

258

8  Die Cloud-Transformation

8.5 Das Geschäftsmodell umstellen Die „Zone-to-win“-Matrix wurde bereits in Abschn. 8.1.2 beschrieben. Die nächsten Abschnitte widmen sich der Frage, wie eine Transformation des kompletten Portfolios an Geschäftsmodellen aussehen kann und wie die Prioritäten eines Unternehmens während dieser Übergangsphase gesetzt werden sollten.

8.5.1 Transformation als erste Führungsaufgabe Eine Annahme, die allen Ratschlägen von Geoffrey Moore zugrunde liegt, lautet: Unternehmen als soziale Gebilde mit starker Kultur, eingefahrenen Gewohnheiten, stabilen Prozessen und in ihrer jeweiligen Zone tradierten Sichtweisen auf die Welt sind für eine disruptive Umstellung eines Geschäftsmodells nicht intrinsisch offen. Denn disruptive Technologien ändern die Vorgehensweisen nicht inkrementell innerhalb der bestehenden Denkmodelle; vielmehr stellen sie die Aufgabenteilung, die Incentivierung, die Prozesse und Systeme komplett infrage. So waren die Erfolgsfaktoren des Geschäftsmodells von Nokia – Kosten der Herstellung durch Skaleneffekte und integrierte Hardware-Wertschöpfung – ganz andere als jene, mit denen das iPhone von Apple erfolgreich wurde (iTunes, App-Ökosystem). Sales und Delivery im klassischen Microsoft-Office-Geschäft unterscheiden sich radikal von jenen, die die Cloud-Applikation Office365 erfolgreich machen. Auch die firmenübergreifende Wertschöpfung ist nicht auf grundlegende Änderungen vorbereitet. Lieferanten bieten nicht die notwendigen Lizenzverträge und Zulieferleistungen, Kunden haben für die neuen Technologien oder Einkaufsmodelle noch keine Budgets vorgesehen, ihre Einkäufer denken noch in alten Schemata. Moore beschreibt in seinen Vorträgen ausführlich die menschliche Dynamik zwischen den unterschiedlichen Zonen innerhalb des Unternehmens (Moore 2017). Vertreter der Performanz-Zone erinnern alle anderen regelmäßig daran, wer momentan das Geld im Unternehmen verdient. Die Mitarbeiter der Inkubations-Zone halten alle anderen für rückständig und die Kolleginnen und Kollegen der Produktivitäts-Zone empfinden sich „als die einzigen Erwachsenen im Raum“. In Zeiten der Disruption aber entsteht die Zukunft des Unternehmens durch die Neuordnung seiner Elemente. Eine Neuordnung, die keiner der Akteure allein stemmen kann, weil er dafür nicht die notwendige Macht hat, weil ihm Know-how, Weitblick oder Wille fehlen. Die Verantwortung liegt dann beim CEO, denn er hat theoretisch die Macht dazu (s. Abb. 8.23). Praktisch benötigt der CEO einen Auftrag der Shareholder – denn er setzt das Unternehmen großen, unbekannten Risiken aus. Zudem hat der CEO den größten Teil seiner beruflichen Erfahrungen in jener Welt gesammelt, die disruptiert wird, und er kennt sich besser mit den alten Prozessen aus als mit der neuen Technologie. Auch ist nicht jeder CEO für jede unternehmerische Herausforderung geeignet. Einige sind bessere Entscheider, andere sind gut im Shareholder Management, wiederum andere sind für Transformationsphasen besser geeignet (Tappin 2015).

259

Unterstützend

Wirtscha lich performant

8.5  Das Geschäftsmodell umstellen Disrupve Innovaon

Erhaltende Innovaon

Transformaon

Performanz

Unsicheres, zuküniges Produkt

Forschung Entwicklung Verprobung

Inkubaon

Die zonenübergreifende Verschiebung von Ressourcen und die Ausrichtung des Fokus müssen vom CEO geführt werden

HR Markeng Facility Management Public Relaons Ausbildung Finance

Produkvität

Legende Bestehende Produkte Inkubaonsthemen

Abb. 8.23   Transformation als Führungsaufgabe nach Geoffrey Moore

Moore positioniert sich eindeutig: Zeiten der Transformation sind „Krisen der Priorisierung“ (Moore 2017). Unternehmen müssten die Prioritäten ihrer Zonen neu ausrichten, um die sogenannte „Hockeyschläger-Kurve“ nicht nur zu beschreiten, sondern auch erfolgreich zu durchlaufen. Die Hockeyschläger-Kurve (oder auch „J-Kurve“) beschreibt einen typischen Profitabilitätsverlauf eines neuen Geschäftsmodells. Dieser ähnelt optisch einem Hockeyschläger bzw. einem „J“: Die Profitabilität sinkt also zunächst und steigt erst nach einiger Zeit wieder ins Positive (Kenton 2019). Das kurzfristige Ziel ist es, möglichst einen Mindestanteil von 10 % am Geschäft des Gesamtunternehmens zu erreichen, um das neue Geschäft intern erfolgreich zu etablieren. Er schlägt dafür zwei Modell-Strategien vor: Angriff (Offense) und Verteidigung (Defense).

8.5.2 Zone Offense – Als Disruptor auftreten Bei der Angriffsstrategie tritt ein Unternehmen als Disruptor auf und möchte mit einem neuen Produkt oder einem neuen Service einen Markt erobern (s. Abb. 8.24). Moore nennt dabei die Beispiele „Apple mit dem iPhone“ und „Salesforce mit der Marketing Cloud“. Beide waren in ihrem jeweiligen Markt (Mobiltelefone bzw. Digital Marketing) vor dem Markteintritt nicht aktiv. Beide hatten solide Standbeine in anderen Bereichen (Computer bzw. Sales Cloud), waren aber derart von ihrem neuen Geschäftsmodell überzeugt, dass sie bereit waren, die gesamte Unternehmung durch die Größe des Wagnisses aufs Spiel zu setzen. Daher rührt die Notwendigkeit, neu zu priorisieren: Das Unternehmen muss in der Zeit, bis das neue Geschäft die Zielmarke von 10 % erreicht hat, die Transformations-Zone höher priorisieren als die Performanz-Zone. Ist sich das Management nicht sicher, ob es

Wirtschalich performant

260

8  Die Cloud-Transformation Disrupve Innovaon

Erhaltende Innovaon

Transformaon

Performanz Nur ein Produkt aus der Inkubaon in die Transformaon verschieben

10%-Ziel

Unterstützend

Fokus auf Transformaon

Forschung Entwicklung Verprobung

Inkubaon

HR Markeng Facility Management Public Relaons Ausbildung Finance

Produkvität

10%

Transformaon wird Priorität 1, bis das neue Produkt 10% des Gesamtumsatzes des Unternehmens erzeugt. Performanz-Zone erhält Priorität 2, Produkvitäts-Zone die Priorität 3, Inkubaons-Zone die Priorität 4. Transformaon unterlassen, falls das Unternehmen nicht sicher ist, ob es auch die „J-curve“ durchlaufen möchte.

Abb. 8.24   Zone Offense – Als Disruptor auftreten nach Geoffrey Moore

das neue Geschäft wirklich wert ist, diese Phase bis zum Ende zu durchlaufen, sollte es die Transformation gar nicht erst beginnen. Gelingt der Umbruch, winkt eine deutlich höhere Unternehmensbewertung als Belohnung: Der Aktienkurs von Salesforce entwickelte sich seit dem Start der Marketing Cloud deutlich besser als jener der Wettbewerber SAP und Oracle, die sich ohne disruptive Transformationen weiterentwickelten. Gleichzeitig warfen die Geschäftsmodelle der Performanz-Zone beider Unternehmen in den untersuchten Jahren exzellente Gewinne ab. So hat sich beispielsweise der Jahresüberschuss von SAP seit dem Jahr 2001 mehr als vervierfacht (SAP 2002) – auf aktuell ca. 4 Mrd. EUR. Auch wenn bei „Zone Offense“ das aktuelle Kerngeschäft des Unternehmens nicht bedroht ist, muss die komplette Führungsmannschaft den Wandel unterstützen. Moore schätzt, dass die Transformations-Zone etwa 15 bis 20 % der Ressourcen des Unternehmens benötigt, um erfolgreich die Zielmarke zu erreichen – und die müssten in der Übergangsphase von den anderen Zonen zur Verfügung gestellt werden. Dies führe notwendigerweise zu den Zielkonflikten, die nur durch eine klare Priorisierung der Transformations-Zone und durch ein Commitment aller Führungskräfte gelöst werden können.

8.5.3 Zone Defense – Der Disruption begegnen Die Verteidigungs-Strategie – dargestellt in Abbildung Abb. 8.25 – schildert die Transformation aus Sicht des disruptierten Unternehmens (Disruptee). Ein Beispiel für die Umsetzung der Zone-Defense-Strategie ist Microsoft. Die drei großen ­Geschäftsmodelle

8.5  Das Geschäftsmodell umstellen Erhaltende Innovaon

Transformaon

Performanz

Wirtschalich performant

Disrupve Innovaon

Das bedrohte Produkt in die Transformaonszone verschieben

Das disruperte Produkt stabilisieren

Unterstützend

261

Forschung Entwicklung Verprobung

Inkubaon

HR Markeng Facility Management Public Relaons Ausbildung Finance

Produkvität

Das Betriebsmodell so viel wie möglich mit Hilfe der disrupven Technologien modernisieren. Die Transformaons-Zone erhält Priorität 1, gefolgt von der InkubaonsZone. Die Performanz-Zone erhält Priorität 3, die Produkvitäts-Zone Priorität 4. Transformaonsmodus beibehalten, bis Unternehmen auf normalem Wachstums-Pfad angekommen ist.

Abb. 8.25   Zone Defense – Der Disruption begegnen nach Geoffrey Moore

des Unternehmens (Office-Programme, Betriebssysteme, Back-end-Server) waren hochprofitabel, bis Cloud- und Mobile-Technologien den Markt disruptierten. Apple und Google übernahmen mit ihren Mobile-Betriebssystemen den Markt für die Betriebssysteme der Endgeräte („Edge-Devices“), die Cloud bedrohte das Geschäft für Lizenz-Software und Back-End-Server. Die zentrale These der Verteidigungsstrategie ist: Ein Geschäftsmodell, das existentiell bedroht wird, kann sich nicht gleichzeitig modernisieren und die traditionell erwarteten Ergebniszahlen und Umsatzsteigerungen liefern. Das Kerngeschäft wird in die Transformations-Zone verschoben, das Durchlaufen einer neuen Hockeyschläger-Kurve muss ermöglicht werden. Die Anforderung an das alte Geschäftsmodell ist es nicht, den Disruptor zu überholen; es reicht, so viele Elemente der neuen Technologie in das eigene Angebot zu integrieren, dass die Kunden von einem vollständigen Wechsel auf das Angebot des Disruptors absehen. Azure, die Cloud-Lösung von Microsoft, muss also nicht besser oder disruptiver sein als AWS, sie muss nur den Kern des Cloud-Leistungsversprechens treffen. Kunden scheuen dann häufig den Anbieterwechsel, denn dieser ist mit Aufwand und Risiken verbunden. Diese Aussage von Moore, getroffen im Jahr 2016, hat sich in den Folgejahren bestätigt: Azure holt im Wettbewerb inzwischen Marktanteile auf (Agarwal 2017), wird aber im entsprechenden Gartner-Quadranten immer noch hinter AWS geführt (Weaver 2019). Unternehmen müssen davon ausgehen, dass die alte Performanz-Zone durch die Transformation in ihrer wirtschaftlichen Leistungsfähigkeit negativ beeinflusst wird. Auch hier dient Microsoft als Beispiel: Im Zuge der Einführung von Azure wurde die Incentivierung der bestehenden Sales-Mitarbeiter umgestellt. Wurden sie vorher

262

8  Die Cloud-Transformation

­ nanziell dazu motiviert, das profitable Altgeschäft zu verkaufen, ging es fortan mit fi doppeltem Gewicht darum, die Cloud-Lösung zu verkaufen – obwohl diese noch nicht einmal einen positiven Deckungsbeitrag abwarf (Moore 2017). Die Disruption erfolgte also aktiv, von innen heraus und selbstgesteuert. Der Erfolg dieser Maßnahmen war immens: Der Aktienwert von Microsoft verdreifachte sich in der Zeit von 2014 bis 2019. Als Begründung führt Moore an, dass die Shareholder die Bedrohung durch disruptive Technologien erkennen und ein Unternehmen, das sich der Transformation glaubwürdig stellt, gegenüber einem Unternehmen bevorzugen, das sich auf die kurzfristige Einhaltung von Finanzkennzahlen im Altgeschäft fokussiert.

8.6 Die Auswirkungen der Cloud-Transformation auf die potenziellen Mitarbeiter In Kap. 7 wurden bereits die größten Herausforderungen für die Anpassung der Unternehmenskultur an die digitalen Herausforderungen dargestellt. Darüber hinaus führt die Umsetzung der Transformationsschritte zu einem neuen Rollenverständnis der (potenziellen) Mitarbeiter im Unternehmen. Die Auswirkungen dieses neuen Rollenverständnisses der einzelnen Mitarbeitergruppen werden in den folgenden Abschnitten beleuchtet.

8.6.1 Entwickler – das neue Paradies Der schwedische LKW-Hersteller Scania behauptet, seine Cloud-First-Initiative sei ein „Paradies für Entwickler“ (Scania 2017). Im Gespräch mit Cloud-Entwicklern ist häufig folgende Aussage zu hören: „Es gab noch nie eine bessere Zeit Softwareentwickler zu sein, als jetzt.“ Kein Wunder: In Kap. 4 wurde ausführlich die neue Macht der Cloud als software-definierte IT beschrieben – und diese Macht fällt vornehmlich den Software-Entwicklern zu. In Zeiten der klassischen IT waren sie von den Projektleitern und Geschäftsverantwortlichen abhängig, die ihnen im Namen der Kunden die Prioritäten setzten und versuchten, durch zusätzlichen Druck die Entwicklung neuer Features zu beschleunigen. Noch abhängiger waren sie von den Systemadministratoren, die sie bitten mussten, ihnen zusätzliche Ressourcen zur Verfügung zu stellen. Die Administratoren aber waren weit weg, meist an entfernten Orten, in anderen Abteilungen und verfolgten andere Ziele. Der Prozess der Softwareentwicklung war zu diesem Zeitpunkt zäh und mühselig. Aufgrund der hohen Arbeitsteiligkeit des Gesamtprozesses konnten Entwickler häufig erst Monate oder Jahre nach dem Start des Projekts und nachdem sie ihre ersten Zeile Code geschrieben hatten das Ergebnis ihrer Arbeit im Live-Betrieb erleben. Mithilfe der Cloud verabschieden sich Software-Entwickler aus der Rolle des „kleinen Rädchens in einer großen Maschine“. Aus ihnen werden Schlüsselspieler ­ in kleinen Mannschaften, die aus heterogenen Spezialisten zusammengesetzt sind.

8.6  Die Auswirkungen der Cloud-Transformation …

263

­ bertragen auf die Sportwelt werden die Veränderungen deutlich: Diese Mannschaften Ü spielen schnell und die Ergebnisse sind sofort sichtbar. Noch vor wenigen Jahren hieß es, Entwicklungsaufgaben sollten am besten an günstige Offshore-Standorte ausgelagert werden. Jetzt hat sich das Blatt gewendet: Entwickler müssen möglichst nah am Kunden arbeiten, eng eingebettet vor Ort in einem kleinen Team. Die Nachfrage nach ihren Fähigkeiten steigt enorm (Gelowicz 2018). Mit steigender Verantwortung und Kundennähe verändert sich aber das Profil des Entwicklers. Konnte er sich früher im großen Prozess zurückzuziehen, wird jetzt von ihm erwartet, direkt mit dem Kunden zu kommunizieren, dessen Anforderungen zu verstehen und mehr in Geschäftsmodellen zu denken.

8.6.2 Cloud-Architekten – Die knappste Ressource am Markt Die herausragende Bedeutung der Software-Architektur für den Unternehmenserfolg wurde bereits in Kap. 6 herausgearbeitet: Schon immer mussten Fachanwendungen die Kriterien Robustheit, Verfügbarkeit und Performance erfüllen. Dies zu erreichen war und ist die Aufgabe des Software-Architekten. Was ist also der Unterschied zu heute und warum ist der Cloud-Architekt die knappste Ressource am Arbeitsmarkt? Mit der Public Cloud verändert sich die Art und Weise wie Applikationen die genannten Anforderungen erreichen. Wenn Software nicht mehr komplett selbst entwickelt und betrieben wird, sondern zu einem möglichst großen Teil aus den in der Public Cloud verfügbaren IT-Fertigteilen zusammengestellt wird, kommt dem Software-Architekten eine herausragende Rolle zu. Er kennt und versteht das große Portfolio der Komponenten und er konzipiert daraus eine Lösung, die den Business-Anforderungen gerecht wird. Er trifft damit auch die Entscheidung, welcher Teil der Anwendung noch selbst entwickelt und betrieben wird und wo ein fertiger Cloud-Service genutzt werden kann. Unternehmen migrieren ihre Applikationen auf Cloud-Infrastrukturen, auf Edge Devices (jede Art von Endgerät) oder zu Software-Services (SaaS). Diese Migrationen sind zunächst Architektur-Herausforderungen: Zu klären ist, wie die Anforderungen des Geschäfts und der aktuelle Workload aussehen, welche Services es dafür in der Cloud gibt und welche davon selbst programmiert werden sollen. Cloud-Lösungen werden von „Cloud-Solution-Architects“ geschaffen. Wenn 80 % der Unternehmen ihre Applikationen auf Cloud-Technologien transformieren, sind es die Cloud-Architekten, die besonders benötigt werden. Eine Kennzahl, die diesen Zusammenhang verdeutlicht, sind die Gehälter der Cloud-Architekten: Diese liegen deutlich über jenen der Entwickler. Das Selbstbewusstsein dieses Mitarbeitertyps ist ohnehin hoch. Cloud-Architekten wissen, was ihre Arbeit wert ist, denn sie sehen die Kostenkalkulationen vor und nach der Migration. Sie sehen, wie sich der Geschäftserfolg einer Applikation verändert, wenn sie die neue Art der Zusammenarbeit in Teams etabliert haben.

264

8  Die Cloud-Transformation

8.6.3 Klassische IT-Spezialisten – Echte Gefahren und große Chancen Aus der Perspektive der IT-Mitarbeiter gibt es zahlreiche Nachteile, die mit der Transformation verbunden sind. Durch die zunehmende Automatisierung der IT sind die Arbeitsplätze vieler IT-Spezialisten in Gefahr. Die Aufgaben jener Mitarbeiter, die Systeme mit klassischen Microsoft-Technologien betreut und betrieben haben, könnten in den kommenden Jahren zu einem großen Teil wegfallen. Microsoft bietet Applikationen wie Exchange, Sharepoint, Onedrive und CRM als Cloud-Service an, ebenso wie Kommunikationslösungen wie Skype oder Teams. Für die Mitarbeiter vor Ort bleiben lediglich administrative Aufgaben, zum Beispiel neue Nutzer anzulegen oder Einstellungen der Nutzerprofile zu konfigurieren. Security- und Netzwerkspezialisten werden auch in der IaaS-Welt noch benötigt, ihr Profil ändert sich aber deutlich: Sie gelangen eher in beratende Rollen oberhalb der API. Zudem entfallen viele Managementrollen: Wenn Installations-Projekte auf wenige Stunden oder Tage schrumpfen, wird kein dedizierter Projektmanager mehr gebraucht. Wenn ein Cloud-Architekt allein das Zusammenspiel von Netzwerk, Server und Datenbank steuert, ist auch kein Service Delivery Manager mehr nötig, der die Leistungserbringung koordiniert. Gleichzeitig erreicht die Zahl der offenen Stellen für IT-Experten jedes Jahr Rekordstände (Bitkom 2018). Um die Möglichkeiten, die sich mit dieser Nachfrage am Arbeitsmarkt verbinden, nutzen zu können, müssen die Mitarbeiter in klassischen IT-Rollen umdenken. Die Kenntnis neuer Vorgehensweisen und Tools sowie die Fähigkeit, Software entwickeln zu können, steigern ihren Wert für ihre (zukünftigen) Arbeitgeber. Für viele ist das kein großer Sprung, haben sie doch in ihren alten Berufen schon „gescripted“ – also eine einfache Form der Programmierung praktiziert. Andere sind schon exzellente Entwickler und nutzen diese Fähigkeiten außerhalb ihres Jobs, zum Beispiel in Open-Source-Projekten oder bei der Programmierung ihres Smart Homes. Der Wechsel von der sekundären Wertschöpfung in die primäre Wertschöpfung birgt noch andere Herausforderungen: Mitarbeiter müssen sich direkt mit dem Kunden auseinandersetzen. Dazu gehören Reisen, die Übersetzung von IT-Sprache in kundenverständliche Präsentationen und persönliche Skills wie Moderation oder der Umgang mit Konflikten. Wie fühlt sich der Wandel also für die klassischen IT-Kollegen an? Sehr unterschiedlich. Für einige wird es eine Befreiung sein, für andere ist es der Verlust einer Welt, in der sie es sich bequem eingerichtet haben.

8.6.4 Das mittlere Management – Druck und Verlustängste Das mittlere Management hat durch den digitalen Wandel einiges zu verlieren. Die Team- und Abteilungsleiter haben in der alten Welt begonnen, Karriere zu machen. Dort kennen sie sich aus und haben sich etabliert. In der neuen Cloud-Welt ändern sich die Paradigmen: Aus Spezialistenteams, die in übergreifende Prozesse eingebunden sind,

8.6  Die Auswirkungen der Cloud-Transformation …

265

werden interdisziplinäre Teams, die für ihren jeweiligen Service gesamtverantwortlich sind. Die Profile der Führungskräfte ändern sich in einige unterschiedliche Richtungen: In einigen Fällen geht es nun eher um agiles Coaching, in anderen um Spezialistenwissen zu Cloud-Architekturen und mitunter löst sich das ganze Team auf, weil es in dieser Form in der neuen Welt nicht mehr benötigt wird. Darüber hinaus steht das mittlere Management weiterhin unter dem Druck, das alte Geschäft eine Zeit lang aufrecht zu erhalten und dort die Margen zu erzeugen, die dem Unternehmen die digitale Transformation überhaupt ermöglichen. Möglicherweise wechseln die Leistungsträger des Unternehmens als erste in die neue Welt. Dadurch engt sich der personelle wie finanzielle Handlungsspielraum der Manager, die Entwicklung der alten Abteilung voranzutreiben, immer weiter ein.

8.6.5 Fachabteilungen – Freiheit, Chaos und Verantwortung Die Cloud-Transformation setzt Ressourcen frei, die bislang in administrativen Prozessen gebunden waren und gibt Unternehmen die Möglichkeit, ihre Kernaufgaben zu digitalisieren. Die ersten Schritte dorthin sind einfach: es wird mit wenigen Mausklicks ein SaaS-basiertes CRM-System eingeführt und die entstehenden Daten werden regelmäßig in eine cloud-basierte Analytics-Plattform kopiert. Die Ergebnisse werden in eine PowerPoint-Datei kopiert und zum Beispiel in einer „Dropbox“ abgelegt. Solche Public Cloud-Lösungen bieten unkompliziert Speicherplatz und die Daten können unmittelbar mit externen Partnern geteilt werden. Anstatt sich unzählige Mails zu schreiben, werden Aufgaben über digitale Kartenwände in Trello priorisiert, einem cloudbasierten Tool, das auf einfache Weise Listen, Karten und Boards visualisiert. Alle genannten Tools sind einfach und ohne IT-Wissen von Mitarbeitern der Fachabteilungen implementier- und nutzbar. Die Probleme der Cloud-Transformation treten in den Fachabteilungen erst mit der Zeit auf: Abteilungen haben plötzlich Probleme, die Kosten zuzuordnen. Es ist nicht klar, wer Zugriff auf welche Daten hat und wie die Adminrechte neu zuordnet werden können, wenn der Mitarbeiter das Unternehmen verlässt, der das jeweilige Tool eingeführt hat. Die Rechtsabteilung kennt die Ansprechpartner der Tools nicht, ihre Nachfragen, ob die geltenden Vorgaben bezüglich des Datenschutzes umgesetzt werden, bleiben unbeantwortet. Die Freiheit der Fachexperten wird schnell zum Chaos, wenn die neuen Möglichkeiten nicht verantwortungsvoll genutzt werden. Die Fachabteilungen benötigen nun Know-how in den Bereichen Software-Entwicklung, Cloud-Architekturen, Security und Compliance. Einige Professionen fühlen sich von der neuen Nähe der IT zu ihrem Fach durchaus bedroht. So sah sich der deutsche Verband der freien Übersetzer und Dolmetscher genötigt, die Öffentlichkeit darüber zu informieren, dass der auf Machine Learning basierende Übersetzungsdienst DeepL immer noch nicht perfekt übersetzt (Bernard 2018). Der Verband übersieht dabei aber, dass diese Dienste weniger die perfekte

266

8  Die Cloud-Transformation

­ bersetzung eines Dokuments anvisieren, als den Mitarbeitern im Unternehmen in ihren Ü alltäglichen Kommunikationsherausforderungen zu helfen. Insgesamt ist der Trend zur cloudbasierten IT für die Fachabteilungen als sehr positiv zu bewerten. Cloudbasierte IT stellt den Mitarbeitern der Fachabteilungen wesentlich mehr Services zur Verfügung, die schneller eingeführt und mit geringen Investitionen genutzt werden können. Die Kehrseite dieser Entwicklung besteht darin, die damit einhergehenden Steuerungs- und Compliance-Aufgaben zu managen.

8.6.6 Top-Management – Finanzkennzahlen, Gefahren der Disruption und neue Vorgehensweisen Ein großer Teil der Last der Cloud-Transformation liegt auf den Schultern des Top-Managements. Dessen Situation aber ist alles andere als einfach: Die Eigentümer bestehen weiterhin auf der Erfüllung der Umsatz- und Gewinnziele. Diese zu erfüllen wird jedes Jahr schwieriger, schließlich geraten die bestehenden Geschäftsmodelle durch neue Wettbewerber unter Druck, die ihre Prozesse ohne Ballast direkt auf neuen Technologien aufbauen konnten. Gerade die gut ausgebildeten und mit den neuen Technologien vertrauten Mitarbeiter verlassen häufiger das Unternehmen, denn sie möchten mit den neuen Methoden arbeiten und nicht althergebrachte Prozesse bedienen. Die Umstellung auf die neuen digitalen Best Practices wie Cloud Native, Agile und DevOps ist zwar technisch vergleichsweise einfach, die dafür notwendige Umstellung der Organisation ist es nicht. Es gibt bestehende Machtstrukturen, Prozesse sind eingefahren und eng mit den aktuellen IT-Tools und Herstellungsmethoden verknüpft. Die Unternehmenskultur ist nicht einfach änderbar, Führungsmodelle und Karrierewege sind eng mit dem aktuellen Geschäftsmodell verflochten. Der theoretische Zusammenhang von moderner Software-Architektur und Wettbewerbsfähigkeit im digitalen Geschäftsmodell ist zwar schnell verstanden, aber wie können die Unternehmensapplikationen verbessert werden, wenn sie von externen Lieferanten wie SAP stammen und erst einmal gar nicht verändert werden können? Zusätzlich stellt sich die Frage nach dem Zugang zum Kapital. Viele Unternehmen sind kreditfinanziert und Banken haben Sonderkündigungsrechte, wenn bestimmte Rentabilitäts-Kennzahlen kurzfristig nicht eingehalten werden. Cloud-Native-Lösungen skalieren zwar auf der Delivery-Seite exzellent und erzeugen nur Kosten, wenn die Kunden sie auch nutzen. Dennoch müssen insbesondere vertriebsseitig häufig lange, unprofitable Wachstumsphasen durchgestanden werden. Mitunter erobern die mit ausreichend Risikokapital ausgestatteten Konkurrenten erst einmal den Markt und profitieren von den digitalen Netzwerkeffekten, bevor sie mit der Monetarisierung ihres Marktanteils beginnen (vgl. Kap. 2). Bereits Clayton Christensen wies darauf hin, dass es nicht der Fehler der TopManager war, die die Unternehmen in die Falle des Innovator’s Dilemma trieb (Christensen 1997). Im Gegenteil, das Management hatte ja über Jahre bewiesen, dass es das ­Unternehmen erfolgreich führen und evolutionär weiterentwickeln kann. In der Zeit der

8.7  Eine erfolgreiche Cloud-Transformation – in einem Bild erklärt

267

Cloud aber stellen sich dem Top-Management ganz neue Herausforderungen: Im einfachsten Fall geht es nur darum, die neuen Best Practices auf der Seite der Infrastruktur zu erlernen und umzusetzen. Im schlimmsten Fall aber steht die Zukunft des Unternehmens auf dem Spiel, alle Stakeholder müssen auf einen großen Wandel eingeschworen werden und eine neue, risikoreiche Reise in einen ganz neuen Markt muss angeführt werden.

8.7 Eine erfolgreiche Cloud-Transformation – in einem Bild erklärt Die grundlegenden Modelle zur Beschreibung der Zusammenhänge im Kontext der Cloud-Transformation sind das Drei-Horizonte-Modell von McKinsey, das Innovator’s Dilemma von Clayton Christensen sowie „Zone-to-win“ von Geoffrey Moore. Das Horizonte-Modell beschreibt die drei Investitionshorizonte, die in großen Unternehmen existieren. Mit dem Blick auf das laufende Jahr wird im ersten Horizont der Geschäftsgewinn erwirtschaftet. Mit begrenztem Budget und Risiko werden im dritten Horizont die Innovationen entwickelt, die in mehr als drei Jahren relevant sein werden. Der mittlere Horizont soll das nächste große Wachstumsgeschäft beinhalten. Im Falle disruptiver Technologien kann es ein „Innovator’s Dilemma“ zwischen dem ersten und dem zweiten Horizont geben. Die neue Technologie ist deutlich günstiger, aber margenschwächer, es scheint für das bestehende Unternehmen demnach nicht attraktiv, in diese disruptive Technologie zu investieren. In Zone-to-win wird das Modell des Innovator’s Dilemma mit dem Modell der unterschiedlichen Horizonte in einer Matrix vereint und um eine Analyse der Strategieoptionen ergänzt. Ausführlich beschreibt Moore den Fall, dass ein Unternehmen in seinem Geschäftsmodell ganzheitlich bedroht wird. In vielen Fällen aber reicht es lediglich, die disruptive Technologie in der Unternehmens-Infrastruktur zu nutzen oder bestehende Geschäftsmodelle dadurch effektiver zu gestalten. Insgesamt können drei unterschiedliche Ebenen der Cloud-Transformation unterschieden werden (Abb. 8.26). 

Geschäsmodell Porolio an Geschäsmodellen transformieren

Transformaon fokussieren

J-Kurve durchlaufen

T

Zonen managen 10%

SaaS Machine Learning

Internet of Things Data Analycs Betriebsmodell Cloud Social Media Wertschöpfung modernisieren Mobile Serverless IaaS PaaS Infrastrukturmodell Back-end-Systeme opmieren

Interdisziplinäre & agile Teams

Eigenes Data Center

Customer Focus & Data Analycs

Machine Learning & AI

Cloud & Cloud Nave

Moderne Soware

5R

Abb. 8.26   Public Cloud Transformation – Zusammenfassung der wichtigsten Punkte je Ebene

268

8  Die Cloud-Transformation

1. Cloud-Technologien disruptieren die klassische IT. Unternehmen können mit ihrer Hilfe schneller und kostengünstiger Software entwickeln und betreiben, sowie weltweit zu faktisch Null-Grenzkosten skalieren. Um mit Unternehmen, wie etwa Startups, mithalten zu können, die ausschließlich auf die neuen Methoden setzen, empfiehlt es sich grundsätzlich, ebenfalls eine Transformation in die Public Cloud durchzuführen. Je nach Einzelfall werden hierfür unterschiedliche Migrationsmodelle empfohlen: Schneller und kostengünstiger verlaufen Migrationen auf niedrigere Cloud-Ebenen (wie IaaS) – teurer, aber wirkungsvoller sind Migrationen auf höhere Cloud-Ebenen (wie Platform Services). Das Unternehmen baut zudem Know-how rund um moderne Software-Methoden und Technologien auf. 2. Sollen die bestehenden Geschäftsmodelle eines Unternehmens inhaltlich von den neuen Technologien profitieren, empfiehlt sich eine weitergehende Umstellung des Betriebsmodells. Die für den Erfolg des Geschäftsmodells relevanten Mitarbeiter – Experten für das Geschäftsmodell selbst, Software-Entwickler und Betriebs-Mitarbeiter – werden in einem Team zusammengeführt. Sie werden mit End-to-End-Verantwortung ausgestattet und können das Geschäft durch ihre Kundennähe und Umsetzungskompetenz schnell und erfolgreich weiterentwickeln. Sie analysieren den Kunden bevorzugt datenbasiert und verstehen ihn und seine Interessen anhand seines tatsächlichen Verhaltens. Sind ausreichend Daten vorhanden, können die Optimierungen durch Machine-Learning-Algorithmen unterstützt werden. 3. Die größte Anstrengung ist es für die Organisation, wenn das gesamte Portfolio komplett neu ausgerichtet werden soll. Dies kann der Fall sein, wenn ein Unternehmen derart von einem disruptiven Produkt überzeugt ist, dass es – zusätzlich zum aktuellen Leistungsportfolio – in einen neuen Markt eintreten möchte. Diesen Weg hat Apple mit seinem iPhone erfolgreich beschritten. Häufiger ist es der Fall, dass ein Unternehmen in seinem Kerngeschäft durch eine neue, disruptive Technologie bedroht wird. Ein wenig erfolgreiches Beispiel hierfür ist Kodak mit seinem Filmgeschäft, das durch die Digitalkamera disruptiert wurde. In beiden Fällen sollte sich der CEO das Mandat seiner Shareholder für eine Transformation sichern, denn das Unternehmen ist während dieser Zeit einem erheblichen Risiko ausgesetzt. Es sollte nur jeweils eine neue Leistung gleichzeitig eingeführt werden und die Transformation sollte höchste Priorität genießen, bis der neue Portfolio-Anteil etwa 10 % des Umsatzes des gesamten Unternehmens ausmacht. Erst dann ist das neue Geschäft in der Organisation unter normalen Bedingungen überlebensfähig. Unabhängig davon, auf welchen der drei beschriebenen Ebenen ein Unternehmen agiert und neue, disruptive Technologien einsetzt, sind die Auswirkungen für die betroffenen Mitarbeiter in allen Fällen erheblich. Die gewohnten Prozesse und Tools verändern sich, es wird mehr outgesourct, Teams werden anders zusammengestellt, die Nähe zum Kunden wächst und das Zusammenspiel von Mitarbeiter und Führungskraft wird ein anderes. Im Erfolgsfall wird die Transformation ein Gewinn für alle: Die Leistungen werden kundennäher, Unternehmen haben ein geringeres Investitionsrisiko und können mit weniger Kapitaleinsatz global skalieren. Die Arbeitsproduktivität steigt, Mitarbeiter können besser entlohnt werden.

Literatur

269

Literatur Agarwal, Nitin (2017): Why Microsoft Azure is growing faster than AWS, erschienen in: motifworks.com, http://motifworks.com/2017/03/20/why-microsoft-azure-is-growing-faster-thanaws/, abgerufen im Juni 2019. Amazon (2019): Leadership Principles, erschienen in: amazon.jobs.de, https://www.amazon.jobs/ de/principles, abgerufen im Juni 2019. Bagban, Khaled und Ricardo Nebot (2016): Governance und Compliance im Cloud Computing, erschienen in: Reinheimer und Robra-Bissantz (2016), S. 163–179. Baghai, Mehrdad, Steve Coley und David White (2000): The Alchemy of Growth, Basic Books, New York. Bernard, Andrea (2018): DeepL: Der Schein trügt, erschienen in: dvud.de, https://dvud. de/2018/05/deepl-der-schein-truegt/, abgerufen im Juni 2019. Bitkom (2018): 82.000 freie Jobs: IT-Fachkräftemangel spitzt sich zu, erschienen in: bitkom. org, https://www.bitkom.org/Presse/Presseinformation/82000-freie-Jobs-IT-Fachkraeftemangel-spitzt-sich-zu, abgerufen im Juni 2019. Briggs, Barry und Eduard Kassner (2017): Enterprise Cloud Strategy, 2. Auflage, Microsoft Press, https://info.microsoft.com/rs/157-GQE-382/images/EN-US-CNTNT-ebook-Enterprise_Cloud_ Strategy_2nd_Edition_AzureInfrastructure.pdf, abgerufen im Mai 2019. Braddy, Rick (2018): When Do You Decide To Ditch Your Own Data Center?, erschienen in: forbes.com, https://www.forbes.com/sites/forbestechcouncil/2018/07/05/when-do-you-decide-toditch-your-own-data-center/#4e8c802b426e, abgerufen im Juni 2019. Bulygo, Zach (2013): How Netflix Uses Analytics To Select Movies, Create Content, and Make Multimillion Dollar Decisions, erschienen in: neilpatel.com, https://neilpatel.com/blog/ how-netflix-uses-analytics/, abgerufen im Juni 2019. DeCarlo, Matthew (2018): Xerox PARC: A Nod to the Minds Behind the GUI, Ethernet, Laser Printing, and More, erschienen in: techspot.com, https://www.techspot.com/guides/477-xerox-parc-tech-contributions/, abgerufen im Mai 2019. Christensen, Clayton M. (1997): The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business Review Press, Boston. Coley, Steve (2009): Enduring Ideas: The three horizons of growth, erschienen in: mckinsey.com, https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/enduring-ideas-the-three-horizons-of-growth, abgerufen im Mai 2019. Dediu, Horace (2011): Comparing top lines: Apple vs. Microsoft, erschienen in: asymco.com, http://www.asymco.com/2011/09/29/comparing-revenues-apple-and-microsoft/, abgerufen im Mai 2019. Dernbach, Christoph (2019): Apple und Xerox PARC, erschienen in: mac-history.de, https://www. mac-history.de/apple-geschichte-2/2012-01-29/apple-und-xerox-parc, abgerufen im Juni 2019. Gairing, Fritz und Heiko Weckmüller (2019): Erfolgreiche Ansätze zur Steuerung von organisationalen Veränderungsprozessen, erschienen in: PERSONALquarterly, Nr. 2/2019, S. 46–49. Geißler, Otto und Nico Litzel (2018): So funktioniert Google TensorFlow, erschienen in: bigdata-insider.de, https://www.bigdata-insider.de/so-funktioniert-google-tensorflow-a-669777/, abgerufen im Juni 2019. Gelowicz, Svenja (2018): Buhlen um Softwareentwickler, erschienen in: sueddeutsche.de, https:// www.sueddeutsche.de/auto/arbeitsmarkt-buhlen-um-softwareentwickler-1.4173881, abgerufen im Juni 2019. Grüner, Sebastian (2016): Stresstest – Netflix’ Chaos Monkey zerstört effektiver Infrastruktur, erschienen in: golem.de, erschienen am: 20. Oktober 2016, https://www.golem.de/news/stresstest-netflix-chaos-monkey-zerstoert-effektiver-infrastruktur-1610-123938.html, abgerufen im Mai 2019.

270

8  Die Cloud-Transformation

Hahn, Dave (2018) in: How Netflix thinks of DevOps, erschienen in: youtube.com, https://www. youtube.com/watch?v=UTKIT6STSVM, abgerufen im Mai 2019. Haufe Akademie (2019): Whitepaper New Work, erschienen in: haufe-akademie.de, https://www. haufe-akademie.de/l/new-work/, abgerufen im Juni 2019. Hawkins, Andrew J. (2019): Apple’s secretive self-driving car project is starting to come into focus, erschienen in: theverge.com, https://www.theverge.com/2019/2/20/18233536/ apple-self-driving-car-voluntary-safety-report-project-titan, abgerufen im Mai 2019. Hill, Andreas F. (2017): Sustaining Growth with the Three Horizons Model for Innovation, erschienen in: medium.com, https://medium.com/frameplay/planning-for-future-growth-withthe-three-horizons-model-for-innovation-18ab29086ede, abgerufen im Mai 2019. Hushon, Dan (2018): 6 digital transformation trends for 2019, erschienen in: blogs.dxc.technology, https://blogs.dxc.technology/2018/11/15/6-digital-transformation-trends-for-2019/, abgerufen im Juni 2019. Kalakota, Ravi (2015): Customer Engagement Architecture: A Quick Reference Guide, erschienen in: disruptivedigital.wordpress.com, https://disruptivedigital.wordpress.com/2015/03/26/customer-engagement-architecture/, abgerufen im Juni 2019. Kenton, Will (2019): J-Curve-Effect, erschienen in: investopedia.com, https://www.investopedia. com/terms/j/j-curve-effect.asp, abgerufen im Juni 2019. Krauter, Ralf (2018) in: Der Hype um die Quantencomputer – Ralf Krauter im Gespräch mit Manfred Kloiber, erschienen in: deutschlandfunk.de, https://www.deutschlandfunk.de/rechnen-mit-qubits-der-hype-um-die-quantencomputer.684.de.html?dram:article_id=422355, abgerufen im Mai 2019. Kurtuy, Andrew (2019): What can you learn from Satya Nadellas’s Rise to CEO, erschienen in: novoresume.com, https://novoresume.com/career-blog/satya-nadella-one-page-resume, abgerufen im Juni 2019. Lorusso, Vito Flavio (2016): Overview of Prestashop and Azure integration and Partnership, Vortrag auf der Konferenz Prestashop Day, erschienen in: slideshare.net, https://www.slideshare. net/vflorusso/prestashop-and-azure, abgerufen im Mai 2019. Merks-Benjaminsen, Joris (2017): Customer focus as the key to digitalization, erschienen in: thinkwithgoogle.com, https://www.thinkwithgoogle.com/intl/en-gb/marketing-resources/content-marketing/customer-focus-key-digitalization/, abgerufen im Mai 2019. Microsoft Azure (2019): Framework für die Einführung der Microsoft Cloud (Microsoft Cloud Adoption Framework), erschienen in: docs.microsoft.com, https://docs.microsoft.com/de-de/ azure/architecture/cloud-adoption/overview, abgerufen im Mai 2019. Möhrle, Martin und Dieter Specht (2018): Not-Invented-Here-Syndrom, erschienen in: wirtschaftslexikon.gabler.de, https://wirtschaftslexikon.gabler.de/definition/not-invented-here-syndrom-40808/version-264185, abgerufen im Juni 2019. Moore, Geoffrey (2015): Zone to Win: Organizing to Compete in an Age of Disruption. Diversion Books, New York. Moore, Geoffrey (2016): Zone to win, Vortrag auf der GoTo-Konferenz, erschienen in: youtube. com, https://www.youtube.com/watch?v=fG4Lndk-PTI, abgerufen im Mai 2019. Moore, Geoffrey (2017): Zone to Win – Organizing to Compete in an Age of Disruption, Vortrag auf der TSIA Konferenz, erschienen in: youtube.com, https://www.youtube.com/ watch?v=FsV_cqde7w8, abgerufen im Juni 2019. Nadella, Satya, Greg Shaw und Jill Tracie Nichols (2017): Hit Refresh – The Quest to Rediscover Microsoft’s Soul and Imagine a Better Future for Everyone, HarperCollins, New York. Nordcloud (2018): Nordcloud ist führender „Accelerator“ für „Managed Public Cloud“ in Deutschland, erschienen in: nordcloud.com, https://nordcloud.com/de/nordcloud-ist-fuehrender-accelerator-fuer-managed-public-cloud-in-deutschland/, abgerufen im Mai 2019.

Literatur

271

Orban, Steven (2016): 6 Strategies for Migrating Applications to the Cloud, erschienen in: aws. amazon.com, https://aws.amazon.com/de/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/, abgerufen im Mai 2019. Protalinski, Emil (2019): Microsoft reports $32.5 billion in Q2 2019 revenue: Azure up 76%, Surface up 39%, and LinkedIn up 29%, erschienen in: venturebeat.com, https://venturebeat. com/2019/01/30/microsoft-earnings-q2-2019/, abgerufen im Mai 2019. Rackspace (2019): Den Wert der Cloud schneller erschließen – mit einem laut Gartner Magic Quadrant führenden Anbieter, erschienen in: rackspace.com, https://www.rackspace.com/de-de/ about/magic-quadrant-leader, abgerufen im Juni 2019. Reinheimer, Stefan und Susanne Robra-Bissantz (Hrsg.) (2016): Business-IT-Alignment: Gemeinsam zum Unternehmenserfolg, Springer Vieweg, Wiesbaden. Ryan, Joe (2018): Three horizons for Growth, erschienen in: youtube.com, https://www.youtube. com/watch?v=cwwAswmJ_yE, abgerufen im Mai 2019. Ryland, Mark (2018): AWS Summit Berlin 2018 Keynote, Vortrag auf der AWS Summit Konferenz, erschienen in: youtube.de, https://www.youtube.com/watch?v=s2Lpkm-jewo&feature=youtu.be, abgerufen im Juni 2019. SAP (2002): SAP Geschäftsbericht 2001, erschienen in: sap.com, https://www.sap.com/docs/ download/investors/2001/sap-2001-geschaeftsbericht.pdf, abgerufen im Juni 2019. SA Technologies (2018): The 5 R’s of Cloud Migration Strategy, erschienen in: medium.com, https://medium.com/@satechglobal/the-5-rs-of-cloud-migration-strategy-3b6a5676dda2, abgerufen im Juni 2019. Scania (2017): Scania’s Cloud First initiative is paradise for developers, erschienen in: scania.com, https://www.scania.com/group/en/scanias-cloud-first-initiative-is-paradise-for-developers/, abgerufen im Juni 2019. Schewe, Gerhard (2018): Organisationskultur, erschienen in: wirtschaftslexikon.gabler.de, https:// wirtschaftslexikon.gabler.de/definition/organisationskultur-46204/version-269490, abgerufen im Juni 2019. Schumacher, Gregor (2018): Kosten senken mit Cloud Native, erschienen in: cloud-blog.arvato.com, https://cloud-blog.arvato.com/kosten-senken-mit-cloud-native/, abgerufen am im Mai 2019. Schwitter, Konrad, Peter Weissmüller und Christian Katz (2007): Unternehmenskultur als Treiber für den Unternehmenserfolg, erschienen in: KMU Magazin, Nummer 5/2007, S. 10–33. Sinek, Simon (2011): How great leaders inspire action, Vortrag im Rahmen eines TED-Talks, erschienen in: youtube.com, https://www.youtube.com/watch?v=7zFeuSagktM&feature=youtu.be, abgerufen im Juni 2019. Siriu, Stefanie (2018): Corporate Covernance, erschienen in: Haufe.de, https://www.haufe. de/compliance/management-praxis/corporate-governance/corporate-governance-defintion-und-ziele_230130_479056.html, abgerufen im Mai 2019. South, Michael (2018): Scaling a governance, risk, and compliance program for the cloud, ermerging technologies, and innovation, erschienen in: aws.amazon.com, https://aws.amazon.com/ de/blogs/security/scaling-a-governance-risk-and-compliance-program-for-the-cloud/, abgerufen im Mai 2019. Tappin, Steve (2015): The six types of CEO, erschienen in: hrmagazine.co.uk, https://www.hrmagazine.co.uk/hr-in-the-boardroom/article-details/the-six-types-of-ceo, abgerufen im Juni 2019. Thrasyvoulou, Xenios (2014): Understanding the innovator’s dilemma, erschienen in: wired.com, https://www.wired.com/insights/2014/12/understanding-the-innovators-dilemma/, abgerufen im Mai 2019. Weaver, Marc (2019): As 2018 Ends, AWS Makes Surprise Announcements for 2019, erschienen in: simplilearn.com, https://www.simplilearn.com/aws-makes-surprise-announcements-for-2019-article, abgerufen im Juni 2019.

272

8  Die Cloud-Transformation

Weddeling, Britta (2018): Weniger iPhones, mehr Gewinn – die Apple-Zahlen in der Blitzanalyse, erschienen in: handelsblatt.com, https://www.handelsblatt.com/unternehmen/it-medien/ quartalszahlen-weniger-iphones-mehr-gewinn-die-apple-zahlen-in-der-blitzanalyse-/23258442. html?ticket=ST-477138-1x2ld5nEdcDuFAfsx46L-ap2, abgerufen im Mai 2019. Weinberger, Matt (2015): Satya Nadella: ‚Customer love‘ is a better sign of success than revenue or profit, erschienen in: businessinsider.com, https://www.businessinsider.com/microsoft-ceosatya-nadella-on-culture-2015-10?IR=T, abgerufen im Juni 2019.

9

Cloud-Transformation – Wie die Public Cloud Unternehmen verändert

Zusammenfassung

„Cloud-Transformation – Wie die Public Cloud Unternehmen verändert“ schlägt einen Bogen von den theoretischen Grundlagen der Digitalisierung (Kap. 1, 2 und 3) über die technischen Faktoren der Umsetzung einer Cloud-Strategie (Kap. 4, 5 und 6) und organisatorischen Implikationen für die Unternehmensführung (Kap. 7 und 8). Damit Sie die wichtigsten Punkte immer schnell zur Hand haben, bieten Ihnen dieses Kapitel einen kompakten Überblick über die zentralen Thesen (s. Abb. 9.1).

9.1 Unternehmen scheitern – auch wenn Manager scheinbar alles richtig machen Disruptive Technologien verändern die Marktlogik ganzer Branchen. Produkte, die wegen ihres Preises und ihrer Komplexität bisher nur wenigen Kunden zugänglich waren, werden nun für eine breite Masse verfügbar. Dabei verändert sich nicht nur der Preis eines Produkts, auch die Zielgruppen und die Vertriebswege sowie der Leistungsumfang und der Standardisierungsgrad verändern sich. Etablierte Anbieter erkennen meist die aufkommende, disruptive Technologie. Allerdings lohnt es sich für sie nicht, die neuen disruptiven Produkte zu lancieren, da ihr bestehendes, sicheres Geschäftsmodell mit hohen Margen davon negativ beeinflusst würde. Die notwendige Umstellung der Wertschöpfungskette ist zudem außergewöhnlich risikoreich. Nach den gängigen Entscheidungsmustern des Unternehmens halten es viele der beteiligten Manager für nicht geboten, in das disruptive Geschäft zu investieren. Hat die disruptive Technologie den Markt dann soweit verändert, dass die Margen der alten Marktführer leiden, ist es für rettende Maßnahmen meist zu spät. Das Unternehmen hat den Kampf um das neue Geschäft verloren (Abb. 9.1, 9.2). © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5_9

273

274

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

Unternehmen unter Druck

Kapitel 1 Disrupve Technologien gefährden bestehende Geschäe von bisher erfolgreichen Unternehmen. Kapitel 2

Digital dominiert Grenzkosten entscheiden Cloud automasiert IT Applikaonen transformieren

Plaormen sind das neue ökonomische Paradigma.

Besmmte Rahmenbedingungen erhöhen die Erfolgswahrscheinlichkeit im digitalen Geschä.

Niedrige Grenzkosten sind der Schlüsselfaktor im Webewerb.

Viele ITFergteile

µ€

Kapitel 3 Digitale Geschäsmodelle sind NullGrenzkosten-Geschäsmodelle.

Mikrotransakonen

(Webewerbsentscheidende) Applikaonen sollten auf CloudTechnologien umgebaut werden.

Kapitel 4

Kosten nur wenn Nutzen

Globale Skalierung

Kapitel 5 Dadurch kann jedes Unternehmen digitale Null-Grenzkostengeschäsmodelle anbieten

Cloud und Soware beherrschen

Für erfolgreiche, digitale Geschäe benögt es neue Kompetenzen:

Sinkende Transakonskosten nutzen

Mit Cloud-Technologien sinken Kosten und Risiken des Outsourcings.

Unternehmen transformieren

Virtualisierungsebenen

SourcingOponen

SowareArchitektur

Prozessabläufe

Kapitel 6

Menschen & Organisaon

Kapitel 7 Unternehmen fokussieren nur noch auf ihr Kerngeschä. Es entstehen komplexe Wertschöpfungsnetzwerke.

Kapitel 8 Die disrupven Technologien erfordern verschiedene Arten der Transformaon IT-Infrastruktur

Geschäsmodell

Porolio-Ausrichtung

Abb. 9.1   Cloud-Transformation – Wie die Public Cloud Unternehmen verändert

Die Cloud ist eine solche disruptive Technologie. Sie disruptiert die klassische Unternehmens-IT, indem sie Rechenleistung, Speicher, Netzwerk und faktisch alle weiteren IT-Komponenten für eine breite Nutzergruppe auf einfache Art und Weise verfügbar macht. Diese Vereinfachung gelingt durch eine vollständige Automatisierung der Bestellund Lieferprozesse. Sind in der klassischen IT noch manuelle Schritte und somit Menschen notwendig, erfolgen in der Cloud alle kundenorientierten Prozesse automatisiert. Mit der Cloud kann die IT eines Unternehmens digitalisiert werden. Das klingt zunächst paradox, da die Produkte und Services der IT in einem Unternehmen ja bereits vor der Umstellung auf die Cloud digital sind. Das gilt aber nur auf der Ebene der Produkte, nicht auf der Ebene der Organisation der Arbeitsprozesse. Da eine schlagkräftige IT für den Betrieb von digitalen Geschäftsmodellen unerlässlich ist, kommt der Cloud im Digitalisierungsprozess eine Schlüsselrolle zu: Unternehmen, die sich der neuen

9.1  Unternehmen scheitern – auch wenn Manager scheinbar alles …

275

Personal Computer

Geschäsentwicklung

Standardisierte Kleinrechner im Massengeschä für B2B und B2C. Starke Relevanz des Betriebssystem-Geschäs. Neuer Gewinner

ManagementDilemma

Microso

Markührer

IBM

Mainframe-Computer

Wenige, stark individualisierte Großcomputer mit wenigen großen Kunden im B2B-Geschä.

Zeit

Abb. 9.2   Innovator’s Dilemma nach Clayton Christensen am Beispiel von „Mainframe Computer versus Personal Computer“

Kunde

Kunde

Applikaon Betrieb Datenbanken Infrastruktur

Klassische IT Manuelle Schrie involviert

Cloud Serverless

PaaS IaaS

Mobile

Cloud IT Digitalisierte Bestell- und Lieferprozesse

Abb. 9.3   Cloud als Digitalisierung der IT

Funktionalitäten bedienen, können schneller und günstiger als ihre Wettbewerber Geschäftsmodelle auf- und nachbauen. Sie schaffen sich dadurch relevante Wettbewerbsvorteile gegenüber Unternehmen, die klassische IT-Ansätze verfolgen (Abb. 9.3). Cloud disruptiert also nicht nur klassische IT-Unternehmen, sondern potenziell alle Anbieter von digitalen Geschäftsmodellen. Die verändernde Kraft der Cloud zu verstehen, ist somit essenziell für alle Firmen, die im digitalen Zeitalter erfolgreich ökonomisch tätig sein wollen (Abb. 9.4).

276

9  Cloud-Transformation – Wie die Public Cloud Unternehmen … Digitale Geschäsmodelle

Anwender klassischer IT z.B. Lidl, Oo, Disney

Applika­on Betrieb

Anwender von Cloud-IT

Disrupon

z.B. Amazon, Zalando, Nelix

Datenbanken

Klassische IT-Unternehmen z.B. SAP, T-Systems

Infrastruktur

Klassische IT

Disrupon

Cloud-Anbieter Cloud IT

z.B. Salesforce, AWS

Abb. 9.4   Cloud-Technologien als mehrfacher Disruptionsfaktor

9.2 Digitalisierung als bestimmender Trend der Wirtschaft Der technische Begriff der Digitalisierung bezieht sich zunächst nur auf die Umwandlung analoger in digitale Signale. Die große ökonomische Relevanz dieser Wandelbarkeit hat sich in den letzten drei Jahrzehnten erst in der Kombination mit weiteren technologischen Entwicklungen gezeigt. Der Personal Computer ermöglichte das dezentrale Arbeiten an jedem Schreibtisch eines Unternehmens. Das überall verfügbare Internet in Kombination mit dem einfach nutzbaren Smartphone führte zu neuen gesellschaftlichen Kommunikationsformen, und die einfache Verarbeitungsmöglichkeit von digitalen Daten auf allen Endgeräten führte zur Konvergenz der Medien. In Summe führt diese Entwicklung zu einer Omnipräsenz des Digitalen. Digitaltechnologien werden – soweit es der aktuelle Stand der Technik erlaubt – in allen Bereichen der Wertschöpfung eingesetzt und ersetzen menschliche Arbeitsschritte (Abb. 9.5). Wenn das eigentliche Produkt selbst nicht digitalisierbar ist, wie etwa eine Jeans oder ein Automobil, werden zumindest alle vor- und nachgelagerten Prozesse digitalisiert – beispielsweise Produktionssteuerung, Qualitätskontrolle und Vertrieb. In Fällen wie den Taxi-Services wird ein Großteil der Wertschöpfung durch digitale Plattformen wie Uber abgebildet. Dass die Kunden über die App einen einfachen Zugang zum Service haben und damit viele verwertbare Daten für die Analyse und die weitere Produktentwicklung liefern, bildet – neben der eigentlichen Taxifahrt – die Grundlage für den zukünftigen wirtschaftlichen Profit des Unternehmens.

Plaormbasierte Geschäsmodelle

Leistungsfähige digitale Endgeräte Omnipräsentes Internet Massendatenbasierte Individualisierung

Die Welt wird digital

Digitalisierung der Produkte Digitalisierung der Prozesse

Abb. 9.5   Die Digitalisierung verändert die ökonomischen Paradigmen

Zunehmende wirtschaliche Arakvität „Winner takes all“-Märkte Verändertes Risikoprofil von Invesonen

277

9.3  Grenzkosten bestimmen die Wettbewerbsfähigkeit

Moderne Fehlerkultur …

Zugang zu Risikokapital … … um risikoreiche Wachstumsphasen zu ermöglichen.

Cloud & So ware-Know-how

Digitale PlaormÖkonomie

… um Webewerbsfähigkeit im zugrundeliegenden digitalen Produkt zu erzeugen.

… um schneller neue Geschäsmodelle und Features zu probieren.

Regulatorische Möglichkeiten … … um Wertschöpfungsnetzwerk zu nutzen und datenbasierte Geschäe zu ermöglichen.

Abb. 9.6   Erfolgsfaktoren in der digitalen Welt

Die Digitalwirtschaft verändert dabei die ökonomischen Paradigmen. Globale Geschäftsmodelle für nicht-digitale Produkte sind sehr investitionsintensiv, zusätzlich müssen lokale Produktions- und Vertriebsstätten aufgebaut sowie eine aufwendige, weltweite Logistik organisiert werden. Jeder lokale Markt muss einzeln beliefert und erobert werden. Digitale Geschäfte hingegen brauchen deutlich weniger Investitionen in Produktionsstätten und Logistik. Sie nutzen bestehende Cloud-Infrastrukturen, die erst im Erfolgsfall – d. h., wenn wirklich Kunden auf die digitalen Produkte und Dienstleistungen zugreifen – bezahlt werden müssen. Höhere Investitionen sind wiederum in der Wachstumsphase eines Produkts notwendig, dann entscheidet sich nämlich, ob das Unternehmen die entscheidende Größe für einen „Winner-takes-all“-Markt erlangt. Dieses neue Risikoprofil von Digitalgeschäften verlangt andere ökonomische, kulturelle und politische Rahmenbedingungen als die klassischen, nicht-digitalen Geschäfte (s. Abb. 9.6). Unternehmen können die Chancen dieser Entwicklung deutlich besser nutzen, wenn • die Kapitalgeber risikoreiche Wachstumsphasen zulassen (Bsp.: Venture Capital), • die Nutzung bestehender IT-Infrastrukturen möglich ist (Bsp.: Public Cloud, Software-Services), • moderne Software-Architekturen und -Methoden genutzt werden (Bsp.: Microservices, DevOps), • Geschäftsmodelle schnell ausprobiert, verworfen und verbessert werden (Bsp.: Fehlerkultur, Minimum Viable Product).

9.3 Grenzkosten bestimmen die Wettbewerbsfähigkeit Grenzkosten sind jene Kosten, die einem Unternehmen für die Produktion einer zusätzlichen Einheit eines Gutes entstehen. Sie sind seit jeher einer der bestimmenden Faktoren in einem Unternehmen. In der Regel gilt: Je größer ein Unternehmen ist und je mehr Erfahrung es bei der Produktion eines Gutes besitzt, desto niedriger sind die Grenzkosten. Je niedriger die Grenzkosten sind, desto besser ist die Wettbewerbsposition. Diese kann dann genutzt werden, um entweder stärker zu wachsen oder höhere Gewinne als der Wettbewerb zu erzielen.

278

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

Der Kampf um die niedrigsten Grenzkosten hat in vielen Phasen der Weltwirtschaft immer neue Großkonzerne hervorgebracht, meist durch Unternehmenszusammenschlüsse. In der digitalen Welt hingegen können auch kleine Unternehmen sehr schnell mit sehr niedrigen Grenzkosten operieren. Dies liegt an den besonderen Eigenheiten digitaler Güter: • Die Bereitstellung erfolgt über bestehende Infrastrukturen, wie zum Beispiel die Cloud-Rechenzentren von Google und die Netzwerk-Infrastruktur der deutschen Telekom. Diese Infrastrukturen sind erst einmal vorhanden und somit grundsätzlich grenzkostenfrei. • Die Erzeugung des digitalen Gutes selbst erfolgt durch Software. Deren tatsächlicher, individueller Aufwand je Nutzung liegt im zusätzlichen Stromverbrauch je Rechenoperation. Dieser ist in den meisten Fällen sehr gering und geht faktisch gegen Null. Werden alle Prozessschritte eines Gutes, von der Herstellung über das eigentliche Produkt bis hin zum Vertrieb, digitalisiert, handelt es sich um Null-Grenzkosten-Geschäftsmodelle (Abb. 9.7) Die Musikbranche hat sich in den letzten Jahren zu einer Null-Grenzkosten-Branche entwickelt. In den 1990ern wurde zuerst die Produktion von Musik in Form der CD digitalisiert, der Vertrieb erfolgte noch physisch. Im nächsten Schritt wurde auch der Vertriebskanal digitalisiert, mit iTunes von Apple als Vorreiter. Der Anbieter von Downloads hatte jetzt schon Grenzkosten nahe Null, und mit dem Streaming-Angebot von Spotify wurden diese niedrigen Kosten auch an den Kunden weitergegeben. Die Größe des Unternehmens selbst spielt für den Erfolg des Geschäftsmodells nicht mehr die entscheidende Rolle. Die niedrigen Grenzkosten entstehen durch das Zusammenspiel der Nutzung bereits bestehender IT-Infrastrukturen (im Regelfall der Public Cloud) sowie moderner Software-Architekturen, die automatisiert global

Kosten

Durchschni skosten

Vollständige Digitalisierung CD Grenzkosten

Streaming

Produkon

Produkt

oder Dienstleistung

Verkauf

Ein Null-Grenzkosten-Geschäsmodell entsteht.

Ausbringungsmenge

Abb. 9.7   Die Entstehung von Null-Grenzkosten-Geschäftsmodellen bei gleichzeitiger Digitalisierung von Produktion, Produkt und Verkauf

9.4  Cloud als Schlüsseltechnologie der Digitalisierung

279

skalieren. Zu Beginn kleine Startups, wie beispielsweise Spotify, können somit erfolgreich weltweite Märkte erobern und die alten Geschäftsmodelle großer Unternehmen zerstören.

9.4 Cloud als Schlüsseltechnologie der Digitalisierung Die drei wichtigsten Kernprozesse der IT-Wertschöpfung sind: Software erstellen, Software betreiben und Software skalieren. In der klassischen IT sind alle drei Prozesse mit erheblichen manuellen Aufwänden verbunden: • Software erstellen: Anforderungen werden erhoben, abgestimmt und spezifiziert. Ein Projekt wird gestartet, Ressourcen allokiert und die Architektur erstellt. Dann wird die Software entwickelt, getestet, angepasst, wieder getestet und live geschaltet. • Software betreiben: Damit Software von den Anwendern benutzt werden kann, ist eine IT-Infrastruktur notwendig – also Netzwerk, Speicher und Rechenleistung. Darüber hinaus müssen Datenbanken, Betriebssysteme, Runtimes und weitere Middleware zur Verfügung gestellt werden. Die Anwendung selbst muss lauffähig gehalten und immer wieder an neue Anforderungen angepasst werden. • Software skalieren: Je nach Nutzungssituation werden zusätzliche IT-Ressourcen hinzugefügt und wieder reduziert. Je nach geografischer Verbreitung der Nutzung erfolgt dies auch global verteilt. Die meisten der geschilderten Aufgaben erfordern in der klassischen IT individuelle, menschliche Tätigkeiten. Programmierer entwickeln die Software, Tester überprüfen die Funktionsfähigkeit, Systemadministratoren stellen Infrastruktur und Middleware bereit, Betriebs-Mitarbeiter kümmern sich um Ausfallzeiten, Helpdesk-Mitarbeiter um Kundenanfragen. Die Koordination zwischen den vielen Rollen erfolgt durch Projektleiter, Service Manager und weitere Management-Funktionen. Vor allem bei Änderungen und Neuerungen ist die klassische IT daher teuer, langsam und fehleranfällig. Cloud Computing ermöglicht die Automatisierung der IT-Wertschöpfung. Der Schlüssel hierfür ist die systematische Nutzung von Programmierschnittstellen – den sogenannten APIs (Application Programming Interfaces). Über solche Schnittstellen werden IT-Leistungen durch den Kunden per Programmier-Aufruf standardisiert abrufbar (Abb. 9.8). Benötigt beispielsweise ein Entwickler für seine Software einen Server, kann er diesen per „API-Call“ mit einem einfachen Befehl aufrufen. Aus einem Prozess, der in der klassischen IT einige Tage dauert und mehrere Personen involviert, wird ein automatisierbarer Prozessschritt, der innerhalb von wenigen Minuten abgeschlossen ist. Gleiches gilt grundsätzlich für alle denkbaren IT-Komponenten, also etwa für Speicher, Netzwerk, Datenbanken und Betriebssysteme, aber auch für Gesichtserkennung, Übersetzungs-Services, Blockchain-Anwendungen oder ganze CRM-Systeme, Online-Marketing-Tools und Bürosoftware.

280

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

CloudAnwendung

Klassische Anwendung Viele Abhängigkeiten Menschliche Aufwände Kein direkter Kundennutzen Hohe Vorhaltekosten

Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher Netzwerk

Automasierte Prozesse API

API Gesichtserkennung

Fokus auf Kerngeschä

API Database 1

API

Übersetzung

IT-Fergteile ohne Invest

Database 2

Versteckte Komplexität API Network

API Storage

API Compute

API Compute

Abb. 9.8   Digitalisierung der Softwareprozesse durch Cloud

Darüber hinaus können beliebige dieser Cloud-Services einfach miteinander kombiniert und wiederum über eine API angeboten werden. Auf diese Weise entstehen schnelle, sehr leistungsfähige Wertschöpfungsnetzwerke. Nutzt eine Software die Vorteile der Cloud vollumfänglich, wird die daraus entstehende Anwendung als „Cloud Native“ bezeichnet. Die wirtschaftlichen Vorteile der Cloud lassen sich wie folgt zusammenfassen: • IT-Fertigteile: Insbesondere die Public Cloud bietet einen umfassenden Katalog an fertig nutzbaren IT-Komponenten. Auf diese Weise kann Software deutlich schneller und kostengünstiger erstellt werden. Da die Fertigteile vom Cloud-Provider gewartet werden, reduziert sich zudem der Betriebsaufwand erheblich. • Kosten erst bei Nutzung: In der klassischen IT werden IT-Komponenten vorab in der Menge der erwarteten, maximalen Nutzung gekauft. Da die durchschnittliche Auslastung der Komponenten meist deutlich unterhalb der Lastspitze liegt, werden in der Regel zu viele Ressourcen vorgehalten. Es entstehen hohe Fixkosten. Bei der cloudbasierten IT erfolgt die Abrechnung gemäß der tatsächlichen Nutzung. Lastspitzen können mithilfe kurzzeitig bereitgestellter Zusatzressourcen kurzfristig abgefangen werden. • Mikrotransaktionen: Viele Cloud-Leistungen können in sehr kleinen Mengeneinheiten konsumiert und abgerechnet werden. Bei einigen Services bedeutet dies, dass die Abrechnung gemäß dem genutzten Arbeitsspeicher und der Rechenleistung erfolgt. Die Preise liegen dann im Mikro-Cent-Bereich pro Gigabyte-Sekunde. Diese Feingranularität ermöglicht erst die niedrigen Grenzkosten bei der Skalierung der Anwendung. • Globale Skalierung: Die großen Public-Cloud-Provider haben in den vergangenen Jahren massiv in ihre globale Infrastruktur investiert. Diese kann nun von den Kunden in Mikrotransaktionen und ohne Investitionskosten genutzt werden. Eine entsprechende Cloud-Native-Architektur der Applikation vorausgesetzt, können auf diese Weise auch kleine Unternehmen in sehr kurzer Zeit globale Geschäftsmodelle ausrollen (Abb. 9.9).

9.5  Klassische Applikationen können auf Cloud-Technologien …

281

Cloud automasiert die IT Die wichgsten Chancen für Unternehmen entstehen durch …

µ€

Konkrete wirtschaliche Effekte

… die vielen IT-Fergteile

Schneller Soware entwickeln

Günsger Soware betreiben

Einfacher skalieren

… direkte Synchronisaon von Kosten und Nutzen

Weniger Fixkosten

Lastspitzen kostengünsg abfangen

Risikoarmes Ausprobieren

… die Nutzbarkeit in Mikrotransakonen

Ermöglichen Null-Grenzkosten-Geschäsmodelle Keine eigenen Invesonen notwendig

… die Möglichkeit der globalen Skalierung

Weltweite Geschäsmodelle auch für kleine Unternehmen

Abb. 9.9   Konkrete wirtschaftliche Effekte der Cloud-Transformation

9.5 Klassische Applikationen können auf Cloud-Technologien umgestellt werden Wird eine Applikation so umgestellt, dass sie die Vorteile der Cloud nativ nutzt, verändern sich die wirtschaftlichen Parameter des zugrundeliegenden Geschäftsmodells. Das ermöglicht die wirtschaftliche Disruption von Unternehmen oder ganzer Branchen. Wird beispielsweise eine einfache Website mit klassischer IT bereitgestellt, sind dafür Netzwerk, Speicher, redundante virtuelle Maschinen und eine redundante Datenbank notwendig. Diese werden in ihrem individuellen Zusammenspiel einmalig aufgebaut und bereitgehalten. Kosten entstehen für den Aufbau der System-Umgebung, für die Anschaffung der Infrastruktur sowie für den monatlichen Betrieb – unabhängig davon, ob und wie viel die Webseite wirklich genutzt wird. In dem in Abb. 9.10 gezeigten Beispiel einer durchschnittlichen Webseite entsteht ein monatlicher Fixbetrag von über 1000 EUR. Werden mehr Ressourcen benötigt, etwa für mehr Grundlast, größere Spitzenlasten oder für eine geografische Skalierung, kommt es zu einem individuellen Projekt mit mehreren involvierten Personen sowie zusätzlichen Investitionen in die Infrastruktur.

Einfache Beispiel-Webseite

Klassische IT

Nutzungsverlauf in einer Woche

Hält Ressourcen gemäß erwartetem Maximalbedarf vor. Webseite

Datenbank-Cluster Backup

Nutzung

Applikaons-Betrieb Weitere Betriebsleistungen System-Betrieb

Webseite

Ungenutzte Ressourcen Serverless

Virtuelle Maschinen Speicher Netzwerk Gesamtkosten/Monat: ~1000€ (Fix) Skalierung nach individueller Absprache

Cloud Nave Skaliert automasch gemäß der tatsächlichen Nutzung des ServerlessDienstes und des Plaorm-Services (PaaS).

Wochenverlauf

Abb. 9.10   Umstellung einer einfachen Applikation auf Cloud Native

Datenbank

Kosten je tatsächlicher Nutzung • 0,000014/GB-Sekunde Ausführungszeit • 0,169€ pro Million Ausführungen • 0,0137€ je Request Unit für Datenbank

282

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

Werden die Möglichkeiten der Cloud nativ genutzt, ergibt sich ein anderes Bild. Anstatt die komplette Wertschöpfungskette von Infrastruktur, Middleware und Anwendung aufzubauen und bereitzuhalten, nutzt der Webseiten-Betreiber lediglich einen der vorhandenen Cloud-Services. Je nach Anwendung können dies Platform-Services, Serverless oder Container-Services sein. Alle diese Services nutzen im Hintergrund ebenfalls Speicher, Netzwerk und virtuelle Maschinen. Doch diese Komplexität – einschließlich der damit verbundenen Betriebsaufwände und Bereitstellungskosten – bleibt dem Kunden verborgen. In dem hier referenzierten Beispiel wird für die Webseite ein Serverless-Service (Azure Functions) in Kombination mit einem Datenbank-Platform-Service (PaaS) genutzt. Beide erzeugen keine Fixkosten, sind global skalierbar, die Zahlung erfolgt nach tatsächlicher Nutzung und die Grenzkosten eines einzelnen Aufrufs liegen nahezu bei Null. Aus einer fixkostenorientierten, mit Investitionen verbundenen Anwendung, die bei zusätzlichem Bedarf nur aufwendig skaliert werden kann, wird nun eine investitionsfreie Anwendung mit faktisch Null-Grenzkosten. Das hier dargestellte Beispiel einer Webseite ist inzwischen zu einem „Commodity“-Gut geworden, also zu einem Gut, das frei am Markt verfügbar ist und bei dem die unterschiedlichen Anbieter transparent am Markt auftreten. Für den spezifischen Bedarf von Webseiten gibt es schon seit Jahren gute Angebote der Cloud-Provider, die Migration dorthin ist ebenfalls einfach und sicher. Die für den spezifischen Bedarf von Unternehmen entwickelten Fachanwendungen sind meistens deutlich komplizierter. Sie basieren auf alten Architektur-Konzepten (Monolithen), sind über Jahre gewachsen und mitunter schlecht dokumentiert. Dennoch sind auch dort Migrationen in Null-Grenzkosten-Architekturen möglich (Abb. 9.11). Die Cloud Provider wissen um diese Herausforderung und haben ihren IT-Baukasten entsprechend ausgebaut. Die Cloud-Transformation wird in der Regel von einem „Cloud-Solution-Architect“ konzipiert. Er analysiert die alte Anwendung und gleicht diese mit den Anforderungen aus dem Geschäftsmodell ab. Diese sind bei geschäftsmodellrelevanten Applikationen

Hohe Fixkosten

~50.000 € / Monat für Infrastruktur bei maximal 3 Mio. Transakonen (TA)

Sprungfixe Grenzkosten

zzgl. ~20.000€ für weitere 3 Mio. TA pro Monat

Lange Dauer der Skalierung

6 Wochen für Auau und Lieferung der Hardware

Höhere Durchschniskosten

Durchschniliche Gesamtkosten je Transakon 0,0339 €

Anwendung vor Transformaon

Cloud-Nave-Anwendung

Applikaon

Applikaon

Betrieb Klassische Infrastruktur Datenbanken Infrastruktur

Nutzung von Plaorm-Services

Webserver

Logic Apps

Service Bus Datenbank Firewall Storage …

Geringere Fixkosten

5 der 13 Komponenten sind fixe Kosten (~20.000 € / Monat)

Nutzungsabhängige Skalierung

Geringe Einzelkosten von 0,0027 € je TA von Beginn an

Geringere Projektkosten

Schnellere Projekte durch automasierte Bestellprozesse

Weniger Gesamtkosten

Über die gesamte Laufzeit ergibt sich ~60% Kostenredukon

Cloud Transformaon Aufwand: ~230.000 €

Abb. 9.11   Cloud-Transformation einer geschäftsmodell-relevanten Applikation

9.6  Mit Software- und Cloud-Kompetenzen wettbewerbsfähig …

283

häufig sehr individuell. In einigen Fällen geht es um Hochverfügbarkeit, in anderen um häufige Änderungen an der Benutzeroberfläche oder die weltweite Synchronisation bestimmter Daten. Die Kunst des Cloud-Solution-Architect besteht nun darin, den alten Monolithen so in voneinander entkoppelte Services aufzuteilen, dass die technischen und wirtschaftlichen Eigenschaften zu den Anforderungen des Geschäftsmodells passen. Gelingt ihm dies, entsteht eine potenziell weltweit skalierende Anwendung, die schnell und sicher um neue Features ergänzt werden kann. Die Fixkosten sind niedrig und die Grenzkosten liegen bei faktisch Null.

9.6 Mit Software- und Cloud-Kompetenzen wettbewerbsfähig für die digitalen Welt werden Die dem Geschäftsmodell zugrundeliegende Software beeinflusst die Kostenstruktur und die Leistungsfähigkeit eines digitalen Geschäftsmodells stark (s. Abb. 9.12). Der Zusammenhang ist mit dem Entwicklungs- und Herstellungsprozess in der Automobilindustrie vergleichbar: Wird ein Auto schlecht entwickelt, wird es niemals schnell fahren können. Wird es gut entwickelt, aber schlecht hergestellt, wird es zwar schnell fahren können, aber häufig ausfallen und viel Zeit in der Werkstatt verbringen. Eine Kernthese dieses Buchs ist, dass Führungskräfte in der digitalen Welt ein grundlegendes Verständnis der Software-Wertschöpfungskette haben sollten, um ihr Unternehmen digital wettbewerbsfähig zu machen und zu halten. Die Wertschöpfung beinhaltet die drei Schritte Software-Erstellung, Software-Betrieb und Software-Skalierung. Die Abfolge ist nicht linear, Software kann durchaus während des Betriebs skaliert und gleichzeitig um neue Funktionen erweitert werden. Unterhalb der Software-Wertschöpfung liegt der „Stack“, also die Infrastruktur (Netzwerk, Speicher, Rechenleistung) sowie weitere Komponenten wie Virtualisierung, Betriebssystem und Datenbanken. Soware-Wertschöpfungskee Soware erstellen

Soware betreiben Security & Integraon Runmes & Libraries Datenbanken Betriebssystem Virtualisierung Rechenleistung Speicher Netzwerk

Soware skalieren

Betroffene Webewerbsfaktoren im digitalen Geschäsmodell Erstellungskosten Erstes Projekt

Neue Funkonen

Time-to-Market Erstes Projekt

Neue Funkonen

Fehleranfälligkeit Sicherheit

Abb. 9.12   Die Software-Wertschöpfung als Faktor im digitalen Wettbewerb

284

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

Die folgenden Faktoren beeinflussen die Performanz der Software-Wertschöpfung: • Virtualisierungsebenen: Die IT-Wertschöpfung wurde durch Cloud-Technologien zunehmend virtualisiert, also von der tatsächlichen Hardware entkoppelt und Kunden automatisiert über Schnittstellen als Software-Service zugänglich gemacht. Diese Virtualisierung erzeugt auf der einen Seite Vorteile in Bezug auf Geschwindigkeit, Reproduzierbarkeit, Skalierbarkeit und Flexibilität auf höheren Ebenen des Stacks. Andererseits reduziert die mit der Automatisierung einhergehende Standardisierung auch die Flexibilität und Transparenz auf den unteren Ebenen der IT-Wertschöpfung. • Sourcing-Optionen: Cloud-Technologien beeinflussen durch die sinkenden Transaktionskosten die Make-or-Buy-Entscheidung. Es sind nun strategisch relevante Fragen zu entscheiden, ob ein Rechenzentrum weitergeführt, eine Private Cloud aufgebaut oder eine Public-Cloud-Transformation durchgeführt wird. Des Weiteren gibt es die Möglichkeit, hybride Lösungen zu erstellen, die unter dem Begriff „Multi-Cloud“ zusammengefasst werden. • Software-Architektur: Software-Architekturen haben sich seit den 1990er-Jahren relevant weiterentwickelt. Wurden in den 1990er-Jahren noch vornehmlich Client-Server-Anwendungen erstellt, entwickelte sich seit Beginn der 2000er das Mehrschicht-Modell. Dann entwickelte sich mit SOA (Service-oriented Architectures) ein Architekturmuster, das auf verteilte Systeme setzte. Aktuell werden neue Anwendungen häufig im Microservices-Modell nach den Cloud-Native-Prinzipien entwickelt. • Prozessabläufe: Software-Entwicklung, Betrieb und Skalierung sind trotz ihrer Digitalität tatsächliche, betriebswirtschaftliche Prozesse, bei denen – ähnlich der Fertigung eines Autos – Menschen, Werkzeuge, Lieferanten und Maschinen integriert funktionieren und am Ende ein Produkt erzeugen. Jener Anteil, der mit Hilfe von Tools weitestgehend automatisierbar ist, wird im Kontext von Continuous Integration und Continuous Deployment behandelt. Wie Menschen in diesem Prozess miteinander agieren, wird im Kontext von agilen Methoden wie Scrum behandelt. Als Idealbild optimaler Software-Entwicklungsprozesse dient meist die Idee des „DevOps Teams“, das sich als kleines, interdisziplinäres Team um alle Belange des ihm zugeordneten Service kümmert. • Menschen & Organisation: Je größer der Anteil der Automatisierung im Gesamtsystem ist, desto mehr Verantwortung und Einfluss kommt jenen noch verbliebenen Menschen zu, die für die Automatisierung sorgen und sie weiterentwickeln. Dies sind einerseits die Cloud-Solution-Architects als Träger des Schlüsselwissens der Cloud-Transformation. Andererseits sind es die Führungskräfte und Top-Manager, die gezwungen sind, ihre bisherigen Erfolgsmuster zu verlassen. Starre Strukturen und Silos werden ersetzt durch eine agile Haltung, das Denken in Minimum Viable Products und eine neue Fehlerkultur.

285

9.7  Sinkende Transaktionskosten ermöglichen mehr Outsourcing … Soware-Architektur

Sourcing-Oponen Private / Public / Hybrid / Mul Cloud, eigenes Rechenzentrum

Virtualisierungsebenen Klassische IT, IaaS, CaaS, PaaS, FaaS, SaaS

Architektur-Paerns, ReST-API, Cloud Nave, Sicherheit

Prozessabläufe Connuous Integraon & Deployment, Agile/Scrum, DevOps

Soware-Wertschöpfungskee Soware erstellen

Soware betreiben

Soware skalieren

Menschen & Organisaon Agile Haltung, MVP, New Work, Fachkräemangel, Feature Teams

Abb. 9.13   Relevante Einflussfaktoren auf die Performanz der Software-Wertschöpfung

Alle fünf Faktoren können die Wettbewerbsfähigkeit des digitalen Geschäftsmodells positiv wie negativ beeinflussen (Abb. 9.13). Für jeden dieser Faktoren gibt es Experten und Expertenliteratur. Daher ist die vorgenommene Aufzählung nur als Ausgangspunkt für die weitere Beschäftigung mit der Überführung und Transformation der Unternehmens-IT in die Cloud zu verstehen.

9.7 Sinkende Transaktionskosten ermöglichen mehr Outsourcing und verändern die Volkswirtschaft Transaktionskosten sind jene Kosten, die einem Unternehmen entstehen, sobald es ein Gut oder eine Dienstleistung outsourct. Es entstehen dabei Aufwände für die Anbahnung und Vereinbarung des Vertrags, für die Durchführung der externen Transaktion, für die Überwachung der Vertragsvereinbarung und die Durchsetzung von Leistungsansprüchen. Jedes Unternehmen trifft hierfür regelmäßig Make-or-Buy-Entscheidungen. Ist es in Summe (Kaufpreis + Transaktionskosten) teurer, die Leistung extern erbringen zu lassen, als sie intern selbst herzustellen, wird der Herstellungsprozess im Unternehmen aufgebaut. Je niedriger aber Kaufpreis und Transaktionskosten ausfallen, desto größer ist der Anreiz, Leistungen nicht mehr selbst zu erbringen, sondern stattdessen Lieferanten zu orchestrieren. Transaktionskosten wirken demnach für Unternehmen identitätsstiftend. Sie bilden den Kleber, der die althergebrachte Organisation zusammenhält (Abb. 9.14). Cloud-Technologien senken die Transaktionskosten relevant, denn IT-Leistungen werden über Programmierschnittstellen (APIs) automatisiert bestellt. Aufwendige Vertragsverhandlungen sind sehr selten, Kontrollen können ebenfalls optimiert werden und Durchsetzungsprobleme werden durch intelligente IT-Architekturen vermieden. Die Entwicklung von Anpassungen an bestehende Applikationen ist mit modernen Cloud-Technologien deutlich schneller und günstiger.

286

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

Unternehmen A Autohersteller

Hohe Transakonskosten halten das Unternehmen zusammen.

… desto mehr „Make“

Auto

Je höher …

Outsourcing erzeugt Transakonskosten Durch das Outsourcing entstehen Kosten für Vertragsanbahnung und Vereinbarung, Kontrolle, Durchsetzung und Anpassung.

Das Unternehmen stellt die nur aufwändig am Markt zu kaufende Leistung lieber selbst her.

… desto mehr „Buy“ Je niedriger …

Unternehmen B Reifenhersteller

Die Leistung ist einfach und sicher am Markt erhältlich, das Unternehmen entscheidet sich für das Outsourcing.

Abb. 9.14   Transaktionskosten sind der Kleber, der Unternehmen zusammenhält

Mit sinkenden Transaktionskosten durch Cloud-Technologien steigt demnach die Neigung von Unternehmen, ihre IT-Leistungen outzusourcen. Der Marktanalyst Gartner geht davon aus, dass etwa 80 % der Unternehmen ihre klassischen Rechenzentren schließen und neue Formen der automatisierten IT nutzen. Neben der Reduktion der Kapitalbindung und einem schnelleren Zugang zu Innovationen hat das Outsourcing von IT-Leistungen in die Cloud vor allem folgenden Vorteil: Unternehmen können sich mit den verbliebenen IT-Mitarbeitern auf ihre Primärprozesse fokussieren. Statt standardmäßig im Markt vorhandene Infrastruktur selbst anzuschaffen und zu warten, können die IT-Experten nun neue Anwendungen programmieren und Funktionen entwickeln, die für das Kerngeschäft wirklich notwendig sind. Die Konzentration auf das Kerngeschäft führt dazu, dass sich Unternehmen von Integratoren zu Orchestratoren wandeln. Statt einen großen Teil der Wertschöpfung selbst zu erbringen, orchestrieren sie ihr Wertschöpfungsnetzwerk. Sie werden dadurch kleiner und flexibler, können aber dank der Cloud trotzdem weltweit skalieren. In Summe entwickelt sich die Volkswirtschaft dadurch zu einer Netzwerkökonomie (Abb. 9.15).

Aus Integratoren … Unternehmen, die viele ITLeistungen selbst erbringen

… werden Orchestratoren. Unternehmen, die ihr Netzwerk orchestrieren.

Cloud-Anwendung

Klassische Anwendung Security & Integraon Runmes & Libraries Datenbanken Betriebssystem

Insgesamt entwickeln wir uns in Richtung Netzwerkökonomie.

API

API Gesichtserkennung

API Database 1

API

Übersetzung

Unternehmen fokussieren sich stark auf ihren Kern …

Database 2

Virtualisierung Rechenleistung Speicher Netzwerk

Abb. 9.15   Sinkende Transaktionskosten verändern die Unternehmenswelt

… mit komplementären, aber auch konkurrierenden Anbietern von CloudServices (Frenemies).

287

9.8  Die Cloud-Transformation betrifft alle Unternehmen …

9.8 Die Cloud-Transformation betrifft alle Unternehmen mit digitaler Wertschöpfung – auf drei unterschiedlichen Ebenen Gemäß dem „Three-Horizons“-Modell von McKinsey agieren Unternehmen in drei verschiedenen Zeithorizonten. Im ersten Horizont – der Ausblick umfasst 12 Monate – geht es darum, das Kerngeschäft profitabel aufrechtzuerhalten und auszubauen. Im dritten Horizont – mit dem Ausblick größer fünf Jahre – geht es darum, mögliche Produkte und Leistungen der Zukunft des Unternehmens zu erfinden und auszuprobieren. Der zweite Horizont umfasst die Zeit zwischen dem ersten und dritten Horizont – in der Regel also den Zeitraum von ein bis fünf Jahren in der Zukunft. In diesem Zeitraum geht es darum, mit neuen Geschäften relevant zu wachsen. Geoffrey Moore ergänzt dieses Modell um den Faktor der disruptiven Technologien. Wie von Clayton Christensen beschrieben, ist es für erfolgreiche Unternehmen besonders schwierig, disruptive Innovationen im eigenen Geschäft einzusetzen. Sie gefährden mitunter die Attraktivität des eigenen Geschäfts und sie bringen große Änderungen in Vertrieb, Marketing und Leistungserbringung mit sich. Moore hat in seinem Buch „Zone to Win“ Modellstrategien dafür entworfen, wie Unternehmen mit disruptiven Technologien umgehen sollten. Besonderen Fokus legt er dabei auf die Cloud-Technologien und die darauf basierenden Mobile-, Analytics- und Machine-Learning-Funktionen. Er identifiziert drei Ebenen, auf denen Unternehmen disruptive Technologien für sich nutzen können (Abb. 9.16). Die Möglichkeit, die Grenzkosten auf faktisch Null zu senken, ist für Moore der Hauptgrund, warum er die systematische Nutzung von Cloud-Technologien empfiehlt. Die erste Ebene der Cloud-Transformation ist die Umstellung des Infrastrukturmodells. Dabei wird innerhalb eines Unternehmens von der klassischen IT, die von vielen menschlichen Interaktionen gekennzeichnet ist, auf die automatisierte IT in der

SaaS Machine Learning Internet of Things Data Analycs Cloud Social Media Mobile

Serverless

Por olio transformieren

Vom Betriebssystem-Hersteller zum Cloud-Anbieter

Betriebsmodell modernisieren

Mit einer Mobile-App das Taxi einfacher bestellen

IaaS

Infrastruktur opmieren

Disrupve Technologie

Handlungsebene im Unternehmen

PaaS

Copyright Frank/Schumacher/Tamm

Ebenen der Disrupon nach Geoffrey Moore

Abb. 9.16   Ebenen der Disruption nach Geoffrey Moore

SAP-System in die Cloud migrieren

Beispiele

288

9  Cloud-Transformation – Wie die Public Cloud Unternehmen … Container Cloud Nave Cloud Serverless

PaaS

Microservices Automated

IaaS

Distributed

Rest API

Elasc DevOps Isolated State Loosely Coupled

Mobile

… mit modernen So wareArchitekturen und Ansätzen.

… in die Cloud … Vom klassischen Data Center …

Abb. 9.17   Infrastrukturmodell umstellen

Cloud umgestellt. Der Hauptaufwand bei dieser Umstellung liegt in der ApplikationsTransformation. Jede Applikation wird einzeln auf ihren aktuellen Status Quo sowie auf die Anforderungen aus dem Geschäft und den Aufwänden der Transformation hin analysiert. Je nachdem erfolgt eine aufwendigere Umstellung in Richtung „Cloud Native“ oder lediglich ein aufwandsarmer Austausch der Infrastruktur (s. Abb. 9.17). Die Geschäftsmodelle bleiben auf dieser Ebene erst einmal unverändert, die Veränderungen in der Architektur der Applikation verbessern aber die wirtschaftlichen Rahmenbedingungen für die darauf basierenden Geschäfte: weniger Kapitalbindung, geringere Grenzkosten, niedrigere Transaktionskosten, Fokus auf das Kerngeschäft. Auf der zweiten Ebene geht es darum, die Chancen der disruptiven Technologien für das Geschäft selbst zu nutzen. Mit den IT-Komponenten aus der Cloud können beispielsweise einfach Big-Data-Analysen durchgeführt und Machine-Learning-Modelle eingesetzt werden (s. Abb. 9.18).

Mit Fokus auf den Kunden …

... Datenanalyse und Machine Learning,…

… und interdisziplinären & agilen Teams …

Betriebsmodell modernisieren

Abb. 9.18   Betriebsmodell modernisieren

… zu global skalierenden Geschäsmodellen mit NullGrenzkosten

9.8  Die Cloud-Transformation betrifft alle Unternehmen …

289

Um im digitalen Wettbewerb mitzuhalten, reicht die Umstellung der Technologie allein nicht. Es sind zusätzliche Veränderungen in der internen Organisation des Unternehmens notwendig. Die dominierende Organisationsform der klassischen IT waren Experten-Teams, die, je nach Herausforderung, von Projekt- oder Service-Managern koordiniert wurden. Unter den veränderten Rahmenbedingungen der Cloud können agile, interdisziplinäre Teams mit viel weniger Aufwand deutlich schneller agieren. Diese Organisationsform nennt sich DevOps beziehungsweise Feature-Team. Voraussetzung für den Einsatz dieses Teams aber ist es, die relevanten Mitarbeiter tatsächlich eng in den Prozess einzubinden, da sie sonst von den bestehenden Hürden der alten Organisation ausgebremst werden. Die Herausforderung auf der dritten Ebene ist die mit Abstand größte. Es gibt dort zwei vorherrschende Situationen: • Zone Offense: Ein Unternehmen ist derart begeistert von einem disruptiven Produkt (Bsp.: Apple mit dem iphone), dass es bereit ist, den Schwerpunkt des gesamten Unternehmens auf dieses disruptive Produkt zu verlagern und für eine gewisse Zeit sogar dem aktuellen Bestandsgeschäft eine niedrigere Priorität zu geben. • Zone Defense: Hier handelt es sich um ein Unternehmen, dessen profitables Bestandsgeschäft von einer disruptiven Technologie gefährdet ist (Bsp.: IBM Mainframe-Computer). Es muss nun das bisher profitable, alte Produkt möglichst schnell mit der neuen Technologie versehen werden, damit die Bestandskunden nicht zum neuen Wettbewerber wechseln und gleichzeitig die neuen Zielgruppen erobert werden. Für eine gewisse Zeit werden die gewohnten Performance-Kennzahlen im alten Geschäft nicht haltbar sein. In beiden Fällen ist davon auszugehen, dass mit dem neuen, disruptiven Produkt ein „Tal der Tränen“ durchwandert werden muss. Moore nennt dies „J-Kurve“, in Anlehnung an die Form des Buchstabens. Der Schlüssel für den Erfolg der Transformation des Gesamtportfolios ist die richtige Prioritätensetzung zwischen den Horizonten (bzw. Zonen). Erst wenn das neue Geschäft etwa 10 % des Umsatzes der Gesamtunternehmung ausmacht, kann die Transformation als erfolgreich betrachtet und zu einem Normalzustand zurückgekehrt werden (Abb. 9.19).

Der CEO nimmt die Transforma on des Gesamtunternehmens als Führungsaufgabe an.

Die Priorisierung der Horizonte folgt den Bedingungen der Transforma on. Transformaon

Abb. 9.19   Gesamt-Portfolio transformieren

Das Tal der Tränen wird durchlaufen, bis das neue Produkt 10% des Gesamtumsatzes erreicht hat

10%

290

9  Cloud-Transformation – Wie die Public Cloud Unternehmen …

9.9 Fazit Zusammengefasst verbirgt sich hinter der Cloud-Transformation eines Unternehmens deutlich mehr als die inflationäre Verwendung der zugehörigen Buzzwords in Management-Meetings ahnen lässt. Die Überführung der klassischen IT in eine Cloud-Native-Architektur wird zur Voraussetzung, um ein Unternehmen auf die digitale Zukunft auszurichten. Ein historischer Vergleich macht das noch deutlicher. Die Überführung von OnPrem-IT-Systemen aus dem Unternehmen in die Cloud ist ähnlich revolutionär wie das Anschließen von Unternehmen an das öffentliche Stromnetz zu Beginn des 20. Jahrhunderts. Die Parallelen zwischen diesen beiden Infrastrukturrevolutionen sind frappant. Stellen Sie es sich bildlich vor: Bevor es die Stromnetze gab, standen in den Unternehmen riesige Dampfmaschinen, die ständig befeuert werden mussten, damit mit dem Wasserdampf die Kolben angetrieben werden konnten. So entstand mechanische Energie, die für die Fertigung von Waren wie beispielsweise Textilien eingesetzt wurde. Allein die Wartungsaufgaben waren immens. Das Unternehmen war als Betreiber der Dampfmaschinen dafür verantwortlich, dass die Fertigungsanlagen permanent mit mechanischer Energie versorgt wurden. Zu diesem Zweck engagierten die Unternehmer Spezialisten, die sich um nichts anderes als die Wartung und den Betrieb der Dampfmaschinen kümmerten. Wenn Sie einen Unternehmer zu dieser Zeit gefragt hätten, ob er sich vorstellen könne, seine Fabrik an das elektrische Stromnetz anzuschließen, hätte er sicherlich vehement widersprochen. Einen dezentralen Dienst in Anspruch nehmen? Und dann auch noch dafür bezahlen? Undenkbar. Die Maschinen sind doch da und funktionieren. Es musste erst eine neue Generation von Unternehmenslenkern die Geschäfte übernehmen, bevor sich die Nutzung des Stromnetzes in den Fabrikhallen in Europa und den USA durchsetzen konnte. Die Vorteile waren gewaltig. Denn dank Stromnetz mussten sich die Unternehmen keine Gedanken mehr um die Energieversorgung machen. Diese Dienstleistung wurde nun zentral von einem Drittanbieter, den Stromproduzenten bzw. -kraftwerken erbracht. Die Fertigungsanlagen verbrauchten in der Folge nur noch so viel Strom, wie sie benötigten und die Ineffizienz bei der Herstellung von Energie fiel mit einem Schlag weg. Und das Beste: Das Stromnetz war viel zuverlässiger als die eigenen Wartungsleute, die den Betrieb der Dampfmaschinen überwachten. Sie erkennen die Parallelen? Richtig. Eine ähnliche Transformation wiederholt sich gerade beim Übergang in die Public Cloud. Die Entscheidung für oder gegen den Einstieg in die Public Cloud ist eine Entscheidung mit großer Tragweite. Wird dieser Schritt nicht gewagt, könnten die Folgen gravierend sein. Im schlimmsten Fall verschwindet das Unternehmen in den Annalen der Wirtschaftsgeschichte. Dann wird sich die Frage stellen: „Erinnern Sie sich noch an Unternehmen X?“ Wird der Schritt aber gewagt, sollten sich die verantwortlichen Manager darauf einstellen, dass in der Organisation kein Stein auf dem anderen bleibt.

Stichwortverzeichnis

A Abrechnung, nutzungsbasierte, 100 Abstraktion, 103, 155 Administrationskosten, 214 Agilität, 169 AI s. Artificial Intelligence Analytics, 107 Anpassungskosten, 217 API s. Application Programming Interface Application Programming Interface, 99, 100, 155, 177, 279 API-Manifest, 102 Artificial Intelligence, 107 Automatisierung, 200 Autoscaling, 136

Cloud-Native-Architektur, 165 Cloud-Solution-Architect, 135 Cloud-Strategie-Team, 230 Cloud-Transformation, 135, 225, 287 Ebenen, 229 Compliance, 239 Container, 106, 156 Continuous Deployment, 174 Continuous Integration, 174 Core Assets, 208 Cost-Income-Ratio, 66

B Betriebskosten, 139 Betriebsmodell, 244 Big Bang, 235 Big Data, 29, 107 BizDevOps s. Feature-Team Blockchain, 108 Boston-Consulting-Matrix, 51 Bottleneck, 154

D Daily Scrum, 172 Data Leveraging, 30 Datenanalyse, 249 DDoS-Attacke, 115 Dedicated IT, 105 Designed for failure, 248 Design Thinking, 41 DevOps, 169, 176, 284 Digitalisierung, technische, 15 Dilemma-Analyse, 227 Durchschnittskosten, 134 Durchsetzungskosten, 217

C CAP-Theorem, 164 Change-Mentalität, 40 Chaos Monkey, 248 Chapters, 185 Client-Server-Architektur, 161 Cloud, 96

E Elastic, 166 Encryption, 239 Entscheidungskosten, 213, 216 Entwicklungssprint, 172 Entwicklungsteam, 171 Erfahrungskurve, 51, 194

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 R. Frank et al., Cloud-Transformation, https://doi.org/10.1007/978-3-658-27325-5

291

292 F Feature-Team, 176, 253 Frenemies, 219 Führung, 258 Function-as-a-Service, 106

G Geschäftsmodell, 258 Governance, 239 Graphical User Interface, 99 GRC-Programm, 239 Grenzkosten, 51, 56, 134, 277 Grenzkostenanalyse, 54 Grenzkostenkurve, 52 GUI s. Graphical User Interface

H Hardware, 91, 111 Hybrid Cloud, 159 Hyperscaler, 7, 219

I IaaS s. Infrastructure-as-a-Service Identitätsmanagement, 116, 118 Identity Management, 239 IKEA-Kosten, 193 Individualisierbarkeit, 37 Informationskosten, 212, 215 Information Technology Infrastructure Library, 92 Infrastructure-as-a-Code, 150 Infrastructure-as-a-Service, 106, 112, 156, 207 Infrastrukturmodell, 233 Innovator’s Dilemma, 2, 229 Insourcing, 206, 219 Integrator, 195 Intelligenz, künstliche, 78, 251 Internet der Dinge, 108 IT Betrieb, klassischer, 90 Fertigteil, 100, 103, 280 Landschaft, 238 Prozess cloudbasierter, 109 klassischer, 86 Wertschöpfung, 279

Stichwortverzeichnis K Kernkompetenz, 208 Kommunikationskosten, 199 Kontrollkosten, 214, 217 Konvergenz, 21 Kundenfokus, 250

L Lastschwankung, 247 Layer Player, 195 Log & Report, 239 Loosely coupled, 166 Loyalty Loop, 30

M Machine Learning, 27, 32, 107, 251 Make-or-Buy-Entscheidung, 158, 206, 284 Mandantentrennung, 116, 129 Mehrschicht-Architektur, 161 Microservice, 163, 247, 284 Migration, 241 Szenario, 233 Mikrotransaktion, 100, 103, 165, 280 Minimum Viable Product, 36, 149, 171, 284 Mitarbeiterführung, 179 Monolith, 152, 282 Monopolbildung, 34 Multi-Cloud, 159 Multi-Factor Authentication, 118 MVP s. Minimum Viable Product

N Negative Cashflow, 37 Netzwerkeffekt, 33, 36 Netzwerkökonomie, 218 Null-Grenzkosten-Geschäftsmodell, 57

O Ökosystem, digitales, 37 On-Premises-System, 91 Orchestrator, 195 Outsourcing, 206, 219

Stichwortverzeichnis P PaaS s. Platform-as-a-Service Pivoting, 40 Platform-as-a-Service, 106, 156, 207 Plattform, digitale, 25 Plattformökonomie, 24 Portfoliotheorie von Markowitz, 38 Preemptive Shipping, 32 Private Cloud, 112, 113, 159 Product Backlog, 173 Increment, 173 Owner, 171 Public Cloud, 112, 113, 159

R Rebuild, 235, 246 Refactor, 234, 246 Rehost, 136, 234, 245 Remain, 245 Replace, 234, 245 Resilience, 166 Retire, 245 Revise, 234, 246 Rightsizing, 247

S SaaS s. Software-as-a-Service Scrum, 171, 284 Master, 172 Server, virtueller, 94 Serverless, 106, 156 Service Level Agreement, 89 Oriented Architecture, 162 verteilter, 165 Sicherheit, 114 Silo-Denken, 178 Simple Object Access Protocol, 162 Sizing, 91 Skaleneffekt, 51, 75, 110, 192 Skalierung, globale, 100, 280 Software, 86, 149 Architektur, 161, 284 monolithische, 161 Betrieb, 88, 110 Defined Network, 239

293 Entwicklung, agile, 170 Erstellung, 86, 109 Skalierung, 92, 111 Software-as-a-Service, 7, 108, 156, 207, 215 Sourcing-Option, 158 Sprint, 41 Backlog, 173 Planning, 172 Retrospective, 172 Review, 172 Squads, 184 Stack, 93, 150, 167, 213, 283 Stateless, 166 Subadditivität, 76, 195 System, verteiltes, 163

T Taylorismus, 96 Technologie aufrechterhaltende, 3 disruptive, 3 Three Horizons of Growth, 226 Time-to-Market, 38 Toolchain, 239 Transaktionskosten, 189, 207, 215, 285 interne, 192 Transformation, digitale, 150, 225 Tribes, 185 Two-sided Market, 34

U Unternehmenskultur, 254

V Verbundeffekt, 75 Virtualisierung, 94, 103, 155 Virtualisierungsebene, 155 Virtualized IT, 105 Virtual Machines, 131

W Wahrnehmungsschwelle, 206 Wasserfallmodell, 87, 169 Wertschöpfungskette, 62, 189

294 Z Zentauren-Team, 81 Zone Defense, 260, 289

Stichwortverzeichnis Offense, 259, 289 to win, 226 Zwilling, digitaler, 23