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 de 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 ofrece una serie de ejemplos que supuestamente ilustran cómo los LLMs (large language models) pueden contribuir a la gestión de supply chain. Considerando la lista de organizaciones de élite (Microsoft, McKinsey, MIT e incluso Harvard) involucradas en la publicación de esta pieza, cabría esperar perspectivas profundas e incisivas, de esas que articulan cuidadosamente cómo una tecnología brillante, los LLMs, va a contribuir a mejorar las supply chains.

En lugar de eso, obtenemos una contribución mediocre. Más precisamente: es perezosa, hiperbólica y profundamente equivocada, una pieza que se sube a una palabra de moda tecnológica. La premisa completa del artículo puede resumirse así: los LLMs pueden generar y explicar código relevante para supply chain. Los autores adoptan lo que suelo llamar una lectura gadgetoid del asunto. La lectura gadgetoid consiste, al descubrir una nueva tecnología, en atornillarla apresuradamente a un sistema existente. Esto suele hacerse sin considerar en absoluto ni las limitaciones de la tecnología ni los cambios que introduciría en el sistema. Como resultado, este enfoque produce invariablemente gadgets, herramientas entretenidas de interés limitado, y ningún valor de negocio.

Para las distintas organizaciones implicadas:

• Microsoft: tienen muchos ingenieros talentosos. Deben exigirse estándares más altos.

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

• MIT y Harvard: deberían ser voces de razón, no amplificadores de las tonterías de los proveedores tecnológicos.

Aclaramos de inmediato que, aunque estoy de acuerdo en que los LLMs pueden utilizarse para mejorar las supply chains, también pueden ser una distracción completa, dependiendo de cómo se aborde la iniciativa. Este punto es exactamente el problema fundamental que aqueja al artículo revisado. Un paper estrechamente relacionado de Microsoft² también sufre este problema; aunque, por claridad, mi reseña se centrará en el artículo de Harvard.

Antes de abordar el sinsentido tecnológico central, señalemos un problema ético notable. Este artículo no es más que una pieza publicitaria apenas disimulada para Microsoft Cloud Supply Chain. Microsoft, naturalmente, es libre de anunciar sus servicios como mejor le parezca, pero arrastrar tanto a Harvard (mediante la publicación) como al MIT (mediante la coautoría) a una pieza promocional me parece incorrecto. Como mínimo, el artículo debería indicar que los coautores tienen conflictos de interés evidentes. La academia no debería aprobar actividad promocional encubierta de proveedores tecnológicos, por 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 empresa de software de supply chain y, por tanto, tengo un interés particular en contradecir las tonterías que Microsoft, McKinsey, MIT y Harvard están difundiendo. Mis cartas ya están sobre la mesa.

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

Los planificadores también monitorean mensualmente los cambios en el plan de demanda, llamados demand drift, para asegurar que el plan revisado cumpla todos los requisitos del cliente y se mantenga dentro de 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 hizo cada cambio y por qué.

En resumen, los LLMs pueden automatizar empleados haciendo tareas rutinarias. Sin embargo, hay dos objeciones obvias. Primero, los LLMs son completamente innecesarios para ejecutar este tipo de política basada en roles. Un lenguaje de programación simple y unas pocas instrucciones imperativas bastan. Además, de todos modos hará falta infraestructura programática para acceder a los datos y enviar el correo. En ese contexto, los LLMs garantizan una enorme complicación de ingeniería que no aporta beneficios tangibles. De hecho, los LLMs son muy lentos y muy costosos, alrededor de 10 órdenes de magnitud peores que una breve lista de reglas. Son una herramienta que debe usarse como último recurso, cuando todo lo demás ha fallado. Claramente, este no es el caso.

Segundo, las tareas rutinarias señaladas 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 tecnológicas sobrecomplicadas garantiza que la burocracia quede aún más arraigada en sus formas disfuncionales. Lokad, mi empresa, lleva más de una década eliminando este tipo de tareas rutinarias y no requiere nada tan complicado ni costoso como los LLMs.

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 suministro. Tras alimentar al LLM con datos de miles de contratos, un OEM pudo identificar reducciones de precio a las que tenía derecho por superar un cierto umbral de volumen.

Si bien es cierto que las empresas suelen no aplicar algunas cláusulas contractuales con sus proveedores que las 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, esto puede abordarse con una herramienta como ChatGPT sin preparación alguna. Basta con redactar una consulta y enviar repetidamente todos los PDF mediante la interfaz de usuario. Este tipo de trivialidad pertenece a una publicación de LinkedIn titulada “The 10 things I did with ChatGPT today”, no a una publicación Harvard-MIT.

Ahora bien, el verdadero desafío es doble: instrumentación y relación. En el lado de la instrumentación, los pasos administrativos para emitir pedidos y pagos están ampliamente automatizados en la mayoría de las empresas que operan algo que califica como “supply chain”. Por tanto, salvo que exista una instrumentación de soporte extensa, tratar casos extremos va a complicar y retrasar todo.

Además, en el lado de la relación, si una cláusula contractual ha sido ignorada durante años, es ingenuo pensar que la empresa puede activarla sin consecuencias. La mayoría de las veces, el proveedor ya había incorporado ese comportamiento laxo del cliente en sus precios, y el escrutinio excesivo de términos contractuales marginales será respondido de la misma manera, o quizá con un aumento de precio.

De manera más general, los descuentos y las rebajas de precio deberían gestionarse como parte de los sistemas transaccionales ordinarios del negocio. 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 tecnológico.

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

Esto es pensamiento ilusorio. Hasta la fecha, el porcentaje de empresas que disfrutan de una “base de código monolítica unificada” para derivar sus decisiones de supply chain es prácticamente nulo (más sobre esto abajo). En cambio, las empresas tienen un océano de hojas de cálculo. A diferencia de la bonita imagen que pintan los autores, no existen “programas matemáticos” con los que los LLMs puedan interactuar. Aunque los LLMs podrían, conceptualmente, editar y mejorar una pila desordenada 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, ya que la duplicación pasiva de código que implican las hojas de cálculo no favorece en absoluto a los LLMs; dar sentido a cientos, si no miles, de hojas sigue siendo ciencia ficción pura en este momento.

Ahora bien, sí hay algunas empresas que se benefician de una base de código monolítica unificada que gestiona los procesos de toma de decisiones de supply chain, concretamente los clientes de Lokad. Si los autores tuvieran, como nosotros, alguna experiencia real en la materia, sabrían que esas bases de código son considerables: típicamente decenas de miles de líneas, a pesar de que usamos un DSL (lenguaje específico de dominio)⁵ dedicado a supply chain. Este DSL, por cierto, es unas 10 veces más conciso que Python o Java para este tipo de tarea. Desafortunadamente, no hay atajo: para cualquier decisión de interés intervienen docenas de tablas, que abarcan cientos de campos. Aunque es concebible que nuevas mejoras de nuestro DSL reduzcan 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 bajo la dirección de un colaborador no técnico. Sin embargo, otra vez estamos en territorio de ciencia ficción. Ya se ha demostrado que los LLMs son herramientas de productividad fantásticas para programadores capaces. En otras palabras, si ya sabes programar, los LLMs pueden ayudarte a programar más rápido. Pero esto no es lo que dicen los autores del artículo. Su propuesta es precisamente que los LLMs pueden permitir que colaboradores no técnicos realicen contribuciones técnicas. Según el estado actual del arte de los LLMs, esta proposición es invariablemente falsa, salvo dentro de pequeños sandboxes que no reflejan la enorme complejidad ambiental de las supply chains reales.

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

Los autores redoblan la apuesta por 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 a partir de tickets enviados por usuarios no técnicos”. Sería una noticia fantástica si esto fuera posible, pero, de nuevo, los LLMs actuales no están ni cerca de lograr este tipo de hazaña de forma fiable para solicitudes serias. Al presentar casos de uso para una tecnología novedosa, es fundamental transmitir con precisión sus límites. Los cuatro coautores parecen completamente ajenos al estado actual del arte de los LLMs; dicho esto, tengo la sospecha de que no lo están. En cambio, recibimos palabrería publicitaria de personas muy conscientes de lo que hacen, lo cual probablemente sea mucho peor.

La necesidad de cambiar el plan de suministro también puede estar 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 indicando que el tiempo de entrega de ese proveedor ha aumentado significativamente durante los últimos meses.

Detectar si un tiempo de entrega es anormal no es en absoluto algo que pueda hacer un LLM. Un LLM sí puede recibir una instrucción para escribir un fragmento de código que realice 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 pedidos donde se consume la información del tiempo de entrega? 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 por apoyará los autores quisieran decir hacer más productivos a los programadores, 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 lleva tiempo haciendo. Sin embargo, si eliminamos a los programadores humanos de la imagen, esta afirmación se parece más a “imaginamos que en los próximos años las tecnologías basadas en LLM alcanzarán la AGI (inteligencia artificial general)”.

Los autores, subidos con entusiasmo a la palabra de moda “Gen AI”, descartan por completo que los LLMs puedan tener limitaciones propias. Esto es lo que plantean en la sección final “Overcoming Barriers”:

Adopción y formación. Usar un LLM para optimizar supply chains requiere un lenguaje muy preciso […] Cada interpretación conduce a decisiones diferentes.

No, esto es sencillamente incorrecto, salvo que “lenguaje muy preciso” se entienda como “lenguaje de programación” (que efectivamente es muy preciso). Para optimizar una supply chain usando un LLM, se necesita un ingeniero humano capaz de hacer la codificación completamente por sí mismo, aunque más lentamente. En el futuro previsible, ninguna cantidad de formación, excepto volverse competente en programación, hará que los usuarios sean capaces de realizar optimizaciones de supply chain con el apoyo de LLMs.

Decirle al CEO o al director de supply chain que solo necesita formar a su equipo para usar un “lenguaje preciso” es totalmente engañoso. Los talleres de formación resultantes de esa visión tienen garantizado ser una pérdida completa de tiempo para todas las partes involucradas.

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

Aunque los LLMs son probabilísticos por diseño, este problema queda eclipsado 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 equivocado. La experiencia de Lokad indica que, con frecuencia, la única manera de comprobar si una implementación dada (que impulsa una decisión de supply chain) es correcta consiste en realizar una prueba experimental limitada⁶. La retroalimentación del mundo real no es una opción. El conocimiento no puede conjurarse de la nada; incluso LLMs de nivel AGI seguirían enfrentándose a este obstáculo.

Aquí, los autores están rellenando. Hacen una afirmación correcta, pero trivial, sobre la naturaleza de los LLMs sin siquiera intentar ver si el problema es una preocupación central o no. Si los autores hubieran gestionado realmente supply chains del mundo real usando 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 mucho más impactantes.

Para concluir, se aplica aquí la ley de Brandolini: La cantidad de energía necesaria para refutar una estupidez es un orden de magnitud mayor que la necesaria para producirla. Este artículo es tan malo que podría haber sido escrito por ChatGPT, y quizá lo fue, por lo que sé. Según mis observaciones casuales, cada día se producen docenas de artículos igual de malos sobre Gen-AI y SCM. La notoriedad de los autores me motivó a preparar esta reseña. Dando un paso atrás, no sería la primera vez que un proveedor promete revolucionar un dominio sin tener nada sustancial que ofrecer. Pero que el mismo proveedor lo haga dos veces⁷ en dos años consecutivos dentro del mismo dominio podría resultar excesivo. Por otra parte, la academia debería al menos intentar ejercer algo de pensamiento crítico en lugar de subirse alegremente al tren de las palabras de moda.