Katalog / Aufbereitung von Daten und Wissen / PREP-012

Geschäftsglossar, Kennzahlendefinitionen und semantische Schicht für KI

Festhalten, was Felder, Codes und Kennzahlen bedeuten (zum Beispiel „Umsatz“ gegenüber „Nettoerlös“), in einem Glossar und einer maschinenlesbaren semantischen Schicht, damit Analyse-Assistenten und Text-to-SQL korrekte Antworten geben.

Bausteine für den EigenbetriebAgenten & AutomatisierungSprachmodell

Fragen Sie drei Abteilungen nach dem „Umsatz“ des letzten Monats, und Sie erhalten drei Zahlen: brutto, netto, mit oder ohne Gutschriften, nach Rechnungsdatum oder nach Lieferdatum. Eine Kollegin oder ein Kollege weiß, welche zu verwenden ist; ein Text-to-SQL-Assistent oder ein Agent nicht, und er antwortet selbstsicher mit der falschen. Dieser Vorbereitungs-Anwendungsfall liefert das fehlende Ergebnis: ein kurzes Glossar von Begriffen und Kennzahlen mit klaren Verantwortlichen und daraus eine semantische Schicht, die der KI sagt, was jede Spalte, jeder Code und jede Metrik bedeutet. Es ist überwiegend Klärungsarbeit, keine KI-Arbeit.

Problem & Nutzen

  • Wer: jedes Unternehmen, das Fragen zu seinen Zahlen in natürlicher Sprache stellen will (DATA-001) oder einen Assistenten ERP-, CRM- oder DATEV-Exporte lesen lässt.
  • Heute: Definitionen leben in den Köpfen der Beschäftigten oder in versteckten Excel-Formeln; Spalten wie STAT oder ZZ_KZ2 und Statuscodes kennen zwei Mitarbeitende.
  • KI-Nutzen: Eine dokumentierte Definition trennt eine plausible Antwort von einer richtigen und gibt neuen Beschäftigten und Prüfern eine einzige Wahrheit.
  • Ehrliche Grenze: Es wird kein belegter Benchmark genannt; messen Sie die Wirkung mit eigenen Testfragen (PREP-018).

Varianten

  • Nur Glossar: eine Tabelle in Excel, SharePoint oder Nextcloud, die einem Assistenten als Kontext mitgegeben wird.
  • Kennzahlenkatalog: Formel, Filter, Zeitbezug, Einheit, Verantwortliche(r) und Ausnahmen je Metrik.
  • Semantische Schicht: Metriken und Dimensionen einmal in einem BI-Datenmodell definiert, sodass Abfragen gesteuerte Definitionen verwenden.
  • Öffentlicher Sektor: statistische Indikatoren und Verwaltungscodes. Maschinenlesbare Tags: siehe DATA-016.

So funktioniert es

collect terms (reports, schemas, interviews)
  -> AI drafts definitions and column descriptions
  -> owner per term approves   [human-in-the-loop]
  -> publish glossary + KPI catalogue + semantic model (versioned)
  -> used by text-to-SQL, BI assistants, agents, RAG
  -> wrong answers feed back into definitions

Ein LLM liest Schema, Beispielwerte und Berichtsformeln und schlägt Beschreibungen, Synonyme und Kennzahlenformeln vor. Die fachliche Bedeutung entscheidet immer die verantwortliche Person, nie die KI.

Datenaufbereitung

Welche Daten: Schemata und Stichproben der Quellsysteme, Formeln in Berichten und Excel-Dateien, vorhandene Dokumentation und das Wissen der Kennzahlen-Nutzer. Wo: ERP- und DATEV-Exporte, CRM, Power-BI- oder Power-Pivot-Modelle, Controlling-Arbeitsmappen, Wikis.

Typische Lücken: mehrere Definitionen für einen Begriff, undokumentierte Codes, kryptische Spaltennamen, in Zellen versteckte Formeln, keine benannte verantwortliche Person, kein Datum „gültig seit“.

Aufbereitungsschritte: 1. 10-20 Kennzahlen auswählen, nach denen das Management wirklich fragt; nicht mit allen Feldern beginnen. 2. Die aktuelle Berechnung je Kennzahl sammeln (PREP-003, PREP-011). 3. Einen LLM Spalten- und Codebeschreibungen aus einem Schema-Export entwerfen lassen (PREP-005); Entwürfe als „unbestätigt“ kennzeichnen. 4. Je Abteilung einen Workshop von 60-90 Minuten abhalten, Konflikte klären, eine verantwortliche Person benennen. 5. Alltagssynonyme ergänzen (PREP-015), dann die freigegebenen Definitionen in das BI-Modell laden. 6. Mit 20-30 echten Fragen mit bekannten Antworten testen (PREP-018).

Werkzeuge: Excel oder SharePoint-Liste, Microsoft 365 Copilot oder Gemini for Workspace zum Entwerfen, Nextcloud oder Wiki zum Veröffentlichen, n8n oder Power Automate für Prüferinnerungen.

Aufwand: fast vollständig Datenaufbereitung. Eine erste Version im KMU dauert etwa 3-6 Arbeitstage verteilt auf 3-4 Wochen, danach 1-2 Stunden pro Monat. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

  • KMU - Weg B: Kein Produkt ersetzt das Nachdenken; die Arbeit besteht darin, die eigenen Definitionen zu dokumentieren und mit den eigenen Systemen zu verbinden. Nutzen Sie die vorhandenen Werkzeuge (Excel, Power BI, eine kleine Cloud-LLM-API mit AVV) statt einer Katalog-Suite. Wo nur ein Glossardokument vorliegt, genügen sogar einfache Weg-A-Funktionen in M365 oder Workspace.
  • Großunternehmen - Weg B: Die semantische Schicht ist Teil einer gemeinsamen Datenplattform; Cloud-KI-Dienste zum Entwerfen plus ein gesteuertes Metrikmodell im bestehenden BI-Stack.
  • Entwickler - Weg C: Open-Source-Metrikschichten und lokale Modelle entwerfen und liefern die Definitionen ohne Lizenzkosten aus.
  • Öffentlicher Sektor - Weg C: Verwaltungscodes und Statistiken sind sensibel, und die Beschaffung bevorzugt selbst betriebene oder souveräne deutsche Cloud-Lösungen.

Weg A — Kaufen (Standardsoftware)

  • Power-BI-Semantikmodelle mit Copilot-Datenaufbereitung, Looker (LookML), Tableau, Qlik; Kataloge mit Glossaren (Atlan, Collibra, Alation) richten sich an größere Unternehmen (DATA-007). Power BI und Looker bieten EU-Regionen; Metabase ist eine in Europa hostbare Option.
  • A wählen, wenn: Sie bereits ein BI-Werkzeug besitzen, dessen Modell die Definitionen tragen kann.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

  • Entwerfen: Ein Cloud-LLM mit EU-Region oder EU-Anbieter (Mistral, Azure OpenAI in einer EU-Region) liest das Schema und nicht personenbezogene Stichproben und entwirft Beschreibungen.
  • Semantische Schicht: Das freigegebene Modell im BI-Datenmodell oder in einer versionierten Datei halten; der Text-to-SQL-Assistent erhält die relevanten Definitionen als Kontext.
  • Orchestrierung: Power Automate oder n8n für Prüferinnerungen und die Veröffentlichung in SharePoint oder Nextcloud.

Weg C — Selbst betreiben (Open Source)

  • dbt MetricFlow, Cube, Metabase; Wren AI oder Vanna für Text-to-SQL rund um ein explizites semantisches Modell. Ollama mit einem 7-14B-Modell entwirft Beschreibungen auf HW1; Schemata sind klein.
  • Die Initiative Open Semantic Interchange (OSI) zielt auf ein herstellerneutrales Format (Spezifikation v1 2026 veröffentlicht); prüfen Sie zuerst Reifegrad und Werkzeugunterstützung.

Weg D — Eigenes Training

Nicht nötig. Feintuning vermittelt die Definitionen eines Unternehmens nicht zuverlässig; Kontext aus einer gepflegten semantischen Schicht ist günstiger, nachvollziehbar und am Tag einer Definitionsänderung aktualisierbar.

Stand der Technik (2026)

  • Text-to-SQL auf echten Unternehmensschemata ist weit weniger zuverlässig als auf akademischen Benchmarks; das übliche Mittel ist diese Schicht aus kuratierten Beschreibungen, Metriken und Beispielabfragen als Kontext [1][2].
  • Anbieter nähern sich semantischen Modellen als Vertrag zwischen Daten und KI an [1][2][3][4].
  • LLMs entwerfen Beschreibungen aus Namen und Stichproben gut, können aber interne Regeln (Gutschriften, Geschäftsjahreskalender) nicht kennen.
  • Fehlerbilder: ungeprüfte Entwürfe, veraltete Definitionen nach Reorganisationen, zwei „offizielle“ Versionen einer Kennzahl, mehrdeutige Synonyme.

Gemeinsame Bausteine & Kombinationen

  • Direkte Abnehmer: DATA-001 (BI in natürlicher Sprache), DATA-006 (Tabellenassistent), DATA-002 (Berichtstexte).
  • Nachbarn: DATA-007 (Katalogwerkzeuge), PREP-015 (Terminologie- und Synonymlisten), PREP-016 (Goldstandard-Beispiele), PREP-004 (Rollen der Datenverantwortung), PREP-001 (Reifegradprüfung).
  • Gleicher Stack: ein kleines LLM, eine Workflow-Engine (n8n oder Power Automate) und ein Veröffentlichungsraum bedienen Glossar-, Terminologie- und Wissensbasis-Anwendungsfälle gleichermaßen (Baukasten-Effekt).

Aufwand, Kosten & Kennzahlen

  • Weg A: 1-2 Wochen, wenn das BI-Werkzeug das Modell trägt. Weg B: 3-6 Arbeitstage für 10-20 Kennzahlen; LLM-Kosten vernachlässigbar. Weg C: plus 1-2 Tage Einrichtung.
  • Kostentreiber: Workshopzeit der Abteilungsleitungen.
  • Kennzahlen: Anteil korrekt beantworteter Testfragen, Kennzahlen mit benannter verantwortlicher Person, Spalten mit Beschreibung, Tickets „Zahlen weichen ab“.

Menschen & Veränderung

Früh einbinden: das Management (entscheidet die offizielle Definition), Abteilungsleitungen und Controlling als Verantwortliche, Datenverantwortliche und IT. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte wird nur gebraucht, wenn Beispielzeilen personenbezogene Daten enthalten; prüfen Sie den AVV (Art. 28 DSGVO) mit dem LLM-Anbieter (GUIDE-005, GUIDE-010).

Betriebsrat: im Normalfall nein, ein Glossar überwacht keine Beschäftigten. Informieren Sie ihn dennoch (§ 90 Abs. 1 Nr. 3 BetrVG); wenn Kennzahlen Einzelpersonen messen, etwa Umsatz je Person, gilt § 87 Abs. 1 Nr. 6 (GUIDE-004).

KI-Kompetenz: Art. 4 KI-Verordnung (AI Act) verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; zeigen Sie den Nutzern, wie sie eine falsche Antwort melden (GUIDE-006).

Pilot: Stellen Sie es als Ende des Streits „Welche Zahl stimmt?“ dar; beginnen Sie mit einer Abteilung, 10 Kennzahlen und einer KI-Fürsprecherin bzw. einem KI-Fürsprecher aus dem Controlling (GUIDE-008, GUIDE-009). Kontrolle beim Menschen: Die Verantwortlichen geben jede Definition frei; der Assistent nennt die von ihm verwendete Definition.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): minimales Risiko, ein Glossar ist Dokumentation; bewerten Sie den nachgelagerten Assistenten neu, wenn er Personal- oder Kreditentscheidungen speist (GUIDE-014).
  • DSGVO: Schemata und Definitionen sind normalerweise nicht personenbezogen; verwenden Sie maskierte oder synthetische Stichproben (PREP-022).
  • Risiken: selbstsicher falsche Antworten, veraltete Definitionen, Schattendefinitionen in neuen Excel-Dateien. Gegenmaßnahme: Verantwortliche, Prüfdaten, Versionierung, erneuter Test nach jeder Änderung (GUIDE-011).

Erste Schritte

  1. Die 10 Zahlen auflisten, nach denen das Management am häufigsten fragt, und notieren, wer jede heute berechnet.
  2. Die Berechnungen vergleichen; jeden Konflikt festhalten (brutto gegenüber netto, Datumslogik).
  3. Je Abteilung einen 90-Minuten-Workshop abhalten, entscheiden, eine verantwortliche Person benennen, „gültig seit“ erfassen.
  4. Einen LLM Spalten- und Codebeschreibungen aus einem Schema-Export entwerfen lassen; in einer kurzen Prüfung bestätigen.
  5. Die freigegebenen Definitionen in das BI-Modell oder den Assistenten-Kontext laden und mit 20 echten Fragen testen.

Quellen

  1. Microsoft - Prepare your data for AI in Power BI (Copilot) - https://learn.microsoft.com/power-bi/create-reports/copilot-prepare-data-ai
  2. dbt Labs - About the dbt Semantic Layer - https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
  3. Google Cloud - Looker semantic layer (LookML) - https://cloud.google.com/looker/docs/what-is-lookml
  4. Open Semantic Interchange (OSI) - https://github.com/open-semantic-interchange/OSI
  5. Wren AI - open-source text-to-SQL with semantic layer - https://github.com/Canner/WrenAI
  6. Metabase - open-source BI - https://github.com/metabase/metabase
  7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj