Kurz gesagt: Ein Data Warehouse ist eine zentrale Analysedatenbank, in der Daten aus ERP, CRM, Außendienst-App und Excel-Dateien bereinigt, mit einheitlichen Definitionen versehen und mitsamt ihrer Historie gespeichert werden. Berichte lesen daraus statt aus der laufenden ERP-Datenbank, und alle erhalten für dieselbe Kennzahl dasselbe Ergebnis. Für KMU ist der erste Schritt kein Großprojekt, sondern ein Modell, das mit wenigen wichtigen Fragen beginnt und schrittweise wächst.
In vielen Unternehmen bringt der Vertriebsleiter eine Umsatzzahl in die Besprechung und die Buchhaltung eine andere. Keine ist falsch: Die eine zieht Retouren ab, die andere nicht. Und weil die Berichte direkt auf der ERP-Datenbank laufen, wird das System zum Monatsende langsam. Ein Data Warehouse löst beide Probleme zugleich.
Inhalt
- Was ist ein Data Warehouse?
- Unterschied zur ERP-Datenbank
- Wann lohnt es sich?
- Aufbau in 6 Schritten
- ETL oder ELT?
- Häufige Fehler
- Fazit und Checkliste
Was ist ein Data Warehouse und wofür braucht man es?
Ein Data Warehouse ist eine zentrale, auf Lesezugriffe ausgelegte Datenbank, in der Daten aus den verschiedenen Systemen eines Unternehmens für die Analyse modelliert, bereinigt und zusammen mit ihrer Veränderung über die Zeit gespeichert werden. Es dient nicht der Erfassung von Buchungen, sondern der Beantwortung von Fragen wie: „In welcher Region und Produktgruppe ist die Marge gegenüber dem Vorjahreszeitraum gesunken?“
Laut dem Microsoft-Leitfaden zur analytischen Onlineverarbeitung (OLAP) sind Datenbanken für das Tagesgeschäft auf einzelne Datensatzeinträge optimiert und nicht für Analysen gedacht. Analysedatenbanken sind dagegen auf viele Lese- und wenige Schreibvorgänge ausgelegt, für die Analyse modelliert und bereinigt und bewahren oft die Historie für Zeitreihenanalysen. Das Data Warehouse ist das Zentrum dieser zweiten Welt.
Data Warehouse und ERP-Datenbank im Vergleich
| Merkmal | ERP-Datenbank (OLTP) | Data Warehouse |
|---|---|---|
| Hauptaufgabe | Rechnungen, Aufträge und Lagerbewegungen erfassen | Fragen beantworten, Trends zeigen |
| Last | Viele kleine Lese- und Schreibvorgänge | Wenige Schreib-, große und komplexe Lesevorgänge |
| Datenmodell | Normalisiert, viele Tabellen | Sternschema aus Fakten- und Dimensionstabellen |
| Quellen | Meist eine Anwendung | ERP, CRM, Außendienst und Excel zusammen |
| Historie | Oft nur der aktuelle Stand | Veränderungen über die Zeit |
| Aktualität | Echtzeit | In geplanten Abständen geladen, etwa nachts |
Die letzte Zeile ist wichtig: Derselbe Leitfaden weist darauf hin, dass Analysespeicher seltener aktualisiert werden als Transaktionssysteme und eher strategischen Entscheidungen dienen als sofortigen Reaktionen. Die minutengenaue Bestandsführung bleibt Aufgabe des ERP.
Wann brauchen KMU ein Data Warehouse?
Nicht jedes Unternehmen braucht eines. Wer aus einem einzigen ERP einige Standardberichte zieht, kommt mit einem gut aufgebauten Power-BI-Modell oft aus. Treffen zwei oder mehr der folgenden Punkte zu, sollten Sie ein Data Warehouse ernsthaft prüfen:
- Berichte bremsen das ERP: Anwender klagen über hängende Masken, während Monatsberichte laufen.
- Mehrere Quellen werden von Hand verknüpft: ERP-, CRM-, Onlineshop- und Außendienstdaten werden jeden Monat in Excel abgeglichen.
- Dieselbe Kennzahl liefert verschiedene Werte: Abteilungen definieren Umsatz, Rohertrag oder aktive Kunden unterschiedlich.
- Historie geht verloren: Ändern sich Region oder Betreuer eines Kunden, ändern sich auch alte Berichte.
- Ein Systemwechsel steht an: Bei einem ERP-Upgrade oder einer Migration müssen frühere Jahre für Analysen verfügbar bleiben.
Data Warehouse in 6 Schritten aufbauen
1. Geschäftsfragen und Kennzahldefinitionen festhalten
Schreiben Sie vor jeder Technologieentscheidung 10 bis 15 wichtige Fragen und die Kennzahlen auf, die sie beantworten. Ist „Nettoumsatz“ der Betrag nach Retouren und Rabatten? Buchhaltung und Vertrieb sollten diese Definitionen gemeinsam freigeben; ein großer Teil des Nutzens entsteht durch dieses gemeinsame Vokabular.
2. Quellen und Verantwortliche auflisten
Notieren Sie für jede Frage, in welchem System die Daten liegen, wer verantwortlich ist und wie oft sie aktualisiert werden müssen. ERP-Tabellen, CRM, Außendienst-App und manuell gepflegte Excel-Dateien gehören auf diese Liste. Kennzahlen mit unklarer Quelle kommen nicht in die erste Version.
3. Das Modell als Sternschema entwerfen
Messbare Ereignisse wie Verkäufe, Zahlungseingänge oder Lagerbewegungen gehören in Faktentabellen, Zusammenhänge wie Kunde, Artikel, Datum und Betreuer in Dimensionstabellen. Legen Sie die Granularität jeder Faktentabelle (zum Beispiel eine Rechnungsposition) von Anfang an fest. Die Modellierungsregeln beschreiben wir in unserem Beitrag Sternschema in Power BI.
4. Den Ladeprozess (ETL) aufbauen
Die Daten werden aus den Quellen extrahiert, in Staging-Tabellen bereinigt, von Dubletten befreit, gegen Regeln geprüft und ins Data Warehouse geladen. Wechseln Sie nach der ersten Volllast wenn möglich zu inkrementellen Ladevorgängen, die nur geänderte Datensätze übernehmen, und planen Sie diese außerhalb der Arbeitszeit.
5. Berichtsebene und Berechtigungen vorbereiten
Das Berichtswerkzeug sollte nicht direkt auf Tabellen zugreifen, sondern auf ein semantisches Modell mit verständlichen Feldnamen, Beziehungen und Berechnungen. Wer welche Region sehen darf, legen Sie mit der Sicherheit auf Zeilenebene (RLS) fest. Wenn Sie Logo einsetzen, beschreibt unser Beitrag Power-BI-Berichte aus Logo-Daten die Anbindung.
6. Betreiben, überwachen und dokumentieren
Gleichen Sie nach jedem Ladevorgang Data Warehouse und Quellsystem über Datensatzanzahl und Summen ab. Legen Sie fest, wer bei einem Ladefehler benachrichtigt wird, nehmen Sie das Data Warehouse in den Sicherungsplan auf und halten Sie die Kennzahldefinitionen aktuell.
ETL oder ELT für das Data Warehouse?
Der ETL-Leitfaden von Microsoft unterscheidet die beiden Ansätze so: Bei ETL werden die Daten in einer separaten Engine umgewandelt, bevor sie ins Ziel geladen werden; bei ELT werden die Rohdaten zuerst geladen und mit der Rechenleistung des Zielspeichers selbst umgewandelt.
- ETL passt eher, wenn das Zielsystem wenig Ressourcen hat, die Geschäftsregeln komplex sind oder vor dem Laden eine prüfbare Staging-Schicht gewünscht ist. In lokalen SQL-Server-Umgebungen sind dafür die SQL Server Integration Services (SSIS) ein verbreitetes Werkzeug.
- ELT passt eher, wenn das Ziel ein modernes, bei Bedarf skalierendes Data Warehouse oder Lakehouse ist und Sie Rohdaten für spätere Analysen aufbewahren möchten. Microsoft Fabric ist ein Beispiel für eine solche Plattform.
In KMU beginnt die erste Version oft als eigene Datenbank auf dem vorhandenen SQL Server. Prüfen Sie zuerst Lizenzierung und Hardwarekapazität und bewerten Sie Cloud-Optionen, wenn der Bedarf wächst; das ist der kontrolliertere Weg.
Häufige Fehler bei Data-Warehouse-Projekten
- Alles auf einmal übernehmen: Wer jede Tabelle kopiert, baut eine große Struktur, die niemand nutzt. Beginnen Sie mit einem Fachbereich.
- Definitionen nicht aufschreiben: Ohne gemeinsames Vokabular liefert das Data Warehouse nur schneller unterschiedliche Zahlen.
- Qualitätsprüfungen auslassen: Ein Data Warehouse, das nie mit den Quellen abgeglichen wird, verliert beim ersten Widerspruch das Vertrauen.
- Historie nicht bedenken: Wird nicht vorab entschieden, wie Änderungen an Kunden und Betreuern gespeichert werden, ändern sich alte Berichte unbemerkt.
- Berichte weiter auf das ERP richten: Sobald das Data Warehouse steht, sollten Managementberichte daraus lesen.
Fazit und Checkliste für das Data Warehouse
- Gibt es einen wiederkehrenden Berichtsbedarf, der mindestens zwei Quellen verbindet?
- Sind die wichtigsten Kennzahldefinitionen schriftlich festgehalten und freigegeben?
- Hat jede Quelle einen Verantwortlichen und einen Aktualisierungsrhythmus?
- Ist das Modell mit Fakten- und Dimensionstabellen entworfen?
- Läuft der Abgleich mit den Quellen nach jedem Ladevorgang automatisch?
- Ist der Berichtszugriff rollenbasiert geregelt und wird das Data Warehouse gesichert?
Kurz: Ein Data Warehouse verbindet die Unternehmensdaten mit einer einzigen verlässlichen Version der Wahrheit und entlastet das ERP von der Berichtslast. Wir bei ÇAP Teknoloji klären mit Ihnen, ob Sie ein Data Warehouse oder ein gut aufgebautes Berichtsmodell brauchen, und setzen es im Rahmen unserer BI-Beratung Schritt für Schritt um, beginnend mit einem Fachbereich. Nehmen Sie Kontakt auf.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Data Warehouse und Datenbank?
Transaktionsdatenbanken wie die des ERP sind auf einzelne Datensatzeinträge ausgelegt: Rechnungen, Aufträge und Lagerbewegungen. Ein Data Warehouse modelliert, bereinigt und speichert Daten aus mehreren Quellen samt Historie für die Analyse. Das eine führt das Tagesgeschäft, das andere beantwortet Fragen dazu.
Braucht ein kleines Unternehmen ein Data Warehouse?
Nicht immer. Wer aus einem einzigen ERP einige Standardberichte zieht, kommt oft mit einem gut aufgebauten Berichtsmodell aus. Ein Data Warehouse lohnt sich, wenn regelmäßig mehrere Quellen von Hand verknüpft werden, dieselbe Kennzahl je Abteilung anders ausfällt oder Berichte das ERP bremsen.
Wie oft wird ein Data Warehouse aktualisiert?
Das richtet sich nach dem Bedarf; in KMU ist ein Ladevorgang pro Tag außerhalb der Arbeitszeit üblich. Für Kennzahlen, die tagsüber aktueller sein müssen, lassen sich zusätzliche Ladevorgänge planen. Echtzeit-Bestände und Auftragsverfolgung bleiben im ERP.
Warum ein Data Warehouse, wenn wir schon Power BI nutzen?
Power BI ist ein Werkzeug für Berichte und Visualisierung; das Data Warehouse ist die bereinigte, einheitlich definierte Datenschicht mit Historie, aus der diese Berichte gespeist werden. Mit mehr Quellen und Datenvolumen werden Berichte konsistenter und leichter zu pflegen, wenn die Umwandlung im Data Warehouse statt in Power BI stattfindet.
