Granica między klasami systemów przebiega tam, gdzie zmienia się jednostka, którą system zarządza: zlecenie, pojazd na terenie, pozycja w magazynie. Oferty opisują je podobnym słownictwem, więc porównanie zaczyna się od ustalenia, czego dana firma naprawdę potrzebuje.
Co odróżnia klasy systemów w logistyce
Podział bierze się z jednostki, którą dany system zarządza. TMS operuje zleceniem przewozowym: skąd, dokąd, czym i za ile. YMS operuje pojazdem obecnym na terenie zakładu. WMS operuje pozycją towarową wewnątrz magazynu. Telematyka operuje pojazdem w trasie, poza terenem obiektu.
Ta różnica przekłada się wprost na dane, które system musi przechowywać, i na pytania, na które potrafi odpowiedzieć. System znający wyłącznie zlecenia nie powie, ile pojazd czekał pod rampą, bo nie ma znacznika wjazdu. System znający wizyty nie powie, ile kosztował przewóz, bo nie ma stawki frachtowej.
| Klasa | Czym zarządza | Typowe pytanie, na które odpowiada |
|---|---|---|
| TMS | Zleceniem przewozowym i jego rozliczeniem | Ile kosztował przewóz na danej relacji |
| YMS | Pojazdem i zasobami na terenie zakładu | Ile pojazd czekał od bramy do rampy |
| WMS | Pozycją towarową i lokalizacją w magazynie | Gdzie leży dana partia towaru |
| Telematyka | Pojazdem w trasie | Kiedy pojazd dotrze pod wskazany adres |
Żadna z tych klas nie zastępuje pozostałych, choć oferty często sugerują inaczej. Moduł awizacji wbudowany w TMS zwykle sprowadza się do pola z godziną, bez kontroli dostępności rampy. Moduł transportowy w WMS zwykle kończy się na wydruku dokumentu. Rozstrzygające jest pytanie, czy dana funkcja pracuje na własnym rejestrze, czy tylko wyświetla pole.
Miejsca styku między systemami
Procesy nie kończą się na granicy systemu, więc styki trzeba zaplanować. Jest ich zwykle cztery i każdy ma inną częstotliwość wymiany danych.
- Zamówienie z ERP do awizacji - numer zamówienia i oczekiwana ilość, pobierane przy zakładaniu zgłoszenia.
- Potwierdzenie przyjęcia do ERP - odsyłane po zamknięciu obsługi, razem z rzeczywistą ilością.
- Zlecenie z TMS do harmonogramu - przewóz zaplanowany po stronie spedycji, rezerwujący okno w magazynie docelowym.
- Pozycja pojazdu z telematyki - przewidywany czas dojazdu, pozwalający wcześniej przesunąć okno.
Ostatni styk bywa pomijany, a daje najszybszy efekt. Informacja, że pojazd spóźni się o dziewięćdziesiąt minut, dociera wtedy przed jego przyjazdem, a nie po. Sposób przekazywania szacowanego czasu dojazdu opisuje strona o wyznaczaniu ETA dla przewoźnika, a dostępne sposoby połączenia zebrano na stronie o integracjach systemu.
Przy porównywaniu ofert pytanie brzmi nie „czy system ma moduł awizacji", tylko „czy ten moduł odrzuci drugą rezerwację tego samego okna". Pole z godziną wpisywaną ręcznie nie jest kalendarzem zasobów.
Od czego zacząć dobór
Kolejność zależy od tego, gdzie firma traci najwięcej czasu, a nie od popularności skrótu. Magazyn z kolejką pod bramą i pustymi rampami po południu potrzebuje warstwy YMS, choćby miał najlepszy TMS. Spedycja rozliczająca dziesiątki przewoźników potrzebuje TMS, choćby jej magazyn działał sprawnie.
Punktem wyjścia jest pomiar. Rozkład przyjazdów w godzinach doby oraz czas od przyjazdu do podstawienia pod rampę wskazują, czy problem leży w placu. Udział przewozów rozliczanych poza systemem wskazuje, czy leży w spedycji. Metodę liczenia porządkuje strona o wskaźnikach OTIF, a zakres funkcji placowych - materiał o systemie klasy Yard Management.
Wdrożenie etapami zamiast jednego projektu
Uruchamianie kilku klas równocześnie wydłuża projekt i utrudnia przypisanie efektu. Sensowniejsza kolejność zaczyna się od warstwy, która daje najszybszy pomiar, czyli od rejestru wizyt. Dane z niego posłużą później do parametryzacji pozostałych warstw.
Drugi etap obejmuje zwykle siatkę okien czasowych, bo dopiero rejestr pokazuje rzeczywiste czasy obsługi. Trzeci - portal dla firm zewnętrznych. Integracje z ERP i systemem spedycyjnym wchodzą na końcu, gdy struktura zgłoszenia jest już stabilna. Przebieg takiego projektu opisuje strona o wdrożeniu oprogramowania do awizowania dostaw.
Osobno warto rozstrzygnąć, czy system stanie na własnej infrastrukturze, czy będzie pracował jako usługa. Decyzja wpływa na to, kto wykonuje kopie zapasowe i aktualizacje, a przy wielu obiektach także na koszt łączy. Kryteria zebrano na stronie o chmurze i instalacji lokalnej.
Czego nie załatwi żadna z tych klas
Oprogramowanie egzekwuje reguły, ale ich nie ustala. Trzy rzeczy pozostają po stronie organizacji i ich brak unieważnia wdrożenie niezależnie od wybranej klasy systemu.
Pierwsza to decyzja, kto ma prawo odstąpić od zasady. Pojazd bez zgłoszenia, przewoźnik spóźniony o trzy godziny, dostawa poza godzinami pracy - każdy z tych przypadków wymaga rozstrzygnięcia na zmianie, a nie eskalacji do kierownika. System pokaże sytuację, ale jej nie rozwiąże.
Druga to jakość danych wejściowych. Kartoteka przewoźników z nieaktualnymi adresami e-mail unieważnia całą warstwę powiadomień, a lista ramp bez ograniczeń rodzaju pojazdu prowadzi do rezerwacji, których nie da się zrealizować. Trzecia to konsekwencja: jeżeli rezerwacja terminu nie daje pierwszeństwa przed pojazdem, który po prostu przyjechał, przewoźnicy przestają rezerwować po drugim takim zdarzeniu.
Jak czytać ofertę
| Zapis w ofercie | Pytanie kontrolne |
|---|---|
| Moduł awizacji dostaw | Co się stanie przy równoczesnej rezerwacji tego samego okna |
| Integracja z ERP | Które pola wymieniane są w którą stronę i z jaką częstotliwością |
| Raporty i analityka | Czy zapytanie raportowe obciąża tabele obsługi bieżącej |
| Dostęp dla przewoźników | Gdzie nakładany jest filtr zakresu danych - w widoku czy na serwerze |
Odpowiedzi na te pytania da się sprawdzić na demonstracji w kilkanaście minut, a różnicują dostawców mocniej niż porównanie list funkcji. Zakres zestawień dostępnych po stronie rejestru pokazuje materiał o usługach raportowych SQL Server.
