Przypomnij sobie ostatni raz, kiedy ktoś zapytał Cię: „co mam zamówić?". Jeśli prowadzisz sieć sklepów, to pytanie pada codziennie, wielokrotnie, z każdego oddziału.
I za każdym razem ktoś musi odpowiedzieć, opierając się na intuicji, doświadczeniu albo, co gorsza, na poprzednim tygodniu z Excela. Ten artykuł opowiada o tym, jak pomogliśmy klientowi przestać zgadywać.
Czym w ogóle jest „algorytm podpowiedzi"?
W klasycznym handlu detalicznym decyzja o tym, co zamówić do sklepu, to złożony proces. Trzeba wziąć pod uwagę, co się sprzedaje, co jest aktualnie w magazynie, jakie produkty są priorytetowe dla danej sieci, jakie marki obsługuje konkretny sklep i kiedy przypada następna dostawa.
W małej firmie to jeszcze do ogarnięcia. W sieci kilkudziesięciu sklepów, z setkami produktów i dziesiątkami marek, to jest już praca na pełen etat.
Nasz klient miał dokładnie ten problem. Proces zamawiania był częściowo ręczny, częściowo oparty na intuicji handlowców. Wszystko działało, ale generowało błędy, zajmowało czas i nie skalowało się. Chcieliśmy to zmienić.
Problem, który wymagał własnego myślenia
Z pozoru brzmi prosto: „weź dane o sprzedaży i powiedz, co zamówić". W praktyce każdy sklep jest inny. Inne marki, inne półki, inna historia sprzedaży, inne priorytety.
Część produktów musi być zawsze dostępna, bo klient je obiecał, bo umowa, bo strategia. Część produktów powinna się pojawiać, jeśli jest miejsce. Reszta powinna być dobierana automatycznie na podstawie tego, co historycznie dobrze rotuje.
Żadne gotowe narzędzie nie obsługiwało tej logiki w sposób dopasowany do struktury klienta. Byliśmy więc tam, gdzie już kilka razy byliśmy: musieliśmy to zaprojektować i napisać sami.
Jak to rozwiązaliśmy?
Kluczem było zrozumienie, że „podpowiedź" to tak naprawdę trzy różne źródła decyzji działające razem, w ściśle określonej kolejności.
Pierwsze: lista P0 - produkty, które muszą być w sklepie. Bez dyskusji. Niezależnie od miejsca na półce, sezonu czy rankingu. To decyzje biznesowe wpisane ręcznie przez zarządzających.
Drugie: lista P1 - produkty pożądane, jeśli jest miejsce. Ważne, ale nie krytyczne. Jeśli sklep ma wolną przestrzeń po P0, P1 wchodzi na swoje miejsce.
Trzecie: TOP produkty - automatyczny ranking wyciągany z historii sprzedaży w ERP. System sam oblicza, które produkty najlepiej rotują, i na ich podstawie uzupełnia zamówienie, jeśli po P0 i P1 zostało jeszcze miejsce.
To brzmi jak prosta kolejka priorytetów, ale szczegóły były najważniejsze. Dla każdego sklepu, dla każdej marki i dla każdej grupy produktów ta logika musi przebiec osobno. Przy sieci kilkudziesięciu sklepów i setkach kombinacji marek oraz grup algorytm wykonuje dziesiątki tysięcy mikrooperacji w jednym przebiegu.
Symulacja zanim cokolwiek się stanie
Jedną z najważniejszych decyzji projektowych było wprowadzenie trybu symulacji. Zamiast od razu tworzyć zamówienia, system najpierw pokazuje, co zostałoby zamówione bez żadnych skutków dla rzeczywistości.
Handlowiec może wejść w podgląd dla dowolnego sklepu, zobaczyć, co algorytm proponuje, skąd pochodzi każda pozycja (P0, P1 czy ranking automatyczny), w jakiej ilości i z jakiego powodu. Może coś odfiltrować, przejrzeć, ocenić. Dopiero gdy wszystko wygląda sensownie, jednym kliknięciem zamienia symulację w realne zamówienie.
To rozwiązało jeden z kluczowych problemów przy automatyzacji: brak zaufania. Ludzie nie ufają systemom, których nie rozumieją. Symulacja dała im wgląd i zaufanie przyszło samo.
Dlaczego to było trudne?
Nie dlatego, że matematyka była skomplikowana. Trudność leżała w precyzji i skali. Każda iteracja musi uwzględniać aktualny stan magazynu w czasie rzeczywistym: zarówno magazynu centralnego, jak i stanów w samym sklepie.
Jeden błąd w synchronizacji i algorytm sugeruje produkty, których nie ma, albo nie sugeruje tych, których jest pod dostatkiem.
Doszła do tego integracja z zewnętrznym systemem ERP, z którego pobierane są dane sprzedażowe do budowania rankingu. Dane nie przychodzą gotowe: trzeba je przetworzyć, wyważyć i ocenić z uwzględnieniem konfigurowalnych okien czasowych, bo luksusowe marki sprzedają się inaczej niż masowe i potrzebują innego horyzontu historycznego.
Na koniec wszystko musi działać asynchronicznie. Algorytm nie może blokować systemu na czas swojego działania. Dlatego całość oparta jest na kolejkach zadań z odpowiednimi mechanizmami blokad, żeby dwa równoległe uruchomienia nie nadpisały sobie nawzajem wyników.
Co dostał klient?
Nie dostał dashboardu z wykresami. Dostał narzędzie, które rano, zanim pierwszy handlowiec zaloguje się do systemu, już wie, co każdy sklep powinien zamówić. I potrafi to uzasadnić.
Każda pozycja ma historię: skąd pochodzi, dlaczego znalazła się w propozycji, jakie miejsce zajmuje w rankingu. Nie ma tu „bo algorytm tak powiedział". Jest pełna przejrzystość.
Czas poświęcany na ręczne planowanie zamówień spadł radykalnie. Błędy wynikające z pominięcia produktów z listy priorytetowej zniknęły. A cały proces stał się powtarzalny, audytowalny i, co kluczowe dla rosnącej sieci, skalowalny.
Dlaczego to ważne poza tym jednym projektem?
Bo każda sieć handlowa, magazyn czy dystrybutor ma jakiś wariant tego problemu. Ktoś decyduje, co zamówić, ktoś pilnuje priorytetów, ktoś porównuje stany. Często jest to miks Excela, intuicji i telefonu.
Ten projekt pokazuje, że tę logikę można ubrać w kod precyzyjnie, z zachowaniem wszystkich reguł biznesowych i z pełną kontrolą dla użytkownika. Automatyzacja nie musi oznaczać utraty wglądu.
Co było najważniejsze?
Nie samo to, że algorytm działa. Ważne było to, że działa według reguł klienta, nie naszych założeń, nie domyślnych ustawień jakiegoś gotowca.
Każda reguła priorytetyzacji, każde kryterium rankingowe i każdy próg ilościowy to decyzje klienta, które system po prostu realizuje.
I to właśnie jest różnica między narzędziem kupionym z półki a narzędziem zaprojektowanym dla konkretnego problemu.