← Wszystkie realizacje
Niemiecka firma motoryzacyjna Niemcy

Planowanie zapasu opon, gdy sezon zaczyna się w dwa tygodnie

Narzędzie, które liczy, ile opon którego wzoru trzeba mieć na składzie w nadchodzących miesiącach – zamiast przepisywania zeszłorocznej sprzedaży do arkusza.

Sprzedaż opon jest sezonowa i nerwowa. Przez większość roku nic się nie dzieje, a potem w ciągu dwóch tygodni przychodzą pierwsze przymrozki i cały rynek chce tego samego rozmiaru naraz. Kto nie ma towaru, oddaje sprzedaż konkurencji. Kto ma go za dużo, zamraża pieniądze i miejsce w magazynie na kolejne pół roku.

Co się działo wcześniej

Plan zapasu powstawał w arkuszu. Brało się sprzedaż z zeszłego roku, dokładało przeczucie co do pogody i zapowiedzi producentów, i wychodziła liczba sztuk na wzór i rozmiar. Przy kilkuset pozycjach katalogowych taki arkusz robi się nieczytelny, a każda korekta wymaga przeliczenia całości od nowa.

Problem nie polega na tym, że arkusz źle liczy. Polega na tym, że nikt nie ma odwagi go zmienić w połowie sezonu, bo nie wiadomo, co jeszcze się przestawi. Plan zrobiony w sierpniu obowiązuje więc do grudnia, nawet jeśli we wrześniu widać już, że jest nietrafiony.

Co zbudowaliśmy

Narzędzie do planowania zapasu, w którym plan jest żywy przez cały sezon.

Algorytm planujący na kolejne okresy. Zaczyna od historii sprzedaży, ale liczy przyszłe okresy, zamiast przepisywać przeszłość. Zmiana założenia przelicza wynik od razu.

Układ katalogu po marce i wzorze. Setki pozycji pogrupowaliśmy tak, jak myśli o nich handlowiec, a nie tak, jak leżą w bazie. Można planować całą marką i zejść do pojedynczego rozmiaru tam, gdzie to ma znaczenie.

Wersje planu. Plan bazowy, plan po korekcie, plan po decyzji zarządu. Widać, co się zmieniło i kto to zmienił, więc korekta w trakcie sezonu przestaje być skokiem na głęboką wodę.

Jak to zmienia pracę

Planowanie przestaje być czynnością raz na rok i to jest tu najważniejsze.

Gdy przeliczenie planu zajmuje chwilę i nie psuje poprzedniej wersji, opłaca się go korygować co miesiąc. A plan korygowany co miesiąc jest po prostu bliżej rzeczywistości niż ten zrobiony raz w sierpniu – bez żadnej magii, samym rytmem pracy.

Druga zmiana dotyczy rozmów z producentami. Kiedy zamówienie wynika z policzonego planu, a nie z przeczucia, łatwiej jest negocjować wielkość partii i termin, bo widać, skąd się wzięła liczba.

Klient nie udostępnił nam liczb po wdrożeniu i nie podajemy ich tutaj. W każdej firmie z sezonowym towarem zysk bierze się jednak z tego samego: mniej pieniędzy zamrożonych w pozycjach, które nie schodzą, i mniej sprzedaży oddanej przez brak towaru w szczycie.

Dlaczego zrobiliśmy to w ten sposób

Firma miała już działające aplikacje i nie chciała kolejnego osobnego systemu z własnym logowaniem i własnym wyglądem. Interfejs powstał więc z komponentów, które dają się osadzić w istniejących ekranach, a nie jako zamknięta wyspa. Dla użytkownika to jedno narzędzie więcej w tym samym miejscu, a nie kolejna zakładka z własnym hasłem.

Pokaż stos technologiczny
  • Angular
  • Ngrx
  • Nx
  • Angular Material
  • Web Components
  • Java 11
  • Spring Boot
  • Hibernate
  • PostgreSQL
  • Flyway
  • Kubernetes

Masz podobny problem u siebie?

Opisz go w dwóch zdaniach. Odpowiemy, czy da się go rozwiązać i ile to zajmie.

Napisz do nas
Albo napisz bezpośrednio na hello@udb.pl