Wer in den letzten Jahren in einer Strategie-Diskussion saß, kennt das Spiel. Irgendwer wirft ein: „Wir brauchen kein OKR, wir machen Hoshin Kanri." Oder andersrum: „Hoshin Kanri ist die strukturiertere Variante von OKR." Beides hört sich klug an. Beides ist falsch.
Die beiden Systeme werden gerne nebeneinandergestellt, als wären sie zwei Varianten desselben Werkzeugs. Sind sie nicht. Sie kommen aus unterschiedlichen Welten, lösen unterschiedliche Probleme und sind unter der Haube auch nicht halb so ähnlich, wie es das gemeinsame Buzzword „Zielsystem" vermuten lässt.
Ich gehe in diesem Artikel der Frage nach, warum Hoshin Kanri in der blauen (komplizierten) Welt stark ist und warum OKR in der roten (komplexen) Welt funktioniert – und was passiert, wenn man die beiden verwechselt.
Zwei Welten, zwei Logiken
Bevor wir zu den Systemen kommen, kurz die Grundunterscheidung. Gerhard Wohland hat den Farbcode blau/rot geprägt, um zwei sehr unterschiedliche Problemtypen voneinander zu trennen.[^1]
Blau – kompliziert. Ursache und Wirkung sind stabil. Vom selben Startpunkt komme ich immer am selben Ziel an. Eine Produktionsmaschine, ein Buchhaltungsprozess, eine Lieferkette. Ich brauche Wissen, kann es in Prozesse gießen und mit Disziplin abarbeiten. Überraschungen sind eher ein Defekt als eine Eigenschaft.
Rot – komplex. Ursache und Wirkung sind im Voraus nicht stabil zu erkennen. Markt, Kunde, Innovation, Mitarbeitermotivation. Pläne haben hier eine kurze Halbwertszeit. Was zählt, ist Können – also die Fähigkeit, im Handeln zu lernen.
Die einfache Test-Frage lautet: Muss ich mit Überraschungen rechnen? Wenn ja, ist die Situation rot. Wenn nein, ist sie blau.
Diese Trennung deckt sich auffallend gut mit Dave Snowdens Cynefin-Framework, das zwischen "complicated" (Ursache-Wirkung über Analyse erkennbar, "good practice" anwendbar) und "complex" (Ursache-Wirkung nur retrospektiv erkennbar, "emergent practice" nötig) unterscheidet.[^2] Im Komplizierten heißt die Handlungslogik Sense – Analyze – Respond. Im Komplexen Probe – Sense – Respond. Erst experimentieren, dann sehen, was emergiert, dann anpassen.
Diese Unterscheidung ist nicht akademisch. Sie ist der eigentliche Schlüssel zur Frage, welches Zielsystem zu welchem Problem passt.
Was Hoshin Kanri eigentlich ist
Hoshin Kanri (方針管理) entstand im Japan der Nachkriegszeit. „Hōshin" heißt so viel wie Richtung oder Kompassnadel, „Kanri" Steuerung oder Management.[^3] Die Übersetzung schwankt zwischen Policy Deployment, Strategy Deployment und gelegentlich Compass Management.
Die Wurzeln liegen im Total Quality Management der 1950er Jahre. Bridgestone Tire wird häufig als erstes Unternehmen genannt, das den Begriff 1965 formal eingeführt hat – in einem Bericht über die Planungspraktiken von Unternehmen, die den Deming-Preis gewonnen hatten.[^4] Wesentliche konzeptionelle Arbeit kam von Yoji Akao und Shigeru Mizuno.[^5] Toyota machte Hoshin Kanri ab 1979 zu einem zentralen Element seines Managementsystems, über das KanPro-Programm von Masao Nemoto.[^6] Bis 1975 war Hoshin Kanri in Japan etabliert, ab den 80er Jahren erreichte es die USA – über Hewlett-Packards Yokogawa-Tochter, Fuji-Xerox und Florida Power and Light.[^7]
Was macht Hoshin Kanri im Kern? Es übersetzt langfristige, oft 3- bis 5-jährige strategische Vorgaben („Breakthrough Objectives") über eine Kaskade in Jahresziele und in die Aktivitäten der einzelnen Abteilungen. Der Mechanismus hat einen Namen: Catchball. Eine Vorgabe von oben wird nicht einfach durchgestellt, sondern in mehreren Schleifen mit den unteren Ebenen verhandelt – wie beim Fangen-Spielen. Am Ende stehen abgestimmte, gemeinsam getragene Ziele, die mit dem PDCA-Zyklus (Plan-Do-Check-Act) operativ verfolgt werden.[^8]
Das ist – und das wird gerne übersehen – im Kern eine strukturierte Anwendung von PDCA auf die Makroebene des Unternehmens.[^9] PDCA ist ein Werkzeug zur Beherrschung kausaler Zusammenhänge. Es funktioniert genau dort, wo Ursache und Wirkung erkennbar sind. Wo sich also Standards definieren, abweichen, korrigieren und stabilisieren lassen.
Das ist nicht abwertend gemeint. Das ist seine Stärke.
Was OKR eigentlich ist
OKR hat eine ganz andere Genealogie. Peter Drucker führte 1954 Management by Objectives ein.[^10] Andy Grove griff das bei Intel ab 1968 auf, fand MBO aber zu langsam, zu bürokratisch, zu starr an Gehälter gekoppelt. Er nannte seine Version zuerst „iMBO" (Intel Management by Objectives) und schließlich OKR.[^11] John Doerr, sein Schüler bei Intel, trug das Konzept 1999 zu Google.[^12]
Grove war Halbleiter-Ingenieur. Sein Problem war nicht Effizienz auf einer stabilen Strecke, sondern Richtungswechsel im Ungewissen. Intel musste sich Anfang der 80er Jahre von Memory-Chips auf Microprozessoren umstellen – ein Sprung, für den es keine sichere Landkarte gab. Die berühmte „Operation Crush" lief unter OKR. Das ist kein Detail. Das ist der Geburtskontext: OKR entstand für eine Situation, in der die alten Antworten nicht mehr trugen.
Strukturell sieht OKR auf den ersten Blick simpel aus: ein qualitatives Objective (wohin?) plus drei bis fünf messbare Key Results (woran erkennen wir, ob wir auf dem Weg sind?). Drei Monate Zyklus. Volle Transparenz. Ein Drittel ambitionierter als gewohnt.
Unter der Haube sind aber zwei Dinge entscheidend, die im Hoshin Kanri so nicht vorkommen:
Erstens: lose Kopplung. Teams formulieren ihre OKR selbst. Es gibt keine top-down zugeteilten Ziele. Ein Team orientiert sich an Vision, Purpose und einem Midterm Goal (Moal), aber niemand schreibt ihm vor, welche Objectives es zu haben hat. Autonomie ist hier nicht Kosmetik, sondern ein systemisches Strukturelement.
Zweitens: Key Results sind keine Performance-Vorgaben, sondern Wetten auf die Zukunft. Ein Key Result formuliert eine Hypothese darüber, was wahrscheinlich zum Objective führen wird. Wenn sich unterwegs herausstellt, dass die Hypothese falsch ist, wird das Key Result abgebrochen – nicht weiterverfolgt. Genau dafür sind die kurzen Zyklen da.
OKR ist also gebaut, um Lernen zu ermöglichen, nicht um Pläne durchzudrücken.
Wo der Unterschied wirklich liegt
Wenn man die beiden Systeme nebeneinanderlegt, sieht man strukturell sehr ähnliche Elemente: Ziele, Kaskade, regelmäßige Reviews, Beteiligung der Mitarbeitenden. Trotzdem sind die Logiken dahinter diametral.
Hier die Punkte, an denen sich die beiden Welten klar trennen:
Problemtyp. Hoshin Kanri operiert in der blauen Welt: stabile Ursache-Wirkungs-Ketten, planbare Märkte, Optimierung bekannter Prozesse. OKR operiert in der roten Welt: Marktverschiebungen, Innovationen, Verhalten von Kunden, Mitarbeiter-Engagement.
Steuerungsrichtung. Hoshin Kanri ist im Kern strict cascading – Catchball mildert das ab, ändert aber die Richtung nicht. Strategische Vorgaben kommen von oben und werden nach unten verfeinert.[^13] OKR ist loosely coupled: Ausrichtung über geteilten Sinn (Vision, Purpose, Moal), nicht über delegierte Ziele.
Verhältnis zum Plan. In Hoshin Kanri ist der Mehrjahresplan ein zentrales Artefakt. Toyota hat klassisch 3- bis 5-Jahres-Targets, dazu Annual Targets, dazu konkrete Countermeasures.[^14] OKR hat keinen Mehrjahresplan in diesem Sinne. Es hat ein orientierendes Zielbild (Moal) und Quartalszyklen. Mehr braucht es in der roten Welt nicht – und mehr würde auch nur Scheinsicherheit erzeugen.
Umgang mit Überraschung. In der blauen Welt ist Abweichung ein Fehler, der korrigiert werden muss. Im PDCA-Zyklus heißt der Check-Schritt genau das: Soll-Ist-Vergleich, dann Maßnahme. In der roten Welt ist Abweichung Information. Ein Key Result, das nicht funktioniert, ist nicht ein Fehler, sondern ein Lerngewinn. „Fail fast, fail often, fail forward" – nicht weil Scheitern romantisch wäre, sondern weil im Komplexen das Lernen über Irrtum schneller geht als über Analyse.
Motivation. Hoshin Kanri arbeitet mit klaren Vorgaben, deren Erreichung gemessen und nachgehalten wird. Das ist extrinsisch geprägt – nicht zwangsläufig schlecht, aber strukturell ein extrinsisch motiviertes System zur Beherrschung kausaler Herausforderungen. OKR setzt auf intrinsische Motivation: Autonomie, Mastery, Purpose im Sinne von Daniel Pink. Das funktioniert nur, wenn Teams wirklich Eigentümer ihrer Ziele sind.
Was misst der Zielerreichungsgrad? Im Hoshin Kanri ist eine 100%-Erreichung das, was angestrebt wird. Im OKR ist eine konstante 100%-Erreichung ein Warnzeichen: zu unambitioniert. Aber – und das wird oft missverstanden – die Zielerreichung im OKR ist auch nicht die Performance des Teams. Sie sagt nur, zu wieviel Prozent ein Key Result umgesetzt wurde. Mehr nicht. Wenn das Team unterwegs merkt, dass ein Key Result die Performance gefährdet, bricht es ab – auch bei 30%. Diese Haltung ist im Hoshin Kanri systemfremd.
Warum die Verwechslung gefährlich ist
Es gibt zwei typische Fehler, die ich in der Praxis immer wieder sehe.
Fehler 1: Hoshin Kanri einführen, wo eigentlich OKR nötig wäre.
Das Unternehmen steht vor disruptiven Marktveränderungen. Niemand weiß genau, was funktionieren wird. Statt mit OKR Hypothesen zu testen, wird ein sauberer 3-Jahres-Plan ausgerollt, schön kaskadiert, mit X-Matrizen und Catchball-Schleifen. Sechs Monate später passt der Plan nicht mehr, aber die Organisation hat sich darauf festgenagelt. Reibung, Verzögerung, Scheinsteuerung.[^15] Klassische Fehlanwendung: blaues Werkzeug gegen rotes Problem.
Fehler 2: OKR einführen, wo Hoshin Kanri ausgereicht hätte.
Eine Produktionsstätte hat ein klar kompliziertes Problem: Durchlaufzeit reduzieren, Ausschussquote senken, OEE verbessern. Das sind alles Probleme, deren Ursache-Wirkung im Wesentlichen bekannt ist. Hier funktioniert PDCA, hier funktioniert Hoshin Kanri, hier funktioniert Lean. OKR mit Quartalszyklen und Bottom-up-Findung obendrauf zu legen, fühlt sich modern an, erzeugt aber vor allem Overhead ohne entsprechenden Mehrwert.
Die Frage „Brauchen wir OKR oder Hoshin Kanri?" ist also eigentlich falsch gestellt. Die richtige Frage lautet: „Mit welcher Art von Problem haben wir es zu tun?"
Wer das nicht trennt, optimiert mit blauen Werkzeugen rote Probleme und experimentiert mit roten Werkzeugen über blaue Probleme. Beides ist teuer.
Und in der Realität? Beides – aber sauber getrennt
Die meisten Unternehmen haben beides – komplizierte und komplexe Anteile. Eine Produktionsstraße ist kompliziert. Das Geschäftsmodell, mit dem das Produkt am Markt landet, ist komplex. Die Finanzbuchhaltung ist kompliziert. Die Frage, ob die Kunden in fünf Jahren noch zahlen werden, ist komplex.
Das heißt nicht, dass man beide Systeme parallel braucht. Es heißt aber, dass man die Anteile sauber unterscheiden muss – und dann das jeweils passende Werkzeug nimmt. Lean und Hoshin Kanri für den blauen Anteil. OKR für den roten.
Was nicht funktioniert, ist die Mischung: OKR mit X-Matrix unterlegen, weil das „strukturierter" wirkt. Oder Hoshin Kanri „agilisieren", indem man Quartalsschleifen einbaut. Das eine zerstört die Autonomie, die OKR braucht. Das andere zerstört die Stabilität, von der Hoshin Kanri lebt.
Was bleibt
Hoshin Kanri ist ein hervorragendes System – für die blaue Welt. Toyota hat das nicht ohne Grund seit Jahrzehnten institutionalisiert, in der Welt der Fertigung, der Qualität, der kontinuierlichen Verbesserung kausaler Prozesse. Das ist seine Domäne. Dort ist es schwer zu schlagen.
OKR ist ein hervorragendes System – für die rote Welt. Andy Grove hat es nicht entwickelt, um Fabriken zu optimieren, sondern um Intel durch einen Marktwechsel zu navigieren, den keiner vorhersagen konnte. Das ist seine Domäne.
Wenn ich für meinen Kontext klar entscheide, was rot ist und was blau, kann ich beide Werkzeuge nutzen, ohne sie zu verwechseln. Wenn ich die Welten vermenge, bekomme ich ein System, das beides halb kann – und nichts richtig.
Das ist am Ende kein Methodenstreit, sondern eine Frage des Hinsehens.
Quellen
[^1]: Wohland, G. & Wiemeyer, M. (2007). Denkwerkzeuge der Höchstleister – Warum dynamikrobuste Unternehmen Marktdruck erzeugen. Murmann Verlag. Wohland hat den Farbcode blau/rot ab 2006 in den Diskurs eingeführt, nicht verwandt mit „Blue Ocean / Red Ocean".
[^2]: Snowden, D. J. & Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, November 2007. – Cynefin unterscheidet zwischen Clear, Complicated, Complex, Chaotic und Disorder. Für jede Domäne gilt eine andere Handlungslogik (Sense-Categorize-Respond, Sense-Analyze-Respond, Probe-Sense-Respond, Act-Sense-Respond).
[^3]: Roser, C. (2025). Hoshin Kanri and the Kanri Noryoku Program: Rejuvenating Toyota. AllAboutLean.com. URL: https://www.allaboutlean.com/kanri-noryoku-program/
[^4]: Lean Enterprise Institute (2025). Hoshin Kanri as a Foundational Piece of a Lean Management System. URL: https://www.lean.org/the-lean-post/articles/hoshin-kanri-as-a-foundational-piece-of-a-lean-management-system/. Bridgestone publizierte 1965 die Ergebnisse einer Studie über Hoshin-Kanri-Aktivitäten verschiedener japanischer Unternehmen.
[^5]: Akao, Y. (Hrsg., 1991). Hoshin Kanri: Policy Deployment for Successful TQM. Productivity Press. – Akao gilt zusammen mit Shigeru Mizuno als wesentlicher Architekt der Methode.
[^6]: Sugiura, T. (2017). Global Ten: A History of Hoshin Management at Toyota. (グローバルテン). Toyota institutionalisierte Hoshin Kanri ab 1979 unter Masao Nemoto über das Kanri-Noryoku-Programm (KanPro).
[^7]: Shingo Institute. Hoshin Kanri: Translating "Big Vision" from Strategy to Execution. URL: https://shingo.org/hoshin-kanri-translating-big-vision-from-strategy-to-execution/. Bis 1975 war Hoshin Kanri in Japan etabliert, in den 80ern erreichte es die USA über Yokogawa-HP, Fuji-Xerox und FPL.
[^8]: Jackson, T. L. (2006). Hoshin Kanri for the Lean Enterprise: Developing Competitive Capabilities and Managing Profit. Productivity Press. – Catchball, X-Matrix und PDCA als Kern des Hoshin-Kanri-Vorgehens.
[^9]: Lean Enterprise Institute (2025), ebd. Sugiura beschreibt Hoshin Kanri als „strukturierte Anwendung von PDCA auf die Makroebene des Unternehmens".
[^10]: Drucker, P. F. (1954). The Practice of Management. Harper & Brothers, New York. – Erstmalige Formulierung von Management by Objectives.
[^11]: Grove, A. S. (1983). High Output Management. Random House. Kapitel zu „Objectives and Key Results" mit der Grundformulierung. Bei Intel intern zunächst als iMBO bezeichnet.
[^12]: Doerr, J. (2018). Measure What Matters – How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio/Penguin. – Doerrs Schilderung der Einführung von OKR bei Google 1999.
[^13]: Lobacher, P & Jacob C.(2026). OKR – Theorie 3. Auflage: „Letztlich arbeiten Systeme wie Balanced Score Cards (BSC) und Hoshin Kanri, aber auch OGSM und verwandte Systeme exakt nach der strict cascading Logik und sind damit weitestgehend unwirksam in einer komplexen Welt."
[^14]: Art of Lean (2026). Hoshin Kanri – TPS Encyclopedia. URL: https://artoflean.com/reference/hoshin-kanri/. Toyota strukturierte ab 1967 in Basic Hoshin, Annual Slogans, Long-term Targets (5 Jahre), Long-term Countermeasures (3-5 Jahre), Annual Targets und Annual Countermeasures.
[^15]: Lobacher, P. & Jacob, C. (2024). OKR ist tot! Hoch lebe AOA, Big Goals, CFR, OGSM, Hoshin Kanri, 4DX, BSC... URL: https://www.die-agilen.de/blog/okr-ist-tot-hoch-lebe-aoa-big-goals-cfr-ogsm-hoshin-kanri-4dx-bsc
