Piensa en la programación de tareas de RCS como el mostrador de triaje de urgencias de un hospital. Los pacientes (tareas) no dejan de llegar; la enfermera de triaje (el programador) decide según la gravedad (prioridad) quién entra primero a la sala de trauma (un robot). El carril de urgencias existe para emergencias reales, pero si cada familia grita "lo nuestro es urgente", el triaje colapsa. La configuración de prioridad de tareas de RCS hace exactamente ese trabajo: decide quién sube primero y quién espera.
Cómo funciona: colas, pesos y el ciclo de despacho
El RCS es el cerebro de la flota de robots. Cada 100 ms hasta aproximadamente un segundo, ejecuta un ciclo de despacho: puntúa cada tarea en espera, las ordena y asigna las de mayor puntuación a los robots libres. La puntuación de una tarea se parece aproximadamente a esto:
task score = priority weight × f(wait time, distance, battery, task type)
La anticipación (preemption) de pedidos urgentes significa literalmente apoderarse. Fíjate en qué se apodera: no de un lugar en la cola, sino de capacidad. El tiempo de robot es fijo: cada minuto que toma un pedido urgente es un minuto que una tarea normal espera.
Puedes pensarlo como una plaza de peaje en una autopista: el carril ETC (alta prioridad) avanza primero mientras el carril de pago en efectivo (tareas normales) hace cola. Pero no puedes seguir añadiendo carriles ETC: si todos los carriles son ETC, nadie se salta ninguna cola; la plaza sigue atascada. La prioridad solo significa algo cuando es escasa.
La f() de la fórmula merece una mirada más atenta: el tiempo de espera protege contra "esperar eternamente", la distancia elige el robot más cercano, la batería filtra las unidades con poca carga y el tipo de tarea distingue trabajos de transporte, elevación y carga. Una tarea P2 que lleva esperando 10 minutos puede superar en puntuación a una P1 recién llegada una vez que entra en juego el envejecimiento (aging): ese es todo el sentido del envejecimiento, y también el ajuste que la mayoría desactiva sin pensarlo y del que más se arrepiente después.
Tres formas de configurar la anticipación, y lo que cuesta cada una
Configuración A: ponderación por prioridad. Sube el peso de prioridad del pedido urgente: por ejemplo, tareas normales en 5, pedidos urgentes en 50. Un solo parámetro, facilísimo. El coste: si lo subes demasiado (por ejemplo, 100), las tareas de baja prioridad nunca reciben servicio. Eso es inanición (starvation), y arrastrará a una oleada normal hasta la muerte.
Configuración B: reasignación anticipada. Cuando llega un pedido urgente, se requisa un robot que está trabajando en una tarea de baja prioridad; la tarea interrumpida retrocede y vuelve a la cola. La respuesta más rápida. El coste es el recorrido en vacío (deadhead): el viaje interrumpido fue kilometraje desperdiciado, y ahora hay que volver a recorrerlo.
Configuración C: capacidad reservada. Mantén entre el 10–20% de la flota fuera de las oleadas normales, dedicada a pedidos urgentes. La opción más estable. El coste es capacidad ociosa en días tranquilos: soldados a los que alimentas mil días para un día de batalla.
| Configuración | Respuesta a urgencias | Impacto en oleadas normales | Complejidad | Adecuada para |
|---|---|---|---|---|
| A Ponderación | Rápida | Arruina la oleada si se exagera | Baja | Cuota de urgencias estable por debajo del 5% |
| B Anticipación | La más rápida | Más recorridos en vacío, reversiones de tareas | Baja | Urgencias raras que exigen respuesta de segundo nivel |
| C Capacidad reservada | Siempre rápida | Casi ninguno | Baja | Cuota de urgencias volátil con picos claros |
Un proyecto que ajusté en 2025: un almacén de comercio electrónico en el este de China, 180 AMR. Peso de urgencias fijado en 50. Con una cuota normal de urgencias del 3%, todo iba bien; el día del festival de compras 618, los pedidos urgentes se dispararon al 15%, la espera media de las tareas normales saltó de 50 segundos a 4 minutos y la tasa de puntualidad de las oleadas cayó 12 puntos. Los registros mostraron una tarea de baja prioridad esperando 47 minutos: inanición de manual. La causa raíz era una sola pieza faltante: ponderación configurada, sin mecanismo de envejecimiento.
¿Cómo elegir entre las tres? Mira la cuota de urgencias: estable por debajo del 5%, usa A: barata y suficiente. Rara pero con necesidad de respuesta de segundo nivel (una línea de producción a punto de quedarse sin material), usa B. Volátil con picos claros (grandes eventos de ventas, fin de trimestre), usa C. La mayoría de los almacenes termina con un híbrido A+C: ponderación en días normales, capacidad reservada activada dos semanas antes del pico. La línea divisoria no es técnica, es el ritmo del negocio, y por eso nueve de cada diez personas que copian los parámetros de otro almacén terminan revirtiéndolos.
La configuración de prioridad de tareas RCS probada en campo: niveles, envejecimiento y capacidad reservada
Niveles. P0 urgencia real (mantener por debajo del 5% del volumen) / P1 oleadas prioritarias / P2 normal / P3 aplazable (reposición, recuentos cíclicos). La regla de hierro para lo que cuenta como "urgente": no que ventas diga que es urgente, sino que la fecha límite del SLA esté a menos de X horas. Cuando ventas dice "este lote es urgente", haz primero dos preguntas: "¿cuál es la penalización del SLA y perdemos al cliente?" ¿No sabes responder? Va a P2. Aquí es donde nacen los requisitos falsos, y nunca me contengo al señalarlos.
Envejecimiento. Las tareas que esperan demasiado se promocionan automáticamente: el suelo que evita la inanición:
effective priority = base weight + factor × wait time / threshold
Sin envejecimiento, incluso pesos bellamente ajustados son una bomba de relojería: tranquilos en días normales, garantizado que estallan en pico.
Capacidad reservada. 15–20% en temporada pico, 5–10% fuera de pico, ajustada dinámicamente con la cuota de urgencias, nunca fijada en código. Recuerda: los pesos reordenan la cola; no crean capacidad. Si la cuota de urgencias supera el 10% y sigues solo ajustando pesos, estás usando la herramienta equivocada.
Las trampas de mantenimiento: configuras una vez, sufres para siempre
Trampa 1: ajustar una vez y funcionar un año. La temporada pico cambia la mezcla de SKU y el ritmo de las oleadas, pero los pesos siguen siendo los del año pasado. La configuración de prioridad debe seguir al plan de oleadas: revisarla al menos trimestralmente y siempre reajustarla antes del pico.
Trampa 2: probar sin carga, así la inanición nunca aparece. Las pruebas solo miran el tiempo medio de espera, y los promedios son la métrica más deshonesta que existe. El número que importa es el tiempo máximo de espera de las tareas de baja prioridad. Cuando ese sube, la inanición está llegando.
Trampa 3: blindarse contra una cuota de urgencias por encima del límite. Si los pedidos urgentes se mantienen por encima del 10% del volumen a largo plazo, eso no es un problema de programación, es un problema de capacidad: añade robots o devuelve algunos pedidos "urgentes" a P2. No puedes tapar un hueco de capacidad con parámetros del programador.
Trampa 4: dejar que cualquiera marque P0. El mayor enemigo de la prioridad no son los parámetros, es la gente. Los derechos de marcado P0 deben restringirse: quién puede marcar, si requiere aprobación y una auditoría mensual de la cuota real de P0. Deja el marcado abierto y P0 superará el 20% en tres meses; ningún ajuste te salva después de eso.
¿Merece la pena entonces la configuración de prioridad? Observa un par de números: la tasa de puntualidad de los pedidos urgentes alcanzando el objetivo mientras el tiempo medio de espera de las tareas normales se mantiene plano. Si ambos se cumplen, la configuración es correcta. Si solo se cumple uno, te estás engañando.
Por Da Liu, Ingeniero de automatización
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
