Time-to-Decision KPI: Entscheidungsdauer messen. Wie lange braucht Ihre Organisation vom entscheidungsreifen Thema zum belastbaren Beschluss?

Wir messen Output - aber nicht Entscheidungs-Latenz

Moderne Unternehmen messen fast alles: Customer Acquisition Cost, Churn Rate, Monthly Recurring Revenue, Conversion, Auslastung, Produktivität, Projektstatus, Sprint Velocity und Budgetabweichungen.

Was fast nie gemessen wird, ist die Kennzahl, die entscheidet, wie handlungsfähig ein Unternehmen wirklich ist: die Time-to-Decision.

Geschwindigkeit wird häufig falsch verstanden. Viele Organisationen fragen: „Wie schnell arbeitet das Team?“ Viel wichtiger wäre oft: „Wie lange wartet das Team, bis klar ist, was entschieden wurde?“

Genau dort entsteht Entscheidungsstau. Nicht erst in der Umsetzung, sondern vor der Umsetzung: in Freigaben, Abstimmungen, Mandatsfragen, Budgetgrenzen, Stakeholder-Schleifen und Meetings, die diskutieren, aber nicht schließen.

Was misst Time-to-Decision genau?

Im Decision-OS wird Time-to-Decision als Zeitspanne zwischen dem entscheidungsreifen Zustand und der final dokumentierten Entscheidung gemessen. Dafür braucht es einen sauberen Startpunkt und einen sauberen Endpunkt.

Praktisch bedeutet das:

• Ready Date: Problem, Optionen, Entscheidungskriterium und notwendiger Input liegen ausreichend vor.
• Decided Date: Es gibt eine dokumentierte Entscheidung mit Owner, Begründung, nächstem Schritt, Termin und Review-Regel.

Ohne Decision Log bleibt TtD oft unsichtbar. Dann diskutieren Teams über gefühlte Langsamkeit, aber niemand kann zeigen, wo die Verzögerung tatsächlich entsteht.

Orientierungswerte: Wann ist TtD gesund?

Es gibt keine universell perfekte Time-to-Decision. Eine operative Freigabe, eine Produktpriorisierung und eine M&A-Entscheidung haben unterschiedliche Anforderungen. Trotzdem helfen Orientierungswerte, Entscheidungs-Latenz im Führungsalltag sichtbar zu machen.

Diese Werte sind keine starren Benchmarks. Sie helfen, Muster zu erkennen: Welche Entscheidungstypen bleiben hängen? Wo fehlen Mandate? Welche Foren schließen nicht? Welche Freigaben warten regelmäßig zu lange?

Warum lange Entscheidungszeiten teuer sind

Eine lange TtD kostet nicht nur Geduld. Sie kostet Geld, Fokus, Vertrauen und Marktchancen.

Jeder Tag, an dem ein Team auf eine Entscheidung wartet, erzeugt direkte und indirekte Kosten:

• Führungszeit wird in Wiederholungsmeetings gebunden.
• Teams halten Ressourcen vor, ohne umsetzen zu können.
• Prioritäten bleiben offen und konkurrieren weiter.
• Marktchancen werden später genutzt oder verpasst.
• Unsicherheit frisst Energie, weil niemand weiß, worauf er sich einstellen soll.

Besonders teuer wird lange TtD, wenn sie mit hoher Meetinglast zusammenfällt. Dann kostet nicht nur die Verzögerung Geld, sondern auch die Abstimmungsschleife selbst. Für eine wirtschaftliche Einordnung lassen sich TtD, der Meetingkosten-Rechner, der FTE-Vollkostenrechner und der Cost-of-Delay-Rechner verbinden.

Time-to-Decision, Cost of Delay und Decision Debt

Time-to-Decision ist eng mit Cost of Delay verbunden. Je länger eine Entscheidung offen bleibt, desto länger bleibt Wertschöpfung blockiert.

Das Problem wächst oft nicht linear. Offene Entscheidungen erzeugen Folgeentscheidungen, Unsicherheit, Ersatzhandlungen und politische Absicherung. So entsteht Decision Debt: organisatorische Verschuldung durch nicht geschlossene Entscheidungen.

Typische Folgen von Decision Debt:

• alte Themen tauchen in neuen Meetings wieder auf,
• Projekte laufen ohne klare Priorität weiter,
• Teams bauen Workarounds,
• Entscheidungen werden später wieder geöffnet,
• Führung verliert Glaubwürdigkeit, weil Beschlüsse ausbleiben.

TtD macht diese Verschuldung messbar. Statt „Wir sind langsam“ heißt es dann: „Budgetentscheidungen über 25.000 Euro dauern im Schnitt 18 Tage - und blockieren drei Teams.“

Symptome, Ursachen und Gegenmittel im Decision-OS

Hohe TtD entsteht selten durch einen einzelnen Fehler. Meist zeigt sie, dass Entscheidungsrechte, Foren, Rollen oder Dokumentation nicht sauber zusammenspielen.

Wie Sie Time-to-Decision praktisch messen

Für den Einstieg reicht oft ein einfaches Decision Log. Entscheidend ist nicht die perfekte Software, sondern eine konsistente Logik.

Jedes relevante Entscheidungselement braucht mindestens:

• eine Decision-ID,
• einen Entscheidungstyp,
• ein Ready Date, alternativ ein Created Date,
• ein Decided Date,
• einen DRI oder Owner,
• ein Forum oder Entscheidungsweg,
• den Status: Draft, Ready, Decided, Review oder Closed.

Damit lässt sich TtD bereits in Excel, Google Sheets, Notion, Confluence, Jira oder Microsoft 365 auswerten. Coachingwerk Berlin verkauft dafür kein neues Tool. Wichtig ist, dass Entscheidungen als Objekte sichtbar werden - nicht nur als Prosa im Meeting-Protokoll.

Was TtD über Ihre Governance verrät

Time-to-Decision ist keine reine Effizienzkennzahl. Sie zeigt, wie gut Ihr Führungssystem Entscheidungen vorbereitet, priorisiert, schließt und dokumentiert.

Damit ist TtD ein Frühwarnsystem für Decision Governance. Sie zeigt nicht nur, dass etwas langsam ist, sondern wo die Entscheidungsarchitektur schwach wird.

Time-to-Decision und Re-Open-Rate gehören zusammen

TtD misst, wie lange eine Entscheidung bis zum Beschluss braucht. Die Re-Open-Rate misst, wie oft sie danach wieder aufgemacht wird. Beide Kennzahlen gehören zusammen.

Eine niedrige TtD bei hoher Re-Open-Rate ist kein Erfolg. Dann wird zwar schnell entschieden, aber schlecht geschlossen. Eine niedrige Re-Open-Rate bei extrem hoher TtD kann ebenfalls problematisch sein: Dann halten Entscheidungen vielleicht - aber das System braucht zu lange, bis sie entstehen.

Gute Decision Governance sucht die Balance:

• Entscheidungen fallen schnell genug, um Umsetzung nicht zu blockieren.
• Beschlüsse sind sauber genug, um nicht ständig wieder aufzugehen.
• Review-Regeln erlauben Lernen, ohne Reopen-Schleifen zu normalisieren.

Wie DoA, RACI und DRI die TtD senken

Lange Entscheidungszeiten entstehen oft nicht, weil die Entscheidung inhaltlich schwer ist. Sie entstehen, weil unklar ist, wer entscheiden darf.

Genau hier helfen DoA, RACI und DRI:

• DoA legt fest, wer welche Entscheidung bis zu welchem Schwellenwert treffen darf.
• RACI klärt, wer verantwortlich ist, wer entscheidet, wer konsultiert wird und wer informiert werden muss.
• DRI sorgt dafür, dass eine Person den Entscheidungsprozess aktiv zur Schließung führt.

Wenn diese Rollen klar sind, sinkt TtD oft nicht durch mehr Geschwindigkeit, sondern durch weniger Suchbewegung. Das Team muss nicht mehr herausfinden, wer zuständig ist. Es kann entscheiden.

Wann ein Decision Velocity Workshop sinnvoll ist

Ein Decision Velocity Workshop ist sinnvoll, wenn Entscheidungen regelmäßig länger dauern als der operative Takt erlaubt. Typische Signale sind wiederkehrende Vertagung, unklare Owner, Freigaben ohne Schwellenlogik, Reopen-Schleifen und Führungskreise, die viel diskutieren, aber wenig schließen.

Im Workshop wird nicht abstrakt über Geschwindigkeit gesprochen. Es werden echte Entscheidungen genommen, in Entscheidungstypen sortiert, mit DRI, Forum, Termin, Decision Log und Reopen-Regel versehen. Ziel ist ein Führungstakt, der Entscheidungen nicht nur bespricht, sondern schließt.

Fazit: Messen, um am System zu arbeiten

Time-to-Decision beendet die diffuse Debatte über Langsamkeit. Statt zu fragen: „Warum sind wir so träge?“, können Führungsteams genauer fragen: „Welche Entscheidungstypen dauern zu lange, und warum?“

Wenn die durchschnittliche TtD bei Budgetfreigaben steigt, ist das ein DoA-Signal. Wenn Produktentscheidungen mehrere Meetingzyklen verpassen, ist das ein Foren-Signal. Wenn Entscheidungen unklar bleiben, ist das ein Decision-Log-Signal.

Genau dafür ist Decision-OS gebaut: Entscheidungen nicht nur zu besprechen, sondern als Führungsprozess sichtbar, steuerbar und messbar zu machen.