Mensch und Maschine – Mitarbeiter und Technologie als Treiber des Plattformerfolgs

Unsere Serie zu Plattformen und Ökosystemen ist mit den ersten drei Artikeln zu den grundlegenden Eigenschaften, Kernerfolgsfaktoren und notwendigen Prozessen gestartet.

In diesem vierten Artikel stehen zwei weitere Aspekte erfolgskritischer Enabler im Fokus: „Mitarbeiter“ mit den zwei Handlungsfeldern Agilität/Flexibilität (13) und Skill/Mindset (14) sowie „Technik“ mit den drei Handlungsfeldern Open Architecture (15), Data Analytics/KI (16) und Integrationsschicht (17).

Bisher haben wir über die fachlich prozessualen Erfolgsfaktoren, die Kernfaktoren und die Rahmenbedingungen eines plattformbasierten Ökosystems gesprochen. Ein Unternehmen wird aber nur in der Lage sein, diese Erfolgsfaktoren dauerhaft umzusetzen, wenn Organisation und Mitarbeiter sich daran ausrichten und dem Ganzen eine zielführende, dynamische IT in optimaler Balance aus Cloud- und Edge-Computing unter Nutzung von modernen Algorithmen und Verfahren der KI zugrunde liegt. Einige wesentliche Aspekte werden nachstehend angerissen.

13. Agilität / Flexibilität                                               

Ein plattformbasiertes Geschäftsmodell ist nie im Stillstand. Es gilt die Plattform stetig entlang von Erkenntnissen des Status Quo, den aktuellen und prognostizierten Kundenbedürfnissen, Marktentwicklungen und unter Berücksichtigung des technischen Fortschritts weiterzuentwickeln und den Reifegrad zu erhöhen. Damit eine Organisation diesem stetigen Wandel gewachsen ist, stellt dies grundlegende Anforderungen an die Organisation selbst. Ein Unternehmen, welches erfolgreich eine Plattform aufbauen und betreiben will, muss im Kern seines Wesens agil sein. In diesem Kontext sind zwei Erkenntnisse wichtig. Erstens: ein bloßer werbewirksamer agiler Anstrich des Unternehmens alleine wird nicht reichen. Zweitens: es gibt kein komplett agil arbeitendes Unternehmen.¹

Agilität ist aktuell in aller Munde. Bevor wir die Anforderungen an eine agile Organisation skizzieren, möchten wir einen Schritt zurücktreten und uns darauf besinnen, was Agilität eigentlich bedeutet. Das Wort „agil“ stammt vom lateinischen „agilis“ ab und bedeutet beweglich, schnell, regsam, wendig. Ursprünglich in den frühen 2000ern für die Anforderungen an moderne Softwareentwicklung genutzt, formuliert der Begriff „agil“ heute einen allumfassenden Anspruch an Organisationen im Ganzen. Getrieben durch eine sich stetig verändernde „VUKA-Welt“ (Volatilität, Unsicherheit, Komplexität und Ambivalenz/Ambiguität) sind nicht nur Programmierer, sondern ganze Unternehmen gezwungen, neue Wege zu gehen. Grundlegende, dafür notwendige Werte sind im Agilen Manifest verankert.² Dieses beschreibt Leitsätze und Werte agiler Teams. Möchte man diese wahrhaft anwenden und den Wortsinn „agil“ tatsächlich erreichen, stellt man schnell fest, dass, um die Ambition „agil“ tatsächlich zu erreichen, weit mehr passieren muss als das bloße „Umklappen“ der Aufbauorganisation oder das Einführen eines Kanban-Boards. Agilität muss sich auf allen Ebenen des Unternehmens wiederfinden und ein kohärentes Gesamtgefüge schaffen. So entsteht der organisatorische und kulturelle Rahmen, in dem Mitarbeiter „by design“ Agilität leben und eine Organisation „truly agile“ ist.

In der weiteren Diskussion beleuchten wir exemplarisch vier Unternehmensbereiche (siehe Abbildung) und wie sich Agilität dort widerspiegelt. Erster Baustein ist die grundlegende Struktur der Organisation und Allokation von Verantwortlichkeiten. Hier stehen vor allem die beiden nachstehenden Fragen im Fokus: Ermöglicht die Aufbauorganisation die Übernahme von Ende-zu-Ende-Verantwortung und gibt es die entsprechenden Entscheidungskompetenzen, diese Verantwortung auch wahrzunehmen? Fast zehn Jahre nach der Publikation ist das Spotify-Modell nach wie vor die wohl meistreferenzierte agile Aufbauorganisation, aber es gibt viele weitere Ansätze. Spannend und besonders lehrreich sind sicher solche Transformationsprozesse, bei denen auf etablierten eher wasserfallartigen Strukturen aufgesetzt und eine konsequente agile Ausrichtung vorgenommen wurde. Die „richtige“ organisatorische Aufstellung, um Agilität zu ermöglichen, ist dabei individuell und muss jedes Unternehmen für sich finden.

Zweiter Baustein einer agilen Organisation ist der Aspekt Steuerung. Hier gilt es vor allem mit folgenden Fragestellungen umzugehen: Nach welchem Zyklus laufen Gremien und Budgetvergaben ab? Sind Anpassungen innerhalb einer Planungsperiode möglich? Für ein Geschäftsmodell im kontinuierlichen Wandel ist eine laufende, adaptive Steuerung unabdingbar. Linkedin steuert seit mehreren Jahren unterjährig bspw. mit Quarterly Business Reviews. Objectives und Key Results (OKR) gehören inzwischen zum Standard-Repertoire agiler Organisationen.

Dritter Bestandteil sind Technologie und Infrastruktur. Kurze Release-Zyklen, DevOps und die enge Zusammenarbeit von Fachseite und IT sollten inzwischen eine Selbstverständlichkeit sein und sind die Voraussetzung dafür, dass die technischen Erfolgsfaktoren aus dem Kapitel Technik angewendet werden können. Amazon Web Services kann hier mit der Weiterentwicklung seiner Cloud Services als Paradebeispiel genannt werden.

Struktur, Steuerung und Technologie schaffen die Voraussetzungen, in welchen letztendlich die Mitarbeiter ihren Beitrag leisten. Anspruch an die Mitarbeiter wiederum ist, dass diese agile Methoden anwenden und die ihnen übertragene Ende-zu-Ende-Verantwortung mit Leben füllen.

14. Skills / Mindset

Neben der Aufbau- und Ablauforganisation, in welcher die Mitarbeiter wirken, sind die Skills und das Mindset der Mitarbeiter selbst von entscheidender Bedeutung. Neben den klassischen, fachlichen Anforderungen an ihre jeweilige Rolle müssen Mitarbeiter die Wirkzusammenhänge eines plattformbasierten Geschäftsmodells verinnerlicht haben. Was auf den ersten Blick trivial klingen mag, ist in der Realität alles andere als einfach. Plattformen mit ihren multi-sided Geschäftsbeziehungen sind deutlich komplexer im Management als klassische Pipeline-Geschäftsmodelle. Infolgedessen sind Ursache-Wirkungs-Beziehungen schwieriger zu identifizieren und komplexer in der Handhabung. So kann z.B. die Anpassung der Matchmaking-Logik zwischen zwei Parteien weitreichende Konsequenzen für eine dritte Gruppe haben und so müssen Auswirkungen stets ganzheitlich durchdacht werden. Das notwendige Skillset der Mitarbeiter gilt es somit kontinuierlich auszubauen. Hierbei werden absehbar Data Analytics Teams allein nicht ausreichen, den Wert der auf Plattformen auflaufenden Vielzahl an Daten auch tatsächlich auszuschöpfen. Plattformen sind zwar meistens reich an Daten, jedoch wird sich der Wert erst über Investitionen in Training und Skill-Entwicklung materialisieren. Fortlaufende Innovationen im Bereich KI werden Plattformen verstärkt zwingen, datengetriebene Innovationen als Kern zukünftiger Geschäftsentwicklung zu begreifen. Da datenaffine Mitarbeiter so strategisch wichtig für die Weiterentwicklung des Geschäftsmodells sind, baut Airnbnb eine eigene „Data University“ auf. Ziel ist es, die über 3.000 Mitarbeiter zu befähigen, datengestützte Entscheidungen zu treffen und das unabhängig von Rollen und Teamzuordnungen, sondern diese Fähigkeit in der ganzen Organisation aufzubauen.³ Wichtige Bausteine dafür sind die in agilen Organisationen verankerten Experimente sowie der cross-funktionale Knowhow-Austausch und -Transfer.

Neben dem fachlichen Skillset ist auch das Mindset der Mitarbeiter entscheidend. Für das erfolgreiche Anwenden von agilen Methoden und die Übernahme von Ende-zu-Ende-Verantwortungen müssen Mitarbeiter die agilen Werte verinnerlicht haben und tatsächlich leben. Diese reichen von einer konstruktiven Fehlerkultur („Trial-and-Error“) bis zu Servant Leadership.

Darüber hinaus darf eine Sache niemals fehlen – der Kundenfokus! Erfolgreiche Plattformunternehmen stellen ihre Kunden konsequent und über das reine Lippenbekenntnis hinaus ins Zentrum und gehen für diesen die Extra-Meile. Denn Kunden sind letztendlich die Daseinsberechtigung für das Unternehmen. Und dass hinter dem Primat der Kundenorientierung auch handfeste ökonomische Vorteile stehen, zeigen zufriedene Kunden jeden Tag, denn sie sind loyaler und empfehlen häufiger. Ein herausragendes Beispiel hierfür ist der amerikanische Online-Modehändler Zappos. Zappos stellt sich explizit in den Dienst der Kunden und verankert dies tief in der Unternehmenskultur. Diese besteht insbesondere darin, dass die Interaktion mit dem Kunden vor allem dazu dient, Kundenbeziehungen aufzubauen und nicht dem Kunden etwas zu verkaufen. Dass dies von den Mitarbeitern sehr ernst genommen wird, beweist der längste Kundenservice-Call der Zappos-Geschichte: 10 Stunden und 51 Minuten! Übrigens kein Ausreißer: der bisherige Rekord lag bei 10 Stunden und 43 Minuten.⁴

15. Open Architecture

Im Bereich Technik möchten wir vor der Erläuterung der technischen Erfolgsfaktoren noch Erfahrungen aus zahlreichen Plattform-/Ökosystemprojekten in Unternehmen aus unterschiedlichsten Sektoren eine eindrückliche Warnung voranstellen: Der Bereich Technik ermöglicht zwar den Aufbau und Betrieb eines Plattformkonzeptes.  Auch können Fehler und Versäumnisse im Bereich Technik die Betriebs- und Ausbaukosten eines Plattformkonzeptes negativ beeinflussen. Aber niemals kompensiert eine noch so überzeugende Kombination aus Architektur und Analytics existente Schwächen und Lücken im Kern des Plattformkonzeptes. Gerade bislang erfolgreiche Pipeline-Unternehmen haben oftmals Schwierigkeiten mit der Herausforderung, ihr Portfolio, ihre Netzwerke und ihre internen Organisationsstrukturen in Richtung Plattformunternehmen zu transformieren. Als „Placebo für den Aufsichtsrat“ wird dann nur allzu häufig darauf verwiesen, dass man immerhin in der Anbieter- und Werkzeugauswahl weit fortgeschritten sei und die Plattform in wenigen Monaten technisch verfügbar sein werde. Die hiermit verbundenen technischen Kosten („Bereits 4 Millionen im Q2 2020 für Digitalisierung eingeplant!“) sollten niemals als Indikator für die Bereitschaft eines Unternehmens missverstanden werden, sich in Richtung Plattformunternehmen zu wandeln. Ein kurzes Gedankenexperiment verdeutlicht dies anschaulich. Wenn im Zuge des oft befürchteten Einstiegs von Amazon in den deutschen Versicherungsmarkt Amazon einen beliebigen deutschen KFZ-Versicherer kaufen und ausschließlich dessen KFZ-Policen auf der technisch überzeugenden Amazon-Plattform eingebettet in die kundenorientierte Servicekultur anbieten würde, würden Sie dann dort kaufen oder doch lieber weiter auf Vergleichsportalen wie Check24 recherchieren?

Zusammen mit dieser eher nüchternen Einordnung der Bedeutung von Technik für den Plattformerfolg kann konstatiert werden, dass die allermeisten Plattformvorhaben keine großen technischen Herausforderungen darstellen, solange nicht ambitionierte Nahe-Echtzeitverarbeitungen von Millionen IOT-Devices im Fokus stehen. Cloud-Technologien, Load-Balancer, Datenbanken und App-Entwicklungsframeworks sind mittlerweile so ausgereift, dass rein technisch eher überschaubare Probleme zu lösen sind.

Die Ansätze einer Open Architecture oder einer Open-API-Entwicklung für Ihre Plattform zielen daher auch eher darauf ab, die Plattformkunden und -anbieter über so viele technische Kanäle wie möglich erreichen bzw. anbinden zu können (externe Sicht) und kostspielige Vendor-Lock-Ins in allen Bereichen zu vermeiden (interne Sicht).

Für eine externe Sicht bspw. im Kontext „Mobility“ heißt dies nicht nur, dass für Plattformlösungen auf jeden Fall App-Schnittstellen für die dominanten Anbieter Apple und Google entwickelt werden sollten, sondern technisch wie kommerziell weitergedacht werden muss. Eine technische Weiterentwicklung wäre es, in die jeweiligen Apps auch die „Im-Auto-Darstellungen“ Apple CarPlay oder Android Auto zu integrieren, um den Kunden auch während der Fahrt oder im Stau zu erreichen, ohne dass hierzu die API-Schnittstellen der Plattform verändert werden müsste. Eine radikale kommerzielle Weiterentwicklung haben z.B. die Londoner Verkehrsbetriebe realisiert, die über API-Schnittstellen die zentralen Dienste ihrer Plattform den zahlreichen Entwicklern von verkehrsträgerübergreifenden Mobilitäts-Apps zur Verfügung stellen.^5­

Kann über derartige Lösungen und Kanäle eine Kunden- und Marktabdeckung erreicht werden, die einer Eigenentwicklung sogar überlegen ist, dann scheint eine kostenintensive Selbstentwicklung der Apps für die externe Sicht auf die Plattform entbehrlich.

In der internen Sicht vermeidet eine offene Architektur mit einem konsequenten Fokus auf funktionale Blackboxes, die über offene Schnittstellen (APIs) angesprochen werden, zuverlässig eine zu große Abhängigkeit von Vendoren und deren Lizenzmodellen. Zwei Aspekte verdienen in diesem Kontext eine besondere Würdigung. Erstens impliziert die Forderung nach offenen Schnittstellen („Wie können Funktionen aufgerufen werden?“) nicht automatisch eine Realisierung der Funktionen in Open Source. Viele kommerzielle Lösungen integrieren eine ganze Reihe von Open Source-Elementen zu einer Gesamtlösung. Die Lizenzgebühren werden dann unter anderem dafür erhoben, dass der kommerzielle Anbieter die Open Source-Komponenten ständig integriert und orchestriert. Setzt ein Unternehmen die Open Source-Komponenten direkt ein, so ist zwar der Bezug unentgeltlich, aber die Wartung und Pflege muss dann zu internen oder externen Kostensätzen selbst geleistet werden. Hier sollte nüchtern und undogmatisch eine Analyse von Kosten/Nutzen und der gewünschten „Fertigungstiefe“ im Bereich der IT durchgeführt werden.

Zweitens sollte die Forderung nach offenen Schnittstellen zur Förderung der Interoperabilität und der grundsätzlichen Austauschbarkeit auch für alle Softwarekomponenten gelten, die von unternehmensinternen Abteilungen entwickelt werden. Hierauf wies schon 2002 in aller Eindrücklichkeit der Amazon Gründer Jeff Bezos hin.

Oftmals erweisen sich in Konzernen gerade etablierte Kernsysteme und deren aufwändige Wartung und Pflege als Stolpersteine.  Es ist nahezu unmöglich, ein neues Plattformerlebnis vor Kunde zu realisieren, wenn die sicherlich unangenehmen und aufwändigen Ablösungen oder Refactorings der Altsysteme nicht angegangen werden. Ein Kunde einer KFZ-Versicherung, der über automobile Apps oder Digitale Assistenten mit den neuen Plattformdiensten zu Reparatur, Mietwagen und Hotel selbst im Auto erreicht, wird wenig Verständnis dafür haben, dass im Pannenfall im Regen die Entscheidung über Abschleppservice, Mietwagen und Hotel erst morgen früh erfolgt, wenn das Kernsystem der Versicherung seinen Batchdurchlauf beendet hat.

Eine offene Architektur muss konsequent auch für die intern erstellten Komponenten gelten und wird daher technisch wie organisatorisch sicherlich zu Umstellungen im Unternehmen führen müssen. Hat man jedoch diese technische Offenheit und Interoperabilität einmal erreicht, dann eröffnen sich im Umkehrschluss auch ganz neue Möglichkeiten, das Plattformmodell anders zu denken.

Ein Autohersteller, der beispielsweise über sichere Schnittstellen im Auto und außerhalb des Autos alle Arbeiten für Wartung und Inspektion, vom Reifenwechsel über ein Softwareupdate bis zum Austausch eines elektronischen Steuergerätes von allen von ihm zertifizierten Werkstätten durchführen lassen kann, muss nicht notwendigerweise mehr ein eigenes Werkstattnetz unterhalten, um im Aftermarket profitabel zu sein. Eventuell ermöglichen Transaktionszahlungen für jede Reparatur/Wartung am Fahrzeug von allen Parteien – freien wie markengebundenen Werkstätten – ein lukrativeres Betriebsmodell für den Fahrzeughersteller als Anbieter der Plattform Automobil.

16. Data Analytics / KI

Bei den Themen Data Analytics oder künstlicher Intelligenz handelt es sich keinesfalls um brandneue Technologien, vielmehr sind die Grundlagen hierzu oft schon in der ersten Hälfte des letzten Jahrhunderts gelegt worden. Die bekannte Hebb’sche Lernregel⁶ für künstliche Neuronale Netze zur Mustererkennung datiert z.B. in das Jahr 1949. Mustererkennung und Clusterbildung zählen im Kontext der Plattformen und Ökosysteme auch heute noch zu den häufigsten Anwendungsfällen von KI. Basierend auf seinem bisherigen Verhalten auf der Plattform/im Ökosystem werden Nutzer in Kundengruppen segmentiert, werden Ansprachen individualisiert, neue Aktionen (Next Best Action) oder neue Käufe vorgeschlagen („Kunden, die dieses Produkt erwarben, kauften auch...”). Diese Empfehlungen sind Ihnen bestimmt auch schon begegnet.

Technologisch gesehen haben sich seit dem letzten Jahrhundert nicht so sehr die eigentlichen KI-Verfahren weiterentwickelt. Der technische Fortschritt sorgte aber dafür, dass die Menge an elektronisch analysierbaren Daten ständig wuchs und die Berechnungszeit für die teilweise sehr aufwändigen KI-Algorithmen zunehmend bereits eine Anwendung innerhalb der Plattformprozesse der Kunden zulässt. Eine Mail mit einer Cross-/Upselling-Empfehlung einen Tag nach dem Kauf bei Amazon würde sicherlich deutlich weniger Kunden zum erneuten Aufsuchen der Plattform und Kauf bewegen als die eingeblendeten Empfehlungen direkt während des Einkaufs.

Für die Effektivität der KI im Hinblick auf den (kommerziellen) Erfolg ist meist weniger der eigentliche KI-Algorithmus entscheidend, sondern die Menge der beobachtbaren Transaktionen, auf denen die Mustererkennung basiert und anhand derer sie ständig weiterentwickelt wird. Ein einfaches Beispiel für die Trainingshäufigkeit: Dass die Spracherkennung in einem KFZ eines deutschen Herstellers oft hinter den Erkennungsraten bei Google/Apple zurückbleibt, kann schlicht daran liegen, dass die Nutzerzahl und Spracheingaben bei Google auch noch für die seltensten Dialekte um Faktoren höher liegt als beim einzelnen Hersteller, auch wenn beide die exakt gleichen Algorithmen einsetzen.

Noch wichtiger als die Nutzungshäufigkeit derselben Plattformservices (Spracherkennung) ist jedoch, wie viele Informationen eine Plattform über den Nutzer sammeln kann, welche Alltags- oder Lebenssituationen sie abdeckt.

Um mit einem plakativen Gegenbeispiel zu starten: Wenn eine Versicherung lediglich ihre aktuelle Produktwelt aus Krankenversicherung, Lebensversicherung und KFZ-Versicherung auf einer „Plattform” anbietet, wird der Kunde diese Plattform im Schnitt etwa einmal im Jahr besuchen, um Schadensfälle zu melden oder sich wegen einer Beitragsanpassung nach Alternativen umzusehen. Ohne vertiefte Analyse dürfte offensichtlich sein, dass auch die beste KI mit diesen wenigen Informationen und einem ohnehin überschaubaren Angebot an Kaufoptionen nur geringe Chancen hat, Kunden zum Cross-Selling zu bewegen („Kunden, die diese KFZ-Versicherung erwarben, schlossen auch folgende Krankenversicherung ab!”).

Anders stellt sich die Situation für einen Kranken- oder Unfallversicherer dar, der seine Kunden begleitet durch kostenlose Online-Trainingspläne, Live-Tracking der Sportaktivitäten, Ausgabe von Ernährungsplänen und Kooperationen mit (Bio-)-Supermärkten, in denen diese Nahrungsmittel rabattiert gekauft werden können. Jetzt haben die KI-Algorithmen genug Informationen, um effektiv unterschiedliche Gruppen in unterschiedlichen Kontexten Empfehlungen geben zu können. Dabei sollte jedoch grundsätzlich der Versuchung widerstanden werden, dem Kunden als direkte Reaktion auf die Überwachung eine Plattformleistung zu verkaufen („Wir haben erkannt, Sie fahren gerade Ski: haben Sie an Ihre Unfallversicherung gedacht?”) oder eine direkte Rabattierung in Aussicht zu stellen, wie bei einem „Pay How You Drive-Tarif" („Bei dieser Fahrt haben Sie wegen zu hoher Beschleunigung leider nur 2 von 5 Sternen erzielt, Ihre Prämie für den Tag erhöht sich auf 1,70 €.”). Die wenigsten Plattformkunden möchten so unmittelbar erfahren, dass sie begleitet bzw. überwacht werden.

Empfehlenswerter sind deshalb KI-Empfehlungen an den Kunden, die eher indirekt wirken. Ein Kunde, bei dem ständig ein Schlaf- und Bewegungsdefizit diagnostiziert wird, kann evtl. durch Empfehlungen in Trainingsgruppen, vergünstigte Sportangebote oder Online-Wettbewerbe dazu bewogen werden, mehr für seine Gesundheit zu tun, was mittelbar die Krankheitskosten senkt. In Richtung Versicherer würde man bei einem KFZ-Kunden im Schadensfall das beobachtete Fahrverhalten auch nur als ein weiteres Kriterium neben etablierten Kriterien in der Überlegung heranziehen, ob vom Sonderkündigungsrecht Gebrauch gemacht werden soll.

Leider verhindern oft vorhandene Strukturen und zu kurz gedachte Prozesse bzw. unrealistische (und vielfach unsinnige) ROI-Zeiten in Unternehmen diese konsequente Ausrichtung eines Ökosystems am Nutzer. Sind die Aufwände für den Aufbau der obigen, fiktiven Plattform „Aktives Leben” bei dem beteiligten Versicherer Marketingaufwände oder Vertriebsaufwände? Welcher Vorstand ist hier „im Lead”? Können die Mitarbeiter der Abteilung „Leistungsabwicklung” überhaupt Empfehlungen rund um Trainingspläne geben? Wer sucht die Partner aus? Wie sehen Monetarisierungskonzepte im Zeitablauf aus? Was sind realistische Zeiträume für zugrundeliegende Business Cases und wie passen ggf. abweichende Betrachtungszeiten zur bestehenden Reportinglogik? Wer verantwortet diese?

Im Angesicht der nötigen Umstrukturierungen und der Erkenntnis, dass die bestehenden pipelineorientierten Geschäftsmodelle nicht tragen, werden dann wirklich nachhaltige und konsequente Plattformkonzepte nur von wenigen Unternehmen weiterverfolgt. Kurzfristig scheint der Aufwand zu hoch. Und insgesamt auch alles zu unsicher, weil sich in der Branche keine belastbaren Business Cases aufzeigen lassen. Wie denn auch. Und die Erfolgsmodelle anderer Branchen werden dann der Einfachheit halber nicht akzeptiert. Mittelfristig sichern plattformbasierte Ökosysteme aber den Unternehmenserfolg bzw. die Existenz.

Aber zurück zum Thema Daten im Kontext von KI: Auf jeden Fall abzuraten ist vom schlichten „Einkaufen” von Kundendaten (falls überhaupt vorhanden und legal erlaubt), genauso wie vom Verkaufen eigener Daten an fremde Anbieter. Kunden reagieren allergisch auf entdeckte „Datenkraken” und die oft zitierte Analogie „Data is the new Oil!” hinkt auf allen verfügbaren Füßen. Die meisten europäischen Autohersteller verzeichnen gerade nach eigenen Angaben enttäuschende Ergebnisse beim Versuch, Daten aus Kunden-KFZ selbst mit Kundenzustimmung an ausgewählte Serviceanbieter zu verkaufen. Für Öl zahlen Firmen und Endkunden gerne pro Liter und direkt, bei Daten hat sich eine Umsonst-Kultur entwickelt, hier sind die indirekten Monetarisierungsmodelle deutlich vielversprechender (Beispiel Google: Suchresultate umsonst, Verdienst durch Adwords).

17. Integrationsschicht

Das Thema „Integrationsschicht”, besser im Plural „Integrationsschichten”, ist als eine Teilmenge der Schnittstellenüberlegungen zu Backendsystemen, zu Nutzerschnittstellen oder etablierten anderen Plattformen vor Kunde im Thema Open Architecture zu verorten und in seinen wesentlichen Bestandteilen bereits dort behandelt worden.

Hier sei nur noch letztmalig darauf verwiesen, dass ein komplexes Thema wie Plattformen oder Ökosysteme immer „integrativ” gedacht und umgesetzt werden muss, sowohl im Hinblick auf interne Organisationseinheiten oder IT-Systeme wie auch im Hinblick auf externe Schnittstellenpartner und Anbieter im geplanten Ökosystem.

Dies schließt unseren Blick auf die theoretischen Grundlagen von Plattformen und Ökosystemen ab. Im nächsten Artikel wird es um Rollen und Akteure im Kontext von plattformbasierten Ökosystemen gehen.

Quellen:

1: Holger Neinhaus et al.: Agile Transformation – Ein industrieübergreifender Praxisbericht; Die wichtigsten Erfahrungen aus großen agilen Transformationsprogrammen in Deutschland, 2020

2: https://agilemanifesto.org/

3: Geoffrey Parker et al.: How Platform Strategies Continue to Create Value, 2018 MIT Sloan Management Review

4: https://www.zappos.com/about/culture; https://www.zappos.com/about/stories/record-call

5: https://tfl.gov.uk/info-for/open-data-users/

6: https://api-university.com/blog/the-api-mandate/

7: Donald Hebb: The organization of behavior. A neuropsychological theory. Erlbaum Books, Mahwah, N.J. 2002, ISBN 0-8058-4300-0 (Nachdruck der Ausgabe New York 1949)

Autoren:

Dr. Alfons Niebuer ist Partner für Versicherungen und Banken bei der Strategieberatung SMP Strategy Consulting. Beratungsschwerpunkte liegen in den Themen Plattformen und Ökosysteme, Transformation von Geschäftsmodellen sowie Omnichannel-Management

Louisa Völker ist Senior Consultant bei der Strategieberatung SMP Strategy Consulting. Beratungsschwerpunkte liegen in der Agilen Transformation und Kunden- und Vertriebsstrategien

Dr. Christian Knobloch ist Gesellschafter der IT-Strategieberatung Knobloch & Gröhn GbR und beschäftigt sich insbesondere mit den systemseitigen Voraussetzungen im Kontext von Plattformen und Ökosystemen