Benötigt dein Unternehmen ein Data Warehouse?
Die Entscheidungsfindung in 4 Schritten

Data Warehouse als Entscheidungsgrundlage: Worum es bei modernem Data Warehousing wirklich geht

Die eigentliche Frage hinter „Brauchen wir ein Data Warehouse?“ lautet: Wie stellst Du sicher, dass Management, Controlling, Produktion und Vertrieb mit denselben, verlässlichen Zahlen arbeiten – heute und in drei Jahren noch. Es geht weniger um eine Technologieentscheidung, sondern um die Basis Deiner Steuerung.

Eurostat zeigt: Bereits 45,5 % der Unternehmen in der EU hosten ihre Datenbanken in der Cloud. Gleichzeitig sagen laut einer DACH-Industrieumfrage sechs von zehn Industrieunternehmen, dass sie „bei der Datenanalyse höchstens an der Oberfläche kratzen“. Genau dazwischen liegt die Entscheidung, ob Du eine zentrale Datenbasis aufbaust – oder weiter mit verteilten Systemen arbeitest.

In diesem Artikel geht es darum, ob Du so eine Plattform jetzt brauchst – nicht darum, jedes technische Detail eines Data Warehouses zu erklären. Du bekommst eine klare Entscheidungslogik in vier Schritten und erfährst, ab wann Alternativen wie Direkt-Reporting oder einzelne Datenmarts noch ausreichen.

Die Leitfragen sind: Musst Du mehrere Systeme verbinden, um die Vorteile von Data Warehouses zu nutzen? Sind historische Analysen wichtig? Liegt Historie in den Systemen wirklich vor, um die Erstellung von Data Warehouses zu unterstützen? Und gefährden Auswertungen die Stabilität Deiner ERP-, MES- oder CRM-Systeme? Wenn Du diese Fragen strukturiert beantwortest, wird die Entscheidung über den Data Mart deutlich einfacher.

Was ein Data Warehouse ist – und was nicht

Ein Data Warehouse ist keine zusätzliche Datenbank und auch kein schickeres Dashboard. Es ist eine eigene Schicht zwischen Quellsystemen und BI-Tools, in der Daten integriert, bereinigt, historisiert und fachlich modelliert werden.

Ein BI-Tool wie Power BI, Qlik oder Tableau liefert Visualisierung und Self-Service, aber es ersetzt nicht automatisch eine zentrale Datenbasis. Wenn jede Auswertung ihre eigene Logik direkt auf ERP-Exports aufbaut, hast Du am Ende viele Reports – aber keine einheitliche Wahrheit.

Kostenloses Erstgespräch vereinbaren

Typische Erwartungen von mittelständischen Unternehmen

Im Mittelstand ist die Erwartung klar: weniger Excel-Schleifen, weniger Diskussionen über Zahlen und schneller verfügbare, zuverlässige Reports. Gleichzeitig sollen Projekte schlank bleiben, ohne monatelange IT-Vorlaufzeiten oder massive Investitionen.

Viele erhoffen sich zudem eine tragfähige Basis für zukünftige KI-Projekte, ohne heute schon alle Anwendungsfälle zu kennen, weshalb Data Warehouses erfordern, dass die Daten konsistent sind. Ein Data Warehouse kann genau das leisten – wenn es pragmatisch aufgebaut wird und zur tatsächlichen Komplexität der Datenlandschaft passt, die in einem IBM DB2 Warehouse gespeichert ist.

Suchintention: Entscheidungshilfe statt Techniklexikon

Wenn Du nach „Data Warehouse Entscheidungshilfe“ suchst, willst Du keine akademische Abhandlung, sondern eine klare, belastbare Antwort:
Lohnt sich der Aufwand für uns? – ja oder nein? Vor allem im Hinblick auf die Vorteile, die Data Warehouses bieten? Und wenn ja, in welcher Ausprägung die Daten im zentralen Repository vorliegen.

Genau dafür nutzen wir im Folgenden vier Prüffragen, die sich an Deiner Realität orientieren: Systemlandschaft, Historienbedarf, technische Grenzen der Quellsysteme und Performance im Alltag. Die Technik bleibt im Hintergrund, die Steuerungsfragen stehen im Vordergrund.

Schritt 1: Müssen Daten aus mehreren Quellsystemen in einem Data Warehouse zusammengeführt werden?

Die erste Frage ist die einfachste – und oft die wichtigste: Reichen Dir Auswertungen aus einem einzigen Kernsystem, oder musst Du regelmäßig Daten aus mehreren Systemen kombinieren, um Deine Fragen zu beantworten?

Typische Kombinationen im Mittelstand sind ERP plus FiBu, ERP plus MES, ERP plus CRM oder ERP plus Webshop, die alle von einem zentralen Repository profitieren. Sobald Du Kennzahlen über diese Grenzen hinweg vergleichen oder zusammenführen willst, wird ein zentraler Ort für Konsolidierung sinnvoll.

Wann ein einzelnes System noch ausreicht

Wenn die meisten Deiner Entscheidungen auf einem System basieren, beispielsweise einem gut strukturierten ERP mit integriertem Finanzmodul, kann es ausreichen, direkt dort zu reporten. Voraussetzung: Die Daten sind vollständig, es gibt kaum Fremdsysteme, der Historienbedarf ist überschaubar, und sie können in einem Data Warehouse transformiert werden.

In solchen Fällen können eingebaute Berichtsfunktionen oder ein BI-Tool direkt auf der Datenbank eine pragmatische Lösung sein. Wichtig ist, dass Du ehrlich prüfst, ob nicht doch regelmäßig Excel-Listen aus weiteren Systemen hinzukommen.

Wenn ERP, CRM, Webshop & Produktion gemeinsam ausgewertet werden sollen

In der Praxis arbeiten die meisten mittelständischen Unternehmen mit einer ganzen Reihe von Systemen: ERP für Aufträge und Bestände, CRM für Kontakte und Opportunities, MES oder BDE für Produktionsdaten, Webshop für Online-Umsätze, dazu Excel-Sheets für Spezialfälle.

Wenn Du verstehen willst, wie sich Auftragsbestand, Produktionsauslastung, Lieferperformance und Kundenprofitabilität zusammenspielen, kommst Du um eine systemübergreifende Sicht nicht herum. Genau hier beginnen klassische Data-Warehouse-Szenarien.

Praxisbeispiele: Produktion, Controlling, Vertrieb

Ein Produktionsleiter möchte OEE, Ausschussquoten und Stillstände werkübergreifend vergleichen. Die Stillstandsgründe kommen aus dem MES, die Planmengen aus dem ERP, die Qualitätsdaten aus einem CAQ-System. Ohne zentrale Zusammenführung bleiben Vergleiche unscharf oder nur mit hohem manuellem Aufwand möglich.

Im Controlling sollen Deckungsbeiträge kunden- und artikelübergreifend über mehrere Jahre analysiert werden. Rabatte und Boni liegen im ERP, Serviceaufwände im Ticketsystem, während Erlöse in einem zentralen Repository konsolidiert werden. Auch hier entstehen ohne zentrales Modell schnell widersprüchliche Bilder.

Was passiert, wenn Du ohne zentrale Datenbasis weiterarbeitest?

Wenn jede Abteilung ihre eigenen Exporte kombiniert, entstehen parallel mehrere „Wahrheiten“. Der Vertrieb rechnet anders als das Controlling, während die Produktion andere Stammdaten nutzt als die Logistik, was die Vorteile von Data Warehouses verdeutlicht, insbesondere weil ein Data Warehouse hingegen ein zentrales Repository für alle relevanten Daten darstellt. Diskussionen drehen sich dann um Zahlen, nicht um Maßnahmen.

Zusätzlich wächst mit jedem neuen Tool der Integrationsaufwand. Was anfangs mit zwei Systemen noch per Hand funktioniert, skaliert bei fünf oder zehn Systemen nicht mehr. Spätestens dann lohnt sich eine zentrale Datenplattform – oder Du bezahlst die Komplexität dauerhaft in Zeit und Fehlern, was die Vorteile von Data Warehouses in den Vordergrund rückt.

Schritt 2: Sollen historische Daten im Data Warehouse ausgewertet werden?

Die zweite Prüffrage betrifft die Zeitdimension: Reicht Dir der aktuelle Stand, oder musst Du Entwicklungen nachvollziehen – zum Beispiel Preisänderungen, Kundenwechsel, Maschinenzustände oder Organisationsanpassungen über mehrere Jahre?

Für viele Management- und Controllingfragen ist Historie kein „Nice-to-have“, sondern zwingend, insbesondere wenn es darum geht, große Datenmengen zu analysieren. Ohne saubere Zeitachsen kannst Du Trends nicht belastbar erkennen, Forecasts schlecht validieren und Revisionen nur mit großem Aufwand bedienen.

Warum operative Systeme Historie meist überschreiben

Operative Systeme wie ERP oder CRM sind für Transaktionen optimiert. Sie speichern den aktuellen Zustand, damit Aufträge, Buchungen oder Kundeninteraktionen schnell verarbeitet werden können. Vergangene Zustände werden häufig überschrieben oder nur in begrenztem Umfang aufbewahrt.

Beispiel: Eine Kundenadresse wird geändert, ein Preis im Artikelstamm angepasst, eine Kostenstelle umstrukturiert. Im operativen System siehst Du dann meist nur den neuen Wert, während komplexe Abfragen im Data Warehouse konsolidiert die historischen Daten bereitstellen. Für die Frage, wie sich Umsatz nach alter und neuer Region entwickelt hat, fehlen Dir die historischen Stände in den im Data Warehouse gespeicherten Daten.

Typische historische Fragestellungen im Mittelstand

Im Controlling tauchen Fragen auf wie: „Wie hat sich der Deckungsbeitrag für Produktgruppe X in den letzten fünf Jahren entwickelt – bereinigt um Preisanpassungen?“ oder „Wie haben sich Bestände zum jeweiligen Monatsende tatsächlich dargestellt?“. Ohne Snapshots im Zeitverlauf bleiben diese Fragen schwer belegbar.

In der Produktion geht es um Stillstands- und Ausschusshistorien, Schichtverläufe oder Anlaufkurven neuer Linien. Der Vertrieb möchte nachvollziehen, wann ein Kunde von Region A nach B gewechselt ist, wie sich Rabattstaffeln verändert haben oder wann bestimmte Konditionen eingeführt wurden.

Beispiele: Preisentwicklungen, Kundenhistorien, Vertriebsstrukturen

Bei Preisentwicklungen interessiert Dich nicht nur der aktuelle Listenpreis, sondern auch, wann eine Preiserhöhung wirksam wurde und wie sich das auf Absatz und Marge ausgewirkt hat, insbesondere im Hinblick auf die Daten im Enterprise Data. Ohne historisierte Preistabellen kannst Du das nur grob schätzen.

Kundenhistorien sind ähnlich: Wenn ein Key Account strukturell zwischen zwei Vertriebsregionen verschoben wurde, willst Du später nachvollziehen, welcher Region welcher Umsatz historisch zugeordnet war. Das betrifft Zielvereinbarungen, Provisionsmodelle und Kapazitätsplanung.

Slowly Changing Dimensions: Historie als fachlicher Mehrwert

In der Datenmodellierung spricht man bei sich ändernden Stammdaten von „Slowly Changing Dimensions“, die im Data Warehouse geladen werden. Gemeint sind genau die Fälle, in denen sich Adressen, Regionen, Konditionen oder Produktzuordnungen ändern, aber fachlich relevant ist, wann welche Ausprägung gültig war.

Ein Data Warehouse kann diese Historie gezielt abbilden, zum Beispiel mit Gültig-von- und Gültig-bis-Feldern, die beim Laden in das Data Warehouse wichtig sind. Damit wird Historie zu einem fachlichen Mehrwert: Du kannst Entwicklungen im Kontext der jeweils gültigen Strukturen nachvollziehen – statt nur mit rückblickenden Annahmen zu arbeiten.

Kostenloses Erstgespräch vereinbaren

Schritt 3: Sind die benötigten historischen Daten in der operativen Datenbank überhaupt vorhanden?

Die dritte Prüffrage klingt trivial, sorgt in Projekten aber regelmäßig für Überraschungen: Sind die historischen Informationen, die Du analysieren willst, im Quellsystem wirklich gespeichert – oder siehst Du dort nur den aktuellen Stand?

Viele Unternehmen nutzen die Annahme, dass ERP oder CRM „alles“ wissen, weil sie im Alltag gut funktionieren, ohne die Rolle von Data Warehouses zu berücksichtigen. Erst bei genauerem Hinsehen zeigt sich, dass wichtige Zustände weder historisiert noch vollständig abgelegt wurden.

Der verbreitete Irrglaube: „Im System steht doch alles drin“

Ein klassisches Beispiel ist die Interpretation von Stammdaten. Auf den ersten Blick wirkt es so, als würden alle Preis- und Konditionsänderungen langfristig erhalten bleiben. In der Praxis werden jedoch oft nur aktuelle Konditionen gespeichert, während in einem Data Warehouse hingegen frühere Versionen erhalten bleiben sollten.

Ähnlich verhält es sich mit Adressen, Regionszuordnungen oder Maschinenparametern. Ohne explizite Historisierungslogik legt das System automatisch nur den neuesten Stand ab, was in einem Data Warehouse hingegen vermieden werden sollte. Für operative Prozesse reicht das, für analytische Fragestellungen meistens nicht, insbesondere wenn es um die Daten im Data Warehouse geht.

Wie Du prüfst, ob Historie im Quellsystem sauber vorliegt

Ein pragmatischer Weg ist, gemeinsam mit Fachbereichen einige typische Zeitfragen durchzuspielen: „Können wir den Auftragsbestand zum 31.12.2022 exakt rekonstruieren?“ oder „Können wir sagen, welche Region Kunde X im März 2021 zugeordnet war?“. Wenn die Antwort „Ja, mit vertretbarem Aufwand“ lautet, ist Historie im System zumindest teilweise vorhanden.

Zusätzlich lohnt sich ein Blick in die Datenbanktabellen oder Systemdokumentation: Gibt es explizite Historientabellen, Änderungsprotokolle oder Snapshot-Mechanismen? Oder werden Werte direkt überschrieben? Hier hilft Dir die IT, klare Antworten zu bekommen, insbesondere zu den strukturierten Daten in Deinem Data Warehouse.

Wenn Historie fachlich wichtig ist, aber technisch fehlt

Besonders kritisch wird es, wenn Fachbereiche historische Analysen benötigen, im System aber weder Snapshots noch Änderungsstände dokumentiert sind, wodurch fundierte Entscheidungen erschwert werden, insbesondere wenn unstrukturierte Daten involviert sind. Dann kannst Du vergangene Situationen nur noch näherungsweise rekonstruieren – und musst das im Reporting transparent machen, insbesondere wenn es um die Daten im Data Warehouse geht.

In solchen Fällen spricht vieles dafür, zukünftig ein Data Warehouse einzusetzen, das regelmäßig Zustände übernimmt und historisiert. Damit verhinderst Du, dass sich diese Lücken in den kommenden Jahren weiter vergrößern.

Konsequenzen für Reporting, Controlling und Revision

Für das Controlling bedeutet fehlende Historie, dass Vergleiche häufig auf „heutigen“ Strukturen basieren und vergangene Rahmenbedingungen nur schwer abbildbar sind, was die Business Intelligence einschränkt. Das kann zu Fehlinterpretationen führen, etwa bei der Bewertung von Standorten oder Kundenbeziehungen.

Aus Revisions- und Compliance-Sicht ist fehlende Nachvollziehbarkeit ebenfalls problematisch. Wenn Du nicht belegen kannst, auf welcher Datenbasis bestimmte Entscheidungen getroffen wurden, steigen Risiko und Aufwand bei Prüfungen, insbesondere wenn die Daten nicht im Data Warehouse konsolidiert sind. Ein sauber historisiertes Data Warehouse reduziert diesen Druck deutlich.

Schritt 4: Belasten Auswertungen operative Systeme und Datenbanken zu stark?

Die vierte Prüffrage betrifft die Stabilität im Alltag: Werden ERP, MES, CRM oder andere operative Systeme regelmäßig durch Auswertungen ausgebremst, während die Daten im Data Warehouse hingegen konsolidiert werden? Gibt es Zeitfenster, in denen keine Reports laufen dürfen, weil sonst Buchungsläufe oder Maschinenanbindungen ins Stocken geraten, insbesondere wenn das Data Warehouse Daten verarbeitet?

Wenn das der Fall ist, zahlst Du den Preis für fehlende Trennung zwischen operativer Verarbeitung und analytischer Last. Ein Data Warehouse kann hier als Puffer dienen und Analysen von den Produktivsystemen entkoppeln.

OLTP vs. OLAP: Warum man operative und analytische Last trennen sollte

Operative Systeme (OLTP) sind für viele kleine Transaktionen optimiert: Aufträge anlegen, Buchungen durchführen, Maschinensignale verarbeiten. Analytische Systeme (OLAP) hingegen sind auf große Leseabfragen ausgelegt, die viele Datensätze über längere Zeiträume aggregieren.

Wenn Du komplexe Analysen direkt auf OLTP-Systemen fährst, konkurrieren sie mit den Tagesgeschäftstransaktionen um Ressourcen. Das kann zu Verzögerungen, Sperren oder sogar Fehlermeldungen führen – besonders bei Monatsabschlüssen oder großen Ad-hoc-Auswertungen.

Typische Symptome überlasteter Systeme im Alltag

Wenn morgens um neun der Vertrieb seine Standardreports startet und sich gleichzeitig der Einkauf über langsame Reaktionszeiten im ERP beschwert, ist das ein klares Signal. Noch deutlicher wird es, wenn IT oder Fachbereiche Reportingfenster definieren müssen, in denen keine kritischen Prozesse laufen.

Ein weiteres Indiz: Import- und Exportjobs oder „Nachtläufe“, die immer länger dauern und irgendwann in den Tagesbetrieb hineinragen, während Daten innerhalb des Data Warehouse konsolidiert werden. Dann sind operative Systeme offensichtlich nicht mehr nur für Transaktionen zuständig, sondern tragen die volle Last der Analytik, die aus dem Data Warehouse geladen wird.

Risiken bei Direkt-Reporting auf ERP, CRM & Co.

Kurzfristig erscheint Direkt-Reporting auf produktiven Systemen attraktiv, weil Du schnell an Daten kommst, jedoch können unstrukturierte Daten die Analyse behindern. Langfristig wächst damit aber das Risiko, dass Abfragen versehentlich Tabellen sperren, Ressourcen blockieren oder ungewollt Geschäftslogik umgehen, insbesondere wenn große datenmengen aus verschiedenen quellen verarbeitet werden.

Hinzu kommt, dass Logiken in vielen einzelnen Reports verteilt werden: Berechnungen, Filter und Zuordnungen entstehen in BI-Tools oder Excel, statt zentral im Datenmodell gepflegt zu werden. Je mehr Reports existieren, desto schwieriger wird es, Konsistenz sicherzustellen.

Wie ein Data Warehouse operative Systeme entlastet

Ein Data Warehouse übernimmt Daten aus Deinen operativen Systemen in geplanten, kontrollierten Prozessen. Analysen laufen dann auf dieser Kopie, nicht mehr auf den produktiven Datenbanken. Das reduziert Lastspitzen und macht den Betrieb berechenbarer, indem es die Datenmengen effizient verwaltet.

Gleichzeitig kannst Du im Warehouse fachliche Logiken zentral abbilden: zum Beispiel die Berechnung von Umsatz, Marge oder OEE. BI-Tools greifen dann auf diese harmonisierten Strukturen zu, statt jede Berechnung selbst zu „erfinden“ und dabei unstrukturierte Daten zu ignorieren.

Die Entscheidungslogik auf einen Blick: Wann Unternehmen ein Data Warehouse brauchen

Checkliste: Ab wann ein Data Warehouse sinnvoll wird

Grenzfälle: Wenn Du Dich zwischen Excel, BI-Tool und Data Warehouse bewegst

Viele Unternehmen befinden sich in einem Zwischenzustand: Einige Reports laufen im BI-Tool, andere in Excel, manche direkt im ERP. Das kann für eine begrenzte Zeit funktionieren, solange die Anzahl der Berichte überschaubar bleibt und die Menschen dahinter stabil sind, besonders im Kontext von online analytical processing.

Spätestens wenn Schlüsselpersonen das Unternehmen verlassen, neue Standorte hinzukommen oder KI-Projekte starten sollen, rächt sich diese Struktur in Bezug auf die Skalierung der Datenmanagement-Prozesse. Dann ist es sinnvoll, aus dem Flickenteppich ein bewusst gestaltetes Datenfundament zu machen.

Kostenloses Erstgespräch vereinbaren

Wann Unternehmen noch kein Data Warehouse oder Data Lake brauchen

Ein Data Warehouse ist kein Dogma. Es gibt Situationen, in denen der Aufwand aktuell nicht gerechtfertigt ist, und es reicht, mit leichteren Lösungen zu arbeiten. Wichtig ist, diese Situationen bewusst zu erkennen – statt sie versehentlich zu verlängern.

Wenn Deine Datenlandschaft überschaubar und stabil ist, kannst Du Budget und Aufmerksamkeit in andere Themen stecken und Dich erst später an ein Warehouse wagen.

Typische Situationen, in denen ein Data Warehouse überdimensioniert ist

Wenn Du mit einem zentralen ERP arbeitest, keine weiteren Kernsysteme eingebunden sind und nur begrenzte historische Analysen nötig sind, ist ein Data Warehouse oft noch nicht zwingend. Gleiches gilt, wenn die Anzahl der regelmäßigen Reports gering ist und diese ohne großen manuellen Aufwand aus dem Data Warehouse geladen werden können.

Auch bei sehr frühen Unternehmensphasen, in denen sich Geschäftsmodell, Produkte und Prozesse noch stark ändern, kann ein schwergewichtiges Warehouse zu früh sein. Dort zählt erst einmal Geschwindigkeit und Marktzugang, insbesondere wenn es um die Nutzung von Data Lakes geht.

Was stattdessen ausreicht: Direkt-Reporting, einfache BI, Excel

In diesen Fällen kann ein gut strukturiertes Direkt-Reporting aus dem ERP kombiniert mit einem BI-Tool vollkommen ausreichen, um die Daten effektiv zu transformieren und zu analysieren. Wichtig ist, dass Du saubere Felddefinitionen, Berechtigungen und Reports pflegst und nicht jede Auswertung als einmalige Excel-Übung aufsetzt.

Excel bleibt dabei ein sinnvolles Werkzeug für Ad-hoc-Analysen oder Simulationen, sollte aber nicht zum primären Ort für Unternehmenskennzahlen werden. Sonst schleichen sich schnell unkontrollierte Formeln und Versionen ein.

Abgrenzung: Data Warehouse vs. Datenbank vs. Data Lake

In Diskussionen werden verschiedene Begriffe oft durcheinandergebracht. Eine klare Abgrenzung hilft Dir, die passende Lösung zu wählen, statt Buzzwords hinterherzulaufen. Wichtige Unterschiede betreffen Struktur, Zweck und Governance.

Die folgende Tabelle fasst zentrale Eigenschaften zusammen und zeigt, wann welches Konzept typischerweise zum Einsatz kommt.

Wie Du Dich auf ein späteres Data Warehouse vorbereiten kannst

Auch wenn Du heute noch kein Data Warehouse brauchst, kannst Du Weichen stellen. Dazu gehören klare KPI-Definitionen, saubere Stammdatenpflege und Dokumentation einzelner Reports. Diese Grundlagen helfen Dir später, schneller in eine zentrale Plattform zu wechseln.

Es lohnt sich außerdem, bereits jetzt auf Systeme zu setzen, die offene Schnittstellen und Exportmöglichkeiten bieten. So vermeidest Du später teure Sonderentwicklungen, wenn Du Daten in ein Warehouse oder eine Plattform wie die zentrale Datenbank geladen hast.

Vorteile eines Data Warehouse – und welche Nachteile Data Warehousing mit sich bringt

Ein Data Warehouse bringt klare Vorteile für Steuerung, Controlling und Fachbereiche – aber auch Aufwand und Verantwortung, da es als zentrales Repository dient. Eine ehrliche Abwägung hilft Dir, Erwartungen intern sauber zu steuern und den Nutzen realistisch einzuschätzen.

Gleichzeitig solltest Du die Kosten schlechter oder fehlender Datenbasis nicht unterschätzen: Verzögerte Monatsabschlüsse, Doppelarbeiten, Fehlentscheidungen und verpasste KI-Chancen schlagen sich ebenfalls in Aufwand und Risiko nieder.

Vorteile für Steuerung, Controlling und Fachbereiche

Das zentrale Versprechen eines Data Warehouse ist eine einheitliche, geprüfte Sicht auf Kennzahlen – unabhängig davon, ob sie im Finance, in der Produktion oder im Vertrieb genutzt werden. Das reduziert Abstimmungsrunden und schafft Vertrauen in die Zahlen.

Zusätzlich sinkt der manuelle Aufwand im Reporting, weil Daten automatisiert bereitgestellt werden. Fachbereiche können schneller auf Fragen reagieren und sich stärker auf Interpretation und Maßnahmen konzentrieren als auf Datenbeschaffung.

Rolle als Entscheidungsunterstützungssystem (DSS)

Ein modernes Data Warehouse bildet häufig die Basis für ein Entscheidungsunterstützungssystem, das strukturierte Daten effizient verarbeitet. Das bedeutet: Reports, Dashboards und analytische Anwendungen greifen auf dieselben Datenprodukte zu und liefern konsistente Antworten auf wiederkehrende Managementfragen.

Mit einer solchen Basis kannst Du Szenarioanalysen, Forecasts oder KI-gestützte Empfehlungen aufsetzen, die nicht auf isolierten Datentöpfen basieren, sondern aus einem konsolidierten Data Warehouse stammen. Entscheidungen erhalten damit eine transparentere und belastbarere Grundlage.

Typische Nachteile, Kosten und Herausforderungen

Ein Data Warehouse ist kein Selbstläufer. Es kostet Zeit, Budget und Aufmerksamkeit, insbesondere in der Konzeptionsphase und beim Aufbau der ersten Modelle. Ohne klare Zielbilder besteht die Gefahr, eine technische Lösung ohne echten Business-Nutzen zu bauen.

Hinzu kommen organisatorische Fragen: Wer verantwortet welche Datenbereiche? Wie werden Berechtigungen in Bezug auf Daten aus verschiedenen Quellen umgesetzt? Wie werden Änderungen am Datenmodell gesteuert? Diese Themen lassen sich lösen, müssen aber von Anfang an mitgedacht werden, insbesondere im Hinblick auf das Schema der Datenintegration.

Wie Du Aufwand und Nutzen realistisch einschätzt

Statt mit pauschalen ROI-Zahlen zu arbeiten, lohnt sich ein Unternehmensspezifischer Blick auf die Vorteile eines Data Warehouse. Welche Zeit investierst Du heute in Datenzusammenführung und Fehlerkorrektur? Wie oft werden Reports korrigiert oder neu aufgelegt? Welche Risiken entstehen durch unvollständige oder widersprüchliche Daten?

Die folgende Tabelle hilft Dir, Aufwand und Nutzen strukturiert zu betrachten und als Basis für interne Entscheidungen zu nutzen.

Kostenloses Erstgespräch vereinbaren

Was moderne Data Warehouse Tools und Cloud-Lösungen im Mittelstand leisten sollten

Wenn Du Dich für ein Data Warehouse entscheidest, sollte es zu Deinen Ressourcen, Systemen und Zielen passen. Ein überdimensioniertes Setup ist genauso problematisch wie eine Lösung, die nach kurzer Zeit an Grenzen stößt.

Für mittelständische Unternehmen stehen vor allem drei Fähigkeiten im Vordergrund: einfache Integration verschiedener Quellen, zuverlässige Historisierung und praxistaugliche Governance für Berechtigungen und Änderungen.

Wichtige Funktionen: Integration, Historisierung, Governance

Technisch bedeutet das: Das System muss in der Lage sein, Daten aus ERP, MES, CRM, Webshop, Dateien und weiteren Quellen automatisiert einzulesen. Es sollte Historienmechanismen unterstützen und klar nachvollziehbar machen, welche Regeln für Berechnungen und Zuordnungen gelten.

Governance heißt in diesem Kontext nicht Bürokratie, sondern Nachvollziehbarkeit: Wer hat wann welche Logik geändert, insbesondere in Bezug auf die Datenmengen im Data Lake? Welche KPIs sind wie definiert? Welche Nutzer dürfen welche Daten sehen? Ein modernes Warehouse unterstützt Dich dabei, diese Fragen jederzeit beantworten zu können.

Architektur: Vom Quellsystem über ETL/ELT bis zum Reporting

Klassisch betrachtet besteht eine Data-Warehouse-Architektur aus drei Schichten: den Quellsystemen, der Integrations- und Transformationsschicht (ETL/ELT) und der Präsentationsschicht für BI/Reports. Moderne Plattformen kombinieren diese Stufen teilweise, behalten die Trennung fachlich aber bei.

Wichtig ist, dass Datenflüsse automatisiert, überwacht und dokumentiert werden. So stellst Du sicher, dass tägliche Ladungen, Qualitätsprüfungen und Modellanpassungen nicht jedes Mal ein Projekt werden, sondern in einen stabilen Betriebsprozess übergehen.

On-Premises, Cloud oder Hybrid? Bereitstellungsmodelle im Vergleich

Die Frage, ob Dein Warehouse in der eigenen Infrastruktur oder in der Cloud laufen soll, ist eine zusätzliche Entscheidungsebene für die gesamte Unternehmen. Sie hängt von Datenschutzanforderungen, vorhandener IT, gewünschter Skalierbarkeit und der Fähigkeit ab, Daten aus verschiedenen Quellen zu integrieren, die im Data Warehouse gespeichert werden.

Die wichtigsten Unterschiede lassen sich in einer kompakten Gegenüberstellung betrachten, ähnlich wie im Artikel On-Premise vs. Cloud.

Kriterien zur Auswahl einer Data-Warehouse-Lösung oder Plattform

Bei der Auswahl solltest Du weniger auf Funktionslisten, sondern stärker auf Arbeitsweise, Betrieb und die Möglichkeit zur Durchführung komplexer Abfragen achten. Wie einfach ist die Anbindung Deiner konkreten Systeme an die zentrale Datenbank? Wie gut lassen sich Änderungen am Datenmodell in der Architektur eines Data Warehouse durchführen, insbesondere auf der obersten Ebene? Wie transparent ist das Monitoring, wenn es auf Datenmengen aus einem Data Lake basiert, die möglicherweise im Data Warehouse gespeichert sind?

Für den Mittelstand sind zudem Low-Code-Fähigkeiten und die Offenheit gegenüber bestehenden BI-Frontends relevant. Idealerweise musst Du Dein Reporting-Tool nicht austauschen, sondern bekommst darunter eine stabilere Datenbasis.

bimanu Cloud als Datenbasis: Wenn ein Cloud Data Warehouse sinnvoll ist

Wenn Deine vier Prüffragen eher in Richtung „Ja“ tendieren, brauchst Du eine Plattform, die Daten aus mehreren Systemen integrieren, historisieren und für Reporting, BI und KI bereitstellen kann – ohne dass jedes Detail ein IT-Projekt wird.

Genau hier setzt die bimanu Cloud an: als vollständig automatisierte Datenplattform, die den Data-Warehouse-Gedanken auf die Bedürfnisse mittelständischer Unternehmen überträgt.

1. Zentrale Integrations- und Modellierungsschicht

Die bimanu Cloud bindet ERP, MES, CRM, Webshop und weitere Systeme über vorgefertigte Konnektoren an und führt sie in einer zentralen Datenbasis zusammen. Die Modellierung erfolgt per Low-Code, sodass fachliche und technische Sicht eng verzahnt bleiben, während das Data Warehouse bietet eine flexible Lösung.

Anstatt Logiken in dutzenden Reports zu verteilen, definierst Du Berechnungen und Strukturen einmal zentral. Das reduziert Inkonsistenzen und erleichtert Wartung und Erweiterung, etwa bei neuen Standorten oder Produkten, indem ein Data Warehouse hingegen eine einheitliche Datenbasis bereitstellt.

2. Historisierung, Versionierung und Data Governance im Alltag

Historienlogik wird in der bimanu Cloud von Beginn an mitgedacht, während das Data Warehouse geladen wird. Änderungen an Stammdaten, Strukturen oder Kennzahlen werden nachvollziehbar versioniert, was in der Architektur eines Data Warehouse von großer Bedeutung ist. Das erleichtert historische Auswertungen und unterstützt Revision und Compliance.

Gleichzeitig kannst Du Rollen und Berechtigungen granular steuern. So sehen Fachbereiche genau die Daten, die sie benötigen – ohne dass die IT jede Abfrage manuell freigeben muss.

3. Entlastung operativer Systeme durch vorgelagerte Datenplattform

Daten werden in geplanten ETL-Prozessen aus den Quellsystemen in das Data Warehouse geladen. Analysen und Reports laufen dann auf der bimanu Cloud, nicht mehr direkt auf ERP-, MES- oder CRM-Datenbanken. Das reduziert Systemlast und stabilisiert das Tagesgeschäft.

Gleichzeitig bleibt die IT entlastet, weil Monitoring, Qualitätssicherung und Betrieb in der Plattform integriert sind, was Data Warehouses bieten. Du musst kein separates Orchestrierungs-Ökosystem aufbauen, um Datenflüsse zuverlässig zu steuern, wenn ein Data Warehouse dient.

4. Offenheit gegenüber BI-Frontends (Power BI, Tableau, Looker, …)

Die bimanu Cloud versteht sich als Datenbasis, nicht als Ersatz für BI-Frontends. Dashboards und Analysen können weiterhin in Tools wie Power BI, Qlik oder Tableau umgesetzt werden – nur eben auf einer konsistenten, harmonisierten Datenbasis, die im Data Warehouse geladen ist.

So kannst Du bestehende Investitionen schützen und gleichzeitig die Qualität der zugrunde liegenden Daten deutlich erhöhen. Fachbereiche arbeiten mit bekannten Oberflächen, während die Komplexität im Hintergrund reduziert wird, was den Aufbau eines Data Warehouse erleichtert.

5. Low-Code-Ansatz und Templates speziell für den Mittelstand

Viele mittelständische Unternehmen verfügen nicht über große Data-Engineering-Teams, was die Implementierung von Data Warehouses erschwert. Der Low-Code-Ansatz der bimanu Cloud adressiert genau das: Fachliche Regeln, Mappings und Datenmodelle können ohne tiefes Programmierwissen gepflegt werden, was die Erstellung von Data Warehouses vereinfacht.

Vorgefertigte Muster, zum Beispiel für Data-Vault-Strukturen oder typische ERP-Modelle, beschleunigen den Aufbau von Data Marts. Gleichzeitig bleibt die Plattform flexibel genug, um branchenspezifische Anforderungen aus Produktion, Handel oder Maschinenbau abzubilden, was die Verwendung eines Data Warehouses erleichtert.

6. Brücke von Reporting zu Predictive Analytics und KI-Agenten

Eine zentrale, historisierte Datenbasis ist nicht nur für klassisches Reporting relevant, sondern auch für spätere KI-Anwendungsfälle. Ob Churn-Prognosen, Predictive Maintenance oder KI-Agenten im Controlling – sie alle brauchen verlässliche, gut dokumentierte Daten.

Mit der bimanu Cloud schaffst Du diese Grundlage für Datenmanagement und Business Intelligence, ohne heute schon jedes KI-Szenario im Detail zu kennen, während gleichzeitig unstrukturierte Daten berücksichtigt werden. Du baust ein Datenfundament, das BI, Automatisierung und KI schrittweise auf derselben Plattform ermöglicht.

Kostenloses Erstgespräch vereinbaren

Praxisbeispiele: Wie Unternehmen Data Warehouses, operative Systeme und historische Daten in der Realität erleben

Die vier Prüffragen sind abstrakt, werden im Alltag aber sehr konkret, insbesondere im Kontext der Einrichtung eines Data Warehouse. Drei vereinfachte Szenarien zeigen, wie sie sich in Produktion, Controlling und Vertrieb bemerkbar machen – und wann ein Data Warehouse den Unterschied macht, indem es Daten aus verschiedenen Quellen konsolidiert.

Die Beispiele sind bewusst qualitativ formuliert, weil harte Kennzahlen stark vom Einzelfall abhängen. Entscheidend ist, dass Du Dich wiederfindest und den jeweiligen Reifegrad im zentralen Repository einordnen kannst.

Produktion: Predictive Maintenance mit Maschinen- und ERP-Daten

Ein Fertiger möchte Ausfälle frühzeitig erkennen und Wartungsfenster optimieren, indem er auf Daten zugreift, die in einem Data Warehouse gespeichert sind. Maschinendaten kommen aus dem MES, Auftrags- und Planungsdaten aus dem ERP, während Wartungsinformationen aus einem separaten Instandhaltungstool konsolidiert werden.

Ohne zentrales Datenmodell lassen sich Muster nur schwer erkennen, weil Zeitstempel, IDs und Strukturen nicht sauber aufeinander abgestimmt sind, was die Analyse von Rohdaten erschwert. Ein Data Warehouse, das diese Quellen integriert und historisiert, bildet die Grundlage für stabile Prognosemodelle auf der mittleren Ebene.

Controlling: Deckungsbeiträge und Preisentwicklungen über Jahre hinweg

Das Controlling möchte Deckungsbeiträge über mehrere Jahre vergleichen, inklusive Effekten aus Preisänderungen, Rohstoffkosten und den Vorteilen eines Data Warehouse. Die relevanten Daten liegen in ERP, FiBu und diversen Excel-Tabellen.

Ohne historisierte Preis- und Konditionsdaten bleibt unklar, welche Effekte auf Mengenänderungen und welche auf Preisgestaltung zurückgehen. Ein Data Warehouse mit klar modellierten Fakten- und Dimensionstabellen schafft hier Transparenz.

Vertrieb: Kundenverhalten über CRM, Webshop und Service hinweg verstehen

Der Vertrieb möchte verstehen, wie sich Kunden vom Erstkontakt über den Webshop bis zum After-Sales-Service verhalten. Daten liegen im CRM, im Shop, im Ticketsystem und teilweise in Marketing-Tools, was die Notwendigkeit eines umfassenden Data Warehousing unterstreicht.

Ein zentrales Datenmodell („Customer 360“) im Warehouse ermöglicht es, diese Berührungspunkte zu verbinden, Zielgruppen zu segmentieren und Potenziale gezielt anzusprechen, um fundierte Entscheidungen zu treffen. Auch KI-gestützte Empfehlungen für Upselling oder Churn-Prevention bauen darauf auf.

Data Warehouse, Business Intelligence, Cloud und KI: Warum die Datenbasis jetzt wichtig ist

BI- und KI-Projekte scheitern selten an der Wahl des Tools, sondern fast immer an der Datenbasis. Wenn Historie fehlt, Definitionen unklar sind oder Daten in Silos liegen, hilft auch der beste Algorithmus nicht weiter.

Gleichzeitig steigt der Druck: Laut BARC bleiben Datenqualität und Governance Top-Prioritäten, während die Nutzung von Business Intelligence und KI-Funktionen zunimmt. Ein sauberes Data Warehouse adressiert genau diese Grundlagen und schafft damit Raum für weitere Schritte in der Datenanalyse und Business Intelligence.

Warum BI- und KI-Projekte ohne saubere Datenbasis scheitern

Ohne zentrale, historisierte Datenbasis werden Auswertungen zu Einzellösungen, die in einem Data Mart gespeichert sind. Jedes Projekt baut sich seine eigene Sicht und generiert dadurch neue Inkonsistenzen, die durch ein zentrales Repository in einem Data Warehouse hingegen vermieden werden können. Das ist teuer, langsam und schwer zu warten.

KI-Modelle verstärken dieses Problem: Sie lernen aus historischen Daten, die im Data Warehouse konsolidiert sind. Wenn diese lückenhaft, widersprüchlich oder schlecht dokumentiert sind, entstehen Modelle, denen Du nicht vertrauen kannst – oder die in der Praxis nicht akzeptiert werden.

Welche Anforderungen KI-Agenten an ein Data Warehouse stellen

KI-Agenten, die Fragen zu Kennzahlen beantworten oder Handlungsoptionen vorschlagen sollen, brauchen eine klare semantische Schicht. Sie müssen wissen, was „Umsatz“, „Marge“ oder „Liefertermin“ im jeweiligen Kontext bedeutet.

Ein Data Warehouse mit gut dokumentierten Datenmodellen und einheitlichen KPI-Definitionen ist dafür eine ideale Basis. Ohne diese Struktur steigt das Risiko, dass KI-Agenten falsche Schlüsse ziehen oder irreführende Antworten liefern.

Wie Du Reporting, BI und KI schrittweise auf derselben Plattform aufbaust

Ein pragmatischer Weg ist, mit einem klar definierten Reporting-Use-Case zu starten, zum Beispiel Monatsabschluss oder Produktionscontrolling in einem Data Mart. Darauf baust Du weitere Datenprodukte und Self-Service-Analysen auf, die im Data Warehouse konsolidierte Daten nutzen.

Wenn diese Basis stabil läuft, kannst Du KI-Use-Cases ergänzen: Prognosen, Anomalieerkennung, KI-Assistenten im Controlling. Alle greifen auf dieselbe Plattform zurück, anstatt parallele Datenwelten zu schaffen, was die Skalierung der Datenverarbeitung erschwert.

Nächste Schritte: So gehen Unternehmen ihre Data-Warehouse-Entscheidung strukturiert an

Ob ein Data Warehouse für Dich jetzt sinnvoll ist, lässt sich nicht per Bauchgefühl entscheiden. Die vier Prüffragen geben Dir einen Rahmen, aber der nächste Schritt ist, sie mit Deiner konkreten Situation zu füllen, um die Daten sinnvoll zu transformieren.

Ziel ist kein perfekter Masterplan, sondern eine realistische Roadmap für die nächsten 6–18 Monate: Was brauchst Du wirklich, um Daten effizient zu transformieren, was kannst Du pragmatisch umsetzen, und wo brauchst Du Unterstützung?

Interner Quick-Check mit den vier Prüffragen

Starte mit einem kurzen Workshop mit IT, Controlling und einem operativen Bereich (z. B. Produktion oder Vertrieb). Geh die vier Prüffragen durch und sammle konkrete Beispiele, wo heute Probleme auftreten: manuelle Exporte, fehlende Historie, Performance-Einbrüche.

Dokumentiere die wichtigsten Kennzahlen, für die es regelmäßig Diskussionen gibt, und notiere, aus welchen Systemen sie stammen. Das schafft eine erste, fundierte Basis für die weitere Entscheidungsfindung, wenn die Daten im Data Warehouse konsolidiert sind und die untere Ebene der Datenanalyse unterstützt wird.

Workshops mit Fachbereichen: Anforderungen systematisch erfassen

Im zweiten Schritt lohnt sich eine etwas tiefere Aufnahme der Anforderungen in den wichtigsten Fachbereichen. Welche Fragen sollen dauerhaft beantwortet werden? Welche Analysen sind heute zu aufwendig oder kaum möglich, weil die Daten nicht effizient extrahiert und konsolidiert werden können?

Diese Anforderungen müssen nicht in technische Spezifikationen übersetzt werden, da das Data Warehousing bietet, um die Integration zu erleichtern. Es reicht, fachliche Fragen klar zu formulieren und den Bezug zu Systemen, Datenquellen und dem zugrunde liegenden Schema herzustellen. Daraus lässt sich ein initiales Datenmodell ableiten.

Proof of Concept: Vom ersten Use Case zur skalierbaren Plattform

Bevor Du ein vollständiges Data Warehouse aufbaust, ist ein Proof of Concept sinnvoll. Wähle einen klar abgegrenzten Use Case mit hohem Nutzen, zum Beispiel Monatsreporting oder OEE-Analyse für ein Werk, und setze ihn auf einer Plattform wie der bimanu Cloud um.

So erkennst Du schnell, ob der Ansatz zu Deinen Prozessen und Ressourcen passt, besonders wenn Du auf die mittlere Ebene der Daten zugreifen möchtest. Gleichzeitig schaffst Du interne Referenzen und kannst auf Basis realer Erfahrungen entscheiden, wie weit Du die Plattform ausrollen möchtest, insbesondere in Bezug auf die Leistung und Skalierbarkeit.

Jetzt unverbindlich Kontakt aufnehmen

Kontaktiere uns jetzt und vereinbare Dein kostenloses Erstgespräch mit einem unserer Experten. 

Kostenlose Erstberatung

Trustpilot

Data Warehouse – Häufige Fragen und Antworten zu Data Warehousing, Tools und Datenbanken

Was ist ein Data Warehouse in einfachen Worten – und wie unterscheidet es sich von einer normalen Datenbank?

Ein Data Warehouse ist eine zentrale, historisierte Datenbasis für Analysen und Berichte, die sowohl strukturierte als auch unstrukturierte Daten berücksichtigt, um fundierte Entscheidungen zu treffen. Im Unterschied zu einer operativen Datenbank, die Transaktionen im Tagesgeschäft verarbeitet, speichert ein Warehouse Daten aus mehreren Systemen langfristig, strukturiert und für Auswertungen optimiert.

Kann ein Data Warehouse wirklich bessere Entscheidungen ermöglichen – und wenn ja, wie?

Ja, weil es dafür sorgt, dass alle Fachbereiche mit denselben geprüften Kennzahlen arbeiten und somit fundierte Entscheidungen treffen können. Anstatt Zahlen aus verschiedenen Systemen manuell zu kombinieren, bekommst Du konsistente Reports und kannst Entwicklungen im Zeitverlauf nachvollziehen – das reduziert Missverständnisse und erhöht die Qualität Deiner Entscheidungen.

Welche Nachteile und Risiken hat ein Data Warehouse für mittelständische Unternehmen?

Die wichtigsten Risiken liegen in zu großen, schlecht fokussierten Projekten und in fehlender Governance, insbesondere wenn es um die Implementierung von Business Intelligence geht. Wenn Ziele unklar sind oder niemand für Datenqualität verantwortlich ist, kann ein Warehouse schnell zum komplexen IT-System ohne echten Mehrwert werden – deshalb ist ein iteratives Vorgehen mit klaren Use Cases entscheidend.

Was kostet ein Data Warehouse – von der Einführung bis zum laufenden Betrieb?

Die Kosten hängen stark von Umfang, Technologie und internen Ressourcen ab, insbesondere bei der Skalierung von Data Warehouses. Neben Lizenz- oder Plattformkosten musst Du mit Aufwänden für Konzeption, Implementierung und laufende Anpassungen rechnen; im Gegenzug sinken Reporting-Aufwände und Fehlerkosten, was Du idealerweise vorab mit eigenen Kennzahlen bewertest.

Ab welcher Unternehmensgröße lohnt sich ein Data Warehouse – und ab wann ist es Pflicht?

Die relevante Größe ist weniger die Mitarbeiterzahl als die Komplexität Deiner Systemlandschaft und Deines Reportings. Ab etwa drei bis fünf Kernsystemen, regelmäßigem Management-Reporting und hohem Historienbedarf wird ein Data Warehouse meist wirtschaftlich sinnvoll, in stark regulierten Branchen oft faktisch unverzichtbar.

Wie gehe ich vor, wenn meine historischen Daten im Quellsystem nicht mehr vorhanden sind?

In diesem Fall kannst Du vergangene Zustände nur noch näherungsweise rekonstruieren und solltest diese Einschränkung im Reporting klar kennzeichnen. Gleichzeitig lohnt es sich, möglichst schnell ein Data Warehouse oder eine Datenplattform aufzusetzen, die künftige Zustände regelmäßig übernimmt und historisiert.

Reicht ein BI-Tool wie Power BI aus – oder brauche ich zusätzlich ein Data Warehouse?

Ein BI-Tool reicht, solange Du wenige Quellen hast, wenig Historie brauchst und Deine Systeme durch Analysen nicht belastet werden. Sobald mehrere Systeme, Historienanalysen und Performance-Themen ins Spiel kommen, brauchst Du zusätzlich eine zentrale Datenbasis – das kann ein klassisches Data Warehouse oder eine Plattform wie die bimanu Cloud sein.

Wie wirkt sich die Wahl zwischen On-Premises und Cloud auf mein Data Warehouse aus?

On-Premises gibt Dir maximale Kontrolle, erfordert aber mehr internes Know-how und Investitionen in Hardware und Betrieb, während ein Data Warehouse hingegen oft kosteneffizienter sein kann. Cloud-Varianten starten schneller, skalieren leichter und entlasten die interne IT, erfordern aber klare Regelungen zu Datenschutz, Hosting-Standort und Zugriffsrechten, insbesondere bei der Nutzung von Daten in einem zentralen Datenspeicher.

Wie lange dauert es, bis ein Data-Warehouse-Projekt im Mittelstand produktiv genutzt werden kann?

Für einen fokussierten ersten Use Case – zum Beispiel Monatsreporting auf Basis von zwei bis drei Systemen – sind Zeiträume von sechs bis zwölf Wochen realistisch, wenn Anforderungen klar sind und die Systemanbindung möglich ist. Der Ausbau zur unternehmensweiten Plattform erfolgt dann schrittweise in weiteren Ausbaustufen.

Kann ich mit einer Plattform wie bimanu bestehende BI-Lösungen weiterverwenden?

Ja, genau das ist eines der Ziele der bimanu Cloud. Sie stellt die zentrale Datenbasis bereit, auf die Deine bestehenden BI-Tools wie Power BI, Qlik oder Tableau zugreifen können, sodass Du Visualisierungen und Dashboards weiter nutzt, aber auf einer konsistenteren und belastbareren Datenbasis arbeitest.