0

Service-Design-Sprint

Von der Anforderung zum Grobkonzept in vier Tagen? Wie klingt das für Dich? Diese Idee möchte ich heute mit Dir teilen und bin gespannt auf Dein Feedback!

Folgendes beobachte ich immer wieder bei manch Kunden: Der Betrieb funktioniert gut, das Beheben von Störungen in der Regel auch. Insgesamt bekommen wir für das Operative meist gute Noten.

Problematisch wird es, wenn es um neue Anforderungen geht. Die IT wirft dem Fachbereich vor, dass er nicht weiß, was er will und der Fachbereich regt sich darüber auf, dass alles so lange dauert und die IT gar nicht weiß, worum es wirklich geht. Ohne, dass der Fachbereich definiert, was er haben will, wird das eh nichts und seine Prozesse muss er auch erstmal sauber bekommen.

Kommt Dir das bekannt vor? Habe ich gerade diese Woche wieder erlebt.

Klar, ich übertreibe (vielleicht) ein bisschen.

Betrieb ist nur ein Teil

Das Grundproblem dahinter ist, dass sich ganz viele IT-Abteilungen fragen, wie sie die ganzen Aufgaben erledigen sollen und dann kommt auch noch die Digitalisierung um die Ecke. Dazu kommt dann meist noch, dass vor allem technische Skills für den Betrieb vorhanden und andere Fähigkeiten nur schwach oder gar nicht ausgeprägt sind. Das ist ein großes Problem – insbesondere, wenn es darum geht, neue Anforderungen aufzunehmen und zu einer sinnvollen Lösung zu führen.

Ähnliches gilt auch für Deine Fachbereiche: Die Mitarbeiter sind stark ausgelastet und die Kenntnis über die Prozesse ist nicht immer so vorhanden, wie es notwendig wäre.

Das Ergebnis: Gerade die Aufnahme und Definition der Anforderungen zieht sich. Danach dauert es, bis Du die notwendigen Experten IT-intern für eine Lösungsdiskussion zusammenbekommst. Bis sich der Kunde entscheidet, vergehen wieder Wochen und dann ist meist nicht absehbar, wann denn dieses Projekt noch umgesetzt werden soll.

Fokussierung & Konzentration

Genau darum dreht sich meine Idee. Das einzige, was aus meine Sicht hier hilft, ist Fokussierung, Konzentration auf das Wesentliche und Entscheidungsfreude.

Ich nenne die Idee mal Service-Design-Sprint. Inspiriert bin ich durch das Design Sprint Konzept, welches von Google entwickelt wurde. Ich habe in den letzten Wochen viel darüber gehört und gelesen. Dabei immer die Frage, wie wir das Konzept anwenden können.

Also, lass uns starten:

Ein Design-Sprint ist ein vier- bis fünftägiger strukturierte Prozess, der mit einem Mix aus Gruppe- und Einzelarbeit von konkreten Fragen, über Ideen, Prototypen und Tests zu einem greifbaren und innovativen Ergebnis führt.

An erster Stelle steht in einem Design-Sprint die Definition des Sprint-Zieles. Adaptiere ich das Vorgehen auf Service-Management und nehme die oben genannte Gemengelage als Ausgangssituation, dann komm ich zu folgendem Ziel:

Das Ziel eines Service-Design-Sprint ist, die Erarbeitung eines Grobkonzeptes für einen neuen Service oder die Weiterentwicklung eines bestehenden Service sowie die Entscheidung ob und wie der Service angeboten wird.

Einfach übersetzt: Eine gewisse Anzahl von Menschen konzentriert sich vier oder fünf Tage ausschließlich auf dieses eine Ziel. Dabei durchläuft das Team verschiedene Phasen.

Als Rahmen für den gesamten Ablauf nehmen wir die IT-Service-Canvas. Diese enthält für jeden Punkt, den wir bearbeiten dürfen, ein Feld. Dort können wir die wichtigsten Erkenntnisse festhalten und entsprechend den Fortschritt visualisieren.

 

Hol Dir jetzt kostenlos die IT-Service-Canvas:

 

Tag 1 – Verstehen.

Im ersten Teil des Tages geht es darum, das das Team versteht, was die Kunden und Nutzer für Probleme und Wünsche haben. Wir können dazu verschiedene Techniken anwenden. Eine Möglichkeit ist beispielsweise Job Shadowing. Wir begleiten für ein bis zwei Stunden Mitarbeiter und beobachten was sie und wie sie etwas tun. Wir notieren, was wir dabei herausfinden, zum Beispiel wo Potential für Verbesserung oder wo Schwierigkeiten liegen. Diese Erkenntnisse tragen wir nachher zusammen und bekommen so ein Bild von der aktuellen Situation und der vor uns liegenden Aufgabe. Das funktioniert insbesondere, wenn es sich um die Weiterentwicklung oder Verbesserung eines bestehenden Service handelt.

Eine zweite Möglichkeit ist die Arbeit mit den „Lightning Talks“. Mitarbeiter, Betroffene oder andere Stakeholder erzählen über die Situation, was getan werden soll und warum das wichtig ist und wie das den Mitarbeiter und das Unternehmen beeinflusst. Es geht dabei wirklich um das Erzählen. Wir hören zu, machen Notizen und stellen Fragen. Wir gehen den Dingen auf den Grund und fragen immer wieder nach dem Warum. Wir wollen den Punkten auf den Grund gehen und fragen gern fünfmal Warum.

Aus diesen Lightning Talks nehmen wir ganz viel mit:

• Wer sind die ganzen Stakeholder?
• Was sind die Ziele, Probleme und Wünschen? Also die wirklichen.
• Was versprechen sich die Menschen?
• Welchen Nutzen haben die Menschen und das Unternehmen?

Wir sammeln ganz viele Informationen zu den Feldern Geschäftsprozesse, Nutzer, Nutzen und auch Service Level.

Im zweiten Teil des Tages beschäftigen wir uns mit der Erarbeitung ganz konkreter Anforderungen an den Service. Ich würde dafür ungefähr zwei Drittel des ersten Tages investieren. Je nachdem mit wie vielen Stakeholdern ich es zu tun habe, kommen dabei unterschiedliche Werkzeuge zum Einsatz: Anforderungsworkshops oder persönliche Interviews zum Beispiel.

In der Regel brauchst Du nicht viele Interview-Partner, um den größten Teil der Anforderungen zu ergründen. Drei bis fünf Menschen in 60 bis 90 Minuten langen Interviews. Je nach Teamgröße kannst Du diese parallel führen.

Aller Erkenntnisse werden zusammengefasst und gesammelt.

Das Team

An der Stelle möchte ich etwas zum Team sagen. Das Team umfasst 4 bis 9 Menschen. Je nach Umfang und wie parallel Du im zweiten Teil des Tages arbeiten möchtest. Es kann für eine Aufgabe auch mehrere Teams geben.

Wir brauchen verschiedene Rollen:

• Wir brauchen einen Entscheider – gerade am ersten Tag muss jemand entscheiden, was ist alles Teil dessen, was am zweiten Tag weiter betrachtet werden soll. Gehen wir offen an das Thema ran, wird der Problemraum riesig. Da braucht es Entscheidungen, die auch nach dem Sprint bestand haben werden.
• Wir brauchen Betroffene – Menschen, die den Service später nutzen werden. Die wollen wir einbinden und deren Kontextwissen nutzen.
• Wir brauchen einen Service Owner – der darf ebenfalls so früh wie möglich involviert sein. Dann kann er zukünftig seiner Rolle vollumfänglich gerecht werden.
• Wir brauchen Wissende – Die brauchen wir auf verschiedenen Ebenen: Einmal Wissende in Bezug auf das Fachliche, Wissende in Bezug auf das vorhandene Service-Portfolio und Wissende, was in der Umsetzung alles möglich ist. Einige dürfen die ganze Zeit dabei sein, andere kommen dazu, wenn sie benötigt werden.
• Wir brauchen Bedenkenträger – die kommen früher oder später eh um die Ecke, also lass sie uns gleich am Anfang einbinden
• Wir brauchen Macher – sonst wird das nichts mit dem Prototypen, wenn alle nur Papier schwarz machen wollen.
• Wir brauchen einen Moderator – der Prozess muss ganz eng geführt werden, denn wir wollen in vier oder fünf Tagen ein Grobkonzept fertig habe. Der Moderator ist verantwortlich, dass wir das erreichen.

Am Ende des ersten Tages wissen wir worum es geht, was die Menschen wie brauchen und warum sie es brauchen.

Tag 2 – Ideen sammeln und Lösungen beschreiben

Am zweiten Tage gehen wir in den Lösungsraum. Wir schauen uns ganz konkret an, wie sich die Anforderungen umsetzen lassen und wie wir die Ziele erreichen können. Dazu werden Lösungsvarianten entwickelt und deren Umsetzung soweit skizziert, dass wir auch etwas über die Kosten sagen können.

Es geht konkret um die Felder Architektur, Menschen, Produktion, Lieferanten und Kosten der IT-Service-Canvas. Mit der IT-Service-Canvas kannst Du den gesamten Prozess der Service-Erstellung visualisieren. Diese gilt es zu füllen.

Zum Start des Tages wird der Lösungsraum so weit wie möglich aufgemacht. Wir dürfen auch Lösungen in den Blick nehmen, die nicht IT sind. Es ist unter Umständen notwendig, dass wir eine kurze Recherche-Phase einlegen oder vielleicht noch zusätzlich Experten dazu holen müssen. Ziel ist, dass sinnvolle Ideen entstehen. Sind die Ideen da, könnt Ihr diese beispielsweise mit der Disney-Methode hinterfragen und so abklären, wie weit die Idee trägt.

Spätestens am Mittag kommt dann der Entscheider wieder ins Spiel: Dieser muss festlegen, an welchen maximal drei Idee nun weitergearbeitet wird. Danach beginnt die Fleißarbeit – das Grobkonzept für den Service ist mit all seinen Punkten zu erarbeiten. Auch da lohnt es sich, das Team in kleinere Teams zu teilen und so parallel zu arbeiten. Natürlich kannst Du ohne eine Service-Architektur und die Entscheidung zu Lieferanten keine Kosten ermitteln.

In der Phase gibt es sicher auch wieder Entscheidungen zu treffen – da ist es wichtig, dass der Entscheider wieder mit dabei ist.

Je nachdem, wie umfangreich Dein Vorhaben ist, kann es sein, dass Du den dritten Tag für das Grobkonzept brauchst. Wenn dem so ist, dann nutze diesen. Ich denke, dass mit ein wenig Übung im Erstellen eines Service-Grobkonzept, das alles an einem Tag möglich ist.

Tag 3 – Prototyp bauen

Am dritten Tag wird es endlich kreativ. Wir bauen den Prototyp. Ich glaube, dass wird beim ersten Mal der schwierigste Part. Deswegen brauchen wir den Macher, der einfach mal los legt.

Den Prototyp brauchen wir am vierten Tag, um das Ergebnis mit dem Kunden und den Nutzern zu testen. Wir wollen daraus lernen und den Service dann im Feinkonzept noch besser zu machen.

Was ist der Prototyp? Das kommt ein wenig auf die konkreten Anforderungen an. Hast Du beispielsweise einen Service, der über ein Handheld bedient wird, dann würde ich den mit realistischer Größe und Gewicht bauen. Holz dafür gibt es im Baumarkt. Die Screens oder Wireframes können dann gemalt werden und werden einfach auf dem Prototypen aufgelegt. Du kannst ganz verschiedene Methoden Nutzen: Skizzen und Diagramme, Service Blueprint, Customer Journey, Wireframes oder Papierinterfaces, Rollenspiel oder Lego-Prototypen.

Klar können auch am dritten Tag zum Start Ideen entwickelt werden, wie der Prototyp gebaut werden soll, was getestet werden soll. Die Frage ist: Was wollen wir konkret herausfinden – dazu muss der Prototyp passen. Dafür dürfen wir uns etwas Zeit nehmen – der Entscheider legt fest, an was dann den Rest des Tages gearbeitet wird.

Der dritte Tag kann schon mal länger dauern. Und vergiss bitte nicht, den Preis für den neuen Service zu ermitteln! Dann ist die IT-Service-Canvas vollständig!

Tag 4 – Testen und Lernen

Jetzt wird es ernst – der erste Praxischeck. Wir präsentieren unseren Service, unseren Prototypen und den Preis.

Mit den Tests finden wir die Schwachstellen in unserem Grobkonzept. Gleichzeitig sichern wir uns mit den Tests gegen massive Fehlinvestitionen ab, da die kritischsten Annahmen hinterfragt und getestet werden.

Wir nehmen Nutzer aus der Zielgruppe und präsentieren ihnen den Prototypen, beobachten sie und lassen uns von ihnen laut ihr Gedanken mitteilen, während sie den Prototypen testen. Oder wir führen Interviews zum Prototypen. Ganz wichtig: Die Führung in den Tests sollte jemand übernehmen, der nicht in die Lösungsfindung und den Prototypen involviert war. Der versucht den Testkandidaten nicht von der Lösung zu überzeugen.

Gegenüber dem Entscheider aus dem Business wird der Nutzen, Leistungsumfang und die Abdeckung der Anforderungen präsentiert. Der entscheidet, ob der Service den Preis auch wert ist. Du bekommst konkretes Feedback, ob die Lösung taugt oder nicht.

Im Vorfeld dürfen wir uns natürlich Gedanken machen, was wollen wir rausfinden. Wie finden wir das raus. Und wir müssen uns damit beschäftigen, wie wir die Ergebnisse auswerten.

Fünf Probanden sind völlig ausreichend.

Die Ergebnisse des Tests nehmen wir und nutzen dies als Input, um die Feinkonzeptphase zu starten. Natürlich mach wir das nur, wenn es positives Feedback und eine Go vom Entscheider in der Fachabteilung – unserem zukünftigen Kunden gibt.

Bekommen wir das Go nicht, gilt es zu entscheiden, wie wir damit umgehen. Verlängern wir den Sprint um einen Tag, um die Kritikpunkte auszuräumen oder die neu aufgetauchten Blickwinkel zu integrieren? Diese Möglichkeit dürfen wir schon im Vorfeld in Betracht ziehen und vordenken, wie wir damit umgehen.

Was hältst Du von der Idee? Für mich klingt es, als ob wir in vier oder fünf Tagen so viel schaffen können, wofür wir sonst Wochen oder Monate brauchen.

Es gibt auch einen Tag 0 – die Woche muss geplant und mit den ganzen Menschen terminiert werden. Es braucht eine Stakeholderanalyse an Tag 0. Alles, damit der Sprint sauber durchläuft. Ich empfehle Dir, fülle zusammen mit dem Kunden die erst drei Felder (Geschäftsprozess, Nutzer und Nutzen) in einer kurzen Session von maximal 45 Minuten aus. Dadurch bekommst Du einen ersten Überblick und identifizierst weitere Stakeholder sowie angrenzende Prozesse.

Nochmal die Frage: Was hältst Du von der Idee? Schreibe gern unten in die Kommentare.

Willst Du mit mir testen?

Ich möchte die Idee gern in der Praxis verproben. Wenn Du jetzt sagst, ich habe einen konkreten Fall im Kopf, da würde uns das total helfen, dann komm bitte auf mich zu. Lass uns drüber reden, ob und wie es funktionieren kann und wann wir es angehen wollen. Für den kommerziellen Aspekt habe ich auch eine ungewöhnliche Idee – daran soll es definitiv nicht scheitern. Schreib mir bitte an robert@different-thinking.de