Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Methoden

Multidimensionales Service Prototyping

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