Problém a zadání

Představte si, že máte 2× ročně kolekci 400 produktů, každý v několika velikostech, a musíte zajistit, aby každý byl v dostatečném množství ve všech velikostech v každém z 34 obchodů.

Zboží se z větší části objednává dlouho dopředu, nelze tak flexibilně reagovat na poptávku, budoucí prodeje na jednotlivých místech jen odhadujete. Přitom nutně potřebujete, aby si po celou dobu mohl zákazník ve „své“ prodejně rovnou vyzkoušet a koupit kterékoliv zboží, ale zároveň aby na konci sezony bylo téměř vyprodáno, protože high-fashion kolekce jsou po skončení sezony neprodejné nebo prodejné jen s výraznou slevou (ztrátou).

Musíte tedy:

• Minimalizovat investice do zásob
• Mít zboží tam, kde se nejlépe prodá
• Minimalizovat ztráty z neprodaného či zlevněného zboží
• Přesouvat efektivně produkty mezi prodejnami (replenishment)

Stávající řešení

Přesně tyto problémy Pietro Filipi trápily, a proto v průběhu více než deseti let vyvíjeli vlastní skript (sadu SQL procedur), který měl přes 5 000 řádků kódu a prakticky nikdo už se v něm nevyznal.

Skript fungoval na principu fixního pořadí prodejen, podle kterého se zásoby přesouvaly. Spouštěli jej 2× týdně ručně a ještě to vyžadovalo mnoho ručních zásahů před i po doladění nějakých zjevných chyb.

Řešení tak ani nedokázalo zhodnotit efektivitu jednotlivých přesunů zboží, nebylo rozhodující, jak dobře se dařilo v jednotlivých prodejnách dané zboží prodávat, a docházelo tak k mnoha přesunům tam, kde pak zboží leželo a naopak v mnoha prodejnách stejné zboží chybělo.

Naše řešení

K celé problematice replenishmentu jsme přistoupili tzv. od konce, tedy od cílů, kterých se chce dosáhnout a jak je hodnotit. Klíčové otázky tedy zněly:

Proč přesouvám zboží?

Chci dosáhnout vyšších tržeb při stejné marži.

Na čem to záleží?

Na pravděpodobnosti prodeje.

Je to logické – potřebujete znát, jak pravděpodobně daný výrobek prodáte na konkrétní prodejně, abyste věděli, do které jej dodat.

Příklad: Máte 100 blůz z nové kolekce a musíte určit, na které prodejny jich kolik poslat. Případně máte blůzy na prodejnách a máte určit, jestli se na nich stihnou prodat do konce sezóny a jestli by se spíše neprodaly jinde. Ovšem s tím vám vznikají náklady na přesun a výpadek z prodeje při tzv. off shelf time.

Prvním krokem je tedy spočítat pravděpodobnost prodeje blůz v jednotlivých prodejnách. Zde jde vycházet z prodejů stejných, příbuzných či podobných produktů v minulosti, ale započítat lze i například vliv počasí atd. Máte přitom několik možností, jak k výsledku dospět. Nám se osvědčilo je zkombinovat a využít různé metody podle toho, kolik máme dat.

Ve druhé fázi je třeba spočítat pravděpodobnost na úroveň jednotlivých kusů v jednotlivých prodejnách. Budu-li mít např. 75 % pravděpodobnost prodeje blůz v Praze a 44 % pravděpodobnost v Teplicích, je lepší dodat blůzu jako třetí do Prahy nebo jako první do Teplic?

Náš kombinovaný prediktivní model:

• Regrese

• Při dostatku dat o předchozích prodejích
• Lineární, logistická, vážená…
• ML algoritmy

• Dokážou dát kvalitní předpověď i s menším množstvím dat
• Analyzují vztahy mezi produkty případně další externí vlivy (počasí, sezona…)
• Neurální sítě, Bayesovské neurální sítě
• Expertní odhad
• Zkušenosti firemních odborníků, výborné hlavně pro úvodní odhady, kdy nejsou k dispozici téměř žádná data

Tím ovšem výpočet nekončí, pravděpodobnost prodeje může být totiž navzájem závislá:

• Nepřípustné pohyby
• Minimální zásoba na prodejně
• Substituty, komplementy

Hledáme tedy to nejlepší rozmístění z množiny přípustných řešení…

Optimalizační model pro replenishment – shrnutí

• KPI
• Celkový očekávaný zisk = očekávané tržby – náklady na přesun a ztráty z off shelf time
• Prediktivní model
• Lineární či složitější kombinace, ML či expertní odhad
• Omezující podmínky
• Všechna pravidla pro přípustnost přesunu

Co nám fungovalo

• Rozklad na dílčí pravděpodobnosti

• Model odhaduje obecnější
• Rozklad nejprve podle apriorních pravidel
• Postupně se zvyšuje váha datového výpočtu
• Párové propojení

• Prohibitivní ceny pro blokace a sklad
• Greedy heuristika pro výběr nejlepších přesunů

Co nám nefungovalo

• Optimalizace cestou IP

• Nápad: rozmístění produktů řešit jednou nebo více IP úloh
• Problém: samotný výpočet, čas, výchozí podmínky, zavádějící shadow-prices
• Substituční analýza

• Nápad: „Slabší“ produkty se prodávají lépe, když lepší není k dispozici
• Problém: hypotéza neprůkazná, datový šum, kladná korelace

Výsledky

Náš nový kód, kterým jsme nahradili původní řešení, přinesl nejen značné úspory a zvýšení zisků, ale byl též mnohem přehlednější, díky rozdělení do nezávisle upravitelných částí. Rozsah navíc klesl z původních více než 5 000 na zhruba 1 000 řádků kódu. Navíc získali kompletní asi 1 000řádkovou dokumentaci.

Veškeré výpočty transferů navíc probíhají každý den zcela automaticky bez nutných zásahů a u Pietro Filipi získali navíc reporty efektivity jednotlivých přesunů, které jim umožnily dále pracovat na optimalizaci.

Co na to říká klient