Business Intelligence
im KI-Zeitalter.

Eine Geschäftsleitung betrachtet Ergebnis und Liquidität, der Vertrieb die Entwicklung von Kunden und Aufträgen, der Betrieb Qualität und Durchlaufzeiten. Diese Perspektiven hängen zusammen. Werden sie aus getrennten Dateien und unterschiedlich definierten Kennzahlen abgeleitet, beginnt die Besprechung häufig mit einem Abgleich der Zahlen. Business Intelligence soll diese Reibung verringern und eine Grundlage schaffen, auf der unterschiedliche Bereiche gemeinsam handeln können.

Im KI-Zeitalter verändert sich vor allem der Zugang. Mitarbeitende können Fragen in Alltagssprache stellen, Auffälligkeiten beschreiben lassen oder sich eine Analyse vorbereiten lassen. Dadurch werden bestehende Unklarheiten jedoch sichtbarer: Was bedeutet „Umsatz“ in diesem Bericht? Welcher Zeitraum ist abgeschlossen? Sind Retouren enthalten? Eine flüssige Antwort löst diese fachlichen Fragen nicht. Sie braucht eine Datenbasis, in der ihre Bedeutung ausdrücklich festgelegt ist.

Gute BI verbindet drei Aufgaben: Sie macht den aktuellen Stand nachvollziehbar, hilft Veränderungen einzuordnen und unterstützt eine konkrete Entscheidung. Ein Dashboard beantwortet beispielsweise, wo die Liefertermintreue sinkt. Eine vertiefende Analyse zeigt, welche Produktgruppen und Prozessschritte betroffen sind. Die Entscheidung über eine Maßnahme bleibt ein eigener Schritt mit Verantwortlichen, Annahmen und späterer Wirkungskontrolle. Eine Korrelation allein erklärt noch keine Ursache.

Der Einstieg sollte deshalb bei wiederkehrenden Entscheidungen beginnen. Welche Information fehlt heute, wer benötigt sie und bis wann muss sie verlässlich vorliegen? Der Nutzen lässt sich an weniger manueller Abstimmung, kürzerer Vorbereitungszeit, nachvollziehbaren Entscheidungen und einer besseren Rückmeldung über Maßnahmen messen. Mehr Diagramme oder mehr KI-Antworten sind für sich genommen kein Fortschritt.

Eine BI-Architektur beginnt in den führenden Fachsystemen: etwa ERP, CRM, Warenwirtschaft, Produktion oder digitalen Vertriebskanälen. Diese Systeme bilden operative Vorgänge ab. Für Analysen werden relevante Daten kontrolliert übernommen, vereinheitlicht und historisiert. Das Data Warehouse stellt dafür einen geordneten analytischen Bestand bereit. Es entlastet operative Anwendungen und ermöglicht Auswertungen über ihre jeweiligen Grenzen hinweg.

Darauf baut die fachliche Bedeutungsschicht auf: der Semantic oder Metric Layer. Er beschreibt Kennzahlen, Dimensionen und zulässige Kombinationen. Eine API macht ausgewählte Abfragen für Dashboards, Anwendungen und KI-Werkzeuge nutzbar. Ein optionaler Graph Layer ergänzt ausdrückliche Beziehungen, beispielsweise zwischen einer Kennzahl, ihrem Datenmodell, dem verantwortlichen Team und einem Geschäftsprozess. So lassen sich Zahlen und ihr Kontext gemeinsam erschließen.

Diese Ebenen sind Aufgabenbereiche, keine Einkaufsliste. Ein vorhandenes System kann mehrere Aufgaben übernehmen. Ein kleiner Einstieg kann mit einer verlässlichen Datenpipeline, gepflegten Modellen und einer BI-Oberfläche auskommen. Erst wenn weitere Anwendungen oder komplexere Beziehungen es rechtfertigen, werden zusätzliche Zugänge und Speicher benötigt. Entscheidend sind verständliche Zuständigkeiten und stabile Übergaben zwischen den Ebenen.

Die folgende Übersicht zeigt einen möglichen Aufbau. Der Zugriff nutzt geprüfte Definitionen und freigegebene Schnittstellen; der Graph liefert ergänzenden Kontext. Ein Sprachmodell erhält dadurch nicht automatisch Zugriff auf alle Tabellen. Auch muss nicht jede BI-Abfrage einen Graph oder eine eigene API durchlaufen. Bestehende BI-Werkzeuge können direkt über geregelte SQL-Zugänge oder semantische Modelle zugreifen. Die passende Route ergibt sich aus Fragestellung und Berechtigungen.

Ein Graph Layer, eine API und ein Data Warehouse erfüllen unterschiedliche Aufgaben. Ihre Verbindung schafft Wiederverwendbarkeit: dieselbe geprüfte Kennzahl kann in einem Dashboard, einer Fachanwendung und einer KI-gestützten Analyse erscheinen.

Ein Data Warehouse ist ein für Analysen modellierter Datenbestand. Es führt ausgewählte Daten aus mehreren Quellen zusammen und bewahrt die für Auswertungen erforderliche Historie. Es ist weder lediglich eine große Datenbank noch automatisch die einzige Ablage des Unternehmens. Rohdateien, Dokumente und operative Transaktionen können weiterhin in anderen Systemen bleiben. Wichtig ist, welche Aussagen das analytische Modell verlässlich beantworten soll.

Am Anfang steht die Granularität: Wofür steht eine Zeile? Für eine Bestellposition, eine Lieferung oder einen täglichen Lagerbestand? Erst danach werden Messwerte und beschreibende Dimensionen festgelegt. Fakten enthalten beispielsweise Menge und Betrag; Dimensionen beschreiben Produkt, Kunde, Standort oder Zeit. Werden Daten unterschiedlicher Körnung unkontrolliert verbunden, können Beträge mehrfach gezählt werden. Auch Bestände lassen sich nicht wie Verkäufe beliebig über mehrere Tage aufsummieren.

Historie ist eine fachliche Entscheidung. Ein Kunde kann heute einem anderen Vertriebsgebiet zugeordnet sein als zum Zeitpunkt eines früheren Auftrags. Soll eine Auswertung den damaligen oder den heutigen Zustand zeigen? Beide Perspektiven können sinnvoll sein, müssen aber unterscheidbar bleiben. Das Modell muss außerdem mit nachträglichen Korrekturen, verspäteten Buchungen und abgeschlossenen Perioden umgehen. Ohne diese Regeln verändert sich eine scheinbar eindeutige Zeitreihe unbemerkt.

ETL und ELT beschreiben unterschiedliche Reihenfolgen der Verarbeitung: Daten werden vor oder nach dem Laden in die analytische Plattform transformiert. Beide Varianten benötigen definierte Quellsysteme, nachvollziehbare Transformationen und Qualitätsprüfungen. Ein Lakehouse kann Speicherung und analytische Verarbeitung auf einer anderen technischen Grundlage verbinden. Es ersetzt dabei weder fachliche Modellierung noch die Festlegung verlässlicher Kennzahlen.

Aktualität hat einen Preis und einen Zweck. Für Monatsabschlüsse gelten andere Anforderungen als für eine operative Bestandsübersicht. Statt pauschal Echtzeit zu verlangen, werden fachlich notwendige Aktualisierungsintervalle vereinbart. Vollständigkeit, Schlüsselbeziehungen, Dubletten und unerwartete Mengenänderungen werden beim Laden geprüft. Ein sichtbarer Datenstand hilft Anwendern, eine aktuelle Beobachtung von einer noch unvollständigen Periode zu unterscheiden.

„Wie stark sind wir gewachsen?“ klingt einfach, lässt aber viele Entscheidungen offen. Geht es um Auftragseingang, fakturierten Umsatz oder Zahlungseingang? Werden Retouren und Stornierungen berücksichtigt? Welche Gesellschaften, Währungen und Zeiträume gehören dazu? Der Semantic Layer macht diese Bedeutung explizit. Ein Metric Layer konzentriert sich besonders auf wiederverwendbare Kennzahlendefinitionen. Die konkrete Aufteilung hängt von den eingesetzten Werkzeugen ab.

Eine Kennzahl braucht mehr als eine Formel. Zu ihr gehören Geltungsbereich, Filter, Zeitbezug, Einheit, erlaubte Dimensionen, Aktualität und fachliche Verantwortung. Änderungen werden versioniert und auf ihre Wirkung auf bestehende Berichte geprüft. So kann eine Person nachvollziehen, warum ein Wert anders ausfällt als im vorherigen Bericht. Dieselbe Definition lässt sich auch einer KI als zugelassenes Werkzeug anbieten.

Das interaktive Beispiel verwendet frei gewählte Eurobeträge ohne Mehrwertsteuer: bestätigte Verkäufe von 120.000 Euro und zugehörige Retouren von 10.000 Euro ergeben 110.000 Euro Nettoerlös. Gegenüber einem vergleichbar abgegrenzten Nettoerlös von 100.000 Euro in der Vorperiode beträgt das Wachstum zehn Prozent. Wer die aktuellen Verkäufe ungeprüft mit diesem Vorperiodenwert vergleicht, erhält zwanzig Prozent. Diese zweite Zahl misst nicht dieselbe sauber definierte Kennzahl.

Das Beispiel zeigt keine allgemeingültige Umsatzdefinition. Es veranschaulicht, warum aktueller Wert und Vergleichsbasis denselben Regeln folgen müssen. In der Praxis sind etwa die Zuordnung einer Retoure zur Periode und der Umgang mit Wechselkursen fachlich zu klären. Eine gute Oberfläche zeigt die verwendete Definition, den Datenstand und relevante Einschränkungen direkt beim Ergebnis – auch wenn die Frage per Chat gestellt wurde.

Ein API Layer stellt ausgewählte Daten und Berechnungen über definierte Schnittstellen bereit. Eine Anwendung kann beispielsweise die freigegebene Kennzahl für einen Zeitraum und einen zulässigen Organisationsbereich anfordern. Die Schnittstelle prüft Eingaben, Berechtigungen und Grenzen und liefert eine strukturierte Antwort. Sie macht ein Datenmodell dadurch nutzbar, ohne jedem Verbraucher dessen gesamte interne Tabellenstruktur offenzulegen.

Zum Vertrag einer solchen Schnittstelle gehören Pflichtparameter, Einheiten, Zeitbezug, Datenstand und Fehlerzustände. Eine leere Ergebnismenge ist etwas anderes als ein ausgefallener Datenzugang. Eine Antwort sollte deshalb nicht nur einen Zahlenwert, sondern auch die Informationen enthalten, die für seine Einordnung erforderlich sind. Versionierung verhindert, dass eine geänderte Definition bestehende Anwendungen unbemerkt anders reagieren lässt.

Die Schnittstelle setzt die Rechte der anfragenden Person oder Anwendung durch. Dazu können Zeilenfilter für Gesellschaften und Spaltenregeln für sensible Daten gehören. Auch zwischengespeicherte Ergebnisse müssen diesen Kontext berücksichtigen. Ein weitreichendes Servicekonto ohne zusätzliche wirksame Durchsetzung der Nutzerrechte würde die fachlich gewollte Trennung aufheben. Zugriffsprüfung und Abfragebegrenzung gehören deshalb in die ausführende Umgebung und nicht nur in einen Prompt.

Eine API kann ein geprüfter Kennzahlenzugang, eine Graphabfrage oder eine eng begrenzte Suchfunktion sein. Sie ist nicht automatisch ein weiterer Datenspeicher. GraphQL wiederum ist eine Sprache und ein Ausführungsmodell für API-Abfragen; der Name bedeutet nicht, dass darunter eine Graphdatenbank liegt. Diese Trennung hilft bei der Architektur: Schnittstellen beschreiben den Zugang, Datenmodelle die fachliche Struktur und Speicher die technische Ablage.

Das Warehouse beantwortet vor allem quantitative Fragen: Wie hoch ist ein Wert, wie hat er sich entwickelt und wie verteilt er sich? Ein Graph Layer ergänzt ausdrücklich modellierte Beziehungen. Eine Kennzahl basiert auf einem Datenmodell, dieses nutzt bestimmte Quellen, ein Team verantwortet die Definition und ein Prozess verwendet das Ergebnis. Solche Zusammenhänge können über mehrere Systeme und Zuständigkeiten hinweg abgefragt werden.

Der Nutzen liegt beispielsweise in einer Änderung am Quellsystem: Welche Datenprodukte und Berichte hängen davon ab, und wer muss die Änderung prüfen? Eine andere Frage betrifft die Interpretation: Welche Definition gilt für diese Kennzahl, welcher Prozess steht dahinter und welche Richtlinie schränkt ihre Verwendung ein? Eine gepflegte Verbindung spart wiederholte manuelle Recherche und macht vorhandenes Wissen für andere Teams zugänglich.

Dafür braucht der Graph stabile Kennungen und belegte Beziehungen. Ein gleich geschriebener Produktname reicht nicht aus, um Datensätze sicher zusammenzuführen. Fachliche Beziehungen, technische Datenherkunft und organisatorische Verantwortung sind außerdem unterschiedliche Beziehungstypen. Sie sollten erkennbar bleiben. Automatisch vorgeschlagene Verknüpfungen können bei der Pflege helfen, benötigen aber einen ihrem Risiko angemessenen Prüf- und Freigabeprozess.

Der Graph ersetzt das Warehouse nicht. Umfangreiche Summen und Zeitreihen können weiterhin dort berechnet werden, während der Graph Zusammenhänge erschließt. Ebenso beweist eine Verbindung oder gemeinsame Veränderung keine kausale Wirkung. Ob ein Prozessschritt ein Ergebnis verursacht, erfordert eine passende fachliche Analyse. Auch ein Graph ist nur so vollständig und aktuell wie seine gepflegten Quellen; eine fehlende Kante belegt keine fehlende Abhängigkeit.

Sprachmodelle können eine Frage strukturieren, passende Kennzahlen vorschlagen und ein Ergebnis verständlich erläutern. Sie sind besonders hilfreich, wenn Menschen die Struktur des Datenmodells nicht kennen. Die verlässliche Berechnung sollte jedoch in den dafür vorgesehenen Datenwerkzeugen erfolgen. Die KI formuliert und koordiniert; das Warehouse oder eine freigegebene Berechnungsfunktion liefert den geprüften Zahlenwert.

Text-to-SQL übersetzt eine Frage in eine Datenbankabfrage. Das ist ein möglicher Zugang, aber keine Garantie für eine fachlich richtige Analyse. Eine syntaktisch gültige Abfrage kann die falsche Tabelle, eine ungeeignete Verknüpfung oder einen unpassenden Zeitraum verwenden. Begrenzte Datenmodelle, bekannte Kennzahlen, lesende Rechte und eine Prüfung der Abfrage reduzieren den Spielraum. Laufzeit- und Mengenlimits schützen den Betrieb; Testergebnisse zeigen, welche Fragen der Zugang tatsächlich zuverlässig bearbeitet.

Ein Agent kann mehrere Schritte verbinden: die Frage präzisieren, den richtigen Datenstand bestimmen, eine Kennzahl abrufen, Abweichungen aufschlüsseln und Kontext aus dem Graph ergänzen. Als Ergebnis entsteht ein nachvollziehbarer Analyseentwurf mit Quellen und offenen Punkten. Der Agent sollte nachfragen, wenn mit „letzter Monat“ der Kalendermonat, die letzte abgeschlossene Buchungsperiode oder die vergangenen 30 Tage gemeint sein könnten. Er darf diese Unsicherheit nicht durch eine überzeugend formulierte Vermutung verdecken.

Ein sinnvoller Qualitätsvergleich betrachtet den vollständigen Vorgang: fachliche Richtigkeit, passende Berechtigungen, notwendige Rückfragen, Bearbeitungszeit und Aufwand für die Prüfung. Ein richtig berechneter Wert kann trotzdem eine unzulässige Offenlegung oder eine unpassende Entscheidungsgrundlage sein. Schreibende Aktionen, etwa die Änderung einer Planung, erhalten daher einen eigenen freigegebenen Ablauf. Eine Erklärung einer Entwicklung ist zunächst eine Analyse; sie löst nicht automatisch eine Maßnahme aus.

Self-hosted bezeichnet zunächst die Verantwortung für den Betrieb. Die Software kann auf eigener Infrastruktur oder in einer gemieteten Cloud-Umgebung laufen. Cloud beschreibt ein Bereitstellungs- und Dienstmodell, in dem Rechenressourcen bedarfsgerecht verfügbar werden und je nach Dienst unterschiedlich viel Betriebsarbeit übernommen wird. Der physische Standort ist eine zusätzliche Frage. Diese Begriffe sind deshalb keine vollständigen Gegensätze. Für eine belastbare Entscheidung muss klar sein, wer jede Komponente betreibt und welche Daten sie tatsächlich verarbeitet.

Beim selbst verantworteten Betrieb liegen unter anderem Updates, Sicherung, Wiederherstellung, Überwachung und Kapazitätsplanung beim Unternehmen oder seinem Dienstleister. Das ermöglicht eigene Gestaltung und Integration, setzt aber verfügbare Kompetenz und verlässliche Prozesse voraus. Ein verwalteter Cloud-Dienst kann Teile dieser Arbeit übernehmen. Definitionen, Zugriffsrollen, Datenqualität und die Verantwortung für die fachliche Nutzung bleiben dennoch Aufgaben des Unternehmens.

Ein hybrider Aufbau verteilt Komponenten bewusst. Beispielsweise können sensible Quelldaten und das Warehouse in einer kontrollierten Umgebung bleiben, während eine Cloud-Anwendung nur freigegebene, ausreichend begrenzte Ergebnisse erhält. Umgekehrt kann ein verwaltetes Warehouse mit selbst betriebenen Integrationen und einem lokalen Modell kombiniert werden. „Hybrid“ beschreibt keine einzelne feste Architektur. Entscheidend ist die Freigabe des konkreten Datenflusses einschließlich Protokollen, Caches, Sicherungen und Modellanfragen.

Für den Vergleich zählen Gesamtkosten und Betriebsfähigkeit: Infrastruktur, Lizenzen, Personal, Bereitschaft, Entwicklung, Datenübertragung und erwartete Last. Auch der Wechsel eines Dienstes und die Wiederherstellung nach einem Ausfall gehören dazu. Ein niedriger Einstiegspreis kann bei vielen Abfragen oder Datenbewegungen anders wirken als ein kalkulierbarer Dauerbetrieb. Umgekehrt ist eigene Infrastruktur nicht kostenlos, nur weil sie bereits vorhanden ist.

Die interaktive Gegenüberstellung zeigt drei mögliche Zuordnungen. Sie vergibt keine pauschale Bestnote. Region und Datenstandort allein belegen weder Datenschutzkonformität noch Sicherheit; maßgeblich sind die tatsächliche Verarbeitung, Verträge, Zugriffsmöglichkeiten und getroffenen Maßnahmen. Die passende Variante ist jene, deren Grenzen und Betriebsaufgaben das Unternehmen verstehen, finanzieren und dauerhaft erfüllen kann.

Ein tragfähiger Einstieg ist klein genug, um vollständig überprüft zu werden, und wichtig genug, um im Alltag genutzt zu werden. Dafür wird eine wiederkehrende Entscheidung mit den beteiligten Fachbereichen ausgewählt. Gemeinsam werden Kennzahlen, Datenquellen, notwendige Aktualität und der bisherige Abstimmungsaufwand dokumentiert. Der erste Erfolg ist eine verlässlich beantwortete Frage, deren Definition auch außerhalb des Projektteams verstanden wird.

Danach wird ein durchgängiger Ausschnitt umgesetzt: von der Quelle über die Transformation und das Modell bis zur Ausgabe. Datenqualität und Berechtigungen werden entlang dieser Strecke geprüft. Eine geeignete Referenzauswertung dient zum Abgleich. Erst wenn Datenstand, Berechnung und Interpretation stimmen, wird der Zugang um zusätzliche Abfragen oder KI-Funktionen erweitert. So lässt sich erkennen, ob ein Fehler aus der Quelle, dem Modell oder der sprachlichen Verarbeitung stammt.

Für den Betrieb braucht jeder wichtige Datenbestand und jede zentrale Kennzahl eine benannte Verantwortung. Fachbereiche entscheiden über Bedeutung und erlaubte Verwendung; Daten- und Entwicklungsteams pflegen Modelle und Schnittstellen; der Betrieb sichert Verfügbarkeit und Wiederherstellbarkeit. Änderungen an Quellen oder Definitionen werden angekündigt, geprüft und nachvollziehbar veröffentlicht. Ein Katalog und die Beziehungen im Graph können diese Zusammenarbeit unterstützen.

Datenschutz und Vertraulichkeit werden im Datenmodell und im Zugriff berücksichtigt. Welche personenbezogenen Daten sind für die jeweilige Analyse erforderlich, wie lange werden sie benötigt und wer darf Details sehen? Aggregation allein garantiert keine Anonymität, insbesondere bei kleinen Gruppen. Auch Exporte, Protokolle, Sicherungen und KI-Eingaben gehören zum Verarbeitungsumfang. Fachliche und rechtliche Anforderungen werden für den konkreten Einsatz geklärt und anschließend technisch umgesetzt.

Die Weiterentwicklung orientiert sich an Nutzung und Wirkung. Werden Definitionen akzeptiert, sinkt der manuelle Abgleich und werden Entscheidungen nachvollziehbar dokumentiert? Welche Rückfragen häufen sich, wo fehlen Beziehungen und welche Daten werden nicht zuverlässig geliefert? Aus diesen Beobachtungen entstehen die nächsten Ausbauschritte. So wächst BI zu einer gemeinsamen Infrastruktur für Menschen, Anwendungen und KI, deren Qualität im laufenden Betrieb sichtbar bleibt.