OKR ist keine Software

In den letzten Wochen erreichten uns immer wieder Anfragen von Firmen, mit der Frage, ob wir dort nicht OKR einführen könnten und wieviel denn die Software kosten würde. Zunächst verwirrt, versuchten wir herauszufinden, was hinter dieser Frage steckt. Es gibt zur Zeit knapp 30 Softwareanbieter zum Thema OKR, die unter anderem beim Marketing einen guten Job machen. So entsteht beim Laien eventuell doch der Eindruck, dass man ein komplexes und agiles Zielmanagement schlicht durch die Installation einer Software etablieren könnte. Natürlich funktioniert das nicht – sogar im Gegenteil!

Gleich das erste Wertepaar im agilen Manifest – die Basis für das agile Mindset – klärt auf:

„Individuen und Interaktionen mehr als Prozesse und Werkzeuge“

Das bedeutet, zunächst muss die Organisation (sprich ihre Individuen) lernen, mit einem agilen Zielsystem umzugehen. Dies entspricht einem Change-Prozess und in den meisten Fällen auch ein Kultur-Entwicklungsprozess. Dieser kann natürlich durch Software unterstützt werden – aber erst wenn erste Lernerfolge erbracht werden. Denn die Einführung einer Software stellt einen weiteren Change-Prozess dar, der die Organisation einerseits zusätzlich belastet und andererseits dem OKR-Prozess die Umsetzung der Software aufdrückt.
Da der OKR-Prozess ein individueller Prozess ist, der in jedem Unternehmen mehr oder weniger anders ausgeprägt ist, gilt dies auch für die Software-Hersteller. Jeder der Anbieter hat eine leicht andere Philosophie, wie der Prozess und die Features bzw. die individuellen OKR-Parameter umgesetzt sind. Verwendet man nun die Software eines beliebigen Anbieters, so muss man den eigenen OKR-Prozess zwangsläufig daraufhin abändern, um die Akzeptanz der Software zu erreichen. Damit richtet sich der OKR-Prozess aber nach der Software, d.h. die Akzeptanz des Prozesses wird notgedrungen sinken und das führt zur (teilweisen) Unwirksamkeit.

Daher verwenden ca. 95% der Unternehmen eine bereits im Unternehmen vorhandene und verwendete Software, die sich maximal flexibel für die ersten Schritte eignet, wie z.B. Google Sheets, Microsoft Excel oder Atlassian Confluence. Erst nach ein bis zwei erfolgreich durchlaufenen Zyklen (und der durch Review sowie Retrospektive erfolgten Anpassung der OKR-Parameter) kann man den eigenen Prozess gegen die Liste der Software-Anbieter matchen und so den Anbieter mit der bestmöglichen Übereinstimmung suchen.

Exemplarisch nun ein paar Beispiele:

  1. OKR-Parameter:

    Nehmen wir für das erste Beispiel zwei der zahlreichen möglichen OKR-Parameter: Zyklus-Start und Zyklus-Dauer. 

    Hier gibt es natürlich mehrere potentielle Ausprägungen:
    • Alle Zyklen haben immer eine gleiche Dauer - z.B. 3 Monate. Aber möglicherweise auch 4 Monate, 6 Monate oder nur 2 Monate. Dies richtet sich nach der potenziellen Änderungsgeschwindigkeit der Ziele. So haben Innovationsteams oftmals Zyklenlängen unter 3 Monaten und Teams mit sehr viel Tagesgeschäft (und damit wenig strategischen Änderungen) oder grundsätzlich Teams mit wenig Zieländerung vielleicht 6 Monate.
    • Die Zyklen sind unterschiedlich groß aber immer gleichbleibend (z.B. um bestimmte Firmenrelevante Gegebenheiten - wie Quartalsberichte, Urlaubsphasen, ...) zu "umschiffen" - z.B.  - 2 - 4 - 2 - 4 Monat.
    • Der erste Zyklus im Jahr sollte aus praktischen Gründen nicht am 01.01. anfangen sondern z.B. 09.01. und hat damit eine leicht kürzere Laufzeit als die restlichen.
    • Oder man startet gleich versetzt - z.B. Q1 Anfang Februar.
    • Vielleicht startet man mit einer Zyklus-Dauer von 3 Monaten und stellt durch Review und Retros fest, dass es besser wäre auf einen 4-monatigen Zyklus zu wechseln.
       
    • Wordings

      Ein zweites Beispiel sind "Wordings - so gibt es im OKR Begrifflichkeiten wie "Moals", "OKR-Master", "Vision", "Company-Objectives", "Team Key Results" oder ähnliches. Fehlen diese in der Software (oder werden gar komplett anders bezeichnet), so sind die User schnell verunsichert, machen Fehler oder meiden gar die Software.
       
    • OKR-Dynamiken

      Wirksame OKR-Systeme sind "loosley-coupled" (und nicht strict-cascading) - das bedeutet, dass es beispielsweise keine direkte Ableitung von einer Ebene zur nächsten gibt. So werden etwa Company-OKR z.B. von einem Führungskreis entwickelt. Die Teams arbeiten nun holistisch darauf zu (und zwar auf die Objectives, auf einzelne Key Results, auf mehrere Key Results zur gleichen Zeit, auf die Moals und/oder die Vision) oder finden auch davon unabhängige Ziele. Man kann aber keine direkte Relation von Company-OKR zu Team-OKR herstellen. Nahezu jeder Software-Hersteller will aber diese Relation herstellen, indem z.B. "related OKR" angegeben werden können, dafür aber nur ein Endpunkt definiert werden kann. 
       
    • User-Interface

      Das User-Interface (UI) spielt eine zentrale Rolle bei der Erfassung von OKR. Will man beispielsweise als Key Result den NPS (Net Promoter Score) von 0.9 auf 14.7 erhöhen, so kann man diese Werte in ein Formular als Startwert und Endwert eintragen. Viele Software-Hersteller nutzen dafür beispielsweise ein Slider-Element von 0% bis 100%. Wenn nun in einem Weekly der NPS gerade bei 8.6 ist, dann müsste man erst der Dreisatz bemühen, um herauszufinden, dass der zugehörige Prozentwert 62% ist. Und oftmals gibt es in der Software nur Schritte von 5% in der Bewegung des Sliders. Hier sieht man, dass eine schicke UI eher hinderlich als förderlich ist.
       
    • Irreführende Mathematik

      Hat man ein Objective definiert, gilt es soviele Key Results wie notwendig zu finden. Die dahinterstehendes qualitativen Werte sind aber mitnichten gleichzusetzen. So macht es überhaupt keinen Sinn beim Objective eine Zielerreichung von 52.5% anzugeben, nur weil Key Result 1 zu 37% und Key Result 2 zu 68% erreicht wurde. Einerseits weil die Metriken der Key Results nicht vergleichbar sind (weder als Arbeitsaufwand noch als Komplexität) und andererseits könnte das Objective bereits zu 100% erreicht sein - selbst wenn die Metriken der Key Results deutlich unter 100% sind. Nahezu alle Software-Produkte suggerieren aber, dass diese Art der falschen Arithmetik sinnvoll und erstrebenswert wäre. Noch schlimmer wird dies, wenn man Zahlen aggregiert - so werden zuerst die Key Results addiert und der Mittelwert als Zielerreichungsgrad des Objectives angegeben. Anschließend werden alle Zielerreichungen im Mittelwert den Teams und deren Mittelwert dem Zielerreichnungsgrad der Organisation zugeordnet. Dies ist natürlich ähnlich sinnbefreit.
       
    • Geschäftsmodell der Software-Anbieter

      Das Geschäftsmodell der Software-Anbieter ist das regelmäßige Verkaufen von Lizenzen. So verlangen nahezu alle Anbieter eine monatliche (oder jährliche) Gebühr pro User. Akzeptiert man aber, dass die Wirksamkeit von OKR unter anderem darin liegt, die Zusammenarbeit im Sinne der Emergenz zu fördern, dann sind "Team-Lizenzen" der einzig logische Weg - damit reduziert sich aber das Geschäftsmodell der Anbieter auf ca. 5-15%, was natürlich aus geschäftlicher Sicht höchst unattraktiv ist. Daher sind nahezu alle Software-Produkte so aufgebaut, dass sie das Individuum in den Mittelpunkt stellen, was wiederum die Wirksamkeit von OKR angreift.