Actualización de mayo de 2016: Las complicaciones abordadas en esta página han sido eliminadas por completo a través de un mejor diseño de nuestro
motor de pronóstico probabilístico. Le recomendamos vivamente que pase a esta nueva tecnología.
El concepto de agregación de datos por día, semana o mes presenta varios problemas sutiles, comenzando por las definiciones mismas de día, semana y mes respectivamente. Este artículo analiza el método adoptado por Lokad para tratar estas agregaciones, tanto a nivel de entrada (datos históricos) como de salida (pronósticos). Y, además, proporciona algunos consejos sobre cómo manipular, en la práctica, diferentes convenciones de agregación de datos.
Terminología: artículo y orden
Los términos
artículo (
item) y
orden se refieren al
formato de datos de entrada de Lokad. En este artículo, esos términos deberían entenderse de acuerdo con la definición de Lokad. Un
artículo (
item) representa un objetivo por pronosticar. Un
artículo puede ser un producto, una SKU, un código de barras, de acuerdo con la actividad. Una
orden representa una cantidad asociada a un artículo en una fecha determinada en el pasado. Una
orden puede ser una venta, un envío, un consumo, de acuerdo con la actividad.
Agregaciones según Lokad
Lokad se vale de las siguientes convenciones:
- Los días comienzan a las 00h00 por la mañana; por lo tanto, cada valor de pronóstico diario cubre un período que comienza a las 00h00 y termina a las 23h59:59.
- Las semanas comienzan los lunes; por lo tanto, cada valor de pronóstico semanal cubre un período que comienza el lunes (inclusive) y termina el domingo (inclusive).
- Los meses comienzan el 1.er día del mes; por lo tanto, cada valor de pronóstico mensual cubre un período que comienza el primer día del mes y termina el último del mes.
Estas convenciones no pueden ser cambiadas en Lokad; no obstante, veremos a continuación cómo trabajar con otras convenciones que podrían ser necesarias en determinadas empresas.
Tolerancia hacia los patrones de agregación de datos de entrada
Lokad intenta ser tolerante cuando se trata de procesar los datos históricos. En particular, si bien se recomienda aplicar una agregación diaria (es decir, para un determinado artículo en un determinado día reunir todas las órdenes como una sola cantidad para el día), Lokad también acepta otras situaciones.
Historial desagregado puro
La agregación diaria reduce la dimensión del conjunto de datos que se debe cargar a Lokad. Esta reducción se produce sin ningún inconveniente para lo que tiene que ver con la precisión del pronóstico. Sin embargo, si el conjunto de datos es relativamente pequeño desde el comienzo, los beneficios resultan poco significativos. Por lo tanto, Lokad también elabora un historial totalmente desagregado con una línea por cada transacción. En este caso, las cantidades diarias se computan como la suma de los valores de
orden para el artículo y el día en cuestión.
Historial preagregado semanal o mensualmente
A veces, los datos históricos agregados diariamente no han sido preservados en el sistema de la empresa en los que se originan los datos de entrada: solo quedan los datos agregados semanal o mensualmente. Lokad puede procesar
órdenes preagregadas semanal o mensualmente.
Si los datos están agregados semanalmente, Lokad debería restringirse a pronósticos semanales clásicos. No deberían utilizarse los pronósticos diarios, mensuales ni cuantílicos, ya que los resultados estadísticos no tendrían sentido. De modo similar, si los datos están agregados mensualmente, Lokad debería ser restringido a los pronósticos mensuales clásicos.
La principal desventaja de los datos preagregados es la limitación que crean con respecto al tipo de pronósticos que pueden elaborarse. Otra desventaja es una pequeña pérdida de precisión. De hecho, Lokad puede utilizar patrones diarios para refinar pronósticos incluso para pronósticos semanales o mensuales.
¿Cuándo comienzan los pronósticos?
Para generar un pronóstico, Lokad define un umbral que representa el
presente, es decir, la fecha de inicio de los pronósticos. Para computar ese umbral, Lokad adopta principalmente una óptica centrada en los datos: los pronósticos inician donde terminan los datos históricos. Por ejemplo, si los datos históricos terminan el 15 de mayo (inclusive) los pronósticos diarios comienzan al día siguiente, el 16 de mayo.
La óptica centrada en los datos es conveniente, especialmente para las comparaciones. Los datos pueden truncarse en algún punto en el pasado, y Lokad genera pronósticos que ya pueden ser comparados con los datos históricos (no truncados), ya que los pronósticos mismos son parte del pasado.
En particular, tanto los pronósticos diarios clásicos como los pronósticos cuantílicos se comportan de modo similar: el pronóstico siempre comienza el día después de la
orden más reciente encontrada en el conjunto de datos de entrada.
En el caso de los pronósticos clásicos semanales o mensuales, la situación es más delicada. Por ejemplo, supongamos que los datos históricos (es decir, las
órdenes en terminología de Lokad) terminan el 15 de mayo: ¿los pronósticos deberían iniciar el 1 de mayo o el 1 de junio? La respuesta de Lokad es que los pronósticos comienzan el 1 de mayo. De hecho, debido a que los datos para el mes de mayo son aún parciales, Lokad trunca los datos hasta el último día de abril, de modo que se pueda realizar un pronóstico mensual clásico regular (*) para el mes de mayo.
(*)
Técnicamente, sería posible diseñar modelos de pronóstico que pudieran aprovechar los datos disponibles para el período parcial; sin embargo, esto representaría una función de pronóstico compleja y, como tal, por el momento no es admitida por Lokad.Datos agregados semanal o mensualmente
En el caso de datos agregados mensualmente (o semanalmente), la acción de truncado de Lokad puede generar resultados accidentales. Supongamos, por ejemplo, que tenemos un historial de
orden agregado mensualmente, con una sola
orden para cada primer día del mes. Supongamos que el 1 de mayo de 2013 representa la última fecha de los datos históricos. En este caso, Lokad interpreta el mes de mayo como parcialmente observado; por lo tanto, mayo se trunca y, como resultado, los pronósticos comienzan el 1 de mayo. Debido a que el punto de datos para el 1 de mayo representa a todo el mes de mayo, no es el comportamiento deseado.
Para evitar el truncado, se recomienda introducir una sola línea de
orden (siendo la cantidad de la orden cero) como fecha que representa el último día del mes en curso. En el ejemplo anterior, la introducción de una línea de una línea de
orden con fecha 31 de mayo le indica a Lokad que el mes de mayo está completo, y, por lo tanto, que el pronóstico debería comenzar el 1 de junio. Una técnica similar, es decir, introducir una línea de orden con cantidad cero, puede ser utilizada para abordar el mismo problema al considerar los pronósticos semanales.
Agregar una línea de orden “dummy” de este tipo tendría un impacto negativo en cualquier pronóstico cuantílico realizado en paralelo al pronóstico mensual clásico en Lokad. En la práctica, cuando los datos se agregan mensualmente, no debería aplicarse ningún pronóstico cuantílico al conjunto de datos.
Limpieza de los datos futuros, una excepción a la óptica centrada en los datos
Existe una excepción a la óptica centrada en los datos: como verificación de limpieza, Lokad filtra
órdenes a más de 1 semana en el futuro (el
futuro definido de acuerdo con el reloj del servidor del ordenador que ejecuta Lokad).
De hecho, regularmente observamos que algunos de nuestros clientes acaban extrayendo
irregularidades de sus sistemas con fechas en el futuro más o menos lejano. Esas líneas generalmente no son ventas ni envíos reales, sino los resultados de pruebas realizadas en algún momento con el sistema de la empresa.
Naturalmente, desde una perspectiva comercial, tiene poco sentido confiar en datos históricos que ni siquiera existen aún. Por lo tanto, Lokad trunca estos datos como procedimiento de
limpieza de datos, y luego retoma el proceso de pronóstico.
Agregación mensual o semanal alternativa
Desde el punto de vista de Lokad, el período mensual siempre empieza el 1 de cada mes. Sin embargo, algunas empresas necesitan una convención diferente, por ejemplo, estableciendo que cada período comience el día 25 de cada mes.
Para procesar situaciones como esta, recomendamos preagregar el historial de las
órdenes hacia los períodos objetivos. En el caso anterior, el rango de fechas desde el 25 de mayo hasta el 24 de junio debería ser agregado en una sola línea de orden. Esta línea pasa entonces a representar el valor mensual
personalizado para el artículo, y debería posicionarse en el 1.er día del mes
antes del rango original. Luego, Lokad genera pronósticos que comienzan el 1 de cada mes que pueden traducirse a la convención original, por ejemplo, el 25 de cada mes.
Es importante utilizar una fecha que preceda el rango de fechas, porque, de lo contrario, parte de los datos resultantes pueden acabar posicionados en el futuro y luego ser truncados por Lokad siguiendo la política de que los datos futuros deberían truncarse (ver más arriba).
