Jak vybrat software pro optimalizaci zásob (a jak ho otestovat před podpisem)

Potřebujete vůbec software pro optimalizaci zásob?

Ne každá firma ho potřebuje a ty, které ho koupí příliš brzy, platí dvakrát: jednou za licenci a podruhé za projekt, který se zasekne, protože na něj organizace nebyla připravená.

Zralost plánování hraje větší roli než velikost firmy a má tři úrovně. Na první úrovni probíhá objednávání v tabulkách a na základě zkušeností. Na druhé počítá ERP systém s min–max hladinami nebo objednacími body, které někdo kdysi nastavil a málokdy reviduje. Na třetí úrovni specializovaný nástroj předpovídá poptávku po jednotlivých položkách a lokalitách, převádí ji na návrhy objednávek s ohledem na velikosti balení, minimální objednací množství (MOQ) a dodací lhůty a lidem nechává k řešení jen výjimky. Právě na tyto tři kroky se ROI kalkulačka Veritico STOCK ptá nejdřív, protože rozdíl mezi vaší současnou a cílovou pozicí určuje většinu celkového přínosu.

Přeskočit úroveň funguje málokdy. Firma, která dnes objednává v tabulkách, nezíská z doplňovacího enginu v dalším čtvrtletí žádnou hodnotu, protože datová disciplína, na které engine stojí, zatím neexistuje. Typickým nákupem je přechod z druhé úrovně na třetí a vyplatí se, když platí několik věcí najednou: aktivní kombinace položka–lokalita se počítají na desítky tisíc, nezanedbatelná část poptávky pochází z proma nebo sezónnosti, dlouhý ocas pomaluobrátkových položek a přerušované poptávky je příliš velký pro jedno pravidlo doplňování a ručním vytvářením objednávek tráví dny více než hrstka lidí. Nejde o striktní hranice, ale o vzorec, který vidíme tam, kde si na sebe nástroj vydělá.

Potenciálním klientům jsme už poradili, aby počkali. Důvodem většinou nebyl software, ale to, že ve firmě nikdo nespravuje kmenová data, nebo že nikdo v provozu nevěří skladovým záznamům. Upřímnou radou je v takové chvíli opravit základy a výběrové řízení zopakovat o rok později, s mnohem větší šancí na úspěch.

Co zkontrolovat ve vlastních datech před sepsáním RFP

O tom, zda pilotní ověření přinese smysluplný výsledek, rozhodují tři věci: přesnost skladových záznamů, stav kmenových dat a kvalita historie poptávky. Nástroj neopraví ani jedno. Jen je rychleji převede do návrhů objednávek.

Přesnost skladových záznamů je na prvním místě, protože každý doplňovací engine objednává podle záznamu, ne podle regálu. Nejznámější studie tohoto problému od DeHoratiuse a Ramana zkoumala téměř 370 000 skladových záznamů ve 37 prodejnách jednoho obchodníka a zjistila, že 65 % neodpovídá fyzickému stavu. To bylo v roce 2008 a retaileři, se kterými dnes pracujeme, jsou na tom lépe, ale málokdy o tolik, jak sami předpokládají. Pokud kategorie vykazuje v systému zápornou zásobu nebo cyklické inventury neustále nacházejí fantomové zásoby, žádný algoritmus dostupnost nezvýší. Udělá přesný opak: systém uvidí zásobu, která neexistuje, přestane objednávat a výpadek zásoby trvá, dokud záznam někdo neopraví. Proto lepší předpověď poptávky sama o sobě výpadky zásob nevyřeší.

Kmenová data představují druhou kontrolu a ve většině projektů ten největší kus práce. Dodací lhůty v ERP hlásí sedm dní, ale dodávky trvají dvanáct. Velikost balení je šest, přestože dodavatel teď posílá dvanáct. Minimální objednací množství se vyjednalo před lety a nikdo ho neaktualizoval. Kvůli každému z těchto případů engine počítá správně se špatným vstupem a výsledek vypadá jako selhání softwaru, i když jde o selhání dat. Před RFP si vezměte jednu reprezentativní kategorii a srovnejte tato pole s realitou. Podíl chyb, které musíte opravit, vám ukáže, kolik přípravy pilot vyžaduje.

Historie poptávky je třetí v pořadí. Dvanáct měsíců je minimum, aby model viděl celý sezónní cyklus. Osmnáct až dvacet čtyři měsíců je lepších, protože zbude prostor pro holdout období. Důležitější než délka je ale to, co v historii chybí. Proma bez patřičného označení vypadají jako výkyvy poptávky, které se model bude snažit předpovědět. Týdny výpadku zásoby se jeví jako týdny s nulovou poptávkou, což model naučí, že se položka neprodává. Obojí se dá opravit, ale musíte na to přijít před pilotem, ne se tím vymlouvat po něm.

Jaká kritéria dodavatele skutečně odlišují a jaká ne

Název algoritmu dodavatele neodlišuje. Způsob, jakým se nástroj chová na okrajích vašich dat, ano.

Kritéria, na kterých záleží, se projevují ve složitých případech. Jak nástroj předpovídá položku, která se prodá dvakrát za měsíc? Jak odděluje promo navýšení od základní (baseline) poptávky a co dělá s propadem po skončení proma? Považuje týdenní výpadek zásoby za nulovou poptávku, nebo za cenzurovanou poptávku, kterou je potřeba odhadnout? Kolik návrhů musí plánovač otevřít, vysvětlí nástroj, proč návrh vypadá zrovna takto, a zaznamená, co plánovač změnil? Kdo spravuje kmenová data po spuštění provozu (go‑live) a jak změny proudí mezi nástrojem a ERP? Kolik času od podpisu do první objednávky vygenerované systémem zabere příprava dat na vaší straně? A jak se zachová cena, když otevřete dalších deset prodejen?

Kritéria, na kterých nezáleží, plní většinu prezentací dodavatelů. „Poháněno AI“ popisuje každý produkt na trhu. Počet modelů v knihovně neříká nic o tom, jak mezi nimi nástroj vybírá. Dashboardy vypadají hezky, ale hezký vzhled není kritérium pro nástroj, který budou tři plánovači používat osm hodin denně. Výjimka ale stojí za pozornost: pokud ho místo tří plánovačů bude využívat čtyřicet vedoucích prodejen, uživatelská přívětivost se stává rozhodující, protože hlavní překážkou bude adopce. Kritéria musí kopírovat váš budoucí provozní model, ne ten, který dodavatel ukazuje v demu. Do srovnání patří i celkové náklady; tématu, jaké jsou skutečné náklady na vývoj vlastního řešení oproti nákupu, jsme se věnovali zvlášť a licence málokdy představuje tu nejvyšší položku.

Navrhněte pilot tak, aby směl selhat

Pilot, který nemůže selhat, je jen demo s vaším logem. Pilot s vypovídající hodnotou je backtest na vaší vlastní historii, proti vašemu současnému procesu a s kritérii úspěchu pevně stanovenými předtím, než kdokoliv uvidí výsledek.

Mechanika se dá popsat jednoduše a velmi snadno se obchází. Vezměte pro pilot osmnáct až dvacet čtyři měsíců historie. Posledních tři až šest měsíců odřízněte jako holdout období, které nástroj nikdy neuvidí. Nechte nástroj generovat návrhy objednávek týden po týdnu v celém holdout období s využitím pouze těch dat, která by měl k dispozici v daném okamžiku. Poté tyto návrhy porovnejte s tím, co vaše firma ve stejných týdnech skutečně objednala a co se skutečně prodalo. Srovnání nezní „nástroj proti naivnímu forecastu“; to je test, který nástroj vždy vyhraje. Srovnání zní „nástroj proti lidem a pravidlům, které řídíte dnes“, protože přesně takové rozhodnutí děláte.

Před začátkem backtestu písemně zafixujte KPI: dostupnost nebo service level, dny zásob nebo hodnotu zásob, bias forecastu podle kategorie a podíl návrhů, které by plánovač přepsal. Dodavatelé vám nabídnou přidání metrik zpětně. Neustupujte.

Zvolte takový rozsah, který prověří hranice: jednu vysokoobrátkovou kategorii se silnou promoční aktivitou plus vzorek z dlouhého ocasu pomaluobrátkových položek. Nevybírejte kategorii s nejčistšími daty ani tu, kterou navrhne dodavatel. Šest až osm týdnů včetně přípravy dat je reálný časový rámec. Když pilot běží déle, příčina se téměř vždy skrývá v datech a už to samo o sobě je důležité zjištění.

Dema dodavatelů vypadají lépe než piloty, protože demo data neobsahují výpadky zásob, změny sortimentu, neoznačená proma ani dodavatele, který měl v listopadu tři týdny zpoždění. Vaše historie tohle všechno má. A v tom je podstata věci.

Na tomto postupu trváme, protože jsme stáli i na druhé straně. Backtesty na klientských datech někdy vyšly hůře, než předpokládal business case. Správnou reakcí bylo případ přepočítat, zúžit rozsah nebo projekt odložit, nikoliv hledat výmluvy pro vzniklý rozdíl. Pilot, který dokáže přinést takovou odpověď, je ten jediný, do kterého má smysl investovat.

Jak číst výsledky a převést je na peníze

Dobrý backtest ukazuje potenciál, ne záruku. Rozdíl tvoří faktory, které backtest nemůže obsáhnout: plánovači přepisující návrhy v ostrém provozu, dodavatelé zpožďující dodávky nebo personál prodejny, který číslům věří či nevěří.

Typické jsou dva scénáře. Nástroj dorovná vaši současnou dostupnost s výrazně menší zásobou, nebo dostupnost zvýší při zhruba stejné hladině zásob. Obě varianty přinášejí peníze přes jiné řádky: ta první znamená uvolněnou hotovost ze zásob a nižší náklady na držení zásob, druhá vrací marži z prodejů, o které byste přišli kvůli prázdným regálům. Třetím řádkem jsou lidé. Pokud backtest ukáže návrhy, na které by plánovači sahali jen málokdy, čas dříve věnovaný vytváření objednávek se změní na čas strávený řešením výjimek a komunikací s dodavateli, tedy tam, kde plánovači skutečně přinášejí hodnotu.

Tohle je chvíle, kdy do ROI kalkulačky zadáte svá vlastní čísla. Vyžaduje pět vstupů: segment, zralost plánování, roční obrat, hodnotu zásob a počet lidí, kteří objednávky zpracovávají. Vrátí odhad ročního přínosu, dobu návratnosti, uvolněnou hotovost a rozpad toho, odkud přínos pramení. Jde o odhad, ne o hotový business case, ale během pár minut zjistíte, jestli výsledek backtestu stojí za další zpracování.

Pro představu, zveřejněné výsledky z našich vlastních projektů se pohybují v tomto rozmezí. V síti 490 lékáren Dr.Max se nasazení modulu Veritico STOCK pojí s nárůstem tržeb o 5 %, zvýšením dostupnosti o 4 % a úsporou dvou hodin denně na každé lékárně při objednávání. V SIKO stoupla dostupnost na regále z 97 na 98,5 %, zatímco hodnota zásob meziročně klesla o 1,65 milionu €. V Košíku dosáhla dostupnost 97 % a objem vyhozeného zboží klesl o 75 %. Jsou to odlišné firmy s různými startovními pozicemi, což je přesně ten důvod, proč backtest na vašich vlastních datech překoná čtení jakýchkoliv případových studií, včetně těch našich.

Smluvní a implementační pasti, které se objevují až po podpisu

Většina sporů po podpisu se týká rozsahu, ne samotného softwaru. Tři otázky většinu z nich vyřeší a patří do smlouvy, nikoliv na kickoff meeting. Kdo vyčistí kmenová data a kdo se postará o to, aby zůstala čistá po spuštění provozu (go‑live)? Kdo staví a udržuje integrace na ERP a skladový systém a kdo platí, když se ERP aktualizuje? A co si odnesete s sebou, pokud odejdete: historii poptávky, odladěné parametry a pravidla pro výjimky, a to ve formátu, který přečte jiný systém?

Následně zkontrolujte dvě čísla vůči vašemu plánu růstu. Cena za položku nebo lokalitu vypadá při podpisu levně, ale roste s každou další otevřenou prodejnou; zeptejte se na částku pro dvojnásobek vaší aktuální sítě prodejen. Spuštění provozu za osm týdnů je reálné pouze tehdy, když z této doby vyjmete přípravu dat. Naše vlastní implementace Veritico STOCK trvají zhruba čtyři měsíce včetně zmíněné přípravy a raději to řekneme na rovinu, než abychom na to přišli společně ve třetím měsíci. Nakonec si přečtěte, co pokrývá SLA: dostupnost systému (uptime) se garantuje snadno, ale vy si kupujete kvalitu návrhů.

Výběrové řízení nemusíte dělat sami, ani věřit dodavatelům každé slovo. Běžně stojíme na straně klienta při výběru a implementaci plánovacích a dodavatelských systémů, a to i těch, které nejsou naše. Otázky uvedené výše jsou přesně ty, které za klienty klademe.

Kdy je správnou odpovědí nekupovat

Někdy dá backtest jasný výsledek a ten ukáže, že software není váš problém.

Tímto směrem ukazují tři signály. Přesnost skladových záznamů pod úrovní, kde dokáže fungovat jakýkoliv engine, typicky když namátková inventura v pilotní kategorii odhalí velký podíl záznamů odchýlených o více než jedno balení. Kmenová data bez jasného vlastníka: pokud dnes nikdo neodpovídá za dodací lhůty a velikosti balení, nástroj pojede do tří měsíců po startu na zastaralých vstupech a vinu ponese projekt. A trvale vysoký podíl přepsaných návrhů z důvodů, které nástroj nevidí, jako jsou neformální dohody s dodavateli nebo proces plánování, který probíhá na schůzkách a do systému se nikdy nedostane. Jako zkušenostní pravidlo z našich projektů platí, že pokud by plánovači změnili zhruba třetinu nebo více návrhů, potřebuje opravit proces, ne nástroj.

V každém z těchto případů nástroj problém jen posune, místo aby ho vyřešil. Lepší postup je zaměřit se nejprve na procesy a data, a teprve za pár měsíců provést druhý pilot na stejném rozsahu a stejných KPI, aby se oba výsledky daly porovnat. Firmy, které zvolí tuto cestu, většinou nakonec nakoupí, ale nákup podloží business casem, který si dokážou obhájit.

Často kladené dotazy

Jak dlouho by měl pilot softwaru pro řízení zásob trvat? Šest až osm týdnů včetně přípravy dat je pro backtest jedné nebo dvou kategorií reálný odhad. Pokud se protáhne na výrazně delší dobu, zdržení téměř vždy pramení v extrakci a čištění dat, nikoliv v nástroji, což je užitečná informace sama o sobě.

Měli bychom testovat dva dodavatele současně? Ano, pokud oba dostanou stejný rozsah, stejnou historii a stejné holdout období. Dva piloty na odlišných kategoriích nebo v různých časových úsecích nejdou porovnat a stejně byste nakonec vybírali jen na základě dojmů.

Můžeme spustit backtest bez předání citlivých dat? Většinou ano. Kódy položek a lokality lze anonymizovat a ceny indexovat. Co ale musí zůstat zachované, je historie poptávky na úrovni položka–lokalita–týden, hladiny zásob, označení promo akcí a parametry dodavatelů, protože právě na nich se nástroj testuje.

Co když jsme promo historii nikdy neoznačovali? Částečně se dá zrekonstruovat na základě změn cen a objemů. Rekonstrukce má ale své meze a dodavatel by vám měl říct, jak k ní přistoupil. Počítejte s tím, že kategorie s velkým podílem proma dopadnou v testu hůř, než kdyby měly čisté označení, a berte výsledky z dlouhého ocasu položek jako tu spolehlivější část pilotu.

Spočítejte si nejprve svá vlastní čísla. ROI kalkulačka vyžaduje pět vstupů a vrátí odhad ročního přínosu, dobu návratnosti a uvolněnou hotovost. Pokud výsledek stojí za debatu, ozvěte se nám a my s vámi backtest navrhneme.