En los últimos dos años he recorrido las naves de más de una docena de almacenes que operan robots móviles autónomos, y un patrón se repite una y otra vez: robots de dos, a veces tres, marcas distintas compartiendo la misma nave. En 2024, en un campus de fulfillment de comercio electrónico en el este de China, los AMR de acarreo por debajo de la Marca C y los AMR tipo carretilla de la Marca D compartían un único pasillo principal, cada uno respondiendo a su propio gestor de flota. Durante el primer mes tras la puesta en marcha, dos robots de marcas distintas fueron enviados a la misma ubicación de almacenamiento —una colisión de despacho— más de 30 veces al día. Hablando con integradores de sistemas, escucho la misma historia con creciente frecuencia: las flotas de varias marcas eran raras antes de 2021 y se han vuelto notablemente comunes desde 2023. Las causas, curiosamente, convergen mucho, y se agrupan en tres.
Cómo se ensamblan las flotas mixtas
La primera causa son las fusiones y adquisiciones. Cuando un 3PL adquiere a otro, el equipo del almacén A y el del almacén B terminan bajo el mismo techo, y las marcas naturalmente no coinciden. La segunda es el cambio de proveedor en la expansión de la fase dos: el piloto se hizo con una marca premium, luego un competidor rebajó la oferta entre un 20 y un 30 por ciento, el director financiero firmó encantado, y el dolor de cabeza de la integración llegó meses después. La tercera es la más común y la más injusta: la compra del piloto y la compra de la ampliación las hicieron responsables distintos que nunca hablaron entre sí, y para cuando ambos lotes de robots llegaron, todos se dieron cuenta de que hablaban dos idiomas diferentes.
Las tres apuntan a la misma conclusión: las flotas mixtas rara vez se planifican; se ensamblan. Y como no se planifican, la capa de programación suele ser lo último en lo que alguien piensa, aunque sea lo más difícil de hacer bien.
Tres trampas, cada una más profunda que la anterior
La primera trampa es el protocolo. VDA5050, el protocolo de comunicación abierto impulsado conjuntamente por la asociación de la industria automotriz alemana (VDA) y la federación de ingeniería mecánica (VDMA), se diseñó precisamente para que los AMR de distintas marcas pudieran ser orquestados por un controlador maestro. En la práctica, el soporte de los proveedores es desigual: algunos implementan solo un subconjunto básico de funciones mientras la gestión del tráfico y la anticipación de tareas siguen corriendo sobre protocolos propietarios; otros declaran soporte sobre el papel pero ocultan campos de datos clave en la entrega, y sus actualizaciones de estado llegan demasiado lentas para la programación en tiempo real. El resultado es que la capa de programación neutral que intenta dirigir la orquesta recibe una partitura censurada.
La segunda trampa es la prioridad de paso. El RCS (sistema de control de robots) de cada marca solo conoce a sus propios robots, planifica sus propias rutas y asume que tiene la prioridad. En 2023 visité un 3PL de piezas de automoción en el Medio Oeste estadounidense que operaba 40 AMR de acarreo por debajo de la Marca A junto a 12 AMR carretilla contrapesada de la Marca B heredados de una adquisición, todos compartiendo una misma intersección del pasillo principal. Los dos programadores no veían los vehículos del otro; la intersección se bloqueaba 17 veces al día de media en el primer mes, cada una requiriendo que un humano caminara hasta allí y moviera un robot, a 8 a 12 minutos por incidente. Tras asumir una capa de programación neutral el control unificado del tráfico, los bloqueos cayeron a uno o dos por semana. La navegación y la evasión de obstáculos de los robots individuales nunca fueron el problema. Lo que faltaba era un agente de tráfico.
La tercera trampa es la más insidiosa: los conflictos de prioridad. Una tarea urgente de expedición aterriza en la cola de la Marca A mientras una tarea rutinaria de reposición espera en la cola de la Marca B, y ningún programador puede ver la cartera de tareas del otro —la urgencia y la rutina viven en mundos separados. Luego está el problema de los datos: la Marca A define la utilización por horas de tarea, la Marca B por distancia recorrida, así que la dirección recibe dos informes de KPI cuyos números no se pueden conciliar, y la reunión de revisión se convierte en dos monólogos.
Cambiar los robots o cambiar el programador: las cuentas
Una flota mixta acaba enfrentando dos salidas: arrancar todo para pasar a una sola marca, o añadir una capa de programación neutral que gobierne todas las marcas. Usando como modelo ilustrativo un sitio mediano con 60 robots (cifras solo orientativas; rigen las cotizaciones reales de cada proyecto):
| Partida de coste | Opción A: marca única | Opción B: capa de programación neutral |
|---|---|---|
| Enajenación de la flota antigua | Recuperación residual, aproximadamente el 20-30% del precio original según estado y antigüedad | Ninguna; se siguen usando |
| Compra de robots nuevos | Recompra de la flota completa; la partida grande | Ninguna |
| Software de programación | RCS del proveedor, a menudo incluido o licenciado por separado | Licencia del programador neutral, por robot o por sitio |
| Trabajo de integración | Una integración WMS | Un adaptador de protocolo por marca |
| Parada de la puesta en marcha | Cambio de todo el sitio, ventana de parada grande | Puesta en marcha por fases posible |
| Apalancamiento a largo plazo | Atado a un solo proveedor | Se conserva el poder de negociación multimarcas |
En magnitud, la Opción A cuesta aproximadamente de 3 a 5 veces la Opción B. Pero la Opción A tiene un beneficio oculto: precios de mantenimiento de un solo proveedor, repuestos comunes y un equipo de operaciones que solo necesita dominar un sistema. El beneficio oculto de la Opción B es estratégico: sin dependencia de un proveedor, las futuras ampliaciones aún pueden licitarse competitivamente.
Cuatro preguntas pueden guiar la elección: ¿la flota supera los 30 robots?; ¿las zonas operativas se solapan mucho?; ¿hay presión de fusiones o expansión en los próximos tres años?; ¿la flota antigua está cerca del final de su depreciación? Si las tres primeras respuestas son sí, una capa de programación neutral suele ser la mejor economía. Si la flota es pequeña, las zonas son independientes y los robots antiguos iban a reemplazarse de todos modos, el dolor a corto plazo supera al dolor a largo plazo: unifica una vez y listo.
La lectura contraria es esta: cuando los proyectos de flotas mixtas fracasan, la causa raíz casi nunca son los robots, sino quién tiene el poder en la capa de programación. Quien posee el programador maestro asigna la prioridad de paso, arbitra las prioridades y define el estándar de datos. Que los proveedores frenen la apertura del protocolo parece un problema técnico; en realidad es una lucha de poder: una vez que una capa neutral toma el mando, los robots quedan degradados a actuadores. Así que en la selección de proveedores, no compares solo las especificaciones de los robots. Haz una pregunta más: en tu protocolo propietario, ¿los campos de control de tráfico y anticipación de tareas están realmente abiertos? Esa sola pregunta evita la mitad de las trampas.
En cuanto a tendencias, VDA5050 está pasando de deseable a imprescindible en los proyectos de logística automotriz europeos, y los proveedores de programadores neutrales que lo soportan están madurando rápido. La pregunta abierta que merece reflexión: una vez que la capa de programación se vuelva verdaderamente independiente —un componente estándar multiplataforma—, ¿qué será lo siguiente en mercantilizarse? ¿Seguirá el robot, hasta que los AMR compitan como lo hacen hoy las carretillas, solo por precio y fiabilidad, con toda la inteligencia concentrada en la capa de programación? Aún no hay respuesta, pero la dirección es clara.
Por el Dr. Chen, investigador de cadena de suministro
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
