Kasa w sklepie wie, co się sprzedało, zaś magazyn wie, ile towaru zostało na półce. Dostawca natomiast wie, ile towaru przywiózł, ale ile z tego się sprzedało, często dowiaduje się dopiero z faktury na koniec miesiąca. Trzy różne systemy, trzy różne bazy, trzy różne wersje prawdy o tym samym towarze — i zwykle żadna z nich nie łączy się z pozostałymi.
W istocie nie jest to problem technologiczny, lecz decyzyjny. Kierownik sklepu zamawia towar na podstawie tego, co widzi w swoim komputerze, a nie na podstawie tego, co dzieje się w głównym magazynie czy u dostawcy. W efekcie może pojawić się nadprodukcja tam, gdzie akurat spadł popyt, a puste półki tam, gdzie wzrósł.
W praktyce wygląda to tak: sklep zamawia więcej sera, bo w zeszłym tygodniu dobrze się sprzedawał. Magazyn wysyła zapas zupełnie innego produktu, bo tak wynika z jego własnej prognozy. Dostawca planuje trzeci scenariusz, bo o tym, ile sera faktycznie zeszło z półek, dowie się za kilka tygodni. Trzy racjonalne decyzje, jeden nielogiczny wynik.
Presja, żeby to zmienić, jest realna. Marże w handlu detalicznym się kurczą, a klient oczekuje dostępności produktu tu i teraz. W takich warunkach różnica między sklepem, który wie, co dzieje się w magazynie w czasie rzeczywistym, a takim, który dowiaduje się tego następnego dnia, przestaje być kosmetyczna.
Ostatnio o retailu mówi się głównie przez pryzmat sztucznej inteligencji i predykcji popytu. To kuszący temat, ale przeskakuje etap, bez którego żaden model prognostyczny nie ma czego przewidywać. Zanim padnie słowo „predykcja”, warto przyjrzeć się trzem konkretnym przypadkom, które pokazują, jak wygląda droga od rozrzuconych danych do modelu, który faktycznie dokładnie coś przewiduje.
Dane, które w końcu się ze sobą dogadały
Sieć sklepów kosmetycznych, obecna w ponad pięćdziesięciu krajach i licząca blisko tysiąc lokalizacji, przez lata miała dokładnie ten problem z rozjazdem systemów. Dane sprzedażowe, magazynowe i produkcyjne żyły całkowicie odseparowane. Dopiero połączenie ich w jednym systemie dało coś więcej niż ładny dashboard. Qlik stał się tym samym warstwą integrującą punkty sprzedaży, magazyny i zakład produkcyjny. W efekcie dało to wspólny obraz, dostępny jednocześnie dla sklepu, magazynu i produkcji.
Efekty okazały się policzalne – ponad milion funtów oszczędności na stratach magazynowych w ciągu dwóch lat. Nie dlatego, że ktoś kupił nowe narzędzie analityczne. Dlatego, że dział zakupów mógł wreszcie planować zamówienia na podstawie tego, co faktycznie działo się w sklepach, a nie na podstawie prognozy sprzed miesiąca.
Znaczące jest też to, kto z tych danych korzystał. Nie był to wąski zespół analityków, tylko siedmiu na dziesięciu pracowników logujących się do systemu codziennie — ludzie na hali sklepowej i w magazynie, a nie tylko w centrali.
Szybkość jako osobna kategoria
Druga sieć — tym razem odzieżowa, kilkaset sklepów w Stanach, Europie i Wielkiej Brytanii — miała inny problem. Dane owszem, spływały, ale zbyt wolno, aby to miało znaczenie. Raport sprzedażowy, który trafiał do centrali po kilku godzinach, w praktyce opisywał przeszłość, nie teraźniejszość.
Zmiana polegała na przeniesieniu strumienia danych — kilkadziesiąt gigabajtów dziennie — bezpośrednio do chmury, z Qlikiem jako warstwą integracji. Raporty, które wcześniej zajmowały godziny, są dziś gotowe niemal na zawołanie. Dane z centrów dystrybucyjnych trafiają do systemu w mniej niż pięć minut od zdarzenia.
To inna kategoria wartości niż w przypadku sieci kosmetycznej. Nie chodzi o połączenie systemów, które wcześniej się nie widziały, tylko o skrócenie dystansu między zdarzeniem a decyzją.
Trzeci poziom: przewidywanie zamiast reagowania
Trzeci przykład idzie o krok dalej. Producent żywności zaopatrujący sieci sklepów, który musiał codziennie decydować, ile faktycznie wyprodukować, zaczął korzystać z modelu predykcyjnego opartego na historii zamówień, wcześniejszych wzorcach zakupowych, pogodzie, wielkości sklepu, lokalizacji dostawy i kalendarzu świąt.
Prognozy trafiały z dokładnością przekraczającą 90 procent. W dziesięciodniowym teście różnica między prognozą a rzeczywistym zamówieniem wyniosła około jednego procenta. Mniej nadprodukcji, mniej zmarnowanej żywności, mniej ryzyka, że produkt trzeba będzie przecenić, bo nie zdążył trafić na półkę we właściwym czasie.
Jest jedno zastrzeżenie. Predykcja tego typu nie działa w oderwaniu od dwóch poprzednich poziomów. Model, który dostaje dane opóźnione o tydzień albo niepełne, bo magazyn i sklep wciąż mówią różnymi językami, będzie przewidywał równie trafnie co prognoza pogody czytana z fusów. Najpierw integracja i szybkość, a potem predykcja, która nie jest zastępstwem.
Przykład z bliższego podwórka
Wszystkie trzy historie pochodzą spoza Polski, więc łatwo je zbyć wzruszeniem ramion. Czwarta jest stąd.
Duża sieć spożywcza, sklepy w całej Polsce, program lojalnościowy z aplikacją. Tym razem problem nie dotyczył półek ani magazynu, tylko ludzi. Sieć nie wiedziała, którzy klienci po cichu przestają przychodzić, więc kupony i powiadomienia szły do wszystkich naraz. „Działaliśmy trochę jak dzieci we mgle” – mówi osoba zaangażowana we wdrożenie.
Najpierw trzeba było ustalić, kogo w ogóle uznać za utraconego klienta. Reguła okazała się prosta: kto przez kilkanaście dni nic nie kupił, trafia pod lupę. Jeśli wróci w ciągu mniej więcej półtora miesiąca, nic się nie stało, mógł wyjechać na urlop. Jeśli nie wróci, sieć go straciła.
Qlik Predict (wtedy jeszcze pod nazwą AutoML) dostał na start kilkadziesiąt zmiennych, część wymyślonych razem z biznesem. Na przykład: czy klient zaczął robić zakupy w innym mieście? Może się przeprowadził. Po treningu zostało kilka, i to tych najmniej efektownych: liczba transakcji w ostatnich miesiącach, obrót, długość przerw między zakupami. Zespół szykował się na coś wyrafinowanego. Wyszło to, co powie każdy kierownik sklepu: kto przestaje kupować, ten odchodzi, bo przecież gdzieś musi jeść. Różnica polega na tym, że teraz wiadomo, który to konkretnie klient.
Na danych testowych, których model wcześniej nie widział, poprawnie zaklasyfikował ponad 90 proc. klientów. Ciekawsze jest to, gdzie się mylił. Za zagrożonego odejściem uznał kogoś, kto i tak by wrócił, zaledwie w kilku procentach przypadków. Niepotrzebny kupon byłby więc rzadkością.
Wynik ląduje w zwykłym arkuszu: identyfikator klienta i prawdopodobieństwo odejścia, liczone codziennie. Marketing może dołożyć własne filtry, np. posiadaczy Karty Dużej Rodziny, i do nich kierować akcję. W przykładowej próbce kilkuset klientów co dziesiąty miał ryzyko odejścia powyżej 70 proc.
Integracja danych też tu była: dziesięć źródeł, zapytanie SQL na kilkaset linijek kodu, a w nim nagłówki paragonów, pozycje, promocje i kupony. Tyle że kolejność była odwrotna niż w schemacie opisanym wyżej. Te dane zawsze dało się połączyć. Nikt tego nie robił, bo nie było takiej potrzeby. Powód pojawił się dopiero razem z pytaniem, kto odchodzi.
Trzy poziomy i jedna oś
Te trzy przykłady to nie przypadkowy zestaw case studies. To trzy etapy tej samej drogi: najpierw trzeba połączyć dane, które wcześniej żyły osobno, potem skrócić czas między zdarzeniem a raportem, na końcu zacząć przewidywać, zanim coś się wydarzy. Firmy rzadko przechodzą przez nie w tej kolejności świadomie — częściej trafiają na etap trzeci, bo etap pierwszy mają już za sobą, tylko nikt tego tak nie sprecyzował.
O efekcie decyduje jakość i dostępność danych, a nie moda na sztuczną inteligencję. Sieć, która nie potrafi połączyć kasy z magazynem, nie ma szans na sensowną predykcję popytu — niezależnie od tego, jak dobry model LLM nabędzie.
Różnica jest w skali, ale nie w samym mechanizmie. Sieć z pięciuset sklepami w Europie Zachodniej i sieć z dwudziestoma placówkami w Polsce mają ten sam problem strukturalny: kasa, magazyn i dostawca liczą inaczej i osobno. Różnica jest w budżecie i tempie wdrożenia, nie w logice rozwiązania.
Retail nie potrzebuje więcej modeli predykcyjnych. Potrzebuje, aby magazyn i kasa korzystały z tych samych danych.
