Por qué las iniciativas de AI fracasan en supply chain - Ep 168

00:00:00 Introducción y aclaración del tema
00:02:55 Empresas revisitando antiguos enfoques con AI
00:04:28 Fracasos de ingenieros inteligentes en supply chain
00:05:44 Traducción automatizada del sitio web de Lokad con LLMs
00:09:15 Las cuatro pruebas clave de los fracasos
00:12:24 Por qué los RFPs son disfuncionales
00:21:28 Por qué las series de tiempo son disfuncionales
00:32:47 Por qué los safety stock son disfuncionales
00:50:04 Por qué los service levels son disfuncionales
01:09:59 Preguntas del público
01:32:15 Reflexiones finales

Resumen

En un reciente episodio de LokadTV, Conor Doherty y Joannes Vermorel discutieron las fallas inherentes en la gestión de supply chain, particularmente la excesiva dependencia en AI. Vermorel criticó prácticas establecidas como Requests for Proposals, el forecast de time series y las fórmulas de safety stock y service levels, argumentando que están desactualizadas y carecen de sentido económico. Enfatizó que AI no puede rectificar estos problemas profundamente arraigados, ya que aún no ha alcanzado la inteligencia a nivel humano. Vermorel sugirió que los ajustes prácticos basados en la experiencia de los profesionales suelen compensar estos métodos defectuosos. La conversación concluyó con una sesión de preguntas y respuestas, resaltando el desafío que representa eliminar procesos arraigados en grandes empresas.

Resumen Extendido

En un reciente episodio de LokadTV, Conor Doherty, Director de Comunicación en Lokad, mantuvo una discusión que invita a la reflexión con Joannes Vermorel, CEO y fundador de Lokad, sobre las trampas de las iniciativas de AI en la gestión de supply chain. La conversación, que tuvo lugar en el nuevo estudio de Lokad, giró en torno a la afirmación de Vermorel de que los enfoques tradicionales de supply chain, particularmente aquellos que involucran AI, son fundamentalmente defectuosos y probablemente fracasarán.

Vermorel comenzó criticando las prácticas arraigadas en la gestión de supply chain, que él cree han permanecido estancadas desde finales de los años 70. Argumentó que simplemente añadir AI a estos métodos desfasados no es una solución, sino un ejercicio inútil. Vermorel enfatizó que los fracasos de iniciativas pasadas en supply chain, incluso aquellas lideradas por ingenieros sumamente inteligentes, deberían servir como advertencia contra la excesiva dependencia en AI.

Conor Doherty retó a Vermorel señalando que muchos ven a AI como una panacea para los problemas de supply chain. Vermorel respondió resaltando las limitaciones de AI, utilizando el ejemplo de ChatGPT. Explicó que si ingenieros sumamente inteligentes han fracasado en resolver estos problemas, es irreal esperar que AI, que aún no ha alcanzado la inteligencia a nivel humano, tenga éxito. Subrayó que AI puede reducir costes y mejorar la eficiencia en áreas donde ya se conocen soluciones, pero no puede solucionar problemas fundamentalmente defectuosos.

La discusión luego profundizó en los detalles de por qué Vermorel cree que las prácticas actuales de supply chain están equivocadas. Identificó cuatro áreas clave: Requests for Proposals (RFPs), forecast de series de tiempo, fórmulas de safety stock y service levels. Vermorel argumentó que los RFPs, particularmente para enterprise software, son disfuncionales porque asumen un nivel de conocimiento y especificidad que es irrealista. Comparó el proceso con la redacción de una especificación detallada para un smartphone sin comprender sus complejidades, lo que conduce a un proceso de selección que a menudo descalifica a los mejores proveedores.

El forecast de series de tiempo, según Vermorel, es otra práctica defectuosa. Explicó que los datos de series de tiempo pueden ser engañosos porque no capturan matices críticos, como la diferencia entre tener un cliente principal y muchos clientes más pequeños. Esta falta de granularidad puede conducir a una toma de decisiones deficiente y a un mayor riesgo.

Las fórmulas de safety stock y los service levels también fueron criticados por ser no económicos y excesivamente simplistas. Vermorel argumentó que estas métricas no consideran el contexto económico más amplio y a menudo conducen a decisiones subóptimas. Sugerió que un enfoque más holístico, que considere el sistema en su totalidad y su impacto económico, sería más efectivo.

Conor Doherty señaló que muchas empresas aún logran un éxito significativo utilizando estos métodos defectuosos. Vermorel lo reconoció, pero lo atribuyó a los ajustes prácticos basados en la experiencia que realizan los profesionales en el terreno, en lugar de a los modelos teóricos enseñados en la gestión de supply chain. Argumentó que estos profesionales a menudo dependen de hojas de cálculo y ajustes manuales para corregir las deficiencias de los métodos establecidos.

La conversación concluyó con una sesión de preguntas y respuestas en la que se atendieron las inquietudes del público. Vermorel reiteró que el principal obstáculo para el cambio en las grandes empresas es la dificultad de eliminar procesos arraigados. Enfatizó que añadir nuevas tecnologías, como AI, resulta más fácil que eliminar prácticas desfasadas, incluso cuando lo último conduciría a mejores resultados.

En resumen, la perspectiva de Vermorel es que las prácticas tradicionales de supply chain son fundamentalmente defectuosas y que AI, aunque útil en ciertos contextos, no puede solucionar estos problemas profundamente arraigados. Aboga por un enfoque más sólido desde el punto de vista económico que considere el sistema en su totalidad y sus complejidades, en lugar de depender de métricas simplistas y desfasadas.

Transcripción Completa

Conor Doherty: Bienvenidos a LokadTV, transmitiendo hoy en vivo desde nuestro nuevo estudio, francamente encantador. Concluimos 2024 con un tema inofensivo y desenfadado basado en su discusión en SCT Tech. Joannes Vermorel, a mi inmediata izquierda, explicará su perspectiva sobre por qué las iniciativas de AI en supply chain probablemente estén condenadas a colapsar y fracasar. Siéntanse libres de enviar sus preguntas en la transmisión en vivo en cualquier momento, y las atenderemos un poco más adelante. Mientras están aquí, suscríbanse al canal de YouTube y sígannos en LinkedIn.

Y un último asunto organizativo antes de comenzar a hablar sobre cuán más inteligentes somos que los demás. Sería descortés no reconocer el esfuerzo de tantos para hacer que el estudio que ven ante ustedes sea tan agradable. Todo, desde las pantallas detrás de mí hasta los micrófonos frente a Joannes y a mí, es resultado de mucho trabajo en Lokad, particularmente por Maxime Larrieu detrás de la cámara y Baptiste Grison. Así que muchas gracias a ambos por sus esfuerzos. Y con eso, Joannes, te pregunto, ¿por qué la gente es tan estúpida?

Joannes Vermorel: En términos generales, creo que es la maldición de la especie humana, incluyéndome a mí mismo. Pero, en realidad, con este título provocador, solo quería llamar la atención sobre el hecho de que lo que normalmente refiero como el enfoque tradicional de supply chain ha sido en gran medida disfuncional durante las últimas cuatro décadas. Ha sido prácticamente un callejón sin salida en términos de tecnologías y prácticas. Lo que las empresas hacen hoy en día apenas ha cambiado conceptualmente desde finales de los 70. Son las mismas recetas numéricas, las mismas ideas, y no está funcionando demasiado bien.

Ahora, la idea de que puedes simplemente tomar las cosas como son y añadir un poco de polvo mágico de AI encima para que de repente esos problemas desaparezcan, creo que esto es una locura o, como dice el título, estupidez. De nuevo, no creo que la gente fuera estúpida a finales de los 70 para intentar eso. Solo digo que, tras cuatro décadas de fracasos consecutivos, nunca aprender de tus errores pasados es donde comienza la estupidez. Cuando veo empresas que intentan revisar, manteniéndose en los mismos enfoques y procesos en su supply chain con AI generativa, no hace falta esperar a ver cómo se desarrollan las cosas. Ya sé que simplemente no funcionará. Será solo una gran pérdida de tiempo, energía y dinero.

Conor Doherty: Pero muchas personas, de hecho, ven a AI como una especie de solución milagrosa cuando se trata de iniciativas de supply chain. Como que lo que esté roto, defectuoso o basado en suposiciones pobres será remedido por la inserción de Gen-AI, por ejemplo. ¿Entonces estás diciendo fundamentalmente que ese es un enfoque equivocado?

Joannes Vermorel: Absolutamente. Pausémonos un segundo. Imaginemos que ChatGPT fuera tan inteligente como un ingeniero del MIT. Excelente, ahora tenemos inteligencia artificial general. Resulta que muchos competidores de Lokad durante las últimas cuatro décadas han hecho exactamente eso. Toman ingenieros del MIT, les asignan grandes proyectos de supply chain, y la ambición es eliminar las hojas de cálculo y automatizar las decisiones. Son muy inteligentes, se les da presupuesto y tiempo, y sin embargo han estado fracasando.

Esos fracasos no son excepcionales. Prácticamente, cualquier empresa que yo conozca que supere, digamos, mil millones de dólares en facturación y tenga más de, por ejemplo, 20 años de antigüedad, probablemente tiene tres o cuatro iniciativas de supply chain fallidas en su haber. Iniciativas destinadas a eliminar las hojas de cálculo introduciendo recetas numéricas más inteligentes e integradas, y fracasaron. Entonces, la pregunta es: si fallaron usando ingenieros muy inteligentes, ¿por qué pensarías que al usar algo de inteligencia inferior, porque seamos honestos, ChatGPT aún no es inteligencia a nivel humano, va a tener éxito?

La automatización de la inteligencia, el beneficio es el costo. Por ejemplo, en Lokad, hemos robotizado la traducción de nuestro sitio web. Ahora, si miras el sitio Lokad.com, está disponible en muchos idiomas. Durante una década, lo hicimos con traductores profesionales. Ahora se realiza automáticamente con grandes modelos de lenguaje. Excelente. Lo que hemos ahorrado es una cuestión de costo, pero fundamentalmente, era un problema que ya sabíamos resolver manualmente con personas. AI no resolvió un problema irresoluble, que era la traducción. Solo nos permitió hacerlo de forma más barata y rápida, lo cual es genial.

Pero ahora, si volvemos al problema inicial, que es la predictive optimization de supply chain, si todos tus intentos previos han fallado a pesar de contar con ingenieros muy inteligentes, ¿por qué crees que disponer de instrumentos menos ingeniosos y un poco más sofisticados realmente marcará la diferencia?

Conor Doherty: Lo que acabas de mencionar lleva a esta pregunta: cuando usas el término estupidez, solo quiero desglosarlo un poco. Sé que fue deliberadamente provocativo, pero aun así, cuando hablas de empresas que toman decisiones basadas en suposiciones erróneas, y entraremos en detalles, pero cuando dices que las empresas repiten errores, eso es una forma de equivocación. Quizás se pueda clasificar generosamente como estupidez. También existe una alternativa, que es la ignorancia. La ignorancia es neutral.

Estupidez, tonto, imbécil—estos términos originalmente aparecían en la literatura psiquiátrica y se refieren a un deterioro cognitivo. Denotan un significado muy específico. La ignorancia es neutral. Tú y yo tenemos coeficientes intelectuales de 180 en un mal día, pero ambos somos ignorantes de muchas cosas. No sé nada de botánica, no sé nada de cómo se hacen los cordones, pero no soy estúpido. No me falta la infraestructura neurológica para aprender estas cosas; simplemente no tengo el tiempo ni acceso a la información. Entonces, sobre la pregunta, tienes empresas que toman decisiones equivocadas resultando en resultados terribles o subóptimos, y luego tienes empresas que realmente no conocen la existencia de paradigmas alternativos. ¿Consideras que son dos representaciones justas del problema, o lo ves simplemente como gente siendo estúpida y cometiendo errores?

Joannes Vermorel: Sí, es una representación justa del problema, lo que nos lleva a analizar en qué exactamente estamos interesados. Cuando observamos los detalles, podemos decidir si estamos hablando de estupidez o de ignorancia. Mi propuesta para hoy es que, al observar los detalles, es tan obvio que afirmar que es ignorancia es exagerado.

Conor Doherty: Vamos a entrar en los detalles. Tienes cuatro pruebas clave, o cuatro formas de demostrar lo que ves como el problema de la estupidez natural o la ignorancia natural en la toma de decisiones corporativas. Son los RFPs, el forecast de series de tiempo, las fórmulas de safety stock y los service levels. Abordaremos cada uno de forma sistemática, pero en resumen, ¿qué es lo que, en esos cuatro conceptos, crees que demuestra tu posición?

Joannes Vermorel: He escogido cuatro, pero podrían ser 20. Al menos cuatro ingredientes principales de la teoría y práctica tradicional de supply chain. Estos son ingredientes que probablemente se pueden encontrar en el 90% de las grandes empresas. Para las empresas más pequeñas varía mucho, pero esas prácticas tienden a ser bastante uniformes entre las grandes empresas. Debido a que están muy extendidas, podemos analizarlas y preguntarnos: ¿tiene siquiera sentido esto? ¿Necesito un doctorado del MIT para darme cuenta de que es puro sinsentido o no?

Si en un minuto puedes darte cuenta de que es puro sinsentido con solo un examen cuidadoso, definitivamente estamos en el campo de la estupidez. Si la única manera de reconocer que estás en error es realizar un experimento muy sofisticado y elegante que requiere mucho financiamiento y tiempo, entonces esto es mucho más un error en la categoría de la ignorancia.

Conor Doherty: Como dije, analicémoslos de forma sistemática. Entonces, la primera prueba en tu argumento es la existencia de los RFPs. Ahora, supongo que eso abarca solicitudes de propuestas, solicitudes de presupuestos, solicitudes de información, etc. ¿Es así?

Joannes Vermorel: Sí, y de nuevo, específicamente para software empresarial dedicado a la optimización de supply chain. Podemos hablar acerca de… No estoy discutiendo si el RFP es la manera adecuada de abastecerse de papel a granel o de alguna especie de commodity súper obvio. El contexto es supply chain, sí. Y más específicamente, porque de nuevo, si quieres tener impresoras de códigos de barras para tu supply chain, esto no es de lo que estoy hablando. Estoy hablando específicamente de lo que quieras abastecer que vaya a atender tu proceso de toma de decisiones. Por supply chain, a eso me refiero. No me refiero a logística, no me refiero a contratar truck conductores. Me refiero a los procesos de toma de decisiones que gobiernan el flujo. Así que todos los pormenores de qué compras, qué produces, a qué precio vendes, dónde colocas tu inventario, todo eso.

Conor Doherty: Bueno, entonces te lo devuelvo inmediatamente. ¿Qué tiene de malo usar el proceso de RFP para seleccionar un proveedor?

Joannes Vermorel: Las RFPs son completamente disfuncionales. Si quieres tener una idea de cómo es una RFP, imagina que tuvieras que escribir en un documento de Word todas las cosas que esperas de tu smartphone. Es un sinsentido. No lo sabes. Tiene un bazillón de funciones. La mayoría de tu smartphone funciona gracias a muchas cosas de las que no tienes idea. Listar todas esas funciones es una cantidad inmensa de trabajo, y si listaras lo que crees que hace tu smartphone, lo más probable es que te equivoques en muchísimas cosas.

Imagínate que tienes cientos de puntos de ítems que necesitas cubrir, y ¿cuáles son las probabilidades de que al producir esas cientos de páginas de requerimientos para tu smartphone, termines con un documento que descalifique tanto a Samsung como a Apple? Muy probablemente lo harás.

El software empresarial es extremadamente complejo, y esta complejidad refleja principalmente el problema que quieres resolver. La optimización de supply chain es en sí misma muy compleja y bastante complicada, así que no puedes esperar una respuesta súper simple. No estás comprando hierro por tonelada ni crude oil. Estás comprando algo muy sofisticado, y eso significa que no tienes proveedores que sean sustitutos unos de otros. No hay una correspondencia uno a uno entre lo que ofrece el proveedor X y el proveedor Y.

El problema con las RFPs es que asumen que ya conoces exactamente tu solución, que puedes tener una especificación completa, y luego quieres canalizar, supuestamente, a una gran cantidad de proveedores dentro de tu lista de requerimientos. El software simplemente no funciona así. Producir un buen software lleva aproximadamente una década, más o menos. Ningún proveedor va a adaptar radicalmente su tecnología para tu RFP. Estás canalizando a todos a través de cientos de páginas de sinsentido.

El proceso tiene tan poco sentido que, usualmente, cuando recibimos RFPs, terminamos con algo entre 400 y 600 preguntas, y esas preguntas están llenas de errores ortográficos. Muy frecuentemente, incluso el nombre de la empresa cliente está mal escrito en el documento porque a la gente no le importaban las preguntas en sí. Se las delegó a pasantes, a consultores, a lo que fuera. Produces una gran cantidad de papeleo, y nadie siquiera sabe lo que significan la mitad de las preguntas porque están tan mal redactadas. La mayoría de las preguntas ni siquiera son preguntas, sino requerimientos disfrazados.

Luego, el proveedor responde con docenas, posiblemente cientos de páginas de respuestas que nadie lee. Hay un comité que lo evalúa en etapas, y la idea de que se llegará a una decisión racional a partir de este proceso completamente irracional es simplemente alucinante. No hay nada en la vida real en lo que tú, como individuo, te involucrarías en un proceso tan insano. ¿Por qué crees que de repente, solo porque operas para una gran empresa, lo que de otro modo parecería completamente insano en tu día a día, de repente tendría sentido solo porque es la práctica de una gran corporación? No lo tiene.

Conor Doherty: Bueno, de nuevo, un par de puntos para desmenuzar, porque hay mucho. Primero que nada, ¿tu crítica es sobre… Oh, disculpa, déjame retroceder. He visto algunas de las RFPs de las que hablas. He visto algunos ejemplos como, “¿Todavía tienes una máquina de fax? ¿Guardas tus reportes de fax en gabinetes ignífugos?” Quiero decir, he visto estas cosas. Por supuesto, eso es completamente absurdo. Esa es una RFP en su estado actual. ¿Estás diciendo que, en un vacío y desvinculado de cualquier mala ejecución, en general, el concepto de RFPs para intentar encontrar un software es simplemente algo absolutamente insano de hacer? Y si la respuesta es sí, por favor explica cuál sería la alternativa.

Joannes Vermorel: No, la idea de hacer investigación de mercado no es insana. Obviamente, si quieres elegir un proveedor, tienes que hacer algo de investigación de mercado. La idea de que tienes que operar a través de las prácticas establecidas de RFI y RFPs es un sinsentido. Ese es mi punto. Mi punto es que esas prácticas son profundamente defectuosas, profundamente, profundamente defectuosas. Cuando tienes un proceso que es completamente disfuncional, entonces la improvisación es mucho mejor.

Si estás haciendo algo que no funciona, que es tan terrible, deja de hacerlo, y prácticamente cualquier otra cosa será mejor. Cualquier cosa que no sea incluso más burocrática. Mi opinión es que esas grandes empresas se beneficiarían más con un proceso informal, y eso es todo. Si estás dispuesto a considerar la idea de tener una versión superior del proceso, entonces también hay un camino alternativo. Se discute en una de mis conferencias sobre investigación de mercado adversarial, donde expongo una manera mejor de hacerlo. Pero incluso en ausencia del conocimiento de esta mejor forma, simplemente eliminar este proceso absurdo ya sería una mejora.

Tener un proceso súper burocrático no es algo bueno. Es algo terrible. Ralentiza todo, diluye la responsabilidad de todos y selecciona proveedores de forma adversa. Imagina, de nuevo, volvamos a Apple. ¿Realmente crees que Apple, si haces una RFP para ellos, realmente te prestarán atención? ¿Modificarán su precioso iPhone para complacer tus requerimientos corporativos? No, no lo harán. Así que, lo que efectivamente estás haciendo es que los buenos proveedores se excluyan voluntariamente de tu investigación de mercado, lo cual es un sinsentido total. Eso es lo opuesto a lo que quieres.

Mi opinión es que cuando tienes algo como un cáncer, quita el cáncer y no te preguntes, “¿Qué pongo en lugar del cáncer?” Si has eliminado el cáncer, ya has hecho algo bueno. Es una mejora. Ahora, podemos entonces discutir qué podría ser aún mejor, qué poner en su lugar, pero la primera etapa es reconocer que al eliminar el cáncer, estás mejorando la situación.

Desafortunadamente, y ahí es donde entra la estupidez burocrática, es pensar que la única alternativa a una pesadilla burocrática es otro tipo de pesadilla burocrática. Esto es un sinsentido total. Claramente, en mis 15 años en el mundo de los negocios, nunca he visto una RFP que no fuera profundamente, profundamente disfuncional. Son solo variaciones entre los círculos del infierno. Algunas RFPs son como el quinto círculo del infierno, otras son como el noveno círculo del infierno. Son solo variaciones en términos de intensidad de pesadilla, pero de otro modo, son uniformemente súper, súper malas.

Conor Doherty: Eso fue Thomas Sowell y Dante Alighieri en el lapso de 60 segundos. Fue muy bueno. Bueno, en realidad, eso transiciona desde el primer punto, que trata sobre las RFPs y la crítica a las RFPs y RFQs, etc. Es una especie de cómo podrías seleccionar un proveedor de AI.

Joannes Vermorel: Exactamente.

Conor Doherty: Si puedo terminar la pregunta, porque estoy haciendo una transición. El segundo punto, sin embargo, es que, una vez que has seleccionado un proveedor de AI, aquí es donde pasamos al segundo punto, que es el forecast de series de tiempo, el cual citas como la segunda prueba de por qué tu iniciativa de AI va a fracasar. Ahora, esto es una vez que ya has seleccionado un proveedor. ¿Cuál es el problema con las series de tiempo?

Joannes Vermorel: Entonces, una vez que has seleccionado… Primero, lo más probable es que, gracias a tu RFP, selecciones un proveedor muy malo. Eso es un hecho. Tienes un proceso que no tiene ningún sentido, así que lo más probable es que obtengas uno de esos peores proveedores que se especializan en hacer todo lo que cumple con esas RFP, sin importar la cantidad de sinsentido. Ya estás en una situación donde el fracaso es casi seguro, incluso si el proveedor no fuera tan disfuncional. Pero realmente has seleccionado al proveedor disfuncional desde el principio. Ahora, lo que me lleva a las series de tiempo.

Las series de tiempo son como el Alfa y la Omega de la perspectiva actual del supply chain mainstream. ¿Qué es una serie de tiempo? Es simplemente una serie de puntos de acuerdo a un período dado. Eso será un valor por día, un valor por semana o por mes. Cuando digo perspectiva de series de tiempo, significa que observas todo a través de tus ventas o tu flujo diario, semanal o mensual agregados. Todo encaja de alguna manera en esas series de tiempo.

Obviamente, con esas series de tiempo, lo que quieres, o al menos según la teoría mainstream de supply chain, lo que deberías querer son forecasts de series de tiempo, que es la extensión de esas series hacia el futuro. Si tienes tus datos de ventas hasta hoy, quieres tener el forecast, que es simplemente esas series extendidas al futuro. Así tienes la cantidad de ventas para mañana, para pasado mañana, etc.

Conor Doherty: ¿Qué tiene de malo que se te proporcione un dato accionable para planificar, por ejemplo, que la demanda de la próxima semana será de 10 unidades? Eso suena genial.

Joannes Vermorel: El problema principal es que tu supply chain no puede ser representado de manera significativa con series de tiempo. ¿Y qué significa eso?

Bueno, comencemos con una situación súper básica. Tienes un producto que se vende de manera constante a 1,000 unidades al día. Ha estado vendiéndose a 1,000 unidades al día durante, digamos, los últimos tres años. Súper bien. Ok, ¿cómo se ve el futuro? Ahora, voy a observar dos situaciones diferentes que tienen exactamente la misma historia. Situación número uno: tienes mil clientes distintos, y de vez en cuando hacen un pedido de un producto. En conjunto, esos 1,000 clientes te dan 1,000 unidades al día. Algunos clientes se van, otros llegan, pero es muy estable. Entonces, eso es lo que genera la serie de tiempo. Ahora, ¿qué te dice eso? Te dice que tienes una demanda muy constante que parece bastante robusta. Mil clientes no son millones, pero tampoco es cero, así que se ve bien.

Ahora, la segunda situación es que tienes 1,000 unidades al día, pero de un solo cliente. Sí, este cliente ha sido muy constante, pidiendo 1,000 unidades al día durante los últimos años, pero es un solo cliente. Ahora, ¿cuáles son las probabilidades de que la demanda caiga mañana a cero y se mantenga en cero para siempre? Obviamente, desde la primera perspectiva, donde tienes mil clientes, no diría que es imposible, pero es muy remota. Incluso si tuvieras un evento catastrófico que dañara la marca, la mayoría de los clientes ni siquiera se enterarían. Incluso si tuvieras un caso masivo de fraude, aún tendrías cientos de clientes que no se enterarían durante meses. Entonces, las probabilidades de que todos esos clientes, en perfecta coordinación, dejen de comprar de ti el mismo día, no es imposible, pero es una probabilidad muy, muy baja. Estamos hablando probablemente de una en un millón. Es raro.

Ahora, lo contrario, si tenemos un solo cliente, entonces basta con que un único gerente decida elegir a un proveedor diferente, y ¡bam!, pasas a cero. Si dices que vas a perder a este cliente leal una vez cada década o así, estamos hablando de una probabilidad del 0.1%. No es una en un millón; es varias órdenes de magnitud mayor. Aún es improbable, pero en comparación con la primera, es algo que, lo más probable, sucederá en unos pocos años. Dado suficiente tiempo, algo como una década, es casi seguro que suceda. Aquí, solo estoy describiendo dos situaciones muy básicas que tienen exactamente la misma representación en series de tiempo. Ese es el meollo del problema: las series de tiempo son simplistas. Puedes tener varias situaciones que son completamente diferentes y, sin embargo, tienen exactamente las mismas series de tiempo.

Conor Doherty: Y eso importa. ¿Por qué?

Joannes Vermorel: Porque tus decisiones son muy diferentes. Si tienes mil clientes, puedes ser muy conservador con el inventario. Puedes decir, por ejemplo, “Oh, vamos a tener muchos meses de inventario en stock porque está bien. Si perdemos algunos clientes, ajustaremos la producción para que no tengamos un gran exceso de stock. Incluso si perdemos clientes, aún tendremos tiempo para liquidar el inventario.” Por el contrario, si tienes solo un cliente, eso significa que si ese cliente deja de comprar, tu stock se convierte en stock muerto de la noche a la mañana. Lo único que te queda es una baja garantizada del inventario por todo lo que tienes en stock.

Así que, ya ves, en términos de decisiones de supply chain, tienes dos situaciones muy diferentes que requieren decisiones muy distintas. Por eso digo que las series de tiempo son insanas. La hipótesis es que si enmarcas todo como series de tiempo, que es exactamente lo que hace el supply chain mainstream, entonces puedes tomar decisiones razonables. Lo que digo es que no, no puedes. No puedes porque las series de tiempo no te permiten captar algunas nociones básicas sobre tu actividad. Estás completamente ciego. No importa si tienes más series de tiempo. De nuevo, volvemos a este caso de un cliente versus 1,000 clientes. No importa si tienes más series de tiempo; sigues atrapado con el hecho de que es una mala representación de tus datos. Es una representación súper simplista de tus datos.

Conor Doherty: Disculpa, solo para asegurarme de aclarar para quien no entienda a lo que te refieres, desde la perspectiva de la gestión de riesgos, tienes que tener enfoques diferentes en términos de asignación financiera porque tu exposición es distinta.

Joannes Vermorel: Es muy diferente. De nuevo, si observamos los artículos perishable en una tienda, las series de tiempo te permitirán representar tu stock level a lo largo del tiempo. Entonces, ¿cuántas unidades tienes en stock en tu tienda, digamos, de yogures? Pero la realidad es que tus productos son perecederos, por lo que tienen fechas de caducidad. Considera, de nuevo, que tienes 10 unidades en stock. Esa es una perspectiva de series de tiempo. El día anterior, tenías 11 unidades, o lo que sea. Tienes tu nivel de stock en curso. Esa es una representación de series de tiempo. Ahora estás pensando, “Tengo 10 unidades en stock. ¿Es bueno o no? ¿Es suficiente o no?”

Permítanme ver dos situaciones. Situación A: los 10 yogures que tienes en stock expirarán dentro de un mes. Eso es bueno. Alguien que entre a la tienda encontrará yogures con un mes de vida en anaquel. Es agradable para los yogures. Ahora, situación B: los 10 yogures expiran mañana. Esto es muy malo. A tus clientes no les gustará recoger yogures que expiran mañana. Tal vez un cliente compre uno solo para consumir al día siguiente, pero cualquier madre que haga las compras para una familia y quiera organizar las cosas para la semana no comprará yogures que van a expirar mañana.

Así que, bajo la misma representación, 10 unidades hoy, que es un nivel de stock, te falta una información muy importante, que es la composición de las fechas de expiración. Si tienes un sistema de software completamente diseñado en torno a esta idea de series temporales, esta información siempre será ignorada por el sistema porque el sistema ni siquiera puede verla. No es parte del paradigma de series temporales.

Conor Doherty: Y de nuevo, para ser muy explícito para quien escuche, diciendo, “Está bien, oigo todo eso, entiendo lo que estás diciendo, sigo los ejemplos. ¿Cómo influye eso en la IA? ¿Cómo encaja la IA en ese panorama?” Incluso si estás usando series temporales o forecast probabilístico.

Joannes Vermorel: Si tienes un paradigma en el que se pierde la información clave, ese es el caso con las series temporales, no importa si la persona que mira las series temporales es una IA o un ingeniero muy inteligente o quien sea. La información clave ya se ha perdido. Si miras tus datos de ventas a través del lente de las series temporales, no puedes ver esto de uno contra muchos clientes. No puedes ver las fechas de expiración. Hay muchas cosas que simplemente no ves. Si no ves, ya sea una IA, un ingeniero inteligente, o un programa aplicando algunas reglas, la información central que necesitarías ya se ha perdido. No importa cuánta tecnología acumules sobre este paradigma.

Conor Doherty: Muy bien, avanzando un poco, hemos cubierto las dos primeras maneras: RFPs y series temporales. La tercera y cuarta se pueden agrupar posiblemente como métricas, que son los safety stock y los niveles de servicio. Discutiendo esos por separado o juntos, ¿cuál es tu objeción a estos? Porque son bastante comunes. La mayoría de las empresas mantienen políticas bastante estrictas de safety stock y de niveles de servicio.

Joannes Vermorel: El problema con el safety stock, para la audiencia, es que se asume que tienes un forecast de demanda basado en series temporales, y asumes que tu demanda se distribuye normalmente, que tus lead times se distribuyen normalmente, y luego eliges tu nivel de servicio. Eso te dará una cantidad objetivo de stock para mantener a mano, y eso es lo que se llama safety stock. Eso es lo que realmente es el safety stock.

Técnicamente, tienes el stock de trabajo, que es la demanda promedio, y luego el safety stock es el componente extra sobre la demanda promedio. Pero eso es una tecnicidad. En general, si sumas el stock de trabajo más el safety stock, eso te daría la cantidad objetivo de stock que deseas mantener.

¿Cuál es el problema con eso? El problema es que es la forma incorrecta de ver la gestión de inventario. El objetivo de la empresa es obtener beneficios. El safety stock es una perspectiva no económica en esas decisiones. ¿Qué significa eso? Significa que es algo que ni siquiera intenta optimizar los beneficios. El problema es que tenemos algo que ni siquiera intenta optimizar los beneficios. ¿Por qué crees que esto va a ser bueno en términos de beneficio?

¿Cómo optimizas realmente para obtener un beneficio? Bueno, es muy simple. Miras, digamos, una situación sencilla, una tienda. Escoges la primera unidad de inventario que maximizará tus retornos. Elijo esta y la pongo en la tienda. Esa es la que me da el mayor retorno. Escojo la primera unidad que hace eso, y luego tengo que repetir el proceso con una segunda unidad que maximice los retornos. Debido a que es una tienda, lo más probable es que la segunda unidad que escoja no sea el mismo producto que la primera unidad.

El punto es que quiero distribuir mis unidades extra para cubrir más demanda. Si te digo que solo puedes pedir una primera unidad, eliges una unidad. Ahora, si digo que puedes escoger una segunda unidad, lo más probable es que quieras tomar otra cosa porque, como mínimo, deseas aumentar tu cobertura en términos de demanda para la tienda. Si te digo que puedes escoger una tercera unidad, nuevamente escogerás algo ligeramente diferente.

El punto que estoy subrayando es que la perspectiva del safety stock adopta un enfoque completamente no económico. Mira un producto en una tienda y, nuevamente, para la audiencia, un mini mercado tendría como 5,000 productos distintos en los estantes. Mira un producto de forma aislada y luego decides de forma aislada si quieres más o menos. Estoy diciendo que esto es absurdo.

Nuevamente, echemos un vistazo. Si tienes que hacerlo manualmente, estás en una tienda de comestibles. No pensarías de forma aislada si necesitas más o menos de algo. Es un compromiso. Tienes espacio limitado en los estantes, tienes una cantidad limitada de dinero, así que pensarías, “¿Tengo suficiente de esto? ¿Debería reordenar suficiente de este producto, o hay algo más que debería reordenar primero?” Así es como se piensa en términos de retorno de la inversión. Así es como puedes pensar en términos de una perspectiva económica.

Lo que digo es que el safety stock es una perspectiva no económica. Es una perspectiva matemáticamente interesante, al menos desde un punto de vista educativo, tal vez para estudiantes de matemáticas aplicadas, solo para darles un pequeño ejercicio o algo así. Pero si tenemos que llegar a una supply chain real, y de nuevo, estoy tomando una situación muy simple como una tienda de comestibles, que es de lo más simple que puedes imaginar, vemos que es una perspectiva no económica. Así que tenemos un problema, Houston. Esto ni siquiera intenta mejorar el resultado final de mi empresa. Esto es simplemente incorrecto.

La alternativa que he descrito es bastante sencilla. Se trata de elegir las cosas que me dan los mayores retornos. Escojo la primera unidad y luego la segunda, etc. Podemos profundizar en las tecnicidades de exactamente cómo hacemos eso, pero esas son tecnicidades. Mi crítica al safety stock es que no puede ser un enfoque razonable porque es un enfoque no económico. En la práctica, con mucha frecuencia terminas con situaciones sin sentido. Por ejemplo, calculas de acuerdo a tus safety stocks todas las cosas que deberías poner en tu tienda, y no encaja.

Lo que ves es que ahí es donde terminas con una situación insana. Terminas con tu safety stock diciéndote que todos esos productos necesitan todas esas unidades, y debido a que todo se hace de forma aislada, tienes 5,000 productos, y para cada producto obtendrás una cantidad. Cuando sumas todas esas cantidades, no encaja.

Si volvemos a tu IA, ¿qué se supone que debe hacer tu IA? De nuevo, tu paradigma dice que calculas tu safety stock. Tu IA tal vez pueda ayudarte a calcular con mayor precisión el safety stock. Ni siquiera estoy seguro de cómo ayudaría eso exactamente. Pero la realidad es que tienes un paradigma que está roto por diseño. Tu IA, sin importar cómo calcule tu safety stock, aún terminará con esa extraña paradoja. ¿Qué significa incluso mejorar si tienes una perspectiva no económica? Tu IA no puede conjurar significado de algo que no tiene un significado económico.

Conor Doherty: Antes de abordar los niveles de servicio, quiero retomar un punto que mencionaste ahí. Describiste los safety stocks como una perspectiva no económica. Lo entendí. También hablaste sobre usar SKUs de forma aislada, y eso es defectuoso. Bueno, entonces lo opuesto es presumiblemente mirar las cosas en combinación. ¿Podrías esbozar un poco más ese punto acerca de la aislación versus la combinación?

Joannes Vermorel: Sí, quiero decir, de nuevo, la supply chain es un sistema. Eso significa que no puedes desconectar las partes sin cambiar su naturaleza. Un producto vendido en un estante en una tienda de comestibles no es lo mismo si vendo ese producto de forma aislada. La gente, cuando va a una tienda de comestibles, espera una variedad de productos, no solo un producto. Y eso es lo mismo para prácticamente cualquier supply chain que no sea trivial. Una supply chain real va a ser así. Si estás produciendo autos, tienes que juntar todas esas partes para tener vehículos funcionales al final del día. No puedes quitarle las ruedas y decir que esto es un auto. Un auto sin las ruedas no es un auto; es simplemente otra cosa.

Fundamentalmente, tienes sistemas donde hay muchos tipos distintos de bienes físicos, y solo tienen sentido cuando se juntan. Obviamente, no significa que, en un auto, si le quitas las ruedas, entonces el auto no funcione en absoluto. En una tienda, puedes decidir que tal vez no quieras tener mostaza en el estante. Tal vez a los clientes les esté bien que no la tengas, o por el contrario, necesitas tener tres tipos distintos de mostaza.

Obviamente, hay mucha sutileza dependiendo de lo que estés observando. No es algo blanco o negro. Pero fundamentalmente, cuando comienzas a vender mostaza en una tienda de comestibles, solo tiene sentido en cuanto a lo que vendes que va junto con ella. Así que lo que estoy diciendo es que cuando adoptas una perspectiva que pone esas cosas de manera aislada, te estás perdiendo lo esencial. Te estás perdiendo lo que hace que la tienda sea atractiva. Te estás perdiendo el punto de la dinámica que ocurre.

La gente entra a tu tienda de comestibles y no compra un solo artículo. Algunos clientes pueden entrar y comprar un artículo, pero la mayoría tendrá una canasta y muchos artículos. Así que lo que digo es que cuando optas por esta perspectiva de safety stock, adoptas una perspectiva matemática muy extraña y super simplista que sitúa tus SKUs, tus productos, en un estricto aislamiento unos de otros. Incluso considerando el tipo más simple de supply chain que puedas imaginar, como una tienda de comestibles, ya no tiene ningún sentido. Entonces, ¿por qué pensarías que va a tener más sentido en algo que sea más complicado, como aviation MRO o algo más?

Conor Doherty: Lokad tiene un término específico para eso, como la perspectiva de la canasta. Creo que en realidad publicamos una flash card en LinkedIn hace un par de semanas o tal vez un mes describiéndolo. Como dijiste, la gente normalmente no entra a un supermercado y compra solo una cosa. Comprarán con una lista en mente, y la ausencia de una cosa puede llevar a pérdidas. Si la gente compra múltiples cosas, entra y compra 10 artículos, y el undécimo artículo que querían no estaba y es un artículo crítico, no solo pierdes las ventas del undécimo artículo. Si la persona se va debido a la ausencia del undécimo artículo crítico, pierdes la totalidad de las ventas en esa canasta. Así que es la perspectiva de la canasta. Hay una relación entre todas estas cosas.

Joannes Vermorel: Sí, y lo que pasa es que si volvemos al safety stock y la IA, una vez que has adoptado tu perspectiva de safety stock, no importa si tu IA es superinteligente o muy tonta, barata o cara, o lo que sea. Ya está atrapada en un rincón que es un mal lugar donde no habrá solución alguna. Por eso digo que la estupidez natural siempre supera a la inteligencia artificial. No importa la sofisticación de la tecnología, su accesibilidad, su mantenibilidad. Todo eso se vuelve completamente irrelevante por el hecho de que ya has enmarcado el problema de manera que carece de sentido.

Conor Doherty: Estoy de acuerdo contigo. Sí, estoy de acuerdo en eso, pero lo que diría es que creo que es un muy buen ejemplo de la distinción que mencioné anteriormente entre la estupidez natural y la ignorancia. Lo que acabamos de describir es un fenómeno real, pero es muy abstracto. Requiere un grado de comprensión acerca de la relación entre cosas que no es inmediatamente clara.

Joannes Vermorel: No estoy de acuerdo. Siempre que tengas una conversación con alguien que está completamente sin educación manejando una tienda, sabrá que no es magia. No estamos hablando de matemáticas súper avanzadas. Solo ve a cualquier tendero que lleve una semana haciendo eso, y entenderá que la variedad es algo que importa. No puedes pensar en la cantidad correcta de stock para un producto en completa aislación del resto.

De hecho, es una especie de absurdo muy elaborado que requiere de un profesor universitario para propagarlo. Es absurdo, y la única manera de promover exitosamente este tipo de idea es estar en un ambiente donde estés completamente protegido de las consecuencias reales de esta muy mala idea. Si dirigieras una tienda, no pensarías así. Puedes hacer una prueba: simplemente conversa con quien en tu vecindario esté manejando cualquier tipo de tienda. Si piensan así, no lo hacen. Si hablas con la persona que está administrando el inventario, quien está pasando la orden de reabastecimiento, como en las tiendas de Mom and Pop, obviamente pensarán en términos del conjunto.

Conor Doherty: Eso es en realidad un buen punto. Hay una distinción que se debe trazar, y me gustaría conocer tu opinión al respecto. La diferencia entre enormes conglomerados de miles de millones de dólares con supply chains increíblemente grandes que pasan órdenes, digamos, en términos de decisiones de supply chain, podría ser cientos de miles por día, y luego contrastas eso con las tiendas Mom and Pop donde es la tienda de Joannes y Joannes saca el dinero de su bolsillo para comprar estas cosas cada día.

Me recuerda a algo que dijo Peter Cotton cuando hablamos con él hace un año y medio. Dijo que tomas decisiones muy diferentes cuando es tu dinero en la mesa. La forma en que piensas acerca del problema es muy diferente cuando tienes que sacar el dinero de tu bolsillo. Así que, tengo curiosidad, ¿por qué ves que las empresas muy grandes toman malas decisiones, pero cuando diste el ejemplo de simplemente ir a la tienda de al lado? " Joannes Vermorel: Ahí es donde radica la locura. Las grandes empresas no toman esas malas decisiones porque, a pesar de lo que dicen, siguen los safety stocks. Las personas que emplean no lo hacen. Ahí es donde se vuelve una locura. ¿Cuál es el panorama real? El panorama es que hay profesores universitarios que dicen que hay que hacer safety stocks. Tienes libros de texto de supply chain que dicen que hay que hacer safety stocks. Tienes proveedores de supply chain impulsados por IA que dicen que tenemos safety stocks impulsados por IA. Genial. Luego, tienes empresas que tienen sistemas basados en safety stocks, o a veces se les llama buffers o lo que sea. Hay varios matices.

Al final del día, tienes empleados de supply chain llamados demand and supply planners, category managers, inventory managers—los títulos varían—que están usando sus hojas de cálculo para hacer algo completamente diferente. Usualmente, la reacción típica que recibo es que, cuando discuto con esas personas, me dicen, “Oh sí, los safety stocks, forman parte de nuestro plan para utilizarlos. El próximo año, cuando tengamos suficiente madurez, los usaremos de verdad. Pero por ahora, tuvimos tantos problemas, que estamos haciendo algo completamente diferente. Con mis hojas de cálculo, estoy haciendo las cosas de otra manera. Sé que es un desastre, pero funciona más o menos. Con más entrenamiento, algún día podré usar los safety stocks.”

Eso es una locura porque la realidad es que, sea lo que sea que esta persona esté haciendo, en realidad es algo que tiene sentido. Esta receta alternativa es simplemente lo que tiene sentido, y los safety stocks son solo la farsa, la farsa ambiental, que no está funcionando. No ha estado funcionando desde al menos 1979, como identificó Russell Ackoff. Esta es la razón por la que las hojas de cálculo nunca podrán desaparecer en ese contexto.

Cada vez que dices que vamos a reemplazar todas esas hojas de cálculo desordenadas con automatización de software, falla. Falla porque el safety stock es una mala idea. No importa si tienes safety stock impulsado por IA; sigue siendo una mala idea. Es una idea tan mala que no funciona. Las grandes empresas lo intentan, fallan y vuelven a las hojas de cálculo. La gente regresa a la actitud de, “Estoy haciendo algo un poco a mi manera. Cuando reciba más entrenamiento, usaré los safety stocks, pero por ahora, necesito algo que realmente funcione.”

Conor Doherty: En ese sentido, has explicado extensamente cómo los safety stocks tienen fallos. Presumo que una buena parte de la misma crítica se aplica a los service levels. No son exactamente lo mismo, pero en términos de procesos de toma de decisiones, ¿cuál es la política que estás implementando para llegar a una decisión? Explica cuál es tu problema con los service levels, por favor.

Joannes Vermorel: Mi problema con los service levels es que el service level es un proxy extremadamente defectuoso para la calidad del servicio. De hecho, tiene casi nada que ver con la calidad del servicio. Lo que se desea es atender bien a tus clientes. Eso es algo dado cuando operas una supply chain.

Ahora, consideremos una tienda de retail básica en moda. ¿Qué significa tener altos service levels? Si equiparas la alta calidad del servicio con el service level, eso significa que la alta calidad del servicio implica un alto service level. Si dices que el service level es un buen proxy para la calidad del servicio, entonces la alta calidad del servicio implica un alto service level.

Si tienes una tienda que vende una colección para tu marca de moda, ¿qué significa tener altos service levels? Efectivamente, significa que aún tienes todos los productos, al menos unas pocas unidades, en los estantes hasta el final de tu colección. Si tienes altos service levels, significa que tu tienda sigue llena de mercancía hasta el final de tu colección. ¿Cómo incorporas en tu tienda la siguiente colección?

Necesitas hacer espacio dejando ir la colección antigua, lo que significa aceptar que para esos productos, los service levels caerán a cero. Los clientes aún pueden estar muy satisfechos a pesar de que tengas un service level de cero para muchos productos. A medida que algunos productos se retiran, otros entran en juego, y tus clientes siguen estando muy contentos. No hay correlación alguna entre la calidad del servicio, que solo existe en la percepción del cliente, y lo que mides con tu receta numérica, que es el service level.

Si los service levels son un proxy extremadamente defectuoso para la calidad del servicio, ¿por qué crees que una IA que se supone que debe impulsar tus service levels va a hacer cosas que tengan sentido para tu empresa? Al igual que mi crítica al safety stock, esto no es una perspectiva económica. Aquí tienes un concepto, el service level, que no es una perspectiva de calidad del servicio. Le das un instrumento a tu IA, por lo que tu IA tiene que lidiar con este instrumento, el service level, pero resulta que este instrumento es completamente inadecuado para resolver el problema, que es la calidad del servicio.

Conor Doherty: Has utilizado un par de frases interesantes, una de las cuales fue “los service levels son un proxy extremadamente defectuoso para la calidad del servicio” y “la calidad del servicio solo existe en los ojos de los clientes”. Pero eso conduce a una pregunta de dos partes. Una, ¿cuál es un buen proxy? Y dos, si la calidad del servicio solo existe en los ojos de los clientes, ¿cómo se supone que las empresas deben saber realmente si tienen buena calidad del servicio?

Joannes Vermorel: Esas son muy buenas preguntas. Empecemos primero por observar los proxies. Hagamos algunos experimentos mentales. Esa es una manera de descartar los que son extremadamente malos. Ni siquiera necesitamos hacer un experimento real con una tienda real; podemos hacerlo como un experimento mental. Es muy económico. Entonces, lo primero es que debemos estar de acuerdo en que si tomamos una tienda con los mismos productos en los estantes, nada ha cambiado. Sea lo que sea que pensemos que es la calidad del servicio, no está cambiando. Si observo la misma tienda, con los mismos productos, en el mismo momento, y no cambio nada, entonces lo que entiendo como la calidad del servicio no debería cambiar.

Repasemos el service level. Muchas empresas miden el service level tomando el porcentaje de productos que están sin faltante de stock o que están disponibles. Si tienes el 97% de tus productos sin faltante de stock, tendrías un service level del 97%. Hay diferentes maneras de analizar el service level a través de faltante de stock. Esto es cuando haces una optimización de safety stock, lo que representa una perspectiva ligeramente diferente. Pero aquí, esta es la forma en que muchas empresas operan con este tipo de reporte, así que es la que voy a usar.

Ahora, imaginemos conceptualmente que hemos decidido que el surtido de la tienda se ha duplicado. Así que, teníamos una tienda de moda con, digamos, 3,000 artículos distintos. Ahora, decimos que esta tienda se supone que debe tener 6,000 artículos, pero en la tienda, aún tenemos exactamente los mismos 3,000 artículos. Conceptualmente, en el sistema informático que gestiona la tienda, simplemente hemos declarado que el surtido es el doble, con más variantes, más colores, más tallas.

¿Cambiamos algo desde la perspectiva de los clientes? Obviamente, no. Sigue siendo la misma tienda, los mismos pantalones en los estantes, los mismos colores, las mismas tallas. Nada ha cambiado. Pero en el sistema informático, hemos duplicado el rango del surtido elegible. Al hacer eso, hemos dividido el service level, tal como lo mide tu sistema informático, a la mitad. Estábamos, digamos, en un service level del 97%, ahora estamos en algo como 48%, y no hemos cambiado nada en la tienda.

Por eso digo, a través de experimentos mentales, que si tienes un proxy que, al ajustar la configuración de tu sistema informático sin cambiar nada en la tienda, puede provocar cambios arbitrariamente grandes en tus números, entonces tu proxy es completamente absurdo. Sea lo que quieras como proxy de la calidad del servicio, obviamente no debería depender de detalles técnicos dentro de tus sistemas informáticos. Sería una locura si un físico dice, “¿Cuál es el peso de esta botella?” y la respuesta depende de si el sistema informático está configurado en ruso o en francés. Eso es simplemente absurdo. La respuesta es obviamente completamente independiente. O imagina si el peso dependiera de si se trata de una máquina Linux o de una máquina Windows. Insano. Así que, estás mirando características que deberían ser completamente independientes de tu sistema informático.

Lo que he demostrado con el service level es que, al jugar con el surtido, puedes tener grandes variaciones en el service level. Esto es una demostración de lo absurdo que es esta medida en realidad. Mi postura es que, si tenemos que recurrir a la calidad del servicio, volvemos a la idea de que si tienes algo que es fundamentalmente absurdo, deberías operar sin ello. Incluso si no tienes una alternativa, es como tener un tumor; quita el tumor, y estarás mejor sin él. No pienses aún en lo que deberías poner en lugar del tumor.

¿Podemos tener mediciones de alta calidad para la calidad del servicio? Sí, se puede. Este es un tema de discusión completamente distinto, y preferiría no entrar en ese terreno. Pero entiendes mi punto. No puedes superar la estupidez natural con inteligencia artificial. No importa cuán sofisticadas sean tus técnicas, si tu premisa es muy mala, no lo solucionará. Si partes de un concepto roto, de un paradigma roto, no importa cuánta instrumentación añadas; tu paradigma sigue estando roto.

Conor Doherty: Sí, de acuerdo, podemos aceptar eso. Pero la respuesta inmediata a eso es que, cuando dices que estas ideas son estúpidas y que los paradigmas están rotos y no van a conducir a mejores decisiones, la respuesta obvia es un CEO que dice: “¿De qué estás hablando? El año pasado logré 10 mil millones en facturación usando safety stocks, usando service levels, usando RFPs, usando forecast de series temporales.” Aunque no hay límite superior en la cantidad de cosas que pueden ser verdaderas simultáneamente, y la suerte como si tuvieran conflicto, seguramente entiendes que para ciertas personas, al escuchar “eres estúpido por hacer estas cosas” o “eres ignorante” o “estas son malas ideas”, a menudo simplemente señalan el resultado final y dicen: “Pero mira, lo estoy haciendo realmente, realmente bien. ¿De qué estás hablando?”

Joannes Vermorel: Reiniciemos desde el principio. Tiendas de moda. Tenemos clientes, y hemos tenido discusiones con prospectos que con el tiempo se convirtieron en clientes. Nos decían que optimizaban los service levels. Eso es lo que dicen, y si miras el proceso, eso es lo que está escrito en el proceso. Pero cuando empiezas a observar lo que hacen los profesionales, no lo están haciendo así. Volvemos al safety stock. Resulta que las tiendas, básicamente, una tienda de moda, cuando se acerca la siguiente colección, de repente deciden que no van a reordenar casi tanto. Intencionalmente dejan que los service levels caigan de manera bastante notable. Luego, cuando finalmente es el momento de la nueva colección, tienes un período de liquidación, y de repente tienes suficiente espacio para traer la nueva colección.

Así que, estamos en una situación en la que las empresas, especialmente la alta dirección, dicen que usan los service levels, pero la realidad es que no lo hacen. Las personas en terreno están haciendo cosas que son diferentes. Por eso, una vez más, cuando intentas automatizar, falla. Cuando intentas automatizar, en realidad estás tratando de imponer esta idea disfuncional a tu supply chain, y entra en conflicto con la realidad, y por lo tanto falla. La gente vuelve a las hojas de cálculo.

Lo interesante es que hay una cantidad enorme de disonancia cognitiva en el mundo moderno de la supply chain. Algunos de los principios fundamentales, como series temporales, safety stocks y service levels, están completamente rotos. En la práctica, las personas hacen cosas que son completamente diferentes a lo que indican las hojas de cálculo. En lugar de tomar los service levels como algo que debe ser impuesto, simplemente lo consideran como un indicador y hacen las cosas con mucha flexibilidad.

Si transformamos la pregunta a “¿Es fundamentalmente malo tener los service levels como un indicador en algún lugar?” yo diría que no. Es solo una estadística descriptiva entre muchas otras estadísticas descriptivas. En esta área, puedes tener muchas estadísticas descriptivas. No son ni buenas ni malas; simplemente están más o menos organizadas y te brindan más o menos información sobre lo que está sucediendo. Pero la teoría de supply chain te dice algo muy diferente.

No dicen que el service level es un elemento de estadísticas descriptivas; te dicen que es tu objetivo, y que debes tomar decisiones que se ajusten a ese objetivo. Lo que estoy diciendo es que las personas en las grandes empresas casi invariablemente no hacen eso, y tienen razón. Al igual que los safety stocks, si se les pregunta, dirían: “Oh sí, tenemos nuestros objetivos de service level. Necesitamos más madurez, y algún día lo haremos. Pero por ahora, necesitamos algo que funcione.”

Volvemos a esa posición tan absurda en la que los profesionales son conscientes de que están haciendo otra cosa, y lo consideran como algo que harán cuando crezcan, cuando tengan más madurez, posiblemente cuando cuenten con alguna IA que los respalde. Pero no va a suceder porque el concepto está roto. Como una estadística descriptiva, está bien. Como una herramienta para la formulación de políticas en tu empresa, es completamente defectuosa.

Conor Doherty: Bueno, tuve que plantearlo de esa manera. Si el argumento es, y puedes corregirme si me equivoco, pero si el argumento es que hay empresas que tienen estas políticas, tienen estas métricas, y los profesionales simplemente las ignoran, pero hay algunas empresas que lo están haciendo realmente, realmente bien, ¿estás diciendo que lo están haciendo realmente, realmente bien por pura suerte y por el instinto de los profesionales, simplemente adivinando y acertando por casualidad?

Joannes Vermorel: No, solo estoy diciendo que muchos de esos problemas, ya sabes, mientras no utilices un enfoque completamente defectuoso, puedes tener soluciones rudimentarias que aun así funcionen para ti. Mira, la cantidad de habilidades que se requiere para gestionar adecuadamente una tienda de abarrotes local no exige un PhD de Stanford. Puedes hacerlo con mucho menos. Incluso puedes descubrir de forma incremental lo que funciona y lo que no funciona.

Así que lo que estoy diciendo es que esas empresas pueden disfrutar del éxito, obviamente no gracias a la teoría de supply chain. Tienen personas con un poco de experiencia que han descubierto algunas recetas numéricas que, de alguna manera, funcionan. Funcionan lo suficientemente bien. La prueba de que esta teoría no está funcionando es que todas esas grandes empresas han intentado automatizar los procesos muchas veces, prácticamente una vez cada cinco años durante las últimas tres décadas, y falló cada vez. La gente volvió a las hojas de cálculo cada vez.

¿Por qué vas a la hoja de cálculo? La fórmula del safety stock es súper sencilla. Dirigir las decisiones de inventario para cumplir con los objetivos de nivel de servicio es muy sencillo en términos de codificación. Esto es como pan comido, estamos hablando de un total de 50 líneas de código, quizás menos. Así que, si funcionara, ya estaría implementado, y el trabajo de todas esas personas ya estaría automatizado.

Mi argumento es que no lo está, ni de lejos está automatizado porque esos paradigmas están rotos y, por lo tanto, no pueden automatizarse como tal. Lo que contienen esas hojas de cálculo usadas por los profesionales de supply chain son métodos alternativos que suelen ser relativamente simples, que resultan funcionar, pero son conceptualmente incompatibles tanto con el safety stock como con los niveles de servicio.

Conor Doherty: Entonces, ¿qué estrategias prácticas crees que los profesionales de supply chain pueden usar ahora para intentar tomar decisiones de supply chain más económicamente sólidas?

Joannes Vermorel: Verás, si intentamos volver a la IA, la cosa es que tienes que renunciar a esta ilusión de que los conceptos que conoces, que se han enseñado en la escuela o en alguna asociación de supply chain, esos conceptos son simplemente disfuncionales. Si intentas aportar instrumentos sofisticados, tal vez generative AI o deep learning o blockchain o lo que se te ocurra, simplemente no va a funcionar.

Así que el primer paso es reconocer que tienes un problema paradigmático. Es una palabra grande para simplemente decir que tenemos una teoría que está totalmente equivocada. Resultó que lo que estábamos haciendo, casi instintivamente, es en cierto modo la mejor manera. Ahora, si quieres hacerlo de forma realmente elegante, puedes intentar formalizar este instinto económico, que es simplemente no hacer algo que sea súper perjudicial y costoso para la empresa. Esa es solo la manera más formal de decir lo mismo.

Entonces, quizás una vez que tengas la perspectiva correcta, puedas incorporar las tecnologías sofisticadas, y eso es, prácticamente, lo que está haciendo Lokad. Pero lo fundamental es que todo comienza por enmarcar correctamente el problema con una perspectiva que tenga sentido. Mientras estés atrapado en una perspectiva disfuncional o estúpida, ser un virtuoso en tecnología es irrelevante. Esa es la parte triste. Por eso puedo decir con relativa seguridad que esos proveedores de IA fracasarán. No importa si son talentosos o no, no importa si su tecnología es muy buena o muy mala, si es barata o exorbitantemente cara. Todo eso es completamente inconsecuente. No funcionará porque los supuestos en los que se basan están rotos.

Conor Doherty: Muy bien, Joannes, gracias. No tengo más preguntas, pero ahora pasaré a algunas de las preguntas del público. Muchas gracias. Entonces, sin ningún orden en particular, refiriéndome a las cuatro pruebas, tus cuatro formas: RFPs, series temporales, safety stocks y niveles de servicio. Si estas prácticas sirven tan mal a las empresas, ¿qué, en tu opinión, impide que los equipos de gestión simplemente las descarten?

Joannes Vermorel: Cambiar cualquier cosa en las grandes empresas es difícil, pero hay una clase de cambios que es aún más difícil. Como regla general, he visto que en cualquier empresa, sin importar el tamaño, eliminar algo es, digamos, dos órdenes de magnitud, es decir, 100 veces más difícil que agregar cosas. Agregar un nuevo proceso es fácil, agregar una nueva posición es fácil, agregar un nuevo software es fácil.

Eliminar cualquier cosa es muy difícil, particularmente en Francia. Pero en todas partes, ya sabes, podemos bromear acerca de que Francia tiene el Banque de France, que es una institución dedicada a la gestión de una moneda que no existía desde 1992. Tenemos una antiinstitución que se dedica a gestionar una moneda que no existía durante 30 años. Y, por cierto, son como 14,000 empleados en París. Pero ya ves, lo que ocurre a gran escala en entornos gubernamentales simplemente ocurre a menor escala en las grandes empresas. Las burocracias tienden a crecer por sí solas, esa es la ley de Parkinson.

Entonces, la pregunta es, ¿por qué la directiva no elimina las cosas que no funcionan? La cuestión es que la gente ya está haciendo algo diferente. La política corporativa oficial es que todos usan safety stock. La realidad es que hay tantas anulaciones manuales impulsadas por hojas de cálculo que, efectivamente, la empresa está utilizando algo completamente diferente. Ese es el estado de las cosas. Tenemos la farsa que aún se juega de que la empresa se rige por el safety stock. Yo digo, pues, ya sabes, que el safety stock sigue siendo una característica importante del supply chain de la empresa. No lo es. Pero, en última instancia, la dirección diría, ¿qué gano haciendo oficial que los safety stocks ya no existen? En última instancia, no cambia nada porque la gente ya no los utiliza.

Así que, es lo mismo. Una vez que tienes un reporte para el nivel de servicio, realmente no tiene sentido. Pero el beneficio de eliminarlo a muy corto plazo es limitado. A largo plazo, los beneficios son enormes porque allana el camino para hacer algo que, en realidad, tenga mucho más sentido. Pero a corto plazo, los beneficios son limitados. De nuevo, agregar cosas es mucho más fácil.

Si volvemos a la IA, eso también explica por qué hay tanto entusiasmo por adoptar tecnologías de IA. Es simplemente aditivo. Vamos a agregar otra categoría de cosas en la organización, y eso es muy agradable y fácil, en contraposición a decir que vamos a eliminar una categoría de cosas que simplemente obstaculizan que la empresa sea más eficiente, más rentable y que sirva mejor a los clientes. Es mucho más difícil para un gerente decir, voy a eliminar gente y que las cosas funcionen mejor.

Solo imagina lo que pasó con Elon Musk en Twitter cuando dijo: Acabo de despedir al 80% del personal y Twitter, ahora X, es más fluido que nunca. Tiene más usuarios que nunca, y en general han agregado toneladas de características que el equipo anterior, que era cinco veces más grande, no pudo hacer en las décadas previas. Eso refleja el poder de restar cosas, pero es extremadamente difícil. Es muy, muy difícil. Así que yo diría que esas cosas no avanzan porque eliminar algo es extremadamente difícil, incluso si es críticamente importante.

Conor Doherty: Gracias. Siguiente pregunta, está muy bien redactada. Considerando tu históricamente franca desaprobación de la intervención humana, ¿consideras que eso es un ejemplo de estupidez natural?

Joannes Vermorel: Las intervenciones humanas. Quiero decir, depende. Si estamos anulando una receta numérica que es completamente absurda, es bueno. Lo que digo es que donde las cosas se vuelven aún más locas es cuando terminas con situaciones en las que tus recetas numéricas son absurdas.

Conor Doherty: Cuando dices recetas numéricas.

Joannes Vermorel: Es aquello que computa tus decisiones de supply chain, como cuánto deberías pedir, cuánto deberías producir, dónde deberías asignar el stock, y así sucesivamente.

Entonces, tienes recetas numéricas que son absurdas, por lo que es absolutamente normal anular manualmente esos resultados insanos para las decisiones. Y ahora lo que sucede es que terminas con muchas personas en la organización que pasan todo el día anulando decisiones. En lo que a mí respecta, esto es necesario porque, de lo contrario, la empresa simplemente se estrellaría contra una muralla gracias a esas decisiones completamente absurdas.

Ahora lo que sucede es que las burocracias siempre se expanden. Esa es la regla de la ley de Parkinson. Las burocracias se expanden. Si tienes personas que pasan todo el día anulando manualmente decisiones numéricas, tendrás personas que pasarán todo el día anulando gradualmente artefactos numéricos. Entonces, ¿qué es un artefacto? Un artefacto es simplemente algo que existe en tu sistema, como un nivel de servicio, como un forecast, un forecast diario, un forecast mensual, un presupuesto, o lo que sea.

Algo con lo que puedes jugar. Este número no tiene un efecto tangible en tu negocio. Podría tener un efecto negativo si hay decisiones que se derivan de este artefacto, quizás. Pero muy frecuentemente, las decisiones no tienen influencia en los artefactos. Así que piénsalo como jugar con KPIs y cosas similares. Va a ser inconsecuente, excepto quizás ante los ojos de la dirección, porque tienes un número que se ve mejor.

Pero de nuevo, la burocracia se expande. Comenzaste con una situación en la que tenías personas anulando manualmente decisiones que eran necesarias. Y ahora la burocracia se expande. Tienes muchas personas que están anulando artefactos, artefactos numéricos, es decir, cosas que no importan. Eso serán personas jugando con ABC classes, personas jugando con niveles de servicio, personas jugando con coeficientes para safety stocks, personas jugando con coeficientes de seasonality, etc. La lista es interminable.

Y lo que estoy diciendo es que sí, esas anulaciones numéricas son completamente absurdas e inútiles. Y, por cierto, el enfoque de Lokad, y por eso la gente mencionaba que soy muy despectivo, es que si tienes una receta numérica que es sensata, no debería haber ninguna necesidad de una anulación manual. Si necesitas anular manualmente tus resultados, es porque tu receta numérica es absurda. Estoy hablando de una decisión. Así que, si la decisión es absurda, necesitas corregir la receta numérica y seguir corrigiéndola hasta que no quede ni una sola línea absurda.

Mientras tu receta numérica siga produciendo decisiones absurdas, necesitas seguir iterando para corregirla, sin excepción. Y por eso, por cierto, en Lokad, generalmente somos muy despectivos con esas anulaciones manuales. Las anulaciones de las decisiones simplemente reflejan que tienes una mala receta numérica. Y la anulación de artefactos numéricos simplemente refleja trabajo burocrático inútil que, en primer lugar, es completamente redundante y que podría eliminarse por completo sin que eso cambiara nada para la empresa.

Conor Doherty: Sí, es tratar los síntomas y no la causa.

Joannes Vermorel: Esencialmente, sí, exactamente. Y además, nuevamente, actuando en interés de las burocracias. De nuevo, esa es la ley de Parkinson. Las burocracias tienden a crecer. Así que, si multiplicas el número de empleados que tienes para hacer esas anulaciones manuales por un factor de 10, tendrás 10 veces más actualizaciones de esos valores. No hará que tu supply chain mejore en absoluto.

Conor Doherty: Bueno, eso es suficiente para mí. Gracias. Siguiente pregunta. Son dos partes. ¿Cómo han empeorado los sistemas ERP el problema y por qué no pueden manejar forecast probabilísticos? Solo mencionaste implícitamente los forecast probabilísticos anteriormente, pero siéntete libre de ampliar.

Joannes Vermorel: Diría que los ERPs han empeorado el problema, en gran parte gracias a los investigadores de mercado, por hacer la situación muy confusa. Primero, en un ERP, no hay P en ERP. Es gestión de recursos empresariales. No hay planificación involucrada. Lo que tienes es un sistema que es transaccional. Es solo para lidiar con un flujo transaccional. Es prácticamente la contraparte electrónica, en términos de flujo, de tu flujo físico. Y eso es bueno. Eso te da la representación electrónica de lo que está sucediendo físicamente en tu supply chain. Eso es bueno.

Ahora el problema es que la planificación de repente… Así que esto es lo que yo llamo un sistema de registros. De repente, en la planificación entramos en el territorio de sistemas de inteligencia, toma de decisiones. Ahora, ¿por qué han empeorado los ERPs la situación? Es porque los proveedores se dieron cuenta muy rápidamente, a finales de los años 90, de que los sistemas de registros, también conocidos como aplicaciones CRUD (Crear, Leer, Actualizar, Eliminar), ya se habían commoditizado. Ya se commoditizó hace 20 años.

Hoy en día, está aún más commoditizado de forma increíble. Y, por cierto, si quieres tener una aplicación real de generative AI como herramienta de productividad, es soberbio para escribir código para aplicaciones CRUD. Así que ahora, con básicamente ChatGPT, puedes literalmente escribir aplicaciones similares a ERP súper, súper rápido, porque esas cosas son simples. Es mucho código repetitivo; tienes toneladas de ello. Es increíblemente repetitivo. No es como una ingeniería sofisticada.

Entonces, ese tipo de cosas como herramientas de productividad, la IA funciona increíblemente bien para lidiar con ERM, ya sabes, la gestión de recursos empresariales. Ahora, volviendo a esta situación que ha sido confusa. Lo que esperas de tus sistemas informáticos para manejar un sistema de inteligencia y toma de decisiones es completamente diferente de lo que esperas de un sistema de registros. Una ilustración es cuántos milisegundos puedes permitirte mantener tu sistema ocupado haciendo algo. Si es un sistema de registros, la respuesta es menos de un milisegundo. Sea lo que sea que hagas, debería finalizar en un milisegundo.

¿Por qué? Porque tu sistema, tu ERM, digamos, depende de una base de datos centralizada, y este es un recurso compartido para todos y cada uno de los procesos en tu empresa. Así que, todo converge a esa única base de datos. Si congelas esa base de datos por un milisegundo, eso significa que todo lo demás se retrasará por un milisegundo. Dirías, “Oh, un milisegundo no es nada.” Sí, pero ahora tienes 500 personas haciendo eso. De acuerdo, no son 500, ahora son 500 milisegundos de retraso los que comienzan a ser notables.

Ahora, ¿qué pasa si algunas de esas solicitudes congelan tu núcleo relacional? Estoy simplificando por un segundo. Entonces, de repente, terminas con un sistema que es muy, muy lento. De repente, escanear un código de barras puede tomar varios segundos para que el sistema reconozca lo que acabas de hacer. Y por eso muchas empresas se quejan, “Oh, mi sistema ERP es tan lento.” La respuesta es invariablemente, es lento porque pusiste cosas en este sistema que no deberías haber puesto.

El ERM, ya sabes, la gestión de recursos empresariales, solo debería tratar con cosas que puedan ser calculadas en tiempo sub-milisegundo, es decir, súper, súper simples. Si haces algo que no es extremadamente simple, significa que vas a congelar tu sistema. Vas a utilizar recursos que, de alguna manera, congelarán tu sistema por una cantidad de tiempo medible. Y si tienes suficientes personas haciendo eso, y adivina qué, estamos hablando de grandes empresas, tantos procesos, tantas personas, tu sistema se volverá increíblemente lento. Y es exactamente por eso que los ERPs en la actualidad siguen siendo tan lentos como hace 20 años. Aunque en cuanto a poder de procesamiento bruto, tenemos computadoras que son al menos mil veces mejores. La respuesta es, ¿por qué sigue siendo tan lento? Es porque aparece un equilibrio.

Si algo está ralentizando tanto el ERP que demora múltiples segundos en que otras personas logren que el sistema responda, entonces el IT department simplemente lo va a apagar y evitar eso. Y ves eso. Entonces, actúan como la policía del consumo del ERP. Y si hay alguien que es excesivo, IT intervendrá en algún momento y simplemente evitará que esta persona o esta pieza de software cree tantos problemas para el resto de nosotros. Y así, hay este equilibrio, y luego converge hacia un equilibrio, que es, es lento pero tolerable. Por eso la mayoría de los ERPs son súper lentos pero no tan lentos como para ser insoportables. Porque si entras en el territorio insoportable, entonces IT interviene y simplemente lo mata.

Así que, volvemos a los sistemas de inteligencia. Por el contrario, si lo piensas, si quieres pensar en cómo deberías hacer un reabastecimiento de tienda, vas a mirar años de historial de ventas. Quieres observar lo que sucede con miles, posiblemente decenas de miles de clientes. Quiero decir, es obvio que es algo que va a manipular una gran cantidad de datos. Es obvio que es algo en lo que quieres invertir un poco más que un milisegundo de cálculo. El cálculo es barato.

El problema es que si tienes un ERM, tus recursos se comparten con toda la empresa. Así que, lo que deseas es tener un sistema de inteligencia que esté fuera del ERM, y entonces esta cosa puede tardar todo el tiempo que sea relevante invertir para hacer esos cálculos sofisticados. Así que, si volvemos a la pregunta inicial, los sistemas de registros deben encargarse de cosas que son transaccionales, que son reglas muy simplistas.

El forecast probabilístico es el arquetipo de lo que no deseas tener en tu sistema de registros. Quiero decir, de nuevo, en cuanto empezamos, cuando dices forecast probabilístico, estamos discutiendo distribuciones de probabilidades. Esos objetos, en términos de memoria, son pesados. Va a tomar mucho espacio tener todas esas probabilidades. Puedes ser muy inteligente de varias maneras, pero seamos obvios. Quiero decir, es obvio que se introduce, en comparación con los datos sin procesar que tienes, una gran sobrecarga. Estás macro-expandiendo tus datos para evaluar todas esas probabilidades.

Así que, fundamentalmente, tienes algo que por diseño podría ser muy poderoso, sí, pero básicamente por diseño, no será en tiempo real. Si te adentras en evaluaciones probabilísticas sofisticadas, no estás en el territorio del cálculo en tiempo real. Quieres algo en lo que puedas asignar gigabytes de memoria y gastar, seamos locos, segundos de cálculo. Está bien. La mayoría de las decisiones de supply chain pueden soportar unos pocos segundos de demora, pero no tu ERP.

Conor Doherty: Bueno, de nuevo, solo para continuar con ese punto sobre los sistemas de inteligencia y la falta de necesidad de tener cálculos en tiempo real dependiendo de lo que se esté tratando de calcular. Así, solo para dar un orden de magnitud aquí, si das el ejemplo de una orden de reabastecimiento de inventario, si estuvieras hablando de una tienda o un cliente, digamos 300 tiendas y, para números redondos, 50,000 SKUs, estarías hablando de 10 horas, 12 horas, como un procesamiento nocturno para llegar a estas decisiones, a diferencia del sistema de registros que simplemente sería…

Joannes Vermorel: Sí, pero quieres mantener tu cálculo típicamente por debajo, en Lokad, lo que hacemos es 60 minutos, pero por una razón que es completamente diferente. Así que sí, en teoría, podrías tener un cálculo que tome 10 horas. En la práctica, es una muy mala idea porque si tu cálculo falla a la mitad y tienes que reiniciarlo, eso significa que estás creando problemas operativos.

Así que, deseas mantener tu cálculo lo suficientemente corto para que cuando necesites rehacerlo, aún haya tiempo de sobra. Y la segunda razón, que es aún más importante, es que este cálculo, no lo vas a acertar inicialmente. Como dije, una receta numérica, mientras produzca resultados insanos, necesitas modificar y actualizar hasta tener una receta numérica que no genere decisiones insanas en absoluto, lo que significa muchas iteraciones.

Si tienes algo donde el cálculo se completa en menos de 60 minutos, significa que un ingeniero puede hacer tal vez cinco, seis iteraciones al día. Si tienes algo que toma 10 horas, significa una iteración al día. Realmente quieres tener algo en lo que un ingeniero pueda iterar muchas veces al día. Y con frecuencia en Lokad, cuando estamos en modo de diseño, cuando elaboramos una nueva receta numérica, intentamos mantener el cálculo por debajo de unos pocos minutos para que podamos tener literalmente docenas de iteraciones por día.

Conor Doherty: Hay ejemplos, sin embargo, otra vez, para pasar, digamos, del retail a algo como la aeroespacial. Hay ejemplos donde querrías que las decisiones se generaran en un puñado de minutos en lugar de incluso una hora. Como 60 minutos podrían ser catastróficos financieramente. Así que, de nuevo, no es que lo más rápido que podamos hacer sea 60 minutos. Es más bien dependiendo del contexto del sector.

Joannes Vermorel: Absolutamente. Pero incluso, ya ves, tienes que apreciar que entre un milisegundo, que debería ser tu objetivo de rendimiento dentro de un ERP, y un minuto, estamos hablando de casi cinco órdenes de magnitud. Esto es muy diferente. Esto es literalmente más de 10,000 veces más, ya sabes. Lo que significa que puedes hacer las cosas de manera muy, muy diferente.

Si quieres operar en menos de un milisegundo, es muy, muy difícil. Muchas cosas simplemente no son posibles. Incluso la velocidad de la luz es bastante lenta. Quiero decir, si estás hablando de cosas que operan en menos de un milisegundo, eso significa que la velocidad de la luz solo recorrerá 300 kilómetros. Eso puede sonar mucho, pero si quieres pensar en términos de ida y vuelta, eso significa que un milisegundo es literalmente la velocidad de la luz. Realmente no puedes ir más allá de 150 kilómetros si necesitas desplazarte.

Entonces, ves, es el tipo de velocidad en la que de repente cualquier comunicación de red queda fuera de la ecuación. Así que, si quieres ceñirte a un rendimiento submilisegundo, no se permite ningún tipo de comunicación de red. Incluso cargar cosas de un disco giratorio está prácticamente fuera de la ecuación. Un disco que gira, un disco magnético, la latencia será de algo así como 10 milisegundos. Así que, incluso cargar algo de un disco está fuera de la ecuación.

Con un disco SSD, ya sabes, disco de estado sólido, puedes hacer eso, pero incluso allí, no podrás realizar muchos accesos. Puedes hacer tal vez unos pocos. Entonces, lo que estoy diciendo es que hay una enorme diferencia entre lo que puedes hacer en un milisegundo y lo que puedes hacer en un minuto. En términos de diseño informático, es completamente diferente. Si tienes un minuto, puedes hacer muchas llamadas de red, puedes hacer muchos cálculos sofisticados, puedes cargar muchos datos. Es muchísimo más fácil de diseñar.

Conor Doherty: Bueno, Joannes, gracias. No hay más preguntas. Muchas gracias por tu tiempo. Ha sido aproximadamente una hora y media, así que te daré un minuto para un pensamiento final. ¿Algo que quieras decir antes de irnos?

Joannes Vermorel: No, desearía decir mucha fortaleza mental para todas las personas que están involucradas en procesos de AI para su supply chain porque, bueno, esos procesos fallarán. Lo siento mucho. Lo siento mucho, chicos. Simplemente sucede. No te lo tomes como algo personal. Quiero decir, creo que pueden consolarse. Creo que para esas personas, pueden consolarse sabiendo que sus habilidades son irrelevantes, ya sabes. Y, por cierto, las habilidades de tu proveedor también son irrelevantes en este punto. Así que, no importa si eres bueno o malo, ya sabes. De esa manera, puedes pensar de ti mismo no tan mal al enfrentar el fracaso. No te lo tomes demasiado personal. El fracaso estaba garantizado. Estaba condenado desde el principio.

Conor Doherty: Sí, de acuerdo. Bueno, con esa nota alegre y festiva, Joannes, muchas gracias por tu tiempo y gracias a todos por ver. Nos vemos en 2025.