Agent AI do zarządzania zapasami w retail: prognozy, zamówienia i kontrola
Agent AI może wspierać planowanie zapasów, ale nie powinien samodzielnie zamawiać towaru bez kontroli. Praktyczny przewodnik po danych POS/ERP, akceptacji człowieka, logach i pilotażu.
W zapasach retailowych najdroższe błędy rzadko wynikają z braku modelu. Częściej zaczynają się od nieczystych danych, niejasnych reguł zamawiania i decyzji bez śladu audytowego.
Syntalith Team
Agent AI do zapasów nie jest magicznym buyerem, który "wie", ile zamówić. W praktyce dobry system robi coś mniej efektownego i bardziej użytecznego: czyści obraz danych, wskazuje ryzyka, przygotowuje propozycje zamówień i zatrzymuje się przed decyzją, która wiąże pieniądze albo zmienia stan w ERP.
To ważne rozróżnienie. Jeśli agent ma dostęp do POS, ERP, e-commerce, arkuszy, portali dostawców i poczty zakupowej, to nie jest już chatbot. To element procesu operacyjnego. Trzeba go projektować jak system z uprawnieniami, logami, wyjątkami i odpowiedzialnością człowieka.
McKinsey opisuje predykcyjne planowanie popytu jako obszar, w którym analityka może korzystać z wielu zmiennych, na przykład pogody, trendów i danych sprzedażowych. To nie jest jednak gwarancja wyniku dla konkretnego sklepu. W retailu najpierw trzeba sprawdzić, czy dane bazowe nadają się do modelowania.
Problem zapasów i rola prognozy
W rozmowach o zapasach łatwo sprowadzić temat do "AI przewidzi popyt". To zbyt wąskie. Nawet dobry model nie naprawi procesu, w którym:
- sprzedaż z POS nie zgadza się ze stanem magazynowym,
- zwroty i anulacje są księgowane z opóźnieniem,
- warianty produktów są dublowane pod różnymi SKU,
- promocje nie mają historii i opisu mechaniki,
- lead time dostawcy jest wpisany raz i nigdy nieaktualizowany,
- buyer zamawia inaczej, niż wynika z oficjalnej polityki zapasu,
- korekty stanów nie mają powodu, autora i daty.
W takim środowisku agent będzie produkował eleganckie sugestie na krzywych danych. Dlatego pierwszy etap nie powinien brzmieć "podłączmy model", tylko "ustalmy, które dane są wiarygodne i kto odpowiada za wyjątki".
Co agent powinien robić
1. Budować roboczy obraz zapasu
Agent może codziennie zestawiać dane z POS, ERP, e-commerce i magazynu. Celem jest wykrycie niespójności w systemie źródłowym:
- SKU z ujemnym stanem,
- produkty sprzedające się mimo braku dostępności w ERP,
- różnice między sklepem internetowym i magazynem,
- zamówienia dostawców bez potwierdzonego terminu,
- towary z wysokim zapasem i niską rotacją,
- produkty sezonowe bez oznaczonego sezonu,
- historyczne promocje bez daty, rabatu lub kanału.
To nudna część wdrożenia, ale bez niej prognozowanie popytu jest dekoracją. Retail potrzebuje jednego roboczego widoku decyzji: ile mamy, ile sprzedajemy, co jest już zamówione, kiedy dojedzie i gdzie model nie ufa danym.
2. Prognozować z zakresem i ryzykiem
Dobra prognoza nie powinna udawać jednej pewnej liczby. Przy zapasach ważne są zakresy i ryzyka:
- scenariusz bazowy,
- scenariusz ostrożny,
- scenariusz przy promocji lub nagłej zmianie popytu,
- informacja, które SKU mają zbyt mało historii,
- wyjaśnienie, jakie zmienne miały wpływ na rekomendację.
Agent może uwzględniać historię sprzedaży, sezonowość, kalendarz promocji, poziom cen, dostępność dostawcy, lokalizację sklepu i dane zewnętrzne, jeżeli są realnie dostępne. Nie powinien natomiast obiecywać stałej dokładności typu "95%". Dokładność zależy od kategorii, rotacji, promocji, braków historycznych i jakości danych.
Praktyczny wynik prognozy wygląda tak:
| Element | Przykład dobrej odpowiedzi |
|---|---|
| SKU | "Produkt A, wariant 500 ml" |
| Rekomendacja | "Zamów 120 sztuk do magazynu centralnego" |
| Uzasadnienie | "Rotacja rośnie od 3 tygodni, promocja zaczyna się 14 marca, dostawca ma lead time 9 dni" |
| Niepewność | "Wysoka, bo ostatnie 2 promocje miały różną mechanikę" |
| Decyzja | "Do zatwierdzenia przez buyera" |
3. Przygotowywać propozycje zamówień
Bezpieczny wzorzec kończy się propozycją do zatwierdzenia. Agent może przygotować koszyk zakupowy. Samodzielne zamówienie wymaga osobnej zgody osoby z odpowiednim uprawnieniem.
W propozycji zamówienia powinno być widać:
- produkt i lokalizację,
- sugerowaną ilość,
- aktualny stan i sprzedaż z ostatnich okresów,
- otwarte zamówienia i przewidywany termin dostawy,
- minimalną ilość zamówienia, opakowania zbiorcze i progi logistyczne,
- alternatywnego dostawcę, jeżeli obecny ma ryzyko opóźnienia,
- powód rekomendacji,
- poziom pewności,
- datę, autora decyzji i zmiany wprowadzone przez człowieka.
Agent może też grupować pozycje pod jednego dostawcę, wyłapywać progi darmowej dostawy albo wskazywać konflikt między minimalnym zamówieniem a niską rotacją. To nadal nie znaczy, że powinien bez pytania wysyłać zamówienie do EDI, maila albo portalu B2B.
4. Alarmować o wyjątkach
Największa wartość często nie leży w "optymalnym" zamówieniu, tylko w szybkim wykryciu wyjątków:
- topowe SKU schodzą szybciej niż zwykle,
- dostawca opóźnia kolejne dostawy,
- towar sezonowy został zamówiony za późno,
- stan magazynowy zmienił się ręczną korektą,
- produkt ma zapas, ale nie jest dostępny online,
- termin przydatności wymaga decyzji handlowej,
- model nie ufa prognozie i prosi o ręczną ocenę.
Takie alerty powinny trafiać do konkretnych ról. Inny alert dostaje buyer, inny kierownik sklepu, inny osoba odpowiedzialna za dane produktowe.
Czego agent nie powinien robić bez akceptacji
Domyślnie zatrzymałbym automatyzację przed działaniami, które mają koszt, zmieniają kontrakt albo wpływają na klienta:
- wysłanie zamówienia do dostawcy,
- zmiana ceny sprzedaży,
- uruchomienie promocji,
- anulowanie zamówienia,
- zmiana dostawcy,
- przeniesienie dużej partii między magazynami,
- korekta stanu magazynowego,
- decyzja o utylizacji, zwrocie albo przecenie,
- eksport danych klienta do zewnętrznego modelu.
W praktyce agent może robić draft. Człowiek zatwierdza, edytuje albo odrzuca. Każda z tych decyzji zostaje w logu.
Architektura kontrolowanego procesu
Nie ma jednej technologii, która sama rozwiązuje zapasy. Sensowna architektura rozdziela model, przebieg procesu, integracje i audyt.
LangGraph / LangChain. Dobre do procesów stanowych, w których agent ma narzędzia i punkty przerwania. Dokumentacja LangGraph opisuje zatrzymanie procesu przed wrażliwą akcją i wznowienie go po decyzji człowieka.
n8n. Przydatne do integracji: harmonogramów, webhooków, pobierania danych z API, powiadomień i obsługi błędów. Dokumentacja n8n pokazuje historię wykonań i strumień logów. Własny audyt decyzji biznesowych nadal jest potrzebny.
OpenClaw albo podobne środowisko agentowe. Może służyć jako orkiestrator narzędzi, ale trzeba je traktować jak konto techniczne z uprawnieniami. Jeżeli środowisko może czytać pliki, wywoływać API albo wysyłać wiadomości, jego zakres działania musi być ograniczony.
Hermes Agent. To środowisko zbudowane przez Nous, które obsługujemy jako warstwę wykonawczą agenta. Nie jest modelem lokalnym i sam jego wybór nie zapewnia jakości prognozy, zgodności z RODO ani kontroli uprawnień.
RAG. Przydaje się do wyszukiwania w politykach zakupowych, umowach dostawców, cennikach, instrukcjach logistycznych i wyjątkach kategorii. Nie powinien być źródłem aktualnego stanu magazynowego. Stan powinien pochodzić z systemów transakcyjnych.
Uprawnienia, logi i obserwowalność
Minimalny zestaw kontroli:
- osobne konto techniczne dla integracji,
- odczyt danych tam, gdzie wystarczy odczyt,
- osobne uprawnienie na przygotowanie propozycji i osobne na zatwierdzenie zamówienia,
- limit wartości zamówienia, powyżej którego wymagane jest drugie zatwierdzenie,
- allowlista dostawców i endpointów,
- log wejść: które dane POS/ERP były użyte,
- log rekomendacji: co agent zaproponował i dlaczego,
- log decyzji: kto zatwierdził, zmienił albo odrzucił propozycję,
- log wykonania: czy zamówienie trafiło do ERP, EDI, maila lub portalu,
- alerty przy braku danych, opóźnionych integracjach i nietypowych zmianach,
- możliwość odtworzenia decyzji po kilku miesiącach.
Obserwowalność jest tu częścią produktu i wymaga osobnego utrzymania. Bez niej nie wiadomo, czy problem wynikał z modelu, złego stanu w ERP, opóźnionego importu POS, ręcznej korekty czy decyzji człowieka.
RODO przy danych osobowych
Wiele wdrożeń do zapasów może działać na danych zagregowanych: SKU, lokalizacja, sprzedaż dzienna, stan, dostawca, zamówienie. Wtedy RODO może mieć ograniczone znaczenie.
Sytuacja zmienia się, gdy system używa danych klienta:
- koszyków przypisanych do konta,
- historii zakupów z programu lojalnościowego,
- reklamacji,
- adresów dostawy,
- danych z CRM,
- segmentów klientów albo predykcji zachowania konkretnych osób.
Wtedy trzeba opisać cel, podstawę prawną, zakres danych, retencję, role administratora i procesora, transfery, prawa osób oraz zabezpieczenia. RODO wymaga między innymi minimalizacji danych, ograniczenia celu i rozliczalności. Jeżeli system miałby podejmować zautomatyzowane decyzje dotyczące konkretnej osoby, trzeba dodatkowo sprawdzić ryzyka związane z profilowaniem i automatycznym podejmowaniem decyzji.
Dla agenta zapasów najprostsza zasada brzmi: używaj danych SKU i lokalizacji, jeśli wystarczą. Nie przenoś danych klienta do modelu tylko dlatego, że są dostępne.
Wdrożenie krok po kroku
Faza 1. Audyt danych
- Lista źródeł: POS, ERP, e-commerce, WMS, arkusze, portale dostawców.
- Mapowanie SKU, wariantów, kodów EAN i lokalizacji.
- Sprawdzenie historii sprzedaży, zwrotów, anulacji i korekt.
- Oznaczenie promocji i zdarzeń nietypowych.
- Sprawdzenie lead time, MOQ, opakowań zbiorczych i progów logistycznych.
- Ustalenie, które dane są źródłem prawdy.
Faza 2. Reguły procesu
- Kto może zatwierdzać zamówienia.
- Kiedy potrzebna jest druga akceptacja.
- Jak traktować nowe produkty bez historii.
- Kiedy model ma milczeć i poprosić o decyzję.
- Jak wygląda obsługa błędnego stanu magazynowego.
- Jak długo przechowujemy rekomendacje, decyzje i logi.
Faza 3. Tryb porównawczy
Agent generuje propozycje obok istniejącego procesu. Buyer widzi rekomendację, ale zamawia po staremu. Celem nie jest udowodnienie, że "agent wygrywa", tylko sprawdzenie:
- które kategorie mają wystarczające dane,
- gdzie rekomendacje są ignorowane i dlaczego,
- które alerty są przydatne,
- ile propozycji wymaga ręcznej korekty,
- czy system tłumaczy decyzje w sposób użyteczny dla zespołu.
Faza 4. Akceptacja człowieka
Po pilotażu agent może przygotowywać propozycje zamówień do zatwierdzenia. Nadal warto zacząć konserwatywnie:
- małe limity wartości,
- wybrane kategorie,
- wybrani dostawcy,
- brak automatycznego wysyłania do dostawcy,
- codzienny przegląd wyjątków,
- tygodniowy przegląd błędów i zmian reguł.
Faza 5. Ograniczona automatyzacja
Dopiero po stabilnym okresie można rozważyć automatyczne wykonanie najbezpieczniejszych działań, na przykład wygenerowanie draftu w ERP albo wysłanie wewnętrznego powiadomienia. Wysyłka zamówienia do dostawcy bez akceptacji powinna być wyjątkiem. Nie jest punktem startowym.
Co sprawdzamy w pilotażu
Nie zaczynaj od ROI z prezentacji. Zacznij od metryk, które da się policzyć przed i po wdrożeniu:
| Obszar | Metryka bazowa | Co ma się poprawić |
|---|---|---|
| Dostępność | liczba dni stockoutu na kluczowych SKU | mniej braków na produktach priorytetowych |
| Nadwyżki | wartość zapasu wolno rotującego | mniej kapitału w towarze bez rotacji |
| Proces | czas przygotowania propozycji zamówień | mniej ręcznego zbierania danych |
| Jakość danych | liczba niespójności POS/ERP | szybsze wykrywanie i zamykanie błędów |
| Decyzje | procent rekomendacji edytowanych przez buyera | wiadomo, gdzie model lub reguły wymagają poprawy |
| Audyt | decyzje bez uzasadnienia | więcej decyzji z powodem i śladem źródeł |
Realistyczny pilotaż nie musi obiecywać spektakularnej redukcji zapasu. Ma odpowiedzieć na pytanie, czy system pomaga zespołowi podejmować lepsze decyzje szybciej i z mniejszą liczbą wyjątków bez właściciela.
Kiedy agent nie pomoże
- Dane sprzedażowe są zbyt krótkie albo niespójne.
- Stany magazynowe są korygowane ręcznie bez powodu w systemie.
- Firma ma mało SKU i proces działa dobrze w prostym arkuszu.
- Produkty są unikatowe i nie mają porównywalnej historii.
- Organizacja nie chce ustalić reguł zatwierdzania.
- Dostawcy nie potwierdzają terminów albo robią to poza systemem.
- Zespół oczekuje pełnej autonomii bez odpowiedzialności za błędy.
W takich przypadkach lepiej zacząć od porządku w danych i procesie zakupowym. Agent może ujawnić problem, ale go nie zastąpi.
FAQ
Czy agent działa z moim systemem POS albo ERP?
To zależy od dostępu do danych. Najlepsze jest API, ale często wystarczy cykliczny eksport CSV, raport z hurtowni danych albo integracja przez warstwę pośrednią. Przed obietnicą integracji trzeba sprawdzić zakres pól, częstotliwość odświeżania, identyfikatory SKU i sposób zapisu zwrotów oraz korekt.
Czy agent może automatycznie zamawiać u dostawców?
Technicznie często tak. Operacyjnie lepszy start to propozycja zamówienia do zatwierdzenia. Pełna automatyzacja ma sens dopiero dla wąskich, dobrze opisanych przypadków, z limitami wartości, logiem, możliwością zatrzymania i jasną odpowiedzialnością.
Jak dokładne są prognozy?
Nie ma jednej uczciwej liczby dla każdej firmy. Dokładność zależy od kategorii, sezonowości, jakości historii, promocji, braków w danych i zmian asortymentu. Dlatego pilotaż mierzy się na własnych danych. Cudzy benchmark nie odpowie na pytanie o Twój asortyment.
Co z nowymi produktami bez historii sprzedaży?
Można używać podobnych produktów, kategorii, sezonu i planu promocji, ale wynik powinien mieć wyraźnie oznaczoną niepewność. Nowe produkty wymagają akceptacji człowieka. Automatyczne zamówienia bez kontroli są tu wykluczone.
Czy RAG rozwiąże problem wiedzy o dostawcach?
RAG pomoże znaleźć zapis w umowie, polityce zakupowej albo instrukcji logistycznej. Nie zastąpi aktualnych danych transakcyjnych. Jeśli system pyta "ile mamy na stanie", odpowiedź powinna pochodzić z ERP/WMS/POS. Dokument w bazie wiedzy nie jest źródłem stanu magazynowego.
Czy lokalny model wystarczy, żeby było bezpiecznie?
Nie. Lokalny model może ograniczyć transfer danych do zewnętrznego dostawcy, ale nadal trzeba kontrolować uprawnienia, logi, retencję, jakość danych i decyzje człowieka. Bezpieczny proces wynika z architektury. Samo miejsce uruchomienia modelu go nie zapewnia.
Przed wdrożeniem
Przygotuj pięć rzeczy:
- Listę źródeł danych i właścicieli każdego źródła.
- Eksport historii sprzedaży, stanów, zamówień i dostaw.
- Reguły zatwierdzania zamówień i limity wartości.
- Listę kategorii, które nadają się do pilotażu.
- Metryki bazowe: stockouty, zapas wolno rotujący, czas pracy buyera i błędy danych.
Umów bezpłatny skan procesów. To 30 minut z inżynierem i pisemne podsumowanie w 2 dni robocze. Przejdziemy przez dane, proces zakupowy i miejsca, w których agent powinien się zatrzymać przed decyzją.
Źródła i punkty kontrolne
- McKinsey: Supply Chain 4.0 - kontekst dla predykcyjnego planowania popytu i pracy na wielu zmiennych.
- LangGraph: zatwierdzanie działań - przerwania, zatwierdzanie, edycja i odrzucanie wywołań narzędzi.
- n8n: executions - historia wykonań procesu, filtrowanie i ponawianie błędnych wykonań.
- n8n: log streaming - zdarzenia i logi jako element monitorowania działania.
- OpenClaw: środowisko agenta - proces z własną przestrzenią pracy i sesjami.
- Hermes Agent: dokumentacja Nous - środowisko zbudowane przez Nous, które obsługujemy jako warstwę wykonawczą, bez gwarancji poprawności procesu.
- RODO / GDPR, rozporządzenie 2016/679 - zasady przetwarzania, rozliczalność, bezpieczeństwo i zautomatyzowane decyzje.
Sprawdź też: Agent AI do raportowania finansowego | Agenci AI dla firm - automatyzacja procesów | Agent AI - ile kosztuje?
Bezpłatny skan procesów
Zacznij od bezpłatnego skanu procesów.
- 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.
0 zł
30 minut · pisemne podsumowanie w 2 dni robocze
Terminy zobaczysz w swojej strefie czasowej.
Wolisz napisać? Opisz proces