Zum Inhalt gehen

Digitale Serviceplattformen in der intelligenten Industrie

Capgemini
02. Okt. 2020

In dieser Blogreihe widmen sich unsere Experten dem Thema Digitale Serviceplattformen in der intelligenten Industrie. In den Blogbeiträgen geben sie Einblicke in die Erkenntnisse aus ihren Projekten und teilen hilfreiche Ressourcen.


Teil 3: Zwei große Herausforderungen auf dem Weg zur Umsetzung

Auf dem Weg digitale Dienste über eine digitale Serviceplattform den Kunden zu Verfügung zu stellen, stoßen viele Unternehmen an Ihre Grenzen. Doch was sind die Gründe, dass die gut durchdachte Vision oft nicht der Plattform entspricht?

In der Praxis stellen wir fest, dass zwei Dinge oftmals für den Erfolg oder Misserfolg auf dem Weg zur digitalen Serviceplattform ausschlaggebend sind. Zum einen ist es die konkrete Definition der passenden Business Architektur, welche die fachliche Grundlage für die spätere IT Implementierung schafft. Zum anderen, die Zusammenarbeit zwischen Business und IT auf dem Weg der Umsetzung.

Definition der Business Architektur anhand von Use Cases

Die Business Architektur für eine digitale Serviceplattform beschreibt aus fachlicher Sicht die notwendigen Fähigkeiten eines Unternehmens für das Geschäft mit digitalen Diensten. Im vorangegangenen Artikel dieser Blogserie wurde bereits eine Schritt für Schritt Anleitung beschrieben, wie eine solche Business Architektur erstellt wird. In diesem Beitrag wollen wir es mit einem sehr kurzen vereinfachten praktischen Beispiel veranschaulichen.

Die fachlichen Anforderungen an eine digitale Serviceplattform sollten anhand der digitalen Services bzw. deren Use Cases abgeleitet werden. Angenommen ein Unternehmen möchte für ein Hardware-Produkt einen digitalen Dienst zum Steuern des Produkts anbieten, welcher über einen Onlineshop erworben und über eine Smartphone App gesteuert werden kann. Aus dieser kurzen Beschreibung lassen sich mehrere Anforderungen an die Serviceplattform ableiten, wovon sich implizit weitere Anforderungen ergeben.

  1. Frontend mittels App zur Benutzereingabe zur digitalen Steuerung der Hardware
  2. Backend (Cloud-basiert) zur Integration des digitalen Dienstes
  3. Online Shop zum Erwerb des digitalen Dienstes
  4. Support, Customer Relationship Management (CRM) und Stammdatenmanagement

Dieses Use Case und somit nutzerzentrierte Vorgehen ist elementar, um den größtmöglichen Kundenmehrwert zu erzielen. Traditionellen Hardware-orientierten Unternehmen fällt dieses Vorgehen oft sehr schwer, da sie bisher keinen oder nur einen sehr geringen Fokus auf digitale Services gelegt haben, welche in der heutigen Zeit immer mehr in den Mittelpunkt rücken.

Um das erstellte Zielbild der Business Architektur schnellstmöglich und vor allem bestmöglich umzusetzen, gilt es eine der größten Herausforderungen auf dem Weg zur Umsetzung zu meistern: die Zusammenarbeit zwischen Business und IT.

Die Zusammenarbeit zwischen Business und IT meistern

Viele denken mit Sicherheit direkt an Frameworks wie Scrum oder SAFe, welche für die agile und skalierbare Softwareentwicklung angewendet werden. Sie sind Teil des Requirements Engineering Prozesses, der den Weg von einer Idee bis zur Umsetzung aus Prozesssicht definiert. Nach diesen Frameworks arbeiten bereits viele unserer Kunden und wir begleiten Sie erfolgreich auf dem Weg dorthin. Wir stellen dabei fest, dass sich dabei zu bewältigende Herausforderungen ergeben, die nicht selten über Erfolg oder Misserfolg entscheiden. Was dabei auffällt ist, dass sich alles um die Anforderungen und deren Abnahmekriterien dreht, die vom Business bzw. den einzelnen Fachbereichen bei der IT eingesteuert werden. Um sicherzustellen, dass die Anforderungen zielführend umgesetzt werden können, müssen diese die nachfolgenden fünf Eigenschaften erfüllen.

Die Anforderungen müssen…

  • so präzise formuliert werden, dass möglichst wenig Spielraum für Interpretationen bleibt
  • entsprechend der verwendeten Technologien und Systeme formuliert werden
  • in Kollaborationstools dokumentiert werden
  • unter Berücksichtigung von Abhängigkeiten korrekt priorisiert werden (MvP – Long-term)
  • rechtzeitig bei der IT eingesteuert werden

Die Voraussetzung, die geschaffen sein muss um die genannten Punkte nicht nur abzuarbeiten, sondern inhaltlich korrekt und zielführend erarbeiten zu können, wird meist vernachlässigt. Viele Mitarbeiterinnen und Mitarbeiter aus den Fachbereichen haben oft wenig bis gar keine IT Erfahrung und deshalb oft ein fehlendes technisches Verständnis. Den ITlern geht es andersherum oft genauso, sie haben kein umfassendes Geschäftsverständnis und können fachliche Themen oft nicht greifen oder nachvollziehen. Deshalb ist es wichtig eine „Brücke“ zwischen den Fachbereichen und der IT zu bilden. Denn hier entsteht oft das größte Delta, welches am Ende dafür verantwortlich ist, dass die digitale Serviceplattform nicht die gewünschten Funktionalitäten bietet oder sich die Umsetzung deutlich verzögert. Sie fragen sich, warum das so ist? Die Antwort ist eindeutig: Da die definierten Anforderungen ohne das Verständnis von Business und IT in der Regel nicht den oben genannten Eigenschaften entsprechen.

Die Lücke zwischen Fachbereich und IT schließen

Unabhängig davon welches agile Framework zum Einsatz kommt, wird eine explizite Rolle, die das fachliche sowie das technische Verständnis mitbringt und mit beiden Parteien durch eine einheitliche Terminologie (Ubiquitous Language) diskutieren kann, benötigt. Diese Rolle wird in der Regel als Requirements Engineer bezeichnet und ist die Schlüsselfigur zwischen den Fachbereichen und der IT, wie in Abbildung 1 dargestellt.

Abbildung 1: Der Requirements Engineer als Brücke zwischen Business und IT

Leider wird diese Rolle jedoch oft vernachlässigt und nicht explizit im Projekt eingesetzt. Dies hat zur Folge, dass Mitarbeiterinnen und Mitarbeiter aus den Fachbereichen die Anforderungen (oft in Form von User Stories) schreiben und die Kolleginnen und Kollegen aus der IT diese umsetzen sollen. Genau hier entsteht das oben genannte Delta zwischen beiden Parteien, was sich negativ auf die Plattform auswirkt und im schlimmsten Fall den Nutzer des digitalen Dienstes nicht zufrieden stellt. Überlassen Sie den Erfolg Ihrer digitalen Serviceplattform nicht dem Zufall und schließen Sie Ihre Lücke zwischen Business und IT.


Teil 2: 6 Schritte von der Vision bis zum Product Backlog

Das Erfolgsgeheimnis hochpreisiger und profitabler Produkte ist das positive Kundenerlebnis. Mit diesen Schritten werden Serviceplattformen implementiert, um die Produkte durch digitale Dienste in ihrer Funktionalität zu erweitern.

Produkte werden zunehmend um digitale Dienste ergänzt (bspw. Bosch eBike Connect), um den Kundennutzen zu steigern (siehe Teil 1 unten). Damit digitale Dienste angeboten werden können, ist jedoch die Implementierung einer digitalen Serviceplattform erforderlich. Dabei müssen die folgenden sechs grundlegenden Schritte vollzogen werden (vgl. Abb. 1).

Capgemini, 6 Schritte zur Spezifizierung einer digitalen Serviceplattform
Abb. 1: 6 Schritte zur Spezifizierung einer digitalen Serviceplattform

1. Vision Statement und Use Case Ideation

Zu Beginn muss eine Vision formuliert werden. Dies gilt für das neue Geschäftsmodell und die zukünftige Plattform gleichermaßen. Verschiedene Bausteine der Business-Strategie wie „Mobile-First“ oder der IT wie „Microservice“ oder „Cloud-First“ sind zu berücksichtigen, da sie einen entscheidenden Einfluss auf die nachfolgenden Schritte haben. Die resultierende Vision bietet Orientierung beim Ausarbeiten des Plattformkonzepts. Ihr folgen die spezifischen Anwendungsfälle (Use Cases), welche die Serviceplattform ermöglichen. Hierbei stehen zu jeder Zeit die Nutzer sowie die Integration der Partner und deren Bedürfnisse im Zentrum. In einem iterativen Ideation-Prozess, welcher zur Ideenfindung durchgeführt wird, wird das Konzept immer weiter konkretisiert und verfeinert.

2. Capability Map

Stehen die Vision und die Use Cases fest, müssen im nächsten Schritt die digitalen Fähigkeiten des Unternehmens und dessen Partner (bspw. Partner, die den Service ermöglichen und/oder erweitern) beurteilt und in einer Capability Map dargestellt werden. Diese wird in Workshops mithilfe geeigneter Werkzeuge wie Storyboards und der Detaillierung der Use Cases erarbeitet. Hierdurch lassen sich Kernfunktionen, deren Erweiterungsmöglichkeiten und Redundanzen identifizieren. Diese Visualisierung der digitalen Fähigkeiten in einer komplexen Geschäftsarchitektur erleichtert die Kommunikation zwischen den Fachbereichen und der IT.

3. Fit-Gap-Analyse

Nun muss die Lücke zwischen dem Ist- und Soll-Zustand geschlossen werden. Jeder benötigten Fähigkeit wird der aktuelle Reifegrad aus der Capability Map gegenübergestellt. Wenn die geforderten Bedarfe nicht im Unternehmen vorhanden sind, müssen diese durch Weiterbildung der Mitarbeiterinnen und Mitarbeiter, neue Talente oder externe Dienstleister gedeckt werden.

4. Domain-Driven Design

Die Bereitstellung von Services auf einer digitalen Plattform und der Zugang für Partner auf das eigene Ökosystem erfordert eine Anpassung der existierenden IT-Anwendungen und die Erweiterung der technologischen Infrastruktur. Hierbei ist eine Modellierung nach dem Domain-Driven Design Prinzip hilfreich. Es wird ein Modell der Anwendungsdomäne für die digitalen Dienste erstellt, welches die Daten, das Verhalten sowie die Abhängigkeiten beschreibt. Dieses Domänenmodell dient als zentrales Kommunikationsmittel zwischen der IT und den Fachbereichen, um fachliche sowie technische Aspekte zu berücksichtigen. Große Modelle und Systeme werden unter Berücksichtigung bestimmter fachlicher Kriterien (z.B. Abgrenzungen der Fähigkeiten) in sich abgeschlossene Bereiche (Bounded Contexts) unterteilt und sorgen durch eine einheitliche Terminologie (Ubiquitous Language) für ein gemeinsames Verständnis. In einer Context Map werden diese Bereiche und ihre Beziehungen zueinander abgebildet. Diese abgegrenzten Bereiche sind potenzielle Kandidaten für Micro Services und unterstützen die Modellierung der skalierbaren Servicearchitektur, so dass die digitale Serviceplattform kontinuierlich und individuell verbessert werden kann.

5. Roadmap

Basierend auf der Capability Map, der Fit-Gap-Analyse und dem Domain-Driven Design werden Meilensteine für den weiteren Projektverlauf definiert. Da sich die Anforderungen an die Serviceplattform und die Rahmenbedingungen im Projektverlauf ändern können, müssen die Meilensteine kontinuierlich überprüft und gegebenenfalls angepasst werden. Die Roadmap ist als Leitfaden anzusehen, der angibt wann welche Capabilities benötigt werden und wann der Kunde welche Teile der Vision erleben kann. Die Roadmap wird im weiteren Projektverlauf basierend auf den Erkenntnissen der nachfolgenden Schritte präzisiert.

6. Product Backlog

Die Ergebnisse der vorausgegangenen Schritte bilden die Grundlage für das Product Backlog (siehe Scrum Guide). Dies ist eine priorisierte Liste von fachlichen Anforderungen in Form von User Stories. Es ist die Aufgabe des Product Owners, diese Aufgaben und Fähigkeiten unter Berücksichtigung des Kundennutzen, Geschäftswerts sowie der Dringlichkeit und Risiken zu priorisieren. Ziel ist es, so schnell wie möglich eine funktionsfähige Serviceplattform mit den wichtigsten Kernfunktionen, nach dem Prinzip eines sogenannten Minimum Viable Products, bereitzustellen. Dabei ist eine stetige Neubewertung und entsprechende Anpassung essenziell, um schnell und präzise auf die sich ändernden Kundenanforderungen einzugehen.

Bevor die Serviceplattform schrittweise implementiert werden kann, muss die Servicearchitektur vollständig definiert werden.

Der Weg hin zu einer Serviceplattform erfordert eine strukturierte Vorgehensweise

Digitale Serviceplattformen, zugeschnitten auf Produkte und Services, bieten ein enormes Potenzial. Mit einer strukturierten Herangehensweise, dem zielorientierten Aufbau der erforderlichen Fähigkeiten, einer kontinuierlichen Kundenzentrierung und interdisziplinären Teams lassen sich schnell sichtbare Fortschritte erzielen. Im nächsten Beitrag erfahren Sie mehr über die Business Architektur und welche Herausforderungen sich bei der Implementierung einer digitalen Serviceplattform ergeben können.

Vielen Dank an die Co-Autorin Kim Weisenburger für die maßgebliche Unterstützung bei der Erstellung dieses Beitrages.


Teil 1: 5 Bausteine zu einem digitalen Ökosystem

Der erste Schritt zur intelligenten Industrie ist mit der digitalen Fabrik getan. Jetzt müssen die physischen Produkte digitale Komponenten erhalten und die Geschäftsmodelle transformiert werden.

Der Wandel in der Fertigungsindustrie erreicht eine neue Stufe. Nach der Digitalisierung der Produktion werden jetzt auch die Produkte selbst digital angereichert. In der Intelligent Industry werden Hersteller zu Lösungsanbietern, Hardware-Produkte zu intelligenten Systemen. Kurzum, es findet eine Transformation von produktzentrierten hin zu kunden- und dienstleistungsorientierten Geschäftsmodellen statt. Hierfür ist eine Erweiterung des Kerngeschäfts um digitale Dienste notwendig. Die branchenübergreifende Digitalisierung der letzten Jahre hat dafür bereits den Grundstein gelegt. Mit Hilfe digitaler Plattformen lassen sich schnell, individuell und skalierbar, digitale Dienste kundenzentriert anbieten. Führende Experten teilen diese Ansicht, wie unsere aktuellste Studie der IT Trends 2020 zeigt.

Das Potenzial von Plattform-Ökosystemen: Ein Beispiel anhand von Smart Speakern

Primär eröffnen digitale Dienste neue Einnahmequellen. Vor allem in Kombination mit einer Integration von Partnern in Dienstleistungs-Ökosysteme lassen sich zusätzliche Geschäftsmodelle realisieren, sowohl im B2B- als auch im B2C-Umfeld. Gleichzeitig steigen Markteintrittsbarrieren. Ein bekanntes Beispiel eines plattformbasierten Dienstleistungs-Ökosystems ist Amazons Alexa. Auf Basis der Amazon Plattform werden eigene Services mit denen von Drittanbietern zu einem B2B2C-Ökosystem gebündelt und generieren mit Hilfe von Alexa Lautsprechern völlig neue Kundenerlebnisse (z.B. Steuerung von Heimautomatisierung über den Alexa Voice Assistent). Über die Alexa App lassen sich alle Dienste gleichermaßen konfigurieren und nutzen. Basierend auf den Nutzerdaten können letztlich individualisierte Dienste angeboten werden. Dieses Szenario zeigt, wie digitale Dienste neue Arten von Kundeninteraktion ermöglichen. Durch die digitalen Dienstleistungen verbessert sich das Nutzererlebnis physischer Produkte während die Wechselkosten von Endverbrauchern steigen.

Das „Wir“ gewinnt: Bündelung von Kernkompetenzen in Ökosystemen

Im Kontext von Industrie 4.0 lag der Fokus produzierender Unternehmen in den vergangenen Jahren auf der Digitalisierung ihrer produktbezogenen Wertschöpfungsketten. Die daraus entstandenen Grundlagen in den Bereichen Industrial IoT (IIoT), Industrie-Plattformen und Data Analytics können nun genutzt werden, um Produkte durch digitale, kundenzentrierte Dienste bzw. Gesamtlösungen zu ergänzen. Derzeit sind nur vereinzelt Initiativen im Manufacturing-Umfeld zu beobachten (z.B. Bosch eBike Connect oder BSH Home Connect), welche erfolgreich durch das sogenannte Servitization Marktanteile ausbauen. Die Mehrheit produzierender Unternehmen bietet zwar bereits Services für deren physische Produkte an. Diese stehen allerding zum jetzigen Zeitpunkt mehrheitlich nur dezentral zur Verfügung. Der nächste Schritt muss daher sein, die entsprechende Infrastruktur zu schaffen, um Dienste an einem zentralen Zugriffspunkt zu bündeln.

Zuallererst ist eine gesamtheitliche Service-Strategie, welche sich mit dem Servicekatalog, den Kanälen, den Domänen, sowie der technischen Infrastruktur befasst, zu entwickeln. Diese bildet die Grundlage, sich am Markt neu zu positionieren und ein plattformbasiertes Ökosystem zu etablieren. Hierbei werden digitale Dienste (auch in Verbund mit physischen Produkten) von Partnern in die eigene Plattform eingebunden, um Netzwerkeffekte zu erzielen. Je mehr Partner sich in einem Ökosystem ergänzen, desto höher der Wert des Plattform-Portfolios.

Optimal umgesetzt ist ein Ökosystem eine Partnerschaft von Akteuren, die folgende Ausprägungen mit sich bringen (vgl. Abb1):

Abb. 1: Charakteristika einzelner Akteure in einem Plattform-Ökosystem

Der Mehrwert eines Ökosystems ist daher die Summe der Charakteristika aller Einzelakteure, welche im Alleingang nicht holistisch geliefert werden können. Abb. 2 verdeutlicht das Zusammenspiel von Partnern in einem Ökosystem, ermöglicht durch eine digitale Serviceplattform.

Abb. 2: Aufbau eines exemplarischen Serviceplattform-Ökosystems

Ziel eines digitalen Service-Ökosystems muss es sein, für alle Beteiligten Synergien zu schaffen – ein nachhaltiges Modell, von dem jeder Einzelne profitieren kann, während ein greifbarer Mehrwert für die Kunden geschaffen wird. Der Enabler dafür ist eine technologiegestützte Plattform, die einen nahtlosen Übergang zwischen Customer Self-Service, Außendienst und Kundenkontaktzentrum bietet. Die Plattform muss auf einem umfassenden Technologiestack aufbauen, der Zusammenarbeit und gemeinsame Angebote ermöglicht. Dazu gehören Software, die in der Cloud, on-Premise und on-Edge bereitgestellt wird, sowie die Verwendung standardisierter APIs einschließlich des Zugriffs auf integrierte Schichten aus dem Ökosystem über eine einzige Benutzeroberfläche.

5 Bausteine für ein Serviceplattform-Ökosystem

Ein digitales Serviceplattform-Ökosystem setzt auf den folgenden fünf Bausteinen auf:

Plattformbasierte Ökosysteme, zugeschnitten auf Produkte und Services, helfen Unternehmen, sich zu diversifizieren und Markteintrittsbarrieren zu verstärken. Wie sich diese Chancen nutzen lassen und welche architekturellen Voraussetzungen eine nachhaltige IT-Implementierung digitaler Serviceplattformen gewährleisten, erfahren Sie im nächsten Beitrag.

Weitere Blogposts

Customer Experience, Digital Core, Transformation & Innovation

Kunden zu verstehen ist keine Magie – Aber es wird sich so anfühlen

Sebastian Marschall
18. Mai 2022
Digital Core, Digital Workplace, Transformation & Innovation

Portfolio Management für intelligente Produkte und Services

Sebastian Marschall
5. Mai 2022

Blog-Updates per Mail?

Abonnieren Sie unseren Newsletter und erhalten Sie alle zwei Monate eine Auswahl der besten Blogartikel.