Ein markenübergreifendes Modell mit Governance für eine Multi-Brand-Handelsgruppe
Multi-Brand-Handel
Eine Handelsgruppe aus mehreren Marken, jede mit eigenen Systemen und einer eigenen Antwort darauf, was eine Marge ist. Ein Fabric-Modell mit Governance spannt sich heute über alle, mit je einer Definition von Umsatz, Marge und Bestand.
3 Antworten darauf, was eine Marge ist, ersetzt durch eine
Jede Marke konnte über sich selbst berichten, aber die Gruppe konnte sie ohne eine Woche Handarbeit nicht vergleichen. Wir haben ein 8 Jahre altes SQL-Server-Warehouse und eine nächtliche Excel-Kette durch Microsoft Fabric ersetzt, und eine Definition je Kennzahl machte aus dem Vergleich eine Filterauswahl.
Monate, als leitender Architekt mit einem Projektteam
10
Nach Branche und Größe anonymisiert, denn die Vertraulichkeit, die diesen Kunden schützt, würde auch Sie schützen. Branche und Ergebnisse sind echt, die identifizierenden Details nicht.
Vorher und nachher
3 Definitionen
Marge Marke AEigene Definition, im eigenen Reporting
Marge Marke BEigene Definition, im eigenen Reporting
Marge Marke CEigene Definition, im eigenen Reporting
1 Definition
Eine MargendefinitionEinmal entschieden, vorgelagert, im Modell mit Governance
Echt: VertriebskanalFilialen, Onlineshops und Großhandel, als Dimension modelliert
Echt: MarkenunterschiedIm Modell geführt und dort benannt, wo es ihn wirklich gibt
Nur GewohnheitEntfällt: eine Definition gilt
3 Marken, die auf 3 Arten beantworten, was eine Marge ist, aufgelöst in eine Definition. Die Unterschiede, die es wirklich gibt, werden modelliert und benannt, die aus Gewohnheit fallen weg.
Das Projekt im Detail
Kunde
Eine Multi-Brand-Handelsgruppe mit 500 bis 1.000 Mitarbeitenden, rund 50 Filialen, 3 Onlineshops, einem Großhandelsgeschäft und rund 200 BI-Nutzern.
Ausgangslage
Jede Marke konnte über sich selbst berichten, und die Gruppe konnte ohne eine Woche Handarbeit über keine von ihnen gemeinsam berichten. Damit wurden Fragen auf Gruppenebene so teuer, dass niemand sie mehr stellte, und das ist der stille Preis, den keine Wirtschaftlichkeitsrechnung ausweist.
Auftrag
Microsoft Fabric von Grund auf einführen, anstelle eines 8 Jahre alten SQL-Server-Warehouses und einer nächtlichen Excel-Kette, und der Gruppe je Kennzahl eine Antwort geben.
Was wir gebaut haben
FoundationEin Review des Reportings jeder Marke, der zeigte, wo sich die Zahlen der Marken nicht vergleichen ließen, allen voran die Marge, und mit einer Liste der Sofortmaßnahmen endete.
ActivationEin semantisches Modell mit Governance über alle Marken hinweg, mit einer einzigen Definition je Kennzahl und den Unterschieden zwischen den Marken, die es wirklich gibt, modelliert statt bestritten.
Vergleich als Filterauswahl
Sobald Umsatz, Marge und Bestand unabhängig vom Kanal definiert waren, war die Konsolidierung der Gruppe keine Arbeit mehr. Die Gruppe, eine Marke oder ein Kanal ist heute ein Filter auf demselben Modell. Vorher eine Woche manuelle Konsolidierung, heute eine Filterauswahl.
Ein Kundenstamm als eigenes Datenprodukt
Die Auflösung der Kundenidentität wurde als eigenes Datenprodukt gebaut, sodass ein Kunde ein Datensatz ist, über welchen Kanal er auch kauft: Filialkunden aus den Kassen, Shopkunden aus 3 Onlineshops und Großhandelskonten aus dem Großhandelsgeschäft, zusammengeführt zu einem dauerhaften Kundenstamm.
Filialumsatz nahezu in Echtzeit
Kassendaten, die in eine KQL-Datenbank strömen, ersetzten 2 Tage Verzug im Filialumsatz-Reporting.
FilialkassenRund 50 Filialen
EventstreamEreignisse, während sie entstehen
KQL-DatenbankReal-Time Intelligence
FilialumsatzNoch am Verkaufstag
Wie umgesetzt wurde
Umgesetzt als leitender Architekt mit einem spezialisierten Projektteam, übergeben mit Runbooks und Excel-Enablement.
.pbip unter GitVon Tag eins
Erst optimierenVor jeder Kapazitätserhöhung
RunbooksFür das Team des Kunden
Analyze in ExcelEnablement bei der Übergabe
Die Architektur
Databricks bleibt die Verarbeitungs-Engine und wird nach OneLake gespiegelt statt kopiert. Die semantischen Modelle lesen das Lakehouse über Direct Lake, ohne nächtlichen Import.
Architekturentscheidungen
Entscheidung
Verworfene Alternative
Warum
Ein Modell über alle Marken
Ein Modell je Marke
Schneller gebaut, aber das Abstimmungsproblem bleibt. Der Vergleich ist das Ergebnis.
Unterschiede modelliert, nicht eingeebnet
Eine Marge jeder Marke aufgezwungen
Ein echter Unterschied wird modelliert und benannt, einer aus Gewohnheit entfällt.
Databricks behalten und gespiegelt
Die Verarbeitung in Fabric neu bauen
Tenant-übergreifend nach OneLake gespiegelt, sodass Power BI über Direct Lake liest, ohne nächtlichen Import.
Zahlen der Gruppe getrennt von den Nutzersichten
Eine Schicht für jeden Zweck
Eine Nutzersicht kann sich ändern, ohne die Zahlen der Gruppe zu berühren.
Was der Kunde heute hat
Eine semantische Schicht mit Governance über alle Marken, mit den echten Unterschieden modelliert.
Vergleich auf Gruppenebene als Filterauswahl, ohne die Woche manueller Konsolidierung.
Filialumsatz noch am Verkaufstag statt 2 Tage später.
Ein dauerhafter kanalübergreifender Kundenstamm, als eigenes Datenprodukt gebaut.
Wohin es geführt hat
Die Gruppe wird mit einem Klick nach Marke oder Kanal verglichen, auf Zahlen, die in jeder Marke dasselbe bedeuten.
Ein Händler mit Microsoft Fabric bereits im Produktivbetrieb, semantischen Modellen über Direct Lake und einströmendem Filialumsatz, der darauf Forecasting, Copilot-Fragen und Anomalieerkennung wollte.
Ein Industriehersteller, der über ein Produktionsnetz mit mehreren Standorten berichtete, von denen jeder seine eigene Sicht darauf hatte, was gerade lief.
Eine kostenlose 60-minütige Beratung. Kein Verkaufsgespräch, keine Rechnung. Danach wissen Sie, ob Ihre Daten bereit für KI sind und ob wir zueinander passen.