Teil 3 von 3 der Serie „KI auf Unternehmensdaten – verlässlich statt plausibel": Teil 1: ChatGPT vs. oneAgent · Teil 2: Korrektes SQL, falsche Kennzahl · Teil 3: Data Warehouse mit KI abfragen (dieser Artikel)
Viele Unternehmen haben in ihre Datenplattform investiert.
Sie haben Daten aus ERP, CRM, Shop, Marketing und Finance zusammengeführt, ein Data Warehouse aufgebaut und Dashboards in Power BI oder anderen BI-Systemen erstellt.
Die Daten sind vorhanden.
Trotzdem erleben wir in Kundengesprächen häufig dieselbe Situation:
Ein Mitarbeiter hat eine konkrete Frage. Die Antwort steckt in den Daten, kann vom Fachbereich aber nicht direkt abgerufen werden.
Also entsteht ein Ticket.
Ein Analyst sucht die passenden Tabellen, stimmt die Kennzahl ab, erstellt die Abfrage und bereitet das Ergebnis auf.
Einige Tage später liegt die Antwort vor.
Meist folgt sofort die nächste Frage:
„Warum ist das in dieser Region anders?"
Dann beginnt der Prozess erneut.
Das Problem ist nicht, dass das Unternehmen zu wenig Daten besitzt.
Das Problem ist der Zugang.
Das Data Warehouse kennt die Antwort. Aber nur wenige Menschen können ihm die richtige Frage stellen.
Ein Data Warehouse ist noch kein Self-Service
Ein Data Warehouse schafft:
- eine gemeinsame Datenbasis,
- konsolidierte Informationen,
- historische Vergleiche,
- kontrollierte Zugriffe,
- und die Grundlage für Reports.
Der Zugang bleibt jedoch häufig technisch.
Für eine neue Analyse muss jemand wissen:
- welche Tabellen relevant sind,
- wie sie zusammenhängen,
- welche Kennzahl gilt,
- welche Filter gesetzt werden müssen,
- und welche Datumsspalte richtig ist.
Diese Fähigkeiten liegen bei BI-Entwicklern, Data Engineers und Analysten.
Für komplexe Analysen ist das sinnvoll.
Problematisch wird es, wenn auch einfache Folgefragen immer von Spezialisten abhängen.
Warum Dashboards nicht jede Frage beantworten
Dashboards sind wichtig.
Sie eignen sich besonders für:
- wiederkehrende Kennzahlen,
- standardisierte Managementberichte,
- KPI-Monitoring,
- und schnelle Übersichten.
Ein Dashboard kann beispielsweise zeigen:
Der Umsatz ist im Mai um zwölf Prozent gesunken.
Damit ist das Problem sichtbar.
Aber noch nicht erklärt.
Nun entstehen Fragen:
- Welche Produkte verursachen den Rückgang?
- Betrifft er bestimmte Regionen?
- Sind Neu- oder Bestandskunden betroffen?
- Sind Retouren gestiegen?
- Haben sich Absatzmenge oder Preise verändert?
Für jede mögliche Folgefrage eine eigene Dashboard-Seite zu bauen, ist weder realistisch noch wirtschaftlich.
Das Dashboard zeigt das Was. oneAgent hilft beim Warum.
Nicht jede Frage braucht ein neues Dashboard
Mit der Zeit entstehen in vielen Unternehmen zahlreiche Reports:
- ähnliche Dashboards für verschiedene Teams,
- Kopien mit leicht abweichenden Filtern,
- unterschiedliche Versionen derselben Kennzahl,
- und hoher Pflegeaufwand.
Dabei sind manche Fragen nur einmal relevant:
„Warum ist die Conversion Rate vergangene Woche eingebrochen?"
Andere entstehen erst aus einer vorherigen Antwort:
„Welche drei Produkte erklären den Unterschied?"
Für solche dynamischen Fragen ist ein Dialog besser geeignet als ein festes Dashboard. Was hinter diesem Ansatz steckt, erklären wir in Was ist Natural Language BI?
Der Nutzer formuliert seine Frage in natürlicher Sprache und kann direkt auf dem Ergebnis aufbauen.
oneAgent ersetzt das Data Warehouse nicht
Bei neuen KI-Lösungen entsteht schnell die Sorge vor einer zusätzlichen Plattform oder einem neuen Datensilo.
oneAgent verfolgt einen anderen Ansatz.
Operative Systeme
↓
Bestehendes Data Warehouse oder Lakehouse
↓
Datenmodell und Kennzahlenlogik
↓
Power BI, Reports und oneAgent
Die bestehende Datenplattform bleibt die Grundlage.
oneAgent ergänzt sie um einen weiteren Zugang:
- Dashboards für standardisierte Berichte,
- oneAgent für flexible Fragen und Folgeanalysen.
Investitionen in Datenmodelle, Views, Kennzahlen und Berechtigungen bleiben erhalten.
oneAgent ersetzt das Data Warehouse nicht. Es macht es dialogfähig. Wie die Anbindung an Ihr Data Warehouse konkret abläuft – vom Erstgespräch bis zum Pilot – zeigt unsere Lösungsseite Data Warehouse.
Wie eine Frage heute beantwortet wird
Eine Vertriebsleiterin möchte wissen:
„Welche Kunden kaufen weniger als im Vorjahr?"
Der typische Ablauf:
- Sie sucht in den vorhandenen Dashboards.
- Die benötigte Sicht fehlt.
- Sie stellt eine Anfrage an das BI-Team.
- Die Definition wird abgestimmt.
- Ein Analyst erstellt die Auswertung.
- Das Ergebnis wird bereitgestellt.
- Die nächste Frage entsteht.
Der Aufwand liegt nicht nur im SQL.
Er entsteht durch fachliche Klärung, Datenverständnis, Kennzahlenauswahl und Ergebnisprüfung.
Ein reiner SQL-Chatbot löst deshalb nur einen Teil des Problems.
Wie oneAgent den Prozess verändert
Die Nutzerin fragt direkt:
„Welche Kunden kaufen in diesem Jahr mindestens 20 Prozent weniger als im gleichen Zeitraum des Vorjahres?"
Daraus entsteht eine strukturierte Analyse:
- Kennzahl: freigegebener Umsatz
- Dimension: Kunde
- Zeitraum: aktuelles Jahr bis heute
- Vergleich: Vorjahreszeitraum
- Bedingung: Rückgang von mindestens 20 Prozent
- Berechtigung: eigener Vertriebsbereich
Falls eine Angabe fehlt, kann oneAgent nachfragen:
„Soll der Umsatz nach Bestell- oder Rechnungsdatum verglichen werden?"
Danach kann die Nutzerin direkt weiterfragen:
„Welche Produktgruppen erklären den Rückgang bei den fünf größten Kunden?"
So entsteht ein Dialog statt einer Reihe einzelner Tickets.
Self-Service bedeutet nicht, dass jeder SQL lernen muss
Fachanwender kennen ihre geschäftlichen Fragen.
Was ihnen fehlt, ist häufig der technische Zugang zur Datenplattform.
Self-Service sollte daher nicht bedeuten, dass jeder:
- Datenmodelle baut,
- DAX schreibt,
- SQL lernt,
- oder eigene Reports entwickelt.
Self-Service bedeutet:
Ein Nutzer kann eine Business-Frage stellen, ohne die technische Struktur dahinter beherrschen zu müssen.
oneAgent soll die Frage des Fachbereichs mit der bestehenden Datenlogik verbinden.
Das BI-Team wird nicht ersetzt
oneAgent macht Data Engineers oder Analysten nicht überflüssig.
Das BI-Team bleibt verantwortlich für:
- Datenintegration,
- Datenqualität,
- Datenmodelle,
- Kennzahlen,
- Berechtigungen,
- Governance,
- und komplexe Analysen.
Verändert wird vor allem der Ticketbetrieb.
Heute beschäftigen sich BI-Teams häufig mit wiederkehrenden Aufgaben:
- bekannte Kennzahlen anders gruppieren,
- Zeiträume verändern,
- bestehende Daten filtern,
- oder ähnliche Auswertungen für weitere Regionen erstellen.
Können Fachbereiche solche Fragen selbst stellen, gewinnt das BI-Team Zeit für wertvollere Aufgaben.
oneAgent schafft das BI-Team nicht ab. Es reduziert die Abhängigkeit bei bekannten Datenfragen.
Bestehende Kennzahlen müssen weiter gelten
Wenn Power BI für einen Zeitraum 935.000 Euro Nettoumsatz zeigt, oneAgent aber 1.080.000 Euro ausgibt, entsteht kein Self-Service.
Es entsteht Misstrauen.
Deshalb sollte eine KI-Lösung vorhandene Definitionen nicht ignorieren. Warum genau hier das größte Risiko liegt, zeigt Teil 2: Korrektes SQL, falsche Kennzahl.
Das Sprachmodell darf flexibel auf Fragen reagieren.
Die zugrunde liegende Kennzahl muss jedoch konsistent bleiben.
Die Oberfläche darf flexibel sein. Die Kennzahlenlogik nicht.
Das bestehende DWH ist ein Vorteil
Ein Data Warehouse ist keine Hürde für oneAgent.
Es ist häufig die wichtigste Grundlage.
Dort wurden bereits viele Probleme gelöst:
- Datenquellen wurden verbunden,
- Formate vereinheitlicht,
- Historien aufgebaut,
- Beziehungen modelliert,
- und Business-Regeln umgesetzt.
oneAgent kann auf dieser Vorarbeit aufsetzen.
Das DWH muss dabei nicht perfekt sein.
Für einen ersten Pilot reicht ein klar abgegrenzter Bereich, der fachlich ausreichend verstanden ist.
Wie ein sinnvoller Pilot startet
Der größte Fehler ist ein zu großer Start:
„Wir möchten sofort alle Unternehmensdaten per Chat abfragen."
Besser ist ein begrenzter Pilot.
1. Einen Fachbereich auswählen
Geeignet sind Bereiche mit wiederkehrenden Fragen und hohem manuellem Aufwand, etwa:
- Controlling,
- Vertrieb,
- E-Commerce,
- Marketing,
- oder Operations.
2. Einen klaren Datenbereich festlegen
Für den Start reichen häufig:
- ausgewählte Views,
- ein bestehendes Datenmodell,
- oder wenige relevante Tabellen.
3. Einige zentrale Kennzahlen definieren
Fünf geprüfte Kennzahlen sind wertvoller als hundert theoretisch verfügbare.
Beispiele:
- Nettoumsatz,
- Deckungsbeitrag,
- Auftragseingang,
- Retourenquote,
- Plan-Ist-Abweichung.
4. Echte Fragen verwenden
Zum Beispiel:
- Welche Kunden kaufen weniger als im Vorjahr?
- Welche Kostenstellen liegen über Plan?
- Welche Produkte verlieren an Marge?
- Welche Kampagnen bringen profitablen Umsatz?
5. Gemeinsam prüfen und erweitern
Fachbereich und Datenverantwortliche prüfen die Antworten. Erst danach werden weitere Kennzahlen, Nutzer und Datenquellen ergänzt.
Beispiele aus der Praxis
Controlling
Das Dashboard zeigt:
Kostenstelle Marketing: 18 Prozent über Plan.
Der Controller fragt:
„Welche Kostenarten erklären die Abweichung?"
Danach:
„Welche Lieferanten sind dafür verantwortlich?"
Das Dashboard liefert den Ausgangspunkt. oneAgent unterstützt die Folgeanalyse. Wie KI-Datenanalyse den kompletten Monatsabschluss beschleunigt, zeigt KI-Datenanalyse im Controlling.
E-Commerce
Der Umsatz bleibt stabil, die Marge sinkt.
oneAgent kann helfen, Fragen zu beantworten wie:
- Welche Produkte verlieren an Deckungsbeitrag?
- Wo steigen Retourenkosten?
- Welche Kampagnen bringen Umsatz, aber unprofitable Kunden?
Vertrieb
Ein Vertriebsleiter fragt:
„Welche Opportunities bleiben ungewöhnlich lange in einer Phase?"
Danach:
„Welche davon hatten seit 30 Tagen keine Aktivität?"
Solche Folgefragen sind für ein festes Dashboard oft zu individuell.
Berechtigungen müssen durchgängig gelten
Ein einfacher Datenzugang darf nicht bedeuten, dass jeder alles sehen kann.
Ein Nutzer darf über den Chat nicht mehr Daten erhalten, als ihm im Unternehmen zustehen.
Das kann unter anderem betreffen:
- Regionen,
- Gesellschaften,
- Kundengruppen,
- sensible Spalten,
- und bestimmte Kennzahlen.
Die Berechtigung muss bei der tatsächlichen Datenabfrage gelten – nicht nur im Frontend oder im Prompt.
Dashboard und Data Agent ergänzen sich
Dashboards eignen sich für:
- wiederkehrende Steuerung,
- feste KPI-Sichten,
- Managementberichte,
- und schnelle Übersichten.
oneAgent eignet sich für:
- spontane Fragen,
- flexible Filter,
- Ursachenanalysen,
- und individuelle Folgefragen.
Ein typischer Ablauf:
- Ein Dashboard zeigt eine Auffälligkeit.
- Der Nutzer fragt oneAgent nach der Ursache.
- Er analysiert einzelne Dimensionen.
- Ein wichtiges Ergebnis wird gespeichert.
- Eine regelmäßig relevante Erkenntnis kann später in ein Dashboard einfließen.
So ergänzen sich standardisiertes Reporting und flexible Analyse.
Warum wir oneAgent bauen
In Projekten sehen wir immer wieder:
Unternehmen scheitern nicht zwingend an fehlenden Daten.
Viele besitzen bereits ein Data Warehouse, Dashboards und spezialisierte Teams.
Trotzdem erreichen die Daten nur einen begrenzten Teil der Organisation.
Der Zugang endet dort, wo kein passender Bericht existiert und eine eigene Abfrage notwendig wird.
Genau diese Lücke möchten wir schließen.
Nicht, indem wir das bestehende System ersetzen.
Sondern indem wir eine neue Oberfläche dafür schaffen:
natürliche Sprache.
Unser Ziel ist, dass Fachanwender Fragen stellen können, ohne SQL oder DAX zu lernen und ohne für jede Folgefrage ein Ticket zu eröffnen.
Everyone can be a datastar – nicht weil jeder zum Data Engineer wird, sondern weil jeder sicheren Zugang zu den richtigen Antworten erhält.
Fazit
Ein Data Warehouse kann alle notwendigen Informationen enthalten.
Das bedeutet noch nicht, dass jeder Mitarbeiter sie nutzen kann.
Dashboards liefern wichtige, standardisierte Übersichten. Neue und spontane Fragen führen jedoch häufig zurück in den Ticketprozess.
oneAgent ergänzt die vorhandene BI-Landschaft um einen flexiblen Zugang in natürlicher Sprache.
Dabei bleiben die entscheidenden Grundlagen bestehen:
- Datenplattform,
- Kennzahlen,
- Beziehungen,
- Berechtigungen,
- und Governance.
oneAgent baut keine zweite Datenwelt auf. Es macht die vorhandene Datenwelt für mehr Menschen zugänglich.
Weiterlesen
Damit schließt die Serie. Falls Sie hier eingestiegen sind: In Teil 1 geht es um die Frage „Wir haben doch schon ChatGPT", in Teil 2 darum, wie technisch korrektes SQL trotzdem die falsche Kennzahl liefern kann.