Aggressive Analytik in der Praxis: Ein Slackbot, eine semantische Schicht sowie die Entscheidung zwischen Kauf und Eigenentwicklung.
Agentic Analytics in einem Technologieunternehmen: Ein Slackbot, der mit den Daten spricht, eine semantische Schicht, die skaliert werden musste, der Kauf von Omni sowie warum die Adoption am wichtigsten war.
Quellen: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
Aggressive Analytiklösungen sind in allen Verkaufspräsentationen der Anbieter zu finden: Kommunikation mit den Daten, BI-Systeme mit KI-Unterstützung, semantische Schichten, Self-Service-Analytik in der zweiten Version. Fast jedes Analytikprodukt bemüht sich, KI in jede Ecke zu bringen. Meinungen dazu, wohin das führt, sind zahlreich, doch Berichte darüber, wie so etwas in einem echten Unternehmen umgesetzt wird, sind selten – genauso wie ehrliche Antworten auf die schwierigere Frage: Hat diese Lösung den Praxistest mit echten Nutzern und ihren Erwartungen bestanden?
Was folgt, ist eine solche Beschreibung, die aus der Arbeit eines Datenwissenschaftlers in einem mittelgroßen Abonnementunternehmen ab Ende 2025 zusammengestellt wurde. Sie umfasst den Aufbau des ersten Slackbots zur Interaktion mit Daten von Grund auf, die Einführung bei echten Nutzern, die Herausforderungen bei der Skalierung einer semantischen Schicht sowie deren Infrastruktur und eine Entscheidung zwischen Eigenentwicklung und Kauf, nachdem das Team nach einem Unternehmens-BI-Tool suchte. Seitdem ist dieselbe Person in die Beratung gewechselt, und fast jedes Unternehmen, das sie dort besucht, versucht, dieses Problem zu lösen – was auf echte Chancen für Datenwissenschaftler hindeutet.
Die entscheidende Wahl vor der Einführung von KI
Anfang 2025 geschah etwas, das damals nicht mit KI in Verbindung gebracht wurde. Der Leiter der Datenabteilung erkannte die Notwendigkeit, das erste Informationsmodell des Unternehmens zu entwickeln, und ein erfahrener Datenengineering-Berater wurde hinzugezogen, um dies zu leiten, wobei bei jedem Schritt zwei Datenwissenschaftler beteiligt waren.
Ein Informationsmodell ist die Schicht, die definiert, wie Daten strukturiert sind, wie Tabellen miteinander verbunden sind und vor allem, was bestimmte Metriken bedeuten. Man kann es sich als die gemeinsame Sprache vorstellen, die alle im Unternehmen beim Erörtern von Daten verwenden sollten.
Die technische Seite ist recht einfach. Die schwierige Aufgabe besteht darin, alle dazu zu bringen, sich auf diese Sprache zu einigen. Wenn man fragt, was als aktiver Benutzer gilt, erhalten die einzelnen Teams unterschiedliche Antworten. Das Marketing hat eine Definition, das Produktmanagement eine andere, die Finanzabteilung wieder eine dritte – und jede Seite ist davon überzeugt, dass ihre Definition richtig ist. Das Erreichen einer Einigung war langsam und mühsam, doch diese Arbeit wurde zur Grundlage für alles, was später entwickelt wurde. Ohne das Informationsmodell hätte das Aufsetzen eines semantischen Modells auf den Daten fast sicher mehr Schaden als Nutzen gebracht.
Erstellung von Erkenntnissen auf Anfrage
Während das Informationsmodell entstand, durchlief derselbe Datenwissenschaftler eine persönliche Veränderung. Die Untersuchung des Arbeitsmarktes zeigte, dass immer mehr Unternehmen nach Fähigkeiten im Bereich KI suchten, was dazu führte, dass er selbst lernte, Teile der täglichen Arbeit zu automatisieren: ein Tool zur Datenreinigung, ein Workflow für explorative Analysen sowie Verbindungen zwischen KI, den Daten und ihrem Kontext.
Was ursprünglich als Produktivitätsmaßnahme begann, entwickelte sich zu etwas Größerem – zu einem Teil der umfassenderen Entwicklung hin zu agiler Analytik (ein Begriff, der damals noch nicht gebräuchlich war), bei der traditionelle Analysemethoden nicht mehr ausreichten. Eines der größten Projekte, die daraus hervorgingen, war der Slackbot.
Die Idee war ein Datenprodukt, das zwischen Dashboards und Datenwissenschaftlern steht, für Fragen, die eigentlich leicht beantwortet werden können, aber keine Erstellung eines neuen Dashboards oder eine Überarbeitung eines bestehenden rechtfertigen. Nicht jede Frage verdient ein Jira-Ticket.
Niemand hatte darum gebeten. Es musste weder auf Genehmigung noch auf grünes Licht gewartet werden. Der größte Teil wurde allein als Prototyp entwickelt, zusammen mit einem Systemdesigndiagramm und einer kurzen Demo für das Team. Der entscheidende Schritt bestand darin, es als bereits fertiggestelltes Produkt darzustellen und nicht als Antrag auf Freigabe zum Beginn der Arbeit. Dadurch hatte das Team fast kein Risiko, und der Entwickler hatte die Möglichkeit, Arbeit mit echtem Wert zu zeigen, was ausreichte, um die benötigte Unterstützung zu gewinnen.
Einführung und Erforschung der Anfragen der Nutzer
Die ersten Nutzer waren ein einzelnes Team, das für Marketing zuständig war. Das war beabsichtigt: eine kontrollierte Einführung statt eines landesweiten Rollouts, bei dem Probleme auftreten könnten, die nicht bewältigt werden könnten.
Die erwartete Ausbeute bestand lediglich in einem sicheren Launch. Tatsächlich zeigte sich dadurch viel darüber, wie Nicht-Analysten Fragen stellen. Marketingspezialisten formulieren eine Frage im Kontext des Geschäftsproblems und nicht in Bezug auf Tabellen oder Definitionen von Metriken, weshalb das System zwischen diesen beiden Ansätzen übersetzen musste. Analysten neigen in diesem Zusammenhang dazu, von ihren eigenen Gewohnheiten geblendet zu werden.
Von Anfang an war klar, dass es sich um ein Datenprodukt und nicht nur um ein Tool handelte, weshalb Dokumentation, interner Marketingaufwand sowie Onboarding besondere Aufmerksamkeit erforderten – schließlich entscheiden diese Faktoren darüber, ob die Menschen das Erstellte tatsächlich nutzen. Die ersten Monate bestanden hauptsächlich aus Tests, und zwar vielen davon.
Was folgte
Das Ergebnis war ein MVP, woraufhin entschieden werden musste, ob das Produkt weitere Investitionen verdiente und welche Anforderungen die nächste Version haben würde. Das System um die Daten herum aufzubauen, war nicht der schwierigste Teil. Als die Frage lautete, was es nützlicher machen könnte, richtete sich die Diskussion auf den Umfang der Daten, die der Bot erreichen konnte – was bedeutete, dass die semantische Schicht erweitert werden musste.
Daraufhin stellte das Team sich eine Reihe von Fragen. Die erste semantische Schicht befand sich als YAML-Dateien hinter einem Slackbot – wie sollte sie also erweitert werden? Wie konnten mehrere Personen daran arbeiten? Stimmten alle überhaupt über die Definitionen überein?
Diese Fragen kamen zur richtigen Zeit, denn bereits wurde ein neues BI-Tool in Betracht gezogen, da das bestehende nicht mehr modern genug erschien. Die Diskussion wandte sich von der Verbesserung des Slackbots der Frage zu, ob ein eigentlicher semantischer Layer benötigt wurde und ob dieser mit dem BI-Tool geliefert werden sollte oder eigenständig existieren sollte.
Viele Unternehmens-BI-Produkte wie Looker oder Omni beinhalten einen semantischen Layer. Für dieses Team galt eine klare Vorgabe: Falls das BI-Tool über einen semantischen Layer verfügte, durfte dieser nicht festgelegt sein und musste in andere Tools übertragbar sein. Deshalb war die Ankündigung zur Open Semantic Interchange im September 2025, die einen universellen Standard für semantische Layer versprach, so wichtig.
Entwickeln oder kaufen – und warum das weniger wichtig ist, als es scheint
Das Unternehmen entschied sich schließlich für einen Kauf. Gewählt wurde Omni, das wie eine Mischung aus Tableau, Looker sowie einigen Tabellenkalkulationsfunktionen wirkte. Im November und Dezember 2025 wurden mehrere Tools geprüft, und Omni wurde Anfang 2026 in Betrieb genommen.
Es mag enttäuschend klingen: Eine Geschichte über einen von Grund auf entwickelten Slackbot, die mit dem Kauf eines fertigen Produkts endet. Der wichtige Punkt, den viele Datenwissenschaftler übersehen, ist, dass die erworbenen Fähigkeiten auch beim Kauf weiterhin relevant sind. Die Entwicklung des Bots brachte Erkenntnisse mit sich, die direkt bei der Integration von Omni zum Tragen kamen: Methoden der Prompt-Engineering, Bewertungsverfahren, MCP sowie ein tiefes Verständnis dafür, welche Funktionen die semantische Schicht erfüllt.
Context Engineering ist ein gutes Beispiel dafür. Damit ist gemeint, die Kontrolle darüber zu haben, welche Informationen das Modell beim Verarbeiten einer Anfrage erhält: welche Tabellen, welche Metrikdefinitionen, welche Geschäftsregeln. Da alles von Grund auf entwickelt wurde, wusste der Entwickler, was dem Modell präsentiert werden sollte – und vor allem, was weggelassen werden musste. Dieses Wissen entsteht durch die eigene Entwicklung und nicht durch das Lesen von Dokumentationen.
Auch in Vorstellungsgesprächen kommen diese Fähigkeiten zur Sprache. Seit dem Wechsel in die Beratung tauchen viele Unternehmen auf, die lieber intern entwickeln, meist weil sie eine maßgeschneiderte Lösung wünschen. Die Frage, ob es sich lohnt, diese Fähigkeit zu erlernen, ist daher falsch gestellt. Man sollte sie erlernen, unabhängig von der Entscheidung des Unternehmens, denn sie bereitet auf jede Herausforderung mit jeder Datenplattform vor.
Wo das gekaufte Tool versagte
Omni ist ein leistungsstarkes Produkt eines jungen Unternehmens, das sich schnell weiterentwickelt und viel Wert bietet. Der häufigste Mangel betraf MCP.
Ein großer Teil des Unternehmens arbeitet immer noch mit Google Sheets und Excel, und das wird sich in absehbarer Zeit nicht ändern. Das Ziel war es, auch diese Daten anzubinden, indem man vom gleichen semantischen Modell wie bei allen anderen Daten Gebrauch machte, sodass eine Zahl in einer Spalte genau dasselbe bedeutete wie anderswo. Das über MCP zu erreichen, wäre ideal gewesen, aber es war nicht möglich.
Das Team wollte mehr Einfluss auf den Übergangsbereich zwischen dem semantischen Modell und dem, was es verwendet – also darauf, was zurückgegeben wird und welche Tools eine Verbindung dazu herstellen dürfen. Eine eigenständige semantische Schicht zusammen mit den übrigen Komponenten, die intern entwickelt werden, würde eine vollständige Kontrolle über die API ermöglichen. Das ist der Kompromiss, und für viele Unternehmen wird genau das die Entscheidung bestimmen. Wo Flexibilität und vollständige Kontrolle entscheidend sind, reicht ein Kauf möglicherweise nicht aus. Wo Geschwindigkeit und eine solide, sofort nutzbare Funktionalität wichtig sind, kommt ein Produkt wie Omni sehr weit.
Die Adoption entscheidet alles
Dieses Thema verdient einen eigenen Artikel. Das fortschrittlichste System der Welt ist wertlos, wenn die Menschen es nicht in ihren Arbeitsablauf integrieren und ihm vertrauen – und genau hier versagen viele Datenwissenschaftler. Für ein kleines Team war es eine echte Herausforderung, Zeit dafür zu finden, doch die Adoption wurde ernst genommen. Die Investitionen waren:
- eine Video-Serie für eine schnelle Einarbeitung,
- mehrere firmenweite Präsentationen,
- spezielle Live-Workshops für Schlüsselteams wie das Finanzwesen.
Jeder, der ein KI-Tool intern einführt, sollte die Einführung wie den Markteintritt eines Produkts behandeln. Das bedeutet interne Marketingmaßnahmen, Schulungen sowie Unterstützer in jedem Team, die daran glauben. Andernfalls enden Monate harter Arbeit damit, dass es nur ein weiteres Tool gibt, das niemand verwendet. Die Arbeit ist mühsam und erscheint nicht in einem Dashboard, doch sie ist der Grund, warum all die Anstrengungen für eine Karriere von Bedeutung sind.
Karriereeffekt
Der Slackbot, die Einführung sowie die führende Rolle bei dem Übergang zu agiler Analytik haben etwas Konkretes hervorgebracht: Verhandlungsmacht. Diese Erfahrung unterstützte einen Beförderungsantrag, und die Beförderung kam tatsächlich zustande.
Es ging bei der Diskussion nicht hauptsächlich um den Slackbot. Es ging vielmehr um Kreativität und das Bleiben an der Spitze des Fachgebiets, um anschließend daraus etwas zu schaffen, das das Unternehmen verbessert – in diesem Fall Erkenntnisse auf Basis der Nachfrage. Der stärkste Aspekt war einer, der nicht extra erwähnt werden musste: Niemand hatte darum gebeten, und niemand musste die Arbeit leiten. Ein Manager interpretiert das als höhere Hierarchiestufe.
Jemand, der solche Systeme entwickeln kann, die Daten versteht und gleichzeitig das Geschäft kennt, ist eine seltene Kombination – und das wissen Unternehmen. Das erklärt auch den späteren Schritt in die Beratung, da die Nachfrage nach Datenwissenschaftlern, die auf Systemebene über KI nachdenken und nicht nur durch gezielte Chat-Anfragen, rasant steigt.
Die Schlussfolgerung
Aggressive Analytik findet bereits statt und ist kein zukünftiges Phänomen. Unternehmen experimentieren damit, setzen sie ein und erkunden, was funktioniert. Datenwissenschaftler sollten daran teilnehmen. Egal, ob ein Unternehmen selbst entwickelt oder kauft – die entsprechenden Fähigkeiten sind überall nützlich: Sie steigern den Wert in der aktuellen Position, stärken die Chancen auf Beförderung und heben einen bei Vorstellungsgesprächen hervor.
Alles begann mit einem nebenbei erstellten Prototypen, einem Systemdesigndiagramm und einer schnellen Demonstration für das Team. Zu warten, bis jemand diese Arbeit anfordert, ist ein Fehler. Die eigene Weiterentwicklung in die Hand zu nehmen, ist der bessere Weg.
Verwandte Artikel
- Praktische Hinweise: Aufbau eines für die Produktion bereiten agierenden Betrugsdetektionssystems — Schritt-für-Schritt-Anleitung zu den Praktischen Hinweisen zum Aufbau eines für die Produktion bereiten agierenden Betrugsdetektionssystems: Verträge, Überprüfungen sowie Code-Blöcke, die Teams direkt verwenden können, die dieses Muster implementieren.
- Eine Web-Stack-Lösung für Startups in der Ära der KI-Agenten: Next.js, MUI und Firebase — Welche Tools eignen sich, wenn Agenten den größten Teil des Codes schreiben: Next.js, MUI, Firebase, Vercel, PostHog sowie eine minimale Agenteneinrichtung, zusammen mit den Begründungen dafür.