Menedzerpepsi.pl — PWA dla firmy dystrybucyjnej

Problem klienta

Firma dystrybucyjna obsługująca dostawy w regionie miała prosty, ale bardzo kosztowny problem: brak przejrzystości tego, co dzieje się we flocie. Właściciel wiedział, którzy kierowcy wyjechali w trasę, ale reszta była czarną skrzynką. Ile kilometrów realnie przejechał dany samochód w miesiącu? Jakie było zużycie paliwa na konkretnej ciężarówce? Czy trasa, którą zaplanował dyspozytor, jest rzeczywiście optymalna? Skąd wiadomo, że kierowca zatankował tyle, ile wpisał na fakturze?

Tankowania spisywane były na papierze, trasy układane w głowie, a raporty miesięczne powstawały pod koniec okresu rozliczeniowego z pudełka na paragony. Przy kilkunastu autach i kilkunastu kierowcach to wystarczyło do rozliczenia VAT-u, ale nie wystarczało do podejmowania decyzji biznesowych.

Klient nie potrzebował kolejnego systemu ERP. Potrzebował narzędzia, które kierowca uruchomi na swoim telefonie bez szkolenia i które menedżer otworzy rano przy kawie, żeby zobaczyć, kto już jedzie.

Dlaczego PWA zamiast natywnej aplikacji

Pierwsza decyzja architektoniczna, którą trzeba było podjąć: aplikacja dla kierowcy. Natywny Android? iOS? Cross-platform? Wybrałem PWA (Progressive Web App) i nie żałuję.

Powód był prozaiczny. Flota była mieszana — część kierowców miała Androida, część starsze iPhone'y, część korzystała z firmowych tabletów. Utrzymywanie dwóch natywnych aplikacji, przechodzenie przez review w App Store za każdym razem, gdy klient poprosi o zmianę koloru przycisku — to byłby koszmar dla projektu tej wielkości. PWA rozwiązuje ten problem: jedna baza kodu, instalacja z poziomu przeglądarki (ikona na pulpicie), działanie offline dla kluczowych widoków, Push notifications z serwera o nowej trasie.

Dla klienta istotne było też to, że aktualizacja dociera do kierowcy natychmiast — bez proszenia go o wchodzenie do sklepu i klikania „aktualizuj". Otworzył aplikację, najnowsza wersja sama się załadowała.

Co widzi kierowca

Kierowca loguje się raz, a potem aplikacja przechowuje jego sesję. Główny ekran jest celowo minimalistyczny — na czerwonym tle widać, że aktualnie stoi w miejscu. Wybiera z listy przypisaną ciężarówkę, klika „Rozpocznij trasę" i ekran zmienia się na zielony. To jest cała ceremonia startu pracy. Żadnych formularzy, żadnych rozwijanych list z dwudziestoma opcjami.

Na koniec dnia kierowca wpisuje końcowy stan licznika i zatwierdza. System sam liczy przejechane kilometry, godziny pracy i dostarcza to do panelu menedżera.

Druga kluczowa funkcja to tankowania. Przy każdym zatankowaniu kierowca wprowadza stan licznika, ilość zatankowanych litrów i cenę brutto. Te trzy liczby wystarczą, żeby system sam obliczył średnie spalanie na 100 km — w perspektywie ostatniego tankowania, ostatnich 30 dni i w całej historii kierowcy.

Trzeci element: podgląd dzisiejszej trasy. Kierowca widzi listę punktów do odwiedzenia w odpowiedniej kolejności, liczbę kilometrów do pokonania i mapę z zaznaczonym przebiegiem. Trasa generowana jest w panelu menedżera, a kierowca dostaje ją gotową.

Co widzi menedżer

Panel menedżera to osobna aplikacja webowa w .NET Framework 4.7 — wtedy jeszcze pragmatyczny wybór dla wewnętrznych narzędzi firmowych, dzisiaj prawdopodobnie zrobiłbym to w .NET 8 z Blazorem lub React + minimal API.

Dashboard pokazuje wszystkich kierowców z ich aktualnym statusem: na zielono ci, którzy zakończyli trasę, na czerwono — ci, którzy aktualnie są w trasie. Widać też statystyki dnia: ilu kierowców powinno być w pracy zgodnie z grafikiem, a ilu rzeczywiście rozpoczęło trasę. Prosta liczba 10/9 oznacza, że ktoś się nie stawił, i menedżer od razu wie, że trzeba dzwonić.

Kluczowa funkcjonalność to generowanie trasy. Menedżer wgrywa plik dostarczony przez firmę dystrybucyjną (lista punktów do odwiedzenia na następny dzień), wybiera kierowcę, klika „Generuj". System sprawdza różne kombinacje kolejności punktów tak, aby trasa była jak najkrótsza — to klasyczny problem TSP (travelling salesman) w wersji praktycznej. Po wygenerowaniu można jeszcze ręcznie edytować kolejność, jeśli menedżer wie coś, czego algorytm nie wie (np. „ten klient otwiera dopiero o 10").

W widoku pojedynczego kierowcy menedżer widzi wszystko: godziny pracy w miesiącu, liczba dni w trasie, przejechane kilometry, średnie spalanie, historię tras, historię tankowań z cenami brutto/netto i wyliczonym spalaniem na każdym odcinku. To samo w perspektywie ciężarówki — kto nią jeździł w danym okresie, ile kilometrów zrobiła, kto ją zatankował.

Osobny moduł obsługuje przypisania ciężarówek. System pokazuje na żółto auta aktualnie zajęte (nie można ich przepiąć, bo jakiś kierowca ich używa), na zielono wolne i listę kierowców bez przypisanego pojazdu. Dwa kliknięcia i mamy nowe przypisanie na jutro.

Raporty i statystyki

Moduł wydatki i raporty generuje pliki Excel z wybranego okresu — raport ogólny dla kierowcy (przejechane kilometry, godziny, liczba tras) oraz raport paliwa (wszystkie tankowania, spalanie, koszty brutto/netto). Dla menedżera to narzędzie do rozmów z kierowcami i do rozliczeń księgowych.

Statystyki w perspektywie kierowcy pokazują uśrednione dane z całej historii zatrudnienia: średnie spalanie, średni dystans dzienny, średnia liczba godzin pracy. Te liczby po kilku miesiącach zaczynają opowiadać historię — widać, kto jeździ ekonomicznie, a kto spala o 2 litry więcej na setce od średniej floty.

Dane same w sobie nic nie znaczą. Dopiero porównanie kierowcy A i kierowcy B na tej samej ciężarówce pokazuje, czy ktoś wozi się z nogą na gazie, czy potrafi przewidywać ruch.

Stos i architektura

• Frontend kierowcy: PWA (HTML/CSS/JS + service worker), instalowalny na ekranie domowym, działanie offline dla widoku aktualnej trasy
• Panel menedżera: ASP.NET MVC na .NET Framework 4.7, Razor views
• Backend / API: REST API w .NET, komunikacja z PWA przez JSON
• Baza danych: SQL Server — tabele kierowców, ciężarówek, tras, punktów trasy, tankowań
• Mapy i routing: Google Maps API z cache'owaniem zapytań — dystanse między parami punktów, które już były liczone, są zapisywane lokalnie w bazie. Przy generowaniu nowej trasy system najpierw sprawdza, które pary są w cache'u (np. 124 z 255), a dopyta Google tylko o brakujące 131. To obcina rachunki za API o kilkadziesiąt procent miesięcznie.
• Push notifications: informowanie kierowcy o nowej trasie przypisanej na jutro

Całość hostowana na jednym VPS-ie, bez kontenerów i orkiestratorów — dla firmy z 15 ciężarówkami to byłaby ślepa technologia, której nikt by nie utrzymywał.

Zobacz więcej

Projekt menedzerpepsi.pl to dobry przykład tego, że małe firmy nie potrzebują SAP-a — potrzebują narzędzia dopasowanego do ich realnego procesu. PWA okazała się idealnym wyborem dla kierowców, którzy nie chcą instalować nic ze sklepu, a panel menedżera w .NET dał klientowi pełną kontrolę nad flotą, paliwem i raportami.

Jeśli pracujesz w logistyce lub transporcie i zastanawiasz się, czy warto budować własne narzędzie zamiast kupować gotowy system flotowy — chętnie porozmawiam. Więcej realizacji znajdziesz w sekcji portfolio, a całą prezentację aplikacji możesz obejrzeć na moim kanale YouTube.