Automatyzacja obsługi zamówień w sieci punktów partnerskich

Nasz partner prowadzi ogólnopolską sieć partnerską w handlu: punkty sprzedaży, które zamawiają towar cyklicznie i rozliczają się z centralą. Zbudowaliśmy system, który automatyzuje obsługę tych zamówień, pracę handlowców w terenie i logistykę przesyłek. To nie jest program z półki ani wdrożenie zamknięte odbiorem. To oprogramowanie pisane pod ten jeden biznes, utrzymywane w abonamencie i rozwijane od początku 2026 roku.

Problem, od którego się zaczęło, brzmi tak samo w każdej rosnącej firmie handlowej. Ludzie przepisują dane między systemami i w sezonie zaczynają się mylić. Różnica polega na tym, że tutaj po drugiej stronie nie ma jednego magazynu, tylko punkty rozsiane po całym kraju.

Zaczęło się od szkoleń, nie od systemu

Pierwsze miesiące nie wyglądały jak projekt programistyczny. Prowadziliśmy szkolenia i konsultacje na przypadkach z firmy naszego partnera. Nie na przykładach z kursu. Na jego zamówieniach, jego papierologii, jego reklamacjach.

Z czasem zakres urósł i szkolenia zamieniły się w budowę systemu, bo zaufanie, które zbudowaliśmy przy prostszych rzeczach, przełożyło się na zgodę na coś większego.

Automatyzacja obsługi zamówień: co system robi na co dzień

System pilnuje trzech rzeczy, które w rozproszonej sieci rozjeżdżają się najszybciej.

Zamówienia. Zamówienie złożone w panelu i zamówienie wysłane SMS-em wchodzą do systemu tą samą ścieżką. Do złożenia zamówienia nie trzeba zakładać konta ani niczego instalować.

Praca handlowców w terenie. Handlowiec rejestruje nowy punkt na miejscu, a nie po powrocie do biura wieczorem. Dane firmy uzupełniają się same, więc nikt nie przepisuje ich z kartki i nikt ich nie przekręca.

Przesyłki i rozliczenia. Każda paczka ma swój stan i swoje rozliczenie. Rozbieżność widać w momencie, w którym powstaje, a nie przy zamknięciu miesiąca.

Do tego dochodzi fakturowanie, komunikacja SMS i podgląd całości dla biura, z uprawnieniami zależnymi od roli. W większości firm tej wielkości robi to kilka osób ręcznie, w kilku arkuszach, które nikomu się nie zgadzają.

Dlaczego przepisaliśmy panel z gotowych klocków na kod

Panel powstał najpierw w narzędziu, w którym ekrany składa się z gotowych klocków zamiast pisać je od zera. Na starcie była to dobra decyzja. Pierwsze moduły powstały szybciej i taniej, niż powstałyby pisane od podstaw.

Potem panel urósł. Przy kilkunastu modułach i kilkuset elementach na ekranach zaczęły przeszkadzać rzeczy, których przy trzech ekranach w ogóle nie widać. Utrzymanie środowiska testowego i produkcyjnego w zgodzie kosztowało coraz więcej. Trudno było powiedzieć, co dokładnie zmieniło się między dwiema wersjami. Zmiana w jednym miejscu potrafiła ruszyć coś, czego nikt nie oglądał od miesięcy, i nie było testu, który by to złapał.

Migrację na zwykły kod zamiast klocków zaproponowaliśmy my, nie nasz partner. Powód był policzalny, nie estetyczny.

• Historia zmian. Panel siedzi w repozytorium kodu, więc każda zmiana ma autora, datę i możliwość cofnięcia.
• Rozdzielone środowiska. Zmianę widać najpierw na teście, dopiero potem u ludzi, którzy pracują na tym codziennie.
• Testy na ścieżkach krytycznych. Fragmenty, których awaria zatrzymuje zamówienia, sprawdzają się same przy każdej zmianie.
• Logi i śledzenie błędów. Kiedy coś pęknie, wiemy co i gdzie, zamiast prosić użytkownika o zrzut ekranu.
• Brak sufitu. W kodzie da się zrobić rzecz, której twórcy klocków nie przewidzieli. W panelu tej wielkości takie rzeczy pojawiają się regularnie.

Stary panel pracował do dnia, w którym nowy przejął jego zadania, bez przestoju, o który nasz partner mógłby się martwić. Sama migracja kosztowała kilka tygodni pracy, które nie dołożyły naszemu partnerowi ani jednej nowej funkcji, i powiedzieliśmy to wprost, zanim zaczęliśmy. Zaufał nam na słowo, bo do tego momentu zawsze dowoziliśmy to, co obiecaliśmy. Zwrot przychodzi na każdej następnej poprawce, bo skróciła się droga od zgłoszenia do wdrożenia, a nie sam czas pisania zmiany.

Jak to jest zbudowane

Warstwa techniczna w trzech punktach, bo to pytanie i tak padnie, bez wchodzenia w to, czego nasz partner wolałby nie upubliczniać.

• Automatyzacje w tle. Integracje i procesy, które działają bez ekranu, na który ktoś patrzy. Ponad 10 procesów działa produkcyjnie.
• Panel operacyjny pisany od podstaw. Kilkanaście modułów dopasowanych do ról biurowych i terenowych, a nie składanych z gotowych klocków.
• Prosta baza danych. Bez sztywnego schematu, więc dodanie pola nie wymaga migracji.

Całość stoi na infrastrukturze naszego partnera, więc kolejny użytkownik w systemie nie podnosi opłaty licencyjnej.

Jak wygląda ta współpraca

Abonament utrzymaniowy, nie projekt z odbiorem i pożegnaniem. Umawiamy się na godziny w miesiącu, a w tych godzinach mieszczą się poprawki, nowe moduły i to, co wyjdzie po drodze.

W praktyce znaczy to tyle, że znamy ten biznes od środka i nasz partner nie musi tłumaczyć nam kontekstu za każdym razem. Zmianę zgłasza się w rozmowie, nie w formularzu. Część rzeczy proponujemy sami, bo widzimy je wcześniej niż osoba pracująca w jednym module. Nasz partner nie musi pilnować, czy coś działa, bo to jest nasza robota, nie jego.

Po ponad półtora roku wspólnej pracy rozmawiamy jak zespół, który zna swoje słabości i mocne strony, nie jak dostawca z klientem. To najlepiej widać w tym, że kolejne pomysły na system przychodzą teraz z obu stron, mniej więcej po równo.

Ile kosztuje takie utrzymanie, zależy od liczby godzin i poziomu SLA, czyli umówionego czasu reakcji i naprawy. U nas zaczyna się od 3 875 zł netto miesięcznie i to jest punkt wejścia, nie średnia. Ile płaci nasz partner, nie napiszemy, bo to jego sprawa, a nie nasza. Widełki dla własnego zakresu policzysz w kalkulatorze.

Czego ten projekt nie dowodzi

Nie podamy nazwy naszego partnera, jego branży w szczegółach, konkretnych narzędzi, na których to stoi, ani tego, ile ma punktów czy ile zamówień przechodzi przez system w miesiącu. Nasz partner wprost zastrzegł sobie prywatność, a to jest projekt oparty na zaufaniu, więc je szanujemy, tak samo jak szanowalibyśmy Twoje.

Nie twierdzimy też, że przejście z gotowych klocków na kod jest zawsze dobrym ruchem. Przy panelu na trzy ekrany byłoby wydawaniem pieniędzy bez powodu i tak byśmy powiedzieli.

Jeśli szukasz najtańszego wykonawcy, nie jesteśmy nim. Ten projekt trwa dlatego, że ktoś płaci za to, żeby ktoś inny go pilnował, a nie dlatego, że musiał.

Jeżeli u ciebie ludzie przepisują dane między systemami i mylą się w sezonie, to jest ten sam problem w innej branży. Zwykle zaczynamy od jednego procesu, tego, który zjada najwięcej godzin, żeby efekt było widać w dwa tygodnie.