Vom Meeting-Protokoll zur relationalen Datenbank: Das Tech-Spec für ein Decision-Log

Vom Meeting-Protokoll zur relationalen Datenbank: Das Tech-Spec für ein Decision-Log

In 90 % aller Unternehmen ist das „Gedächtnis“ der Organisation unstrukturiert. Es liegt in Word-Dokumenten, Confluence-Seiten („Meeting Minutes“) oder E-Mail-Threads. Aus datentechnischer Sicht ist das Dark Data. Es ist nicht filterbar, nicht abfragbar und nicht skalierbar.

Prosa ist der natürliche Feind der Exekution. Sätze wie „Tom und Sarah schauen sich das mal an“ enthalten keine Logik, die ein System verarbeiten kann. Sie lassen Interpretationsspielraum.

Im Decision-OS Framework behandeln wir Entscheidungen deshalb nicht als soziale Ereignisse, sondern als Datenobjekte. Wir ersetzen das narrative Protokoll durch eine relationale Datenbank: das Decision-Log.

Dieser Artikel liefert die Technical Specification (Tech-Spec) für den Aufbau eines solchen Logs in Tools wie Notion, Airtable oder Jira.

1. Das Datenmodell (Schema Design)

Ein valides Decision-Log benötigt zwingende Attribute, um Prozess-Integrität zu gewährleisten. Eine einfache To-Do-Liste reicht nicht. Hier ist das Schema für die Tabelle DECISIONS_DB:

Primary Key: ID

• Typ: String / Auto-Increment (z. B. DEC-001, DEC-002)
• Warum: Jede Entscheidung muss eindeutig referenzierbar sein.
• Use Case: Ein Entwickler schreibt in den Git-Commit: Implemented feature flag as per DEC-124. Damit ist der „Golden Thread“ von der Strategie zum Code hergestellt.

Field: DRI (Directly Responsible Individual)

• Typ: User (Single Select)
• Constraint: Strictly Single Select.
• Logik: Es darf technisch nicht möglich sein, zwei Personen auszuwählen. Das System erzwingt das „Gesetz der Singularität“. Wenn zwei Namen im Feld stehen, ist der Datensatz ungültig (Verantwortungsdiffusion).

Field: Consulted

• Typ: User (Multi Select)
• Constraint: Max. 3 User (Validation Rule empfohlen).
• Logik: Wer mehr als 3 Personen konsultieren will, betreibt oft „Cover Your Ass“. Wenn das System mehr als 3 Einträge erkennt, sollte es eine Begründung im Feld Rationale erzwingen („Rule of 3“).

Field: Entscheidung (The Payload)

• Typ: Text (Long)
• Formatierung: Klartext. Subjekt + Prädikat + Objekt.
• Beispiel: „Wir erhöhen die SaaS-Preise um 5 % ab 01.10.“
• Anti-Pattern: Keine Begründungen oder Diskussionen in dieses Feld. Nur das Ergebnis. Die Herleitung gehört in das Feld Rationale.

Field: Review Date (TTL – Time to Live)

• Typ: Date
• Logik: Keine Entscheidung gilt ewig. Das System muss automatisch eine Benachrichtigung auslösen, wenn das Review-Datum erreicht ist, um zu prüfen: War die Wette richtig?

2. Die Business Logic: The State Machine

Eine Entscheidung ist kein punktuelles Ereignis, sondern ein Lifecycle. Das Feld Status darf kein Freitext sein, sondern muss einer strikten State Machine folgen.

Valide Zustände und Übergänge im Decision-OS:

• EXPLORE (Phase 0):
  Definition: Ressourcenfreigabe für Recherche. Noch keine Lösungsidee.
  Bedingung: Keine Definition of Ready nötig. Timebox max. 4 Wochen.
• DRAFT:
  Definition: Ein konkreter Vorschlag liegt vor.
  Owner: DRI ist zugewiesen.
• ASYNC REVIEW:
  Definition: Der 48-Stunden-Timer läuft. Stakeholder werden notifiziert.
  Automation: Wenn nach 48h kein Veto vorliegt → Auto-Transition zu DECIDED.
• READY FOR DECISION:
  Definition: Veto wurde eingelegt oder Thema ist zu komplex für Async. Muss ins Meeting (Weekly Tactical).
  Validator: Alle Pflichtfelder (Budget, Impact etc.) müssen gefüllt sein.
• DECIDED (Final State):
  Definition: Hammer gefallen.
  System-Action: Record Lock – der Eintrag wird schreibgeschützt („Read Only“), um Geschichtsfälschung zu verhindern.
• KILLED:
  Definition: Aktiv abgelehnt. Wichtig für das „Organizational Memory“, um Zombie-Ideen in Zukunft schneller zu erkennen.

3. Implementation & Stack

Wie setzen Sie das praktisch um?

Notion / Airtable

• Ideal für schnelle Implementierung ohne Development-Team.
• Nutzen Sie „Relations“, um Entscheidungen mit Ihrer PROJECTS_DB und OKR_DB zu verknüpfen.
• Bauen Sie Formeln ein, die die Tage zählen, die ein Ticket im Status DRAFT hängt (Latenz-Messung).

Jira

• Legen Sie einen eigenen Issue Type Decision an.
• Nutzen Sie Workflow Validators, um den Übergang von DRAFT zu READY zu blockieren, wenn Pflichtfelder leer sind.
• Nutzen Sie Post Functions, um den Status DECIDED zu sperren (keine weiteren Edits).

Fazit: Code your Governance

Hören Sie auf, Governance als „Kultur-Thema“ zu behandeln. Behandeln Sie sie als Software-Problem.

Wenn Sie Ihre Entscheidungsprozesse in eine Datenbank zwingen, erhalten Sie zwei massive Vorteile:

• Messbarkeit: Sie können KPIs wie Time-to-Decision und Re-Open-Rate berechnen.
• AI-Readiness: Sie erzeugen strukturierte Trainingsdaten für Ihre künftige Unternehmens-KI.

Der Weg vom Meeting-Protokoll zum Decision-Log ist kein „nettes Projekt“, sondern eine Infrastruktur-Entscheidung. Sie legen heute fest, was Ihre Organisation morgen noch weiß – und was Ihre KI später überhaupt verstehen kann.

Deep Dive: Sie wollen die kompletten Tech-Specs, inklusive der Jira-Workflow-Konfiguration und der Formeln für Notion? Das vollständige Technische Handbuch finden Sie in Kapitel 8 von Decision-OS.