Die Digitalisierung prägt das Umfeld von Unternehmen vor allem durch neue technologische Entwicklungen in der Erfassung und Speicherung großer Datenmengen – auch bekannt als Big Data. Dies ermöglicht Unternehmen, datenbasierte Services zu entwickeln und somit ihr bestehendes Geschäftsmodell zu erweitern oder sogar neu zu gestalten. Allerdings unterscheiden sich die Anforderungen für die Entwicklung datenbasierter Services maßgeblich von denen für die Entwicklung klassischer Produkte und Services, weshalb viele Unternehmen vor einem Paradigmenwechsel stehen. Da Daten selbst kein inhärentes Wertversprechen haben, müssen für die erfolgreiche Entwicklung eines datenbasierten Service neben (daten-)technischen Anforderungen auch prozessuale Anforderungen sowie eine kundenzentrische Perspektive integriert betrachtet werden. Dies ist entscheidend, da Services kundenorientiert gestaltet werden müssen, um ein entsprechendes Wertversprechen zu vermitteln. Obwohl die Relevanz dieser Herausforderung sowohl in der Wissenschaft als auch in der Praxis bereits bekannt ist, existieren bis heute kaum anwendungsorientierte und keine umfassenden Konzepte für dieses Spannungsfeld. Um diese Lücke zu schließen, wird im vorliegenden Beitrag das Service Design Framework vorgestellt, welches Unternehmen bei der systematischen Entwicklung datenbasierter Services unterstützt. Dabei strukturiert das Framework zentrale Anforderungen (z. B. Kundenbedürfnisse, Prozesse, Daten, Chancen und Risiken) zum Design eines datenbasierten Service. Das Framework wurde mithilfe aktueller Literatur und in Zusammenarbeit mit Experten aus Industrieunternehmen entwickelt und validiert. Das Service Design Framework baut dabei auf den Konzepten der Customer Journey Map und des Service Blueprints auf, kombiniert diese und entwickelt sie für ein umfassendes Design von datenbasierten Services weiter. Damit leistet das Framework einen wichtigen Beitrag bei der strukturierten Erfassung, Entwicklung und Analyse datenbasierter Services.
1 Datenbasierte Services und die Ambivalenz zwischen großer Chance für Kundenmehrwerte und großer Herausforderung im Design
Durch die stetige Weiterentwicklung digitaler Technologien (z. B. Internet der Dinge, künstliche Intelligenz) entstehen für Unternehmen neue Möglichkeiten für die Erweiterung und Anpassung ihrer Geschäftsmodelle (GM) (BMBF 2020). Unabhängig von der konkreten digitalen Technologie stellt dabei die Erfassung, Speicherung, Verarbeitung und Anwendung von Daten die Grundlage für die Ausgestaltung neuer, datengetriebener GM dar.
Gerade für Unternehmen, welche zum Teil Dekaden vor diesen Technologien entstanden sind, bieten datenbasierte Services eine enorme Chance für die Transformation ihres GM (Gimpel und Röglinger 2015). In einem globalen Wettbewerb, welcher durch sinkende Margen im (physischen) Produktbereich geprägt ist, bieten datenbasierte Services eine Chance zur Komplementierung der Produkte und somit zur Differenzierung im Wettbewerb. Durch den Einsatz von Daten und Analytik ermöglichen datenbasierte Services Unternehmen konkrete Potenziale für die Weiterentwicklung ihrer GM, wie u. a. die Individualisierung des Werteversprechens, eine intensivere und vor allem kontinuierliche Kundenbeziehung nach dem Produktverkauf sowie Up- und Cross-Selling-Möglichkeiten zur Erschließung neuer Kundengruppen und Märkte. Unternehmen stehen daher vor der Chance und zugleich Herausforderung, datenbasierte Produkte und Services noch stärker in ihr bestehendes GM zu integrieren. Da Daten selbst kein inhärentes Wertversprechen haben, ist ein Verständnis der Datennutzung, das heißt wie Produkte, Services und Kundenerlebnisse mithilfe von Daten aktiv verbessert werden können, entscheidend (Wiener et al. 2020).
Anzeige
Neben (daten‑)technischen Anforderungen auf Ebenen des Services bzw. des Produkts, der IT-Infrastruktur sowie der Anwendungssysteme gehören die Berücksichtigung prozessualer Anforderungen und die Bedürfnisse der Kunden gleichermaßen zu einer ganzheitlichen Betrachtung des Service Designs (Buhl und Kaiser 2008). Für Unternehmen, die bisher primär auf die funktionale Weiterentwicklung ihrer eigenen Produkte fokussiert waren, stellt dies einen Paradigmenwechsel dar (Voigt et al. 2019). Denn dies umfasst neben der Produktexpertise ein ausgeprägtes Verständnis über den Anwendungskontext beim Kunden (Kundenprozesse), die möglichen Formen der Zusammenarbeit mit dem Kunden (Interaktionsprozesse) und der Kollaboration zwischen unterschiedlichen Abteilungen sowie mit externen Dienstleistern (Providerprozesse) (Lim et al. 2018). Um wahrnehmbare Mehrwerte erzielen zu können, erfordert das Design eines datenbasierten Services über die differenzierte Betrachtung dieser komplexen Zusammenhänge auf Prozessebenen hinaus eine konsequente Einbindung von Kunden und deren Bedürfnisse (Kindström und Kowalkowski 2009). Für die Entwicklung datenbasierter Services sind daher Ansätze nötig, die sowohl die Kunden- als auch die Anforderungsseite strukturiert erfassen (Vargo und Lusch 2016; Patrício et al. 2011).
Eine ganzheitliche Entwicklung datenbasierter Services wird im Wesentlichen von drei Aspekten geprägt: erstens durch die kundenzentrische Entwicklung, zweitens durch prozessuale und drittens durch (daten-)technische Anforderungen. Allerdings verfolgen bisherige Beiträge, wie die von Hunke und Schüritz (2019), Osterwalder et al. (2015) oder Pöppelbuß und Durst (2017), Betrachtungen, welche mindestens einen dieser essenziellen Aspekte vernachlässigen. Um diese Lücke zu schließen, ist ein integrierter Ansatz notwendig, weshalb dieser Beitrag die Beantwortung der folgenden Fragestellung verfolgt:
Wie können datenbasierte Services sowohl unter Berücksichtigung der Kundenbedürfnisse als auch der prozessualen und (daten-)technischen Anforderungen im Rahmen des Service Design strukturiert erfasst und entwickelt werden?
Zur Beantwortung dieser Fragestellung wurde das Service Design Framework (SDF) entwickelt und validiert. In der Entwicklung wurden dafür Elemente der Customer Journey Map (CJM) und des Service Blueprints (SB) sowie im Rahmen eines öffentlich geförderten Forschungsprojektes das spezifische Know-how von sechs Industrieunternehmen durch Experteninterviews miteinbezogen. Die Anwendung des SDF wurde anschließend im Design eines Predictive Maintenance (PM) Service und eines Service für das individuelle Energiemanagement von Mietern demonstriert.
Im Folgenden werden für die Arbeit zentrale Begrifflichkeiten definiert und relevante Konzepte in der Literatur eingeordnet. Anschließend folgt eine kurze Darstellung des Entwicklungs- und Evaluationsprozesses, die in der Vorstellung des Frameworks und seiner Anwendung mündet. Zum Abschluss des Beitrags werden die zentralen Nutzungsoptionen des Frameworks sowie deren Mehrwerte und Limitationen skizziert.
Anzeige
2 Datengetriebene Geschäftsmodelle und das Design datenbasierter Services
Um datenbasierte Services erfassen und entwickeln zu können, ist ein Verständnis darüber notwendig, wie diese auf ein (datengetriebenes) GM wirken. Im Rahmen der theoretischen konzeptionellen Vielfältigkeit und Ambiguität des Begriffs GM (Häckel und Übelhör 2019), folgt dieser Beitrag der Definition nach Osterwalder und Pigneur (2011). Demzufolge ist ein GM das Grundprinzip, nach dem eine Organisation Werte schafft, vermittelt und erfasst. Vor dem Hintergrund aufkommender, digitaler Technologien (z. B. Big Data, Cloud Computing, Internet der Dinge) entstehen dabei neue Grundprinzipien für GM (Gimpel und Röglinger 2015). Im Zusammenhang mit zunehmenden Datenmengen führt diese Entwicklung zu datengetriebenen GM (Fruhwirth et al. 2020). Damit bilden datengetriebene GM eine eigene Untergruppe an GM (Kühne und Böhmann 2019). In der Literatur gibt es keine festgeschriebene Schwelle oder Schöpfungshöhe, ab der ein Geschäftsmodell datengetrieben ist (Schüritz et al. 2017; Hartmann et al. 2016). Einigkeit besteht aber dahingehend, dass Daten eine zentrale Ressource dieser GM sein müssen (Hartmann et al. 2016). Für bestehende Unternehmen impliziert das Erstreben von datengetriebenen GM daher eine fortschreitende Integration von Daten in ihr GM. Infolgedessen befinden sich Unternehmen mit der Einführung von datenbasierten Services in einer sukzessiven Transformation von traditionellen zu datengetriebenen GM (Schüritz et al. 2017).
Über die Integration von Daten und Analytik in bestehende Strukturen ermöglichen datenbasierte Services das Wertversprechen zum Kunden zu erweitern oder neu zu entwickeln (Schüritz et al. 2017; Hunke et al. 2019). Bestehende Produktangebote können dabei durch datenbasierte Services zu integrierten Produkt-Service Systemen (PSS) weiterentwickelt werden (Abramovici et al. 2015). Als Beispiel für einen datenbasierten Service dient ein PM Service, welcher basierend auf Operations- und Sensordaten der jeweiligen Maschine einen optimalen Wartungszeitpunkt prognostiziert. Die Integration eines solchen datenbasierten Service in ein bestehendes GM eines traditionellen Maschinenbauunternehmens resultiert daher sowohl in der Transformation des GM zu einem datengetriebenen GM als auch in der Entstehung eines PSS.
Die Serviceentwicklung unterscheidet sich grundsätzlich von der Produktentwicklung, weshalb die Disziplin des Service Engineering konkrete Konzepte zur Planung, Gestaltung und Entwicklung von Services umfasst (Bullinger und Scheer 2007). Über die Vielfalt unterschiedlicher Vorgehensmodelle hinweg (u. a. Kindström und Kowalkowski (2009), Wiesner et al. (2015), Beverungen et al. (2018)) wird die Serviceentwicklung in die Phasen „Service Creation“ und „Service Design“ unterteilt. Ersteres umfasst dabei die Generierung von Serviceideen, wobei für diesen Zweck dedizierte Kreativmethoden eingesetzt werden (Rennung et al. 2016). Im Anschluss daran wird eine Idee im „Service Design“ konzeptionell ausgestaltet. Dies umfasst die Aufnahme von Anforderungen sowie Spezifizierung und Detaillierung der Bestandteile (Wiesner et al. 2015). Hierzu werden detaillierte Kundenanforderungen wie auch prozessuale und technische Anforderungen des Service berücksichtigt (Rennung et al. 2016; Goldstein et al. 2002; Beverungen et al. 2018).
Die Berücksichtigung der Daten und Analytik, die einen elementaren Bestandteil von datenbasierten Services darstellen, ist im Design von datenbasierten Services essenziell (Schüritz et al. 2017). Ergänzend wird hierdurch auch der Beitrag von Daten zum Erfüllen der Kundenbedürfnisse (der so genannte Data-Need-Fit) sichergestellt (Mathis und Köbler 2016). Der Aspekt „Daten“ erfasst dabei Daten, Datenkombinationen und Datenquellen (Hunke et al. 2019; Kühne und Böhmann 2019). Der Aspekt „Analytik“ erfasst die Analyse der Daten, generierten Informationen und die Rolle des Service-Konsumenten. Durch die differenzierte Betrachtung von Daten werden besondere Designanforderungen von datenbasierten Services abgedeckt (Hartmann et al. 2016; Hunke et al. 2019; Kühne und Böhmann 2019). Für ein ganzheitliches Design datenbasierter Services ist allerdings sowohl eine Betrachtung der Kundenbedürfnisse als auch der prozessualen und (daten-)technischen Anforderungen notwendig.
Ansätze zum ganzheitlichen Design datenbasierter Services sind in der Literatur bislang nicht ausreichend beleuchtet (Hunke und Engel 2018). Hunke und Schüritz (2019) berücksichtigen in ihrer Taxonomie für analysebasierte Dienstleistungen fünf Schlüsselkategorien, erfassen Kundenbedürfnisse allerdings nur unzureichend. Das auf den Kunden zentrierte Value Proposition Canvas von Osterwalder et al. (2015) vernachlässigt sowohl die dedizierte Erfassung der Rolle von Daten als auch die der prozessualen und technischen Abhängigkeiten eines Service. Die Erweiterung dessen um einen Datenfokus im Smart Service Canvas von Pöppelbuß und Durst (2017) zielt zwar auf den optimalen Fit zum Kunden und somit auf ein besseres Wertversprechen ab, verzichtet aber weiterhin auf die detaillierte prozessuale und technische Beschreibung des sich im Design befindlichen Service.
Um eine integrierte kundenzentrische, prozessuale und (daten-)technische Betrachtung im Design datenbasierter Services zu ermöglichen, bieten sich zwei sowohl in der Wissenschaft als auch in der Praxis anerkannte und etablierte Methoden an: die CJM und der SB. Die CJM ist ein vor allem in der Praxis weitverbreitetes Instrument für die Erfassung von Kundenbedürfnissen entlang eines Serviceprozesses (Maechler et al. 2016). Dabei berücksichtigt eine CJM Berührungspunkte zwischen Anbieter und Kunden, antizipiert Kundenemotionen und erfasst positive wie negative Kundenerfahrungen (User Experiences) (Marquez et al. 2015). Ein SB leitet die schrittweise Erfassung und Strukturierung von Serviceprozessen an (Joyce und Gibbons 2019). Dabei adressiert der SB primär die technischen und prozessualen Anforderungen eines Service, insbesondere die Prozessschritte zum Kunden, Supportprozesse im eigenen Unternehmen sowie technische Voraussetzungen für die Leistungserbringung (Kostopoulos et al. 2012). Während die CJM somit aus Kundensicht Rückschlüsse auf die Serviceentwicklung erlaubt (Outside-in), erfasst der SB die prozessualen und technischen Voraussetzungen aus Sicht des Anbieters des datenbasierten Service (Inside-out).
Da in der Literatur bisher keine Arbeiten vorliegen, welche sich zur Entwicklung von datenbasierten Services sowohl explizit den Aspekten Daten und Analytik als auch integriert der Betrachtung von Kundenbedürfnissen sowie den prozessualen und (daten-)technischen Anforderungen widmen, soll diese Lücke geschlossen werden. Durch eine Kombination der CJM und des SB sowie der Berücksichtigung des Hintergrunds von Daten und Analytik wird innerhalb des SDF die strukturierte Entwicklung datenbasierter Services ermöglicht. Neben der ganzheitlichen Strukturierung von Anforderungen wird Unternehmen dadurch eine Weiterentwicklung des GM hin zu einem datengetriebenen GM ermöglicht.
3 Vorgehen bei der Entwicklung des Service Design Frameworks
Zur Entwicklung des SDF wurde ein iterativer Ansatz angewandt, welcher sich in drei übergeordnete Phasen unterteilen lässt. Das Vorgehen ist in Abb. 1 illustriert und wird im Folgenden erläutert.
Abb. 1
Übersicht des methodischen Vorgehens
×
3.1 Literaturrecherche
Um auf in der Literatur bestehenden und etablierten Ansätze zur Entwicklung von datenbasierten Services aufzubauen, wurde zunächst eine Literaturrecherche durchgeführt. Hierbei lag der Fokus auf Beiträgen, welche sowohl Kundenbedürfnisse wie auch prozessuale und (daten-)technische Anforderungen berücksichtigen. Dazu wurden in einem ersten Schritt fachspezifische Datenbanken (u. a. SpringerLink, ScienceDirect und AIS Library) durchsucht und relevante Artikel identifiziert. Anschließend wurden mithilfe von Forward und Backward Search auf Basis der identifizierten Artikel weitere relevante Beiträge ergänzt. Zudem wurden aktuelle Veröffentlichungen branchenspezifischer Unternehmensberatungen (u. a. Maechler et al. 2016) und Forschungseinrichtungen (z. B. Freitag et al. 2019) zum Thema gesichtet, um neben wissenschaftlichen Publikationen aktuelle und in der Praxis etablierte Ansätze zu berücksichtigen.
3.2 Framework Entwicklung
Die identifizierten Ansätze wurden anschließend auf ihre Eignung hinsichtlich der Berücksichtigung der zuvor definierten Anforderungen überprüft. In einem ersten Schritt wurden hierzu die Ansätze zunächst auf ausgewählte, branchenspezifische Anwendungsfälle (u. a. Condition Monitoring und PM) angewandt. Somit konnten die Ansätze aussortiert werden, welche die Anforderungen nur unzureichend erfüllen. Die verbliebenen Ansätze wurden daraufhin in einem Interview mit wissenschaftlichen Experten, welche vor allem in der Entwicklung datenbasierter Services und Industrie 4.0 Anwendungen tätig sind, evaluiert (I1 und I2, siehe Tab. 1). Hierbei kristallisierte sich die Kombination aus der CJM und dem SB als vielversprechender Ansatz heraus.
Tab. 1
Übersicht der Experteninterviews
ID
Rollen der Interviewpartner
Industrie/Forschung
Mitarbeiter (2019)
Umsatz (2019)
I1
Wissenschaftlicher Mitarbeiter
Forschungseinrichtung
–
–
I2
Wissenschaftlicher Mitarbeiter
I3
Service Director Global Accounts
Hersteller von Groß- und Industrieküchengeräten
2200
843 Mio. €
I4
Data Analytics Manager Service Department
I5
Condition Monitoring Engineer
Hersteller von Antriebstechnik
2500
559 Mio. €
I6
Global Product Manager
Hersteller von optischen und optoelektronischen Geräten
31.200
6,4 Mrd. €
I7
Team Lead Condition Monitoring Layout
Hersteller von Produktions- und Automatisierungssystemen
6800
1,2 Mrd. €
Um auf dieser Basis ein anwendbares Framework zu erstellen, wurde ein iteratives Vorgehen gewählt. In jeder Iteration wurde zunächst ein branchenspezifischer Anwendungsfall (z. B. PM) modelliert. Danach wurde die domänenspezifische Literatur geprüft, um gewonnene Erkenntnisse auf ihre wissenschaftliche Validität zu überprüfen und Erkenntnisse zu komplementieren. Zum Abschluss wurde ein Experteninterview zur Bestätigung der Anwendbarkeit und praktischen Validität durchgeführt (I3–I7, siehe Tab. 1). Zudem wurden die Experten auch zur Notwendigkeit und Relevanz des Frameworks befragt. Durch dieses iterative Vorgehen konnte die initiale, aus der Literatur abgeleitete Version des SDF dahingehend weiterentwickelt werden, dass für den Anwendungskontext des Frameworks relevante Dimensionen hinzugefügt (z. B. Daten und Analytik sowie Chancen und Risiken) und irrelevante Aspekte weggelassen (z. B. Supportprozesse) wurden. Die Vorgehensweise wurde dabei so lange wiederholt, bis sich aus den Experteninterviews und der Literatur keine grundlegenden Änderungen für das SDF mehr ergaben.
3.3 Framework Demonstration
Nachdem durch die Modellierung der Anwendungsfälle wie auch durch die Experteninterviews keine neuen Erkenntnisse mehr gewonnen werden konnten, wurde in der letzten Phase die Anwendbarkeit des SDF anhand zwei realer Anwendungsfälle demonstriert. Hierzu wurde das SDF zunächst im Rahmen eines öffentlich geförderten Forschungsprojektes des Bundesministeriums für Wirtschaft und Forschung (ODH@Bochum-Weitmar 2021) zur Entwicklung eines datenbasierten Service, dem individuellen Energiemanagement für Mieter, eingesetzt. Die Anwendung des Frameworks erfolgte dabei in einem Online-Workshop zusammen mit fünf wissenschaftlichen Mitarbeitern des Forschungsprojektes unter Zuhilfenahme eines interaktiven Kollaborationstools (MURAL). Darüber hinaus wurde das SDF im eigenen Forschungsprojekt (Datenbasierte Services für Industrieunternehmen (DaSIe)) zur Entwicklung eines PM Service für einen Hersteller von Groß- und Industrieküchengeräten verwendet. Als Ergebnis der Demonstration konnte die Anwendbarkeit und der Mehrwert des SDF durch die Forschungs- und Industrieexperten positiv bestätigt werden. Das finale SDF sowie dessen exemplarische Anwendung wird im nachfolgenden Kapitel ausführlich beschrieben.
4 Vorstellung des Service Design Frameworks
Das SDF besteht aus der prozessualen Beschreibung des Service auf der x‑Achse und den Dimensionen zur Beschreibung relevanter Kunden‑, Unternehmens- und Serviceaspekte auf der y‑Achse. Aus beiden Dimensionen wird eine Matrix aufgespannt, welche den Service sowohl aus der Perspektive des Kunden als auch bezogen auf die prozessualen und technischen Anforderungen ganzheitlich beschreibt und strukturiert (siehe Abb. 2).
Abb. 2
Service Design Framework
×
4.1 Phasen des Service Design Frameworks (x-Achse)
Die Phasen (Stages), abgebildet auf der x‑Achse, strukturieren den Service dabei in chronologische und logisch abgrenzbare Schritte. Die Phasen ermöglichen eine umfassendere Betrachtung des Service. Für zusätzliche Orientierung wurden die übergeordneten Phasen „Pre-Encounter Stage“, „Service Encouter Stage“ und „Post-Encounter Stage“ in das SDF integriert, welche im Folgenden kurz erklärt werden.
Pre-Encounter Stage
Hier werden der Nutzung des Service vorgelagerte Aktivitäten, beispielsweise die Betrachtung von Angebotsalternativen oder die Registrierung für die Nutzung, erfasst.
Service Encounter Stage
Mit dem Beginn der Service Encounter Phase startet die tatsächliche Nutzung des Service bzw. der reguläre Ablauf des Service. Hierbei wird die gesamte Leistungserbringung erfasst, wie bspw. die komplette Durchführung eines Condition Monitoring Service.
Post-Encounter Stage
An dieser Stelle werden alle dem Service nachgelagerten Aktivitäten, wie etwa die Evaluation des Service oder zugehörige Rechnungsprozesse, erfasst.
4.2 Dimensionen des Service Design Frameworks (y-Achse)
Auf der y‑Achse befinden sich die Dimensionen „Customer Side“, „Business Side“, „Service Blueprint“ und „Data Analytics“ resultierend aus dem methodischen Vorgehen beschrieben in Kap. 3. Die Dimension „Result“ wurde, innerhalb des iterativen Vorgehens, zusätzlich ergänzt, um Metaerkenntnisse und Verbesserungspotenziale festzuhalten.
Customer Side
Die Customer Side beleuchtet die Perspektive des Kunden und trägt somit zum besseren Verständnis der Kundenbedürfnisse bei. Dazu enthält sie die aus Kundensicht notwendigen Schritte (Steps), die ein Kunde in der jeweiligen Phase durchläuft, sowie die Kontaktpunkte (Touchpoints) zwischen Servicenutzer und -anbieter. Darüber hinaus werden die Ziele (Customer Goals) sowie die Gedanken und Gefühle (Thinking Feeling) des Kunden bzw. der Kundengruppe in jeder Phase festgehalten. Das Ergebnis der Customer Side ist eine umfassende Betrachtung der Kundenanforderungen und -wünsche an den Service. Diese dient als Grundlage für die weiterführende Erfassung des Service und trägt in der Folge zum „Fit“ des Service zum Kunden und damit auch zur Verbesserung der Kundenzufriedenheit bei.
Business Side
Die Business Side betrachtet die (inter-)organisationale Perspektive des Serviceanbieters während der Serviceerstellung. Zu ihr gehören die in der Wertschöpfung involvierten internen und externen Parteien (Involved Parties), die nach innen gerichteten Unternehmensziele (Internal Business Goals) und die nach außen gerichteten Unternehmensziele (External Business Goals). Die internen Ziele sind dabei auf die Effizienz und Effektivität des Unternehmens (z. B. die Optimierung der Durchlaufzeiten) bezogen, während die externen Ziele die Außenwahrnehmung durch den Kunden (z. B. die Servicequalität) verfolgen. Die Beleuchtung der Business Side stellt sicher, dass vor der eigentlichen Serviceentwicklung ein gemeinsames Verständnis der damit verbundenen Ziele geschaffen wird.
Service Blueprint
Der SB spiegelt den Entwurf des Service aus der Perspektive des Serviceanbieters wider. Hierbei ermöglicht der SB entscheidende Erkenntnisse sowohl über die resultierenden Anforderungen an die eigene Organisation als auch im Hinblick auf die Zusammenarbeit mit Partnern für die Umsetzung des Service. Dazu gehören die im direkten Kundenkontakt durchgeführten Aktionen (Frontstage Actions), unterstützende Aktionen und Supportprozesse im Hintergrund (Backstage Actions) sowie die involvierten Rollen (Involved Roles) innerhalb einer Organisation. Der SB dient somit als erster Ansatz für die Erfassung zentraler nach innen und außen gerichteter Anforderungen zur Implementierung des Service.
Data Analytics
Daten und die darauf aufbauende Analytik stellen einen hochgradig relevanten Bestandteil datenbasierter Services dar und werden daher in unterschiedlichen Dimensionen dediziert betrachtet. Um im Design von datenbasierten Services wichtige Elemente sowohl hinsichtlich der Daten und Datenerfassung als auch der darauf aufbauenden Datenanalyse festzuhalten, bietet sich in Anbetracht der integralen Bedeutung dieser beiden Dimensionen eine Unterstrukturierung an. Innerhalb der Dimension Daten (Data) wird dabei erfasst, welche Daten für den Service genutzt werden sollen, wie diese kombiniert werden können, um neue Informationen zu generieren und welche Quellen für diese Daten benötigt werden. Die Dimension Analytik (Analytics) umfasst dabei, wie und mit welchen Technologien die Daten weiterverarbeitet werden, welche Informationen bzw. Mehrwerte generiert werden sowie die Rolle des Servicenutzers in diesem Zusammenhang. Welche und ob weitere dieser (optionalen) Unterstrukturierungselemente benötigt werden, wird dabei durch den Anwender basierend auf den jeweiligen Rahmenbedingungen entschieden. Die inhaltliche Ausgestaltung des zukünftigen Service im Service Blueprint gibt dabei vor, welche Anforderungen an Daten und Analytik gestellt werden und ermöglicht demnach eine erste Erfassung und Dokumentation der technischen Anforderungen des zu entwickelnden Service.
Result
Die Dimension Result fasst die Erkenntnisse aus dem Serviceentwicklungsprozess in Chancen (Chances) und Risiken (Risks) zusammen. Hieraus können sowohl relevante Risiken (wie z. B. das Verfehlen von Kundenerwartungen) als auch Chancen identifiziert werden. Überdies sollten die entsprechenden Risiken in das Risikomanagement aufgenommen werden.
5 Anwendung des Service Design Frameworks
Die Anwendung des SDF wird im Folgenden an einem PM Anwendungsfall demonstriert, welcher im Rahmen eines Forschungsprojekts zur Entwicklung innovativer Analytics-Lösungen und datengetriebener GM-Innovationen entwickeltet wurde. Der Anwendungsfall spiegelt dabei einen PM Service eines global agierenden Herstellers von Groß- und Industrieküchengeräten wider, der mit Hilfe von Sensor- (z. B. Innenraumtemperatur) und Produktnutzungsdaten (z. B. Garprogramme) sein Wertversprechen durch proaktive, digitale Services erweitern möchte. Ziel des Herstellers ist dabei sein bereits existierendes Wartungsangebot durch den Einsatz von moderner Analytik in eine nicht länger reaktive, sondern bedarfsorientierte und proaktive Wartung zu überführen. Abb. 3 stellt das ausgefüllte SDF dieses Anwendungsfalls dar, wobei im Sinne der Lesbarkeit lediglich ein Beispiel pro Zeile aufgeführt wird. Die Bearbeitung des SDF erfolgte dabei in 6 Schritten, welche im Folgenden näher erläutert werden.
Abb. 3
Ausgefülltes Service Design Framework für den Predictive Maintenance Anwendungsfall
×
Schritt 1
Dabei wurden in einem ersten Schritt zunächst die übergeordneten Phasen, gegliedert nach Pre-Encounter, Service Encounter und Post-Encounter Phasen aus Kundensicht definiert. Für den spezifischen Anwendungsfall ergaben sich, wie in Abb. 3 dargestellt, eine Pre-Encounter Phase (der Normalzustand des Geräts), vier Service Encounter Phasen (von der Anomalieerkennung bis zur Überführung in den Normalbetrieb) und eine Post-Encounter Phase (Nachbehandlung des Vorfalls).
Schritt 2
Im nächsten Schritt erfolgte die Ausarbeitung der Customer Side. Das Framework wurde hierzu Dimension für Dimension entlang der Phasen befüllt. Sukzessive konnten so die Kundenbedürfnisse spezifiziert werden, indem zuerst relevante Aktionen, dann Kontaktpunkte, anschließend Ziele und final Gedanken und Gefühle des Kunden erarbeitet wurden.
Schritt 3
Nachdem mit der Customer Side die zentralen Kundenbedürfnisse erfasst wurden, erfolgte ein analoges Vorgehen zur Erarbeitung der Business Side. Hierbei konnten neben den Unternehmenszielen auch erste interorganisationale Anforderungen identifiziert werden (wie z. B. die Zusammenarbeit mit einem Dienstleister für Cloud-Services).
Schritt 4
Aufbauend auf den Ergebnissen für Customer und Business Side wurde daraufhin der SB ausgearbeitet. Während Frontstage und Backstage Actions hier für die Klärung der prozessualen Anforderungen (bspw. das Anbieten von Sofortlösungen) dienten, konnten mit den Involved Roles bereits wichtige Stakeholder (wie z. B. die Prozessverantwortlichen aus der Customer Care Abteilung) identifiziert werden.
Schritt 5
Anschließend wurden innerhalb der Dimension Daten für den Service relevante Daten, Datenkombinationen sowie die dafür benötigten Datenquellen ermittelt. So konnte u. a. aufgezeigt werden, dass für eine belastbare Vorhersage des Wartungszeitpunktes mehr und vor allem spezifische Daten hinsichtlich der Verwendung des Produktes (u. a. verwendete Garprogramme) benötigt werden. Mithilfe der Dimension Analytik konnten zudem mögliche Ansätze zur Weiterverarbeitung der Daten (z. B. innerhalb eines Decision Support Systems) und der Mehrwerte für den Kunden (wie z. B. die aktive Einbindung in Entscheidungen bezüglich der Wartung der Geräte) identifiziert und festgehalten werden. Darüber hinaus konnte die Rolle des Servicenutzers in den einzelnen Phasen des Service definiert werden, was z. B. in der Phase der Anomaliebehebung verdeutlichte, dass der Kunde dort interagierend auftritt.
Schritt 6
In einem letzten Schritt wurden mit den Chancen und Risiken die Basis für strategische Handlungsempfehlungen bereitgestellt, die im Rahmen der weiteren Serviceentwicklung relevante Anwendung fanden.
Die Anwendung des SDF offenbarte dabei eine Reihe wichtiger Erkenntnisse und ermöglichte, den Service sowohl aus kundenzentrischer, prozessualer und (daten-)technischer Sicht zu analysieren. So konnte identifiziert werden, dass z. B. aus (daten-)technischer Sicht während des Gerätebetriebs zusätzliche Daten gespeichert werden müssen, um verlässliche Vorhersagen innerhalb des Service zu generieren. Auf prozessualer Ebene wurde festgestellt, dass eine effektive Informationsübertragung von Vor-Ort-Technikern zu den Prozessverantwortlichen innerhalb der Customer Care Abteilung eine wichtige Voraussetzung für die Entscheidungsunterstützung darstellt. Bezogen auf den Kunden konnte ermittelt werden, dass eine individuelle Kommunikationsstrategie stark zur Kundenzufriedenheit beiträgt. Die Integration von CRM-Daten zur Steuerung der Kundenkommunikation während der Problembehebung wurde daher als mögliche Lösungsstrategie im SDF festgehalten. Das SDF ermöglichte in diesem Zusammenhang nicht nur eine strukturierte Erfassung des zu entwickelnden Service, sondern unterstützte auch dabei, ein gemeinsames Verständnis der involvierten Rollen und Projektmitarbeitern herzustellen. Zudem wurden die dokumentierten Ergebnisse als wichtige Grundlage für die weitere Ausgestaltung und Implementierung des Service angesehen.
6 Nutzungsoptionen und Mehrwerte des Service Design Frameworks
Das SDF wurde entwickelt, um datenbasierte Services besser erfassen, analysieren und designen zu können. Es wurde initial aus der Literatur abgeleitet und durch ein iteratives Vorgehen sowie in enger Zusammenarbeit mit Industrieexperten für dessen praktikable Anwendung weiterentwickelt. Anschließend wurde das Framework in unterschiedlichen Projekten und Anwendungskontexten validiert.
Das SDF ermöglicht dabei je nach Anwendungskontext und Fokus unterschiedliche Mehrwerte und schafft überdies eine Grundlage für die strukturierte Entwicklung datenbasierter Services. Die phasenweise Erfassung von Kundenbedürfnissen sowie die daraus resultierende Zuordnung von (daten-)technischen sowie prozessualen Anforderungen resultiert dabei in einem umfassenden Konzept des Service Designs.
Im Rahmen der Entwicklung des SDF wurden zwei übergeordnete Möglichkeiten zur Anwendung identifiziert. Eine mögliche Anwendung besteht dabei in der Konzeption eines neuen, datenbasierten Service, um diesen mithilfe des SDF strukturiert auszugestalten. Zum anderen kann das SDF zur strukturierten Analyse und Weiterentwicklung eines bereits bestehenden Service hin zu einem datenbasierten Service verwendet werden. Beide Arten der Anwendung werden im Folgenden hinsichtlich ihrer Mehrwerte und Limitationen kurz erläutert:
6.1 Design eines neuen, datenbasierten Service
Mehrwerte
Das Framework stellt eine adäquate Berücksichtigung der Kundenzentrierung im Service Design sicher. Hierbei handelt es sich um einen entscheidenden Erfolgsfaktor bei der Entwicklung datengetriebener GM. Insbesondere traditionelle Unternehmen ohne besondere Vorerfahrung im Design datenbasierter Services vernachlässigen diesen Aspekt oftmals, allerdings ist dies für eine umfassende Betrachtung eines Service und dessen Anforderungen zwingend erforderlich.
Neben der Integration der Kundenbedürfnisse werden innerhalb des SDF auch die (daten-)technischen Anforderungen explizit erfasst. Dies ermöglicht schon während der initialen Konzeption des Service Rückschlüsse auf benötigte Daten und Datenquellen sowie Anforderungen an die analytischen Auswertungen abzuleiten. In der Folge wird sowohl die Berücksichtigung wie auch das Verständnis der (daten-)technischen Anforderungen im weiteren Verlauf der Implementierung des Service sichergestellt.
Darüber hinaus wurde sowohl in den Interviews als auch in der Demonstration des SDF deutlich, dass sich die Serviceentwicklung in einigen Aspekten von der Produktentwicklung unterscheidet. Für einige Unternehmen stellt dies einen Paradigmenwechsel und somit eine herausfordernde Aufgabenstellung dar, da traditionelle Vorgehensmodelle aus der Entwicklung physischer Produkte nicht oder nur teilweise anwendbar sind. Das SDF unterstützt hier durch eine strukturierte sowie systematische Vorgehensweise, die den Einstieg in die Serviceentwicklung erleichtert.
Limitationen
Für die erfolgreiche Anwendung des Frameworks sind gewisse Rahmenbedingungen erforderlich. Unter anderem wird ein gemeinschaftliches Verständnis der im Framework verwendeten Begriffe und Prozessschritte benötigt. Zum anderen sollten methodische Grundlagen, wie bspw. zentrale Konzepte (z. B. CJM) und Methoden (z. B. Personas) des Service Designs, bereits bekannt sein.
Weiterhin ist zu berücksichtigen, dass das Framework durch seine Struktur grundsätzlich eher zum analytischen statt zum kreativen Denken anregt. Die erste Ideenfindung für einen Service sollte daher mit klassischen Kreativmethoden zuvor in der „Service Creation“ erfolgen.
6.2 Analyse und Weiterentwicklung eines bestehenden Service
Mehrwerte
Die strukturierte und analytische Vorgehensweise des SDF eignet sich ebenso zur Überprüfung bereits bestehender Services, die initial nicht zwangsläufig datenbasiert sein müssen. Durch die Evaluation und Demonstration des Frameworks wurde deutlich, dass die Erfassung und Dokumentation eines bestehenden Service mithilfe des SDF sicherstellt, alle wichtigen und zentralen Aspekte eines datenbasieren Service strukturiert sowie ganzheitlich zu erfassen.
Durch die dedizierte Berücksichtigung von Daten und Analytik werden durch die Anwendung des SDF Weiterentwicklungspotenziale aufgezeigt, die es in der Folge ermöglichen, den Service datenbasierter zu gestalten. So können beispielsweise durch die Hinzunahme weiterer Datenquellen oder durch eine verbesserte Auswertung der Daten bestehende Service erweitert und verbessert und somit direkt Mehrwerte für den Kunden erzielt werden.
Zudem unterstützt das Framework bei der Identifikation von konkreten Ansatzpunkten für die Verbesserung und Weiterentwicklungen bestehender Services. Durch ihre Verankerung in der Struktur der SDF können diese außerdem wesentlich schneller in umsetzbare Maßnahmen überführt werden.
Limitation
Für die erfolgreiche Erweiterung und Verbesserung eines bestehenden Service ist eine zentrale Voraussetzung, dass die Anwender des Frameworks (z. B. die Workshopteilnehmer) ausreichende Vorkenntnisse über den bestehenden Service haben. Optimalerweise waren diese sogar bei der initialen Entwicklung des Service involviert oder haben einen Gesamtüberblick über Fachbereichs- und Unternehmensgrenzen hinweg.
Das SDF bietet Unternehmen ein methodisches Werkzeug, welches strukturiert bei der Entwicklung und Analyse von datenbasierten Services unterstützt. Durch den Einsatz weiterer Werkzeuge (z. B. Business Model Canvas) und Methoden (z. B. Value Proposition Design) können Unternehmen bei der strukturierten Entwicklung datengetriebener GM aktiv unterstützt werden.
Danksagung
Die Autoren danken für die finanzielle Unterstützung des Forschungsprojekts „Datenbasierte Services für Industrieunternehmen“ (DaSIe), welches durch das Bayerische Staatsministerium für Wirtschaft, Landesentwicklung und Energie gefördert wird.
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
HMD liefert IT-Fach- und Führungskräften Lösungsideen für ihre Probleme, zeigt ihnen Umsetzungsmöglichkeiten auf und informiert sie über Neues in der Wirtschaftsinformatik (WI).
