Standardisierte Metriken mit Tableau Pulse: Ein Ansatz zur „Headless BI“-Architektur mit KI  

Einleitung

März 2026

Seit knapp zwanzig Jahren funktioniert Business Intelligence (BI) in vielen Fällen nach dem „Pull-Prinzip“: Nutzer müssen Dashboards aktiv öffnen, Filter setzen und Visualisierungen interpretieren, um für sie relevante Infos zu finden. Doch dieser Ansatz stößt in der heutigen, schnelllebigen Arbeitswelt mittlerweile oft an seine Grenzen. Die Zeit zwischen dem Vorliegen der Daten und der daraus resultierenden Erkenntnis ist oftmals zu lang. 

Eine neue KI-Funktionalität von Tableau, Tableau Pulse, adressiert dieses Defizit durch den Wechsel zur „Push-Analytik“. Statt aufwändige, pixelgenaue Berichte zu erstellen, definieren BI-Architekten standardisierte Kennzahlen (Metriken), die den Nutzern proaktiv zugesendet werden. Technisch sprechen wir hier von einer „Headless BI“-Architektur: Die Business-Logik (die Metrik) ist von ihrer Darstellung (der Visualisierung) entkoppelt. Anstatt relevante Informationen in verschiedenen Berichten und Dashboards suchen zu müssen, werden den Benutzern diese Informationen in geeigneter Form und an geeigneter Stelle proaktiv bereitgestellt. 

In diesem Blog zeigen wir Schritt für Schritt, wie ein solcher Ansatz grundlegend funktionieren kann. Wir nutzen den bekannten „Sample – Superstore“-Datensatz von Tableau, um die Konfiguration einer Metrik-Definition in Tableau Cloud zu demonstrieren. 

Voraussetzungen und technische Umgebung 

Um die folgenden Schritte in Ihrer eigenen Unternehmensumgebung nachvollziehen zu können, benötigen Sie eine korrekt eingerichtete Tableau Cloud-Umgebung. Im Folgenden betrachten wir, welche Infrastruktur zur Nutzung der hier betrachteten KI-Features vorausgesetzt wird und welche Einstellungen dafür erforderlich sind. 

System-Checkliste: 

1. Tableau Cloud Instanz: Tableau Pulse steht zurzeit nur in der Tableau Cloud zur Verfügung. 

2. KI-Funktionen aktivieren: Die Optionen „Tableau Pulse aktivieren“ und “Tableau Pulse: Fasst die Erkenntnisse aus kritischen Kennzahlen zusammen” müssen aktiviert sein. 

 

3. Datenbasis: Wir verwenden die Beispiel-Datenquelle „Sample – Superstore“, die im Standard von Tableau bereitgestellt wird. 

Die Etablierung der Metrik-Definition (Semantic Layer) 

In Tableau Pulse beginnt der Workflow nicht mit einer Visualisierung, sondern mit der Semantik. Wir öffnen die Tableau Pulse Startseite und legen eine „Neue Metrikdefinition“ an. Damit legen wir fest, welche Kennzahl für uns in einem bestimmten Kontext relevant ist. Anschließend liefert uns Tableau auf Basis von KI erweiterte Informationen zu dieser Kennzahl und den mit ihr in Verbindung stehenden Merkmalen. 

  1. Wir öffnen Tableau Pulse, um in das relevante Menü zu gelangen. 

 

2. Wir klicken auf Neue Metrikdefinition, um den Prozess zur Erstellung einer neuen Metrikdefinition zu starten. 

 

3. Wir erstellen die ”Core-Definition” der neuen Metrik: 

(1) Damit die neue Metrikdefinition eindeutig identifiziert werden kann, vergeben wir einen eindeutigen Namen. 

Optional: Wir können das “Beschreibung”-Feld für technische Dokumentation (z.B. „Bruttoumsatz vor Retouren“) nutzen. Diese Metadaten werden von der KI genutzt, um Kontext für den Endanwender zu generieren. 

(2) Wir wählen die zu analysierende Kennzahl, über die wir Informationen erhalten bzw. verteilen wollen. 

(3) Wir selektieren den für den gewählte Kennzahl relevanten Aggregationstyp, d.h. ob Werte der Kennzahl z.B. summiert werden sollen. 

(4) Wir legen die Logik für die angezeigte Sparkline-Visualisierung fest, wodurch u.a. Vergleichswerte für unsere Kennzahl bereitgestellt werden. 

(5) Wir definieren über welche Zeitdimension (z.B. Rechnungsdatum, Lieferdatum) die Metrik analysiert werden soll 

(6) Wir fügen eine oder mehrere Filter hinzu, die durch Benutzer gemäß Ihres Informationsbedarfs angepasst werden können 

4. Wir verfeinern die Einstellungen für Zeitangaben, Ziel- und Schwellenwerte, um die Metrik weiter zu individualisieren: 

5. Wir legen im “Erkenntnisse” -Menü fest, über welches Merkmal Datensätze eindeutig identifiziert werden können (1). Dies ist insbesondere für die Identifikation von Ausreißern relevant – in diesem Fall von Bestellungen mit einem auffallend geringen oder hohen Umsatz. 

6. Wir können im Governance-Menü eine Vorschau der Metrik sehen und definieren, falls nötig, die Berechtigungen, um zu steuern, welche Benutzer Zugriff auf die Metrik haben. 

7. Zuletzt betrachten wir das Ergebnis in der Metriken-Liste in Tableau Pulse: 

Detailbetrachtung der generierten Metrik 

speichern, beginnt die Engine mit der Analyse von Anomalien, Trends und Treibern. Durch diese Konfiguration erzeugt das System automatisch die gesamte Berechnungslogik für Vergleiche (Vorperiode) und Trendanalysen im Hintergrund. Das kann den Aufwand für BI-Teams potenziell enorm verringern, da diese oder ähnliche Analysen nicht erst „manuell“ erstellt werden müssen. Dies ermöglicht es den „Konsumenten“ der analysierten Kennzahl zudem potenziell, neue Abhängigkeiten oder Kausalitäten, welche die Kennzahl beeinflussen, zu erkennen.  

Die Detailseite der Metrik – das Ergebnis dieser KI-gestützten Analyse – liefert eine Zusammenfassung der wichtigsten Datenpunkte in natürlicher Sprache. 

Das System generiert automatisch Aussagen wie: „Der Umsatz ist um 12% gestiegen, primär getrieben durch die Kategorie ‚Technology‘ in der Region ‚East‘.“ 

Für IT-Sicherheit und Datenschutz ist entscheidend: Diese Analyse findet innerhalb des sogenannten Einstein Trust Layers statt. Kundendaten werden nicht zum Training öffentlicher Modelle verwendet. Die KI agiert ausschließlich im Kontext der definierten Metrik und gewährleistet Datensouveränität. 

Kontextualisierung durch dimensionale Filter 

Moderne BI-Architekturen vermeiden Redundanz. Anstatt einen separaten Bericht für jede Region oder Produktgruppe zu erstellen, können wir in Pulse flexible Filter-Kontexte innerhalb einer einzigen Metrik-Definition festlegen. 

Somit kann die Metrik für verschiedene Benutzerkreise individualisiert werden. Ein Regionalleiter sieht beispielsweise dieselbe Metrik-Definition wie der globale Vertriebsleiter, aber standardmäßig gefiltert auf seinen Verantwortungsbereich. Die Daten bleiben konsistent, die Ansicht wird aber individualisiert. 

Integration in den Workflow (Mobile & Digest) 

Ein weiteres relevantes Thema ist die Verteilung der generierten Metriken. Im „Headless“-Szenario ist das Ziel, die Information genau dorthin zu bringen, wo die Entscheidungsträger arbeiten. Dies vereinfacht die Auswertung der Kennzahlen und erhöht damit die Wahrscheinlichkeit, dass diese auch tatsächlich betrachtet und genutzt werden. 

Tableau Pulse verwendet hierfür das „Folgen“/”Follow”-Modell (ein Abonnement-Prinzip): 

  1. Wir klicken auf “Folgen“ (Alternative: Follower werden über “Follower hinzufügen/Add Followers” hinzugefügt) um zukünftig Informationen zu dieser Metrik zu erhalten. 

2. Wir definieren, optional, persönliche Filter (z. B. nur „Country/Region”) um die Metrik zu individualisieren. 

3. Tableau generiert periodische Zusammenfassungen, die den Benutzern bereitgestellt werden, die der Metrik folgen. 

Diese “Digests” (Zusammenfassungen) landen per E-Mail, Slack oder über die Tableau Mobile App beim Nutzer. Sie enthalten nicht nur den aktuellen Wert, sondern auch die KI-generierte Trendbewertung. Das Dashboard wird so vom primären Monitoring-Tool zu einem optionalen Diagnose-Werkzeug für den Drill-Down. 

Über ein entsprechendes Einstellungsmenü können wir im Detail festlegen, wie und über welchen Kanal “Digests” bereitgestellt werden sollen – abhängig davon, wann die Kennzahlen von ihren „Konsumenten“ benötigt werden. 

In der Metriken-Übersicht können uns zudem eine kurze Zusammenfassung der Metrik anschauen: 

Fazit: Eine neue Rolle für Data Analysten 

Die Einführung von Tableau Pulse und ähnlicher „Metric-Store“-Technologien markiert einen Wandel für BI-Teams. Der Fokus verschiebt sich weg von der Erstellung und Pflege visueller Oberflächen hin zur Architektur valider Datenmodelle und Metrik-Definitionen. Wichtige Kennzahlen werden Ihren „Konsumenten“ proaktiv, zum richtigen Zeitpunkt und in passender Form bereitgestellt. 

Mit der Konfiguration von Tableau Pulse, wie am „Superstore“-Beispiel gezeigt, können Unternehmen drei strategische Ziele verfolgen: 

1. Schnellere Erkenntnisse dank proaktiver Benachrichtigungen. 

2. Höhere Datenkonsistenz durch zentral verwaltete Metrik-Definitionen. 

3. Skalierbare Personalisierung ohne hohen Mehraufwand für das Berichtswesen. 

Wir empfehlen, mit einer Pilotphase für die wichtigsten KPIs (Umsatz, Marge, Lagerbestand) zu starten, um die „Push-Analytik“ in der Führungsebene zu demonstrieren und die Vorteile dieses Ansatzes herauszustellen. 

KI-gestützte Analysetools, wie etwa Tableau Pulse, können Data Analysts signifikant entlasten. Sie generieren proaktive Einblicke und automatisieren Routineaufgaben. Wichtig ist jedoch: Man sollte diesen Ergebnissen nicht blind vertrauen. Die Vorschläge der künstlichen Intelligenz dienen als Ausgangspunkte oder Hypothesen. Die abschließende Validierung und die Beurteilung der geschäftlichen Auswirkungen erfordern weiterhin die Expertise und das Urteilsvermögen der Data Analysts. Die KI ist ein unterstützendes Werkzeug; die finale Entscheidung liegt aber weiterhin beim menschlichen Experten. 

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.

Ansprech­partner

Ilya Kirzner
Consultant
biX Consulting
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.