Die OKR Architektur ist die zweite tragende Säule des OKR Rahmenwerks Und vielleicht auch der anspruchsvollste Baustein im Rahmen einer OKR Einführung. 

In diesem Beitrag erkläre ich den Aufbau einer zielführenden OKR Architektur. Dazu gehe ich erst auf den idealtypischen Aufbau ein und zeige dir im Anschluss, wie Du eine OKR Architektur entwickelst. Wenn Du dir zunächst einen Überblick zur OKR Methode verschaffen möchtest, findest Du hier einen Beitrag zu den Grundlagen des OKR Frameworks. Oder Du lädst dir einfach unseren OKR Guide herunter. 

Idealtypischer Aufbau deiner OKR Architektur

Eine idealtypische OKR Architektur hat zwei Ebenen.

1. Top Level OKR: Auf der obersten Ebene deiner OKR Architektur definierst Du übergeordnete Ziele für die gesamte Organisation mit einem zeitlichen Horizont von  12-36 Monaten. 
2. Team OKR: Auf der darunter liegenden Ebene formulieren Teams ihre OKR mit einem zeitlichen Horizont von 2-4 Monaten. 

Durch einen gut gemanagten OKR Zyklus sorgst Du schließlich dafür, dass Teams mit ihren OKR für die Ziele der Organisation arbeiten bzw. diese ermöglichen. So werden kurzfristige Team OKR zum Hebel für die Erreichung deiner mittelfristigen Ziele. 

Die oberste Ebene deines OKR Systems

Was Du nun als oberste Ebene deiner OKR Architektur definierst, hängt von deinem Kontext und dem Einsatzbereich der OKR Methode ab. Hier ein paar typische Anwendungsfälle aus meiner Beratungspraxis:

• Unternehmen: Du setzt OKR für dein gesamtes Unternehmen ein. 
• Geschäftsbereiche: Wenn dein Unternehmen bereits in eigenständigen und unabhängigen Geschäftsbereichen organisiert ist, dann formulierst Du OKR für einzelne Geschäftsbereiche statt allgemeingültigen Unternehmens OKR. 
• Produktzentrierte Organisation: Wenn dein Unternehmen mehrere “Flagship” Produkte hat, kannst Du auch Top Level OKR zu deinen Produkten formulieren. Das ist gerade für IT- und servicelastige Geschäftsmodelle ein gutes Vorgehen.
• Programme: Du definierst Top Level OKR auf einer Programmebene, Projektteams arbeiten mit Team OKR.

Je diverser dein Unternehmen ist oder auch der Kontext, in dem Du dich mit OKR bewegst, desto größer ist die Gefahr, generische Top Level OKR zu formulieren. Deswegen ist die Definition der Top Level Ebene die erste wichtige Entscheidung beim Aufbau deiner OKR Architektur.  

Flache Strukturen statt vieler Ebenen

In meiner OKR Beratung versuche ich die OKR Architektur konsequent flach zu halten. Das heißt, eine Top Level Ebene, darunter Team OKR. Wenn ein Unternehmen jedoch mehrere Führungs- und Hierarchieebenen hat, ist es ein spontaner Impuls, dass jede Führungsebene ihre eigenen OKR definiert. Das steigert jedoch die Komplexität und erhöht den Aufwand. Deswegen würde ich darauf gerade am Anfang deiner Arbeit mit OKR unbedingt verzichten. Aus diesem Grund braucht es im Rahmen deiner OKR Einführung auch ein wenig Dialog und Denkarbeit, wie die Führungslinien und -rollen effektiv in das OKR System einbezogen werden. Z.B. können sie abgeleitet aus den Top Level OKR Maßnahmen priorisieren und den OKR Teams als Coach zur Seite stehen.

Die Mischung macht’s: Top Down vs Bottom Up

Eine tragfähige OKR Architektur setzt auf eine ausgewogene Mischung aus Top Down Vorgaben und Bottom Up Engagement. Um dieses Spannungsverhältnis gut zu navigieren, kannst Du dich an den folgenden beiden Extrempunkten orientieren:

• Leitungsteams geben Top Level OKR vor, dürfen sich dabei aber auch von den Teams oder der gesamten Organisation beraten lassen.
• Teams formulieren ihre eigenen OKR, die in direkter Verbindung zu den Top Level OKR stehen. Das Management gibt im Rahmen des Planning Feedback zu den anvisierten OKR. 

In einem gut gemanagten OKR Prozess lernst Du schließlich, welche top down /bottom up Mischung für deine Organisation förderlich ist. 

For team-level goals, recognize that not every organizational OKR needs to be reflected in every team OKR. It’s possible that a team’s OKRs will focus on just one of the organizational OKRs. But there should be some connection between team OKRs and at least one of the organizational OKRs.

re:Work – wie Google mit OKR arbeitet

	Top Level OKR	Team OKR
Betreffen	Unternehmen oder Geschäftsbereich oder Produkt oder Programm	Team
Anzahl	1-5	1-3 pro Team
Zeitraum	12-36 Monate	2-4 Monate
Zuständig	Leitungsteam, Management	Team

Eine zielführende OKR Architektur entwickeln

Unabhängig von deinem jeweiligen Kontext würde ich bei der Entwicklung deiner OKR Architektur einem einfachen Prinzip folgen: Erst die Gesamtziele verstehen, dann über Teams und genaue Strukturen reden. 

Schritt 1: Top Level OKR formulieren

Bevor Du sinnvoll über deine OKR Architektur sprechen kannst, solltest Du zunächst deine Ziele kennen. Das heißt, im ersten Schritt formulierst Du mit den jeweiligen Stakeholdern mittelfristige strategische Ziele für die nächsten 12-36 Monate als OKR. Diese beziehen sich auf dein Unternehmen, einzelne Geschäftsbereiche, Produkte oder eben ein Programm. Das kann frei oder in einem moderierten OKR Workshop passieren. Im Rahmen dieser Diskussion legst Du fest, ob deine Top Level OKR für 12, 24 oder 36 Monate gelten. 

Den passenden OKR Zyklus definieren

Die Länge deiner OKR Zyklen hängt davon ab, wie klar Du in deinen Zielen bist und wie dynamisch Du dein Umfeld einschätzt. Wichtig ist nur, dass Du dich auf einen Zeitraum festlegst. Für den Anfang ist ein 12-monatiges Top Level Intervall mit einem 3-monatigen Zyklus für Teams in fast allen Fällen “good enough for now, safe enough to try”. Und wenn das nicht passt, merkst Du das in einem gut aufgesetzten OKR Prozess und passt dein Vorgehen basierend auf echten und empirischen Erkenntnissen an. 

Schritt 2: Themen priorisieren

Im zweiten Schritt definierst Du, abgeleitet aus deinen Zielen und unabhängig von deiner heutigen Struktur, die Themen, die unbedingt angeschoben werden müssen, um die anvisierten Top Level OKR zu erreichen. Das kann durch das Management passieren oder Du setzt in diesem Schritt bereits auf die Schwarmintelligenz deiner Organisation. Z.B. indem du die Frage stellst, welche Themen unbedingt bearbeitet werden sollten, damit deine Organisation den nächsten sinnvollen Entwicklungsschritt machen und ihre Ziele erreichen kann. Diese Themen sammelst und priorisiert Du, so entsteht sozusagen ein Backlog wichtiger Initiativen. Hier findest Du eine Vorlage, um eine solche Befragung einfach durchzuführen und ein Vorgehensmodell zur Priorisierung.

Schritt 3: Teams identifizieren 

Im dritten Schritt überlegst Du schließlich erst, welche Teams Du genau einsetzt bzw. brauchst, um deine wichtigen Maßnahmen umzusetzen und Gesamtziele zu erreichen. Dabei wäre es ein Fehler anzunehmen, dass deine heutige Aufbauorganisation die erste Wahl für deine OKR Architektur ist.

Warum deine Aufbauorganisation nicht die beste Wahl für deine OKR Architektur ist

Es könnte so einfach sein, aber deine Aufbauorganisation ist selten die beste Wahl für dein OKR System. Hier ein paar Argumente, die zumindest dafür sprechen, etwas genauer über deine OKR Architektur nachzudenken.

1. Funktionale Teams: Je funktionaler eine Organisation und damit einzelne Teams aufgestellt sind, desto schwieriger ist eine outcomeorientierte OKR Formulierung. Dann ist die Gefahr groß, dass OKR nur Aktivitäten beinhalten. 
2. Komplexität und Qualität: In Aufbauorganisationen zu denken, führt schnell zu einer verfrühten Skalierung und zu vielen OKR. Das erhöht vor allem in Verbindung mit dem ersten Punkt die Komplexität, den Aufwand im OKR Prozess und zu vielen schlecht formulierten OKRs. 
3. Transformation: Vielleicht steckst Du ja mitten in einer Transformation und der Umbau der vorhandenen Organisation ist ein wichtiger Katalysator dafür. Warum solltest Du also ein suboptimales Relikt des 20. Jahrhunderts mit einer modernen Methode noch weiter zementieren?

Deswegen solltest Du ein wenig Abstand von deiner Aufbauorganisation nehmen und vor allem in crossfunktionalen Teams denken.

Crossfunktionale OKR Organisation

Ich denke und arbeite als OKR Berater lieber in Projekt- als in bestehenden Aufbauorganisationen, um die Arbeit in und mit crossfunktionalen Teams zu fördern. Das hat mehrere Vorteile:

1. Chance auf echte Outcomes. In einer crossfunktionalen Besetzung haben Teams die Chance auf echte Outcomes.
2. Weniger Abhängigkeiten: Je crossfunktionaler ein Teams, desto weniger Abhängigkeiten hast Du. Das reduziert die Komplexität deiner OKR Architektur.  
3. Höhere Klarheit. Gerade während einer Transformation sind Mitarbeiter “zerrissen” zwischen den “business as usual” Aktivitäten und der Arbeit an der strategischen Entwicklung. Das wird besonders schlimm, wenn Du im Rahmen deiner OKR Einführung versäumst, klassische Zielsysteme und -vorgaben wie z.B. eine Umsatz- und Ergebnisplanung sinnvoll in dein OKR System zu integrieren. 
4. Neues Arbeiten: Wie sinnvoll und tragfähig funktionale Aufbauorganisationen dauerhaft sind, darfst Du selbst entscheiden. Ich bin skeptisch, dass Unternehmen in einer VUCA Welt mit einer funktionalen Aufbauorganisation dauerhaft Erfolg haben werden. So kannst Du im Rahmen einer crossfunktionalen OKR Organisation bereits erste Erfahrungen mit neuen Arbeitsmethoden sammeln.

Dabei ist wichtig, dass Du die Arbeit in der OKR Organisation mit klaren Regeln versiehst. Zum Beispiel legst Du fest, dass ein Mitglied 2 Tage pro Woche damit verbringen darf und soll. Schließlich ist es ein strategisch wichtiges Thema.

OKR Architektur als duale Organisation denken

Eine letzte Überlegung ist, dass du deine OKR Organisation mit den Ideen einer dualen Organisation nach John Kotter verzahnst. Dabei ist die klassische Hierarchie der Organisation, die stabile Seite, die sich um das “daily business” kümmert. Wichtige strategische Initiativen werden über ein agiles Netzwerk mit OKR geführt. Auf hoher Abstraktionsebene ist das ähnlich wie bei einer Projektorganisation, allerdings geht John Kotter in seinen Überlegungen zur dualen Organisation deutlich weiter.

OKR Im Rahmen einer Projektorganisation

Zum Abschluss noch ein paar Gedanken, wie Du OKR ausschließlich zur Steuerung im Rahmen einer Projektorganisation einsetzt. Das heißt, statt ein gesamtes Unternehmen mit OKR zu führen, begrenzt Du den Einsatz von OKR auf ausgewählte Projekte oder Programme wie z.B. die Umsetzung deiner Digitalstrategie. 

Steuerung von einzelnen Initiativen / Projekten

Sofern Du ein Portfolio von einander unabhängigen Projekten mit OKR steuern möchtest, kann ein Vorgehen wie folgt aussehen.

1. Projektziele werden wahlweise als OKR formuliert.
2. Projektteams arbeiten in einem 3-Monatszyklus an ihren OKR.
3. Projektteams kommunizieren regelmäßig ihre Confidence Level in Bezug auf die anvisierte Zielerreichung.
4. Lenkungsausschüsse werden durch Demos zum Ende eines OKR Prozesses ersetzt
5. Alle OKR Events sind “all hands” mit allen beteiligten Projektteams und Stakeholdern. 

Steuerung eines Programms

Sofern Du ein Programm bestehend aus mehrere (Teil)Projekten steuerst, kannst Du deine OKR Architektur wie folgt aufsetzen:

1. Auf Programmebene formulierst Du Gesamtziele, wahlweise auch als Top Level OKR. Dabei kannst Du ebenfalls auf einen jährlichen Zyklus gehen oder Du formulierst ein finales Ziel des Programms als OKR.
2. Zu Beginn eines OKR Zyklus gehen alle beteiligten Projektteams gemeinsam in ein Planning und formulieren 3-Monats OKR. 
3. Projektteams kommunizieren regelmäßig ihre Confidence Level in Bezug auf die anvisierte Zielerreichung.
4. Lenkungsausschüsse werden durch die Demos zum Ende eines OKR Prozesses ersetzt.
5. Alle OKR Events sind “all hands” mit den beteiligten Teams und Stakeholdern. 

Umsetzung deiner Digitalstrategie

Auch die Umsetzung deiner Digitalstrategie kannst Du mit OKR steuern. Schließlich manifestiert sich deine Digitalstrategie über ein Portfolio von konkreten Initiativen und Projekten. Deswegen kannst Du OKR zur Steuerung deiner Digitalstrategie weitgehend identisch zu den oben skizzierten Punkten einsetzen.

1. Du definierst ein Portfolio digitaler Initiativen und Projekte. Bei einer großen Anzahl von Projekten kannst Du diese auch in thematischen Clustern und Handlungsfeldern zusammenfassen (z.B. interne Prozesse, digitales Marketing, neue Geschäftsmodelle etc.). 
2. Nun kannst Du zu jedem Cluster, analog zum Vorgehen bei einem Programm, eigene Top Level OKR formulieren.
3. Projektteam formulieren wiederum OKR in einem 3-Monats-Rhythmus. 
4. Projektteams kommunizieren regelmäßig ihre Confidence Level in Bezug auf die anvisierte Zielerreichung.
5. Lenkungsausschüsse werden durch die Demos zum Ende eines OKR Prozesses ersetzt.
6. Alle OKR Events sind “all hands” mit den beteiligten Teams und Stakeholdern. 

Fazit – OKR Architektur ist echte “Denkarbeit”

Eine gute OKR Architektur ist die halbe Miete für eine erfolgreiche Arbeit mit OKR. Denn es geht nicht darum, einfach jeden Mitarbeiter mit OKR zu beglücken. Sondern darum, abgeleitet aus deinen Gesamtzielen die richtige Konfiguration für dein OKR zu definieren und in einem gut gemanagten OKR Prozess laufend anzupassen.

Viel Erfolg dabei.