Detección de quiebres de disponibilidad de productos en góndolas

Contexto

Uno de los grandes desafíos que experimentan las cadenas de supermercados es lograr la reposición oportuna de los productos en los locales, para que estén disponibles cuando el cliente los vaya a buscar a la góndola.

Como Brain Food nos tocó participar de un proyecto con una cadena de supermercados para mejorar la disponibilidad de los productos en locales y evitar la pérdida de venta por falta de estos.

El proyecto contaba con una serie de herramientas y frentes a trabajar, para lograr el objetivo:

  • Modelo matemático y computacional de predicción de demanda de los diferentes productos de cada uno de los locales de la cadena
  • Alerta en vivo que avisara a la operación de los productos que presentaran problemas de disponibilidad
  • KPI y reportes asociados a las predicciones y resultados del modelo
  • Aplicación que se conectara a los sistemas y comunicara los resultados a la operación
Solución

Modelo

Como fue mencionado, uno de los frentes del proyecto era definir y medir un KPI que dimensionara la venta que no se había efectuado por falta de disponibilidad. Dado que estas ventas nunca ocurrieron y, por lo tanto, no hay datos de esta, fue que determinamos que lo mejor era medirla con un modelo predictivo.

Para ello, lo que hizo el equipo fue, en base a la historia de ventas de los supermercados, entrenar un modelo de tipo XGBoost que realizaba una predicción de demanda para cada producto, local, día y hora. Dada la magnitud del problema, fue una solución compleja de implementar, en la que hubo que combinar muchas variables: descuentos, feriados, cuarentena, etc.

Además, se clusterizaron los productos según categorías de distribución de ventas:

Como era de esperarse, los mejores resultados del modelo fueron para los productos Smooth, con una precisión de más de un 70% en cada hora, día y local. Mientras que para los Intermittent y Erratic los resultados bordeaban el 50%. Con ello ya se abarcaba cerca de un 80% de las ventas de los locales, así que, por alcances del proyecto, los Lumpy quedaron para una etapa posterior.

Alerta

El desafío consistía en implementar en pocas semanas una herramienta que fuera avisando en vivo a la operación qué productos ir a reponer, puesto que no estaban teniendo las ventas esperadas.

Nuestra primera aproximación fue ocupar el modelo de predicción ya descrito. Sin embargo, al momento de hacerlo (que era en una etapa temprana del proyecto), este todavía tenía un alto margen de error y se requirió de un buen tiempo para mejorarlo. Para lograr los plazos que el proyecto asignaba a la alerta requeríamos de una solución más rápida y eficiente.

Así fue como se nos ocurrió un enfoque distinto: en conjunto con el cliente se estudió que era razonable modelar las ventas de los productos utilizando una distribución de Poisson, nuestra nueva propuesta consistía en asumir esta distribución y calcular la probabilidad de que un determinado producto hubiera tenido un quiebre en las horas anteriores a cada alerta.

Bajo el supuesto de que la venta de los distintos productos responde a una variable Poisson, se puede asumir que los tiempos entre eventos distribuyen exponencial con parámetro correspondiente a 1/lambda, donde lambda corresponde al promedio de ventas por hora de cada uno de los productos.

Esto permite determinar la probabilidad de que cada producto pase un determinado tiempo sin vender y, cuando superaba un margen crítico, era agregado a la alerta y anunciado a la operación.

Con esta simple herramienta implementada en apenas unas semanas, se obtuvieron resultados de más del 50% de precisión en la alerta, es decir, al menos uno de cada dos productos de los anunciados en vivo estaba efectivamente teniendo problemas de disponibilidad. El cliente, en sus cálculos iniciales para estimar la disponibilidad de productos, estaba obteniendo una precisión entre el 10% y 30%, por lo que el resultado de nuestra herramienta significó una mejora importante en este aspecto. Es importante destacar, además, que se obtuvieron estos resultados incluso bajo el efecto de variables externas de gran impacto negativo en la predicción, como cuarentenas y cambios de fases por el covid.

Esto permitía a la operación solucionar el problema en vivo e ir a reponer el producto indicado, para evitar así la pérdida de ventas.

KPI

El indicador de cuánta venta se había perdido por falta de disponibilidad era una combinación de las dos componentes ya descritas: modelo y alerta.

En primer lugar, identificaba con la misma lógica de probabilidades de Poisson qué productos efectivamente estaban teniendo un quiebre de ventas. Y, en segundo lugar, para estos determinaba el monto que debían haber vendido según lo que indicaba el modelo. Así se determinaba cuánta venta se había perdido.

El KPI permitió identificar los montos de venta perdida que se estaban teniendo por cada uno de los supermercados, comparar, ver tendencias y tomar acciones respecto a ello.

Aplicación

Un desafío importante del proyecto y transversal a las componentes mencionadas, era la comunicación con la operación.

Para ello, programamos una API que se conectaba a los servidores que contenían los resultados del modelo, KPI y alerta y esta, a su vez, entregaba los datos a una aplicación que mostraba la información en el celular de la operación.

Conclusiones

Finalizado el proyecto, como equipo somos conscientes de que existen variadas mejoras que se podrían hacer a la solución, como relajar el supuesto de que la distribución de los productos es Poisson y estudiar en detalle otras posibles variables que podrían afectar los resultados del modelo, como los productos que son sustitutos entre ellos.

Como producto final obtuvimos un programa que era capaz de conectarse a los sistemas del cliente, ir a buscar la venta histórica, predecir la demanda que no había sido efectuada por problemas de disponibilidad, discriminar por probabilidad de quiebre, hacer una alerta y construir un KPI de manera automática. Todo esto en un flujo continuo de información que no terminaba en los servidores donde fue programado el modelo, sino en los celulares de la operación y en reportes de Power BI que revisaba cada gerencia.