In Folge 345 von MY DATA IS BETTER THAN YOURS (MDIBTY) spricht Jonas Rashedi mit Torben Broll (Director Data & AI Solutions, Natsana) über Wie ein Datenteam sich mit zu vielen Dashboards sein eigenes Grab baut und mit einem Agenten wieder rauskommt. Konkret: Ein Report Graveyard entsteht, wenn die Leitfrage lautet, welche Daten es gibt, statt welche Entscheidung getroffen werden soll.
3 Erkenntnisse aus dieser Folge
- 01
Ein Report Graveyard entsteht, wenn die Leitfrage lautet, welche Daten es gibt, statt welche Entscheidung getroffen werden soll. Bei Natsana fiel das erst auf, als das Management wieder in Excel steuerte.
- 02
Ein Agent, der die Stakeholder hinterfragt, entschärft die persönliche Ebene: Kritik an Zahlen kommt nicht mehr vom Controller. Ob er hält, was er verspricht, ist bei Natsana allerdings noch nicht zu Ende evaluiert.
- 03
Vibe Coding liefert das Frontend in Stunden, der POC stand nach zwei Wochen — der saubere Agent-Flow brauchte noch einige Wochen. Tragfähig ist das nur, weil darunter eine lange aufgebaute P&L auf Order-Item-Level liegt.
Worum es in dieser Folge geht
Mir gegenüber sitzt Torben Broll, Director Data & AI Solutions bei Natsana. Natsana ist das Haus hinter vier Supplement-Marken — Natural Elements, Nature Love, Feel Natural und Gloryfeel — und gehört heute zu Bayer. Groß geworden ist das Unternehmen auf Amazon, inzwischen kommen eigene Webshops in mehreren Ländern dazu. Und ja: Ich habe das Zeug selbst zu Hause.
Torbens Weg ist kein gerader. Nach dem Abi eine Weltreise, dann Wirtschaftsinformatik, eine Ausbildung zum IT-Kaufmann bei BP, dort landet er im Business-Intelligence-Bereich. 2022 steigt er bei Natsana als Business Analyst ein, wird Lead BI, disziplinarischer Lead, Director — und verantwortet heute Data und AI zentral.
Der Grund, warum ich mit ihm sprechen wollte, steckt im Titel der Folge: Er hat einen Namen für etwas, das ich in sehr vielen Unternehmen sehe, aber selten jemanden so offen beschreiben höre. Report Graveyard.
Die Storyline
Von Excel-Limitations zum zentralen Data Warehouse
Der Anfang ist klassisch. Business Intelligence startet bei Natsana im Finance-Bereich, beim CFO — für Torben auch der richtige Ort. Der Auslöser: Excel kam mit der Menge an Orders und Order-Items an seine Grenzen.
Statt In-House aufzubauen, entscheidet sich das Unternehmen für eine externe Partnerschaft mit Gemma Analytics, mit denen Natsana bis heute arbeitet. Als Torben 2022 dazukommt, gibt es noch kein richtiges Data Warehouse, sondern einen Postgres-Server on-premise, ein angebundenes ERP-System und ein paar Power-BI-Reports. Dann der Umzug auf Snowflake, die Data Foundation, die meisten Quellen angebunden.
Wie ein Datenteam sich sein eigenes Grab baut
Als alle Quellen da waren, ging es ans Bereitstellen. Für jede Abteilung Reports, alles zeigen, was man hat. Torben beschreibt das ohne Beschönigung.
Wir haben viele Reporte aufgebaut. Die Frage war damals falsch: Was für Daten haben wir?
Die Folge: so viele Reports, dass das Team selbst den Überblick verlor. Die Usage wurde nicht getrackt, und die Kritik aus dem Business war fast sarkastisch — man wisse gar nicht, was es überhaupt gibt. Nicht, weil es zu wenig gab, sondern weil es so viel gab, dass niemand wusste, wo er hinschauen soll.
Der Ausweg war ein Mindset-Change: weniger Reporting, mehr Decisions. Torben nennt es Business Decision Framework — Interview-Leitfäden, Gespräche Abteilung für Abteilung, nicht nur mit den Leads. Welche Pain Points gibt es, welche Entscheidungen werden auf Basis welcher KPIs getroffen? Daraus entsteht eine aufgeräumte Reporting-Landschaft und ein neues Rollenbild: Domain Experts mit Data-Product-Ownership, nah am Business, mit Fokus auf Adoption, Literacy und Trust. Rückblickend, sagt er selbstkritisch, hat das ganz schön lange gedauert. Und ob damit bessere Entscheidungen getroffen werden, findet er schwer messbar — was er sieht, ist die Usage, die Zufriedenheit der Stakeholder und ein deutlich besseres Sparring zwischen Data und Business.
Die Excel-Datei, die weh tat
Die Szene, an der die Folge hängt: Für das Management wurde ein großer Power-BI-Report gebaut, gespeist aus den KPI-Wünschen der verschiedenen Bereiche — nach Torbens Schätzung bestimmt 30, 40 KPIs. Ein mächtiges Werkzeug, aber für die falsche Zielgruppe. Irgendwann wurde es nicht mehr genutzt.
Ich glaube Anfang des Jahres habe ich dann irgendwann mitbekommen, dass das Management wieder mit Excel steuert.
Ein Business Analyst hatte eine Power-BI-Verbindung nach Excel hergestellt, dort wurde gefiltert und kommentiert — weil Kommentare in Power BI nie gut gelöst waren. Torben war, wie er selbst sagt, im Stolz verletzt. Was ihm die Excel-Datei aber auch zeigte: Das Management brauchte gar keine 30, 40 KPIs, sondern die wichtigsten Positionen der P&L gegen Plan, auf Markt- und Brand-Ebene.
Zwei Wochen bis zum POC — und ein Agent, der Fragen stellt
Torben setzt sich hin und promptet in Lovable. Daten aus Snowflake nach Supabase, ein Dashboard mit den Kern-KPIs, rechts eine Kommentarleiste zu jeder Granularität. Nach zwei Wochen stand der POC. Dazu kommt ein eigener AI-Agent: aggregierte Daten, die Kommentare der Stakeholder, ein sauberer System- und User-Prompt. Jede Woche fürs Weekly Steering und jeden Monat fürs Monthly Steering läuft er durch die Daten.
An der Stelle habe ich eingehakt, weil mich das aus eigener Erfahrung umtreibt: Wenn ich als Analyst die Zahlen eines Managers hinterfrage, wird das schnell persönlich. Kommt die Frage vom Agenten, ist sie emotionsloser. Torben sieht das genauso — und hat den Agenten so gebaut, dass die Kommentare der Vorwoche wieder als Input reinlaufen.
Da ist gerade noch nicht quasi zu Ende evaluiert, das läuft gerade noch ein paar Monate, wir müssen das noch bewerten.
Diese Ehrlichkeit gehört dazu. Genauso wie der Hinweis, dass das Frontend in wenigen Stunden steht, das Backend aber die meiste Arbeit kostet: Für einen sauberen Agent-Flow, validierte Daten und validierte Insights hat er noch einige Wochen gebraucht. Und selbst dann musste er die Stakeholder für die Adoption anschubsen, egal wie gut das Produkt ist.
Warum das so schnell ging: 200 Dollar statt Budgetantrag
Meine These in der Folge war: Große Unternehmen bauen erst den Standard und überlegen dann, was möglich ist. Natsana geht andersherum. Torben erklärt die Geschwindigkeit mit der Struktur — Data und AI zentral in einer Abteilung, mit eigenem Budget.
Wenn mein AI Lead mich heute fragt, hey, ich will mal das ausprobieren, ich brauche dafür 200 Dollar, dann macht er das eben.
Sein Satz, dass es keine Limitations mehr gibt, kommt mit einer klaren Grenze: Natürlich baut niemand ein eigenes ERP oder einen eigenen Marktplatz. Aber auf einer sauberen Datenlandschaft lässt sich mit Lovable, n8n und ThoughtSpot erstmal sehr viel bauen. ThoughtSpot kam übrigens über Bayer ins Haus und läuft zusätzlich zu Power BI — unter anderem für den D2C-Bereich, in dem Natsana das externe Tool Klar abgelöst hat, um die Hoheit über die eigenen Daten und Attributionsmodelle zu haben.
Das Fundament, das niemand sieht: die P&L auf Order-Item-Level
Für mich der wichtigste Teil der Folge. Weil das Team unter Finance aufgehängt war, investierte es früh in eine BI-basierte P&L. Ein BI-Lead hat gemeinsam mit einem Engineer von Gemma Analytics fast Vollzeit daran gearbeitet — nach Torbens Erinnerung mindestens ein Jahr, vielleicht sogar zwei, mit Parallelthemen. Vier Marken, mehrere Hauptchannels mit Unterchannels und Ländern, Kosten auf verschiedenen Ebenen, teils automatisiert, teils manuell, von Finance gegengeprüft.
Du siehst halt nicht von heute auf morgen den Mehrwert, sondern du siehst dann den Mehrwert, wenn du halt diesen Layer nimmst und dann obendrauf den Consumption-Layer setzt.
Ohne das Vertrauen der Geschäftsführung wäre das nicht gegangen, sagt er. Heute kann Natsana alle Brands und Channels auf der granularsten Ebene steuern — und genau darauf setzen der Agent, ThoughtSpot und die nächsten Produkte auf.
Wohin es geht: ein AI-Team mit Produktmanager und ein AI-Day
Zum Schluss wird es noch einmal konkret. Das AI-Team hat ein Buchungstool selbst gebaut, für das vorher 7.000 bis 8.000 Euro im Jahr fällig waren — für Torben nicht viel im Jahr, aber für ein Buchungstool. Genauso den Chatbot auf den Webshops. Gebaut hat beides ein Produktmanager ohne technisches Vorwissen, der aus dem Business kommt. Der nächste Schritt ist ein AI-Day, um das in die Fachabteilungen zu tragen. Torbens Bild dafür sind Puzzleteile — AI Sales Steering, der P&L Gold Layer, der Chatbot — die irgendwann zusammengesetzt werden.
Warum mich das besonders umtreibt
Ich glaube ja, dass fast jedes Datenteam irgendwann an dem Punkt steht, an dem Torben stand: alles bereitgestellt, alles visualisiert, und trotzdem schaut niemand hin. Frech gesagt ist das Report Graveyard die logische Folge der Frage "Welche Daten haben wir?" — und die stellen wir viel zu oft, weil sie sich nach Fortschritt anfühlt. Die bessere Frage kam bei Natsana aus einer Excel-Datei, und ich finde es stark, dass Torben die Kränkung nicht verteidigt, sondern daraus ein Produkt gebaut hat.
Das Zweite ist die CFO-Brille. Bitte nicht falsch verstehen: Der Lovable-POC in zwei Wochen ist beeindruckend. Aber er ist nur möglich, weil vorher über lange Zeit in eine P&L auf Order-Item-Level investiert wurde, deren Wert man im nächsten Quartal nicht sieht. Das deckt sich mit dem, was ich seit Jahren sage: erst das Fundament, dann die KI. Wer es andersherum macht, baut mit Vibe Coding nur schneller das nächste Grab. Wenn ihr in eurem Haus gerade genau diese Diskussion führt — Fundament oder schneller Use Case —, schreibt mir, wie ihr sie gelöst habt.