Decision Log: So protokollieren Sie Entscheidungen, damit die Begründungen erhalten bleiben

Organisationen erinnern sich daran, was sie entschieden haben, aber vergessen das Warum. Wie Entscheidungsprotokolle funktionieren, was erfasst werden muss, eine leichtgewichtige Vorlage und wie man diese mit den Ergebnissen verknüpft.

Ibrahim Elkobeissi · 2. November 2026 · 6 Min. Auswertung ·

LinkedIn X WhatsApp

Die Fassade eines großen modernistischen Institutionsgebäudes

Fragen Sie ein Team nach dem Grund für eine Richtlinie, und oft folgt eine Pause. Jemand erinnert sich an ein Meeting. Jemand anderes glaubt, es lag an einem Lieferanten. Die Person, die Bescheid wusste, hat letztes Jahr das Unternehmen verlassen. Die Entscheidung blieb bestehen. Ihre Gründe nicht.

Das ist normal, aber teuer. Ohne die Gründe hat ein Team zwei schlechte Optionen: eine Entscheidung beizubehalten, die es nicht mehr versteht, oder sie rückgängig zu machen und zu riskieren, das gelöste Problem wieder einzuführen. Ein Entscheidungsprotokoll bietet eine dritte Option. Lesen Sie das Protokoll, prüfen Sie, ob die Bedingungen noch vorliegen, und entscheiden Sie erneut mit Absicht.

Warum Organisationen vergessen, warum sie entschieden haben

Drei Kräfte wirken gegen das Gedächtnis einer Organisation für ihre eigenen Entscheidungen.

Gründe leben in Gesprächen. Entscheidungen werden in Meetings, Telefonaten und Nachrichtenverläufen getroffen. Das Ergebnis fließt in eine Richtlinie oder einen Plan ein. Der Kontext hingegen selten.
Menschen wechseln. Die Personen, die die Optionen abgewogen haben, wechseln die Rolle oder verlassen das Unternehmen. Ihr Verständnis geht mit ihnen.
Das Gedächtnis schreibt sich selbst um. In einer Studie aus dem Jahr 1975 stellte der Psychologe Baruch Fischhoff fest, dass Menschen ein Ergebnis als vorhersehbarer einstufen, sobald sie es kennen. Er nannte dies "creeping determinism". Im Nachhinein wirkt eine fundierte Entscheidung, die schlecht ausging, nachlässig, während eine glückliche Entscheidung weise erscheint.

Der letzte Punkt ist der wichtigste. Selbst wenn dieselben Personen bleiben, wird ihre Erinnerung daran, warum sie so entschieden haben, durch das beeinflusst, was danach geschah. Nur ein Protokoll, das zum Zeitpunkt der Entscheidung erstellt wurde, bewahrt, was bekannt war, was erwartet wurde und was ungewiss war.

Die Architektur-Leitlinien von Microsoft formulieren die Kosten deutlich: Eine Entscheidung, die nie protokolliert wird, "wird wahrscheinlich vergessen werden, was zu wiederholten Debatten führt."

Was Software-Teams lernten: Das Architecture Decision Record

Das Software Engineering hat eine bewährte Antwort. Im November 2011 schlug Michael Nygard das Architecture Decision Record (ADR) vor: ein kurzes Dokument für jede wichtige Entscheidung, fortlaufend nummeriert und zusammen mit dem Projekt aufbewahrt. Sein Format besteht aus fünf Teilen.

Titel. Eine kurze Nominalphrase mit einer Nummer, wie z. B. "ADR 9: LDAP für Multitenant-Integration."
Kontext. Die wirkenden Kräfte: technische, politische, soziale und lokale Faktoren. Nygard empfahl, diesen Abschnitt wertneutral zu halten – als reine Beschreibung der Fakten.
Entscheidung. Die Reaktion auf diese Kräfte, in vollständigen Sätzen und im Aktiv: "Wir werden..."
Status. Vorgeschlagen, akzeptiert, veraltet oder ersetzt, mit einem Verweis auf etwaige Nachfolger.
Konsequenzen. Der daraus resultierende Kontext. In Nygards Worten: "Alle Konsequenzen sollten hier aufgeführt werden, nicht nur die positiven."

Diese Praxis verbreitete sich. Thoughtworks platzierte leichtgewichtige ADRs im "Adopt"-Ring ihres Technology Radars – ihrer höchsten Empfehlungsstufe – und riet dazu, sie in der Versionsverwaltung statt in einem separaten Wiki zu speichern. Das Azure Well-Architected Framework von Microsoft bezeichnet das Entscheidungsprotokoll als eines der wichtigsten Ergebnisse eines Solution Architects. Die Leitlinien enthalten zwei Regeln, die man übernehmen sollte: Behandeln Sie das Protokoll als

nur für Anhänge (append-only) und halten Sie bei jeder Entscheidung ein Konfidenzniveau fest.

What a decision record should capture

Was ein Entscheidungsprotokoll erfassen sollte

ID and title. A number and a phrase that states what was decided.
ID und Titel. Eine Nummer und eine Phrase, die angibt, was entschieden wurde.
Datum. Wann die Entscheidung getroffen wurde, nicht wann sie aufgeschrieben wurde.
Verantwortlicher. Die Person, die für die Entscheidung rechenschaftspflichtig ist, und wer konsultiert wurde.
Kontext. Das Problem, die Einschränkungen und die Spannungsverhältnisse.
In Betracht gezogene Optionen. Einschließlich der abgelehnten Optionen und der Gründe dafür. Dies ist das Feld, das am häufigsten fehlt und am dringendsten benötigt wird.
Entscheidung. Ein klarer Satz, der mit "Wir werden..." beginnt.
Expected outcome. What should be true if the decision works, and by when.
Konfidenz. Hoch, mittel oder niedrig, ergänzt um eine Angabe dazu, was weiterhin ungewiss bleibt.
Überprüfungsdatum. Wann die Entscheidung im Hinblick auf das erwartete Ergebnis überprüft wird.
Status. Vorgeschlagen, akzeptiert, ersetzt oder eingestellt, inklusive Link zu einem etwaigen Nachfolger.

Die Felder für das erwartete Ergebnis und die Konfidenz übernehmen die Funktion eines Decision Journal. Sie halten fest, was Sie glaubten, bevor Sie das Ergebnis kannten – genau das, was die rückblickende Betrachtung normalerweise auslöscht.

Auch bei unseren eigenen Produktentscheidungen folgen wir dieser Gewohnheit. Beobachtetes wird strikt von Schlussfolgerungen getrennt, und widersprüchliche Ansichten werden beibehalten, statt sie zu glätten. Eine Entscheidung verdient mindestens diese Sorgfalt.

Verknüpfen Sie jede Entscheidung mit ihren Belegen und ihrem Ergebnis.

Ein einzeln stehender Datensatz ist besser als gar keiner. Ein verknüpfter Datensatz ist weitaus nützlicher.

Verlinken Sie zurück zu den Belegen. Wenn eine Entscheidung eine Patientenbefragung, eine Kostenanalyse oder einen Vorfallbericht zitiert, verlinken Sie direkt die Quelle. Spätere Leser können dann beurteilen, ob die Belege noch Bestand haben. Die Leitlinien von Microsoft sagen dasselbe: Ein Datensatz ohne Begründung "verliert mit der Zeit seinen Wert."

Verlinken Sie vorwärts zum Ergebnis. Schreiben Sie am Überprüfungsdatum auf, was tatsächlich passiert ist, im Vergleich zu dem, was erwartet wurde. Wenn die Abweichung groß ist, fragen Sie nach dem Warum. Waren die Belege schwach? Haben sich die Bedingungen geändert? War die Entscheidung fundiert und das Ergebnis einfach nur Pech? Die Antwort ist eine Lehre, und sie gehört in dieselbe Kette. Unser Artikel über Lessons Learned, die das nächste Projekt verändern zeigt, wie man solche Erkenntnisse nachhaltig nutzt.

Verlinken Sie zu Nachfolgern. Wenn eine Entscheidung revidiert wird, bearbeiten Sie nicht den alten Datensatz. Markieren Sie ihn als ersetzt und verweisen Sie auf den neuen. Die Historie einer Richtungsänderung ist oft das Wertvollste im Log.

Ein hypothetisches Beispiel verdeutlicht die Kette: Eine Klinik entscheidet, die Nachfassgespräche von Pflegekräften an einen dedizierten Koordinator zu übertragen. Der Datensatz zitiert Daten zur Abschlussquote der Anrufe, nennt den Betriebsleiter als Verantwortlichen, erwartet eine Steigerung der Quote innerhalb von drei Monaten und setzt ein Überprüfungsdatum. Bei der Überprüfung ist die Quote gestiegen, aber die Arbeitsbelastung der Pflegekräfte ist nicht wie erwartet gesunken. Ein neuer Datensatz ersetzt den ersten, passt die Rolle an und verlinkt zurück auf den alten. Zwei Jahre später kann eine neue Führungskraft die gesamte Geschichte in fünf Minuten nachvollziehen.

Halten Sie es leicht genug, um es dauerhaft zu nutzen.

Entscheidungsprotokolle scheitern so wie die meisten Dokumentationen. Sie werden zur lästigen Pflicht und dann eingestellt. Fünf Regeln halten sie am Leben.

Protokollieren Sie nur bedeutende Entscheidungen. Der Test von Microsoft ist hilfreich: Entscheidungen, die die Struktur prägen, wesentliche Qualitäten beeinflussen oder schwer rückgängig zu machen sind.
Halten Sie jeden Datensatz kurz. Eine Seite oder weniger. Verlinken Sie auf unterstützendes Material, anstatt es zu kopieren.
Schreiben Sie es auf, wenn Sie entscheiden. Ein Datensatz, der in derselben Woche verfasst wurde, ist präzise. Einer, der Monate später geschrieben wird, ist eine Rekonstruktion.
Führen Sie es dort, wo die Arbeit stattfindet. Ein Log, das direkt bei den Plänen und Verfahren geführt wird, die es beeinflusst, wird gelesen. Ein Log in einem separaten Ordner nicht.
Beginnen Sie jetzt und ergänzen Sie später einige. Beginnen Sie mit neuen Entscheidungen. Rekonstruieren Sie dann die wenigen vergangenen Entscheidungen, nach denen die Leute am häufigsten fragen, und kennzeichnen Sie diese als rekonstruiert.

Eine Entscheidung ohne Begründung ist eine Anweisung. Eine Entscheidung mit Begründung kann mit Sorgfalt geprüft, beibehalten oder geändert werden.

Wie Prism Entscheidungsprotokolle verwaltet

Prism speichert die Entscheidungen und das Wissen einer Organisation als Einträge mit einem festgelegten Vertrauenslevel: bestätigt, belegt, beobachtet oder geschlussfolgert. Jede Entscheidung verlinkt auf ihre Belege, auf die Schritte, die sie ausführen, sowie auf die Ergebnisse und die daraus resultierenden Pause-und-Lerneffekte. Wenn eine Entscheidung ersetzt wird, bleibt die vorherige sichtbar. Die Assistenten, die Ihr Team bereits nutzt, können den Datensatz ebenfalls lesen, sodass die Gründe vorhanden sind, wenn jemand fragt. Menschen treffen die Entscheidungen. Prism bewahrt ihre Gründe.