Service Engineering Blog

Clash of Cultures wenn Engineering auf Design trifft? Nicht ganz, aber: Man spricht über das gleiche Thema (Dienstleistungsentwicklung) und versteht doch jeweils was ganz anderes darunter. Das kann mühsam sein, ist es aber nicht, denn durch das Aufbrechen der Denkmuster entdeckt man nicht nur ein neues Land, nein, es kommt ein ganzer neuer Kontinent zum Vorschein. Hier ist also mein Bericht über meine „Entdeckung der Neuen Servicewelt“ und von meiner Job-Shadowing Woche als „Werkstudent“ bei Uscreates in London….Vorweg zur Weltstadt London: Teuer und schnell (zumindest für einen Kleinstädter wie mich). Meine Gastgeberin Mary (Director Uscreates) hat nicht mal die Ruhepause auf der Rolltreppe in der U-Bahn genutzt (Sorry, can I pass?). Und ich immer hinterher gehetzt. Seltsamerweise ist die Geschwindigkeit je nach Stadtteil geregelt: Financial Disctrict – Full throttle, London Bridge – Cruise. Nach einer Woche London war ich auf den Wien-Marathon vorbereitet und habe 3 Kilo abgenommen.

Mein Wochen-Programm:
Tag 1: Kennenlernen der Firma, der Service Design Prozesse und Werkzeuge bei Uscreates und Diskussion über Fallbeispiele
Interessant, im Gespräch mit Joanna spricht sie vorweg über das Mission Statement des Unternehmens: „Wir sind eine Change Agentur: Wir versuchen Menschen dabei zu untersützen ein für sie positiveres soziales Verhalten zu erreichen.“ Service Design wird also bei Uscreates als Werkzeug (Means) genutzt um:

• Menschen besser zu verstehen,
• (Verhaltens-)Muster zu erkennen,
• bestehende Dienstleistungen für Betroffene zu Analysieren,
• mit Betroffenen diese Dienstleistungen zu besprechen und
• neue/adaptierte Dienstleistungen durch die Betroffenen zu entwickeln.

Sie stellen dies in ihrem Prozessvorgehen so dar:

(C) Uscreates: Prozessframework

Wir diskutieren noch einige Fallbeispiele durch (siehe: http://www.uscreates.com/case_studies) und ich stelle fest, dass die Datensammlungsmethoden wirklich innovativ sind. Es werden u.a. Videos zum Datensammeln gemacht, vor Ort direkt oder durch die Betroffenen selbst, es werden Betroffene durch Betroffene gesucht und eingebunden und es wird viel Wert darauf gelegt, offene Meinungen von Menschen zu bekommen und dabei wird mit Respekt, Demut (vor dem Thema und den Betroffenen), Empathie und Sorgfalt vorgegangen. Man spricht nicht von Kunden sondern von „audience“. Und in jedem Prozessschritt lese ich das kleine Wort „co-“ (Co-scope/co-develop/etc…)

Meine ersten Erkenntnisse für den ersten Tag nach dem Gespräch:

• Guide on the Side: Service Design wie Uscreates es lebt bedeutet, dass der Service Designer rein ein Begleiter der betroffenen Menschen ist. „The service is developed and owned by the audience“ höre ich immer wieder. Das Entwicklungsteam versucht zuerst sehr genau zu verstehen, was das Problem ist, nähert sich dem Thema auf einer empathischen Weise und schafft es, Informationen über das Leben der Betroffenen zu gewinnen durch die einzige brauchbare Quelle: Die betroffenen Menschen selbst.
• Only qualitative Data is real Data: Natürlich werden teilweise Quantifizierungsmethoden genutzt um Informationen zu erheben. Aber ich merke, damit ist hier bei Uscreates niemand so richtig glücklich. Viel mehr werden qualitative Erhebungsmethoden genutzt die ich (als Techniker) noch nie zuvor erlebt oder gesehen habe (Kleinstädter…). Ich erfahre von der „Rant-Box(tm)“: Um junge Menschen zu erreichen fährt das Team zu crowdy places (Shopping Malls) und baut dort die sogenannte „Suderkiste“ auf. Das ist eine Box im Ausmaß von 3x3x3m mit Couches drinnen und hier kann jeder drauflosschimpfen und drauflosplaudern wie er will. Das Ganze wird gefilmt für eine spätere Auswertung. Die Idee dahinter: Die Box schafft einen abgeschlossenen Raum um ungestörter die Zielgruppe zu interview und schaut cool aus. Und der Name ist Programm: RANT! (Schimpfen/Nörgeln/Sudern). Ich denken, dass wir in Österreich als tlw. „nörgleraffine“ Bevölkerung die Box sprengen würden (das ist eine Selbsteinschätzung und bitte keine Verallgemeinerung :-)).
• Co-Whatsoever Principle: Daten mit den betroffenen Menschen gemeinsam erheben bzw. durch die betroffenen Menschen erheben lassen und dabei respektvoll und ehrlich miteinander umgehen. Nur diese Menschen wissen genau, was sie bewegt und wie man ihnen helfen kann. Also: Zuhören und lernen!
• Stay agile in your process: Auf die Frage, wie das Prozessmodell und die Prozessschritte geplant werden kommt ein irritiertes Lächeln: „We have a good framework and the rest is rather intuitive and experience.“ Aaargh: Ich hätte gerne sowas gehört wie: „Ja, wir machen eine Mustererkennung der Problemstellung und daraufhin spuckt uns unsere BI das optimierte Prozessvorgehen mit den dahinterliegenden Methoden und Werkzeuge aus.“ Was natürlich völliger Blödsinn ist: Menschen sind nicht-deterministische Systeme (Annahme und Empirik :-)) und daher gibt es sowas wie den perfekten Pfad in der Entwicklung nicht. Bei Uscreates kommt es immer wieder zu Überraschungen, dass manche Co-Scope Methoden besser bzw. schlechter funktionieren. Hier muss man dann schleunigst umstellen und nicht festhalten an irgendwelchen Vorgaben oder Prozesshandbüchern (das habe ich mich gar nicht fragen getraut: „Habts ein Prozesshandbuch?“ – ich wäre wahrscheinlich ausgelacht worden und hätte kein Bier am Abend bekommen…).
• Interdisciplinarity leads the Team: Die Mannschaft besteht aus Menschen die aus wirklich unterschiedlichen Systemwelten kommen (Journalismus, Soziologie, etc.) und alle haben unterschiedliche weitere Betätigungsfelder (Töpfern, Kunst..) zusätzlich sind in dem Team zumindest 4 Nationalitäten vertreten (Schweden, Libanon, etc.). Hier kann man wirklich von „Think outside the box“ sprechen (auch wenn Mary mir gesagt, hat, dass der Spruch eher eine Belustigungsphrase hier in London ist). Und ja: Auf Grund der Unterschiedlichkeit habe ich gesehen, wie respektvoll und wertschätzend miteinander umgegangen wird. (Gender und Diversity Management braucht es hier nicht, das wird einfach gelebt…).

Tag 2: Job-Shadowing at Uscreates/Diskussion zum Thema Service Engineering vs Service Design

Ich beobachte den open-workspace hier und merke, dass in einem Kreativteam wie diesem hier ein „cave-dwelling“ in Einzelbüros gar nicht möglich ist. Das ist für die Leute hier sogar „unnatürlich“. Die Wände werden genutzt um die gewonnen Daten aus dem Co-Scope aufzubereiten und um Muster (patterns) zu erkennen. Da ist es natürlich sehr wichtig, dass man ein interdisziplinäres Team hat, denn das Erkennen von Verhaltensmuster ist eine spannende und herausfordernde Angelegenheit (denk ich mir, bin ja kein Experte in diesen Sachen, kenne den Begriff „Patterns“ nur aus der Software Welt).

Die Uscreates MitarbeiterInnen sind permanent unterwegs. Es ist ein „Kommen und Gehen“, aber die Hauptarbeit wird bei der „audience“ erledigt. Ich höre Diskussionen über die Notwendigkeit des Büros (…“eigentlich brauchen wir das Büro nicht, wir sind ja ohnehin immer unterwegs“). Dennoch merke ich, dass eine „homebase“ von den MitarbeiterInnen hier als wichtig und notwendig empfunden wird.

Bei der Vorbereitung auf mein Referat für Studierende des London College of Communication überlege ich mir, wie und was ich zum Service Engineering sagen kann. Mir ist der Diskurs wichtig, denn ich will ja lernen und daher entscheide ich mich zu einem klischeehaften Ansatz: Wir Techniker lösen Probleme und quantifizieren, ihr Nicht-Techniker wollt das Problem „verstehen“ und dann beschreiben.

Referat: Es ist nett zu beobachten, wie man in einer technikfremden Welt mit Begriffen wie UML, SysML, Datamining, BI etc. Eindruck schinden kann :-). Prozessvorgehen mit klarer Struktur schüchtern auch ein, stelle ich fest. In der anschließenden Diskussion erfahre ich durch die anwesende Professorin etwas spannendes: In England wurde im Rahmen der Industrialisierung bereits sehr früh eine „Gegenbewegung“ mitentwickelt um der Technologisierung einen Ausgleich zu geben. Es wurde das Thema Design (im Sinne von Kunst und nicht Konstruktion) gefördert. Wahrscheinlich sind die Ursprünge des Industrial Design dort entstanden?

Wie auch immer, wir kommen nach einer spannenden Diskussion zu folgendem Ergebnis: Die „Disziplinen“ (Service Engineering/Service Design) können, mussen und sollen sich austauschen! In einer komplexen Welt mit komplexen Problemen braucht es ganzheitliche Lösungskonzepte. Die Herausforderung liegt aber sicher darin, ein entsprechend interdisziplinares Team zu leiten und Ergebnisse zu produzieren.

Meine Erkenntnisse nach dem zweiten Tag:

• Opposite attracts : Das ist also ein uralter Hut die Sache mit dem Service Engineering vs Service Design! Durch ein intelligentes Zusammenführen von Menschen in ein interdisziplinares Team schafft man sicher spannende und gute Entwicklungen in dem Umfeld. Ich erinnere mich an eine PPT die mir mein Boss weitergeleitet hat von einem Vortrag den er von Jim Spohrer (IBM) gehört hat: Hier werden unzählige (Wissenschafts-)Disziplinen aufgezählt und einem Problemmuster gegenübergestellt. IBM versucht nun entsprechend der Aufgabenstellung die notwendigen Disziplinen in der Matrix herauszuleiten.
• „road warrior“ : Ich bin mir klar darüber, dass das ein wenig martialisch klingt und auch eher den klassischen ITler bezeichnet, der über Internet von Unterwegs seine Kunden serviciert. Aber: Das Geschäftsmodell bei Uscreates ist so aufgebaut, dass 80% der Arbeit beim /mit dem Kunden passiert und Eigenleistung (Konzepte usw.) beinhaltet. 20% werden in Teamarbeit erarbeitet (Abstimmungen etc.). Daher möchte ich den Begriff auch in adaptierter Weise nutzen im Sinne von: Immer auf Achse sein, der Ort der Arbeit ist nicht primär im Office. (Vielleicht fällt mir noch was besseres ein aber ich lass das mal so stehen.)

Tag 3: Job-Shadowing at Uscreates

Es geht weiter mit dem Job-shadowing. Ich stelle fest, dass Uscreates jede Woche einen potentiellen Kooperationspartner einlädt zu einem gegenseitigen Kennenlernen. Dabei stellt der „Kandidat“ (meist sind dies Firmen oder Organisationen) das Leistungsspektrum aber auch den Unternehmenszweck genau dar. Ich konnte das „Forum for the Future“ (FFTF) dabei kennen lernen. Die haben ein interessantes Geschäftsmodell: Um den CO2 Ausstoss der Welt zu reduzieren erarbeiten sie mit großen Firmen (Levis, Nike, etc.) Szenarien die in diese Richtung gehen: „Stell Dir vor, Wasser als Rohstoff ist in 10 Jahren doppelt so teuer wie jetzt. Was bedeutet das für dein Business?“. Wo zuerst noch großes Kopfschütteln und ein Belächeln war, setzen nun immer mehr Firmen auf diese Szenarien. Und das Ergebnis ist immer super-innovativ: Mit weniger Rohstoffen (=weniger CO2) dennoch das Geschäftmodell führen. Eventuell die eine oder andere ergänzende Dienstleistung mitanbieten um so weiterhin im Markt bleiben zu können.

Auf alle Fälle kommt eine spannende Diskussion mit dem Uscreates Team zu stande. Schnell und ganz offen wird über Schnittpunkte zwischen FFTF und Uscreates geplaudert. Mir fällt auf, das habe ich schon wo gelesen, dass das wichtig ist: Kernkompetenzen bündeln und Kooperationspartner für die Bildung virtueller Organisationen finden. Bei Alexander Zobel (2005) wird das (unter anderem) explizit als wichtiger Faktor für eine agile Unternehmensführung aufgezeigt. Weiters beschreibt Zobel (2005) den Faktor „Bereicherung des Kunden“ als wesentlich. Ja und das beherrscht uscreates wie kaum ein anderes Unternehmen, da der Kunde (audience) sich selbst seine Dienstleistung entwickelt.
Spannend: Je mehr ich hier sehe, desto mehr erkenne ich ein agiles Muster in der Art und Weise wie Uscreates funktioniert. Und die Agilität ist eine gewachsene und nicht bewußt erzwungene Eigenschaft, denn das Wort Agilität kennt man hier auch nur als buzzword :-).

Meine Erkenntnisse nach dem dritten Tag:

• Agility is key: Ich sehe hier sehr viele Ansätze wie agile Werte, Strategien, Methoden und Werkzeuge gebündelt werden. Intuitiv und ohne viel Diskussion. Offensichtlich kann sich agiles Verhalten „natürlich“ ergeben.

Tag 4: Interviews, Interviews, Interviews….

Am Tag vier startet der Interviewteil meines Aufenthalts: Ich besuche Joe Heapy (Founder and Director of Engine – http://www.enginegroup.co.uk/). Vorweg: Ein toller, netter und superkreativer Mensch. Obwohl Joe immer eingespannt ist, nimmt er sich 1 H Zeit um mit mir locker über den Service Design Ansatz von Engine zu sprechen. Ich habe das Interview aufgenommen und werte noch alles aus, aber vorweg kann ich schon meine Eindrücke zusammenfassen.
Bei Engine gibt es auch keine „starren“ Prozesse sondern ein Prozessframework (wobei der Begriff „Prozess“ auch nicht wirklich verwendet wird). Auch hier zählt Flexibilität zu einem wichtigen Element in der Entwicklung. Auf meine Frage, wie die Prozessschritte bei der Entwicklung aussehen bekomme ich wieder ein fast mitleidiges Lächeln (das bekomme ich überhaupt öfters in der Service Design „Commnity“). Service Design wird von Joe wie folgt definiert: „[…] [it] is about understanding needs, being sensitive, is about to understand what it is to be a person, a human. Is very much the person first and the technology second. Is about knowing how to understand people […]“ (Heapy 2011)
Joe spricht auch von Geschäftsmodellen (und da natürlich vom Businessmodelgeneration nach Osterwalder und Pigneur). Ich sehe, dass Engine mehr im Industriesektor arbeitet und auch für Organisationen wie die BBC. Aber deren Fokus ist nicht wie bei Uscreates das Thema „Behaviour Change“ sondern tatsächlich, wie man Services für Geschäftsmodelle der jeweiligen Firmen konstruiert. Design wird hier auch eher als Konstruktion und nicht im Sinne von „künstlerischem Agieren“ verstanden.
Aber, und das finde ich wiederum interessant, im Sinne der generischen Prozessschritte bei der Dienstleistungsentwicklung (Service Creation – Service Design -Service Management – Vgl. dazu Bullinger et al. (2006)) ist Engine sehr oft rein in den Phasen Service Creation und Service Design unterwegs. Service Management liegt nicht im Kernkompetenzbereich des Unternehmens. Das muss das Unternehmen, für das Engine ein Service entwickelt und umbaut selbst übernehmen. Ich hoffe, dass ich nicht zu lange brauche um mein Interview auszuwerten, aber wenn ich es habe, werde ich es online stellen.

Am Nachmittag besuche ich mit Mary (…schneller! Wir erreichen diese U-Bahn noch!!...) die City University of London. Ich treffe Dr. Sarah Jones und sie zeigt mir das HCI Labor: Co-Design mit Hilfe von IT Werkzeugen, da bin ich natürlich interessiert. Ich finde es spannend, dass hier auch nicht nur die technische Seite untersucht wird, sondern vor allem der psychologische Aspekt wie mit Medien gearbeitet wird und wie Menschen mit diesen Interagieren ohne die Kreativität zu verlieren.

Meine Erkenntnisse nach dem vierten Tag:

• Service Design is a niche: Wirklich große Aufträge mit großem Budget sind in der Service Design Branche nicht drinnen. Bei unserem Service Engineering Expertenworkshop am Vormittagd des 28.4.2011 hat Dr. Meiren von Fraunhofer IAO analysiert, dass Service Engineering bzw. Service Development nicht das high-selling Thema ist wie zB CRM. Bei CRM ist jede Firma auf den „Zug“ aufgesprungen. Es wird in dem Themenfeld zwar ein stetes aber auch langsames Wachstum geben.
  Ich sehe auch hier in London, dass mit Service Design als Innovationsthema in einer Nische gut zu arbeiten ist, aber wenn der globale Markt einbricht, dann geben die großen Player auch kein Geld für Service Entwicklung aus, sondern investieren wo anders. Das scheint auch der Grund zu sein, für das Schrumpfen diverser Service Design Firmen in London nach der 2008er Krise.
• One mind – one community: Ich sehe aber auch, dass in der Grundüberzeugung die Service Design Community gleich denkt: Human centered approach is mandatory. Und das mit voller Überzeugung.

Tag 5: Interview und Referat zum Thema Smart Services

Letzter Tag und ich fühle mich schon ein wenig „abgefeuert“. Mein letzter Firmenbesuch ist bei Live|work und dazu marschiere ich in der Früh durch den financial district (marschieren? Eher laufen…). Ich treffen mich mit Ben Reason, dem Director von Live|work auf ein Interview.
Vorweg: Ben ist gleich wie Joe ein sehr sympathischer, kreativer und freundlicher Mensch. Ich bin sehr dankbar, dass er mir eine Stunde Zeit geschenkt hat. Auch hier muss ich das aufgenommene Interview noch auswerten, aber einiges kann ich schon zusammenfassend darstellen:
Das Unternehmen ist auch in Norwegen tätig. Ben erzählt mir, dass live|work u.a. für die Norwegische Bahn die Service Prozesse verbessert. Wieder diskutiere ich über Prozesse und den Begriff Service Design und wie er von Ben interpretiert wird.
Prozesse: Live|work hat ein Framework wo im ersten Schritt User insight gewonnen wird, dann die user needs identifiziert werden und dann kommt schon das schnelle prototyping. „we look in peoples lives, behaviours to see what options are there [to develop services].„(Reason 2011)
Ben erzählt, dass er viel mit großen Software Firmen zusammenarbeitet. IT ist auch hier der enabler für innovative Services und das (software) engineering wird ausgelagert. Aber die vorgelagerte Innovationsleistung wird von live|work erbracht. Dabei nutzt live|work auch Methoden wie ethnographische Studien und Customer Journey maps usw.
Als wesentliche Kernkompetenz von live|work sieht Ben die Fähigkeit, die Value Proposition der (per se) nicht tangiblen Services für die Unternehmen zu schärfen und zu definieren.

Am Nachmittag halte ich mein zweites Referat, diesmal über Smart Services (Allmendinger 2005) und Agilität bzw. die Ermöglichung von agilem Verhalten durch den Einsatz von Smart Services. Wieder vor Nicht-TechnikerInnen (StudentInnen aus dem Service Design Bereich). Ich sehe, dass das Thema kaum auf Interesse stößt. Eher schon das Smart Service Konzept (Daten sammeln, auswerten und proaktive Services anbieten). Es geistert gerade die Geschichte mit dem Datenklau rund um die Sony Playstation durch die Medien und das heizt hier erfreulicherweise die Diskussion an. Die Leute teilen mit mir die Einschätztung, dass das Smart Service Konzept kommt bzw. sich schon eingeschlichen hat in alle möglichen Bereiche unseres Lebens. Und im nächsten Moment wird schon darüber nachgedacht, wie Service Design diese Konzept „menschlicher“ machen kann. Mich überrascht das nicht mehr, denn anstatt Furcht und Angst und Ablehnung darzustellen, kommen die Leute hier mit positiven Gedanken und Ideen.

Meine Erkenntnisse nach dem fünften Tag:

• Service Design is positive thinking: Nach dem Plaudern mit allen Menschen, nach dem Besuch von drei Service Design Firmen und dem kennen lernen von einigen Fallstudien kann ich eines sagen: Diese Menschen machen ihren Job mit Freude und Begeisterung und sind sehr (sehr!!) positiv im Denken. Wann immer ich ein Problem aufgebracht habe oder angesprochen habe, wurde sofort geantwortet: Das wäre doch eine spannende und interessante Sache hier was tolles zu designen!

Und damit schließe ich auch meinen Bericht und danke nochmals dem gesamten Uscreates Team und allen tollen Menschen die ich in London interviewen durfte, dass ich als Kleinstädter und Schablonendenker die Möglichkeit bekommen habe, zu lernen, wie man ein wenig „outside the box“ denken kann 🙂

Quellen:

Allmendinger, Glen und Lombreglia, Ralph. 2005. Four Strategies for the Age of Smart Services. Harvard Business Review. October, 2005. reprint R0510j.
Bullinger, Hans-Jörg und Scheer, August-Willhelm, [Hrsg.]. 2006. Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen. Zweite, vollständig überarbeitete und erweiterte Auflage. Berlin, Heidelberg, New York : Springer, 2006. ISBN-13 978-3-540-25324-2.
Heapy, Joe. 2011. Interview. London : Engine. 12.05.2011
Reason, Ben. 2011. Interview. London : live|work. 13.05.2011
Zobel, Alexander. 2005. Agilität im dynamischen Wettbewerb – Basisfähigkeit zur Bewältigung ökonomischer Turbolenzen. 1. Auflage. Wiesbaden : Deutscher Universitätsverlag/GWV Fachberlag GmbH, 2005. ISBN: 3-8244-0846-5.