Debate de supply chain sobre el modelo Demand Driven Adaptive Enterprise (con Carol Ptak) - Ep 165

00:00:00 Introducción por Conor Doherty
00:00:35 Explicación del formato del debate
00:02:59 Observaciones de apertura de Joannes Vermorel
00:09:52 Observaciones de apertura de Carol Ptak
00:17:07 Réplica de Joannes Vermorel
00:22:13 Réplica de Carol Ptak
00:27:17 Observaciones conclusivas de Joannes Vermorel
00:29:19 Observaciones conclusivas de Carol Ptak
00:31:24 Preguntas de la audiencia
00:32:10 Desafíos de la toma de decisiones
00:34:56 Reflexiones sobre la teoría detrás de DDMRP
00:37:51 Enfoque Demand Driven durante la COVID
00:40:52 El enfoque de Lokad para gestionar interrupciones
00:42:17 DDAE y forecast probabilístico
00:49:14 Comparación de DDMRP con MRP
00:56:40 Tecnología mínima para la optimización
00:58:44 Implementaciones de DDMRP en grandes redes de retail
01:00:02 Significado del flujo en DDMRP
01:01:09 Adaptabilidad a nivel sistémico
01:03:35 ¿Se pueden comparar estudios de caso?
01:07:46 Gestionando la incertidumbre sobre la incertidumbre
01:12:26 Principal crítica al modelo DDMRP
01:19:19 Cuando DDMRP no es suficiente
01:24:47 Perspectiva sobre push vs pull
01:26:46 Stock de seguridad y alta variabilidad
01:29:46 Por qué el enfoque Demand Driven no está más extendido
01:35:01 El fin del debate

Transcripción completa

Conor Doherty: Bienvenidos a un episodio muy especial de LokadTV. Hoy, tengo el placer de moderar un debate en vivo y, espero, amistoso entre Carol Ptak y Joannes Vermorel. Carol es socia del Demand Driven Institute y profesora visitante y ejecutiva distinguida en residencia en la Pacific Lutheran University. Mientras tanto, Joannes, a mi derecha, es el fundador y CEO de Lokad. Es un ingeniero del Corps des Mines France y enseñó ingeniería de software en la École Normale Supérieure durante seis años.

Ahora, intentaré repasar rápidamente los parámetros del debate. Primero, el tema: “¿Es el modelo Demand Driven Adaptive Enterprise capaz de abordar los desafíos de la toma de decisiones de supply chain en el mundo real?” Carol argumentará a favor, y Joannes en contra. Primero, habrá observaciones de apertura de siete minutos, según lo acordado previamente. Joannes hablará primero, seguido por Carol. Luego, cada orador tendrá una réplica de cinco minutos. A continuación, cada orador tendrá una observación conclusiva de dos minutos. En ese momento, plantearé algunas preguntas, con suerte, completamente provenientes de la audiencia. No duden en enviar sus preguntas en el chat en vivo en cualquier momento. Ah, y al final, tendrán un intercambio libre, que es realmente lo que todos buscan aquí.

Ahora, en preparación para el debate, ambos oradores han acordado la siguiente definición, y cito: “El modelo DDAE es una herramienta de gestión para percibir cambios en el mercado, adaptarse a entornos complejos y volátiles, y habilitar estrategias de innovación impulsadas por el mercado. Sus tres componentes principales son el modelo operativo demand-driven, la planificación de ventas y operaciones demand-driven, y la planificación de ventas y operaciones adaptativa.” Ahora, para ser justos, esa es una definición larga, por lo que, precisamente por eso, hemos insertado un enlace a un Google Document abierto en el chat en vivo. Si hacen clic en él, serán llevados a un Google Document abierto en el que encontrarán definiciones detalladas de todos esos términos y biografías completas de los oradores.

Ahora, durante la sección del debate, cronometraré estrictamente a ambos oradores. La única interrupción será un recordatorio sutil para avisarles cuando se queden sin tiempo. También les recomiendo que se cronometréis mutuamente en vuestros dispositivos. Oradores, ya casi terminamos. Los oradores deben permanecer completamente en silencio durante la sección preparada del debate. Si comienzan a interrumpirse mutuamente durante sus observaciones preparadas, serán silenciados, y esto ya se les ha advertido con antelación. Y, por último, si disfrutan de lo que hacemos aquí, si les gustan los debates de supply chain, les animo a suscribirse al canal de YouTube de Lokad y a seguirnos en LinkedIn.

Y con esa descarada autopromoción fuera del camino, les pregunto a ambos: ¿Es el modelo Demand Driven Adaptive Enterprise capaz de abordar los desafíos de la toma de decisiones de supply chain en el mundo real? Argumentando en contra, Joannes.

Joannes Vermorel: Señoras y señores, estimados colegas y apasionados del supply chain, es un placer estar aquí para discutir el modelo Demand Driven Adaptive Enterprise y su capacidad para abordar los desafíos de la toma de decisiones en el mundo real. Con este mismo propósito, Carol me sugirió tres libros: “Demand Driven Material Requirements Planning” de 2016, “Demand Driven Adaptive Enterprise” de 2018, y finalmente, “Adaptive Sales and Operations Planning” de 2022.

Son 886 páginas en total, pero no se preocupen, solo necesitan leer aproximadamente un tercio de ellas. El resto es como una serie de Netflix que no puede dejar de recapitular episodios anteriores, ya que esos libros se superponen extensamente. Los ahorraré a todos y los descartaré como una obra única, excesivamente repetitiva. Como alguien profundamente involucrado en el supply chain, abordé el paradigma demand-driven con grandes expectativas. Después de todo, ¿quién no se emocionaría con un marco que promete revolucionar nuestra industria? Sin embargo, después de someterme a casi mil páginas, no estoy convencido.

Primero, las trivialidades. La página 43 de “Adaptive Enterprise”, y cito: “Si los ejecutivos quieren cumplir su misión, deben entender por dónde empezar.” Pues sí. Página 163: “Definición consistente, adherirse consistentemente a los mismos principios.” Supongo que es consistente definir lo consistente para aquellos que pudieron haberse saltado la escuela primaria. Las ilustraciones, presumiblemente destinadas a ayudar al lector, no son mejores. En la página 150, tenemos una tabla de números etiquetada como “Data”, un gráfico de barras etiquetado como “Graph”, y un fragmento de texto etiquetado, esperen, “Text”. Menos mal que lo aclaran. Estaba a punto de llamar al gráfico de barras arte moderno. Es como si los autores temieran que no reconozcamos estos conceptos básicos, pero quizás están ofreciendo un servicio público para aquellos que fallaron en su escuela primaria.

Ahora, si las partes fáciles son insultantemente simples, ¿qué hay de las partes difíciles? Tal vez el verdadero valor del demand-driven se encuentre en el medio, enterrado entre los clichés. Examinemos las ecuaciones. Y sí, incluyen ecuaciones, o al menos las etiquetan como tales. En las páginas 17, 25, 28 y 29 de “Adaptive Enterprise”, nos encontramos con lo que los autores llaman ecuaciones. Pero estas ecuaciones son solo una colección aleatoria de letras griegas y barras de fracción. No son ecuaciones en absoluto. Como alguien que también ha jugado con el editor de ecuaciones de Microsoft Word, entiendo la tentación, pero considerando que intentan enseñar una mejor toma de decisiones de supply chain, quizás proporcionar algunas fórmulas matemáticas reales sería más útil.

Por el contrario, de las páginas 99 a 105, soportamos una explicación dolorosamente tediosa en la que los autores, en un inglés sencillo, nos dicen: “Suma esto, resta aquello, y multiplica esto.” Es como leer una receta de cocina para operaciones matemáticas. Media docena de páginas podría condensarse en solo unas pocas líneas de fórmulas básicas. Pero tal vez hacerlo revelaría que las matemáticas subyacentes del Demand Driven Adaptive Enterprise carecen de la sofisticación de un libro de texto de secundaria. No es exactamente lo que se esperaría de una obra que afirma ser parte, y cito, “la ciencia emergente de sistemas adaptativos complejos.”

Para ser justos, hay una ecuación genuina en esos tres libros. Solo una. Y no, no es la llamada ecuación de flujo neto en la página 150 del libro DDMRP, que a pesar de su nombre grandilocuente, no es más que una definición. La única ecuación se encuentra en “Adaptive S&OP” en la página 156. Es el índice de capacidad Taguchi. Esta fórmula es un copiar y pegar directo de Wikipedia, pero bueno, sigue siendo una ecuación. Desafortunadamente, es una ecuación de ingeniería mecánica para tolerancias dimensionales, y generalmente se considera completamente ajena al supply chain. Aparece de forma aleatoria en medio de una discusión sobre los objetivos de rendimiento del S&OP.

Ahora, no sugeriría que los autores están intentando confundir a los lectores con ecuaciones irrelevantes. Quizás simplemente se perdieron en un mar de copiar y pegar. A medida que profundizamos entre los clichés y las pseudo-ecuaciones, encontramos numerosas llamadas a la acción. Y las llamadas a la acción son geniales. Las empresas necesitan actuar. En la página 44 de “Adaptive Enterprise”, se nos ofrece una serie de recomendaciones que sugieren que se debe capacitar a las personas para pensar sistemáticamente, que las personas deben tener un lenguaje común, un lenguaje sistémico común para pensar y trabajar, y debemos permitir que las personas comprendan las conexiones entre departamentos, recursos y personas.

Señoras y señores, qué programa tan brillante. Como CEO, me encantaría que mis 60 empleados pudieran lograr eso. Y tengan en cuenta que, en Lokad, contratamos talento de ingeniería de élite, y aun para nosotros, lo que Carol sugiere es ridículamente difícil. Solo puedo imaginar qué tan bien funcionaría esto en una empresa que emplea a miles de empleados, donde la principal conexión que entienden es tomar unas copas después del trabajo los viernes por la noche. Así que, naturalmente, anticipé la orientación del libro sobre cómo reconfigurar las mentes de mis empleados, enseñarles un nuevo lenguaje y hacer que comprendan las complejidades de cada departamento. Pero después de soltar esta bomba, los libros pasan rápidamente al siguiente capítulo, proporcionando exactamente cero orientación sobre cómo lograr estos elevados objetivos.

Para resumir, tenemos casi mil páginas que oscilan entre lo evidentemente obvio, lo totalmente trivial, lo matemáticamente sin sentido y lo extremadamente poco práctico. El demand-driven se jacta de liderar una revolución en supply chain management. Es irónico que lo único que ha revolucionado sea mi decepción con el estado actual de la literatura de supply chain.

Conor Doherty: Joannes, te quedan 21 segundos.

Joannes Vermorel: Estoy bien.

Conor Doherty: ¿Estás bien? Bueno, en ese caso, Joannes, gracias por tus observaciones de apertura. Carol, te cedo la palabra para tus siete minutos de apertura, por favor.

Carol Ptak: Oh, muchas gracias. Bueno, eso fue, en el mejor de los casos, divertido. No me di cuenta de que iba a presentarme para un informe de libro y una crítica página por página. Así que, para descartar eso, realmente esperaba que nuestro debate fuera sobre el modelo Demand Driven Adaptive Enterprise, no sobre un informe de libro y páginas citadas. Solo para dejarlo claro, esos tres libros fueron escritos para tres mercados muy separados y diferentes. No esperaba que ninguna persona allá leía las mil páginas. Simplemente pensé que, con la mente científica de Joannes, él podría disfrutar entendiendo tanto la visión operativa, táctica y estratégica de este supply chain.

Así que entremos en lo que realmente es el modelo Demand Driven Adaptive Enterprise y por qué es revolucionario. DDAE se basa realmente en la ciencia de los sistemas adaptativos complejos y en entender que los supply chains no son cadenas. Los supply chains nunca han sido cadenas. Los nombramos incorrectamente cuando los denominamos, y es porque aquellos de nosotros que estuvimos involucrados en el nombramiento de supply chains, yo incluido, provenimos de la capacidad operativa, donde estábamos acostumbrados a utilizar algoritmos de optimización para entender dónde estaban nuestros cuellos de botella y cómo podíamos maximizar la producción del proceso general basándonos en la maximización del cuello de botella.

Entonces, cuando por primera vez nombramos supply chain, dijimos, “Bueno, está bien, voy a tomar mis operaciones y las voy a conectar a mi cliente, al cliente de mi cliente, a mi proveedor y al proveedor de mi proveedor, y voilà, allí tenemos un supply chain.” Nos equivocamos mucho. Los supply chains no son cadenas, nunca lo han sido. Son sistemas adaptativos complejos, y los sistemas adaptativos complejos se rigen por una ciencia muy diferente a la de una cadena. Una cadena es un sistema lineal. Los sistemas adaptativos complejos no son lineales. Son redes. Hay muchos nodos, hay muchas conexiones, y desafortunadamente, a los académicos les encanta cortar las conexiones para poder estudiar los nodos en detalle y luego creer que podemos volver a juntarlo todo y entender el conjunto. Cuando, de hecho, en el minuto en que se cortan las conexiones, se pierde el contexto del conjunto.

Entonces, lo que hace que el DDAE sea diferente es el hecho de que entiende que los supply chains en efecto no son cadenas; son sistemas adaptativos complejos, lo que significa que no permanecen en un estado estable por mucho tiempo. En cuanto se ejerce alguna presión sobre ellos, cambian y se transforman, y por definición, no pueden ser optimizados matemáticamente. La ciencia de los sistemas adaptativos complejos surge de la idea de la biología y la economía, y por ello es muy bien entendida. Si a alguien le interesa un muy buen libro sobre el tema, existe un libro llamado “Team of Teams” escrito por el General Stanley McChrystal.

Entonces, ¿cómo funciona el DDAE? Bueno, entendemos que cada empresa hoy está en un mundo variable, volátil, incierto, complejo y ambiguo. Por lo tanto, lo que debemos ser capaces de hacer es tener la capacidad de percibir los cambios en ese mercado muy rápidamente y luego adaptar la planificación en la producción, extraer de los proveedores, y encargarnos de ello y hacerlo todo en tiempo real. Ahora, ¿una idea completamente nueva? No. La definición de demand driven existía ya en 2001. De hecho, se acuñó cuando yo estaba en PeopleSoft. Realmente no entendíamos cómo hacerlo hasta alrededor de 2006, cuando Chad Smith y su equipo comenzaron a utilizar el concepto de desacoplamiento a lo largo del supply chain. Debido al mundo VUCA, ese mundo volátil, incierto, complejo y ambiguo en el que vivimos, a menos que nuestros tiempos de respuesta al mercado sean menores que el tiempo de tolerancia de nuestros clientes, en algún lugar alguien a lo largo de la supply chain tiene que mantener inventario. Por lo tanto, el inventario es un activo. Hemos permitido que se discuta el inventario como un pasivo, como un activo, de un lado a otro, pero depende de dónde y de cuánto de ese inventario exista. Si tenemos el inventario adecuado en el lugar adecuado, entonces el inventario es claramente un activo porque mejora el retorno de la inversión para la empresa, que es la métrica relevante.

Entonces, ¿cómo es que podemos lograr coherencia en toda la organización para impulsar el ROI? ¿Cómo gestionamos esos rangos operativos, tácticos y estratégicos relevantes de manera que la empresa esté en coherencia para alcanzar el ROI? No puedo salir al piso de producción y preguntarle a Joe, que está en el piso, qué hizo para aumentar el ROI ese día, pero ciertamente puedo salir a hablar con él en el piso y decirle: “¿Qué hiciste para mejorar el flujo?” Y, de nuevo, no es una idea nueva. Hemos conocido el flujo durante un tiempo muy, muy, muy largo, remontándonos hasta los antiguos fenicios, cuando tuvieron que adaptar sus embarcaciones comerciales para convertirlas en buques de guerra.

El modelo DDAE se basa en la coherencia del flujo en la organización, la cual transforma todo en la organización. Ya no nos centramos en la eficiencia de costos y la optimización, porque reconocemos que lo que estamos gestionando no es un sistema lineal; es un sistema complejo adaptativo. Y el mundo moderno en el que lo gestionamos es un mundo volátil, incierto, complejo y ambiguo. El MRP, por ejemplo, fue concebido en los años 50, comercializado en los años 70 cuando Joe Orlicky escribió su libro. Y lo que entendíamos en ese momento es que necesitábamos poder hacer planificación dependiente, y por eso la planificación dependiente fue el verdadero activo del MRP.

Pero recuerden, en los años 50 y 60, teníamos 8K de memoria y un par de unidades de cinta, por lo que normalmente solo ejecutábamos la planificación de materiales quizás una vez a la semana, muchas empresas una vez al mes, y luego desagregábamos a partir de ahí. Y realmente pensamos que, a medida que la tecnología se volviera más rápida, las cosas mejorarían. Y de hecho, en 2001, PeopleSoft lanzó el primer sistema MRP en tiempo real, y la reacción de nuestros clientes fue: “Por favor, deténganlo”, porque no podían manejar los nervios del sistema. El nivel de precisión al intentar conectarlo a lo largo de la supply chain causa una volatilidad y variabilidad autoinducida tal que los planificadores no pueden manejarlo.

La idea es, ¿cómo podemos, al mismo tiempo, reaccionar muy rápidamente a los cambios en el mercado en un entorno volátil, variable, incierto, complejo y ambiguo y ser capaces de aprovechar la computación en tiempo real de hoy? Cuando el Dr. Goldratt y yo escribimos el libro “Necessary But Not Sufficient,” estábamos hablando de tecnología, porque lo que entendíamos era que, a medida que la tecnología cambia, las reglas de negocio tienen que cambiar. Y a medida que las reglas de negocio cambian, la tecnología tiene que cambiar. Y tenemos mucha suerte hoy en que contamos con cosas como machine learning e inteligencia artificial, que, por cierto, también se basan en la misma ciencia que el modelo DDAE.

Y así es lo que nos hace muy innovadores: ahora las reglas de negocio están alineadas con lo que la tecnología posibilita, y de esta manera podemos detectar cambios en el mercado, adaptar nuestra planificación y producción, extraer de los proveedores y aprovechar los sistemas en tiempo real que tenemos.

Conor Doherty: Bueno, Carol, te di 3 segundos extra allí, pero se invirtieron bien. Muchas gracias. Gracias. En este punto, Joannes, te devuelvo la palabra para tu réplica de 5 minutos.

Joannes Vermorel: Sí, quiero decir, lo primero es que no puedo evitar notar las contradicciones, por ejemplo, en matemáticas. Porque cuando Carol cita computadoras modernas, las computadoras, como su nombre lo indica, computan. Eso es lo único que hacen. No tienen ningún tipo de bola de cristal ni nada de eso. Y de hecho, en los mismos libros hay toneladas de ecuaciones. Nuevamente, no estoy diciendo que encontré —estoy describiendo las cosas como ecuaciones. Las cosas se mencionan y se enlistan como ecuaciones por los propios autores. Y luego, cuando abordan la no linealidad, volvemos al ámbito de las matemáticas. Así que esto no es algo que me esté preparando a mí mismo; esto es lo que los propios autores se están preparando.

Ahora, basándome en mi crítica de estos libros, que son prácticamente las escrituras sagradas de los paradigmas demand driven, la respuesta parece ser —aunque hay muchas digresiones— que el todo es más que la suma de sus partes. Exacto, no podemos realmente ver las piezas. Así que, sin importar cuán disfuncionales sean las piezas, júntalas y ¡voilà!, tienes grandeza. Es como ensamblar un auto con piezas de repuesto de Toyota y esperar un Tesla. ¿Y adivina qué? También contamos con estudios de caso que lo respaldan. Ese también es un punto de interés.

En la página 325 del libro DDAE, tenemos un estudio de caso minorista utilizando DDMRP, por ejemplo. Se afirma un aumento del 60% en los ingresos, una disminución del 40% en el inventario, y cito: “la eliminación de una sensación de escasez en las tiendas a pesar de haber reducido casi a la mitad el stock en primer lugar.” Bueno, si crees eso, tengo un puente en Brooklyn que venderte. Pero aquí está el quid de la cuestión: no podemos verificar ninguno de esos estudios de caso. Sorprendente, lo sé. Y la aprobación viene del mismo vendedor que promociona la cura milagrosa demand driven. Es como si el dueño de un restaurante escribiera su propia reseña de cinco estrellas en Yelp: “Confía en mí, es el mejor sushi de la ciudad.” Claro, pero los estudios de caso no son más que una forma elegante de decir, “Porque yo lo digo.” No es exactamente una evidencia convincente.

Ahora, en el tema, debido a que hubo tantas tangentes aquí —anécdotas, la definición de sistemas complejos adaptativos, anécdotas, ¿de dónde viene el nombre supply chain?— y algunas trivialidades sobre ERP mejorando y tecnologías y demás, la realidad es que si volvemos a una prueba simple, diría que en tiempo real de la empresa adaptativa, la página 7 enumera la no linealidad como el primer principio, el cual Carol también señaló. Así que ese es el primer principio de los sistemas complejos adaptativos. Suena impresionante, pero elijamos la no linealidad más simple que podemos tener en la supply chain: MOQs, cantidades mínimas de pedido. Ciertamente, demand driven tendría algo profundo que decir sobre los MOQs. Bueno, no realmente. A lo largo de mil páginas, los MOQs se mencionan seis veces. Eso es agradable en cada libro, más o menos dos veces en promedio por libro. Así que tenemos bastante material.

Y tomemos un ejemplo. En la página 63, tenemos un ejemplo de un MOQ que es tan pequeño que bien podría no existir, porque numéricamente no tiene ningún impacto en el cálculo. Cosas fascinantes. Y luego, en la página 115, tenemos una situación de pedido de contenedor. Interesantes no linealidades desde varios frentes con un MOQ. ¿Y cuál es la situación? Tenemos un tamaño de pedido de 100 unidades, un tamaño de contenedor de 100 unidades, y un MOQ—espera—de 100 unidades. Qué coincidencia. Es como si las estrellas se alinearan justo para no tener que lidiar con ninguna no linealidad real. Puedes repetir este proceso con reducciones de precio, perecederos productos, cross-docking, equipos reparables, lo que sea. Demand driven no tiene absolutamente nada que decir sobre estas no linealidades comunes. Nada. Cero.

Y esa es la esencia de demand driven: una teoría llamativa que se plantea objetivos grandiosos, aprovechando lo mejor que la tecnología tiene para ofrecer. Sí, pero la tecnología te ofrece computadoras para hacer cálculos, y hay tantas ecuaciones, y sin embargo no están haciendo nada. Esencialmente, nos proponemos objetivos grandiosos, pero luego no tenemos nada que ofrecer para abordar problemas comunes en la toma de decisiones. ¿Y, por tanto, debemos creer que demand driven puede enfrentar desafíos reales de la supply chain? Déjame pensar. No, absolutamente no.

Conor Doherty: Varios segundos de sobra. Gracias, Joannes. Carol, tu réplica de cinco minutos cuando estés lista.

Carol Ptak: Gracias. De nuevo, estoy muy decepcionada de que Joannes elija usar un informe de libro en lugar de debatir el modelo que se suponía debatiéramos. Pero permítanme primero abordar el caso que él está citando en el libro, y los invito a unirse a nosotros en Frankfurt la próxima semana, donde podrán hablar con la persona que realmente llevó a cabo esa implementación. David Poveda estará allí desde Medan, Colombia, y podrá darles todos los detalles.

En Demand Driven World la próxima semana, también tenemos —porque sé que siempre están muy preocupados por los casos— que, créanme, siempre los estudios de caso son realizados por la empresa de software o por el consultor, quienes siempre tratan de ponerle una cara reluciente a la manzana. No permitimos eso en el Demand Driven Institute. Todos nuestros estudios de caso los realiza el practicante. Así que los invito, Joannes, y a todos nuestros oyentes, si desean registrarse para Demand Driven World la próxima semana.

Tenemos nueve estudios de caso próximos, nuevos estudios de caso de empresas como Assa Abloy, donde Fredrik Helgesson, el director de logística, estará presentando. Otro caso de México, de Mega Alimentos, donde Antonio Treviño, el director de supply chain, estará presente. Mettler Toledo vendrá con el jefe de su planificación global, o A2A con su director general, o Gelwin con su VP de supply chain, o Sapo con su jefe de planificación, o Koch Engineered Solutions con su jefe global de planificación y programación, o PPG con su director de supply chain para América Latina.

Esos son solo los estudios de caso que aparecerán la próxima semana en Alemania. Animaría a cualquiera, confíen en mí, a que se animen. Ponemos todos nuestros estudios de caso en nuestro sitio web. Solo los realiza el practicante. No permitimos que la empresa de software ni el consultor siquiera co-presenten. Estos practicantes dicen: “Esto es lo que hicimos, por qué lo hicimos, este es el problema que tuvimos, estos son los resultados que obtuvimos,” y de manera muy franca añaden: “Y si tuviéramos que hacerlo de nuevo, esto es lo que cambiaríamos.” No monitoreamos ni editamos ninguno de sus comentarios.

Así que, al observar la idea del MOQ, creo que has citado mal el número de veces que aparece el MOQ, ya que aparece cada vez que también aparece la ecuación de flujo neto. Pero realmente sigo pensando que te estás perdiendo el punto de lo que es la Demand Driven Adaptive Enterprise. En realidad, se compone de tres rangos de tiempo relevantes separados, con las herramientas requeridas que son pertinentes para cada uno de esos rangos.

Ahora, ¿qué es la relevancia? Y esa es una definición que se encuentra en el libro. La relevancia es cómo establezco y conecto los requerimientos con lo que ocurre en ese rango de tiempo. Entonces, ¿cómo conecto más estrechamente mis activos con lo que sucede en el mercado? Simplemente implementando DDMRP, que es el motor dentro del Demand Driven Operating Model; típicamente, en promedio, las empresas logran una reducción de inventario de entre un tercio y la mitad, y habitualmente su cumplimiento a tiempo y en su totalidad aumenta a más del 90%.

Los remitiría al caso de Coca-Cola Africa para escuchar a Coca-Cola Africa hablar sobre lo que estaba ocurriendo allí. Ahora, antes de implementar DDMRP, su forecast accuracy era de aproximadamente 50%. Implementaron, obtuvieron mejores resultados, su inventario disminuyó, su cumplimiento a tiempo y en su totalidad aumentó, y al final, su forecast accuracy era de aproximadamente 50%. ¿Significa eso que no hacemos forecast? No, por supuesto que no. Necesitamos forecasts para poder operar en el rango táctico y estratégico. Lo que esperaba que abordáramos en este debate es una conversación más sobre cómo funciona el modelo DDAE en lugar de una revisión libro página por página.

Entonces, al considerar la idea del forecasting, ya saben, en el probabilistic forecasting, sí, definitivamente tiene un papel, pero tiene un papel solo en los rangos táctico y estratégico, lo que nos permite ayudar a modificar y adaptar el modelo operativo del cual DDMRP es el motor de planificación. Así que, al observar eso, tenemos que considerar que el modelo DDAE solo puede abarcar lo que podemos afectar. Por lo tanto, fuera de nuestra consideración debe estar nuestra innovación orientada al mercado, y por otro lado, tenemos que considerar la demanda real del mercado.

Y como dije antes, si tenemos la suerte de que nuestro lead time total acumulado se encuentra dentro de las expectativas de nuestros clientes, esa es una empresa fácil de gestionar. Sin embargo, ese no es el mundo en el que vivimos. Los tiempos de tolerancia de nuestros clientes son significativamente más cortos que nuestro lead time acumulado. Así que debemos contar con algún modelo de gestión que nos permita percibir los cambios en el mercado, adaptar nuestra planificación y producción, traducir un plan de negocio adaptativo en lo que significa en términos de capacidad operativa, y además explotar nuestra capacidad operativa única para aprovechar estratégicamente. Creo que ya les devolví los tres segundos.

Conor Doherty: Con cambio. Gracias. Bueno, muchas gracias, Carol. Con eso, Joannes, te devuelvo la palabra para tu comentario final de dos minutos.

Joannes Vermorel: Así que, casi mil páginas de materiales demand driven más unos pocos minutos de comentarios pueden resumirse en una nota adhesiva. Aquí no hay nada más que lo más condenatorio: el paradigma demand driven es totalmente impermeable a la razón. Podría pasar todo el día citando líneas, destacando si cada una es trivial, absurda o francamente delirante, y aún así seguiríamos estancados en el mismo lugar, como un hámster en una rueda pero sin el valor de entretenimiento. ¿Por qué es eso? Porque cada vez que señalo una falla, es como intentar jugar ajedrez con una paloma. Derriba las piezas, ensucia el tablero y luego se pavonea como si hubiera ganado.

Carol no respondió a ninguna de las críticas serias que presenté, incluidas las básicas, como el flagrante mal uso del índice de capacidad Taguchi. No explicó las pseudoecuaciones. Ella podría haber intentado refutar mis argumentos uno por uno, pero no lo hizo. Y no lo hizo porque no puede. Así que, en cambio, se nos presentan una serie de digresiones, en su mayoría argumentos de autoridad. No nos engañemos. Los estudios de caso no son más que una forma elegante de decir, “Confía en mí, soy un profesional.” Señoras y señores, apeló a la forma más elevada de razonamiento humano: la prueba del pato. Si parece un pato, nada como un pato y grazna como un pato, entonces probablemente sea un pato. Si una teoría parece basura, huele a basura y suena a basura, entonces probablemente sea basura.

En conclusión, ¿puede el modelo Demand Driven Adaptive Enterprise abordar desafíos de supply chain reales? No. Pero concederé lo siguiente: si de alguna manera logras engañar a tus competidores para que piensen que sí puede, entonces definitivamente obtendrás una ventaja, ya que ellos se desplomarán.

Conor Doherty: Gracias, Joannes. Y Carol, me dirijo a ti para tu comentario de conclusión de dos minutos, por favor.

Carol Ptak: Gracias. Bueno, estoy muy decepcionada con Joannes, para ser muy honesta. Realmente esperaba una discusión abierta y honesta en lugar de que él leyera de sus notas pre-preparadas sin considerar los puntos que se hicieron.

En cuanto a la función Taguchi, como mencioné en mi réplica de cinco minutos, el plan de negocios adaptable crea entonces un modelo operativo. Un modelo operativo tiene un objetivo, tiene un límite de especificación superior e inferior, y cuando comparamos eso con cómo funciona el proceso, ya que el modelo Demand Driven Adaptive Enterprise ahora nos permite operar con control de proceso en lugar de control de transacción como en los viejos tiempos del MRP, entonces la función Taguchi encaja, obviamente, porque queremos ver qué tan bien se desempeña nuestro rendimiento real contra ese rango definido.

Como dije, no esperaba un informe de libro página por página o una reseña. Lo que realmente esperaba era una discusión sobre la metodología en sí. Y no es “confía en mí.” Sugeriría que hables con los verdaderos practicantes y observes sus resultados reales. Para mí, eso es lo que realmente habla más fuerte que cualquier otra cosa. No es “confía en mí.” Es: “Este fue nuestro problema de negocio, esto es lo que hemos implementado, estos son los resultados que hemos alcanzado, y si tuviéramos que hacerlo de nuevo, esto es lo que haríamos de manera diferente.”

Y cuando hablamos de si el modelo Demand Driven Adaptive Enterprise cubre las necesidades de este mundo VUCA en el que vivimos y proporciona resultados reales, la respuesta es absolutamente y sin lugar a dudas sí. Las decenas de miles de personas que han pasado por la educación DDI, los resultados de las empresas, los aumentos en ROI, la capacidad de la empresa para sobrevivir a la pandemia mientras sus patrones de demanda se volvían de cabeza y erráticos y, aun así, lograban mejorar los ingresos y el ROI, creo que los resultados hablan por sí mismos.

Conor Doherty: Bueno, muchas gracias a ambos. Y Carol, gracias por esos comentarios. En este momento, voy a pasar a algunas de las preguntas del público. En realidad, ya hay bastantes en el chat en vivo. Para ser claros, pedimos que se designe a quién van las preguntas, pero obviamente se las dirigiré a ambos. Y, de nuevo, no tiene límite de tiempo, pero intenten mantener los comentarios breves para que todos tengan una oportunidad.

Pero antes de llegar a las preguntas del público, hay solo una que escribí porque los escuché a ambos hablar durante los últimos 33 minutos. Y ya saben, discutieron los libros y si se trataba de los libros o no, está bien. Pero a menos que me equivoque, en ningún momento alguno de ustedes definió realmente cuáles son los desafíos reales en la toma de decisiones de supply chain. Así que, Carol, comenzaré contigo. De la manera más breve que puedas, ¿cuáles ves realmente que son los desafíos en la toma de decisiones de supply chain?

Carol Ptak: Bueno, el mayor desafío es lo que ya dije, que es: ¿cómo respondo a un mundo que es variable, volátil, incierto, complejo y ambiguo? Y, ¿cómo lo hago de tal manera que pueda aumentar mi retorno de inversión?

Conor Doherty: ¿Joannes?

Carol Ptak: Es tan conciso como puedo hacerlo. Y si Joannes quiere ponerlo en una nota adhesiva, puede escribir eso. Resume el modelo Demand Driven Adaptive Enterprise en una nota adhesiva: todo se trata de flujo.

Conor Doherty: Bueno, gracias, Carol. ¿Joannes?

Joannes Vermorel: Mi opinión es que la supply chain es el dominio de la opcionalidad. Tienes recursos limitados de todo, y necesitas asignarlos, lo que en la práctica representa millones de decisiones diarias para una supply chain de gran tamaño. Así que resolver el problema significa, esencialmente, tomar esas decisiones. Son muy básicas. Son: qué compras, qué produces, qué asignas, qué tipo de rango de precios tienes, si aumentas o reduces tu surtido, etc., etc. Y, en mi opinión, todo eso se hace para obtener beneficios. Pero, en mi opinión, la supply chain es una teoría y una práctica que te permite realizar esta toma de decisiones a gran escala, lo que hoy en día implica que muchas cosas deben ser computadas para que pueda ser automatizada con computadoras. Eso es básicamente todo.

Conor Doherty: Bueno, Carol, ahora que escuchas la opinión de Joannes, ¿deseas modificar la tuya o estás de acuerdo o en desacuerdo?

Carol Ptak: No, para nada, pero creo, y ya sabes, habiendo estado presente desde los primeros días de las computadoras y en una conversación que tuve con una empresa de computadoras y una compañía de software, él dijo, “No obligamos a nuestros clientes a hacer las cosas de la manera en que se las decimos.” Y yo dije, “Definitivamente sí lo hacen, porque lo que incorporan en su software es lo que consideran las mejores prácticas de la industria.” Ahora, ¿qué pasa si esas prácticas son incorrectas?

Así que la metodología va de la mano con la computación y la tecnología va de la mano con la metodología. Por ejemplo, en el Demand Driven World la próxima semana, contaremos con Simo, quien puede hacer un digital twin completo de una empresa para poder comenzar a tomar algunas de esas decisiones estratégicas a las que se refiere Joannes. Pero hace eso con el potencial de un motor DDMRP instalado allí para que entienda dónde posicionar los buffers estratégicos de stock, cómo planificarlos, y cómo lograr una respuesta en tiempo real a mi mercado. Así que la tecnología en sí misma es necesaria pero no suficiente. Buen título de libro.

Conor Doherty: ¿Deseas agregar algo o puedo continuar?

Joannes Vermorel: No, continúa.

Conor Doherty: Continúa. Entonces, esta pregunta va dirigida a Joannes. Estoy leyendo esto literalmente, tal como me fue planteado. ¿Podría Joannes compartir sus pensamientos sobre la teoría detrás de DDMRP, específicamente DDMRP y cómo se fundamenta en las prácticas existentes de supply chain?

Joannes Vermorel: En resumen, DDMRP es un conjunto de trivialidades. Dimensionan los buffers con tres colores. No se especifica realmente nada en el punto de desacoplamiento. No tienes ningún algoritmo para saber cómo ubicarlos, así que, básicamente, solo proveen una guía extremadamente ambigua. También hay errores garrafales. Por ejemplo, dicen que cuando está presente el MOQ, necesitas que la zona verde sea tan grande como el MOQ, lo cual es absolutamente una locura porque hay muchas situaciones en las que reordenar hasta tu MOQ es una locura. Así que eso absolutamente no debería formar parte de lo que DDMRP denomina verde.

Pero, en definitiva, es muy, muy superficial. Ya sabes, lo que quiero decir es que, para algo que es cuantitativo, en mi opinión se podría resumir en unas tres páginas y eso es todo. Y así, es muy, muy débil. Es incluso un insulto a la investigación de operaciones, que le precedió, decir que sería su descendiente. No lo es. La investigación de operaciones ya estaba años luz de sofisticación por delante de DDMRP.

Carol Ptak: Bueno, y yo desafiaría la sofisticación frente a los resultados. Que algo sea sofisticado no significa que sea mejor. DDMRP en realidad se basa en la idea de lean manufacturing, MRP, DRP, teoría de restricciones, con alguna innovación que ahora armoniza todas esas cosas que anteriormente pensábamos que eran la antítesis entre sí. Así que, realmente, todo se trata de flujo.

Y en cuanto a cómo posicionar esos buffers, creo que probablemente se saltó esas páginas en el libro. Hay seis criterios sobre dónde se posicionan esos buffers, e incluyen el tiempo de tolerancia del cliente, el potencial de mercado, el tiempo de entrega, los waters y la variabilidad externa. Así que son seis, y eso es lo que se optimiza y se considera en un digital twin, una vez que he posicionado esos buffers.

Típicamente, lo que vemos es que las supply chains tienden a estabilizarse porque hemos eliminado la inestabilidad del sistema, y luego tanto la posición como la cantidad necesitan cambiar. Así que este es el ciclo de adaptación. No es solo puro pull; es posicionar, proteger, tirar y adaptarse. Pero somos muy claros acerca de dónde se posicionan esos buffers y de verde, amarillo, rojo, porque esa es la practicidad frente a la sofisticación. Todo el mundo entiende verde, amarillo, rojo.

Y así entiendo las reglas. ¿Qué sucede cuando veo verde, amarillo, rojo? Por eso a los planificadores les encanta y las empresas lo implementan muy rápidamente, y las implementaciones suelen ser mucho más rápidas de lo que se había planificado originalmente.

Conor Doherty: Joannes, ¿algún comentario?

Joannes Vermorel: Sin comentario.

Conor Doherty: Continuaré. Este es directamente para ti, Carol. Estoy leyendo tal como está escrito. ¿Por qué tuvo dificultades el enfoque demand-driven durante la crisis del COVID y qué deberían hacer las empresas para adaptarse en tales situaciones?

Carol Ptak: Bueno, hubo una conversación interesante durante la crisis del COVID. No tuvimos dificultades. Creo que cada proyecto de IT, cada proyecto de mejora de procesos durante el COVID se paralizó, y eso fue desafortunado. Pasamos mucho tiempo al teléfono con altos ejecutivos que decían, “Bueno, volveremos a la implementación cuando volvamos a la normalidad.” Y nuestro mensaje para ellos fue, “Bienvenidos a la nueva normalidad.”

La pregunta no es si las disruptions están llegando, sino cuándo y dónde, así que es mejor estar preparado. Y lo que hemos visto es que, después del COVID, la demanda real por nuestros cursos de educación se ha elevado a un nivel récord, y el número de implementaciones a nivel global ha aumentado a un nivel récord, porque los ejecutivos se dieron cuenta de que lo que tienen que enfrentar es este mundo variable, volátil y loco en el que estamos. No solo tuvimos COVID, tuvimos la invasión rusa de Ucrania, tuvimos la siguiente pandemia, tuvimos la locura en los puertos estadounidenses, tenemos huelgas de trabajadores portuarios. No se trata de si llegará la siguiente interrupción, sino cuándo y dónde.

Y desafortunadamente, durante la crisis del COVID, muchos equipos de ejecutivos dijeron, “Bueno, cuando volvamos a la normalidad,” y nuestro mensaje fue, “Bienvenidos a su nueva normalidad.”

Conor Doherty: Bien, gracias, Carol. Joannes, discúlpame, ¿por qué crees que el enfoque demand-driven pudo o no haber tenido dificultades durante la crisis del COVID?

Joannes Vermorel: Esta pregunta no me fue dirigida, así que me centraré en comentar la respuesta de Carol. Porque, de nuevo, no tengo datos ya que realmente no estoy al tanto de lo que sucede exactamente en las empresas que manejan esas cosas. Pero lo que diría es que, ante una pregunta tan factual como ésta, lo que obtenemos, y eso es algo muy típico de los paradigmas demand-driven, es una lista interminable de factores: ya sabes, regresión, guerra en Ucrania, volatilidad, incertidumbre, etc. Palabra de moda, palabra de moda, palabra de moda, problema, problema, situación.

Verás, es como una profusión de cosas. Pero cuando empiezo de nuevo, y los libros son exactamente iguales, tienes la lista en cada página. Se extienden en 20 tangentes, y cada vez pienso, “Bien, ahora han abierto como 20 capítulos para abordar cada una de esas tangentes,” y no obtienes nada en términos de algo concreto, matemáticamente sólido, y cuando digo matemáticamente sólido, no me refiero a matemáticas avanzadas, me refiero incluso a matemáticas de primaria, algo que no sea ambiguo, que te dé una regla que puedas calcular, y luego nada. Simplemente sigues adelante, y, de nuevo, eso es solo una profusión de interminables datitos. Y creo que eso realmente es un patrón, y me gustaría que la audiencia prestara atención a esas profusiones de datitos.

Conor Doherty: Bueno, en realidad, si puedo continuar porque la próxima pregunta irá para Joannes y luego para Carol, se las lanzaré. Pero, ¿ofrece Lokad un enfoque diferente para manejar las interrupciones como las vistas durante el COVID, y de ser así, cómo aborda esos desafíos?

Joannes Vermorel: Entonces, la respuesta larga está en la serie de conferencias de supply chain, pero es una respuesta muy larga. La respuesta corta es que usamos probabilidades y forecast probabilísticos. La idea es tener un modelo económico donde eventos que tienen una baja probabilidad y un gran impacto económico puedan ser considerados. Así que se necesitan forecast probabilísticos, y además, se necesita un segundo instrumento. Ese es el instrumento predictivo, y luego el instrumento de optimización es la optimización estocástica, que es el término general para cualquier tipo de solucionador general que pueda darte una respuesta optimizada en condiciones de incertidumbre.

En definitiva, evalúas las probabilidades de todos los futuros posibles, paso uno. Paso dos, observas todas las decisiones posibles, claro, reducidas a lo que una computadora puede gestionar, y optimizas lo que te ofrece el mayor retorno de inversión ajustado al riesgo. Esa es la respuesta corta sobre cómo lo hace Lokad, diría, en términos muy, muy técnicos.

Conor Doherty: Carol, anteriormente dijiste que el modelo DDAE, como la jerarquía de conceptos que lo abarca todo, es compatible con el forecast probabilístico.

Carol Ptak: Absolutamente, absolutamente. Quiero decir, el forecast probabilístico es algo que nos ayudaría a diseñar cómo se define el modelo operativo. Pero, ya sabes, para contradecir a Joannes sobre su respuesta, fue una respuesta científica muy complicada que básicamente se reduce a, “Sabes, la respuesta salió de la computadora, confía en ella.” Y no conozco a ningún planificador en el mundo que vaya a decir, “Oh, salió de la computadora, confía en ella.” El modelo DDAE es más comprensible.

Bien, en lenguaje sencillo, no tengo un doctorado ni dos ni tres. Y entonces, lo que plantearía es: “De acuerdo, primero tenemos que ponernos de acuerdo sobre cuál es el problema. ¿Cuál es el problema que estamos tratando de resolver?” Y por eso hablamos insistentemente sobre la variabilidad, la diversidad, ya sabes, los problemas reales del mundo real y cómo el modelo DDAE los resuelve. Y, ya sabes, la otra pregunta que tendría es: “De acuerdo, Lokad, ¿dónde está tu página con los estudios de caso de cómo has resuelto problemas para tus clientes en el mundo real con los resultados reales que presentan tus practicantes?” Y confrontaría esa página con lo que el modelo Demand Driven Adaptive Enterprise ha logrado cualquier día. Y, como dije, acompáñanos la próxima semana en Alemania, conoce a estas personas cara a cara, habla con ellos.

Conor Doherty: ¿Algún comentario? No más factores ni más digresiones ni argumentos de autoridad sobre Cherry y el pastel. Así que, sin más comentarios.

Bueno, si puedo continuar allí, Carol, de nuevo, y no quiero poner palabras en tu boca, así que corrígeme si me equivoco, pero la manera en que enmarcaste tu respuesta al comentario de Joannes fue casi como, “Bueno, yo tampoco tengo un PhD, así que, hey, no soy médico. Salí de la informática y los números.”

Parecía que te estabas posicionando a ti misma y tu enfoque como no necesariamente antiacadémico sino comprensible. Mi pregunta para ti como seguimiento es: si es comprensible pero menos efectivo que una solución más sofisticada, ¿estarías de acuerdo con eso?

Carol Ptak: No, no lo haría porque creo que es más comprensible y más efectivo. Cuando los planificadores y gerentes pueden entender cómo funciona algo, entonces lo usarán. Como dije, no hay ningún ejecutivo en el planeta que diga, “Oh, los números salieron de una computadora, bien.” Porque también desafiaría a Joannes en que no se puede optimizar una supply chain porque las supply chains son sistemas adaptativos complejos. Puedes examinar alternativas y seleccionar una, pero la realidad es que, a menos y hasta que no exista ninguna variabilidad en la ejecución, siempre habrá un rango de posibilidades que los resultados reales van a mostrar.

En demand-driven, diría que no sólo es altamente comprensible, no usamos nada superior a matemáticas de quinto grado. Así que, puedo entender por qué Joannes se sentiría insultado por la academia primordial de las matemáticas, pero al mismo tiempo, no usamos nada superior a matemáticas de quinto grado. Es muy comprensible, por lo que las empresas lo usan y ven resultados increíbles. Hay un gran estudio de caso; fue el último cuando hicimos Alemania hace unos años. Ella dice, “Sí, lo sé, lo mismo que todos: el inventario se redujo a la mitad, on-time full subió a 90%, aburrido.” Y yo dije, “Hombre, cuando te canses de ver esos resultados, estoy en el lugar equivocado.”

Entonces, te sugeriría que no sólo es más fácil de entender, sino que también es más efectivo. Pero no es la antítesis del forecast probabilístico, porque esas matemáticas pueden ayudarnos a comprender a medida que empezamos a avanzar por el modelo una vez que se ha completado la implementación inicial. ¿Cómo nos adaptamos? Y ahí es donde creo que el forecast probabilístico, los digital twins, realmente entran en juego, para comprender todas esas relaciones. Pero primero, el primer paso tiene que ser estabilizar la supply chain para poder mitigar esa variabilidad operativa.

Conor Doherty: Bien, bueno, Joannes, para ser justos, hiciste algunas anotaciones. ¿Tienes alguna respuesta a eso?

Joannes Vermorel: Quiero decir, primero, de nuevo, señalando cosas que son ligeramente ilógicas. Sí, el DDMRP y el sistema adaptativo complejo y toda esta teoría realizan una optimización. Se establece desde el principio: optimiza el retorno de la inversión. Si intentas empujar un número hacia arriba o hacia abajo, estás haciendo una optimización. Esa es la definición de una optimización. Así que, cuando dices, “Ves, ese es el tipo de cosa que es completamente esquizofrénica,” donde dices, “Oh no, en realidad no hacemos eso, no hacemos optimización,” y luego mencionas al minuto siguiente que estás intentando optimizar el retorno de la inversión. Eso es, perdón, la misma definición de optimización.

Y luego, si volvemos a…

Carol Ptak: Estamos tratando de hacer crecer el retorno de la inversión, no de optimizarlo.

Joannes Vermorel: Pero eso es lo mismo. Crecer, la optimización es literalmente una forma de tomar una función objetivo que puede ser el ROI y moverla un poco en la dirección deseada. Esa es literalmente la definición de optimización en Wikipedia. Así que, esto es exactamente lo que estás haciendo. Por eso, para mí, este tipo de enfoque es una locura.

Y luego, forecast probabilístico, lo siento mucho, pero las fórmulas y todo lo que se expone en esos libros son muy débiles. Las fórmulas, sí, también puedo, de nuevo, esto es un poco un argumento de autoridad de mi parte, pero es completamente incompatible con forecast probabilístico. Solo para darte una idea de lo que, si aplicas forecast probabilístico, se ve, lo primero es que no quieres analizar tus SKUs de forma independiente. Ponderarás la contribución de cada unidad individualmente a lo largo de toda la empresa. Eso es literalmente forecast probabilístico 101.

Así que aquí, en esta metodología, estás tratando con el buffer, un buffer a la vez. Entonces, lo siento, simplemente no es así; esas cosas ni siquiera existen en el mismo plano. No son compatibles, ni en términos de conceptos, ni en términos de metodología, ni en términos de tecnologías. Son muy, muy diferentes.

Carol Ptak: ¿Dije que el forecast probabilístico sería un buffer a la vez? Creo que una cosa que siempre hemos dicho sobre DDAE es que miramos de forma holística la causa y efecto en conjunto. Y, de nuevo, te invitaría a que asistas a una capacitación, ven a Frankfurt la próxima semana. Tenemos alrededor de tres presentaciones sobre cómo el forecast probabilístico está analizando toda la red y siendo utilizado con gran éxito dentro del modelo DDAE.

Conor Doherty: Bien, siguiente pregunta. De nuevo, esta, en realidad, Carol, es directamente para ti. Hay bastantes. Cuando nos cansemos, podemos detenernos, no tenemos que responderlas todas. ¿Cómo aborda DDMRP, de nuevo, estoy leyendo literalmente, los problemas inherentes a la lógica de MRP? ¿Requiere ejecutarse múltiples veces al día para ser efectivo?

Carol Ptak: Cuanto más cercano estés a ejecutar DDMRP en tiempo real, más estable se vuelve, porque permite a nuestros planificadores tener la información en tiempo real más relevante. ¿Es necesario ejecutarlo en tiempo real? No. La forma en que aborda las limitaciones de la lógica de MRP es que la fortaleza de MRP es que todo es dependiente, y la mala noticia de MRP es que todo es dependiente. Así que, un retraso en cualquier lugar es un retraso en todas partes.

La forma en que la lógica de DDMRP aborda eso es insertando estos puntos de desacoplamiento basados en uno de los seis criterios para determinar dónde estarán esas posiciones de independencia, de modo que absorban la variabilidad de ambos lados. Se desacopla y proporciona nuestra posición primaria para la planificación. Entre los puntos de desacoplamiento, es dependiente, como siempre lo ha sido. Por eso recibimos muchas críticas cuando lo nombramos DDMRP, y es porque MRP todavía está presente. Porque entre los puntos de desacoplamiento, sigue siendo planificación dependiente como siempre ha sido. Así que aborda las limitaciones de MRP mediante la inserción de esos puntos de desacoplamiento, y esas son las posiciones primarias para la planificación.

Conor Doherty: Gracias. Joannes, te paso la palabra para un comentario.

Joannes Vermorel: Sí, quiero decir, hay varias cosas aquí. Primero, MRP es realmente la línea base equivocada. En esencia, está utilizando una base de datos tradicional, y el problema es que un núcleo transaccional es absolutamente pésimo cuando se trata de analíticas, de todo tipo de analíticas. Así que, esto es una locura. Es una línea base insana, y por eso creo que es incorrecto comparar a MRP con cualquier cosa. Esta es una línea base anticuada que ni siquiera debería ser considerada.

Luego, cuando se trata de tiempo real, quiero decir, de nuevo, esto es algo en lo que realmente deberías cuestionar de dónde proviene la pregunta. Porque la realidad es que una computadora moderna, como línea base, te da un procesador de 2 GHz. Eso significa que puedes hacer dos mil millones de operaciones por CPU. Y una computadora moderna tiene, tu teléfono tiene ocho CPUs, así que literalmente eso son decenas de miles de millones de operaciones por segundo en un smartphone.

Entonces, la pregunta ahora es, ¿qué tienes que no se pueda hacer con una latencia de microsegundos? Y la respuesta corta es que cuando diseñas un sistema sobre una base de datos transaccional, obtienes un rendimiento absolutamente horrible. Y así, los proveedores que apenas logran mitigar ese rendimiento absolutamente horrible lo denominan tiempo real. Es realmente un disparate, quiero decir, realmente, realmente un disparate. Es simplemente un mal uso del hardware de computación moderno. Podría entrar en detalles, pero diría que aquí tenemos una línea base realmente equivocada para MRP y para el tiempo real. Esos serían mis comentarios.

Conor Doherty: Carol, creo que con parte de eso podrías estar de acuerdo, una línea base inadecuada siendo MRP, ¿no?

Carol Ptak: Bueno, la realidad es esta: MRP está siendo utilizado por prácticamente todas las empresas alrededor del mundo. Así que sí, estoy de acuerdo en que es anticuado. Estoy de acuerdo en que necesitaba un salto hacia el futuro, y por eso hicimos DDMRP. Por eso tuvimos que implementar los buffers de desacoplamiento, lo que nos permitió ejecutar operaciones de acuerdo con el control de procesos en lugar del control transaccional, que es lo que hace MRP. Todo es control transaccional. O estás bien o no lo estás en MRP. No sabes cuán bien o cuán mal estás.

Y sabes, MRP en tiempo real salió por primera vez con PeopleSoft en 2001, y a nuestros clientes no les gustó. Quiero decir, tengo la ventaja sobre Joannes de ser realmente mayor. Así que, cuando enseñaba en la universidad, los estudiantes me decían cuánto admiraban cómo investigaba la historia de TI, y es como, sí, no era investigación, esto es anecdótico, lo viví.

Y realmente pensamos que a medida que las computadoras se volvieran más rápidas, resolverían nuestro problema. Pero descubrimos que, a medida que las computadoras aceleraban, nuestros problemas empeoraban, y eso se debía al nerviosismo del sistema. Mi primera reunión de APICS hace 46 años fue acerca del nerviosismo del sistema. Lo sabíamos entonces; simplemente no sabíamos cómo resolverlo. Y no supimos cómo solucionarlo hasta que apareció DDMRP para estabilizar la función de planificación.

Pero la idea completa de APS, quiero decir, no existe ninguna implementación de APS que haya tenido éxito. Para darle a Joannes su definición, el éxito es: ¿ha incrementado el ROI de la empresa? Y es porque está intentando hacer esta optimización multi-echelon basada en una función empresarial incorrecta. Y estoy de acuerdo con él, ya sabes, la tecnología tiene que cambiar cuando hay un cambio en las reglas de negocio, y las reglas de negocio tienen que cambiar cuando hay un cambio en la tecnología. Eso es lo que Eli y yo escribimos en 2000 cuando escribimos “Necessary but Not Sufficient.” Lo hemos sabido desde hace mucho tiempo.

Conor Doherty: Gracias.

Joannes Vermorel: Sí, comentaría de nuevo, mal uso de los términos. Cuando digo transaccional para un sistema de base de datos, lo expreso de una manera muy específica. Se refiere a la forma en que se usa al diseñar bases de datos. Y cuando dices transaccional, no tiene nada que ver con finanzas o con algún tipo de proceso, etc. Significa esencialmente la propiedad ACID: atomicidad, consistencia, aislamiento, durabilidad. Esas son propiedades garantizadas por tu almacenamiento.

Y DDMRP es tan transaccional como MRP como paradigma. Y todas las implementaciones que he visto, los proveedores que hacen DDMRP, lo hacen sobre bases de datos SQL, al igual que todos los demás que hacían MRP. Así que, de nuevo, hay tantas cosas en las que usas palabras, pero no las usas de la manera adecuada. Eso significa que si te refieres a transacción, te refieres a algo que no tiene nada que ver con el objetivo, que era el diseño de sistemas de bases de datos. Te desviarás al usar transacción para algo que es más como la metodología de DDMRP.

Y de nuevo, son cosas completamente diferentes. Lo siento, solo estoy señalando que tenemos, de nuevo, factores, pero también estamos cambiando constantemente la semántica de lo que realmente significan las palabras.

Carol Ptak: Bueno, y creo que ahí es donde la conversación que tuvimos cuando establecimos este debate llega a la definición. Porque mi perspectiva del mundo proviene de toda una vida dirigiendo manufactura y siendo planificadora de operaciones, siendo planificadora en el piso de producción, siendo supervisora, siendo vicepresidenta de operaciones, y trabajando en la industria de TI como experta de la industria.

Ya sabes, abordándolo desde la perspectiva práctica del mundo real y no desde, ya sabes, lo que solíamos llamar la pequeña casa blanca, que era la TI en los viejos tiempos que tenía piso elevado. Y era a donde querías salir en verano porque tenían que estar climatizados. Así que no vengo de lo que llamamos los bit twiddlers. Vengo de la perspectiva del mundo real de cómo es que realmente operas una operación y diriges una fábrica como parte de una supply chain integrada.

Así que sí, diría que probablemente tenemos definiciones muy diferentes, pero mis definiciones serían las que utilizan los, ya sabes, esto fue parte de nuestro debate: ¿aborda los desafíos del mundo real de hoy? Y ese es el mundo del que provengo.

Conor Doherty: Bien, perdón, solo voy a insistir un poco porque hay bastantes preguntas por llegar. Pero, de nuevo, podemos retomar este punto más adelante. Entonces, a Joannes, y de nuevo, ya has tocado este tema, así que supongo que puedes mantenerlo breve. ¿Cuál es la tecnología mínima que necesitamos para construir optimización?

Joannes Vermorel: Sugiero plantear el problema desde el lado opuesto: ¿cuáles son las tecnologías que explícitamente se interponen en lograr eso? Verás, porque la realidad es que ciencia de datos, en términos generales, necesita muy, muy poco. Por eso, por ejemplo, Python es tan popular.

Así que mi opinión es que la maldición hoy en día es que los sistemas empresariales modernos son como mil capas. Tienes la base de datos, tienes los sistemas operativos, tienes todo tipo de cachés, tienes todo tipo de capas de recuperación de datos, etc., capas sobre capas. Y esencialmente, lo que diría que hacen los sistemas de enterprise software modernos es que tienden a simplemente mover datos de una capa a otra, lo que implica toneladas de recursos de cómputo, memoria, CPU, ancho de banda y demás.

Entonces, en resumen, no hay un requisito mínimo, pero tienes que ser consciente de todas las cosas que se interponen en el camino. Y en este estado moderno de las tecnologías de software, es enorme. Así que mi mensaje es: no pienses en las cosas que necesitas; piensa en las cosas que no necesitas y deshazte de ellas. Y luego, una vez que vuelvas al núcleo, el núcleo algorítmico, estarás bien.

Conor Doherty: Carol, sé que dijiste que la supply chain no se podía optimizar, pero, ya sabes, condescíbeme. Si pensaras que se pudiera optimizar, ¿qué tecnología se requeriría?

Carol Ptak: Oh, para mí, la tecnología es, ya sabes, eso lo dejo para Joannes. Sabes, vivo en el mundo real con los problemas reales de analizar las metodologías. Y luego, siempre trabajo muy de cerca porque trabajé en IBM por un tiempo, y tuve el gran honor de trabajar con el Watson Research Center. Sabes, esos son los brillantes tipos con PhD. Yo no soy uno de ellos. Sabes, soy simplemente un gerente de operaciones muy pragmático que ha tenido la gran suerte de disfrutar de una carrera muy exitosa durante los últimos 45 años.

Conor Doherty: Bien, entonces seguiré adelante. Carol, de nuevo, estoy leyendo estas cuestiones por el momento. ¿Se ha implementado con éxito DDMRP o, digamos, incluso DDAE en alguna gran organización de retail con varias cientos de tiendas? De ser así, ¿podrías dar algunos ejemplos?

Carol Ptak: Claro, sí. Uno, el primero que me viene a la mente es Mick. La mayoría de las operaciones de retail en las que se ha implementado se encuentran en Sudamérica. Así que Mick tiene, tienen varias tiendas de retail. Estoy tratando de pensar en algunos de los otros. El mayor minorista en Colombia ha implementado DDMRP. Existe un desafío único en el retail porque el retail es lo que se conoce como long tail. Típicamente, alrededor del 10% de sus productos generan el 90% de sus ingresos, y el 90% de sus productos generan el 10% de los ingresos.

Así que es una aplicación única, pero la mayoría de las implementaciones de retail se realizan en realidad en Sudamérica y México. Y además, tenemos una implementación de retail que viene desde Sudáfrica. Takealot se suponía que estaría en la conferencia, y es la tienda más grande en Sudáfrica.

Conor Doherty: Bien, gracias. Seguiré adelante. Realmente no hay mucho que agregar a esa pregunta, Carol. Entonces, has mencionado el concepto de flow algunas veces. ¿Podrías definir el concepto de flow y explicar qué significa dentro del contexto de DDMRP, por favor?

Carol Ptak: Bueno, ese es el pilar fundamental. Flow es la velocidad a la que un supply chain convierte materiales en productos requeridos por un cliente. Y eso es muy específico. Flow es la velocidad a la que un supply chain convierte materiales, insumos, en salidas que son requeridas por un cliente. Es absolutamente el pilar fundamental sobre el que se cimienta DDMRP. Además, resulta ser el pilar fundamental sobre el que se cimienta Lean y Theory of Constraints y muchas de las otras, ya sabes, áreas de mejora de operaciones más comunes y recientes, debería decir. Así que ese es el pilar fundamental. Como mencioné, si Joannes quisiera escribir una verdadera nota Post-It sobre demand-driven, todo se trata de flow.

Conor Doherty: Gracias, Carol. Joannes, hiciste algunas anotaciones. ¿Deseas responder? Bueno, esta va para ti. ¿Cómo incorpora Lokad la adaptabilidad a nivel de sistema mientras equilibra la sensibilidad de la solución a las variaciones en el supply chain?

Joannes Vermorel: Entonces, dos enfoques aquí. En cuanto a la sensibilidad a la variación, la pregunta es: ¿son deseables o no? Existen clases de recetas numéricas que son extremadamente, diría yo, precipitadas en términos de resultados, y eso es muy perjudicial porque en el supply chain se producen efectos de trinquete. Así que una vez que has activado un lote de producción, no puedes deshacerlo, por lo que debes vivir con tu decisión.

Así que realmente no deseas recetas numéricas que sean precipitadas y erráticas por sí mismas. Por cierto, uno de los aspectos del forecast probabilístico es que tiende a hacer que las recetas numéricas sean mucho más estables. Gran parte de la incertidumbre que existe en los sistemas tradicionales es que, cuando tienes un forecast clásico, una pequeña desviación del forecast tiende a desencadenar una divergencia masiva aguas abajo. De modo que ese problema se resuelve pasando al forecast probabilístico y a la optimización estocástica.

Ahora tenemos otro enfoque en la pregunta, que es la adaptabilidad. La realidad es que cuando tienes una receta numérica y sucede algo catastrófico o completamente sin precedentes, no hay sustituto para la inteligencia humana. La forma en que Lokad trabaja es contando con Supply Chain Scientists que pueden, en muy poco tiempo, reescribir y modificar las recetas numéricas para adaptarlas a la nueva situación. Nuevamente, no tenemos una bola de cristal; no podemos anticipar algo que sea radicalmente sin precedentes, como el bloqueo de un canal por parte de Evergreen.

Pero cuando sucede, hay tantos cambios que se requiere una mente humana. Sin embargo, la mente humana no está para arreglar con cinta adhesiva cada SKU individual; está para reescribir la receta numérica. Entonces, volvemos al negocio. Todas las decisiones se automatizan, y se realizan de forma automática y a gran escala.

Conor Doherty: Carol, ¿deseas añadir algo a esto?

Carol Ptak: No puedo comentar sobre Lokad.

Conor Doherty: Pues bien, esta pregunta era originalmente para ti, Carol, pero en realidad, creo que sería más interesante plantearla primero a Joannes y luego contrastar tu respuesta. Así que, Joannes, ¿por qué eres reacio a comparar estudios de caso de forecast probabilístico con DDMRP o con los de Carol? Digámoslo así.

Joannes Vermorel: Porque, en primer lugar, no creo en absoluto en los estudios de caso en software empresarial o en prácticas empresariales. El campo ha estado plagado de problemas desde, esencialmente, los años 50. El problema, nuevamente, es que existe un conflicto de intereses masivo. Piénsalo de esta manera: el proveedor no publicará el estudio de caso a menos que sea como ponerlos en un pedestal.

Y luego, los clientes, los gerentes que arriesgan su reputación cuando se embarcan en una iniciativa, tienen un incentivo masivo para que el mundo entero crea que esta iniciativa salió de maravilla. Mi observación casual es que el 90% de las iniciativas en supply chain fracasan en todas las empresas, todos los países, todos los sectores. El 90%, esa es la misma base.

¿Y cuántos estudios de caso puedo nombrar en toda mi carrera que mostraran resultados desastrosos? Ninguno, ni uno solo. El único estudio de caso negativo que pude encontrar fue, diría yo, gracias a brillantes periodistas. Por ejemplo, animo a esta audiencia a leer “The Last Days of Target Canada.” Este es un fantástico resumen de todas las cosas que salieron mal, pero es muy raro.

Leo perdió medio billón de euros hace apenas unos años en una iniciativa de optimización de inventario de SAP. Ningún estudio de caso. Así que ves mi punto. El conflicto de intereses es tan masivo que no se trata de comparar mi estudio de caso con el tuyo. Esto debe desaparecer. Esta es una metodología que debe ser rechazada por completo, punto.

Conor Doherty: Correcto. Bueno, Carol, la pregunta era originalmente para ti. Entonces, ¿por qué crees que Joannes es reacio a comparar estudios de caso con los tuyos?

Carol Ptak: Bueno, esa es una muy buena pregunta, y solo él puede responderla. Sé que él es muy reacio a los estudios de caso. Quiero decir, desde la perspectiva de un observador del mundo real, la pregunta obviamente sería: “¿Tienes alguno?” Y animo a la gente a hablar con estos muchachos, no solo con lo que se ha publicado, sino a venir y hablar con ellos para obtener los detalles.

Porque los alentamos a decir realmente, “Si tuviéramos que hacerlo de nuevo, ¿qué haríamos de manera diferente? ¿Dónde fallamos? ¿Qué no funcionó? ¿Qué pensamos que iba a funcionar?” Fomentamos ese tipo de transparencia en nuestros estudios de caso. Como dije anteriormente, no permitimos que las empresas de software ni las empresas de consultoría realicen los estudios de caso. Son las personas.

Esa es la razón por la que organizamos Demand Driven World, para permitir que estos profesionales hablen entre sí y puedan tener ese tipo de conversaciones sobre qué funcionó, qué realmente no funcionó, qué aprendieron y cómo podemos aprender unos de otros. No solo los éxitos, lo cual es importante, sino ¿cómo aprendemos de los fracasos? ¿Qué no salió bien?

Y creo que eso es absolutamente igual de crítico. Si podemos ayudar a compartir los fracasos para que alguien más no tenga que tropezar con el mismo bordillo, entonces creo que es algo bueno. Por eso hacemos Demand Driven World. La mayoría de nuestras implementaciones están en Europa, por lo que iremos a Europa la próxima semana.

Pero creemos que los estudios de caso son absolutamente críticos porque es lo primero que nos piden. Entiendan, Demand Driven Institute, no somos una empresa de consultoría. No somos una empresa de software. Nunca hemos sido una empresa de software, y nunca hemos sido una empresa de consultoría. Solo somos líderes de pensamiento en el área de supply chain. Así que somos muy independientes de todas las empresas de software.

Pero a medida que la gente consideraba el enfoque demand-driven, cambió justo después de la pandemia. Diría que pasó de “¿Has probado demand-driven?” a “¿Por qué no has probado demand-driven?” Y eso fue debido a los resultados que la empresa observó durante la pandemia, cuando ya tenían implementaciones en marcha.

Conor Doherty: Bien, seguiré, pero volveré contigo, Carol. Primero, de nuevo, en realidad es para ambos, pero empezaré con Carol porque ya estabas hablando. En un mundo altamente VUCA con una demanda dispersa y errática, ¿cómo tomarías decisiones sin aumentar significativamente los niveles de stock? Y sub-pregunta, ¿cómo manejas la incertidumbre sobre incertidumbre en situaciones tan desafiantes?

Carol Ptak: Bueno, y ahí es donde realmente necesitas entender el negocio. Esa pregunta no brinda suficiente información. ¿Qué es la incertidumbre sobre incertidumbre? ¿Cuánta de esa incertidumbre es autoinducida? ¿Cuánta de esa incertidumbre se debe a tu estrategia de precios? Hay muchas capas de la cebolla que pelar para llegar a la causa raíz.

Estaba justo en una conferencia en Wisconsin cuando una empresa de software se me acercó y dijo, “¿Cómo propondrías hacer la asignación en caso de escasez?” Pregunté, “¿Tu cliente tiene inventario excesivo?” “Oh sí, tienen demasiado de lo equivocado, muy poco de lo correcto.” Respondí, “Bueno, resuelve ese problema.” A veces lo que vemos es que esta variabilidad sobre la variabilidad es autoinducida.

Si quiero ser un proveedor de respuesta rápida, de alta variabilidad y bajo volumen, no lo lograrás importando desde China. Esa es una estrategia diferente. Tu estrategia debe estar alineada con tu capacidad operativa, y tu capacidad operativa te permite tener diferentes ventajas estratégicas. Esas cosas deben coincidir. Por eso DDAE analiza la estrategia, lo táctico y las operaciones y separa esos tres ámbitos relevantes.

Conor Doherty: Gracias. Joannes, misma pregunta.

Joannes Vermorel: Entonces, esa es una pregunta muy interesante. Comencemos con comportamientos dispersos e intermitentes. Dispersos y erráticos, sí, ahí es donde el enfoque probabilístico realmente brilla. Cuando tratas con algo que es disperso, debes tener un instrumento matemático que te permita lidiar con patrones por subunidades.

Si simplemente preguntas, “¿Cuántas unidades voy a vender durante el transcurso de una semana?” podrías decir, “50% de probabilidad de vender solo una.” En el mundo clásico, dirías 0.5, pero no tiene sentido porque no puedes fraccionar la unidad; está empaquetada. La perspectiva clásica tiene dificultades con las predicciones por subunidades, lo que resulta en muchas tonterías porque terminas con números fraccionarios que simplemente no son reales. Existen en las matemáticas, pero no existen en la supply chain donde solo es cero o uno.

Con las probabilidades, obtienes una solución elegante y agradable que realmente funciona, donde puedes tener una probabilidad para cero, una probabilidad para una, una probabilidad para dos, digamos, unidades, y tal vez una probabilidad para 50 unidades también, lo cual será el pico errático. Así que, en casos dispersos e intermitentes, es donde realmente brilla.

Ahora, cuando apilas incertidumbre sobre incertidumbre, esta es una pregunta muy interesante. ¿Cómo lo haces en un mundo determinista cuando añades un retraso sobre otro retraso? La respuesta: haces una suma, una adición que se siente como algo supernormal. Así que, puedes sumar, restar, multiplicar. Pues bien, resulta que cuando tienes incertidumbre, si tienes algo como un álgebra de variables aleatorias, puedes hacer todas esas combinaciones de incertidumbres, y obtendrás, a través de este álgebra de variables aleatorias, la capacidad de calcular efectivamente el tipo de incertidumbres resultantes que tienes encima de todo eso. Así que, no estoy describiendo exactamente la solución; solo estoy describiendo los instrumentos que te permiten llegar a ello.

Primero, necesitas tener, diría yo, instrumentos estadísticos que aborden la escasez y la erraticidad. Así que, ese no va a ser tu típico tipo de forecast. Ese no va a ser los buffers que son promedios móviles glorificados que se presentan en DDMRP. Y segundo, cuando te enfrentas a incertidumbres compuestas, necesitas tener los instrumentos que te permitan hacerlo. La gente ha estado haciendo eso durante medio siglo en finanzas. Esto no es magia. Lokad no inventó eso. Es solo un instrumento un poco inusual, pero es muy sencillo. Así como sumar, restar números y multiplicarlos se siente natural, simplemente aprenderás a hacerlo con la incertidumbre involucrada.

Conor Doherty: Bien, gracias. Seguiré. Bien, esta es una pregunta bastante extensa. Voy a intentar resumirla en tiempo real. Eh, bien, quiero decir, esto será para ti, Joannes, porque ya has respondido en parte a esto. Hay algunas partes móviles, pero lo leeré como base.

Para Joannes: ¿cuál es tu principal crítica al modelo DDMRP, y qué aspectos específicos de él estás cuestionando? Creo que ya has respondido esto, pero no he escuchado un argumento sólido en contra de DDMRP más allá de que es demasiado simple. Si un modelo simple puede ofrecer resultados, ¿por qué necesitamos modelos de dinámica de sistemas más complejos y sofisticados?

Joannes Vermorel: Mi principal crítica es que hay excesivamente poco, ya sabes, y por eso estaba señalando páginas. Porque cuando tomas las piezas, te das cuenta de que es mayormente mucho de nada. Y la idea de que a partir de mucho de nada ensamblado, vas a tener, ¡voilà!, un gran conjunto, creo que es completamente absurdo. Así que, mi principal crítica es que es muy, muy débil, tanto línea por línea como en su totalidad.

Y luego vuelves a por qué funciona tan bien. La pregunta, si ya asumes que todos los estudios de caso son ciertos—lo siento, no puedo hacer nada por ti. Si asumes, al igual que el estudio de caso es cierto, que puedes obtener un aumento de facturación del 60% de manera fiable aplicando DDMRP al retail mientras se reduce a la mitad el stock en el mismo proceso y se da la impresión de que la tienda está aún más llena, si crees que ese es el tipo de resultado que puedes obtener, ya sabes, porque eso es lo que se presenta—lo siento, de nuevo, tengo un puente en Brooklyn para venderte. Eso es todo.

Conor Doherty: Bueno, Carol, de nuevo, en realidad quiero hacer un seguimiento, y se basa en eso. Así que, de nuevo, esta es una pregunta basada en escuchar a Joannes y también en captar la conversación en su totalidad. Al principio, comentaste: “Me sorprendió que Joannes quisiera hablar sobre los libros.” Y, de nuevo, no voy a hablar por Joannes, pero ciertamente para mí, si dijeras, “Oye, ¿quieres aprender sobre algo? Aquí tienes varios libros que explicarán, como manuales, ¿cómo despega el avión?” Lees sobre aviation o aeronáutica, aprendes sobre el principio de Bernoulli. Está escrito en un libro. Así que, no aprendo que los aviones vuelan; leo ese libro para aprender cómo vuelan.

Entonces, cuando hablas de estudios de caso, y, por el bien del argumento, simplemente diré que funciona, ¿de acuerdo?, pero creo que para Joannes y quizá también para las personas que escuchan, el problema es que si quiero aprender cómo funciona, estás diciendo que no está en los libros.

Carol Ptak: Oh no, claramente está en los libros. Joannes está diciendo que no está en los libros. Está en los libros. Escribimos esos tres libros para tres mercados muy distintos y separados. El libro “Demand Driven Adaptive Enterprise” fue escrito para que un ejecutivo entienda cómo se compone todo. El libro “Adaptive S&OP” fue escrito para el equipo de S&OP sobre cómo ahora enlazamos un proceso estratégico de S&OP que genera un plan de negocio adaptable que puede ser traducido a un modelo operativo demand-driven. Y el libro “DDMRP” es muy específicamente sobre cómo funciona el motor DDMRP.

Ahora, me encanta la crítica de que es demasiado simple. Creo que ese es el mejor cumplido que puedo recibir. ¿Por qué? Porque es muy fácil hacer las cosas complejas. Es muy difícil hacer las cosas simples. Y hemos trabajado muy, muy duro para que el concepto sea fácil de entender y sencillo de implementar.

Así que, toda la conversación de hoy es sobre: ¿resuelve el modelo DDAE el problema en la supply chain del mundo real hoy? Bueno, eso es del mundo real. Tenemos que tener algo que sea comprensible, fácil de implementar y que genere resultados significativos. Sabes, al examinar las herramientas de pensamiento crítico, siempre buscas esa idea revolucionaria que resuelve muchos problemas y lo hace de una manera muy profunda. Y eso es lo que hace demand-driven.

Quiero decir, me encanta Eli Goldratt. O sea, él siempre decía las cosas tan bien. Sabes, dijo: “Si tienes que usar matemáticas para explicarte, entonces no sabes de qué estás hablando.” Me encanta Goldratt. O sea, él propuso grandes ideas, ya sabes, así que si la peor crítica de Joannes es que no le gusta lo que llamamos una ecuación, de acuerdo, el resto del mundo las llama ecuaciones. Y existen ciertos requisitos de formato por parte de una editorial, y no sé cuántos libros ha publicado Joannes, pero hay ciertos requisitos de formato al sacar un libro, en los que realmente tienes que etiquetar las cosas como gráfico y figura, ¿de acuerdo? Y es un requisito.

Entonces, tratas con las editoriales, y estaríamos encantados de eliminar todo eso, pero es un requisito. Así que, no sé cuántos libros has tenido la experiencia de publicar, pero verás que ese es un requisito cuando publicas con algunas de las editoriales de primer nivel, como si todas esas cosas tuvieran que estar etiquetadas. Por lo tanto, llamar a lo que hacemos simple es el mejor cumplido que se me puede ocurrir, porque trabajamos muy, muy duro para que sea simple de entender, simple de implementar, pero que produzca resultados profundos.

Conor Doherty: Bien, gracias, Carol. Le paso la palabra de vuelta a Joannes.

Joannes Vermorel: Sí, creo que es una tergiversación de mi crítica. No dije que esos libros sean simples. Al contrario, expresé extensamente que son muy enrevesados para presentar cosas que, al final, son muy simples. Es decir, pasas literalmente media docena de páginas en inglés diciendo, “Suma esto, resta aquello, multiplica por aquello.” Es simplemente increíblemente difícil seguir lo que se habría representado, de nuevo, con fórmulas de primaria, como súper básicas.

Y, por el contrario, verás, ese es el punto con este libro. No estoy criticando que sean demasiado simples. Ese no es mi punto. Mi punto es que son extremadamente débiles. Esa es una crítica muy diferente. La debilidad no es simplicidad. Puedes tener cosas que sean extremadamente simples y hermosas. Las ecuaciones de Maxwell, ya sabes, extremadamente simples, hermosas. Sí, el formalismo es bastante elaborado, pero este no es el tipo de problema de simplicidad del que estoy hablando.

Mi punto es que esos libros podrían haberse simplificado drásticamente, de hecho drásticamente, nuevamente, adhiriéndose a las normas establecidas de cuando tienes cosas que quieres sumar, restar, etc., simplemente usas una fórmula simple, y no extiendes en literalmente media docena de páginas de explicaciones extremadamente complicadas y enrevesadas para explicar lo que es simple. Y mi punto, la crítica, es que al hacer eso, inflas el número de páginas, inflas la masa de palabras para, al final, entregar muy, muy poco en, de nuevo, 900 páginas.

Conor Doherty: Muy bien, continuaré. A este punto, llevamos 80 minutos, así que voy a empezar a eliminar preguntas que ya han sido respondidas. Así que, de nuevo, no voy a preguntarle a Joannes sobre estudios de caso de DDMRP otra vez. Hemos recorrido ese terreno bastante bien. Sí, así que esto, le paso la palabra a Carol.

¿Pueden definir conjuntamente el alcance, las situaciones o condiciones en las que se requiere algo más sofisticado que DDMRP? Por ejemplo, en procesos de desarme, DDMRP parece quedarse corto. ¿Cómo abordarías tales escenarios?

Carol Ptak: En realidad, en desarme, funcionó muy bien. Uno de los primeros estudios de caso fue una empresa llamada Erickson Air-Crane. Lo siento, Joannes, por volver a un estudio de caso, pero Erickson Air-Crane en realidad tiene el certificado de vuelo para el helicóptero Sikorsky. Y por lo tanto, cuentan con un proceso completo de desarme. Así que en realidad funciona muy, muy bien, y funciona allá muy bien debido al alto nivel de variabilidad.

Cuando llega una aeronave, aterriza según lo mantenido. Ahora tienes que determinar cómo fue construido, diseñado, y luego tienes que intentar modernizarlo por completo. Y luego tienes un problema con tu certificado de vuelo de la FAA que dice que una parte fue modernizada y es válida hasta el 31 de octubre de 2024, pero otra parte fue modernizada y es válida hasta el 1 de junio de 2025. El fuselaje solo está certificado hasta el 31 de octubre de 2024 porque todas las partes deben coincidir. Así que cuando te enfrentas a ese tipo de alta variabilidad, en realidad funciona bastante bien.

Lo que les digo a las personas —siempre me preguntan: “¿En qué industria no encaja?"— es que la industria en la que demand driven no encaja es aquella en la que estás en un sector de alta fiabilidad donde el tiempo de tolerancia de tu cliente es más corto que tu tiempo de entrega acumulado y no experimentas variabilidad en las operaciones, entonces no funcionará.

Implícitamente, no, no he encontrado ese lugar en el mundo, pero oye, sabes, teóricamente, podrías llevarlo a ese punto. Cuanta más variabilidad, volatilidad, incertidumbre, complejidad y ambigüedad haya, mejor funciona porque fue diseñado. Demand Driven Adaptive Enterprise fue diseñado para el mundo VUCA de hoy, y funciona en el mundo VUCA de hoy.

Conor Doherty: Te dejo responder.

Joannes Vermorel: Sí, simplemente tomaré este ejemplo como, nuevamente, para la audiencia. De acuerdo, hablemos de aviación. Así tenemos piezas que tienen horas de vuelo y ciclos de vuelo. Lo estoy haciendo muy simple para la audiencia. Eso significa que, al observar tu inventario, no puedes decir, “Tengo una unidad, dos unidades, tres unidades, cinco unidades.” Realmente no tiene sentido porque cada unidad que tienes tiene una cierta cantidad de horas de vuelo y ciclos de vuelo, por cierto.

Así que puedes terminar con miles de horas de vuelo pero con solo una pieza o tal vez solo 100 horas de vuelo pero tienes dos piezas por alguna razón. Así que la conclusión es que lo que ya no puedes hacer es tener una representación unidimensional de tu SKU. Entonces no puedes decir, “Tengo una, dos, tres, cuatro, cinco unidades extra.” Necesitas una representación multidimensional del SKU.

Y nuevamente, si vuelvo a DDMRP y a todo lo que está en los libros, esos puntos nunca, jamás se tocan, ni siquiera algo que pudiera abordar esos puntos conflictivos. No se tocan. Garantizo a esta audiencia que no encontrarán nada que les permita tratar problemas de SKU multidimensionales. Y sin embargo, es literalmente el tipo de no linealidad y complejidad que los libros se propusieron como metas desde el principio.

Carol Ptak: Estoy de acuerdo con Joannes, absolutamente. Sí, no cubrimos las piezas multidimensionales. ¿Significa eso que no sabemos cómo hacerlo o que no sabemos cómo implementarlo? Absolutamente no. Mi experiencia es en aeroespacial. Hice mucho trabajo con los depósitos de aviación de la NAA en Cherry Point, Jacksonville y en California, así como con las compañías de helicópteros. Quiero decir, esa fue mi carrera. Si investigas, pasé 20 años en aeroespacial.

Así que entiendo las piezas multidimensionales porque tienes diferentes números de SKU con diferentes códigos de condición y con diferentes horas de vuelo en ellos. Y Joannes, tienes toda la razón. No cubrimos las piezas multidimensionales en ninguno de esos libros. Ahora, quiero decir, si quieres leer un libro de ERP, mi libro de ERP es la primera vez que la remanufactura aparece en un libro. Pero es un ambiente tan especializado que si incluyéramos todo sobre cada ambiente que existe, esos libros tendrían 3,000 páginas.

Esos son los fundamentos, los bloques de construcción de cualquier empresa adaptativa orientada a la demanda. Hay diferentes dimensiones que añades, como ya hemos discutido el retail, ya sabes, hablamos de aeroespacial, hablamos de remanufactura, de gestión de proyectos. ¿Qué tal una empresa que nunca usa el mismo material dos veces? Implementaciones de demand-driven muy exitosas. Así que esos libros representan los bloques de construcción.

Sabes, es como mencionaste antes: si leo sobre vuelo, sí, voy a leer los libros y voy a entender el principio de Bernoulli y todo eso, pero no te va a convertir en piloto de un 747.

Conor Doherty: Eso me haría ingeniero solo por completar ese símil. Pero Joannes, tu…

Joannes Vermorel: No, creo que de nuevo nos enfrentamos, para la audiencia, a un argumento de autoridad, que mencioné inicialmente, que es, “Confía en mí.” De todas formas, sugiero que avancemos para no volver a los mismos argumentos.

Conor Doherty: Bueno, está bien. Bueno, este es para Joannes. Así que APICS y ASCM también enfatizan la importancia de la frontera push-pull. En tu solución, ¿en qué punto de la red de supply chain haces la transición de un enfoque push a uno pull?

Joannes Vermorel: Primero, la distinción entre push y pull proviene nuevamente de una línea de base equivocada. Así que estamos volviendo a esa mentalidad de los años 70 en la que se asumía que las diferentes partes de la organización no podían comunicarse entre sí. En efecto, tienes que tener una parte que decida cuándo empujar o la parte que decida cuándo tirar. Pero, nuevamente, esto es una especie de tontería en esta era de internet. ¿Por qué es eso? Muy simplemente, puedes poner una inteligencia encima, artificial o no, no importa, siempre y cuando tengas una red.

Lo único es desencadenar decisiones. Si decides mover 10 unidades del punto A al punto B, quiero decir, es solo una perspectiva decir que si es el punto A el que solicita las unidades, entonces estás tirando. Si es el punto B el que decide, entonces estás empujando. De nuevo, esta no es una distinción válida en esta era de internet. Así que mi opinión sería: por favor, no mantengas esos conceptos que quedaron obsoletos hace 25 años, prácticamente por la idea de que tienes una red de internet y, por lo tanto, la información puede fluir libremente a través de tu supply chain.

En Lokad realmente no nos ocupamos de eso porque es un problema que está obsoleto, y solo existe en empresas que persisten en usar, diría yo, metodologías y perspectivas obsoletas.

Conor Doherty: Bien, hay dos preguntas más y luego haremos la transición porque ya ha pasado un tiempo. Pero Joannes, primero tú. ¿Qué tan efectivas son los cálculos tradicionales de existencias de seguridad para una empresa que gestiona tanto alto volumen como alta variabilidad en su operación?

Joannes Vermorel: El stock de seguridad está fallido por diseño en tantos frentes. Seré breve, pero la conclusión es: ¿por qué está completamente fallido? Cada vez que inviertes $1 en tu supply chain, ese $1 compite por todas, digamos, las inversiones en inventario. Compite con todos los SKUs. Todos los SKUs compiten por ese $1. Tu modelo de stock de seguridad asume que puedes procesar un SKU en aislamiento completo, sin tener en cuenta todo lo que sucede en los otros SKUs. Ese es literalmente el modelo de stock de seguridad.

Así que, con solo este supuesto, el stock de seguridad está completamente fallido. Y luego tienes un segundo problema, que es un detalle de implementación, pero en la práctica, es realmente fatal: la suposición de la distribución normal que se hace encima de eso. Así que el stock de seguridad invariablemente implica, tanto en libros como en implementaciones de software, que se usen distribuciones normales tanto para la demand como para los tiempos de entrega. Y esto es una locura.

Así que el gran problema es, nuevamente, que todos los SKUs compiten por la misma inversión. Cualquier lógica independiente del SKU está fallida por diseño. Y luego tienes un segundo problema, que es la matemática que se está utilizando, la cual es realmente inadecuada.

Conor Doherty: Gracias. Carol, ¿cuáles son tus pensamientos?

Carol Ptak: Me emociona haber encontrado otro punto de acuerdo con Joannes. El stock de seguridad está fundamentalmente fallido, absolutamente. Muy bien, es una de las dos cosas que eliminamos en la metodología orientada a la demanda. La razón es que los stocks de seguridad, tal como se calculan a través de cualquier software de optimización MEIO, asumen que para tener un mejor servicio al cliente, debes tener más inventario y que puedes calcular la cantidad de stock de seguridad requerida, como dijo Joannes, de forma aislada, SKU por SKU, analizando la variación y el z-score para tu nivel de servicio.

Eso es ridículo. Es absolutamente ridículo, y a eso lo llamamos una verdad profunda. Una verdad profunda solo puede ser expuesta por una verdad aún más profunda, que es, de nuevo, lo que se resume en ese Post-It que desearía poder poner en la oficina de Joannes: “Todo se trata del flujo.” Cuando tenemos un mejor flujo, obtenemos un mejor servicio al cliente con menos inventario al mismo tiempo. No es una compensación, ya sabes.

Los sistemas MEIO que intentan optimizar esas dos posiciones de la cantidad de inventario y el servicio al cliente están absolutamente, fundamentalmente rotos, y el enfoque demand-driven no utiliza safety stocks. Así que estoy de acuerdo con Joannes, absolutamente en lo cierto.

Conor Doherty: Muy bien, y de nuevo, haremos una última pregunta. Hubo otras preguntas, pero nuevamente, quiero pasar a la siguiente sección. Cualquier cosa que no se haya respondido, la abordaremos en LinkedIn. Pero en realidad, esta es una pregunta que llegó, Carol, de alguien que es fan tuya, de hecho. No voy a decir el nombre, pero alguien que es fan tuya. Así que esto realmente viene de buena fe y en buen espíritu.

Entonces, Carol, a ti: Si la crítica de Joannes es completamente incorrecta, si está totalmente equivocada, ¿por qué, en tu opinión, crees que el enfoque demand-driven no es más extendido ni más popular?

Carol Ptak: Bueno, eso es interesante. Sabes, yo no… su crítica… bueno, déjame retroceder. Mi decepción fue que pensé que nuestro debate hoy sería sobre la metodología, no sobre números de página y el etiquetado de cosas, gráficos y figuras, que nos imponen nuestros editores. Así que me decepcionó la profundidad de nuestra discusión de hoy.

Creo que las preguntas que hemos ido intercambiando al final fueron lo mejor de todo, en lugar de que Joannes leyera sus notas pre-preparadas al entrar. Así que yo buscaba una discusión más dinámica. ¿Por qué el enfoque demand-driven no es más prevalente? En realidad, es muy conocido en ciertos países y depende del equipo que lo implemente en el país. En Francia, es muy, muy conocido, por lo que hemos sido el blanco junto a Joannes durante muchos, muchos años.

Él ha estado atacando la metodología demand-driven durante muchos años debido a su visibilidad en Francia. Nuestro país número uno es Francia. El número dos es Colombia. El número tres es México. Acabamos de expandirnos a Japón. Estados Unidos está creciendo como loco. Así que estamos viendo que algunas compañías de productos de consumo muy grandes, como Fortune Brands, la han estado implementando. Tenemos algunas marcas menos conocidas, como Toyota y Caterpillar, que la han estado implementando.

Así que cuestionaría el hecho de que no sea más conocido. Han sido empresas muy, muy grandes las que típicamente han adoptado la idea. También hemos tenido algunos pequeños negocios familiares porque entienden el impacto y la importancia del flujo de caja. Lo más emocionante es que nos expandimos a China durante la pandemia, y ahora recién nos estamos expandiendo a Japón. El equipo en Japón dice: “Sabes, nos damos cuenta de que lo que hemos estado perdiendo es el enfoque demand-driven porque el enfoque Kaizen es limitado y necesitamos una idea revolucionaria.” Ellos creen que el demand-driven es precisamente eso.

Así que el hecho de que nuestro diccionario demand-driven esté en 12 idiomas, y el examen en nueve, cuestiona que no sea más conocido. Los de nosotros en la comunidad tendemos a fijarnos en cuántas empresas no lo están utilizando, en oposición al tamaño y la amplitud de las empresas que sí lo hacen. En el punto de vista de Joannes, muchas empresas, una vez que lo han implementado, no se escucha su estudio de caso porque lo consideran una ventaja competitiva, y eso es desafortunado.

Conor Doherty: Muy bien, Joannes, voy a modificar un poco la pregunta porque, obviamente, las razones por las cuales crees que no funciona no necesariamente coincidirán con personas que no tienen, de nuevo, tu nivel de formación académica. Entonces, ¿por qué crees que, para otros practicantes, no es más extendido, más adoptado?

Joannes Vermorel: Es decir, de hecho, diría, muy, muy de hecho, porque mi opinión es que es extremadamente ambigua. Hay algunos métodos, si tuviera que compararlos con otras teorías de supply chain—no las mías, de nuevo, dejemos de lado mis propias ideas—digamos que si me refiriera a teorías rivales, por ejemplo, flowcasting. Yo tampoco creo en flowcasting, pero ellos son extremadamente específicos en su teoría, extremadamente, extremadamente específicos.

Así que, si quiero implementar un software de flowcasting, puedo tomar el libro de flowcasting—se llama flowcasting—y literalmente me dan todo lo que necesito. Es con casi cero ambigüedad sobre lo que necesito hacer para implementarlo. No estoy diciendo que flowcasting sea bueno; en realidad, creo que es bastante terrible. Pero, en mérito a los autores, la teoría que presentan no es ambigua ni vaga. Aquí, en DDMRP, diría que la crítica principal es que es extremadamente vaga, sumamente débil y es muy difícil enmarcar algo.

Si me quitara el sombrero como editor de software y dijera que quiero implementarlo, es tan increíblemente vago que ni siquiera sé por dónde empezar. Lo siento, y sé que es algo subjetivo, así que solo puedo decirle a la audiencia: tomen uno de esos libros, lean 10 páginas al azar y pregúntense: “¿Puedo tomar lo que se ha dicho y, sin ambigüedades, hacer algo para mi empresa?” Sin ambigüedades. Hazte tu propia pregunta, y la respuesta que obtengas a esa pregunta debería ser el verdadero juez de si lo que estoy diciendo es correcto o simplemente tonterías.

Carol Ptak: Bueno, desafiaría esa idea de que cualquier libro que tomes y leas 10 páginas te dará el panorama completo. La manera en que todos nuestros libros están escritos es: primero describimos el problema, luego describimos la dirección de la solución, después explicamos cómo la solución resuelve el problema, y luego abordamos lo que llamamos los impedimentos, los “ya-buts”, y finalmente describimos un camino seguro a seguir. Así que, leyendo 10 páginas al azar, no creo que en ningún libro se logre lo que buscas.

Pero tendría que resumir la discusión de hoy como: Todo se trata de flujo, y lo aproximadamente correcto es mejor que lo precisamente incorrecto.

Conor Doherty: Bueno, en este punto, no tengo más preguntas, pero abriré el micrófono. Joannes, ¿hay algo que desees plantearle directamente a Carol sin mi supervisión?

Joannes Vermorel: No, me gustaría agradecerle a Carol por realizar este ejercicio. Realmente lo aprecio. Ha sido un verdadero debate. Quiero decir, el punto no era reconciliar mis puntos de vista. No voy a convencerte, y probablemente tú no me vas a convencer, pero realmente aprecio que hayas tomado el tiempo y el esfuerzo para tener esta discusión. Para mí, significa mucho, y mi objetivo de aquí en adelante sería tener más de esos debates. Obviamente, existen otras teorías, así que ese es un objetivo que me he propuesto para este canal.

Me alegra mucho que, nuevamente, Carol dedicara unos sólidos, qué, 90 minutos de su tiempo. Es decir, realmente lo aprecio, y me gustaría agradecerte, Carol, por eso.

Carol Ptak: Bueno, de nada, y agradezco la invitación. Esperaba que pudiéramos hacer el debate cara a cara, pero luego llegó la pandemia, lo que lo pospuso. Así que me alegra que esta oportunidad volviera a surgir porque, si recuerdas, me comprometí contigo y te dije que en cualquier momento, en cualquier lugar, estaría feliz de hacer ese debate, ya que creo que es muy importante sacar toda la información completa al mercado y debatir esos puntos.

Creo que, como en un debate, alguien puede decidir exactamente por qué camino quiere ir, y está bien así. Como dije antes, si tuviera que resumirlo, el enfoque demand-driven se trata de flujo. Lo aproximadamente correcto es mejor que lo precisamente incorrecto.

Conor Doherty: Bueno, Carol, sé que escuché en algún lugar que Francia es el país número uno en la implementación de DDMRP. Así que la próxima vez que estés en Francia, si estás en París, de nuevo, sé que ambos estaríamos muy contentos de recibirte, aunque sea solo para cenar.

Carol Ptak: Ese es mi favorito. Mis chicos en Toulouse saben que cuando llego allí, tiene que haber foie gras y tiene que haber magret de pato. Yo consigo mi canard, consigo mi foie gras, y estoy muy contenta.

Conor Doherty: Bueno, en ese momento, voy a dar por concluido este evento. Honestamente, ha sido muy agradable escucharlos intercambiar opiniones, debo decir. Esto se estuvo gestando durante varios años, creo que es seguro decirlo. Así que, si no fue edificante, espero que al menos haya sido entretenido para todos. Así que, nuevamente, muchas gracias a ambos.

Carol Ptak: Conor, creo que hiciste un trabajo absolutamente fantástico, y lo aprecio. Como dije, Joannes y yo hemos hablado de esto durante varios años, así que me alegra que finalmente hayamos logrado que sucediera.

Conor Doherty: Con eso, daré por concluido este evento. Joannes, muchas gracias por tu tiempo. Carol, has sido de gran apoyo. Muchas gracias también por el tuyo, y gracias a todos por vernos. Nos vemos la próxima vez.