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?
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.
Exasol positioniert sich als souveräne Datenbank für KI-Agenten, entwickelt für KI- und Analyse-Workloads mit hoher Parallelität – dieselbe Architektureignet sich genauso für klassisches Reporting. Je nach Vertragsmodell läuft Exasol selbst betrieben, als SaaS oder, über die Partnerschaft mit STACKIT, in deutschen und österreichischen Rechenzentren mit Datenhaltung ausschließlich in der EU und ohne Zugriffsrisiko durch den US CLOUD Act, naheliegend für ein Unternehmen mit Hauptsitz in Nürnberg. 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.
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.
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. Oft genügt dafür auch deutlich weniger als 50.000 Euro.
Beispiele dafür sind:
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.
Aus unserer Projekterfahrung passen unterschiedliche Ausgangslagen zu unterschiedlichen Pilotformen.
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.
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.
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.
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.
KI-Projekte scheitern an Prozessen, nicht an Algorithmen. Wir zeigen, warum gute Governance über Erfolg oder Misserfolg von KI-Initiativen entscheidet…
Weiterlesen
Ein Dashboard kann inhaltlich stimmen und trotzdem scheitern. Wir zeigen, wie ein Budget von bis zu 50.000 Euro das Datenfundament dahinter verändern…
Weiterlesen
Wir zeigen, was Tableau und Amazon QuickSight möglich machen.
Weiterlesen
Wie Behörden Daten schneller, verständlicher und wirtschaftlicher nutzbar machen.
Weiterlesen