Mehr als Daten: Warum Unternehmen Kontext brauchen

Die Daten sind da. Der Zusammenhang fehlt.

Stell in einem etablierten Unternehmen eine ganz normale Frage: Welche Kunden haben eine Maschine mit Konfiguration B im Einsatz – und welche davon müssen bis Ende Quartal geprüft werden?

Die Antwort existiert. Nur liegt sie verteilt: Die Kunden sind im ERP, die installierten Konfigurationen in einer Excel-Liste des Serviceteams, die Prüfintervalle in einem Wartungstool. Und wer letzte Woche eine Komponente getauscht hat, weiss nur der Techniker, der vor Ort war. Irgendwer findet die Antwort schon – nach einem halben Tag mit Exporten, Suchen und Telefonaten.

So zeigt sich im Alltag ein Problem, das kaum jemand beim Namen nennt. Den meisten Unternehmen fehlen nicht die Daten. Davon haben sie oft mehr als genug. Es fehlen die Verbindungen: Was gehört zu was? Was hängt wovon ab? Was ist vorher passiert? Die Informationen sind da, der Zusammenhang nicht.

Ein Unternehmen ist ein Netz

Wer genau hinschaut, merkt: Ein Unternehmen besteht nicht aus Dokumenten und Tabellen. Es besteht aus Dingen, die miteinander zusammenhängen.

Ein Kunde betreibt eine Anlage. Die Anlage steht an einem bestimmten Standort und ist auf eine bestimmte Art konfiguriert. Darin stecken Komponenten, jede mit Seriennummer und Version. Für die Anlage gelten Wartungsvorgaben. Eine Prüfung liefert Befunde, ein Befund löst eine Massnahme aus. Verträge legen fest, wer wofür geradesteht. Zertifikate, Berichte und Zeichnungen gehören zu ganz bestimmten Stellen in diesem Netz. Und Mitarbeitende, Lieferanten und Kunden sind jeweils für andere Teile davon zuständig.

Dieses Netz ist das Unternehmen, so wie es tatsächlich arbeitet. Erfahrene Mitarbeitende haben es zu grossen Teilen im Kopf. Die Software des Unternehmens meistens nicht.

Von einzelnen Datensätzen zu Beziehungen

Die meisten Business-Programme wurden für eine bestimmte Aufgabe gebaut und sehen die Welt aus diesem Blickwinkel. Das ERP kennt den Kunden und die Rechnung. Das CRM kennt die Ansprechperson. Die Servicesoftware kennt den Wartungsauftrag. Im Dokumentenmanagement liegt der Bericht. Und in einer Excel-Liste steht, welche Konfiguration wirklich verbaut ist.

Jedes dieser Systeme kann für sich stimmen – und trotzdem hat niemand das ganze Bild. Denn die Verbindungen zwischen den Daten, also genau das, was man für die Antwort auf die Frage oben braucht, liegen zwischen den Systemen. Dort setzt man sie jedes Mal von Hand neu zusammen. Oder sie existieren nur im Kopf.

---
config:
  flowchart:
    wrappingWidth: 240
---
graph LR;
    ERP["ERP
Kunde, Rechnung"];
    CRM["CRM
Kontakt"];
    SVC["Servicesoftware
Wartungsauftrag"];
    DMS["Dokumentenablage
Servicebericht"];
    XLS["Excel-Liste
Installierte Konfiguration"];

    ERP -. keine Verbindung .- XLS;
    XLS -. keine Verbindung .- SVC;
    CRM -. keine Verbindung .- SVC;
    SVC -. keine Verbindung .- DMS;

    classDef current fill:#FCE8E8,stroke:#C94A4A,color:#0d2123,stroke-width:1.5px;
    class ERP,CRM,SVC,DMS,XLS current;

    linkStyle 0,1,2,3 stroke:#C94A4A,color:#C94A4A,stroke-width:1.5px;

Schnittstellen helfen, Daten von einem System ins andere zu bringen. Aber wer eine Kundennummer aus dem ERP ins Servicetool kopiert, weiss danach immer noch nicht, welche Konfiguration dieser Kunde hat oder welche Prüfung als Nächstes ansteht.

Worauf es ankommt, lässt sich in vier Schritten zeigen:

---
config:
  flowchart:
    wrappingWidth: 240
---
graph LR;
    D["Daten
einzelne Werte"] --> O["Objekte
klar erkennbare Dinge"];
    O --> R["Beziehungen
wie sie zusammenhängen"];
    R --> C["Kontext
was das fürs
Geschäft bedeutet"];

Daten werden nützlich, wenn sie konkrete Dinge beschreiben. Noch nützlicher, wenn diese Dinge verbunden sind. Und richtig wertvoll, wenn die Verbindungen so aussehen, wie das Geschäft tatsächlich läuft.

Was eine Ontologie ist – einfach erklärt

Für ein solches Modell gibt es einen Fachbegriff: Ontologie. Das Wort klingt akademisch, die Idee dahinter ist aber simpel:

Eine Ontologie beschreibt, welche Dinge es in einem Unternehmen gibt, wie sie zusammenhängen und was sie im Arbeitsalltag bedeuten.

Ein Beispiel macht den Unterschied deutlich. In einer Datenbank steht vielleicht:

• Kunde 4711
• Maschine 0815
• Komponente A
• Servicebericht 2026-104

Das ist alles korrekt, aber für sich allein sagt es wenig. Hier dieselben Einträge, diesmal verbunden:

---
config:
  flowchart:
    wrappingWidth: 240
---
graph LR;
    C["Kunde 4711"] -->|betreibt| M["Maschine 0815"];
    M -->|steht in| L["Standort Zürich"];
    M -->|hat| K["Konfiguration B"];
    K -->|enthält| A["Komponente A"];
    A -->|getauscht bei| S["Service 2026-104"];
    M -->|nächste Prüfung| I["Prüfung fällig im März"];

Die Fakten sind dieselben. Aber jetzt ergibt sich ein Bild, mit dem jemand arbeiten kann. Genau darum geht es: Eine Datenbank speichert Informationen. Eine Ontologie zeigt, wie sie zusammenhängen.

Jedes Unternehmen hat dabei seine eigene Ontologie. Zwei Firmen derselben Branche verstehen unter einer «Anlage», einem «Auftrag» oder einem «Fall» oft etwas anderes. Das ist richtig so – in diesen Unterschieden steckt häufig genau das, was ein Unternehmen besonders macht.

Warum Beziehungen so viel verändern

Sind die Verbindungen einmal sauber erfasst, werden aus aufwendigen Recherchen einfache Abfragen. Welche Kunden sind betroffen, wenn ein Lieferant ein Problem mit einer bestimmten Komponentenversion meldet? Welche Verträge betreffen Anlagen an einem Standort, der geschlossen wird? Welche offenen Qualitätsprobleme hängen mit Maschinen zusammen, die im letzten Jahr umgebaut wurden?

Für keine dieser Fragen braucht es neue Daten. Es braucht nur Daten, die so verbunden sind, wie das Geschäft funktioniert.

Und das hilft weit über Auswertungen hinaus. Wer einen Serviceauftrag öffnet, sieht sofort Anlage, Konfiguration, Vorgeschichte und Vertrag – statt sich alles aus vier Systemen zusammenzusuchen. Kommt etwas Neues dazu, etwa eine Produktlinie oder ein Serviceangebot, erweitert man das Modell, statt noch ein weiteres Tool einzuführen.

Eine Ontologie ist mehr als ein Datenmodell

Man könnte das alles als «flexible Datenbanktabellen» abtun. Damit wäre aber das Wichtigste verpasst. Der eigentliche Wert entsteht durch das, was rund um die Objekte passiert. Ein Objekt soll nicht einfach Daten speichern, sondern in seinem Zusammenhang stehen.

---
config:
  flowchart:
    wrappingWidth: 240
---
graph LR;
    R["Beziehungen
Anlage, Kunde, Standort"] --- I(("Prüfung"));
    P["Berechtigungen
wer sie sehen oder ändern darf"] --- I;
    D["Dokumente
Berichte, Zertifikate"] --- I;
    I --- H["Historie
was vorher war"];
    I --- W["Workflow
was als Nächstes passiert"];

Berechtigungen gehören dazu

Ein gutes Modell zeigt nicht nur, was es gibt. Es regelt auch, wer was sehen, ändern oder auslösen darf.

Nimm einen Servicebericht. Der Techniker hat ihn geschrieben, der Kunde will wissen, was an seiner Maschine gemacht wurde, die Qualitätsverantwortliche prüft ihn, und der Lieferant sollte nur den Teil sehen, der seine Komponente betrifft. Alle brauchen etwas anderes aus demselben Dokument.

Werden Berechtigungen erst im Nachhinein geregelt – pro Programm, pro Export, pro Netzwerkordner –, passen sie bald nicht mehr zusammen. Sind sie Teil des Modells, folgen sie automatisch der Struktur des Unternehmens: Kunden sehen ihre eigenen Anlagen, Lieferanten die Befunde zu ihren Komponenten.

Die Historie erzählt, wie es dazu kam

Zu wissen, in welchem Zustand eine Anlage oder ein Fall gerade ist, hilft. Zu wissen, wie es dazu kam, hilft oft noch mehr. Warum wurde die Konfiguration geändert? Wer hat die Abweichung freigegeben? Wie sah die Maschine vor dem letzten Service aus?

Ein Modell, das jede Änderung festhält, zeigt nicht nur den Moment, sondern die ganze Entwicklung. Das ist bei Audits praktisch. Wichtiger ist aber der Nutzen im Alltag: Man erkennt Muster, kann Entscheidungen nachvollziehen, und das Wissen geht nicht verloren, wenn jemand die Stelle wechselt.

Mit Geschäftslogik arbeitet das Modell mit

Mit Geschäftsobjekten passiert laufend etwas. Eine Prüfung wird fällig. Eine Maschine wird umgebaut. Ein Qualitätsproblem verlangt eine Massnahme. Ein Vertrag läuft aus. Ein Serviceauftrag muss freigegeben werden.

Hängen die passenden Abläufe und Regeln direkt an diesen Objekten, beschreibt das Modell nicht mehr nur, was ist. Die fällige Prüfung erzeugt selbst die nötige Aufgabe. Der Befund landet automatisch bei der richtigen Person zur Freigabe. Das Modell bildet das Geschäft nicht nur ab – es hilft mit, es zu führen.

So setzt Exolynk das um

Genau das ist die Idee hinter Exolynk. Unternehmen legen ihre eigenen Datenmodelle an – für Kunden, Maschinen, Standorte, Verträge, Produkte, Komponenten, Prüfungen, Serviceaufträge, Qualitätsprobleme, Dokumente, Mitarbeitende oder was auch immer in ihrem Betrieb eine Rolle spielt. Diese Objekte werden über Beziehungen verbunden, die die Plattform sicherstellt. Exolynk ist bewusst nicht auf eine Branche zugeschnitten: Du bildest dein Unternehmen so ab, wie es arbeitet, statt es in eine fertige Software zu zwängen.

Rund um dieses Modell kommt alles zusammen, was oben beschrieben ist:

• Beziehungen zwischen den Objekten – jede Information gibt es nur einmal, verbunden überall dort, wo sie gebraucht wird
• Rollen und fein abgestufte Berechtigungen, bis hinunter zum einzelnen Datensatz
• Verlauf und Audit-Trail, damit jede Änderung nachvollziehbar bleibt
• Workflows, die zu einem bestimmten Zeitpunkt oder bei einer Änderung am Objekt starten
• Dokumente und Schnittstellen – per REST API und Webhooks –, direkt verknüpft mit dem passenden Objekt
• Eigene Logik mit klaren Grenzen: Wo Konfiguration nicht reicht, laufen eigene Skripte in einer abgeschotteten Umgebung. So lässt sich die Plattform erweitern, ohne dass fremder Code das System gefährden kann

Auch das Modell selbst bleibt beweglich. Dank Entwurfs- und Live-Version, Versionierung und Freigabeprozess kann es mit dem Unternehmen mitwachsen und ist nach der Einführung nicht in Stein gemeisselt.

Warum das mit KI noch wichtiger wird

Alles bisher Gesagte lohnt sich auch ganz ohne KI. Mit KI wird ein gut strukturiertes Modell aber noch um einiges wertvoller.

Sprachmodelle können Texte, Dokumente und unklare Angaben erstaunlich gut verstehen. Was sie nicht wissen, ist, wie dein Unternehmen funktioniert. Eine KI weiss nicht von selbst, welche Maschine zu welchem Kunden gehört, welche Konfiguration gerade verbaut ist, welche Prüfung für welche Anlage gilt, welcher Quelle sie glauben soll, wenn sich zwei Dokumente widersprechen, wer einen bestimmten Datensatz sehen darf oder was in welcher Situation erlaubt ist.

Ohne diesen Zusammenhang arbeitet KI mit Bruchstücken: ein paar Dokumente aus einer Stichwortsuche, eine einzelne Antwort aus einem System, oder das, was jemand in den Chat kopiert hat. Das Ergebnis klingt dann vielleicht überzeugend, stimmt aber trotzdem nicht.

Mit einer Ontologie dahinter kann die KI mit den echten Geschäftsobjekten und ihren Verbindungen arbeiten. Statt nur «Finde Dokumente, in denen Maschine 0815 vorkommt» kann man fragen: «Welche Maschinen mit dieser Konfiguration stehen bei Kunden, welche Komponenten sind darin verbaut, und welche davon sind von dieser Wartungsvorgabe betroffen?» Die Antwort stützt sich auf dieselben Daten, mit denen auch alle anderen im Unternehmen arbeiten – und zeigt nur, was die fragende Person sehen darf.

Die KI entscheidet dabei nicht selbstständig. Sie versteht den Zusammenhang besser. Das Urteil bleibt beim Menschen.

KI baut auf dem Fundament auf – sie ist nicht der Grund dafür

Hier liegt ein Punkt, den man leicht verwechselt. Unternehmen sollten ihre Daten nicht wegen der KI strukturieren. Sondern weil ein zusammenhängendes Modell des Unternehmens Anwendungen, Abläufe, Auswertungen, Schnittstellen und die tägliche Arbeit besser macht. Die KI profitiert einfach auch davon.

Diese Reihenfolge ist wichtig, weil sich die KI-Welt schnell verändert. Die heutigen Modelle werden abgelöst, wahrscheinlich mehrmals. Ein sauberes Modell deines Unternehmens hängt davon nicht ab. Es bleibt wertvoll, egal welche KI darauf zugreift – und es funktioniert auch, wenn gar keine KI im Spiel ist. Wie wir in Jenseits der Benutzeroberfläche geschrieben haben: Eine Business-Plattform muss auch ganz ohne KI laufen können. KI ist ein zusätzlicher Weg hinein, keine Abhängigkeit.

Das digitale Abbild deines Unternehmens gehört dir

Mit der Zeit wird eine solche Ontologie mehr als ein IT-Projekt. Objekte, Beziehungen, Berechtigungen, Verlauf und Regeln ergeben zusammen ein digitales Abbild davon, wie dein Unternehmen arbeitet – und damit auch von vielem, was es besonders macht.

Wo dieses Abbild liegt und wer darüber bestimmt, ist deshalb eine strategische Frage. Nicht aus Misstrauen gegenüber einem bestimmten Anbieter, sondern aus einem einfachen Grund: KI-Modelle und Anbieter kommen und gehen. Das digitale Abbild deines Unternehmens sollte dir gehören.

Exolynk wird in der Schweiz entwickelt und gehostet. Die Plattform läuft als SaaS, auf eigener dedizierter Infrastruktur oder On-Premises. Das Modell, sein Verlauf und seine Regeln bleiben in einer Umgebung, über die das Unternehmen selbst bestimmt.

Vom Modell zur Umsetzung

Mit Exolynk musst du nicht heute ein Modell aufbauen und dir erst später überlegen, wie die KI dazukommt. Dieselbe Plattform, auf der das Modell liegt, verbindet es auch kontrolliert mit KI. KI-Schritte lassen sich direkt in Workflows einbauen, und externe Assistenten können über MCP mit dem Modell arbeiten. Dabei gelten dieselben Berechtigungen, pro Tool lässt sich festlegen, was ohne Bestätigung laufen darf, und jede Aktion wird protokolliert. Mehr zum technischen Hintergrund steht in unserem MCP-Artikel .

Die KI setzt also auf dem Fundament auf. Sie ist nicht der Grund, warum es das Fundament braucht.

Der nächste Schritt

Digitalisierung hiess lange vor allem: Informationen in Software bringen. Diesen Schritt haben die meisten Unternehmen längst gemacht, oft mehrfach.

Der nächste Schritt ist, diese Informationen so zu verbinden, wie das Unternehmen tatsächlich funktioniert: welche Dinge es gibt, wie sie zusammenhängen, wer wofür zuständig ist und wie sich alles über die Zeit verändert. Ein solches Modell macht schon heute Anwendungen, Automatisierung und Entscheidungen besser. Und es ist die Grundlage, damit KI dein Unternehmen morgen versteht – und irgendwann auch darin handeln kann, innerhalb klarer Grenzen.

Genau dafür gibt es Exolynk: um dieses Fundament aufzubauen – und es in deinen Händen zu behalten.