Projektübersicht

RetailPulse Analytics ist eine fiktive Analytics-Plattform für die Lumen Retail Group. Sie verbindet Verkaufs-, Bestands-, Kunden- und Kampagnendaten aus 28 Filialen und einem Onlineshop. Das Management erhält dadurch täglich ein einheitliches Bild der Geschäftsentwicklung.

Geschäftsziele

• Umsatz und Marge nach Kanal, Region und Produktgruppe transparent machen
• Bestandsengpässe früh erkennen und Überbestände reduzieren
• Wirkung von Marketingkampagnen vergleichbar bewerten
• Manuelle Excel-Berichte durch einen reproduzierbaren Datenprozess ersetzen

Nutzergruppen

Projektumfang

Im Umfang enthalten sind Datenaufnahme, Qualitätsprüfung, ein zentrales Sternschema, definierte Kennzahlen und ein interaktives Management-Dashboard. Prognosen und automatische Bestellvorschläge sind als spätere Ausbaustufe vorgesehen und nicht Teil der aktuellen Version.

Datenquellen

Die Plattform kombiniert operative Systeme mit unterschiedlichen Aktualisierungsrhythmen. Jede Quelle wird zunächst unverändert in einer Rohdatenzone gespeichert, bevor fachliche Transformationen stattfinden.

Quellsysteme

Datenverantwortung

Die jeweiligen Fachbereiche verantworten Vollständigkeit und fachliche Korrektheit ihrer Quellsysteme. Das Analytics-Team überwacht technische Lieferung, Schemaänderungen und die Einhaltung der vereinbarten Qualität.

Personenbezogene Identifikatoren werden vor der analytischen Verarbeitung pseudonymisiert. E-Mail-Adressen, Namen und vollständige Anschriften werden nicht in das Reporting-Modell übernommen.

Lieferkonventionen

• Zeitstempel werden in UTC geliefert und im Dashboard lokal dargestellt.
• Geldbeträge verwenden die Transaktionswährung und zwei Dezimalstellen.
• Stornierungen referenzieren immer die ursprüngliche Bestellposition.
• Neue Spalten sind erlaubt; entfernte oder umbenannte Spalten lösen einen Alarm aus.

Datenmodell

Das Reporting basiert auf einem Sternschema. Die zentrale Faktentabelle enthält eine Zeile je verkaufter oder retournierter Bestellposition. Einheitliche Dimensionen ermöglichen Vergleiche zwischen Filiale und Onlineshop.

Tabellen

Modellregeln

Produkt- und Standortattribute werden historisiert. Eine nachträgliche Kategorieänderung verändert daher keine bereits veröffentlichten Berichte. Retouren werden als negative Mengen und Umsätze mit eigenem Buchungsdatum geführt.

Beispiel für eine aggregierte Abfrage:

SELECT
    d.month_name,
    l.channel_type,
    SUM(s.net_revenue) AS net_revenue
FROM fact_sales AS s
JOIN dim_date AS d ON s.order_date_key = d.date_key
JOIN dim_location AS l ON s.location_key = l.location_key
GROUP BY d.month_name, l.channel_type;

Kennzahlenkatalog

Alle Kennzahlen werden zentral berechnet. Dashboard-Seiten dürfen keine abweichenden lokalen Definitionen verwenden. Beträge werden standardmäßig in EUR und ohne Umsatzsteuer dargestellt.

Kernkennzahlen

Vergleichslogik

Jede Kennzahl kann gegen Vorjahr, Vormonat und Plan verglichen werden. Der Vorjahresvergleich verwendet vergleichbare Wochentage. Neue Filialen fließen erst nach 90 Betriebstagen in den Like-for-like-Vergleich ein.

Ampellogik

• Grün: Ziel erreicht oder positive Abweichung
• Gelb: Abweichung bis fünf Prozent vom Ziel
• Rot: Abweichung über fünf Prozent oder fehlende Daten

Die Farbe dient nur der Orientierung. Exakte Werte und Vergleichszeitraum bleiben immer sichtbar, damit die Bewertung nachvollziehbar ist.

Pipeline und Datenqualität

Die Verarbeitung läuft täglich automatisiert und zusätzlich inkrementell für Verkaufsdaten. Jeder Lauf besitzt eine eindeutige Run-ID und kann ohne doppelte Buchungen wiederholt werden.

Verarbeitungsschritte

1. Quelldaten laden und unverändert archivieren
2. Schema, Datentypen und Pflichtfelder prüfen
3. Schlüssel vereinheitlichen und personenbezogene Daten pseudonymisieren
4. Fakten und Dimensionen inkrementell aktualisieren
5. Kennzahlen berechnen und fachliche Qualitätstests ausführen
6. Freigegebene Daten für das Dashboard veröffentlichen

Qualitätsprüfungen

Beispiel einer vereinfachten Job-Konfiguration:

job: retail_sales_daily
schedule: "15 5 * * *"
retries: 2
quality_gate: required
publish_on_success: true

Fehlerhafte Datensätze werden mit Fehlercode und Run-ID in einer Quarantänezone gespeichert. Sie werden erst nach fachlicher Klärung erneut verarbeitet.

Dashboard und Nutzung

Das Dashboard ist für wiederkehrende Management- und Analyseaufgaben aufgebaut. Alle Seiten verwenden dieselben Filter für Zeitraum, Region, Kanal und Kategorie.

Dashboard-Seiten

Beispielanalyse

Sinkt die Marge einer Region, wird zuerst nach Kanal und Produktkategorie aufgeschlüsselt. Anschließend zeigt die Detailansicht, ob Rabatte, Retouren oder Einkaufskosten die Abweichung verursachen. Ein Drill-through führt bis auf Artikel- und Filialebene, jedoch nicht auf einzelne Kunden.

Export und Teilen

Tabellen können als CSV exportiert werden. Exporte übernehmen aktive Filter und enthalten Erstellungszeitpunkt sowie Datenstand. Automatische PDF-Berichte werden montags um 07:00 Uhr an den definierten Management-Verteiler gesendet.

Betrieb und Monitoring

Das Analytics-Team betreibt Pipeline und semantisches Modell. Der Fachbereich verantwortet Kennzahlendefinitionen und Abnahme. Das Dashboard ist werktags zwischen 06:00 und 22:00 Uhr verfügbar.

Tagesablauf

Serviceziele

• Verkaufsdaten sind höchstens 90 Minuten alt.
• Der tägliche Gesamtstand ist bis 06:00 Uhr verfügbar.
• Kritische Fehler werden innerhalb von 15 Minuten alarmiert.
• Wiederherstellung bei Pipelinefehlern erfolgt innerhalb von vier Stunden.

Vorgehen bei Störungen

1. Run-ID und betroffene Quelle im Monitoring identifizieren.
2. Prüfen, ob Lieferung, Schema oder Qualitätsregel die Ursache ist.
3. Fachbereich bei inhaltlichen Abweichungen einbeziehen.
4. Fehler korrigieren und betroffene Partition idempotent neu laden.
5. Dashboard-Datenstand prüfen und Vorfall dokumentieren.

Geplante Wartungen und bekannte Datenverzögerungen werden im Dashboard als Hinweis angezeigt. Für technische Unterstützung steht die Support-Seite bereit.

Support