Prognozowanie popytu z AI. Najpierw sprawdźcie, czy pobijecie prognozę, która nic nie kosztuje

Co właściwie obiecuje to wdrożenie

W firmie handlowej, dystrybucyjnej albo produkcyjnej zamówienia planuje zwykle jedna albo dwie osoby, na podstawie raportu sprzedaży, kalendarza i pamięci. Działa to lepiej, niż przyznają entuzjaści automatyzacji — człowiek wie o wejściu nowego klienta, o promocji, o tym, że dostawca ma trzytygodniowe opóźnienie. Działa też gorzej, niż przyznaje firma: przy dwóch tysiącach pozycji nikt nie planuje dwóch tysięcy pozycji. Planuje się dwadzieścia najważniejszych, a resztę zamawia odruchowo.

Tu jest cała obietnica tego wdrożenia i warto ją nazwać precyzyjnie, bo zwykle jest nazywana źle. Nie chodzi o to, żeby model przewidział popyt lepiej niż Wasz najlepszy planista na jego dwudziestu pozycjach. Chodzi o to, żeby pozostałe tysiąc dziewięćset osiemdziesiąt pozycji przestało być zamawiane odruchowo. Wartość leży w ogonie asortymentu, nie w czołówce.

I drugi, równie konkretny efekt: skrócenie cyklu. Jeśli dziś przygotowanie zamówienia do głównego dostawcy zajmuje dwa dni pracy, a robi się to raz w miesiącu, to firma reaguje na popyt z miesięcznym opóźnieniem. Kiedy ta sama praca zajmuje dwie godziny, można zamawiać co tydzień — a tygodniowy cykl zamówień poprawia dostępność towaru bardziej niż jakakolwiek poprawa trafności prognozy. To jest najczęściej przeoczana korzyść całego projektu.

Punkt odniesienia, który kosztuje zero złotych

Zanim ktokolwiek wyceni narzędzie, potrzebujecie jednej liczby: o ile Wasza obecna praktyka jest lepsza od prognozy naiwnej. Prognoza naiwna to reguła bez modelu i bez myślenia — „w przyszłym miesiącu sprzedamy tyle, ile w zeszłym” albo, przy sezonowości, „tyle, ile rok temu w tym samym miesiącu”. Policzycie ją w arkuszu w ciągu jednego dnia na trzech latach historii.

Metoda porównywania nazywa się Forecast Value Added i jest wyjątkowo prosta: każdy kolejny krok procesu prognozowania ma prawo istnieć tylko wtedy, gdy poprawia wynik poprzedniego kroku. Naiwna prognoza jest punktem zerowym. Potem model statystyczny — ile dodał. Potem korekta ręczna planisty — ile dodała. W literaturze branżowej opisywane są przypadki, w których model statystyczny poprawiał naiwną prognozę o kilka punktów procentowych, a następująca po nim korekta kierownictwa pogarszała wynik — czyli miała ujemną wartość dodaną. W jednym z klasycznych przykładów prognoza po korektach handlowych miała błąd 10%, a naiwna 5%.

Z tego wynika praktyczny wniosek, który oszczędza firmom bardzo dużo pieniędzy: jeśli nie znacie swojego punktu odniesienia, nie da się ocenić żadnej oferty. Dostawca powie „poprawiamy trafność o 25%” i nie będzie kłamał — tylko że nie wiadomo, o 25% względem czego. Mając liczbę bazową, rozmowa wygląda inaczej: tu jest nasz błąd naiwny, tu nasz obecny, pokażcie wynik na naszych danych.

Co ważne, ten jeden tydzień pracy ma wartość niezależnie od tego, czy wdrożenie dojdzie do skutku. Firmy regularnie odkrywają przy tym ćwiczeniu, że mają trzy kategorie towaru, których nie da się sensownie prognozować w ogóle, i że tam problemem jest polityka zamówień, nie prognoza.

Dlaczego do tego zadania nie używa się ChatGPT

To wdrożenie trafia dziś w firmach do tej samej szuflady, co chatbot i asystent dokumentowy, i jest to pomyłka kategorialna, która kosztuje kilka miesięcy. Przewidywanie liczb z historii sprzedaży jest zadaniem dla modelu szeregów czasowych albo gradient boostingu na tabeli cech — nie dla modelu językowego. Model językowy wkleja się do tego świetnie na demie i jest w tej roli najdroższym i najmniej przewidywalnym możliwym rozwiązaniem.

Warto znać stan faktyczny, bo on też bywa przekręcany. Zawody M5, rozegrane na danych sprzedażowych Walmartu, były pierwszym dużym porównaniem, w którym metody uczenia maszynowego pobiły wszystkie klasyczne benchmarki statystyczne — pięćdziesiąt najlepszych zgłoszeń przewyższało najlepszy benchmark statystyczny o ponad 14%, a czołowa piątka o ponad 20%. Zwycięskie rozwiązania opierały się w dużej mierze na LightGBM, czyli bibliotece, którą uruchomicie na zwykłym laptopie. To jest „AI” w tym wdrożeniu: nudna, dobrze zbadana i tania.

Model językowy ma w tym projekcie dwie sensowne role, obie poboczne. Pierwsza: zamiana danych jakościowych na cechy, których w tabeli nie ma — informacja o promocji z maila od dostawcy, zapowiedź otwarcia nowego punktu, treść zamówienia opisowego. Druga: wyjaśnianie prognozy człowiekowi, czyli odpowiedź na pytanie „dlaczego system proponuje zamówić dwa razy więcej niż ostatnio”. Ta druga rola jest zresztą tym, co decyduje o tym, czy planista zacznie z systemu korzystać. Jak podłączyć pytania w języku naturalnym do firmowych danych, opisaliśmy w tekście o pytaniach do danych firmy. Granicę między automatyzacją a autonomicznym agentem rozpisaliśmy w tekście agent AI czy zwykła automatyzacja.

Popyt przerywany, czyli miejsce, w którym łamią się wszystkie dema

Demo prognozowania pokazuje wykres sprzedaży produktu, który sprzedaje się codziennie. Wasz asortyment tak nie wygląda. W typowej firmie dystrybucyjnej większość pozycji sprzedaje się w kilku, kilkunastu dniach w roku, a w pozostałych dniach historia zawiera zero. To się nazywa popyt przerywany i jest zupełnie innym problemem matematycznym.

Z zerami w historii łamią się dwie rzeczy naraz. Po pierwsze miara błędu: najpopularniejszy wskaźnik MAPE jest procentem od wartości rzeczywistej, więc przy sprzedaży zero jest po prostu niepoliczalny — dzielenie przez zero. Jeśli ktoś pokazuje Wam MAPE dla całego asortymentu, to albo wyrzucił z obliczeń pozycje z zerami, albo podstawił coś w ich miejsce; w obu przypadkach liczba na slajdzie dotyczy innego asortymentu niż Wasz. Po drugie łamie się sam model, bo metody zaprojektowane dla ciągłej sprzedaży z sezonowością na przerywanym popycie zachowują się nieprzewidywalnie.

Rozwiązanie jest znane od lat siedemdziesiątych i nazywa się metodą Crostona — prognozuje się osobno wielkość pojedynczego zamówienia i osobno odstęp między zamówieniami. Nowsze warianty działają lepiej, ale sens jest ten sam. Praktyczny wniosek dla firmy: asortyment trzeba podzielić, zanim wybierze się jakąkolwiek metodę.

• Pozycje o regularnej sprzedaży i wyraźnej sezonowości. Tu uczenie maszynowe faktycznie dowozi poprawę i tu ma sens cały projekt. Zwykle to kilka do kilkunastu procent asortymentu i większość obrotu.
• Pozycje o popycie przerywanym, ale przewidywalnej częstotliwości. Osobna metoda, osobna miara błędu, prognoza traktowana jako rozkład, nie jako jedna liczba.
• Pozycje jednorazowe, projektowe i nowe. Nie mają historii, więc nie mają prognozy — i udawanie, że mają, jest głównym źródłem martwego towaru. Tu decyduje polityka: zamówienie pod potwierdzone zapotrzebowanie, zapas zerowy, krótszy cykl dostaw.
• Pozycje krytyczne o niskiej rotacji — części serwisowe, komponenty bez zamiennika. Prognoza jest tu drugorzędna, bo decyzję podejmuje koszt braku, nie trafność. Zapas ustala się regułą, nie modelem.

Trafność prognozy to nie to samo co dostępność towaru

To jest najważniejszy punkt całego tekstu i jednocześnie ten, który najłatwiej przegapić, bo cały przemysł narzędziowy mówi o trafności. Trafność jest cechą liczby. Wam zależy na dwóch zupełnie innych rzeczach: żeby towar był, kiedy klient pyta, i żeby pieniądze nie leżały w magazynie. Te trzy wielkości nie są tym samym i dają się rozjechać.

Mechanizm jest asymetryczny. Pomyłka w górę kosztuje zamrożony kapitał, miejsce i ryzyko przeceny — koszt realny, ale rozłożony w czasie. Pomyłka w dół kosztuje utraconą marżę, czasem utraconego klienta, czasem karę z umowy. Dla większości asortymentu te dwa koszty różnią się kilkukrotnie, a model minimalizujący błąd symetrycznie traktuje je identycznie. Dlatego systemowi nie zadaje się pytania „ile sprzedamy”, a pytanie „ile zamówić, żeby z prawdopodobieństwem 95% nie zabrakło” — czyli prognozę traktuje się jako rozkład, a nie punkt. Nowsze prace nad popytem przerywanym idą dokładnie w tym kierunku: ocenia się decyzję i jej koszt, nie sam błąd prognozy.

Praktyczna konsekwencja dla odbioru wdrożenia: w umowie i w testach obok błędu prognozy muszą stać trzy liczby biznesowe — poziom obsługi (odsetek zamówień zrealizowanych z zapasu), wartość zapasu i liczba pozycji zalegających powyżej ustalonego progu. Można poprawić trafność i pogorszyć wszystkie trzy. Można też odwrotnie, i to jest ten przypadek, za który płacicie.

Osobno pilnujcie jednej rzeczy, którą trafność ukrywa całkowicie: systematycznego przesunięcia prognozy w jedną stronę. Model, który myli się po równo w górę i w dół, jest nieprzyjemny. Model, który myli się przeciętnie o tyle samo, ale zawsze w dół, cicho obniża Wam poziom obsługi przez cały rok.

Dane, których naprawdę potrzebujecie

Lista jest krótsza, niż się w firmach sądzi, i zawiera dokładnie jedną pozycję, której prawie nigdy nie ma.

• Historia sprzedaży na poziomie pozycji i dnia, minimum dwa pełne lata, a przy wyraźnej sezonowości trzy. Krótsza historia nie pozwala rozpoznać sezonowości i to twarde ograniczenie, nie kwestia modelu.
• Historia braków i odmów — pozycja, której nie było na stanie. To jest ta brakująca dana. Sprzedaż pokazuje popyt zrealizowany, nie popyt. Jeśli towaru nie było, w historii jest zero i model uczy się, że nikt go nie chciał, a potem sam utrwala brak. Jeśli nie macie tego rejestru, zacznijcie go prowadzić dziś — będzie potrzebny za rok niezależnie od wdrożenia.
• Kalendarz promocji i zmian cen, z datami. Bez tego każda promocja z przeszłości jest dla modelu niewyjaśnionym skokiem popytu, który uzna za sezonowość i powtórzy w prognozie.
• Rzeczywiste czasy realizacji od dostawców, nie te z umowy. Prognoza popytu bez czasu dostawy nie daje się przełożyć na zamówienie, a różnica między „czternaście dni” z cennika i realnymi dwudziestoma trzema jest tym, co faktycznie generuje braki.
• Mapowanie zamienników i pozycji wycofanych. Produkt, który zastąpił inny, bez tego powiązania startuje bez historii, a jego poprzednik zostaje w danych jako pozycja, której sprzedaż spadła do zera.

Dlaczego to zwykle nie jest projekt o AI

W większości firm, do których wchodzimy z tym tematem, pierwsze trzy tygodnie nie mają nic wspólnego z modelami. Dwie bazy mają różne kody tego samego towaru. Jednostki miary są pomieszane — część pozycji w sztukach, część w opakowaniach zbiorczych, bez informacji o przeliczniku. Zwroty figurują jako sprzedaż ujemna w jednym systemie i jako korekta w drugim. Sprzedaż wewnętrzna między magazynami podwaja wolumen.

Nie jest to argument przeciw wdrożeniu, tylko informacja o tym, gdzie leży koszt — i o tym, że porządek w tych danych ma wartość sam w sobie, bo ten sam bałagan zaniża dziś Wasze raporty. Metodę szybkiego sprawdzenia, w jakim stanie są dane, opisaliśmy w tekście o danych gotowych na AI, a to, co da się wyciągnąć z ustrukturyzowanych faktur, w tekście o danych z KSeF.

Jest też druga strona tej obserwacji, dla firm, które porządek mają: jeśli dane są czyste i macie ERP z sensownym eksportem, to pierwsza użyteczna wersja powstaje w dwa, trzy tygodnie i nie wymaga żadnej platformy. Rozpiętość kosztu tego projektu między firmą uporządkowaną i nieuporządkowaną jest dziesięciokrotna — i to dane, nie model, o niej decydują.

Czego ten system nie powinien móc zrobić

Prognozowanie jest niegroźne. Zamawianie już nie, a te dwie rzeczy w narzędziach bywają sklejone jednym przyciskiem.

• Składać zamówień bez zatwierdzenia przez człowieka, dopóki nie przejdzie kilku pełnych cykli obserwowanych. Potem automatycznie — ale z twardym limitem wartości pojedynczego zamówienia i progiem, powyżej którego pozycja wraca do akceptacji.
• Zmieniać progów zapasu bezpiecznego bez zapisu kto, kiedy i dlaczego. Ciche przesunięcie progu jest zmianą kapitału obrotowego firmy i musi być widoczne w historii.
• Prognozować pozycji bez historii. System ma odpowiedzieć „brak danych”, a nie wygenerować liczbę. Prognoza z niczego wygląda identycznie jak prognoza z trzech lat danych i to jest cała trudność.
• Podawać prognozy bez przedziału. Jedna liczba zachęca do traktowania jej jako faktu. „Między 40 a 70, najbardziej prawdopodobne 52” prowadzi do innej decyzji niż „52” — i to ta pierwsza jest uczciwa.
• Działać na danych pozwalających zidentyfikować klientów, jeśli prognoza ich nie potrzebuje. Do planowania zapasu wystarcza wolumen na pozycji; dane osobowe w tym zbiorze są zbędnym ryzykiem, a obowiązki wokół nich rozpisaliśmy w tekście o RODO przy wdrożeniu AI.

Rachunek, który trzeba zrobić przed rozmową z dostawcą

Koszt obliczeń jest w tym projekcie pomijalny i warto to powiedzieć wprost, bo wyceny bywają budowane tak, jakby był głównym składnikiem. Model gradient boostingu na dwóch tysiącach pozycji i trzech latach historii liczy się minuty na jednej maszynie. Realny koszt to przygotowanie danych, integracja z ERP i zbudowanie zestawu testowego — przy typowym bałaganie kilkadziesiąt do stu kilkudziesięciu godzin pracy kogoś, kto rozumie i dane, i magazyn. Anatomię takiego budżetu rozpisaliśmy w tekście ile kosztuje wdrożenie AI.

Korzyść liczcie na trzech swoich liczbach, nie na procentach z cudzych wdrożeń. Pierwsza: wartość zapasu, który nie obrócił się przez ostatnie dwanaście miesięcy — to kapitał, który leży. Druga: liczba zamówień niezrealizowanych z zapasu w ostatnim kwartale, pomnożona przez średnią marżę. Trzecia: godziny, które dwie osoby spędzają miesięcznie na przygotowywaniu zamówień. Suma dwóch pierwszych jest zwykle o rząd wielkości większa niż trzecia, a mimo to prezentacje handlowe mówią głównie o trzeciej.

I jeden warunek odrzucenia projektu, który warto ustalić z góry: jeśli po policzeniu prognozy naiwnej okaże się, że Wasz obecny proces poprawia ją o kilkadziesiąt procent, a asortyment ma dwieście pozycji, to tu nie ma czego wdrażać. Ten projekt opłaca się tam, gdzie pozycji jest dużo, a uwagi planisty mało. Szersza lista procesów wartych automatyzacji w pierwszej kolejności jest w tekście o siedmiu procesach do automatyzacji.

Wdrożenie w sześć tygodni

Kolejność ma tu znaczenie, bo pierwszy tydzień jest najmniej efektowny i najczęściej pomijany — a to on decyduje, czy w szóstym tygodniu będzie wiadomo, czy to zadziałało.

1. Tydzień pierwszy: prognoza naiwna i podział asortymentu. Policzcie błąd naiwny i błąd swojego obecnego procesu na tej samej historii. Podzielcie pozycje na cztery grupy z sekcji o popycie przerywanym. Ustalcie, które grupy wchodzą w zakres, a które dostają politykę zamówień zamiast prognozy.
2. Tydzień drugi: dane. Eksport historii z ERP, uzgodnienie jednostek i kodów, usunięcie sprzedaży wewnętrznej, doklejenie kalendarza promocji i rzeczywistych czasów dostaw. Uruchomienie rejestru braków, jeśli go nie było.
3. Tydzień trzeci: zestaw testowy na przesuwanym oknie. Model uczy się na danych do pewnej daty i prognozuje okres, którego nie widział — i tak kilkanaście razy wzdłuż historii. Jednorazowy podział danych na dwie części wystarcza, żeby wynik wyglądał dobrze i nic nie znaczył. Metodę budowania takich zestawów rozpisaliśmy w tekście o testowaniu wdrożenia AI.
4. Tydzień czwarty: model na grupie pierwszej i porównanie z naiwną prognozą oraz z obecnym procesem, na tych samych okresach. Obok błędu liczone trzy miary biznesowe: poziom obsługi, wartość zapasu, pozycje zalegające. Jeśli model nie pobija naiwnej prognozy na grupie pierwszej, nie ma sensu rozszerzać zakresu — trzeba wrócić do danych.
5. Tydzień piąty: praca równoległa. System generuje propozycje zamówień, planista decyduje jak dotąd, obie wersje są zapisywane i porównywane po fakcie. Każda korekta planisty z jednozdaniowym uzasadnieniem — to jest Wasze główne źródło brakujących cech i jednocześnie pomiar, czy korekty dodają wartość.
6. Tydzień szósty: decyzja o zakresie. Grupa, na której system wygrywa, przechodzi na propozycje zatwierdzane jednym kliknięciem; pozostałe wracają do polityki zamówień. Dalej, raz w miesiącu: przegląd przesunięcia prognozy, korekt planisty i pozycji nowych — bo asortyment starzeje się szybciej niż model, co opisaliśmy w tekście o utrzymaniu AI po wdrożeniu.

Cztery sygnały, że poszło w złą stronę

• Nie znacie swojego błędu naiwnego. Bez tej liczby każda poprawa jest nieweryfikowalna, a każda oferta nieporównywalna. To jedyny punkt z tej listy, który dyskwalifikuje projekt natychmiast.
• Trafność rośnie, a braki na półce nie maleją. Oznacza to, że poprawa dotyczy pozycji, które i tak były przewidywalne, albo że model przesunął się systematycznie w dół. Mierzcie poziom obsługi osobno, bo on jest celem, a trafność tylko środkiem.
• Planista koryguje większość propozycji. To nie jest opór przed zmianą, tylko informacja: model nie widzi czegoś, co widzi człowiek — zwykle promocji, wejścia klienta albo zamiennika. Rozwiązaniem jest dodanie tej danej jako cechy, nie przekonywanie planisty.
• Prognozy pojawiają się dla pozycji nowych i jednorazowych. System zgaduje tam, gdzie nie ma z czego prognozować, i to jest najkosztowniejszy cicho działający błąd tego wdrożenia — powstaje z niego martwy towar, którego nikt nie wiąże z narzędziem.

Od czego zacząć

Jeden konkret na ten tydzień, bez narzędzia i bez budżetu: wyciągnijcie trzy lata historii sprzedaży, policzcie w arkuszu prognozę naiwną na poziomie miesiąca i porównajcie ją z tym, co faktycznie zamówiliście. Dzień pracy. Dostaniecie dwie rzeczy: liczbę, bez której nie da się ocenić żadnej oferty, i listę pozycji, których Wasz obecny proces nie dotyka w ogóle — bo to w nich, a nie w czołówce asortymentu, leżą pieniądze tego projektu.

Warto przy tym pamiętać o szerszym kontekście: badania z 2026 roku pokazują, że polskie MŚP przeszły z fazy entuzjazmu do fazy liczenia efektów — udział firm planujących zwiększyć wydatki na AI spadł z blisko połowy do około jednej czwartej w ciągu pół roku. Prognozowanie popytu jest jednym z niewielu zastosowań, które ten test przechodzą, ale tylko wtedy, gdy ktoś zmierzył punkt wyjścia.

Takie wdrożenia prowadzimy wąsko i mierzalnie: najpierw prognoza naiwna jako punkt odniesienia, potem podział asortymentu, test na przesuwanym oknie, trzy miary biznesowe obok błędu i praca równoległa z planistą, zanim cokolwiek zacznie zamawiać samo. Jeśli macie więcej niż kilkaset pozycji, a zamówienia planuje się z pamięci i raportu, umówcie bezpłatną konsultację albo zobaczcie, jak wygląda nasz konsulting i wdrożenia AI.