2
Methoden
Abdul Rahman Abdel Razek, Martin Raban, Alexander Hengels,
Christian van Husen, Matthes Elstermann, Victor Häfner,
Polina Häfner und Saed Imran
Zusammenfassung
Service Prototyping ist ein neuer innovativer Ansatz, mit dem die Service-Entwicklung
und die Service-Repräsentation verbessert werden sollen, noch bevor der Service existiert.
Service-Prototyping umfasst den innovativen Einsatz aktueller Prototyping-Techniken,
-Verfahren, -Methoden und -Tools, die sich positiv auf die Erfolgsquote von Services auswirken und den Entwicklungsprozess verbessern. In diesem Kapitel wird ein umfassendes Modell innovativer Service-Prototyping-Tools bereitgestellt, die in einer Toolbox
kombiniert sind, und die Idee eines Service-Prototyping-Konfigurators dargestellt. Die
Toolbox soll die Entscheidungsfindung verbessern und Alternativen erweitern, um die
Elektronisches Zusatzmaterial Die elektronische Version dieses Kapitels enthält Zusatzmaterial,
das berechtigten Benutzern zur Verfügung steht https://doi.org/10.1007/978-3-662-60732-9_2. Die
Videos lassen sich mit Hilfe der SN More Media App abspielen, wenn Sie die gekennzeichneten
Abbildungen mit der App scannen.
A. R. Abdel Razek (*) · A. Hengels · C. van Husen · S. Imran
Hochschule Furtwangen (HFU), Furtwangen, Deutschland
E-Mail: aba@hs-furtwangen.de; vahu@hs-furtwangen.de;
simr.dk@gmail.com
M. Raban
FCS Schirgiswalde, Görlitz, Deutschland
E-Mail: martinraban@gmx.de
M. Elstermann · V. Häfner · P. Häfner
Karlsruher Institut für Technologie(KIT), Informationsmanagement im Ingenieurwesen (IMI),
Karlsruhe, Deutschland
E-Mail: matthes.elstermann@kit.edu; victor.haefner@kit.edu; polina.haefner@kit.edu
© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2020
C. van Husen, J. Ovtcharova (Hrsg.), Multidimensionales Service Prototyping,
https://doi.org/10.1007/978-3-662-60732-9_2
47
48
A. R. Abdel Razek et al.
erfolgreiche Erbringung der Dienstleistung gemäß dem Wertversprechen sicherzustellen.
Diese Tools wurden in Korrelation mit den Design-Dimensionen, den Attributen und den
wichtigsten Entwicklungsaspekten des Service Prototyping entwickelt. Es wird erwartet,
dass durch den Einsatz der zielgerichteten Service-Prototyping-Tools und der zugehörigen Technologien der Service-Prototyping-Prozess beschleunigt, die Service-Abschlussrate verbessert und schließlich der Erfolg des Service sichergestellt wird.
2.1
Toolbox für das Service Prototyping
Abdul Rahman Abdel RazekMartin Raban, Alexander Hengels und Christian van Husen
Für die Durchführung von Service Prototyping wurden im Projekt Methoden und Werkzeuge gesammelt, systematisiert und in einer Toolbox zusammengefasst. Im Verständnis
des „dimenSion“-Kontextes ist eine Methode die systematische und zielgerichtete Art und
Weise, in welcher spezifische Werkzeuge zur effizienten Zielerreichung im Prototyping
eingesetzt werden. Werkzeuge bzw. Tools sind Bestandteile einer Methode und Arbeits-,
bzw. Hilfsmittel zur Durchführung von Aufgaben. Werden Tools in einer bestimmten, für
den Anwendungsfall sinnvollen, Reihenfolge kombiniert, sprechen wir von Toolsets. Prozeduren sind hingegen die gesamten Verfahren. Im Projekt wurden über 100 Techniken,
Methoden und Prozeduren gesammelt. Tab. 2.1 skizziert einen Auszug dieser Sammlung.
Die über 100 Techniken, Methoden oder Prozeduren sind im Projekt nach unterschiedlichen Gesichtspunkten kategorisiert worden. In Workshops und Expertengesprächen
wurde jeweils die Eignung diskutiert und in Tab. 2.2, 2.3, 2.4 und 2.5 mit Kreuzen gekennTab. 2.1 Toolbox mit ausgewählten Tools, Methoden und Prozeduren
Art
Tools
Toolbox
Service
Blueprint
Customer
Journey
Scorecard
Virtual
Simulation
Wizard of Oz
Beschreibung
Visualisierung des
Leistungserstellungsprozesses mit allen
dafür notwendigen Prozessschritten,
Ereignissen, Entscheidungen und
Kundeninteraktionen
Darstellung der Berührungspunkte der
Kunden mit dem Service, um ein Bild zu
erlangen, wie Kunden den Prozess oder
Service wahrnehmen und in welchen
Phasen Berührungspunkte auftreten.
Künstlich nachgebaute Realität
Inhalt
Diagramme
Episoden, Ende-zuEnde-Erfahrung,
Sprache, Dauer,
Wiederholung
Simulation mittels
Virtueller Realität
Testen der NutzerTest eines Produkts, bei dem ein
Proband annimmt, mit einem autonomen oberfläche
System zu kommunizieren, in
Wirklichkeit jedoch ein anderer Mensch
im Verborgenen die Reaktionen des
Systems erzeugt.
2 Methoden
49
Tab. 2.1 (Fortsetzung)
Art
Methoden
Toolbox
Personas
Beschreibung
Nutzermodelle, die Personen einer
Zielgruppe in ihren Merkmalen
charakterisieren. Dadurch kann z. B.
einem Entwicklerteam aufgrund
umfangreicher Beschreibungen
geholfen werden, sich in die Lage der
potenziellen Nutzer hinein zu versetzen.
Story Telling Durch den Gebrauch von einfachen
Wörtern illustriert der Erzähler die
Lösung in Form einer Geschichte und
unterstützt damit die Erforschung der
Serviceidee.
Hotspot View Identifiziert Bereiche mit Potenzial für
den Kunden und das Geschäft.
Bestimmung der Interventionspunkte.
Lego Serious Moderierte Methode, die die Vorzüge
Play
des Spiels und des Modellierens mithilfe
von Lego-Steinen mit den Interessen der
Geschäftswelt verbindet. Ziel ist es,
neue Ideen zu fördern, die
Kommunikation zu verbessern und
Problemlösungen zu beschleunigen.
Video
Methode, um Ideen und Konzepte
Prototyping
audiovisuell zu realisieren. Innovative
Ideen können mit emotionaler
Faszination durch bewegte Bilder per
Storytelling-Ansatz getestet, verfeinert
und kommuniziert werden.
Design Fiction Design Fiction ist ein Designansatz, der
durch Prototyping und
Geschichtenerzählen über neue Ideen
spekuliert. Ziel ist es, sich von der
Routine statischer Szenarien zu
entfernen.
Gamification Einbindung von spieltypischen
Elementen in einen
themenunabhängigen Kontext.
Understanding Veranstaltungen, an denen sich kleinere
Workshop
Gruppen in begrenzten Zeitspannen
intensiv mit einem Thema
auseinandersetzen. Der Fokus liegt dabei
auf dem gemeinsamen Erarbeiten eines
Verständnisses zu bestimmten
Problemen.
Inhalt
Verbale Beschreibung
potenzieller Nutzer
Verbales Geschichtenerzählen
Tabellen
Moderierte
professionelle
Workshops mit
Einsatz von
Legosteinen
Video und Multimedia
Video erklärt die Idee
Teamwork,
Serviceüberprüfung
Zwischenmenschlicher Austausch
(Fortsetzung)
50
A. R. Abdel Razek et al.
Tab. 2.1 (Fortsetzung)
Art
Prodzeduren
Toolbox
System Map
Design
Workshop
Beschreibung
Visuelle Beschreibung der
servicetechnischen Organisation: Die
verschiedenen kontextuellen
Zusammenhänge von Hauptfaktoren und
die Flüsse von Materialien, Energie,
Informationen und Geld im System
werden holistisch dargestellt.
Veranstaltungen, an denen sich kleinere
Gruppen in begrenzten Zeitspannen
intensiv mit einem Thema
auseinandersetzen. Der Fokus liegt dabei
auf dem gemeinsamen Erarbeiten eines
kollektiven Konzepts.
Inhalt
Karten, Bild,
Verbindungen
Neue Ideen schaffen
(Abdel Razek et al. 2017)
Tab. 2.2 Kategorisierung und Bewertung ausgewählter Tools, Methoden und Prozeduren bei der
Dienstleistungsentwicklung
Zweck
Toolbox
Service Blueprint
Personas
Story Telling
Customer Journey
Scorecard
Hotspot View
Virtual Simulation
System Map
Lego Serious Play
Video Prototyping
Design Fiction
Wizard of Oz
Gamification
Understanding
Workshop
Design Workshop
KommuErstellung Evaluation nikation
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
(Abdel Razek et al. 2017)
x
x
x
Service Prototyping Key Development
Aspects
Anforderungs-defi- KonImplemenzeption tierung
Idee nition
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
2 Methoden
51
Tab. 2.3 Kategorisierung und Bewertung ausgewählter Tools, Methoden und Prozeduren aus Sicht
des Dienstleistungsprototypen
Toolbox
Service Blueprint
Personas
Story Telling
Customer Journey Scorecard
Hotspot View
Virtual Simulation
System Map
Lego Serious Play
Video Prototyping
Design Fiction
Wizard of Oz
Gamification
Understanding Workshop
Design Workshop
Aufwand
niedrig mittel hoch
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Detailgrad
Ähnlichkeitsgrad
niedrig mittel hoch niedrig mittel hoch
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
(Abdel Razek et al. 2017)
Tab. 2.4 Kategorisierung und Bewertung ausgewählter Tools, Methoden und Prozeduren bezüglich
der Design Dimensionen und immersiven Technologien
SP Design Dimensionen
Toolbox
Service Blueprint
Personas
Story Telling
Customer Journey
Scorecard
Hotspot View
Virtual Simulation
System Map
Lego Serious Play
Video Prototyping
Design Fiction
Wizard of Oz
Gamification
Understanding
Workshop
Design Workshop
(Abdel Razek et al. 2017)
Immersive Technologien
Augmented
Virtual
Akteure Artefakte Prozess Umgebung Reality
Reality
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
52
A. R. Abdel Razek et al.
Tab. 2.5 Kategorisierung und Bewertung ausgewählter Tools, Methoden und Prozeduren für weitere Kategorien
Weitere Zwecke
Toolbox
Service Blueprint
Personas
Story Telling
Customer
Journey
Scorecard
Hotspot View
Virtual
Simulation
System Map
Lego Serious
Play
Video
Prototyping
Design Fiction
Wizard of Oz
Gamification
Understanding
Workshop
Design
Workshop
Test und
Ideen Experimente Evaluation
x
Planung Information Lernen
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Integration
x
x
x
x
x
x
x
x
(Abdel Razek et al. 2017)
zeichnet. Eindeutige Abgrenzungen sind nicht möglich, es soll lediglich eine Orientierung
gegeben werden. Allgemeine Kategorien waren z. B., welche Tools zur Erstellung, Evaluation oder Kommunikation besonders geeignet sind. Die gleiche Bewertung wurde für
die Schwerpunkte im Dienstleistungsentwicklungsprozess, den sogenannten „Key Development Aspects“ (vgl. Abb. 1.9) Ideenfindung, Anforderungsdefinition, Konzeption
und Implementierung durchgeführt.
Bei Dienstleistungsprototypen wird zwischen „Effort“ (Aufwand der Erstellung) „Fidelity“ (Detaillierungsgrad) und „Resolution“ (Ähnlichkeitsgrad im Verhältnis zur finalen
Dienstleistung) unterschieden. Die Tools wurden jeweils graduell nach Ausprägung der
„Key Attributes“lals „niedrig“, „mittel“ und „hoch“ unterschiedlich evaluiert.
Ferner wurde eine Bewertung der Toolbox bezüglich der „Design Dimensions“ (Akteure, Artefakte, Umgebung, Prozess), vgl. Abschn. 1.6.2, durchgeführt; zusätzlich wurde
die Toolbox hinsichtlich immersiver Anwendungsmöglichkeiten, siehe Tab. 2.4, bewertet.
Tab. 2.5 zeigt die Bewertung der Toolbox nach Zweck in der Anwendung.
Die Bewertung der Toolbox anhand verschiedener Anwendungsmöglichkeiten verdeutlicht die spezifische Eignung der einzelnen Tools für bestimmte Kategorien; so sind je
nach Ziel und Zweck bestimmte Tools geeigneter als andere. Aufbauend auf den Bewer-
2 Methoden
53
Abb. 2.1 Video-Marker: Service Prototyping Toolsets (https://doi.org/10.1007/000-011)
tungen wurden praktische Anwendungen entwickelt. So wird in Abschn. 2.2 ein Konfigurator vorgestellt, der den Anwender bei der Auswahl der Tools unterstützt und Hilfestellung für die praktische Anwendung der Toolbox leistet.
Abb. 2.1 dient als Marker der SN More Media App und zeigt per Video pro Zweck ein
Anwendungsbeispiel.
2.2
Konfigurator für das Service Prototyping
Abdul Rahman Abdel RazekMartin Raban, Alexander Hengels und Christian van Husen
Im Rahmen des Forschungsprojekts wurden Techniken, Methoden und Prozeduren für die
prototypische Dienstleistungsentwicklung konsolidiert und untersucht, um den Entstehungsprozess von Dienstleistungsprototypen zu verbessern. Bei der Vielzahl von bereits
vorhandenen Prototyping-Tools ergaben diverse Fragen Aufschluss darüber, wie Dienstleistungsentwickler bei deren Auswahl unterstützt werden können:
•
•
•
•
•
Zu welchem Zweck sollte jedes Tool verwendet werden?
Wie wird jedes Tool angewandt?
Was sollte von jedem Tool erwartet werden?
Wie effektiv ist jedes Tool im spezifischen Anwendungsfall?
Welche Techniken, Methoden und Prozeduren sollten situationsadäquat verwendet werden?
• Wann ist der optimale Zeitpunkt, die jeweiligen Tools einzusetzen?
Dieses Unterkapitel beschreibt ein Konzept einer digitalen interaktiven Lösung, die
Dienstleistungsentwickler dabei unterstützt, Tools systemgestützt auszuwählen und anzuwenden. Dabei ist eine Applikation entstanden, welche in Abb. 2.2 skizziert ist; zudem
dient Abb. 2.2 als Marker für ein Video, welches einen Prototyp des Konfigurators als
Demonstrator vorstellt.
Um die Erstellung des Konfigurators zu realisieren, wurde eine Toolbox konzipiert,
vgl. Abschn. 2.1. Durch Experten-Workshops und Nutzeranalysen entstand eine Lösung in
Form einer Applikation. Das erarbeitete Konzept wurde anhand von nutzerzentrierten
54
A. R. Abdel Razek et al.
Abb. 2.2 Screenshot der App: Service Prototyping Methoden (https://doi.org/10.1007/000-00z)
Testverfahren mit Hilfe eines interaktiven Prototyps auf Usability und User Experience
getestet.
In einer Analysephase wurden die Bedürfnisse, Anforderungen und Aufgaben der späteren Nutzer analysiert und als Personas festgehalten. Anhand der Personas, konzipiert in
verschiedenen Anwendungsszenarien, wurden die Aufgaben potenzieller Dienstleistungsentwickler definiert und von diesen ausgehend, Anforderungen an die Verwendung der
Toolbox abgeleitet.
Die App wurde inhaltlich in drei Hauptbereiche aufgeteilt: Methoden, Szenarien und
Projekte.
Der Bereich „Methoden“ beinhaltet alle über die Anwendung verfügbaren PrototypingMethoden und gibt zusätzlich die Möglichkeit, diese nach eigenen Anforderungen zu filtern und auszuwählen. Darüber hinaus können Methoden zu Projekten gebündelt und Detailinformationen abgerufen werden. Diese geben Auskunft darüber, wann eine Methode
angewendet werden kann, wie die entsprechende Umsetzung erfolgtund wie das Endergebnis aussieht.
Über den Bereich „Szenarien“ erhalten die Nutzer Zugang zu vorgefertigten Prototyping-Szenarien. Diese sind wie Projekte aufgebaut und enthalten Methoden, die auf einen
bestimmten Zweck ausgerichtet sind. Nutzer können bereits in der Vergangenheit umgesetzte Projekte zu Szenarien umwandeln, welche anschließend unter diesem Bereich auffindbar sind und für zukünftige Projekte als Vorlage genutzt werden können. Die Funktion
der Szenarien soll somit als einsteigerfreundliches Feature der Anwendung fungieren, sowie geübte Anwender dabei unterstützen, effizient Projekte umzusetzen, indem sinnvoll
kombinierbare und aufeinander aufbauende Tools vorgeschlagen werden.
2 Methoden
55
Unter dem Bereich „Projekte“ können aktuelle und archivierte Prototyping-Projekte
der Nutzer aufgelistet werden, die zuvor aus Methoden erstellt wurden. Der Nutzer erhält
im Projektkontext wichtige Informationen über die Verteilung der Methoden auf einzelne
Key Development Aspects des Dienstleistungserstellungsprozesses, den durchschnittlichen Aufwand und den durchschnittlichen Grad der Detaillierung. Zudem können Projekte dauerhaft in Szenarien umgewandelt werden, sodass diese wiederum als Muster für
ähnliche Projekte angewendet werden können. So wird dem Nutzer Zeit erspart, welche er
sonst bei der Auswahl der Methoden aufwenden müsste.
2.2.1
Konzept
Um die Anwendung des Konzepts auf Funktionsweise, Nutzbarkeit und Potenzial testen
zu können, wurde ein interaktiver Prototyp erstellt und von potenziellen Anwendern getestet. Das wurde mit der Software „Axure RP 8“ umgesetzt, die es ermöglicht, grafische
Prototypen zu erstellen und diese mit interaktiven Elementen auszustatten. Die Herausforderung bestand darin, eine prototypische Methodendatenbank zu realisieren, die sich
nach Key Development Aspects und Attributen filtern lässt. Um Filterfunktionen zu implementieren, wurden Tools in einer Datenbank hinterlegt und mit Attributen ausgestattet.
Der Filter wurde nach diesen aufgelisteten Funktionen am Prototyp umgesetzt:
•
•
•
•
•
•
•
•
•
•
•
•
Key Development Aspects
Attribute: Aufwand und Detaillierungsgrad
Methodenanzeige als Methodenkarten inklusive Übersicht
Zähler für angezeigte Methoden
Suchfunktion für Methoden
Detailansicht von Methoden
Selektion von Methoden
Projektansicht eines exemplarischen Projekts
nachträgliches Hinzufügen und Entfernen von Methoden bei Projekten
Methoden-Favoriten
Einführungstutorial (Onboarding)
Vertikale Hauptnavigation
Bei den sogenannten „Repeatern“ tauchten Probleme auf, welche Wartezeiten bei der
Nutzung des User Interfaces verursachten. Da sich die Filterfunktion ohne Repeater jedoch nicht umsetzen ließ, musste dieser Kompromiss zu Lasten der Performance eingegangen werden. Den Probanden wurde bei den Tests mitgeteilt, dass es sich um einen
Prototyp handelt, der noch unter Performance-Problemen leidet. Sie wurden darum gebeten, ausreichend abzuwarten. Die Performance und die damit zusammenhängenden
Feedback-Prozesse des Prototyps können aus diesem Grund nur bedingt in der Evaluation
des Konzepts berücksichtigt werden.
56
2.2.2
A. R. Abdel Razek et al.
Evaluation
Nach der Fertigstellung des Konzepts erfolgte eine formative Evaluation des interaktiven
Prototyps anhand von Nutzertests. Bei formativen Nutzertests werden in der Regel Systeme, die sich noch in der Entwicklung befinden oder weiterentwickelt werden sollen, auf
ihre Gebrauchstauglichkeit getestet. Die Tests sollen Aufschluss darüber geben, wie Nutzer mit dem System umgehen. Den Probanden wurden Aufgaben gestellt, die unter möglichst realistischen Bedingungen mit dem zu testenden System bearbeitet und gelöst werden sollten. Während der Bearbeitung der Aufgaben wurden die Probanden durch einen
oder mehrere Usability-Experten beobachtet. Durch Äußerungen der Nutzer oder Beobachtungen und Messungen durch den Usability-Experten konnten so Erkenntnisse darüber
gewonnen werden, wie die Nutzer das System bedienen, welche Probleme dabei auftreten
können und welche Maßnahmen getroffen werden müssen, um die erkannten UsabilityProbleme zu beheben. Um die Objektivität der Messungen zu wahren, hat der Moderator
bei der Durchführung der Tests so wenig wie möglich in die Aufgabenbearbeitung der
Nutzer eingegriffen. Er griff erst dann ein, wenn Probranden den Test nach mehrmaligen
Anläufen nicht fortführen konnten.
Die Tests ergaben wesentliche Potenziale zur Weiterentwicklung der Applikation:
• Unzureichende Performance des Systems förderte Fehler in der Bedienung.
• Die Icons der Entwicklungsphasen waren teilweise noch nicht spezifisch genug dargestellt, um eine eindeutige Zuordnung zu gewährleisten.
• Der Button zur Methodenerstellung wurde aufgrund zu dezenter Gestaltung von einigen
Nutzern nicht sofort wahrgenommen. Das grundlegende Konzept dieser Funktion wurde
von Nutzern zwar erfolgreich angewendet, jedoch ergaben sich Probleme, aus ausgewählten Methoden Projekte zu erstellen. Den Nutzern wurde zu wenig kommuniziert,
welche Methoden genau ausgewählt wurden und wie sie diese zu einem Projekt bündeln können.
• Beim Ausblenden der Bildschirmtastatur sind Probleme aufgetreten.
• Die Suchfunktion wurde kaum genutzt, da den Nutzern nicht sofort ersichtlich war,
dass diese vorhanden und nutzbar ist.
• Nutzer konnten visualisierte Informationen teilweise nicht erfassen oder entschlüsseln,
da die Struktur von „Headern“ bei Detailansichten und Projektansichten nicht optimal
dargestellt wurde.
• Fehlerhafte Einstellungen in den „Boundaries“ der „Methoden-Scroll-Funktion“ führten zu Problemen.
• Das Systemfeedback war zu dezent gestaltet, sodass Nutzern oft nicht ganz klar war, ob
das System momentan arbeitet oder nicht auf eine Eingabe reagiert.
• „Methodenkarten“ waren bei den „Aufgaben“ zum Teil verdeckt und wurden dadurch
nur partiell von Probanden wahrgenommen.
2 Methoden
57
• Nutzern war nicht eindeutig klar, wie beim „Onboarding“ vorangeschritten wird und
wann dieses beendet wurde.
• Nutzern fehlte eine umfangreiche Einführung in den gesamten Themenkomplex der
Anwendung.
In Fortsetzung dieses Projekts ließe sich aus diesen Weiterentwicklungspotenzialen
schnell ein konkreter Maßnahmenkatalog erstellen.
Positiv ist zu erwähnen, dass die Nutzer trotz der geringen Performanz des Prototyps,
das Bedienkonzept der Anwendung generell gut handhaben und wichtige Interaktionen
mit dem System meist ohne Probleme durchführen konnten. Die eingesetzten Interaktionstechniken waren somit leicht verständlich und konnten gut von den Probanden erlernt
sowie angewandt werden. Die elementare Funktion der Filterung von Methoden und deren
Umsetzung wurde von den Probanden verstanden und erfolgreich angewendet.
Insgesamt wurde das Konzept der „dimenSion Toolbox“ von den Probanden und Stakeholdern als eine Lösung bewertet, die das Potenzial hat, eine wichtige Rolle als Werkzeug
in der Entwicklung von Dienstleistungen einzunehmen. Probanden können sich gut vorstellen, mit solch einem Tool zu arbeiten und mit Hilfe der Toolbox Informationen darüber
zu erlangen, wann sie bestimmte Methoden einsetzen können und wie sie diese erfolgreich
anwenden. Die Höhe des endgültig zu erwartenden Nutzens nach Anwendung der Methoden hängt jedoch stark davon ab, wie gut Methoden textuell und medial ausgearbeitet
werden und wie hoch der finale Informationsgehalt unter Zuhilfenahme der Toolbox ist.
Dies sollte durch weitere Nutzertests in der Zukunft mit einem weiter fortgeschrittenen
Prototyp überprüft werden. Insgesamt ergeben sich durch die Schlussfolgerungen und Optimierungsvorschläge aus den durchgeführten Nutzertests, der Analyse qualitativer Interviews und den Erkenntnissen aus dem durchgeführten Design Workshop eine Vielzahl an
Möglichkeiten, um die Entwicklung der Toolbox weiter fortzuführen. Neben der Anpassung von bereits existierenden Strukturen und Funktionen der Anwendung zählt die detaillierte Ausarbeitung des Konfigurators sowie die Ergänzung des Toolbox-Konzepts um
weitere Interaktionstechniken.
Zusätzlich zu den definierten Anforderungen hat sich abgezeichnet, dass Anfänger im
Service Prototyping ein „Onboarding“ benötigen, das ihnen verständlich das Konzept erklärt, welchen Vorteil die Anwendung von Prototyping Methoden in der Dienstleistungsentwicklung mit sich bringt und wie ihnen die Toolbox dabei helfen kann, adäquate Methoden auszuwählen und anzuwenden. Dienstleistungsentwickler wollen bei der Auswahl
und chronologischen Zusammensetzung der Methoden vom System unterstützt werden.
Dies hat zur Folge, dass eine zusammenhängende Logik unter den Methoden entwickelt
werden muss, auf deren Grundlage das System Entscheidungen darüber treffen kann, welche von Nutzern ausgewählte Methoden aufeinander folgen sollten, sodass ein möglichst
effizienter Workflow ermöglicht wird, bei dem durch Methoden generierte Informationen
aufeinander aufbauen.
58
2.3
A. R. Abdel Razek et al.
Rapid Service Prototyping
Matthes Elstermann
2.3.1
Motivation
In „dimenSion“ wurde die Entwicklung von Dienstleistungen mittels Service-Prototyping
erforscht. Im Kern ging es dabei darum, Aspekte einer zukünftigen möglichen Dienstleistung so zu beschreiben, dass pozentielle Service-Stakeholder das Konzept leicht erfassen
und vor allem erfahren können, um auf Basis ihres Feedbacks die Dienstleistungsentwicklung voranschreiten zu lassen (vgl. Abb. 2.3).
Im Prinzip ist das tatsächliche Vorgehen dabei abhängig von den Präferenzen der Organisation, die eine Dienstleistung entwickeln will. Das entwickelte agile Vorgehensmodell
für die Dienstleistungsentwicklung, welches auf den im Rahmen des „dimenSion“ gesammelten Erfahrungen beruht ist daher als Empfehlung zu verstehen. Es handelt sich dabei
um eine Adaption der „Scrum Systematik“ (Schwaber 2004; Wikipedia „Scrum“ 2018;
Larman 2009), die erfolgreich in der Entwicklung von Software eingesetzt wird. Die
Adaption eines Software-Entwicklungsmodells für Dienstleistungen ist naheliegend, bedarf jedoch des Verständnisses und der Annahme folgender Umstände und Hypothesen.
Dienstleistungsentwicklung ist wie Softwareentwicklung Sowohl Software als auch
Dienstleistungen sind im Prinzip immateriell und bekommen erst durch ihre Ausführung
eine Bedeutung in der realen Welt; in beiden Fällen geht es in der Entwicklung darum,
Beschreibungen von dem zu erstellen, was ausgeführt werden soll. Im Falle von Software
ist dies der Programmcode, der von einem digitalen Prozessor ausgeführt werden soll; im
Falle von Dienstleistungen sind dies z. B. Prozesshandbücher, mündliche Weisungen etc.,
die Vorgaben zur Ausführung eines Prozesses setzen. Ein nennenswerter Unterschied be-
Abb. 2.3 Agile ServicePrototyp-Entwicklung
2 Methoden
59
steht jedoch darin, dass die Beschreibung einer Dienstleistung in der Regel weniger formal ist als die einer Software (Handbücher, Skizzen und PowerPoint Präsentation vs. Programmcode).
Ein weiterer Punkt der Ähnlichkeit zwischen Software und Dienstleistungen ist der
Umstand, dass bei beiden die Entwicklung niemals wirklich abgeschlossen ist oder sein
muss, solange diese profitabel ist. Es existiert immer eine aktuelle Version von dem, was
getan werden sollte. Wenn während der (wiederholten) Ausführung eines Programms oder
einer Dienstleistung Verbesserungsmöglichkeiten auffallen, können diese relativ einfach
in die Beschreibungen eingearbeitet und in kommenden Durchläufen angewandt und getestet werden. Bei Software ist dies meist formal durch eine Versionsnummer gekennzeichnet. Bei Dienstleistungen muss dies nicht unbedingt so formal definiert werden,
erfolgt jedoch auf ähnliche Weise, in dem z. B. Sachbearbeiter Arbeitsabläufe neu strukturieren, um schneller arbeiten zu können.
Dienstleistungsentwicklung heißt Lernen und Erfahrungen sammeln Neuentwicklungen, also Entwicklungen ohne Existenz einer aktuellen Version als Grundlage, bedingen primär, Erfahrungen zu sammeln und aus diesen zu lernen.
Diese sind alle möglichen Rahmenbedingungen, Grenzen und Möglichkeiten, die eine
zukünftige Dienstleistung betreffen (z. B. gesetzliche Vorgaben, Normen, Potenziale von
Technologien etc.), die erkannt und in die Entwicklung eingebracht werden sollten.
Dies führt zum Problem, dass, außer in den trivialsten Fällen, mit großer Wahrscheinlichkeit am Anfang der Entwicklung noch nicht alle Erkenntnisse vorliegen, die für eine
präzise Vorhersage von Dauer, Umfang, und Aufwand der Entwicklung der späteren
Dienstleistung nötig sind. Um dieses Problem in der Praxis zu bewältigen, besteht oft die
Gefahr, dass das Entwicklungsbudget von Anfang an über- oder unterschätzt wird, sodass
daraus entsprechende Verlängerungen der Laufzeit resultieren.
Dieses Problem besteht bei der Softwareentwicklung in gleicher Form. Als Antwort
darauf entstanden die agilen Vorgehensmodelle, bei denen zwischen „Tätigkeiten“ und
„Ergebnissen“ unterschieden wird, und es so möglich ist, neue Erkenntnisse direkt in die
Steuerung des Entwicklungsprozesses einfließen zu lassen.
Dienstleistungsentwicklung enthält Softwareentwicklung Ein weiterer Grund dafür,
sich bei der Dienstleistungsentwicklung an der Softwareentwicklung zu orientieren ist,
dass moderne Dienstleistungsentwicklung im Prinzip Softwareentwicklung bedeutet. Jede
einzelne der von den Anwendungspartnern geplanten Dienstleistungen besaß entweder
direkt oder indirekt Softwareelemente; vielmehr war bei vielen eine Software der Hauptbestandteil der Entwicklung. Eine nicht-triviale Dienstleistung, die ohne ein IT-System
funktioniert, kann nahezu ausgeschlossen werden.
Dienstleistungsentwicklung ist kontinuierlich Es gibt bei Dienstleistungen, wie auch
bei Software, zwar immer einen aktuellen Stand, jedoch ist dieser selten abgeschlossen
und muss in der Regel an neue Umstände angepasst werden.
60
A. R. Abdel Razek et al.
Sowohl Dienstleistungen als auch Software haben dynamische Komponenten, welche
in der Entwicklung berücksichtigt werden müssen. Speziell im Service-PrototypingKontext sollte die Dienstleistungsentwicklung als Konsequenz eher als „kontinuierlicher
Verbesserungsprozess“ verstanden werden, als die Entwicklung eines finalisierbaren
Produktes. Ein aktueller Stand oder eine aktuelle Version einer Service-Beschreibung ist
gleichzeitig immer auch der Prototyp für die nächste Version.
Ein agiles Manifest des Service Prototypings Dienstleistungsprototypen können auch
klassisch entwickelt werden, indem eindeutig vordefinierte Phasen nach einer Checkliste
linear abgearbeitet werden. Abgeleitet von den Erkenntnissen in der Softwareentwicklung
ist jedoch davon auszugehen, dass ein solches Vorgehen, wenn idealisiert durchgezogen,
nicht praktikabel ist (Schwaber 2004).
Agile Vorgehensmodelle im Allgemeinen, Scrum im Speziellen, stellen dem klassischen Vorgehensmodell einen anderen Ansatz gegenüber, der mit dem Konzept des Service
Prototyping harmoniert. Im agilen Manifest (Beck 2001) fordert Beck vier Grundprinzipien (im englischen Original):
•
•
•
•
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Dabei ist zu erwähnen, dass die Aussagen zwar fordern, dass der jeweils erste Teil
der vier Statements wichtiger ist als der zweite und im Entscheidungsfall präferiert
werden sollte, dies aber im Gegenzug nicht bedeutet, dass der zweite Teil völlige Missachtung erfahren sollte. Auch bei agilem Vorgehen sollte es Pläne, Dokumentationen,
Verträge und die Anwendung von Werkzeugen und vordefinierten Prozessen geben;
diesen sollte jedoch nicht starr gefolgt werden, so dass diese im Mittelpunkt der Entwicklung stehen.
Sinngemäß lässt sich im Rahmen der Dienstleistungsentwicklung und unter Berücksichtigung der vorherigen Punkte ein agiles Manifest für die Dienstleistungsentwicklung
ableiten bzw. teils direkt übernehmen, welches den Ansprüchen des Service Prototyping
gerecht wird.
• Individuen und Interaktion vor festen Abläufen und Werkzeugen – dieser Grundsatz
kann quasi direkt übernommen werden und unterstreicht die Bedeutung der eigentlichen Entwickler und ihrer Zusammenarbeit.
• Nutzbare Service Prototypen vor perfekt ausgearbeiteter Dokumentation – Dieses
Statement erscheint etwas widersprüchlich, unterstreicht jedoch, dass beim Service
Prototyping primär die Entwicklung von Beschreibungen fokussiert wird, die das Erleben der zukünftigen Dienstleistung ermöglichen und sekundär explizit ausgearbeitete
Handbücher, Musterdefinitionen, Dresscodes etc.
2 Methoden
61
• Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen – Diese Aussage entspricht der Grundidee des Service Prototyping. Es ist unwahrscheinlich, dass eine
Dienstleistungsentwicklung, die zuerst oder führend durch eine Rechtsabteilung gesteuert wird, sonderlich effizient oder zielführend ist (jenseits von juristischen Dienstleistungen).
• Reagieren auf Veränderungen vor dem Folgen eines Plans – auch hier existieren
große Ähnlichkeiten zwischen Softwareentwicklung und Service Prototyping. Erkenntnisse, die während der Entwicklung gewonnen werden, wie z. B. Ankündigungen von
Konkurrenten oder neue Technologien, sollten in den weiteren Verlauf der Entwicklung
einfließen können. Dies schließt ebenfalls umfangreiche Änderungen mit ein, wie
z. B. Verlängerungen der Projektlaufzeit oder eine vorläufige Paralyse aller Tätigkeiten
(ohne personelle Konsequenzen für die beteiligten Entwickler).
Diese Statements entsprechen in der Regel der Erwartungsnorm, gelingen jedoch bei
der tatsächlichen Umsetzung nicht ohne weiteres.
2.3.2
Grundprinzipien des Rapid-Service-Prototyping-Vorgehens
Allgemein sollten die in diesem Abschnitt vorgestellten Grundprinzipien und das Vorgehensmodell des „Rapid Service Prototyping“ verstanden sein, um fundierte Entscheidungen darüber treffen zu können, ob diese für die eigene Entwicklung zu adaptieren sind,
oder ob Gründe und Rahmenbedingungen vorliegen, die gegen eine Adaption und für ein
anderes, möglicherweise klassischeres Vorgehen sprechen.
Grundsätzlich besteht das Vorgehen des Rapid Service Prototypings aus drei zyklisch
aufeinanderfolgenden Aktivitäten: Beschreiben, Erleben und Evaluieren (vgl. Abb. 2.4).
Innerhalb eines Dienstleistungsentwicklungsprojektes wiederholen sich diese Aktivitäten
Abb. 2.4 Grundzyklus des
Rapid-Service-Prototyping
62
A. R. Abdel Razek et al.
mehrmals, wobei allgemein festgelegt ist, wie oft diese Aktivitäten wiederholt werden
oder wie lange ein Zyklus dauert.
Beschreiben Das „Beschreiben“ von Aspekten der zukünftigen Dienstleistung erfordert
in der Regel das größte Engagement während der Dienstleistungsentwicklung. Es gilt die
Klärung der Fragen:
• Welche Akteure, Artefakte, Umgebungen und Prozesse gibt es, die für die Dienstleistung relevant sind?
• Welche Tools sollen für die gewünschte Beschreibung eingesetzt werden?
• Zu welchen Tools gibt es bereits Beschreibungen oder Modelle? Welche Beschreibungen müssen neu erstellt, verändert oder gelöscht werden?
• Welche zusätzlichen Informationen sind für die Beschreibungen notwendig und wie
können diese gewonnen werden?
Das Ergebnis des „Beschreibens“ sollte, nach Beantwortung dieser Fragen, ein Dienstleistungsprototyp sein, der zumindest rudimentär erlebbar ist; je höher der investierte Aufwand, umso besser die Erlebbarkeit des Prototyps.
Erleben Die Aktivität des „Erlebens“ impliziert den Test eines Dienstleistungsprototyps,
indem Stakeholder diesen anwendungsorientiert nutzen. Je nach Art des Service Prototyps
kann dies mit mehr oder weniger Ressourceneinsatz ausgeführt werden. Dies ist der Fall,
wenn es sich beim Prototyp z. B. um das hypothetische Durchspielen einer ersten Prozessskizze auf Papier handelt, die in einigen Minuten eines Review-Meetings abgehandelt
werden kann. Handelt es sich jedoch um einen elaborierten Prototyp, der größeren Material- und Personalaufwand beinhaltet und von Endkunden erprobt werden soll, kann unter
Umständen lediglich die Organisation einer entsprechenden Veranstaltung oder eines Panels zum „Erleben“ des Prototyps ein aufwendiges Unterfangen sein.
Evaluieren Die grundsätzliche Idee des Service Prototyping ist es, eine Dienstleistung möglichst früh erlebbar zu machen. Um diesen Nutzen zu optimieren wird während der Aktivität des „Evaluierens“ das aus den Usability-Tests generierte Feedback
der entsprechenden Stakeholder ins Kalkül mit einbezogen, sodass die gewonnen Erfahrungen direkt in den Entwicklungsprozess einfließen können. In vielen Fällen ist die
Evaluation in die einzelnen Service-Prototyping-Methoden bereits integriert, so dass
keine speziellen Tätigkeiten geplant werden müssen. Allgemein gilt es bei allen Evaluationsaktivitäten, die gemachten Annahmen zu überprüfen und die zukünftige Dienstleistung hinsichtlich aller wichtigen Aspekte auf ihre Funktionalität und Machbarkeit
zu prüfen.
Zusammenfassend lässt sich sagen, dass beim „Evaluieren“ eine Bewertung möglicher
Risiken und Chancen durchgeführt wird. In der Anfangsphase einer Entwicklung gibt es
hier Analogien zum klassischen Requirementsengineering.
2 Methoden
63
Der Komplexität und Individualität ist es geschuldet, dass die Bewertung auch Aspekte
umfassen kann, die nicht explizit in den vorgestellten Methoden inkludiert sind. Insbesondere Fragen der Kosten oder Preisstrategie sollten zusätzlich berücksichtigt werden. Diese
sind zwar implizit niemals ausgeschlossen, entstammen jedoch meist aus eigenständigen
Methoden anderer Bereiche (z. B. Investitionsrechnungen).
Einen Teil der Tätigkeit dieses Aktivitätsbereiches besteht auch darin, generell zu bestimmen, welche Faktoren der Dienstleistung zu welchem Zeitpunkt evaluiert werden
sollten. Idealerweise kontinuierlich alle Faktoren zu jedem Zeitpunkt, jedoch stehen dafür
selten von Anfang an alle Informationen zur Verfügung, oder es würde die verfügbaren
Personal- oder Zeitressourcen überwältigen. Hier gibt es zu Beginn einer Dienstleistungsentwicklung starke Ähnlichkeiten zum klassischen Requirementsengineering, bei dem es
darum geht, allgemein zu bestimmen, welche Rand- oder Rahmenbedingungen, gesetzliche Vorgaben, Kundenwünsche etc. existieren.
2.3.3
Sprints – Vorgehen und Tracking
Die eigentliche Entwicklungsarbeit findet in sogenannten „Sprints“ statt; diese sind fest
definierte, immer gleichlange Zeiträume (Timeboxes). Die Länge eines Sprints hängt von
den Präferenzen und (Zeit-)Ressourcen der entwickelnden Organisation und der beteiligten Personen ab und liegt klassischerweise in der Softwareentwicklung zwischen ein und
vier Wochen.
Den Zeitraum selbst nutzen die Dienstleistungsentwickler, um die Entwicklungsarbeit
zu leisten, die das Ziel hat, am Ende des Sprints einen nutzbaren Prototyp zu generieren;
also mit den ausgewählten Methoden und/oder IT-Werkzeugen die nötigen Beschreibungen zu erstellen, die eine Evaluation ermöglichen.
Spätestens gegen Ende eines jeden Sprints finden prinzipiell drei Arten von Meetings
statt, die allerdings auch kombiniert werden können, solange sich alle Beteiligten ihrer
unterschiedlichen Bedeutung bewusst sind und jedem Aspekt auch entsprechend formal
Platz eingeräumt wird.
Diese drei Vorgänge sind das „Review“ der bisherigen Dienstleistungsentwicklung,
welches im Prinzip aus dem „Erleben“ des Service Prototyps und den bisherigen Beschreibungen besteht. Danach fließen die Ergebnisse aus dem Review und generell aus
dem Sprint in die „Retrospektive“ und „Evaluation“ ein, welche wiederum die Grundlage bildet, um das weitere Vorgehen im nächsten Sprint formal festzulegen.
Die entsprechenden Aufgaben werden in zwei Arten von Dokumenten festgehalten.
Konkret anstehende Aufgaben werden im „Sprint-Back-Log“ vermerkt. Längerfristige
Aufgaben, die jedoch im folgenden Sprint noch nicht relevant sind, oder für die aktuell
keine Ressourcen bereitstehen, werden im allgemeineren „To-Do-Backlog“ vermerkt, aus
dem wiederum auch für den kommenden Sprint Aufgaben ins Sprint-Back-Log übernommen werden können und sollten (vgl. Abb. 2.5).
64
A. R. Abdel Razek et al.
Abb. 2.5 Grundsätzliches Iteratives-Sprintbasiertes Vorgehen
2.3.4
Team, Scrum Master, Product Owner, und Stakeholder
Im Gegensatz zum klassischen Projektmanagement, bei dem ein einzelner Manager Verantwortung aber auch absolute Weisungsbefugnis hat, gibt es beim klassischen „Scrum“
nur das (Service-) Entwicklungsteam, das selbstverantwortlich seine Aufgaben wählt und
erfüllt. Dies setzt grundsätzlich die Mitarbeiterfähigkeit des eigenständigen Denkens und
der Empathie voraus, sich in aktuelle oder potenzielle Kunden hineinzuversetzen, oder mit
ihnen im Verlauf der Dienstleistungsentwicklung zusammen zu arbeiten.
Das Entwicklerteam wird durch einen „Scrum-Master“ unterstützt, dessen Aufgabe die
Organisation der Entwicklung ist. Diese Person kann Teil des Teams sein, sie ist jedoch
kein weisungsberechtigter Vorgesetzter. Die Aufgabe des Scrum-Masters besteht darin,
dass eigentliche Vorgehen voranzutreiben und die Einhaltung der „Scrum-Abläufe“ durchzusetzen und die Kommunikation zwischen dem Team und anderen Beteiligten zu unterstützen; dies schließt auch Manager (Head of Business) außerhalb des Projekt-Teams mit ein.
Im Scrum gibt es keinen Projektmanager, dafür aber einen „Product-Owner“. Klassischerweise ist dies eine Person, die die Interessen des Auftraggebers bzw. der Stakeholder
vertritt; diese Person ist bezüglich einzelner Aufgaben im Detail jedoch nicht weisungsbefugt. Vielmehr legt ein Product-Owner die Prioritäten der bestimmten Entwicklungsaspekte der Dienstleistung fest und steht für Fragen des Teams zur Verfügung. Ein ProductOwner ist auch die Rolle, die am Ende jedes Sprints das Team und die Arbeit des Teams,
ungeachtet der tatsächlichen Ergebnisse, entlastet; d. h. sollte es innerhalb des Sprints zu
neuen Erkenntnissen oder unvorhergesehenen Ereignissen gekommen sein, die in der
Lage sind, das Ergebnis der bisherigen Entwicklung quasi wertlos zu machen, so kann und
sollte ein Product-Owner trotzdem die eigentliche Arbeit des Teams, insofern berechtigt,
als adäquat anerkennen und gleichzeitig für das weitere Vorgehen Prioritäten und Richtun-
2 Methoden
65
Abb. 2.6 Das Service Entwicklungsteam und seine Interaktionen.
gen anpassen. Letztendlich ist es ein Product-Owner, die Person, die von der bisher geleisteten Arbeit und vom aktuellen Service Prototyp überzeugt werden muss, damit die
Entwicklung fortgesetzt werden kann. Das ist besonders dann von Bedeutung, wenn die
Anzahl ursprünglich definierter Sprint-Zyklen überschritten wurde und entschieden werden muss, ob weitere Ressourcen für eine Entwicklung genutzt werden sollten, oder ob
eine Fortsetzung nicht mehr plausibel erscheint (vgl. Abb. 2.6).
2.3.5
Typische Fehler und Missverständnisse bei der Adaption von
Agilem Vorgehen
Die Grundzüge agilen Vorgehens lassen sich relativ einfach zusammenfassen. Zwischen
dem theoretischen Verständnis und einer praktischen Ausführung stehen jedoch oftmals
einige Hindernisse, die nicht zuletzt darauf beruhen, dass auf Basis des Scrum-Vorgehens
anders als traditionell verfahren wird.
Es gibt dabei unterschiedliche Missverständnisse und Fehler, die sich abzeichnen können und dadurch tatsächlich agiles Vorgehen oder entsprechende Erfolge behindert werden.
Scrum überschätzen Agil ist das was sowieso geschieht! Nämlich vor allem dann wenn
sich in Entwicklungsprojekten und -prozessen nicht geplante Situationen einstellen und
ein ggf. vorher entwickelter Projektplan neu arrangiert oder ganz verändert werden muss
66
A. R. Abdel Razek et al.
um überhaupt zu einem nutzbaren Ergebnis zu kommen.1 Und da, frei nach Heraclius,
Veränderung die einzige Konstante ist, kommt es im Verlauf jedes Entwicklungsvorhabens
zu neuen Erkenntnissen oder Veränderungen die einen solchen Schritt notwendig machen.
Scrum nimmt in diesem Kontext einen hypothetischen Projektplan (Objekt) aus dem
Fokus der Entwicklungsorganisation (nicht der Entwicklung selbst), und stellt dem ein
Koordinationssystem gegenüber, das sich an den weniger variablen Dingen, nämlich fixer
Zeititerationen (Sprints) und dem Menschen (Team), orientiert. Es stellt damit den Menschen in den Mittelpunkt und entspricht dem Grundgedanken der Subjekt-Orientierung.
Im Gegensatz dazu muss erwähnt sein, dass agiles Vorgehen niemals alle Probleme von
Entwicklungsarbeit „magisch“ lösen kann und seinen Möglichkeiten niemals überschätzt
werden sollten. Es ist grundsätzlich eine andere aber potenziell bessere Art Entwicklungsvorgehen zu organisieren nicht aber die Ultimative lösung.
Scrum ≠ Zwei Wochen Meilensteine Ob Scrum bzw. agiles Vorgehen wirklich verstanden wurde, kann man unter anderem auch an der Antwort auf die folgende Frage erkennen:
Was ist der Unterschied zwischen einem agilen Vorgehen mit Sprints und einem Projektplan mit zweiwöchigen Meilensteinen?
Wenn auf diese Frage die Antwort gegeben wird, dass es kaum oder gar keinen Unterschied gebe, dann wurde Scrum nicht verstanden. Trotzdem handelt es sich um eine klassische Antwort auf diese Frage und beruht auf der Annahme, dass sich alles exakt und
präzise vorausplanen lässt. Sollte es zu Abweichungen vom idealen Projektplan kommen,
so ist eine mögliche Vermutung meistens die Unzulänglichkeit der beteiligten Personen,
die diese entweder durch Mehrarbeit kompensieren müssen oder die entsprechenden beruflichen Konsequenzen zu befürchten haben. Dies führt sehr leicht zu Frust oder Überarbeitung, vor allem wenn eine vermeintliche Leistungsmessung (Meilenstein) alle zwei
Wochen geschieht.
Individuelle Inkompetenz kann als ein Faktor in der Abweichung von einem Projektplan stehen, oft jedoch spielen andere Faktoren eine Rolle und ändern auch nichts an der
Tatsache, dass mit Änderungen umgegangen werden muss, möglichst ohne ein Projektteam zu überarbeiten bzw. zu überfordern.
Der Unterschied zwischen agilem Vorgehen und Meilensteinplanung lässt sich am besten anhand des „magischen“ Projektmanagement-Dreiecks erklären (abgeleitet von (Keßler und Winkelhofer 2011, S. 55)). Die drei Spitzen des Dreiecks stellen die Hauptfaktoren
eines Entwicklungsprojektes dar, welche die Qualität des zu entwickelnden Gegenstandes
beeinflussen: Zeit, Kosten, und (geplanter) Umfang (vgl. Abb. 2.7).
Aussage des Projektmanagement-Dreieck-Modells ist, dass unter den Annahmen, dass
die Qualität nicht beeinträchtig werden darf und dass es unweigerlich zu Änderungen im
Diese Erkenntnis ist nicht originär lässt sich aber ebenso wenig einer bestimmten Quelle zuordnen.
Sie wurde jedoch des öfteren im Gespräch von Managern bestätigt die für Projekte außerhalb ursprünglicher Projektpläne verantwortlich waren.
1
2 Methoden
67
Abb. 2.7 Unterschiede zwischen den Anpassungsmechanismen im traditionellen und im agilen
Projektmanagement
Plan kommen wird, immer nur zwei der drei Seiten gemeinsam fixiert oder festgesetzt
werden können.
Im klassischen Projektmanagement sind meistens die Kosten und der Umfang vorgegeben; Abweichungen müssen über die Zeit kompensiert werden. Das kann dabei entweder
die Projektlaufzeit sein oder die tatsächliche Arbeitszeit der Entwickler (Stichwort: Überstunden).
Im Gegensatz dazu ist es bei agilen Vorgehensmodellen der Umfang, der variiert werden kann, da Kosten in jedem Fall fix sind und jeweilige Entwicklungszeiten durch die
Dauer und Anzahl der Sprints festgelegt sind.
Abweichungen vom Umfang Die Vorstellung, dass eine Dienstleistung oder ein Projekt
nicht vollumfänglich entwickelt wird, mag auf den ersten Blick irritieren. Eine „Nicht
vollumpfängliche Entwicklung“ ist jedoch rein praktisch nur dann möglich, wenn von Anfang des Projektes an alle Aspekte und Rahmenbedingungen eines Projektes detailliert
bekannt und ausgeplant sind (Lastenheft/Pflichtenheft) und es im Verlauf zu keinerlei Veränderungen der Rahmenbedingungen kommt. Sollte dies der Fall sein, ist es auf der anderen Seite jedoch fraglich, warum und was überhaupt „entwickelt“ werden soll, wenn alles
bereits zu Projektbeginn detailliert verstanden sund hochgradig trivial sind.
In nicht trivialen Fällen muss davon ausgegangen werden, dass ein solches Vorwissen
nicht umfänglich besteht, der Plan ggf. unbekannte Aspekte nicht berücksichtigt, und
dass externe Ereignisse Anpassungen notwendig machen. Agile Vorgehensweisen (vgl.
Abschn. 2.3.1, unter: „Ein agiles Manifest des Service Prototypings“) setzten sich daher
zum Ziel, innerhalb der bereitgestellten Entwicklungszeit und mit den bereitgestellten
Ressourcen etwas zu entwickeln, das funktioniert und dem Unternehmen oder der Organisation Mehrwert schafft (laufende Dienstleistungsprototypen vor Befolgen eines Planes).
Abb. 2.8 veranschaulicht diesen Unterschied zwischen zeitlicher Organisation inklusive
der Abweichung von Ergebnissen und den klassischen Phasen-basierten Konzepten.
68
A. R. Abdel Razek et al.
Offizielle Deadline
1 Zeit einheit
Ergebnis
Zeit
Plan: Arbeitsaufwand/Umfang in bestimmten Intervallen
Längere Dauer
Längere Dauer
Abweichung - Klassisches Phasenkonzept: Fester Inhalt, variable Zeit
Zeit
Zeit
Abweichung - agiles Vorgehen: Feste Intervalle, variabler Inhalt
Abb. 2.8 Agiles Projektmanagement im Vergleich zum klassischen Phasenkonzept
Agiles Projektmanagement hat zum Ziel innerhalb der gesetzten Entwicklungszeit das
bestmögliche Entwicklungsergebnis zu liefern, wenn es zu Abweichungen vom Ursprünglichen Plan kommt. Zusammengefasst lässt sich folgende Aussage treffen: Veränderungen
im Umfang sind etwas Gutes, solange sie konstant und zielführend vorgenommen und
gesteuert werden.
Keine Phasen Das klassische Projektmanagement bzw. klassische Vorgehensmodelle
nutzen oft das Beschreibungskonzept der Phasen (Herstatt und Verworn 2007; Cooper
2010) oder (Jacoby 2015), wobei typische Phasen die der Geschäftsplanung des Requirements-Engineerings, die Entwicklung, das Testen etc. sind. Diese werden meist in grafischen Darstellungen verdeutlicht, die den Eindruck erwecken, dass diese Phasen linear
aufeinander folgen, und dass dementsprechend wiederum die Entwicklungsarbeit geplant
und durchgeführt wird.
Dies ist jedoch eine der größten gedanklichen Fehler, die gemacht werden können. Die
genannten Aspekte sollten vielmehr als Aufgabenbereiche verstanden werden, in die im
Verlauf der Entwicklung, je nach aktueller Lage im Entwicklungsprojekt, unterschiedlich
viel Energie gesteckt wird (vgl. Abb. 2.9).
Kein agiles Umfeld – „Agil“ nur dem Namen nach Ob und inwiefern agiles Vorgehen
tatsächlich Vorteile bringt, ist umstritten. In Fällen, in denen agile Projekte scheitern, liegt
dies auch daran, dass zwar das Vorgehen als agil bezeichnet wird, jedoch das gesamte Umfeld nicht darauf ausgelegt ist. Dies war z. B. bei zwei nicht an dimenSion beteiligten
Unternehmen der Fall, mit denen wir während der Laufzeit des -Projektes bezüglich der
Thematik von agilem Vorgehen in Kontakt standen.
2 Methoden
69
Inception
I1
Elaboration
E1
E2
Construction
C1
C2
C3
Transition
C4
T1
T2
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Time
Abb. 2.9 Aufwand von Aufgabenbereichen im Verlauf eines Entwicklungsprojektes (Wikipedia –
Iterative Development 2019)
Vor allem das Management bzw. die entsprechende Unternehmenskultur ist es, die
letztendlich agile Konzepte adaptieren und akzeptieren müssen. Es nützt weinig, einen
klassischen Projektleiter simplistisch inScrum-Master umzubenennen, solange dessen
Vorgesetzten ihn gleichermaßen, so wie zuvor, als Einzelperson verantwortlich machen
und ihn anhand der reinen Ergebnisse bewerten. Eine solche rein ergebnisorientierte Bewertung ist für die Vorgesetzten vermeintlich einfach da sie sich nicht im Detail mit der
Arbeit ihrer Untergebenen beschäftigen müssen, wird jedoch dazu führen, dass der entsprechende Leistungsdruck an das Entwicklerteam weitergegeben wird und dann doch
wieder strikte Arbeitsvorgaben gemacht werden. Konflikte mit dem Team, welches eigentlich das Recht hat, eigenständig seine Arbeit zu erfüllen, sind quasi vorprogrammiert oder
zumindest wahrscheinlich.
Besonders große Unternehmen mit einer lange tradierten, hierarchischen Firmenstruktur, in dem Erfolg und Macht gleichbedeutend mit der Anzahl der Untergebenen ist, laufen
Gefahr so agiles Vorgehen nur dem Namen nach einzuführen. Dies liegt u. a. an den klassischen Belohnungs- und Kontrollmechanismen einer Hierarchie wie formale Beförderungen, Bemessung der Entlohnung anhand der Anzahl der untergebenen Mitarbeiter oder
Projekten, formales Weisungsbefugnisse anhand der erreichten Stufe in der Hierarchie etc.
Eine Einführung von agilem Vorgehen würde ein Aufbrechen dieser Strukturen und zur
formalen Abgabe von Kompetenzen führen (z. B. keine direkte Weisungsbefugnis mehr)
und damit einen Verlust gerade für die höheren Manager bedeuten. Auch setzt eine solche
Einführung die Fähigkeit zum Anpassen der eigenen Konzepte und Gedankenstrukturen
über Aufbau und Abläufen einer Organisation voraus. Geht man davon aus das höhere
Manager ehr zu den älteren Beschäftigten gehören und das die entsprechenden Fähigkeiten im höheren Alter abnehmen, ist ein Szenario sehr einfach denkbar, bei dem alteinge-
70
A. R. Abdel Razek et al.
sessene Führungskräfte tradierten Führungsstile einfach weiterverwenden (Stichwort „Beratungsresistenz) Bekannte Konzepte wie das Peter-Prinzip (Peter und Hull 2001) oder das
Dilbert-Prinzp (Adams 1997) spielen hier ebenso eine hinderliche Rolle.
2.4
Service Prozessmodellierung
Matthes Elstermann
Die formale Beschreibung von Prozessen (Prozessmodellierung) galt lange Zeit und gilt
stets als Spezialwissen. Prozessmodellierung ist in Großprojekten und für das Management von Geschäftsprozessen ein etabliertes Vorgehen.
Für die Entwicklung von Dienstleistungen im dimenSion-Kontext ist diese zwingend
notwendig und essenzieller Bestandteil des Service Prototypings. Darüber hinaus sind
viele Service-Entwicklungstechniken und -methoden im Prinzip Übungen darin, Prozesse
hinsichtlich unterschiedlicher Aspekte zu beschreiben und mit diesen Beschreibungen
weiter zu arbeiten; explizit genannt werden kann hier z. B. das Service-Blueprinting. Zumeist machen diese Methoden jedoch keine expliziten Vorgaben darüber, wie ein Prozess
modelliert werden soll.
Prozesse können auf unterschiedlichste Arten beschrieben werden. Bereits eine einfach
textuelle Beschreibung eines Ablaufes im Rahmen einer Dienstleistung kann als Prozessmodell betrachtet werden. Auch wenn textliche Beschreibungen prinzipiell leicht zu erstellen sind, unterliegen sie den Einschränkungen und Mehrdeutigkeiten der natürlichen
Sprachen und den Fähigkeiten der beteiligten Personen. Darüber hinaus sind textuelle
Beschreibungen nur sehr bedingt maschinenlesbar und daher automatisch ausführbar, was
im Rahmen einer prototypischen Serviceentwicklung sehr nützlich wäre.
Als Alternativen zu textuellen Beschreibungen bieten sich unterschiedliche Arten von
grafischen Prozessmodellierungen an. Diese können völlig frei gestaltet werden (PowerPointProzessmodellierung) oder sich aber an einer speziellen Notation orientieren, wie z. B.
Standard Flussdiagramme oder über „Ereignisse gesteuerte Prozessketten“ (EPKs). Die
meisten dieser Formate besitzen zwar eine definierte Syntax, die jedoch oft auf die Definition für grafische Schreibweisen beschränkt ist und keine formalen Spezifikationen zur
Ausführung enthält. Dies ist jedoch für die Nutzung mit IT Systemen, und damit für eine
schnelle und effiziente Service-Entwicklung, unabdingbar.
Um sinnvoll im Rahmen des Service Prototypings eingesetzt werden zu können, sollten
Prozessbeschreibungen die beiden genannten wichtigen Aspekte gleichzeitig und gleichermaßen ermöglichen. Sie sollten zum einen den Dienstleistungsentwicklern bzw.
Prototyp-Erstellern helfen, Ideen zu kommunizieren. Zum anderen sollten sie aber auch
gleichzeitig möglichst formal sein, um sie effektiv als technische Grundlage für die Prototypenerstellung nutzen zu können, idealerweise in einer Form, in der Änderungen am Prozessmodell gleichzeitig Änderungen am Prototyp bedeuten und eine entsprechend dynamische und iterative Entwicklung erfolgen kann, die ungebunden von langwierigen
2 Methoden
71
Wartezeiten ist, bei der Techniker und Programmierer erst die gewonnenen Erkenntnisse
in das Service Prototyping System überführen und anpassen müssen. Dies gilt unter der
Annahme, dass der Service Prototyp ein technisches/digitales System ist.
2.4.1
Subjekt-Orientierte Prozessmodellierung mit PASS
Prinzipiell kann jede Prozessmodellierung bei der Dienstleistungsentwicklung verwendet werden.
Es wurde jedoch schon bei Planung des dimenSion-Projektes festgestellt, dass für alle
Anforderungen des Rapid Service Prototypings mit dem dimenSion-Konzept nur ein Paradigma wirklich genutzt werden kann: die subjektorientierte Prozessmodellierung in Form
der Modellierungssprache „Parallel Activity Specification Schema“ (PASS). Dies wird auf
den kommenden Seiten erläutert.
Subjekt, Objekt, Verb Einer der Hauptgründe für die Unzulänglichkeiten vieler Beschreibungssprachen ist, dass diese im Prinzip nur Prädikat-orientiert sind, d. h.: die
Grundlage ihrer Beschreibungssystematik ist allein das Verb bzw. der „Task“. Alle anderen Aspekte können zwar berücksichtigt werden, müssen dies jedoch nicht.
Damit decken diese Beschreibungssprachen jedoch nur einen der drei Hauptbestandteile im Grundmuster der menschlichen Kommunikation ab, die für gut verständliche
Beschreibungen bzw. Modellierungen notwendig wären. Dieser Logik folgt (Buchwald
2009) in seinem Plädoyer für die Subjekt-Orientierung, in dem die Grundaussage von
(Fleischmann 1994) aufgegriffen wird und die Programmierparadigmen mit den Strukturen der menschlichen Sprache verglichen werden. Die vollständige Beschreibung einer
Aktion in den natürlichen Sprachen und damit in den Grundmustern unseres Denkens,
bedarf eines Subjektes, eines Objektes und eines Prädikates (Verb).
Während die deutsche Sprache in der Grundstruktur auch der Subjekt Verb Objekt
(SVO) Struktur folgt und in komplizierten Sätzen sogar noch flexibler ist, ist die Reihenfolge von 50 % aller Sprachen der Welt tatsächlich SOV (Dryer 2017). Dies bedeutet, dass
bevor eine Aktion beschrieben wird, sowohl erst der Handelnde (das Subjekt), als auch das
Objekt genau in dieser Reihenfolge als Information bereitgestellt werden sollten um möglichst einfach verstanden werden zu können (vgl. Abb. 2.10).
Diesem Informationsbedarf werden jedoch bestehende Prozessmodellierungsansätze
nur teilweise gerecht, wie die Analyse durch (Schmidt et al. 2009) zeigte (vgl. Abb. 2.11).
Die Untersuchung geht lediglich darauf ein, ob es überhaupt Möglichkeiten gibt, alle
Aspekte auszudrücken. Dass das Subjekt, bzw. der Akteur, für die Beschreibung einer
Dienstleistung relevant ist, und daher in die Modellierung einfließt, ist jedoch nicht exklusiv für das „Subjektorientierte Modellierungsparadigma“ formuliert und seine Berücksichtigung ist daher auch nicht das, was die Subjekt-Orientierung ausmacht.
Die Antwort auf die Frage nach dieser Kernessenz der Subjekt-Orientierung lässt sich
daher aus unserer Sicht so beantworten:
72
A. R. Abdel Razek et al.
Abb. 2.10 Abbildung der
Natürlichen Sprache durch
Beschreibungsparadigmen der
Programmierung
(Buchwald 2009)
Abb. 2.11 Beschreibungsmöglichkeiten der Grundelemente menschlicher Sprache in verschiedenen Modellierungssprachen (Schmidt et al. 2009)
2 Methoden
73
c Subjektorientierte Prozessmodellierung bedeutet, bei der Prozessmodellierung von
Anfang an eine grundsätzliche, getrennte und unumgängliche Betrachtung von aktiven
Elementen in einem Prozess (Subjekten) und passiven Datenobjekten, die von Subjekten
genutzt und zwischen Subjekten ausgetauscht werden, vorzunehmen.
Die Betrachtung von Objekten im Kontext der Subjekt-Orientierung lässt ggf. die Frage
nach einer objektorientierten Prozessbeschreibung aufkommen; diese existiert nur theoretisch. Sie käme einer Vorgehensmodellierung gleich, bei der für einzelne Objekte komplett
im „Passiv“ beschrieben wird, was mit ihnen geschehen kann oder soll. Das Subjekt kann
dabei optional weggelassen werden. Sollte dieses Modellierungsmuster durchgezogen
werden, entsteht jedoch eine formale Problematik bzw. Beschreibungslücke; wenn etwa
beschrieben werden muss, dass ein Arbeiter ein Objekt A und ein Objekt B zu einem Teil
C kombiniert. In diesem Fall ist es unklar, zu welcher Objektbeschreibung dieser Vorgang
gehört. Subjekt-Orientiert kann dieser natürlich einfach als Aufgabe der „Arbeitsbeschreibung“ werden, der selbst jedoch kein Objekt ist, sondern ein Subjekt.
Prozesse werden dabei immer als sozio-technisches System beschrieben, bei dem die
Beteiligten und ihre Interaktion im Fokus der Modellierung stehen. Wichtig ist dabei jedoch zu verstehen, dass das Subjekt explizit keine reale Person, sondern vielmehr ein Beschreibungskonzept für eine Art prozesskontextspezifische Rolle oder Akteur ist.
Eine Modellierung ist nur dann subjektorientiert, wenn die Beschreibung der Subjekte
explizit vorgesehen ist, und nicht optional ist, oder implizit weggelassen werden kann.
Diese Betrachtung muss vielmehr zentraler Bestandteil der Modellierung sein und Aktivitäten können nur zugeordnet zu einem Subjekt beschrieben werden. Der Abstraktionsgrad
ist dabei nicht vorgegeben. Ein Subjekt als aktive Einheit bzw. als Arbeitsbereich kann für
eine gesamte Fabrik stehen oder ebenso für einen Teiltätigkeitsbereich einer einzelnen Person. Es ist jedoch notwendig, die Kommunikation und Interaktion zwischen diesen Subjekten als Austausch von Nachrichten bzw. (Informations-)Objekten explizit zu definieren.
Subjekte sind dabei keine „Rollen“, auch wenn sie nah verwandt sind. Vielmehr stellen
sie abstrakte Akteure innerhalb eines festen Prozesskontextes dar. Nachrangig wird dann
das einzelne Verhalten dieser Akteure als sequenzielle oder iterative Abfolge von Aktivitätszuständen beschrieben (ähnlich eines Zustandsautomaten). Dadurch entsteht ein Modell, das vollständig dem einfachen Subjekt-Verb-Objekt-Prinzip natürlicher Sprachen
entspricht („Akteur ‚X‘ führt Aktion ‚Y‘ an/mit Objekt ‚Z‘ aus“).
Dieses relativ simple Konzept verlangt, dass Aktionen immer formal einem Subjekt
zugewiesen werden müssen, bzw. dass diesem ein Name gegeben werden muss. Parallele
Ausführungen von Tasks sind nur durch Einführen und sinnvolles Benennen eines weiteren Akteurs/Subjektes in dem Prozessmodell darstellbar. Die Interaktion dieser beiden
muss dann wiederum explizit modelliert werden und die Informationseinheiten/Nachrichten, die sie dabei austauschen, sauber im Sinne der Objektorientierung benannt werden.
Eine „schludrige“ Darstellung bzw. Nicht-Benennung von potenziell komplexen Interaktionen ist nicht zulässig. Vielmehr muss immer sauber differenziert sein, was ein Akteur
ist, was ein Objekt ist, und was eine Aktion/Interaktion ist.
74
A. R. Abdel Razek et al.
In diesem Sinne kann auch zu gewissen Teilen mit bestehenden Modellierungssprachen
subjektorientiert modelliert werden, z. B. mit einem strikt limitierten „Subset“ von
„BPMN“. Dabei ist es jedoch notwendig, einen Prozess ausschließlich innerhalb der
Grenzen mehrerer „Single-Lane-Pools“ darzustellen, sowie deren Verknüpfung nur mittels „Messages“ und unter Vermeidung von „AND-Splits“ – um die wichtigsten Konzepte
zu benennen. Eine durchgehende Verwendung nur von „Swimlanes“ ist dagegen nicht
hinreichend, da hier zwar der prinzipielle Gedanke ähnlich ist und eine solche Modellierung somit zumindest als „subjektbasiert“ betrachtet werden kann, jedoch nicht als „subjektorientiert“. Da eine solche strikte Limitierung einer Sprache, die vom Grundverständnis vieler ihrer Nutzer anders genutzt werden sollte, jedoch nicht zielführend ist, weswegen
sich die Nutzung einer, für die subjektorientierte Prozessmodellierung explizit konzipierten Sprache, anbietet.
S-BPM und PASS Die einzige explizit subjektorientierte Modellierungssprache ist das,
von (Fleischmann 1994) konzipierte „Parallel Activity Specification Schema“ (PASS)
(siehe Abb. 2.12). Es ist vollständig formal und automatisiert ausführbar, was es für eine
Konzipierung von teilweise digitalen Service Prototypen ideal macht.
Die entsprechenden Diagramme werden oft auch als „S-BPM Diagramme“ bezeichnet.
„S-BPM“ steht dabei für die Managementdisziplin des „subjektorientierten Business Prozess Managements“, eine Variante des Geschäftsprozessmanagements, das im Kern auf
dem subjekt-orientierten Modellierungsparadigma basiert und eine entsprechende Prozess-
Abb. 2.12 Kurzeinführung in die subjektorientierte Prozessmodellierungssprache des „Parallel
Activity Specification Schemas “ (PASS)
2 Methoden
75
beschreibung forciert, aber auch darüber hinaus beim inhaltlichen Arbeiten mit Prozessen
und Prozessbeteiligten die Einbindung von allen Akteuren fokussiert. Als Schlagwort hat
sich der Begriff S-BPM dadurch als eine Art Oberbegriff für die gesamte Forschungsdisziplin etabliert (Fleischmann et al. 2011). Zum Beispiel, lautet der Name der seit 2009 jährlichen Fachkonferenzreihe zum Thema Subjekt-Orientierung „S-BPM ONE“.
Abb. 2.12 erläutert die Grundelemente der Sprache. Ein einfaches Prozessmodell besteht aus einem „Subjekt-Interaktions-Diagramm“ (SID), das verschiedene Subjekte enthält, die jeweils auf ein eigenes „Subjekt-Verhaltens/Behavior-Diagramm“ (SVD/SBD)
verweisen. In den Tab. 2.6 und 2.7 werden alle Elemente der Prozessmodellierungssprache
PASS erläutert.
Die Zustände der Subjektverhaltensdiagramme beschreiben dabei meistens Tätigkeiten
mit der impliziten Interpretation, dass diese gerade ausgeführt werden, wenn sich ein Subjekt in diesem Zustand befindet. Auf den Transitionspfeilen ist jeweils die Bedingung bzw.
Tab. 2.6 Elemente des Subjekt-Interaktions-Diagrammes in PASS
Subjekte sind aktive Einheiten bzw.
Arbeitsbereiche in einem Prozess. Zu jedem
Subjekt gehört jeweils implizit ein
Subjektverhaltensdiagramm (SVD), das seine
(Inter-)Aktionsmöglichkeiten innerhalb des
dargestellten Prozesses beschreibt.
Multi-Subjekte sind Subjekte mit gleichem
Verhalten, die mehrfach innerhalb eines
Prozesses existieren können (mehrere
Instanzen).
Interface Subjekte haben kein spezifiziertes
Verhalten (SVD); dieses liegt außerhalb des
betrachteten Prozesses. Sie können entweder
als Black Boxen dienen, weil ihr Verhalten im
Detail nicht relevant (zu einfach) oder
unbekannt ist, oder sie dienen als Platzhalter/
Wegweiser für weitere Prozessmodelle
(Interface).
Subjekte kommunizieren über Nachrichten,
die asynchron ausgetauscht werden. Die
Nachrichten definieren alle
Interaktionsmöglichkeiten eines Subjektes
innerhalb des beschriebenen Prozesses.
Nachrichten können dabei reale/physikalische
Objekte repräsentieren (z. B. eine
Warenlieferung) oder auch eine immaterielle
Information (z. B. eine E-Mail).
Erweiterung in Anlehnung an Fleischmann (1994)
76
A. R. Abdel Razek et al.
Tab. 2.7 Elemente von Subjekt-Verhaltens- Diagrammen (SVD)
In Empfangszuständen wartet ein Subjekt
auf das Eintreffen einer Nachricht (eines
Ereignisses). Ist eine Nachricht eingetroffen,
die auf einer Empfangstransition als
Exit-Bedingung vermerkt wurde, kann der
Zustand über die entsprechende
Empfangstransition verlassen werden.
Subjekte befinden sich implizit immer in
einem Zustand ihres SVDs, der durch eine
von mehreren möglichen Transitionen
verlassen wird (XOR). Die Do- oder
Funktionszustände stellen dabei eine
eigenständige Aktion des Subjektes dar,
deren Abbruchbedingungen auf einer von
mehreren Funktions-/Do-Transitionen
vermerkt werden.
In Sendezuständen bereitet ein Subjekt das
Senden einer Nachricht vor. Mit dem Folgen
der Sendetransition wird diese versendet.
Im Gegensatz zu Empfangs- und
Funktionszuständen dürfen Sendezustände
nur eine ausgehende Sendetransition haben.
Start- und End-Zustände: Jeder Zustand in
einem SBD kann als Startzustand definiert
werden, in dem ein Subjekt einen Prozess
beginnt. Empfangs- und Funktionszustände
können darüber hinaus als Endzustände
definiert werden, in dem ein Subjekt seinen
Prozess beendet.
Time-Transitionen definieren einen
Zustandsübergang, der durch das Ablaufen
einer Frist oder das Erreichen eines Datums
ausgelöst wird. Es gibt zwei Arten von
zeitbasierten Transitionen: Transitionen, die
nach Ablauf einer gewissen Zeit, seit der
Ausgangszustand betreten wurde, triggern
(Timer). Alternativ können in zyklischen
SBDs auch Zeittrigger genutzt werden, die
regelmäßige Intervalle als Auslöser haben
(Reminder).
User Cancel Transitionen können genutzt
werden, um zu beschreiben, dass ein (meist
Empfangs-) Zustand über diese Transition
auch ohne das Empfangen einer bestimmten
Nachricht, sondern auf Entscheidung eines
Systemnutzers verlassen werden kann.
Erweiterung in Anlehnung an Fleischmann (1994)
2 Methoden
77
das Ergebnis vermerkt, das die Ausführung eines Zustandes erbracht haben muss, um über
diese Transition verlassen werden zu können; also z. B. der Empfang oder das Versenden
einer entsprechenden Nachricht von oder an ein anderes Subjekt. Innerhalb eines Subjektverhaltensdiagrammes (SBDs) gibt es daher nur X-OR Verzweigungen, auch weil ein einzelner Prozessor keine Aktion wirklich parallel ausführen kann. Eine solche parallele Ausführung (UND) wird, getriggert durch Nachrichten, im Verhalten von anderen Subjekten
dargestellt.
Ausführungskonzept Die Prozessmodellierungssprache PASS ist nicht nur intuitiv verständlich, sondern auch formal und besonders in einfachen Modellen auf entsprechenden
Workflow Engines automatisch ausführbar. Dies bietet einen großen Vorteil für ein mögliches Rapid Service Prototyping, da Änderungen am Dienstleistungsprozess relativ
schnell im Prozessmodell erledigt und theoretisch sofort in einen Dienstleistungsprototypen eingepflegt werden können.
Um dies zu ermöglichen, werden bei der Ausführung von PASS implizit zwei Konzepte
ergänzt.
Zum einen besitzt jedes Subjekt während der Ausführung eine sogenannte Inbox: eine
Art Briefkasten, in dem alle eingehenden Nachrichten erst einmal zwischengespeichert,
aber noch nicht empfangen werden.
Das zweite Konzept ist das des „Subject-Carriers“ oder Prozessors, dass die Trennung
zwischen eigentlichem Akteur und dem Konzept des Subjektes verständlich macht. Ein
Subjekt ist nur die Abstraktion eines Akteurs innerhalb des Rahmens einer konkreten Prozessinstanz. Um ausgeführt zu werden, muss ein Subjekt-Carrier die Kontrolle über ein
Subjekt „übernehmen“ und die Aufgaben bzw. Funktionen des Subjektes ausführen. Ein
Subjekt-Carrier kann dabei sowohl ein realer Mensch sein, der über ein „Graphical User
Interface“ (GUI) mit dem entsprechenden System arbeitet oder es kann auch ein technisches System sein, das ein Subjekt innerhalb einer Prozessinstanz automatisch steuert.
Subjekte und real Ausführende sind somit sauber getrennt. Ein einzelner SubjektCarrier kann so für mehrere Subjekte in unterschiedlichen Subjekt-Instanzen verantwortlich sein. Genauso gut können aber auch mehrere Carrier nacheinander für die Ausführung
eines einzelnen Subjektes sein. Dies wäre der Fall, wenn z. B. ein Sachbearbeiter im Urlaub ist und ein Kollege die Bearbeitung eines Einzelfall-Subjektes übernimmt.
So wird eine größtmögliche Flexibilität sowohl bei der Ausführung als auch bei der
Abstraktion von Modellen gewährleistet (vgl. Abb. 2.13).
Werkzeuge Um mit PASS zu modellieren, stehen unterschiedliche Werkzeuge zur
Verfügung. Eine ausführliche Beschreibung von möglichen Werkzeuge für die SubjektOrientierte Prozessmodellierung und Ausführung ist in (Fleischmann et al. 2017) zu finden.
Im Rahmen des dimenSion-Projektes wurde mit einem Werkzeugsatz gearbeitet, der es
erlaubt, innerhalb von Microsoft Office Visio subjektorientiert Prozesse mit PASS zu modellieren (vgl. Abb. 2.14).
78
A. R. Abdel Razek et al.
Subject Carrier / Processor A
Subject Carrier / Processor
(Real Person or System)
Subject Carrier Group C
Subject Carrier / Processor B
Subject
Instance in
Process B
Subject
Instance in
Process A
Subject
Instance
ox
Inb
ox
Inb
ox
Inb
Abb. 2.13 Ausführung von PASS mit Inbox und Subject-Carrier-Konzepten
Abb. 2.14 Screenshot des eingesetzten Modellierungswerkzeuges für die subjektorientierte Prozessmodellierung innerhalb von MS Visio
Eine freie Version davon kann aktuell heruntergeladen und ausprobiert werden unter:
https://subjective-me.jimdo.com/visio-modelling/
Das ursprüngliche Visio-Plug-in wurde auf Basis der im dimenSion-Forschungsprojekt
gewonnenen Erkenntnisse um mehrere Funktionen erweitert, die von Anwendungspartnern direkt benötigt wurden, oder sich auf Basis des Feedbacks als sinnvolle Ergänzung
herausgestellt haben.
Werkzeuge: Simple Simulation Das „Simple Simulation Werkzeug“ erlaubt eine einfache Berechnung und Abschätzung von Prozessdurchlaufzeiten. Ähnliche Funktionen bestanden bereits in Spezialwerkzeugen für die Prozessmodellierung, jedoch nur für klassische Beschreibungsmethoden, und nicht für subjektorientierte Werkzeugsätze.
2 Methoden
79
Falls es gewünscht und sinnvoll für die Dienstleistungsentwicklung ist, können mittels
Simple Simulation Prozessmodelle von Serviceprototypen mit Schätzungen oder Messungen von Durchlaufzeiten einzelner Tasks in Verhaltensdiagrammen, oder auch von Antwortzeiten, für Interface Subjekte annotiert werden (vgl. Abb. 2.15).
Auf dieser Basis kann das Werkzeug dann wiederum die zu erwartende Durchlaufzeit
für den entsprechenden prototypischen Dienstleistungsprozess berechnen. Dies wiederum
erlaubt es, den Prototyp entsprechend zu verbessern oder anhand dieses quantitativen
Feedbacks entsprechend Entscheidungen für die weitere Entwicklung des aktuellen Serviceprototyps zu fällen (vgl. Abb. 2.16).
Werkzeuge: Gant Chart Creator Eine der großen Stärken von PASS ist, dass das entsprechende Prozessmodell sowohl lineares als auch zyklisches/kontinuierliches Verhalten
Abb. 2.15 Eingabemöglichkeit für Zeitdauer
Abb. 2.16 Beispielhaftes Ergebnis des Simple Simulation Tools zu Abschätzung von Prozessdurchlaufzeiten
80
A. R. Abdel Razek et al.
abbilden kann. Beides ist sogar gepaart in einem Modell gleichzeitig möglich, da jedes
Subjekt einzeln beschrieben werden kann. Einer der häufigsten Feedback- bzw. Kritikpunkte an PASS ist, dass das SID keine temporalen Informationen enthält, sondern nur das
System beschreibt. Gewünscht wurde oft eine Übersicht über alle Aktivitäten gleichzeitig;
diese ist nur bedingt für einfache, lineare Prozesse möglich, kann jedoch auch mit PASS
dargestellt werden. Dementsprechend steht Nutzern ein Werkzeug zur Verfügung, mit dem
alle Verhaltensdiagramme eines Dienstleistungsprozesses automatisch auf eine einzelne
Visio-Seite kopiert werden und dort aneinander, auf Basis der entsprechenden Empfangsund Sendezustände, platziert werden (vgl. Abb. 2.17).
Diese parrallele Anordnung funktioniert jedoch nur dann sinnvoll, wenn es sich um lineares Verhalten handelt, da es nur hier Sinn ergibt, ihre Abfolgen aufeinander abzugleichen.
Ein solches „Gant-Chart“ eines Dienstleistungsprozesses kann so bereits als einfacher
Dienstleistungsprototyp genutzt werden, mit dem die entsprechenden Prozesse z. B. wie
auf einem Spielbrett mit kleinen Figuren durchgespielt werden können. Dies ist natürlich
auch mit einzelnen SBDs möglich, die einfach getrennt ausgedruckt oder gezeigt werden
müssten. Der Vorteil des Gant-Charts hier ist dessen Kompaktheit gegenüber möglichen
Einzelausrucken.
Werkzeuge: Office Export Tools Die klassischen IT Werkzeuge von Microsoft Office
spielen häufiger eine zentrale und wichtige Rolle in der Dienstleistungsentwicklung, als
dass sie es nicht tun. Für Berichte und Präsentationen werden häufig „MS Word“ oder
„MS PowerPoint“ als Werkzeuge verwendet, da hiermit sehr viele Menschen relativ gut
umgehen können. Um den Bruch zwischen den Werkzeugen möglichst leicht zu überwinden, wurden für das dimenSion-Projekt Plug-ins entwickelt, die per Knopfdruck aus einem Visio-Modell entsprechende Word- oder PowerPoint-Dokumente erzeugen, die dann
wiederum im Entwicklungsprozess der Dienstleistungund als Teil eines Prototyps verwendet werden können.
Werkzeuge: Export und Enactment in der Actorsphere Die prinzipielle Idee des Service Prototyping ist, einem möglichen Kunden oder Stakeholder früh ein Bild davon zu
geben, wie eine zukünftige Dienstleistung aussehen soll. Eine Möglichkeit hierfür ist eine
Ausführung des Prozessmodells auf einer Workflow Engine, bei der mehrere Stakeholder
gemeinsam Abläufe durchspielen und simulieren können. Die Actorsphere der Firma
„ActNConncet (http://actnconnect.de/actorsphere)“ stellt hierfür eine Möglichkeit dar.
Sollte ein Zugang zu diesem System bestehen, kann in MS Visio eine entsprechende Funk-
Abb. 2.17 Skizze einer automatisch generierten Gant Chart
2 Methoden
81
tion genutzt werden, um das Modell in einem entsprechend kompatiblen Format zu exportieren und prototypisch in der Actorsphere zu erproben.
Werkzeuge: OWL Export for Virtual Enactment Das Ausdrucken und Durchspielen
auf Papier und der Export in die Actorsphere sind zwei Möglichkeiten für die prototypische Erprobung von Dienstleistungsprozessen. Es war einer der Kernaspekte des
dimenSion-Projektes zu erproben, inwiefern unterschiedliche Beschreibungsarten ineinander integriert werden können. Kernwerkzeug dabei soll eine Service-Prototyping-Umgebung in der virtuellen Realität sein (vgl. Abschn. 2.5). Um die Prozessmodelle für eine
aktuell zu entwickelnde Dienstleistung verfügbar zu machen, musste ein Austauschformat geschaffen werden, das der möglichen Komplexität von subjektorientierten Service-Prototyp-Prozess-Modellen gerecht wird. Für den Austausch zwischen Prozessmodellierungstool und VR-Umgebung wurde daher ein Austauschkonzept auf Basis der
„Web Ontology Language“ (OWL) entwickelt. Die semantische Präzision dieses Werkzeuges ermöglicht es, erstellte Prozessmodelle vollständig zu übertragen. Da dieses Konzept gleichzeitig als Grundlage für einen möglichen weltweiten Austauschstandard
akzeptiert wurde, wird dieses es in absehbarer Zeit ermöglichen, die Funktion subjektorientierte Prozessmodelle nicht nur mit den hier vorgestellten Tools zu nutzen, sondern
eine größere Anzahl von Tools sowohl für die Modellierung als auch für das Erleben zu
nutzen (vgl. Abb. 2.18). Dies schließt die Entwicklung eigener Werkzeuge mit ein
(Fleischmann et al. 2017).
Process model X ont
toolX additional
semantics ont
loaded / imported loaded additonal concepts for reasoning
Execute Reaoning
Generic
Triple
Store
Tool Y
Query for known model
concepts
(Optional) Instruktions for
Model Manipulation
abstractlayeredpass ont
known/accepted concepts
Tool
Engine/
Tool
Parser
Reply
Abb. 2.18 Grundsätzliches Funktions- bzw. Nutzungsprinzip des OWL-Ontologie basierten Austauschformates
82
A. R. Abdel Razek et al.
Werkzeuge: Beispielprozess Innerhalb des dimenSion-Projektes wurde die subjektorientierte Prozessmodellierung vielfach erfolgreich für die Beschreibung von Dienstleistungsprototypen eingesetzt. Die Darstellung aller Modelle würde an dieser Stelle jedoch
über den Rahmen dieses Buches hinausgehen. Daher ist hier nur beispielhaft ein einzelner,
kleiner Prozess des Projektpartners „FALLER“ abgebildet. Es handelt sich um einfache
Überlegungen zum Ablauf bei der Verwendung einer Augmented Reality Applikation (vgl.
Abb. 2.19), wobei nicht die Technologie, sondern der Service Prozess um den Kunden und
die App herum im Fokus steht. Die Abläufe innerhalb des Unternehmens waren zu diesem
Zeitpunkt noch nicht relevant und wurden daher als Interface-Subjekte modelliert. Dies
sollte jedoch ein gutes Bild darüber vermitteln, wie subjektorientierte Prozessmodelle für
das Service Prototyping genutzt werden können (vgl. Abb. 2.20 und 2.21).
Werkzeuge: Subjektorientiertes Service Blueprinting Ein „Service Blueprint“ (englisch »Blaupause«) ist eine bestimmte Art der Prozessdarstellung einer Dienstleistung.
Das Erarbeiten und Aufzeichnen eines „Blueprint“ nennt man Blueprinting.
Ein Service Blueprint stellt alle Prozesse und Aktivitäten in der Serviceerbringung dar.
Er ist ein Dokument zur detaillierten Planung und Diagnose (der Dienstleistung) und zeigt
aus „Vogelperspektive“ alle „Moments of truth“ aus allen Blickwinkeln auf. Ziel ist es,
Dienstleistungen zu antizipieren, die für Kunden einen Wert haben und potenzielle Fehlerquellen zu identifizieren. Er bietet so die Chance, die Tangibilisierung von Leistungen zu
planen (Shostack 1984).
Abb. 2.19 Beispiel Subjekt-Interaktionsdiagram für mögliche Abläufe einer Dienstleistung rund
um eine AR-Applikation
2 Methoden
Abb. 2.20 Subjekt-Verhaltensdiagramm des Kunden-Subjektes aus dem SID der Abb. 2.18
83
84
A. R. Abdel Razek et al.
Abb. 2.21 Subjekt-Verhaltensdiagramm des App-Subjektes aus dem SID der Abb. 2.18
2 Methoden
85
In seiner Originalform ist das Blueprinting eine Darstellungsmethode der Dienstleistung in Form eines Ablaufdiagramms. Es ermöglicht eine detaillierte und transparente
Aufzeichnung der Arbeitsabläufe zur Erbringung der Dienstleistung. Wie bei jeder Prozessmodellierung kann die Darstellung so gestaltet werden, dass sie auch mögliche Fehler
und die wichtigsten Entscheidungssituationen beinhaltet. Darüber hinaus soll das entsprechende Prozessmodell aber auch zusätzlich durch objektive und qualifizierbare Aussagen
annotiert werden (z. B. über den zeitlichen Rahmen, Bewegungsstudien, mögliche Fehlerquellen etc.).
Ein wichtiges Charakteristikum des klassischen Service Blueprinting ist die Betrachtung einer Dienstleistung aus Kundensicht und die Überlegung, wie dieser eine Dienstleistung und bestimmte Dienstleistungsaspekte wahrnimmt (vgl. Abb. 2.22).
Für die Autoren der entsprechenden Literatur scheint die verwendete Modellierungsform dabei nebensächlich und meistens wird arbiträr ein Set an Symbolen definiert, mit
dem das auszudrücken ist, was für die Fragestellung der Dienstleistungsentwicklung relevant ist.
Meist wird dabei vollständig die Rolle des Kunden betrachtet und alle anderen Aspekte
und Abläufe nur insofern berücksichtigt, in dem diese in einem einfachen, zweidimensionalen, einem Flow-Chart ähnlichen Prozessmodell abgebildet werden können, ohne den
Kundenfokus zu verlieren.
Abb. 2.22 stellt ein Beispiel für einen klassischen Service-Blueprint nach limitierender
Input-Output-Logic mit Fokus auf den Kunden und der Trennung zwischen zwei Subjekten dar. Es geht um die Dienstleistung einer Fahrzeuginspektion während einer Flugreise.
Prinzipiell handelt es sich also beim Blueprinting um eine einfache primitive Form der
Subjektorientierung. Es lag daher nahe, die inhaltlichen Elemente des Blueprinting zu
Abb. 2.22 Beispiel für einen klassischen Service-Blueprint
86
A. R. Abdel Razek et al.
adaptieren und zu überprüfen, inwiefern Service Blueprinting mittels formellerer subjektorientierter Prozessmodellierung funktioniert.
In den Abb. 2.23 und 2.24 ist der Service Blueprint aus Abb. 2.22 als subjektorientiertes
Prozessmodell ausgeführt, wobei in dem Fall lediglich das SBD des Kunden skizziert wird.
Es ist offensichtlich, dass bereits das SID das geplante Dienstleistungssystem ausführlicher
abbildet, als es das einfache Flowchart des klassischen Blueprints vermag, obwohl keine
zusätzlichen Informationen hinzukommen, die implizit im klassischen Modell versteckt sind.
Darüber hinaus kann in den SBDs der Subjekte bei Bedarf die Dienstleistung viel genauer geplant werden, als es in einem einfachen einseitigen Service Blueprint der Fall wäre.
Ebenfalls offensichtlich ist, dass die Betrachtung der Kundenperspektive einer, wenn
nicht der zentrale, Bestandteil einer Dienstleistungsentwicklung mit oder ohne Prototyping sein sollte. Sie darf jedoch nicht die einzige Sichtweise bleiben und auch nicht das
Maß aller Dinge, da so sehr leicht wichtige Koordinationsaspekte als vermeintlich trivial
übersehen werden könnten, die für die Erbringung der gesamten Dienstleistung unabdinglich sind. Eine Dienstleistung, bei der das Zusammenspiel zwischen wichtigen Elementen
im Backoffice nicht ordentlich geplant und koordiniert wurde, wird mit höherer wahrscheinlich scheitern.
Abb. 2.23 Service-Blueprint SID für den gleichen Prozess wie in Abb. 2.22
2 Methoden
Abb. 2.24 SVD für Kunden im Service-Blueprint aus Abb. 2.22
87
88
A. R. Abdel Razek et al.
Mit vollständiger subjektorientierter Modellierung kann das Prinzip des Service Blueprinting bei der Dienstleistungsentwicklung uneingeschränkt auf alle Aspekte und Beteiligten einer Dienstleistung angewandt werden. Es ist damit dem klassischen Blueprinting
in allen Aspekten überlegen, insofern man gewillt ist, sich an eine vorgegebene Modellsyntax und Semantik zu halten.
2.5
Immersive Technologien im Service Prototyping
Abdul Rahman Abdel RazekMartin Raban, Alexander Hengels und Christian van Husen
Immersive Technologien haben zum Ziel, den Anwender umfassend in die virtuelle Anwendung einzubinden; äußere Einflüsse werden minimiert, das Sichtfeld maximiert. Die
Anwendung bildet meist eine realistische Szene ab, die den Nutzer involviert, damit er
dazu verleitet wird, sich darauf vollkommen einzulassen. Dazu gehören auch eine stereoskopische Darstellung sowie die Erfassung des Nutzers, insbesondere seine Kopfposition
und die Lage der Hände, die eine Intuitive Handhabung der Anwendung ermöglichen.
Das Ziel dieser aufwendig zu betreibenden Systeme ist zweiseitig; einmal erhofft man
sich Nutzergruppen, denen es an Affinität oder Knowhow mangelt, zu erreichen und zu
befähigen, mit professionellen Softwarewerkzeugen zu arbeiten und diese somit in Planungs- und Virtualisierungsprozesse einzubinden; zweitens sollen immersive Systeme die
komplexe Interaktion in einer 3D Umgebung stark unterstützen und vereinfachen, und
somit ein wesentlich effizienteres Arbeiten ermöglichen. Ein weiterer Vorteil immersiver
Systeme ist der Einsatz als Kommunikationsplattform, um kollaboratives Arbeiten in
Echtzeit zu ermöglichen. Dies ist besonders interessant für das Projektvorhaben, da das
Wissen für einen Service Prototyp, Prozesse, Richtlinien, Ressourcen etc. in den Köpfen
verschiedener Menschen steckt. Hier können immersive Systeme helfen, die Personen zusammen zu bringen und interaktiv den Service Prototyp zu erstellen.
Der Einsatz immersiver Systeme stellt eine große Frage in den Raum, mit der man sich
intensiv auseinandersetzen muss; und zwar die Erstellung der Inhalte für diese Systeme.
Klassische digitale Ressourcen wie Text, Bilder und Pläne sind unzureichend, da sie die
räumliche Dimension nicht ausreizen können. Zum Beispiel wird im Maschinenbau mittlerweile teilweise flächendeckend am Computer in 3D konstruiert. Dies ist eine gute
Voraussetzung, um automatisiert 3D Inhalte für VR Systeme zu erstellen, jedoch gestaltet
sich auch das in diesem Fall kompliziert, da gute Schnittstellen fehlen, um Daten zwischen
Systemen zu übertragen. Außerdem sind Unternehmen derzeit in der Regel wenig dazu
bereit, VR Knowhow aufzubauen; somit brauchen sie vollständig automatisierte Systeme
und Workflows.
Das Ziel des Projektvorhabens „dimenSion“ ist somit, den Einsatz immersiver Systeme
für Service Prototyping zu erforschen. Neben den Möglichkeiten zur effizienten Erfassung
von Prozessen und Virtualisierung von Service Ressourcen, geht es auch darum, den Service Prototyp zu validieren, indem man ihn virtuell durchleben kann. Auch hier können
2 Methoden
89
wieder alle involvierten Parteien gemeinsam das Ergebnis evaluieren, und kollaborativ
und iterativ zusammen bearbeiten.
Im Abschn. 2.5.1 werden verschiedene immersive Systeme vorgestellt, die im Rahmen
des Projektvorhabens zusammengestellt und analysiert worden sind.
2.5.1
Anwendungsfälle für Immersions-Service-Prototypen
Tab. 2.8 zeigt Anwendungsbeispiele immersiver Service Prototypen, die während der Literaturrecherche und aus eigenen Anwendungen konsolidiert wurden. Was während der
Literaturrecherche auffiel, ist, dass es an Wissen über den Einsatz immersiver Technologien im Service Prototyping mangelt und eine Literaturlücke in diesen Bereichen existiert.
Darüber hinaus werden die meisten der gefundenen Anwendungsfälle nicht empirisch
untersucht, sondern hängen von weichen Parametern wie der Nutzererfahrung oder dem
Tab. 2.8 Immersive Service Prototyping Use Cases
Service Art
Automobil
Self-SalesService
ISP Art
Virtual
Reality
Branche
Automotive
Einzelhalndel
Use Case
Land Ref.
KP Oh et al.
Simulation der
(2013)
Kundenaktivitäten in einer
3D-Service-VRUmgebung
Servicescape
Einzelhandel
VR-Simulation der
KP Jung Bae
Simulation
Customer eXperience
und Seong
Leem
(2014)
Beratung
Health-Care
VR-Bildgebung mittels
TW Peng et al.
mobilem Endgerät
(2017)
DE Exner et al.
Fertigungsindustrie Implementierung von
PSS
(2014)
immersiven 3D-PSSLebenszykElementen in einer
lustests
virtuellen Umgebung
DE Projekt
Fertigungsindustrie Verwendung eines
Service
dimenSion
VR-Tischmonitors zur
ProzessmoErgebnisse
virtuellen
dellierung
Prozessmodellierung
SE
Arvola et al.
Service
Augmented Service Design
Verwendung von
(2012)
Walkthrough Reality
Requisiten und mobilem
AR für einen Service
Walkthrough
App
Modellbau
Verwendung von mobilen DE Projekt
dimenSion
Konfigurator
Endgeräten zur Fällung
Ergebnisse
von
Produktentscheidungen
Marketing &
Automotive
Verwendung einer mobilen DE Projekt
dimenSion
Vertrieb
Einzelhandel
App zur Visualisierung
Ergebnisse
eines Oldtimers in AR
mittels Marker
90
Service Art
ISP Art
Technischens Mixed
Training
Reality
Service
Optimierung
A. R. Abdel Razek et al.
Branche
Use Case
Fertigungsindustrie Technische
Trainingsszenarien in
einem Mixed-RealitySimulator
Gastgewerbe
Verhaltensvisualisierung
der Stakeholder am
Point-of-Sale mit realen
physikalischen Sensoren
Land Ref.
DE Projekt
dimenSion
Ergebnisse
JP
Fukuhara
et al.
(2014)
(Abdel Razek et al. 2018a, S. 5)
menschlichen Verhalten ab. Das Ziel ist, das Wissen über das Prototyping von Services zu
erweitern, insbesondere über Service Prototyping-Anwendungen für immersive Technologien und deren Auswirkungen. Ausgewählte Use Cases, die während der Literaturrecherche von Abdel Razek (2018a) identifiziert wurden, sind in Tab. 2.8 mit „Service Art“,
„Immersive Service Prototyping Art“ (ISP-Art), „Branche“, „Use Case“ und „Land“ aufgeführt.
Als Schlussfolgerungen, nach Beobachtung dieser Use Cases, entstanden folgende Bemerkungen:
1. Alle Fälle hatten keine empirischen Daten
2. Koreanische und japanische Forscher sind Pioniere bei der Verwendung immersiver
Technologien für das Service Prototyping gewesen;
3. Das Interesse an der Nutzung immersiver Technologien im Service Prototyping steigt
seit 2014; dies ist auf die verstärkten Digitalisierungsvorhaben der EU als Ganzes und
des „Bundesministeriums für Bildung und Forschung“ in Deutschland zurückzuführen
4. Immersives Service Prototyping wurde verwendet, um menschliches Verhalten durch
Avatare, Nutzererfahrung und Serviceumgebung zu visualisieren
5. Das Prototyping von Dienstleistungen wurde durchgeführt, um Prozesse zu optimieren, das Service-Design zu verbessern, Mitarbeiter zu schulen und Simulationen zur
Unterstützung des Vertriebs zu erstellen.
6. Immersives Service Prototyping wurde in stakeholderorientierten Dienstleistungsszenarien mit komplexen Interaktionen verwendet
7. Immersives Service Prototyping wird in verschiedenen Branchen wie Fertigung,
Gesundheitswesen, Automobil, Gastgewerbe und Vertrieb eingesetzt.
Wir betrachten das „Immersive Service Prototyping“ (ISP) als einen Prozess, der eine
reale oder fiktive Service-Idee bereits vor der Dienstleistung aufgreift, damit ServiceStakeholder die Service-Erfahrung mit einer immersiven Service Prototyping Erfahrung
für Exploration, Kommunikation und Evaluierung antizipieren können. ISP kann in Form
eines VR-Simulationstrainings oder eines AR-Anweisungsführers oder eines MR-Hologramms zur Entscheidungsfindung gestaltet werden.
2 Methoden
91
Immersive Service Prototyping-Techniken können in drei SP-Techniken kategorisiert werden:
1. Virtual Reality Service Prototyping (VRSP) ist ein Prozess, der eine reale oder fiktive
Service-Idee verwendet, um Stakeholder-Erfahrungen zu ermöglichen, zu erkunden, zu
kommunizieren, und in einer virtuellen Szenariosimulation zu bewerten.
2. Augmented Reality Service Prototyping (ARSP) ist ein Prozess, der eine reale oder
fiktive Service-Idee verwendet, um Stakeholdern zu ermöglichen, diese mit überlagerten virtuellen Objekten und Informationen in einer realen Umgebung zu erkunden, zu
kommunizieren und zu bewerten.
3. Mixed Reality Service Prototyping (MRSP) ist ein Prozess, der eine reale oder fiktive
Service-Idee verwendet, um Stakeholdern zu ermöglichen, diese durch Interaktion mit
virtuellen Objekten und Informationen in einer realen Umgebung zu erkunden, zu
kommunizieren und zu bewerten.
Abb. 2.25 stellt Immersive Service Prototypes stichwortartig vor und ist Marker des
entsprechenden Videos, welches per SN More Media App angesehen werden kann.
In Tab. 2.9 werden die Ergebnisse der Stärken- und Schwächenanalyse für konventionelles und Immersives Service Prototyping vorgestellt. Um das Potenzial des immersiven
ServicePrototypings zu erkennen, sollte verstanden werden, welche Vorteile realisiert können, aber auch welche möglichen Nachteile berücksichtigt werden müssen;
Nach Abdel Razek et al. (2018a, S. 5 ff.) wurden für die Bewertung der „SP-User eXperience“ konsolidierte Ergebnisse aus Workshops, Einzel- und Fokusgruppeninterviews
analysiert und in der durchgeführten qualitativen Forschung, basierend auf den Teilnehmererfahrungen nach gegenseitigem Austausch ihrer Meinungen und Emotionen, zusammengestellt. In den Feedback-Sitzungen tauschten sich ca. 30 Teilnehmer bezüglich ihrer
eigenen SP-eXperiences und über SP-Tools aus. Die wahrgenommene eXperience-Bewer-
With ISP you can
experience a service
even before it exists!
Immersive
Service
Prototype
1
2
ISP advantages:
Providing
better testing
usability
scenarios
Receiving
stakeholders
feedback as if in
real-life situations
So you can e more realistic,
flexible and accurate
service experience!
But it has
disadvantages:
Creating a more
realistic immersive
stakeholder
experience
4
High
technological
investment
needed
Could be lagging
due to insufficient
processing power
3
Examples of
ISP
Consequences in the
immersive environment
might not be the same
as in the real world
› Virtual Reality SP
› Augmented Reality SP
› Mixed Reality SP
5
Abb. 2.25 Video-Marker: Immersive Service Prototype (https://doi.org/10.1007/000-010)
6
92
A. R. Abdel Razek et al.
Tab. 2.9 Immersives Service Prototyping: Stärken und Schwächen
Stärken
Feedback-Generierung zu neuen Ideen und die Möglichkeit, die Reaktion
der Stakeholder in realen Situationen zu untersuchen
Bewertung des Service-Designs und Feedback-Generierung, wie die
Dienstleistungsimplementierung und -bereitstellung verbessert werden
kann
Erhöhte Dienstleistungsaktivität in der realen Welt durch Interaktion
Quellen
(Kim et al. 2008,
S. 110)
(Kim et al. 2008,
S. 110)
(Kim et al. 2008,
S. 110)
Präzise Darstellung der zeitlichen und räumlichen
(Pallot et al. 2013,
Dienstleistungskomponenten
S. 15)
Realisierung eines besseren Usability-Test-Szenarios mittels 3D-Objekten, (Pallot et al. 2013,
-Entwürfe und -Räume
S. 15)
Ermöglichung einer schnellen, kostengünstigen und flexiblen Bewertung
(Pallot et al. 2013,
S. 15)
eines Designs
Schaffung einer realistischeren immersiven Experience für Stakeholder
(Miettinen et al.
2012, S. 1202)
Erschafft Mehrwert in verschiedenen Service Design Phasen zur
(Miettinen et al.
2012, S. 1202)
Ermittlung von Kundeninformationen.
Die Qualität des Service Prototyp-User Interfaces ist möglicherweise höher (Marcus 1997,
S. 423)
Schwächen
Quellen
Stakeholder könnten dazu tendieren, eher zu grafischen Details als zur
(Sefelin et al. 2003,
Interaktion Stellung zu nehmen
S. 778)
Simulationen erfodern möglicherweise eine sehr spezifische Anleitung, um (Moritz 2005)
erfolgreich zu interagieren
Vorbestimmte Aktionen der Simulation können der inkonsistenten Natur
(Blomkvist und
der Dienstleistung widersprechen
Holmlid 2012, S. 1)
Hohe Investitionskosten für Technologien zur Realisierung komplexer
dimenSion
Visualisierung
Ergebnisse
Hoch immersive Simulationen können durch nicht ausreichende
dimenSion
Rechenleistung des Computers verzögert oder langsam sein
Ergebnisse
Immersives Design setzt hohes Knowhow voraus
dimenSion
Ergebnisse
Manche Stakeholder könnten VR als Gimmick bzw. Spielerei empfinden
dimenSion
Ergebnisse
(Abdel Razek et al. 2018a, S. 6)
tung hing von verbalen Teilnehmer-Feedbacks, Diskussionen, Kommentaren, Anwendungen und Anpassungen ab. Um aus den Einzel- und Fokusgruppeninterviews möglichst
viele Kernaussagen realistisch und neutral herauszukristallisieren, wurden Design Thinking Tools (d. h. „Design Thinking Empathy Rating Methode“, angepasst an die „Empahty Map“) zur Datenerfassung und -analyse genutzt.
Abb. 2.26, 2.27, 2.28 und 2.29 beschreiben die in Tab. 2.10, 2.11, 2.12 und 2.13 aufgeführten „Conventional Service Prototypes“ (CSP) und sind Marker entsprechender Videos, in denen die CSPs mit Vor- und Nachteilen erklärt werden.
2 Methoden
93
With VSP you can
explain your idea
with words oraly!
Verbal Service
Prototype
1
2
VSP has
advantages:
Enhanced
sense of
efficacy
So you can have a
rapid, simple and
affordable SP
But it has
disadvantages:
Allowing testing and
evaluating from
turning hypothesis
into explicit
Easily capture
the whole
service idea
Lack of
presence due to
lack of
visualization
Limited
service
Prototyping
applications
3
Examples of
VSP
› Brainstorming
› Story telling
› Cognitive Walkthrough
Only in the
first key
development
aspect
4
5
6
Abb. 2.26 Video-Marker: Verbal Service Prototype (https://doi.org/10.1007/000-00y)
With PSP you can
experience a service
idea by using paper,
drawings and pictures!
Paper Service
Prototype
1
2
But it has
disadvantages:
PSP has also:
a long
shelf-live
SP flexibility in
early key
development
aspects
So you can have a
easily altered, reliable
and low tech SP
can prototype
anything even
if it cannot be
built
does not adhere
to any physical
or scientific
constraints
lacking user
interface
3
Examples of
PSP
› Storyboard
› Evidencing
› Sketching
feeling of being
observed might
change the
outcome prototype
4
5
6
Abb. 2.27 Video-Marker: Paper Service Prototype (https://doi.org/10.1007/000-012)
With MSP you can
experience a service
idea by using physical or
digital mock-ups!
Mock-Up
Service
Prototype
1
2
MSP advantages:
Paper MSP
can be shown
to larger
groups
Digital MSP
allows
stakeholders to
interact with it
So you can intangibles
into tangibles for
better service
understanding!
But it has
disadvantages:
Can aid the
service
documentation
process
4
Needs
contextual
information
Can be easily
broken or
damaged
3
Examples of
MSP
Perfect mock-ups
can mistaken for
final solutions
› Physical Mock-Up
› Digital Mock-Up
› Lego Serious Play
5
Abb. 2.28 Video-Marker: Mock-up Service Prototype (https://doi.org/10.1007/000-013)
6
94
A. R. Abdel Razek et al.
With SSP you can use
simulations of a real or
imaginary service idea
before it even exists!
Simulation
Service
Prototype
1
2
But it has also
disadvantages:
SSP advantages:
Enabling
testing of all
service
interactions
Simulating all
service
scenarios
So you can have a
better understanding
of the service
through simulation
Allowing
replication of
service
experience
Stakeholders
comment more
on visual details
than on
interactions
Needs very
specific
guidance to be
used
successfully
3
Examples of
SSP
Predetermined
actions contradicts
with the
inconsistent nature
of services
4
› Physical Simulation
› Digital Simulation
› Verbal Simulation
5
6
Abb. 2.29 Video-Marker: Simulation Service Prototype (https://doi.org/10.1007/000-014)
Tab. 2.10 Evaluation der wahrgenommenen SP-User eXperience
SP Art
Aktivitäten
Experimentieren
Lernen
Testen
Demonstrieren
Kommunizieren
Informieren
Integrieren
Planen
CSP
VSP
*
*
*
*
*
*
*
*
PSP
**
**
*
**
**
*
*
*
MSP
**
**
*
**
**
*
*
**
SSP
*
**
***
**
**
**
**
**
ISP
VR SP
***
***
***
***
**
***
**
***
AR SP
***
***
**
***
***
***
***
***
MR SP
***
***
**
***
***
***
***
**
(VSP: Verbal SP; PSP: Paper SP; MSP: Mock-Up SP; SSP: Simulation SP; VR SP: Virtual Reality
SP; AR SP: Augmented Reality SP; MR SP: Mixed Reality SP)
Legende: * = niedrige UX, ** = mittlere UX, *** = hohe UX
(Abdel Razek et al. 2018a, S. 7)
Tab. 2.10 zeigt die Bewertung der verschiedenen SP-Techniken hinsichtlich der
SP-Aktivitäten
Nach iterativer Verdichtung und Verbesserung der Service Prototyping Toolbox hinsichtlich der SP-Arten (vgl. Tab. 2.1) wurden die Teilnehmer bezüglich ihrer User eXperience (Anwendbarkeit, Kosten) befragt (Abdel Razek et al. 2018a, S. 7).
Die Teilnehmer bewerteten die „Verbal SPs“ aufgrund der fehlenden Visualisierungsmöglichkeit als niedrig, fügten jedoch ihren Bemerkungen hinzu, dass diese sich gut zur
schnellen Realisierung einer Idee eignen würden. Die „Paper SPs“ wurden besser als
„Verbal SPs“ bewertet, da diese die kostengkünstigste, zugänglichste und vielseitigste Option seien, um simple Service Ideen zu explorieren, zu kommunizieren und zu demonstrieren. „Mock-up SPs“ wurden ähnlich wie die „Paper SPs“ bewertet; aufgrund der Möglich-
2 Methoden
95
Tab. 2.11 Service Prototyping-Arten und -Techniken
SP Art
Techniken
Personas
Role Play
Storytelling
Storyboard
Cognitive Walkthrough
Virtual Simulation
Video Prototyping
Design Fiction
Experience Prototype
Rapid SP
CSP
VSP
X
X
X
PSP
X
MSP
X
X
X
X
X
SSP
X
X
X
X
ISP
VR SP
X
X
X
X
X
AR SP
X
X
X
X
X
MR SP
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
(VSP: Verbal SP; PSP: Paper SP; MSP: Mock-Up SP; SSP: Simulation SP; VR SP: Virtual Reality
SP; AR SP: Augmented Reality SP; MR SP: Mixed Reality SP)
(Abdel Razek et al. 2018a, S. 8)
Tab. 2.12 Service Prototyping-Arten und Attribute
SP Art
Attribute
Fidelity
Resolution
Effort
Interaktivität
User eXperience
Kommunikation
Feedback
Visualisierung
Simulation
Nutzung
CSP
VSP
1
1
1
1
1
2
3
1
2
3
PSP
2
2
2
2
2
3
2
2
2
4
MSP
3
3
3
3
3
3
3
3
2
4
SSP
4
4
4
4
4
4
2
4
4
3
ISP
VR SP
4
5
5
5
5
5
4
5
5
4
AR SP
5
4
4
4
5
5
5
5
4
3
MR SP
5
4
5
5
5
5
5
5
4
5
(VSP: Verbal SP; PSP: Paper SP; MSP: Mock-Up SP; SSP: Simulation SP; VR SP: Virtual Reality
SP; AR SP: Augmented Reality SP; MR SP: Mixed Reality SP)
Legende: 1 = sehr niedrig, 2 = niedrig, 3 = mittelmäßig, 4 = hoch, 5 = sehr hoch
In Anlehnung an (Abdel Razek et al. 2018a, S. 8)
keit physische oder digitale Artefakte darzustellen, wurde die Planbarkeit als besser
wahrgenommen. Über alle Aktivitäten des Service Prototypings hinweg wurden
„Immersive SPs“ als sehr hoch bewertet, da diese einen hohen Grad an Visualisierung,
Interaktion und Simulation erlauben. Tab. 2.11 aus den Einzel- und Fokusgruppeninterviews entstanden. Das „X“ gibt an, ob die SP-Techniken für einen oder mehrere der fünf
Service Prototyping-Arten anwendbar sind. „Personas“ ist eine SP-Technik, die auf fiktiven Charakteren basiert, deren Profile eine Stakeholder-Gruppe darstellen, um ihre Bedürfnisse, Wünsche, Eigenschaften und Verhaltensweisen zu antizipieren und die spätere
Service Journey zu simulieren (Arvola et al. 2012, S. 21–29). Das „Storytelling“ unter-
96
A. R. Abdel Razek et al.
Tab. 2.13 Vergleich zwischen konventionellen und immersiven Service Prototyping Attributen
Attribute
Fidelity
CSP
VSP: Offen für jede
Interpretation
PSP: Eingeschränkte Details,
keine Funktionalität
MSP: Hohe physische
Fidelity
SSP: Hohe prozessuale
Fidelity
Resolution
VSP: Mündliche Wiedergabe
PSP: Darstellung mittels
Papier
MSP: Materielle Darstellung
SSP: Prozessdarstellung
Effort
VSP: Niedrig
PSP: Niedrig
MSP: Mittelmäßig
SSP: Hoch
Nutzung
VSP: Einmal
PSP: Mehrfach
MSP: Einmal pro Prototyp
SSP: Iterativ
User
VSP: Kongnitiv
eXperience
PSP: Visuell
MSP: Physisch
SSP: Prädestiniert
Visualisierung VSP: Mental
PSP: Mental
MSP: Physisch
SSP: Komplex
Simulation
VSP: Mündliche
Interaktionen
PSP: Stationäre
Interaktionen
MSP: Physische
Interaktionen
SSP: Prädestinierte
Interaktionen
Dokumentation VSP: Keine
PSP: Analog
MSP: Analog/digital
SSP: Analog/digital
ISP
Die Fidelity variiert je nach Art der Immersion
Je nach definierter Resolution lässt sich das
ganze Spektrum an immersiven
3D-Darstellungen realisieren
Hohe Initialinvestitionen und hoher Effort für
komplexe Immersion
komplexe Anwendungen bedingen hohe
technologische Investitionen und hohes
Knowhow
Hohes Immersionslevel und verbesserte User
eXperience
Abhängig vom Endgerät sind komplexe
immersive Visualisierungen möglich
Immersive digitale 3D-Interaktionen hängen
vom Simulationsprozess ab
Digitale Dokumentation mit Überlagerung,
Implementierung und Sequenzierung von
Informationen
(Fortsetzung)
2 Methoden
97
Tab. 2.13 (Fortsetzung)
Attribute
CSP
Kommunikation VSP: Verbale Informationen
PSP: Analoge Informationen
MSP: Physische
Informationen
SSP: Zusammengefasste
Informationen
ISP
Digitale immersive, benutzerzentrierte
Informationen, die von den Eingabe- und
Ausgabegeräten abhängen
(VSP: Verbal SP; PSP: Paper SP; MSP: Mock-Up SP; SSP: Simulation SP
(Abdel Razek et al. 2018a, S. 8 f.)
stützt die Erforschung von Serviceideen mit einfachen Worten oder komplexen Erzählungen, um die Service-Idee als begreifbare Geschichte darzustellen (Goodwin 2011).
Storyboard ist eine SP-Technik, die die Service-Idee durch eine logische Folge von Bildern oder Zeichnungssequenzen darstellt (Quesenbery und Brooks 2010).
Mithilfe von „Cognitive Walkthrough“ können Service-Designer eine Serviceidee gedanklich oder „beim Eintauchen“ (engl. „to immerse“; i. S. d. ISP) untersuchen, indem sie
die Service-Phasen der Stakeholder durchlaufen (Polson et al. 1992, S. 741–773). Die virtuelle Simulation ist eine Computersimulation einer Serviceidee oder -umgebung, die
visualisiert, analysiert und bewertet werden kann (Wang 2002, S. 232–236). Beim „Video-Prototyping“ werden Video und Ton kombiniert, um ein visuell reichhaltiges Multimediasystem für die Entwicklung einer Dienstleistung und die Unterstützung von Interessengruppen zu erstellen (Mackay 1988). „Design Fiction“ ist ein SP-Ansatz, um über die
Auswirkungen neuer Serviceideen spekulieren zu können (Pasman 2016, S. 511–515).
Der „Experience-Prototyp“ ist eine Service-Experience-Simulation, bei der der Kontaktpunkt bestimmter Stakeholder verwendet wird, um die Performanz einer Dienstleistung
besser zu prognostizieren Buchenau und Fulton Suri 2000, S. 424–433). „Rapid Service
Prototyping“ ist ein Service-Entwicklungsprozess, bei dem eine Reihe von Service Prototypen verwendet werden, um sich dem endgültigen Service-Design durch Iterationen und
Verfeinerungen kontinuierlich zu nähern (Abdel Razek et al. 2017).
In Tab. 2.12 sind Rückmeldungen aller Teilnehmer zu den verschiedenen Service
Prototyping-Arten und Service Prototyping-Attributen dargestellt. Das Rating gibt den
Konsens der Fokusgruppen wieder. Die Tabelle wurde basierend auf den digital geprägten
Service Use Cases im Rahmen des Forschungsprojektes erstellt. Sie ist jedoch nicht allgemeingültig zu interpretieren; sie stellt die fallspezifisch untersuchten, digital ausgerichteten Dienstleistungen dar. Aus diesem Grund erhielt der ISP eine höhere Bewertung als
der CSP (siehe Tab. 2.12). Diese Bewertung hing von Feedback, Erfahrung und Anmerkungen zur Anwendung und Implementierung der 10 am häufigsten verwendeten Service
Prototyping-Tools ab.
In Tab. 2.13 werden Bemerkungen zur Literatur bezüglich konventionellem und immersivem Service Prototyping basierend auf den in Tab. 2.8, 2.9, 2.10, 2.11 und 2.12 dargestellten Ergebnissen zusammengefasst. Die „Key Attributes“ (Schlüsselattribute), die in
98
A. R. Abdel Razek et al.
Abb. 2.9 (vgl. Abschnitt) im Service Prototyping Modell skizziert sind, sind „Resolution“
(Ähnlichkeitsgrad), „Effort“ (Erstellungsaufwand) und „Fidelity“ (Detaillierungsgrad);
sie stellen einen vollständigen Maßstab eines Service Prototyps dar.
2.5.2
Service Prototyping Forschungsrahmen
Ein Forschungsrahmen wurde entwickelt, um den SP-Prozess und seine Konstrukte darzustellen. Zusätzlich zu diesem wurde ein Forschungsmodell erstellt. Dieses vorgeschlagene
Forschungsmodell wurde durch mehrere Experimente validiert (vgl. Abb. 2.30, Abdel Razek et al. 2018b).
ISPX kann zu einer ganzheitlicheren und umfassenderen Darstellung der SX; in Fällen
führen, in denen der Schwerpunkt auf Darstellung, Visualisierung und Simulation liegt.
Immersives Lernen und Engagement ist den konventionellen Methoden überlegen (Dede
2009, S. 66–69). Eine Kombination aus „Conventional Service Prototyping eXperience“
(CSPX) und „Immersive Service Prototpying eXperience“ (ISPX) könnte die optimale
Lösung für die umfassendste Darstellung der „Service eXperience“ (SX) sein; je nach anvisiertem Komplexitätsgrad der finalen Dienstleistung. Man kann davon ausgehen, dass
die Summierung von SPX, konventionell und immersiv, zur umfassendsten Darstellung
eines Service-Erlebnisses führt.
Dies wird in dieser Formel dargestellt:
¥
å ( SPX1 + SPX 2 +¼+ SPXn ) = SPX ,
n =1
¥
Optimal å ( SPX ) @ SX
n=1
Abb. 2.30 Service Prototyping Forschungsrahmen (Abdel Razek et al. 2018b)
2 Methoden
99
Service Prototyping ist ein co-kreativer Prozess, der dabei hilft, Design-, Anforderungsund Implementierungsprobleme zu lösen, die bei der Replikation und Repräsentation der SX
auftreten können. Aus diesem Grund ist es wichtig, CX, UX und SX in diesem co-kreativen
Service-Entwicklungsprozess zu verstehen. Es könnte einige Einschränkungen bei der Verknüpfung von CX, UX und SX in einer instanziierenden Interdependenzbeziehung geben,
aber dies wird in zukünftigen Experimenten verifiziert werden (Dede 2009, S. 66–69).
Wie in Abb. 2.31 dargestellt, beginnt der experimentelle Triangulationsansatz mit der
Auswahl des SP-Typs, der in dem verwendeten Prototyp dargestellt ist. Der zweite Schritt
ist das Durchführen des Experiments, das wiederum eine Nutzeraktion und Interaktion
erzeugt. Diese Aktion führt zu einer Nutzererfahrung, die zu Nutzerfeedback durch den
Fragebogen führt und während des Experimentierens Beobachtungen generiert. Das Feedback wird in Form eines quantitativen und qualitativen eingebetteten bipolaren Fragebogens mit Begründungen erhoben. Die Beobachtungen, die sich aus dem Verhalten des
Teilnehmers während des Experiments ergeben, werden mit den qualitativen und quantitativen Daten des Fragebogens in einem Triangulationsansatz verwendet.
Ziel ist es, nach einer quantitativen Validierung des Modells und des Instruments diese
in einem industriellen Umfeld anzuwenden. In diesem industriellen Umfeld werden
Service-Stakeholder damit beschäftigt sein, gemeinsam eine Service-Idee zu erkunden,
ein Service-Konzept zu kommunizieren und schließlich ein Service-Design zu evaluieren.
2.5.3
Service Prototyping Forschungsmodell
Das SP-Forschungsmodell ist eine Erweiterung basierend auf dem „Immersive eXperienceModell“ von Pallot et al. (2017). Dieses Modell wurde nach Überprüfung der Literatur
Abb. 2.31 Customer eXperience-Struktur eines Produkt-Service-Systems (Abdel Razek et al. 2018b)
100
A. R. Abdel Razek et al.
entwickelt und erweitert. Das SP-Forschungsmodell umfasst die Erstellung eines SPX,
seiner Faktoren und seiner Kausalitäten. Immersive Erfahrung wird Nutzer dazu bringen,
zu reagieren, und durch ihre Reaktionen, Rückmeldungen und die gemachten Beobachtungen werden die Kausalitätseffekte festgestellt. Immersive eXperience kann als perzeptuelle, emotionale und kognitive Immersion beschrieben werden. Es gibt keine soziale
Immersion in diesem Stadium, da das Experiment individuell durchgeführt wird (Abdel
Razek et al. 2018b).
Die „perzeptuelle Immersion“ (PI) wird anhand der Intuitivität, Interaktivität und Benutzerfreundlichkeit des Prototyps gemessen. Sie stellt beispielhaft das Engagement der
Nutzer und des Nutzerverhaltens dar sowie die Adaption des Prototyps.
Die „emotionale Immersion“ (EI) wird basierend auf dem Grad der Attraktivität des
Prototyps für den Nutzer bewertet, der von mehreren Faktoren abhängt: dem wahrgenommenen Annehmlichkeitsniveau des Prototyps für den Nutzer und dem Grad der emotionalen Nutzerbeteiligung mit dem Prototyp.
Die „kognitive Immersion“ (CI) wird auf der Ebene des Interesses am Prototyp, der
vom Nutzer wahrgenommenen Nützlichkeit des Prototyps und der kognitiven Interaktion
des Nutzers mit dem Prototyp bewertet.
Die „Immersive eXperience“ wird dann aus perzeptueller, emotionaler und kognitiver
Immersionserfahrung zusammengefasst. Die Kausalitätseffekte werden durch verschiedene
Faktoren gemessen. Gelegentlich können durch die Immersion Effekte entstehen, indem
sich das wahrgenommene Zeitgefühl der Nutzer verändert hat; der Nutzer sich seiner Umgebung bewusst ist; und auf externe Faktoren oder Ereignisse reagieren kann. Die kausalen
Auswirkungen auf den Service Prototyping-Entwicklungsprozess durch das Erlebnis eines
Dienstleistungsnutzers sind wahrzunehmen. Der Nutzer lernt durch die Prototyp-Exploration, wie einerseits der Prototyp mit dem Nutzer kommunizieren kann, und andererseits wird
aus den Usability-Auswertungen des Prototyps eine bessere Entscheidungsgrundlage entwickelt, um weitere Entwicklungsmaßnahmen zu treffen (Abdel Razek et al. 2018b).
2.6
Hardware und 3D-Rekonstruktion
Victor Häfner, Polina Häfner und Matthes Elstermann
Im Rahmen des Projektvorhabens wurden verschiedene Immersive Systeme ausprobiert.
Zum Beispiel die hoch-immersive CAVE-Umgebung, die es erlaubt vollständig in die virtuelle Szene einzutauchen. Da mehrere Nutzer gleichzeitig mit der CAVE interagieren
können, ist sie eine gute Kollaborationsumgebung. Jedoch ist sie auch das kostenintensivste System und ermöglicht es in der Regel nur einer Person, mit der Szene zu interagieren. Dies ist sehr gut für Validierungszwecke geeignet, jedoch nicht als Arbeitsumgebung
um Inhalte zu editieren.
Eines der Ziele des Projektes war eine sogenannte „Holobench“ zu entwickeln, um
Service Prototyping mit einer immersiven Umgebung zu unterstützen. Eine Holobench ist
2 Methoden
101
eine horizontale interaktive Displayfläche für VR Anwendungen. Es wurde ein neues Konzept für eine Holobench entwickelt und umgesetzt, bei der der Fokus auf einer kollaborativen Umgebung liegt, unterstützt durch neuartige Interaktionsgeräte wie die Leap Motion
und Microsoft Kinect, um die Interaktion mit dem Datenmodell des Service-Prototyps zu
erleichtern.
Die Holobench besteht aus einem 3D-fähigen Fernseher, der auf einem Tischgestell
montiert und mit einem Multitouch-Rahmen versehen ist. Dadurch kann per Touch-Eingabe
mit der virtuellen Szene interagiert werden. Zudem sind um den Tisch Leap Motion Geräte
angebracht, die die Konfiguration der Hände der Nutzer erfassen können; somit erweitert
sich der Interaktionsbereich über die Touch-Fläche hinaus, auch auf den unmittelbar angrenzenden Raum, bis etwa 30cm über den Tisch. Die Synergie beider Hardware-Eingabegeräte, Touch-Rahmen und Leap-Motion, ermöglicht eine wesentlich effizientere Interaktion mit der virtuellen Szene. Die letzte Komponente des Interaktionskonzeptes ist die
Erfassung der Kopfpositionen der Nutzer mit Hilfe der Microsoft Kinect. Dieses Gerät erlaubt es in Echtzeit, die Darstellung der virtuellen Szene anzupassen, indem die Kopfposition des Nutzers dafür verwendet wird, die Perspektive des Nutzers zu berechnen und auf
der Tischfläche darzustellen. Um den Effekt auch für kollaborative Anwendungen zu nutzen, wurde die Displayfläche in vier Quadranten geteilt, und bietet somit für vier Anwender
einen Platz um immersiv am Service Prototypen zu arbeiten (vgl. Abb. 2.32).
Die Anwendung, die für die Holobench entwickelt wurde, ist ein Konfigurator, der die
verschiedenen Aspekte der Service Modellierung zusammenbringt: Einerseits das Einle-
Abb. 2.32 Anwendungsbeispiele an der Holobench
102
A. R. Abdel Razek et al.
sen und Editieren von Prozessdaten, die mit Visio erstellt wurden, als auch der Werkzeuge
für den schnellen Aufbau von 3D-Szenen, um den Service Prototyp in diesem Kontext zu
veranschaulichen. Hinzu kommt die Möglichkeit, den Prozess abzuspielen und somit
vorab die Modellierung zu validieren.
Die Anwendungsfälle in diesem Projekt sind relativ vielfältig. Es wurden mehrere Datenschnittstellen aufgebaut, wie zum Beispiel eine „STEP AP214 Schnittstelle“, eine „IFC
Schnittstelle“, um „BIM Daten“ aus „REVIT“ zu importieren, eine „OWL/RDF Schnittstelle“, um Prozessdaten und Ontologien zu importieren. Die Softwareumgebung unterstützt auch das Einlesen und Visualisieren von 3D-Scan Daten, zum Beispiel über das
„STL“ und „e57 Formate“. Dadurch können mit entsprechender Hardware 3D-Ressourcen
schnell und effizient erstellt werden und für das Service Prototyping eingesetzt werden.
Eine weitere Schnittstelle ist eine direkte Anbindung über eine Netzwerkschnittstelle von
„SolidWorks“, einem CAD-System, zu der Projektlösung. Damit kann direkt aus dem
CAD-System die 3D-Ressource in die VR-Umgebung eingebunden werden. Hierbei werden keine Daten über Export/Import von Austauschformaten übermittellt, sondern direkt
über eine REST-Schnittstelle ausgetauscht, was die schnellere und effizientere Datenübermittlung darstellt. So können auch Änderungen am 3D-Modell im CAD-System direkt an
das VR-System gesendet werden; Änderungen werden somit in quasi Echtzeit synchronisiert. Dies hat enorme Vorteile wie Zeitersparnis und somit wesentlich kürzere Iterationsschleifen, als auch neuen Möglichkeiten effizientere Workflows umzusetzen.
2.7
Service Usability des Prototyps
Martin RabanSaed Imran, Abdul Rahman Abdel RazekAlexander Hengels und
Christian van Husen
Als Basis zur Ermittlung von Beurteilungskriterien für ein neues Konzept der Service
Usability wurden bestehende Ansätze der Dienstleistungsquqlität untersucht. Usability
Engineering und Testing beschränkt sich bisher auf die Untersuchung der Interaktion mit
Geräten, Maschinen oder Anlagen sowie digitalen Benutzeroberflächen. Bei Dienstleistungen können bisherige Konzepte allerdings wegen der Interaktion mit den Akteuren sowie der Freiheitsgrade im Prozess, die durch verschiedene Akteure beeinflusst werden,
nicht angewendet werden. Die Abb. 2.33 und 2.34 geben eine Übersicht verschiedener
Ansätze, Dienstleistungsqualität zu messen (Bruhn 2016, S. 140).
Die Messung von Dienstleistungsqualität lässt sich in objektive und subjektive Messansätze einteilen. Bei der Evaluation im Rahmen des dimenSion-Projekts wurden das Multiattributverfahren (subjektorientiert) mit der Beobachtung (objektorientiert) und den klassischen Usability-Tests kombiniert und auf das Testen von Service Prototypen und -Prototyping
übertragen.
Für das „Multiattributive Verfahren“ (Merkmalsorientierte Messung) wurden im Rahmen des Projektes in Workshops über 200 Attribute gesammelt, mit IDs versehen und kategorisiert, um sie als Bewertungskriterien einzusetzen. Einen Auszug dieser zeigt Tab. 2.14.
2 Methoden
103
Abb. 2.33 Kundenorientierte Messansätze, in Anlehnung an (Bruhn 2016, S. 140 f.)
Einen ersten Ansatz zur Kategorisierung lieferte eine Umfrage (Imran et al. 2018), wobei die Attribute in folgende 12 Kategorien zusammengefasst wurden:
• Reaktionsfähigkeit (Schnelligkeit, Verfügbarkeit, Agilität, …)
• Sicherheit (Datensicherheit, Informationssicherheit, Bequemlichkeit, …)
• Kommunikation (Verständlichkeit, Information über den Status, Dokumentation, …)
104
A. R. Abdel Razek et al.
Abb. 2.34 Unternehmensorientierte Messung von Dienstleistungsqualität, in Anlehnung an (Bruhn
2016, S. 140 f.)
Tab. 2.14 Ausgewählte Attribute und Beispiele als Bewertungskriterien des Prototyps
Attribute
Motivation
Reaktionsfähigkeit
Kommunikation
Verständlichkeit
Rückmeldung
Selbstbeschreibungsfähigkeit
Hilfen
Detailtreue
Fehlertoleranz
Fehlerverhütung
Funktionstiefe
Funktionsumfang
Anpassbarkeit
Erreichbarkeit
Erklärbarkeit
Navigierbarkeit
Konsistenz
Erwartung
Arbeitskultur
Intuition
Innovation
Motivation
Reaktionsfähigkeit
(Imran et al. 2018)
Beispielsthesen zum Prototyp
Der Prototyp motiviert mich, damit zu arbeiten.
Der Prototyp reagiert schnell auf meine Eingaben.
Der Prototyp macht Inhalte leicht kommunizierbar.
Der Prototyp ist verständlich.
Der Prototyp gibt rechtzeitig Rückmeldung über richtige oder falsche Eingaben.
Der Prototyp ist selbsterklärend.
Der Prototyp bietet genügend Hilfen zum Verständnis seiner Bedienung.
Der Prototyp ist ausreichend detailgetreu.
Der Prototyp ist fehlertolerant bei Bedienungsfehlern.
Der Prototyp verhütet aktiv Bedienungsfehler.
Der Prototyp bietet eine passende Funktionstiefe.
Der Prototyp bietet einen passenden Funktionsumfang.
Der Prototyp lässt sich an meine Bedürfnisse anpassen.
Der Prototyp ist über das Internet gut erreichbar.
Der Prototyp macht das Endprodukt im Voraus erklärbar.
Der Prototyp lässt sich gut navigieren.
Der Prototyp ist in sich schlüssig.
Der Prototyp entspricht meinen Erwartungen.
Der Prototyp passt zu meiner Arbeitskultur.
Der Prototyp ist intuitiv bedienbar.
Der Prototyp ist innovativ.
Der Prototyp motiviert mich, damit zu arbeiten.
Der Prototyp reagiert schnell auf meine Eingaben.
2 Methoden
105
• Einfühlungsvermögen (Darstellung der Kundeninteressen, Berücksichtigung emotionaler Aspekte, Hilfen, …)
• Materielles Erscheinungsbild (Ausstattung, Vielfältigkeit, Attraktivität, …)
• Wirtschaftlichkeit (Effizienz, Preis/Leistung, Nützlichkeit, …)
• Zugehöriges Produkt (Anpassbarkeit, Interaktivität, Barrierefreiheit, …)
• Wertschätzung (Erreichbarkeit, verbindliche Ergebnisse, Loyalität, …)
• Wissen (Erklärbarkeit, enthaltene Kenntnisse, enthaltene Erfahrung, …)
• Zuverlässigkeit (Pünktlichkeit, Termintreue, Ernstnehmen des Kundenproblems, …)
• Externe Ressourcen (Gemeinschaftserlebnis, Internationalisierung, Akzeptanz, …)
• Kompetenz (Innovation, Möglichkeit zur Verbesserung, Selbstanpassung, …)
Jedes Attribut wurde basierend auf seiner Signifikanz und Wirkung anhand von LikertSkalenantworten getrennt bewertet. Aus Kundensicht wurde für die Bewertung eines Service Prototyps die Kategorie „Zuverlässigkeit“ am höchsten gewichtet. Die zweit- und
dritthöchste Gewichtung wurde jeweils für „Kommunikation“ und „Reaktionsfähigkeit“
vergeben. Die niedrigste Gewichtung erhielt die Kategorie „Externe Ressourcen“. Zusammenfassend ergab sich folgendes Ranking:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Zuverlässigkeit
Kommunikation
Reaktionsfähigkeit
Wirtschaftlichkeit
Kompetenz
Sicherheit
Wissen
Wertschätzung
Zugehöriges Produkt
Materielles Erscheinungsbild
Einfühlungsvermögen
Externe Ressourcen
Die Qualität von Service Prototypen oder -Prototyping kann generell an Erwartungen,
gesetzten Zielen oder Standards gemessen werden (Parasuraman et al. 1986). Spezielle
Standards für Service Prototypen gibt es jedoch noch nicht.
Ein grundsätzliches Kriterium für einen guten Service ist Kundenzufriedenheit. Dabei
ist zwischen der erwarteten und der tatsächlich wahrgenommenen Leistung aus Kundensicht zu unterscheiden. Liegt die tatsächlich wahrgenommene Leistung unter der erwarteten, so ergibt sich Unzufriedenheit. Entspricht oder übertrifft sogar die wahrgenommene
Leistung, so ergibt sich Zufriedenheit bzw. Begeisterung (Homburg et al. 1999). Eine Bewertung von Service Prototypen erfolgt generell co-kreativ mit Stakeholdern. Kunden
können selbst zum Entwicklerteam gehören oder auch Experten oder Nutzer sein. Bei der
Beurteilung der Dienstleistungsqualität durch Kunden oder Dienstleister werden zwischen
106
A. R. Abdel Razek et al.
Erwartungen und Wahrnehmungen Lücken erkennbar. Das Service Prototyping vermag
durch seinen anschaulichen und kommunikativen Ansatz diese Lücken schon in der Entwicklung greifbar, erlebbar und diskutierbar zu machen. Durch die Besonderheiten von
Dienstleistungen gegenüber Sachgütern ergeben sich auch für die Bewertung von prototypischen Dienstleistungen Besonderheiten. Die Kommunikation der Mitarbeiter (Akteure) untereinander, aber auch im Bezug zu den Artefakten, wird zum Beispiel durch die
Immaterialität besonders stark bewertet.
Die Vorteile des Multiattributverfahrens liegen in der Bewährtheit und Standardisierung, der Vergleichbarkeit der Ergebnisse im Zeitverlauf oder auch mit anderen Einheiten,
und der repräsentativen Ergebnisse. Probleme können „Unschärfen“ bei der Interpretation
sein. Diese sind bei Prototyping jedoch zweitrangig, da es vorrangig um die schnelle
praktische Erstellung eines Maßnahmenkataloges mit wesentlichen Punkten zur kontinuierlichen Verbesserung geht. Aufgrund ihrer Effizienz eignen sich bei prototypischen
Dienstleistungsentwicklungen zur Evaluation besonders qualitative Methoden, da in Entwicklungsprozessen zeitliche und finanzielle Ressourcen kritische Güter sind. Ferner stehen oft nur wenige Probanden zur Verfügung. Durch die Tests wurde das Ziel verfolgt,
schnell einen Maßnahmenkatalog zur Optimierung des Prototyps und der Dienstleistung
in ausreichender Tiefe zu erstellen.
Aufbauend auf dem Multiattributverfahren wurden Usability-Tests entwickelt und
durchgeführt. Für die Entwicklung der Fragebögen wurden Pretests mit einer Studentengruppe durchgeführt, um sich der Thematik praktisch nähern zu können. Anschließend
wurden zu ausgewählten Attributen (z. B. „Motivation“) Bewertungsthesen (z. B. „Die
Arbeit mit dem Prototyp motiviert mich.“) formuliert, welche die separate Bewertung des
Service Prototyps an sich und des Service Prototypings als Prozess berücksichtigte. Der
Prototyp wurde nach Akteuren, Artefakten, Umgebung und Prozess bewertet. Um die
Zielgruppen zu berücksichtigen, wurden vorab Personas, Szenarien und konkrete Aufgaben erarbeitet.
Ferner wurde ein Methodenmix aus qualitativen und quantitativen Elementen angewendet; die Fokusgruppenbefragung wurde als qualitative Methode durchgeführt. Die
Kombination dieser mit einer quantitativen Methode wurde umgesetzt, indem der Bewertungsbogen mittels Likert-Skala von eins bis fünf von den Probanden auszufüllen war und
diese zusätzlich um stichwortartige Begründungen qualitativer Einschätzungen gebeten
wurden. Das hatte zum Vorteil, dass die quantitative Bewertung schnell Schwachstellen
aufdeckte, und die qualitativen Bewertungen effektiv auf die Ursachen dieser Bewertungen hinwiesen, auch, wenn von der geringen Anzahl der Befragten keine repräsentativen
Aussagen erwartet werden können. Der quantitative Ansatz dient also der Sortierung nach
Qualität und Bedeutung, der qualitative Ansatz dient als Grundlage zur Ursachenaufdeckung für die Entwicklung eines Maßnahmenkataloges zur Optimierung des Prototyps
und des Prototypings.
Bei den dimenSion-Verbundpartnern wurde jeweils eine Fokusgruppenbefragung
durchgeführt. An jeder Fokusgruppe nahmen 3–8 Probanden aus dem realen Arbeitsumfeld teil. Nach Faulkner (2003, S. 381) erhält man bereits mit fünf Probanden durch-
2 Methoden
107
schnittlich rund 85 % der Usability-Probleme. Der Fokusgruppe gehörte ferner ein Experte und ein Beobachter an. Diese bearbeiteten den gleichen Bewertungsbogen, erhielten
jedoch eine gesonderte Auswertung. Abweichungen zwischen dem Ergebnis der Probanden als Gruppenergebnis und dem der Experten und Beobachter kristallisierten sich
schnell heraus. Die Gründe der Abweichungen wurden in der Gruppe hinterfragt und beleuchtet.
Während der Gruppentests notierte der Beobachter Mimik, Gestik und verbale Äußerungen. Als Bewertungsattribute wurden z. B. Freude, Überraschung, Interesse, Ärger,
Frust etc. verwendet. Zusätzlich wurden Auffälligkeiten zu Fehlern und Zeiten notiert.
Die Abb. 2.35 zeigt einen beispielhaften Auszug der Testergebnisse und verdeutlicht
die Vorgehensweise.
Links in Abb. 2.35 sind Thesen ersichtlich (z. B. die erste „Der Prototyp ist innovativ“).
In dieser wurde das Attribut „Innovation“ verarbeitet. Grafisch dargestellt sind die Mittelwerte und Modalwerte, gesondert die Ergebnisse des Experten und Beobachters. Mittels
Likert-Skala (1 = stimme zu, 5 = stimme nicht zu) war ein schneller Überblick der quantitavien Ergebnisse möglich. Um Verbesserungsmaßnahmen abzuleiten, konnten die schlecht
bewerteten Thesen effektiv analysiert werden.
Ebenso schnell sind Abweichungen von Experten- und Beobachterbewertungen erkennbar. Beispielsweise wurde die dritte Zeile der Testergebnisse „Der Prototypt ist gut
erreichbar“ vom Experten und auch vom Beobachter wesentlich schlechter bewertet als
von der Gruppe. Auf der rechten Seite sind exemplarisch stichwortartig Kommentare der
Befragten aufgeführt. Die dritte Zeile erklärt: „bei Zielgruppe kein Problem“. Durch
Nachfrage konnte zum Attribut „Erreichbarkeit“ ermittelt werden, dass die Zielgruppe
generell über Internet verfügt und somit der Prototyp – hier das Herunterladen als App –
für Kunden gut erreichbar ist. Dies relativiert dann die negative Bewertung des Experten
und Beobachters. An dieser Stelle ist also keine Maßnahme zur Optimierung des Prototyps
notwendig. Mit dieser Form der Auswertung sind auch schnell und einfach Vergleiche
zwischen zeitlich aufeinander folgenden Tests an gleichen Objekten oder Vergleiche
zweier Objekte möglich.
2.8
Usability-Ergebnisse zu Prototypen der Projektpartner
Martin RabanAbdul Rahman Abdel Razek, Alexander Hengels und Christian van Husen
Im Rahmen des Forschungsprojektes wurden die Prototypen und das Prototyping der Projektpartner Usability-Tests unterzogen und nach der im Unterkapitel 2.7 beschriebenen
Vorgehensweise evaluiert.. Insgesamt nahmen 18 Personen an den Fokusgruppenbefragungen teil. Die Fokusgruppenbefragungen fanden als dreistündiger Workshop jeweils bei
den Projektpartnern vor Ort am Prototyp statt. Die Hochschule Furtwangen moderierte die
Workshops und wertete die Ergebnisse aus. Die Teilnehmer bestanden aus Ingenieuren,
Technikern, Kaufleuten und Projektleitern; je Fokusgruppe nahmen drei bis acht Personen
108
A. R. Abdel Razek et al.
Abb. 2.35 Exemplarischer Ausschnitt der Testergebnisse
2 Methoden
109
teil, die durchschnittliche Berufserfahrung der Teilnehmer lag bei über zehn Jahren. Das
Service Engineering- und Service Prototyping-Know-how der Teilnehmer wurde von diesen selbst im Durchschnitt als „gut“ eingeschätzt.
2.8.1
Evaluationsergebnisse zum Service Prototyping
Service Prototyping wurde mit einem Durchschnitt von „1,8“ als ein gutes Verfahren bewertet und bestätigt die Relevanz des dimenSion-Forschungsschwerpunktes und -themas.
Eine direkte Abfrage, Service Prototyping weiterzuempfehlen, wurde im Durchschnitt mit
„1,4“ bewertet. Modalwerte,vertiefte Nachfragen und Beobachtungen bestätigten das insgesamt sehr positive Bild des Service Prototypings als Verfahren. Besonders positiv wurde
bewertet, dass Service Prototyping Raum für neue Ideen lässt und dieses im Umfeld des
Mittelstandes besonders innovativ ist. Nach Einschätzung der Befragten verbessert sich so
die Qualität am Service-Endprodukt, da viele potenzielle Probleme schon vor der Markteinführung bearbeitet werden können. Das Prototyping schafft ein Bewusstsein für andere
Sichtweisen unter den an der Entwicklung Beteiligten. Somit werden durch co-kreative
Zusammenarbeit vielfältige Lösungen ermöglicht. Eine Stärke des Prototypings liegt in
der guten Kommunikation innerhalb aller Stakeholder anhand eines konkret vorliegenden
Prototyps; Positiv bewertet wurde ebenfalls die aufgelockerte Arbeitsatmosphäre. Dadurch, dass durch das Prototyping der Prototyp erlebbar war, entstand eine hohe Motivation, dieses Verfahren anzuwenden, sodass die Identifizierung potenzieller Probleme
vereinfacht wurde und diese sofort diskutiert werden konnten. Ebenso wurden in der Befragung, und in spontanen Äußerungendas Zusammenbringen der verschiedenen Abteilungen und damit einhergehend ein guter Teamgeist positiv hervorgehoben. Das Service
Prototyping wurde insgesamt als effizientes Verfahren zur Dienstleistungsentwicklung
bewertet.
Gleichzeitig werden aber noch genauere Erklärungen und Definitionen gefordert, um
noch zielgerichteter arbeiten zu können. Durch die gute Abstimmung untereinander sind
alle Arbeitspakete klarer und fokussierter zu bearbeiten, da Bedingungen anderer Abteilungen durch das Prototyping rasch offengelegt werden konnten. So kann auch modular
vorübergehend unabhängig voneinander gearbeitet werden.
Modularisierung war aber im Kontext der eigentlichen Dienstleistungsentwicklung
nach Rückfrage kein hoch relevantes Thema. Etwas kritischer wurden folgende Punkte
bewertet:
• Das Service Prototyping passt generell in die Arbeitskultur der befragten Unternehmen als iterative agile Methode und wird von Ingenieuren als pragmatischer Ansatz
begrüßt, war aber stellenweise etwas ungewohnt.
• Das Prototyping kann Verantwortlichkeiten offenlegen und schnell klären. Das war
aber im Untersuchungsumfeld weniger relevant. Bedarf besteht noch an der praktischen Umsetzung des Prototyping.
110
A. R. Abdel Razek et al.
• Prototyping bereitet gelegentlich Probleme; das kann beispielsweise das Vorhandensein von Daten für die Erstellung eines 3D-Prototyps in AutoCAD sein.
• Informationsbedarf zur Durchführung von Prototyping. Generell fehlt es noch an
praktischen Ratgebern zur Durchführung von Service Prototyping. Sobald aber die Information besteht, lässt sich Service Prototyping relativ einfach umsetzen. Es fördert
eine flexible und freie Arbeitsweise, die aber nicht jeder Techniker gewohnt ist.
• Aufwand zur Erstellung des Prototyps; situativ fehlt es an Ressourcen zur Umsetzung.
Nicht relevant war im Voraus eine rechtliche Begutachtung der Dienstleistungen am
Prototyp. Dies wurde mit der relativ niedrigen Bewertung zum Ausdruck gebracht.
Bei den begleitenden Beobachtungen über die Teilnehmer gab es keine wesentlichen
Widersprüche zu den über den Fragebogen geäußerten Bewertungen, sowohl beim Prototyping als auch zu den Prototypen selbst.
Die Reflexion der Ergebnisse ergibt nicht wie bei den in Abb. 2.36 beschriebenen
Usability-Tests der Prototypen einen klassischen Maßnahmenkatalog, sondern diese können
als Anregungen für die Forschung zur Weiterentwicklung des Service Prototypings verstanden werden. Das Service Prototyping scheint als Verfahren sehr gut akzeptiert zu werden und
kann durch verbesserte Vorgehensmodelle und praktische Tipps zur Anwendung eine praxisnah durchführbare Herangehensweise in der Dienstleistungsentwicklung darstellen.
2.8.2
Usability-Test-Ergebnisse zu Service Prototypen
Die Service Prototypen wurden zusammen mit einem Durchschnitt von „2,1“ als gut bewertet, eine direkte Abfrage auf Weiterempfehlung dieser wurde mit „1.3“ bewertet (vgl.
Abb. 2.37). Konkrete Beschreibungen der Prototypen sind in Kap. 4 zu finden. Modalwerte und die differenzierte Nachfrage und Beobachtungen bestätigten das insgesamt positive Bild der Service Prototypen. Im Umfeld von KMUs galten die Prototypen als besonders innovativ. Da Prototypen oft sehr bildhaft gestaltet sind, lassen sie sich mit
geringem Aufwand international einsetzen. Die untersuchten Prototypen waren insgesamt
ausreichend detailgetreu, lediglich eine reale Positionierung im Arbeitsumfeld des zukünftigen Nutzers fehlte gelegentlich. Auch die Navigation wurde als gut bewertet, bei softwarebasierten Prototypen zeigte oft die Gestaltung von Buttons noch Verbesserungenpotenziale. Die Prototypen waren generell gut zugänglich. Bei den potenziellen Nutzern
wurde der Zugang zum Internet zu softwarebasierten Prototypen als gegeben bestätigt; bei
den konkreten Prototypen wurde die gute Kommunizierbarkeit hervorgehoben.
Insgesamt wurden die Prototypen überwiegend visuell und weniger auditiv umgesetzt.
Die gute Kommunizierbarkeit der Prototypen machten finale Services im Voraus erlebbar,
wodurch komplexe Handlungsabläufe durch die intuitive Usability unterstützt wurden.
Die Prototypen waren methodisch-konzeptionell gut aufgebaut und trafen nach Aussagen
der Befragten die Kernfunktionen der zukünftigen Leistungen. Sie waren derart gestaltet,
dass sie den potenziellen Nutzer keine speziellen Fertigkeiten zur Nutzung abverlangten;
2 Methoden
111
die Umgebung der finalen Services wurde nutzeradäquat bei der Konzeption berücksichtigt. Gemessen daran, ob die reale Nutzung der Prototypen einen Berater des Unternehmens voraussetzt oder der Nutzer den Prototyp allein anwendet, wurden die Prototypen als
selbsterklärend, benutzerfreundlich und verständlich bewertet. Die Nutzer wurden durch
die Prototypen motiviert, diese anzuwenden; hervorgehoben wurde das spielerische Erkunden. Die Fidelity der Prototypen wurde dem Zweck entsprechend als angemessen
empfunden. In der Tiefe seien weitere Funktionen denkbar, jedoch für den aktuellen Entwicklungsstand des Service vollkommen ausreichend, sodass die Prototypen den Erwartungen der Nutzer entsprachen.
Abb. 2.36 Ranking zur Bewertung des Service Prototypings
112
A. R. Abdel Razek et al.
Abb. 2.37 Ranking zur Bewertung der Service Prototypen
Bei der Anwendung immersiver Technologien bestehen seitens Nutzer oft Hemmungen, eine 3D-Brille aufzusetzen. Die Reaktionsgeschwindigkeiten der Informationseingabe an den Prototypen selbst wurde, mit Ausnahme eines Prototpys, als angenehm
beschrieben. Etwas kritischer wurden mögliche Vorkehrungen zur Fehlertoleranz bei Eingaben bewertet; über FAQs oder direkte Rückmeldungen sollten den Nutzern relevante
Usability-Hinweise gegeben werden. Ein konkretes Beispiel dieser war der Abstand zwischen Tablet und Marker, der für eine einwandfreie Nutzung eingehalten werden musste.
Generell passten die Prototypen in die jeweilige Arbeitskultur. Die Nutzung immersiver
Technologien könnte sich für Nutzer höheren Alters jedoch adaptionsintensiver als für
jüngere Nutzer darstellen. Als störend wurde bei softwarebasierten Prototypen ein leicht
zeitverzögertes Ansprechverhalten kritisiert, was aber rein technisch lösbar war. Die Prototypen wurden, bis auf Ausnahme einiger Button-Systematiken (z. B. Hilfe-Buttons), als
in sich schlüssig bewertet. Gewünscht waren FAQs und auch Tutorials in Form von Filmen
2 Methoden
113
oder gar Trainer für komplexe Anwendungen. Die meisten Prototypen waren technisch
recht aufwändig und wenig individuell konfigurierbar (z. B. Barrierefreiheit). Aber auch
dies wurde von den Befragten relativiert, da bei diesen Anwendungen solche Gesichtspunkte in der realen Anwendung kaum von Bedeutung waren. Als wesentliche Probleme
galten im Allgemeinen Leistungsbeschränkungen der verwendeten Hardware oder gelegentliches „Aufhängen“ der softwarebasierten Prototypen. Die Probleme waren somit alle
eher technischer als inhaltlicher Art. Bei der Erstellung digitaler Prototypen bereiteten
gelegentlich Datenkonvertierungen Probleme. Aktive Rückmeldungen oder Präventionen
möglicher Usability-Fehler waren bei den getesteten Prototypen nicht vorgesehen, da sie
in diesem Kontext nicht notwendig waren; Ausnahme bildet der hardwarebedingte korrekte Abstand des Tablets zu den Markern.
2.8.3
Usability-Test-Ergebnisse zu den Design Dimensionen
Akteure Bei den befragten Unternehmen waren in den Prototypen keine Akteure explizit
dargestellt. Somit wurde keine Bewertung vorgenommen. Nach der Vorgehensweise der
anderen Design-Dimension-Usability-Fragen in Unternehmen, können die Akteure nach
folgenden Thesen zur Bewertung befragt werden:
•
•
•
•
•
•
•
•
•
•
Der Akteur handelt realistisch
Der Akteur reagiert realitätsgetreu
Der Akteur kommuniziert realistisch
Der Akteur zeigt passende Emotionen
Der Akteur ist sympathisch
Der Akteur löst jede Aufgabe
Der Akteur zeigt realistische Fertigkeiten
Der Akteur ist an verschiedene Szenarien anpassbar
Der Akteur reagiert flexibel
Der Akteur ist vertrauenswürdig
Artefakte Als Artefakte werden Gegenstände oder auch Software bezeichnet, die in
den Handlungen der Dienstleistungen verwendet werden. So wurde bei einem der untersuchten Prototypen ein Marker verwendet, der gesondert auf Usability getestet
wurde; an anderer Stelle waren es in der Software dargestellte Werkzeuge. Die Ergebnisse sind so individuell, dass die Darstellung hier nur exemplarisch gelten kann.
Abb. 2.38 zeigt Parallelen zur Bewertung des gesamten Prototyps und ist entsprechend
zu deuten.
Umgebung Aufgrund der Individualität der Ergebnisse kann Abb. 2.39 ebenfalls nur
exemplarisch gelten. Bei einem Prototyp ist die Umgebung eine gesamte Modellbauanlage gewesen, ein anderer umgab sich mit einem Raum eines simulierten Steuerstands.
114
A. R. Abdel Razek et al.
Abb. 2.38 Ranking zur Bewertung der Artefakte
Abb. 2.39 Ranking zur Bewertung der Umgebung
Prozesse Mit „Prozesse“ sind hier die Prozesse der zu entwickelnden Dienstleistungen,
die im Prototyp Grundlage für die Handlungsabläufe der Dienstleistung sind, gemeint.
Auch der Prozess kann an dieser Stelle lediglich exemplarisch gelten, da dieser je nach
Dimensionen-Konfiguration individuell gestaltet ist. Die Prozesse wurden als sehr effizient und effektiv beschrieben und entsprachen somit den Anforderungen.
Auf Basis der Usability-Tests der einzelnen Prototypen ließe sich aus den Kommentaren zu den bewerteten Thesen schnell ein Maßnahmenkatalog entwickeln (vgl. Abb. 2.40).
Dazu wäre noch eine Gewichtung der Thesen empfehlen. Sinnvoll hierbei ist aber keine
allgemeingültige Gewichtung, sondern eine eigens für jeden Fall undPrototyp entwickelte
Gewichtung.
2 Methoden
115
Abb. 2.40 Ranking zum im Prototyp dargestellten Prozess
2.9
Ergebnisse aus Befragung der Industrie
Abdul Rahman Abdel RazekMartin Raban, Alexander Hengels und Christian van Husen
2.9.1
Vorgehensweise und Aufbau der Befragung
Ziele der Umfrage Die Umfrage zielte auf die Beantwortung der Fragen,
• inwieweit produzierende Unternehmen in Deutschland aktuell Strategien des Wandels
zum Lösungsanbieter verfolgen,
• wie Dienstleistungen entwickelt werden,
• inwiefern Service Prototyping mit seinen Darstellungsmöglichkeiten für Dienstleistungen Anwendung findet,
• und welche Motivation diesbezüglich besteht.
Aus den ermittelten Hürden sollten anschließend verbesserte Ansätze abgeleitet werden. Darüber hinaus war von Interesse, wie sich produzierende Unternehmen hinsichtlich
des Vertriebs neuer Dienstleistungen und Lösungen positionieren und wie deren Lösungen
im Sinne der Customer Experience bewertet werden.
Umfragestruktur Insgesamt reagierten 263 Befragte, wobei leider eine hohe Abbruchquote zu verzeichnen war, vermutlich aufgrund des umfangreichen Fragenkatalogs. 72 Teilnehmer haben jedoch den Fragekatalog vollständig beantwortet, sodass sich aus diesen Ergebnissen klare Antworten herauskristallisierten und eindeutige Tendenzen erkennbar wurden.
Die Hälfte der Antworten stammt von Befragten aus dem „Maschinen- und Anlagenbau“. Die restlichen Antworten stammen ebenfalls aus technischen Branchen, namentlich
116
A. R. Abdel Razek et al.
„Herstellung von Datenverarbeitungsgeräten“, „Herstellung von elektrischen Ausrüstungen“ und „Reparatur und Installation von Maschinen“.
Die Befragten waren zur Hälfte im Service-Ressort tätig, übten aber auch zu größeren
Anteilen Tätigkeiten der Geschäftsführung und des Vertriebs aus, sodass ca. 60 % dieser
auf Managenemnt-Ebene agierten. Ein Viertel der Befragten war schon mehr als 15 Jahre
in Ihrer Funktion tätig, ein anderer großer Teil gab an, eine Tätigkeitsdauer von 3 Jahren
verzeichnen zu können.
Die befragten Unternehmen boten hauptsächlich Dienstleistungen zur Unterstützung des
Produktlebenszyklus, der Anlageneffizienz und der Prozesse an. Dienstleistungen durch Übernahme von Teilprozessen (z. B. Infrastrukturübernahme) waren deutlich weniger vertreten.
Strategie Die Befragten maßen einer Servitization-Strategie eine hohe Bedeutung bei, Investitionen in die Umsetzung bleiben jedoch dahinter zurück. Trotz der Erkenntnis, dass
eine Notwendigkeit systematischer Dienstleistungsentwicklung besteht, wurden hohe Investitionen selten getätigt und entsprechende Strategien nicht adäquat fokussiert. Ungefähr
ein Viertel der Befragten beschäftigte sich länger als 5 Jahre mit Produkt-Service-SystemKonzepten. Der Anteil an IT-Innovationen bei neuen Dienstleistungen wurde mit einem
mittleren bis niedrigen Niveau angegeben, ebenso der Anteil an radikalen Innovationen.
2.9.2
Ergebnisse der Befragung
Dienstleistungsentwicklung Die Befragten bewerteten die eigenen Unternehmen im
Vergleich zu Wettbewerbern durchweg als gut darin, Probleme ihrer Kunden zu identifizieren, kreativ selbst nach Lösungen suchen zu können, Lösungskonzepte zu erarbeiten
und diese zu testen, zu verbessern und weiterzuentwickeln.
Hingegen sahen sie die Formalisierung des Prozesses zur Entwicklung von Dienstleistungen als eher schlecht und ordneten das Vorhandensein von detaillierten Aufgabenbeschreibungen nur einem mittleren Niveau zu.
Gestaltung und Tools Die Gestaltung von Dienstleistungen findet bei den befragten
Unternehmen hauptsächlich klassisch über Texte statt, aber auch mit Abbildungen, Prozessmodellen und Lastenheften; 10 % der Befragten gaben an, Dienstleistungsentwicklungen überhaupt nicht zu beschreiben.
Um einen Überblick der Umfrage zu verschaffen, werden von Abb. 2.41, 2.42, 2.43,
2.44, 2.45, 2.46, 2.47, 2.48 und 2.49 ausgewählte Fragen des Katalogs mit dazugehörigen
Antwortverteilungen dargestellt:
„Wenn Sie Dienstleistungen beschreiben – welche Tools nutzen Sie dafür?“ 90 % der
Befragten nutzten klassische Bürosoftware, z. B. Microsoft Word, 46 % nutzen Prozessmodellierungssoftware, z. B. Microsoft Visio und 33 % nutzen Grafiksoftware, z. B. Adobe
Illustrator; es waren Mehrfachnennungen möglich.
2 Methoden
Abb. 2.41 Tools zur Beschreibung von Dienstleistungen
Abb. 2.42 Webkonferenz-Software zur Unterstützung der dezentralen Zusammenarbeit
Abb. 2.43 Projektion (2D oder 3D) zur Visualisierung von Dienstleistungen
Abb. 2.44 Smartboards zur Unterstützung der Kreativarbeit
117
118
A. R. Abdel Razek et al.
Abb. 2.45 Kompetenz im Bereich IT-basierte Dienstleistungen
Abb. 2.46 Kompetenz, Dienstleistungsinnovationen mit Hilfe von IT-Unterstützung zu entwickeln
Abb. 2.47 Kompetenz in Virtual Reality und Augmented Reality
2 Methoden
119
Abb. 2.48 Bereitschaft für den Einsatz von Virtual Reality
Abb. 2.49 Bereitschaft für den Einsatz von Augmented Reality
„Wie häufig werden folgende Medien bei der Entwicklung von Dienstleistungen in Ihrem Unternehmen genutzt?“ Zur gezielten Frage über die Nutzung von WebkonferenzSoftware bei der Entwicklung von Dienstleistungen ergab sich eine Aufteilung: ein Drittel
der Befragten nutzte diese Software nie, ein Viertel benutzte sie fast immer. Ein ähnliches
Muster ergab die Visualisierung von Dienstleistungen mittels 2D- oder 3D-Projektion.
Smartboards werden zurzeit hingegen „fast nie“ bis „nie“ genutzt.
„Inwiefern ist in Ihrem Unternehmen oder Geschäftsbereich die Kompetenz bzw. Bereitschaft vorhanden, Informationstechnik bei der Entwicklung von Dienstleistungen
zu nutzen?“ Bei der Selbsteinschätzung der Kompetenz bei IT-basierten Dienstleistungen und auch Dienstleistungsinnovationen mit IT-Unterstützung ergab sich ein diffuses
Bild über alle Bewertungsklassen hinweg. Eine deutliche Tendenz ist hingegen in der
Selbsteinschätzung zur Kompetenz in Augmented Reality zu sehen, welche die meisten
bei sich als „sehr niedrig“ angaben.
„Inwiefern ist in Ihrem Unternehmen oder Geschäftsbereich die Kompetenz bzw. Bereitschaft vorhanden, Informationstechnik bei der Entwicklung von Dienstleistungen zu
nutzen?“ Ebenso die Bereitschaft zum Einsatz von Virtual Reality und Augmented Reality
120
A. R. Abdel Razek et al.
wurde generell als schlecht angegeben. Auf dieser Ebene besteht also noch viel Potenzial,
die Vorteile dieser Technologien bekannt zu machen und gewinnbringend zu nutzen.
Zusammenarbeit Die Zusammenarbeit während der Dienstleistungsentwicklung wurde
als „generell gut“ angegeben. Nach Einschätzung der Befragten fällt es den Kundenbetreuern
leicht, für eine Dienstleistungsentwicklung mit den betreffenden Kunden in Kontakt zu
treten und diese auf unbewusste Bedürfnisse anzusprechen. Es wurde eine gute Vernetzung zu Kunden genannt; ebenso fällt es leicht, trendführende Kunden (Lead User)zu
identifizieren und mit ihnen in Kontakt zu treten.
Genauso als „gut“ wurde speziell die Kooperation zwischen der Dienstleistungsentwicklung und Kunden angegeben. Unter „Kooperation“ wurde die Entwicklung neuer
Dienstleistungen oder Lösungen allgemein, die Analyse von Kundenbedürfnissen und die
Zusammenarbeit an Prototypen genannt. Die kooperative Arbeitmit Prototypen, z. B. die
Diskussion der Service-Qualität oder die Definition von Zielen und Prioritäten bei der
Dienstleistungsentwicklung, wurde mit einem mittleren Niveau angegeben. Schlussfolgernd lässt sich ableiten, dass ein großes Potenzial besteht, Arbeit mit Prototypen in der
Dienstleistungsentwicklung zu erforschen, eine praxisnahe Handhabung zu transferieren
und Forschungsergebnisse der breiten Masse zugänglich zu machen.
Service Prototyping Service Prototypen wurden zum Zeitpunkt der Umfrage generell
selten bei der Dienstleistungsentwicklung verwendet. Das gilt für die Darstellung von
Inhalten, Gegenständen, Nutzer-Schnittstellen und Einbindung in die Umgebung oder
Abläufe.
„Wie häufig setzen Sie Prototypen während der folgenden Phasen des Entwicklungsprozesses ein?“ Bei der Frage nach dem Einsatz von Prototypen im Entwicklungsprozess
wurde deutlich, dass bei „Ideenfindung und -bewertung“, „Anforderungsdefinition“, „Design“ und „Implementierung“ Prototypen selten genutzt werden; eine Ausnahme zeigt die
Phase der Markteinführung. Hier war eine Differenzierung der Aussagen zu finden: Ein
Drittel der Befragten gab an, Prototypen nie zu verwenden, ca. ein Viertel verwendete sie
sehr häufig. Demzufolge werden Prototypen bisher hauptsächlich erst in späten Entwicklungsphasen eingesetzt. Ziel des Forschungsprojektes dimenSion ist es jedoch, Protoyping
schon in den frühen Phasen der Dienstleistungsentwicklung zu etablieren, um Fehlentwicklungen dadurch vorzubeugen, indem unter anderem alle Service-Stakeholder in eine
transparente Kommunikation miteinbezogen werden (Abb. 2.50, 2.51, 2.52, 2.53 und 2.54).
Auch bei der Zweckorientierung des Prototypeneinsatzes wurde die seltene Nutzung
deutlich. Sowohl bei der Exploration von Ideen, als auch bei Besprechungen zu Entwicklungsständen wurden Prototypen selten eingesetzt.
Für eine Kosten- und Risikoreduzierung wurde eine hohe Motivation zum Einsatz von
Prototypen genannt, eine mittlere Motivation hingegen für Preiseinschätzungen oder Aufzeigen des Mehrwertes für die Kunden.
2 Methoden
Abb. 2.50 Ideenfindung und -bewertung
Abb. 2.51 Anforderungsdefinition
Abb. 2.52 Design
121
122
A. R. Abdel Razek et al.
Abb. 2.53 Implementierung
Abb. 2.54 Markteinführung
Die Qualität der Zuverlässigkeit genutzter SP-Tools, der damit verbundene PrototypingProzess und die prototypische Repräsentation und Visualisierung werden als „mittel“ oder
als „sehr schlecht“ eingestuft. Die Gesamtqualität des Service Prototyping wird tendenziell als „schlecht“ eingestuft. Die sehr negativen Einstufungen rührten vermutlich daher,
dass keine Prototypen verwendet werden und lediglich Meinungen über eine Bewertungsskala (1–5) geäußert wurden.
Service Prototyping-Techniken Das Ergebnis der Umfrage zeigte, dass Service Prototyping generell für drei Zwecke angewandt wird (Sämann et al. 2016):
1. Exploration neuer Ideen und Lösungen,
2. Kommunikation und Feedback-Erhebung von Stakeholdern, um vorab Erfahrung und
Kompetenzen aufzubauen, Wissen zu generieren, die Stakeholder in die Entwicklung
miteinzubeziehen und Dokumentationen zu erstellen,
3. Bewertung neuer Serviceidee oder eines neuen Servicekonzepts und so die Entscheidungsfindung zu unterstützen.
„Sind die folgenden Techniken in Ihrem Unternehmen oder Geschäftsbereich bekannt
und werden diese in Ihrem Unternehmen oder Geschäftsbereich eingesetzt?“ Folgende
Techniken werden bevorzugt eingesetzt (Abb. 2.55, 2.56 und 2.57)
2 Methoden
123
Abb. 2.55 Papier Prototyping
Abb. 2.56 Live Prototyping
Abb. 2.57 Service Skizzen
Folgende Techniken sind generell bekannt, werden aber nicht eingesetzt
(Abb. 2.58, 2.59 und 2.60):
Folgende Techniken sind eher unbekannt (Abb. 2.61, 2.62, 2.63, 2.64, 2.65, 2.66
und 2.67):
Platzhalter Abbildung Start Mock-up (Attrappe eines Gegenstandes)
Dienstleistungsentwicklungsprozess Der im eigenen Unternehmen durchgeführte Dienstleistungsentwicklungsprozess wurde tendenziell als „gut“ bis „mittelmäßig“ bewertet.
Dieser wird nach Selbsteinschätzung kaum schneller als vom Wettbewerb durchlaufen
124
A. R. Abdel Razek et al.
Abb. 2.58 Storyboard
Abb. 2.59 Rollenspiele
Abb. 2.60 Video Prototyping
und besteht in ähnlicher Qualität; diese Aussage ist auf den aus der Dienstleistung entstandene Kundennutzen übertragbar. Etwas kritischer, aber auch noch mittelmäßig, war
die Selbsteinschätzung bezüglich Beschwerden und Reklamationen bei Dienstleistungen;
die Termintreue wurde teils „eher gut“ und „eher schlecht“ eingeschätzt.
Kundeninformation Kunden werden generell gut über neue Dienstleistungen informiert; das bestätigten 83 % der Befragten. Klassische Informationsmedien, sowohl digita-
2 Methoden
125
Abb. 2.61 Service Blueprinting
Abb. 2.62 Mock-up
Abb. 2.63 Step-through Simulation
ler (E-Mail, Online-Katalog) als auch physischer Art (Druckmedien wie Flyer, persönlicher Austausch auf Messen und Events) , werden bevorzugt. Videoportale wie YouTube
oder soziale Netzwerke wie Facebook finden deutlich selteneren Einsatz. Das mag mit der
Altersstruktur der Befragten zusammenhängen, da, wie eingangs erwähnt, über ein Viertel
der Befragten schon über 15 Jahre ihre Positionen einnehmen. Man kann also davon ausgehen, dass diese Befragten fortgeschrittenen Alters sind.
126
A. R. Abdel Razek et al.
Abb. 2.64 Personas
Abb. 2.65 Customer Journey Map
Abb. 2.66 Virtual Prototyping
Anforderungsmanagement Die Bewertung der Fähigkeiten von Mitarbeitern der Entwicklung im Vergleich zum Vertrieb entspricht ihren Stärken in Ihren Aufgabenfeldern im
Dienstleistungsentwicklungkontext. So wurden die Entwicklungsmitarbeiter als „gut“ darin bewertet, Anforderungen zu analysieren und Vertriebsmitarbeiter als „gut“ darin bewertet, Anforderungen zu ermitteln. Die Eigenschaften der Entwicklungs- und Vertriebsmitarbeiter, Anforderungen zu erfragen, zu beschreiben und zu validieren wurden auf
mittlerem Niveau bewertet. Hier könnten Schulungen das Potenzial erschließen, besonders die beschreibenden und validierenden Aspekte.
2 Methoden
127
Abb. 2.67 Wizard-of-Oz
Erfolg Diese Umfrage zeigt, dass funktionale Aspekte das Kundenerlebnis einer Dienstleistung sehr stark beeinflussen. Emotionale, monetäre und nicht-monetäre Aspekte,
z. B. der Zeiteinsatz der Kunden, treten dagegen eher in den Hintergrund.
Die Kundenzufriedenheit wird aus Sicht der Befragten, also von Unternehmerseite, als
durchweg positiv bewertet, sowohl bezüglich der Unternehmen selbst als auch mit der
Dienstleistung; das gilt über alle Kontaktpunkte hinweg. Die Kundenerfahrung seitens der
Unternehmen wird als umfassend, persönlich und nachhaltig wahrgenommen.
Literatur
Abdel Razek AR, van Husen C, Pallot M, Richir S (2017) Innovation by service prototyping design
dimensions and attributes, key design aspects, and toolbox. In: Proceedings of international conference on engineering, technology and innovation (ICE/ITMC), IEEE, Funcal, S 571–576
Abdel Razek AR, van Husen C, Pallot M, Richir S (2018a) A comparative study on conventional
versus immersive service prototyping (VR, AR, MR). In: Proceedings of the virtual reality international conference-laval virtual, ACM, Laval, S 9
Abdel Razek AR, van Husen C, Pallot M, Richir S (2018b) A proposed research framework and
model for service prototyping. In: Proceedings of 2018 IEEE international conference on engineering, Stuttgart
Adams S (1997) Das Dilbert-Prinzip – Die endgültige Wahrheit über Chefs, Konferenzen, Manager
und andere Martyrien. Redline, München, ISBN: 978-3-636-01592-1
Arvola M, Blomkvist J, Holmlid S, Pezone G (2012) A service walkthrough in Astrid Lindgren’s
footsteps. In: Proceedings of service design and innovation conference, Espoo. Linköping University Electronic Press, Linköping, S 21–29
Beck K (2001) Manifesto for Agile software development. agilemanifesto.org/: http://agilemanifesto.org/. Zugegriffen am 07.08.2010
Blomkvist J, Holmlid S (2012) Service prototyping according to service design practitioners. In:
Proceedings of ServDes 2010, exchanging knowledge, Bd 60, Linköping University Electronic
Press, Linköping, 1–3 Dec 2010, S 1–11
Bruhn M (2016) Qualitätsmanagement für Dienstleistungen – Handbuch für ein erfolgreiches Qualitätsmanagement. Grundlagen – Konzepte – Methoden. Springer, Berlin/Heidelberg
128
A. R. Abdel Razek et al.
Buchenau M, Fulton Suri J (2000) Experience prototyping. In: Proceedings of 3rd conference on
designing interactive systems, nordic design research conference. ACM, New York, S 424–433
Buchwald H (2009) The power of ‚As-Is‘ processes. In: S-BPM ONE. Springer, Karlsruhe, S 13–23
Cooper RG (2010) Top oder Flop in der Produktentwicklung – Erfolgsstrategien: Von der Idee zum
Launch. Wiley, Weinheim
Dede C (2009) Immersive interfaces for engagement and learning. Science 323(5910):66–69
Dryer MS (2017) Chapter order of subject, object and verb – the world atlas of language structures.
http://wals.info/chapter/81. Zugegriffen am 06.02.2017
Exner K, Lindow K, Buchholz C, Stark R (2014) Validation of product-service systems–a prototyping approach. Procedia CIRP 16:68–73
Faulkner L (2003) Beyond the five-user assumption: benefits of increased sample sizes in usability
testing. Behav Res Methods Instrum Comput 35(3):379–383
Fleischmann A (1994) Distributed systems: software design and implementation. Springer, Berlin/
Heidelberg. ISBN: 3-540-57382-8
Fleischmann A, Schmidt W, Stary C, Obermeier S, Börger E (2011) Subjektorientiertes Prozessmanagement: Mitarbeiter einbinden, Motivation und Prozessakzeptanz steigern. Hanser, München
Fleischmann A, Borgert S, Elstermann M, Singer R (2017) An overview to S-BPM oriented tool
suites. ACM, Darmstadt
Fukuhara T, Tenmoku R, Okuma T, Ueoka R, Takehara M, Kurata T (2014) Improving service processes based on visualization of human-behavior and POS data: A case study in a Japanese restaurant. Serviceology for Services. Springer, Tokyo, S 3–13
Goodwin K (2011) Designing for the digital age: how to create human-centered products and services. Wiley, Weinheim
Herstatt C, Verworn B (2007) Management der frühen Innovationsphasen: Grundlagen – Methoden – Neue Ansätze. Gabler, Wiesbaden
Homburg C, Giering A, Hentschel F (1999) Der Zusammenhang zwischen Kundenzufriedenheit und
Kundenbindung. In: Bruhn M, Homburg C (Hrsg) Handbuch Kundenbindungsmanagement:
Grundlagen, Konzepte, Erfahrungen. Gabler, Wiesbaden, S 81–112
Imran S, Raban M, van Husen C, Abdel Razek AR (2018) An approach for enhancing the value of
industrial service prototyping. In: Proceedings of the 28th RESER conference, Gothenburg
Jacoby W (2015) Projektmanagement für Ingenieure. Springer, Heidelberg
Jung Bae D, Seong Leem C (2014) A visual interactive method for service prototyping. Manag Serv
Quality 24(4):339–362
Keßler H, Winkelhofer G (2011) Projektmanagement – Leitfaden zur Steuerung und Führung von
Projekten. Springer, Heidelberg, S 2011
Kim HM, Lyons K, Cunningham MA (2008) Towards a framework for evaluating immersive business models – evaluating service innovations in second life. In: Proceedings of the 41st annual
hawaii international conference on system sciences (HICSS 2008). IEEE, Hawaii, S 110
Larman C (2009) Scaling lean & agile development: thinking and organizational tools for largescale scrum. Addison-Wesley, Upper Saddle River
Mackay WE (1988) Video prototyping: a technique for developing hypermedia systems. In: Proceedings of companion human factors in computing systems conference, Bd 5, S 1–3, Austin, Texas
Marcus A (1997) Graphical user interfaces. In: Handbook of human-computer interaction. Elsevier
Science Inc., North-Holland, S 423–440
Miettinen S, Rontti S, Kuure E, Lindström A (2012) Realizing design thinking through a service
design process and an innovative prototyping laboratory – introducing service innovation corner
(SINCO). In: Proceedings of the conference on design research society (DRS 2012), Bangkok,
S 1202–1214
Moritz S (2005) Service design – practical access to an evolving field. International School of Design, Köln
2 Methoden
129
Oh K, Lee JS, Kim SK, Jung JY, Kim B (2013) Service prototyping for service testing in virtual
reality. Intern J Inf Electron Eng 3(3):304–308
Pallot M, Pawar K, Santoro R (2013) A user experience framework and model within experiential
living labs for internet of things. In: Proceedings of engineering, technology and innovation ICE/
IEEE international technology management conference, The Hague, S 1–15
Pallot M, Dupont L, Christmann O, Richir S, Vincent B, Morel L (2017) ICE breaking: disentangling factors affecting the performance of immersive co-creation environments. In: Proceedings of
VRIC virtual reality international conference, Funcal
Parasuraman A, Zeithaml V, Berry LL (1986) SERVQUAL: a multiple-item scale for measuring
customer perceptions of service quality, report no. 86-108. Marketing Science Institute, Cambridge, MA
Pasman G (2016) Design fiction as a service design approach. In: Service design geographies,
proceedings of the ServDes. University Electronic Press. No. 125, Linköping, S 511–515
Peng KL, Lin YL, A Nd Tseng YC (2017) Constructing a 3D multiple mobile medical imaging system through service science, management, engineering and Design. Systems 5(1):5
Peter LJ, Hull R (2001) Das Peter-Prinzip oder die Hierarchie der Unfähigen. Rowohlt, Reinbek bei
Hamburg, ISBN: 978-3-499-61351-7
Polson PG, Lewis C, Rieman J, Wharton C (1992) Cognitive walkthroughs: a method for theorybased evaluation of user interfaces. Int J Man Mach Stud 36(5):741–773
Quesenbery W, Brooks K (2010) Storytelling for user experience: crafting stories for better design.
Media, Rosenfeld
Sämann M, Abdel Razek AR, Imran S, van Husen C, Droll C (2016) Innovation in prototyping for
technical product service systems, Bd 22. IEEE International Technology Management Conference, Trondheim
Schmidt W, Fleischmann A, Gilbert O (2009) Subjektorientiertes Geschäftsprozessmanagement.
HMD Praxis Wirtschaftsinformatik 46(2):52–62
Schwaber K (2004) Agile project management with scrum. Microsoft Press, Redmond
Sefelin R, Tscheligi M, Giller V (2003) Paper prototyping – what is it good for? A comparison of
paper- and computer-based low-fidelity prototyping. In: CHI’03 extended abstracts on Human
Factors in Computing Systems, ACM, S 778–779
Shostack GL (1984) Designing services that deliver. Harv Bus Rev 62(1):133–139
Wang G (2002) Definition and review of virtual prototyping. J Comput Inf Sci Eng 2(3):232–236
Wikipedia – Iterative Development (2019) Iterative development. Wikipedia.org: https://de.wikipedia.org/wiki/Datei:Development-iterative.png. Zugegriffen am 30.06.2019
Wikipedia – Scrum (2018) Scrum. Wikipedia.org: http://en.wikipedia.org/wiki/Scrum_%28development%29. Zugegriffen am 07.08.2018