OKR-Kaskade für KMU: die Vorlage, die wir mit Loop nutzen
Eine OKR-Kaskade, die im KMU wirklich funktioniert, passt auf eine Seite: ein Company-Objective, drei Department-OKRs, pro Rolle eine messbare Kennzahl. So bauen wir sie mit Loop, inklusive Vorlage und Beispiel aus einem 42-Personen-Betrieb.
Jeder kennt OKRs aus Büchern. Fast niemand hat eine Kaskade, die im KMU-Alltag hält. Hier ist die Vorlage, die wir bei ChangeMy.AI in jedem Loop-Workshop nutzen, das Beispiel aus einem 42-Personen-Betrieb, und die drei Fehler, die die Kaskade in KMU meistens zerlegen.
TL;DR
- Eine OKR-Kaskade für ein KMU passt auf eine Seite: ein Company-Objective, drei Department-OKRs, pro Rolle eine Kennzahl.
- Oben stehen OKRs (Company, Department), unten KPIs (Role, Agent). Das trennt Veränderungsziele von Betriebszahlen.
- Jede Ebene braucht einen Judge, der beurteilt, ob die Zahl wirklich erreicht ist. Sonst wird gerechnet, nicht geliefert.
- KI-Agenten hängen an der untersten Ebene und zahlen genauso auf das Company-Ziel ein wie Menschen.
- Vorlage und Beispiel in diesem Artikel; die interaktive Version baust Du in 3 Minuten mit dem Loop Architekt.
Warum die meisten OKR-Kaskaden in KMU scheitern
Die drei Klassiker aus der Praxis:
- Zu viele Ziele. Ein KMU kopiert die Google-Vorlage: 5 Company-Objectives, 4 Key Results pro Objective, dann pro Abteilung nochmal. Nach zwei Quartalen kann niemand mehr sagen, was Priorität war.
- Keine Verbindung nach unten. Company-OKRs stehen in einem Deck, die Rolle im Vertrieb hat ihre eigene Zielvorgabe, und keiner rechnet nach, ob das eine auf das andere einzahlt. Ergebnis: lokal optimiert, global stagniert.
- Kein Judge. "Umsatz +15 %" ist erreicht, wenn die Zahl im BI-Tool steht. Aber niemand fragt, ob die 15 % aus Neukunden oder aus Preiserhöhungen kamen. Die Zahl ist grün, das Ziel verfehlt.
Loop löst alle drei über eine feste Struktur.
Die Loop-Kaskade auf einen Blick
Vier Ebenen, jede mit einer klaren Aufgabe:
| Ebene | Wer | Was misst er | Beispiel |
|---|---|---|---|
| Company | Geschäftsführung | 1 Objective, 3 Key Results | "Wir wachsen kontrolliert auf 8 Mio. €" |
| Department | Abteilungsleitung | 1 Objective pro Abteilung, je 2 bis 3 Key Results | Vertrieb: "Wir schließen 20 % mehr Deals mit gleicher Pipeline" |
| Role | Mitarbeiter | 1 bis 2 KPIs pro Rolle | Innendienst: "Angebots-Durchlaufzeit unter 24 h" |
| Agent | KI-Agent | 1 messbare Kennzahl mit Judge | Angebots-Agent: "80 % der Standard-Angebote in <2 h draftfähig" |
Die Regel: Jede Ebene muss auf die Ebene darüber einzahlen. Wenn der Agent seine Kennzahl erreicht, verbessert sich die KPI der Rolle. Wenn alle Rollen ihre KPIs treffen, wird das Department-Objective erreicht. Und so weiter.
Das ist keine Theorie, das ist die Prüffrage. Für jedes Ziel auf jeder Ebene fragt der Loop-Workshop: "Auf welches Ziel eine Ebene höher zahlt das ein?" Findet sich keine Antwort, ist das Ziel raus.
Die Vorlage
Kopier das für Deinen nächsten Workshop:
```
COMPANY (Q1 – Q4)
Objective: <Ein Satz, was am Ende des Jahres anders ist>
KR1: <messbar, Zahl mit Deadline>
KR2: <messbar>
KR3: <messbar>
DEPARTMENT: <Name>
Objective: <Ein Satz, wie diese Abteilung zum Company-Objective beiträgt>
KR1: <messbar>
KR2: <messbar>
Zahlt ein auf: Company-KR<n>
ROLE: <Rollenname>
KPI1: <laufende Kennzahl, wöchentlich sichtbar>
KPI2: <optional>
Zahlt ein auf: Department-KR<n>
AGENT: <Agentenname>
Kennzahl: <eine, messbar>
Judge: <wer/was beurteilt Erreichung>
Autonomie: <Mensch macht / Mensch prüft / Autonom>
Zahlt ein auf: Role-KPI<n>
```
Wichtig: Die letzte Zeile jeder Ebene ("Zahlt ein auf …") ist kein Detail. Sie ist der ganze Sinn der Kaskade. Ohne sie hast Du eine Liste, keine Kaskade.
Beispiel: 42-Personen-Betrieb aus dem Maschinenbau
Anonymisierter Ausschnitt aus einem Loop-Workshop, den wir Ende 2025 mit einem österreichischen Zulieferer gemacht haben (Umsatz ~9 Mio. €, klassisches KMU, viel gewachsene IT).
Company
- Objective: Wir liefern spürbar schneller, ohne die Marge zu opfern.
- KR1: Durchlaufzeit vom Anfrage-Eingang bis zum Angebot: von Ø 5 Tagen auf Ø 2 Tage.
- KR2: Angebots-Erfolgsquote von 22 % auf 30 %.
- KR3: EBIT-Marge stabil ≥ 11 %.
Department: Vertrieb
- Objective: Angebote sind schnell, präzise, und der Kunde hört von uns, bevor er nachfragt.
- KR1: 90 % der Anfragen mit einem qualifizierten Angebot innerhalb von 24 h beantwortet.
- KR2: Follow-up-Rate offener Angebote nach 7 Tagen: 100 %.
- Zahlt ein auf: Company-KR1 und Company-KR2.
Role: Innendienst-Sachbearbeiter:in
- KPI1: Durchschnittliche Bearbeitungszeit pro Standardanfrage < 45 min.
- KPI2: Anteil vollständig ausgefüllter Anfragen (kein Nachfragen) > 80 %.
- Zahlt ein auf: Department-KR1.
Agent: Angebots-Assistent (KI)
- Kennzahl: 80 % aller Standard-Anfragen werden als Angebotsentwurf in < 30 min bereitgestellt.
- Judge: Innendienstleitung, wöchentliches Sampling von 10 Angeboten (korrekt konfiguriert? Preise plausibel? Kunde adressiert?).
- Autonomie: Mensch prüft (25/100). Der Agent draftet, der Sachbearbeiter gibt frei.
- Zahlt ein auf: Role-KPI1.
Alles auf einer Seite. Jede Zeile trägt eine Zeile höher.
Was der Judge macht (und warum ohne ihn nichts funktioniert)
Der Judge ist die stille Innovation in der Loop-Kaskade. Für jedes messbare Ziel gibt es eine Person oder eine Kennzahl, die beurteilt, ob das Ziel wirklich erreicht ist. Nicht ob die Zahl grün ist, sondern ob sie den erhofften Effekt hat.
Beispiel Angebots-Agent: Er könnte technisch 90 % Trefferquote schaffen, indem er nur die einfachsten Anfragen bearbeitet und schwierige aussortiert. Zahl grün, Ziel verfehlt. Der Judge (Innendienstleitung) sampelt jede Woche zehn Angebote und beurteilt Qualität und Anteil an Standard vs. Sonder. Sinkt die Qualität, wird die Autonomie zurückgedreht.
Judges gibt es auf jeder Ebene. Auf Company-Ebene ist es der Aufsichtsrat oder ein externer Sparringspartner. Auf Department-Ebene die Geschäftsführung. Auf Rollen-Ebene die Abteilungsleitung. Auf Agent-Ebene die Rolle selbst.
Wo die KI-Agenten in die Kaskade eingehängt werden
Zwei Regeln machen KI-Agenten in einer Loop-Kaskade beherrschbar:
- Ein Agent hängt immer an einer Rolle, nie direkt an einer Abteilung. So bleibt klar, wer verantwortlich ist. Wenn der Angebots-Assistent liefert, ist es die Leistung des Innendienstes, nicht "der KI". Wenn er schlecht liefert, weiß die Innendienstleitung, was zu tun ist: nachjustieren oder abschalten.
- Autonomie wird verdient. Ein neuer Agent startet auf 25/100 ("Mensch macht's, KI schlägt vor"). Erst wenn der Judge über mehrere Wochen grün gibt, wird auf 50 ("Mensch prüft") erhöht. 100 ("Autonom") bleibt Ausnahme.
Das ist der Unterschied zwischen "wir bauen mal einen ChatGPT-Prompt" und einer OKR-Kaskade, in der KI messbar auf das Unternehmensziel einzahlt.
Der Ein-Seiten-Test
Wir schließen jeden Loop-Workshop mit demselben Test ab: Die komplette Kaskade wird auf ein A4-Blatt gedruckt. Passt nicht drauf, war zu viel. Steht der Chef vor dem Blatt und kann in 60 Sekunden erklären, wie ein Angebots-Agent auf die EBIT-Marge einzahlt, ist die Kaskade fertig.
Genau diese Ansicht ist die Loop Map. Company oben, Departments in der Mitte, Roles und Agents unten, mit Linien dazwischen, die zeigen, was auf was einzahlt.
So probierst Du es aus
- Selbst ausfüllen: Kopier die Vorlage oben und fülle sie für Dein Unternehmen aus, 60 bis 90 Minuten pro Abteilung.
- In 3 Minuten skizzieren: Der Loop Architekt baut aus 4 Fragen einen ersten Entwurf Deiner Kaskade inklusive vorgeschlagener KI-Agenten. Kostenlos, DSGVO-konform.
- Aus dem Chat bauen: Wenn Du in Claude, Cursor oder ChatGPT arbeitest, verbinde Loop MCP und lass die KI die Loop Map direkt aus einem Workshop-Transkript bauen.
- Mit einem Berater machen: Wenn Du Berater bist und die Kaskade mit Deinen Kunden aufsetzen willst, sieh Dir das Loop-Partnermodell für Berater an.
Zusammengefasst
Eine OKR-Kaskade, die im KMU wirklich steuert, hat drei Eigenschaften: sie passt auf eine Seite, jede Ebene zahlt nachweisbar auf die Ebene darüber ein, und jedes Ziel hat einen Judge, der nicht die Zahl misst, sondern den Effekt. Die Loop-Vorlage macht diese drei Eigenschaften zur Struktur. Der Rest ist ein sauberer Workshop und die Disziplin, keine vierte Company-Objective dazuzuschreiben.
Weiterlesen:
- Wie Unternehmensberater ein KI-Standbein aufbauen, ohne Entwickler einzustellen
- Loop für Berater: KI für Unternehmensberater in DACH
- Loop Architekt: dein Unternehmen als KI-System in 3 Minuten
Häufige Fragen
Was ist eine OKR-Kaskade?
Eine OKR-Kaskade verbindet das eine Unternehmensziel (Company-Objective) über Abteilungs-OKRs und Rollen-KPIs bis zur messbaren Kennzahl jedes einzelnen Mitarbeiters oder KI-Agenten. Jede Ebene zahlt nachweisbar auf die Ebene darüber ein, damit lokales Optimieren nicht das Ganze verschlechtert.
Wie viele OKRs braucht ein KMU?
In einem KMU unter 250 Mitarbeitern reicht ein Company-Objective mit drei Key Results, plus ein Objective pro Abteilung (typischerweise 3 bis 6). Pro Rolle eine messbare Kennzahl. Mehr wird nicht gelesen, weniger ist nicht steuerbar.
Was ist der Unterschied zwischen OKRs und KPIs?
KPIs messen laufende Leistung, OKRs setzen zeitlich begrenzte Veränderungsziele. In der Loop-Kaskade sitzen OKRs oben (Company, Department) und KPIs unten (Role, Agent). So bleibt die Strategie ambitioniert und der Betrieb messbar.
Kann ich die OKR-Kaskade auf einer Seite abbilden?
Ja, das ist sogar der Test. Wenn die Kaskade nicht auf ein A4-Blatt passt, ist sie für ein KMU zu komplex. Die Loop Map bildet Company, Abteilungen, Rollen und Agenten auf einer einzigen Ansicht ab.