SOP-TAGS-PROPERTIES-1.0Rev. v1.0··2026-05-15

Tags + Properties

Klassifikation am Block, nicht in der Tabelle nebenan.

ABLAUF

1
Bestehende Status-Tabelle (Excel oder Notion-DB) sichten und ihre Spalten als künftige Properties notieren.
WERKZEUG
Excel / Tracker
DAUER10 min
☐Prüfpunkt: Spalten-Liste = künftige Property-Schlüssel.
2
Pro Domäne erlaubte Schlüssel und Werte festlegen (z. B. status:: offen|review|final) und die Konvention auf einer Seite versionieren.
MATERIAL
Property-Konvention pro Domäne
DAUER20 min
☐Prüfpunkt: Konventions-Seite mit Schlüsseln und erlaubten Werten existiert.
3
Im Quell-Dokument je Aussage die Property am Block setzen (status::, quelle::, frist::); Tags für Quer-Sichten ergänzen (#wettbewerber).
WERKZEUG
Outliner (mium)
DAUER5 min pro Bericht
☐Prüfpunkt: Jeder relevante Block trägt seine Property.
4
Die Status-Tabelle als Query nachbauen — alle Blöcke mit status:: review, sortiert nach frist::.
WERKZEUG
Datalog-Query
DAUER10 min
☐Prüfpunkt: Das Query-Ergebnis deckt sich mit der alten Tabelle.
5
Alte Excel-Tabelle als read-only archivieren — nicht weiterpflegen. Ab jetzt ist die Query die Sicht.
WERKZEUG
Datei-Explorer
MATERIAL
Archiv-Ordner
DAUER2 min
☐Prüfpunkt: tracker.xlsx in `archiv/`, Query als Lesezeichen gesetzt.
6
Stichprobe: fünf Blöcke prüfen, ob Property-Wert und Quelltext übereinstimmen.
DAUER5 min
☐Prüfpunkt: Konsistenz Quelle ↔ Sicht bestätigt.

HINTERGRUND

#wettbewerber, status:: review, source:: bloomberg — Klassifikation an dem Block, der sie braucht. Keine Tabelle daneben.

Klassifikations-Zeit pro Bericht: −65 %
Tabellen-Pflegeaufwand: −80 %
Datenkonsistenz Quelle ↔ Sicht: 100 %

Warum die Excel-Tabelle zur zweiten Wahrheit wird

Im Due-Diligence-Alltag laufen Inhalt und Klassifikation getrennt — Memos im Word, ein Excel-Register mit Status, Quelle, Wettbewerber daneben. Sobald ein Memo aktualisiert wird, driftet das Register. Nach 12 Wochen finden sich 18 Einträge mit Status „review“, deren Quelltext längst auf „final“ steht.

5 Regeln

Tag = Quer-Klassifikation. `#wettbewerber`, `#risiko`, `#vendor` — flach, ohne Hierarchie, für Sichten über Domänen hinweg.
Property = strukturierte Metadate. `status:: review`, `quelle:: bloomberg`, `frist:: 2026-06-30` — Schlüssel-Wert, abfragbar, typisiert.
Query = lebende Sicht. Eine Abfrage über alle Blöcke mit `status:: review` ersetzt die handgepflegte Tabelle. Das Ergebnis aktualisiert sich, sobald ein Block sich ändert.
Properties auf Page oder Block. Page-Property gilt für das ganze Dokument (Mandant, Vertragsart). Block-Property gilt für die Aussage (Quelle einer Zahl, Frist eines Absatzes).
Konvention pro Domäne. Welche Schlüssel und Werte erlaubt sind, wird je Domäne festgelegt und versioniert — nicht pro Person improvisiert.

## Wettbewerber-Memo Acme
status:: review
quelle:: bloomberg
frist:: 2026-06-30

Umsatz Q4 lag bei 142 Mio. EUR #wettbewerber

Vorher/Nachher — Excel-Liste vs. Block mit status:: review

Vorher (Excel daneben)	Nachher (Property am Block)
Memo in Word, Eintrag in tracker.xlsx Zeile 47	Block im Memo trägt `status:: review`
Statuswechsel: zwei Dateien öffnen, beide speichern	Statuswechsel: ein Wert ändern, Sicht aktualisiert sich
Audit-Frage „Stand 2026-04-12?“ → Datei-Historie zweier Dateien abgleichen	Audit-Frage „Stand 2026-04-12?“ → eine Versionsspur, ein Block
Konsistenz Quelle ↔ Sicht: prüfbar nur per Stichprobe	Konsistenz Quelle ↔ Sicht: per Definition 100 %

Die Tabelle verschwindet nicht — sie wird zur Query. Wer „alle Blöcke mit status:: review und frist:: < 2026-07-01“ sehen will, schreibt die Abfrage einmal und liest sie täglich neu.

Ehrliche Frage

Wie oft pflegst Du Inhalte und ihre Tabelle separat? Zähle in der laufenden Woche die Fälle, in denen Du dieselbe Information an zwei Stellen geändert hast — einmal im Dokument, einmal im Register.

Klassifikation, die sich selbst pflegt.

Häng die Bedeutung an den Block, nicht an die Tabelle daneben. Dein Zweitgehirn hält Status und Quelle dort, wo die Aussage steht — ein Begleiter, keine zweite Buchhaltung.

Slot sichern··kostenlos →