System Zarządzania Dispatcher

Na standardowych urządzeniach z Androidem: wytrzymałych tabletach montowanych na wózkach lub terminalach ręcznych, do wyboru.

Na podstawie pilności zlecenia, potrzeb harmonogramu produkcji i konfigurowalnych reguł, z możliwością ręcznego nadpisania przez przełożonych.

Tak. Rezerwacje automatycznie generują zadania dla dyspozytora, dzięki czemu cały przepływ od zlecenia po zasilenie linii nie wymaga żadnej koordynacji ze strony człowieka.

Wymaga zasięgu wzdłuż całych tras, którymi jeżdżą wózki, bo operator potwierdza zadanie na obu końcach: przy rampie, w alejkach i przy linii. Potwierdzenie wykonane tam, gdzie nie ma sygnału, trafia na serwer dopiero po powrocie urządzenia do sieci, więc dla kierownika zadanie nadal wygląda na otwarte. Alerty z 30-minutowym wyprzedzeniem to powiadomienia push, więc w alejce bez zasięgu przyjdą z opóźnieniem albo wcale.

Tak i jest to świadoma decyzja projektowa, bo operator, który ma już załadowany wózek albo stoi zablokowany, musi mieć jak to zgłosić. Przy odrzuceniu nie jest zapisywany powód, więc schemat widać tylko pośrednio: czas reakcji i obciążenie pracą są rejestrowane na operatora, a ktoś, kto odrzuca regularnie, wyrabia godziny bez odpowiadającej im liczby zamkniętych zadań. Ustalcie przed startem produkcyjnym, kto czyta te KPI i zadaje pytanie, inaczej przycisk odrzucenia stanie się furtką do wymigiwania się od pracy.

Sam z siebie nie. Każde zadanie ma lokalizację źródłową, lokalizację docelową i trasę między nimi, ale jest to stała trasa między dwoma znanymi miejscami. Nie jest przeliczana na żywo z miejsca, w którym wózek aktualnie stoi. Ciągła lokalizacja wymaga osobnego modułu RTLS: tagów na wózkach, beaconów referencyjnych zamontowanych i skalibrowanych na całym objętym obszarze oraz skanerów na bramkach, gdzie księgowane są ruchy. To projekt obejmujący pomiary na obiekcie i montaż. Samym przełącznikiem w aplikacji się tego nie włączy.

Każda lokalizacja źródłowa i docelowa musi być miejscem, które system zna po unikalnym adresie, a wszystko, co ma być potwierdzane, musi mieć etykietę do zeskanowania, do której operator sięgnie w momencie przekazania. Potwierdzenie kodem kreskowym jest warte tyle, ile dyscyplina etykietowania wcześniej w procesie. Jeżeli dziś operatorzy znajdują materiał dlatego, że wiedzą, gdzie zwykle leży, ta wiedza musi najpierw trafić do danych podstawowych, zanim zostanie wysłane pierwsze zadanie.

Technicznie tak, ale wtedy ktoś wprowadza każde zadanie ręcznie, najczęściej mistrz logistyki, na podstawie tych samych telefonów, które system miał wyeliminować. To ma sens przy pilotażu na jednym obszarze albo jednej zmianie, gdzie wolumen jest mały i sprawdzacie raczej zachowanie operatorów i pokrycie sieci niż przepustowość. Przestaje być wykonalne w momencie, w którym ręczne wprowadzanie zadań kosztuje więcej czasu niż ruch na radiotelefonach, który zastąpiło.

Dwa skany na zadanie, jeden przy pobraniu i jeden przy dostawie, po kilka sekund każdy, jeśli etykieta jest tam, gdzie operator się jej spodziewa. Kosztem nie jest sam skan, tylko schodzenie z wózka i obchodzenie palety, bo etykieta jest odwrócona w głąb regału albo naklejona z drugiej strony. Uporządkujcie miejsce naklejania etykiety pod operatora podjeżdżającego wózkiem, zanim wdrożycie aplikację, bo inaczej te sekundy zamienią się w minuty.

Nie. Zdejmuje ruch na radiotelefonach i zgadywanie, co robić dalej, ale ktoś nadal odpowiada za priorytety, obsługuje sytuacje wyjątkowe i decyduje, co się dzieje, gdy dwie linie chcą tego samego wózka. Zmienia się to, że mistrz pracuje na kolejce zadań i zarejestrowanych czasach reakcji. Krzyk i pamięć przestają być potrzebne. Planujcie zmianę roli; na oszczędność etatu nie liczcie.