Optimización de rutas de reparto con múltiples restricciones: cómo funciona realmente

Resumen: Optimizar rutas de reparto no es calcular el camino más corto en un mapa. Cuando entran en juego ventanas horarias de clientes, capacidad de cada vehículo y zonas de entrega, el problema se convierte en uno de los más difíciles de resolver en logística. Este artículo explica qué hace un algoritmo cuando se enfrenta a esas restricciones y por qué muchas soluciones genéricas fallan antes de llegar a producción.

Tabla de contenidos

• Por qué el camino más corto no sirve de nada
• Las tres restricciones que rompen cualquier algoritmo simple
• Cómo trabaja el motor de optimización por dentro
• Qué pasa cuando las restricciones entran en conflicto
• Lo que el algoritmo no puede hacer por ti
• Cómo evaluar una solución antes de implantarla
• TL;DR
• Lecturas recomendadas

Por qué el camino más corto no sirve de nada

Cuando un comercial de software te presenta una demo donde un mapa muestra rutas con flechas de colores en dos segundos, lo que ves es un algoritmo de distancia mínima. Eso resuelve un problema diferente al tuyo.

Tu problema real tiene nombre técnico: Vehicle Routing Problem with Time Windows and Capacity Constraints (VRPTW-C). Es una variante del problema del viajante de comercio, que pertenece a la categoría NP-hard: no existe un algoritmo que garantice la solución óptima en tiempo razonable cuando la flota supera 10-15 vehículos y los clientes superan 50-60 paradas diarias. Lo que existe son métodos de aproximación que encuentran soluciones muy buenas, no perfectas.

Esa distinción importa. Si alguien te promete “la ruta óptima” para 80 clientes y 12 camiones con restricciones horarias, o no entiende el problema o no te está diciendo la verdad.

Las tres restricciones que rompen cualquier algoritmo simple

Ventanas horarias de clientes

Un cliente solo acepta mercancía entre las 8:00 y las 10:30. Si el camión llega a las 10:45, la entrega falla. El algoritmo tiene que conocer esa ventana para cada parada y calcular si el vehículo puede llegar a tiempo partiendo de su posición anterior, con el tráfico estimado y los tiempos de descarga.

Las ventanas horarias no son opcionales: son un dato duro que convierte el problema de ordenación en un problema de planificación temporal. Añadir 40 clientes con ventanas distintas multiplica exponencialmente las combinaciones posibles.

Capacidad de vehículo

Cada camión tiene un límite de carga en kilos, en metros cúbicos o en número de palés. El algoritmo tiene que asignar pedidos a vehículos sin superar ese límite, respetando además la secuencia de descarga: el pedido que se entrega primero tiene que estar cargado al fondo del último en salir.

En distribución de alimentación o farmacia, la temperatura añade otra dimensión: no puedes mezclar referencias de cadena de frío con producto seco en el mismo espacio si el vehículo no está compartimentado.

Zonas de entrega y restricciones de circulación

Las zonas de bajas emisiones (ZBE) vigentes en Madrid, Barcelona, Sevilla y otras ciudades españolas prohíben la circulación de ciertos vehículos en determinadas franjas horarias. Un algoritmo que no incorpora esas restricciones planifica rutas que el conductor no puede ejecutar.

A esto se suman túneles con límite de tonelaje, calles de sentido único o muelles de carga de acceso restringido. Cada una de esas condiciones es una restricción adicional que el motor tiene que procesar.

Cómo trabaja el motor de optimización por dentro

Los algoritmos comerciales que funcionan en producción usan combinaciones de estas técnicas:

1. Construcción heurística inicial — Se genera una primera solución válida (no óptima) agrupando paradas por proximidad geográfica y verificando que no se violan las restricciones de capacidad ni las ventanas horarias. Esta fase tarda milisegundos.

2. Mejora iterativa por metaheurística — Sobre la solución inicial se aplican operadores de mejora: intercambio de paradas entre rutas, inversión de segmentos, reubicación de clientes aislados. Los algoritmos más comunes son ALNS (Adaptive Large Neighborhood Search) y Simulated Annealing. Cada iteración acepta o rechaza el cambio según criterios que permiten salir de mínimos locales.

3. Evaluación de factibilidad en cada paso — Antes de aceptar cualquier movimiento, el motor comprueba que la ruta resultante no viola ninguna restricción. Capacidad acumulada hasta cada parada, hora de llegada estimada respecto a la ventana, tipo de vehículo permitido en la zona. Si viola alguna, el movimiento se descarta.

4. Parada por tiempo o por umbral de mejora — El algoritmo no busca indefinidamente. Se detiene cuando el tiempo de cómputo supera un límite (habitualmente entre 30 segundos y 5 minutos según el tamaño del problema) o cuando la mejora marginal entre iteraciones cae por debajo de un umbral definido.

El resultado es una solución que en la mayoría de los casos se sitúa entre el 3 % y el 8 % por encima del óptimo teórico. Para flotas reales, ese margen es perfectamente asumible.

Qué pasa cuando las restricciones entran en conflicto

Aquí es donde la mayoría de las soluciones genéricas muestran sus límites. Si un cliente tiene una ventana horaria estricta pero vive en una zona de bajas emisiones a la que tu vehículo no puede acceder hasta las 9:00, y además la carga de ese pedido no cabe en el único camión que puede circular por esa zona, el algoritmo necesita una jerarquía de prioridades.

¿Qué pesa más: la ventana horaria o la capacidad? ¿Se permite llegar tarde a ese cliente si eso salva cuatro entregas más? ¿O ese cliente tiene un contrato con penalización que lo convierte en intocable?

Esas respuestas no están en el algoritmo. Están en tu operativa. Un sistema que no te deje configurar esa jerarquía te va a generar rutas que son matemáticamente eficientes pero operativamente inviables.

Las restricciones en conflicto no tienen solución matemática única. Tienen solución operativa, y esa depende de decisiones que solo tú puedes tomar.

Un motor bien construido expone esa configuración como parámetros editables: peso de penalización por incumplimiento de ventana, coste unitario por kilómetro, tolerancia de retraso permitida antes de marcar una parada como fallida.

Lo que el algoritmo no puede hacer por ti

• Conocer restricciones no modeladas. Si un cliente nuevo exige que el conductor hable catalán o que el vehículo lleve lona, eso tiene que estar en el dato de entrada. El algoritmo trabaja con lo que le das.
• Anticipar imprevistos en tiempo real. Un accidente en la A-6 a las 8:15 no estaba en la planificación de las 7:00. Un buen sistema permite recalcular sobre la marcha, pero requiere que los conductores alimenten el sistema con incidencias.
• Sustituir el criterio del jefe de tráfico. La optimización reduce el margen de maniobra manual, pero no lo elimina. Los conductores con 15 años en la misma zona saben cosas que ningún mapa digital recoge.

Cómo evaluar una solución antes de implantarla

Antes de firmar cualquier contrato con un proveedor de software de rutas, ejecuta estas comprobaciones:

1. Pide que carguen tus propios datos históricos, con tus restricciones reales, no un dataset de demo.
2. Verifica que el sistema modela ventanas horarias por cliente, no solo por zona.
3. Confirma que la capacidad se gestiona en las unidades que tú usas: kilos, palés, litros o metros cúbicos, no solo “stops”.
4. Comprueba que las ZBE de tus ciudades de reparto están actualizadas en la cartografía del sistema.
5. Pregunta qué pasa cuando el algoritmo no encuentra una solución factible: ¿te avisa, te propone la mejor aproximación o simplemente omite paradas sin decirte nada?
6. Revisa si el sistema registra el historial de rutas ejecutadas para que puedas comparar planificación con realidad.

Si el proveedor no puede responder con datos concretos a alguna de esas preguntas, la solución no está lista para tu operativa.

En Rowan Rutas construimos el motor de planificación sobre la operativa real de cada cliente: sus restricciones, sus vehículos, sus zonas. No hay un dataset de demo que valga para todos. La configuración inicial se hace con tus datos, y el algoritmo se ajusta hasta que las rutas que propone son rutas que tus conductores pueden ejecutar.

La firma digital de albaranes va integrada en el mismo flujo: el conductor firma en la app, el albarán queda vinculado a la entrega con timestamp y geolocalización, y el jefe de tráfico lo ve en tiempo real sin llamar al teléfono. Si quieres entender cómo funciona esa parte, aquí tienes el detalle técnico y legal.

Para empresas que gestionan también el almacén de salida, la integración entre el SGA y el módulo de rutas elimina el paso manual de trasladar pedidos preparados al planificador. Este artículo explica cómo funciona ese flujo completo.

Si quieres ver cómo quedan los datos de ejecución de rutas en un cuadro de mando operativo, la demo de Rowan Analytics está disponible sin registro.

TL;DR

• La optimización de rutas con restricciones reales (ventanas horarias, capacidad, zonas) es un problema NP-hard: ningún algoritmo garantiza la solución óptima, sino la mejor aproximación en tiempo razonable.
• Los motores comerciales usan metaheurísticas como ALNS o Simulated Annealing y se detienen cuando la mejora marginal cae por debajo de un umbral; el resultado suele estar entre un 3 % y un 8 % del óptimo teórico.
• Cuando las restricciones entran en conflicto, el algoritmo necesita una jerarquía de prioridades que tú defines, no el software.
• Una solución que no modela tus restricciones reales genera rutas matemáticamente eficientes pero operativamente inviables.
• Antes de implantar cualquier sistema, pruébalo con tus propios datos históricos y tus restricciones reales, no con datos de demo.

Lecturas recomendadas

• Gestor de rutas con firma digital de albarán: criterios técnicos y legales para elegir bien
• Software de logística y distribución para pymes: SGA, rutas y firma digital en un solo flujo
• Optimización de rutas de reparto en flotas: factores reales y límites del software genérico