00:00:00 La historia de la fundación de Lokad y los primeros años
00:02:31 Conceptos erróneos sobre la optimización de supply chain
00:04:31 Las teorías existentes de supply chain no funcionaron
00:06:32 La paradoja de los fallos de forecast
00:08:33 Cómo “forecasting nothing” venció a la competencia
00:10:25 El desafío de rechazar las ideas establecidas
00:12:00 Pivotando hacia forecast probabilístico
00:14:07 La importancia de escenarios extremos de demanda
00:16:32 La complejidad de la integración de datos empresariales
00:20:55 Por qué los modelos de supply chain en papel fallan
00:27:30 Problemas de ingeniería en la adopción de IA empresarial
00:35:00 El impacto de COVID-19 en supply chain
00:42:49 Los LLMs son basados en texto, no matemáticos
00:50:25 La evolución paralela de la industria financiera
01:09:00 Preguntas y respuestas y comentarios finales
Resumen
Joannes Vermorel, CEO y Fundador de Lokad, impartió una conferencia en francés, compartiendo su trayectoria en gestión de supply chain. Vermorel relató la fundación de Lokad tras graduarse de École Normale Supérieure y cambiar el enfoque de la bioinformática hacia los desafíos de supply chain. Discutió el desarrollo de Envision, el lenguaje de programación de Lokad, y la evolución de la empresa desde 2007. Vermorel criticó las teorías tradicionales de supply chain, comparándolas con la astrología, y enfatizó la importancia de desafiar el consenso. Destacó el éxito de Lokad con métodos probabilísticos y el impacto de COVID-19 en la robotización de supply chain. Vermorel predijo la obsolescencia de los roles tradicionales y animó a los estudiantes a impulsar la revolución de la industria.
Resumen Extendido
En una conferencia impartida a estudiantes en francés, Joannes Vermorel, CEO y Fundador de Lokad, compartió su trayectoria y sus ideas sobre el mundo de la gestión de supply chain y la evolución de su empresa. Vermorel comenzó presentándose y relatando los orígenes de Lokad, una empresa que fundó justo después de graduarse de École Normale Supérieure. Inicialmente, Vermorel intentó realizar una tesis en bioinformática, pero pronto se dio cuenta de que el campo ya estaba saturado de personas talentosas. Por casualidad, se topó con los desafíos de la gestión de supply chain, que se convirtieron en su nuevo enfoque.
Vermorel expresó su sorpresa y deleite al ver a estudiantes de Centrale utilizando Envision, un lenguaje de programación que creó para la optimización de supply chain. Relató el desarrollo de Envision, señalando que el primer compilador que escribió fue rápidamente reemplazado por una versión superior creada por Victor Nicolet, CTO de Lokad. Desde entonces, Envision ha evolucionado significativamente, y la empresa está a punto de lanzar la versión 6.
El camino de Lokad comenzó en 2007, con la empresa fundada oficialmente en 2008. Sin embargo, Envision no se presentó hasta 2013, cinco años después de la existencia de Lokad. Vermorel explicó que la decisión de crear un nuevo lenguaje de programación surgió tras agotar todas las demás alternativas. Inicialmente, creía que el supply chain era un campo bien establecido, con décadas de literatura y numerosos competidores como SAP, Oracle, IBM y Microsoft. Pensó que la clave del éxito sería reempaquetar las teorías existentes de supply chain en aplicaciones web, aprovechando el cambio de las aplicaciones cliente-servidor a soluciones basadas en computación en la nube.
A pesar de su confianza inicial, Vermorel pronto descubrió que las teorías y modelos establecidos no funcionaron como se esperaba. Relató una experiencia particularmente absurda en 2011, en la que Lokad ganó un benchmark al presentar cero forecast, superando a la competencia en un 20% en precisión. Esta experiencia llevó a Vermorel a cuestionar la validez de las teorías tradicionales de supply chain, comparándolas con la astrología en lugar de la astronomía.
Vermorel enfatizó la importancia de desafiar el consenso en la ciencia, señalando que la historia está llena de ejemplos de creencias ampliamente aceptadas pero que resultaron ser incorrectas. Concluyó que, si bien el supply chain en sí es un campo legítimo, las teorías clásicas que lo sustentan eran defectuosas. Esta realización lo impulsó a explorar enfoques alternativos, como los forecast sesgados y las predicciones de cuantiles, que resultaron ser más efectivos.
El enfoque de Lokad evolucionó para adoptar métodos probabilísticos y programáticos, alejándose de los modelos tradicionales que no lograban abordar las complejidades de los problemas reales de supply chain. Vermorel destacó la importancia de contar con un lenguaje de programación robusto hecho a la medida para estos desafíos, criticando el uso de lenguajes de propósito general como Python, que a menudo conducían a iniciativas fallidas debido a diversos problemas técnicos.
La conferencia también abordó el impacto de la pandemia de COVID-19, que aceleró la robotización de supply chain. Vermorel señaló que las soluciones de Lokad demostraron ser efectivas a gran escala, gestionando existencias por valor de miles de millones de euros con una mínima intervención humana. Este cambio refleja la transición en la industria financiera, donde el trading se ha vuelto predominantemente algorítmico.
Vermorel habló sobre el futuro de la gestión de supply chain, prediciendo que los roles tradicionales de los encargados de inventario y demand planners se volverían obsoletos a medida que más empresas adopten procesos automatizados de decision-making. Animó a los estudiantes a ser proactivos en impulsar esta revolución en lugar de limitarse a observarla.
En respuesta a las preguntas de los estudiantes, Vermorel explicó que las empresas con un fuerte enfoque tecnológico podrían internalizar las soluciones de Lokad, mientras que otras probablemente continuarían tercerizando estos servicios. También abordó las limitaciones de los grandes modelos de lenguaje (LLMs) como ChatGPT, señalando su falta de capacidad de aprendizaje y memoria.
Vermorel concluyó reflexionando sobre la irracionalidad de los mercados y la persistencia de proyectos fallidos en la industria de supply chain. Compartió anécdotas de competidores que recaudaron fondos sustanciales de manera reiterada a pesar de fracasos anteriores, destacando la naturaleza caótica del mercado. A pesar de estos desafíos, Vermorel expresó orgullo por los logros de Lokad y el éxito inesperado de Envision entre estudiantes de instituciones prestigiosas como Centrale. Invitó a los estudiantes a considerar unirse a Lokad, enfatizando los esfuerzos continuos de contratación de la empresa.
Transcripción Completa
El discurso original en francés fue traducido al inglés.
Joannes Vermorel: Permítanme presentarme: soy Joannes Vermorel, fundador de Lokad. Creé la empresa cuando terminé mis estudios. Estaba en la École Normale Supérieure, comencé un doctorado en bioinformática, pero al final, tanta gente estaba haciendo cosas interesantes en bioinformática que probablemente no me necesitaban. Y por casualidad, me topé con estos problemas de supply chain. Me alegra mucho ver que han estado utilizando Envision hoy. Es algo muy especial para mí encontrarme frente a estudiantes de Centrale hablando sobre este lenguaje. Es algo que nunca habría imaginado cuando creé Envision, hace aproximadamente doce años.
Escribí el primer compilador de Envision, luego Victor Nicolet—CTO de Lokad—lo descartó y rápidamente escribió el segundo compilador, que fue mucho mejor. Y ahora, básicamente están usando la versión 5, mientras que la versión 6 está a punto de lanzarse. El lenguaje ha evolucionado mucho. Pero lo que han trabajado—la parte que han visto—no era en absoluto donde comenzó Lokad. De hecho, llegó bastante tarde. Lokad es un proyecto que comenzó en 2007 y se constituyó en 2008, mientras que Envision es de alrededor de 2013. Así que cuando llegó Envision, la empresa ya tenía unos cinco años.
La idea de crear un lenguaje surgió después de haber agotado todas las demás alternativas; no fue el plan del fundador visionario desde el principio, simplemente todo lo que habíamos intentado había fallado.
Para darles una idea de lo sorprendente que es el supply chain: cuando lancé Lokad en 2008, mi perspectiva era que el supply chain era un campo bien establecido. Después de todo, existen 60 o 70 años de literatura al respecto, literalmente millones de artículos. Si buscas “supply chain management” en Amazon, obtendrás—verifiqué—alrededor de 10,000 libros disponibles actualmente sobre el tema. A lo largo de las décadas, se han publicado muchos más, pero esos 10,000 son los que aún están a la venta. Es un campo enormemente documentado.
Cuando comencé, vi grandes competidores con grandes nombres: SAP, Oracle, IBM, incluso Microsoft—jugadores importantes en supply chain. Si sumas los ingresos totales de tus competidores, es medio billón de dólares. Eso es significativo. Mi intuición original—completamente equivocada, al parecer—fue que podía tomar las teorías establecidas de supply chain y simplemente reempaquetarlas en una aplicación web. Era 2008, y todo el enterprise software se estaba desplazando de las llamadas aplicaciones “thick client”, que instalas en tu PC, a “thin client”, es decir, aplicaciones web. Así que existía la oportunidad de reconstruir el software de supply chain como una aplicación web, posiblemente con hosting en la nube. Lokad se trasladó a la nube muy temprano. Eso podría darnos una ventaja sobre las grandes compañías que aún utilizan sistemas basados en clientes más antiguos y pesados. Y dado que existen literalmente libros enteros que explican cómo optimizar supply chain—como el manual del MIT, el manual de Stanford, el manual de Caltech—los leí, todos esos volúmenes de 1,000 páginas escritos por dos o tres profesores con todas las ecuaciones.
Luego programé esos enfoques—y nada funcionó. Curiosamente, eso no impidió que Lokad creciera o tuviera clientes. Se podría pensar que para ganar dinero como startup necesitas un producto que realmente funcione, pero en el enterprise software, puedes vender algo que no funcione en absoluto y aún así encontrar clientes. Puede sonar extraño, pero así es. La realidad es que, si hay un gran problema que una empresa quiere resolver, existe un presupuesto para intentarlo. Ese presupuesto puede no ser enorme—especialmente si tu producto realmente no funciona—pero para una startup, esas sumas pueden parecer muy grandes. Si un gigante como Carrefour pone 100,000 euros sobre la mesa “solo para ver”, eso no es nada para Carrefour, pero sí es mucho para una pequeña empresa.
Así que, aprovechando esa asimetría, comencé e intenté implementar estas teorías estándar de supply chain: forecast de time-series, safety stock, optimización del nivel de servicio, etc. Nada de ello funcionó; nada en absoluto. Tuvimos discusiones bastante esquizofrénicas con los clientes: decían, “Debes haber programado la fórmula de safety-stock incorrectamente”, así que volvíamos, literalmente tomábamos los valores de las tablas de los libros de texto, volvíamos a verificar los parámetros—y era exactamente como se indicaba. Así que la teoría se implementó correctamente, pero el resultado era un completo sinsentido.
Creo que el colmo del sinsentido se dio en el verano de 2011. Participamos en una gran solicitud de propuestas (RFP) con media docena de proveedores de software, la mitad europeos y la otra mitad estadounidenses. Lokad estaba entre los europeos. El caso, según recuerdo, involucraba a alrededor de diez supermercados, 5,000 SKUs por supermercado, con la necesidad de forecast de algunos días adelante, ya que estos supermercados se reabastecían tal vez dos o tres veces por semana. El cliente utilizó un criterio de error de backtesting en los forecast diarios a nivel de producto para cada tienda—básicamente el error absoluto entre el forecast y lo real. Al final, Lokad ganó ese benchmark—con un 20% de precisión mejor, aplastando absolutamente a la competencia. ¿Mi método secreto? Envié ceros. Cero para todo. Gracias a mi “zero forecast”, también superé a todos los demás en velocidad de cálculo: devolver ceros es extremadamente rápido. Y obtuve un 20% de better forecasting más de precisión que los demás. Aún mejor, si forecast cero demanda, no reabasteces la tienda, por lo que en dos semanas, la tienda queda vacía, lo que coincide con tu forecast al 100%. Fui el rey de las estadísticas.
Obviamente, eso fue un completo sinsentido. Pero si consideras el enfoque recomendado por todos los libros de texto de supply chain y el proceso estándar del cliente, resultó en una total absurdidad. La conclusión a la que llegué fue bastante desconcertante. Teníamos una empresa rentable y en crecimiento, pero me vi obligado a darme cuenta de que quizás simplemente me topé con algún esquema. Puedes empezar algo, ganar dinero, pero es un puro sinsentido. Tal vez al principio eres demasiado inexperto para darte cuenta. Pero una vez que te das cuenta, ¿sigues adelante? Cuando te gradúas y descubres que lo que haces es un sinsentido, ¿continuas? Eso desencadenó una profunda reflexión. ¿Podría ser que el supply chain fuera simplemente astrología—como la adivinación, no la astronomía?
Finalmente, concluí que el supply chain como campo es real, pero que la teoría estándar de supply chain es básicamente astrología. Ese fue el defecto. Es muy difícil aceptar que 70 años de investigación, más de un millón de artículos, miles de profesores, pudieran estar todos equivocados. Imagina la arrogancia intelectual necesaria. Si ves a cuatro doctores diferentes, cada uno diciéndote que tienes el mismo diagnóstico, ¿en qué momento dices que todos están equivocados y tú tienes razón? Pero la ciencia no funciona por consenso. Mil personas pueden estar de acuerdo en algo y, aun así, equivocarse. La historia de la ciencia está llena de ejemplos: un consenso extremadamente amplio sobre ideas que resultaron ser una locura. Algunos que estudian la historia de la ciencia incluso afirman que la mitad de lo que cualquier sociedad cree en un momento dado es incorrecto; lo complicado es saber cuál mitad.
Así que Lokad llegó a esa conclusión a partir del benchmark: la forma convencional era una tontería. Tuvimos que buscar otra cosa. Nuestro gran avance llegó a principios de 2012, persiguiendo forecast sesgados con lo que se conoce como quantile forecasts. En ese momento, tenía clientes que empleaban a 50 personas a tiempo completo solo para eliminar el sesgo. Así que me preguntaron, “¿Por qué diablos querrías un forecast sesgado, si pagamos a la gente para eliminar el sesgo?” Estaban bastante alarmados porque el nuevo método añadía tanto sesgo que nunca podrían eliminarlo manualmente. Pero si lo llamo “quantile forecasting”, suena más científico que “biased forecasting.” Sin embargo, en realidad, un quantile forecast es simplemente un forecast sesgado.
Probamos este enfoque con nuestro primer cliente e-commerce. De la noche a la mañana, pasamos de resultados absurdos—como forecastear cero para todo—a algo mediocre, pero al menos algo sensato. Eso puede no sonar impresionante, pero pasar de una absurdidad total a una mera mediocridad fue un gran avance.
Eso nos llevó a replantear todas las suposiciones de supply chain que se encuentran en los libros de texto—cuestionando cada fundamento, que resultaron ser muy inestables, básicamente incorrectos. El quantile forecasting es simplemente la versión sencilla de eso. Es una herramienta estadística que examina específicamente los extremos. Económicamente, en supply chain, los extremos son donde se pierde dinero: una demanda inesperadamente alta que crea un faltante de stock, una demanda inesperadamente baja que crea sobreinventario, tiempos de lead times inesperadamente largos que arruinan tus planes, etc. Nunca es el centro de la distribución lo que realmente te perjudica; son las colas. Un quantile forecast es una herramienta que se centra en esos extremos. Una versión mejorada es el probabilistic forecasting—que es en lo que has estado trabajando—donde obtienes una distribución de probabilidad completa. En 2012, empezamos con quantile forecasts porque era más simple en términos de matemáticas, estadísticas y computación. Manejar una distribución de probabilidad a lo largo de millones de SKUs es mucho más pesado que generar un único número de forecast por SKU.
Mientras tanto, Envision—que originalmente fue desarrollado para algo completamente distinto, un proyecto interno con nombre en clave “Priceforge” para la fijación de precios—resultó ser perfecto para abordar el nuevo enfoque. Antes de eso, la idea de Lokad era construir software estándar de supply chain con menús, botones y opciones, como es típico en el software empresarial. Pero era un caos desde el punto de vista del editor de software: a medida que añades más funcionalidades, el mapeo de datos desde el entorno del cliente a tus estructuras de datos se convierte en una pesadilla de ingeniería.
¿Por qué? Porque las arquitecturas de datos de los clientes siempre son únicas. El ERP de un cliente podría tener 10,000 tablas, cada una con 50 campos, muchos sin documentar, usados de maneras inusuales. De hecho, podrían tener dos o tres ERPs, además de un WMS, además de una plataforma e-commerce… El ecosistema es complicado. Ninguna dos empresas tiene las mismas definiciones de datos. Incluso algo aparentemente simple como “order date” puede tener 20 definiciones diferentes: la fecha en que se creó el registro, la fecha en que el cliente confirmó el pedido, la fecha en que tú lo confirmaste, la fecha en que el proveedor de pago lo autorizó, la fecha en que el pedido fue enviado, y así sucesivamente. Multiplica eso por mil otros posibles campos de datos.
Si creas un software “clásico” con definiciones establecidas para producto, SKU, variantes, proveedor, ubicación, y así sucesivamente, esas definiciones rara vez coinciden con la realidad del cliente. Incluso dentro del sector de la moda, por ejemplo, una empresa podría definir las variantes únicamente como color y talla, mientras que otra podría incluir también la composición de la tela. O en el sector de comestibles, podrías tener “expiration date” refiriéndote al día en que absolutamente no se puede vender, o el día en que no se puede exhibir en la tienda. Hay sutilezas infinitas.
De ahí que las teorías estándar de supply chain resultaron ser inadecuadas. Necesitábamos algo nuevo: un enfoque programático. Esto es algo que los libros de texto de supply chain nunca abordan. Los modelos listos para usar no ayudan porque el mundo real nunca encaja perfectamente en esos modelos. Siempre hay algo—mínimos de pedido, restricciones de caducidad, restricciones en los horarios de envío. Las restricciones de cada empresa son únicas. Así que nos dimos cuenta de que la solución es programática, no una fórmula estática. La pregunta entonces se volvió: ¿cuál es el paradigma de programación adecuado para supply chain?
En 2012, la gente podría decir, “¿Por qué no usar simplemente Python?” De hecho, en aquel entonces, eso es exactamente lo que estaban haciendo todos mis clientes e-commerce estadounidenses. Casi cada iniciativa de data science que vi en ese tiempo fracasó debido a Python (o podría haber sido Java, C# o más tarde Julia—es el mismo problema). El patrón era: en tres semanas, un equipo de data science construye un prototipo impresionante para algún problema de supply chain. Luego quieren ponerlo en producción, y un año después aún no está en producción; la dirección pierde la paciencia, cancela el proyecto, y eso es todo.
¿Por qué falló? Muerte por mil cortes: NullReferenceException, OutOfQuotaException, problemas de concurrencia, paquetes incompatibles, brechas de seguridad, ransomware en tu entorno, y así sucesivamente. Nada de eso está directamente relacionado con el problema de supply chain en sí. El problema fundamental es que si usas un lenguaje de propósito general en un entorno de producción grande, tu superficie de ataque para problemas es enorme. Por ejemplo, si puedes escribir en el sistema de archivos desde tu código, puedes corromper accidentalmente el entorno que hospeda tu código—fácil de suceder si estás manejando gigabytes de datos en paralelo. Tal vez un archivo esté bloqueado por un proceso, o un disco se quede sin espacio, y así sucesivamente. Estas cosas inevitablemente ocurren en plena noche, sin que nadie esté allí para solucionarlo en el momento. Luego, por la mañana, el cliente se enfurece porque esperaba que el sistema terminara a las 2 a.m. pero se estrelló a la medianoche.
En las demostraciones de data science, usualmente tienes a alguien encargado de lanzar el script, así que si falla, lo arreglan. Pero la automatización de supply chain en el mundo real debe funcionar sin supervisión todos los días. Incluso los tiempos de ejecución pueden fluctuar de 20 minutos a dos horas, lo cual rompe la producción. Ese fue el problema en 2012: estas iniciativas de data science fallaban en producción debido a la gran complejidad de los lenguajes de propósito general, no por la lógica de supply chain en sí.
Todo eso llevó a Lokad a darse cuenta de que necesitábamos un entorno programático que fuera seguro y lo suficientemente especializado para manejar operaciones diarias a gran escala sin una supervisión frágil. Además, una vez que reconocimos que también necesitábamos hacer forecasting avanzado (probabilistic, quantile, etc.), Envision se configuró para manejar esos flujos de trabajo como ciudadanos de primera clase. Por ejemplo, si deseas differentiable programming para machine learning, en un lenguaje de propósito general integras otro “mini-lenguaje” como PyTorch para eso. Entonces tienes Python más un trozo de código de PyTorch, y es fácil cometer errores, porque tu código de PyTorch es esencialmente una cadena sin compilar. Lo mismo ocurre al mezclar consultas SQL dentro de tu código Python. Todo es cadena, por lo que solo descubres tus errores tipográficos en tiempo de ejecución. Envision, por otro lado, puede tratar estas funcionalidades como características integradas con verificaciones de compilación.
El enfoque de Lokad evolucionó en paralelo con avances como deep learning—donde ya no solo tienes una biblioteca de modelos preempaquetados, sino que compones tu propio modelo de manera programática. TensorFlow es esencialmente un lenguaje para construir gráficos computacionales. No estás atado a un “catálogo” de modelos; construyes estructuras. Envision también puede incorporar estas ideas de forma nativa. Por ejemplo, recientemente hemos trabajado en optimización estocástica. ¿Alguien aquí sabe lo que es? Es la optimización matemática de una función cuyo resultado es incierto—como decidir cuántas unidades comprar cuando la future demand es desconocida. Ese es un desafío clásico de supply chain. Has visto versiones más simples con restricciones mínimas, pero los negocios reales tienen una montaña de restricciones: mínimos de pedido, fill rates, restricciones por categoría o calendarios complicados. Además, tu función costo/beneficio es incierta. Así que estos son conceptos programáticos avanzados.
En resumen, Envision siguió añadiendo características. Hasta el día de hoy, también estamos al umbral de otra revolución: los large language models (LLMs). Probablemente estés familiarizado con ChatGPT. Quizás algunos de ustedes lo estén usando para hacer la tarea. (¡No los estoy evaluando, así que pueden admitirlo!) O incluso pagando por la versión pro. Lo interesante para nosotros es que Lokad tiene una cultura de escritura, lo cual es bastante inusual para una compañía de supply chain. Dependemos del texto en dos niveles. Primero, tenemos el propio código de Envision, que literalmente codifica “lo que” estamos haciendo. No queremos un proceso que genere órdenes recomendadas en Excel, y luego alguien las modifique manualmente. Nuestro objetivo es que los números finales se generen automáticamente sin cambios manuales. Y si se necesitan cambios—a veces sí, inicialmente—esos cambios se capturan en un flujo de trabajo para que podamos discutir con el cliente: “¿Por qué modificaste lo que se generó? ¿Qué podríamos cambiar para que las ediciones manuales ya no sean necesarias?” O a veces vemos que las ediciones en realidad no fueron útiles, por lo que podemos incorporar ese conocimiento también.
Luego tenemos un segundo artefacto de texto, el JPM o Joint Process Manual, que explica el “por qué.” Es nuestro documento de referencia para las transferencias y para darle al cliente una visión global de la iniciativa en lenguaje sencillo—sin que tengan que leer el código de Envision directamente. Así que tenemos una capa de código que describe el “qué” y una capa documental separada que explica el “por qué.”
Eso encaja bastante bien con los LLMs, porque los LLMs procesan texto. No son tan buenos con datos numéricos en bruto. Si introduces una tabla enorme en ChatGPT, no obtendrás una regresión sensata. ChatGPT solo puede generar un trozo de código Python que haría la regresión. Los LLMs en sí mismos son solo gigantescos modelos de predicción del siguiente token; no están diseñados para la aritmética. De ahí los chistes sobre que ChatGPT falla en matemáticas básicas. Pero si les das código o instrucciones basadas en texto, son bastante buenos en manipulación y generación.
Así que así es como se encuentra Lokad: tenemos automatizaciones avanzadas de supply chain que pueden funcionar durante meses sin intervención humana—algo probado durante los confinamientos de 2020–2021, cuando muchos de nuestros clientes enviaron a sus empleados de oficina a casa. Mientras tanto, el supply chain aún tenía que funcionar porque la fuerza laboral de cuello azul en almacenes y trucks seguía activa. Lokad ya operaba en gran medida de forma remota, por lo que nuestros Supply Chain Scientist pudieron seguir trabajando desde casa. Esa fue la verdadera prueba de estrés: ver cómo nuestras recetas funcionarían sin ninguna supervisión diaria. En algunos casos, grandes clientes tenían literalmente cientos de planificadores, gerentes o analistas que de repente no estaban allí, pero su supply chain aún tenía que operar.
Y para nosotros, funcionó sorprendentemente bien. Ninguno de nuestros clientes “murió” a causa de ello—nadie desapareció. Eso plantea la pregunta: si puedes operar tu supply chain durante 12 o 14 meses sin 500 empleados de oficina, ¿realmente los necesitas de vuelta? Este fue un experimento que nunca hubiéramos podido hacer de otra manera, ya que las empresas usualmente tienen miedo de confiar plenamente en un sistema automatizado. Pero los confinamientos efectivamente los obligaron a depender de la automatización, demostrando que podíamos operar supply chains masivos con mínima o incluso ninguna intervención manual. Por supuesto, seguimos discutiendo maneras de mejorar las recetas numéricas; no es cero colaboración. Pero ya no ves grandes equipos haciendo modificaciones diarias en Excel a cada SKU en cada tienda.
Así que, si trato de ver hacia dónde se dirige el mundo de supply chain: para mí, se asemeja al cambio que ocurrió en finanzas hace 20 años, cuando el trading se volvió electrónico. Los traders humanos que antes leían el periódico matutino y decidían comprar o vender una acción a mano, fueron reemplazados por quants con grandes portfolios automatizados. Veo la misma transformación ocurriendo en supply chain. Resolvimos ese viejo sueño—mecanizar las decisiones de supply chain. Esa fue la ambición original de la investigación de operaciones (el “antepasado” de supply chain) en los años 40, 50 y 60. Con el tiempo, la “investigación de operaciones” se convirtió en una subdisciplina propia, enfocándose en los solucionadores, pero si miras la visión inicial, es exactamente lo que supply chain quiere: matemáticas, optimización numérica, asignación de recursos. Logramos una versión de eso en Lokad hace casi diez años. Los confinamientos fueron nuestra verdadera prueba de que funciona a escala, incluso por más de un año sin supervisión directa.
Varios de nuestros clientes hoy en día dejan que el sistema funcione completamente por sí mismo. Por ejemplo, podemos citar a Cdiscount, un gran minorista francés e-commerce: gestionamos el inventario de sus tiendas de manera totalmente automática, sin intervención manual. Eso no detiene las discusiones en curso sobre cómo mejorar las recetas, pero el enfoque diario de “más o menos unidades” ha terminado. Eso terminó en 2020, y sigue funcionando ahora.
Como resultado, creo que estamos al final de una era, la en la que hay algo así como cinco millones de personas en todo el mundo cuyo trabajo es revisar mil SKUs por día en Excel para decidir si necesitan ordenar más, producir más, redistribuir el inventario, cambiar precios, y así sucesivamente. Todo tipo de títulos de trabajo—inventory manager, demand planner, supply planner, category manager, analista de S&OP—se reducen a la misma rutina diaria: repasar un montón de SKUs. Con grandes presupuestos, eso podría ser 100 SKUs por persona; con presupuestos más pequeños, tal vez 5,000 SKUs por persona. De cualquier manera, creo que eso está llegando a su fin.
¿Por qué ahora? Porque durante décadas, nadie pudo automatizar todas esas decisiones. Pero una vez que cierto número de empresas demuestre que se puede hacer, otros seguirán. Es extremadamente costoso mantener grandes equipos de planificación manual, además es difícil pivotar estratégicamente cuando necesitas reentrenar a cientos de planificadores en varios países, cada uno acostumbrado a hacer la misma rutina diaria en hojas de cálculo durante 20 años. Cambiar eso es muy lento. Pero una vez que puedes ir de forma puramente programática, puedes redirigir rápidamente.
Eso es lo que se avecina: el mismo cambio que vimos en la banca. Antes había personas operando manualmente todo el día; ahora es en su mayoría automatizado. Veo la misma mecanización en camino para supply chain, y creo que se convertirá en práctica estándar mucho antes de que te retires—si te retiras después de 61 años trabajando, o según cambien las leyes. Aún te encontrarás con muchas empresas atrapadas en métodos antiguos, pero esa revolución ya está en marcha.
Así que mi mensaje es que pueden ser motores activos de este cambio o simplemente pasajeros. Dado que son estudiantes de Central, probablemente tengan el potencial de ser motores activos en lugar de simples observadores.
Muy bien, tal vez podamos pasar a las preguntas. Les he impuesto un monólogo de 50 minutos, así que si tienen alguna pregunta sobre todo esto, por favor adelante.
Student: Sí, entonces ¿eso significa que estas compañías se volverán dependientes de soluciones como Lokad, o podrán desarrollar tecnologías similares internamente?
Joannes Vermorel: Ambas son posibles. Si se trata de una empresa experta en tecnología—como un actor muy grande en ecommerce—a veces envían equipos para ser entrenados por nosotros, con la idea de internalizar el tipo de prácticas que emplea Lokad. Si una empresa tiene una fuerte cultura tecnológica y ya desarrolla mucho internamente, ciertamente puede hacerlo. Pero si su cultura es “Subcontratamos todo lo que es demasiado complicado,” entonces probablemente externalizarán. En general, creo que la mayoría optará por proveedores especializados, ya sea Lokad u otros. Por supuesto, tengo mi sesgo—me gustaría creer que Lokad estará entre esas soluciones—pero, en cualquier caso, estoy convencido de que la revolución está sucediendo, de una forma u otra.
Student: Dijiste que los LLMs no reemplazarían a los ingenieros, solo a aquellos que no usan LLMs. ¿Qué factor limita a la IA de modo que no pueda reemplazar a aquellos ingenieros que sí usan LLMs? En otras palabras, ¿qué impide que la IA supere a los ingenieros que la utilizan?
Joannes Vermorel: Si supiera la respuesta definitiva, valdría mil mil millones de dólares. A lo largo de las décadas, ha habido muchos avances en la inteligencia artificial, cada vez revelando una faceta de lo que es la inteligencia—lo cual no habíamos comprendido completamente. Una y otra vez, nos damos cuenta de que nos equivocamos sobre lo que constituye la “verdadera” inteligencia.
Por ejemplo, si preguntaras en 1940 qué demuestra una inteligencia superior, podrían decir: “Alguien que pueda diagonalizar una matriz.” La École Polytechnique incluso tenía un departamento para diagonalizar matrices, considerado el pináculo del logro intelectual. Ahora, un algoritmo de computadora simple puede diagonalizar una matriz; no lo vemos para nada como algo inteligente.
Hemos tenido veinte episodios de este tipo en la historia de la IA, cada vez descubriendo que algo que pensábamos era “inteligencia” no lo es. Los Large Language Models tienen algunos defectos evidentes en este momento—como no aprender realmente nada durante su uso. Son modelos estáticos. Puedes darles un prompt, ellos te dan una continuación, y eso es todo. Si haces el mismo prompt de nuevo, obtienes la misma continuación. No aprenden de la conversación. Se puede realizar fine-tuning, sí, pero ese es un proceso externo. Día a día, no hay memoria ni mejora persistente. Un humano que hace un ejercicio aprende algo; un LLM no. Puedes ejecutar el mismo escenario 200 veces, y no acumula conocimiento.
Otro aspecto extraño es la cantidad masiva de datos que requieren los LLMs. Un niño aprende a hablar en aproximadamente tres años, con tal vez 1,000 horas de escucha como máximo. Aparentemente, un LLM necesita leer toda la internet—miles de millones de tokens. O considera los coches autónomos: recorren millones de millas virtuales o reales para aprender a hacer lo que un humano domina en 20 horas de lecciones. ¿Por qué tantos datos para “inteligencia”?
Así que sentimos que falta algo fundamental, pero no sabemos exactamente qué. Tal vez la próxima iteración de los LLMs o un nuevo enfoque en su totalidad arregle esas deficiencias, pero no estamos seguros si eso será mañana o en 20 o 50 años. Algunas personas, como Yann LeCun, dicen que deberíamos desechar todo el enfoque de LLMs y hacer algo diferente. No estoy tan seguro; tal vez podamos ajustar los LLMs para abordar los problemas. Dado que nadie tiene una solución todavía, simplemente no lo sabemos.
De todos modos, estas son limitaciones profundas que impiden que un LLM reemplace completamente a un humano, incluso en trabajos relativamente simples. Así que sí, los LLMs reemplazarán a los ingenieros que elijan no usarlos; pero no necesariamente reemplazarán a los ingenieros que sí los usan—esos individuos seguirán siendo indispensables.
Student: Anteriormente, mencionaste que Lokad se mantuvo rentable a pesar de que el producto no funcionaba al principio. ¿Cómo es eso posible? ¿Recibieron funding o subsidios? ¿O estaban proporcionando otros servicios?
Joannes Vermorel: No, sin subsidios ni funding externo. Permítanme explicar: el mercado de supply chain es algo loco. Los planes de negocio típicos de los competidores desde los años 80 son así: Paso 1, recaudar un montón de dinero—decenas de millones. Paso 2, capturar cuota de mercado centrándose en alguna vertical, como aviation, durante dos o tres años. Paso 3, contratar 200 vendedores, apoderarse del 20% del mercado, y finalmente implosionar. Repetir y repetir.
Lo vemos constantemente. Incluso gigantes como Nike estuvieron a punto de ir a la bancarrota en 2004 debido a un conocido desastre de software de supply chain con uno de nuestros competidores. El “desastre de Nike” está documentado en su página de Wikipedia. Básicamente, arruinaron nueve meses de producción de Nike. Mientras tanto, el mismo proveedor arruinó a muchos clientes, fue adquirido, y el adquirente terminó pagando 250 millones de dólares en daños. Mi experiencia es que en el software empresarial, incluso si eres mediocre, usualmente no te demandan, así que estos chicos debieron haber sido realmente terribles. Pero a pesar de ese historial, simplemente iniciaron una nueva compañía—con las mismas personas—y recaudaron otros quinientos millones de dólares. El mercado nunca aprende.
Muchos de nuestros clientes en realidad vienen a nosotros después de media docena de intentos desastrosos con proyectos de supply chain de diferentes proveedores. La automatización de supply chain es un sueño antiguo; los datos subyacentes han sido digitalizados desde los años 80 o 90, así que han estado intentándolo durante décadas. Es normal que las grandes empresas tengan una pila de proyectos fallidos en su armario.
Ese es el entorno en el que operamos. Hay una enorme inercia. La gente se olvida. La necesidad permanece, así que lo intentan una y otra vez. El mercado puede parecer racional desde la distancia, pero es lento para solucionar estos problemas—especialmente en un área opaca como el software empresarial. Incluso puedes tener una implementación catastrófica, y sin embargo, el cliente podría ofrecerte un estudio de caso brillante de todos modos, porque el gerente que eligió tu producto no quiere que se le culpe. Así que, irónicamente, un fiasco puede ser presentado como un éxito en la narrativa de marketing. Así de desordenado puede llegar a ser.
Joannes Vermorel: ¿Alguna otra pregunta? ¿Todo lo que he descrito les parece normal, racional—lo que esperaban del mundo de los negocios?
Muy bien. En cualquier caso, muchas gracias a todos por el tiempo que dedicaron a programar scripts de Envision. Estoy muy orgulloso de ver a los estudiantes de Central arremangándose y utilizando Envision. Realmente nunca imaginé, cuando escribí el primer compilador hace más de una década, que algún día vería a estudiantes de Central trabajar con él. Fue una apuesta arriesgada en ese entonces; no estaba en nuestro plan de negocios ponerlos frente a Envision, pero me alegra que haya sucedido. Y si Rémi o Basil aún no se los han dicho: ¡Lokad está contratando, solo para que lo sepan!
