Podcast

Dobrý den, moje jméno je Jirka Vicherek.

Dobrý den všem, moje jméno je Hinek Wollner.

Vítáme vás u dalšího dílu DataTalku.

Naším dnešním hostem je... Naším dnešním hostem je Karel Tesař, který k nám přišel popovídat, co znamená DataSense ve ShipMonku.

Ahoj Karle.

Ahoj, děkuji za pozvání.

Myslím, že málo technologických firem má tolik věhlasu a je tak vidět třeba v médiích jako ShipMonk. Je to logistická firma založená Čechem, jejíž úspěch vaší firmy katapultoval vás mezi nejbohatší Čechy dokonce.

Myslím si, že ale zas moc lidí nevidí úplně dovnitř a co ta firma technologicky dělá. Co ty říkáš, že dělá ShipMonk, když se snažíš vaši firmu někomu vysvětlit?

Já ještě doplním, že jsme americká firma, vlastně naše byznys centrum je v Americe a to hlavní, co děláme, je, že nabízíme sklad jako službu. Když to řeknu hodně zjednodušeně.

To znamená, že pro kohokoliv, kdo má svůj malý, střední nebo klidně i velký e-shop a už se mu to rozrostlo natolik, že nechce ty objednávky vyřizovat sám, protože jich prodává tolik, že se mu to nevejde ani domů, ani do garáže, sklep už je taky plný, tak v ten moment přicházíme my jako ShipMonk a e-shop jediné, co musí udělat, je integrovat se k nám do systému, začít nám posílat své zboží a o zbytek se postaráme už my.

Jakmile mu přijde jakákoliv nová objednávka, tak ji z toho skladu vyřídíme a odešleme koncovému zákazníkovi.

Takže v e-commerce tomu říkáme i fulfillment?

Jo, jo, říkáme tomu fulfillment odborně.

Aha, a fulfillment přesně označuje vlastně pozici ShipMonku?

Přesně tak, přesně tak. ShipMonk to, co dělá, je fulfillment, že vezme objednávku, vyřídí ji ze skladu, pošle ji nějakým dopravcem a tam naše zodpovědnost vlastně končí. Potom zodpovědnost za objednávku přebírá dopravce, aby ji doručil koncovému zákazníkovi.

No a co dopravilo do ShipMonku tebe? Jaká byla tvoje logistická cesta tady a role ve ShipMonku?

To samo o sobě už je takový menší příběh, tak já to vezmu trošku zeširoka.

V době střední a vysoké školy jsem se hodně věnoval soutěžnímu programování, soutěžil jsem v tom, jak rychle zvládnu naprogramovat nějaké algoritmy.

Na vysoké škole jsem organizoval seminář pro středoškoláky, kde oni jednak soutěžili, zároveň jsme dělali vzdělávací soustředění, aby se programování naučili lépe, zlepšovali nebo někteří aby ho zvládli úplně od nuly.

Právě jeden z účastníků takových soustředění mě potom dostal do ShipMonku. Já jsem jednou scháněl práci, zmínil jsem to na Facebooku a ozval se mi člověk, kterého jsem viděl jednou v životě na jednom soustředění, a lákal mě do ShipMonku.

Takhle to vlastně začalo. Pak jsem přišel na pohovor a hned mě zaujalo, že všechny logistické problémy, které mi představili, že ve skladu řeší, jsem viděl jako paralelu s těmi úkoly z programátorských soutěží.

Ty zadání vypadala jako hodně podobná, že máme nějaký problém a potřebujeme algoritmus, který ho vyřeší.

Můžeš jmenovat nebo navést ty z našich posluchačů, kteří by měli zájem o programovací soutěže?

Určitě, poslouchají nás i nějací středoškoláci.

Ty soustředění, o kterých jsem mluvil, se pořádají na MatFizu a jmenují se korespondenční seminář programování. Je to dlouhodobý seminář, trvá celý rok a na jeho konci jsou nejlepší pozvaní na soustředění.

Druhá věc je soutěž Cassiopeia, také pořádaná MatFizem, jednou ročně. Nejprve je domácí kolo online a potom ti nejlepší soutěží ve finále o hodnotné ceny.

Když říkáš, že problémy, které vám představili na pohovoru nebo které řešíte, jsou podobné úlohám ze soutěží, můžeš být konkrétnější?

Nejde o úplně stejná zadání. V soutěžích jsou problémy vymyšlené, inspirované skutečnými problémy, ale jsou zjednodušené tak, aby měla řešení pěknou matematickou či algoritmickou podobu.

Realita je jiná.

Protože problémy byly často inspirované logistikou nebo skladem samotným, bylo to pro mě známé prostředí.

Říkal jsem si, že bych to jednou chtěl dělat profesně.

ShipMonk pak ukázal ty skutečné problémy, ne zjednodušené.

To mě zaujalo.

Může jít třeba o hledání nejkratší cesty, když potřebuji vyzvednout nějaké zboží ve skladu.

Ty jsi nastoupil do ShipMonku jako data scientist a zmínil jsi už některé problémy. Můžeme se teď víc dotknout, co vlastně znamená data science ve ShipMonku?

Data science ve ShipMonku je nyní hodně zaměřené na to, co se děje uvnitř skladu.

ShipMonk má dvě hlavní části systému. Jednou je order management system, který je určený právě pro naše e-shopy, aby se tam organizovali - kdy posílají jaký inventář, vidí počet vyřízených objednávek a tak podobně. Je to webové prostředí pro jejich organizaci vztahu s námi.

Druhou částí jsou sklady.

Data science je zatím zapojená právě do těch skladů.

Pokud se podívám na sklad jako na celek, je to velký optimalizační problém.

Na vstupu skladu jsou inventury, které nám doručují naše e-shopy. To nemáme pod kontrolou, dostáváme je tak, jak nám je posílají.

Výstupem skladu jsou objednávky od koncových zákazníků, které také nemáme pod kontrolou.

Naším úkolem je, aby sklad fungoval co nejefektivněji s ohledem na tyto požadavky.

Celé to je vlastně jeden velký optimalizační problém, který neřešíme celý.

V rámci skladu jsou prostory, kde se inventury skladují, fungují tam procesy, které zajišťují přesuny zboží či vyřizování objednávek.

My se věnujeme především optimalizaci těchto procesů.

Super, mohli bychom ten popis vzít z pohledu datové cesty? Člověk si představí sklad jako velké místo s regály a množstvím věcí, které se přemisťují. Co to znamená datově? Co všechno měříte? Jak vypadají data ve ShipMonku? Když bych otevřel vaši databázi, co bych tam našel?

Základem skladu jsou lokace.

Každé místo, kde leží inventura, je lokace a vztah toho, že něco někde leží, je "okurenský" vztah.

V databázi tak vidíme, že na dané lokaci leží určitý produkt s určitou kvantitou.

To je základní pohled.

Pomocí lokací se popisuje celý fyzický layout skladu.

Existuje mnoho typů lokací.

Dva hlavní typy v našem skladu jsou backstock a picking zóna.

Backstock je to, co si většina lidí představí pod pojmem sklad – regály od země až ke stropu s uskladněným zbožím často na paletách.

Když někdo chce k něčemu přistoupit, musí použít vysokozdvižný vozík, dojet až nahoru, něco vytáhnout a přemístit na zem.

Z pohledu optimalizace je to skladový prostor levný na uskladnění, protože je obrovský a skladovací kapacita je velká.

Ale manipulace je drahá, protože je třeba používat velký vozík, pohybovat se ve výšce, což je obtížné a zdlouhavé.

Oproti tomu je picking zóna, která je podobná supermarketu.

Regály jsou nižší, dosáhne na ně člověk.

Může tam jezdit s vozíkem, nebo v některých skladech tam jezdí roboti.

Tam se přímo vytahují jednotlivé kusy a skládají objednávky.

Picking zóna je menší než backstock, nemůže tam být úplně všechno, ale je efektivní pro manipulaci.

Co se týče dat samotných, jak ta dvě prostředí - backstock a picking zóna - popisuješ, víceméně máte přehled o tom, kde je každý balík a co se s ním děje, a to jsou všechna data, která sbíráte a s nimi pracujete.

Od chvíle, kdy přijmeme zboží do skladu, každá krabice se musí oskenovat.

Tímto způsobem vznikají datově položky v našem skladu.

Od té chvíle evidujeme inventář - kde se nachází, v jaké krabici je, případně kde leží ta krabice.

V datech je nejen to, která inventura leží kde, ale i to, že inventura může být v krabici a ta krabice může být uskladněná jinde.

Většina akcí ve skladu spočívá v tom, že vezmeme nějaké množství inventury a přesuneme ji jinam, nebo vezmeme krabici a přesuneme ji.

Těmito akcemi se postupně inventura přemisťuje z místa na místo, až se na konci inventura patřící do jedné objednávky shromáždí v jednom kontejneru a zabalí se do balíčku, který se pak odešle.

Jakmile se balíček zabalí, inventura z našeho systému zmizí.

Dále existuje pouze balíček s adresovou nálepkou pro doručení.

Ty jsi teď pěkně popsal, jak data v logistice fungují.

Před nahráváním jsme se bavili o tom, že ShipMonk je velmi specifický a řeší jiný problém než klasické e-shopy.

Například skladové problémy Alzy jsou jiné.

Můžeš to trochu popsat?

Ano, hlavní rozdíl oproti Alze nebo Amazonu je, že když si člověk u nich objedná, může mít v balíčku cokoliv.

My zastřešujeme zhruba tisíc různých e-shopů.

Od nás si člověk nikdy nic neobjednává přímo.

Objednává si vždy z jednoho konkrétního e-shopu.

Dostáváme objednávky se zbožím vždy z jednoho e-shopu, což můžeme využít.

Například větší e-shopy mají dedikovanou zónu, kde jsou jen oni.

Menší e-shopy jsou soustředěny ve větší společné zóně.

Můžeme využít toho, že skladáme zboží blíže k sobě, protože objednávka je vždy z jednoho e-shopu.

Další rozdíl například oproti Rohlíku je, že tam musíte řešit velmi přesně datum spotřeby.

My žádné potraviny nemáme, nebo alespoň ne ve smyslu, kdy by datum spotřeby bylo pár dní.

U nás je datum spotřeby v řádu let.

To hodně mění skladový problém, který řešíme.

Skvělé, Karle, myslím, že to byl velmi dobrý popis fungování skladu, sběru dat a jejich zpracování.

Pojďme se teď podívat na konkrétní problémy.

Jak data science v ShipMonku pomáhá?

Snažíme se představit optimalizační platformu, postupně do ní zahrnujeme případy, kdy je potřeba navigovat proces.

To znamená navigaci: kde je moje příští akce.

Pokud dělám pinkání objednávek, co je moje další zastávka, co mám udělat.

To je jedna část.

Druhá část, na které hodně participujeme, je generování samotného workloadu.

Můžeme si to představit tak, že máme nějaké objednávky, ke kterým je potřeba provést určité akce.

Když budu mluvit o backstocku a picking zóně, které jsem popisoval, tak přišly objednávky a je potřeba zjistit, zda je v picking zóně inventář pro jejich vyřízení.

Není.

Takže je potřeba vytáhnout inventář z backstocku a rozprostřít ho do picking zóny, abych objednávky bylo možné splnit.

To je jeden konkrétní příklad.

Plánujete nějakou predikci picking?

Ano, máme modely predikce, ale v rámci celého problému je to menší část.

Větší část je efektivně vykonat práci.

Jak co nejefektivněji vzít zboží, které chybí v picking zóně, z backstocku - vybrat správné krabice.

Zboží nemusí být jen na jedné lokaci, může být na deseti různých místech.

Celé je potřeba vymyslet tak, abychom vzali správné krabice a zároveň neudělali zbytečně dlouhou trasu.

Je to několik kroků.

Nejdříve vytáhnout zboží z backstocku na zem.

Pak naložit a převézt ho do picking zóny.

Oba tyto kroky vyžadují navigaci.

Při zavážení do picking zóny navíc záleží na tom, kam zboží umístíme.

Mám tam stovky volných lokací pro uložení produktu.

Kam ho dám, výrazně ovlivní efektivitu dalšího zpracování objednávek.

Zmínil jsem hodně problémů, které řešíme v různém rozsahu.

Některé jsme jen začali řešit, některé už pokročileji, ale...

Ještě. Například na tom backstocku je situace trochu složitější a řekl bych, že jde o docela zajímavý problém. Tam proces neexistuje jen jeden, ale můžeme si představit, že se tam v zhruba 10 až 20 různých místech, záleží na konkrétním skladu, pohybují obrovské vozíky. A proces tam neprobíhá jen jeden, ale několik najednou. Některé vozíky přivážejí nové věci dovnitř, jiné vytahují věci ven, někdy kontrolují problémy s lokacemi. Všechny tyto procesy musíme nějakým způsobem zorganizovat, aby si navzájem nepřekážely a všichni v daný okamžik dělali nějakou hodnotnou práci.

To je skvělé, můžeme si vzít tento konkrétní problém a popsat celý životní cyklus, jak to začalo a jak k tomu přistupoval. Mojí naivní představou je, že přišel za vámi někdo z byznysu, například tvůj šéf, a říkal: „Hele, v tom backstocku to vypadá, že máme velké problémy, je tam hodně velkých vozíků, a nevyužíváme dostatečně místo, které máme. Co se stane po této konverzaci? Jak k tomu přistoupíš?“

Historicky, co se týká data science, tak se v začátcích firmy data science nevěnovalo pozornost. První roky existence firmy data science nebyla vůbec. Sklady byly navíc menší než dnes a spoustu problémů nebylo nutné při menších objemech řešit rozsáhle. Ale sklady postupně vyrostly a množství procesů, které tam fungují, se zvětšilo.

My jsme v rámci data science týmu začali postupně přebírat pod sebe navigaci těch jednotlivých procesů – šli jsme zpracováváním těch procesů jeden po druhém. Začali jsme procesy, které fungují na backstocku, a to konkrétně jedním procesem, který řeší retrievly (vyzvedávání). Už na datech bylo vidět, že je tam problém – uživatelé často zadávali tak, že jeden systém navigoval někam, kde už právě byl někdo jiný.

Původní implementace s tím nepočítala, protože se nepočítalo s takovým nárůstem pohybu, aby to byl problém. Ale jak sklad rostl, problém se objevil. To bylo první, co jsme museli vyřešit – aby lidé nepřicházeli o čas tím, že jedou někam, kam nemohou vjet, nebo tam musí čekat.

Jaký byl tedy první krok k vyřešení tohoto problému? Nejprve jsme pochopili, kde byla chyba, a následně jsme problém začali řešit. Šlo o postupnou práci: vzali jsme jeden proces podruhým a řešili pro něj navigaci.

Původní řešení bylo takové, že každý proces, respektive každý vozík, se navigoval úplně nezávisle na ostatních. My jsme k tomu přistoupili tak, že jsme to vše postupně přidávali do jednoho řešiče (solveru). Když si člověk žádal příští zastávku, my jsme nespočítali jen její polohu pro něj, ale v rámci jednoho požadavku jsme spočítali příštích několik zastávek pro všechny vozíky, kteří se pohybovali na backstocku. Zohlednili jsme, kdo kde je, kdo blokuje uličku, a podle toho určili, kam pošleme právě dotyčného člověka, který si žádá navigaci.

Po vyřešení tohoto problému se nám podařilo zlepšit celé řešení asi o 30 %. Možná bych měl zmínit ještě něco, o čem jsem se ptal úplně na začátku. Vyvinuli jsme totiž metriku, která dokáže tento problém měřit – měřili jsme průměrnou vzdálenost, kterou člověk najede na jednu vyzvednutou krabici. A byla docela vysoká, což nás vedlo k rozhodnutí, že tento problém chceme optimalizovat.

Když jsme přidali řešení kolizí, tedy minimalizování překrývání pohybu vozíků, už bez další složité logiky ve výběru úkolů jsme zlepšili průměrnou ujetou vzdálenost asi o 35 %, což znamenalo, že lidé najeli o 35 % méně než předtím.

Co to znamená nabrat data? Vím, že sbíráte množství dat přímo ze skladu. Co to znamená v tomto konkrétním případě? Znáte polohu každé krabice, lokace jsou přesně popsané, vysokozdvižní vozík má zřejmě v sobě nějaký technologický systém, takže víte, kde se právě nachází, a to v reálném čase.

Popisované řešení, které jsem zmínil, funguje v reálném čase. S načtením všech dat o vozících víme, kam jsme posledně vozík poslali; nevlastníme však GPS, takže slepě věříme, že vozík dojel do požadovaného místa. Víme tedy, kde byl naposledy a kam jsme ho poslali teď, a podle toho vyhodnocujeme jeho aktuální polohu a pohyb. To děláme pro všechny vozíky v backstocku.

Tím pádem rovnou víme, kterým uličkám se chceme vyhnout, zpravidla těm, kde právě jede někdo jiný. Celý systém funguje real time, při každém požadavku spočítáme navigaci znovu.

V budoucnu budeme možná potřebovat ještě větší real-time optimalizaci, pokud budeme chtít dosahovat dalšího zlepšení, například z pohledu celodenní organizace práce. Zatím to však nebylo potřeba.

Super. Tak pojďme k dalšímu příkladu. Jaká data od vás chodí? Co s nimi dělá váš solver, na čem běží? Komu ty data posíláte a jak se používají?

To je dobrá otázka. Ve skladu má člověk v ruce tablet se skenerem, který používá pro vykonávání své práce. Vždy zjistí, kde je jeho aktuální zastávka; když tam dojede, oskenuje položku, naloží ji a zobrazí se mu další zastávka. Tablet komunikuje s backendem.

Backend, který není součástí data science řešení, je napsaný v PHP a odpovídá za celkové reprezentování skladu. Kdykoli se něco přemístí z místa na místo, backend zajistí, že je to správně zaznamenáno a zpracováno v systému.

Během práce ve skladu, kdy frontend komunikuje s backendem, může nastat situace, kdy je třeba rozhodnout, kam má člověk dál jet, nebo vyvolat optimalizaci na vyšší úrovni. V takovém okamžiku backend odešle požadavek našemu systému, který analyzuje data a odpoví, jakou akci je potřeba provést a kam se má vozík poslat.

Ve vašem data science týmu kolik vaší práce představují stále hledání rychlých vítězství (quick wins), tedy případů, kdy se snažíte jednoduše vymigrovat stará pravidla na chytřejší systém, integrovat řešení do platformy a automatizovat proces? Nebo je už systém plně funkční a jde jen o průběžnou optimalizaci? Jak moc je potřeba platformové práce a jak moc experimentujete a hledáte nové příležitosti?

Myslíme si, že rychlých vítězství máme stále poměrně dost před sebou. Vyplatí se vždy nejdříve pokrýt různé drobné problémy, protože když člověk udělá jednoduché první řešení, narazí na mnoho neočekávaných skutečností. Často problém není tam, kde jsme ho původně viděli.

To je zásadní součást naší práce, rozhodně se nesoustředíme jen na platformní věci. Když přijde někdo k nám, musí umět dobře programovat, protože po něm budeme chtít, aby dané řešení implementoval a napsal kód.

Zároveň však musí být velmi vnímavý k tomu, co se ve skladu skutečně děje, mít metodický přístup – postavit metriku, stanovit očekávání, že navržené řešení pomůže, a na základě metriky ověřovat, zda k zlepšení skutečně dochází. Pokud ne, musí umět najít příčiny nebo pojmenovat skutečný problém, který jsme zatím nepostihli a který je třeba řešit.

Říkal jsi, že na začátku jsi příznivcem toho, že je potřeba pokrýt všechny procesy, vymyslet jednoduché, nekomplexní řešení a agilně s ním pracovat. Můžeš uvést příklad situace, kdy pilotní řešení ukázalo, že skutečný problém je někde jinde a je potřeba se zaměřit na jiný aspekt?

Ano, například jsme řešili zavážení inventory do picking zóny. Jedna věc byla, kde zásoby uložit, kam je pojede vozík a jak daleko ujedou. Největší problém však byl, že uživatelé měli možnost akci zamítnout. Setkali jsme se s tím, že vybraná lokace se jim fyzicky nehodila, například se tam zboží nevešlo ideálně, takže akci zamítli. Nebo jsme je poslali příliš daleko, což bylo také odmítnuto. Další situací bylo, že jsme jim přidělili příliš těžkou krabici (například do čtvrtého levelu), kterou nechtěli zvedat, a proto akci zamítli.

Zjistili jsme tedy, že největší problém je minimalizovat odmítnutí akce uživateli, protože těch bylo přes 20 %.

Jak tento problém řešíte? Nejprve je potřeba pochopit, proč uživatelé akce odmítají, jaké jsou fyzické překážky a jak funguje proces z pohledu lidí, kteří jej vykonávají.

To je jedna část – mít pochopení, že těžké věci není vhodné zvedat do velké výšky.

Druhá věc je komunikace – být transparentní vůči skladům, komunikovat, co děláme, proč a naslouchat jejich potřebám. Když máme společný cíl minimalizovat odmítnutí a všichni ho sdílí, začínáme problém úspěšně řešit. Dostáváme zpětnou vazbu o skutečných překážkách.

Pomáhá identifikovat správná místa v systému, kde je vhodné logiku vylepšit – třeba i jednoduchými pravidly, aby vše dohromady dávalo smysl.

V praxi to může být if statement nebo rozhodovací strom, například pravidlo, že těžké věci nepatří do regálů nad třetím patrem. Tedy abychom nezaváděli příliš složitou nebo lokálně přizpůsobenou logiku, ale udrželi jednotná, univerzální pravidla.

Takové pravidlo platí ve všech skladech: když něco váží více než stanovenou hranici, dáváme to jen do prvního či druhého levelu, lehčí věci lze uložit všude.

Tímto přístupem rozdělujeme problémy na fyzické a logické.

Nejprve se musí vyřešit fyzické omezení, tak aby lidé mohli vůbec vykonávat činnosti, které doporučíme. A až když to funguje, řešíme logiku usazení zboží po skladu.

Protože pokud bychom nastavili příliš mnoho fyzických omezení, nezbyl by prostor pro logiku samotnou a optimalizaci.

My pak musíme dávat pozor, abychom pravidly problém nepřeháněli; když je jich příliš, už není možné dále zlepšovat.

Na základě popsaných datových zdrojů bych měl dojem, že máte svůj 'píseček', tedy sklad, kde je zaznamenán každý proces spojený s položkou. Víte tedy všechno a můžete to využít v optimalizaci. Je to tak, nebo by vám přesto nějaká data pomohla?

První, co mě napadá – nevím, jestli by to pro vás bylo užitečné – jsou data o chování zákazníků e-shopu, například sezónnost různých objednávek, protože víte, že v zimě je poptávka po určitých produktech vyšší.

Nedá se říct, že máme data perfektní. Máme však vysokou důvěru v to, že většina skladových dat pochází přímo z naší aplikace, což znamená nízkou potřebu předzpracování, protože data mají už při sběru konkrétní význam.

Nicméně jak se systém vyvíjí, neznamená to, že všechna data sbíráme správně ke všem účelům, a proto se občas setkáváme s tím, že nám chybí určitá data potřebná pro analýzy nebo identifikaci problémů.

Tento problém je čím dál menší, protože kvalita dat roste, ale je to oblast, kterou kontinuálně zlepšujeme.

Dále jsme mluvili o datech z našich e-shopů. Tam je situace složitější, protože máme tisíce různých e-shopů a získat pro všechny stejný soubor dat je velký problém.

Situace je natolik složitá, že se jí momentálně nezabýváme. V budoucnu možná ano.

Zatím se snažíme vystačit s tím, co máme. Například při predikcích množství zboží vycházíme výhradně z dat objednávek.

Mít spolehlivá data pro všechny zákazníky ohledně sezónnosti nebo typu prodávaných produktů je obtížné právě kvůli velikosti a různorodosti.

Co je pro tebe ultimátní stav vaší práce? Je to kompletní automatizace skladu s minimálními náklady zvládající jakýkoli vstup? Je to tedy finální vize, ke které směřujete?

Ano, naším ultimátním cílem je metrika cost per order, tedy náklady na vyřízení jedné objednávky. Vše, co děláme, by mělo snižovat tuto hodnotu.

Pokud se nám podaří náklady snížit o 10, 20 nebo 30 procent, bude to skvělé.

Zároveň tím nejsou pokryty jen naše aktivity, ale i práce ostatních týmů. Nejlepší cesta k úspěchu je tedy týmová spolupráce.

Omlouvám se, že přerušuji, ale text je velmi dlouhý. Rád ho přepíšu do spisovné češtiny, ale z důvodu přehlednosti to provedu po částech. Zde je první část upraveného textu:

Mluvím o tom, co my a jak optimalizujeme, ale i o tom, jak jsou navržené jednotlivé procesy. Vlastně se do toho dá započítat i to, jak dlouho se například vykresluje stránka na frontendu konkrétnímu člověku. Kdyby nám například uteklo toto, a naše optimalizace by fungovala naprosto perfektně, ale každá akce by se na té obrazovce vykreslovala o pět sekund déle, tak to ve výsledku ten čas neušetří. Takže je to kombinace úplně všeho.

Když teď budu mluvit konkrétně o cíli, kam bych chtěl dotáhnout tu optimalizaci, tak je to jednak rozšířit případy, které pokrýváme. Začít je spojovat dohromady, neřešit izolovaně malé problémy, ale řešit to komplexněji. Vlastně ideálně, když budu vytahovat krabici z backstoku, abych už rovnou v tu chvíli přesně věděl, jaká bude její cesta, jak se dostane do packing zóny, aby to bylo co nejefektivnější.

Dá se to potom rozšiřovat i o to, že pokud to budeme mít dostatečně podchycené, budeme přesně vědět, kolik lidí by mělo pracovat kde. Což je jedna z věcí, kterou teď vůbec neřešíme, ale myslím si, že v tuto chvíli je správně, že to neděláme. Množství lidí, kteří tam pracují, a kolik jich kde pracuje, se totiž může dynamicky měnit v průběhu dne.

Pak mám ještě jednu vizi. Nevím, jestli už jsem to zmiňoval – vlastně nám veškerý náš kód běží v produkci, to znamená, že to, co vyvíjíme, napřímo ovlivňuje, jak sklad funguje. Vidím v tom velký potenciál k tomu, aby stejné algoritmy, které běží v produkci, nepoužívaly jen produkční data o tom, jak sklad funguje, ale aby do nich bylo možné nasypat i nějaká odsimulovaná data. Nebo aby do těch samých algoritmů byla posílána data v rámci nějaké simulace – například posíláme denní objednávky, které jsme měli vyřizovat. V rámci simulace pak dokážeme vyhodnotit, které přístupy fungují lépe a které hůře, a obohacovat sklad tímto explorativním přístupem.

Ješě napíšu další část?

Nejdříve vyberu nějaký kontejner, do kterého naskládám to zboží, a potom ten kontejner dám do nějaké lokace, kam se proto chodí. A tady vlastně výrazně pomohlo, že jsme tyto dvě věci neřešili izolovaně, ale řešili je společně dohromady. Už na základě toho, jaké volné lokace mám k dispozici a na základě toho, co vše už mám naložené a někam se to veze, jsem schopen říct, že tyto lokace mi už docházejí nebo už došly. Takže tuto velikost kontejneru nemohu používat.

Zároveň je to velmi jednoduché, ale už jenom to, že pokrývá více částí těch systémů najednou, přináší tu extra přidanou hodnotu. Když jsme právě tyto dvě rozhodnutí začali dělat společně, tak celkový počet zamítnutých lokací na jednou klesl během pár dnů o polovinu, tedy o 50 %.

Nyní jsi zmínil příklad toho komplexního problému, máš nějaký příklad toho velmi jednoduchého problému, na který jste přišli a jehož řešení mělo velkou hodnotu, přestože bylo algoritmicky velmi jednoduché?

Máme jeden takový problém a pak můžeme společně říct, zda podle vašeho názoru patří do data science, nebo ne. Ten problém byl takový. Jedna z věcí, které v tom skladu děláme, je optimalizace jednokusových objednávek, aby se vyřizovaly dohromady. Vlastně je spojujeme do větších celků, které se potom vyřizují najednou, a děláme to na základě toho, aby byly blízko sebe.

Takovéto řešení jsme v Shipunku měli dlouho a na našich metrikách jsme zjistili, že to funguje až podezřele špatně. Začali jsme to zkoumat a zjistili jsme, že ta optimalizace běží každých pět minut. To ve výsledku znamená, že se optimalizují vždy ty objednávky, které během posledních pěti minut přišly. Což ve výsledku znamenalo, že buď nespojuji nic dohromady, nebo spojím všechny objednávky, co přišly, a ty pak v tom skluzu jsou většinou kdekoliv. Optimalizace tak ve výsledku nedělala vůbec nic.

Jediné, co jsme pro to udělali a jak jsme to změnili, bylo to, že jsme optimalizaci nenechali běžet každých pět minut, ale jenom třikrát denně. Byla to velmi jednoduchá změna jednoho cron jobu. Jakmile to začalo běžet třikrát denně, řešení se výrazně zlepšilo. V průměru před tímto zásahem spojené objednávky navštěvovaly zhruba pět a půl uliček, které ve skluzu máme. Po spuštění třikrát denně se to snížilo na zhruba jednu a půl uličky. Bylo to tedy obrovské zlepšení a přitom jediná změna byla právě změna jednoho čísla, které bylo někde nastavené.

Odpověď na tvou otázku je ano, i tohle podle mě patří do data science.

Podle mě také. Za mě to do data science patří taky.

Ano, ale je to tak, že často, když se řekne data science, každý si pod tím představí něco hrozně složitého. Lidé ve firmě vidí data scientisty jako osoby, které řeší pouze velké a komplexní problémy. A jsou lidé, kteří říkají, že je nebude zatěžovat jednoduchými problémy, protože by to bylo plýtvání času.

S tímto předsudkem se snažím hodně bojovat a myslím, že by to tak rozhodně nemělo být. Už jsem to dnes několikrát zmínil, že základ úspěchu je v tom, že ti samí lidé, kteří pak mohou řešit komplexní problémy, začnou s těmi jednoduchými. Vybudují si tím zkušenosti, znalosti o fungování systému a mohou tak snadno vytvořit i jednoduchá řešení. To, že je něco teď jednoduché, neznamená, že by to data science neměla řešit. Naopak se vyplatí takto začínat právě kvůli získávání těch zkušeností.

Těchto situací jsem se potkal i v Shipmangu. Když se člověk například poprvé setká s někým z Ameriky, koho nikdy předtím neviděl a navzájem nevíme, jaké problémy ten druhý řeší, on vidí, že jsem data scientist. Vždy je důležité nějakým způsobem, aby ten druhý člověk získal představu o tom, co řešíme, že to mohou být i jednoduché věci. A ono to funguje i obráceně.

Pro nás je velkou motivací dělat taková řešení, která dokážeme vysvětlit lidem. Je totiž velmi častý požadavek nebo otázka od nich, jak to funguje. Lidé, kteří ty procesy vykonávají nebo kteří nesou zodpovědnost za plnění denního objemu práce, chtějí vědět a rozumět tomu, jak systém funguje a na základě čeho se rozhoduje.

Musíme neustále myslet na to, že ať uděláme cokoli, musí to být pochopitelné selským rozumem. Pokud sami nedokážeme těm lidem jednoduše říct, co a proč systém dělá, pravděpodobně to nebude dobré řešení. Když nastane nějaká chyba, je pak těžké ji obhájit. Jednotlivý pracovník nemusí vidět celkovou optimalizaci, není to součástí jeho zkušeností, ale každá chyba, například kdy balík jde na místo, kam se nevejde, se mu silně zaznamená v jeho osobní zkušenosti.

Dobrým příkladem je například rozhodnutí stáhnout z backstocku celou paletu nějakého zboží. Ten pracovník vidí, že na paletě je 500 kusů, ale dnes potřebujeme jen 100. Častější je případ, kdy dnes potřebujeme jen jeden kus, ale chystáme krabici, kde je 50 kusů, což nedává smysl. Musíme umět v komunikaci vysvětlit, proč to tak dává smysl. Umět říct, nebo ideálně ukázat na grafu: „Hele, sice dneska potřebujeme jeden kus, ale když se podíváme za 14 dní, bylo potřeba 50 kusů. Kdybychom si to dnes nevzali, museli bychom za pár dní přijít znovu s celou paletou.“

Fungovalo to i bez nás. Než přišel chytrý Karol Tesář a říkal, co mám pickovat, pickoval jsem taky a nějak to fungovalo. Oni v Praze ale vůbec nemají tušení, co tady v Austinu můžu pickovat. Není tam tento sentiment? Tady není.

Hlavně lidem, kteří dělají picking, je to jedno. Ti přišli vykonávat kusovou práci podle toho, co jim systém říká, a víc je to nezajímá. Ale manažeři, kteří vedou směny a nesou zodpovědnost, aby během dne stihli všechno vychystat, když vidí, že systém člověky posílá někam z jejich pohledu neefektivně, tak to řeší.

Takže ten sentiment tam je. Ale kdybych to teď měl rozhodnout já, udělal bych to jinak a lépe. Stává se to určitě. Proto je velmi důležitá komunikace, transparentnost, co je cílem a proč se věci chovají tak, jak se chovají. A nejdůležitější je chtít od lidí zpětnou vazbu. Když budeme chtít zpětnou vazbu, musíme ji skutečně chtít, protože víme, že chyby mohou vznikat.

Vždy chceme, aby nám chyby nahlásili, než aby si je začali řešit nějak po svém.

Karle, na co se může Shipmong Data Science Team těšit v následujícím roce?

V tomto roce určitě chceme navázat na úspěchy, které jsme měli minulý rok, týkající se některých use case právě ze skladu, kdy jsme dokázali zbytku firmy, že naše řešení jsou schopná něco optimalizovat a výrazně zefektivnit některé procesy. A to rozhodně není všechno, chceme to rozšířit ještě na další oblasti.

Konkrétně nás čeká větší práce s rozmístěním inventáře po skladu, tak aby to, co patří k sobě, bylo spolu. Druhým cílem je, aby se Data Science tým nezaměřoval pouze na sklad. Shipmong čelí mnoha dalším problémům, kde může data science hrát důležitou roli. Jedním z velkých problémů jsou například odchody zákazníků, kterým chceme co nejvíce zabránit. Protož se budeme věnovat větší analýze, zaměřené například na detekci odchodů.

Je toho víc, takže určitě je cílem nezůstat zavření jenom ve skladu, ale pomáhat i mimo něj.

Skvělé, moc vám držíme palce a děkujeme, že jste nám ukázal vnitřnosti Shipmangu z datové perspektivy.

Já také děkuji, bylo fajn si o tom takto popovídat. Díky moc, Karle.

A děkujeme všem posluchačům. Tak mějte se, ahoj.

Ahoj. Ahoj.

A to je všechno. Děkujeme, že jste doposlouchali další díl Data Tolku. Díky také našim partnerům: Big Hubu, Vypnoutu, Mantě, Natinu a také mně, Jean Beamu, Seznamu.cz a Muse.

Pokud vás zajímají další informace ze světa datových technologií a ze československé datové scény, navštivte naše stránky datatolk.cz.

Nechť vás provází data.