Dispatch inteligente para distribución bajo demanda

La distribución bajo demanda es una industria que está creciendo a muy alta velocidad. Todos los días aparecen nuevas empresas, especialmente en el mercado de alimentos, bebidas y entregas de productos perecederos. Y la competencia es salvaje. La eficiencia es una métrica clave en la era de «Lo quiero todo y lo quiero ahora» y la parte más crítica es lo que sucede desde que se realiza un nuevo pedido hasta que se entrega.

Hoy quiero centrarme en el problema de enviar nuevos pedidos, es decir, cómo decidir cuál es el servicio de mensajería al que se debe asignar el pedido cuando un pedido ingresa en el sistema. Esto se debe a que el dispatch hoy en día no se aborda sistemáticamente. La optimización del sistema de dispatch puede minimizar el tiempo de entrega y mejorar la satisfacción del cliente.

El paradigma operativo de las empresas que realizan entregas bajo demanda se puede dividir en dos tipos diferentes:

1. Operativa basada en un solo almacén son aquellas operativas centradas en un solo depósito. Este depósito tiene varios reparidores y la programación se realiza una vez para obtener una lista de pedidos; generalmente agrupando los pedidos por áreas. Amazon Prime es un buen ejemplo de este paradigma.
2. Operativa basada en múltiples almacenes son aquellas operativas que confían en elegir el pedido en uno de los múltiples depósitos y entregarlo a un cliente. En este caso, los repartidores se encuentran dispersas por la ciudad, y una vez que llega un nuevo pedido, se asigna mediante un proceso de envío a uno de los múltiples repartidores. Empresas como Uber, Just Eat, Delivero, etc. operan de esta forma.

El problema del dispatching se resuelve más o menos satisfactoriamente en el primer escenario gracias a la posibilidad de encadenar una lista de entregas y considerándolo como un Problema del vendedor viajero (Traveling Salesman Problem) con algunas restricciones pre-clustering (OK, se que el TSP es un problema caro, pero… venga, se trata de Amazon).

Al contrario en el segundo escenario, no está tan claro que el problema se aborde de manera óptima. ¿Cómo se puede agregar un nuevo pedido entrante a un escenario en ejecución? Hay toneladas de variables que deben tenerse en cuenta:

• ¿Puede el mensajero realizar múltiples recogidas antes de comenzar a entregar?
• ¿Se puede reasignar un pedido ya asignado a otro servicio de mensajería?
• ¿Todas las órdenes tienen la misma prioridad? (por ejemplo, todos los pedidos deben entregarse antes de los 30 minutos posteriores a su realización) ¿Los pedidos requieren ser entregados por un vehículo en particular?
• …

Foto de Roman Mager / Unsplash

Modelar este escenario puede ser bastante desafiante, y por eso en Routal (antes SmartMonkey) hemos trabajado en este problema. Llamamos a nuestra solución Modelo de optimización de programación en línea (OSOM) (Sí, la marca no es uno de nuestros puntos fuertes 😅, pero fonéticamente suena como «increíble» y eso es bastante divertido). OSOM puede modelar las restricciones comerciales y encontrar una solución factible para el problema de dispatching.

En la simulación que se ofrece a continuación, hemos modelado un mundo donde:

• a un servicio de mensajería se le pueden asignar múltiples recogidas y entregas a la vez
• y el primer servicio próximo de cada servicio de mensajería es fijo y no se puede reasignar en las siguientes iteraciones.

La visualización contiene veinte iteraciones del mundo divididas en dos pasos:

1. Los nuevos servicios entrantes están marcados en color gris.

2. Los servicios se asignan dinámicamente a los repartidores para optimizar el tiempo de entrega general.