Decision-OS Tech Series · Decision Data Layer
Decision Log Tech: Vom Meeting-Protokoll zur Entscheidungsdatenbank.
Wie Entscheidungen zu strukturierten Daten werden – mit ID, DRI, Status, Review, Reopen-Regel und Governance-KPIs.
In vielen Organisationen liegen Entscheidungen als Dark Data in Protokollen, E-Mails, Chats und Präsentationen. Ein technisches Decision Log macht daraus strukturierte Datensätze: mit ID, DRI, Status, Entscheidungsrechten, Review-Datum und Governance-KPIs.
Der Unterschied ist klein im Format – aber groß in der Wirkung: Ein Protokoll erzählt, was besprochen wurde. Ein Decision Log zeigt, was entschieden wurde, wer verantwortlich ist und wann geprüft wird.
Teil der Decision-OS Tech Series: technische Spezifikationen für ein AI-taugliches Betriebssystem für Entscheidungen.
Was ist ein technisches Decision Log?
Ein technisches Decision Log ist eine strukturierte, durchsuchbare und auswertbare Ablage von Entscheidungen als Datensätze. Jede Entscheidung erhält eine eindeutige ID, einen Owner oder DRI, einen Status, eine Begründung, einen nächsten Schritt, ein Review-Datum und eine Reopen-Regel.
Im Decision-OS ist das Decision Log die Single Source of Truth für Entscheidungen. Es macht Time-to-Decision, Reopen-Rate, Verantwortungsdiffusion, DoA und Governance-KPIs messbar.
Warum Meeting-Protokolle als Entscheidungsarchiv nicht reichen
In vielen Unternehmen ist das Gedächtnis der Organisation unstrukturiert. Entscheidungen liegen in Word-Protokollen, PowerPoint-Notizen, E-Mail-Threads, Teams-Chats, Slack-Verläufen oder Confluence-Seiten mit dem Titel „Meeting Minutes“.
Für Menschen ist das lesbar. Für Steuerung ist es schwach. Für KI ist es häufig fast unbrauchbar. Aus Datensicht ist ein klassisches Meeting-Protokoll oft Dark Data: nicht sauber filterbar, nicht zuverlässig auswertbar, nicht statusfähig und nicht mit Ownern, Projekten, OKRs oder Risiken verbunden.
Genau dort entsteht ein Kernproblem vieler Führungssysteme: Entscheidungen werden zwar besprochen, aber nicht als strukturierte Objekte geführt.
Prosa beschreibt, was passiert ist. Ein Decision Log steuert, was entschieden wurde, wer verantwortlich ist und wann überprüft wird.
Vom Protokoll zur Entscheidungsdatenbank
Ein Decision Log ersetzt nicht jedes Protokoll. Aber es trennt das Wichtige vom Rauschen. Nicht jede Diskussion muss als Datensatz geführt werden. Aber jede relevante Entscheidung sollte eine strukturierte Form bekommen.
Der Unterschied ist einfach:
- Ein Protokoll erzählt, was besprochen wurde.
- Ein Decision Log dokumentiert, was entschieden wurde.
- Ein technisches Decision Log macht diese Entscheidung filterbar, messbar und verknüpfbar.
Dadurch entsteht ein Decision-Data-Layer: Entscheidungen werden nicht nur archiviert, sondern als Führungsdaten nutzbar gemacht.
Das Datenmodell: Welche Felder ein Decision Log braucht
Ein gutes Decision Log ist keine beliebige Tabelle. Es braucht Pflichtfelder, klare Typen und eine Statuslogik. Sonst entsteht nur ein weiteres Excel-Sheet mit unklarer Verantwortung.
| Feld | Typ | Warum es wichtig ist |
|---|---|---|
| Decision-ID | String / Auto-ID, z. B. DEC-001 | Jede Entscheidung wird eindeutig referenzierbar, z. B. in Projekten, Tickets, Commitments oder Reviews. |
| Titel / Entscheidung | Text | Beschreibt den Beschluss klar und kurz. Keine Diskussion, keine Prosa, sondern das Ergebnis. |
| DRI / Owner | User, Single Select | Verhindert Verantwortungsdiffusion. Es darf genau eine natürliche Person verantwortlich sein. |
| Accountable / Entscheider | User oder Rolle | Klärt, wer den Beschluss formal trägt, besonders wenn DRI und Entscheider nicht identisch sind. |
| Consulted | User, Multi Select | Zeigt, wer vor der Entscheidung gehört werden muss. Verhindert späte Einwände und Reopens. |
| Status | Enum | Zeigt den Lifecycle: Draft, Ready, Decided, Review, Closed oder Killed. |
| Created Date | Datum | Startpunkt für Time-to-Decision. |
| Decided Date | Datum | Endpunkt für Time-to-Decision. |
| Review Date | Datum | Verhindert, dass Entscheidungen für immer gelten, ohne überprüft zu werden. |
| Rationale | Text | Dokumentiert die Begründung: Warum wurde so entschieden? |
| DoA-Bezug | Relation / Kategorie | Verknüpft die Entscheidung mit Entscheidungsrechten, Schwellenwerten und Eskalationslogik. |
| Reopen-Regel | Text / Enum | Klärt, unter welchen Bedingungen die Entscheidung wieder geöffnet werden darf. |
Minimal-Schema für den Start
Für den Einstieg muss das Decision Log nicht perfekt sein. Ein Minimal-Schema reicht, wenn es konsequent genutzt wird.
Minimal-Schema:
DEC-ID
Titel
Status
DRI
Entscheider / Accountable
Created Date
Decided Date
Review Date
Rationale
Nächster Schritt
Reopen-RegelDiese Felder reichen, um die wichtigsten Governance-KPIs sichtbar zu machen: Time-to-Decision, Reopen-Rate, offene Entscheidungen, Verantwortungsdiffusion und Review-Disziplin.
Die State Machine: Entscheidungen brauchen einen Lifecycle
Eine Entscheidung ist kein einzelner Moment. Sie hat einen Lifecycle. Deshalb sollte der Status nicht als Freitext gepflegt werden, sondern als kontrollierte State Machine.
Wichtig ist: Nicht jedes Tool erzwingt diese Logik automatisch. Aber jedes Team kann sie operationalisieren, wenn Statusfelder, Pflichtfelder und Review-Routinen klar definiert sind.
Warum der DRI im Decision Log ein Single-Select-Feld sein sollte
Einer der häufigsten Fehler in Decision Logs ist ein Owner-Feld mit mehreren Namen: „Sarah & Tom“, „Sales / Marketing“, „Product & Tech“.
Das sieht kooperativ aus, erzeugt aber Verantwortungsdiffusion. Deshalb sollte der DRI im technischen Decision Log als Single-Select-Feld modelliert werden. Genau eine Person trägt den Hut.
Diese Regel verbindet das technische Datenmodell direkt mit der Führungslogik. Das System verhindert, dass Verantwortung in einer Gruppe verschwindet.
Consulted, RACI und DoA: Entscheidungsrechte sauber abbilden
Ein Decision Log wird stärker, wenn es nicht nur Entscheidungen dokumentiert, sondern die Entscheidungsrechte dahinter sichtbar macht.
DRI
Eine Person besitzt Fortschritt, Klärung und Abschluss der Entscheidung.
RACI
Klärt Rollen rund um Entscheidung oder Übergabe: Responsible, Accountable, Consulted, Informed.
DoA
Legt fest, wer welche Entscheidung bis zu welchem Schwellenwert treffen darf.
Ohne diese Logik bleibt ein Decision Log eine Ablage. Mit DRI, RACI und DoA wird es zum Governance-System.
Welche KPIs aus einem Decision Log entstehen
Der eigentliche Wert eines technischen Decision Logs entsteht nicht nur durch Dokumentation. Er entsteht durch Messbarkeit.
| KPI | Berechnung | Aussage |
|---|---|---|
| Time-to-Decision | Decided Date minus Created Date | Wie lange dauert es, bis aus Entscheidungsbedarf ein Beschluss wird? |
| Reopen-Rate | Wiedergeöffnete Entscheidungen / alle Entscheidungen im Zeitraum | Wie stabil sind Beschlüsse nach der Entscheidung? |
| Open Decisions | Anzahl Entscheidungen mit Status Draft oder Ready | Wie viel Entscheidungsarbeit ist noch offen? |
| Review Compliance | Reviews fristgerecht erledigt / geplante Reviews | Werden Entscheidungen planmäßig überprüft? |
| DRI Coverage | Entscheidungen mit DRI / alle Entscheidungen | Wie oft ist Ownership sauber benannt? |
| DoA Exceptions | Entscheidungen außerhalb definierter Mandate | Wo sind Schwellenwerte oder Entscheidungsrechte unklar? |
Damit wird Decision Governance operationalisierbar. Führungsteams müssen nicht mehr über diffuse Langsamkeit oder fehlende Verbindlichkeit sprechen. Sie sehen, wo das System hakt.
Implementierung: Notion, Airtable, Jira, Confluence oder Microsoft 365?
Ein technisches Decision Log braucht nicht zwingend neue Software. In vielen Fällen lässt es sich in vorhandenen Systemen aufsetzen.
Notion oder Airtable
Gut für schnelle Prototypen, kleine Führungsteams und Pilotbereiche. Relationen zu Projekten, OKRs, Risiken oder Meetings lassen sich einfach abbilden. Formeln für TtD und Filter für offene Entscheidungen sind schnell umsetzbar.
Jira
Gut für produkt- und technologieorientierte Organisationen. Ein eigener Issue Type Decision kann mit Workflow-Status, Pflichtfeldern und Automation versehen werden. Besonders stark, wenn Entscheidungen direkt mit Epics, Releases oder Incidents verbunden werden sollen.
Confluence oder SharePoint
Gut für Organisationen, die stark dokumentenorientiert arbeiten. Wichtig ist, dass das Decision Log nicht als Fließtext-Seite endet, sondern als strukturierte Tabelle oder Liste mit Pflichtfeldern geführt wird.
Excel, Google Sheets oder Microsoft Lists
Gut für den Einstieg. Gerade für einen ersten Decision-OS-Piloten reichen strukturierte Tabellen, wenn Status, DRI, Created Date, Decided Date und Review Date konsequent gepflegt werden.
Tool-neutral heißt nicht tool-los. Decision-OS wird in Ihrer vorhandenen Arbeitsumgebung umgesetzt – aber mit klarer Governance-Logik statt Tool-Zoo.
Decision Log und AI-Readiness
Ein technisches Decision Log ist auch die Grundlage für AI-Readiness. KI kann nur dann sinnvoll auf Entscheidungen zugreifen, wenn diese Entscheidungen strukturiert, nachvollziehbar und maschinenlesbar sind.
Ein klassisches Protokoll beantwortet selten zuverlässig:
- Was wurde entschieden?
- Wer war verantwortlich?
- Welche Begründung lag zugrunde?
- Welche Alternativen wurden verworfen?
- Wann wird überprüft?
- Unter welchen Bedingungen darf die Entscheidung wieder geöffnet werden?
Ein Decision Log beantwortet genau diese Fragen als Datenstruktur. Dadurch wird es zum Decision-Data-Layer: der Schicht, auf der spätere Automatisierung, Analyse und AI-Unterstützung überhaupt sinnvoll arbeiten können.
Anti-Pattern: Wann ein Decision Log scheitert
Ein Decision Log scheitert nicht daran, dass das Tool falsch ist. Es scheitert meistens an schwacher Governance-Disziplin.
- Owner-Felder enthalten Teams statt Personen.
- Statusfelder werden nicht gepflegt.
- Beschlüsse werden nachträglich geändert, statt sauber reopened zu werden.
- Review-Daten fehlen.
- Rationale-Felder bleiben leer.
- Entscheidungen werden im Meeting getroffen, aber nicht ins Log übertragen.
- Das Log wird als Archiv verstanden, nicht als Steuerungsinstrument.
Deshalb braucht ein Decision Log immer einen Operating Rhythm: Wer pflegt es? Wann wird es geprüft? Welche Entscheidungen müssen hinein? Welche nicht? Wer darf Status ändern?
Fazit: Code your Governance
Ein technisches Decision Log ist kein weiteres Reporting-Tool. Es ist Infrastruktur.
Es verwandelt Entscheidungen von flüchtigen Gesprächsergebnissen in strukturierte Führungsdaten. Dadurch werden Time-to-Decision, Reopen-Rate, Verantwortungsdiffusion, DoA-Lücken und Review-Disziplin sichtbar.
Der Weg vom Meeting-Protokoll zur Entscheidungsdatenbank ist deshalb kein nettes Digitalisierungsprojekt. Er legt fest, was Ihre Organisation morgen noch weiß – und was Ihre KI später überhaupt verstehen kann.
Decision Log, TtD und Reopen-Rate im Führungssystem verankern
Wenn Entscheidungen heute in Protokollen, Chats und Präsentationen verschwinden, braucht Ihr Team keine weitere Dokumentationspflicht, sondern ein schlankes Decision Log mit klarer Governance-Logik.
Weiterführende Artikel
Decision-OS Tech Series im Kontext
Das Decision Log ist der Datenkern. Die benachbarten Seiten vertiefen Meeting-State-Machines, Delegation of Authority und Governance-KPIs.
Weekly Tactical Tech
State Machines für Meetings: Wie Status, Entscheidungen und Follow-up technisch sauber geführt werden.
DoA-Matrix Tech
Delegation of Authority als Datenmodell: Schwellenwerte, Mandate und Eskalationen abbilden.
Decision KPIs Tech
Time-to-Decision, Reopen-Rate, Kill-Rate, DRI Coverage und Review Compliance technisch messen.
Fragen & Antworten
FAQ: Decision Log, Datenmodell und Decision-OS
Häufige Fragen zum technischen Aufbau eines Decision Logs, zur Verbindung mit TtD, Reopen-Rate, DRI, DoA und AI-Readiness.
Was ist ein technisches Decision Log?
Was ist der Unterschied zwischen Meeting-Protokoll und Decision Log?
Welche Felder braucht ein Decision Log mindestens?
Wie hilft ein Decision Log bei Time-to-Decision?
Wie senkt ein Decision Log die Reopen-Rate?
Kann ein Decision Log in bestehenden Tools umgesetzt werden?
Warum ist ein Decision Log wichtig für AI-Readiness?
Ist ein Decision Log ein neues Softwaretool?
Nächster Schritt
Wenn Entscheidungen verschwinden, ist das kein Dokumentationsproblem.
Es ist ein Governance-Problem. Lassen Sie uns klären, ob Ihr Führungsteam ein schlankes Decision Log, klare Decision Rights oder einen Decision-OS-Piloten braucht.