---
name: decision-record
description: Hält eine getroffene Entscheidung als kurzen Eintrag im Entscheidungslog fest - die Entscheidung in einem Satz, Kontext, geprüfte Optionen, warum diese, wer entschieden hat, Datum, Status und was das Team dazu bringen würde, sie neu zu prüfen. Beruht auf der Praxis von Architecture Decision Records (ADR) und Entscheidungslogs, geschrieben für jede geschäftliche Entscheidung. Nutze ihn, wenn ein Team gerade etwas entschieden hat, jemand eine Entscheidung dokumentieren oder protokollieren will oder immer wieder gefragt wird „Warum haben wir das eigentlich so gemacht?“.
---

# Entscheidung dokumentieren

Ein Entscheidungseintrag lässt jemanden in sechs Monaten verstehen, was entschieden wurde, warum und wann man es wieder aufmacht, ohne die Leute zu fragen, die dabei waren. Er hält eine schon getroffene Entscheidung fest; er wirbt nicht für eine. Halte ihn kurz: Michael Nygards Beitrag von 2011, der das Format des Architecture Decision Record (ADR) eingeführt hat, sagt, das ganze Dokument solle 1 oder 2 Seiten lang sein; Standard dieses Skills ist eine halbe Seite.

## Wann du sie nutzt

- Ein Team hat gerade etwas entschieden, das sich nur teuer rückgängig machen lässt oder das später infrage gestellt wird: ein Tool, ein Anbieter, ein Preis, eine Richtlinie, ein Einstellungsplan, ein Prozess.
- Jemand sagt „Lass uns das festhalten“ oder will einen Eintrag im Entscheidungslog.
- In einem Thread fragt jemand immer wieder „Warum haben wir X gewählt?“, und die Antwort steckt nur in einem Kopf.
- Nicht, um die Entscheidung zu treffen. Um Optionen darzulegen und eine Empfehlung freigeben zu lassen, schreib zuerst ein Entscheidungsmemo und halte dann das Ergebnis hier fest.

## Was du brauchst

- Was entschieden wurde und von wem. Ist unklar, wer entschieden hat, frag einmal nach; rate nie. Schreib „[Entscheider nicht bestätigt]“, wenn es weiter unklar ist.
- Das Datum der Entscheidung. Fehlt es, nimm das Datum der Quellnachricht und markiere „[aus dem Datum der Nachricht]“.
- Die Optionen, die zur Wahl standen, und warum die anderen verloren haben. Wurde nur eine Option besprochen, sag das; erfinde keine Alternativen.
- Optional: der Thread, das Protokoll oder das Dokument, wo es besprochen wurde, und die Nummer des letzten Eintrags im Log.

## Schritte

1. **Formuliere die Entscheidung in einem Satz, im Aktiv.** Nygard schreibt den Abschnitt zur Entscheidung „in ganzen Sätzen, im Aktiv“, meist beginnend mit „Wir werden“. Beispiel: „Wir nutzen ab 1. März Dealbook als CRM.“
2. **Schreib den Kontext in 2 bis 4 Sätzen.** Die Fakten und der Druck, die eine Wahl erzwungen haben: Frist, Kosten, ein Kunde, eine Einschränkung. Nygard sagt, dieser Abschnitt „ist wertneutral. Er beschreibt einfach Fakten.“ Meinungen gehören zu den Gründen.
3. **Liste die geprüften Optionen auf.** Je eine Zeile mit dem wichtigsten Zielkonflikt. Das DACI-Play von Atlassian führt eine Tabelle der Optionen mit Vor- und Nachteilen und Kosten. Nimm „nichts tun“ auf, wenn das eine echte Option war. Liste nur Optionen auf, die wirklich besprochen wurden.
4. **Nenn die Gründe.** 2 bis 4 Punkte, die auf den Kontext zurückverweisen: warum diese Option die anderen geschlagen hat. Liste dann die Folgen auf, gute und schlechte. Nygard: „Alle Folgen sollten hier aufgeführt werden, nicht nur die ‚positiven‘.“
5. **Nenn, wer entschieden hat und wer einbezogen wurde.** Eine Person entscheidet (das DACI-Play von Atlassian nennt sie Approver, „die eine Person (ja: eine!), die die Entscheidung trifft“), dazu die einbezogenen Personen. Auch das ADR-Framework der britischen Regierung hält die einbezogenen Stakeholder fest.
6. **Leg einen Auslöser für die Neuprüfung fest.** Eine konkrete Bedingung, die sie wieder aufmacht: ein Datum, eine Zahl oder ein Ereignis („wenn wir mehr als 20 Leute im Vertrieb haben“, „wenn der Preis über unser Budget steigt“, „Prüfung am 1. März nächsten Jahres“). Standard dieses Skills: Jeder Eintrag hat einen; „nie“ ist nur erlaubt, wenn die Entscheidung wirklich endgültig ist, und dann mit Begründung.
7. **Setz Status und Nummer.** Vorgeschlagen, angenommen oder ersetzt. Nummeriere die Einträge der Reihe nach und vergib eine Nummer nie zweimal, wie in Nygards Format. Ersetzt dieser Eintrag eine ältere Entscheidung, markiere die alte mit „Ersetzt durch #[n]“ und behalte sie; Nygard hebt aufgehobene Entscheidungen auf, markiert sie aber als ersetzt.

## Ausgabeformat

```markdown
## #[Nummer] — [kurzer Titel als Substantiv]

**Status:** [vorgeschlagen / angenommen / ersetzt durch #n] · **Datum:** [Datum] · **Entschieden von:** [ein Name]  
**Einbezogen:** [Namen] · **Quelle:** [Link zu Thread, Protokoll oder Dokument]

**Entscheidung:** Wir [ein Satz].

**Kontext:** [2–4 Sätze mit Fakten.]

**Geprüfte Optionen:**
- **[Option A, gewählt]:** [wichtigster Zielkonflikt]
- **[Option B]:** [wichtigster Zielkonflikt]
- **[Nichts tun]:** [wichtigster Zielkonflikt, falls geprüft]

**Warum:**
- [Grund mit Bezug zum Kontext]

**Folgen:**
- [gute und schlechte Wirkungen, was sich für wen ändert]

**Neu prüfen, wenn:** [konkretes Datum, Zahl oder Ereignis]
```

## Beispiel

**Eingabe:** Zusammenfassung eines Slack-Threads: „OK, finale Entscheidung von Rosa (COO) am 3. Feb.: Wir nehmen Dealbook, nicht FunnelHQ. Nadia und Felix waren dabei. Der Sales-Tarif von FunnelHQ kostet für unsere 6 Leute im Vertrieb etwa das Dreifache, und Marketing-Automation nutzen wir noch nicht. Dealbook hat die E-Mail-Synchronisierung, die wir brauchen. Nachteil: Wir müssen noch mal migrieren, falls das Marketing später FunnelHQ will. Die Tabelle bricht zusammen, letzten Monat sind uns 2 Follow-ups durchgerutscht. Der letzte Log-Eintrag war #11.“

**Ausgabe:**

```markdown
## #12 — CRM für das Vertriebsteam

**Status:** angenommen · **Datum:** 3. Februar · **Entschieden von:** Rosa (COO)  
**Einbezogen:** Nadia, Felix · **Quelle:** Slack-Thread, 3. Februar

**Entscheidung:** Wir stellen das Vertriebsteam von der gemeinsamen Tabelle auf Dealbook um.

**Kontext:** Das Team aus 6 Leuten im Vertrieb verfolgt Deals in einer Tabelle, die zusammenbricht. Letzten Monat sind 2 Follow-ups verloren gegangen. Wir brauchen eine E-Mail-Synchronisierung mit dem CRM. Marketing-Automation nutzen wir heute nicht.

**Geprüfte Optionen:**
- **Dealbook, gewählt:** hat die E-Mail-Synchronisierung, die wir brauchen; keine Marketing-Automation.
- **Sales-Tarif von FunnelHQ:** Marketing-Automation inklusive, etwa das Dreifache der Kosten von Dealbook für 6 Leute im Vertrieb.

**Warum:**
- Es ersetzt die zusammenbrechende Tabelle und hat die E-Mail-Synchronisierung, die wir brauchen.
- Der Sales-Tarif von FunnelHQ kostet für 6 Leute im Vertrieb etwa das Dreifache, und Marketing-Automation nutzen wir noch nicht.

**Folgen:**
- Der Vertrieb überträgt seine offenen Deals in Dealbook und nutzt die Tabelle nicht mehr.
- Braucht das Marketing später FunnelHQ, migrieren wir die CRM-Daten ein zweites Mal.

**Neu prüfen, wenn:** das Marketing FunnelHQ will oder anfängt, Marketing-Automation zu nutzen.
```

## Prüfen vor dem Senden

- [ ] Die Entscheidung ist ein Satz im Aktiv, nach dem jemand handeln kann.
- [ ] Genau eine Person ist als Entscheider genannt, oder „[Entscheider nicht bestätigt]“.
- [ ] Jede aufgeführte Option wurde wirklich besprochen; nichts wurde ergänzt, um gründlich zu wirken.
- [ ] Die Folgen enthalten mindestens einen Kostenpunkt oder Nachteil.
- [ ] Der Auslöser für die Neuprüfung ist ein konkretes Datum, eine Zahl oder ein Ereignis.
- [ ] Fakten, Namen, Zahlen und Daten stammen alle aus der Quelle.

## Häufige Fehler

- Eine Diskussion als Entscheidung festhalten. Hat niemand mit Befugnis Ja gesagt, ist der Status „vorgeschlagen“.
- Einen alten Eintrag bearbeiten, wenn sich die Entscheidung ändert. Schreib einen neuen Eintrag und markiere den alten als ersetzt; genau um diese Geschichte geht es.
- Ein Kontextabschnitt, der argumentiert. Die Begründung für die Wahl gehört unter „Warum“.