BRIEF··

Tags + Properties

EXECUTIVE SUMMARY

Was, wenn die Klassifikation nicht in einer Tabelle neben dem Inhalt läge, sondern am Block selbst — abfragbar, konsistent, ohne doppelte Pflege? Tags und Properties senken die Klassifikations-Zeit pro Bericht um rund 65 % und den Tabellen-Pflegeaufwand um 80 %, während die Konsistenz zwischen Quelle und Sicht per Definition bei 100 % liegt.

−65 %
Klassifikations-Zeit
−80 %
Tabellen-Pflegeaufwand
100 %
Konsistenz Quelle ↔ Sicht
0
Parallele Register
1 Query
Handpflege → Abfrage
0 €
Toolchain-Kosten
RISIKEN
  • Ohne Domänen-Konvention wuchern Schlüssel und Werte — drei Leute schreiben status::, statu:: und Status::, und die Query greift ins Leere.
  • Properties am Block verlangen Disziplin beim Anlegen; 1 000 Blöcke nachträglich zu taggen ist teurer als von Beginn an.
  • Tag-Wildwuchs ohne kuratierten Kern führt zu Synonym-Inseln — #wettbewerber neben #competitor neben #wb.
ENTSCHEIDUNG
Empfehlung — Klassifikation an den Block verlagern (Tags + Properties) und parallele Status-Tabellen als lebende Query ablösen; Pflichtfelder pro Domäne versionieren.

#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

  1. Tag = Quer-Klassifikation. `#wettbewerber`, `#risiko`, `#vendor` — flach, ohne Hierarchie, für Sichten über Domänen hinweg.
  2. Property = strukturierte Metadate. `status:: review`, `quelle:: bloomberg`, `frist:: 2026-06-30` — Schlüssel-Wert, abfragbar, typisiert.
  3. 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.
  4. 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).
  5. 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 47Block im Memo trägt `status:: review`
Statuswechsel: zwei Dateien öffnen, beide speichernStatuswechsel: ein Wert ändern, Sicht aktualisiert sich
Audit-Frage „Stand 2026-04-12?“ → Datei-Historie zweier Dateien abgleichenAudit-Frage „Stand 2026-04-12?“ → eine Versionsspur, ein Block
Konsistenz Quelle ↔ Sicht: prüfbar nur per StichprobeKonsistenz 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.

Audit-ID: BRF-tags-properties-v1.0Vorgelegt: 2026-05-15··Falktron GmbH, Oelde
Die Frühjahrsschule ist vorbei. Tag 93 ansehen → Das Spiel starten →