Measuring Management Latency: Die Mathematik hinter der „Time-to-Decision“

Warum Management-Latenz die blinde Stelle vieler Dashboards ist

In der IT-Infrastruktur überwachen wir Latenzen im Millisekundenbereich. Wenn der Server-Ping über 200 Millisekunden liegt, gilt das als Incident. Im Management dagegen finden Verzögerungen von 14 Tagen kaum Erwähnung. Budgetentscheidungen, die sich über mehrere Wochen ziehen, tauchen in keinem Standard-Report auf.

Im Decision-OS Framework behandeln wir die Organisation wie ein technisches System und installieren Telemetrie. Die wichtigste Kennzahl für die Agilität eines Unternehmens ist nicht die Anzahl der Sprints, sondern die Time-to-Decision (TtD). Sie misst, wie schnell ein erkanntes Problem in eine verbindliche Entscheidung überführt wird.

1. Die Formel: Time-to-Decision berechnen

TtD misst die Zeitspanne vom Moment der Erkenntnis bis zum Beschluss. Formal: vom Status Draft (Problem erkannt) bis Decided (Hammer gefallen).

In SQL oder DAX können Sie TtD zum Beispiel so berechnen:

TtD = DATEDIFF(day, created_at, decided_at)

Im Decision-OS nutzen wir bewusst Kalendertage und nicht nur Werktage. Der Markt pausiert nicht am Wochenende. Wenn eine Entscheidung am Freitag reif ist, aber erst am Dienstag im Weekly Tactical beschlossen wird, sind vier Tage Opportunitätskosten entstanden. Die Latenz ist real, auch wenn niemand im Büro ist.

Das Ampel-System als Benchmark

Rohdaten allein reichen nicht. Für das BI-Dashboard brauchen Sie Interpretationsrahmen. Bewährt hat sich ein einfaches Ampel-System:

• 🟢 < 2 Tage (Hyper-Speed) – Entscheidungen werden oft asynchron getroffen. Hier lohnt ein Blick auf die Re-Open-Rate, um Flüchtigkeitsfehler auszuschließen.
• 🔵 2 – 7 Tage (Healthy) – Standard-Takt. Themen werden spätestens im nächsten Weekly Tactical gelöst.
• 🟡 8 – 14 Tage (Lagging) – Warnsignal. Entscheidungen „verpassen“ den Wochenzyklus. Decision Debt baut sich auf.
• 🔴 > 14 Tage (Stuck) – Systemverstopfung. Hier braucht es Eingriffe in die Governance (Triage, Entschlackung von Gremien).

2. Advanced Analytics: Cost of Delay sichtbar machen

Für CFOs und Business-Owner reicht eine Zeitangabe selten. Zeit muss in Geld übersetzt werden. Dafür nutzen wir die Cost of Delay (CoD).

Verzögerungen sind in vielen Szenarien exponentiell teuer. Wer zu spät launcht, verliert Marktanteile, Zinseszinseffekte und First-Mover-Vorteile. In Ihrem BI-Tool (PowerBI, Tableau, Looker) sollte deshalb eine Kurve sichtbar sein, die TtD mit Business Value verknüpft.

Eine praktische Visualisierung:

• X-Achse: Zeit (z. B. Wochen oder Quartale)
• Y-Achse: Anzahl offener Entscheidungen bzw. kumulierte TtD

Steigt die Kurve offener Entscheidungen schneller als die Kurve der abgeschlossenen Entscheidungen, bewegt sich die Organisation auf den Punkt des Kollaps zu. Ab diesem Punkt übersteigt die Komplexitätslast die Entscheidungskapazität der Führungsteams – Projekte stauen sich, selbst triviale Beschlüsse werden zur Hängepartie.

3. Qualitäts-Sicherung: Die Gegenmetrik Re-Open-Rate

Jede Metrik, die ein Ziel wird, hört auf, eine gute Metrik zu sein (Goodharts Gesetz). Wenn Sie Teams ausschließlich auf Speed (niedrige TtD) optimieren, werden sie anfangen, schlechte Entscheidungen schnell zu treffen.

Deshalb braucht TtD eine natürliche Gegenmetrik: die Re-Open-Rate (RoR). Sie misst, wie häufig bereits getroffene Entscheidungen wieder aufgegriffen werden, weil sie falsch, unvollständig oder politisch nicht haltbar waren.

Eine einfache Definition:

RoR = (COUNT(decisions WHERE status_change = 'Decided_to_Review') / COUNT(all_decisions)) * 100

Eine gesunde Organisation kombiniert hohe Geschwindigkeit mit hoher Stabilität, zum Beispiel:

• TtD Median unter 5 Tagen
• RoR unter 5 Prozent

Steigt TtD, werden Sie langsam. Steigt RoR, werden Sie wankelmütig – und damit ebenfalls langsam, nur zeitversetzt.

4. Data Engineering: Das Decision-Log als Sensor

Damit diese Metriken funktionieren, brauchen Sie eine saubere Datenquelle. Narrative Protokolle („Tom und Sarah schauen sich das mal an“) sind für BI wertlos. Sie benötigen eine strukturierte Tabelle DECISIONS mit klaren Timestamps.

Minimales Schema für Telemetrie:

• created_at – wann wurde das Problem erfasst (Status: Draft)
• ready_at – wann lagen alle Infos vor (Status: Ready). Damit können Sie die reine „Meeting-Wartezeit“ isolieren.
• decided_at – wann wurde final entschieden (Status: Decided)
• killed_at – wann wurde bewusst abgebrochen (Status: Killed)

Auf Basis von killed_at können Sie zusätzlich eine Kill-Rate berechnen – eine Fokus-Metrik, die zeigt, wie konsequent Sie Projekte stoppen, die keinen Wert mehr liefern. Eine Kill-Rate von 0 Prozent ist ein Warnsignal: Ihr Portfolio ist wahrscheinlich von Zombie-Initiativen verstopft.

Fazit: Vom Gefühl zur Evidenz

Viele Diskussionen über „Kultur“ oder „Mindset“ drehen sich im Kreis, weil sie auf Eindrücken basieren. Als Data Analyst können Sie diese Debatte objektivieren, indem Sie Management-Latenz messbar machen.

Wenn Sie im Vorstand nicht nur Umsatzkurven zeigen, sondern auch: „Unsere Time-to-Decision im Marketing hat sich in den letzten sechs Monaten verdoppelt – und der Umsatz ist im gleichen Zeitraum gefallen“, dann schaffen Sie einen starken Hebel für strukturelle Veränderungen.

Decision-OS liefert dafür das Governance-Design. Ihre Aufgabe ist es, die Sensoren zu bauen – und TtD, Cost of Delay, Re-Open-Rate und Kill-Rate in ein belastbares Telemetrie-Dashboard zu gießen.