Una revisión de "How Generative AI Improves Supply Chain Management"

Joannes Vermorel

The Harvard Business Review, como parte de su edición de enero-febrero 2025, publicó recientemente How Generative AI Improves Supply Chain Management¹ de Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Profesor, MIT), y Tom Linton (McKinsey). Como sugiere el título, el artículo proporciona una serie de ejemplos que supuestamente ilustran cómo los LLMs (large language models) pueden contribuir a supply chain management. Considerando la lista de organizaciones de élite (Microsoft, McKinsey, MIT, e incluso Harvard) involucradas en la publicación de este artículo, se esperaría obtener algunas perspectivas profundas e incisivas—esas que articulan cuidadosamente cómo una brillante pieza de tecnología—LLMs—va a contribuir a la mejora de supply chain.

En lugar de ello, obtenemos una contribución mediocre. Más precisamente: es perezosa, hiperbólica y profundamente equivocada—una pieza que resulta aprovecharse de una palabra de moda tecnológica. La premisa completa del artículo se puede resumir como LLMs pueden tanto generar como explicar código de relevancia para supply chain. Los autores adoptan lo que usualmente denomino un enfoque gadgetoid. Este enfoque gadgetoid consiste, al descubrir una nueva pieza de tecnología, en acoplarla apresuradamente a un sistema existente. Esto se hace normalmente sin ninguna consideración sobre las limitaciones de la pieza o de los cambios que se introducirían en el sistema. Como resultado, este enfoque invariablemente produce gadgets—herramientas divertidas de interés limitado—y ningún valor de negocio.

Para las diversas organizaciones involucradas:

• Microsoft: tienen muchos ingenieros talentosos a bordo. Deben mantener estándares más altos.

• McKinsey: no orienten a potenciales clientes hacia direcciones que seguramente serán una pérdida de tiempo y dinero.

• MIT y Harvard: deberían ser voces de la razón y no amplificar las tonterías de los proveedores de tecnología.

Aclaramos de inmediato que, si bien estoy de acuerdo en que los LLMs pueden utilizarse para la mejora de supply chain, los LLMs también pueden ser una distracción completa—dependiendo de cómo se aborde la iniciativa. Este punto resulta ser exactamente el problema fundamental que aqueja al artículo en revisión. Un artículo estrechamente relacionado de Microsoft² también sufre de este inconveniente; aunque, para mayor claridad, mi revisión se centrará en el artículo de Harvard.

Antes de abordar las tonterías tecnológicas fundamentales, señalemos un notable problema ético. Este artículo no es más que una pieza de publicidad disfrazada que promociona Microsoft Cloud Supply Chain. Microsoft, por supuesto, es libre de anunciar sus servicios de cualquier modo que considere oportuno, pero involucrar tanto a Harvard (a través de la publicación) como al MIT (a través de la coautoría) en una pieza promocional me resulta inaceptable. Al menos, el artículo debería señalar que los coautores tienen evidentes conflictos de interés. La academia no debería aprobar la actividad promocional encubierta de proveedores de tecnología, sin importar lo grandes e influyentes que sean.

Descargo de responsabilidad: El lector perspicaz habrá notado que yo también tengo un conflicto de interés. Sí, dirijo una compañía de software de supply chain y, por ello, tengo un interés particular en contradecir las tonterías que Microsoft, McKinsey, MIT y Harvard están difundiendo. Ahora pongo todas mis cartas sobre la mesa.

Procedamos ahora con una revisión de las afirmaciones hechas por el artículo.

Los planificadores también monitorean los cambios en el plan de demanda, denominado el “demand drift”, mensualmente para asegurar que el plan revisado cumpla con todos los requisitos del cliente y se ajuste a las pautas presupuestarias […] La tecnología basada en LLM ahora hace todo esto. Genera automáticamente un informe por correo electrónico que detalla quién realizó cada cambio y el motivo para hacerlo.

En resumen, los LLM pueden automatizar a los empleados en tareas rutinarias. Sin embargo, existen dos objeciones obvias. Primero, los LLM son completamente innecesarios para ejecutar este tipo de política basada en roles. Un lenguaje de programación simple y unas pocas sentencias imperativas serán suficientes. Además, se necesitará de todos modos una infraestructura programática para acceder a los datos y enviar el correo electrónico. En esos casos, los LLM representan garantía una complicación de ingeniería masiva que no aporta beneficios tangibles. De hecho, los LLM son muy lentos y muy costosos; aproximadamente 10 órdenes de magnitud peores que una breve lista de reglas. Son una herramienta para usarse como último recurso, cuando todo lo demás ha fallado. Claramente, este no es el caso aquí.

Segundo, las tareas rutinarias mencionadas anteriormente son completamente innecesarias. La empresa debería eliminar esta clase de actividades sin sentido³. Las burocracias ya son bastante malas, pero las tecnocracias son peores. Introducir piezas de tecnología sobrecomplicadas garantiza que la burocracia se arraigue aún más en sus formas disfuncionales. Lokad, mi compañía, ha estado eliminando este tipo de tareas rutinarias durante más de una década y no requiere nada tan complicado y costoso como los LLM.

Estos contratos especifican los detalles del precio pagado por el OEM, los requisitos de calidad, los tiempos de entrega, y las medidas de resiliencia que los proveedores deben tomar para asegurar el supply. Después de alimentar al LLM con datos de miles de contratos, un OEM pudo identificar reducciones de precio a las que tenía derecho al superar un cierto umbral de volumen.

Si bien es cierto que las empresas rutinariamente fallan al aplicar algunas de las cláusulas contractuales con sus proveedores que les beneficiarían, identificar los términos contractuales relevantes es solo una porción microscópica del desafío—digamos, el 1% o posiblemente mucho menos. Además, se puede abordar con una herramienta como ChatGPT sin ninguna preparación previa. Todo lo que se necesita es componer una consulta y enviar repetidamente todos los PDF a través de la interfaz de usuario. Este tipo de trivialidades pertenece a una publicación en LinkedIn titulada “The 10 things I did with ChatGPT today” y no a una publicación conjunta de Harvard-MIT.

Ahora, el desafío real es doble: instrumentación y relación. En el lado de la instrumentación, los pasos administrativos para emitir órdenes y pagos están en gran medida automatizados en la mayoría de las empresas que operan algo que califica como “supply chain”. Por lo tanto, a menos que exista una extensa instrumentación de apoyo, tratar con casos extremos complicará y retrasará todo.

Además, en el aspecto de la relación, si una cláusula contractual ha sido ignorada durante años, entonces es ingenuo pensar que la empresa puede activar la cláusula sin ninguna consecuencia. Más a menudo que no, el proveedor ya había integrado este comportamiento laxo del cliente en sus precios, y criticar en exceso los términos contractuales marginales será respondido de la misma manera—o posiblemente con un aumento de precio.

De manera más general, los descuentos y las rebajas de precio deben gestionarse como parte de los sistemas de negocio transaccionales regulares. Esto no es ingeniería aeroespacial, sino simple CRUD⁴. Una vez más, introducir un LLM donde bastarían unas pocas reglas imperativas no tiene sentido desde el punto de vista tecnológico.

Un LLM permite a los planificadores hacer preguntas detalladas. Aquí hay algunos ejemplos: “¿Cuál sería el costo de transporte adicional si la demanda total del producto aumentara en un 15%?” […] Así es como un LLM puede responder a preguntas como estas de manera precisa y eficiente. Muchas tareas de optimización están redactadas en forma de programas matemáticos […] Un LLM […] traduce una consulta humana a un código matemático que representa un pequeño cambio al modelo matemático original utilizado para producir el plan.

Esto es un pensamiento ilusorio. Hasta la fecha, el porcentaje de empresas que disfrutan de una “base de código monolítica unificada” para derivar sus supply chain decisions es prácticamente nulo (más sobre esto a continuación). En cambio, las empresas tienen un océano de hojas de cálculo. A diferencia de la bonita imagen que los autores están pintando, no existen “programas matemáticos” con los que interactuar para los LLMs. Aunque los LLMs podrían, conceptualmente, editar y mejorar un desordenado montón de hojas de cálculo medio obsoletas, hasta que se demuestre lo contrario, esto es pura especulación. Incluso los LLMs de última generación tendrían dificultades para editar una única hoja de cálculo grande—la duplicación pasiva de código que implican las hojas de cálculo no es favorable en absoluto para los LLMs—pero dar sentido a cientos, si no a miles, de hojas sigue siendo pura ciencia ficción en este momento.

Ahora, de hecho, hay algunas empresas que se benefician de una base de código monolítica unificada que gestiona los procesos de toma de decisiones en supply chain—a saber, los clientes de Lokad. Si los autores hubieran tenido, como nosotros, alguna experiencia en el tema, habrían sabido que esas bases de código son considerables; típicamente, decenas de miles de líneas de código, a pesar de que utilizamos un DSL (lenguaje específico de dominio)⁵ dedicado a supply chain. Este DSL es aproximadamente 10 veces más conciso que Python o Java para este tipo de tarea, por cierto. Desafortunadamente, no hay atajo: para cualquier decisión de interés, hay docenas de tablas, que abarcan cientos de campos, involucrados en el cálculo. Aunque es concebible que mejoras adicionales a nuestro DSL puedan reducir aún más el número de líneas de código, esas bases de código nunca serán pequeñas.

De nuevo, los LLMs podrían, conceptualmente, editar y mejorar una base de código compleja mientras son dirigidos por un colaborador no técnico. Sin embargo, nuevamente estamos en territorio de ciencia ficción. Ya se ha demostrado que los LLMs son herramientas fantásticas de productividad para programadores capaces. En otras palabras, si ya sabes programar, los LLMs pueden ayudarte a programar más rápido. Sin embargo, esto no es lo que dicen los autores del artículo. Su propuesta es precisely que los LLMs pueden utilizarse para permitir que colaboradores no técnicos realicen contribuciones técnicas. Basado en el estado actual del arte de los LLMs, esta proposición es invariablemente falsa, salvo dentro de pequeños sandboxes que no reflejan la masiva complejidad ambiental de las supply chain del mundo real.

Los planificadores pueden usar la tecnología de LLM para actualizar los modelos matemáticos de la estructura de una supply chain y los requisitos comerciales para reflejar el entorno empresarial actual. Además, un LLM puede actualizar a los planificadores sobre un cambio en las condiciones comerciales.

Los autores se están aferrando a la ciencia ficción. Esta afirmación es técnicamente indistinguible de “un LLM puede emitir parches a un repositorio de código en GitHub basado en tickets presentados por usuarios no técnicos”. Sería una noticia fantástica si esto fuera posible, pero nuevamente, los LLMs actuales están lejos de poder lograr este tipo de hazaña de manera confiable para solicitudes serias. Al presentar casos de uso para una tecnología novedosa, es fundamental transmitir con precisión los límites de dicha tecnología. Los cuatro coautores parecen estar completamente ajenos al estado actual del arte de los LLMs; dicho esto, sospecho en el fondo que no lo están. En cambio, recibimos un parloteo publicitario por parte de personas que son muy conscientes de lo que están haciendo—lo cual es, posiblemente, mucho peor.

La necesidad de cambiar el plan de supply también puede ser impulsada por tecnología basada en LLM. Por ejemplo, después de analizar datos de envíos de un proveedor específico, puede generar una alerta de que el lead time del proveedor ha aumentado significativamente en los últimos meses.

Detectar si un lead time es anormal no es absolutamente lo que un LLM puede hacer. Sin embargo, se le puede solicitar a un LLM que escriba un fragmento de código para realizar este análisis. Volvemos a la publicación de LinkedIn “Top 10 things I did with ChatGPT today”. ¿Por qué detenerse ahí y no actualizar directamente la lógica de ordenación donde se consume la información del lead time? Esto es exactamente lo que los autores sugieren más adelante en el artículo.

Imaginamos que en los próximos años la tecnología basada en LLM apoyará escenarios de toma de decisiones de extremo a extremo.

Si con support los autores querían decir hacer que los programadores sean más productivos—siendo dichos programadores los encargados de codificar la toma de decisiones de extremo a extremo—entonces esto ya es posible—de hecho, es algo que Lokad ha estado haciendo desde hace algún tiempo. Sin embargo, si eliminamos a los programadores humanos de la ecuación, esta afirmación se parece más a “imaginamos que en los próximos años las tecnologías basadas en LLM lograrán AGI (inteligencia artificial general)”.

Los autores, aprovechándose a pleno de la palabra de moda “Gen AI”, desestiman por completo que los LLM puedan de alguna manera tener limitaciones propias. Esto es lo que los autores proponen en su sección de conclusión “Overcoming Barriers”:

Adopción y entrenamiento. Utilizar un LLM para optimizar supply chain requiere un lenguaje muy preciso […] Cada interpretación conduce a decisiones diferentes.

No, esto es totalmente incorrecto—salvo que se entienda “un lenguaje muy preciso” como “lenguaje de programación” (ya que estos son efectivamente muy precisos). Para optimizar un supply chain utilizando un LLM, se necesita un ingeniero humano que sea capaz de hacer la codificación completamente por sí mismo, aunque de forma más lenta. Para el futuro previsible, ninguna cantidad de entrenamiento, salvo volverse competente en programación, hará que los usuarios sean capaces de realizar optimizaciones de supply chain con el soporte de los LLMs.

Decirle al CEO o al director de supply chain que simplemente necesita entrenar a su equipo para usar un “lenguaje preciso” es totalmente engañoso. Los talleres de formación que resultarían de esta visión garantizarían ser una completa pérdida de tiempo para todas las partes involucradas.

Verificación. La tecnología de LLM puede ocasionalmente producir un resultado incorrecto. Por lo tanto, un desafío general es mantener la tecnología “dentro de los rieles”—es decir, identificar errores y recuperarse de ellos.

Si bien los LLMs son probabilísticos por diseño, este problema queda ensombrecido por la incertidumbre semántica que permea los sistemas de supply chain. En otras palabras, es muy probable que el LLM te dé la respuesta correcta al problema incorrecto. La experiencia de Lokad indica que, con frecuencia, la única manera de verificar si una implementación dada (que deriva en una decisión de supply chain) es correcta es realizar una prueba experimental limitada⁶. La retroalimentación del mundo real no es una opción. El conocimiento no puede ser conjurado de la nada—incluso los LLMs a nivel de AGI aún se enfrentarían a este obstáculo.

Aquí, los autores se quedan en rellenar. Hacen una afirmación correcta—pero trivial—sobre la naturaleza de los LLM sin siquiera intentar determinar si el problema es una preocupación central o no. Si los autores realmente hubieran gestionado supply chain del mundo real utilizando LLMs, se habrían dado cuenta, como nosotros, de que esta preocupación es un problema pequeño dentro de una larga lista de problemas mucho mayores—y de mayor impacto.

Para concluir, se aplica aquí la ley de Brandolini: La cantidad de energía necesaria para refutar la mierda es una magnitud de orden mayor que la necesaria para producirla. Este artículo es tan malo que podría haber sido escrito por ChatGPT—y tal vez lo fue, por lo que yo sé. Basándome en mis observaciones casuales, existen docenas de artículos igual de malos producidos cada día acerca de Gen-AI y SCM. La notoriedad de los autores me motivó a reunir esta reseña. Dando un paso atrás, no sería la primera vez que un proveedor promete revolucionar un dominio sin tener nada de sustancia que ofrecer. Sin embargo, el mismo proveedor haciéndolo dos veces⁷ en dos años seguidos dentro del mismo dominio podría ser excesivo, aunque. Por otro lado, la academia al menos debería estar intentando realizar un pensamiento crítico en lugar de subirse felizmente al carro de las palabras de moda.