Es ist der Beginn eines weiteren Quartals. Thomas, Director of Engineering, präsentiert stolz die Leistung seines Teams vor dem Vorstand. Die Dashboards leuchten grün. „Im letzten Quartal haben wir 1.200 Tickets geschlossen, 15 % mehr als im Vorquartal”, verweist er. „Unsere Teams haben insgesamt 500 ‚Story Points’ geliefert, und die Code-Abdeckung durch Unit-Tests stieg auf beeindruckende 85 %!” Thomas beendet seine Präsentation und erwartet anerkennende Blicke. Stattdessen meldet sich nach einem Moment der Stille der Product Director zu Wort: „Das klingt alles beeindruckend, Thomas. Aber im selben Quartal ist die Kundenabwanderungsrate um 10 % gestiegen, und die Akzeptanz all der neuen Features, die Sie mit so viel Aufwand geliefert haben, lag unter 5 %. Sagen Sie mir also – was haben wir mit all dieser Arbeit wirklich erreicht?” In diesem einen Moment erkannte Thomas die brutale Wahrheit. Seine Teams liefen schneller als je zuvor, aber sie liefen auf einem Laufband. Sie erzeugten eine enorme Menge an „Aktivität”, aber nicht unbedingt „Wirkung”. Er maß den Aufwand, nicht das Ergebnis.

Lesen Sie auch: Automatisiertes vs. manuelles Testen 2026: Wo verändert KI die Balance?

Diese Szene ist in vielen Technologieorganisationen alltäglich. Wir sind in die Falle getappt, das zu messen, was leicht zu zählen ist, anstatt das, was tatsächlich zählt. Codezeilen, Anzahl der Deployments, „Velocity” – das alles sind Kennzahlen, die uns ein illusorisches Gefühl von Kontrolle und Fortschritt geben, aber selten etwas über den tatsächlichen Wert aussagen, den wir Kunden und dem Unternehmen liefern. Wirklich leistungsstarke IT-Organisationen unterscheiden sich von anderen nicht dadurch, dass sie mehr arbeiten, sondern dadurch, dass sie ihre Auswirkungen auf die Geschäftsleistung präzise messen und optimieren können. Dieser Artikel ist ein praxisnaher Leitfaden für Führungskräfte, die aufhören wollen, Aktivität zu managen, und anfangen wollen, Ergebnisse zu managen. Wir erklären die grundlegenden Unterschiede zwischen zwei Schlüsselwerkzeugen – KPIs (Key Performance Indicators) und OKRs (Objectives and Key Results) – und zeigen Ihnen, wie Sie ein konsistentes Messsystem aufbauen, das die tägliche Arbeit der Entwicklungsteams mit den strategischen Zielen des gesamten Unternehmens verbindet.

Warum sind traditionelle IT-Produktivitätskennzahlen (Story Points, Codezeilen) irreführend und schädlich?

„Die durchschnittliche Fehlerbeseitigungseffizienz der meisten Softwareorganisationen liegt bei etwa 85 %, was bedeutet, dass 15 % der Fehler an die Kunden ausgeliefert werden.”

— Capers Jones, Applied Software Measurement | Quelle

Seit Jahren versucht die IT-Branche, den „Heiligen Gral” zu finden – eine einzige, einfache Kennzahl zur Messung der Entwicklerproduktivität. So entstanden und verbreiteten sich Kennzahlen wie die Anzahl der Codezeilen (Lines of Code, LOC), die Anzahl geschlossener Tickets oder die „Velocity” (die Anzahl der in einem Sprint abgeschlossenen „Story Points”). Obwohl jede dieser Kennzahlen in einem sehr engen, diagnostischen Kontext nützlich sein kann, ist ihre Verwendung als primäres Produktivitätsmaß – oder schlimmer noch, als Grundlage für die Bewertung und Belohnung von Teams – äußerst schädlich.

1. Sie messen Aufwand, nicht Wert: 1.000 Zeilen komplizierten, fehlerhaften Codes zu schreiben, der kein Problem löst, ist weitaus schlimmer als 10 Zeilen eleganten Codes zu schreiben, der ein zentrales Kundenproblem löst. Ebenso ist ein Team, das 50 „Story Points” „verbrennt”, um ein Feature zu bauen, das niemand nutzt, weitaus weniger produktiv als ein Team, das 10 „Story Points” einsetzt, um eine kleine, aber äußerst wertvolle Änderung umzusetzen. Diese Kennzahlen sagen nichts über den Geschäftswert der geleisteten Arbeit aus.

2. Sie fördern unangemessenes Verhalten: Wenn Menschen wissen, dass sie anhand einer bestimmten Kennzahl beurteilt werden, beginnen sie, ihr Verhalten für diese Kennzahl zu optimieren – oft auf Kosten des gesunden Menschenverstands (bekannt als Goodharts Gesetz).

  • Messen Sie Codezeilen? Entwickler werden anfangen, langatmigeren, komplexeren Code zu schreiben, um eine bessere Bewertung „herauszuholen”.

  • Messen Sie die Anzahl geschlossener Tickets? Teams werden sich darauf konzentrieren, die einfachen, trivialen Aufgaben schnell zu schließen und die schwierigen, strategisch wichtigen zu vermeiden.

  • Messen Sie die „Velocity”? Teams werden beginnen, Schätzungen „aufzublähen” (Inflation von „Story Points”), um zu zeigen, dass sie schneller werden, während Qualität und technische Schulden in den Hintergrund treten.

3. Sie sind zwischen Teams nicht vergleichbar: „Story Points” sind ein subjektives Maß für Komplexität, einzigartig für jedes Team. Team A, das 20 „Story Points” pro Sprint liefert, ist nicht unbedingt weniger produktiv als Team B, das 50 liefert. Der Vergleich der „Velocity” zwischen Teams ist einer der größten und häufigsten Missbräuche agiler Methoden. Er führt zu ungesundem Wettbewerb und zerstört Vertrauen.

4. Sie ignorieren „unsichtbare” Arbeit: Viele zentrale Engineering-Aktivitäten schlagen sich nicht direkt in neuen Features nieder. Die Arbeit an Refactoring, der Verbesserung der CI/CD-Pipeline, dem Schreiben von Dokumentation oder dem Mentoring jüngerer Kollegen ist absolut entscheidend für die langfristige Gesundheit des Systems, wird aber in Kennzahlen wie „Story Points” nicht widergespiegelt. Die Fokussierung auf diese Kennzahlen entmutigt Investitionen in diese wichtigen, aber „unsichtbaren” Aufgaben.

Die Verwendung dieser Kennzahlen zur Bewertung der Produktivität ist wie die Beurteilung eines Restaurants anhand der Anzahl der servierten Teller statt anhand des Geschmacks der Speisen und der Zufriedenheit der Gäste. Um zu messen, was wirklich zählt, brauchen wir einen völlig anderen Satz von Werkzeugen.

Was sind Vanity Metrics und wie erkennen Sie sie in Ihrem Team?

Vanity Metrics sind Kennzahlen, die auf den ersten Blick beeindruckend aussehen, Ihnen aber in Wirklichkeit nichts über die tatsächliche Gesundheit Ihres Unternehmens verraten und Ihnen nicht helfen, bessere Entscheidungen zu treffen. Sie sind oft leicht zu messen und sehen auf aufsteigenden Diagrammen wunderbar aus, weshalb Manager gerne damit prahlen. Das Problem ist, dass sie oft Rauschen messen, nicht das Signal.

Eric Ries, der Begründer der Lean-Startup-Methodik, definierte einen einfachen Test, um Vanity Metrics von handlungsrelevanten Kennzahlen zu unterscheiden: „Erlaubt mir diese Kennzahl, eine konkrete, nützliche Entscheidung zu treffen? Wenn nicht, ist es wahrscheinlich eine Vanity Metric.”

Beispiele für Vanity Metrics in IT und Business:

  • Anzahl registrierter Nutzer: Das Diagramm der Gesamtzahl registrierter Nutzer steigt fast immer. Das sieht großartig aus. Aber was, wenn sich 95 % von ihnen registriert haben, die App einmal genutzt und nie wieder zurückgekehrt sind? Eine wertvolle Kennzahl wäre die Anzahl aktiver Nutzer in der letzten Woche oder die Retentionsrate.

  • Anzahl der Downloads einer mobilen App: Eine Million Downloads klingt nach Erfolg. Aber wie viele dieser Personen haben die App tatsächlich gestartet? Wie viele von ihnen haben den Onboarding-Prozess durchlaufen? Wie viele nutzen sie regelmäßig?

  • „Velocity” (Story Points pro Sprint): Wie wir bereits besprochen haben, ist diese Kennzahl sehr leicht zu manipulieren und sagt nichts über den an den Kunden gelieferten Wert aus.

  • Anzahl der Deployments pro Tag: Für sich allein kann diese Kennzahl eine Vanity Metric sein. Was nützt es, wenn wir 20 Mal am Tag deployen, wenn 10 dieser Deployments Hotfixes sind, die Fehler der vorherigen 10 Deployments beheben? Erst in Kombination mit der Change Failure Rate (der Rate fehlgeschlagener Deployments) wird sie Teil eines wertvollen Gesamtbildes.

Wie erkennen Sie Vanity Metrics?

  • Sie misst das „Was?”, nicht das „Warum?”: Sie informiert Sie darüber, was passiert ist, hilft Ihnen aber nicht zu verstehen, warum es passiert ist und was Sie dagegen tun können.

  • Es ist unmöglich, auf ihrer Basis ein Experiment durchzuführen: Sie können keine Hypothese formulieren und durch die Beobachtung der Veränderung dieser Kennzahl verifizieren.

  • Es handelt sich um eine aggregierte, nicht um eine segmentierte Kennzahl: Die Gesamtzahl der Nutzer sagt nichts aus. Aber die Anzahl der Nutzer, segmentiert nach Akquisitionskanal oder Zeitkohorte, wird zu einer wertvollen Kennzahl.

  • Sie ist leicht manipulierbar: Wenn ein Team eine Kennzahl leicht „verbessern” kann, ohne den tatsächlichen Wert zu steigern, ist dies ein Warnsignal.

Die Falle der Vanity Metrics besteht darin, dass sie ein falsches Erfolgsgefühl vermitteln und die Wachsamkeit einschläfern. Sie führen zu schlechten Entscheidungen auf der Grundlage unvollständiger oder irreführender Daten. Der erste Schritt zum Aufbau eines gesunden Messsystems ist die konsequente Eliminierung von Vanity Metrics und deren Ersetzung durch Kennzahlen, die echte geschäftliche Auswirkungen widerspiegeln.

KPI vs. OKR: Was ist der grundlegende Unterschied und wann sollten Sie welches Werkzeug einsetzen?

In Diskussionen über die Erfolgsmessung tauchen ständig zwei Akronyme auf: KPI und OKR. Sie werden oft verwechselt oder synonym verwendet, was eine Quelle großer Verwirrung ist. Tatsächlich sind KPIs und OKRs zwei verschiedene, aber komplementäre Werkzeuge, die völlig unterschiedliche Funktionen erfüllen. Diesen Unterschied zu verstehen, ist der Schlüssel zum Aufbau eines nachhaltigen und effektiven Messsystems.

KPIs (Key Performance Indicators):

  • Was sind sie? KPIs sind Indikatoren für die Gesundheit eines Systems oder Prozesses. Es sind Kennzahlen, die wir kontinuierlich überwachen, um sicherzustellen, dass alles wie erwartet funktioniert.

  • Metapher: KPI ist das Armaturenbrett eines Autos. Es zeigt wichtige Parameter an: Geschwindigkeit, Motortemperatur, Kraftstoffstand. Solange die Anzeigen in der „grünen Zone” sind, müssen Sie keine besonderen Maßnahmen ergreifen – Sie fahren einfach weiter. Wenn jedoch ein Indikator in die „rote Zone” eintritt (zum Beispiel leuchtet die Ölkontrollleuchte auf), ist dies ein Alarmsignal, das sofortiges Handeln erfordert.

  • Zweck: Der Zweck von KPIs ist es, den Status quo zu überwachen und aufrechtzuerhalten oder inkrementelle, evolutionäre Verbesserungen vorzunehmen.

  • Beispiele in der IT: Service-Verfügbarkeit (Uptime), API-Antwortzeit, Change Failure Rate, Kundenzufriedenheit (CSAT).

OKRs (Objectives and Key Results):

  • Was sind sie? OKRs sind ein Framework für das Setzen und Erreichen ambitionierter Ziele. Es ist ein Werkzeug für das Management von Veränderung und Innovation.

  • Metapher: OKR ist ein GPS-Navigationssystem. Es sagt Ihnen nicht Ihre aktuelle Geschwindigkeit oder Motortemperatur. Es sagt Ihnen, wohin Sie gelangen wollen (Objective) und zeigt Ihnen, welche Meilensteine Sie erreichen müssen, um dorthin zu gelangen (Key Results). Sie nutzen es, wenn Sie Ihre Position aktiv von Punkt A nach Punkt B verändern wollen.

  • Ziel: Das Ziel von OKRs ist es, eine bedeutende, bahnbrechende Veränderung innerhalb eines festgelegten, in der Regel vierteljährlichen Zeithorizonts zu erreichen.

  • Beispiel in der IT:

  • Ziel: „Die Benutzererfahrung während des Onboarding-Prozesses revolutionieren.”

  • Key Results: 1. Die für das Onboarding benötigte Zeit von 10 Minuten auf 3 Minuten reduzieren. 2. Die Rate der erfolgreichen Onboarding-Abschlüsse von 60 % auf 90 % steigern.

Wie arbeiten KPIs und OKRs zusammen?

KPI und OKR stehen nicht im Widerspruch zueinander – sie leben in Symbiose.

  • KPIs zeigen den Bedarf für ein OKR auf: Wenn einer Ihrer wichtigsten KPIs zu sinken beginnt (z. B. die API-Antwortzeit steigt), könnte dies ein Signal sein, dass Sie im nächsten Quartal ein OKR erstellen müssen, das auf die Leistungsverbesserung ausgerichtet ist.

  • Ein OKR kann zu einem neuen KPI werden: Sobald ein OKR erfolgreich abgeschlossen und ein neues, höheres Leistungsniveau erreicht wurde (z. B. die Service-Verfügbarkeit von 99,5 % auf 99,95 % gestiegen ist), kann dieses neue Niveau zu einem neuen Standard werden, der durch einen KPI überwacht wird.

Kurz gesagt: KPIs sind „business as usual” und OKRs sind „business as unusual”. Sie brauchen beides. KPIs sagen Ihnen, ob Ihr Unternehmen gesund ist. OKRs sagen Ihnen, in welche Richtung es wachsen sollte.

Welche Beispiele für gute KPIs können zur Messung von Zuverlässigkeit und Leistung verwendet werden (DORA-Metriken)?

Gute KPIs zu definieren ist eine Kunst. Sie müssen messbar, relevant und vor allem ein Abbild dessen sein, was für das Unternehmen und die Kunden wirklich wichtig ist. In der Welt der modernen IT sind der absolut beste und bewährteste Ausgangspunkt die sogenannten DORA-Metriken, die – wie wir im Kontext der DevOps-Kultur erwähnt haben – das Ergebnis jahrelanger Forschung darüber sind, was leistungsstarke Technologieorganisationen von leistungsschwachen unterscheidet.

Die DORA-Metriken sind vier zentrale Leistungsindikatoren (KPIs), die Geschwindigkeit und Stabilität perfekt ausbalancieren.

Durchsatz-Metriken:

1. Deployment-Frequenz (Deployment Frequency):

  • Was misst sie? Wie oft eine Organisation erfolgreich Änderungen in die Produktionsumgebung einspielt.

  • Warum ist sie wichtig? Sie ist ein Indikator für die Agilität und Reife der CI/CD-Prozesse. Hochleistungsorganisationen deployen Änderungen bei Bedarf (mehrmals täglich), während leistungsschwache Organisationen dies seltener als einmal im Monat tun. Eine hohe Deployment-Frequenz (in kleinen Chargen) reduziert das Risiko und beschleunigt die Wertlieferung.

  • Reifegrade: Elite: bei Bedarf. Hoch: einmal täglich/wöchentlich. Mittel: einmal wöchentlich/monatlich. Niedrig: seltener als einmal im Monat.

2. Vorlaufzeit für Änderungen (Lead Time for Changes):

  • Was misst sie? Wie viel Zeit zwischen der Code-Freigabe (Commit) und dem erfolgreichen Deployment in die Produktion vergeht.

  • Warum ist sie wichtig? Sie ist ein Maß für die Effizienz der gesamten Delivery-Pipeline. Eine kurze Vorlaufzeit bedeutet, dass der Prozess automatisiert, effizient und frei von Engpässen ist (z. B. lange Wartezeiten auf manuelle Tests oder Freigaben).

  • Reifegrade: Elite: < 1 Stunde. Hoch: < 1 Tag. Mittel: 1 Tag – 1 Woche. Niedrig: > 1 Woche.

Stabilitäts-Metriken (Stability):

3. Änderungsfehlerrate (Change Failure Rate):

  • Was misst sie? Welcher Prozentsatz der Produktions-Deployments einen Fehler verursacht (z. B. eine sofortige Korrektur erfordert – Hotfix, Rollback – oder einen Vorfall auslöst).

  • Warum ist sie wichtig? Sie ist ein zentraler Indikator für die Prozessqualität und Zuverlässigkeit. Sie zeigt, ob Geschwindigkeit nicht auf Kosten der Stabilität erreicht wird. Das Ziel ist, diesen Indikator so niedrig wie möglich zu halten.

  • Reifegrade: Elite: 0–15 %. Hoch: 16–30 %. Mittel: 16–30 %. Niedrig: 46–60 %.

4. Zeit zur Wiederherstellung des Dienstes (Time to Restore Service, MTTR):

  • Was misst sie? Wie schnell eine Organisation den vollen Betrieb eines Dienstes nach einem Vorfall oder Ausfall in der Produktion wiederherstellen kann.

  • Warum ist sie wichtig? Sie ist ein Maß für die Resilienz des Systems und die Effektivität der Incident-Response-Prozesse. In komplexen Systemen sind Ausfälle unvermeidlich. Entscheidend ist, wie schnell wir damit umgehen können.

  • Reifegrade: Elite: < 1 Stunde. Hoch: < 1 Tag. Mittel: 1–7 Tage. Niedrig: > 1 Woche.

Diese vier Metriken bilden ein ausgewogenes System. Die ersten beiden (Geschwindigkeit) treiben die Organisation voran, und die letzten beiden (Stabilität) fungieren als Notbremse und stellen sicher, dass wir nicht zu schnell unterwegs sind. Die regelmäßige Messung und das Streben nach Verbesserung dieser vier KPIs ist einer der wirkungsvollsten Wege, eine leistungsstarke Technologieorganisation aufzubauen.

Wie schreiben Sie ein gutes Objective (Ziel), das inspiriert und eine Richtung weist?

Das Objective (Ziel) im OKR-Framework ist mehr als nur eine Textzeile. Es ist das Herz und die Seele des gesamten Quartalsaufwands. Es soll die Frage beantworten: „Wohin gehen wir?”. Ein gut formuliertes Objective sollte wie ein Polarstern sein – eine klare Richtung weisend, das Team inspirierend und ambitioniert genug, um Menschen aus ihrer Komfortzone zu holen.

Hier sind die Schlüsselmerkmale eines guten Ziels:

1. Es ist qualitativ und inspirierend: Das Ziel sollte keine Zahlen enthalten. Es soll den gewünschten Zukunftszustand auf eine ansprechende und motivierende Weise beschreiben. Es sollte etwas sein, das Menschen stolz über ihrem Schreibtisch aufhängen würden.

  • Schlechtes Beispiel (Kennzahl als Ziel): „MAU um 15 % steigern.”

  • Gutes Beispiel (inspirierende Vision): „Die ansprechendste Erfahrung für unsere neuen Nutzer schaffen.”

2. Es ist ambitioniert und etwas unbequem: OKRs sollen nicht die tägliche Arbeit beschreiben („business as usual”). Sie dienen dazu, Durchbrüche zu erzielen. Ein gutes Ziel sollte ambitioniert sein, und seine vollständige Erreichung sollte zunächst schwierig erscheinen. Bei Google gilt das Erreichen von 70 % eines Ziels als Erfolg. Wenn Sie regelmäßig 100 % erreichen, bedeutet das, dass Ihre Ziele nicht ambitioniert genug sind.

  • Schlechtes Beispiel (sicher, leicht erreichbar): „Die Plattform am Laufen halten.”

  • Gutes Beispiel (ambitioniertes „Stretch Goal”): „Die legendäre Zuverlässigkeit und Performance unserer Plattform erreichen.”

3. Es ist handlungsorientiert und zeitlich begrenzt: Das Ziel sollte zum Handeln anregen und in den Zeitrahmen des OKR-Zyklus eingebettet sein (in der Regel ein Quartal). Es sollte so formuliert sein, dass es ein Gefühl der Dringlichkeit vermittelt.

  • Schlechtes Beispiel (passiv, unbestimmt): „Kundenzufriedenheit verbessern.”

  • Gutes Beispiel (aktiv, zeitlich eingebettet): „Unseren Kunden in diesem Quartal erstklassigen technischen Support bieten.”

4. Es ist für das Team verständlich und eindeutig: Das Objective muss einfach und klar sein. Jede Person im Team sollte beim Lesen leicht verstehen, was die Priorität für das kommende Quartal ist. Unternehmens-Jargon und komplizierte Formulierungen sollten vermieden werden.

  • Schlechtes Beispiel (Jargon, unklar): „Unsere Kernkompetenzen synergetisch nutzen, um die Auswirkungen auf das Marktparadigma zu maximieren.”

  • Gutes Beispiel (einfach, klar): „Unser Produkt zur einfachsten und schnellsten Lösung auf dem Markt machen.”

Gute Ziele zu formulieren ist eine Kunst, die Übung erfordert. Es ist eine Übung in strategischem Denken und Führung. Ein gut gesetztes Ziel ist die halbe Miete – es gibt der gesamten Arbeit des Teams für die kommenden drei Monate Sinn und Energie.

Wie definieren Sie messbare Key Results (Schlüsselergebnisse), die tatsächlich Fortschritt messen – und nicht Aufgaben?

Wenn das Objective (Ziel) die Frage beantwortet „Wohin gehen wir?”, dann beantworten die Key Results (KRs) die Frage „Woran erkennen wir, dass wir angekommen sind?”. Genau an diesem Punkt wird am häufigsten der Fehler gemacht, Ergebnisse (Outcomes) mit Aktivitäten (Outputs) zu verwechseln.

Ein Key Result ist keine zu erledigende Aufgabe. Es ist ein messbares Ergebnis, das aus der Durchführung mehrerer Aufgaben resultiert.

Schlechte Praxis: KR als Aufgabenliste (output-basiert)

  • Ziel: Den Prozess der Kundeneinführung optimieren.

  • KR1: Den neuen Onboarding-Assistenten starten.

  • KR2: 5 neue Anleitungsvideos erstellen.

  • KR3: Eine Schulung für die Support-Abteilung durchführen.

Was stimmt mit den obigen KRs nicht? Sie können alle drei „abhaken”, und dennoch hat sich der Einführungsprozess möglicherweise überhaupt nicht verbessert. Wir haben die Durchführung der Arbeit gemessen, nicht das Ergebnis.

Best Practice: KR als Ergebnismaß (outcome-basiert)

  • Ziel: Einen nahtlosen und blitzschnellen Einführungsprozess für neue Kunden schaffen.

  • KR1: Die durchschnittliche Zeit von der Registrierung bis zur Aktivierung einer Schlüsselfunktion von 48 Stunden auf 2 Stunden reduzieren.

  • KR2: Den Anteil der Kunden, die den Onboarding-Prozess selbstständig (ohne Kontakt zum Support) abschließen, von 50 % auf 85 % steigern.

  • KR3: Die Zufriedenheitsrate mit dem Onboarding-Prozess (gemessen durch eine Umfrage) von 6/10 auf 9/10 erhöhen.

Jetzt sehen wir einen fundamentalen Unterschied. Diese KRs definieren explizit, was „Prozessverbesserung” bedeutet. Sie geben dem Team die Autonomie zu entscheiden, welche Aufgaben (Einführung eines Assistenten, Anleitungsvideos oder etwas ganz anderes?) am besten zum Erreichen dieser messbaren Ergebnisse beitragen.

Merkmale eines guten Key Results:

  • Es ist messbar und überprüfbar: Es muss eine Zahl enthalten. Es muss eine eindeutige Möglichkeit geben, am Ende des Quartals festzustellen, ob es erreicht wurde oder nicht. Es gibt keinen Raum für subjektive Bewertungen.

  • Es misst Wert, nicht Aktivität: Es konzentriert sich auf die Auswirkung auf den Nutzer oder das Unternehmen, nicht auf die Lieferung eines Features. Ein guter Test ist die Frage: „Na und?” Wenn die Antwort auf „Wir haben ein neues Feature geliefert” lautet „Na und?”, dann ist es kein gutes KR.

  • Es ist ambitioniert, aber realistisch: Wie ein Ziel sollte auch ein KR herausfordernd sein. Es sollte Anstrengung und Kreativität vom Team erfordern.

  • Es ist vom Team beeinflussbar: Das Team muss einen echten Einfluss auf die Kennzahl haben, die es misst. Einem einzelnen Entwicklungsteam ein KR wie „Unternehmensumsatz um 20 % steigern” zu setzen, ist ein Fehler, da es darauf keinen direkten Einfluss hat. Aber ein KR wie „Konversionen auf der Preisseite um 15 % steigern” liegt sehr wohl in seiner Reichweite.

Gute, ergebnisbasierte Key Results zu definieren, ist der schwierigste Teil der Arbeit mit OKRs. Es erfordert einen Perspektivwechsel, ein tiefes Produktverständnis und die Disziplin, das, was wir tun, von dem zu trennen, was wir erreichen wollen.

Wie verbinden Sie langfristige KPIs mit vierteljährlichen, ambitionierten OKRs?

Ein Messsystem zu schaffen, das Stabilität und Monitoring (KPI) harmonisch mit Ambition und Veränderung (OKR) verbindet, ist das Kennzeichen einer reifen, datengetriebenen Organisation. Diese beiden Werkzeuge sollten nicht in getrennten Welten leben. Sie sollten ein zusammenhängendes, dynamisches System bilden, in dem das eine das andere informiert und beeinflusst.

Das „Gesundheit und Ziele”-Modell: Sie können es sich in Bezug auf die menschliche Gesundheit vorstellen.

  • KPIs sind unsere „Vitalzeichen”. Blutdruck, Herzfrequenz, Temperatur. Wir überwachen sie regelmäßig. Solange sie normal sind, schenken wir ihnen keine besondere Aufmerksamkeit. Das ist der „business as usual”-Zustand. Unser Ziel ist einfach, „gesund zu sein”.

  • OKR ist unser „Trainingsplan”. Wenn wir ein bestimmtes, ambitioniertes Ziel erreichen wollen – etwa einen Marathon zu laufen – erstellen wir einen Plan. Unser Ziel wird „Den Marathon in unter 4 Stunden absolvieren”. Unsere Key Results sind zum Beispiel „Die wöchentliche Laufdistanz auf 50 km erhöhen”, „Die persönliche Bestzeit über 10 km um 5 Minuten verbessern”. Wir arbeiten mehrere Monate intensiv an diesen Zielen. Während dieser Zeit überwachen wir weiterhin unsere „Vitalzeichen” (KPIs), um sicherzustellen, dass das intensive Training unsere Gesundheit nicht negativ beeinflusst.

Wie funktioniert das in der IT-Praxis?

  • Definieren Sie Ihre KPIs: Jedes Produkt- oder Plattformteam sollte einen kleinen Satz (3–5) von KPIs definieren und regelmäßig überwachen, die die „Gesundheit” seines Bereichs widerspiegeln. Für ein Produktteam könnten das Kennzahlen zum Nutzerengagement und zur Zufriedenheit sein. Für das Plattformteam wären es die DORA-Metriken. Diese KPIs sind auf permanenten Dashboards sichtbar.

  • Nutzen Sie KPIs zur Problemerkennung: Die regelmäßige Überprüfung von KPIs ermöglicht die frühzeitige Erkennung von Problemen. Wenn der KPI für die Ladezeit einer Anwendung stetig steigt (sich verschlechtert), ist dies ein Signal, dass im nächsten Quartal Maßnahmen ergriffen werden müssen.

  • Erstellen Sie ein OKR zur Lösung eines Problems oder zur Nutzung einer Chance: Ein sich verschlechternder KPI wird zu einem natürlichen Kandidaten für ein vierteljährliches OKR. Das Team kann ein Ziel definieren: „Unsere Anwendung blitzschnell machen”, mit Key Results, die sich auf spezifische Performance-Kennzahlen beziehen. OKRs können auch aus neuen strategischen Initiativen resultieren, die nicht an bestehende KPIs gebunden sind.

  • Überwachen Sie KPIs während der OKRs: Während das Team hart an der Erreichung seiner OKRs arbeitet (z. B. neue, innovative Features implementiert), muss es gleichzeitig seine „Gesundheits”-KPIs im Auge behalten. Geht das Streben nach Neuem auf Kosten der Stabilität? Steigt die Rate fehlgeschlagener Implementierungen gefährlich an? So bleibt die Balance erhalten.

  • Nach Erreichung eines OKRs kann es zu einem neuen KPI werden: Wenn ein Team ein OKR erfolgreich erreicht und zum Beispiel die Ladezeiten der Anwendung dauerhaft auf ein neues, besseres Niveau senkt, kann dieses neue Niveau zu einem neuen Standard werden, der durch einen KPI überwacht wird.

Dieser dynamische Zyklus, in dem KPIs Bedarfe aufzeigen und OKRs Veränderungen vorantreiben, schafft ein leistungsstarkes, sich selbst verbesserndes System, das gleichzeitig Stabilität und das Streben nach Innovation ermöglicht.

Was sind die häufigsten Fehler und Fallstricke bei der Implementierung von OKRs in Technologieteams?

Das OKR-Framework ist vom Konzept her täuschend einfach, aber in der Praxis extrem schwer korrekt umzusetzen. Technologieteams mit ihrer Tendenz, sich auf Lösungen und Aufgaben zu konzentrieren, sind besonders anfällig dafür, in dieselben wiederkehrenden Fallen zu tappen.

1. Verwechslung von Key Results mit Initiativen (Aufgaben): Dies ist der Fehler Nummer eins, den wir bereits besprochen haben. Teams erstellen Aufgabenlisten und nennen sie Key Results. Dies führt zu einer Kultur des „Abhakens” von Aufgaben anstatt des Erreichens von Ergebnissen. Das Heilmittel: Stellen Sie immer die Frage „Na und?” „Wir haben Feature X geliefert.” -> „Na und?”. Die Antwort auf die zweite Frage ist wahrscheinlich ein guter Kandidat für ein KR.

2. Zu viele OKRs: Teams, begeistert vom neuen System, versuchen 5–7 ambitionierte Ziele und 5 OKRs für jedes einzelne zu setzen. Das ist ein direkter Weg zu Fokusverlust und Lähmung. Das Heilmittel: Die „Weniger ist mehr”-Regel. Das Team sollte nicht mehr als 1–3 Objectives pro Quartal haben, mit 2–4 Key Results für jedes einzelne. OKRs sollen die Frage beantworten: „Was ist in diesem Quartal absolut am wichtigsten?”

3. Hierarchisches Kaskadieren von OKRs: Traditionelles Management-Denken führt zum Versuch einer starren, top-down Kaskadierung von OKRs, bei der die Ziele eines Managers zu den Schlüsselergebnissen seiner Untergebenen werden. Das tötet Autonomie und Engagement. Das Heilmittel: Ziele sollten aufeinander abgestimmt (aligned) sein, nicht kaskadiert. Sobald die Unternehmens-OKRs bekannt gegeben werden, sollten Teams die Autonomie haben, ihre eigenen OKRs zu definieren, von denen sie glauben, dass sie am besten zu den übergeordneten Zielen beitragen. Der Prozess sollte eher netzwerkartig als hierarchisch sein.

4. Zu unambitionierte Ziele setzen („Sandbagging”): Wenn OKRs an das Bonussystem und die Mitarbeiterbewertung geknüpft sind, werden Menschen sofort beginnen, einfache, sichere Ziele zu setzen, die sie garantiert zu 100 % erreichen. Das tötet die gesamte Idee ambitionierter „Stretch Goals”. Das Heilmittel: OKRs sollten vollständig von Gehaltsbewertungen getrennt werden. OKRs sind ein Werkzeug für Navigation und Lernen, nicht für Bewertung.

5. „Setzen und Vergessen” (Set and Forget): Das Team definiert enthusiastisch OKRs zu Beginn des Quartals und kehrt erst am Ende zu ihnen zurück, um das Ergebnis zu überprüfen. In der Zwischenzeit haben OKRs keinen Einfluss auf die tägliche Arbeit. Das Heilmittel: OKRs müssen leben. Etablieren Sie ein regelmäßiges wöchentliches Ritual (z. B. ein 30-minütiges Meeting am Freitag), bei dem das Team den Fortschritt bei den OKRs überprüft, Probleme bespricht und Prioritäten für die folgende Woche im Kontext der Quartalsziele plant.

Die OKR-Implementierung ist ein Lernprozess. Das erste Quartal wird mit ziemlicher Sicherheit nicht erfolgreich sein. Entscheidend sind Geduld, Konsequenz und regelmäßige Retrospektiven, um den Prozess in den folgenden Zyklen anzupassen und zu verbessern.

Wie sieht ein Messsystem für eine moderne IT-Organisation aus, das KPIs und OKRs kombiniert?

Die nachstehende Tabelle zeigt ein beispielhaftes, vereinfachtes Modell, wie die kontinuierliche „Gesundheits”-Überwachung (KPIs) mit vierteljährlichen, ambitionierten Zielen (OKRs) in verschiedenen Verantwortungsbereichen einer Technologieorganisation kombiniert werden kann.

KategorieBeispiel-KPIs („Gesundheit des Systems")Beispiel-Objective (OKR-Ziel)Beispiel-Key Results (OKR-Schlüsselergebnisse)
**Zuverlässigkeit und Stabilität**Service-Verfügbarkeit (Uptime) > 99,9 %. Rate fehlgeschlagener Deployments (Change Failure Rate) < 15 %. Die legendäre Zuverlässigkeit unserer Flaggschiff-Plattform erreichen.Die Verfügbarkeit von 99,9 % auf 99,99 % steigern. Die mittlere Wiederherstellungszeit (MTTR) von 4 Stunden auf 30 Minuten reduzieren. Die Anzahl kritischer Produktionsalarme um 75 % senken.
**Geschwindigkeit und Durchsatz**Vorlaufzeit für Änderungsimplementierung (Lead Time) < 24h. Deployment-Frequenz > 1 Deployment/Tag. Unseren Wertlieferungszyklus drastisch beschleunigen, um schnellere Experimente zu ermöglichen.Die durchschnittliche Zeit vom Commit bis zum Deployment von 24 Stunden auf 2 Stunden reduzieren. Die Deployment-Frequenz von 1/Tag auf 10/Tag steigern.
**Produktqualität und UX**Kundenzufriedenheitswert (CSAT) > 8/10. Anzahl kritischer, von Kunden gemeldeter Fehler < 5/Monat. Unsere mobilen Nutzer mit einer nahtlosen und intuitiven Erfahrung begeistern.Die App-Store-Bewertung von 3,8 auf 4,7 steigern. Die App-Absturzrate von 1 % auf 0,1 % senken. Die Abschlussrate des zentralen Workflows um 40 % steigern.
**Geschäftswert**Retentionsrate > 90 %. Kundenakquisitionskosten (CAC). Customer Lifetime Value (LTV). Unsere kostenlose Produktversion in ein effektives Werkzeug zur Generierung zahlender Kunden verwandeln.Die Konversionsrate von kostenlos zu bezahlt von 2 % auf 5 % steigern. Den monatlichen Umsatz aus neuen Abonnements um 50 % erhöhen.

Benötigen Sie Unterstützung beim Testen? Entdecken Sie unsere Quality Assurance Services.

Lassen Sie uns Ihr Projekt besprechen

Haben Sie Fragen oder benötigen Sie Unterstützung? Kontaktieren Sie uns – unsere Experten helfen Ihnen gerne weiter.

Wie hilft ARDURA Consulting Organisationen bei der Implementierung von Messsystemen, die Ergebnisse vorantreiben?

Bei ARDURA Consulting verstehen wir, dass die Implementierung eines effektiven Messsystems eine der schwierigsten, aber zugleich wichtigsten Aufgaben einer Führungskraft ist. Es ist ein Prozess, der nicht nur Werkzeugkenntnisse erfordert, sondern vor allem die Fähigkeit, strategisch zu denken, kulturellen Wandel zu begleiten und ein tiefes Verständnis dafür, wie Technologie mit dem Geschäft verbunden werden kann.

Als vertrauenswürdiger Berater (Trusted Advisor) unterstützen wir unsere Kunden in jeder Phase dieser Reise:

  • Audit und Diagnose: Wir beginnen mit einer Überprüfung Ihrer aktuellen Kennzahlen und Prozesse. Wir helfen dabei, „Vanity Metrics” zu identifizieren und zu verstehen, wo die größten Lücken in Ihrem Messsystem liegen.

  • Systemdesign: Gemeinsam mit Ihrem Führungsteam entwerfen wir ein zusammenhängendes System, das die richtigen KPIs zur Gesundheitsüberwachung mit einem OKR-Framework zur Steuerung von Veränderungen kombiniert. Wir helfen bei der Definition erster, aussagekräftiger Kennzahlen und Ziele, die zu Ihrer Strategie und Ihrem Reifegrad passen.

  • Moderation und Implementierung: Wir unterstützen bei der praktischen Umsetzung des OKR-Zyklus. Wir führen Workshops für Teams durch und vermitteln, wie man gute Objectives und Key Results formuliert. Wir agieren als Coaches und Moderatoren in den ersten, schwierigsten Planungs- und Evaluierungszyklen und helfen dabei, gute Gewohnheiten aufzubauen.

  • Technologische Unterstützung: Wir beraten bei der Auswahl und Implementierung von Tools, die den Messprozess unterstützen – von Monitoring- und Observability-Plattformen bis hin zu Software für das OKR-Management. Unsere Engineering-Teams können bei der Automatisierung der Erfassung und Visualisierung wichtiger Kennzahlen helfen.

Bei ARDURA Consulting sind wir überzeugt: Unternehmen, die effektiv messen können, was zählt, gewinnen. Unser Ziel ist es, Ihnen einen Kompass und eine Navigation zu geben, die es Ihrer Organisation ermöglichen, sich nicht nur schnell, sondern vor allem in die richtige Richtung zu bewegen.

Wenn Sie das Gefühl haben, dass Ihre Teams beschäftigt, aber nicht unbedingt effektiv sind, und Sie Entscheidungen auf der Grundlage harter Daten statt Intuition treffen möchten, beraten Sie Ihr Projekt mit uns. Gemeinsam können wir ein System aufbauen, das Aufwand in echte Ergebnisse verwandelt.