Erstellung von Dashboards in Tableau Desktop mit Hilfe des Tableau Agents

März 2026

Vom manuellen Erstellen zur intelligenten Validierung

Im Bereich Business Intelligence (BI) ändert sich zusehends die tägliche Arbeitsweise von Data Analysten. Lange Zeit definierte sich die Expertise eines Data Analysten primär über die technische Beherrschung des Werkzeugs: Wie baue ich einfache oder auch umfangreiche Dashboards genau auf? Wie baue ich komplexe Formeln, die in Dashboards benötigt werden? Diese und weitere „handwerkliche“ Tätigkeiten in der Entwicklung sind wichtig, jedoch auch zeitintensiv.

Mit der Integration des Tableau Agents (vormals Einstein Copilot) in Tableau Desktop verschiebt sich der Fokus hin zu der eigentlichen Absicht der Analyse (“Intent-Driven Analytics”). Der Analyst formuliert eine fachliche Frage, und die KI unterstützt bei der technischen Übersetzung in Visualisierungen und Berechnungen. Hierdurch wird der Analyst nicht obsolet, sondern es verändert sich seine Rolle: Er wird vom reinen Dashboard-Ersteller zum Architekten und Qualitätsprüfer. Der Schwerpunkt der Analysen verlagert sich folglich stärker auf den Inhalt selbst – und somit auf den eigentlichen Nutzen von Berichten und Dashboards – und weniger auf die dafür notwendigen Entwicklungsprozesse.

In diesem Blog entwickeln wir ein konkretes Beispiel mit dem bekannten „Sample – Superstore“-Datensatz und demonstrieren, wie ein solcher neuer Workflow gestaltet werden könnte. Wir durchlaufen den Prozess von der ersten Datenexploration bis zur detaillierten Gestaltung eines Dashboards, wo die KI echten Mehrwert bietet und wie sie die „Blank Canvas Paralysis“ – das Zögern vor der leeren Arbeitsfläche – überwindet.

Voraussetzungen für die Nutzung des Tableau Agents

Bevor wir in Tableau Desktop starten, ist ein kurzer Blick auf die technischen Voraussetzungen für die Nutzung des Tableau Agents notwendig. Die Integration von generativer KI in Tableau ist kein rein lokales Feature (in Tableau Desktop), sondern ein Cloud-/Server-Feature, das spezifische Anforderungen an die Architektur stellt.

Damit der Tableau Agent effizient arbeiten kann, müssen folgende Voraussetzungen erfüllt sein:

Infrastruktur: Der Tableau Agent ist ein Cloud-Service. Die Nutzung erfordert Tableau Desktop (ab 2025.1) zwingend in Verbindung mit Tableau Cloud (Edition Tableau+) oder Tableau Server (ab 2025.3).
Datenanbindung: Damit die KI die Semantik versteht, müssen die Daten (z. B. Superstore) als publizierte Datenquelle oder Extrakt in Ihrer Cloud- bzw. Server-Umgebung vorliegen.
Datenschutz: In der Cloud garantiert der Einstein Trust Layer, dass Ihre Daten nicht zum Training öffentlicher KI-Modelle genutzt werden. Bei der Server-Nutzung (On-Premise) greifen Ihre individuellen Sicherheitsrichtlinien für die LLM-Anbindung.

Für unser Szenario nutzen wir den „Sample – Superstore“, da er eine Mischung aus Transaktionsdaten (Bestellungen), geografischen Informationen und Produkthierarchien bietet – ideal, um die Fähigkeiten des Agenten zu testen.

Der Einstieg – Schnelle Orientierung statt leerer Arbeitsfläche

Es ist eine bekannte Situation: Man verbindet sich mit einer neuen Datenquelle und sieht zunächst nur eine lange Liste von Tabellen und Feldern. Sofern nicht bereits konkrete Anforderungen für das Dashboard bestehen, steht man vor der ersten Hürde: Man muss sich einen ersten Überblick verschaffen und sinnvolle Zusammenhänge erkennen. Oft wird hier viel Zeit investiert, nur um die Datenstruktur zu verstehen.

Der Tableau Agent bietet hier eine effiziente Unterstützung durch “Vorschläge” bzw. „Recommended Questions“. Sobald die Verbindung zur Datenquelle steht, analysiert der Agent im Hintergrund die Metadaten. Er erkennt Zeitreihen, kategorische Felder und Kennzahlen. Dies ermöglicht die Erstellung erster Visualisierungen und die Hervorhebung von Datenzusammenhängen, um die Daten initial besser verstehen zu können.

Als praktisches Einstiegsbeispiel stellen wir zunächst in Tableau eine Verbindung mit dem Superstore-Datensatz her und rufen dann das Agent-Panel auf. Anstatt manuell Felder in den Arbeitsbereich zu ziehen, schlägt der Agent kontextbezogene Fragen vor:

Ein Klick auf einen dieser Vorschläge generiert sofort eine erste Ansicht.

Diese Funktion dient als Beschleuniger. Sie ermöglicht es dem Analysten, sofort in die Validierung von Hypothesen einzusteigen, anstatt Zeit mit dem mechanischen Aufbau von “Basis”-Charts zu verbringen. Es geht hier nicht darum ein fertiges Endergebnis zu generieren, sondern um den schnellstmöglichen Einstieg in den Analysefluss.

Visualisierung durch natürliche Sprache (Text-to-Viz)

Nachdem wir einen ersten Überblick gewonnen haben, wollen wir spezifische Fragestellungen untersuchen. Nehmen wir an, wir möchten das Verhältnis von Umsatz und Gewinn analysieren, und zwar detailliert auf Ebene der Produkt-Unterkategorien.

Traditionell erfordert dies mehrere Schritte: Die Auswahl des richtigen Diagrammtyps, das Platzieren der Kennzahlen auf die korrekten Achsen und das Hinzufügen von Dimensionen für Detailgrad und Farbe. Mit dem Tableau Agent können wir diesen Wunsch in natürlicher Sprache formulieren.

Der Prompt: „Erstelle ein Streudiagramm für Umsatz und Gewinn pro Unterkategorie. Färbe die Punkte nach Kategorie.“

Die Umsetzung durch die KI: Der Agent übersetzt diese textliche Absicht in VizQL (Visual Query Language). Er führt dabei folgende Schritte autonom aus:

Auswahl von SUM(Sales) und SUM(Profit) für die Achsen.
Nutzung von Sub-Category im Detail-Container, um die Granularität festzulegen.
Nutzung von Category in der Farbe, um den visuellen Kontext zu liefern.
Wahl des Markierungstyps „Form“.

Das Ergebnis ist eine fertige Visualisierung. Der Analyst muss hier nicht mehr über die technische Umsetzung nachdenken, sondern kann sich sofort auf das Muster in den Daten konzentrieren: Gibt es Cluster? Gibt es Ausreißer?

Berechnung und Logik – Semantik vor Syntax

Eine häufige Herausforderung in der Datenanalyse ist die Erstellung komplexer berechneter Felder. Während die Geschäftslogik oft klar ist („Ich brauche die Dauer zwischen Bestellung und Versand“), scheitert die Umsetzung häufig an der exakten Syntax der Formelsprache im BI-Tool.

Der Tableau Agent fungiert hier als “Übersetzer“. Der Analyst liefert die fachliche Anforderung, die KI liefert den korrekten Code.

Beispiel A: Logistik-Analyse (Zeitberechnungen) Wir wollen die Effizienz unserer Lieferkette prüfen:

Ergebnis: Der Agent generiert den Code DATEDIFF(‚day‘, [Order Date], [Ship Date]). Er erkennt automatisch die relevanten Datumsfelder im Superstore-Datensatz und wählt die passende Funktion.

Beispiel B: Geschäftslogik (Segmentierung von Transaktionen)

Oft müssen Daten nicht nur berechnet, sondern nach geschäftlichen Regeln kategorisiert werden. Wir wollen Aufträge identifizieren, die zwar Umsatz bringen, aber durch hohe Rabatte unrentabel sind.

Ergebnis: Der Agent übersetzt diese gesprochene Logik in eine passende Syntax. Er erkennt dabei automatisch, dass „20%“ im Code als 0.2 geschrieben werden muss:

Die neu-erstellte Berechnung kann dann in beliebigen Visualisierungen eingesetzt werden.

Explain Data – Statistische Ursachenforschung

Zurück zu unserer KI-generierten Visualisierung. Wir sehen nun die Datenpunkte, und vielleicht fällt auf, dass die Kategorie „Tables“ (Tische) ungewöhnlich schlecht abschneidet. Ein klassisches Dashboard zeigt uns das „Was“. Das „Warum“ musste der Analyst bisher mühsam durch manuelles Filtern und Suchen („Drill-Down“) ermitteln.

Hier greift die KI-Komponente „Datenhandbuch“, die nahtlos in den Workflow integriert ist.

Wir klicken in der Visualisierung auf den auffälligen Datenpunkt (z. B. den Punkt für „Tables“).
Wir klicken auf das Symbol des Datenhandbuchs.

Tableau prüft im Hintergrund mögliche Erklärungsmodelle. Es testet Korrelationen, die wir vielleicht nicht in Betracht gezogen hatten.

Das Ergebnis: Das Datenhandbuch mit den Hauptmerkmalen des gewählten Datenpunkts wird im rechten Seitenfenster angezeigt. Dort kann man bestimmen, welche Werte im Detail untersucht werden sollen. Unser Interesse gilt in diesem Fall dem bereits als „niedrig“ klassifizierten „Profit“.

Das nachfolgende Fenster präsentiert die grundlegenden Merkmale und Einflussfaktoren, die den negativen Ausreißer in diesem Fall bedingen könnten. So können wir herausfinden, wodurch diese negativen Ausreißer entstanden sind, und können dementsprechend aktiv werden.

Weitere Details können bei Bedarf aufgeklappt werden. Im vorliegenden Beispiel liegt die Vermutung nahe, dass ein oder mehrere „kritische“ Deals abgewickelt wurden. Diese lassen sich auch mit Hilfe der Formel identifizieren, die wir in einem der vorherigen Schritte zur Berechnung generiert haben und welche nun auch im Datenhandbuch berücksichtigt wird.

Dieser Schritt markiert den Übergang von deskriptiver Analytik (Was ist passiert?) zu diagnostischer Analytik (Warum ist es passiert?). Die KI übernimmt die Rolle eines unvoreingenommenen Statistikers, der auch Zusammenhänge prüft, nach denen der Mensch aufgrund von „Confirmation Bias“ vielleicht gar nicht gesucht hätte. Dennoch bleibt der menschliche Analyst weiterhin ein unverzichtbarer Teil des Prozesses und muss die präsentierten Ergebnisse stets kritisch hinterfragen. So könnte im obigen Beispiel näher betrachtet werden, warum unprofitable Deals abgeschlossen wurden. Auf dieser Basis können Prozesse oder Bewertungskriterien in Zukunft angepasst werden.

Interaktive Verfeinerung der Ansicht

Oft ist der erste Entwurf noch nicht perfekt. Anstatt sich nun durch Menüs zu klicken, nutzen wir den Agenten, um die Ansicht iterativ zu verbessern. Wir wollen den Fokus auf die aktuellen Zahlen legen und die Analyse optimieren. Gleichzeitig wollen wir die hierfür notwendigen Entwicklungsschritte beschleunigen und vereinfachen.

Die Stärke der KI liegt hier in der schnellen Manipulation der Ansicht (View Modifications).

Funktionierende Prompts für den Feinschliff:

1. Geografischer Filter:

„Filtere auf die Region ‚East‘.“
(Eine sichere Methode, um den Datenumfang gezielt einzugrenzen.)

2. Kontext durch Farbe:

„Färbe nach der Summe der ‘Quantity’.“
(Der Agent nutzt automatisch eine divergierende Palette.)

3. Fokus setzen:

„Zeige nur die Flop 5 Sub-Categories nach Profit.“
(Der Agent erstellt automatisch einen Filter)

4. Unterscheidbarkeit sicherstellen:

“Nutze die Sub-Category für die Form.”
(Der Agent legt die Sub-Category als Mermal für die angezeigten Formen fest).

Fazit: Der Analyst als Qualitätsmanager

Die Anwendung der KI-Funktionen im Superstore-Szenario zeigt, dass der Tableau Agent weit mehr ist als eine technische Spielerei. Diese Funktionen erleichtern und beschleunigen Analysten den Einstieg in das Tool und ermöglichen ein effizienteres Arbeiten.

Die wesentlichen Vorteile lassen sich wie folgt zusammenfassen:

Geschwindigkeit (Time-to-Insight): Die Zeit zwischen der analytischen Frage und der visuellen Antwort wird drastisch reduziert.
Qualitätssicherung: Da der Agent Syntax für Berechnungen generiert, werden Syntaxfehler eliminiert. Der Analyst konzentriert sich auf die logische Validierung.
Barrierefreiheit: Komplexe Methoden wie RegEx oder statistische Erklärungsmodelle werden auch für Anwender zugänglich, die keine tiefen Programmierkenntnisse besitzen.

Die Einführung dieser Technologie erfordert ein Umdenken in den BI-Teams. Wir bewegen uns weg von der reinen Erstellung („Wie bediene ich das Tool?“) hin zur Validierung und Interpretation („Stimmt das Ergebnis und was bedeutet es für das Business?“). Der Analyst der Zukunft verbringt weniger Zeit mit dem „Wie“ und mehr Zeit mit dem „Warum“.

Data Products Setup

I’ll start with Data Products setup. If you’re new to the concept, this recent video is a great starting point, but here’s a short summary. A data product is a well-described, easily discoverable, and consumable collection of data sets.

Creating a Data Product in Datasphere

Note that in this article I create Data Products in the Data Sharing Cockpit in Datasphere. This functionality is expected to move into the Data Product Studio, but that had not taken place at the time writing.

Before creating a Data Product in Datasphere, I need to set up a Data Provider profile, collecting descriptive metadata like contact and address details, industry, regional coverage, and importantly define Data Product Visibility. Enabling Formations allows me to share the Data Product with systems across your BDC Formation – Databricks, in this case.

With the Data Provider set up, I can go ahead and create a Data Product. As with the Data Provider, I’ll need to add metadata about the product and define its artifacts – the datasets it contains. Only datasets from a space of SAP HANA Data Lake Files type can be selected. Since this Data Product is visible across the Formation, it is available free of charge.

For this demo, the artifact is a local table containing ten years of Ice Cream sales data. Since this is a File type space, importing a CSV file directly to create a local table isn’t an option (see documentation).

I used a Replication Flow to perform an initial load from a BW aDSO table into a local table.

Once Data Product is created and listed, it becomes available in the Catalog & Marketplace, from where it can be shared with Databricks by selecting the appropriate connection details.

Jump into Databricks

To use the shared object In Databricks, I need to mount it to the Catalog – either by creating a new Catalog or using an existing one.

Databricks appends a version number to the end of the schema – ‘:v1’ – to maintain versioning in case of any future changes to the Data Product.

Once the share is mounted, the schema is created automatically, and the Sales actual data table becomes available within it. From there, I can access the shared table directly in a Notebook.

Creating a Data Product in Databricks

To create a Data Product in Databricks, I first need to create a Share – which I can either do via the Delta Sharing settings in the Catalog:

Or directly out of the table which is going to become a part of the Share:

Since a single Share can contain multiple tables, I have the option to either add the table to an existing Share, or create a new one:

To publish the Share as a Data Product, I run a Python script where I define the target table for the forecast and describe the Share in CSN notation, setting the Primary Keys. Primary Keys are required for installing Data Products in Datasphere.

Jump back into Datasphere

Once the Databricks Data Product is available in Datasphere, I install it into a Space configured as a HANA Database space – since my intention is to build a view on top of the table and use it for planning in SAC.

There are two installation options: as a Remote table for live data access, or as a Replication Flow, in which case the data is physically copied into the object store in Datasphere.

Since I want live access, I install it as a Remote Table:

and build a Graphical view of type Fact on top:

Forecast calculation

With my Data Products set up and Sales actual data are available in Databricks, I create a Notebook to calculate the Sales Forecast.

The approach combines Sales and Weather data to train a Linear Regression model. I import the Weather data *https://zenodo.org/records/4770937 from an external server directly into Databricks, select the relevant features from the weather dataset, and combine them with the Sales actual data:

* Klein Tank, A.M.G. and Coauthors, 2002. Daily dataset of 20th-century surface
air temperature and precipitation series for the European Climate Assessment.
Int. J. of Climatol., 22, 1441-1453.
Data and metadata available at http://www.ecad.eu

Using the “sklearn” library, I build and train a Linear regression model:

Once trained, the model predicts the Sales forecast for Rome in June 2026 based on the weather forecast, and I save the results to my Catalog table:

Seamless planning data model

Seamless planning concept is built around physically storing planning data and public dimensions directly in Datasphere, keeping them alongside the actual data.

Since the QRC4 2025 SAC release, it has also been possible to use live versions and bring reference data into planning models without replication.

In this scenario, I build a seamless planning model on top of the Graphical view I created over the Remote table. This lets me use the forecast generated in Databricks as a reference for the final SAC Forecast version.

The model setup follows these steps:

Create a new model:

Start with data:

Select Datasphere as the data storage:

From there, I define the model structure and can review the data in the preview.

For a deeper dive into Seamless Planning, I recommend this biX blog.

Process Flow automation

Multi-action triggers Datasphere task chain

The final step is automating the entire forecast generation by using SAC Multi-actions and a Task-Chain in Datasphere – so that my user can trigger the calculation with a single button click from an SAC Story.

The model setup follows these steps:

Create a new model:

Triggering Task Chains from Multi-actions is a recent release. This blog post walks through how to set it up.

For details on how to trigger a Databricks Notebook from Datasphere, I recommend referring to this blog.

With everything in place, I create a Story, add my Seamless planning Model, and attach the Multi-action:

Running the Multi-action triggers the Task Chain, which in turn triggers the Databricks Notebook.

I can monitor the execution details in Datasphere:

and in Databricks:

Once the calculation completes, the updated forecast appears in the Story:

The end-to-end calculation took 2 minutes 45 seconds in total. The Task Chain in Datasphere is triggered almost instantly by the Multi-action, the Databricks Notebook execution itself took 1 minute 29 seconds, with the remaining time spent on Serverless Cluster startup.

From here, I can copy the calculated forecast into a new private version:

adjust the numbers as needed, and publish it as a new public version to Datasphere:

Conclusion

With SAP Business Data Cloud, it is possible to build a forecasting workflow that feels seamless to the end user — even though it spans multiple systems under the hood.

Companies using BW as the main Data Warehouse and Databricks for ML calculations or Data Science tasks can benefit from using the platform, as the data no longer needs to be physically copied out of BW.

What this scenario demonstrates is that once wrapped as a Data Product, BW sales data can be shared with Databricks via the Delta Share protocol. Databricks, in turn, can then create its own Data Products on top of the calculation results and share them back with Datasphere as a Remote Table.

A Seamless Planning model in SAC sits on top of that Remote Table, giving planners live access to the generated forecast. A single Multi-action in an SAC Story ties it all together, triggering a Datasphere Task Chain that kicks off the Databricks Notebook — completing the full cycle in under three minutes.

As SAP Business Data Cloud continues to mature, scenarios like this one are becoming achievable – leaving the complexity in the architecture and not in the workflow.