La prioridad de tareas del RCS no era un problema en la época de las flotas pequeñas. Con una docena de robots, el orden de llegada funcionaba bastante bien: una batería baja significaba ir a cargar, y un pedido urgente podía insertarse a mano sin romper nada. Pero una vez que una flota supera cierto umbral, la programación deja de ser despacho y se convierte en una verdadera disyuntiva. Las tareas de oleada necesitan rendimiento, los pedidos urgentes necesitan plazo de entrega, y la carga necesita que la flota siga en línea — y las tres compiten por los mismos robots. El RCS, el sistema de control de robots que se sitúa entre el WMS y la flota, pasa cada día asignando capacidad entre estos tres tipos de tareas.
Una vez que la flota crece, la prioridad de tareas del RCS se vuelve un problema real
Empecemos por los datos. Según Interact Analysis, los envíos acumulados de robots móviles se acercaban a 2.1 million de unidades a finales de 2025, lo que representaba aproximadamente $18 billion en ingresos, mientras que el número de sitios de clientes que despliegan robots móviles creció de poco más de 9,000 en 2020 a más de 53,000. La historia de la industria en los últimos cinco años ha sido el paso de "unas pocas docenas de robots en piloto" a "una flota como unidad operativa".
Sin embargo, la misma firma rebajó su pronóstico en una actualización de mediados de 2025: recortó la previsión de AMR del año en $800 million, redujo la tasa de crecimiento compuesto a cinco años del 26% al 21%, y bajó la proyección de ingresos para 2030 a $15.6 billion, citando la disrupción arancelaria y una actitud de esperar y ver en el gasto de capital de los clientes. La rebaja merece una pausa. No significa que el problema de programación se esté haciendo más pequeño — todo lo contrario. En los años en que la expansión se frena, los operadores exprimen más utilización de las flotas que ya tienen, y cuanto mayor la utilización, más agudo el conflicto entre tipos de tareas.
Una segunda señal viene de Amazon. En June 2025 la compañía anunció su robot número one-million desplegado, repartido en más de 300 instalaciones, junto con DeepFleet, un modelo de IA generativa creado para coordinar el movimiento de robots, que según la compañía puede mejorar la eficiencia de desplazamiento de los robots en un 10%. Esa cifra es una afirmación del proveedor, no una medición verificada de forma independiente, y la distinción importa. Pero la dirección es clara: cuando el objetivo de coordinación crece de docenas de máquinas a un millón, la programación ya no puede ser "reglas escritas en piedra". Tiene que convertirse en algo que el sistema aprende.
Un verdadero dilema: cuando los pedidos urgentes le roban los robots a la oleada
Antes de la temporada alta de 2024, un almacén de cumplimiento de comercio electrónico en el suroeste de Estados Unidos se topó con el caso de manual. En la noche de una gran promoción, los pedidos urgentes llovían, y el RCS activó la prioridad preventiva: las tareas urgentes de alta prioridad podían interrumpir las tareas de oleada de menor prioridad en curso y llevarse los robots.
El corte se salvó, y los pedidos urgentes de esa noche se enviaron más o menos a tiempo. El precio apareció en la segunda mitad de la noche. Las tareas de oleada interrumpidas seguían postergándose, las oleadas siguientes se retrasaban todas, y en un momento las estaciones de picking quedaron inactivas con robots esperando mercancías que no habían llegado — los vehículos esperaban al trabajo, no al revés.
El caso ilustra un hecho fácil de pasar por alto: la interrupción preventiva no es gratis. No elimina la demora; la reubica, trasladando el costo de los pedidos urgentes a las tareas de oleada de otra forma. Una política de prioridad es, en esencia, una decisión sobre quién soporta el costo de la congestión del sistema.
Tres estrategias de prioridad de tareas del RCS: un marco de disyuntiva de programación
En la práctica, los enfoques de la industria ante el conflicto a tres bandas se agrupan en tres grandes estrategias, cada una con sus costos:
| Estrategia | Lógica | Mejor ajuste | Costo |
|---|---|---|---|
| Prioridad estática | Clasificación fija, p. ej., urgente > oleada > carga | Flotas pequeñas, mezcla de tareas homogénea | Las oleadas se quedan sin recursos cuando los pedidos urgentes son frecuentes; la carga se descuida sistemáticamente |
| Puntuación ponderada | Cada tipo de tarea se puntúa dinámicamente por tiempo de espera, presión del plazo y estado del vehículo; la puntuación más alta va primero | Tareas mixtas, carga volátil | Los pesos necesitan recalibración continua; el ajuste es costoso y la deriva degrada el rendimiento |
| Preventiva con salvaguardas | Los pedidos urgentes pueden interrumpir, pero las tareas de oleada mantienen una cuota mínima garantizada; la carga se reserva en ventanas | Flotas grandes, temporada alta | La más compleja de implementar; requiere pronosticar el estado de la flota y la llegada de tareas |
Ninguna de ellas es la respuesta estándar. Mi observación es que la mayoría de las flotas maduras ejecutan una variante de la tercera: la interrupción está permitida, pero el lado interrumpido recibe protección contra la inanición — por ejemplo, una tarea de oleada escala automáticamente en prioridad después de haber sido diferida un número determinado de veces. La cuestión no es qué estrategia elegir, sino si la operación acepta la premisa de que cualquier regla estática fallará bajo alguna carga, y que la propia política necesita retroalimentación.
La contraintuitiva: la carga es la variable oculta del rendimiento
De los tres tipos de tareas, la carga es la más fácil de subestimar. La intuición dice que la carga no produce pedidos, así que debería ocupar el último lugar. Un almacén siguió esa intuición y fijó la prioridad de carga al mínimo, dejando que solo los robots por debajo de un umbral de batería fueran a cargar.
Entonces, en una noche de temporada alta, una gran parte de la flota alcanzó el umbral casi al mismo tiempo. Se formó una cola en las estaciones de carga, la disponibilidad de la flota se desplomó en las primeras horas, y el rendimiento del sitio cayó con ella. La solución de los ingenieros fue contraintuitiva: elevaron la prioridad de las tareas de carga y pasaron a la carga fragmentada de oportunidad — recargando entre tareas siempre que un robot pasara junto a un cargador — combinada con ventanas de carga concentrada durante las horas valle. La curva de disponibilidad se aplanó, y el sistema se volvió más estable, no menos.
La disyuntiva merece desmenuzarse. El costo real de una tarea de carga no es la electricidad. Son los vehículos que se desconectan en el momento equivocado, juntos. En una flota de alta utilización, la carga es una condición previa del rendimiento, no una ocurrencia tardía. Tratarla como una tarea de baja prioridad "cuando haya tiempo" planta una bomba de tiempo en la programación.
Por qué los tres tipos de tareas entran en conflicto por diseño
El conflicto es estructural, no de gestión. Los tres tipos de tareas viven en tres escalas de tiempo distintas: las tareas de oleada se planifican por hora y son muy predecibles; los pedidos urgentes llegan por minuto y son esencialmente impredecibles; la carga se rige por las curvas de batería y el número físico de cargadores, lo que la convierte en esencia en un problema de satisfacción de restricciones.
Un nivel más abajo, sus funciones objetivo nunca estuvieron alineadas. Las tareas de oleada quieren maximizar el rendimiento, los pedidos urgentes quieren minimizar la latencia, y la carga quiere maximizar la disponibilidad de la flota. Cada día, el RCS realiza una disyuntiva en línea entre los tres objetivos, y cualquier regla que optimice uno solo — "siempre priorizar los pedidos urgentes", por ejemplo — lo paga en las otras dos dimensiones. Por eso también, cuanto mayor la flota, más rápido se quedan sin recorrido las reglas escritas a mano.
Juicio de tendencia: la prioridad de tareas del RCS está pasando de los motores de reglas a la optimización basada en aprendizaje
Juntando los datos y los casos, mi juicio es que en los próximos tres a cinco años, la programación RCS convencional pasará de "los humanos escriben reglas y ajustan parámetros" a la optimización basada en aprendizaje de "entrenar en simulación, inferir en línea". Tres razones: primero, la escala de la flota — 2.1 million de unidades acumuladas en 53,000 sitios — ya ha hecho insostenible el ajuste manual; segundo, prácticas como el DeepFleet de Amazon muestran que los operadores líderes están reemplazando reglas por modelos para la coordinación a nivel de flota; tercero, la simulación madura de gemelos digitales permite que una política ensaye miles de temporadas altas en una flota virtual antes de tocar una real.
El juicio tiene una condición previa, sin embargo. La programación basada en aprendizaje necesita datos operativos de alta calidad como combustible, y la gobernanza de datos de la mayoría de los almacenes sigue en la etapa de "suficientemente bueno". El algoritmo no es el cuello de botella. Los datos lo son.
Lo que deja una pregunta abierta. Cuando la propia política de programación se convierte en un sistema que aprende, ¿el equipo de operaciones del almacén sigue necesitando mantener una mano en la anulación manual de prioridad? Y si es así, ¿a qué granularidad — ajustando unos pocos parámetros de peso, o tomando el control de un robot individual en una emergencia? Todavía no hay una respuesta estándar, pero la respuesta probablemente dará forma a cómo será la próxima generación de productos RCS.
Por Dr. Chen, investigador de la cadena de suministro
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
