Système de Gestion Dispatcher

Des appareils Android standards, tablettes durcies montées sur les chariots ou terminaux portables, à votre choix.

Selon l’urgence des ordres de fabrication, les besoins du planning de production et des règles configurables, avec possibilité de dérogation manuelle pour les superviseurs.

Oui. Les réservations génèrent automatiquement des tâches dispatcher, si bien que tout le flux, de l’ordre de fabrication à l’alimentation de la ligne, ne nécessite aucune coordination humaine.

Il faut une couverture le long des trajets que parcourent les chariots, et pas seulement à des points fixes, parce que le cariste confirme aux deux extrémités de chaque tâche, entre le quai, les allées et le bord de ligne. Une confirmation faite dans une zone sans signal ne remonte au serveur qu’au retour de l’appareil sur le réseau : côté responsable, la tâche reste affichée comme ouverte. Les alertes envoyées 30 minutes à l’avance sont des notifications push : dans une allée non couverte, elles arrivent en retard, ou pas du tout.

Oui, et c’est voulu : un cariste déjà chargé ou bloqué doit pouvoir le dire. Aucun motif n’est saisi avec le refus, donc une dérive ne se voit qu’indirectement : le temps de réponse et la charge de travail sont enregistrés par opérateur, et celui qui refuse systématiquement accumule des heures sans le nombre de tâches terminées qui devrait aller avec. Décidez avant la mise en production qui lit ces indicateurs et pose la question, sinon le bouton de refus devient une porte de sortie.

Pas à elle seule. Chaque tâche porte un emplacement source, une destination et un chemin entre les deux. Ce chemin est un itinéraire fixe entre deux emplacements connus ; il n’est pas recalculé en direct depuis l’endroit où se trouve réellement le chariot. La localisation continue exige le module RTLS séparé : tags sur les chariots, balises d’ancrage installées et calibrées sur toute la zone suivie, et scanners de portique là où les mouvements sont postés. C’est un relevé de site et un chantier d’installation. Cela ne se règle pas dans l’application.

Chaque source et chaque destination doit être un emplacement que le système connaît par une adresse unique, et tout ce que vous voulez faire confirmer doit porter une étiquette scannable que le cariste peut atteindre au moment du transfert. La confirmation par code-barres ne vaut que ce que vaut la discipline d’étiquetage en amont. Si aujourd’hui vos caristes trouvent la matière parce qu’ils savent où elle se trouve habituellement, ce savoir doit devenir une donnée de référence avant la première tâche envoyée.

Techniquement oui, mais quelqu’un saisit alors chaque tâche à la main, en général le superviseur logistique, à partir des mêmes appels téléphoniques que le système devait supprimer. C’est tenable pour un pilote sur une zone ou une équipe, où le volume est faible et où vous testez le comportement des opérateurs et la couverture réseau plutôt que le débit. Cela cesse d’être viable dès que la saisie manuelle des tâches coûte plus de temps que le trafic radio qu’elle remplace.

Deux scans par tâche, un à l’enlèvement et un à la livraison, quelques secondes chacun quand l’étiquette est là où le cariste l’attend. Le coût n’est pas le scan lui-même, c’est descendre du chariot et contourner une palette parce que l’étiquette est tournée vers le rack ou a été posée du mauvais côté. Corrigez le positionnement des étiquettes pour un cariste qui arrive depuis son chariot avant de déployer l’application, sinon ces secondes deviennent des minutes.

Non. Il supprime le trafic radio et l’incertitude sur la tâche suivante, mais quelqu’un reste propriétaire des priorités, traite les exceptions et arbitre quand deux lignes veulent le même chariot. Ce qui change, c’est que le superviseur travaille à partir d’une file de tâches et de temps de réponse enregistrés. La voix et la mémoire ne suffisent plus. Prévoyez une évolution du poste. Une réduction d’effectif n’est pas l’objectif.