Systém řízení Dispatcher

Na běžných zařízeních Android, podle volby na odolných tabletech namontovaných na vozíku nebo na ručních terminálech.

Podle naléhavosti zakázky, potřeb výrobního plánu a nastavitelných pravidel, s možností ručního zásahu pro nadřízené.

Ano. Rezervace automaticky generují úkoly pro dispečera, takže celý tok od zakázky až po zásobení linky nevyžaduje žádnou ruční koordinaci.

Potřebuje pokrytí podél celých tras, kudy vozíky jezdí, protože řidič potvrzuje na obou koncích každého úkolu: u rampy, v uličkách i přímo u linky. Potvrzení provedené v místě bez signálu dorazí na server až ve chvíli, kdy je zařízení zpátky v síti, takže úkol zatím vypadá jako otevřený. Předstihová upozornění 30 minut dopředu jsou push notifikace, takže v nepokryté uličce přijdou pozdě nebo vůbec.

Ano, a je to tak záměrně, protože řidič, který už má naloženo nebo stojí zablokovaný, musí mít jak to říct. K odmítnutí se nezapisuje důvod, takže se vzorec chování projeví jen nepřímo: doba odezvy a vytížení se evidují po operátorech a ten, kdo odmítá soustavně, má odpracované hodiny bez odpovídajícího počtu dokončených úkolů. Ještě před ostrým provozem se dohodněte, kdo tato KPI čte a kdo se zeptá. Jinak se z tlačítka odmítnout stane způsob, jak se práci vyhnout.

Sama o sobě ne. Každý úkol nese zdrojovou lokaci, cílovou lokaci a trasu mezi nimi, ale je to pevná trasa mezi dvěma známými místy, ne živé přepočítání z aktuální pozice vozíku. Průběžné určování polohy vyžaduje samostatný modul RTLS: tagy na vozících, kotevní majáky nainstalované a zkalibrované po celé sledované ploše a bránové skenery v místech, kde se pohyby zaúčtovávají. To je projekt s obhlídkou provozu a montáží, ne přepínač v aplikaci.

Každý zdroj i cíl musí být lokace, kterou systém zná pod jednoznačnou adresou, a všechno, co chcete mít potvrzené, musí nést čitelný štítek, na který řidič v okamžiku předání dosáhne. Potvrzování čárovým kódem je jen tak spolehlivé jako kázeň při značení materiálu před ním. Pokud dnes řidiči hledají materiál podle toho, že vědí, kde obvykle bývá, musí se tato znalost stát kmenovými daty dřív, než se odešle první úkol.

Technicky ano, jenže pak někdo zadává každý úkol ručně. Obvykle je to mistr logistiky, a to na základě stejných telefonátů, které měl systém odstranit. Pro pilot na jedné hale nebo jedné směně to použitelné je, protože objem je malý a testujete chování operátorů a pokrytí sítě, ne průchodnost. Přestane to dávat smysl ve chvíli, kdy ruční zadávání úkolů spolyká víc času než vysílačkový provoz, který nahradilo.

Dva skeny na úkol, jeden při vyzvednutí a jeden při doručení, pár sekund každý. Platí to, pokud je štítek tam, kde ho řidič čeká. Nákladem není sken samotný, ale slézání z vozíku a obcházení palety, protože štítek míří do regálu nebo skončil na špatné straně. Ještě před nasazením aplikace vyřešte umístění štítků tak, aby byly čitelné pro řidiče přijíždějícího na vozíku. Jinak se z těch sekund stanou minuty.

Ne. Odstraní vysílačkový provoz a hádání, co dělat jako další, ale někdo pořád musí vlastnit priority, řešit výjimky a rozhodnout, co se stane, když dvě linky chtějí stejný vozík. Změní se to, že mistr pracuje s frontou úkolů a zaznamenanými dobami odezvy. Pokřikování a spoléhání na paměť odpadá. Počítejte s tím, že se změní role, ne že se ušetří člověk.