00:00 Introducción
02:55 El caso de los tiempos de entrega
09:25 Tiempos de entrega del mundo real (1/3)
12:13 Tiempos de entrega del mundo real (2/3)
13:44 Tiempos de entrega del mundo real (3/3)
16:12 Lo que llevamos hasta ahora
19:31 ETA: 1 hora a partir de ahora
22:16 CPRS (recapitulación) (1/2)
23:44 CPRS (recapitulación) (2/2)
24:52 Validación cruzada (1/2)
27:00 Validación cruzada (2/2)
27:40 Suavizado de los tiempos de entrega (1/2)
31:29 Suavizado de los tiempos de entrega (2/2)
40:51 Composición del tiempo de entrega (1/2)
44:19 Composición del tiempo de entrega (2/2)
47:52 Tiempo de entrega cuasiestacional
54:45 Modelo de tiempo de entrega log-logístico (1/4)
57:03 Modelo de tiempo de entrega log-logístico (2/4)
01:00:08 Modelo de tiempo de entrega log-logístico (3/4)
01:03:22 Modelo de tiempo de entrega log-logístico (4/4)
01:05:12 Modelo de tiempo de entrega incompleto (1/4)
01:08:04 Modelo de tiempo de entrega incompleto (2/4)
01:09:30 Modelo de tiempo de entrega incompleto (3/4)
01:11:38 Modelo de tiempo de entrega incompleto (4/4)
01:14:33 Demanda durante el tiempo de entrega (1/3)
01:17:35 Demanda durante el tiempo de entrega (2/3)
01:24:49 Demanda durante el tiempo de entrega (3/3)
01:28:27 Modularidad de las técnicas predictivas
01:31:22 Conclusión
01:32:52 Próxima clase y preguntas de la audiencia
Descripción
Los tiempos de entrega son un aspecto fundamental de la mayoría de las situaciones de la cadena de suministro. Los tiempos de entrega se pueden y se deben pronosticar al igual que la demanda. Se pueden utilizar modelos de pronóstico probabilístico dedicados a los tiempos de entrega. Se presentan una serie de técnicas para elaborar pronósticos probabilísticos de tiempo de entrega para fines de la cadena de suministro. Componer esos pronósticos, tiempo de entrega y demanda, es un pilar fundamental de la modelización predictiva en la cadena de suministro.
Transcripción completa
Bienvenidos a esta serie de conferencias sobre la cadena de suministro. Soy Joannes Vermorel y hoy presentaré “Pronóstico de tiempos de entrega”. Los tiempos de entrega, y en general todos los retrasos aplicables, son un aspecto fundamental de la cadena de suministro cuando se intenta equilibrar la oferta y la demanda. Se deben tener en cuenta los retrasos que están involucrados. Por ejemplo, consideremos la demanda de un juguete. La anticipación adecuada del pico estacional de demanda antes de Navidad no importa si los productos se reciben en enero. Los tiempos de entrega gobiernan los detalles de la planificación tanto como lo hace la demanda.
Los tiempos de entrega varían; varían mucho. Este es un hecho y presentaré algunas pruebas en un minuto. Sin embargo, a primera vista, esta proposición es desconcertante. No está claro por qué los tiempos de entrega deberían variar tanto en primer lugar. Tenemos procesos de fabricación que pueden operar con menos de un micrómetro de tolerancia. Además, como parte del proceso de fabricación, podemos controlar un efecto, como la aplicación de una fuente de luz, hasta un microsegundo. Si podemos controlar la transformación de la materia hasta el micrómetro y hasta el microsegundo, con suficiente dedicación, deberíamos poder controlar el flujo de demandas con un grado comparable de precisión. O tal vez no.
Esta línea de pensamiento podría explicar por qué los tiempos de entrega parecen ser tan subestimados en la literatura de la cadena de suministro. Los libros de la cadena de suministro y, en consecuencia, el software de la cadena de suministro apenas reconocen la existencia de los tiempos de entrega más allá de presentarlos como un parámetro de entrada para su modelo de inventario. Para esta conferencia, habrá tres objetivos:
Queremos comprender la importancia y la naturaleza de los tiempos de entrega. Queremos comprender cómo se pueden pronosticar los tiempos de entrega, con un interés específico en los modelos probabilísticos que nos permiten abrazar la incertidumbre. Queremos combinar los pronósticos de los tiempos de entrega con los pronósticos de la demanda de formas que sean de interés para la cadena de suministro.
Según la literatura principal de la cadena de suministro, los tiempos de entrega apenas valen un par de notas al pie. Esta afirmación puede parecer una exageración extravagante, pero me temo que no lo es. Según Google Scholar, un motor de búsqueda especializado dedicado a la literatura científica, la consulta “pronóstico de la demanda” para el año 2021 devuelve 10,500 artículos. Una inspección superficial de los resultados indica que efectivamente la gran mayoría de esas entradas están discutiendo el pronóstico de la demanda en todo tipo de situaciones y mercados. La misma consulta, también para el año 2021, en Google Scholar para “pronóstico de tiempos de entrega” devuelve 71 resultados. Los resultados de la consulta de pronóstico de tiempos de entrega son tan limitados que solo se necesitan unos minutos para revisar un año completo de investigación.
Resulta que solo hay alrededor de una docena de entradas que realmente están discutiendo el pronóstico de los tiempos de entrega. De hecho, la mayoría de las coincidencias se encuentran en expresiones como “pronóstico de tiempos de entrega largos” o “pronóstico de tiempos de entrega cortos” que se refieren a un pronóstico de la demanda, y no a un pronóstico de los tiempos de entrega. Es posible repetir este ejercicio con “predicción de la demanda” y “predicción de los tiempos de entrega” y otras expresiones similares y otros años. Esas variaciones arrojan resultados similares. Dejaré eso como un ejercicio para la audiencia.
Por lo tanto, como una estimación aproximada, tenemos alrededor de mil veces más artículos sobre el pronóstico de la demanda que sobre el pronóstico de los tiempos de entrega. Los libros de cadena de suministro y el software de cadena de suministro siguen el mismo camino, dejando los tiempos de entrega como ciudadanos de segunda clase y como una cuestión técnica inconsecuente. Sin embargo, el personal de la cadena de suministro que se ha presentado en esta serie de conferencias cuenta una historia diferente. Este personal puede representar empresas ficticias, pero reflejan arquetipos de la cadena de suministro. Nos hablan sobre el tipo de situación que se debe considerar como típica. Veamos qué nos dicen este personal en cuanto a los tiempos de entrega.
París es una marca de moda ficticia que opera su propia red minorista. París realiza pedidos a proveedores en el extranjero, con tiempos de entrega largos y a veces superiores a seis meses. Estos tiempos de entrega solo se conocen de manera imperfecta, y sin embargo, la nueva colección debe llegar a la tienda en el momento adecuado según lo definido por la operación de marketing asociada con la nueva colección. Los tiempos de entrega de los proveedores requieren una anticipación adecuada; en otras palabras, requieren un pronóstico.
Ámsterdam es una empresa ficticia de productos de consumo masivo que se especializa en la producción de quesos, cremas y mantequilla. El proceso de maduración del queso es conocido y controlado, pero varía, con desviaciones de unos pocos días. Sin embargo, unos pocos días es precisamente la duración de las intensas promociones desencadenadas por las cadenas minoristas que resultan ser el principal canal de ventas de Ámsterdam. Estos tiempos de entrega de fabricación requieren un pronóstico.
Miami es una empresa ficticia de aviación MRO. MRO significa mantenimiento, reparación y revisión. Cada avión comercial necesita miles de piezas al año para seguir volando. La falta de una sola pieza es probable que deje en tierra la aeronave. La duración de la reparación de una pieza reparable, también conocida como TAT (tiempo de respuesta), define cuándo la pieza rotable vuelve a estar en servicio. Sin embargo, el TAT varía desde días hasta meses, dependiendo de la magnitud de las reparaciones, que no se conocen en el momento en que se retira la pieza de la aeronave. Estos TAT requieren un pronóstico.
San José es una empresa ficticia de comercio electrónico que distribuye una variedad de muebles y accesorios para el hogar. Como parte de su servicio, San José proporciona un compromiso de fecha de entrega para cada transacción. Sin embargo, la entrega en sí depende de empresas externas que están lejos de ser perfectamente confiables. Por lo tanto, San José requiere una suposición educada sobre la fecha de entrega que se puede prometer para cada transacción. Esta suposición educada es implícitamente un pronóstico de los tiempos de entrega.
Finalmente, Stuttgart es una empresa ficticia de posventa automotriz. Opera sucursales que realizan reparaciones de automóviles. El precio de compra más bajo para las piezas de automóviles se puede obtener de mayoristas que ofrecen tiempos de entrega largos y algo irregulares. Hay proveedores más confiables que son más caros y están más cerca. Elegir el proveedor adecuado para cada pieza requiere un análisis comparativo adecuado de los tiempos de entrega respectivos asociados con varios proveedores.
Como podemos ver, todo el personal de la cadena de suministro presentado hasta ahora requiere la anticipación de al menos uno, y con frecuencia varios, tiempos de entrega. Si bien se podría argumentar que pronosticar la demanda requiere más atención y esfuerzo que pronosticar los tiempos de entrega, al final, ambos son necesarios para casi todas las situaciones de la cadena de suministro.
Por lo tanto, echemos un vistazo a algunos tiempos de entrega reales del mundo real. En la pantalla hay tres histogramas que se han trazado compilando los tiempos de entrega observados asociados con tres piezas mecánicas. Estas piezas se ordenan al mismo proveedor ubicado en Europa Occidental. Los pedidos provienen de una empresa también ubicada en Europa Occidental. El eje x indica la duración de los tiempos de entrega observados expresados en días, y el eje y indica el número de observaciones expresado como un porcentaje. A continuación, todos los histogramas adoptarán las mismas convenciones, con el eje x asociado a duraciones expresadas en días y el eje y reflejando la frecuencia. A partir de estas tres distribuciones, ya podemos hacer algunas observaciones.
En primer lugar, los datos son escasos. Solo tenemos unos pocos puntos de datos, y estas observaciones se han recopilado a lo largo de varios años. Esta situación es típica; si la empresa realiza pedidos solo una vez al mes, se tarda casi una década en recopilar más de 100 observaciones de los tiempos de entrega. Por lo tanto, cualquier cosa que hagamos en términos de estadísticas debe estar orientada hacia números pequeños en lugar de grandes. De hecho, rara vez tendremos el lujo de lidiar con números grandes.
En segundo lugar, los tiempos de entrega son erráticos. Tenemos observaciones que van desde unos pocos días hasta un trimestre. Siempre es posible calcular un tiempo de entrega promedio, pero confiar en cualquier tipo de valor promedio para cualquiera de esas piezas sería imprudente. También está claro que ninguna de esas distribuciones es remotamente normal.
En tercer lugar, tenemos tres piezas que son algo comparables en tamaño y precio, y sin embargo, los tiempos de entrega varían mucho. Si bien podría ser tentador agrupar esas observaciones para que los datos sean menos escasos, obviamente no sería prudente hacerlo, ya que se estarían mezclando distribuciones que son muy diferentes. Esas distribuciones no tienen la misma media, mediana ni siquiera el mismo mínimo o máximo.
Echemos un vistazo a un segundo conjunto de tiempos de entrega. Estas duraciones reflejan el tiempo que se tarda en reparar tres piezas distintas de aeronaves. La primera distribución parece tener dos modos más una cola. Cuando una distribución presenta dos modos, generalmente sugiere la existencia de una variable oculta que explica esos dos modos. Por ejemplo, puede haber dos tipos distintos de operaciones de reparación, cada tipo asociado con un tiempo de entrega propio. La segunda distribución parece tener un modo más una cola. Este modo coincide con una duración relativamente corta, aproximadamente dos semanas. Podría reflejar un proceso en el que la pieza se inspecciona primero y, a veces, se considera utilizable sin ninguna intervención adicional, de ahí un tiempo de entrega mucho más corto. La tercera distribución parece estar completamente dispersa, sin un modo u cola evidentes. Puede haber varios procesos de reparación en juego aquí que se agrupan juntos. La escasez de datos, con solo tres docenas de observaciones, dificulta decir más. Volveremos a visitar esta tercera distribución más adelante en esta conferencia.
Finalmente, echemos un vistazo a dos tiempos de entrega que reflejan los retrasos en el envío desde Taiwán a la costa oeste de Estados Unidos, ya sea por aire o por mar. No sorprende que los aviones de carga sean más rápidos que los barcos de carga. La segunda distribución parece sugerir que a veces un envío marítimo puede perder su barco original y luego ser enviado con el siguiente barco, casi duplicando el retraso. El mismo fenómeno podría estar ocurriendo con el envío aéreo, aunque los datos son tan limitados que solo es una suposición. Señalemos que tener acceso a solo un par de observaciones no es algo fuera de lo común en lo que respecta a los tiempos de entrega. Estas situaciones son frecuentes. Es importante tener en cuenta que en esta conferencia, buscamos herramientas e instrumentos que nos permitan trabajar con los datos de tiempo de entrega que tenemos, incluso con un puñado de observaciones, no con los datos de tiempo de entrega que deseamos tener, como miles de observaciones. Los cortos intervalos en ambas distribuciones también sugieren un patrón cíclico de día de la semana en funcionamiento, aunque la visualización del histograma actual no es apropiada para validar esta hipótesis.
A partir de esta breve revisión de los tiempos de entrega del mundo real, ya podemos comprender algunos de los fenómenos subyacentes que están en juego. De hecho, los tiempos de entrega están altamente estructurados; los retrasos no ocurren sin causa, y esas causas se pueden identificar, descomponer y cuantificar. Sin embargo, los detalles de la descomposición del tiempo de entrega a menudo no se registran en los sistemas informáticos, al menos aún no. Incluso cuando una descomposición extensa del tiempo de entrega observado está disponible, como podría ser el caso en ciertas industrias como la aviación, no implica que los tiempos de entrega se puedan anticipar perfectamente. Es probable que los subsegmentos o fases dentro del tiempo de entrega exhiban su propia incertidumbre irreducible.
Esta serie de conferencias sobre la cadena de suministro presenta mis puntos de vista y conocimientos tanto sobre el estudio como sobre la práctica de la cadena de suministro. Estoy tratando de mantener estas conferencias algo independientes, pero tienen más sentido cuando se ven en secuencia. El resto de esta conferencia depende de elementos que se han presentado previamente en esta serie, aunque proporcionaré un repaso en un minuto.
El primer capítulo es una introducción general al campo y estudio de la cadena de suministro. Aclara la perspectiva que se tiene en cuenta en esta serie de conferencias. Como probablemente ya hayas deducido, esta perspectiva difiere sustancialmente de lo que se consideraría la perspectiva convencional de la cadena de suministro.
El segundo capítulo presenta una serie de metodologías. De hecho, la cadena de suministro derrota a las metodologías ingenuas. Las cadenas de suministro están compuestas por personas que tienen sus propias agendas; no existe tal cosa como una parte neutral en la cadena de suministro. Este capítulo aborda esas complicaciones, incluido mi propio conflicto de intereses como CEO de Lokad, una empresa de software empresarial especializada en optimización de la cadena de suministro predictiva.
El tercer capítulo presenta una serie de “personajes” de la cadena de suministro. Estos personajes son empresas ficticias que hemos revisado brevemente hoy, y están destinados a representar arquetipos de situaciones de la cadena de suministro. El propósito de estos personajes es centrarse exclusivamente en los problemas, posponiendo la presentación de soluciones.
El cuarto capítulo revisa las ciencias auxiliares de la cadena de suministro. Estas ciencias no se tratan de la cadena de suministro en sí, pero se deben considerar esenciales para una práctica moderna de la cadena de suministro. Este capítulo incluye una progresión a través de las capas de abstracción, desde el hardware informático hasta las preocupaciones de ciberseguridad.
El quinto y presente capítulo está dedicado a la modelización predictiva. La modelización predictiva es una perspectiva más general que la previsión; no se trata solo de predecir la demanda. Se trata del diseño de modelos que se pueden utilizar para estimar y cuantificar los factores futuros de la cadena de suministro de interés. Hoy nos adentramos en los tiempos de entrega, pero en general, en la cadena de suministro, cualquier cosa que no se conozca con un grado razonable de certeza merece una previsión.
El sexto capítulo explica cómo se pueden calcular decisiones optimizadas aprovechando los modelos predictivos, y más específicamente, los modelos probabilísticos que se introdujeron en el quinto capítulo. El séptimo capítulo vuelve a una perspectiva en gran medida no técnica para discutir la ejecución corporativa real de una iniciativa de Supply Chain Quantitativa.
Hoy nos enfocamos en los tiempos de entrega. Acabamos de ver por qué los tiempos de entrega son importantes y acabamos de revisar una breve serie de tiempos de entrega del mundo real. Por lo tanto, procederemos con los elementos de la modelización de los tiempos de entrega. Como adoptaré una perspectiva probabilística, reintroduciré brevemente el Continuous Rank Probability Score (CRPS), una métrica para evaluar la calidad de un pronóstico probabilístico. También introduciré la validación cruzada y una variante de la validación cruzada que es adecuada para nuestra perspectiva probabilística. Con esas herramientas en mano, presentaremos y evaluaremos nuestro primer modelo probabilístico no ingenuo para los tiempos de entrega. Los datos de los tiempos de entrega son escasos y el primer punto en nuestra agenda es suavizar esas distribuciones. Los tiempos de entrega se pueden descomponer en una serie de fases intermedias. Por lo tanto, suponiendo que algunos datos de tiempos de entrega descompuestos estén disponibles, necesitamos algo para recomponer esos tiempos de entrega mientras se preserva el enfoque probabilístico.
Luego, reintroduciremos la programación diferenciable. La programación diferenciable ya se ha utilizado en esta serie de conferencias para pronosticar la demanda, pero también se puede utilizar para pronosticar los tiempos de entrega. Lo haremos, comenzando con un ejemplo sencillo destinado a capturar el impacto del Año Nuevo Chino en los tiempos de entrega, un patrón típico observado al importar mercancías desde Asia.
Luego procederemos con un modelo probabilístico paramétrico para los tiempos de entrega, aprovechando la distribución log-logística. Una vez más, la programación diferenciable será fundamental para aprender los parámetros del modelo. Luego ampliaremos este modelo considerando observaciones incompletas de los tiempos de entrega. De hecho, incluso las órdenes de compra que aún no se han completado nos brindan información sobre el tiempo de entrega.
Por último, combinaremos un pronóstico probabilístico de los tiempos de entrega y un pronóstico probabilístico de la demanda en una única situación de reabastecimiento de inventario. Esta será la oportunidad de demostrar por qué la modularidad es una preocupación esencial cuando se trata de la modelización predictiva, incluso más importante que los detalles de los propios modelos.
En la Conferencia 5.2 sobre pronósticos probabilísticos, ya hemos presentado algunas herramientas para evaluar la calidad de un pronóstico probabilístico. De hecho, las métricas habituales de precisión como el error cuadrático medio o el error absoluto medio solo se aplican a los pronósticos puntuales, no a los pronósticos probabilísticos. Sin embargo, no es porque nuestros pronósticos se vuelvan probabilísticos que la precisión en el sentido general se vuelve irrelevante. Solo necesitamos un instrumento estadístico que resulte compatible con la perspectiva probabilística.
Entre esos instrumentos, se encuentra el Continuous Rank Probability Score (CRPS). La fórmula se muestra en la pantalla. El CRPS es una generalización de la métrica L1, es decir, el error absoluto, pero para distribuciones de probabilidad. El CRPS habitual compara una distribución, llamada F aquí, con una observación, llamada X aquí. El valor obtenido a partir de la función CRPS es homogéneo con la observación. Por ejemplo, si X es un tiempo de entrega expresado en días, entonces el valor de CRPS también se expresa en días.
El CRPS se puede generalizar para la comparación de dos distribuciones. Esto es lo que se está haciendo en la pantalla. Es solo una variación menor de la fórmula anterior. La esencia de esta métrica permanece sin cambios. Si F es la verdadera distribución de tiempos de entrega y F_hat es una estimación de la distribución de tiempos de entrega, entonces el CRPS se expresa en días. El CRPS refleja la cantidad de diferencia entre las dos distribuciones. El CRPS también se puede interpretar como la cantidad mínima de energía necesaria para transportar toda la masa de la primera distribución de manera que tome la forma exacta de la segunda distribución.
Ahora tenemos un instrumento para comparar dos distribuciones de probabilidad unidimensionales. Esto será de interés en un minuto, cuando presentemos nuestro primer modelo probabilístico para los tiempos de entrega.
Tener una métrica para medir la calidad de un pronóstico probabilístico no es suficiente. La métrica mide la calidad en los datos que tenemos; sin embargo, lo que realmente queremos es poder evaluar la calidad de nuestro pronóstico en datos que no tenemos. De hecho, los tiempos de entrega futuros son los que nos interesan, no los tiempos de entrega que ya se han observado en el pasado. Nuestra capacidad para modelar para que un modelo funcione bien en los datos que no tenemos se llama generalización. La validación cruzada es una técnica general de validación de modelos destinada precisamente a evaluar la capacidad de un modelo para generalizar bien.
En su forma más simple, la validación cruzada consiste en dividir las observaciones en un pequeño número de subconjuntos. En cada iteración, se aparta un subconjunto y se denomina subconjunto de prueba. El modelo se genera o entrena en función de los otros subconjuntos de datos, que se denominan subconjuntos de entrenamiento. Después del entrenamiento, el modelo se valida con respecto al subconjunto de prueba. Este proceso se repite un cierto número de veces, y la bondad promedio obtenida en todas las iteraciones representa el resultado final de la validación cruzada.
La validación cruzada rara vez se utiliza en el contexto de los pronósticos de series de tiempo debido a la dependencia temporal entre las observaciones. De hecho, la validación cruzada, tal como se acaba de presentar, asume que las observaciones son independientes. Cuando se trata de series de tiempo, en su lugar se utiliza el análisis retrospectivo. El análisis retrospectivo se puede ver como una forma de validación cruzada que tiene en cuenta la dependencia temporal.
La técnica de validación cruzada tiene numerosas variantes que reflejan una amplia gama de ángulos potenciales que pueden necesitar ser abordados. No vamos a examinar esas variantes con el propósito de esta conferencia. Voy a utilizar una variante específica en la que, en cada división, el subconjunto de entrenamiento y el subconjunto de prueba tienen aproximadamente el mismo tamaño. Esta variante se introduce para lidiar con la validación de un modelo probabilístico, como veremos con un poco de código en un minuto.
Vamos a revisar uno de los tiempos de espera del mundo real que hemos visto anteriormente en la pantalla. A la izquierda, el histograma está asociado con las terceras distribuciones de tiempo de reparación de la aviación. Esas son las mismas observaciones que vimos anteriormente, y el histograma simplemente se ha estirado verticalmente. Al hacerlo, los dos histogramas a la izquierda y a la derecha comparten la misma escala. Para el histograma de la izquierda, tenemos alrededor de 30 observaciones. No es mucho, pero ya es más de lo que obtendremos con frecuencia.
El histograma de la izquierda se denomina distribución empírica. Es literalmente el histograma sin procesar obtenido a partir de las observaciones. El histograma tiene un cubo para cada duración expresada en un número entero de días. Para cada cubo, contamos el número de tiempos de espera observados. Debido a la dispersión, la distribución empírica parece un código de barras.
Aquí hay un problema. Si tenemos dos tiempos de espera observados exactamente de 50 días, ¿tiene sentido decir que la probabilidad de observar 49 días o 51 días es exactamente cero? No lo tiene. Claramente, hay un espectro de duraciones en marcha; simplemente no tenemos suficientes puntos de datos para observar la verdadera distribución subyacente, que probablemente sea mucho más suave que esta distribución tipo código de barras.
Por lo tanto, cuando se trata de suavizar esta distribución, hay un número indefinido de formas de realizar esta operación de suavizado. Algunos métodos de suavizado pueden parecer buenos pero no son estadísticamente sólidos. Como punto de partida, nos gustaría asegurarnos de que un modelo suave sea más preciso que el empírico. Resulta que ya hemos introducido dos instrumentos, el CRPS y la validación cruzada, que nos permitirán hacer eso.
En un minuto, los resultados están a la vista. El error CRPS asociado a la distribución tipo código de barras es de 1.6 días, mientras que el error CRPS asociado a la distribución suave es de 1.4 días. Estas dos cifras se han obtenido mediante validación cruzada. El error más bajo indica que, en el sentido del CRPS, la distribución de la derecha es la más precisa de las dos. La diferencia de 0.2 entre 1.4 y 1.6 no es mucha; sin embargo, la propiedad clave aquí es que tenemos una distribución suave que no deja erráticamente ciertas duraciones intermedias con una probabilidad cero. Esto es razonable, ya que nuestra comprensión de las reparaciones nos dice que esas duraciones probablemente terminarían ocurriendo si se repiten las reparaciones. El CRPS no refleja la verdadera profundidad de la mejora que acabamos de lograr al suavizar la distribución. Sin embargo, como mínimo, reducir el CRPS confirma que esta transformación es razonable desde una perspectiva estadística.
Ahora veamos el código fuente que ha producido esos dos modelos y ha mostrado esos dos histogramas. En total, esto se logra en 12 líneas de código si excluimos las líneas en blanco. Como es habitual en esta serie de conferencias, el código está escrito en Envision, el lenguaje de programación específico del dominio de Lokad dedicado a la optimización predictiva de las cadenas de suministro. Sin embargo, no hay magia; esta lógica podría haber sido escrita en Python. Pero para el tipo de problemas que estamos considerando en esta conferencia, Envision es más conciso y más autónomo.
Veamos esas 12 líneas de código. En las líneas 1 y 2, estamos leyendo una hoja de cálculo de Excel que tiene una sola columna de datos. La hoja de cálculo contiene 30 observaciones. Estos datos se recopilan en una tabla llamada “H” que tiene una sola columna llamada “days”. En la línea 4, estamos construyendo una distribución empírica. La variable “R” tiene el tipo de datos “ranvar”, y en el lado derecho de la asignación, la función “ranvar” es un agregador que toma las observaciones como entrada y devuelve el histograma representado con un tipo de datos “ranvar”. Como resultado, el tipo de datos “ranvar” está dedicado a distribuciones enteras unidimensionales. Introdujimos el tipo de datos “ranvar” en una conferencia anterior de este capítulo. Este tipo de datos garantiza una huella de memoria constante y un tiempo de cálculo constante para cada operación. La desventaja del “ranvar” como tipo de datos es que implica una compresión con pérdida, aunque la pérdida de datos causada por la compresión se ha diseñado para ser inconsecuente para los fines de la cadena de suministro.
En la línea 5, estamos suavizando la distribución con la función incorporada llamada “smooth”. Bajo el capó, esta función reemplaza la distribución original con una mezcla de distribuciones de Poisson. Cada cubeta del histograma se transforma en una distribución de Poisson con una media igual a la posición entera de la cubeta, y finalmente, la mezcla asigna un peso a cada distribución de Poisson proporcional al peso de la cubeta en sí. Otra forma de entender lo que hace esta función “smooth” es considerar que es equivalente a reemplazar cada observación individual por una distribución de Poisson con una media igual a la observación misma. Todas esas distribuciones de Poisson, una por observación, se mezclan. Mezclar significa promediar los valores respectivos de los cubos del histograma. Las variables “ranvar” “R” y “S” no se utilizarán nuevamente antes de las líneas 14 y 15, donde se muestran.
En la línea 7, comenzamos un bloque de Monte Carlo. Este bloque es una especie de bucle, y se ejecutará 100 veces, como se especifica por los 100 valores que aparecen justo después de la palabra clave Monte Carlo. El bloque de Monte Carlo está destinado a recopilar observaciones independientes que se generan de acuerdo con un proceso que involucra un grado de aleatoriedad. Es posible que se pregunte por qué hay un constructo de Monte Carlo específico en Envision en lugar de simplemente tener un bucle, como suele ser el caso con los lenguajes de programación convencionales. Resulta que tener un constructo dedicado ofrece beneficios sustanciales. En primer lugar, garantiza que las iteraciones sean verdaderamente independientes, hasta las semillas utilizadas para derivar la pseudoaleatoriedad. En segundo lugar, ofrece un objetivo explícito para la distribución automatizada de la carga de trabajo en varios núcleos de CPU o incluso en varias máquinas.
En la línea 8, creamos un vector aleatorio de valores booleanos dentro de la tabla “H”. Con esta línea, estamos creando valores aleatorios independientes, llamados desviaciones (verdadero o falso), para cada línea de la tabla “H”. Como es habitual en Envision, los bucles se abstraen a través de la programación de matrices. Con esos valores booleanos, estamos dividiendo la tabla “H” en dos grupos. Esta división aleatoria se utiliza para el proceso de validación cruzada.
En las líneas 9 y 10, creamos dos “ranvars” llamados “A” y “B”, respectivamente. Volvemos a utilizar el agregador “ranvar”, pero esta vez aplicamos un filtro con la palabra clave “when” justo después de la llamada al agregador. “A” se genera utilizando solo las líneas donde el valor en “a” es verdadero; para “B”, es lo contrario. “B” se genera utilizando solo las líneas donde el valor en “a” es falso.
En las líneas 11 y 12, recopilamos las cifras de interés del bloque de Monte Carlo. En Envision, la palabra clave “sample” solo se puede colocar dentro de un bloque de Monte Carlo. Se utiliza para recopilar las observaciones que se realizan al iterar muchas veces a través del proceso de Monte Carlo. En la línea 11, estamos calculando el error promedio, expresado en términos de CRPS, entre dos distribuciones empíricas: una submuestra del conjunto original de tiempos de espera. La palabra clave “sample” especifica que los valores se recopilan a lo largo de las iteraciones de Monte Carlo. El agregador “AVG”, que significa “promedio” en el lado derecho de la asignación, se utiliza para producir una única estimación al final del bloque.
En la línea 12, hacemos algo casi idéntico a lo que sucedió en la línea 11. Esta vez, sin embargo, aplicamos la función “smooth” al “ranvar” “B”. Queremos evaluar qué tan cerca está la variante suave de la distribución empírica ingenua. Resulta que está más cerca, al menos en términos de CRPS, que sus contrapartes empíricas originales.
En las líneas 14 y 15, mostramos los histogramas y los valores de CRPS. Esas líneas generan las figuras que hemos visto en la diapositiva anterior. Este script nos da nuestra línea de base para la calidad de la distribución empírica de nuestro modelo. De hecho, aunque este modelo, el “barcode”, es ingenuo, sigue siendo un modelo, y uno probabilístico. Por lo tanto, este script también nos da un mejor modelo, al menos en el sentido del CRPS, a través de una variante suave de la distribución empírica original.
En este momento, dependiendo de su familiaridad con los lenguajes de programación, puede parecer mucho para asimilar. Sin embargo, me gustaría señalar lo sencillo que es producir una distribución de probabilidad razonable, incluso cuando no tenemos más que unas pocas observaciones. Aunque tenemos 12 líneas de código, solo las líneas 4 y 5 representan la verdadera parte de modelado del ejercicio. Si solo estuviéramos interesados en la variante suave, entonces el “ranvar” “S” se podría escribir con una sola línea de código. Por lo tanto, es literalmente una línea de código: primero, aplicamos una agregación de ranvar, y segundo, aplicamos un operador suave, y listo. El resto es solo instrumentación y visualización. Con las herramientas adecuadas, el modelado probabilístico, ya sea de tiempo de espera u otra cosa, puede ser extremadamente sencillo. No hay grandes matemáticas involucradas, no hay grandes algoritmos, no hay grandes piezas de software. Es simple y notablemente así.
¿Cómo se obtiene un envío seis meses tarde? La respuesta es obvia: un día a la vez. Más en serio, los tiempos de espera generalmente se pueden descomponer en una serie de retrasos. Por ejemplo, un tiempo de espera del proveedor se puede descomponer en un retraso de espera mientras el pedido se coloca en una cola de espera, seguido de un retraso de fabricación mientras se producen los bienes, y finalmente seguido de un retraso de tránsito mientras se envían los bienes. Por lo tanto, si los tiempos de espera se pueden descomponer, también es interesante poder recomponerlos.
Si viviéramos en un mundo altamente determinista donde el futuro pudiera ser anticipado con precisión, recomponer los tiempos de espera sería solo una cuestión de suma. Volviendo al ejemplo que acabo de mencionar, componer el tiempo de espera del pedido sería la suma del retraso en la cola en días, el retraso de fabricación en días y el retraso de tránsito en días. Sin embargo, no vivimos en un mundo donde el futuro pueda ser anticipado con precisión. Las distribuciones de tiempos de espera del mundo real que presentamos al comienzo de esta conferencia respaldan esta proposición. Los tiempos de espera son erráticos y hay pocas razones para creer que esto cambiará fundamentalmente en las próximas décadas.
Por lo tanto, los tiempos de espera futuros deben abordarse como variables aleatorias. Estas variables aleatorias abarcan y cuantifican la incertidumbre en lugar de descartarla. Más específicamente, esto significa que cada componente del tiempo de espera también debe modelarse individualmente como una variable aleatoria. Volviendo a nuestro ejemplo, el tiempo de espera del pedido es una variable aleatoria y se obtiene como la suma de tres variables aleatorias asociadas respectivamente con el retraso en la cola, el retraso de fabricación y el retraso de tránsito.
La fórmula para la suma de dos variables aleatorias independientes, unidimensionales y de valores enteros se presenta en la pantalla. Esta fórmula simplemente establece que si obtenemos una duración total de Z días y si tenemos K días para la primera variable aleatoria X, entonces debemos tener Z menos K días para la segunda variable aleatoria Y. Este tipo de suma se conoce, en términos generales, en matemáticas como convoluciones.
Aunque parece que hay un número infinito de términos en esta convolución, en la práctica solo nos preocupamos por un número finito de términos. En primer lugar, todas las duraciones negativas tienen una probabilidad cero; de hecho, los retrasos negativos significarían viajar hacia atrás en el tiempo. En segundo lugar, para retrasos grandes, las probabilidades se vuelven tan pequeñas que, para fines prácticos de la cadena de suministro, se pueden aproximar de manera confiable como ceros.
Pongamos en práctica estas convoluciones. Consideremos un tiempo de tránsito que se puede descomponer en dos fases: un retraso de envío seguido de un retraso de despacho en aduanas. Queremos modelar estas dos fases con dos variables aleatorias independientes y luego recomponer el tiempo de tránsito sumando esas dos variables aleatorias.
En la pantalla, los histogramas a la izquierda son producidos por el script a la derecha. En la línea 1, el retraso de envío se modela como una convolución de una distribución de Poisson más una constante. La función de Poisson devuelve un tipo de datos “ranvar”; agregar tres tiene el efecto de desplazar la distribución hacia la derecha. El “ranvar” resultante se asigna a la variable “C”. Este “ranvar” se muestra en la línea 3. Se puede ver a la izquierda como el histograma superior. Reconocemos la forma de una distribución de Poisson que se ha desplazado hacia la derecha por algunas unidades, tres unidades en este caso. En la línea dos, el despacho de aduanas se modela como una mezcla de una función de Dirac en cero y una distribución de Poisson en cinco. La función de Dirac en cero ocurre el ochenta por ciento del tiempo; eso es lo que significa esta constante 0.8. Refleja situaciones en las que la mayor parte del tiempo, las mercancías ni siquiera son inspeccionadas por la aduana y pasan sin ningún retraso notable. Alternativamente, el veinte por ciento del tiempo, las mercancías son inspeccionadas en aduanas y el retraso se modela como una distribución de Poisson con una media de cinco. El “ranvar” resultante se asigna a una variable llamada D. Este “ranvar” se muestra en la línea cuatro y se puede ver a la izquierda como el histograma del medio. Este aspecto asimétrico refleja que la mayor parte del tiempo, la aduana no agrega ningún retraso.
Finalmente, en la línea cinco, calculamos C más D. Esta adición es una convolución, ya que tanto C como D son ranvars, no números. Esta es la segunda convolución en este script, ya que una convolución ya tuvo lugar en la línea uno. El “ranvar” resultante se muestra y es visible a la izquierda como el tercer y más bajo histograma. Este tercer histograma es similar al primero, excepto que la cola se extiende mucho más hacia la derecha. Una vez más, vemos que con unas pocas líneas de código, podemos abordar efectos del mundo real no triviales, como los retrasos de despacho en aduanas.
Sin embargo, se podrían hacer dos críticas sobre este ejemplo. En primer lugar, no dice de dónde provienen las constantes; en la práctica, queremos aprender esas constantes a partir de datos históricos. En segundo lugar, si bien la distribución de Poisson tiene la ventaja de la simplicidad, puede que no sea una forma muy realista para modelar el tiempo de espera, especialmente en situaciones de colas pesadas. Por lo tanto, vamos a abordar esos dos puntos en orden.
Para aprender parámetros a partir de datos, vamos a revisar un paradigma de programación que ya hemos introducido en esta serie de conferencias, a saber, la programación diferenciable. Si no has visto las conferencias anteriores de este capítulo, te invito a echarles un vistazo después de terminar la presente conferencia. La programación diferenciable se presenta con más detalle en esas conferencias.
La programación diferenciable es una combinación de dos técnicas: descenso de gradiente estocástico y diferenciación automática. El descenso de gradiente estocástico es una técnica de optimización que empuja los parámetros una observación a la vez en la dirección opuesta de los gradientes. La diferenciación automática es una técnica de compilación, como en el compilador de un lenguaje de programación; calcula los gradientes para todos los parámetros que aparecen dentro de un programa general.
Ilustremos la programación diferenciable con un problema de tiempo de espera. Esto servirá como un repaso o una introducción, dependiendo de tu familiaridad con este paradigma. Queremos modelar el impacto del Año Nuevo Chino en los tiempos de espera asociados con las importaciones de China. De hecho, a medida que las fábricas cierran durante dos o tres semanas por el Año Nuevo Chino, los tiempos de espera se alargan. El Año Nuevo Chino es cíclico; ocurre todos los años. Sin embargo, no es estrictamente estacional, al menos no en el sentido del calendario gregoriano.
En las líneas uno a seis, estamos introduciendo algunas órdenes de compra simuladas con cuatro observaciones, tanto una fecha de pedido como una fecha de recepción. En la práctica, estos datos no estarían codificados en duro, sino que cargaríamos estos datos históricos de los sistemas de la empresa. En las líneas ocho y nueve, calculamos si el tiempo de espera se superpone con el Año Nuevo Chino. La variable “T.overlap_CNY” es un vector booleano; indica si la observación se ve afectada por el Año Nuevo Chino o no.
En la línea 12, introducimos un bloque “autodiff”. La tabla T se utiliza como tabla de observación y hay 1000 épocas. Esto significa que cada observación, es decir, cada línea en la tabla T, se visitará mil veces. Un paso del descenso de gradiente estocástico corresponde a una ejecución de la lógica dentro del bloque “autodiff”.
En las líneas 13 y 14, se declaran dos parámetros escalares. El bloque “autodiff” aprenderá estos parámetros. El parámetro A refleja el tiempo de espera base sin el efecto del Año Nuevo Chino, y el parámetro B refleja el retraso adicional asociado con el Año Nuevo Chino. En la línea 15, calculamos X, la predicción del tiempo de espera de nuestro modelo. Este es un modelo determinista, no probabilístico; X es una predicción puntual del tiempo de espera. El lado derecho de la asignación es sencillo: si la observación se superpone con el Año Nuevo Chino, entonces devolvemos la base más el componente del Año Nuevo; de lo contrario, solo devolvemos la base. Como el bloque “autodiff” toma solo una observación a la vez, en la línea 15, la variable T.overlap_CNY se refiere a un valor escalar y no a un vector. Este valor coincide con la línea elegida como la línea de observación dentro de la tabla T.
Los parámetros A y B están envueltos en la función exponencial “exp”, que es un pequeño truco de programación diferenciable. De hecho, el algoritmo que controla el descenso de gradiente estocástico tiende a ser relativamente conservador cuando se trata de las variaciones incrementales de los parámetros. Por lo tanto, si queremos aprender un parámetro positivo que pueda crecer más de, digamos, 10, envolver este parámetro en un proceso exponencial acelera la convergencia.
En la línea 16, devolvemos un error cuadrático medio entre nuestra predicción X y la duración observada, expresada en días (T.days). Nuevamente, dentro de este bloque “autodiff”, T.days es un valor escalar y no un vector. Como la tabla T se utiliza como tabla de observación, el valor de retorno se trata como la pérdida que se minimiza a través del descenso de gradiente estocástico. La diferenciación automática propaga los gradientes desde la pérdida hacia atrás hasta los parámetros A y B. Finalmente, en la línea 19, mostramos los dos valores que hemos aprendido, respectivamente, para A y B, que son la línea base y el componente de Año Nuevo de nuestro tiempo de entrega.
Esto concluye nuestra reintroducción de la programación diferenciable como una herramienta versátil que aprende patrones estadísticos. A partir de aquí, volveremos a visitar los bloques “autodiff” con situaciones más elaboradas. Sin embargo, señalemos una vez más que aunque pueda parecer un poco abrumador, no hay nada realmente complicado sucediendo aquí. Se podría argumentar que la pieza de código más complicada en este script es la implementación subyacente de la función “ChineseYearStart”, llamada en la línea ocho, que resulta ser parte de la biblioteca estándar de Envision. En unas pocas líneas de código, introducimos un modelo con dos parámetros y aprendemos esos parámetros. Una vez más, esta simplicidad es notable.
Los tiempos de entrega suelen tener colas pesadas; es decir, cuando un tiempo de entrega se desvía, se desvía mucho. Por lo tanto, para modelar el tiempo de entrega, es interesante adoptar distribuciones que puedan reproducir esos comportamientos de cola pesada. La literatura matemática presenta una extensa lista de tales distribuciones, y varias de ellas se adaptarían a nuestro propósito. Sin embargo, simplemente explorar el panorama matemático nos llevaría horas. Solo señalemos que la distribución de Poisson no tiene una cola pesada. Por lo tanto, hoy elegiré la distribución log-logística, que resulta ser una distribución de cola pesada. La justificación principal de esta elección de distribución es que los equipos de Lokad están modelando los tiempos de entrega a través de distribuciones log-logísticas para varios clientes. Resulta estar funcionando bien con un número mínimo de complicaciones. Sin embargo, tengamos en cuenta que la distribución log-logística de ninguna manera es una solución milagrosa, y hay numerosas situaciones en las que Lokad modela los tiempos de entrega de manera diferente.
En la pantalla, tenemos la función de densidad de probabilidad de la distribución log-logística. Esta es una distribución paramétrica que depende de dos parámetros, alfa y beta. El parámetro alfa es la mediana de la distribución, y el parámetro beta gobierna la forma de la distribución. A la derecha, se pueden obtener una serie corta de formas a través de varios valores de beta. Si bien esta fórmula de densidad puede parecer intimidante, es literalmente material de libro de texto, al igual que la fórmula para calcular el volumen de una esfera. Puede intentar descifrar y memorizar esta fórmula, pero ni siquiera es necesario; solo necesita saber que existe una fórmula analítica. Una vez que sabe que la fórmula existe, encontrarla en línea lleva menos de un minuto.
Nuestro objetivo es aprovechar la distribución log-logística para aprender un modelo de tiempo de entrega probabilístico. Para hacer esto, vamos a minimizar la log-verosimilitud. De hecho, en la conferencia anterior dentro de este quinto capítulo, hemos visto que hay varias métricas que son apropiadas desde la perspectiva probabilística. Hace un momento, revisamos el CRPS (Continuous Ranked Probability Score). Aquí, revisamos la log-verosimilitud, que adopta una perspectiva bayesiana.
En pocas palabras, dada dos parámetros, la distribución log-logística nos dice la probabilidad de observar cada observación tal como se encuentra en el conjunto de datos empíricos. Queremos aprender los parámetros que maximizan esta verosimilitud. El logaritmo, por lo tanto la log-verosimilitud en lugar de la verosimilitud simple, se introduce para evitar desbordamientos numéricos. Los desbordamientos numéricos ocurren cuando procesamos números muy pequeños, muy cercanos a cero; esos números muy pequeños no se llevan bien con la representación de punto flotante que se encuentra comúnmente en el hardware informático moderno.
Por lo tanto, para calcular la log-verosimilitud de la distribución log-logística, aplicamos el logaritmo a su función de densidad de probabilidad. La expresión analítica se muestra en la pantalla. Esta expresión se puede implementar, y esto es exactamente lo que se hace en las tres líneas de código a continuación.
En la línea uno, se introduce la función “L4”. L4 significa “log-verosimilitud de log-logística” - sí, eso es muchas L y muchos logaritmos. Esta función toma tres argumentos: los dos parámetros alfa y beta, más la observación x. Esta función devuelve el logaritmo de la verosimilitud. La función L4 está decorada con la palabra clave “autodiff”; la palabra clave indica que esta función está destinada a ser diferenciada mediante diferenciación automática. En otras palabras, los gradientes pueden fluir hacia atrás desde el valor de retorno de esta función hasta sus argumentos, los parámetros alfa y beta. Técnicamente, el gradiente también fluye hacia atrás a través de la observación x; sin embargo, como mantendremos las observaciones inmutables durante el proceso de aprendizaje, los gradientes no tendrán ningún efecto en las observaciones. En la línea tres, obtenemos la transcripción literal de la fórmula matemática justo encima del script.
Ahora pongamos todo junto con un script que aprende los parámetros de un modelo de tiempo de entrega probabilístico basado en la distribución log-logística. En las líneas uno y tres, generamos nuestro conjunto de datos de entrenamiento simulado. En entornos del mundo real, estaríamos utilizando datos históricos en lugar de generar datos simulados. En la línea uno, creamos un “ranvar” que representa la distribución original. Por el bien del ejercicio, queremos aprender de vuelta esos parámetros, alfa y beta. La función log-logística es parte de la biblioteca estándar de Envision y devuelve un “ranvar”. En la línea dos, creamos la tabla “H”, que contiene 1,000 entradas. En la línea tres, dibujamos 1,000 desviaciones que se muestrean aleatoriamente de la distribución original “R”. Este vector “H.days” representa el conjunto de datos de entrenamiento.
En la línea seis, tenemos un bloque “autodiff”; aquí es donde tiene lugar el aprendizaje. En las líneas siete y ocho, declaramos dos parámetros, alfa y beta, y para evitar problemas numéricos como la división por cero, se aplican límites a esos parámetros. Alfa debe permanecer mayor que 0.01 y beta debe permanecer mayor que 1.0. En la línea nueve, devolvemos la pérdida, que es el opuesto de la log-verosimilitud. De hecho, por convención, los bloques “autodiff” minimizan la función de pérdida, y por lo tanto queremos maximizar la verosimilitud, de ahí el signo menos. La función “log_likelihood.logistic” es parte de la biblioteca estándar de Envision, pero en el fondo, es solo la función “L4” que hemos implementado en la diapositiva anterior. Por lo tanto, no hay magia en juego aquí; todo es diferenciación automática que hace que el gradiente fluya hacia atrás desde la pérdida hasta los parámetros alfa y beta.
En las líneas 11 y 12, se trazan la distribución original y la distribución aprendida. Los histogramas están limitados a 200; esta limitación hace que el histograma sea un poco más legible. Volveremos a eso en un minuto. En caso de que te preguntes sobre el rendimiento de la parte “autodiff” de este script, tarda menos de 80 milisegundos en ejecutarse en un solo núcleo de CPU. La programación diferenciable no solo es versátil, sino que también hace un buen uso de los recursos informáticos proporcionados por el hardware informático moderno.
En la pantalla, tenemos los dos histogramas producidos por nuestro script que acabamos de revisar. En la parte superior, la distribución original con sus dos parámetros originales, alfa y beta, en 80 y 4, respectivamente. En la parte inferior, la distribución aprendida con dos parámetros aprendidos a través de la programación diferenciable. Esos dos picos en la parte derecha están asociados con las colas que hemos truncado, ya que esas colas se extienden bastante lejos. Por cierto, aunque es raro, sucede que ciertos bienes se reciben más de un año después de haber sido ordenados. Esto no es el caso para todos los sectores, ciertamente no para los lácteos, pero para las piezas mecánicas o la electrónica, ocasionalmente sucede.
Si bien el proceso de aprendizaje no es exacto, obtenemos resultados dentro de un uno por ciento de los valores de los parámetros originales. Esto demuestra, al menos, que esta maximización de la log-verosimilitud a través de la programación diferenciable funciona en la práctica. La distribución log-logística puede ser apropiada o no; depende de la forma de la distribución del tiempo de espera con el que te enfrentas. Sin embargo, prácticamente podemos elegir cualquier distribución paramétrica alternativa. Todo lo que se necesita es una expresión analítica de la función de densidad de probabilidad. Existe una amplia variedad de tales distribuciones. Una vez que tienes una fórmula de libro de texto, una implementación sencilla a través de la programación diferenciable suele hacer el resto.
Los tiempos de espera no se observan solo una vez que la transacción es final. Mientras la transacción aún está en curso, ya sabes algo; ya tienes una observación de tiempo de espera incompleta. Consideremos que hace 100 días realizaste un pedido. Aún no has recibido los bienes; sin embargo, ya sabes que el tiempo de espera es de al menos 100 días. Esta duración de 100 días representa el límite inferior para un tiempo de espera que aún no se ha observado por completo. Esos tiempos de espera incompletos a menudo son bastante importantes. Como mencioné al principio de esta conferencia, los conjuntos de datos de tiempo de espera a menudo son dispersos. No es raro tener un conjunto de datos que solo incluya media docena de observaciones. En esas situaciones, es importante aprovechar al máximo cada observación, incluidas las que aún están en curso.
Consideremos el siguiente ejemplo: tenemos un total de cinco pedidos. Tres pedidos ya se han entregado con valores de tiempo de espera muy cercanos a 30 días. Sin embargo, los dos últimos pedidos han estado pendientes durante 40 días y 50 días, respectivamente. Según las tres primeras observaciones, el tiempo de espera promedio debería ser de alrededor de 30 días. Sin embargo, los dos últimos pedidos que aún están incompletos desmienten esta hipótesis. Los dos pedidos pendientes de 40 y 50 días sugieren un tiempo de espera sustancialmente más largo. Por lo tanto, no debemos descartar los últimos pedidos solo porque están incompletos. Debemos aprovechar esta información y actualizar nuestra creencia hacia tiempos de espera más largos, tal vez 60 días.
Revisemos nuestro modelo probabilístico de tiempo de espera, pero esta vez, teniendo en cuenta las observaciones incompletas. En otras palabras, queremos lidiar con observaciones que a veces son solo un límite inferior para el tiempo de espera final. Para hacer eso, podemos usar la función de distribución acumulativa (CDF) de la distribución log-logística. Esta fórmula está escrita en la pantalla; nuevamente, esto es material de texto. La CDF de la distribución log-logística se beneficia de una expresión analítica simple. A continuación, me referiré a esta técnica como la “técnica de probabilidad condicional” para tratar con datos censurados.
Basándonos en esta expresión analítica de la CDF, podemos revisar la verosimilitud del modelo de distribución log-logística. El script en la pantalla proporciona una implementación revisada de nuestra implementación anterior en L4. En la línea uno, tenemos prácticamente la misma declaración de función. Esta función toma un cuarto argumento adicional, un valor booleano llamado “is_incomplete” que indica, como sugiere el nombre, si la observación está incompleta o no. En las líneas dos y tres, si la observación está completa, entonces volvemos a la situación anterior con la distribución log-logística regular. Por lo tanto, llamamos a la función de verosimilitud que forma parte de la biblioteca estándar. Podría haber repetido el código de la implementación anterior en L4, pero esta versión es más concisa. En las líneas cuatro y cinco, expresamos la verosimilitud de observar finalmente un tiempo de espera mayor que la observación incompleta actual, “X”. Esto se logra a través de la CDF y, más precisamente, el logaritmo de la CDF.
Ahora podemos repetir nuestra configuración con un script que aprende los parámetros de la distribución log-logística, pero esta vez en presencia de tiempos de espera incompletos. El script en la pantalla es casi idéntico al anterior. En las líneas uno a tres, generamos los datos; estas líneas no han cambiado. Señalemos que H.N es un vector generado automáticamente que se crea implícitamente en la línea dos. Este vector numera las líneas generadas, comenzando en uno. La versión anterior de este script no estaba utilizando este vector generado automáticamente, pero actualmente, el vector H.N aparece al final de la línea seis.
Las líneas cinco y seis son realmente las importantes. Aquí, censuramos los tiempos de espera. Es como si hiciéramos una observación de tiempo de espera por día y truncáramos las observaciones que son demasiado recientes para estar informadas. Esto significa, por ejemplo, que un tiempo de espera de 20 días iniciado hace siete días aparece como un tiempo de espera incompleto de siete días. Al final de la línea seis, hemos generado una lista de tiempos de espera donde algunas de las observaciones recientes (aquellas que terminarían más allá de la fecha actual) están incompletas. El resto del script no ha cambiado, excepto en la línea 12, donde se pasa el vector H.is_complete como cuarto argumento de la función de verosimilitud. Por lo tanto, estamos llamando, en la línea 12, a la función de programación diferenciable que acabamos de introducir hace un minuto.
Finalmente, en la pantalla, los dos histogramas son producidos por este script revisado. Los parámetros todavía se aprenden con alta precisión, mientras que ahora estamos en presencia de numerosos tiempos de espera incompletos. Para validar que tratar con tiempos incompletos no fue una complicación innecesaria, he vuelto a ejecutar el script, pero esta vez con una variación modificada con la sobrecarga de tres argumentos de la función de verosimilitud (la que usamos inicialmente y asumimos que todas las observaciones son completas). Para alpha y beta, obtenemos los valores que se muestran en la parte inferior de la pantalla. Como era de esperar, esos valores no coinciden en absoluto con los valores originales de alpha y beta.
En esta serie de conferencias, no es la primera vez que se introduce una técnica para tratar con datos censurados. En la segunda conferencia de este capítulo, se introdujo la técnica de enmascaramiento de pérdidas para tratar con faltantes de stock. De hecho, normalmente queremos predecir la demanda futura, no las ventas futuras. Los faltantes de stock introducen un sesgo a la baja, ya que no llegamos a observar todas las ventas que habrían ocurrido si no hubiera ocurrido el faltante de stock. La técnica de probabilidad condicional se puede utilizar para tratar con la demanda censurada, al igual que ocurre con los faltantes de stock. La técnica de probabilidad condicional es un poco más compleja que el enmascaramiento de pérdidas, por lo que probablemente no se deba utilizar si el enmascaramiento de pérdidas es suficiente.
En el caso de los tiempos de espera, la escasez de datos es la motivación principal. Podemos tener tan pocos datos que puede ser crítico aprovechar al máximo cada observación, incluso las incompletas. De hecho, la técnica de probabilidad condicional es más poderosa que el enmascaramiento de pérdidas en el sentido de que aprovecha las observaciones incompletas en lugar de simplemente descartarlas. Por ejemplo, si hay una unidad en stock y si esta unidad en stock se vende, entonces, insinuando un faltante de stock, la técnica de probabilidad condicional aún utiliza la información de que la demanda fue mayor o igual a uno.
Aquí, obtenemos un beneficio sorprendente del modelado probabilístico: nos brinda una forma elegante de lidiar con la censura, un efecto que ocurre en numerosas situaciones de la cadena de suministro. A través de la probabilidad condicional, podemos eliminar clases enteras de sesgos sistemáticos.
Los pronósticos de tiempos de espera suelen estar destinados a combinarse con los pronósticos de demanda. De hecho, consideremos ahora una situación simple de reposición de inventario, como se ilustra en la pantalla.
Servimos un solo producto y el stock se puede reponer volviendo a pedir a un solo proveedor. Estamos buscando un pronóstico que respalde nuestra decisión de volver a pedir o no al proveedor. Podemos volver a pedir ahora, y si lo hacemos, los productos llegarán en el momento indicado como “primer llegada”. Más tarde, tendremos otra oportunidad para volver a pedir. Esta oportunidad posterior ocurre en un momento indicado como “próximo pedido” y, en este caso, los productos llegarán en el momento indicado como “segunda llegada”. El período indicado como “ventana de responsabilidad” es el período que importa en lo que respecta a nuestra decisión de volver a pedir.
De hecho, cualquier cosa que decidamos volver a pedir no llegará antes del primer tiempo de espera. Por lo tanto, ya hemos perdido el control sobre el servicio de la demanda para cualquier cosa que ocurra antes de la primera llegada. Luego, como tendremos otra oportunidad para volver a pedir, el servicio de la demanda después de la segunda llegada ya no es nuestra responsabilidad; es responsabilidad del próximo pedido. Por lo tanto, volver a pedir con la intención de atender la demanda más allá de la segunda llegada debe posponerse hasta la próxima oportunidad de pedido.
Para respaldar la decisión de volver a pedir, hay dos factores que deben pronosticarse. Primero, debemos pronosticar el stock esperado en el momento de la primera llegada. De hecho, si para el momento de la primera llegada todavía queda mucho stock, entonces no hay razón para volver a pedir ahora. Segundo, debemos pronosticar la demanda esperada durante la duración de la ventana de responsabilidad. En una configuración real, también tendríamos que pronosticar la demanda más allá de la ventana de responsabilidad para evaluar el costo de mantenimiento de los productos que estamos ordenando ahora, ya que podría haber sobrantes que se extiendan a períodos posteriores. Sin embargo, por razones de concisión y tiempo, nos vamos a centrar hoy en el stock esperado y la demanda esperada en lo que respecta a la ventana de responsabilidad.
Este script implementa los factores o pronósticos de la ventana de responsabilidad que acabamos de discutir. Toma como entrada un pronóstico probabilístico de tiempo de espera y un pronóstico probabilístico de demanda. Devuelve dos distribuciones de probabilidades, a saber, el stock disponible a la llegada y la demanda elegible según la ventana de responsabilidad.
En las líneas uno y dos, configuramos las líneas de tiempo, que comienzan el 1 de enero y terminan el 1 de marzo. En una configuración de predicción, esta línea de tiempo no estaría codificada de forma rígida. En la línea cuatro, se introduce un modelo de demanda probabilístico simplista: una distribución de Poisson repetida día a día durante toda la duración de esta línea de tiempo. La demanda será de una unidad por día en promedio. Aquí estoy utilizando un modelo simplista para la demanda con el fin de claridad. En una configuración real, por ejemplo, usaríamos un ESSM (Modelo de Espacio de Estados de Conjunto). Los modelos de espacio de estados son modelos probabilísticos y se han presentado en la primera conferencia de este capítulo.
En la línea cinco, se introduce otro modelo probabilístico simplista. Este segundo modelo está destinado a los tiempos de espera. Es una distribución de Poisson desplazada siete días hacia la derecha. El desplazamiento se realiza a través de una convolución. En la línea seis, definimos el stock inicial disponible. En la línea siete, definimos el ciclo de pedido. Este valor se expresa en días y caracteriza cuándo se realizará el próximo pedido.
Desde la línea 9 hasta la 16, tenemos un bloque de Monte Carlo que representa la lógica principal del script. Anteriormente en esta conferencia, ya hemos presentado otro bloque de Monte Carlo para respaldar nuestra lógica de validación cruzada. Aquí, estamos utilizando esta construcción nuevamente, pero con un propósito diferente. Queremos calcular dos variables aleatorias que reflejen, respectivamente, el stock disponible a la llegada y la demanda elegible. Sin embargo, el álgebra de las variables aleatorias no es lo suficientemente expresiva como para realizar este cálculo. Por lo tanto, en su lugar, estamos utilizando un bloque de Monte Carlo.
En la tercera conferencia de este capítulo, señalé que hay una dualidad entre el pronóstico probabilístico y las simulaciones. El bloque de Monte Carlo ilustra esta dualidad. Comenzamos con un pronóstico probabilístico, lo convertimos en una simulación y finalmente convertimos los resultados de la simulación en otro pronóstico probabilístico.
Echemos un vistazo a los detalles. En la línea 10, generamos una trayectoria para la demanda. En la línea 11, generamos la fecha de llegada del primer pedido, asumiendo que estamos haciendo el pedido hoy. En la línea 12, generamos la fecha de llegada del segundo pedido, asumiendo que estamos haciendo el pedido un ciclo de pedido a partir de ahora. En la línea 13, calculamos lo que queda como stock disponible en la primera fecha de llegada. Es el stock inicial disponible menos la demanda observada durante la duración del primer tiempo de espera. El “max zero” indica que el stock no puede ser negativo. En otras palabras, asumimos que no hay ningún atraso. Esta suposición de no atraso se puede modificar. El caso de atraso se deja como ejercicio para la audiencia. Como pista, se puede utilizar la programación diferenciable para evaluar el porcentaje de la demanda no satisfecha que se convierte con éxito en atrasos, dependiendo de cuántos días falten antes de la disponibilidad renovada del stock.
Volviendo al script, en la línea 14, calculamos la demanda elegible, que es la demanda que ocurre durante la ventana de responsabilidad. En las líneas 15 y 16, recopilamos dos variables aleatorias de interés mediante la palabra clave “sample”. A diferencia del primer script de Envision de esta conferencia, que se ocupaba de la validación cruzada, aquí buscamos recopilar distribuciones de probabilidades de este bloque de Monte Carlo, no solo promedios. En ambas líneas 15 y 16, la variable aleatoria que aparece en el lado derecho de la asignación es un agregador. En la línea 15, obtenemos una variable aleatoria para el stock disponible a la llegada. En la línea 16, obtenemos otra variable aleatoria para la demanda que ocurre dentro de la ventana de responsabilidad.
En las líneas 18 y 19, se muestran estas dos variables aleatorias. Ahora, detengámonos por un segundo y reconsideremos todo este script. Las líneas del uno al siete están dedicadas únicamente a la configuración de los datos simulados. Las líneas 18 y 19 solo muestran los resultados. La única lógica real ocurre en las ocho líneas entre las líneas 9 y 16. De hecho, toda la lógica real está ubicada, en cierto sentido, en las líneas 13 y 14.
Con solo unas pocas líneas de código, menos de 10 sin importar cómo las contemos, combinamos un pronóstico probabilístico de tiempo de espera con un pronóstico probabilístico de demanda para componer algún tipo de pronóstico probabilístico híbrido de importancia real en la cadena de suministro. Notemos que no hay nada aquí que realmente dependa de los detalles tanto del pronóstico de tiempo de espera como del pronóstico de demanda. Se han utilizado modelos simples, pero en su lugar se podrían haber utilizado modelos sofisticados. No habría cambiado nada. El único requisito es tener dos modelos probabilísticos para que sea posible generar esas trayectorias.
Finalmente, en la pantalla, los histogramas producidos por el script. El histograma superior representa el stock en mano a la llegada. Hay aproximadamente un 30% de probabilidad de enfrentar un stock inicial en cero. En otras palabras, hay un 30% de probabilidad de que haya ocurrido un faltante de stock en el último día justo antes de la primera fecha de llegada. El valor promedio del stock podría ser de alrededor de cinco unidades. Sin embargo, si juzgáramos esta situación por su promedio, estaríamos interpretando seriamente mal la situación. Un pronóstico probabilístico es esencial para reflejar adecuadamente la situación inicial del stock.
El histograma inferior representa la demanda asociada con la ventana de responsabilidad. Tenemos aproximadamente un 10% de probabilidad de enfrentar una demanda en cero. Este resultado también podría percibirse como sorprendente. De hecho, comenzamos este ejercicio con una demanda estacionaria de Poisson de una unidad por día en promedio. Tenemos siete días entre pedidos. Si no fuera por el tiempo de espera variable, debería haber menos de un 0.1% de probabilidad de obtener una demanda en cero durante siete días. Sin embargo, el script demuestra que esta ocurrencia es mucho más frecuente. La razón es que una pequeña ventana de responsabilidad puede ocurrir si el primer tiempo de espera es más largo de lo habitual y si el segundo tiempo de espera es más corto de lo habitual.
Enfrentar una demanda en cero durante la ventana de responsabilidad significa que es probable que el stock en mano se vuelva bastante alto en algún momento. Dependiendo de la situación, esto podría ser o no crítico, pero podría serlo, por ejemplo, si hay un límite de capacidad de almacenamiento o si el stock es perecedero. Una vez más, la demanda promedio, probablemente alrededor de ocho, no proporciona una visión confiable de cómo se veía la demanda. Recuerde que hemos obtenido esta distribución altamente asimétrica a partir de una demanda estacionaria inicial, una unidad por día en promedio. Este es el efecto del tiempo de espera variable en acción.
Esta configuración simple demuestra la importancia de los tiempos de espera cuando se trata de situaciones de reabastecimiento de inventario. Desde una perspectiva de la cadena de suministro, aislar los pronósticos de tiempo de espera de los pronósticos de demanda es, en el mejor de los casos, una abstracción práctica. La demanda diaria no es lo que realmente nos interesa. Lo que realmente nos interesa es la composición de la demanda con el tiempo de espera. Si hubiera otros factores estocásticos presentes, como los atrasos o las devoluciones, esos factores también habrían formado parte del modelo.
El presente capítulo de esta serie de conferencias se titula “Modelado Predictivo” en lugar de “Pronóstico de Demanda”, como suele ser el caso en los libros de texto convencionales de la cadena de suministro. La razón de este título del capítulo debería haberse vuelto progresivamente obvia a medida que avanzamos en la presente conferencia. De hecho, desde una perspectiva de la cadena de suministro, queremos pronosticar la evolución del sistema de la cadena de suministro. La demanda ciertamente es un factor importante, pero no es el único factor. También se deben pronosticar otros factores variables como el tiempo de espera. Aún más importante, todos esos factores deben ser pronosticados juntos al final.
De hecho, necesitamos reunir esos componentes predictivos para respaldar un proceso de toma de decisiones. Por lo tanto, lo importante no es buscar algún tipo de modelo de pronóstico de demanda final. Esta tarea es en gran medida una tarea inútil, en última instancia, porque la precisión adicional se obtendrá de maneras que van en contra del interés de la empresa. Mayor sofisticación significa más opacidad, más errores, más recursos informáticos. Como regla general, cuanto más sofisticado sea el modelo, más difícil será componer con éxito este modelo con otro modelo. Lo importante es reunir una colección de técnicas predictivas que se puedan componer a voluntad. Esto es de lo que se trata la modularidad desde una perspectiva de modelado predictivo. En esta conferencia, se han presentado media docena de técnicas. Estas técnicas son útiles ya que abordan ángulos críticos del mundo real como observaciones incompletas. También son simples; ninguno de los ejemplos de código presentados hoy superó las 10 líneas de lógica real. Lo más importante, estas técnicas son modulares, como ladrillos de Lego. Funcionan bien juntas y se pueden recombinar casi infinitamente.
El objetivo final del modelado predictivo para la cadena de suministro, como se debe entender, es la identificación de dichas técnicas. Cada técnica debería ser, por sí misma, una oportunidad para revisar cualquier modelo predictivo preexistente con el fin de simplificar o mejorar este modelo.
En conclusión, a pesar de que el tiempo de espera es en gran medida ignorado por la comunidad académica, el tiempo de espera puede y debe ser pronosticado. Al revisar una breve serie de distribuciones de tiempo de espera del mundo real, hemos identificado dos desafíos: en primer lugar, los tiempos de espera varían; en segundo lugar, los tiempos de espera son escasos. Por lo tanto, hemos introducido técnicas de modelado que son apropiadas para tratar con observaciones de tiempo de espera que resultan ser tanto escasas como erráticas.
Estos modelos de tiempo de espera son probabilísticos y son, en gran medida, la continuación de los modelos que se han introducido gradualmente a lo largo de este capítulo. También hemos visto que la perspectiva de probabilidad proporciona una solución elegante al problema de la observación incompleta, un aspecto casi omnipresente en la cadena de suministro. Este problema ocurre siempre que hay faltantes de stock y siempre que hay pedidos pendientes. Finalmente, hemos visto cómo componer un pronóstico de tiempo de espera probabilístico con un pronóstico de demanda probabilístico para crear el modelo predictivo que necesitamos para respaldar un proceso posterior de toma de decisiones.
La próxima conferencia será el 8 de marzo. Será un miércoles a la misma hora del día, a las 3 PM hora de París. La conferencia de hoy fue técnica, pero la próxima será en gran medida no técnica, y discutiré el caso del Supply Chain Scientist. De hecho, los libros de texto convencionales de la cadena de suministro abordan la cadena de suministro como si los modelos de pronóstico y los modelos de optimización surgieran y operaran de la nada, ignorando por completo su componente “wetware”, es decir, las personas a cargo. Por lo tanto, analizaremos más de cerca los roles y responsabilidades del científico de la cadena de suministro, una persona que se espera que lidere la iniciativa de la cadena de suministro cuantitativa.
Ahora, procederé con las preguntas.
Pregunta: ¿Qué sucede si alguien quiere mantener su stock para futuras innovaciones o por razones distintas al just in time u otros conceptos?
Esta es una pregunta muy importante. El concepto se aborda típicamente a través del modelado económico de la cadena de suministro, que técnicamente llamamos “drivers económicos” en esta serie de conferencias. Lo que estás preguntando es si es mejor no atender a un cliente hoy porque, en un momento posterior, habrá una oportunidad de atender a la misma unidad a otra persona que sea más importante por cualquier motivo. En esencia, lo que estás diciendo es que hay más valor que se puede capturar al atender a otro cliente más tarde, tal vez un cliente VIP, que al atender a un cliente hoy.
Esto podría ser cierto y sucede. Por ejemplo, en la industria de la aviación, supongamos que eres un proveedor de MRO (Mantenimiento, Reparación y Revisión). Tienes tus clientes VIP habituales, las aerolíneas a las que sirves rutinariamente con contratos a largo plazo, y son muy importantes. Cuando esto sucede, quieres asegurarte de que siempre podrás atender a esos clientes. Pero, ¿qué sucede si otra aerolínea te llama y te pide una unidad? En este caso, lo que sucederá es que podrías atender a esta persona, pero no tienes un contrato a largo plazo con ellos. Entonces, lo que vas a hacer es ajustar tu precio para que sea muy alto, asegurándote de obtener suficiente valor para compensar el posible faltante de stock que puedas enfrentar en un momento posterior. En resumen, para esta primera pregunta, creo que no es realmente una cuestión de pronóstico, sino más bien una cuestión de modelado adecuado de los drivers económicos. Si quieres preservar el stock, lo que quieres es generar un modelo, un modelo de optimización, donde la respuesta racional no sea atender al cliente que solicita una unidad mientras aún tienes stock en reserva.
Por cierto, otra situación típica para eso es cuando vendes kits. Un kit es un conjunto de muchas partes que se venden juntas, y solo te queda una parte que vale solo una pequeña fracción del valor total del kit. El problema es que si vendes esta última unidad, ya no puedes construir tu kit y venderlo a su precio completo. Por lo tanto, podrías estar en una situación en la que prefieras mantener la unidad en stock solo por el hecho de poder vender el kit en un momento posterior, potencialmente con cierta incertidumbre. Pero nuevamente, todo se reduce a los drivers económicos, y esa sería la forma en que abordaría esta situación.
Pregunta: Durante los últimos años, la mayoría de los retrasos en la cadena de suministro ocurrieron debido a la guerra o la pandemia, lo cual es muy difícil de pronosticar porque no habíamos tenido tales situaciones antes. ¿Cuál es tu opinión al respecto?
Mi opinión es que los tiempos de entrega han estado variando desde siempre. He estado en el mundo de la cadena de suministro desde 2008, y mis padres trabajaban en cadena de suministro incluso 30 años antes que yo. Hasta donde podemos recordar, los tiempos de entrega han sido erráticos y variables. Siempre está sucediendo algo, ya sea una protesta, una guerra o un cambio en los aranceles. Sí, los últimos años han sido extremadamente erráticos, pero los tiempos de entrega ya variaban bastante.
Estoy de acuerdo en que nadie puede pretender ser capaz de pronosticar la próxima guerra o pandemia. Si fuera posible predecir estos eventos matemáticamente, las personas no se involucrarían en guerras ni invertirían en cadena de suministro; simplemente jugarían en el mercado de valores y se enriquecerían anticipando los movimientos del mercado.
La conclusión es que lo que puedes hacer es planificar para lo inesperado. Si no tienes confianza en el futuro, puedes inflar las variaciones en tus pronósticos. Es lo contrario de tratar de hacer tu pronóstico más preciso: preservas tus expectativas promedio, pero simplemente inflas la cola para que las decisiones que tomes basadas en esos pronósticos probabilísticos sean más resilientes a las variaciones. Has diseñado tus variaciones esperadas para que sean más grandes de lo que estás viendo actualmente. La idea de que las cosas sean fáciles o difíciles de pronosticar proviene de una perspectiva de pronóstico puntual, donde te gustaría jugar el juego como si fuera posible tener una anticipación precisa del futuro. Esto no es así, no existe tal cosa como una anticipación precisa del futuro. Lo único que puedes hacer es trabajar con distribuciones de probabilidad con un rango amplio que manifieste y cuantifique tu ignorancia del futuro.
En lugar de afinar decisiones que dependen críticamente de la ejecución minuciosa del plan exacto, estás teniendo en cuenta y planificando un grado interesante de variación, lo que hace que tus decisiones sean más robustas frente a esas variaciones. Sin embargo, esto solo se aplica al tipo de variación que no afecta tu cadena de suministro de manera demasiado brutal. Por ejemplo, puedes lidiar con tiempos de entrega más largos de los proveedores, pero si tu almacén ha sido bombardeado, ningún pronóstico te salvará en esa situación.
Pregunta: ¿Podemos crear estos histogramas y calcular el CRPS en Microsoft Excel, por ejemplo, utilizando complementos de Excel como itsastat o que aloja muchas distribuciones?
Sí, puedes hacerlo. Uno de nosotros en Lokad ha creado una hoja de cálculo de Excel que representa un modelo probabilístico para una situación de reabastecimiento de inventario. El meollo del problema es que Excel no tiene un tipo de datos de histograma nativo, por lo que todo lo que tienes en Excel son números: una celda, un número. Sería elegante y simple tener un valor que sea un histograma, donde tengas un histograma completo empaquetado en una sola celda. Sin embargo, hasta donde yo sé, esto no es posible en Excel. Sin embargo, si estás dispuesto a gastar alrededor de 100 líneas o más para representar el histograma, aunque no será tan compacto y práctico, puedes implementar una distribución en Excel y hacer algún modelado probabilístico. Publicaremos el enlace al ejemplo en la sección de comentarios.
Ten en cuenta que es una tarea relativamente dolorosa porque Excel no es ideal para esta tarea. Excel es un lenguaje de programación y puedes hacer cualquier cosa con él, por lo que ni siquiera necesitas un complemento para lograr esto. Sin embargo, será un poco verboso, así que no esperes algo súper ordenado.
Pregunta: El tiempo de entrega se puede descomponer en componentes como el tiempo de pedido, el tiempo de producción, el tiempo de transporte, etc. Si uno desea un control más granular sobre los tiempos de entrega, ¿cómo cambiaría este enfoque?
Primero, debemos considerar qué significa tener un mayor control sobre el tiempo de entrega. ¿Quieres reducir el tiempo de entrega promedio o reducir la variabilidad del tiempo de entrega? Curiosamente, he visto muchas empresas tener éxito en la reducción del tiempo de entrega promedio, pero a costa de aumentar la variación del tiempo de entrega. En promedio, el tiempo de entrega es más corto, pero de vez en cuando es mucho más largo.
En esta conferencia, estamos llevando a cabo un ejercicio de modelado. Por sí mismo, no hay ninguna acción; se trata simplemente de observar, analizar y predecir. Sin embargo, si podemos descomponer el tiempo de entrega y analizar la distribución subyacente, podemos utilizar el modelado probabilístico para evaluar qué componentes varían más y cuáles tienen el mayor impacto negativo en nuestra cadena de suministro. Podemos realizar escenarios “qué pasaría si” con esta información. Por ejemplo, toma una parte de tu tiempo de entrega y pregúntate: “¿Qué pasaría si la cola de este tiempo de entrega fuera un poco más corta, o si el promedio fuera un poco más corto?” Luego puedes recomponer todo, volver a ejecutar tu modelo predictivo para toda tu cadena de suministro y comenzar a evaluar el impacto.
Este enfoque te permite razonar por partes sobre ciertos fenómenos, incluidos los erráticos. No sería tanto un cambio de enfoque, sino una continuación de lo que hemos hecho, que nos lleva al Capítulo 6, que trata sobre la optimización de decisiones reales basadas en estos modelos probabilísticos.
Pregunta: Creo que esto ofrece la oportunidad de recalcular nuestros tiempos de entrega en SAP para proporcionar un marco de tiempo más realista y ayudar a minimizar nuestra entrada y salida del sistema. ¿Es posible?
Descargo de responsabilidad: SAP es un competidor de Lokad en el espacio de optimización de la cadena de suministro. Mi respuesta inicial es no, SAP no puede hacer eso. La realidad es que SAP tiene cuatro soluciones distintas que se ocupan de la optimización de la cadena de suministro, y depende de qué pila estés hablando. Sin embargo, todas esas pilas tienen en común una visión centrada en pronósticos puntuales. Todo en SAP ha sido diseñado sobre la premisa de que los pronósticos serán precisos.
Sí, SAP tiene algunos parámetros para ajustar, como la distribución normal que mencioné al principio de esta conferencia. Sin embargo, las distribuciones de tiempo de entrega que observamos no eran distribuciones normales. Hasta donde yo sé, las configuraciones principales de SAP para la optimización de la cadena de suministro adoptan una distribución normal para los tiempos de entrega. El problema es que, en el núcleo, el software está haciendo una suposición matemática ampliamente incorrecta. No puedes recuperarte de una suposición matemática ampliamente incorrecta que va directamente al núcleo de la arquitectura de tu software ajustando un parámetro. Tal vez puedas hacer ingeniería inversa y encontrar un parámetro que genere la decisión correcta. Teóricamente, esto es posible, pero en la práctica presenta tantos problemas que la pregunta es, ¿realmente quieres hacer eso?
Para adoptar una perspectiva probabilística, debes estar completamente comprometido, lo que significa que tus pronósticos son probabilísticos y tus modelos de optimización también aprovechan modelos probabilísticos. El problema aquí es que incluso si pudiéramos ajustar el modelado probabilístico para obtener tiempos de entrega ligeramente mejores, el resto de la pila de SAP volverá a los pronósticos puntuales. No importa lo que suceda, colapsaremos esas distribuciones en puntos. La idea de que podrías aproximar esto con un promedio es problemática y simplemente incorrecta. Entonces, técnicamente, podrías ajustar los tiempos de entrega, pero te encontrarás con tantos problemas después de eso que puede que no valga la pena el esfuerzo.
Pregunta: Hay situaciones en las que se ordenan las mismas piezas a diferentes proveedores. Esta es información importante para procesar en el pronóstico del tiempo de entrega. ¿Realizas el pronóstico del tiempo de entrega por artículo o hay situaciones en las que aprovechas la agrupación de artículos en familias?
Esta es una pregunta notablemente interesante. Tenemos dos proveedores para el mismo artículo. La pregunta será cuánta similitud hay entre los artículos y los proveedores. Primero, debemos analizar la situación. Si un proveedor está al lado y el otro proveedor está al otro lado del mundo, realmente necesitas considerar esas cosas por separado. Pero supongamos la situación interesante donde los dos proveedores son bastante similares y es el mismo artículo. ¿Deberías agrupar esas observaciones o no?
Lo interesante es que a través de la programación diferenciable, puedes componer un modelo que le dé cierto peso al proveedor y cierto peso al artículo y dejar que la magia del aprendizaje haga su magia. Se ajustará si debemos poner más peso en el componente del artículo del tiempo de entrega o en el componente del proveedor. Es posible que dos proveedores que sirven productos bastante similares tengan algún sesgo donde un proveedor sea, en promedio, un poco más rápido que el otro. Pero hay artículos que definitivamente llevan más tiempo, y así que si seleccionas artículos selectivamente, no está muy claro que un proveedor sea más rápido que el otro porque realmente depende de qué artículos estés mirando. Es muy probable que tengas muy pocos datos si desagregas todo hasta cada proveedor y cada artículo. Por lo tanto, lo interesante, y lo que recomendaría aquí, sería diseñar a través de la programación diferenciable. De hecho, podríamos intentar revisar esta situación en una conferencia posterior, una situación en la que colocas algunos parámetros en el nivel de la pieza y algunos parámetros en el nivel del proveedor. Entonces, tienes un número total de parámetros que no es el número de piezas multiplicado por el número de proveedores; eso sería el número de piezas más el número de proveedores, o tal vez más el número de proveedores multiplicado por categorías, o algo similar. No explotas tu número de parámetros; simplemente agregas un parámetro, un elemento que tiene afinidad con el proveedor, y eso te permite hacer algún tipo de mezcla dinámica impulsada por tus datos históricos.
Pregunta: Creo que la cantidad que se ordena y qué productos se ordenan juntos también podrían afectar el tiempo de entrega al final. ¿Podrías explicar la complejidad de incluir todas las variables en este tipo de problema?
En el último ejemplo, teníamos dos tipos de duración: el ciclo de pedido y el propio tiempo de entrega. El ciclo de pedido es interesante porque solo es incierto en la medida en que aún no hemos tomado la decisión. Es fundamentalmente algo que puedes decidir prácticamente en cualquier momento, por lo que el ciclo de pedido es completamente interno y de tu propia creación. Esto no es lo único en la cadena de suministro que es así; los precios son iguales. Tienes demanda, observas la demanda, pero en realidad puedes elegir el precio que deseas. Algunos precios son obviamente imprudentes, pero es lo mismo: es de tu propia creación.
El ciclo de pedido es de tu propia creación. Ahora, lo que estás diciendo es que hay incertidumbre sobre el momento exacto para el próximo tiempo de entrega del pedido porque no sabes exactamente cuándo realizarás el pedido. De hecho, tienes toda la razón. Lo que sucede es que cuando tienes la capacidad de implementar este modelado probabilístico, de repente, como se discutió en el sexto capítulo de esta serie de conferencias, no quieres decir que el ciclo de pedido es de siete días. En cambio, quieres adoptar una política de reordenamiento que maximice el retorno de la inversión para tu empresa. Por lo tanto, lo que puedes hacer es planificar el futuro para que si vuelves a ordenar ahora, puedas tomar una decisión ahora y luego aplicar tu política día a día. En algún momento en el futuro, haces un nuevo pedido y ahora tienes una especie de situación de “serpiente que se come la cola” porque la mejor decisión de pedido para hoy depende de la decisión del próximo pedido, la que aún no has tomado. Este tipo de problema se conoce como un problema de política y es un problema de decisión secuencial. En el fondo, lo que realmente quieres es diseñar algún tipo de política, un objeto matemático que gobierne tu proceso de toma de decisiones.
El problema de la optimización de políticas es bastante complicado y tengo la intención de cubrirlo en el sexto capítulo. Pero la conclusión es que tenemos, si volvemos a tu pregunta, dos componentes distintos. Tenemos el componente que varía independientemente de lo que hagas, el tiempo de entrega que es el tiempo de entrega de tu proveedor, y luego tienes el tiempo de pedido, que es algo que realmente está impulsado internamente por tu proceso y debe tratarse como una cuestión de optimización.
Concluyendo este pensamiento, vemos una convergencia de la optimización y el modelado predictivo. Al final, ambos acaban siendo prácticamente lo mismo porque hay interacciones entre las decisiones que tomas y lo que sucede en el futuro.
Eso es todo por hoy. No olvides, el 8 de marzo, a la misma hora del día, será un miércoles a las 3 PM. Gracias y nos vemos la próxima vez.
