Warum „Wer hat das wann entschieden?“ ein Alarmsignal ist
Wenn in Meetings oder Chats regelmäßig Fragen fallen wie „Wer hat das entschieden?“ oder „Wann wurde das eigentlich freigegeben?“, ist das kein Detailproblem – sondern ein strukturelles Risiko. Entscheidungen passieren, aber sie sind nicht auffindbar, nicht nachvollziehbar und oft auch nicht verbindlich.
Typische Symptome:
- Teams diskutieren Themen mehrfach, weil unklar ist, ob schon entschieden wurde.
- Projektleiter verlieren Zeit damit, alte E-Mails und Protokolle zu durchsuchen.
- Führungskräfte merken erst spät, dass kritische Themen „zwischen den Stühlen“ hängen bleiben.
- Niemand weiß genau, wer für welche Entscheidung gerade „den Hut auf“ hat.
Die Folge: Entscheidungsstau, Reopens, Frust und langsame Umsetzung – egal, wie viele Tools im Einsatz sind. Genau hier setzt ein Decision-Log an.
Was ein Decision-Log ist – und was nicht
Ein Decision-Log ist kein weiteres Reporting-Tool und kein schwerfälliges Protokollwesen. Es ist ein leichtgewichtiges Register aller relevanten Entscheidungen in einem definierten Bereich (z. B. Produkt, Operations, Transformationsteam).
Kernidee: Jede wichtige Entscheidung bekommt einen klaren Eintrag mit wenigen, aber eindeutigen Feldern:
- ID / Kürzel: Eindeutige Referenz („D-2025-017“ oder „PRD-DEC-08“).
- Titel: Worum geht es – in einem Satz?
- Owner / DRI: Wer verantwortet die Entscheidung?
- Datum: Wann wurde entschieden?
- Forum: Wo wurde entschieden? (z. B. Weekly, Steering, schriftlich)
- Entscheidung: Was wurde beschlossen – in Klartext, ohne Floskeln.
- Gültigkeit / Scope: Für welchen Zeitraum und für welchen Kontext gilt die Entscheidung?
- Nächster Schritt: Was passiert jetzt – und wer macht es bis wann?
- Status: offen · beschlossen · umgesetzt · angepasst.
Wie ein Decision-Log in den Alltag passt
In vielen Organisationen scheitern gute Ideen daran, dass sie als Sonderformat eingeführt werden. Das Decision-Log funktioniert anders: Es dockt an bestehende Routinen an und nutzt die Tools, die bereits da sind.
Typische Setups aus Projekten:
- Einfacher Start: Gemeinsame Tabelle (z. B. in Sheets oder Excel) pro Team oder Bereich mit 10–15 Spalten.
- Einbettung: Verlinkung im Meeting-Template und in zentralen Channels (z. B. Teams/Slack „#entscheidungen“).
- Ritual: Fester Punkt in wichtigen Runden: „Welche neuen Entscheidungen kommen ins Log?“ – maximal 10 Minuten.
- Review: Monatlicher Blick: „Welche Entscheidungen sind überfällig, obsolet oder müssen wir anpassen?“
Das Entscheidende ist nicht die Perfektion des Templates, sondern die Konsequenz, mit der Entscheidungen festgehalten und wiedergefunden werden können.
Konkretes Beispiel: Produktteam im Wachstumsmodus
Ein Produktteam (rund 25 Personen) kämpfte mit immer gleichen Fragen: „Warum haben wir Feature X nicht priorisiert?“, „Wer hat entschieden, dass wir hier abbrechen?“ und „Wieso machen wir jetzt A statt B?“ Die Folge: Unmut, Schatten-Entscheidungen und Reibungsverluste zwischen Produkt, Tech und Sales.
Der Weg ins Decision-Log sah so aus:
- Klare Auswahl: Nur Entscheidungen, die Scope, Budget, Prioritäten oder Kundenerwartungen betreffen, kommen ins Log.
- Ein gemeinsamer Ort: Eine Tabelle, die aus dem Weekly, dem Steering und dem Refinement heraus gepflegt wird.
- Verbindliche Rollen: Jede Entscheidung hat einen DRI – und dieser prüft, ob der Eintrag vollständig ist.
- Kommunikation: Teams wissen: „Wenn es nicht im Decision-Log steht, ist es kein verbindlicher Beschluss.“
Nach wenigen Wochen gab es deutlich weniger Diskussionen darüber, ob etwas entschieden wurde – der Fokus verlagerte sich auf wie man Entscheidungen umsetzt und gegebenenfalls anpasst.
Wie das Decision-Log mit Decision-OS zusammenspielt
Ein Decision-Log entfaltet seine Wirkung erst richtig, wenn es eingebettet ist in ein Entscheidungssystem – also in klare Foren, einen verbindlichen Takt und nachvollziehbare Verantwortlichkeiten.
Im Rahmen von Decision-OS ist das Decision-Log:
- der sichtbare Speicher der wichtigsten Beschlüsse,
- der Brückenschlag zwischen Meetings und Umsetzung,
- die Datenbasis, um Time-to-Decision, Reopens und Durchsatz zu messen.
Damit das funktioniert, braucht es drei Dinge:
- Klare Foren: Welche Runde entscheidet was? (z. B. Steering vs. Daily vs. QBR)
- Definierte Rollen: Wer bringt Entscheidungsfragen ein, wer entscheidet, wer setzt um?
- Leichtgewichtige Routinen: Am Ende jedes relevanten Meetings der Satz: „Was kommt heute ins Decision-Log?“
Warum sich der Aufwand rechnet
Auf den ersten Blick wirkt ein Decision-Log wie zusätzlicher Aufwand. In der Praxis zeigt sich fast immer das Gegenteil: Schon nach wenigen Wochen sinkt die Zahl der Reopens, die Meetingzeit wird zielgerichteter, und Führungskräfte müssen weniger „Feuerwehr“ spielen, weil Klarheit herrscht.
Typische Effekte in Projekten:
- Weniger Doppelarbeit: Teams müssen Entscheidungen nicht mehrfach herleiten.
- Weniger Eskalationen: Unklarheiten werden früh sichtbar, statt spät zu explodieren.
- Schnellere Onboardings: Neue Führungskräfte und Kolleginnen sehen sofort, wie und warum bisher entschieden wurde.
- Bessere Governance: Entscheidungsmuster werden messbar – und damit gestaltbar.
Ein funktionierendes Decision-Log ist damit ein kleiner, aber entscheidender Baustein eines modernen Decision-OS – und der Anfang vom Ende der „Wer hat das wann entschieden?“-Sucherei.
Wann ein Decision-Log allein nicht mehr ausreicht
Ein einzelnes Decision-Log kann unglaublich viel Ordnung schaffen – vor allem in einem Team oder einer Abteilung. Aber es gibt einen Punkt, an dem klar wird: Es geht nicht mehr nur um das Register, sondern um das gesamte Entscheidungssystem.
Typische Signale, dass Sie an dieser Grenze angekommen sind:
- Sie führen mehrere Logs: Produkt, Operations, Transformation – aber die Foren und Rollen sind nicht klar verzahnt.
- Entscheidungen werden zwar dokumentiert, aber es fehlt ein gemeinsamer Takt für Reviews und Anpassungen.
- Teams stoßen an Grenzen, weil unklar ist, welche Ebene welche Entscheidungen treffen darf (Delegation of Authority).
- Die Organisation bereitet sich auf KI- oder Tool-Rollouts vor – ohne klaren Governance-Layer.
Spätestens dann reicht es nicht mehr, das Decision-Log „besser zu pflegen“. Was fehlt, ist ein Decision-OS: klare Foren, eindeutige Entscheidungsrechte, leichtgewichtige Routinen und Kennzahlen, die zeigen, ob Entscheidungen wirklich schneller und besser werden.
Genau darauf zielt unser 14-Tage-Format: Wir starten mit den bestehenden Praktiken (auch Ihren bisherigen Logs), machen Engpässe sichtbar und bauen einen stabilen Rahmen, in dem ein Decision-Log seine volle Wirkung entfalten kann.
Mehr zu Decision-OS, Tempo & Governance
Wenn Sie tiefer einsteigen möchten, wie ein modernes Decision-OS wirkt, sind diese Beiträge eine sinnvolle Ergänzung zu Ihrem Decision-Log.
Der Latenz-Rechner: Warum euer Entscheidungsstau teurer ist als eure Miete
Wie Sie aus Time-to-Decision, Reopens und Meeting-Stunden einen belastbaren Business Case ableiten.
Artikel lesenKI skaliert Chaos: Warum ihr ohne Decision-Governance in 12 Monaten vor die Wand fahrt
Weshalb KI-Initiativen nur dann Wirkung entfalten, wenn Entscheidungsrechte und Foren vorher geklärt sind.
Artikel lesenMeeting-Diät: Wie ihr 30 % Kalenderzeit freischaufelt, ohne Informationen zu verlieren
Ein schlanker Reset für eure Meeting-Landschaft – mit klaren Regeln, Rollen und Outputs.
Artikel lesen