Pronóstico de tiempo de entrega

Pronóstico de tiempo de entrega











Inicio » Recursos » Aquí

El cálculo preciso de los tiempos de entrega futuros es esencial para calcular con precisión la cantidad de inventario necesaria para satisfacer la demanda futura. El motor de pronóstico de Lokad cuenta con un modo de pronóstico de tiempo de entrega que está pensado específicamente para los tiempos de entrega. De hecho, los tiempos de entrega deben pronosticarse del mismo modo que se pronostica la demanda, ya que también presentan varios patrones estadísticos, como efectos de estacionalidad y día de la semana. Los pronósticos de tiempo de entrega elaborados por el motor de pronóstico de Lokad son probabilísticos y representan las probabilidades esperadas de la duración de cada uno de los tiempos de entrega expresada en días. En esta página, describimos en detalle la sintaxis utilizada para calcular los pronósticos de tiempo de entrega a través de Lokad.

Sintaxis general

El motor de pronóstico tiene una función especial: la función llamada, como se conoce en la terminología de Envision. La sintaxis es la siguiente:

Leadtime = forecast.leadtime(
  category: C1, C2, C3, C4
  hierarchy: H1, H2, H3, H4
  supplier: Supplier
  offset: 0
  present: max(Orders.Date) + 1
  leadtimeDate: PO.Date // "PO" significa pedido de compra
  leadtimeValue: PO.ReceivedDate - PO.Date + 1
  leadtimeSupplier: PO.Supplier)

A diferencia de las funciones habituales, las funciones llamada tienen argumentos con nombre en lugar de posicionales. Estos argumentos con nombre son más adecuados para funciones complejas, porque hacen que el código fuente sea mucho más legible, a cambio de un poco más de detalle. Estos argumentos se comportan como los argumentos de función habituales; por lo tanto, admiten las expresiones de Envision.

La función devuelve un vector Leadtime que es del tipo distribución (vea también el artículo sobre el álgebra de distribuciones). Las distribuciones son un tipo de datos avanzado que representan funciones $p: \mathbb{Z} \to \mathbb{R}$. Más específicamente, el motor de pronóstico devuelve variables aleatorias, es decir, distribuciones que son positivas y tienen una masa igual a 1. En el caso actual, $p(k)$ representa la probabilidad de tiempo de entrega asociada con $k$ días. Cada artículo —en el sentido utilizado en Envision— se asocia con su propia distribución.

La sintaxis completa de forecast.leadtime incluye muchos argumentos; sin embargo, solo dos de ellos son obligatorios:

  • present: un valor de fecha escalar
  • leadtimeDate: un vector de fecha con una afinidad de artículo

El valor present es la fecha equivalente al primer día por pronosticar, suponiendo que existen datos completos hasta el día anterior. De hecho, algunos negocios pueden, por ejemplo, estar cerrados los domingos, y si la fecha más reciente encontrada en el conjunto de datos es un sábado, se presenta el dilema de si el pronóstico debería comenzar el domingo o el lunes. En la sintaxis ilustrativa a continuación, utilizamos max(Orders.Date) + 1, suponiendo que los pedidos se observan todos los días y que los datos de entrada son recientes del día anterior.

Se espera que el leadtimeDate y el leadtimeValue pertenezcan a la misma tabla que muestra una afinidad de artículo, es decir, (Id, *) en terminología de Envision. Las fechas representan los días de inicio (incluidos) de las observaciones del tiempo de entrega. Se espera que los valores se expresen en días. No se admiten días fraccionarios. Esta tabla contiene el historial del tiempo de entrega real pronosticado por el motor de pronóstico.

Cuando se omite leadtimeValue, las duraciones sucesivas en medio de las fechas de leadtimeDate se utilizan, en cambio, como valores de tiempo de entrega. Este comportamiento está pensado para pronosticar el tiempo de entrega de pedido, algo que generalmente se realiza separado del pronóstico de tiempo de entrega de suministro.

Idealmente, el historial debería ser lo más extenso posible, si bien en la práctica los beneficios de superar los 5 años de tiempos de entrega son limitados. El motor de pronóstico se adapta tanto a un historial de tiempo de entrega breve como extenso: cuando el historial es extenso, los puntos de datos más antiguos simplemente se vuelven estadísticamente irrelevantes.

Además de estos argumentos obligatorios, la precisión de los pronósticos puede mejorarse significativamente proporcionando más datos al motor de pronóstico. Las secciones a continuación explican este concepto con más detalle.

Categorías y jerarquía

Las categorías y la jerarquía desempeñan un rol similar desde el punto de vista del motor de pronóstico: ayudan a este último a gestionar los datos históricos dispersos. De hecho, para un determinado artículo, la cantidad de observaciones de tiempo de entrega puede ser limitada, tal vez solo unas pocas observaciones por año. En esas situaciones, pronosticar el tiempo de entrega futuro basado solamente en datos que tenemos para un determinado artículo resulta bastante impreciso, porque el cálculo contiene mucho ruido.

El motor de pronóstico de Lokad aborda esta problemática aprovechando de modo extensivo las correlaciones entre las observaciones de tiempo de entrega. Sin embargo, debido a que los tiempos de entrega se presentan dispersos, es bastante difícil correlacionarlos teniendo en cuenta solo sus valores. Como resultado, el motor de pronóstico intenta aprovechar las relaciones que existen entre los artículos.

Con el término jerarquía se hace referencia a una organización jerárquica (estructura de árbol) de todos los artículos. El motor de pronóstico admite hasta 4 niveles de jerarquía. Cuando existen múltiples niveles jerárquicos, estos deberían transmitirse al motor de pronóstico por orden de importancia decreciente; es decir, el primer argumento representa el nivel jerárquico superior. El motor de pronóstico no admite múltiples jerarquías.

Las categorías están pensadas para diferentes categorizaciones de los artículos que resultan relevantes para el pronóstico. En la práctica, las categorías pueden utilizarse para reflejar diferentes atributos de los artículos, como marca, material o color. Las categorías también pueden utilizarse como un modo alternativo de representar una jerarquía secundaria. El motor de pronóstico admite hasta 4 atributos de categoría distintos.

En la práctica, recomendamos utilizar la jerarquía canónica y la categorización de artículo del modo que se encuentra habitualmente y que los especialistas del sector de interés utilizan. El motor de pronóstico es resistente al ruido; por lo tanto, si bien no es recomendable alimentar al motor de pronóstico con datos irrelevantes, es casi siempre mejor transmitirle una categoría que, a fin de cuentas, internamente no se utiliza en lugar de darle observaciones de tiempo de entrega puras.

Proveedor

La elección del proveedor a menudo desempeña una función importante en el cálculo del tiempo de entrega. Los datos del proveedor pueden comunicarse al motor de pronóstico de dos modos que son complementarios.

En primer lugar, las observaciones de tiempo de entrega pueden categorizarse por proveedor. Esta es la finalidad del argumento leadtimeSupplier. Cuando este argumento está presente, el motor de pronóstico aprovecha esta información para evaluar si los tiempos de entrega asociados con un determinado proveedor presentan correlaciones o no. La información de proveedor ofrece una granularidad de información que puede no encontrarse en la jerarquía o en las categorías del artículo individual, porque los artículos provienen de diferentes proveedores en el tiempo.

En segundo lugar, es posible informar al motor de pronóstico sobre qué proveedor debe considerarse para el próximo envío. Esta es la finalidad del argumento supplier. Cuando este argumento está presente, el motor de pronóstico puede anticipar que un artículo puede sufrir modificaciones repentinas en el tiempo de entrega porque el proveedor acaba de cambiar. Naturalmente, el motor de pronóstico solo podrá aprovechar esta información si el historial de tiempo de entrega mismo está categorizado adecuadamente por proveedor, como se ve más arriba.

Desfases del tiempo de entrega

Por defecto, el pronóstico comienza el día present (actual). Sin embargo, a veces puede preferirse que un pronóstico comience más tarde, en una fecha posterior. Si los tiempos de entrega son estacionales, la fecha de inicio del tiempo de entrega puede tener un impacto significativo en su distribución del valor. Este caso se gestiona a través de las propiedades offset. Esta propiedad opcional espera contar con un vector numérico de la tabla artículos. Los valores de este vector representan los desfases —expresados en días— que deben considerarse para los pronósticos de tiempo de entrega. Por ejemplo, si un artículo tiene un valor de desfase 10, el primer día del tiempo de entrega pronosticado será present + 10. Cuando el offset se omite, todos los desfases se consideran iguales a cero.