Digitale Innovation Teil 1 - Wie geht Innovation innerhalb der Organisation?
Habt ihr auch das Gefühl, dass wenn es um IT als Speerspitze für Innovation geht, es oft zögerlich gemacht wird oder es als zu aufwändig wahrgenommen wird? Das Motto “Fail early, fail fast” findet hier genauso Anwendung wie im Startup-Bereich.
Dieser Post ist der erste in einer Reihe, wo ich das Thema digitale Innovation mit Fokus auf organisationsinterne Auslöser behandle. In diesem Post möchte ich zuerst meine Sicht vom Innovationsprozess darstellen. Das ist ein wenig theoretisch, jedoch in den späteren Posts, wo es praktisch wird, kann man anhand des hier beschriebenen Prozesses nachvollziehen, an welchen Stellen angesetzt wird. Oder: Wo ist der Hebel?
Fangen wir also an.
Wie es bereits in 2013 in der Computerwoche erschienenen Artikel mit einem etwas provokativen Titel “Was hat die IT mit Innovation zu schaffen” (link) hervorgehoben wird: “Überall im Unternehmen gibt es Potenzial für Veränderungen, aber die Fachbereiche sehen selten über den Tellerrand hinaus und verschenken so möglicherweise Synergien.” Dem kann ich vollends zustimmen. Danach kommt ein anderer Satz, den ich hier kritisch hinterfragen muss: “Auch hier soll die IT als übergreifende Instanz Anstöße geben”. Ja, mitunter auch die IT, aber nicht nur!
Um hier mit noch einem Mythos zu brechen: Diese Art von Innovation kann und darf jeder starten! Es ist nicht nur der Management-Ebene vorbehalten, da es heute so viele Möglichkeiten gibt, mit Hilfe bereits vorhandener Tools einfach mal loszustarten. Im englischsprachigen Raum spricht man von "grassroots innovation”.
Im letzten Beitrag (einer der letzten Beiträge - LINK) habe ich auf das Thema Komplexität in der Softwareentwicklung aufmerksam gemacht. In Innovation haben wir es auch mit Komplexität zu tun - Viele Unbekannte und unbeantwortete Fragen: Wie kann ich mein Use Case richtig formulieren? Was können die Benefits für die Organisation (ich beschränke mich ungern nur auf “das Unternehmen”) sein? Erst danach kommt die Frage: ist es grundsätzlich technologisch machbar? Letztere ist aber eine vielschichtige Frage oder Hydra-Frage - auf den ersten Blick lässt es sich fast immer mit “ja” beantworten (ein Kopf weg), doch dann kommt das “aber” (zwei neue Köpfe gewachsen).
Hier sollte man grob auf folgende Phasen achten:
Die 1. Phase stellt sich fast von alleine ein. Entweder stellt man einen Änderungsbedarf fest beziehungsweise hat eine Idee dazu, oder etwas (ein Prozess, Vorgang, Applikation etc.) funktioniert nicht wie es soll und es führt zu Verluste (Zeit, Geld, Nerven etc.).
Die 2. Phase zieht sich manchmal über längere Zeit hin, wo Sie über Lösungen nachdenken, sich mit anderen Personen dazu austauschen und vielleicht auch recherchieren nach dem Prinzip “jemand anders hat doch sicher das Problem vorher gehabt”. Manchmal wird die Suche nach einer Lösung schon in dieser Phase abgebrochen.
Empfohlen von LinkedIn
Die 3. Phase erreichen diejenigen, die bereits ein wenig Erfahrung haben und eine konkrete Vorstellung davon entwickeln, wie der “Schmerz” zu lösen ist. Auch der Austausch mit anderen über das Problem erfordert eine Dokumentation - z.B. als Dokument, Präsentation oder manchmal auch eine Applikation (von Excel Macros bis Clickdummies gibt es hier eine ganze Palette von Möglichkeiten).
Die 4. Phase - Die Entwicklung einer prototypischen Lösung. In dieser Phase kommen nur wenige an, da oft die Expertise fehlt, wie eine solche umzusetzen sei. Die erfolgreichsten Organisationen versuchen, Mitarbeiter hier mit Tools, Schulungen oder Expertise (im Haus oder extern) zu unterstützen. Zu Recht, denn jede Phase ist teurer als die andere und Mitarbeiter-getriebene Innovation ist tendenziell nachhaltiger und kosteneffektiver.
Zwischen Phasen 2 und 4 wird in der Regel mehrmals hin- und her gewechselt (iteriert). Spätestens hier kommt Agilität ins Spiel. Agile Prinzipien eignen sich für explorative Situationen, wo man sich über die Anforderungen nicht im Klaren ist, daher können sie hier Anwendung finden. Hier lauert jedoch auch Gefahr, worauf ich unten näher eingehe.
Kann Agilität hier zur Kostenfalle werden?
Die typische Berater Antwort: ganz klar “jaein”.
Falls die Anforderungen relativ klar sind (auch wenn kompliziert - im Gegensatz zu komplex), dann wird Agilität hier ihre Stärken nicht entfalten können und kann die Kosten in die Höhe treiben.
Generell gilt: Jede der Phasen kann sehr kostspielig sein, wenn die vorherigen nicht beantwortet sind. Dies wird von vielen Fachautoren bestätigt, z.B. von Robert.C Martin im Buch “Clean Code: A Handbook of Agile Software Craftsmanship” oder auch deutschsprachige neuere Fachbücher wie “Softwareentwicklung kompakt und verständlich: Wie Softwaresysteme entstehen” von Hans Brandt-Pook und Rainer Kollmeier.
Beispiel: Wenn die Anforderungen und Benefits nicht klar definiert sind (Phasen 2,3, selten 1) dann weiß man nicht, wann ein erster “fit” beim Prototyping/MVP entsteht. Es geht dann Iteration nach Iteration, ohne klares Ziel in Sicht. Wenn man dabei noch agil vorgeht, fällt es kaum auf, dass die unklaren ersten Phasen die Kosten in die Höhe treiben - agile Prinzipien sind OK mit Unsicherheit. Heißt: man kann prozessual und technisch damit umgehen und erst die wirtschaftlichen Faktoren (“Ups, kein Budget mehr”) beenden den Zyklus - oft auch ziemlich abrupt.
Ein Tipp dazu aus der Startup-Welt: Man kann das anfängliche Anforderungsbild auch iterieren, und zuerst nur Schlüsselanforderungen in die ersten MVPs validieren (manchmal in der Literatur als “dealbreakers” oder “KO Kriterien” bezeichnet).
Bevor der Beitrag zu lang wird, machen wir hier eine Verschnaufpause. Im nächsten Post geht es weiter mit einem konkreten Beispiel und mit einer Analyse anhand der obigen Faktoren. Wir stellen zwei Vorgehensweisen vor und schauen auf die Unterschiede.
Ich würde mich freuen über Ihre Antworten auf folgende Frage: Möchten Sie auch ein Videotutorial dazu für die Umsetzung mithilfe der Microsoft Power Platform? Oder lieber Screenshots und Beschreibungen?
Und gerne auch wie immer Gegenmeinungen und konstruktive Kritik!