00:28 Introducción
00:43 Robert A. Heinlein
03:03 La historia hasta ahora
06:52 Una selección de paradigmas
08:20 Análisis estático
18:26 Programación de matrices
28:08 Miscibilidad de hardware
35:38 Programación probabilística
40:53 Programación diferenciable
55:12 Versionado de código+datos
01:00:01 Programación segura
01:05:37 En conclusión, las herramientas también importan en la cadena de suministro
01:06:40 Próxima conferencia y preguntas de la audiencia
Descripción
Mientras que la teoría de la cadena de suministro convencional lucha por prevalecer en las empresas en general, una herramienta, en particular Microsoft Excel, ha disfrutado de un considerable éxito operativo. Reimplementar las recetas numéricas de la teoría de la cadena de suministro convencional a través de hojas de cálculo es trivial, sin embargo, esto no es lo que sucedió en la práctica a pesar del conocimiento de la teoría. Demostramos que las hojas de cálculo ganaron al adoptar paradigmas de programación que demostraron ser superiores para obtener resultados en la cadena de suministro.
Transcripción completa
Hola a todos, bienvenidos a esta serie de conferencias sobre cadena de suministro. Soy Joannes Vermorel y hoy presentaré mi cuarta conferencia: Paradigmas de Programación para la Cadena de Suministro.
Así que cuando me preguntan: “Sr. Vermorel, ¿cuáles cree que son las áreas de mayor interés para usted en términos de conocimiento de la cadena de suministro?”, una de mis respuestas principales suele ser los paradigmas de programación. Y luego, no con demasiada frecuencia, pero lo suficientemente frecuente, la reacción de la persona con la que estoy hablando es: “¿Paradigmas de programación, Sr. Vermorel? ¿De qué diablos estás hablando? ¿Cómo puede ser relevante para la tarea en cuestión?” Y ese tipo de reacciones, obviamente, no son tan frecuentes, pero cuando ocurren, invariablemente me recuerdan esta cita completamente increíble de Robert A. Heinlein, considerado el decano de los escritores de ciencia ficción.
Heinlein tiene una cita fantástica sobre el hombre competente, que destaca la importancia de la competencia en varios campos, especialmente en la cadena de suministro donde tenemos problemas complejos entre manos. Estos problemas son casi tan desafiantes como la vida misma, y creo que realmente vale la pena explorar la idea de los paradigmas de programación, ya que podrían aportar mucho valor a su cadena de suministro.
Hasta ahora, en la primera conferencia, hemos visto que los problemas de la cadena de suministro son complejos. Cualquiera que hable de soluciones óptimas no entiende el punto; no hay nada ni remotamente cercano a la optimalidad. En la segunda conferencia, delineé la Supply Chain Quantitativa, una visión con cinco requisitos clave para la grandeza en la gestión de la cadena de suministro. Estos requisitos no son suficientes por sí solos, pero no se pueden pasar por alto si se quiere lograr la grandeza.
En la tercera conferencia, discutí la entrega de productos de software en el contexto de la optimización de la cadena de suministro. Defendí la proposición de que la optimización de la cadena de suministro requiere que un producto de software se aborde adecuadamente de manera capitalista, pero no se puede encontrar dicho producto en el estante. Hay demasiada diversidad y los desafíos que enfrentamos están mucho más allá de las tecnologías que tenemos en el presente. Por lo tanto, va a ser, por necesidad, algo completamente hecho a la medida. Por lo tanto, si es un producto de software que va a ser hecho a la medida para la empresa o la cadena de suministro de interés, surge la pregunta de cuáles son las herramientas adecuadas para entregar realmente este producto. Eso me lleva al tema de hoy: la herramienta adecuada comienza con los paradigmas de programación correctos, porque vamos a tener que programar este producto de una forma u otra.
Hasta ahora, requerimos capacidades programáticas para lidiar con el lado de la optimización del problema, sin confundirlo con el lado de la gestión. Lo que hemos visto, que fue el tema de mi conferencia anterior, es que Microsoft Excel ha sido el ganador hasta ahora. Desde empresas muy pequeñas hasta empresas muy grandes, es omnipresente, se usa en todas partes. Incluso en empresas que han invertido millones de dólares en sistemas superinteligentes, Excel sigue siendo el rey, ¿y por qué? Porque tiene las propiedades de programación correctas. Es muy expresivo, ágil, accesible y mantenible. Sin embargo, Excel no es el objetivo final. Creo firmemente que podemos hacer mucho más, pero necesitamos tener las herramientas adecuadas, la mentalidad correcta, las ideas y los paradigmas de programación.
Los paradigmas de programación pueden parecer demasiado oscuros para la audiencia, pero en realidad es un campo de estudio que se ha estudiado intensamente en las últimas cinco décadas. Se ha realizado una inmensa cantidad de trabajo en este campo de estudio. No es ampliamente conocido por una audiencia más amplia, pero hay bibliotecas enteras llenas de trabajos de alta calidad que han sido realizados por muchas personas. Así que hoy, voy a presentar una serie de siete paradigmas que Lokad ha adoptado. No inventamos ninguna de estas ideas; las tomamos de personas que las inventaron antes que nosotros. Todos estos paradigmas se han implementado en el producto de software de Lokad, y después de casi una década de ejecutar Lokad en producción, aprovechando estos paradigmas, creo que han sido absolutamente críticos para nuestro éxito operativo hasta ahora.
Avancemos en esta lista con el análisis estático. El problema aquí es la complejidad. ¿Cómo se maneja la complejidad en la cadena de suministro? Te enfrentarás a sistemas empresariales que tienen cientos de tablas, cada una con docenas de campos. Si estás considerando un problema tan simple como el reabastecimiento de inventario en un almacén, tienes tantas cosas que tener en cuenta. Puedes tener cantidades mínimas de pedido (MOQs), descuentos por volumen, pronósticos de demanda, pronósticos de tiempos de entrega, y todo tipo de devoluciones. Puedes tener limitaciones de espacio en el estante, límites de capacidad de recepción y fechas de vencimiento que hacen que algunos de tus lotes sean obsoletos. Entonces, terminas con toneladas de cosas que considerar. En la cadena de suministro, la idea de “moverse rápido y romper cosas” simplemente no es la mentalidad correcta. Si por error ordenas un millón de dólares en mercancía que no necesitas en absoluto, este es un error muy costoso. No puedes tener un software que maneje tu cadena de suministro, tome decisiones rutinarias y cuando haya un error, cueste millones. Necesitamos tener algo con un grado muy alto de corrección por diseño. No queremos descubrir los errores en producción. Esto es muy diferente de tu software promedio donde un fallo no es gran cosa.
Cuando se trata de optimización de la cadena de suministro, este no es tu problema habitual. Si acabas de pasar un pedido masivo e incorrecto a un proveedor, no puedes simplemente llamarlos una semana después para decir: “Oh, mi error, no, olvídalo, nunca pedimos eso”. Esos errores van a costar mucho dinero. El análisis estático se llama así porque se trata de analizar un programa sin ejecutarlo. La idea es que tienes un programa escrito con declaraciones, palabras clave y todo, y sin siquiera ejecutar este programa, ¿puedes decir si el programa presenta problemas que casi seguramente afectarían negativamente tu producción, especialmente tu producción de cadena de suministro? La respuesta es sí. Estas técnicas existen y se implementan y son extremadamente valiosas.
Solo para dar un ejemplo, puedes ver una captura de pantalla de Envision en la pantalla. Envision es un lenguaje de programación específico del dominio que ha sido desarrollado durante casi una década por Lokad y está dedicado a la optimización predictiva de la cadena de suministro. Lo que estás viendo es una captura de pantalla del editor de código de Envision, una aplicación web que puedes usar en línea para editar código. La sintaxis está fuertemente influenciada por Python. En esta pequeña captura de pantalla, con solo cuatro líneas, estoy ilustrando la idea de que si estás escribiendo una gran pieza de lógica para el reabastecimiento de inventario en un almacén, e introduces algunas variables económicas, como descuentos de precios, a través de un análisis lógico del programa, puedes ver que esos descuentos de precios no tienen ninguna relación con los resultados finales que devuelve el programa, que son las cantidades a reabastecer. Aquí tienes un problema obvio. Has introducido una variable importante, los descuentos de precios, y esos descuentos de precios lógicamente no tienen influencia en los resultados finales. Entonces aquí tenemos un problema que se puede detectar mediante análisis estático. Es un problema obvio porque si introducimos variables en el código que no tienen ningún impacto en la salida del programa, entonces no sirven para nada. En este caso, nos enfrentamos a dos opciones: o esas variables son realmente código muerto y el programa no debería compilar (deberías deshacerte de este código muerto para reducir la complejidad y no acumular complejidad accidental), o fue un error genuino y hay una variable económica importante que debería haberse incluido en tu cálculo, pero dejaste pasar la oportunidad debido a una distracción u otra razón.
El análisis estático es absolutamente fundamental para lograr cualquier grado de corrección por diseño. Se trata de solucionar problemas en tiempo de compilación cuando escribes el código, incluso antes de tocar los datos. Si los problemas surgen cuando los ejecutas, es probable que tus problemas solo ocurran durante la noche cuando tienes el lote nocturno que impulsa el reabastecimiento del almacén. Es probable que el programa se ejecute en horas extrañas cuando nadie lo está supervisando, por lo que no quieres que algo se bloquee cuando no hay nadie frente al programa. Debería bloquearse en el momento en que las personas realmente están escribiendo el código.
El análisis estático tiene muchos propósitos. Por ejemplo, en Lokad, utilizamos el análisis estático para la edición WYSIWYG de paneles de control. WYSIWYG significa “lo que ves es lo que obtienes”. Imagina que estás construyendo un panel de control para informes, con gráficos de líneas, gráficos de barras, tablas, colores y varios efectos de estilo. Quieres poder hacer eso visualmente, no ajustar el estilo de tu panel de control a través del código, ya que es muy engorroso. Todas las configuraciones que has implementado se reinyectarán en el propio código, y eso se hace a través del análisis estático.
Otro aspecto en Lokad, que puede no ser tan importante para la cadena de suministro en general, pero ciertamente es crítico para llevar a cabo el proyecto, fue lidiar con un lenguaje de programación llamado Envision que estamos desarrollando. Sabíamos desde el primer día, hace casi una década, que se cometerían errores. No teníamos una bola de cristal para tener la visión perfecta desde el primer día. La pregunta era, ¿cómo podemos asegurarnos de que podemos corregir esos errores de diseño en el propio lenguaje de programación de la manera más conveniente posible? Aquí, Python fue una advertencia para mí.
Python, que no es un lenguaje nuevo, fue lanzado por primera vez en 1991, hace casi 30 años. La migración de Python 2 a Python 3 llevó a toda la comunidad casi una década, y fue un proceso pesadillesco, muy doloroso para las empresas involucradas en esta migración. Mi percepción fue que el propio lenguaje no tenía suficientes constructos. No fue diseñado de tal manera que se pudieran migrar programas de una versión del lenguaje de programación a otra versión. De hecho, fue extremadamente difícil hacerlo de manera completamente automatizada, y eso se debe a que Python no ha sido diseñado teniendo en cuenta el análisis estático. Cuando tienes un lenguaje de programación para la cadena de suministro, realmente quieres uno que tenga una excelente calidad en términos de análisis estático porque tus programas tendrán una larga vida útil. Las cadenas de suministro no tienen el lujo de decir: “Espera tres meses; solo estamos reescribiendo el código. Espera por nosotros; la caballería está llegando. No va a funcionar durante un par de meses”. Es literalmente como arreglar un tren mientras el tren está funcionando a toda velocidad en las vías, y quieres arreglar el motor mientras el tren está funcionando. Eso es lo que parece arreglar cosas de la cadena de suministro que están en producción. No tienes el lujo de simplemente pausar el sistema; nunca se detiene.
El segundo paradigma es la programación de matrices. Queremos tener la complejidad bajo control, ya que ese es un tema recurrente importante en las cadenas de suministro. Queremos tener lógica donde no tengamos ciertas clases de errores de programación. Por ejemplo, cada vez que tienes bucles o ramas que son escritos explícitamente por los programadores, te expones a clases enteras de problemas muy difíciles. Se vuelve extremadamente difícil cuando las personas pueden simplemente escribir bucles arbitrarios para tener garantías sobre la duración del cálculo. Aunque pueda parecer un problema de nicho, no es del todo el caso en la optimización de la cadena de suministro.
En la práctica, digamos que tienes una cadena minorista. A medianoche, habrán consolidado completamente todas las ventas de toda la red, y los datos se consolidarán y se pasarán a algún tipo de sistema para la optimización. Este sistema tendrá exactamente una ventana de 60 minutos para hacer el pronóstico, la optimización de inventario y las decisiones de reasignación para cada tienda de la red. Una vez que se haya completado, los resultados se pasarán al sistema de gestión de almacenes para que puedan comenzar a preparar todos los envíos. Los camiones se cargarán, tal vez a las 5:00 a.m., y a las 9:00 a.m., las tiendas abrirán con la mercancía ya recibida y colocada en los estantes.
Sin embargo, tienes un tiempo muy estricto, y si tu cálculo se sale de esta ventana de 60 minutos, estás poniendo en riesgo toda la ejecución de la cadena de suministro. No quieres descubrir en producción cuánto tiempo llevan las cosas. Si tienes bucles donde las personas pueden decidir cuántas iteraciones van a tener, es muy difícil tener alguna prueba de la duración de tu cálculo. Ten en cuenta que estamos hablando de optimización de la cadena de suministro. No tienes el lujo de hacer una revisión por pares y verificar todo. A veces, debido a la pandemia, algunos países están cerrando mientras que otros están reabriendo de manera bastante errática, generalmente con un aviso de 24 horas. Necesitas reaccionar rápidamente.
Entonces, la programación de matrices es la idea de que puedes operar directamente en matrices. Si observamos el fragmento de código que tenemos aquí, este es el código de Envision, el DSL de Lokad. Para entender lo que está sucediendo, debes entender que cuando escribo “orders.amounts”, lo que viene es una variable y “orders” es en realidad una tabla en el sentido de una tabla relacional, como una tabla en tu base de datos. Por ejemplo, aquí en la primera línea, “amounts” sería una columna en la tabla. En la línea uno, lo que estoy haciendo es que literalmente estoy diciendo que por cada línea de la tabla de pedidos, simplemente voy a tomar la “cantidad”, que es una columna, y multiplicarla por el “precio”, y luego obtengo una tercera columna que se genera dinámicamente, que es “amount”.
Por cierto, el término moderno para la programación de matrices hoy en día también se conoce como programación de marcos de datos. El campo de estudio es bastante antiguo; se remonta a tres o cuatro décadas, tal vez incluso cuatro o cinco. Se ha conocido como programación de matrices incluso si hoy en día las personas suelen estar más familiarizadas con la idea de los marcos de datos. En la línea dos, lo que estamos haciendo es un filtro, al igual que SQL. Estamos filtrando las fechas, y resulta que la tabla de pedidos tiene una fecha. Se va a filtrar, y digo “fecha que es mayor que hoy menos 365”, por lo que son días. Mantenemos los datos del año pasado, y luego escribimos “products.soldLastYear = SUM(orders.amount)”.
Ahora, lo interesante es que tenemos lo que llamamos una unión natural entre productos y pedidos. ¿Por qué? Porque cada línea de pedido está asociada con un producto y solo un producto, y un producto está asociado con cero o más líneas de pedido. En esta configuración, puedes decir directamente, “Quiero calcular algo a nivel de producto que es solo una suma de lo que está sucediendo a nivel de pedidos”, y eso es exactamente lo que se está haciendo en la línea nueve. Puede que notes que la sintaxis es muy simple; no tienes muchos accidentes o tecnicismos. Yo afirmaría que este código está casi completamente desprovisto de cualquier accidente cuando se trata de programación de marcos de datos. Luego, en las líneas 10, 11 y 12, simplemente estamos mostrando una tabla en nuestro panel de control, lo cual se puede hacer de manera muy conveniente: “LIST(PRODUCTS)”, y luego “TO(products)”.
Hay muchas ventajas de la programación de matrices para las cadenas de suministro. Primero, elimina clases enteras de problemas. No vas a tener errores de uno por uno en tus matrices. Será mucho más fácil paralelizar e incluso distribuir el cálculo. Eso es muy interesante porque significa que puedes escribir un programa y hacer que se ejecute no en una máquina local, sino directamente en un conjunto de máquinas que están en la nube, y por cierto, esto es exactamente lo que se está haciendo en Lokad. Esta paralelización automática es de gran interés.
Verás, la forma en que funciona es que cuando haces optimización de la cadena de suministro, tus patrones de consumo típicos en términos de hardware informático son super intermitentes. Si vuelvo al ejemplo que estaba dando sobre la ventana de 60 minutos para las redes minoristas durante el reabastecimiento de la tienda, significa que hay una hora al día en la que necesitas potencia de cálculo para hacer todos tus cálculos, pero el resto del tiempo, las otras 23 horas, no necesitas eso. Entonces lo que quieres es un programa que, cuando estés a punto de ejecutarlo, se distribuya en muchas máquinas y luego, una vez que haya terminado, simplemente libere todas esas máquinas para que se puedan realizar otros cálculos. La alternativa sería tener muchas máquinas que estás alquilando y pagando todo el día, pero solo las usas el 5% del tiempo, lo cual es muy ineficiente.
Esta idea de poder distribuir rápidamente y de manera predecible en muchas máquinas, y luego ceder el poder de procesamiento, necesita la nube en una configuración de múltiples inquilinos y una serie de otras cosas que Lokad está haciendo. Pero en primer lugar, necesita la cooperación del propio lenguaje de programación. Es algo que simplemente no es factible con un lenguaje de programación genérico como Python, porque el propio lenguaje no se presta a este tipo de enfoque muy inteligente y relevante. Esto va más allá de simples trucos; se trata literalmente de dividir los costos de hardware de TI en un 20%, acelerar masivamente la ejecución y eliminar clases enteras de posibles errores en tu cadena de suministro. Esto cambia el juego.
La programación de matrices ya existe en muchos aspectos, como en NumPy y pandas en Python, que son tan populares para el segmento de científicos de la cadena de suministro de la audiencia. Pero la pregunta que tengo para ti es, si es tan importante y útil, ¿por qué estas cosas no son ciudadanos de primera clase del propio lenguaje? Si todo lo que haces es canalizar a través de NumPy, entonces NumPy debería ser un ciudadano de primera clase. Diría que puedes ir incluso más allá de NumPy. NumPy se trata solo de programación de matrices en una máquina, pero ¿por qué no hacer programación de matrices en una flota de máquinas? Es mucho más poderoso y mucho más adecuado cuando tienes una nube con capacidad de hardware accesible.
Entonces, ¿cuál será el cuello de botella en la optimización de la cadena de suministro? Hay un dicho de Goldratt que dice: “Cualquier mejora realizada junto al cuello de botella en una cadena de suministro es una ilusión”, y estoy muy de acuerdo con esta afirmación. Realísticamente, cuando queremos hacer optimización de la cadena de suministro, el cuello de botella serán las personas, y más específicamente, los científicos de la cadena de suministro que, desafortunadamente para Lokad y mis clientes, no crecen en los árboles.
El cuello de botella son los científicos de la cadena de suministro, las personas que pueden diseñar las recetas numéricas que tienen en cuenta todas las estrategias de la empresa, los comportamientos adversarios de los competidores y que convierten toda esta inteligencia en algo mecánico que se puede ejecutar a gran escala. La tragedia de la forma ingenua de hacer ciencia de datos, cuando comencé mi doctorado, que nunca completé, por cierto, era que podía ver que todos en el laboratorio estaban literalmente haciendo ciencia de datos. La mayoría de las personas estaban escribiendo código para algún tipo de modelo avanzado de aprendizaje automático, presionaban enter y luego comenzaban a esperar. Si tienes un conjunto de datos grande, digamos de 5 a 10 gigabytes, no será en tiempo real. Entonces, todo el laboratorio estaba lleno de personas que escribían unas pocas líneas, presionaban enter y luego iban a tomar una taza de café o leer algo en línea. Por lo tanto, la productividad era extremadamente baja.
Cuando comencé a crear mi propia empresa, tenía en mente que no quería terminar pagando a un ejército de personas súper inteligentes que pasaran la mayor parte del día tomando café, esperando a que sus programas se completaran para poder obtener resultados y avanzar. En teoría, podrían paralelizar muchas cosas a la vez y realizar experimentos, pero en la práctica, nunca he visto eso realmente. Intelectualmente, cuando estás comprometido en encontrar una solución para un problema, quieres probar tu hipótesis y necesitas el resultado para avanzar. Es muy difícil hacer varias tareas al mismo tiempo en cosas altamente técnicas y perseguir múltiples líneas intelectuales al mismo tiempo.
Sin embargo, había un rayo de esperanza. Los científicos de datos, y ahora los científicos de supply chain en Lokad, no terminan escribiendo mil líneas de código y luego diciendo “por favor, ejecútalo”. Por lo general, agregan dos líneas a un script que tiene mil líneas de largo, y luego piden que se ejecute el script. Este script se ejecuta con los mismos datos que acaban de ejecutar unos minutos antes. Es casi exactamente la misma lógica, excepto por esas dos líneas. Entonces, ¿cómo puedes procesar terabytes de datos en segundos en lugar de varios minutos? La respuesta es que, para la ejecución anterior del script, has registrado todos los pasos intermedios del cálculo y los has almacenado (normalmente en unidades de estado sólido o SSD), que son muy baratas, rápidas y convenientes.
La próxima vez que ejecutes tu programa, el sistema se dará cuenta de que es casi el mismo script. Hará una comparación y verá que, en términos del grafo de cálculo, es casi idéntico, excepto por algunos detalles. En términos de datos, generalmente es 100% idéntico. A veces hay algunos cambios, pero casi nada. El sistema diagnosticará automáticamente que solo tienes algunas cosas que necesitas calcular, por lo que puedes obtener los resultados en segundos. Esto puede aumentar drásticamente la productividad de tu científico de supply chain. Puedes pasar de tener personas que presionan enter y esperan 20 minutos por el resultado a tener personas que presionan enter y, 5 o 10 segundos después, tienen el resultado y pueden avanzar.
Estoy hablando de algo que puede parecer muy oscuro, pero en la práctica, estamos hablando de algo que tiene un impacto 10 veces mayor en la productividad. Esto es enorme. Entonces, lo que estamos haciendo aquí es usar un truco inteligente que Lokad no inventó. Estamos sustituyendo un recurso informático básico, que es el cálculo, por otro, que es la memoria y el almacenamiento. Tenemos los recursos informáticos fundamentales: cálculo, memoria (ya sea volátil o persistente) y ancho de banda. Estos son los recursos fundamentales por los que pagas cuando compras recursos en una plataforma de computación en la nube. En realidad, puedes sustituir un recurso por otro, y el objetivo es obtener el máximo rendimiento por tu dinero.
Cuando la gente dice que deberías usar la computación en memoria, yo diría que eso es absurdo. Si dices computación en memoria, significa que estás poniendo énfasis en un recurso en lugar de en los demás. Pero no, hay compensaciones, y lo interesante es que puedes tener un lenguaje de programación y un entorno que facilite la implementación de estas compensaciones y perspectivas. En un lenguaje de programación general de propósito regular, es posible hacerlo, pero tienes que hacerlo manualmente. Esto significa que la persona que lo hace tiene que ser un ingeniero de software profesional. Un científico de supply chain no va a realizar estas operaciones de bajo nivel con los recursos informáticos fundamentales de tu plataforma. Esto tiene que ser diseñado a nivel del propio lenguaje de programación.
Ahora, hablemos de la programación probabilística. En la segunda conferencia donde presenté la visión para la Supply Chain Quantitativa, mi primer requisito fue que necesitamos analizar todos los futuros posibles. La respuesta técnica a este requisito es el pronóstico probabilístico. Quieres lidiar con futuros donde tienes probabilidades. Todos los futuros son posibles, pero no todos son igualmente probables. Necesitas tener un álgebra donde puedas hacer cálculos con incertidumbre. Una de mis grandes críticas a Excel es que es extremadamente difícil representar la incertidumbre en una hoja de cálculo, independientemente de si es Excel o cualquier otra versión basada en la nube más moderna. En una hoja de cálculo, es muy difícil representar la incertidumbre porque necesitas algo mejor que números.
En este pequeño fragmento, estoy ilustrando el álgebra de las variables aleatorias, que es una característica nativa de Envision. En la línea uno, estoy generando una distribución de Poisson que es discreta, con una media de 2, y la coloco en la variable X. Luego, hago lo mismo para otra distribución de Poisson, Y. Luego, calculo Z como la multiplicación de X por Y. Esta operación, la multiplicación de variables aleatorias, puede parecer muy extraña. ¿Por qué necesitas este tipo de cosas desde una perspectiva de la supply chain? Permíteme darte un ejemplo.
Digamos que estás en el mercado de accesorios automotrices y estás vendiendo pastillas de freno. Las personas no compran pastillas de freno por unidad; compran dos o cuatro. Entonces, la pregunta es, si quieres hacer un pronóstico, es posible que desees pronosticar las probabilidades de que los clientes aparezcan para comprar un cierto tipo de pastillas de freno. Esa va a ser tu primera variable aleatoria que te da la probabilidad de observar cero unidades de demanda, una unidad de demanda, dos, tres, cuatro, etc. para las pastillas de freno. Luego tendrás otra distribución de probabilidad que representa si las personas van a comprar dos o cuatro pastillas de freno. Tal vez sea 50-50, o tal vez sea 10 por ciento comprando dos y 90 por ciento comprando cuatro. La cosa es que tienes estos dos ángulos, y si quieres saber el consumo total real de pastillas de freno, quieres multiplicar la probabilidad de que un cliente aparezca para esta pastilla de freno y luego la distribución de probabilidad de comprar dos o cuatro. Por lo tanto, necesitas tener esta multiplicación de estas dos cantidades inciertas.
Aquí, estoy asumiendo que las dos variables aleatorias son independientes. Por cierto, esta multiplicación de variables aleatorias se conoce en matemáticas como una convolución discreta. Puedes ver en la captura de pantalla el panel de control generado por Envision. En las primeras tres líneas, estoy haciendo este cálculo de álgebra aleatoria, y luego en las líneas cuatro, cinco y seis, estoy mostrando esas cosas en la página web, en el panel de control generado por el script. Estoy trazando A1, B2, por ejemplo, al igual que en una cuadrícula de Excel. Los paneles de control de Lokad están organizados de manera similar a las cuadrículas de Excel, con posiciones que tienen columnas B, C, etc., y filas 1, 2, 3, 4, 5.
Puedes ver que la convolución discreta, Z, tiene este patrón muy extraño y lleno de picos que en realidad se encuentra muy comúnmente en las supply chains cuando las personas pueden comprar paquetes o múltiplos. En este tipo de situaciones, generalmente es mejor descomponer las fuentes de los eventos multiplicativos asociados con el lote o el paquete. Necesitas tener un lenguaje de programación que tenga estas capacidades disponibles al alcance de tu mano, como ciudadanos de primera clase. Eso es exactamente de lo que se trata la programación probabilística, y así es como lo implementamos en Envision.
Ahora, hablemos de la programación diferenciable. Debo poner una advertencia aquí: no espero que la audiencia realmente entienda lo que está sucediendo, y me disculpo por eso. No es que les falte inteligencia; es solo que este tema merece una serie completa de conferencias. De hecho, si miras el plan para las próximas conferencias, hay una serie completa dedicada a la programación diferenciable. Voy a ir muy rápido y va a ser bastante críptico, así que me disculpo de antemano.
Procedamos con el problema de la cadena de suministro de interés aquí, que es la canibalización y la sustitución. Estos problemas son muy interesantes y probablemente son donde la previsión de series de tiempo que es omnipresente, falla de la manera más brutal. ¿Por qué? Porque con frecuencia, los clientes o prospectos vienen a mí y preguntan si podemos hacer, por ejemplo, pronósticos a 13 semanas para ciertos artículos como mochilas. Yo diría que sí, podemos, pero obviamente, si tomamos una mochila y queremos pronosticar la demanda para este producto, depende en gran medida de lo que estés haciendo con tus otras mochilas. Si solo tienes una mochila, entonces tal vez vas a concentrar toda la demanda de mochilas en este producto. Si introduces 10 variantes diferentes, obviamente habrá mucha canibalización. No vas a multiplicar la cantidad total de ventas por un factor de 10 solo porque hayas multiplicado el número de referencias por 10. Así que obviamente, tienes canibalización y sustitución en marcha. Estos fenómenos son frecuentes en las cadenas de suministro.
¿Cómo se analiza la canibalización o la sustitución? La forma en que lo estamos haciendo en Lokad, y no pretendo que sea la única forma, pero ciertamente es una forma que funciona, es típicamente mirando el gráfico que conecta a los clientes y los productos. ¿Por qué es eso? Porque la canibalización ocurre cuando los productos compiten entre sí por los mismos clientes. La canibalización es literalmente el reflejo de que tienes un cliente con una necesidad, pero tienen preferencias y van a elegir un producto entre el conjunto de productos que se ajustan a su afinidad, y eligen solo uno. Esa es la esencia de la canibalización.
Si quieres analizar eso, necesitas analizar no la serie de tiempo de las ventas, porque en primer lugar no capturas esta información. Quieres analizar el gráfico que conecta las transacciones históricas entre los clientes y los productos. Resulta que en la mayoría de los negocios, estos datos están fácilmente disponibles. Para el comercio electrónico, eso es un hecho. Cada unidad que vendes, conoces al cliente. En B2B, es lo mismo. Incluso en B2C en el comercio minorista, la mayoría de las veces, las cadenas minoristas tienen programas de lealtad donde conocen un porcentaje de dos dígitos de los clientes que se presentan con sus tarjetas, por lo que sabes quién está comprando qué. No para el 100% del tráfico, pero no necesitas eso. Si tienes el 10% o más de tus transacciones históricas donde conoces el par de clientes y productos, es suficiente para este tipo de análisis.
En este fragmento relativamente pequeño, voy a detallar un análisis de afinidad entre clientes y productos. Ese es literalmente el paso fundamental que debes tomar para hacer cualquier tipo de análisis de canibalización. Echemos un vistazo a lo que está sucediendo en este código.
Desde las líneas uno a cinco, esto es muy mundano; solo estoy leyendo un archivo plano que contiene un historial de transacciones. Solo estoy leyendo un archivo CSV que tiene cuatro columnas: fecha, producto, cliente y cantidad. Algo muy básico. Ni siquiera estoy usando todas esas columnas, pero solo para hacer el ejemplo un poco más concreto. En el historial de transacciones, asumo que los clientes son conocidos para todas esas transacciones. Entonces, es muy mundano; solo estoy leyendo datos de una tabla.
Luego, en las líneas siete y ocho, simplemente estoy creando la tabla de productos y la tabla de clientes. En una configuración de producción real, normalmente no crearía esas tablas; las leería de otros archivos planos en otro lugar. Quería mantener el ejemplo muy simple, así que solo estoy extrayendo una tabla de productos de los productos que observé en el historial de transacciones, y hago lo mismo para los clientes. Como ves, es solo un truco para mantenerlo muy simple.
Ahora, las líneas 10, 11 y 12 involucran espacios latinos, y esto se volverá un poco más oscuro. Primero, en la línea 10, estoy creando una tabla con 64 líneas. La tabla no contiene nada; solo está definida por el hecho de que tiene 64 líneas, y ya está. Entonces esto es como un marcador de posición, una tabla trivial con muchas líneas y sin columnas. No es tan útil así. Luego, “P” es básicamente un producto cartesiano, una operación matemática con todas las parejas. Es una tabla donde tienes una línea por cada línea en los productos y cada línea en la tabla “L”. Entonces, esta tabla “P” tiene 64 líneas más que la tabla de productos, y estoy haciendo lo mismo para los clientes. Solo estoy inflando esas tablas a través de esta dimensión adicional, que es esta tabla “L”.
Esto será mi soporte para mis espacios latinos, que es exactamente lo que voy a aprender. Lo que quiero aprender es, para cada producto, un espacio latino que va a ser un vector de 64 valores, y para cada cliente, un espacio latino de 64 valores también. Si quiero conocer la afinidad entre un cliente y un producto, solo quiero poder hacer el producto punto entre los dos. El producto punto es simplemente la multiplicación punto a punto de todos los términos de esos dos vectores, y luego haces la suma. Puede sonar muy técnico, pero es solo multiplicación punto a punto más suma, eso es el producto punto.
Estos espacios latinos son solo jerga elegante para crear un espacio con parámetros un poco inventados, donde solo quiero aprender. Toda la magia de la programación diferenciable ocurre en solo cinco líneas, desde las líneas 14 hasta la 18. Tengo una palabra clave, “autodiff”, y “transactions”, que dice que esta es una tabla de interés, una tabla de observaciones. Voy a procesar esta tabla línea por línea para hacer mi proceso de aprendizaje. En este bloque, estoy declarando un conjunto de parámetros. Los parámetros son las cosas que quieres aprender, como números, pero aún no conoces los valores. Esas cosas solo se inicializarán al azar, con números aleatorios.
Introduzco “X”, “X*” y “Y”. No voy a entrar en detalles sobre lo que hace exactamente “X*”, tal vez en las preguntas. Estoy devolviendo una expresión que es mi función de pérdida, y eso es la suma. La idea de filtrado colaborativo o descomposición de matrices es simplemente que quieres aprender espacios latinos que se ajusten a todos tus bordes en tu gráfico bipartito. Sé que suena un poco técnico, pero lo que estamos haciendo es literalmente muy simple, en términos de supply chain. Estamos aprendiendo la afinidad entre productos y clientes.
Sé que parece probablemente muy opaco, pero quédate conmigo y habrá más conferencias donde te daré una introducción más reflexiva sobre eso. Todo el proceso se hace en cinco líneas, y eso es completamente notable. Cuando digo cinco líneas, no estoy engañando al decir: “Mira, son solo cinco líneas, pero en realidad estoy haciendo una llamada a una biblioteca de terceros de una complejidad gigantesca donde estoy enterrando toda la inteligencia”. No, no, no. Aquí, en este ejemplo, no hay literalmente magia de aprendizaje automático además de las dos palabras clave “autodiff” y “params”. “Autodiff” se utiliza para definir un bloque donde se llevará a cabo la programación diferenciable, y por cierto, este es un bloque donde puedo programar cualquier cosa, así que literalmente puedo inyectar nuestro programa. Luego, tengo “params” para declarar mis problemas, y eso es todo. Entonces, ves, no hay magia opaca sucediendo; no hay una biblioteca de un millón de líneas en segundo plano haciendo todo el trabajo por ti. Todo lo que necesitas saber está literalmente en esta pantalla, y esa es la diferencia entre un paradigma de programación y una biblioteca. El paradigma de programación te brinda acceso a capacidades aparentemente increíblemente sofisticadas, como realizar análisis de canibalización con solo unas pocas líneas de código, sin recurrir a bibliotecas de terceros masivas que envuelven la complejidad. Trasciende el problema, haciéndolo mucho más simple, para que puedas resolver algo que parece súper complicado en solo unas pocas líneas.
Ahora, unas palabras sobre cómo funciona la programación diferenciable. Hay dos ideas. Una es la diferenciación automática. Para aquellos de ustedes que han tenido el lujo de una formación en ingeniería, han visto dos formas de calcular derivadas. Hay una derivada simbólica, por ejemplo, si tienes x al cuadrado, haces la derivada por x, y te da 2x. Esa es una derivada simbólica. Luego tienes la derivada numérica, así que si tienes una función f(x) que quieres diferenciar, va a ser f’(x) ≈ (f(x + ε) - f(x))/ε. Esa es la derivación numérica. Ambas no son adecuadas para lo que estamos tratando de hacer aquí. La derivación simbólica tiene problemas de complejidad, ya que tu derivada puede ser un programa mucho más complejo que el programa original. La derivación numérica es numéricamente inestable, por lo que tendrás muchos problemas con la estabilidad numérica.
La diferenciación automática es una idea fantástica que data de los años 70 y redescubierta por el mundo en general en la última década. Es la idea de que puedes calcular la derivada de un programa de computadora arbitrario, lo cual es asombroso. Aún más asombroso, el programa que es la derivada tiene la misma complejidad computacional que el programa original, lo cual es impresionante. La programación diferenciable es simplemente una combinación de diferenciación automática y parámetros que quieres aprender.
Entonces, ¿cómo aprendes? Cuando tienes la derivada, significa que puedes propagar gradientes y, con el descenso de gradiente estocástico, puedes hacer pequeños ajustes a los valores de los parámetros. Al ajustar esos parámetros, de forma incremental, a través de muchas iteraciones de descenso de gradiente estocástico, convergerás a parámetros que tienen sentido y logran lo que quieres aprender u optimizar.
La programación diferenciable se puede utilizar para problemas de aprendizaje, como el que estoy ilustrando, donde quiero aprender la afinidad entre mis clientes y mis productos. También se puede utilizar para problemas de optimización numérica, como optimizar cosas bajo restricciones, y es muy escalable como paradigma. Como puedes ver, este aspecto se ha convertido en un ciudadano de primera clase en Envision. Por cierto, todavía hay algunas cosas que están en progreso en términos de la sintaxis de Envision, así que no esperes exactamente esas cosas todavía; todavía estamos refinando algunos aspectos. Pero la esencia está ahí. No voy a discutir los detalles de las pocas cosas que aún están evolucionando.
Ahora pasemos a otro problema relevante para la preparación de producción de tu configuración. Típicamente, en la optimización de la cadena de suministro, te enfrentas a Heisenbugs. ¿Qué es un Heisenbug? Es un tipo frustrante de error donde se produce una optimización y se obtienen resultados incorrectos. Por ejemplo, tenías un cálculo por lotes para el reabastecimiento de inventario durante la noche, y por la mañana descubres que algunos de esos resultados eran absurdos, causando errores costosos. No quieres que el problema vuelva a ocurrir, así que vuelves a ejecutar tu proceso. Sin embargo, cuando vuelves a ejecutar el proceso, el problema desaparece. No puedes reproducir el problema y el Heisenbug no se manifiesta.
Puede sonar como un caso extraño, pero en los primeros años de Lokad, nos enfrentamos a estos problemas repetidamente. He visto muchas iniciativas de cadena de suministro, especialmente del tipo de ciencia de datos, fracasar debido a Heisenbugs no resueltos. Tenían errores que ocurrían en producción, intentaron reproducir los problemas localmente pero no pudieron, por lo que los problemas nunca se solucionaron. Después de un par de meses en modo de pánico, generalmente se cerraba silenciosamente todo el proyecto y la gente volvía a usar hojas de cálculo de Excel.
Si quieres lograr una replicabilidad completa de tu lógica, necesitas versionar el código y los datos. La mayoría de las personas en la audiencia que son ingenieros de software o científicos de datos pueden estar familiarizados con la idea de versionar el código. Sin embargo, también quieres versionar todos los datos para que cuando tu programa se ejecute, sepas exactamente qué versión del código y los datos se está utilizando. Es posible que no puedas replicar el problema al día siguiente porque los datos han cambiado debido a nuevas transacciones u otros factores, por lo que las condiciones que desencadenaron el error en primer lugar ya no están presentes.
Quieres asegurarte de que tu entorno de programación pueda replicar exactamente la lógica y los datos tal como estaban en producción en un momento específico. Esto requiere una versión completa de todo. Nuevamente, el lenguaje de programación y la pila de programación deben cooperar para hacer esto posible. Se puede lograr sin que el paradigma de programación sea un ciudadano de primera clase en tu pila, pero entonces el científico de la cadena de suministro debe tener mucho cuidado con todas las cosas que hace y la forma en que programa. De lo contrario, no podrá replicar sus resultados. Esto pone una presión inmensa sobre los hombros de los científicos de la cadena de suministro, que ya están bajo una presión significativa de la cadena de suministro en sí. No quieres que estos profesionales tengan que lidiar con complejidad accidental, como no poder replicar sus propios resultados. En Lokad, llamamos a esto una “máquina del tiempo” donde puedes replicar todo en cualquier punto del pasado.
Ten cuidado, no se trata solo de replicar lo que sucedió anoche. A veces, descubres un error mucho después del hecho. Por ejemplo, si realizas un pedido a un proveedor que tiene un tiempo de entrega de tres meses, es posible que descubras tres meses después que el pedido era absurdo. Necesitas retroceder tres meses en el tiempo hasta el punto en el que generaste este pedido de compra falso para averiguar cuál fue el problema. No se trata de versionar solo las últimas horas de trabajo; se trata literalmente de tener un historial completo del último año de ejecución.
Otra preocupación es el aumento de ransomware y los ciberataques a las cadenas de suministro. Estos ataques son muy disruptivos y pueden ser muy costosos. Al implementar soluciones impulsadas por software, debes considerar si estás volviendo a tu empresa y cadena de suministro más vulnerable a ciberataques y riesgos. Desde esta perspectiva, Excel y Python no son ideales. Estos componentes son programables, lo que significa que pueden tener numerosas vulnerabilidades de seguridad.
Si tienes un equipo de científicos de datos o científicos de supply chain que se ocupan de problemas de la cadena de suministro, no pueden permitirse el proceso de revisión por pares cuidadoso e iterativo del código que es común en la industria del software. Si un arancel cambia de la noche a la mañana o un almacén se inunda, necesitas una respuesta rápida. No puedes pasar semanas produciendo especificaciones de código, revisiones, y demás. El problema es que estás dando capacidades de programación a personas que, por defecto, tienen el potencial de causar daño a la empresa accidentalmente. Puede ser aún peor si hay un empleado malintencionado, pero incluso dejando eso de lado, aún tienes el problema de que alguien exponga accidentalmente una parte interna de los sistemas de TI. Recuerda, los sistemas de optimización de la cadena de suministro, por definición, tienen acceso a una gran cantidad de datos en toda la empresa. Estos datos no solo son un activo sino también una responsabilidad.
Lo que quieres es un paradigma de programación que promueva la programación segura. Quieres un lenguaje de programación en el que haya clases enteras de cosas que no puedes hacer. Por ejemplo, ¿por qué deberías tener un lenguaje de programación que pueda hacer llamadas al sistema con fines de optimización de la cadena de suministro? Python puede hacer llamadas al sistema, al igual que Excel. Pero, ¿por qué querrías un sistema programable con tales capacidades en primer lugar? Es como comprar un arma para dispararte en el pie.
Quieres algo donde clases enteras o características estén ausentes porque no las necesitas para la optimización de la cadena de suministro. Si estas características están presentes, se convierten en una gran responsabilidad. Si introduces capacidades programables sin las herramientas que hacen cumplir la programación segura por diseño, aumentas el riesgo de ciberataques y ransomware, empeorando las cosas.
Por supuesto, siempre es posible compensar duplicando el tamaño del equipo de ciberseguridad, pero eso es muy costoso y no es ideal cuando se enfrentan situaciones urgentes de la cadena de suministro. Necesitas actuar rápidamente y de manera segura, sin tiempo para los procesos habituales, revisiones y aprobaciones. También quieres una programación segura que elimine problemas mundanos como excepciones de referencia nula, errores de falta de memoria, bucles fuera de rango y efectos secundarios.
En conclusión, las herramientas importan. Hay un dicho: “No lleves una espada a un tiroteo”. Necesitas las herramientas adecuadas y los paradigmas de programación, no solo los que aprendiste en la universidad. Necesitas algo profesional y de calidad de producción para satisfacer las necesidades de tu cadena de suministro. Si bien es posible que puedas lograr algunos resultados con herramientas mediocres, no será genial. Un músico fantástico puede hacer música con solo una cuchara, pero con un instrumento adecuado, puede hacerlo mucho mejor.
Ahora, procedamos con las preguntas. Ten en cuenta que hay un retraso de aproximadamente 20 segundos, por lo que hay cierta latencia en la transmisión entre el video que estás viendo y yo leyendo tus preguntas.
Pregunta: ¿Qué hay de la programación dinámica en términos de investigación de operaciones?
La programación dinámica, a pesar del nombre, no es un paradigma de programación. Es más una técnica algorítmica. La idea es que si quieres realizar una tarea algorítmica o resolver un determinado problema, repetirás la misma suboperación con mucha frecuencia. La programación dinámica es un caso específico del intercambio espacio-tiempo que mencioné anteriormente, donde inviertes un poco más en memoria para ahorrar tiempo en el lado del cálculo. Fue una de las primeras técnicas algorítmicas, que se remonta a los años 60 y 70. Es buena, pero el nombre es un poco desafortunado porque no hay nada realmente dinámico al respecto, y no se trata realmente de programación. Es más sobre la concepción de algoritmos. Entonces, para mí, a pesar del nombre, no califica como un paradigma de programación; es más una técnica algorítmica específica.
Pregunta: Johannes, ¿podrías proporcionar amablemente algunos libros de referencia que todo buen ingeniero de cadena de suministro debería tener? Desafortunadamente, soy nuevo en el campo y mi enfoque actual es la ciencia de datos y la ingeniería de sistemas.
Tengo una opinión muy mixta sobre la literatura existente. En mi primera conferencia, presenté dos libros que considero el pináculo de los estudios académicos sobre la cadena de suministro. Si quieres leer dos libros, puedes leer esos libros. Sin embargo, tengo un problema constante con los libros que he leído hasta ahora. Básicamente, tienes personas que presentan colecciones de recetas numéricas de juguete para cadenas de suministro idealizadas, y creo que estos libros no abordan la cadena de suministro desde el ángulo correcto y se pierden por completo el punto de que es un problema malicioso. Hay una amplia bibliografía muy técnica, con ecuaciones, algoritmos, teoremas y pruebas, pero creo que se pierde completamente el punto.
Luego, tienes otro estilo de libros de gestión de la cadena de suministro, que son más estilo consultor. Puedes reconocer fácilmente estos libros porque usan analogías deportivas cada dos páginas. Estos libros tienen todo tipo de diagramas simplistas, como variantes 2x2 de diagramas DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades), que considero formas de razonamiento de baja calidad. El problema con estos libros es que tienden a entender mejor que la cadena de suministro es una tarea maliciosa. Entienden mucho mejor que es un juego jugado por personas, donde pueden suceder todo tipo de cosas extrañas, y puedes ser inteligente en términos de formas. Les doy crédito por eso. El problema con esos libros, que suelen ser escritos por consultores o profesores de escuelas de administración, es que no son muy ejecutables. El mensaje se reduce a “ser un mejor líder”, “ser más inteligente”, “tener más energía”, y para mí, esto no es ejecutable. No te da elementos que puedas convertir en algo altamente valioso, como puede hacer el software.
Entonces, volvamos a la primera conferencia: lee los dos libros si quieres, pero no estoy seguro de que sea tiempo bien invertido. Es bueno saber lo que la gente ha escrito. En el lado de la literatura de consultoría, mi favorito es probablemente el trabajo de Katana, que no mencioné en la primera conferencia. No todo es malo; algunas personas tienen más talento, incluso si son más consultores. Puedes consultar el trabajo de Katana; tiene un libro sobre cadenas de suministro dinámicas. Enumeraré el libro en las referencias.
Pregunta: ¿Cómo utilizas la paralelización al tratar decisiones de canibalización o surtido, donde el problema no es fácilmente paralelizable?
¿Por qué no es fácilmente paralelizable? El descenso de gradiente estocástico es bastante trivial de paralelizar. Tienes pasos de gradiente estocástico que se pueden tomar en órdenes aleatorios, y puedes tener múltiples pasos al mismo tiempo. Entonces, creo que cualquier cosa impulsada por el descenso de gradiente estocástico es bastante trivial de paralelizar.
Al tratar la canibalización, lo que es más difícil es lidiar con otro tipo de paralelización, que es lo que viene primero. Si pongo este producto primero, luego hago un pronóstico, pero luego tomo otro producto, modifica el panorama. La respuesta es que quieres tener una forma de abordar todo el panorama frontalmente. No dices: “Primero, introduzco este producto y hago el pronóstico; introduzco otro producto y luego vuelvo a hacer el pronóstico, modificando el primero”. Simplemente lo haces frontalmente, todas esas cosas a la vez, al mismo tiempo. Necesitas más paradigmas de programación. Los paradigmas de programación que he presentado hoy pueden ayudar mucho en eso.
En cuanto a las decisiones de surtido, este tipo de problemas no presentan grandes dificultades para la paralelización. Lo mismo se aplica si tienes una red minorista mundial y quieres optimizar el surtido para todas tus tiendas. Puedes tener cálculos que ocurren para todas las tiendas en paralelo. No quieres hacerlo en secuencia, donde optimizas el surtido para una tienda y luego pasas a la siguiente tienda. Esa es la forma incorrecta de hacerlo, pero puedes optimizar la red en paralelo, propagar toda la información y luego repetir. Hay todo tipo de técnicas, y las herramientas pueden ayudarte mucho a hacerlo de manera mucho más fácil.
Pregunta: ¿Estás utilizando un enfoque de base de datos gráfica?
No, no en el sentido técnico y canónico. Hay muchas bases de datos gráficas en el mercado que son de gran interés. Lo que estamos utilizando internamente en Lokad es una integración vertical completa a través de una pila de compiladores unificada y monolítica para eliminar por completo todos los elementos tradicionales que encontrarías en una pila clásica. Así es como logramos un rendimiento muy bueno, en términos de rendimiento informático, muy cerca del metal. No porque seamos programadores fantásticamente inteligentes, sino simplemente porque hemos eliminado prácticamente todas las capas que tradicionalmente existen. Lokad no utiliza literalmente ninguna base de datos en absoluto. Tenemos un compilador que se encarga de todo, hasta la organización de las estructuras de datos para la persistencia. Es un poco extraño, pero es mucho más eficiente hacerlo de esa manera, y de esta manera, juegas mucho mejor con el hecho de que compilas un script hacia una flota de máquinas en la nube. Tu plataforma objetivo, en términos de hardware, no es una máquina; es una flota de máquinas.
Pregunta: ¿Cuál es tu opinión sobre Power BI, que también ejecuta códigos Python y algoritmos relacionados como el descenso de gradiente, greedy, etc.?
El problema que tengo con todo lo relacionado con la inteligencia de negocios, siendo Power BI uno de ellos, es que tiene un paradigma que considero inadecuado para la cadena de suministro. Ves todos los problemas como un hipercubo, donde tienes dimensiones que solo cortas y cortas. En el núcleo, tienes un problema de expresividad, que es muy limitante. Cuando terminas usando Power BI con Python en el medio, necesitas Python porque la expresividad relacionada con el hipercubo es muy pobre. Para recuperar la expresividad, agregas Python en el medio. Sin embargo, recuerda lo que dije en la pregunta anterior sobre esas capas: la maldición del software empresarial moderno es que tienes demasiadas capas. Cada capa que agregas va a introducir ineficiencias y errores. Si usas Power BI más Python, vas a tener demasiadas capas. Entonces, tienes Power BI que se encuentra en la parte superior de otros sistemas, lo que significa que ya tienes múltiples sistemas antes de Power BI. Luego tienes Power BI en la parte superior, y encima de Power BI, tienes Python. Pero ¿Python actúa por sí solo? No, es probable que uses bibliotecas de Python, como Pandas o NumPy. Entonces, tienes capas en Python que se van a acumular, y terminas con docenas de capas. Puedes tener errores en cualquiera de esas capas, por lo que la situación va a ser bastante pesadillesca.
No creo en esas soluciones donde terminas teniendo una gran cantidad de pilas. Hay una broma de que en C++, siempre puedes resolver cualquier problema agregando una capa más de indirección, incluido el problema de tener demasiadas capas de indirección. Obviamente, esto es un poco absurdo como afirmación, pero estoy en profundo desacuerdo con el enfoque en el que las personas tienen un producto con un diseño central inadecuado, y en lugar de abordar el problema frontalmente, terminan agregando cosas encima mientras los cimientos son inestables. Esta no es la forma de hacerlo, y vas a tener una productividad deficiente, batallas continuas con errores que nunca vas a resolver, y luego, en términos de mantenibilidad, es simplemente una receta para una pesadilla.
Pregunta: ¿Cómo se pueden integrar los resultados de un análisis de filtrado colaborativo en el algoritmo de predicción de demanda para cada producto, como mochilas, por ejemplo?
Lo siento, pero abordaré este tema en la próxima conferencia. La respuesta corta es que no quieres integrarlo en un algoritmo de predicción existente. Quieres tener algo que esté mucho más integrado de forma nativa. No haces eso y luego vuelves a tus viejas formas de hacer pronósticos; en cambio, simplemente descartas la forma antigua de hacer el pronóstico y haces algo radicalmente diferente que aproveche eso. Pero discutiré esto en una conferencia posterior. Sería demasiado para hoy.
Supongo que esto es todo para esta conferencia. Muchas gracias a todos por asistir. La próxima conferencia será el miércoles 6 de enero, a la misma hora, el mismo día de la semana. Tomaré unas vacaciones de Navidad, así que les deseo a todos una feliz Navidad y un feliz Año Nuevo. Continuaremos nuestra serie de conferencias el próximo año. Muchas gracias.
