Kaskadierung und Abhängigkeiten

Wenn ein Unternehmen Ziele auf mehreren Ebenen verfolgt, stellt sich eine zentrale Frage: Wie wird aus einem Unternehmensziel ein konkreter Beitrag auf Abteilungs-, Team- oder individueller Ebene — ohne dabei die Eigenverantwortung der handelnden Personen zu untergraben? Evident Flow beantwortet diese Frage über zwei Mechanismen: die Kaskadierung von Zielen und das systematische Management von Abhängigkeiten.

Ziel zu Ziel, nie Ziel zu Aufgabe

Die grundlegende Regel der Kaskadierung in Evident Flow lautet: Was delegiert wird, ist immer ein Ziel — ein Zielzustand, kein Arbeitspaket.

Ein übergeordnetes Ziel wird in kleinere Teilziele heruntergebrochen, die jeweils einen eigenen Zielzustand beschreiben. Jedes Teilziel folgt denselben Regeln wie jedes andere Ziel in der Flow Pipeline: Es beschreibt einen konkreten Zustand, liegt im Einflussbereich des zuständigen Owners und kann am Ende mit Ja oder Nein bewertet werden.

Der entscheidende Punkt: Die Kaskadierung bleibt auf der Ebene des Was. Das Wie — also welche Initiativen, Aufgaben oder Maßnahmen nötig sind, um das Teilziel zu erreichen — bleibt in der Verantwortung des empfangenden Teams. Wer ein Teilziel delegiert, gibt einen Zielzustand weiter, keine Handlungsanweisung.

Das unterscheidet Evident Flow von klassischen OKR-Kaskadierungen, bei denen Key Results der oberen Ebene zu Objectives der nächsten werden. Da Key Results per Definition auf der Output-Ebene formuliert sind, entsteht dort ein konzeptioneller Bruch: Die untere Ebene beginnt in einer Umsetzungslogik, bevor sie eigenständig über den besten Weg nachdenken konnte. Evident Flow vermeidet diesen Bruch, indem auf jeder Ebene ein Outcome-Ziel steht.

Das Gegenstromprinzip

Kaskadierung in Evident Flow ist kein Top-Down-Befehl. Ein Ziel wird nicht einfach eine Ebene nach unten durchgereicht. Stattdessen folgt der Prozess einem Gegenstromprinzip: Die übergeordnete Ebene formuliert ihr Ziel, und die untergeordnete Ebene übersetzt daraus eigenständig, welchen Beitrag sie leisten kann.

Konkret läuft das so ab:

1. Die obere Ebene definiert ihr Ziel — beispielsweise ein Unternehmensziel in der Flow Pipeline.
2. Die untere Ebene leitet daraus ein eigenes Teilziel ab — formuliert als eigenständiger Zielzustand, der zum übergeordneten Ziel beiträgt.
3. Beide Seiten verabschieden das Teilziel gemeinsam — es gibt einen Diskurs darüber, ob das abgeleitete Teilziel sinnvoll ist, ob es den erwarteten Beitrag leistet und ob es im Einflussbereich des Teams liegt.

Dieser Prozess stellt sicher, dass Kaskadierung keine mechanische Ableitung ist, sondern ein Verständigungsprozess. Die übergeordnete Ebene weiß, welchen Beitrag sie erwarten kann. Die untergeordnete Ebene hat die Formulierung mitgestaltet und übernimmt echte Verantwortung — nicht für ein aufgedrücktes Ziel, sondern für ein vereinbartes.

Wie tief die Kaskadierung reicht

Die Kaskadierung kann über beliebig viele Ebenen gehen: von der Unternehmensebene über die Abteilung und das Team bis hin zur einzelnen Person. Wie tief sie tatsächlich reicht, hängt von der Organisationsstruktur und der Komplexität des Ziels ab.

Ein Unternehmensziel, das nur eine Abteilung betrifft, wird möglicherweise nur eine Ebene tiefer kaskadiert. Ein Ziel, das die Zusammenarbeit mehrerer Teams erfordert, kann auf Team-Ebene und von dort auf individuelle Ebene heruntergebrochen werden. Es gibt keine Pflicht, jedes Ziel bis auf die unterste Ebene zu kaskadieren — aber wenn auf einer Ebene Teilziele existieren, die für die Erreichung des übergeordneten Ziels nötig sind, müssen sie als eigenständige Ziele in der Pipeline sichtbar werden.

Wo ein Ziel nicht weiter kaskadiert wird, übernimmt der Owner die Konkretisierung durch Key Results — die messbaren Ergebnisse, über die das Ziel erreicht werden soll. Die Faustregel: Ziele werden delegiert, Key Results werden selbst verantwortet.

Abhängigkeiten als Ziele sichtbar machen

Nicht alle Teilziele entstehen durch vertikale Kaskadierung von oben nach unten. Viele entstehen horizontal: Ein Team stellt fest, dass es für die Erreichung seines Ziels auf die Zuarbeit eines anderen Teams angewiesen ist.

Evident Flow behandelt solche Abhängigkeiten konsequent über die Flow Pipeline. Die Regel lautet: Wenn die Zuarbeit eines anderen Teams relevanten Aufwand bedeutet, muss sie als eigenständiges Ziel in der Pipeline dieses Teams abgebildet werden.

Das bedeutet konkret:

• Der Owner des abhängigen Ziels formuliert den benötigten Beitrag als Teilziel — als Zielzustand, nicht als Arbeitsauftrag.
• Dieses Teilziel wird in der Flow Pipeline des anderen Teams angelegt.
• Das andere Team bewertet das Ziel, schätzt den Aufwand und nimmt es in seine Pipeline auf — oder eben nicht.

Abhängigkeiten werden damit strukturell sichtbar. Sie sind keine informellen Absprachen auf dem Flur, sondern dokumentierte Ziele mit Owner, Impact-Bewertung und Aufwandsschätzung.

Ziel oder To-Do: Wann ein eigenes Ziel nötig ist

Nicht jede Abhängigkeit rechtfertigt ein eigenes Ziel. Evident Flow unterscheidet zwei Ebenen:

Ebene	Wann	Was der Anfordernde erwarten kann
Ziel in der Pipeline	Relevanter Aufwand im anderen Team	Proaktivität — das andere Team übernimmt Verantwortung für den Zielzustand und steuert die Umsetzung eigenständig
To-Do-Ebene	Geringer Aufwand, kein eigenes Ziel nötig	Keine Proaktivität — der Anfordernde muss aktiv koordinieren, dem anderen Team alles Nötige liefern und die Erledigung einfordern

Die Unterscheidung ist pragmatisch, aber folgenreich: Wer Proaktivität oder nennenswerte Kapazität eines anderen Teams braucht, muss sicherstellen, dass der Beitrag als Ziel in dessen Pipeline steht. Alles andere ist ein informelles Arrangement, auf das sich nicht verlassen lässt.

Ein Anti-Pattern, das in der Praxis häufig auftritt: To-Do-Anfragen an ein anderes Team summieren sich. Einzeln betrachtet ist jede Anfrage zu klein für ein eigenes Ziel. In Summe binden sie aber erhebliche Kapazität — ohne in der Pipeline sichtbar zu werden. Wenn ein Team regelmäßig feststellt, dass es durch eine Vielzahl kleiner Zuarbeiten für andere Teams belastet ist, ist das ein Signal: Entweder werden die Anfragen gebündelt in ein Ziel überführt, oder die kooperative Zusammenarbeit muss auf anderer Ebene neu verhandelt werden.

Konflikte lösen: Die Trade-Off Session

Was passiert, wenn ein Team feststellt, dass ein Ziel, von dem es abhängig ist, vom anderen Team nicht ins Quartal aufgenommen wurde? Genau dafür ist die Trade-Off Session da.

Abhängigkeitskonflikte werden als Trade-Offs sichtbar gemacht und im Workshop diskutiert. Die Entscheidungslogik folgt dem Prinzip der globalen Optimierung: Wo erzielen die Ressourcen den größtmöglichen Impact auf den Fortschritt des Gesamtunternehmens? Der Evident Flow Index (EFI) liefert die Grundlage für diese Entscheidung.

Der Eskalationspfad ist damit in den Prozess eingebaut — er findet statt, bevor jemand mit der Arbeit beginnt. Wenn nach dem Workshop klar ist, dass ein abhängiges Ziel nicht bedient wird, bleiben drei Optionen:

1. Überzeugen — das andere Team von der Relevanz des Themas überzeugen, gestützt auf die Impact-Bewertung
2. Ohne auskommen — den eigenen Plan so anpassen, dass das übergeordnete Ziel auch ohne den Beitrag des anderen Teams erreichbar bleibt
3. Alternative finden — eine andere Lösung, beispielsweise über externe Ressourcen

Das Spannungsfeld, das dabei auf Bereichsebene entsteht — Kapazität für ein Abhängigkeitsziel aufbringen zu müssen, das die eigenen Prioritäten verschiebt — wird über die Kategorienlogik der Priorisierung aufgelöst. Dort ist die Reihenfolge definiert: Beiträge zu Unternehmenszielen stehen vor rollenbasierten Zielen und vor Abhängigkeiten anderer Teams.

Abhängigkeiten während des Quartals

Nicht alle Abhängigkeiten werden vor dem Quartal erkannt. Während der Umsetzung kann ein Team feststellen, dass es doch Zuarbeit eines anderen Teams braucht.

In diesem Fall wird ein neues Ziel in der Flow Pipeline des anderen Teams erstellt und in die Next-Spalte einsortiert — nicht ohne vorherige Rücksprache mit dem betroffenen Team. Das WIP-Limit bleibt davon unberührt: Es werden weiterhin nur so viele Ziele gleichzeitig bearbeitet, wie das Limit erlaubt. Das neue Abhängigkeitsziel reiht sich in die bestehende Rangfolge ein und wird gezogen, wenn Kapazität frei wird.

Wenn ein Ziel blockiert wird

Trotz sorgfältiger Planung kann es vorkommen, dass ein zugesagtes Teilziel nicht rechtzeitig geliefert wird. In diesem Fall verschiebt der Owner das blockierte Ziel in die Blocked-Stage der Flow Pipeline.

Die Blocked-Stage macht die Situation systemisch sichtbar. Sie signalisiert: Dieses Ziel kann nicht weiter vorangetrieben werden, weil ein externer Input fehlt. Die Klärung erfolgt im regelmäßigen Sync — dort wird entschieden, ob das blockierende Team umpriorisiert, ob der Owner einen alternativen Weg sucht oder ob das Ziel zurückgestellt wird.

Gleichzeitig wirkt sich eine Blockade auf das Confidence Level des übergeordneten Ziels aus: Der Owner passt seine Zuversicht nach unten an, was die Führungsebene über den regulären CL-Mechanismus informiert. So kaskadiert die Information über die Blockade nach oben, ohne dass jede Ebene im Detail berichten muss.

Was sich verändert

Wenn Kaskadierung nach dem Gegenstromprinzip funktioniert und Abhängigkeiten als Ziele in der Pipeline sichtbar sind, verändern sich drei Dinge:

Eigenverantwortung statt Gehorsam. Teams formulieren ihren Beitrag selbst. Sie setzen sich mit dem übergeordneten Ziel auseinander und übersetzen es in etwas, das in ihrem Einflussbereich liegt und das sie eigenständig verfolgen können. Das erzeugt Ownership — nicht für ein Ziel, das jemand anderes geschrieben hat, sondern für eines, das man selbst mitgestaltet hat.

Transparenz statt informelle Absprachen. Abhängigkeiten sind keine versteckten Risiken, sondern dokumentierte Ziele mit Owner, Aufwand und Impact-Bewertung. Jeder kann in der Pipeline sehen, welche Cross-Team-Abhängigkeiten existieren und ob sie bedient werden.

Konflikte vor der Arbeit, nicht danach. Die Trade-Off Session zwingt dazu, Abhängigkeitskonflikte zu klären, bevor das Quartal beginnt. Das ist unangenehm, aber deutlich billiger als ein Ziel, das erst nach Wochen der Arbeit an einer ungelösten Abhängigkeit scheitert.

Voraussetzungen

Damit Kaskadierung und Abhängigkeitsmanagement in Evident Flow funktionieren, braucht es:

• Eine Flow Pipeline mit klar definierten Stages — insbesondere die Stages Next und Blocked müssen verstanden und genutzt werden
• Gut formulierte Objectives — Kaskadierung funktioniert nur, wenn das übergeordnete Ziel klar genug ist, um daraus Teilziele ableiten zu können
• Eine Trade-Off Session als regelmäßiges Format, in dem Abhängigkeitskonflikte EFI-basiert gelöst werden
• Geklärte Rollen — insbesondere die kooperative Verantwortung muss verstanden sein, damit Teams Abhängigkeiten aktiv managen statt passiv auf Zuarbeit zu warten
• Die Bereitschaft zum Gegenstromprinzip — Führungskräfte, die Ziele nur diktieren wollen, werden keine echte Kaskadierung erreichen