DuckDB hat die Stellenbeschreibung des Analysten überflüssig gemacht, und das sollten CDOs jetzt tun

Die Rolle des Analysten gerät seit zwei Jahren leise ins Wanken. Natural-Language-Interfaces auf BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Plattformen bedeuten, dass ein Product Manager „zeig mir den Umsatz nach Region ohne Retouren, letzte 90 Tage“ tippen kann und ein Chart bekommt, ohne ein Ticket zu ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →öffnen. Gleichzeitig verändert sich die Infrastruktur unter diesen Queries. Ein 2025 bei Towards Data Science veröffentlichtes Tutorial zum Aufbau eines LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen → mit DuckDB und DuckLake, ausgehend von einer lokalen Parquet-Datei, die mit Daten in der Cloud gejoint wird, hat etwas Wichtiges gezeigt: Der Abstand zwischen „Analyst-Workstation“ und „produktiver Datenplattform“ ist inzwischen klein genug, dass ein einzelner Engineer oder ein KI-AgentKI-AgentSoftware, die ein Ziel eigenständig verfolgt: Sie plant Schritte, nutzt Werkzeuge und handelt mit wenig menschlichem Eingriff.Vollständige Definition ansehen → ihn an einem Nachmittag überbrückt. Dass beide Entwicklungen zusammentreffen, schafft ein reales organisatorisches Problem für CDOs, die noch nicht entschieden haben, wofür ihre Analysten eigentlich da sind.

Der Druck ist nicht hypothetisch. Auf dem dbt Summit 2026 hat dbt Labs (ein kommerzieller Anbieter mit offensichtlichem Interesse an der Geschichte, die er erzählt) dbt Charts und dbt Wizard zusammen mit dbt v2 angekündigt und positioniert die Transformationsschicht als Ort, an dem Fachanwender ihre eigenen metrikgetriebenen Visualisierungen erzeugen. Ob dieses konkrete Produkt ankommt oder nicht, die Richtung ist klar: Der Semantic LayerSemantic LayerEine gemeinsame Ebene für Geschäftsdefinitionen zwischen Rohdaten und Berichten, damit alle Umsatz, Churn oder Marge gleich berechnen.Vollständige Definition ansehen → übernimmt mehr von dem, was Analysten früher manuell erledigt haben, undwie Ihre Organisation ihren Semantic Layer heute strukturiertbestimmt, wie viel dieser Analystenkapazität Sie umlenken statt schlicht abbauen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.

Ein Playbook in fünf Schritten für CDOs

Schritt 1: Prüfen Sie, wohin die Zeit der Analysten tatsächlich fließt

Bevor Sie irgendetwas umbauen, verschaffen Sie sich eine echte Aufschlüsselung. Ziehen Sie die Ticketdaten Ihres Analytics-Request-Systems der letzten sechs Monate. Ordnen Sie jedes Ticket einer von vier Kategorien zu: Datenextraktion und -aufbereitung, Reproduktion von Reports, Ad-hoc-Queries schreiben sowie Insight-Generierung oder Entscheidungsunterstützung. In den meisten Organisationen verbrauchen die ersten drei 70 bis 80 Prozent der Analystenstunden. Genau diesen Teil werden Natural-Language-BI und ein gut governter Semantic Layer zuerst übernehmen. Sie müssen Ihre tatsächliche Zahl kennen, bevor Sie gegenüber CFO oder CHRO glaubwürdig argumentieren können, was als Nächstes kommt.

Schritt 2: Bauen Sie die Infrastruktur, die Natural-Language-Queries verlässlich macht

Natural-Language-BI scheitert, wenn das zugrunde liegende Datenmodell inkonsistent ist. Ein Fachanwender fragt „wie hoch ist unsere Churn RateChurn RateDie Churn Rate ist der Prozentsatz an Kunden oder Umsatz, der in einem Zeitraum verloren geht. Sie misst, wie schnell ein Unternehmen seinen bestehenden Kundenstamm verliert.Vollständige Definition ansehen →?“ und bekommt drei verschiedene Zahlen, je nachdem, welchen Datensatz das Modell trifft. Die Lösung ist nicht besseres PromptingPromptingPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen →. Die Lösung ist ein sauber governter Semantic Layer mit zertifizierten Metriken. Die Architektur von DuckDB ist hier aufschlussreich: Sie kann eine lokale Parquet-Datei in einer einzigen Query mit Cloud Storage joinen, weil sie beides als gleichrangige Quelle unter einer einheitlichen Query Engine behandelt. Ihr Semantic Layer braucht dieselbe Eigenschaft. Zertifizierte Definitionen von „Revenue“, „Churn“ und „Active Customer“ müssen identisch auflösen, ob die zugrunde liegenden Daten nun in Snowflake, in einem Lakehouse oder in einer föderierten Quelle liegen.Diese Architektur gut zu entwerfenist eine Voraussetzung für jeden Natural-Language-BI-Rollout, kein Nachgedanke.

Schritt 3: Definieren Sie die Analystenrolle um das herum, was die Maschine nicht kann

Die Aufgaben, die nach der Automatisierung bleiben, sind nicht die einfachen. Dazu gehören: zu erkennen, wann ein Query-Ergebnis plausibel und wann es verdächtig ist, die Frage überhaupt erst zu formulieren, Datenbefunde mit Geschäftskontext zu verbinden, der in keiner Tabelle steht, und den Semantic Layer selbst zu governen. Benennen Sie diese Verantwortlichkeiten explizit. Bei Spotify und Airbnb entstand Analytics Engineering als eigene Disziplin genau deshalb, weil jemand die Transformations- und Metrikschicht verantworten musste, die Self-Service trägt. 2026 braucht diese Disziplin eine zweite Entwicklungsstufe in Richtung dessen, was manche Teams „Analytics Orchestration“ nennen: zu entscheiden, welche Fragen es wert sind, gestellt zu werden, und ob die Antwort des Systems tatsächlich die Antwort auf die gestellte Frage ist.

Schritt 4: Machen Sie einen strukturierten Piloten, bevor Sie reorganisieren

Wählen Sie eine Business Unit, idealerweise eine mit klar abgegrenzter Domäne wie Pricing oder Customer Support. Setzen Sie Ihren Natural-Language-BI-Layer auf einen sauberen Semantic Layer für diese Domäne auf. Verfolgen Sie acht Wochen lang drei Dinge: das Volumen der Ad-hoc-Anfragen, die über das Tool statt über Analysten laufen, die Fehlerquote bei generierten Queries (wo die Antwort falsch war und es niemand gemerkt hat) und die freigewordenen Analystenstunden. Die Fehlerquote ist die Zahl, die Ihnen sagt, wie viel menschliche Kontrolle Sie noch brauchen und an welcher Stelle. Überspringen Sie diesen Schritt nicht und gehen Sie nicht direkt zu Headcount-Entscheidungen über.

Schritt 5: Richten Sie Recruiting und Entwicklung auf Interpretation aus, nicht auf Query-Mechanik

Der nächste Analyst sollte danach beurteilt werden, ob er ein Ergebnis hinterfragen kann, nicht ob er es erzeugt. Praktisch heißt das: andere Interviewfragen. „Schreiben Sie eine SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-Query, die Kohorten-Retention berechnet“ ist 2026 die falsche Frage. „Hier ist ein Retention-Chart, das das BI-Tool automatisch erzeugt hat. Welche drei Dinge würden Sie prüfen, bevor Sie das dem VPVPEine klare Aussage darüber, welchen Nutzen Ihr Produkt liefert, welche Probleme es löst und warum Kunden sich für Sie und nicht für Alternativen entscheiden sollten.Vollständige Definition ansehen → of Growth zeigen?“ ist die richtige. Die MIT Sloan Management Review hat dokumentiert, dass Unternehmen, die in Reskilling-Programme mit Fokus auf zukünftige Fähigkeiten statt auf heutige Tool-Kenntnisse investieren, über einen Horizont von drei Jahren eine bessere Anpassungsfähigkeit der Belegschaft erreichen. Dieselbe Logik gilt für das Recruiting in Analytics.

Wo es schiefgeht

Der häufigste Fehlermodus: Natural-Language-BI auf ein unsauberes Datenmodell setzen und dann die KI beschuldigen, wenn die Ergebnisse falsch sind. Garbage-in gilt weiterhin, und Fachanwender sind weniger gut gerüstet als Analysten, um eine plausibel aussehende falsche Antwort zu erkennen.

Der zweite Fehlermodus: das Produktivitätsnarrativ der Governance davonlaufen zu lassen. dbt Labs (wieder ein Anbieter mit kommerziellem Interesse an dieser Deutung) positioniert Tools wie dbt Charts so, dass Fachanwender sicher im Self-Service arbeiten können. Das stimmt nur, wenn die darunterliegende Metrikschicht zertifiziert und gepflegt ist. Sonst wird aus Self-Service Selbstschädigung: Jedes Team baut seine eigene Version von „Monthly Active Users“ und die Organisation verliert eine gemeinsame Faktenbasis für Entscheidungen.

Der dritte Fehlermodus ist der politische. Analysten, die das Gefühl haben, ihre Rolle werde automatisiert, werden sich still dagegen sperren, den Semantic Layer zu governen, der die Automatisierung erst funktionieren lässt. Sprechen Sie das direkt an. Zeigen Sie ihnen das Audit aus Schritt 1. Ziel ist, ihre Zeit von den 70 Prozent, die die Maschine übernimmt, zu den 30 Prozent zu verschieben, die weiterhin Urteilsvermögen verlangen.

Quick Wins für diese Woche

• Ziehen Sie sechs Monate Analytics-Tickets und klassifizieren Sie sie nach den vier oben genannten Kategorien. Die Verteilung wird Sie überraschen.
• Identifizieren Sie eine Metrik, die Ihre Organisation auf drei oder mehr widersprüchliche Arten verwendet, und schreiben Sie eine kanonische Definition. Das ist der erste Eintrag in Ihrem governten Semantic Layer.
• Ändern Sie eine Interviewfrage für Analysten so, dass sie die Interpretation von Ergebnissen prüft statt das Schreiben von Queries.
• Briefen Sie Ihr Analytics-Team darüber, was Query-Föderation von lokal nach Cloud im DuckDB-Stil für Datenzugriffsmuster bedeutet: Ihre Annahmen über den eigenen Workflow werden sich ändern.

Der Wert des Analysten war nie die Query. Es war das Urteil darüber, ob die Antwort Sinn ergibt und was damit zu tun ist. Teams, die das jetzt klar benennen, haben es deutlich leichter, wenn der CFO fragt, warum der Headcount in Analytics so aussieht, wie er aussieht.