Optimización de la última milla: cómo planificar un día que se sostenga

Por qué la última milla es la parte cara

Mover un palé de un extremo a otro del país es un problema resuelto: mucho volumen, pocas paradas, horarios predecibles y un coste que se reparte entre muchas unidades. El tramo final invierte todas esas propiedades. Cada paquete va a una puerta distinta, cada puerta consume unos minutos del tiempo de una persona, y ese tiempo se divide entre un pedido en lugar de entre mil.

Hay tres hechos estructurales que hacen que este tramo se comporte de forma distinta al resto de la cadena:

• El coste es por parada, no por kilómetro. Dos direcciones en el mismo edificio no cuestan casi nada más; dos direcciones en extremos opuestos de la ciudad cuestan una hora. La distancia importa, pero el orden de las paradas importa más.
• La capacidad son personas, y las personas son inelásticas. Un turno tiene un número fijo de horas de trabajo. No se puede añadir un diez por ciento más de horas a las cinco de la tarde, así que un plan que se pasa de largo se convierte, sin más, en visitas fallidas.
• Es el único tramo que el cliente experimenta. La productividad del almacén es invisible; una ventana de dos horas incumplida, no. La calidad de servicio en este tramo impulsa la recompra como ninguna otra etapa.

Esa combinación explica por qué aquí las pequeñas mejoras de planificación se amortizan rápido. Recortar el tiempo muerto entre paradas no solo ahorra combustible: mete más trabajos completados dentro del mismo turno pagado, que es la cifra que de verdad le interesa al área financiera.

Dónde se esconden realmente las pérdidas

Antes de comprar un motor conviene averiguar qué pierde el día actual. En la mayoría de los equipos las fugas no son exóticas: son las mismas cuatro y se acumulan entre sí.

• Un plan desequilibrado. Un mensajero termina a las dos de la tarde mientras otro sigue trabajando a las ocho. El desequilibrio es invisible en una pizarra y evidente en las marcas de hora de finalización.
• Zigzags. Las secuencias armadas a mano tienden a cruzar el barrio de un lado a otro, porque el planificador las montó en el orden en que llegaron los pedidos y no en el orden que permiten las calles.
• El plan y el día se separan. El plan de la mañana es una hipótesis. Pedidos urgentes nuevos, una avería, un cliente que reprograma: al mediodía la versión en papel describe una jornada que ya no existe, y nadie replanifica porque hacerlo a mano cuesta una hora.
• Visitas fallidas. La línea más cara de todas: el mensajero condujo, esperó y volvió con el paquete. El viaje se paga dos veces y el cliente se enfada una.

Estas fugas comparten una causa. El planificador resuelve a mano, y con prisa, un problema cuyo número de respuestas posibles crece más rápido de lo que nadie puede evaluar. Veinte paradas se pueden ordenar de más maneras que segundos tiene la edad del universo; una persona elige una razonable y sigue adelante. Lo razonable suele estar lejos de lo bueno, y nunca se sabe cuánto, porque no hay nada con qué comparar.

Qué resuelve de verdad un motor de optimización

El nombre formal de esta tarea es problema de rutas de vehículos: dado un conjunto de direcciones, un conjunto de vehículos o técnicos de campo y un conjunto de restricciones, encontrar la asignación y la secuencia que completen el trabajo al menor coste. Es un problema muy estudiado, con solvers maduros, y las herramientas de planificación modernas se apoyan en esos solvers en lugar de en heurísticas escritas a mano.

Lo que importa en la práctica es que el motor optimice según tus restricciones, no según un libro de texto. Un plan utilizable tiene que respetar aquello que hoy el coordinador lleva en la cabeza:

• Ventanas horarias. El intervalo pactado con el cliente y el horario laboral del turno.
• Capacidad. Lo que cabe en el vehículo y cuántos trabajos puede cerrar una persona en un día de forma realista.
• Reglas de asignación. Competencias, equipamiento, zonas, el cliente que insiste en que vaya siempre el mismo técnico.
• Tiempo de servicio en la parada. Una entrega en la puerta y una instalación no son el mismo evento, y un plan que los trate igual se desbordará antes del mediodía.

En itlogist el motor de rutas está construido sobre OR-Tools y tiene en cuenta las ventanas de entrega y las restricciones al armar el plan, junto con las partes operativas del día: la recepción de pedidos y su reparto entre los empleados de campo, las rutas en vivo sobre el mapa y la confirmación in situ de que el trabajo se hizo. Si quieres el panorama completo de cómo encajan las piezas, mira el ruteo en itlogist.

Lo que el motor no resuelve son los datos. Si los tiempos de servicio son una suposición, las direcciones están sin verificar y la mitad de los pedidos entran por teléfono a las once de la mañana, un plan óptimo construido sobre esa base se caerá igual: simplemente se caerá de forma más ordenada.

Ventanas horarias: la restricción que decide el plan

Nada moldea una ruta tanto como la promesa hecha al cliente. Una ventana amplia da libertad para agrupar paradas por criterio geográfico; una estrecha impone la secuencia y puede obligar a un mensajero a cruzar la ciudad dos veces en una tarde. Es la palanca que la mayoría de los equipos ajusta la última y debería ajustar la primera.

De cómo tratan los solvers las ventanas se derivan unas cuantas reglas prácticas:

• Las ventanas estrechas son un producto de pago, no una opción por defecto. Cada hora que recortas de la promesa cuesta tiempo de vehículo en algún sitio. Ofrece precisión donde el cliente la valore y cóbrala, en lugar de prometerla en todas partes e incumplirla.
• Las ventanas se ofrecen contra un plan real. Un hueco que el sistema sabe alcanzable vale más que un hueco que un operador se inventó para cerrar la llamada.
• Mezclar ventanas es mejor que uniformarlas. Un día en el que algunas paradas son flexibles le da al motor margen para absorber las rígidas. Si cada parada es urgente, no queda nada que optimizar.
• Mide el cumplimiento, no solo la finalización. Un pedido entregado fuera de su ventana es al mismo tiempo un trabajo completado y una promesa rota, y solo una de las dos cosas aparece en la tasa de finalización.

La otra mitad de la promesa es contarle al cliente en qué punto está su pedido. Un portal del cliente con estados en vivo elimina la mayoría de las llamadas que no preguntan otra cosa que «cuándo», y son justo esas llamadas las que apartan al coordinador del trabajo de gestionar la jornada.

El turno después del plan: control, excepciones, confirmación

Un plan es una suposición sobre las próximas ocho horas. La optimización rinde solo si esa suposición se vigila y se corrige, y por eso la pantalla de planificación y la de ejecución tienen que ser el mismo sistema. Tres capacidades sostienen esa carga.

• Rutas en vivo sobre el mapa. El coordinador ve dónde está cada empleado de campo respecto al plan y detecta un retraso cuando todavía hay tiempo de reaccionar: pasar las dos últimas paradas a un compañero, avisar al cliente, reprogramar a conciencia en vez de fallar en silencio.
• Estados actualizados sobre la marcha. El mensajero cambia el estado de cada pedido en la propia parada, así que la oficina nunca tiene que reconstruir la jornada a partir de una llamada.
• Confirmación en la puerta. Los informes fotográficos y las listas de comprobación en la interfaz móvil cierran el trabajo con evidencias adjuntas al pedido. En itlogist el empleado de campo trabaja desde una interfaz web móvil sin necesidad de instalar una app, algo que cuenta cuando parte de la flota son eventuales o subcontratas.

Las excepciones merecen la misma disciplina que los éxitos. Una visita que termina sin entrega ha consumido igualmente una hora de turno pagado y, si el motivo se registra desde una lista cerrada en vez de describirse en texto libre, un mes de esos registros te dice qué zonas, clientes o franjas generan los fallos. Ese es el bucle de realimentación que mejora el siguiente plan: el motor optimiza la secuencia, los datos de excepciones arreglan las entradas.

Cómo empezar sin montar un proyecto de seis meses

Los proyectos de optimización se atascan por motivos organizativos mucho más a menudo que por motivos técnicos. Un enfoque por etapas evita la trampa habitual de rehacerlo entero de golpe.

• Arregla primero los datos de direcciones. Nada degrada un plan más rápido que unas coordenadas que apuntan al patio equivocado. Es un trabajo poco lucido y marca el techo de cuanto viene después.
• Mide la jornada actual con honestidad. Paradas completadas por turno, tiempo entre paradas, porcentaje de visitas fallidas, porcentaje de pedidos entregados dentro de su ventana. Sin una línea base no sabrás si el plan nuevo es mejor o simplemente distinto.
• Estima el tiempo de servicio por tipo de trabajo. Pregunta a los mensajeros y luego contrasta con las marcas de hora reales. Los solvers valen lo que vale ese número.
• Conecta las fuentes de pedidos. itlogist intercambia datos con 1C, AmoCRM, Bitrix24 y Excel, así que los pedidos llegan desde los sistemas que ya usas en lugar de tener que reescribirlos en uno nuevo.
• Haz un piloto con un solo grupo. Aplica la planificación automática a una zona o a un equipo durante dos semanas y compárala con la línea base. itlogist está pensado para arrancar en 7 días, funciona sin contratos de permanencia y encaja en equipos de 5 a 100 empleados de campo, así que un piloto son quince días de atención y no un trimestre.
• Al principio, revisa cada semana. Fíjate en qué corrigió el coordinador a mano. Cada corrección manual es o bien una restricción que falta en el modelo, o bien una costumbre que conviene jubilar, y las dos cosas vale la pena saberlas.

Hecho en este orden, optimizar deja de ser la compra de un software y pasa a ser lo que debería: menos hueco entre paradas, una promesa en la que el cliente puede confiar y un turno que termina cuando estaba previsto que terminara.