¿Valen la pena los digital twins?

Transcripción completa

Conor Doherty: Esto es Supply Chain Breakdown, y durante los próximos 30 minutos aproximadamente desglosaremos el bombo que rodea a los digital twins, particularmente en supply chain. Mi nombre es Conor. Soy el Director de Comunicaciones en Lokad, y me acompaña en el estudio, a mi izquierda, como siempre, el inefable Joannes Vermorel, fundador y CEO de Lokad.

Ahora, antes de comenzar, comenta abajo—primero, ¿de dónde eres? y en segundo lugar, ¿qué opinas de los digital twins? Recuerda, estamos aquí para hablar sobre tus inquietudes. Además, envía tus preguntas cuando las tengas. Si escuchas algo que Joannes dice y quieres cuestionarlo, siéntete libre de hacerlo. Ponlo abajo y se lo preguntaré en aproximadamente 20 minutos.

Y con eso, no más tiempo perdido. Joannes, quita el bombo de los digital twins, porque sé que han existido por un tiempo, pero aclara el contexto: ¿qué es un digital twin en términos básicos y simples? Y además, ¿cuál es el problema que al menos se piensa que los digital twins están diseñados para resolver?

Joannes Vermorel: Entonces, considerando qué son los digital twins, diría que si tomas la versión de consultoría—la cual no es la que yo seguiría—te dirían: es una representación precisa de tu supply chain, completamente digital, que te permite proyectar casi cualquier cosa hacia el futuro. Como si tuvieras una simulación completa, perfectamente precisa, de toda tu supply chain. Al menos, esa es la perspectiva ideal para los digital twins de tu supply chain.

Y la idea de los digital twins también existe en otros dominios, y para otros dominios a veces puedes tener una simulación muy precisa de un sistema físico. Ahora, en la práctica, ¿qué es? En la práctica, es solo un simulador Monte Carlo reempaquetado. Esos simuladores han existido por alrededor de cuatro décadas. La característica clave es que son muy, muy fáciles de implementar, y es relativamente divertido, como un proyecto de juguete, implementar un simulador Monte Carlo de un sistema siempre que realmente no te importe nada como la precisión de las simulaciones.

Conor Doherty: Voy a intervenir de inmediato porque planteaste un par de puntos interesantes. Así que diste al menos dos aplicaciones. Una fue cómo se podrían comercializar los digital twins en un contexto de supply chain—esa es una categoría. Pero dijiste que hay una aplicación preexistente o más perdurable; dijiste que era para productos físicos. ¿Podrías desglosar un poco más esa separación?

Joannes Vermorel: Sí. Quiero decir, la idea de tener simuladores—existen tres ideas clave: microanalíticos, discretos y estocásticos. Son tres conceptos. Cuando la gente piensa en simuladores Monte Carlo, esos son los tres aspectos que tienes.

Microanalítico significa que quieres descomponer tu sistema en algo parecido a átomos o en elementos muy, muy pequeños que tienen comportamientos simples regidos por leyes simples que puedes cuantificar completamente. Esa es la perspectiva microanalítica. Luego, discreto: para tu computadora vas a asumir que todo se comporta con incrementos definidos—en supply chain tiene sentido—incluida la dimensión temporal. Así que vas a decir, “Está bien, voy a crear un simulador que opere con un paso por día,” o algo así.

Y lo último es el aspecto estocástico: a algunos comportamientos simplemente les vas a agregar algo de aleatoriedad. Por eso hablo de un simulador Monte Carlo. Atribuyes a ciertos comportamientos una naturaleza aleatoria o estocástica, y luego puedes ejecutar repetidamente tu simulador muchas veces para supuestamente proyectar un estado futuro de tu supply chain, o al menos puedes hacer que el simulador avance en el tiempo. Y debido a que se supone que es un digital twin de tu supply chain, representa el futuro de tu supply chain.

Conor Doherty: Gracias, y creo que esto vuelve a plantear un punto clave sobre dónde se puede separar la conversación. Cuando la gente habla de utilizar un digital twin en, digamos, fabricación o reparación, puedes decir, “Tengo un digital twin. Es una representación determinista de un avión completo.” Así, un A320 tiene aproximadamente 320,000 partes. Sabes cuántas partes hay; puedes modelarlo; es fijo. Esa es una réplica digital o representación digital de un producto o propiedad física conocida.

¿Qué tan bien puedes aplicar ese mismo concepto a una red geográficamente distribuida como una supply chain que engloba no solo partes físicas como productos y trucks y demás, sino también comportamientos, tendencias, políticas—todo lo cual impacta en esas cosas?

Joannes Vermorel: El principal problema son las leyes que rigen tus átomos, tus unidades elementales de simulación. Si estás en el mundo físico, literalmente puedes aplicar el electromagnetismo y demás para tener una evolución físicamente precisa de tu sistema, porque asumes que si descompones las cosas lo suficiente, lo que queda obedecerá leyes muy, muy conocidas. Si quieres describir un fluido que pasa a través de varios tubos y demás, cuentas con las ecuaciones microfluídicas y puedes hacer una simulación de elementos finitos.

Pero la clave aquí es que se asume que tienes leyes que rigen los elementos de tu sistema que son prácticamente perfectamente conocidas, y entonces el único cabo suelto es la resolución de tu simulación, la cual podría no ser suficiente para ser súper precisa. El problema con un digital twin en supply chain es que el desafío no es realmente la resolución. El desafío es que no está claro en absoluto que tengas algún conocimiento previo relevante sobre los comportamientos de esas unidades simples, porque esas unidades simples—digamos que quieres simular un proveedor—no son nada simples.

No hay—puedes hacer suposiciones simplistas acerca del comportamiento de este proveedor todo lo que quieras, pero no es porque hayas conjurado una suposición sobre esa entidad que vaya a ser cierta. Y lo mismo se puede decir de todo: clientes, almacenes, rutas que conectan toda tu supply chain, etc. Así que realmente existe un problema fundamental: sí, puedes crear un simulador descomponiendo tu sistema y simplemente inventando comportamientos para todos los átomos, pero ¿son esos comportamientos de algún tipo de corrección? Ese es el gran, gran desafío, y es algo que típicamente nunca se discute con esos digital twins de supply chain—la corrección de la modelización.

Conor Doherty: A la corrección y otras métricas volveremos, pero quiero profundizar un poco más. De hecho, voy a leerte una definición muy clara. Estés o no de acuerdo con ella, es una definición clara, y quiero saber tu reacción. No te voy a decir de quién es aún—puedes adivinarlo más tarde—pero es contundente. Así que, cito: “Los digital twins pueden usarse para modelar la interacción entre procesos físicos y digitales a lo largo de toda la supply chain, desde la ideación del producto y la fabricación hasta el almacenamiento y la distribución, desde las compras en tienda u online hasta el envío y las devoluciones. Así, los digital twins pintan un panorama claro de un proceso óptimo end-to-end de supply chain.” Ahora, ¿cuál es tu opinión al respecto? ¿Con qué partes de ello no estás de acuerdo?

Joannes Vermorel: Esta definición no dice nada excepto la intención. Simplemente dice, “Está bien, la intención es tener algo que haga todas las cosas que esta definición describió,” lo cual es una representación end-to-end precisa de bla, bla, bla. Esa es la intención. No dice nada acerca de cómo lo hace. Y mi mensaje es: el cómo importa.

Puedes inventar o desear muchas herramientas increíbles. Me gustaría—¿qué es un asistente de IA perfecto? Eso es algo que tiene una inteligencia mucho mayor que la de un humano y que puede hacer todo lo que un humano puede hacer, pero simplemente mejor. De acuerdo, acabo de definir lo que sería un asistente de IA perfecto. ¿Significa eso que existe uno disponible de inmediato? El problema es que si defines algo por su intención, no dice nada acerca de la viabilidad o del hecho de que esta cosa siquiera sea real.

Así que sí, tenemos una buena definición intencional. Y yo, cuando digo “simulador Monte Carlo”, hice exactamente lo contrario. Empecé con, “Está bien, ¿qué están haciendo las empresas bajo el capó cuando usan la palabra de moda ‘digital twin’?” Y mi respuesta es, hasta donde puedo observar: simulador Monte Carlo. ¿Por qué? Porque es extremadamente sencillo de implementar. Literalmente, un estudiante de primer año en informática puede hacerlo en solo unos pocos días—probablemente incluso los más inteligentes lo puedan hacer en una tarde. Y sí, siempre y cuando no te importe si tu simulación tiene alguna relevancia para el mundo real, es súper sencillo de implementar.

Conor Doherty: Volviendo, estás hablando de la intención. El propósito, al menos según lo presentado por muchas personas, sería—para darte algo con qué responder—que muchos proveedores, consultores y defensores de un digital twin argumentarían que un digital twin mejora la toma de decisiones al proporcionar efectivamente—aunque sea mediante Monte Carlo—un entorno de pruebas en el que puedes experimentar con scenarios tipo “what-if”, como “¿Qué pasa si el proveedor se retrasa? ¿Qué pasa si hay un bloqueo en el Canal de Suez?” o lo que sea.

Joannes Vermorel: Una inteligencia artificial general mejora la rentabilidad de cualquier empresa—por definición. Si tienes algo que es tan inteligente como un humano pero no tiene salario, sí, mejorará. De acuerdo. Pero volvamos a la pregunta: ¿está disponible esta cosa, y cuáles son las técnicas? Esas partes lo presentan como un hecho consumado: ya está ahí, lo tenemos, tiene todas esas buenas propiedades. Pero, espera—¿qué tienes bajo el capó?

Y mi mensaje es: hasta donde yo sé, literalmente todas las empresas que he visto impulsar los digital twins no tenían nada más que simuladores Monte Carlo ingenuos, lo cual, en mi opinión, es una sofisticación a nivel de juguete. Es elegante. Es el tipo de buen ejercicio que le daría a estudiantes de primer año de informática. Sí, es divertido implementarlo, y es fácil. Pero el problema es, nuevamente, que es completamente inventado.

Sí, puedes descomponer tu supply chain en una lista de SKUs, una lista de clientes, una lista de proveedores, y asignar comportamientos a todas esas entidades, y luego dejar que la simulación se ejecute—absolutamente. Pero, ¿es realmente correcta? Esa es una pregunta muy importante. Una analogía sería: simplemente toma SimCity 2000, el videojuego—uno antiguo. Tienen un editor de mapas. Literalmente, puedes editar un mapa que se parezca exactamente a París, trazar todas las calles exactamente como son en París—casi, de nuevo tienes el problema de la discretización, por lo que no son las mismas calles exactamente, pero lo suficientemente parecidas. Luego puedes decir, “Esta área es residencial, esta es industrial, esta es comercial.” Sí, podrías hacer eso, y luego dejar que la simulación del juego avance.

¿Te da eso una simulación precisa del futuro del entorno urbano de París? Mi respuesta es absolutamente no—especialmente cuando Godzilla entra en escena; eso es un desastre que sucede en el juego. No es porque sea muy fácil de crear. De nuevo, lo reitero: es muy fácil crear simuladores, y es divertido. La pregunta realmente es: ¿por qué crees siquiera que tendrá algún tipo de accuracy?

En otras áreas, como las ciencias físicas—digamos, las ciencias de materiales—tu simulador es bueno porque obedece fundamentalmente las leyes de la física, que son muy conocidas y verificadas. Así que, fundamentalmente, tus comportamientos no son inventados: literalmente tomas libros de texto de física y aplicas el electromagnetismo o la dinámica de fluidos o lo que sea, y estos son los comportamientos que rigen tus elementos, tus átomos. Pero en un digital twin de supply chain tienes que inventar y conjurar esos—o descubrir de alguna manera—esos comportamientos, y esa es una parte muy, muy complicada. Hasta donde yo sé, los digital twins para supply chain—los proveedores, las personas que lo promocionan—realmente no dicen nada sobre eso, y esa es la clave de toda esta digresión.

Conor Doherty: Has mencionado la precisión y la corrección, y nuevamente, solo para replicar—por cierto, esa definición anterior era de McKinsey, con la que no estuviste de acuerdo. Y de una a otra, porque esta ahora es de BCG—oh, perdón, ¿quieres decir algo?

Joannes Vermorel: Nuevamente, el problema es que describen la intención. Cuando se trata de una pieza de tecnología, realmente prefiero enfocarme en el cómo. Definir una pieza de tecnología a través de la intención de lo que se quiere lograr está bien, pero luego no puedes razonar sobre si es una buena pieza de tecnología o no. No estoy en desacuerdo con la intención—la intención está bien, sí. La pregunta es: ¿tienes una definición que te permita identificar si esta pieza de tecnología es mejor o peor que otra para tu supply chain?

Conor Doherty: En esa línea, según—nuevamente, estamos haciendo referencias—según Boston Consulting Group, las empresas con digital twins mejoraron su forecast accuracy en un 20 a 30%. Quiero decir, ¿no es eso algo por lo que la mayoría de las empresas darían lo que fuera? ¿Están equivocados al perseguir esto?

Joannes Vermorel: Hasta donde yo sé, los digital twins nunca han aparecido en ninguna forecasting competitions. Hay muchas forecasting competitions; existen docenas de técnicas utilizadas para obtener mejores forecasts en esas competencias. Nunca he oído hablar de algo relacionado con digital twins haciendo algo respecto a forecasting.

Así que ves, el problema es que, para mí, dado que no definen a qué técnicas se refieren realmente, podría ser cualquier cosa. Mi opinión—y es una opinión empírica—es que las empresas que están comercializando digital twins esencialmente están construyendo simuladores Monte Carlo, y estos no aportan una accuracy superior a la mesa. De nuevo, no sé cómo se han recopilado esos números, pero la realidad es que ni siquiera está en el ámbito de aquello que realmente puede mejorar el forecast accuracy.

Conor Doherty: Pero concediendo, hay otro punto a considerar, seguramente, que es: ¿acaso una mayor accuracy es algo que necesariamente conduce a una mejor toma de decisiones, lo que la gente intenta lograr con el digital twin? Así que existe un uso instrumental y luego está lo que realmente se intenta lograr—la meta, el propósito.

Joannes Vermorel: Sí. Si decimos que lo que queremos son mejores decisiones con mayor retorno de la inversión, entonces conceptualmente el gemelo digital podría decir: si tengo una política A, lo ejecuto a través de mi gemelo digital, evalúo el retorno de la inversión; luego tengo la política B, hago lo mismo, y elegiré la política que rige mi decisión y que simplemente me da una tasa de retorno superior. Conceptualmente, bien—¿por qué no?

Pero nuevamente, todo esto depende del hecho de que tu gemelo digital te brinde una evaluación económica correcta. Así que este problema de exactitud se te vuelve a presentar en términos de dólares: tienes una tasa de retorno para la política A, una tasa de retorno para la política B. Pero de nuevo: ¿tiene tu gemelo digital algún tipo de corrección? ¿Por qué confiarías en él? Es una pregunta muy complicada.

Podemos volver a SimCity 2000 y París. Puedo dejar que el juego avance con diferentes niveles de tributación para la ciudad—existe en el juego. Pero, ¿este asunto me dirá algo muy preciso acerca de la ciudad de París? Creo que sería obviamente completamente una locura pensar que un videojuego puede usarse para modelar con precisión la evolución de una metrópolis real. Ese es el mismo tipo de problema que tengo con esos gemelos digitales para supply chain. A menos que agregues muchas cosas, lo que simplemente tienes es un pensamiento ilusorio.

Sí, sería genial tener algo que haga todo eso de forma muy precisa. Si me dices que esta simulación de Monte Carlo es algo innovador que va a hacer esto posible, realmente no lo creo. En el mejor de los casos, es un pequeño ingrediente: súper simple. Sería un poco como decir: “Los ordenadores van a estar involucrados.” Sí, probablemente. Es buena idea involucrar computadoras, al igual que tener un simulador de Monte Carlo es una técnica interesante. Es ínfimo; no voy a disentir. Es simplemente muy, muy superficial. Es un poco como decir: “Sería mejor usar metal para un coche.” Ciertamente, el metal estaría involucrado, pero no te va a conseguir un coche.

Conor Doherty: Bien. Sé que podríamos hablar de eso para siempre, pero nuevamente, el tema anunciado era específicamente los digital twins. Hace un par de días realizaste una encuesta en LinkedIn donde le preguntaste a tu audiencia, “¿Cuáles son los mayores obstáculos para los digital twins?” porque muchas de las personas que están viendo, y que lo verán más adelante, son empresas que están considerando adoptar esta tecnología o que ya la están adoptando.

Joannes Vermorel: Primero, un simulador de Monte Carlo a la escala de tu supply chain no es más que un modelo de forecast probabilístico. Eso es literalmente lo que es. Cuando decimos forecast probabilístico, no especificamos mucho qué modelos subyacentes se utilizan realmente para ello. En la conferencia doy una serie de ejemplos de cómo puedes construir esos modelos. Pero cuando simplemente dices “forecast probabilístico,” no estás diciendo nada acerca del modelo en sí.

Puedes construir tu modelo de forecast probabilístico con un simulador de Monte Carlo. Simplemente dejas que la simulación se ejecute, recoges tus distribuciones de probabilidad que son empíricas, y si ejecutas tus simulaciones miles de veces, vas a recolectar esos bonitos histogramas multidimensionales que te darán tus distribuciones de probabilidad, y aquí tienes tu forecast probabilístico. Así que existe una dualidad entre un simulador de Monte Carlo y un forecast probabilístico. A partir de las probabilidades, puedes generar desviaciones—lo que te da esos comportamientos estocásticos. Pero si tienes los comportamientos estocásticos, puedes ejecutarlos y obtener las distribuciones de probabilidad. Fundamentalmente es lo mismo.

Sin embargo, hay una cosa clave: en cuanto empiezas a pensar en tu simulador de Monte Carlo como un motor de forecast probabilístico, entonces puedes evaluar su precisión —que también es muy importante y que encuentro muy deficiente en los proveedores que promueven los digital twins. Ni siquiera mencionan el hecho de que lo que tienen es un motor de forecast probabilístico, y por lo tanto debe evaluarse en términos de precisión con métricas relevantes para el forecast probabilístico.

Conor Doherty: Bien. Sé que podríamos hablar de eso para siempre, pero nuevamente, el tema anunciado era específicamente los digital twins. Hace un par de días realizaste una encuesta en LinkedIn donde le preguntaste a tu audiencia: “¿Cuáles son los mayores obstáculos para los digital twins?” porque muchas de las personas que están viendo, y que lo verán más adelante, son empresas que están considerando adoptar esta tecnología o que ya la están adoptando.

Ahora, en esa encuesta, el 52% de los votantes dijo que el mayor obstáculo eran los datos desordenados o incompletos. Primero que nada —y esto es algo que recuerdo que dijiste hace unos años—, considerando el tamaño de las empresas que considerarían un digital twin, estamos hablando de empresas muy grandes; presumiblemente, cuentan con costosos y fiables ERPs. Entonces, la pregunta es: ¿cómo es exactamente que los datos desordenados o incompletos sean un obstáculo para algo que, según dijiste, es bastante simple de implementar?

Joannes Vermorel: Aquí, si defines por datos faltantes los comportamientos —lo que caracteriza el comportamiento de todas esas entidades—, diría que sí. Pero nunca hubo, creo, una expectativa de encontrar en un ERP los parámetros que pudieran caracterizar el comportamiento de cualquiera de tus clientes, por ejemplo. Así que no creo que eso sea a lo que la gente se refiere—sin duda.

Mi opinión es que los datos siempre son el chivo expiatorio. Cuando la tecnología es súper superficial y no cumple lo prometido, invariablemente los datos malos son el chivo expiatorio. Eso realmente no coincide con la experiencia que tenemos en Lokad. Mi experiencia es que las empresas con ingresos anuales superiores a mil millones de dólares o euros tienen datos excelentes. Saben casi exactamente lo que están vendiendo, saben exactamente lo que están comprando y saben precisamente lo que tienen en stock. Sí, hay errores clericales aquí y allá, pero estamos hablando de algo como un 0.1% de error en errores clericales.

En general, en lo que respecta a la precisión de los datos, es perfecta. Todo el flujo de mercancías —desde la adquisición, transporte, transformación y distribución—, todo eso se conoce con casi certeza. La calidad de estos datos es muy alta. Sí, algunos otros datos pueden ser un poco más imprecisos, especialmente si entras en planes promocionales o cosas por el estilo, pero el historial transaccional central es excelente. Técnicamente, eso es lo único que realmente necesitas para construir un simulador. Tendrías estos sistemas que evolucionan con el tiempo, generando transacciones, y tu gemelo digital debería ser capaz de ser el reflejo de esto en el futuro y predecir el estado futuro de tus sistemas.

Pero no lo son. Ese es el problema. Según ellos, no lo son, y luego se culpa a los datos. Cada vez que escucho esos discursos sobre problemas de datos, lo que oigo es una tecnología inadecuada que esencialmente estaba generando basura, y la gente dice, “Oh, la salida es basura,” pero debe ser porque la entrada es basura —el problema GIGO, basura entra, basura sale. Pero, ¿qué pasa si la entrada está perfectamente bien? Mi opinión es que la entrada está perfectamente bien, prácticamente —y lo ha estado durante las últimas dos décadas— para la gran mayoría de las grandes empresas.

Eso no significa que no existan desafíos con los datos. Uno de los desafíos principales es que, al mirar un ERP, hay 10,000 tablas, y cada tabla tiene como 50 campos. Eso es un desafío enorme. Pero eso no significa que los datos que ahí se encuentran sean basura. Simplemente refleja el hecho de que tus sistemas de negocio no han sido diseñados para facilitarte la vida como científico de datos para poder diseñar tu simulador de Monte Carlo. Ese es un problema completamente diferente.

Conor Doherty: Hablando de problemas, otro problema citado por el 21% de los votantes fue el modelado frágil o con errores. Anteriormente dijiste que instalar esto no es especialmente complicado—es el tipo de cosa que podrías delegar a un estudiante de primer año de informática. Así que, nuevamente, vuelvo a la pregunta: si cuentas con empresas de varios miles de millones de dólares, y un ejercicio que es un proceso muy sencillo, ¿por qué una quinta parte de los encuestados dice que el modelado es el problema?

Joannes Vermorel: Los simuladores de Monte Carlo son conceptualmente muy simples y, en términos de implementación, muy directos. Sin embargo, muy pronto te enfrentarás a problemas de rendimiento muy básicos. Permíteme explicar. ¿De cuántos SKUs estamos hablando? Un millón—más o menos, para una empresa que supera los mil millones. Digamos un millón de SKUs.

Luego, ¿cuántos ciclos de CPU necesitamos para simular un SKU solo para el comportamiento del que estamos hablando? Digamos 10 ciclos de CPU como mínimo, y somos muy eficientes si decimos eso. Entonces, ¿cuántos días? Supongamos que tenemos un simulador que se ejecuta un día a la vez—100 días. Así que estamos hablando de 1 millón por 1,000 —mil millones de operaciones de CPU—para simular 100 días, a modo de estimación.

El problema es que es estocástico—es un simulador microanalítico, discreto y estocástico—por lo que necesitas repetir tus ejecuciones. ¿Cuántas veces necesitas ejecutar tu simulación para tener estadísticas algo fiables? Debido al problema de resolución, necesitas repetir al menos mil veces. Así que ahora estamos hablando de mil mil millones de operaciones. No es un problema con las computadoras modernas, a menos que hagas algo realmente sofisticado con la computadora y comiences a paralelizar y demás. Estamos hablando de unos 20 minutos de cómputo, y nuevamente hay muchas soluciones para paralelizar todo eso, pero las personas que simplemente hacen un simulador rápido y sencillo no van a hacer todo eso. Así que simplemente asumimos algo directo—bien. Veinte minutos no parecen tan mal—excepto.

Excepto que ahora quieres comprobar opciones. Por ejemplo, “¿Debería colocar esta unidad aquí o esta unidad aquí?” Cada opción que explores, tendrás que pagar este impuesto, porque vas a ejecutar tu simulación para tu línea base y luego pruebas algo y la ejecutas de nuevo. Si solo tienes una preocupación a un nivel muy alto—como “¿Qué pasa si el costo del capital de trabajo cambia? Solo quiero conocer el output”—está bien: la ejecutas dos veces y tendrás la diferencia.

Pero si quieres empezar a hacer preguntas como “¿Cuántas unidades debería colocar en cada ubicación de tienda?” tendrás que ejecutar tu simulador miles y miles de veces—una para cada micro pregunta que quieras responder. De repente, la gente se da cuenta, “Oh, 20 minutos es tan lento. Necesito ejecutar esto cientos de miles de veces, posiblemente millones—una para cada SKU o algo así.” Entonces se convierte en un gran problema. La solución se convierte en: este enfoque microanalítico en el que estaba simulando todo a nivel de SKU—ah, se vuelve un fastidio. “Así que vamos a tener una simulación a un nivel mucho más agregado.”

Pero ahora tenemos otro gran problema, y es que todo dependía del hecho de que los comportamientos de tus átomos de simulación fueran correctos a nivel de SKU. Ya era forzado decir que es fácil, que tienes comportamientos obvios que se aplicarían. Si comienzas a agregar a nivel de DC, ¿qué te hace pensar que alguna vez podrás idear las leyes correctas que gobiernan el flujo de entrada y salida de un centro de distribución? Esta es una parte muy compleja de tu red. No hay razón para pensar que leyes simplistas gobernarán esto. Lo mismo ocurre si hablamos de un cliente en B2B—un cliente que está ordenando toneladas de productos muy diversos en calendarios diversos, etc.

Así que tuviste este problema con el simulador. El simulador es fácil a nivel micro, pero muy rápidamente terminas con problemas de rendimiento. Puedes re-agregar, pero si lo re-agregas, entonces el problema de tener comportamientos precisos para tu simulador se magnifica absolutamente.

Conor Doherty: Creo que una parte clave de eso, por si es la primera vez que la gente nos escucha hablar de ello, es: cuando hablas de decisiones, las decisiones bajo el lema de Lokad no se limitan a, “Bueno, tengo una unidad; la envío allí o no.” Es decir, hay combinaciones para todas estas decisiones. Podría enviar una allí o ninguna. Puedo enviar una allí y una allá o ninguna, o dos allá y una allí, o liquidar, o puedo subir el precio de una unidad aquí en este lugar. Así que la perspectiva local es increíblemente granular, por si la gente no tenía claro cuán granular estamos hablando. Es como bajo un microscopio—así de granular.

Y, por cierto, la razón por la que somos tan granulares es que, si volvemos a modelar esos comportamientos, si queremos tener alguna confianza en el resultado económico, necesitamos estar en el nivel más básico. Es la única área donde realmente podemos reconectar cuánto costó producir esto, cuánto le paga el cliente por esa unidad, etc.

Joannes Vermorel: Exactamente. Esa es la razón por la que estamos en el nivel más básico. El problema con las iniciativas de digital twin es que muy rápidamente—con sus simuladores de Monte Carlo—se dan cuenta de que tienen problemas de rendimiento, y por lo tanto cambian directamente a un nivel de agregación superior que es más fácil de computar. Pero entonces el problema de tener esos comportamientos correctos se vuelve absolutamente enorme, y entonces sí, tienes un simulador que potencialmente puede ser ampliamente inexacto. Ni siquiera está claro por qué deberías creer en el simulador en primer lugar, porque esos comportamientos que gobiernan esas entidades son enteramente inventados.

Conor Doherty: Nuevamente, volveremos en otra charla sobre el valor de las decisiones—lo hablamos recientemente con Adam Dejans Jr y Warren Powell. Cualquiera que quiera más información al respecto, vea el video más reciente aquí. Continuando: otro obstáculo clave para la adopción mencionado por tu audiencia fue la gestión del cambio. Es algo que típicamente surge para prácticamente cualquier tipo de tecnología. Pero cuando hablamos de algo—usaste una imagen especular—lo describiste esencialmente como que, si funciona bien, tienes una imagen especular de lo que ya tienes. Entonces la pregunta es: ¿por qué una imagen especular de un estado preexistente requeriría una gestión del cambio extensa?

Joannes Vermorel: Si tuvieras —y realmente desafío que las empresas que impulsan estas tecnologías lo hagan—, pero si tuvieras algo que es un predictor de alta dimensión del estado futuro de tu supply chain, que es inspiradoramente lo que aspiran a ser esos gemelos digitales, ahora lo interesante es que, si se hace de extremo a extremo, puedes —ya no hay silos— literalmente simular el efecto de cada cambio de política que se vaya a implementar en cada silo, y entonces tienes la tasa de retorno para la empresa en su conjunto. Es muy atractivo. No lo niego. Lokad está en la misma línea.

Lo que pienso de nuevo —y por ello requiere una enorme gestión del cambio— es que, si tienes una tecnología que te permite saltarte todos los silos de la empresa, entonces va a crear desafíos por todas partes. De repente te darás cuenta de que la política adoptada por, digamos, esta división es en realidad perjudicial para la empresa en su conjunto. Tal vez mejore los KPIs de esta división, pero es a expensas del rendimiento del conjunto. Así que sí, se puede esperar que la cantidad de gestión del cambio y resistencia sea naturalmente muy alta. Esa parte, creo, es razonable.

Conor Doherty: Joannes, hemos estado hablando durante unos 35 minutos, creo, y en realidad hay varias preguntas por abordar. Voy a pasar a las preguntas del público en un momento. Por favor, formula tus preguntas antes de que terminemos. Pero, como reflexión final para esta sección —dado todo lo que hemos discutido—, ¿cuál es tu consejo de despedida para los gerentes y ejecutivos de supply chain que están en proceso de intentar adoptar esta tecnología o están considerando adoptarla?

Joannes Vermorel: Realmente necesitas echar un vistazo serio a lo que hay bajo el capó. Mi opinión es —al igual que “demand sensing”, y otras palabras de moda que circulan en los círculos de supply chain— que, pienso, en el caso de “demand sensing” no hay nada; en el caso de los gemelos digitales, la mayoría de las veces hay un poco de algo: es simplemente un simulador de Monte Carlo. Pero realmente necesitas cuestionar lo que hay bajo el capó.

Sí, la gente puede construir todo tipo de interfaces de usuario bonitas sobre eso. Pueden tener gráficos elegantes. Si ponen un mapa, puedes tener un mapa animado y demás. Eso es vender un sueño. Realmente necesitas comprobar qué hay en esta cosa. Aplica la simpatía mecánica: deberías exigirle a tu proveedor, “Por favor, dime por qué esto va a funcionar.” Y no confundas la intención. La gente dice, “Esto optimiza aquello.” No, espera. Estás optimizando la ganancia —optimizar, ese es el resultado. No te estoy preguntando por el resultado. Me estás vendiendo algo muy positivo para la empresa, pero dime cómo se está haciendo numéricamente.

Investiga. Si al final ves que son simplemente reglas codificadas de forma rígida aplicadas en secuencia para este simulador de Monte Carlo, entonces el emperador no tiene ropa. Es simplemente muy, muy superficial.

Conor Doherty: Para cerrar con tus propias reflexiones: dije al inicio que esta es una conversación que tuviste antes de que yo llegara aquí. En agosto de 2022, sobre este tema, dijiste, y cito, “My perception on digital twins is that it’s just one of those buzzwords. It looks like nothing more than a glorified simulator.” Entonces, para concluir, en los últimos tres años, ¿mantienes esas palabras?

Joannes Vermorel: Dado que se trata de una intención —“digital twin”— no he visto ningún proveedor que haya impulsado algo que realmente tuviera sustancia tecnológica. No desafío la intención. Si mañana alguien viene y dice, “Tengo un digital twin, pero en lugar de hacer simplemente un simulador de Monte Carlo súper ingenuo, al estilo de un estudiante de primer año de informática, tengo esta increíble técnica nueva, y te doy el plano de esta nueva técnica increíble; es muy elegante, y hace las cosas de formas que son muchísimo mejores que este ingenuo simulador de Monte Carlo,” diría, “Sí, absolutamente, tal vez sea realmente relevante.”

Es como si alguien dijera “AGI is super good,” yo diría, “Sí, AGI is super good. ¿Tienes uno?” Así que, de nuevo, no desafío la intención asociada con eso. Realmente desafío el conjunto de técnicas que subyacen. Y, por ahora, tres años después, aún no he visto a ningún proveedor presentar técnicas que considere notables.

¿Existe algún proveedor —y me interesaría mucho si la audiencia puede aportar algo— que diga, “Joannes, mira esas técnicas que son verdaderamente notables; están llevando el estado del arte en lo que respecta a simulaciones estocásticas”? Yo diría que estoy todo oídos. No he visto eso.

Conor Doherty: Ese es un desafío abierto. Si alguien tiene algo que quiera compartir con Joannes, conéctese con él y hágalo. De todos modos, Joannes, pasaré a las preguntas del público. Hay algunas que atender. Voy a leer —algunas son bastante largas—, así que presten atención.

De Philip: tomemos el incidente del Canal de Suez como ejemplo. Supongamos que mi modelo estima un lead time de un mes para el envío de mercancías desde Australia a Francia, teniendo en cuenta las condiciones normales de tráfico. ¿Qué pasa si un barco bloquea el canal inesperadamente, como ocurrió anteriormente? El modelo no podría prever esa interrupción, y yo sufriría retrasos y dificultades serias como resultado. Pregunta: ¿cómo manejamos tales eventos impredecibles en la modelación de la supply chain?

Joannes Vermorel: Esa es una excelente pregunta. Aquí, de hecho, el simulador de Monte Carlo de stock proporciona una visión que no está nada mal, y es la misma visión que está utilizando Lokad. Es un enfoque programático. El simulador de Monte Carlo es, fundamentalmente, un paradigma programático: implementas, en un lenguaje de programación relativamente general, tus reglas que caracterizan los comportamientos.

En Lokad, la forma en que se hace es que una gran parte de los comportamientos se aprende a partir de datos históricos. Pero, dado que es un programa, puedes interferir con él e introducir una interferencia, intencional y programática. ¿Por qué es necesario? Porque necesitas asegurarte realmente de que estás aumentando selectivamente los lead times —los lead times proyectados— para los proveedores que van a sufrir el problema en este canal.

Por ejemplo, si tienes proveedores en Asia pero están enviando cosas por aire, no quieres aumentar su lead time. Por lo tanto, debes tener mucho cuidado, y tal vez tendrás que revisar en los datos históricos quiénes fueron los proveedores que tenían el lead time correspondiente a un envío por barco —o cuentas con esa información— y luego puedes añadir programáticamente este empujón extra. Creo que tener un enfoque programático aquí es una ventaja. En el frente de los gemelos digitales, creo que están abordando el problema desde la perspectiva correcta, que es a través de lentes programáticas, tal como lo hace Lokad. En este aspecto, está bien. La situación es, en realidad, más limpia en comparación con los enfoques alternativos no programáticos que simplemente esperan tener menús y botones para cubrir cada situación posible. Si tienes acceso a un lenguaje de programación en el núcleo de tu modelo, siempre puedes implementar reglas hechas a la medida que correspondan a eventos inesperados.

Conor Doherty: Gracias. Continuaré — de Manuel: “En teoría, esta tecnología, los gemelos digitales, podría tener un gran impacto en el soporte de decisiones en supply chain. ¿Qué opinas sobre la evolución de esta tecnología y la realización de su potencial?” Creo que lo cubrimos un poco.

Joannes Vermorel: Como dirección inspiradora, la idea de tener una modelización de extremo a extremo de la supply chain es una gran idea. Lokad también está en esta línea. ¿Cuáles son los ingredientes clave? Hay muchos ingredientes clave para eso: differentiable programming es uno de ellos; el álgebra de variables aleatorias es otro; la álgebra relacional también es uno de ellos. Tienes montones de ingredientes.

La idea de tener simuladores de Monte Carlo —por cierto, por ejemplo, Lokad también tiene componentes de Monte Carlo— y hay algunas cosas muy interesantes para hacer. Si tienes comportamientos aleatorios —intencionalmente aleatorios—, parte de este proceso de Monte Carlo, se crea un problema muy sutil en lo que respecta a la depuración. Ejecutas tu programa: se bloquea —eso es malo. Lo ejecutas de nuevo: no lo hace —y eso es peor, porque tienes un error que aparece de forma intermitente, y cuando quieres observarlo más de cerca, ha desaparecido. En Lokad, llamamos a esos problemas “Heisenbugs.” Es un error que solo aparece de manera intermitente; cuando lo miras de cerca, desaparece.

Ese es un defecto masivo de la interpretación clásica y simplista de tu simulador de Monte Carlo. Es algo que las finanzas encontraron a principios de los años 90. Lo que deseas es pseudoaleatoriedad y, de hecho, algo que sea completamente determinista, incluso si tienes una simulación de Monte Carlo en marcha. Requiere trucos relativamente inteligentes. Además, quieres que este determinismo se mantenga incluso si estás haciendo computación distribuida, de modo que todo se ejecute en muchas CPUs y, posiblemente, en muchas máquinas —porque, como señalé, si tienes una CPU única, de un solo hilo, rápidamente tendrás problemas de rendimiento. No hay problema: puedes escalar a través de muchas CPUs y muchas máquinas. Pero eso requiere herramientas donde, si tienes esos errores o fallos o lo que sea, el sistema completo permanezca completamente determinista.

Mi opinión es que hay muchas cosas para, en última instancia, diseñar esos digital twins que los proveedores pueden aportar. Espero que Lokad esté trayendo bastantes de ellas. Lo que digo —la clave de mi crítica— es que las personas que se publicitan con esta etiqueta, esta palabra de moda, no aportan mucha sustancia. Es muy, muy superficial, y cuando miras lo que hay detrás —pide una demo— solo ves una simulación de Monte Carlo muy simplista e ingenua, que simplemente no va a ofrecer ese tipo de cosas.

Conor Doherty: Perfecta transición a la tercera pregunta, gracias. De Shashank —perdona si lo pronuncio mal—: “Joannes, ¿cuál es tu opinión sobre el simulador de Monte Carlo versus modelos estocásticos agenticos a lo largo de redes de supply chain?”

Joannes Vermorel: Tienes varios ángulos. Monte Carlo es una herramienta muy útil; es un truco numérico. Es muy útil —al igual que el álgebra lineal, es un truco súper básico y fundamental. En sí mismo, es muy útil. Ahora, en un simulador de Monte Carlo, toda la inteligencia reside en los comportamientos que estás simulando, porque, esencialmente, un simulador de Monte Carlo es: tengo un millón de ítems; tomo el ítem uno; tengo mi comportamiento; aplico mi comportamiento; tengo una desviación —un comportamiento no determinista—, así que obtengo la desviación en la salida del átomo uno. Luego repito para el átomo dos, tres, etc., y repito en cada período de tiempo.

Lo crucial son esos comportamientos, y eso es realmente, realmente complicado. La ventaja del truco numérico de Monte Carlo es que encaja bastante bien en el mundo muy cuantitativo y de alta dimensión de la supply chain. Si hablamos de IA agentica —eso serían los LLMs, digamos, para ser específicos—, los LLMs, por otro lado, se ocupan de secuencias de símbolos. Un LLM —un modelo de lenguaje grande— es una máquina para predecir futuras secuencias de símbolos, llamados tokens.

En términos de concordancia con los datos que tienes, realmente no está tan claro. Un LLM no es exactamente una correspondencia obvia para tu sistema de supply chain. Mi opinión es que, en el estado futuro de las tecnologías de supply chain, ¿existirán los simuladores de Monte Carlo dentro de 10 años? Sí, porque es un bloque de construcción tan básico. Es, de nuevo, como decir, “¿Tendrás raíces cuadradas en tus sistemas?” Sí. La IA agentica, como los LLMs —creo que tienen su lugar, pero su lugar podría no estar en la evaluación cuantitativa de la supply chain. Su lugar está más en la periferia, donde tienes que interactuar con clientes, proveedores o, potencialmente, incluso terceros, y luego tener conversaciones basadas en texto. Esa es una forma de aportar algunos datos o completar algunas interacciones, pero no es exactamente el núcleo de la optimización.

Conor Doherty: Gracias. Continuaré con Tao: “En tu opinión, ¿es el verdadero problema de los digital twins el hecho de que las herramientas actualmente utilizadas para simular la supply chain están defectuosas, o es que la herramienta adecuada para la optimización de la supply chain quizás ni siquiera requiera un digital twin?”

Joannes Vermorel: Es exactamente la primera razón. Esas herramientas están defectuosas —y de una manera muy específica. Se trata de una herramienta súper superficial y fácil de implementar. La gente tiene que pensar que, en el mundo del enterprise software, existe una tentación: en cuanto estás cerrando con la junta directiva, con un CEO, el precio va a ser muy alto —incluso si lo que estás vendiendo es esencialmente nada. Puede sonar extraño, pero en el enterprise software estarás vendiendo algo por más de $100,000 al año, prácticamente sin importar lo que en realidad estés vendiendo.

Así que hay este flujo constante de personas que llegan al mercado y dicen, “Mira, tengo esto, y ahora, si puedo crear suficiente entusiasmo por ello, algunas empresas pagarán por ello.” A esa escala es una gota en el océano. Si eres una empresa de más de mil millones y pagas $100,000 al año por algún artilugio, no es gran cosa; no va a poner en peligro tu rentabilidad. Pero, como consecuencia, los CEOs y las juntas directivas —los ejecutivos de nivel C en general— no necesariamente tienen tanto tiempo para adentrarse en los detalles de lo que están comprando exactamente, especialmente si el precio no es exorbitante. Para el nivel empresarial, $100,000 no es excesivo. Por ese precio, el CEO de una empresa de mil millones de dólares no va a pasar días validando estas cosas; será una decisión que debe tomarse muy rápido.

La consecuencia es que, desafortunadamente, hay muchos actores que presentan una tecnología muy sencilla —súper simplista—, pero han dominado el arte del empaquetado. Tienes tu simulador de Monte Carlo —francamente, no es nada, es un simulacro sin sustancia—, pero tiene un empaquetado llamativo y elegante. Luego presentas, tal como la definición que recibimos, una descripción que dice, “¿Quién no querría tener algo que vaya a optimizar esto y aquello, y mejorar esto y aquello, para la manufactura y todo lo demás?” Sí. “¿Cuál es el precio de este widget que mejora toda mi empresa?” “Tal y cual —$100,000.” “Está súper barato. Probémoslo.”

Pero mi mensaje es: investiga lo que hay bajo el capó. ¿Tiene realmente sustancia? El empaquetado no es suficiente. Lo que veo es un patrón: el “digital twin” llegó acompañado de un empaquetado. Una vez que has visto a otro proveedor con un paquete, replicar ese empaquetado es sencillo, porque es literalmente lo que ves desde el exterior. Lo que hay dentro —si es simplemente un simulador de Monte Carlo—, puedes contratar a un ingeniero de software y esto se implementará en cuestión de días.

Todos esos ingredientes juntos crean esta tentación de salir al mercado con el paquete adecuado, prospectar a ejecutivos a nivel C en todas las áreas, y si tienes la suerte suficiente, cerrarás una serie de acuerdos—y de repente, bam, tendrás un negocio. Sólo digo que, típicamente, este es el tipo de anti-patrones que veo en el ámbito del software empresarial.

Conor Doherty: Gracias. Y Joannes, esta es la última pregunta—siento que puedo adivinar la respuesta, pero viene de Murthy: “¿Cómo pueden los gemelos digitales evolucionar de herramientas de monitoreo reactivas a agentes de toma de decisiones proactivos en ecosistemas empresariales reales?”

Joannes Vermorel: Primero, en esta definición y en el esquema técnico que acabo de presentar, ¿qué es lo que hace que el gemelo digital sea reactivo en lugar de proactivo? Conceptualmente, nada. ¿Por qué no utilizarías este simulador—súper granular, de principio a fin—para desafiar de manera proactiva cada una de las políticas que estás a punto de implementar en tu supply chain? Obviamente, este sistema está destinado a ser proactivo.

Entonces, si la forma en que se utiliza en la práctica no es proactiva, tenemos que preguntarnos por qué. En teoría, un simulador de Monte Carlo: tienes algo que es razonablemente preciso y representativo de tu supply chain y de su estado futuro; puedes—debido a que es programático—inyectar cualquier tipo de política en él. Fantástico. Eso significa que puedes desafiar todo; obviamente, está diseñado para ser proactivo.

Pero no lo es. ¿Por qué es así? Analiza desde una perspectiva de software: ¿qué están haciendo, cómo se implementa? Eso te dará la respuesta. La respuesta es: volvemos a tener un millón de SKUs, 10 ciclos de CPU, 100 días, etc. Terminas con: sí, este sistema puede darte una simulación de lo que pasará, pero a menos que realices esfuerzos de ingeniería sustanciales—lo cual esos proveedores no hacen—obtendrás una respuesta cada, digamos, 20 minutos, o incluso cada una hora si no está súper bien implementado.

De repente te das cuenta de que tienes un problema, porque ¿cómo puedes impulsar algo hacia adelante cuando tienes este tipo de problema de rendimiento? Ni siquiera estoy hablando del problema de precisión del modelado—sólo del rendimiento básico en términos de recursos de cómputo que necesitas inyectar. Ese es un problema muy real. Por eso la gente termina con un enfoque muy reactivo, porque se da cuenta de que todo es súper lento. Esencialmente, estás intentando hacerle millones de preguntas a tu sistema, pero si necesitas esperar 20 minutos por cada respuesta, es increíble—y tienes que hacer esas un millón de preguntas todos los días.

Terminas con problemas muy básicos. Si re-agregas los datos, de repente no puedes hacer preguntas que realmente importen, porque estás en un nivel de agregación que ya no refleja las decisiones que debes tomar, tales como: “¿Necesito producir esto? ¿Necesito mover el inventario allí? ¿Debería aumentar el precio de estos productos?” De pronto, si estás en un nivel agregado—por ejemplo, si quieres razonar sobre la fijación de precios de una categoría de productos—no tiene mucho sentido decir, “Voy a aumentar o disminuir el precio de todos los productos en esta categoría.” Probablemente quieras diferenciar en función de las características de cada producto. Pero, nuevamente, eso va en contra de la idea de agregar todo.

Conor Doherty: Como una rápida mención, sé que abordas extensamente el concepto de opcionalidad en la toma de decisiones inherente al flujo de bienes físicos—tu definición de supply chain. Eso se cubre, creo, en la Lección 1.2, “Supply Chain in a Nutshell.”

Eso es literalmente lo primero—bueno. Pues mira las dos primeras, al menos, porque luego llegas a “Supply Chain Quantitativa in a Nutshell.” Eso está bastante bien—mejor que bastante bien. De todas formas, Joannes, llevamos una hora. Se nos han acabado las preguntas, y ahora se nos ha acabado el tiempo. Como siempre, muchas gracias por acompañarme y por tus respuestas.

Y a todos los demás, gracias por asistir. Gracias por sus preguntas. Si aún no lo haces, sigue a Lokad en LinkedIn, por favor. Y si no estás conectado con nosotros, envíanos una solicitud de conexión. Siempre nos alegra discutir temas de supply chain. Y con eso, a todos les digo: vuelvan al trabajo.