Service-Dominierte Architektur
Wie die Service-Plattform der Zukunft aussieht
Markus Warg ist Professor an der FH Wedel und IT-Vorstand der Signal Iduna Gruppe.
Ingo Bahrs ist Industry Leader Insurance bei IBM Deutschland.
Jens Stäcker ist Geschäftsführer der innovas GmbH und Vorstand der msg systems ag.
- Kunden wünschen sich einen größtmöglichen Gebrauchsnutzen von Services; das Produkt wie ein Auto möchten sie gar nicht mehr besitzen.
- Die Digitalisierung forciert jetzt den Wechsel auf den alleinigen Fokus des „Gebrauchsnutzens für den Kunden“.
- Für die Transformation von der Produktdominanz zur Servicedominanz benötigt man ein neues Service-Design
- Die dafür nötige Plattform verbindet Anwendungen, Produkte, Daten, Kunden und Co-Produzenten
- Weitere Charakteristika sind Echtzeitfähigkeit, Interaktivität, Prozess-Automatisierung und Open Source.
Gliederung
1. Gebrauchsnutzen statt Eigentum
2. Plattformen: Aufbau und Charakteristika
3. P2P-Praxisbeispiel Rechnungs-App mit einer Service Dominierten Architektur (SDA)
4. Ausblick
5. Literatur
Ob Telefon, Auto oder Musik - Apple, Car2Go und Spotify zeigen, was Kunden wollen: Gebrauchsnutzen und bitte schön einfach, schnell, transparent und der jeweiligen Situation entsprechend.
Gebrauchsnutzen, Interaktivität, Co-Creation mit dem Kunden und das Einbinden von weiteren Akteuren als Co-Produzenten (Komplementoren) sind zentrale Merkmale von Plattformen. Apple, Car2Go und Spotify haben die technischen Möglichkeiten für sich erschlossen und bereits eigene digitale Plattformen etabliert. Andere Unternehmen stehen am Beginn ihrer Reise.
Dieser Beitrag analysiert die Charakteristika von Plattformen und zeigt anhand von einem Anwendungsfall (use case) einen möglichen Weg auf, wie Unternehmen ihre Produkte unter Einbettung weiterer Servicegeber in ihrem Ökosystem zu Plattformen mit hohem Gebrauchsnutzen weiterentwickeln können.
1. Gebrauchsnutzen statt Eigentum
Apple, Car2Go und Spotify zeigen, was Kunden wollen: Individualisierten Gebrauchsnutzen und dies einfach, schnell, transparent und der jeweiligen Situation. Nur in den seltensten Fällen möchte der Kunde wirklich das Produkt Telefon, Auto oder die CD besitzen; vielmehr will er seiner individuellen Situation entsprechend kommunizieren, sich fortbewegen und Musik hören. Gelingt dies, wird es vom Kunden als wertvoll empfunden, und er ist bereit, sich als Co-Creator aktiv in den Wertschöpfungsprozess einzubringen. Damit dies gelingt, sind eine große Kundennähe und ein umfassendes Kundenverständnis notwendig. Beides kann durch konsequentes service-orientiertes Denken erreicht werden.
Service als dominierende Perspektive auf die Wertschöpfung ist nicht neu und erfährt bereits mit der service-dominierten Logik (SDL) eine theoretische Fundierung. Dabei wird ein Paradigmenwechsel von einer produkt-dominierten und auf Eigentum ausgerichteten Wertschöpfung (exchange value) hin zu einer service-dominierten, auf Gebrauchsnutzen ausgerichteten Wertschöpfung (value in use) beschrieben (Vargo & Lusch, 2004). Im Zuge dieses Paradigmenwechsels wird Service als Einsatz von Ressourcen wie Fähigkeiten und Wissen zum Vorteil eines anderen Akteures verstanden.
Zentrales Merkmal eines Services ist dabei die Interaktion/Co-Creation, da erst durch einen zielgerichteten und wechselseitigen Einsatz von Ressourcen ein spezifischer Wert bzw. Nutzen für einen Akteur geschaffen werden kann. Weitere Merkmale service-dominierter Geschäftsmodelle sind die Orientierung am Gebrauchsnutzen, der Tausch immaterieller Ressourcen (z.B. Kompetenzen) und das Einbinden von weiteren Akteuren (Komplementoren) als Co-Produzenten.
Mit diesem Paradigmenwechsel kommt es zu fundamentalen Veränderungen in der jeweiligen Rolle von Produkten und Kunden. Wurde ein Produkt traditionell verkauft (value in exchange), so ist dieses in einem service-dominierten Geschäftsmodell nur noch Input zur Wertschaffung von Gebrauchsnutzen und Träger von Services. Das Produkt - bspw. das Auto - tritt in den Hintergrund, den Produzenten droht die Gefahr der "Commodity Trap", d.h. der Wert des Produktes reduziert sich tendenziell auf den Wert eines Rohstoffs.
Auch die Rolle des Kunden verändert sich vom Konsumenten zum interaktiven Mitersteller der Lösung (Co-Creator), die ihm einen hohen Gebrauchsnutzen bringt (siehe Abbildung 1).
Viele Charakteristika der service-dominierten Logik finden sich heute bei digitalen Plattformen wieder.
2. Plattformen: Aufbau und Charrakteristika
Der Aufbau und die Funktionsweise von digitalen Plattformen lässt sich durch das folgende "5+ Akteure Schema" verdeutlichen:
Generell bilden digitale Plattformen die Grundlage für Entwicklung, Ausführung und Integration unterschiedlicher Anwendungen. Digitale Plattformen stehen für einen modularen Aufbau, modulare Software (Microservices), Offenheit, modernste Sicherheitselemente, Transferierbarkeit (Container) und Skalierbarkeit ihrer Lösungen (Cloud).
Akteur 1: Technologieanbieter
Bei der Realisierung einer Plattform arbeiten häufig unterschiedliche Akteure zusammen. Die erste Gruppe von Akteuren sind zumeist die Technologieanbieter. Diese beschaffen, konfigurieren und betreiben die Hardware. Somit stellen sie die Infrastruktur für die Softwareinstallation, Berechtigungssysteme, Testumgebungen und Sicherheitsfunktionen zur Verfügung.
Akteur 2: Plattformeigentümer
Darüber hinaus ist zwischen Plattformeigentümer und Plattformanbieter zu unterscheiden: In unserem Beispiel ist die Apple Corporation der Eigentümer der Plattform. Der Eigentümer hält die IP-Rechte (Intellectual Property), bestimmt das Design und die Spielregeln bzgl. Offenheit, Wiederverwendbarkeit und Transferierbarkeit der zugrundeliegenden Technologien und Lösungen.
Akteur 3: Plattformanbieter
Die Rolle des Plattformanbieters kann durch den Plattformeigentümer oder einen weiteren spezifischen Akteur eingenommen werden. Der Anbieter bildet die Schnittstelle zu den Komplementoren (Co-Produzenten, vierter Akteur) und den Kunden (Co-Creator, fünfter Akteur). Die wesentliche Leistung des Plattformanbieters ist es, die Architektur derart zu gestalten, dass die Wertversprechen (Lösungen, Produkte) so abgebildet werden, wie es der Plattformeigentümer wünscht.
Der Plattformanbieter bestimmt, wie stark Akteure, Anwendungen und Geräte vernetzt, anwendungsübergreifende Prozesse automatisiert und Echtzeit-Interaktionen ermöglicht werden. Je höher die Ressourcendichte und der Grad der Wiederverwendbarkeit sind, umso mehr innovative Anwendungen können erstellt werden.
Apple bspw. betreibt eine Reihe von Plattformen. Diese sind u.a. iTunes (Multimedia), AppStore (Software), iOS (iPhone, iPad, iWatch), MacOS, iCloud (Daten) usw..
Im Betrieb werden vom Plattformanbieter sämtliche Interaktionen mit dem Kunden genutzt, um das Kundenprofil und -verständnis in Echtzeit zu aktualisieren. Auf diese Weise wird das Wissen und somit die Ressourcendichte ständig gesteigert und durch deren Wieder- und Weiterverwendung werden Innovationen ermöglicht. Beispielsweise dauert es kaum zwei Minuten, die neue iWatch mit dem iPhone zu synchronisieren und sie damit zu individualisieren. Dies gelingt durch die Wiederverwendung und Übertragung von iPhone-Funktionen und -Konfigurationen auf die iWatch.
Akteur 4: Komplementoren oder Co-Produzenten
Die vierte Akteursgruppe ist die der Komplementoren. Der oder die Komplementoren bieten ergänzende Wertversprechen im Sinne einer Co-Produktion an.
Ein Beispiel für einen Komplementor zu Apple ist der Musikstreaming-Dienst Spotify. In Ergänzung zu iTunes bietet Spotify ein Abruf von Musikstücken mit Flatrate-Tarifen an. Der Erfolg von Spotify belegt die hohe Bedeutung des Gebrauchsnutzens für Kunden; obwohl iTunes auf Apple Endgeräten quasi "schon da" ist (Kreditkarte hinterlegt, kein Installationsaufwand) und die Musik bei iTunes gekauft werden kann, punktet Spotify mit einem vitalen Netzwerk (Zugriff auf Playlists) und dem komfortablen Zugriff auf vorhandene Geräte beim Gebrauchsnutzen so stark, dass es Vergleichstests dominiert. Das Besondere an Spotify ist, dass auch Spotify eine eigene Plattform etabliert hat. Dies zeigt, dass eine Plattform auch weitere Plattformen anbinden kann.
Akteur 5: Kunden
Die fünfte Akteursgruppe ist die der Kunden. Erst mit dem Gebrauch der Plattform, d.h. durch die Interaktion mit der Plattform entsteht aus dem Wertversprechen der Gebrauchsnutzen (value in use/ value in context) für den Kunden. Am Beispiel der iWatch generiert der Kunde den Gebrauchsnutzen indem er die iWatch zunächst für seine Zwecke individualisiert (Co-Creation) und dann mit der iWatch Laufen geht (Interaktion). Er erhält als Gebrauchsnutzen durch die iWatch neben der Aufzeichnung von Strecke, Distanz, Puls und Laufzeit auch andere Lösungen wie Musik (iTunes), ohne ein weiteres Gerät mitführen zu müssen.
Charakteristika der Plattform
Zusammenfassend lassen sich auch in Anlehnung an (Smedlund, 2012) und (Chesbrough, 2011) folgende Charakteristika von Plattformen festhalten:
Verbinden verschiedene Akteure
Ermöglichen von Nutzen im Moment des Gebrauches (Gebrauchsnutzen)
Vernetzen von Ressourcen wie Anwendungen, Produkte, Daten und Menschen
Durchgängige Prozessautomatisierung
Echtzeitfähigkeit
Interaktivität
Co-Produktion mit Komplementoren
Kunde als Co-Creator des Prozesses
Im Vergleich zu traditionellen Marktplätzen wie dem Wochenmarkt, auf dem physische Güter gegen Geld getauscht werden (exchange value), steht bei Plattformen oftmals die Schaffung von Gebrauchsnutzen (value in use) im Vordergrund. Ressourcen wie Menschen, Geräte, Anwendungen, Daten und Produkte werden mittels Plattformen vernetzt und übergreifende Prozesse automatisiert. Wertversprechen werden über Komplementoren (Co-Produzenten) erweitert und entfalten durch die Interaktion des Kunden ihren Nutzen im Moment des Gebrauches.
Die wesentlichen Merkmale des Paradigmenwechsels hin zur service-dominierten Perspektive und die Rolle von Plattformen als "enabler" können wie folgt dargestellt werden:
3. P2P-Praxisbeispiel mittels Service Dominierter Architektur (SDA)
Apple, Car2Go und Spotify haben die technischen Möglichkeiten digitaler Plattformen für sich erschlossen und haben bereits eigene digitale Plattformen etabliert. Andere Unternehmen stehen am Beginn ihrer Reise.
Zumeist sind es tradierte Unternehmen, die sich infolge ihrer eher hierarchieorientierten Kultur, ihrer siloartigen Organisationsformen und ihrer gewachsenen und teilweise komplexen und monolithischen IT-Landschaften schwertun. Dies obwohl ein unglaublicher Schatz an Fähigkeiten, Wissen, Daten und Prozessen in den Köpfen der Mitarbeiter, den Anwendungen und den Abläufen dieser Unternehmen vorhanden ist, der für service-dominierte Lösungen eine ideale Ausgangsposition bildet.
Für den Transformationsprozess von der Produktdominanz zur Servicedominanz benötigt es ein neues Service Design. (Vink, Tronvoll, Edvardsson, & Wetter-Edman, 2017) beschreiben, dass sich hierfür der Fokus des Service Designs von der Zentrierung auf Eigentum - Ergänzung von Produkten um Service - hin zur Schaffung von Voraussetzungen für das Co-Design von Service-Anbieter und Service-Nachfrager entwickeln muss, um das Generieren von Gebrauchsnutzen zu ermöglichen.
Die Service Dominierte Architektur schafft genau dies, d.h. die Voraussetzungen für das Generieren von Gebrauchsnutzen im Wege der Co-Creation zwischen verschiedenen Akteuren (Kunden, Unternehmen, Komplementoren usw.).
Hierfür werden einerseits die Merkmale der service-dominierten Logik in der Architektur abgebildet und andererseits die Eigenschaften von Plattformen in der technischen Realisierung sichergestellt.
Um diese Zielsetzung zu erfüllen, integriert und orchestriert die Service Dominierte Architektur fortlaufend verschiedenste Ressourcen, um eine kundenzentrierte Lösungserstellung in Echtzeit zu ermöglichen.
Das 3-Services-System und ein Data Lake
Dies geschieht auf Basis der nachfolgenden drei Service-Systeme und eines Datenhaushaltes (Data Lake). Ein Service-System kann, wie von Spohrer et al. definiert, als Konfiguration von Personen, Technologien und anderen Ressourcen, die im Wege der Interaktion mit anderen Service-Systemen gegenseitig Wert schaffen, betrachtet werden.
Das System of Operant Resources
System of Operant Resources: Das System operanter Ressourcen ist das Herz der SDA, die Plattform bzw. Werkbank oder Arbeitsplatte, wo die verschiedenen Zutaten (Ressourcen) zusammengeführt und unter Zuhilfenahme bestimmter Logiken bzw. Prozesse bearbeitet werden.
Der service-dominierten Logik entsprechend stehen hier also nicht physische Ressourcen, dort als operand resources bezeichnet, im Mittelpunkt. Stattdessen werden immaterielle Ressourcen (Kompetenzen, Wissen, Technologien, Anwendungen usw.), sogenannte operant resources, zusammengebracht, die bei der Lösungserstellung zum Einsatz kommen. Je höher die Ressourcendichte in diesem System ist, desto innovativere und wertvollere Lösungen entstehen.
Das System of Interaction
System of Interaction: Im System of Interaction wird der für eine konsequente Kundenausrichtung notwendige Datenfluss (in beide Richtungen) ermöglicht. In einer solchen Omnikanal-Integrationsschicht werden die Voraussetzungen für ein interaktives, einheitliches Kundenerlebnis über alle für den Kunden relevanten Kommunikationskanäle hinweg geschaffen. Darüber hinaus nimmt der Kunde ggf. über seine bewussten und unbewussten Dateninputs an der Erstellung und Individualisierung der jeweiligen Lösung teil, wird also zum Mitersteller oder Co-Creator.
Das System of Participation
System of Participation: Im Idealfall schließt das angesprochene Konzept der Co-Creation über den jeweiligen Kunden hinaus auch weitere Co-Produzenten ein. Auch Dritte, also weitere externe Ressourcen, werden aktiv als 'Co-Ersteller' in die jeweilige Lösung integriert. Dies kann von der Zulieferung externer Daten über die Analyse bis hin zu einer Anbindung des Unternehmens an externe Plattformen reichen, um an deren Fähigkeiten zu partizipieren.
Der Data Lake
Data Lake: Aus Unternehmenssicht werden die erhaltenen und im Lösungserstellungsprozess generierten Daten systematisch aufgenommen und in Echtzeit ausgewertet, um so ständig hinzuzulernen, das datenbasierte Kundenverständnis zu vertiefen und auf dieser Basis eine fortlaufende Verbesserung der Serviceleistungen zu erreichen.
Als Kombination von Service-Systemen stellt die SDA eine Umgebung dar, in der externe Ressourcen von Kunden (Verhalten, Eingaben etc.) und Komplementoren (Co-Produzenten, Plattformen, GPS-Daten, Wetterdaten, Marktdaten etc.) mit unternehmenseigenen Ressourcen (Vertragsdaten, Kundendaten, Services etc.) verbunden und eingesetzt werden.
Technologisch ist die SDA mit maximaler Offenheit und Unabhängigkeit umgesetzt, d.h. auf der Basis von Microservices entwickelt, die in den Service-Systemen orchestriert werden und deren Entwicklerteams agil und unabhängig arbeiten können. Die Module sind unabhängig voneinander skalierbar, leicht wartbar und können individuell mit verschiedenen Technologien implementiert werden (flexiblen Laufzeitumgebungen, Servicekatalog, Openstack, DevOpsDevOps, Container). Auf diese Weise werden die Eigenschaften der Plattformen technologisch abgebildet. Alles zu DevOps auf CIO.de
Dies ermöglicht die Generierung von Gebrauchsnutzen im Wege der Co-Creation. Abbildung 4 veranschaulicht dies.
Praxisbeispiel Rechnungs-App
Der use case "Rechnungs-App mit Einbindung Außendienstpartner" veranschaulicht wie produkt-dominierte Krankenversicherungen den Weg vom Produkt zur Plattform schaffen können (siehe Abbildung 5).
Ausgangssituation: Der Kunde hat eine Krankenversicherung und die Rechnungs-App, um Rechnungen digital einreichen zu können und schnell erstattet zu bekommen. Die Rechnungs-App ist Bestandteil der Kunden-App seines Versicherungsunternehmens; beim Installieren hat sich der Kunde für die Option entschieden, dass der ihn betreuende Außendienstpartner Einblick in die Rechnungen nehmen darf, um ihn bei Rückfragen unterstützen zu können.
Schritt 1: Der Kunde fotografiert seine Rechnungen mit seinem Smartphone und ...
Schritt 2: ... sendet diese verschlüsselt an die Versicherung. Die Unterlagen gehen im System of Interaction ein. Der Kunde erhält die Information, daß die Unterlagen eingegangen sind. Die Vollständigkeitsprüfung mit Bezugnahme auf den konkreten Versicherungsvertrag wird angestoßen. Die Prüfung ergibt, daß eine Unterlage fehlt. Der Kunde erhält eine Mitteilung.
Schritt 3: Wie vom Kunden gewünscht, erhält zeitgleich der den Kunden betreuende Außendienstpartner eine Echtzeit-Push-Nachricht, dass von seinem Kunden Rechnungsunterlagen eingereicht wurden und eine Unterlage fehlt. Der Außendienstpartner kann sofort Einblick nehmen.
Schritt 4: Der Außendienstpartner nimmt Kontakt mit dem Kunden auf und hilft ihm, die fehlende Unterlage zügig nachzureichen.
Schritt 5: Der Kunde erhält die von ihm erhoffte schnelle Auszahlung.
Für das Anbinden der Rechnungs-App an das Versicherungsunternehmen wird keine Service Dominierte Architektur benötigt. Diese ist jedoch dann sinnvoll, wenn weitere Akteure (Komplementoren bspw. wie der Außendienstpartner) und andere Ressourcen wie bspw. Identifikations-, Berechtigungs-, Prüf-, Benachrichtigungs-, Zugriffsservices (bspw. auf Bestandssysteme mit Vertragsdaten) integriert und automatisiert werden. Wenn diese Ressourcen und deren Aufbau sowie Verknüpfung als wertvoll erachtet werden und standardisiert sowie wiederverwendbar etabliert werden soll, dann macht die Etablierung einer Plattform wie der SDA Sinn.
Nutzt der Kunde zusätzlich zur Kunden-App bspw. die App für einen Medikationsplan oder additive Gesundheitsservices, wird schnell deutlich, dass es sinnvoll ist, der wachsenden Anzahl und Komplexität von neuen Services mit einer einheitlichen Architektur zu begegnen.
Dies ermöglicht die Wiederverwendbarkeit der Funktionen, ein datenbasiertes Kundenverständnis in Echtzeit, die Einbindung weiterer Akteure und damit den gezielten Aufbau von Ressourcen für service-dominierte Lösungen. Werden die Ressourcen der unterschiedlichen Apps auf einer Plattform wie der SDA zusammengeführt, so können aus der hohen Ressourcendichte etablierte Abläufe verändert und neue, innovative Lösungen etabliert werden. Bspw. kann der Kunde automatisiert prüfen lassen, ob sich die Medikamente, die aus den Rechnungen ausgelesen werden, mit seinem Medikationsplan vertragen.
Der use case zeigt, wie es Branchen möglich ist, sich von der Produktdominanz zur Servicedominanz zu entwickeln; dabei wird der Gebrauchsnutzen von Produkten durch das Einbinden von Komplementoren und die Ermöglichung von Interaktion und Co-Creation mit den Kunden schrittweise erhöht. Das ursprüngliche Produkt entwickelt sich zum Träger wertvoller Services und zur Plattform weiter.
Ausblick
Nachdem in den letzten Dekaden unter dem Begriff "Service" primär verstanden wurde, Produkte zu ergänzen und mit Alleinstellungsmerkmalen zu versehen, forciert die Digitalisierung- insbesondere mit der Trennung der Informationen vom Produkt und deren Wiederverwendung in vielfach anderen Kontexten - nun den Wechsel auf den alleinigen Fokus des "Gebrauchsnutzens für den Kunden".
Unternehmen, die diese Entwicklung verpassen, droht die "Commodity Trap", d.h. der Preisverfall ihrer Produktangebote auf den Wert eines Rohstoffs.
Anbieter wie Apple, Car2Go oder Spotify machen vor, wie aus produkt-dominierten StrategienStrategien service-dominierte Plattform-Strategien entwickelt werden. Offenheit für Interaktion, Co-Creation mit Kunden und die Einbindung von Komplementoren (Co-Produzenten) führen zu neuen Geschäftsmodellen und Lösungen, die den Gebrauchsnutzen für die Kunden und den Wert der Plattformen erhöhen. Alles zu Strategien auf CIO.de
Die Service Dominierte Architektur ermöglicht als Service-Plattform bisher produkt-dominierten Unternehmen die Transformation hin zu offenen, interaktiven, echtzeit-fähigen, service-dominierten Lösungsanbietern. Der Aufbau einer hohen Dichte an Ressourcen, die für kundenzentrierte Lösungen benötigt werden, und die Offenheit für die Co-Creation mit Kunden und die Anbindung von Komplementoren und Plattformen ermöglicht mehr Kundenorientierung und Kompetenz bei weniger Komplexität und Kosten.
Fazit – Eine These für das 21. Jahrhundert
Zusammengefasst lässt sich die Entwicklung in folgender These verdichten: Der Tausch von digitalen Lösungen (Services) ist der Handel des 21. Jahrhunderts - Plattformen sind die Boote der Eroberer.
Literaturverzeichnis |
Akaka, M. A., Vargo, S. L., & Wieland, H. (2017). Extending the Context of Innovation: The Co-creation and Institutionalization of Technology and Markets Innovating in Practice (pp. 43-57): Springer. Bahrs, I., & Huschens, J. (2017). Business Platforms - Perspektiven und Optionen. Chesbrough, H. (2011). Open Services Innovation: Rethinking your business to compete and grow in a new era. New York: Wiley. Demirkan, H., Bess, C., Spohrer, J., Rayes, A., Allen, D., & Moghaddam, Y. (2015). Innovations with smart service systems: analytics, big data, cognitive assistance, and the internet of everything. Communications of the Association for Information Systems, 37(1), 35. Demirkan, H., & Spohrer, J. C. (2016). Emerging service orientations and transformations (SOT). Information Systems Frontiers, 18(3), 407-411. doi:10.1007/s10796-016-9656-8. Lusch, R. F., Vargo, S. L., & Wessels, G. (2008). Toward a conceptual foundation for service science: Contributions from service-dominant logic. IBM Systems Journal, 47(1), 5-14. Parker, G., Alstyne, M., & Choudary, S. (2016). Platform Revolution - how network markets are transforming the economy and how to make them work for you. Shostack, L. G. (1982). How to Design a Service. European Journal of Marketing, 16(1), 49-63. Smedlund, A. (2012). Value Cocreation in Service Platform Business Models. Service Science, 4(1), 79-88. doi:10.1287/serv.1110.0001. Spohrer, J., Maglio, P., Bailey, J., & Gruhl, D. (2007). Steps toward a science of service systems. Computer, 40(1), 71-77. Spohrer, J. C., Vargo, S. L., & Maglio, P. P. (2008). The Service System is the Basic Abstraction of Service Science. Paper presented at the Proc. 41st Hawaii Int. Conf. on System Science, Big Island. Vargo, S. L., & Lusch, R. F. (2004). Evolving to a New Dominant Logic for Marketing. Journal of Marketing, 68(January), 1-17. Vink, J., Tronvoll, B., Edvardsson, B., & Wetter-Edman, K. (2017). Service Ecosystem Design: Doing Institutional Work Through Design. Paper presented at the Conference Paper. Warg, M., & Engel, R. (2016). Service-Dominierte Architektur (SDA): Kernkomponente digitaler Transformation. Zeitschrift für Versicherungswesen, 2016(12), 391-395. Warg, M., Weiß, P., Engel, R., & Zolnowski, A. (2016). Service Dominant Architecture based on S-D logic for Mastering Digital Transformation: The Case of an Insurance Company. Paper presented at the 26th Annual RESER Conference, Naples, Italy. Zolnowski, A. (2015). Analysis and Design of Service Business Models. (Doctor PhD.), University of Hamburg, Hamburg. Zolnowski, A., Weiß, C., & Böhmann, T. (2014). Representing Service Business Models with the Service Business Model Canvas - The Case of a Mobile Payment Service in the Retail Industry. Paper presented at the 47th Hawaii International Conference on System Sciences (HICSS-47), Hilton Waikoloa, Big Island. |