Una revisión de "Cómo la IA generativa mejora la gestión de la cadena de suministro"

Joannes Vermorel

La Harvard Business Review, como parte de su número de enero-febrero de 2025, publicó recientemente Cómo la IA generativa mejora la gestión de la cadena de suministro¹ 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 LLM (modelos de lenguaje grandes) pueden contribuir a la gestión de la cadena de suministro. Teniendo en cuenta la lista de organizaciones de élite (Microsoft, McKinsey, MIT e incluso Harvard) involucradas en la publicación de este artículo, uno esperaría algunas opiniones profundas y perspicaces, del tipo que articulan cuidadosamente cómo una brillante pieza de tecnología, los LLM, va a contribuir a la mejora de las cadenas de suministro.

En cambio, obtenemos una contribución mediocre. Más precisamente: es perezosa, hiperbólica y profundamente equivocada, una pieza que aprovecha una palabra de moda tecnológica. Toda la premisa del artículo se puede resumir como los LLM pueden generar y explicar código relevante para la cadena de suministro. Los autores adoptan lo que suelo llamar un enfoque gadgetoide sobre el tema. El enfoque gadgetoide consiste, al descubrir una nueva pieza de tecnología, en añadirla apresuradamente a un sistema existente. Esto se hace típicamente sin tener en cuenta las limitaciones de la pieza ni los cambios que se producirían en el sistema. Como resultado, este enfoque produce inevitablemente gadgets, herramientas divertidas de interés limitado y sin ningún valor comercial.

A las diversas organizaciones involucradas:

• Microsoft: tienes muchos ingenieros talentosos a bordo. Debes exigirte estándares más altos.

• McKinsey: no dirijas a los posibles clientes en direcciones que están garantizadas a ser 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.

Vamos a aclarar de inmediato que si bien estoy de acuerdo en que los LLM se pueden utilizar para mejorar las cadenas de suministro, los LLM también pueden ser una distracción completa, dependiendo de cómo se aborde el proyecto. Este punto resulta ser exactamente el problema fundamental que aqueja al artículo bajo revisión. Un artículo estrechamente relacionado de Microsoft² también sufre de este problema; aunque, para mayor claridad, mi revisión se centrará en el artículo de Harvard.

Antes de abordar la tontería tecnológica central, señalemos un notable problema ético. Este artículo no es más que una pieza de publicidad disfrazada para Microsoft Cloud Supply Chain. Microsoft tiene naturalmente libertad para promocionar sus servicios de la manera que considere oportuna, 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 no me parece correcto. Como mínimo, el artículo debería señalar que los coautores tienen conflictos de interés evidentes. La academia no debería estar avalando actividades promocionales encubiertas de proveedores de tecnología, sin importar cuán grandes e influyentes sean.

Descargo de responsabilidad: El lector perspicaz se habrá dado cuenta de que yo también tengo un conflicto de interés. Sí, dirijo una empresa de software de cadena de suministro y, por lo tanto, tengo un interés personal en contradecir las tonterías que Microsoft, McKinsey, MIT y Harvard están difundiendo. Ahora muestro mis cartas.

Ahora procedamos con una revisión de las afirmaciones hechas en el artículo.

Los planificadores también supervisan los cambios en el plan de demanda, llamado deriva de la demanda, mensualmente para asegurarse de 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 la razón para hacerlo.

En resumen, los LLM pueden automatizar el trabajo de los empleados ocupados. Sin embargo, hay dos objeciones obvias. En primer lugar, los LLM son completamente innecesarios para ejecutar este tipo de política basada en roles. Un lenguaje de programación simple y algunas declaraciones imperativas serán suficientes. Además, de todos modos se necesitará una programación para acceder a los datos y enviar el correo electrónico. En esos casos, los LLM representan una complicación de ingeniería masiva que no ofrece beneficios tangibles. De hecho, los LLM son muy lentos y muy costosos; aproximadamente 10 órdenes de magnitud peor que una lista corta de reglas. Son una herramienta que se utiliza como último recurso, cuando todo lo demás ha fallado. Este claramente no es el caso aquí.

En segundo lugar, el trabajo ocupado mencionado anteriormente es completamente innecesario. La empresa debería eliminar esta clase de tareas sin sentido[^burocracias]. Las burocracias ya son lo suficientemente malas, pero las tecnocracias son peores. Traer piezas de tecnología complicadas a la fiesta garantiza que la burocracia se afianzará aún más en sus formas disfuncionales. Lokad, mi empresa, ha estado eliminando este tipo de trabajo ocupado 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 plazos de entrega y las medidas de resiliencia que los proveedores deben tomar para garantizar el suministro. Después de alimentar los datos de LLM de miles de contratos, un OEM pudo identificar reducciones de precios a las que tenía derecho por superar un cierto umbral de volumen.

Si bien es cierto que las empresas rutinariamente no logran aplicar algunas de las cláusulas contractuales con sus proveedores que les beneficiarían, identificar los términos contractuales relevantes es solo una parte microscópica del desafío, digamos, un 1% o posiblemente mucho menos. Además, se puede abordar con una herramienta como ChatGPT sin ninguna preparación. 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 de LinkedIn titulada “Las 10 cosas que hice con ChatGPT hoy” y no a una publicación de Harvard-MIT.

Ahora, el desafío real es doble: instrumentación y relación. En cuanto a la instrumentación, los pasos administrativos para emitir pedidos y pagos están en gran medida automatizados en la mayoría de las empresas que operan algo que califica como una “cadena de suministro”. Por lo tanto, a menos que haya una instrumentación de apoyo extensa, lidiar con casos marginales complicará y retrasará todo.

Además, en cuanto a 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. La mayoría de las veces, el proveedor ya ha integrado este comportamiento laxo del cliente en sus precios, y hacer hincapié en los términos contractuales marginales será respondido de la misma manera, o posiblemente con un aumento de precio.

En general, los descuentos y las rebajas de precios deben gestionarse como parte de los sistemas comerciales transaccionales regulares. Esto no es ingeniería espacial, sino simplemente CRUD³. Una vez más, traer un LLM donde unas pocas reglas imperativas serían suficientes es tecnológicamente absurdo.

Un LLM permite a los planificadores hacer preguntas detalladas. Aquí hay algunos ejemplos: “¿Cuál sería el costo adicional de transporte si la demanda total del producto aumentara en un 15%?” […] Así es como un LLM puede responder preguntas como estas de manera precisa y eficiente. Muchas tareas de optimización se escriben en forma de programas matemáticos […] Un LLM […] traduce una consulta humana en un código matemático que es un pequeño cambio en el 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 decisiones de supply chain es prácticamente nulo (más sobre eso 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 hay “programas matemáticos” con los que interactuar para los LLM. Si bien los LLM podrían, conceptualmente, editar y mejorar un montón desordenado de hojas de cálculo medio obsoletas, hasta que se demuestre lo contrario, esto es pura especulación. Incluso los LLM de última generación tendrían dificultades para editar una sola 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 LLM, pero entender cientos, si no miles, de hojas sigue siendo pura ciencia ficción en este momento.

Ahora bien, hay algunas empresas que se benefician de una base de código monolítica unificada que gestiona los procesos de toma de decisiones de la cadena de suministro, 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 considerablemente grandes; típicamente de decenas de miles de líneas de código, a pesar de que utilizamos un DSL (lenguaje específico del dominio)⁴ dedicado a la cadena de suministro. Este DSL es aproximadamente 10 veces más conciso que Python o Java para este tipo de tareas, por cierto. Desafortunadamente, no hay atajos: para cualquier decisión de interés, hay docenas de tablas que cubren cientos de campos que están involucrados en el cálculo. Si bien es concebible que futuras mejoras en 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.

Nuevamente, los LLM 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. Los LLM ya han demostrado ser herramientas de productividad fantásticas para programadores capaces. En otras palabras, si ya sabes programar, los LLM pueden ayudarte a programar más rápido. Sin embargo, esto no es lo que los autores del artículo están diciendo. Su propuesta es precisamente que los LLM se pueden utilizar para permitir que los colaboradores no técnicos realicen contribuciones técnicas. Según el estado actual de la técnica de los LLM, esta propuesta es invariablemente falsa, excepto dentro de los límites de pequeños entornos de prueba que no reflejan la complejidad masiva del ambiente de las cadenas de suministro del mundo real.

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

Los autores están insistiendo en 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 una vez más, los LLM actuales están muy lejos de poder lograr este tipo de hazaña de manera confiable para solicitudes serias. Cuando se presentan casos de uso para una nueva tecnología, es fundamental transmitir con precisión los límites de dicha tecnología. Los cuatro coautores parecen estar completamente inconscientes del estado actual de la técnica de los LLM; dicho esto, tengo la sospecha de que no lo están. En cambio, obtenemos un discurso publicitario de personas que son plenamente conscientes de lo que están haciendo, lo cual es sin duda mucho peor.

La necesidad de cambiar el plan de suministro también puede ser impulsada por la tecnología basada en LLM. Por ejemplo, después de analizar los datos de envío de un proveedor específico, puede generar una alarma de que el tiempo de entrega del proveedor ha aumentado significativamente en los últimos meses.

Detectar si un tiempo de entrega es anormal es algo que un LLM no puede hacer en absoluto. Sin embargo, un LLM puede ser instruido para escribir un fragmento de código que realice este análisis. Volvemos al post de LinkedIn “Las 10 cosas que hice con ChatGPT hoy”. ¿Por qué detenerse ahí y no actualizar directamente la lógica de pedido 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.

Visualizamos 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 “apoyar” los autores se refieren a “hacer que los programadores sean más productivos” -siendo estos 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 tiempo. Sin embargo, si eliminamos a los programadores humanos de la ecuación, esta afirmación se acerca más a “visualizamos que en los próximos años las tecnologías basadas en LLM lograrán la IA general (inteligencia artificial general)”.

Los autores, aprovechando al máximo la palabra de moda “Gen AI”, ignoran por completo que los LLM podrían tener limitaciones propias. Esto es lo que los autores presentan en su sección de conclusión “Superando barreras”:

Adopción y entrenamiento. Utilizar un LLM para optimizar las cadenas de suministro requiere un lenguaje muy preciso […] Cada interpretación lleva a decisiones diferentes.

No, esto es completamente incorrecto, a menos que “lenguaje muy preciso” se entienda como “lenguaje de programación” (ya que esos son efectivamente muy precisos). Para optimizar una cadena de suministro utilizando un LLM, se necesita un ingeniero humano que sea capaz de hacer la programación completamente por sí mismo, aunque más lentamente. En un futuro previsible, ninguna cantidad de entrenamiento, excepto volverse competente en programación, hará que los usuarios sean capaces de realizar optimizaciones de cadena de suministro con el apoyo de los LLM.

Decirle al CEO o al director de la cadena de suministro que solo necesita capacitar a su equipo para usar un “lenguaje preciso” es completamente engañoso. Los talleres de capacitación que resultarían de esta visión están garantizados a ser una completa pérdida de tiempo para todas las partes involucradas.

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

Si bien los LLM son probabilísticos por diseño, este problema se ve opacado por la incertidumbre semántica que impregna los sistemas de cadena de suministro. 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 forma de comprobar si una implementación determinada (que impulsa una decisión de cadena de suministro) es correcta es realizar una prueba experimental limitada⁵. Los comentarios del mundo real no son una opción. El conocimiento no puede ser conjurado de la nada, incluso los LLM de nivel AGI se enfrentarían a este obstáculo.

Aquí, los autores se quedan rellenando. Hacen una afirmación correcta pero trivial sobre la naturaleza de los LLM sin siquiera intentar ver si el problema es una preocupación central o no. Si los autores hubieran gestionado cadenas de suministro del mundo real utilizando LLM, se habrían dado cuenta, al igual que nosotros, de que esta preocupación es un problema pequeño dentro de una larga lista de problemas mucho más grandes y con un impacto mucho mayor.

Para concluir, se aplica la ley de Brandolini: La cantidad de energía necesaria para refutar tonterías es un orden de magnitud mayor que la necesaria para producirlas. Este artículo es tan malo que podría haber sido escrito por ChatGPT, y tal vez lo fue, por lo que sé. Según mis observaciones casuales, todos los días se producen docenas de artículos igualmente malos sobre Gen-AI y SCM. La notoriedad de los autores me motivó a escribir esta reseña. Mirando hacia atrás, no sería la primera vez que un proveedor promete revolucionar un dominio sin tener nada sustancial que ofrecer. Sin embargo, que el mismo proveedor lo haga dos veces⁶ dos años seguidos dentro del mismo dominio podría ser excesivo. Una vez más, la academia debería al menos intentar hacer un poco de pensamiento crítico en lugar de subirse felizmente al carro de las palabras de moda.