Werttreiber oder Kostenfalle?

Diese vier KPIs machen die Dateneffizienz sichtbar

Unternehmen investieren seit Jahren massiv in moderne Datenplattformen, Cloud-Infrastrukturen und Analysewerkzeuge. Dennoch bleibt in der Praxis häufig unklar, ob diese Architekturen tatsächlich zur Wertschöpfung beitragen oder vor allem laufende Kosten verursachen. Unternehmen, die Dateneffizienz konsequent messen und strukturell adressieren, könnten ihre Datenarchitektur vom reinen Kostenfaktor zu einem strategischen Werttreiber entwickeln.

Im Gespräch mit Computing Deutschland erläutert Jörg Hesske, Regional Vice President bei Denodo, mit welchen Kennzahlen sich die Effizienz von Datenarchitekturen objektiv bewerten lässt. Nach seiner Einschätzung fehlt es in vielen Organisationen weniger an Technologie als an Transparenz.

Zwar seien Budgets, Betriebskosten und Lizenzmodelle meist gut dokumentiert, doch der tatsächliche Nutzen der Dateninfrastruktur lasse sich oft nur schwer beziffern. „Viele Organisationen wissen sehr genau, was ihre Dateninfrastruktur kostet – aber nicht, was sie tatsächlich leistet“, sagt Hesske.

Time to Insight als Frühindikator

Ein zentraler Indikator für die Leistungsfähigkeit einer Datenarchitektur ist aus Sicht von Hesske die sogenannte Time to Insight. Sie beschreibt, wie viel Zeit vergeht, bis aus Rohdaten verwertbare Informationen entstehen – sei es für den operativen Betrieb, strategische Entscheidungen oder KI‑gestützte Anwendungen.

Lange Durchlaufzeiten seien laut Hesske ein klares Warnsignal. Lange Durchlaufzeiten deuteten in vielen Fällen darauf hin, dass Daten in Silos organisiert seien oder Architekturen fragmentiert aufgebaut wurden. „Wenn Daten über viele Systeme verteilt sind und immer wieder repliziert oder manuell angepasst werden müssen, verlängert sich der Weg zur Erkenntnis erheblich“, erklärt er. Die Folgen reichten dabei weit über die IT hinaus: Verzögerte Analysen bremsten Entscheidungen, behinderten Innovationen und schwächten letztlich die Wettbewerbsfähigkeit.

„Im Kern geht es um Zeit”, so Hesske weiter. “Unternehmen sollten messen, wie lange es von einer Anfrage bis zur Bereitstellung nutzbarer Informationen für die Anwender dauert.“ Diese Betrachtung lasse sich über verschiedene Anwendungsfälle hinweg anwenden – von Dashboards über Analysemodelle bis hin zu KI‑Workloads – und eigne sich auch für den Vergleich unterschiedlicher Plattformen oder Werkzeuge.

Produktivität im Data Engineering

Neben der Geschwindigkeit rückt Hesske die Produktivität der Data‑Teams in den Fokus. “Hoher manueller Aufwand, doppelte Datenpipelines oder schwer wiederverwendbare Datenprodukte seien häufige Ursachen”, sagt Hesske.

„Wenn Data Engineers einen Großteil ihrer Zeit mit Wartung verbringen, statt neue Mehrwerte zu schaffen, ist das ein strukturelles Problem der Architektur“, so der Denodo‑Manager weiter.

Aussagekräftig werde dieser KPI vor allem dann, wenn Unternehmen erfassen, wie viele Engineering‑Stunden erforderlich sind, um neue Datenquellen anzubinden oder zusätzliche Datenprodukte bereitzustellen. “Ein pragmatischer Ansatz ist die Erfassung der Engineeringstunden, die für die Integration neuer Datenquellen oder die Bereitstellung neuer Datenprodukte benötigt werden“, erklärt Hesske. „Ergänzend sollte man das Verhältnis von Wartungsaufwand zu wertschöpfender Entwicklungsarbeit betrachten. Diese Kennzahlen helfen nicht nur intern, sondern eignen sich auch für den Vergleich unterschiedlicher Plattformen.“

Kosteneffektivität statt reiner Einsparungen

Datenreplikation, überdimensionierte Rechenleistung oder redundante Tool-Landschaften treiben auch die Kosten der Datenarchitekturen – oft unbemerkt – in die Höhe. Entscheidend sei jedoch nicht, die Kosten um jeden Preis zu senken, betont Hesske: „Es geht darum sicherzustellen, dass Ausgaben tatsächlich zur Wertschöpfung beitragen – und nicht im Hintergrund verpuffen.“

Transparenz lasse sich vor allem durch eine ganzheitliche Betrachtung der Gesamtkosten herstellen. „Die Basis bildet eine umfassende Total‑Cost‑of‑Ownership‑Betrachtung, die Rechenleistung, Speicher, Integrationen, Tool‑Management und weitere Faktoren einbezieht“, so Hesske. „Zusätzlich können Kosten pro Abfrage, pro Use Case oder pro aktivem Nutzer ausgewertet werden, um Transparenz über Effizienz und Skalierbarkeit zu gewinnen.“

Agilität als strategischer Wettbewerbsfaktor

Als vierte wichtige Kennzahl nennt Hesske die Agilität der Datenarchitektur. Marktveränderungen, neue regulatorische Vorgaben oder zusätzliche Geschäftsmodelle erfordern schnelle Anpassungen. Ob Unternehmen dazu in der Lage sind, hängt laut Hesske maßgeblich von der Flexibilität ihrer Datenarchitektur ab. „Agilität bedeutet vor allem, Datenprodukte mehrfach nutzen zu können – für Analysen, operative Anwendungen oder KI‑Use‑Cases“, sagt er.

Lange Projektlaufzeiten wertet Hesske als Indiz für starre Strukturen. „Auch hier ist Zeit die zentrale Kenngröße“, erklärt er. „Unternehmen sollten erfassen, wie lange es dauert, ein neues datengetriebenes Projekt von der Idee bis zur produktiven Umsetzung zu bringen. Ergänzend ist interessant, wie viele Use Cases auf gemeinsam genutzten Datenprodukten basieren – und wie viele individuelle Implementierungen erfordern.“

Logisches Datenmanagement als Hebel

Das Erfassen der KPIs ist laut Hesske nur der erste Schritt. Um sie nachhaltig zu verbessern, brauche es strukturelle Änderungen in der Datenarchitektur. Einen zentralen Hebel sieht er im logischen Datenmanagement.

Durch die Trennung von Datenzugriff und physischen Quellsystemen entstehe eine virtuelle Schicht zwischen Datenproduzenten und ‑konsumenten. „Was zunächst nach zusätzlicher Komplexität klingt, reduziert in der Praxis Datenreplikation, individuelle Pipelines und manuellen Aufwand“, so Hesske. Wiederverwendbare semantische Definitionen steigerten Produktivität und Agilität, während weniger Datenbewegungen die Kosteneffektivität verbesserten.

Die 4 KPIs auf einen Blick

1. Wie schnell werden aus Rohdaten verwertbare Erkenntnisse (Time to Insight)?
Messgröße: Zeit von der Anfrage bis zur Bereitstellung nutzbarer Informationen (Dashboards, Analysen, KI‑Modelle).

ℹ️ Lange Durchlaufzeiten deuten auf Datensilos, unnötige Replikationen und komplexe Integrationen hin.

2. Wie effizient arbeitet das Data‑Team?
Messgröße: Engineering‑Stunden pro neuer Datenquelle bzw. Datenprodukt sowie Verhältnis von Wartung zu Entwicklung.

ℹ️ Hoher manueller Wartungsaufwand spricht für fragmentierte Architekturen und geringe Wiederverwendung.

3. Tragen die laufenden Kosten tatsächlich zur Wertschöpfung bei?
Messgröße: Total Cost of Ownership (TCO) sowie Kosten pro Abfrage, Use Case oder aktivem Nutzer.

ℹ️ Replikation, überdimensionierte Ressourcen und Tool‑Wildwuchs treiben Kosten oft unbemerkt.

4. Wie schnell lassen sich neue datengetriebene Projekte umsetzen?
Messgröße: Zeit von der Idee bis zur produktiven Umsetzung sowie Anteil wiederverwendeter Datenprodukte.

ℹ️ Lange Rollout‑Zeiten sind ein Indikator für starre Datenstrukturen.