automatyzacja procesów · integracje systemów · Lublin i cała Polska
Integracja sklep–magazyn: koniec ze sprzedażą towaru, którego nie ma
Stan w magazynie mówi jedno, sklep drugie, a marketplace trzecie. Ktoś dwa razy dziennie eksportuje plik i wgrywa go ręcznie, więc przez kilka godzin dziennie sklep sprzedaje towar, którego fizycznie nie ma na półce. Potem są telefony, przeprosiny i anulacje.
To kolejny proces, w którym sztuczna inteligencja nie jest do niczego potrzebna. Stan magazynowy to liczba przy indeksie. Wystarczą reguły, które pilnują mapowania i przenoszą liczby co kilka minut zamiast dwa razy dziennie.
Ręczna synchronizacja to nie jest opóźnienie. To okno, w którym sprzedajesz powietrze.
Kiedy stany wgrywa się ręcznie dwa razy dziennie, między jednym a drugim wgraniem mija kilka godzin. W tym czasie sklep pokazuje liczby sprzed śniadania. Jeżeli akurat zeszła większa partia towaru, klienci kupują coś, czego nie ma — i dowiadują się o tym dzień później, w mailu z przeprosinami.
Na marketplace'ach ten sam problem kosztuje więcej niż stracone zamówienie. Anulacja z winy sprzedawcy obniża ocenę konta, a przy odpowiedniej liczbie takich zdarzeń kończy się ograniczeniem widoczności ofert. Płacisz więc dwa razy: raz utraconą sprzedażą, drugi raz pozycją, której nie widać.
- Godzina eksportu to godzina prawdy. Wszystko po niej jest zgadywaniem aż do kolejnego wgrania.
- Indeksy nie pasują do siebie. Ten sam produkt ma inny symbol w magazynie, inny w sklepie i inny u marketplace'u. Mapowanie żyje w arkuszu, który ktoś prowadzi ręcznie.
- Rezerwacje nikną. Towar odłożony pod zamówienie hurtowe wciąż widnieje jako dostępny w sklepie.
- Rozjazd wykrywa klient. Nikt nie sprawdza zgodności — dowiadujesz się o niej z reklamacji.
Cztery reguły, które chodzą co pięć minut i nigdy nie zapominają.
- 01bez AI
Proces czyta stan ze źródła prawdy
Najpierw ustalamy, który system jest źródłem prawdy dla stanu — zwykle magazyn albo ERP. Bez tej decyzji integracja nie ma sensu, bo dwa systemy będą się nawzajem nadpisywać.
- 02bez AI
Reguła mapuje indeksy między systemami
Symbol z magazynu, SKU ze sklepu, identyfikator z marketplace'u — mapowanie jest zapisane w jednym miejscu i sprawdzane przy każdym przebiegu. Produkt bez pary jest zgłaszany, a nie po cichu pomijany.
- 03bez AI
Wyliczany jest stan do publikacji
Nie zawsze równy stanowi magazynowemu. Odejmujemy rezerwacje, towar uszkodzony i bufor bezpieczeństwa — na przykład dwie sztuki, których nie pokazujemy, żeby przy równoległych zamówieniach nie zejść poniżej zera. To jedna reguła, którą ustawiasz raz.
- 04bez AI
Kanały dostają aktualizację
Sklep, marketplace'y, porównywarki — każdy w swoim formacie i w swoim tempie, zgodnie z limitami API. Wysyłane są tylko zmiany, więc przebieg co pięć minut jest tani i nie przeciąża niczego.
- 05bez AI
Kontrola wyłapuje rozjazdy
Osobna reguła porównuje stany po obu stronach i zgłasza różnice: produkt bez mapowania, kanał, który odrzucił aktualizację, indeks ujemny. Dostajesz o tym wiadomość zanim zauważy to klient.
Bo stan magazynowy to liczba przy indeksie, a nie zdanie do zrozumienia.
bez AI Reguły — cały proces
- odczyt stanów ze źródła prawdy
- mapowanie indeksów między systemami
- rezerwacje, bufory i towar wyłączony ze sprzedaży
- publikacja zmian w każdym kanale
- synchronizacja cen i statusów zamówień
- kontrola zgodności i alarmy
Reguła przenosi liczbę bez interpretacji. To jedyny akceptowalny sposób pracy ze stanem magazynowym.
AI · 0 kroków Model — niepotrzebny
Model językowy jest narzędziem do rzeczy niejednoznacznych. Stan magazynowy jest jednoznaczny z definicji: siedem sztuk to siedem sztuk. Wpuszczenie tu modelu oznaczałoby wprowadzenie niepewności w miejsce, w którym jej dziś nie ma.
Jedyny sensowny wyjątek to jednorazowe dopasowanie katalogów — kiedy trzeba połączyć kilka tysięcy produktów po nazwach, bo nikt nigdy nie prowadził mapowania. To zadanie robi się raz, przy wdrożeniu, a jego wynik i tak zatwierdza człowiek. Potem proces chodzi już wyłącznie na regułach.
Okno błędu spada z godzin do minut, a anulacje przestają psuć konto.
Prawdziwa oszczędność jest gdzie indziej niż w godzinie dziennie. Kiedy stany są aktualne, przestaje istnieć cała kategoria pracy: telefony z przeprosinami, ręczne anulacje, korekty zamówień, tłumaczenie się na marketplace'ach. Ta praca nigdzie nie jest zapisana jako koszt, ale zjada więcej czasu niż samo wgrywanie plików.
Kiedy dane ze sklepu i magazynu są już spójne, naturalnym kolejnym krokiem jest automatyczny raport — bo wreszcie jest z czego go liczyć.
Decyzja o źródle prawdy i dostęp do obu stron.
- Wskazanie źródła prawdy. Który system decyduje o stanie: magazyn, ERP czy sklep. To pierwsza i najważniejsza decyzja — bez niej integracja tworzy pętlę nadpisań zamiast porządku.
- Dostęp do systemów. API po obu stronach jest najwygodniejsze. Jeśli któryś system go nie ma, pracujemy na eksportach — rzadziej, ale nadal automatycznie.
- Mapowanie indeksów albo zgoda, żeby je zbudować. Jeśli nie istnieje, przygotowanie go jest częścią wdrożenia. Przy dużych katalogach da się to zrobić półautomatycznie, ale wynik i tak przechodzi przez Twoją akceptację.
- Zasady buforów i rezerwacji. Ile sztuk chowamy, co robimy z towarem uszkodzonym, jak traktujemy zamówienia w realizacji.
Wdrożenie zaczynamy zwykle w trybie „tylko podgląd”: proces liczy, co powinien wysłać, i pokazuje to obok stanu rzeczywistego, ale niczego nie zmienia. Dopiero gdy przez kilka dni liczby się zgadzają, włączamy zapis.
Pytania, które padają przy integracjach
Zwykle tak. Warunkiem jest jakikolwiek sposób wyjęcia danych: API, regularny eksport do pliku, baza, do której da się zajrzeć. Sprawdzam to na pierwszej rozmowie i mówię wprost, jeśli system jest zamknięty na tyle, że integracja nie ma sensu — wtedy szkoda Twoich pieniędzy na próby.
Osobna reguła kontrolna porównuje obie strony przy każdym przebiegu i zgłasza różnice. Dostajesz wiadomość z listą produktów, których dotyczy problem, i przyczyną: brak mapowania, odrzucona aktualizacja, stan ujemny. Chodzi o to, żeby rozjazd wykrywał proces, a nie klient.
Tak i zwykle właśnie tak to wygląda docelowo: stany w jedną stronę, zamówienia w drugą — do magazynu albo systemu handlowego. Zaczynamy jednak od stanów, bo to one kosztują najwięcej, gdy się rozjeżdżają, a ich synchronizacja jest najprostsza do zweryfikowania.
Domyślnie co pięć minut, ale tempo dopasowujemy do limitów API każdego kanału i do Twojej rotacji. Przy szybko schodzącym towarze da się zejść niżej i dołożyć natychmiastową aktualizację po każdym zamówieniu. Wysyłane są tylko zmiany, więc częstsze przebiegi nic nie kosztują.
Dlatego zaczynamy w trybie podglądu: proces liczy, co powinien wysłać, i pokazuje to obok stanu rzeczywistego, ale niczego nie zapisuje. Zapis włączamy dopiero wtedy, gdy przez kilka dni obie liczby się zgadzają. Nic nie idzie na produkcję, zanim nie zobaczysz, że działa.
Powiązane automatyzacje
Procesy rzadko chodzą pojedynczo — te trzy najczęściej wchodzą razem z tym opisanym wyżej.
- Automatyczne raportyzestawienie czeka, zanim wstaniesz→
- Automatyzacja fakturowaniafaktury z maila prosto do księgowości→
- Przypomnienia o płatnościachnikt nie musi być niemiły→
Wolisz zobaczyć całość? Wróć na stronę główną — jest tam osiem procesów w wersji animowanej, na żywo.
Jak często aktualizujesz dziś stany w sklepie?
Napisz, jakich systemów używasz po obu stronach, ile masz produktów i w ilu kanałach sprzedajesz. Powiem, czy da się je spiąć, jak gęsto może chodzić synchronizacja i od czego zacząć, żeby nic nie ruszyć na produkcji.
Napisz w trzech zdaniach
Ile dokumentów albo spraw miesięcznie, kto się tym dziś zajmuje i co najbardziej wkurza. Tyle wystarczy, żebym powiedział, czy warto.
Bez zobowiązań i bez przygotowań. Jeśli automatyzacja tego procesu się nie opłaca, usłyszysz to wprost.