Data Warehouse für den Handel – Architektur aus der Praxis

Warum die Warenwirtschaft allein nicht reicht

Eine Warenwirtschaft ist für den Tagesbetrieb gebaut: Artikel anlegen, Ware buchen, Bons speichern. Sie ist nicht dafür gebaut, fünf Jahre Bonpositionen nach Warengruppe, Lieferant und Filiale gegeneinander zu stellen. Wer das trotzdem versucht, kennt die Folgen:

• Große Abfragen bremsen die Kasse und den Wareneingang.
• Jede Auswertung wird von Hand in Excel nachgebaut, jedes Mal ein bisschen anders.
• Zwei Leute nennen für denselben Monat zwei verschiedene Rohgewinne.
• Daten aus mehreren Systemen (Kasse, Warenwirtschaft, Lieferantenlisten) passen nicht zusammen.

Ein Data Warehouse trennt das Arbeiten vom Auswerten. Die operative Datenbank bleibt schnell, die Auswertungsdatenbank ist für lange Zeiträume und große Gruppierungen optimiert.

Die Architektur im Überblick

Der Aufbau hat fünf Schichten. Jede Schicht hat genau eine Aufgabe; dadurch lässt sich jede einzeln austauschen, ohne den Rest anzufassen.

Der Import: vom Kassenbon zur sauberen Zeile

Die meiste Arbeit steckt nicht in den Diagrammen, sondern im Import. Hier entscheidet sich, ob die Zahlen stimmen.

1. Auslesen: Nur neue oder geänderte Bons seit dem letzten Lauf. Ein Zeitstempel oder eine laufende Nummer in der Quelle genügt.
2. Vereinheitlichen: Warengruppen, Lieferanten- und Markennamen in eine einheitliche Schreibweise bringen. „Müller GmbH“, „Mueller“ und „MUELLER GMBH“ sind ein Lieferant, nicht drei.
3. Ergänzen: Einkaufspreis zum Verkaufszeitpunkt an jede Bonposition hängen. Nur so lässt sich der Rohgewinn später korrekt rechnen.
4. Prüfen: Summen je Tag gegen den Kassenabschluss abgleichen. Weicht etwas ab, bricht der Lauf ab, statt falsche Zahlen zu laden.
5. Laden: In die Faktentabelle schreiben, Sichten aktualisieren, Datenstand vermerken. Jedes Dashboard zeigt an, bis wann die Daten reichen.

Personenbezogene Daten (Kundennamen, Bankverbindungen) gehören nicht ins Auswertungssystem, wenn sie für die Auswertung nicht gebraucht werden. Für Demo- und Testsysteme werden sie pseudonymisiert.

Das Datenmodell: Star-Schema oder flache Tabelle?

Lehrbücher empfehlen das Star-Schema: eine Faktentabelle in der Mitte (Bonpositionen mit Menge, Umsatz, Einkaufswert), darum herum Dimensionen (Zeit, Artikel, Warengruppe, Lieferant, Filiale). Das ist sauber und bei vielen Quellen die richtige Wahl.

In der Praxis des Mittelstands geht es oft einfacher. Bei einer Quelle und einigen Millionen Bonpositionen reicht eine breite Faktentabelle, die Artikel, Warengruppe, Marke und Lieferant direkt mitführt, plus eine Zeit-Dimension und ein paar Sichten. Das ist schneller gebaut, leichter zu verstehen und mit passenden Indizes schnell genug.

Wichtig ist bei beiden Varianten dasselbe: Der Einkaufspreis wird zum Verkaufszeitpunkt gespeichert, nicht später aus dem Artikelstamm nachgeschlagen. Sonst ändert jede Preiserhöhung rückwirkend den Rohgewinn der Vorjahre.

Kennzahlen mit Formeln

Eine Kennzahl ist nur so gut wie ihre Definition. Deshalb steht jede Formel an genau einer Stelle, in der Schnittstelle, und alle Oberflächen übernehmen das Ergebnis.

Umsatz, Rohgewinn, Marge

So sieht das als Abfrage je Warengruppe aus:

SELECT  WG                                         AS warengruppe,
        SUM(ENDPREIS)                              AS umsatz,
        SUM(ENDPREIS - EKPREIS * STCK)             AS rohgewinn,
        ROUND(SUM(ENDPREIS - EKPREIS * STCK)
              / NULLIF(SUM(ENDPREIS), 0) * 100, 1) AS marge_prozent
FROM    umsatz
WHERE   DATUM BETWEEN '2026-01-01' AND '2026-09-30'
GROUP BY WG
ORDER BY rohgewinn DESC;

Durchschnittlicher Bonwert

Lagerumschlag

Das ist die Lehrbuchformel. Fehlen historische Bestände, wird oft vereinfacht mit Umsatz ÷ Ø Bestand gerechnet. Das geht für Vergleiche zwischen Warengruppen, ergibt aber höhere absolute Werte. Wichtig ist, dass die Variante dabeisteht.

Abverkaufsquote

Flächenproduktivität

Warenkorb-Verbindungen

Ein Lift über 1 bedeutet: A und B landen häufiger zusammen im Korb, als der Zufall erwarten lässt. Das ist die Grundlage für Platzierung und Zusatzverkäufe.

Vorjahresvergleich

Verglichen wird immer der gleiche Zeitraum des Vorjahres, nicht das ganze Vorjahr. Wer Januar bis Oktober gegen ein volles Vorjahr stellt, sieht scheinbar einen Einbruch.

Im eigenen Haus oder in der Cloud?

Cloud-Data-Warehouses sind für sehr große, schnell wachsende Datenmengen gebaut. Die Bonpositionen eines mittelständischen Händlers passen dagegen bequem in eine gewöhnliche Datenbank. Die Entscheidung hängt deshalb weniger an der Technik als an Kosten, Abhängigkeit und Datenschutz.

Auch eine hybride Lösung ist möglich: Datenbank im eigenen Haus, Dashboards über einen abgesicherten Webserver erreichbar. Welche Variante passt, ergibt sich aus Datenmenge, Anzahl der Nutzer und den Anforderungen an den Datenschutz, nicht aus einem Werbeprospekt.

Lokale KI: Fragen stellen, ohne Zahlen herzugeben

Mit einem Data Warehouse wird eine KI im Unternehmen erst richtig nützlich: Statt Excel-Dateien hochzuladen, fragt man „Welche Warengruppe hat im dritten Quartal am meisten Marge verloren?“ und bekommt eine Antwort aus den echten Zahlen.

Damit dabei keine Geschäftszahlen das Haus verlassen, sieht der Aufbau so aus:

• Lokales Sprachmodell auf einem eigenen Rechner oder Server, kein Cloud-Dienst.
• MCP-Server (Model Context Protocol) als Bindeglied zwischen Modell und Datenbank.
• Nur lesender Datenbank-Benutzer, der nur freigegebene Sichten sieht und keine Kundendaten.
• Nur Summen und Kennzahlen als Ergebnis, keine Einzeldatensätze mit Personenbezug.

Mehr dazu: MCP-Server-Entwicklung, RAG verständlich erklärt und KI-Agent-Demo.

So läuft ein Projekt ab

1. Fragen sammeln: Welche Entscheidungen sollen die Zahlen stützen? Daraus folgen die Kennzahlen, nicht umgekehrt.
2. Quellen prüfen: Welche Daten liegen wo, in welcher Qualität, seit wann?
3. Prototyp mit echten Daten: Ein Ausschnitt (z. B. ein Jahr, eine Filiale) zeigt schnell, wo die Daten haken.
4. Import automatisieren: Nächtlicher Lauf mit Prüfsummen und Datenstand-Anzeige.
5. Ausbauen: Weitere Dashboards, Board-Pack für die Geschäftsleitung, KI-Abfragen.

Live-Demo

Die Demo läuft mit pseudonymisierten Daten eines Fahrrad- und Gartenfachhandels. Sie zeigt, wie die beschriebene Architektur in der Oberfläche aussieht.

Häufige Fragen