Dem Innovationslebenszyklus folgen

Abgeschlossen

Tailwind Traders beschäftigt sich mit Fragen zu Innovationen, die sich auch auf viele andere Organisationen auswirken:

• Wie können wir Änderungsrate erhöhen, ohne das laufende Geschäft zu beeinträchtigen?
• Wie können wir entscheiden, wo Innovationen erforderlich sind und welche Änderungen implementiert werden müssen, um die geschäftliche Rendite dieser Innovationen zu maximieren?

Die Antwort auf beide Fragen lautet, dass Tailwind Traders Veränderungen in die Organisationskultur integrieren muss. Ein Grund, warum änderungsscheue Unternehmen häufig änderungsbedingte Ausfälle haben, liegt darin, dass diese Änderungen zu umfangreich und einschneidend sind. Die Änderungen sind in kontrollierten und realistischen Umgebungen schwer zu testen.

Wenn Prozesse eingerichtet werden, um häufig Änderungen einzuführen, sind diese Änderungen kleiner und mit geringeren Risiken verbunden. Beachten Sie, dass dieser Prozess nicht lediglich die Einführung bestimmter Tools oder Technologien umfasst. Sie erfordert eine Kultur, die Veränderungen fördert und Fehler akzeptiert.

Das Konzept der Akzeptanz von Fehlern erscheint möglicherweise widersprüchlich, ist aber für den Innovationszyklus von entscheidender Bedeutung. Wenn Menschen Angst haben zu scheitern, weil ihnen die Schuld an Fehlern gegeben wird, werden sie aufgrund dieser Angst wahrscheinlich keine neuen Ansätze zur Problemlösung verfolgen. Die gesamte Organisation ist dann eine Gefangene ihrer etablierten Praktiken.

Es ist möglich, eine Fail-Fast-Kultur zu etablieren, in der Mitarbeiter*innen dazu ermutigt werden, neue Methoden auszuprobieren. Sie haben die Möglichkeit, schnell die Richtung zu ändern, wenn sie nicht das erwartete Ergebnis erhalten, was zu einer vielfältigeren Innovationskultur beiträgt.

Hypothesenbasierte Innovation

Innovation könnte als hypothesenbasierter, iterativer Zyklus beschrieben werden. Sobald ein Problem erkannt wird, können eine oder mehrere Hypothesen formuliert werden, die möglicherweise die Grundursache erklären und zur Lösung führen. Die Definition des Problems selbst kann schwierig sein, weil sie messbar sein muss.

Beispielsweise ist die Problemdefinition „Kund*innen sind mit den Auswahlmöglichkeiten unserer Zahlungsplattform nicht zufrieden“ nicht messbar und daher schwer zu lösen. Wenn Sie das Problem als „23 Prozent der Kunden verlassen ihre Einkaufssitzung beim Auswählen der Zahlungsplattform“ definieren können, sind Sie in einer besseren Position, um den Erfolg einer möglichen Lösung zu messen.

Nachdem Sie ein Problem auf messbare Weise definiert haben, können Sie Hypothesen formulieren, die Kandidaten für die Beschreibung und Lösung des Problems sind. Eine Hypothese für Tailwind Traders könnte beispielsweise wie folgt lauten: „Das Hinzufügen von ContosoPay zu den von uns unterstützten Zahlungsplattformen würde die Kundenabwanderung auf der Zahlungsseite von 23 Prozent auf 10 Prozent verringern.“ Nun kann die Tauglichkeit der vorgeschlagenen Idee überprüft werden.

Hypothesen sollten sich darauf konzentrieren, Mehrwert für Kunden zu schaffen und ihre Erfahrung in ihren Interaktionen mit Ihrer Organisation zu verbessern. Das wird oft als Kundenempathie bezeichnet: Kund*innen in den Mittelpunkt Ihrer Innovation zu stellen und sich darauf zu konzentrieren, den Nutzen für die Kund*innen und für Sie selbst zu steigern.

Es gibt viele Möglichkeiten, eine Hypothese zu überprüfen, ohne Anwendungscode zu ändern. Kundenbefragungen und Marktforschung sind zwei Beispiele für wertvolle Informationsquellen, die helfen können, über die Gültigkeit einer Hypothese zu entscheiden. Wenn Sie diese Quellen überprüfen, können Sie Ihre Hypothesen qualifizieren und Hypothesen entwickeln, die sich mit größter Wahrscheinlichkeit als richtig erweisen und zu einem geschäftlichen Mehrwert beitragen.

Build

Sobald eine Hypothese über genügend Wertpotenzial verfügt, um in Ihre Anwendung integriert zu werden, beginnt der Erstellungsprozess. Auch hier ist Geschwindigkeit entscheidend.

Ihre Entwicklungssprints sollten so kurz wie möglich sein. Durch kurze Sprints kann die Hypothese schnell überprüft oder abgelehnt werden. Außerdem können Sie dadurch ggf. die Integration der erforderlichen Funktionen in die Anwendung optimieren. Das Ergebnis sind schnellere Innovationszyklen.

"Measure"

Sie möchten die Richtigkeit Ihrer Hypothese so schnell wie möglich überprüfen. Ein Minimum Viable Product (MVP) ist eine Vorabversion der neuen Funktionalität, mit der Sie Feedback einholen und sich vergewissern können, ob Sie sich in die richtige Richtung bewegen.

Das Ziel des MVP ist es, nicht nur Ihre Hypothese, sondern auch etwaige getroffene Annahmen zu überprüfen. Wenn beispielsweise 23 Prozent der Tailwind Traders-Kunden den Kaufvorgang auf der Zahlungsseite verlassen, lautet die Hypothese, dass der Grund dafür darin liegt, dass vom Unternehmen nicht genügend Zahlungsplattformen angeboten werden. Der Grund kann jedoch ein anderer sein. Das MVP sollte entworfen werden, um diese Annahmen und Hypothesen zu bestätigen oder abzulehnen.

Learn

Die Lernphase ähnelt dem Beginn des Prozesses. Nachdem Sie mehr über Ihre Annahmen und Hypothesen erfahren haben, können Sie feststellen, ob sie richtig, teilweise richtig oder falsch waren. Mit einer Wachstumsmentalität und genug Demut, um Misserfolge einzugestehen, können Sie Folgendes erreichen:

• Schnelles Umschwenken, wenn Sie mit der Arbeit an Ihrem MVP fortfahren müssen
• Konzentrieren Ihrer Bemühungen auf andere Bereiche und Formulieren einer alternativen Hypothese

Es ist wichtig zu erkennen, dass Sie durch den Prozess etwas Neues über Ihre Kunden und Ihr Unternehmen gelernt haben, selbst wenn Ihre Annahmen und Hypothesen falsch waren. Betrachten Sie dies nicht als verschwendete Zeit. Der Schlüssel liegt darin, dieses Wissen so schnell wie möglich zu erlangen und es auf eine zukünftige Hypothese anzuwenden. Dieser Ansatz ist der Kern der Fail-Fast-Kultur.

Wo als nächstes gesucht werden sollte

Am besten beginnen Sie bei der Untersuchung von Innovationen mit dem Dokument Übersicht über Innovationen in Cloud Adoption Framework.