50.000 Euro für Exasol – die Frage ist nicht die Lizenz

Fast jede Abteilung hat mindestens ein Dashboard, das eigentlich gut sein sollte, aber trotzdem kaum noch jemand öffnet: Es lädt zu langsam, zeigt veraltete Zahlen, oder zwei Abteilungen streiten über die richtige Version derselben Kennzahl. Das eigentliche Problem liegt in solchen Fällen selten im Dashboard selbst. Es liegt eine Ebene tiefer, in der Datenbank, im Datenmodell oder auf dem Weg von den Quellsystemen zur Auswertung.

Teil eins dieser Reihe hat den Baustein Sichtbarkeit gezeigt, ein klar abgegrenztes BI-Projekt mit Tableau Server oder Amazon QuickSight. Dieser Beitrag geht eine Ebene tiefer: das Datenfundament, mit Exasol als möglichem Baustein. Zur Erinnerung: Seit dem 1. Juli 2026 liegt die Direktvergabegrenze für Bundesbehörden bei 50.000 Euro netto. Länder und Kommunen regeln ihre Wertgrenzen eigenständig.

Die eigentliche Leitfrage ist nicht, ob sich für 50.000 Euro eine Exasol-Lizenz kaufen lässt. Vielmehr lautet sie: Lässt sich innerhalb dieses Rahmens belastbar prüfen, ob eine eigene analytische Datenbasis Ihr Reportingproblem wirklich löst?

Warum operative Systeme an ihre Grenzen kommen

Fachverfahren sind für den Alltag gebaut. Dazu zählen Anträge, Laboraufträge, Zahlungen oder Statusänderungen. Komplexe Auswertungen über lange Zeiträume gehören selten zu ihren eigentlichen Aufgaben. Trotzdem laufen genau solche Abfragen oft direkt auf diesen Systemen. Die Folgen sind bekannt: Dashboards werden träge, die Produktivsysteme geraten zusätzlich unter Last, und mit wachsender Datenmenge dauert jede historische Auswertung länger als die letzte. Fachbereiche greifen zu eigenen Excel-Kopien, weil der offizielle Weg zu langsam oder zu starr ist.

Eine eigenständige Analyseschicht trennt operative Verarbeitung und Reporting voneinander. Daten aus ausgewählten Quellen werden geladen, transformiert, fachlich strukturiert und für BI-Werkzeuge bereitgestellt. Das Produktivsystem wird dadurch nicht mehr bei jeder Abfrage zusätzlich belastet.

Welche Rolle Exasol dabei übernimmt

Exasol positioniert sich als die souveräne Datenbank für KI-Agenten: entwickelt für KI- und Analyse-Workloads mit hoher Parallelität. Für den in diesem Beitrag beschriebenen Anwendungsfall heißt das konkret: Dieselbe Architektur, die viele gleichzeitige KI- und Analyseabfragen zuverlässig verarbeitet, trägt auch klassische Reporting-Workloads. Je nach Vertragsmodell läuft Exasol selbst betrieben oder als SaaS-Angebot nutzbar. In einer typischen Reportingarchitektur sitzt Exasol zwischen den aufbereiteten Quelldaten und einem BI-Werkzeug wie Tableau. Dort werden Daten zusammengeführt, Berechnungslogiken vereinheitlicht und historische Daten ausgewertet, weitgehend getrennt von den operativen Produktivsystemen. Tableau lässt sich dabei über JDBC (Java Database Connectivity) oder ODBC (Open Database Connectivity) direkt mit Exasol verbinden. Das erlaubt Live-Analysen auch bei hoher Parallelität und auf großen Datenbeständen.

Wird der Ladeprozess zum Beispiel nur einmal pro Nacht angestoßen, zeigt das Dashboard am nächsten Morgen noch den Stand von gestern, egal wie schnell Exasol die einzelne Abfrage danach beantwortet. Wie aktuell ein Dashboard wirkt, entscheidet also der Ladeprozess mit, nicht die Datenbank allein.

Im M2 Data Maturity Framework ist eine solche zentrale Datenbasis ein typischer Entwicklungsschritt: weg von fragmentierten Datenbeständen hin zu organisierten, wiederverwendbaren Datenprozessen. Exasol ist dort ein möglicher Baustein für ein zentralisiertes Data Warehouse.

Wann sich der Blick auf die Datenbasis überhaupt lohnt

Nicht jedes langsame Dashboard benötigt eine neue Datenbank. Manchmal reichen ein besseres Datenmodell, effizientere Abfragen oder eine Optimierung der bestehenden Tableau-Arbeitsmappe. Ein Hinweis auf ein tieferes Problem sind eher Situationen wie diese: Analytische Abfragen bremsen das operative Fachverfahren spürbar aus. Dieselben Daten werden für verschiedene Berichte mehrfach kopiert. Kennzahlen werden in jedem Dashboard neu berechnet oder neue Berichtswünsche lassen sich nur noch durch weitere Einzellösungen umsetzen.

Unsere Einordnung: Eine kombinierte Daten- und Performanceanalyse schafft die Grundlage für diese Entscheidung. Sie zeigt, ob Exasol im konkreten Fall einen Mehrwert schafft oder ob eine kleinere, günstigere Optimierung der bestehenden Umgebung bereits genügt. Diese Ehrlichkeit gehört für uns zu einem guten Einstiegsprojekt dazu, auch wenn das Ergebnis am Ende gegen eine größere Einführung spricht.

Was innerhalb von 50.000 Euro realistisch machbar ist

Für eine größere Behörde reicht dieses Budget in der Regel nicht, um ein organisationsweites Data Warehouse komplett zu planen, zu migrieren und produktiv auszurollen. Bei überschaubarer Daten- und Integrationskomplexität reicht der Rahmen aber für einen klar abgegrenzten Datenbereich.

Beispiele dafür sind:

• Fallzahlen und Bearbeitungszeiten eines Fachverfahrens
• Betriebsdaten einer öffentlichen Einrichtung
• Servicekennzahlen eines Bürgerportals
• oder ein einzelnes Dashboard mit auffällig hohen Ladezeiten

Das Projekt beschränkt sich bewusst auf einen fachlich relevanten Ausschnitt und lässt die übrigen Datenquellen der Organisation zunächst außen vor. Aus dem Budget wird so kein verkleinertes Großprogramm, sondern ein Pilot, der anhand realer Daten eine belastbare Entscheidung ermöglicht.

Ein solches Einstiegsprojekt lässt sich aus unserer Erfahrung in fünf Schritten denken.

• Zuerst die Diagnose. Welche Berichte sind besonders langsam, welche Abfragen erzeugen die höchste Last, und liegt der Engpass in der Datenbank, im Datenmodell, in der Verbindung oder im Dashboard selbst?
• Danach wird ein Datenbereich klar abgegrenzt: fachlich zusammenhängend, mit verantwortlicher Fachseite, bekannten Datenquellen und einem erkennbaren Engpass. Groß genug für echten Nutzen, klein genug für das Budget.
• Die Daten wandern nach Exasol und werden dort modelliert. Uneinheitliche Bezeichnungen werden harmonisiert, wiederkehrende Kennzahlen zentral berechnet, damit nicht mehr jedes Dashboard seine eigene Version derselben Zahl liefert.
• Tableau oder ein anderes BI-Werkzeug wird an die neue Datenbasis angebunden. Wie aktuell die Daten sein müssen und wie viel Last die Systeme vertragen, entscheidet sich von Fall zu Fall.
• Zum Schluss die Betriebsgrundlage: Dokumentation, Monitoring der Lade- und Abfrageprozesse, geregelte Rollen und Zuständigkeiten für die Datenqualität.

Drei Zuschnitte, je nach Ausgangslage

Aus unserer Projekterfahrung passen unterschiedliche Ausgangslagen zu unterschiedlichen Pilotformen.

• Performance-Pilot eignet sich, wenn ein bestehendes Dashboard fachlich funktioniert, aber an langen Wartezeiten oder instabilen Aktualisierungen scheitert. Ein begrenzter Datenbestand wandert nach Exasol. Vorher- und Nachher-Ladezeiten werden gemessen.
• Datenmodell-Pilot passt, wenn verschiedene Bereiche regelmäßig über abweichende Werte für denselben Sachverhalt diskutieren. Berechnungen, die vorher in einzelnen Excel-Dateien verstreut waren, werden zentral und nachvollziehbar dokumentiert.
• Entlastungs-Pilot ist relevant, wenn analytische Abfragen ein operatives Fachverfahren spürbar belasten oder nur außerhalb der üblichen Betriebszeiten laufen dürfen. Die Reporting-Last wird gezielt aus dem Produktivsystem herausgelöst.

Praxisbeispiel: Tableau und Exasol bei Labor Berlin

Wie das Zusammenspiel aus Datenbank, Datenmodell und Visualisierung in der Praxis aussehen kann, zeigt ein Projekt bei Labor Berlin. Das Beispiel dient hier ausschließlich zur Illustration der technischen Architektur und steht nicht in Verbindung mit der neuen Direktvergabegrenze.

Labor Berlin verarbeitet ein hohes Aufkommen an Laboranalysen. In der damaligen Ausgangslage kamen mehrere Herausforderungen zusammen: Das Produktivsystem wurde durch Berichtsabfragen belastet, das Datenmodell war inkonsistent und das Reporting stieß an Leistungsgrenzen. M2 hat deshalb mehrere Ebenen gemeinsam betrachtet: die Migration der analytischen Datenbank auf Exasol, die Überarbeitung des Datenmodells, die Umstellung auf Live-Datenverbindungen und die Performanceoptimierung der Tableau-Dashboards.

Das Ergebnis: Ausgewählte Dashboards ließen sich um bis zu 90 Prozent beschleunigen. Diese Zahl bezieht sich auf das konkrete Projekt und lässt sich nicht pauschal auf andere Umgebungen übertragen. Aufschlussreicher ist, was ohne die Kombination aller Maßnahmen gefehlt hätte: Eine schnellere Datenbank hätte am inkonsistenten Datenmodell wenig geändert. Ein neues Datenmodell hätte das Produktivsystem trotzdem weiter überlastet. Erst die Kombination aus Exasol-Migration, überarbeitetem Datenmodell und Live-Verbindungen hat den Effekt gebracht.

Ein Pilot braucht messbare Ziele

Bereits vor dem Projektstart sollte feststehen, woran der Erfolg bewertet wird, etwa an der Ladezeit ausgewählter Dashboards, der Laufzeit definierter Datenbankabfragen, der Belastung des operativen Quellsystems oder der Zahl manueller Dateiübertragungen, die künftig entfallen. Ein Pilot ist auch dann wertvoll, wenn er am Ende gegen eine größere Einführung spricht. Denn sein eigentlicher Zweck ist es, eine Architekturentscheidung auf reale Daten statt auf Vermutungen zu stützen.

Woher unsere Einschätzung kommt: Ein Exasol-Projekt ist mehr als eine Datenbankinstallation. Architektur, Datenengineering, Datenmodellierung, BI-Anbindung und Betrieb müssen zusammenkommen, damit ein fachlich nutzbares Ergebnis entsteht. Unsere Projekterfahrung reicht von Datenbankmigrationen und Data-Warehouse-Projekten über Tableau-Architekturen bis zu Performanceanalysen und der langfristigen Weiterentwicklung bestehender Datenplattformen. Eine leistungsfähige Datenbank allein beantwortet noch keine fachliche Frage. Erst eine verständliche Datenlogik, verlässliche Prozesse und eine geeignete Analyseschicht machen die Informationen im Arbeitsalltag nutzbar.

Auch bei Exasol zählt der Gesamtbedarf

Für Lizenzen, Betrieb, Wartung und andere wiederkehrende Leistungen gelten dieselben Grundsätze wie im ersten Teil dieser Reihe: Der voraussichtliche Gesamtbedarf muss realistisch ermittelt werden. Wirtschaftlich zusammengehörige Leistungen dürfen nicht künstlich in Einzelaufträge zerlegt werden. Ein fachlich und zeitlich klar abgegrenzter Pilot kann innerhalb der Direktauftragsgrenze liegen, solange damit kein bereits feststehender, größerer Gesamtbedarf künstlich aufgeteilt wird. Ist von Anfang an eine mehrjährige Produktivumgebung mit Lizenzen und Support geplant, muss dieser Gesamtbedarf entsprechend berücksichtigt werden. Die endgültige vergaberechtliche Einschätzung trifft am Ende die zuständige Vergabestelle.

Zwei Bausteine, ein gemeinsames Ziel

Beide Teile dieser Reihe folgen derselben Idee: Ein begrenztes Budget soll einen vollständigen, überprüfbaren Baustein mit echtem fachlichen Nutzen schaffen, mehr als einen isolierten Technologieeinkauf. Fehlt bislang ein gemeinsamer Zugang zu vorhandenen Daten, ist ein BI-Projekt wie in Teil eins oft der richtige erste Schritt. Sind Berichte vorhanden, aber langsam oder widersprüchlich, lohnt sich der Blick auf die Datenbasis, wie in diesem Beitrag beschrieben. Liegen beide Probleme gleichzeitig vor, sollten Datenmodell und Dashboard von Anfang an gemeinsam betrachtet werden. Die beiden Bausteine dieser Reihe lassen sich frei kombinieren.

Wenn Sie einordnen möchten, ob der Engpass bei Ihnen eher im Dashboard, im Datenmodell oder in der technischen Datenbasis liegt, stehen wir dafür zur Verfügung, ganz ohne Verpflichtung. In einem unverbindlichen Erstgespräch schauen wir gemeinsam, welcher Reportingprozess heute den größten Aufwand verursacht und welcher Pilot innerhalb Ihres Budgetrahmens eine belastbare Entscheidung ermöglicht.

Wer die Datenbasis jetzt klärt, trifft die nächste Architekturentscheidung mit Fakten statt mit Bauchgefühl.

Teil eins lesen: Der Baustein Sichtbarkeit →