Wie kann mit Design Thinking ein hochkomplexer IT-Prototyp in wenigen Wochen entwickelt werden, um umfangreiche Prozessoptimierungen oder sogar eine komplette Customer Journey abzubilden? Wie wird dieser Prototyp konkret entwickelt, wie muss ein Entwicklerteam aussehen und welche Spielregeln gelten, um das Ziel zu erreichen?
Zielsetzung
Design Thinking kann als offene Methode eingesetzt werden, um Innovationen zu erzeugen, doch wir werden als Berater oftmals damit beauftragt, konkrete Lösungen zu erzeugen. Definierte Budgets, Zeitvorgaben und Erwartungshaltungen stehen im Raum. Ist es möglich, mit diesen Eckdaten Design Thinking anzuwenden? Meine persönliche Erfahrung: Ja, das funktioniert. Allerdings gelten spezielle Spielregeln.
Die Spielregeln
Ein spezielles Setting ist notwendig, um die definierten Ziele zu erreichen, auf das sich Berater und Kunde gleichsam einlassen müssen. Die Eckdaten
- Erarbeitung einer gemeinsamen Zielsetzung
- Kernkompetenzen fusionieren
- Neues wagen
- Gesteuerte Produktion
In einem ersten Schritt werden die gemeinsamen Ziele festgelegt. Es ist auch möglich, eine multiple Zielstruktur auszuarbeiten mit bis zu fünf oder sechs Zielen. Wahrscheinlich werden diese im Projektverlauf verjüngt, doch Kostenreduktion, Performance und Kundenerlebnis können dabei auf der Zielmatrix stehen.
Die Kernkompetenzen setzen sich aus unterschiedlichen Disziplinen zusammen. Tiefe Erfahrung und Branchenexpertise sind die erste Zutat. Zweitens Methodenkompetenz und Moderationsexpertise und drittens IT-Umsetzungs-Know-how, also Programmierung/Coding von Lösungen. Repräsentiert werden die Kompetenzen durch Kunde, Berater und „Agentur/IT-Leute“.
Im Team ist es für den Kunden, also denjenigen, der das Ziel erreichen will, am wichtigsten, Leute an Board zu holen, die ihr Geschäft in- und auswendig wie ihre eigene Westentasche kennen. Die Teammitglieder (Mitarbeiter/Angestelllte) müssen trotz der Expertise in der Lage sein, komplett neue Wege und Lösungen unter Anleitung der Moderation zu denken, Regeln zu verletzen und auf „Wasser zu gehen“, was ja eigentlich nicht geht.
Die IT-Leute/Agentur braucht eigentlich nicht unbedingt am Projektstandort zugegen sein, weil Lösungen in Apps und Screens in virtuellen Teams erzeugt werden können. Video-Conferencing, Telefonate und Plattformen reichen völlig aus. Am besten ist es, wenn Lösungen über Nacht produziert werden, die am Tag zuvor besprochen wurden.
Mit diesem Ansatz konnten Design Thinking-Ansätze hervorragend genutzt werden, um Lösungen in hochkomplexen Prozessumfeldern zu erzeugen, konkret abgebildet in IT-Mock-ups, um Investitionsentscheidungen für „echte Lösungen“ treffen zu können. Nichts begeistert einen Vorstand mehr, als eine konkrete Lösung. Das ist besser, als eine PowerPoint, besser als die Idee, besser als die Strategie. Eine konkrete Lösung macht transparent, was wirklich machbar ist.
Drei Nutzen-Aspekte von Software-Prototyping
- Erlebnis von Kernfunktionen
Zuerst einmal können potenzielle Anwender via „Look & Feel“ erleben, wie die zukünftige Lösung wirklich aussieht. Das ist verständlich und kann sofort auf aktuelle Aufgabenstellungen übertragen werden. Kernfunktionalitäten werden erlebt. Auf dieser Basis ist ein erstes Feed-back möglich.
- Missverständnisse vermeiden
Ein Typischer Fall in der Kommunikation: Sender und Empfänger kommunizieren durch die Wolke von Störungen. Die Botschaft wird unscharf und das Ergebnis weicht möglicherweise vom Ziel ab. Mit einem Prototyp können viele Missverständnisse vor der ersten „echten“ Entwicklung vermieden werden .
- Akzeptanz absichern
Wie enttäuschend für alle Beteiligten, wenn die Lösung am Ziel vorbei entwickelt wurde. Mit einem Prototypen können alle Beteiligten einen ersten echten Eindruck gewinnen und frühzeitig Fehlentwicklungen vermeiden. Das spart Kosten, Zeit und auch Nerven.