- Protokolle sind nach Datum sortiert, Fragen kommen nach Thema – dafür gibt es das Log.
- Ins Log gehören Entscheidungen, die schwer umkehrbar, teuer oder umstritten sind.
- Das Wertvollste an einem Eintrag ist das Warum und die verworfenen Alternativen.
- Einträge werden nie gelöscht, sondern als ersetzt oder zurückgenommen markiert.
- Eine Person pflegt das Log, Einträge entstehen innerhalb eines Tages nach dem Meeting.
Warum Protokolle allein nicht reichen
Jedes Protokoll hält die Entscheidungen seines Meetings fest. Das Problem: Nach einem Jahr sind es fünfzig Protokolle, und die Entscheidungen liegen verstreut darin. Manche wurden später geändert, ohne dass das alte Protokoll davon weiß. Und die Begründung steht – wenn überhaupt – in einem Nebensatz.
Die Folgen kennt jedes Team: Dieselbe Diskussion wird nach einem halben Jahr wieder geführt, weil sich niemand an die Gründe erinnert. Neue Kolleg:innen stellen Entscheidungen in Frage, die längst gut begründet waren. Oder jemand hält sich an einen Beschluss, der schon zweimal überholt ist. Ein Entscheidungslog setzt genau hier an: Es sortiert nach Entscheidung statt nach Sitzung und hält den aktuellen Stand fest.
Für Gremien gibt es dafür die Beschlussliste, die alle Beschlüsse über die Sitzungen hinweg sammelt – beschrieben in Protokolle ablegen. Das Entscheidungslog ist ihre Variante für Teams und Projekte, in denen viele Entscheidungen ohne förmliche Abstimmung fallen.
Was ins Log gehört – und was nicht
Ein Log, in dem jede Kleinigkeit steht, liest niemand. Eins, in dem nur drei Einträge im Jahr landen, hilft auch nicht. Als Faustregel gehört eine Entscheidung ins Log, wenn mindestens eines davon zutrifft: Sie ist schwer rückgängig zu machen, sie kostet nennenswert Geld oder Zeit, sie betrifft mehrere Personen oder Teams, oder du ahnst schon jetzt, dass sie später hinterfragt wird.
| Ins Log | Nicht ins Log |
|---|---|
| Wir wechseln das Buchhaltungsprogramm zum 1. Jänner (Januar). | Die Rechnung von Lieferant X wird bezahlt. |
| Neue Kunden bekommen nur noch Jahresverträge. | Herr Berger ruft den Kunden morgen an. |
| Die App wird zuerst für Windows gebaut, Mac folgt später. | Das Meeting wird auf 10 Uhr verschoben. |
| Wir verzichten auf eine Messe-Teilnahme 2027. | Offene Frage: Welche Messe passt besser? |
Aufgaben gehören in die Aufgabenliste, offene Fragen in die Offene-Punkte-Liste. Wer alles in ein Dokument kippt, findet am Ende gar nichts mehr.
So sieht ein guter Eintrag aus
Ein Eintrag beantwortet sieben Fragen: Was wurde entschieden, in einem Satz? Was war das Problem? Warum diese Lösung? Welche Alternativen gab es? Wer hat entschieden, wann und wo? Wen betrifft es? Wann sollte man es überprüfen? Ein Beispiel aus einem kleinen Dienstleistungsbetrieb:
- E-017 · 8. 10. 2026 · gültig
- Entscheidung: Ab 1. 12. ersetzen wir die Telefon-Hotline durch ein Rückrufsystem mit Zeitfenstern.
- Kontext: Anrufe kommen gehäuft am Vormittag, das Team ist dann in Terminen; viele Kund:innen landen auf der Mailbox.
- Begründung: Rückrufe lassen sich in ruhige Zeiten legen, Kund:innen bekommen eine verbindliche Zeit statt Warteschleife.
- Verworfen: zusätzliche Teilzeitkraft (zu teuer für den Bedarf), externer Telefondienst (kennt die Kunden nicht).
- Entschieden von: Geschäftsführung (Frau Huber) nach Teammeeting vom 8. 10., Protokoll TOP 3.
- Betrifft: Kundenservice, Website, Kundenmailing.
- Überprüfen: Ende Februar 2027 anhand der Rückmeldungen.
Die verworfenen Alternativen sind der Teil, der am häufigsten fehlt – und später am meisten hilft. Wenn in einem Jahr jemand vorschlägt, „doch einfach eine Teilzeitkraft einzustellen“, steht die Antwort schon da. Ein Gerüst zum Ausfüllen gibt es als Vorlage für das Entscheidungslog.
Status und Lebenszyklus einer Entscheidung
Entscheidungen veralten. Das Log bleibt nur verlässlich, wenn es zeigt, welche noch gilt. Dafür genügen wenige Statuswerte:
| Status | Bedeutung | Was du tust |
|---|---|---|
| vorgeschlagen | liegt zur Entscheidung vor | Termin für die Entscheidung nennen |
| gültig | entschieden und in Kraft | Überprüfungsdatum setzen, falls sinnvoll |
| ersetzt durch E-… | eine neuere Entscheidung gilt | auf den neuen Eintrag verweisen, alten nicht löschen |
| zurückgenommen | gilt nicht mehr, ohne Nachfolger | Grund und Datum ergänzen |
Die wichtigste Regel: nie löschen, nie überschreiben. Gerade der Weg einer Entscheidung – erst A, dann B, weil sich etwas geändert hat – ist später aufschlussreich. Wird eine Entscheidung ersetzt, bekommt sie einen neuen Eintrag mit eigener Nummer, und der alte verweist darauf.
Variante für Software-Teams: Architecture Decision Records
In der Softwareentwicklung hat sich eine eigene Form etabliert: der Architecture Decision Record, kurz ADR. Bekannt gemacht hat ihn Michael Nygard 2011 mit einem Blogbeitrag. Statt einer Tabelle gibt es für jede Architekturentscheidung eine kurze Textdatei im Code-Repository, nummeriert und mit den Abschnitten Titel, Kontext, Entscheidung, Status und Konsequenzen.
Der Gedanke ist derselbe wie beim Entscheidungslog: Begründungen festhalten und überholte Entscheidungen nicht löschen, sondern als ersetzt markieren. Der Vorteil für Entwicklerteams liegt darin, dass die Entscheidungen direkt neben dem Code liegen, den sie betreffen, und mit ihm versioniert werden. Für Teams außerhalb der Softwareentwicklung ist eine Tabelle oder eine Wiki-Seite meist praktischer.
Das Log einführen und am Leben halten
Die meisten Entscheidungslogs sterben in der zweiten Woche. Damit es nicht so weit kommt, helfen ein paar einfache Gewohnheiten:
- Mit der Vergangenheit starten: Trag zum Start die zehn wichtigsten Entscheidungen der letzten Monate nach. Dann ist das Log vom ersten Tag an nützlich.
- Eine Person verantwortlich machen: Sie überträgt Entscheidungen aus den Protokollen, spätestens am Tag nach dem Meeting.
- Am Ende des Meetings fragen: „Gibt es heute etwas fürs Log?“ – zehn Sekunden, die das Bewusstsein schärfen.
- Verknüpfen: Im Protokoll steht die Log-Nummer, im Log das Protokoll als Quelle.
- Benutzen: Wenn eine alte Frage auftaucht, zuerst ins Log schauen und den Eintrag zeigen. Ein Log, das hilft, wird gepflegt.
Wie du Entscheidungen anschließend so weitergibst, dass alle Betroffenen sie verstehen, beschreibt Entscheidungen im Team kommunizieren.
Typische Stolpersteine
Auch gut gemeinte Entscheidungslogs scheitern oft an denselben Punkten. Wer sie kennt, kann früh gegensteuern:
- Nur das Was, kein Warum: Ein Eintrag „Rückrufsystem ab Dezember“ hilft in einem Jahr niemandem. Die Begründung ist der eigentliche Wert.
- Zu viel auf einmal: Wenn jede Kleinigkeit im Log landet, sind die wichtigen Einträge nicht mehr zu finden. Lieber zwanzig gute Einträge im Jahr als zweihundert.
- Unklare Urheberschaft: „Wurde entschieden“ ohne Namen führt später zu der Frage, ob das überhaupt jemand entscheiden durfte.
- Mehrere Logs: Jedes Teilteam führt sein eigenes – und keiner weiß, welches gilt. Ein Log pro Projekt oder Bereich, an einem Ort, für alle lesbar.
- Kein Abgleich mit der Realität: Entscheidungen, die in der Praxis längst anders gelebt werden, stehen weiter als „gültig“ da. Das Überprüfungsdatum hilft, solche Einträge regelmäßig anzusehen.
Eine einfache Gegenprobe: Kann jemand, der neu ins Team kommt, mit dem Log die drei wichtigsten Weichenstellungen des letzten Jahres erklären? Wenn ja, funktioniert es.
Dieser Beitrag dient der allgemeinen Information und ersetzt keine individuelle Beratung. Stand der Angaben: 8. Oktober 2026.