- Eine Ontology beschreibt fachliche Konzepte, ihre Eigenschaften und ihre Beziehungen zueinander.
- Sie hilft Unternehmen, Daten nicht nur technisch zu speichern, sondern fachlich einzuordnen.
- Eine Ontology ersetzt keine Datenmodellierung und keinen Semantic Layer. Sie ergänzt beide um einen klaren Bedeutungs- und Beziehungskontext.
- Besonders für KI, Natural Language Querying und AI Agents ist eine Ontology wichtig, weil sie explizit beschreibt, welche Objekte im Unternehmen existieren und wie sie zusammenhängen.
- Der Nutzen entsteht nicht durch möglichst komplexe Modelle, sondern durch verständliche, abgestimmte und wiederverwendbare Fachlogik.
Eine Ontology, auf Deutsch häufig Ontologie, beschreibt die wichtigsten fachlichen Begriffe eines Unternehmens und deren Beziehungen zueinander.
Sie beantwortet Fragen wie:
Welche Objekte gibt es in unserem Geschäft?
Wie hängen diese Objekte zusammen?
Welche Eigenschaften haben sie?
Welche Regeln gelten für ihre Interpretation?
Ein einfaches Beispiel aus dem Vertriebsumfeld:
Ein Kunde gibt einen Auftrag auf.
Ein Auftrag enthält Auftragspositionen.
Eine Auftragsposition bezieht sich auf ein Produkt.
Eine Rechnung gehört zu einem Auftrag.
Ein Produkt ist einer Produktgruppe zugeordnet.
Ein Kunde gehört zu einer Region oder Organisationseinheit.
Diese Zusammenhänge wirken selbstverständlich. In Datenlandschaften sind sie es oft nicht. Dort liegen Kunden, Aufträge, Rechnungen, Produkte, Planwerte und Organisationseinheiten häufig in unterschiedlichen Systemen, Tabellen und Modellen. Eine Ontology macht den fachlichen Zusammenhang explizit.
Damit geht es nicht nur um Begriffe, sondern um Bedeutung. Eine Ontology beschreibt, was ein Kunde, ein Produkt, eine Rechnung oder eine Organisationseinheit fachlich ist und wie diese Konzepte miteinander verbunden sind.
Daten werden heute an immer mehr Stellen genutzt. Neben klassischen Reports und Dashboards entstehen Self-Service-Analysen, Data Apps, Plattformarchitekturen, KI-Assistenten und automatisierte Workflows. Je mehr Anwendungen mit Daten arbeiten, desto wichtiger wird ein gemeinsames Verständnis darüber, was diese Daten bedeuten.
Ohne dieses Verständnis entstehen typische Probleme:
Eine Ontology hilft, diese Brüche zu reduzieren. Sie beschreibt zentrale Fachobjekte und ihre Beziehungen in einer Form, die von Menschen verstanden und von Systemen genutzt werden kann.
Das ist besonders relevant, wenn Unternehmen nicht nur einzelne Kennzahlen auswerten, sondern Zusammenhänge verstehen möchten. Viele Geschäftsfragen lassen sich nicht aus einer isolierten Tabelle beantworten. Sie betreffen Prozesse, Abhängigkeiten und Beziehungen:
Welche Kunden kaufen welche Produkte über welche Kanäle?
Welche Lieferanten beeinflussen welche Produktionsbereiche?
Welche Organisationseinheiten sind für welche Kennzahlen verantwortlich?
Welche Verträge, Rechnungen und Leistungen gehören fachlich zusammen?
Eine Ontology macht solche Zusammenhänge sichtbar. Sie schafft damit eine Grundlage, um Daten über Domänen hinweg verständlicher und nutzbarer zu machen.
Eine Ontology ist kein Ersatz für Datenmodellierung. Sie ist auch kein Ersatz für einen Semantic Layer. Alle drei Konzepte haben unterschiedliche Aufgaben und sollten zusammenspielen.
Die Datenmodellierung beschreibt, wie Daten strukturiert, gespeichert, verbunden und historisiert werden. Sie klärt zum Beispiel Fakten, Dimensionen, Schlüssel, Granularitäten, Beziehungen und technische Strukturen. Ohne gute Datenmodellierung fehlt die Grundlage für verlässliche Analysen.
Der Semantic Layer macht modellierte Daten fachlich nutzbar. Er definiert Kennzahlen, Dimensionen, Hierarchien, Berechnungslogiken und Regeln für die Nutzung in BI-Tools, Anwendungen oder KI-Szenarien. Er sorgt dafür, dass Business-Logik nicht in jedem Bericht neu entsteht.
Die Ontology beschreibt darüber hinaus fachliche Konzepte und Beziehungen auf einer allgemeineren Ebene. Sie beantwortet nicht primär die Frage, wie eine Kennzahl berechnet wird. Sie beschreibt, welche fachlichen Objekte existieren und wie sie zusammenhängen.
Ein Beispiel:
Die Datenmodellierung legt fest, wie Aufträge, Auftragspositionen, Rechnungen und Produkte technisch und logisch strukturiert werden.
Der Semantic Layer definiert darauf aufbauend Kennzahlen wie Umsatz, Auftragseingang, Rohertrag oder Anzahl aktiver Kunden.
Die Ontology beschreibt den fachlichen Zusammenhang: Ein Kunde erteilt Aufträge. Ein Auftrag enthält Positionen. Eine Position bezieht sich auf ein Produkt. Eine Rechnung gehört zu einem Auftrag. Ein Produkt gehört zu einer Produktgruppe.
Diese Ebenen dürfen nicht vermischt werden. Eine Ontology kann keine fehlerhafte Datenmodellierung reparieren. Sie kann auch keine saubere Kennzahlenlogik im Semantic Layer ersetzen. Sie hilft aber, den fachlichen Kontext sichtbar zu machen, auf dem Datenmodelle, Semantic Layer und KI-Anwendungen aufbauen können.
Kurz gesagt:
Datenmodellierung schafft die Struktur.
Der Semantic Layer macht Business-Logik nutzbar.
Die Ontology beschreibt fachliche Konzepte und Beziehungen.
Erst im Zusammenspiel entsteht ein belastbarer Kontext für moderne Datenarchitekturen.
Eine Ontology kann sehr einfach beginnen und später wachsen. Entscheidend ist nicht die maximale Vollständigkeit, sondern ein gemeinsames fachliches Verständnis.
Fachliche Konzepte
Im Mittelpunkt stehen die zentralen Objekte eines Unternehmens. Je nach Branche und Fachbereich können das zum Beispiel Kunde, Produkt, Auftrag, Vertrag, Rechnung, Standort, Maschine, Patient, Lieferant, Mitarbeiter oder Organisationseinheit sein.
Diese Konzepte sollten nicht nur benannt, sondern auch beschrieben werden. Was genau ist ein Kunde? Wann gilt ein Kunde als aktiv? Ist ein Interessent bereits ein Kunde? Was unterscheidet einen Auftrag von einer Bestellung oder einem Vertrag?
Solche Fragen wirken einfach, sind in der Praxis aber oft der Ursprung unterschiedlicher Auswertungen.
Eigenschaften
Jedes fachliche Konzept besitzt Eigenschaften. Ein Kunde kann zum Beispiel eine Kundennummer, einen Status, eine Branche, eine Region oder eine verantwortliche Organisationseinheit haben. Ein Produkt kann eine Produktgruppe, eine Marke, einen Preis oder einen Lebenszyklusstatus besitzen.
Eigenschaften helfen, Konzepte genauer zu beschreiben und auszuwerten. Sie sollten fachlich verständlich und möglichst eindeutig definiert sein.
Beziehungen
Der wichtigste Unterschied zu einem einfachen Glossar liegt in den Beziehungen. Eine Ontology beschreibt nicht nur Begriffe, sondern auch deren Zusammenhänge.
Beispiele:
Ein Kunde hat Aufträge.
Ein Auftrag enthält Auftragspositionen.
Eine Rechnung gehört zu einem Auftrag.
Ein Produkt gehört zu einer Produktgruppe.
Ein Mitarbeiter gehört zu einer Organisationseinheit.
Eine Maschine befindet sich an einem Standort.
Diese Beziehungen sind entscheidend, weil viele analytische Fragen über mehrere Objekte hinweg gestellt werden. Ohne explizite Beziehungen bleibt unklar, in welchem fachlichen Rahmen Daten interpretiert werden dürfen.
Regeln und Bedeutung
Eine Ontology kann auch fachliche Regeln enthalten. Zum Beispiel, wann ein Kunde als aktiv gilt, welche Beziehung zwischen Rechnung und Auftrag maßgeblich ist oder welche Produktklassifikation für das Reporting verwendet wird.
Dabei geht es nicht darum, jede Regel in ein hochkomplexes Modell zu pressen. Wichtig ist, die Regeln festzuhalten, die für Analysen, Reporting, Governance und KI-Nutzung wirklich relevant sind.
Synonyme und Begriffsvarianten
In Unternehmen werden für dieselben Dinge oft unterschiedliche Begriffe verwendet. Vertrieb, Controlling, IT und Management sprechen nicht immer dieselbe Sprache.
Eine Ontology kann Synonyme und Begriffsvarianten verbinden. Das ist besonders für Natural Language Querying und KI-Assistenten wichtig. Wenn ein Nutzer nach „Umsatz“, „Revenue“ oder „Sales“ fragt, muss ein System verstehen, ob damit dasselbe gemeint ist oder unterschiedliche Kennzahlen angesprochen werden.
Der Einsatz von künstlicher Intelligenz macht Ontologien besonders relevant.
Ein Sprachmodell kann Formulierungen verstehen, Muster erkennen und Antworten erzeugen. Es weiß aber nicht automatisch, wie ein Unternehmen seine Daten, Prozesse und Begriffe fachlich definiert. Ohne Kontext arbeitet es auf Basis von Wahrscheinlichkeiten. Das kann plausibel wirken, ist aber bei Unternehmensdaten riskant.
Wenn ein AI Agent auf Daten zugreift, muss er wissen, welche Objekte existieren und wie sie zusammenhängen. Er muss verstehen, dass eine Rechnung zu einem Auftrag gehört, ein Auftrag Positionen enthält, Positionen Produkte referenzieren und Produkte wiederum Produktgruppen zugeordnet sind. Er muss auch wissen, welche Beziehungen für eine bestimmte Frage zulässig sind.
Eine Ontology gibt diesen Kontext vor. Sie beschreibt die fachliche Welt, in der sich ein KI-System bewegen darf.
Das ist wichtig, weil viele Fehler nicht durch fehlende Daten entstehen, sondern durch falsche Interpretation. Ein System kann eine Tabelle technisch korrekt lesen und trotzdem fachlich falsch antworten, wenn Beziehungen, Begriffe oder Regeln nicht bekannt sind.
Beispiel: Ein Nutzer fragt nach Kunden mit rückläufigem Umsatz in einer bestimmten Produktgruppe. Dafür muss ein System verstehen, was ein Kunde ist, welche Umsatzzahl maßgeblich ist, wie Produkte gruppiert werden, welche Zeitlogik gilt und wie Rechnungen, Aufträge und Kunden zusammenhängen.
Eine Ontology allein reicht dafür nicht aus. Sie braucht ein sauberes Datenmodell und eine klare Kennzahlenlogik im Semantic Layer. Aber sie hilft, den fachlichen Zusammenhang explizit zu machen. Gerade für KI-gestützte Analysen ist das ein wichtiger Schritt.
Eine Ontology wird häufig im Zusammenhang mit Knowledge Graphs genannt. Beide Begriffe hängen eng zusammen, sind aber nicht identisch.
Eine Ontology beschreibt das fachliche Modell. Sie legt fest, welche Konzepte es gibt und welche Beziehungen zwischen ihnen bestehen. Ein Knowledge Graph nutzt dieses Modell, um konkrete Objekte und Beziehungen abzubilden.
Vereinfacht gesagt:
Die Ontology beschreibt die Struktur der fachlichen Welt.
Der Knowledge Graph enthält konkrete Instanzen und Verbindungen.
Ein Beispiel:
Die Ontology sagt: Ein Kunde kann Aufträge haben. Ein Auftrag kann Rechnungen besitzen. Eine Rechnung bezieht sich auf Produkte.
Der Knowledge Graph enthält dann konkrete Informationen: Kunde A hat Auftrag 4711. Auftrag 4711 hat Rechnung 900123. Rechnung 900123 enthält Produkt X.
Für Unternehmen kann diese Denkweise besonders nützlich sein, wenn Zusammenhänge über mehrere Systeme, Domänen oder Prozesse hinweg analysiert werden sollen. Klassische Tabellenmodelle bleiben wichtig. Aber ein graphorientierter Blick kann Beziehungen sichtbarer machen, die in Tabellenstrukturen schwerer zu erkennen sind.
Auch moderne Datenplattformen greifen diese Entwicklung auf. Semantik, Governance, Katalogfunktionen, Graph-Strukturen und KI-Funktionen rücken näher zusammen. Das Ziel ist, Daten nicht nur technisch bereitzustellen, sondern mit Bedeutung, Kontext und Beziehungen nutzbar zu machen.
Trotzdem sollte Ontology nicht als neues Pflichtwerkzeug für jedes Projekt verstanden werden. Der Nutzen entsteht dort, wo fachliche Zusammenhänge komplex sind, mehrere Domänen verbunden werden müssen oder KI-Systeme einen kontrollierten Kontext benötigen.
Für einfache Reporting-Szenarien kann ein gutes Datenmodell mit sauberem Semantic Layer völlig ausreichen. In komplexeren Landschaften kann eine Ontology helfen, die fachliche Welt des Unternehmens expliziter und maschinenlesbarer zu beschreiben.
Eine Ontology sollte nicht als theoretisches Großprojekt starten. Der bessere Weg ist ein konkreter fachlicher Use Case.
Sinnvolle Startpunkte sind Bereiche, in denen viele Begriffe, Systeme und Beziehungen zusammenkommen. Zum Beispiel Vertrieb, Kundenmanagement, Finance, Supply Chain, Produktion oder ein konkreter KI-Anwendungsfall.
Ein pragmatisches Vorgehen kann so aussehen:
Zuerst werden die wichtigsten fachlichen Fragen gesammelt. Welche Zusammenhänge sollen besser verstanden werden? Welche Begriffe führen heute zu Missverständnissen? Wo braucht ein KI-System mehr Kontext?
Danach werden zentrale Konzepte identifiziert. In einem Vertriebsfall könnten das Kunde, Auftrag, Produkt, Rechnung, Region, Vertriebskanal und Organisationseinheit sein.
Anschließend werden Beziehungen beschrieben. Welche Objekte gehören zusammen? Welche Beziehung ist fachlich maßgeblich? Gibt es mehrere mögliche Beziehungen, zum Beispiel zwischen Auftrag, Lieferung und Rechnung?
Dann werden wichtige Eigenschaften, Synonyme und Regeln ergänzt. Dabei sollte die Ontology nicht überladen werden. Es geht um die Begriffe und Beziehungen, die für die Nutzung wirklich relevant sind.
Parallel muss geprüft werden, wie diese fachliche Sicht zur vorhandenen Datenmodellierung und zum Semantic Layer passt. Wenn die Ontology fachliche Beziehungen beschreibt, die im Datenmodell nicht sauber abgebildet sind, entsteht Klärungsbedarf. Das ist kein Fehler der Ontology, sondern oft ein wertvoller Hinweis auf strukturelle Lücken.
Entscheidend ist die Zusammenarbeit von Fachbereich, IT und Data Teams. Der Fachbereich kennt die Bedeutung der Begriffe. Data Teams kennen Datenstrukturen, Qualität und technische Abhängigkeiten. Gemeinsam entsteht ein Modell, das fachlich sinnvoll und technisch nutzbar ist.
Eine gute Ontology ist nicht fertig, sobald sie einmal erstellt wurde. Sie muss gepflegt werden, wenn sich Geschäftsmodelle, Produkte, Organisationen oder Datenlandschaften verändern. Deshalb braucht sie Verantwortlichkeiten, Governance und klare Regeln zur Weiterentwicklung.