Sistema de Gestión Dispatcher

Dispositivos Android estándar: tablets robustas montadas en carretillas o terminales portátiles, a su elección.

Según la urgencia de la orden de trabajo, las necesidades del programa de producción y reglas configurables, con anulación manual para los supervisores.

Sí. Las reservas generan tareas de dispatcher automáticamente, de modo que todo el flujo desde la orden de trabajo hasta el abastecimiento de línea no necesita coordinación humana.

Hace falta cobertura en los recorridos por los que circulan las carretillas, no solo en puntos fijos, porque el carretillero confirma en los dos extremos de cada tarea entre el muelle, los pasillos y el borde de línea. Una confirmación hecha en una zona sin señal no llega al servidor hasta que el dispositivo vuelve a la red, así que para el responsable la tarea sigue abierta. Las alertas con 30 minutos de antelación son notificaciones push: en un pasillo sin cobertura llegan tarde o no llegan.

Sí, y está pensado así, porque un operario que ya va cargado o que está bloqueado necesita poder decirlo. Con el rechazo no se registra ningún motivo, de modo que un patrón solo se ve de forma indirecta: el tiempo de respuesta y la carga de trabajo se registran por operario, y quien rechaza de forma sistemática acumula horas sin el número de tareas completadas que le correspondería. Decida antes del arranque quién mira esos KPI y hace la pregunta, o el botón de rechazar se convierte en una vía de escape.

Por sí sola no. Cada tarea lleva un origen, un destino y una ruta entre ambos, pero esa ruta es un trayecto fijo entre dos ubicaciones conocidas. No se recalcula en vivo desde donde esté la carretilla en ese momento. El posicionamiento continuo requiere el módulo RTLS aparte: etiquetas en las carretillas, balizas ancla instaladas y calibradas en toda el área que se quiera seguir, y escáneres de puerta donde se registran los movimientos. Eso exige un estudio de campo y un proyecto de instalación; la app no lo resuelve con una opción de configuración.

Cada origen y cada destino tiene que ser una ubicación que el sistema conozca por una dirección única, y todo lo que quiera confirmar tiene que llevar una etiqueta escaneable a la que el carretillero pueda llegar en el momento de la entrega. La confirmación por código de barras vale lo que valga la disciplina de etiquetado aguas arriba. Si hoy sus operarios encuentran el material porque saben dónde suele estar, ese conocimiento tiene que convertirse en datos maestros antes de lanzar la primera tarea.

Técnicamente sí, pero entonces alguien teclea cada tarea a mano, normalmente el responsable de logística, a partir de las mismas llamadas de teléfono que el sistema venía a eliminar. Es asumible en un piloto de una zona o de un turno, donde el volumen es pequeño y lo que se está probando es el comportamiento de los operarios y la cobertura de red. El rendimiento queda fuera de esa prueba. Deja de ser viable en cuanto la introducción manual de tareas cuesta más tiempo que el tráfico de radio que sustituyó.

Dos escaneos por tarea, uno en la recogida y otro en la entrega, unos segundos cada uno cuando la etiqueta está donde el carretillero espera encontrarla. Lo que cuesta es bajarse de la carretilla y rodear el palé porque la etiqueta mira hacia el interior de la estantería o se pegó en el lado equivocado. Corrija la colocación de etiquetas pensando en un operario que se acerca desde la carretilla antes de desplegar la app, o esos segundos se convierten en minutos.

No. Elimina el tráfico de radio y las dudas sobre qué toca hacer ahora, pero sigue haciendo falta alguien que fije prioridades, gestione las excepciones y decida qué pasa cuando dos líneas quieren la misma carretilla. Lo que cambia es que ese responsable trabaja desde una cola de tareas y unos tiempos de respuesta registrados. Se acabó coordinar a voces y de memoria. Cuente con que el puesto cambia, no con ahorrar una persona.