Retail: vraagvoorspelling per winkel en SKU op één platform
Een omnichannel-keten bouwt vraagvoorspelling per winkel en SKU met Spark-notebooks en MLflow bovenop dezelfde Gold-laag als de BI-rapportage, zonder een apart ML-platform.
Business challenge
Een retailketen met tweehonderd-plus winkels en een webshop stuurde voorraad en promoties per silo: elke winkel, elk kanaal, eigen aannames. Er was geen vraagvoorspelling op SKU-niveau, dus derving en nee-verkoop werden achteraf geconstateerd in plaats van vooraf voorkomen.
Architectuur
Kassadata, e-commerce-orders en ERP-voorraad landen via batch-ingestie in Bronze op OneLake. Spark-notebooks conformeren en verrijken de data in Silver; dezelfde notebooks trainen vraagvoorspellingsmodellen per winkel en SKU, met MLflow voor experiment-tracking en modelregistratie. Voorspellingen landen als Gold-tabellen naast de reguliere verkoopaggregaten, zodat één Direct Lake semantic model zowel historische verkoop als voorspelling ontsluit. AI Functions classificeert tekstuele reviews en servicetickets als extra signaal voor de voorspelmodellen.
Waarom deze keuze
Het punt was niet "een ML-model bouwen", dat kan overal. Het punt was feature-engineering en serving op dezelfde data laten draaien als de bestaande BI-rapportage, zonder een aparte kopie naar een apart ML-platform te slepen. Doordat Lakehouse en semantic model dezelfde Delta-tabellen delen, is een voorspelling nooit meer dan één Gold-tabel verwijderd van het dashboard waar een category manager al in werkt.
Alternatieven
Een apart ML-platform (bijvoorbeeld Azure Machine Learning naast de bestaande BI-stack) geeft meer controle over MLOps-volwassenheid, maar voegt een datakopie en een tweede promotiemodel toe. Voor dit team, met een sterk Spark-profiel en een bestaande Fabric-investering, woog die extra complexiteit niet op tegen de winst.
Trade-offs
- ML-modellen en notebooks passen niet netjes in hetzelfde promotiemodel als BI-items; een aparte MLflow-gedreven promotie was nodig.
- Piekbelasting rond feestdagen vraagt om tijdelijke capaciteitsopschaling; structureel overdimensioneren was duurder dan plannen.
- Batch-training buiten kantooruren voorkomt dat trainingsjobs interactieve rapportage vertragen.
Microsoft-producten
Microsoft Fabric (Lakehouse, Data Factory, Spark Notebooks, Data Science met MLflow, AI Functions), OneLake, Power BI met Direct Lake.
Best practices
- Houd modelpromotie (MLflow-registry) gescheiden van BI-promotie (Deployment Pipelines); ze kennen een andere levenscyclus.
- Train buiten de interactieve piek en gebruik capacity smoothing, niet structurele overdimensionering, om feestdagenpieken op te vangen.
- Behandel voorspellingen als een gewone Gold-tabel, geen aparte black box, zodat BI-developers ze net zo makkelijk kunnen combineren als verkoopcijfers.
Lessons learned
Tachtig procent van de voorspelkwaliteit kwam niet van het model maar van de features: promoties, feestdagen en lokale evenementen als inputvariabelen toevoegen gaf meer winst dan drie iteraties modelafstemming. Verder bleek de eerste versie van de pipeline modellen op elke run te herregistreren, wat het MLflow-register onbruikbaar groot maakte; versiebeheer met expliciete promotie naar "production"-stage loste dat op.
Architectuur in beeld
Klik op een onderdeel voor toelichting
Kassa, e-commerce, ERP
Verkoop- en voorraaddata landt via batch-ingestie in Bronze.
Voorspellingen landen als een gewone Gold-tabel naast de verkoopaggregaten, geen aparte black box.
Gerelateerde content
Gerelateerde patterns
Gerelateerde how-to's
Gerelateerde best practices