00:00:00 Capítulo de implementación y marco del profesional
00:04:35 La simplicidad supera la complejidad de la supply chain convencional
00:09:10 Las decisiones desatendidas evitan desvíos en el flujo de trabajo
00:13:45 La gestión de cambios elimina principalmente el trabajo innecesario
00:18:20 Las decisiones finalizadas acortan drásticamente la implementación de TI
00:22:55 Los datos empresariales desordenados son responsabilidad del proveedor
00:27:30 Survival demuestra que los datos ya son suficientes
00:32:05 Los Supply Chain Scientists toman decisiones rentables
00:36:40 Una mente evita recetas numéricas fragmentadas
00:41:15 La explicabilidad necesita propiedad y caja blanca
00:45:50 Las explicaciones comienzan cuando las decisiones realmente aparecen
00:50:25 Decisiones locas revelan restricciones y campos faltantes
00:55:00 Las decisiones rentables pueden romper viejos hábitos
00:59:35 Post-implementación significa mantenimiento contra deriva estructural
01:04:10 La mejora continua amplía el alcance de las decisiones con el tiempo
01:08:45 No hay valor sin decisiones finales
01:13:20 Diez semanas deberían mostrar un progreso real
01:17:55 La confianza lleva meses; prueba los problemas más difíciles primero
Resumen
Joannes Vermorel y Conor Doherty continúan su discusión capítulo por capítulo sobre Introducción a la supply chain. El capítulo diez pasa a la implementación: el trabajo práctico de llevar las decisiones automatizadas de la supply chain a producción, hacerlas confiables y garantizar que remodelen las operaciones diarias en lugar de quedarse en un prototipo.
Resumen ampliado
Esta discusión sobre la implementación atraviesa una gran cantidad de tonterías de moda en el software empresarial. El punto central no es complicado: el propósito de una iniciativa de supply chain no es producir paneles, flujos de trabajo, cuadros de mando u otros artefactos decorativos de gestión. Su propósito es producir mejores decisiones. Si el llamado despliegue no termina en decisiones desatendidas, auditables y económicamente sólidas, entonces mucho de lo que lo precede es, en el mejor de los casos, ceremonia.
Un error recurrente en la industria es la confusión de complejidad con sofisticación. Muchas empresas adoptan capas de flujos de trabajo de segmentación, anulaciones, alertas y aprobación porque parecen prudentes. En la práctica, suelen crear más código, más excepciones, más ambigüedad y más oportunidades de error. Lo que parece “más seguro” se vuelve más difícil de mantener, más lento de mejorar y más fácil de culpar a todos y a nadie. Por el contrario, un sistema diseñado desde el principio para generar decisiones definitivas es más difícil en principio pero más simple en la práctica.
Otro punto importante se refiere a los datos. A menudo se les dice a las empresas que sus datos son demasiado confusos para soportar la automatización. Esa excusa sobrevive porque es útil para los proveedores cuyos sistemas fallan. Pero cualquier empresa que todavía esté en el negocio a escala ya posee datos lo suficientemente buenos para operar su supply chain; de lo contrario, habría quebrado hace mucho tiempo. La cuestión no es si los datos están ordenados. Los sistemas empresariales reales nunca lo son. La cuestión es si las personas que construyen la solución son lo suficientemente competentes para lidiar con la realidad en lugar de exigir un conjunto de datos imaginario.
El papel del Supply Chain Scientist, tal como se describe aquí, no es, por lo tanto, limitado. No se trata simplemente de preparación de datos, ni de modelado ni de optimización de forma aislada. Es la propiedad de la receta numérica completa, desde los datos sin procesar hasta la decisión final. Dividir esa responsabilidad entre especialistas puede parecer eficiente, pero generalmente genera fallas en las costuras. Lo que se necesita es una mente que comprenda toda la cadena lo suficientemente bien como para darle coherencia y explicarla.
La explicabilidad en sí se trata aquí de una manera más práctica que teatral. No se explican las abstracciones por sí mismas. Explicas las decisiones. Y la explicación finalmente debe cobrar fuerza en economía: ¿por qué este pedido, por qué este precio, por qué ahora, por qué no más tarde? Si la respuesta no puede expresarse en términos de ganancias, pérdidas, riesgos y compensaciones, entonces la explicación probablemente sea ornamental.
La lección más amplia es que el despliegue debe juzgarse por la ambición y la velocidad. Apunte primero al problema real más difícil, no al problema fácil de un juguete. Exija resultados útiles en semanas, no promesas vagas en años. Si un proveedor no puede demostrar capacidad para tomar decisiones rápidamente, la demora no curará la incompetencia.
Transcripción completa
Conor Doherty: Bienvenido de nuevo. Este es el episodio 10 de una serie muy especial donde Joannes y yo tomamos su nuevo libro, Introducción a la supply chain, y discutimos las ideas capítulo por capítulo. Ahora, para esta serie específica, asumo una postura muy específica. Como sabes, pretendo no ser alguien que trabaja en Lokad. Nunca he oído hablar de la Supply Chain Quantitativa. Ciertamente no conozco a Joannes y no he trabajado con él desde hace casi cuatro años.
Pretendo ser uno de los aproximadamente 10 millones de practicantes en el mundo que podrían ver este libro, sentir curiosidad, comenzar a leer y luego tener preguntas. Ahora, hoy es el capítulo 10. Eso significa, por supuesto, que hubo nueve antes de este. Le recomiendo encarecidamente que los vea primero porque seguramente las cosas que discutimos hoy se basarán en material cubierto en episodios anteriores.
Y con eso, Joannes, comencemos. Capítulo 10, implementación. Ahora inmediatamente voy a violar la postura que les acabo de prometer a todos, y diré que, ya sabes, Conor, que trabaja aquí, los capítulos cuatro, que son economía, y el capítulo ocho, que son decisiones, probablemente sean mis favoritos personales. Ocho es probablemente sobre el que recibo más comentarios, disculpe, de personas que conocen Lokad.
Pero si realmente lo pienso desde la perspectiva de un profesional, como alguien que lee el libro y lee los primeros capítulos y piensa: “Realmente me gusta este enfoque. Me gusta mucho la idea de la clasificación financiera cuantitativa de las decisiones. Realmente estoy pensando en cuál es la vida media de una decisión. Lo que hago ahora, ¿abre o cierra decisiones más adelante?” Estoy totalmente de acuerdo con eso. Tendrán una pregunta muy simple: “¿Cómo diablos se ve eso?” ¿Qué pasa si mi jefe me dice: “Es una gran idea, pero cómo será? ¿Cuáles son los roles? ¿Qué se requiere de nosotros? ¿Cuáles son los datos? ¿Cuánto tiempo llevará? ¿Cuáles son los posibles puntos de falla?”
El Capítulo 10 es donde realmente entras en eso. Entonces, vamos a hablar sobre los entresijos de esto, pero a un alto nivel, para comenzar, en su opinión, ¿qué hace que una implementación realmente funcione y qué hace que una simplemente falle catastróficamente?
Joannes Vermorel: En lo que respecta a Lokad, las empresas en las que tenemos éxito son esencialmente las que nos permiten continuar con el esfuerzo. Y puede parecer una tontería, pero fundamentalmente no tiene nada que ver con la madurez. Entonces, se ve a algunos discutiendo con muchos directores de supply chains y diciendo: “Oh, necesitamos cierto grado de madurez”, y aquí no estoy de acuerdo, porque ¿de qué madurez estamos hablando?
Si por madurez te refieres a la adhesión a teorías de supply chains rotas, entonces avanzar más en este camino no te ayudará a tener éxito con Lokad, sino también a tener éxito en la supply chain. Verá, la postura que adopto en este libro es que este libro se presenta como una nueva introducción a la supply chain. Así que no analizo en profundidad todas las cosas que no funcionan, pero se puede leer esencialmente como las cosas que funcionan, a diferencia de la teoría dominante de la supply chain que es esencialmente una larga lista o colección de cosas que no funcionan en la práctica.
Y entonces están todas esas cosas, como pronósticos puntuales, microgestión del nivel de servicio, tener un enfoque en el que administrará su supply chain a través de alertas y excepciones, todo basado en reglas, anulaciones manuales para todo, etc., etc. Entonces, la conclusión es que, cuando Lokad tiene éxito, son esencialmente los lugares los que simplemente nos dan una sólida oportunidad de probar algo que normalmente es un orden de magnitud más simple que lo que implica la supply chain clásica.
Porque el problema es que, debido a que la teoría dominante de la supply chain está completamente rota, termina siendo una pesadilla de complicaciones en la práctica. Verá, tan pronto como tenga una teoría correcta, todo será más sencillo. El software es más simple, las matemáticas son más simples, la lógica es más simple y el tipo de entregable llega de manera mucho más limpia, lo cual es como decisiones, decisiones optimizadas y ajustadas al riesgo, llegan de manera mucho más limpia al final de la iniciativa.
Entonces, yo diría que tal vez si hubiera una conclusión, sería no seguir una teoría que finalmente fracasará, sin importar quién esté a cargo de implementarla. En Lokad, intentamos orientar a nuestros clientes potenciales y clientes para que realmente se centren en lo que funcionará. Pero al final, si nos dan órdenes directas, resulta muy difícil tener éxito en contra de la voluntad del cliente.
Conor Doherty: Ya sabes, para continuar con eso, solo para aclarar, disculpe, cuando dice “un orden de magnitud”, solo está dando números, pero digamos un orden de magnitud más simple, ¿quiere decir que en términos de implementación es un orden de magnitud más simple? ¿O quiere decir que en términos de entregable es mucho más sencillo de manejar?
Más simple en términos de cronograma, ¿cuántos días se necesitan para poner un sistema en funcionamiento? ¿Cuántas horas hombre necesitas invertir? ¿Cuánta interrupción se requiere? Quiero decir, por ejemplo, un ejemplo por favor.
Joannes Vermorel: Si comienzas con, digamos, algo como el análisis ABC, que te encanta, o cualquier tipo de segmentación inventada, entonces verás que no lo necesitabas. Es como una solución pseudo-obvia a un problema inexistente. Entonces la gente piensa: “Oh, sí, debemos abordar esto variando la calidad del servicio o algo así, a través de una segmentación”. La respuesta corta es no, no necesitas esta segmentación.
Y si nos vemos obligados a realizar una segmentación, terminamos teniendo tantas líneas de código que serán: si categoría A, entonces esto y esto y esto; si es categoría B, entonces esto y esto y esto. Si tenemos un producto que pasó de B a A recientemente, necesitamos tener esto y esto y esto. Si recientemente pasó de A a B, entonces necesitamos algo. Como puede ver, es solo una idea que parece que la teoría dominante aceptaría absolutamente y le gustaría una segmentación.
Y esto, en cuanto a código, caerá en cascada en un laberinto de casos extremos, lo que significa más líneas de código, más errores, más, diría yo, decisiones locas que surgirán del proceso de datos al final del día. Por eso se necesita más tiempo para que la gente revise los números. Necesita más informes para incluso entender los números, etc., etc. Verá, esas cosas se superponen en cascada.
Y el tipo de cosas que hace Lokad puede parecer complicado, como pronóstico probabilístico, pero no lo es, porque es una forma de eliminar literalmente clases enteras de problemas y expresar, en solo unas pocas líneas de código, cosas que de otro modo requerirían miles de líneas de código. Esa es la esencia. Yo diría que debemos perseguir lo que es realmente simple, no lo que parece simple, que en realidad es simplista y, por lo tanto, genera toneladas de reglas y casos extremos y, yo diría, complicaciones posteriores.
Conor Doherty: Entonces, para continuar con eso, quiero ser muy consciente de no fusionar demasiadas ideas, así que para enmarcarlo un poco más concretamente, una de las cosas que usted argumenta en el capítulo 10, nuevamente estoy parafraseando, pero esto es muy fiel, usted argumenta que en el contexto de una implementación, concretamente en términos del entregable, no está buscando una mejor visibilidad. No estás buscando mejores paneles. No estás persiguiendo mejores pronósticos.
El objetivo de una implementación, ciertamente desde una perspectiva de optimización de la supply chain, es producir decisiones desatendidas y auditables, que son, por ejemplo, órdenes de compra, transferencias, cronogramas o cambios de precios que luego se vuelven a escribir en sus sistemas operativos. Sí. Eso es más sencillo. Ese es el punto que estás planteando.
Joannes Vermorel: Nuevamente, y lo importante está desatendido. Entonces, por ejemplo, si decides eso, si dices: “Oh, el listón está muy alto, sin supervisión. Realmente quieres poder hacerlo bien así, sin paso intermedio, directo a lo bueno”. Y digo que sí, porque ¿cuál es la alternativa?
La alternativa es diseñar un flujo de trabajo muy complicado donde las personas puedan intervenir, hacer todo tipo de anulaciones y, al final, generamos las asignaciones de recursos, las decisiones reales. ¿Cuánto compro? ¿Cuánto produzco? ¿Dónde pongo las acciones? ¿Subo o bajo el precio? Entonces, si decide que vamos directamente a tomar decisiones desatendidas, obviamente lo que quiere es decir: “Está bien, no aceptaría decisiones desatendidas que no sean excelentes”. Por lo general, deben ser mucho mejores que lo que la gente podría producir manualmente.
Yo digo, bien, no hay problema. Éste es un criterio absolutamente justo. Y lo que digo es que esto es a lo que debemos apuntar desde el primer día. Y verá, si lo intenta, dice: “Está bien, queremos hacerlo de la manera asistida, con un flujo de trabajo de varios pasos”, etc., entonces su proceso, que se suponía que era la optimización de la supply chain, pasa al diseño de un flujo de trabajo y luego, como puede ver, simplemente no es el mismo objeto.
Y fundamentalmente, en lugar de dedicar tiempo a “¿Estoy diseñando un sistema que realmente maximice la tasa de rendimiento de cada recurso asignado a través de mi supply chain?” cuál es el juego que estamos jugando, se disuelve en algo en el que hay que sondear las opiniones de cada persona y luego hay que optimizar la productividad porque el flujo de trabajo es “dejar que la gente intervenga”, por lo que consume tiempo.
Así que hay todo tipo de compensaciones en juego. Si brinda más flexibilidad, la gente puede decir: “Oh, entonces tengo más palancas”, pero luego crea complicaciones porque entonces sus empleados podrían dedicar demasiado tiempo al flujo de trabajo. Y luego, si las decisiones finales terminan siendo falsas, ¿de quién es la culpa? Desdibuja completamente la responsabilidad.
Especialmente si el flujo de trabajo involucra a media docena de personas haciendo pequeños cambios, de manera incremental, entonces resulta extremadamente difícil señalar quién tiene la culpa. Por lo tanto, es necesario realizar un análisis de causalidad en todos esos departamentos. Y verá, así es como comenzamos con algo que era: “Vayamos directamente a las decisiones que sean más rentables”, a algo en lo que nos hemos desviado por completo, donde comenzamos a diseñar un flujo de trabajo e interfaces de usuario y monitorear lo que hace la gente y optimizar la productividad, etc.
Verás, así es como puedes terminar con algo que es un orden de magnitud más lento, más complicado, simplemente porque en realidad hiciste algunas cosas que parecían más simples inicialmente. No, no, no lo es. Entonces, nuevamente, para nosotros, ese es un verdadero criterio para el éxito: poder seguir adelante con la maximización de la rentabilidad, sin desviarnos hacia los flujos de trabajo, sin desviarnos hacia artefactos numéricos inventados como segmentaciones y demás.
En última instancia, no te importa ABC. Lo que le importa es: ¿estoy realmente maximizando el retorno de la inversión? No importa si corte y troceo mis SKU a través de clases, de esto, de aquello o de lo que sea. Quiero decir, si lo que quiere es maximizar, nuevamente, la tasa de retorno con una perspectiva de largo plazo, lo que significa que no está adoptando una perspectiva de corto plazo, diría yo, destructiva, quiere valorar la calidad del servicio en lo que importa y al mismo tiempo proteger sus intereses a largo plazo, y todo eso estará en la tasa de retorno. Si no, es que tienes un criterio simplista que hay que ajustar.
Conor Doherty: Sí. Y algo que dijiste allí en particular, nuevamente, la idea de hablar con profesionales, ya sea solo en una conferencia, haciendo podcasts como este, ya sea una llamada de negocios, lo que sea, una de las cosas que surge es la gestión del cambio. Y algo que dijiste allí, te pregunté qué separa a una persona exitosa de un fracaso, y dijiste, ya sabes, empresas que te permiten hacer lo tuyo.
Y yo agregaría a eso, aceptar que en la gestión de cambios, eso significa que en el título habrá al menos algún cambio. Y el cambio será que te alejarás de lo que acabas de describir, la segmentación, la anulación manual, la supervisión. Tienes que aceptar que vas en dirección a la automatización y a las decisiones desatendidas.
Joannes Vermorel: Y nuevamente, creo que también parte del problema es que el cambio que trae Lokad es extremadamente limitado y principalmente sustractivo. Verá, eso es lo que hace que la gente esté muy, a veces muy, muy confundida. Lokad no requiere rediseñar las empresas de nuestros clientes. El cambio que traemos es casi todo sustractivo, quitando cosas y ya.
Por lo tanto, no es necesario rediseñar las descripciones de trabajo de muchas personas, ni volver a capacitarlas. Esencialmente, porque nuevamente estamos apuntando a procesos de toma de decisiones desatendidos, sí, son conceptualmente más simples en todos los niveles. Es más sencillo para TI. Es más sencillo para los profesionales de la supply chain. Es más sencillo para la alta dirección. De hecho, es más sencillo para todos.
Así que no se trata tanto de “Oh, tenemos tantos cambios que necesitaremos aprender mucho”, como opuesto a desaprender todas las cosas que simplemente ya no son relevantes. Verá, piense en ello como en esas viejas máquinas de escribir, las mecánicas. Había que engrasarlos. Necesitabas poder cambiar la cinta entintada. A veces era necesario tomar…
Tuve uno cuando era joven. Quiero decir, si querías utilizar una máquina de escribir mecánica de forma profesional, esto requería mucho mantenimiento. Es literalmente un poco de mecanismo de relojería. Y si usas una computadora, de repente desaparece. Tu teclado funciona, y si tu teclado está muerto, simplemente compras un teclado nuevo y listo.
La cantidad de conocimientos que necesitas para utilizar un teclado moderno, en comparación con una máquina de escribir de la vieja escuela, es mucho menor. Como puede ver, la gestión del cambio es muy sustractiva. Son toneladas de cosas que simplemente desaparecieron. Y esa es quizás la parte que podría resultar más confusa para los clientes potenciales cuando hablamos con ellos. De hecho, esperan muchos cambios en el sentido de: “Oh, necesitaremos volver a capacitar a la gente, necesitamos agregar esto y aquello”, y hay muy poco de eso. Es muy, muy poco.
Para TI, Lokad es, diría yo, solo una pequeña fracción del esfuerzo que requiere un sistema clásico. Entonces, para TI, es mucho menos. Ciertamente, para un piloto, la fricción suele ser muy baja. Básicamente se trata de enviar archivos sin formato, archivos planos en filas extraídos del sistema, sin preprocesamiento alguno, copiar y pegar, simplemente volcar y transferir.
Conor Doherty: Lo cual es un punto clave. Lo sentimos, en realidad ese es un punto clave que acabamos de pasar por alto, que es lo bajo que se compara con “Necesitamos un proceso de implementación de dos años solo para prepararlo”. No vuelvas a pasar ese punto a toda velocidad.
Joannes Vermorel: Sí. La razón es, nuevamente, por diseño, la forma en que opera Lokad es que queremos que este motor de toma de decisiones funcione sin un flujo de trabajo. Entonces, quiero decir, el flujo de trabajo es súper minimalista: entran datos, salen decisiones y listo.
Y hay tantas cosas que simplemente no son necesarias. No necesitamos resincronizar con el ERP, toneladas de cosas complicadas, ya ve, porque al final lo que producimos son decisiones finalizadas que son muy sencillas de luego reimportar al ERP. Si desea generar, digamos, una orden de compra, lo único que se ve afectado es el producto, la cantidad y el proveedor, y eso es todo. La estructura de datos, orden de compra finalizada, es muy, muy sencilla.
A diferencia de si queremos, digamos, administrar muchas segmentaciones, resincronizarlas con el ERP, darles a las personas la posibilidad de hacer todo tipo de cosas en Lokad y luego resincronizarlas con el ERP, ese es el tipo de cosas que la mayoría de mis pares estarían ofreciendo. Y es por eso que la implementación lleva una eternidad, porque nuevamente hay tantas capas de artefactos numéricos, cosas que, yo diría, cosas que no son reales, que son simplemente como instrumentos para llegar al producto final, que es una decisión.
Y a veces incluso el software de supply chain clásico ni siquiera llega a la decisión final, la que realmente tiene en cuenta todas las restricciones, como la cantidad mínima de pedido verificada, la capacidad máxima del contenedor verificada, la carga completa del camión verificada, etc. Así que muy frecuentemente terminas con mucha complejidad que surge del hecho de que, en lugar de apuntar a una decisión completamente finalizada, lo que obtienes del típico software de planificación avanzada, el APS clásico, es algo que, nuevamente, no es final. resultado y, por lo tanto, se necesita mucha plomería después para finalizar las decisiones.
Conor Doherty: Creo que este es un terreno muy fértil para seguir caminando, porque cuando hablamos de la participación de TI, y esto es algo que ambos sabemos por haberlo discutido con muchos, muchos profesionales en este momento, una de las cosas que les preocupará es: “Bueno, mis datos maestros no son lo suficientemente buenos. La salud de mis datos es terrible. Joannes, deberías ver mis datos. Es un desastre. Es indecente. Inviable. Ni siquiera puedes usarlos. eso.”
Tú, en el capítulo 10, tienes muy claro que eso es una tontería total.
Joannes Vermorel: Ah, sí. Oh sí. Lo interesante es que, nuevamente, el mercado de proveedores de software empresarial de supply chain, quiero decir, este mercado es absolutamente terrible, y la mayoría de los proveedores tienen tasas de falla que están muy por encima del 90%. No, literalmente suena una locura. Son grandes. En el papel, supuestamente están teniendo cientos de implementaciones exitosas. En la práctica, todos ellos son distintos grados de fracaso.
Y cada vez que falla, y casi siempre falla, culparán a los datos porque son un chivo expiatorio perfecto. Un chivo expiatorio perfecto, ¿sabes? Es como culpar al dios del tiempo o algo así. Simplemente se culpa a una fuerza externa, como si los datos fueran cosa del universo y tuviéramos que vivir con ellos. No, no, no.
Así que mi opinión es: los datos son casi invariablemente excelentes para cualquier empresa que supere, digamos, 50 millones de dólares. Casi invariablemente excelente. ¿Por qué? Porque las empresas que no tenían datos excelentes quebraron hace mucho tiempo. Es sólo darwinismo corporativo. Si no sabes lo que estás comprando, entonces no sabes cómo pagarles a tus proveedores, y a algunos les pagarás dos veces o nada, y luego dejarán de ser proveedores, o algo así.
Entonces, ¿no puedes saber lo que estás comprando? No. ¿No puedes saber lo que estás vendiendo? No. Porque si no sabes lo que estás vendiendo, tampoco perseguirás a clientes que olvidaron pagar y ese tipo de cosas. Así que las únicas empresas que sobrevivieron son las que saben esencialmente qué compran, qué producen y qué venden, básicamente.
Conor Doherty: Sí. Sí. Regla básica.
Joannes Vermorel: Sí. Y nuevamente, el darwinismo en acción. Las empresas que no pueden hacer eso quebraron hace mucho tiempo, probablemente hace dos décadas. Entonces, las empresas que sobrevivieron son aquellas en las que esos datos básicos son correctos. Correcto en el sentido de que reflejan la realidad y son utilizables.
Conor Doherty: ¿Entonces rechazas el argumento del desorden?
Joannes Vermorel: No. Ah, sí, exactamente. Quiero decir, luego está lo que sucede cuando los proveedores incompetentes, sí, se enfrentan a estos datos, y lo que esperan son datos que estén perfectamente organizados de una manera, digamos, organizada una competencia de Kaggle. Tienes datos súper ordenados con las tablas correctas, con los campos correctos y todo está muy bien documentado. Pero nuevamente, una competencia de Kaggle.
Sí, bueno, si esperas eso como proveedor, te decepcionarás. Sí. La realidad es que sí, el panorama aplicativo es confuso. Lo que enfrentará es un panorama con media docena de sistemas empresariales complejos, cada sistema empresarial con entre 1.000 y 10.000 tablas, y cada tabla con entre 10 y 500 campos. Y cada dato, como las ventas, está al menos triplicado. Entonces se presenta de tres maneras diferentes en diferentes tablas por diferentes razones, y así es como es.
Así que ahora, en lo que respecta a Lokad, es nuestro trabajo, y yo diría que considero que es responsabilidad de Lokad, simplemente solucionarlo. Ésta es sólo una expectativa básica. Y entonces, para nosotros, no esperamos nada más que un panorama aplicativo extremadamente desordenado con décadas de cosas que se han sedimentado. Entonces tienes como cuatro ERP diferentes, uno que era… porque los ERP realmente nunca mueren, simplemente pasan a un segundo plano, y todavía tienes lo que se está ejecutando en algún mainframe, en un AS/400 o algo así, que todavía está ejecutándose, y nunca se cerró realmente.
Y sí, tienes que lidiar con eso así como con el resto, y eso es perfectamente normal. Como puede ver, cuando la gente culpa a los datos, para mí son realmente los proveedores los que culpan. Para mí, es casi invariablemente una demostración de incompetencia por parte de los proveedores. Si un proveedor le dice: “Oh, sí, fallamos porque los datos son malos”, quiero decir, simplemente huya. Este proveedor es completamente incompetente. Ni siquiera saben que son incompetentes y culpan a los dioses del tiempo o algo así. Simplemente… culpar a los datos parece mucho más propio del siglo XXI que decir: “Sí, los dioses no estuvieron con nosotros en esto, por lo que perdimos esta batalla”, pero en realidad es lo mismo.
Conor Doherty: Este es un punto clave, y realmente quiero profundizar en él, porque necesito separar dos puntos que usted ha planteado, pero sólo quiero repetirlos porque son importantes. Uno, la afirmación “Mis datos están desordenados”, que está aquí. Y la otra es: “Mis datos son demasiado confusos para hacer algo laborioso con ellos”. Esas son dos afirmaciones distintas que estás haciendo.
Y de hecho, directamente sobre tu hombro, no sé si es visible en la cámara, está tu primer libro, el manifiesto, el rojo. Y en eso que das el ejemplo, realmente creo que es en los años 90, tal vez en la página 98 o algo así, das el ejemplo de, ¿qué significa fecha de venta? Y enumera entre seis y diez ejemplos diferentes. Por ejemplo, si abre sus datos transaccionales, podría significar el día en que ingresó a la cesta, el día en que se vendió, el día en que finalizó el período de devolución, el día en que finalizó la garantía, lo que sea. Hay muchas interpretaciones diferentes de lo que eso significa. Eso lo hace complicado.
Pero como acabas de decir, es responsabilidad del proveedor quitarte ese desorden de encima y hacer algo laborioso y productivo con él.
Joannes Vermorel: Sí. Sí. Y la clave, y eso es apropiado para la implementación del capítulo, es que desea terminar con el resultado de una iniciativa, de algo que brinde decisiones muy fundamentadas, ajustadas al riesgo y muy rentables basadas en cualquier información que tenga. Porque la realidad es que la gente dentro de su empresa no tiene acceso a más datos.
El gerente de producción o el gerente de inventario o el gerente de compras, no entran físicamente al almacén para adquirir más información antes de ingresar las órdenes de compra o la orden de producción o lo que sea. Hacen todo desde su escritorio y no tienen ningún tipo de acceso privilegiado a ningún tipo de información privilegiada, en su mayor parte, excepto lo que realmente está en los sistemas empresariales.
Entonces, lo que estoy afirmando es que Lokad… porque su gente, sus empleados, ya pueden operar su supply chain; de lo contrario, nuevamente, el darwinismo en acción, estaría en bancarrota. Entonces, si no está en quiebra, algunas personas logran hacer funcionar su negocio, lo que demuestra que los datos de alguna manera son suficientes. El mero hecho de que su empresa aún no esté en quiebra demuestra por sí solo que los datos son suficientemente buenos.
Ahora la pregunta es: ¿es el proveedor lo suficientemente competente para utilizar los datos tal como están, en lugar de hacer ilusiones? Si el proveedor viene y dice: “Sí, tendremos éxito si sus datos cumplen con mis estándares”, el estándar del proveedor, usted, como empresa que dirige una supply chain, no tiene control sobre el estándar del proveedor. Evidentemente, esto es una tontería.
Imagínate que quieres hacer una reparación de plomería en tu casa y el tipo que aparece dice: “Oh, no, ya sabes, no me gusta mucho el estilo en la forma en que se dispuso tu plomería. Se siente un poco complicado. Los tubos no están completamente rectos. No, creo que esperaré a que tu plomería esté realmente a la altura de mis estándares antes de comenzar a echar un vistazo”. Y la gente decía: “No, usted es el plomero. Simplemente ocúpese de la forma en que se hizo la plomería. Y sí, si hay algunas tuberías que no están completamente rectas, quiero decir, ocúpese de ello. Eso es lo que esperamos de usted”.
Verás, este tipo de culpar a los datos es una locura. Y para mí, lo que habla mucho de la locura de este mercado es que algunos proveedores rutinariamente logran salirse con la suya culpando al cliente por el fracaso con la excusa de que fueron solo los datos. Y lo más loco es que muchas veces consiguen convencer a los propios clientes de que la culpa fue suya.
Conor Doherty: Sabes, para mí es como, guau. No sólo el vendedor fracasó, sino que lograron convencerme… me hicieron creer que era yo.
Joannes Vermorel: Está bien. Lograron convencer a su cliente de que era culpa suya. Yo diría que sí, es un talento. En cierto modo, es un arte, pero no es exactamente lo que se esperaría de personas que afirmarían ser Supply Chain Scientists en lugar de especialistas en manipulación.
Conor Doherty: Bueno, esto en realidad establece el siguiente punto, que es, nuevamente, cuando decimos que Lokad tomará los datos, o quien usted seleccione, pero en nuestro caso obviamente somos Lokad, tomaremos sus datos y trabajaremos con ellos, lo que en realidad queremos decir es el Supply Chain Scientist. Y eso en realidad nos lleva a un punto central, que es el papel del Supply Chain Scientist en la implementación y en la mejora continua.
Pero ciertamente en la etapa de implementación, ¿el papel del Supply Chain Scientist se limita solo a analizar y ordenar los datos, como acaba de decir, o es más integral?
Joannes Vermorel: No, porque lo que pasa es que no puedes saber si la forma en que procesas los datos es correcta o no sin el lente de las decisiones finales. Al final, el único criterio para saber si lo que estás haciendo con los datos es correcto o no es: ¿tus decisiones son rentables o no? Esa es la…
Conor Doherty: En cierto sentido, si malinterpretas los datos, pero las decisiones salen bien…
Joannes Vermorel: Entonces tu malentendido es intrascendente.
Conor Doherty: Sí.
Joannes Vermorel: Y entonces la gente tal vez se sorprenda, digamos, ¿cómo puedes cometer un error y no importa? Una vez más, es un juego de escala. Tienes miles de mesas. Tienes, en total, decenas de miles de campos. Sí, habrá malentendidos. Habrá fallos. Habrá muchas cosas. Pero lo que importa es que, al final del día, la gente también comete errores. Puedes tener personas que lean un campo; deberían estar leyendo otro campo.
Es realmente: ¿generas decisiones que tienen cero por ciento de locura? Así que no hay una sola decisión que sea inmediatamente falsa.
Conor Doherty: Mhm.
Joannes Vermorel: Y además todos son al menos decentemente buenos, ¿sabes? Y luego, cuando se mide el desempeño económico en promedio, ¿realmente superan el status quo anterior? Ese es el criterio.
Entonces, el hecho de que puedas tener un trabajo interminable, yo diría, para seguir mejorando la receta numérica para que sea muy, muy excelente con el tiempo es bueno, y eso es una continuación del esfuerzo del Supply Chain Scientist. Pero, en última instancia, la contribución del Supply Chain Scientist debe leerse de la siguiente manera: ¿logramos que esas decisiones altamente rentables se generen diariamente, sin supervisión? Y eso es un despliegue. Esa es una iniciativa que llega a este punto en el que cada día tomas decisiones.
Esa es la contribución del Supply Chain Scientist. Y mecánicamente, o lo siento, no mecánicamente, mecanicistamente hablando, el Supply Chain Scientist es esencialmente el experto.
Conor Doherty: Creo que es la analogía que diste antes. Es como el equipo de boxes, todo en uno. Es el ingeniero, el científico de datos, el experto en la supply chain quien administrará su cuenta específica. Por ejemplo, estás interactuando con esa persona, la persona que administra tu cuenta.
Joannes Vermorel: Sí. Y va un poquito más allá. Lo que digo es que ni siquiera depende de Lokad. Si fragmentas la responsabilidad de la receta numérica… Entonces alguien tiene que diseñar el software que toma los datos sin procesar y genera decisiones. Esto es lo que, cuando uso el término receta numérica, es una pieza de software que parte de los datos tal como se pueden encontrar en los sistemas comerciales, lo que existe en bruto y genera al final del día las decisiones finales reales.
Y cuando digo finalizado, significa que nadie tiene que abrir una hoja de cálculo para ajustar los números hacia arriba o hacia abajo solo porque hay un MOQ que no se administró o algo así. Así que es realmente definitivo. Bien. La orden de compra está exactamente lista para ser enviada, por ejemplo, al proveedor. Bueno.
Entonces, lo que estoy diciendo es, y así es como se debe entender al Supply Chain Scientist, debe haber una mente que cubra todo eso. Una mente humana. Y esta mente humana es lo que es muy importante, porque en última instancia quieres tener algo que sea completamente consistente de principio a fin.
Y verás, si fragmentas la responsabilidad, eso es lo que Lokad aprendió hace 15 años. Si fragmenta esta tarea entre, “Oh, habrá una persona a cargo de, digamos, preparar los datos, y luego otra estará a cargo de hacer, digamos, el modelado probabilístico, y luego otra estará a cargo de hacer la optimización para el proceso de toma de decisiones final”, este tipo de cosas, terminará con toneladas de errores en los límites dentro de su sistema.
Verás, al tener varias personas, naturalmente establecerán límites dentro de esta receta numérica, y casi todos los errores se concentrarán en esos límites. Entonces necesitas tener una manera de eliminar todos esos límites para que no esté fragmentado.
Y otra forma de entender esto es pensar en ello como un proceso en el que dividirías el juego de ajedrez en varias etapas. Como, por ejemplo, la primera persona decide una lista corta de piezas que son elegibles para movimiento, y luego otra persona decide otra cosa. Si organizas el proceso, ¿obtendrás una mejor jugada de ajedrez al final del día? No. Quiero decir, es casi seguro que si intentas fragmentar la forma en que juegas al ajedrez, terminarás con movimientos de ajedrez que son malos, mientras que, si juegas contra alguien que es realmente bueno, esa persona tendrá una enorme ventaja sobre ti simplemente porque es una mente que puede echar un vistazo a todo el tablero en lugar de intentar fragmentar el análisis.
Conor Doherty: Por supuesto. Sólo para subrayar un punto, o aclarar y, con suerte, subrayar el punto, cuando dices que es una mente humana, estás hablando del lado de Lokad. Es una mente humana porque obviamente todavía tienes que interactuar con el cliente.
Joannes Vermorel: Esta relación no se trata de Lokad. Ya sabes, esta Introducción a la supply chain no trata sobre Lokad. Se trata de lo que funciona y lo que no funciona en la supply chain. Lokad apenas se menciona en las notas a pie de página un par de veces en el otro libro.
Lo que estoy diciendo, y esa es la lección importante, es que si desea que cualquier iniciativa de supply chain realmente funcione, no importa si Lokad está involucrado. Lo que digo es que debe haber un software que genere tus decisiones. Pasamos por eso. Si no tienes un software, entonces tus esfuerzos, tus inversiones, no son acumulativos. No puedes mejorarlo porque se vuelve muy borroso. Si alguien se va, nuevamente, es extremadamente difícil mejorar sistemáticamente algo que se hace de forma completamente manual.
Por eso digo, está bien, debemos abordar eso como un artefacto de software, esta receta numérica. Bueno. Ahora lo que digo es que habrá alguien involucrado en el diseño y mantenimiento de este artefacto numérico. Si Lokad está involucrado, podría ser alguien de Lokad. Si Lokad no está involucrado, será otra persona. No importa dónde.
Y mientras no tengamos niveles Skynet de IA que sean tan autónomos y capaces como los humanos, será una mente humana. Porque incluso si esos agentes agentes son increíbles, todavía no son capaces de realizar una tarea tan compleja por sí solos. Entonces por ahora eso significa que habrá una persona.
Y lo que digo es que, y ese es un criterio, no importa la escala de su empresa, debe ser una sola persona. No significa que no puedas tener tres personas, pero verás, es muy diferente. Piénselo: quiere jugar al ajedrez con tres personas y, potencialmente, tener como tres expertos. Todos los expertos tienen capacidades equivalentes, todos pueden jugar por sí solos y pueden ver el problema completo. No está fragmentado. No es una puesta en escena.
Entonces, en cierto sentido, si tienes como tres expertos para decidir el movimiento, son completamente redundantes. Y eso está bien. Como verás, lo que estoy diciendo es que debería haber una sola mente. En la práctica, para una gran empresa, lo que desea es un despido porque no quiere que, si esta persona está enferma, no tenga ningún recurso alternativo. Lo entiendo. Lo que estoy diciendo es que si tienes varias personas, esencialmente introducirán redundancias. No se trata de una división del trabajo en la que se corta el problema en pedazos y la gente ignora ciertos aspectos del proceso.
Fundamentalmente, para que funcione, la receta numérica debe ser producida por alguien que comprenda completamente el proceso de principio a fin. Eso es lo que estoy diciendo. Y si no lo tiene, se encontrará con problemas extremadamente predecibles que casi sistemáticamente provocan la ruina de este tipo de iniciativa.
Conor Doherty: Bueno, en términos de problemas predecibles que deshacen la iniciativa que estás tratando de llevar a cabo, uno de los más importantes es la explicabilidad. Y nuevamente, ambos hemos escuchado personalmente muchas, muchas, muchas veces: “Eso suena genial. ¿Cómo le explico eso a mi equipo, que tiene que interactuar con este sistema de inteligencia que ahora está diseñando decisiones automatizadas desatendidas? ¿Cómo puedo generar confianza? ¿Cómo puedo crear explicabilidad para eso? ¿Cómo se ve eso?”
Joannes Vermorel: Entonces, primero, volvamos a esta única persona, una sola mente. Verás, ¿quién está a cargo de la explicabilidad? La respuesta es la persona que elaboró la receta numérica. No es una IA. No es un sistema. Es una persona. Entonces hay una persona que puede explicar lo que hizo. Entonces, si esta persona no está disponible para dar una explicación, entonces nuevamente tienes un problema.
Entonces lo que estoy diciendo es que volvemos a tener una implementación exitosa. Es necesario tener a alguien que se haga cargo de la receta numérica. Ese es el primer paso. Entonces, la explicabilidad comienza con tener a alguien que explique. Verás, ese es el papel.
Y entonces, ¿esta persona es capaz de dar explicaciones? Bueno, si esta persona tiene una comprensión integral de principio a fin, incluso si en la práctica puede ser un equipo, por lo que algunas partes del trabajo podrían haber sido realizadas por otras personas, si esta persona posee toda la receta numérica, entonces sí, esta persona puede dar la explicación.
Ahora lo que quieres es que esta persona también cree la instrumentación. Eso es parte de lo que llamamos el boxeo blanco. Entonces, la persona que elabora la receta numérica también elaborará toda la instrumentación de caja blanca. Básicamente se trata de todo tipo de paneles de control…
Conor Doherty: Sí, sí, sí.
Joannes Vermorel: …que instrumenta la receta numérica. La intención detrás de esta instrumentación es, en primer lugar, permitir que la persona que elabora la receta numérica se convenza de que la receta está funcionando. Verá, quiero decir, escribo una receta numérica que genera, digamos, órdenes de compra. ¿Cómo me convenzo de que lo que acabo de hacer es correcto? Verás, solo puse fórmulas.
Conor Doherty: Esa es literalmente la pregunta que te hago.
Joannes Vermorel: Sí. Y la primera respuesta es: necesito elaborar una serie de indicadores, sí, en euros o dólares, que descompongan lo que voy a hacer y me digan simplemente si lo que estoy obteniendo… Y habrá, nuevamente, mucha heurística en lo que quiero mirar.
Así que estaré mirando… probablemente otra vez, el boxeo blanco es un poco un arte. No querrás mirar sólo los promedios. Tal vez desee acercarse a productos que son muy erráticos, algunos que son muy estables, algunos que están creciendo, algunos que tuvieron períodos extensos de faltante de stock, etc. Quiero decir, todo eso es el tipo de instrumentación que está superponiendo a la receta numérica para convencerse a sí mismo, como Supply Chain Scientist, de que en realidad está funcionando según lo previsto.
Y luego esta instrumentación suele ser un poco abrumadora porque son literalmente miles de números. Y normalmente, como Supply Chain Scientist, usted querrá producir un resumen que sea mucho más conciso, que se presentará a sus colegas, o nuevamente a los clientes, o a otras personas, para transmitir lo convincente, pero de una manera mucho más concisa. Y eso vuelve a ser responsabilidad de la misma persona, de nuevo, el encargado de elaborar la receta numérica.
Conor Doherty: Bueno, en esa respuesta, cubriste quién, qué y cómo. Entonces, quién explica, qué explica, cómo explica. Lo que no se cubrió es cuándo comienza esa explicación. Y si entendí correctamente en el capítulo 10, eso es durante la fase de ejecución dual. Ahí es donde empiezan a ver por primera vez cómo se ve el nuevo sistema de inteligencia en comparación con su sistema actual. Entonces, expanda.
Joannes Vermorel: Entonces la cuestión es que en la receta numérica, tienes potencialmente cientos de pasos intermedios de cálculo, pero todos los artefactos numéricos, esas cosas, son solo medios para un fin. Lo único que importa es el final, porque para eso estás ahí. Es, nuevamente, como cuando, si estás jugando al ajedrez, lo único que importa es el movimiento que haces. Todos los tipos de pasos intermedios que tenías en mente para tomar esta decisión son, como, sí, está bien. En última instancia, son intrascendentes para los observadores. Lo único que realmente importa es lo que estás jugando. Eso determinará el resultado del juego.
Sí. Entonces, lo que estoy diciendo es, y decimos un poco lo mismo para la receta numérica, decimos que la explicabilidad comienza una vez que se tienen decisiones que explicar. Porque antes de eso, todo es discutible. Puede explicar por qué hizo todo ese tipo de preprocesamiento, por qué aplica esta heurística aquí y allá, por qué elige este modelo probabilístico para el tiempo de entrega en lugar de otro. Todo eso son sólo infinitos tecnicismos.
Fundamentalmente, lo único que realmente merece una explicación es el final, las decisiones que estás sugiriendo. Y es por eso que la explicación, el boxeo blanco, normalmente solo comenzará al final del segundo mes, al comienzo del tercer mes. Una vez, en una iniciativa de supply chain, el Supply Chain Scientist comienza a tomar decisiones diarias.
Hasta entonces, es solo un trabajo que es principalmente interno a lo que el Supply Chain Scientist está haciendo para tomar esas decisiones. Quiero decir, el cronograma es básicamente de dos meses para poner en funcionamiento un canal de datos y que el Supply Chain Scientist se ocupe de este lío de datos, le dé sentido y luego, muy rápidamente, escriba la primera receta numérica.
Los próximos dos meses se tratarán de iteraciones rápidas para deshacerse de todas las decisiones descabelladas y realmente sintonizar, con comentarios de los profesionales, todos los impulsores económicos. Porque muchas cosas requieren ajustes, y eso se debe a que lo que uno quiere es asegurarse de que sus impulsores económicos reflejen la intención estratégica de la supply chain, de la empresa.
Entonces, por ejemplo, ¿qué significa realmente calidad de servicio? Una vez más, un Supply Chain Scientist puede haber hecho algunas conjeturas y suposiciones aquí, pero en última instancia requerirá una discusión con profesionales reales para asegurarse de que el marco económico realmente capte los intereses a largo plazo de la empresa. Y esas son decisiones muy mundanas sobre lo que realmente significa calidad de servicio, cómo son exactamente las estructuras, la presión sobre el capital de trabajo, etc., etc.
Muchas cosas, iteraciones rápidas durante dos meses y luego, al final del cuarto mes, estás listo para dejar que la receta numérica se ejecute sin supervisión durante dos meses haciendo una ejecución dual.
Conor Doherty: Sí.
Joannes Vermorel: Para que la gente realmente pueda… para que la receta numérica pueda ganarse la confianza necesaria para que la gente pueda decidir que realmente confiarán en la producción de este software para dirigir el flujo.
Conor Doherty: Bueno, mencionaste locura, y anteriormente mencionaste que lo que estás buscando son decisiones sin locura. Ahora, durante esa fase de ejecución dual, y durante, digamos, los primeros seis meses de un despliegue, de una implementación, presumiblemente habrá momentos, ya sea con Lokad, con quien sea, cuando estés implementando un sistema de inteligencia, presumiblemente habrá momentos en los que las personas que están observando, tratando de generar confianza en este sistema, podrían observar una decisión y podría ser indistinguible para ellos de un defecto o, “Oh, no, eso es sólo una nueva manera de hacer las cosas.”
¿Cómo exactamente, si es tan radicalmente diferente al sistema anterior, cómo esperas que la gente diferencie entre “Esa es una decisión demencial” o “No, parece una locura, en realidad es la mejor decisión financiera que puedes tomar”?
Joannes Vermorel: No, quiero decir, primero, el primer lote de cosas que necesitas arreglar son realmente una locura. ¿Bueno? Casi invariablemente es porque hay algún campo que se malinterpreta, porque, nuevamente, estamos hablando de miles de tablas. Hay algo en lo que crees que tienes unidades, pero en realidad no son unidades, son kilogramos o lo que sea. Tienes cosas, está completamente apagado.
Y muy frecuentemente, por ejemplo, el primer lote será solo para verificar con un director financiero que estamos viendo el mismo margen bruto, el mismo valor de las acciones. Y no es inusual que en el primer intento termines teniendo una discrepancia de factor dos por cualquier motivo. Entonces eso es, esto es como la primera capa de locura.
Y luego también descubres toda la TI en la sombra. Por ejemplo, sugieres una cantidad de 110, y luego hay alguien que te dice: “Ay no, no, no. No te lo dije, pero solo viene en pallets de 100 unidades”. Bien, entonces hay mucho multiplicador. No fue documentado. Sí. Bien, debemos tener eso en cuenta. Y luego, etc. Y luego hay personas que levantan la mano y dicen: “Oh, pero no, tuvimos estas rebajas de precios de este proveedor”.
Conor Doherty: Sí.
Joannes Vermorel: No está registrado en el sistema. Por lo general, simplemente realizaba ajustes manualmente en una hoja de cálculo. Bien, tenemos que arreglar eso, etc., etc. Entonces, para mí, la mayor parte de las primeras rondas de iteraciones son en realidad todas estas cosas que son, yo diría, locura fácil. Es algo en lo que hay un malentendido sobre los datos, hay una restricción que no está modelada adecuadamente, etc., etc.
Y como te fijas el objetivo de que queremos tener una toma de decisiones desatendida, es más exigente. Porque normalmente, históricamente, los practicantes decían: “Oh, este número, sí, es bueno, 110, simplemente lo redondearemos manualmente a 100. Para mí es bueno”. Y Lokad va mucho más allá y dice: “No, no, no. Si hay mucho multiplicador involucrado, entonces la receta numérica debe, no es opcional, debe hacer todo lo posible para que no necesitemos tener un paso correctivo manual al final”. No es satisfactorio.
Entonces, deshacerse de la locura es eliminar todas estas cosas. Y luego sí, más adelante tendremos decisiones que no reflejan la práctica histórica. Y aquí tendremos reflejadas las fuerzas económicas. Y normalmente, si hay un desacuerdo, será: “¿Están de acuerdo con los dólares que estamos viendo?”. Lokad sugiere que cuando miramos los dólares involucrados en términos de costo del faltante de stock versus costo del exceso de existencias, este es el equilibrio que vemos.
Y aquí tendremos una iteración sobre esos impulsores económicos para tener un acuerdo compartido. Y esa será la segunda ronda de cosas en la que tendremos que corregir las decisiones locas, es decir, que de hecho los impulsores económicos que son muchas conjeturas inicialmente resultan incorrectos, y necesitamos iterar rápidamente para ubicarlos en el estadio de lo que se siente bien para la empresa.
Y finalmente, sí, al final tendremos decisiones que a veces sorprenden a los profesionales, pero llegan bastante tarde porque en este punto, lo que vemos, y eso es típicamente lo que sucede con un sistema que funciona bien, es que romperá los viejos patrones. Por ejemplo, digamos que los pedidos para un proveedor determinado siempre se realizan los lunes, pero no es una restricción real.
Conor Doherty: Sí.
Joannes Vermorel: El proveedor puede tomar pedidos cuando queramos. Y a veces tiene sentido aprobar un pedido el jueves y no esperar hasta el lunes siguiente, simplemente porque, bueno, cuanto antes mejor si vemos que hubo un aumento inesperado de la demanda. ¿Por qué debería empezar esperando un par de días cuando ya sabe que necesita aprobar un pedido? Eso romperá algunos hábitos.
Pero aquí la pregunta será, nuevamente, ¿es la medida correcta desde la perspectiva de la tasa de rendimiento? ¿Es este movimiento más rentable o no? Y aquí ese será el alcance de la conducción del cambio, es decir, bueno, si esto es obviamente algo más rentable, incluso si no coincide con el antiguo patrón manual, entonces esta debería ser la decisión, y eso es todo, y no tratar de agregar restricciones ficticias para que encaje.
Por cierto, eso es algo que estaba sucediendo bastante, yo diría que hace más de una década, en Lokad, es que teníamos menos experiencia de la que tenemos ahora. Y el tipo de problemas que tuvimos es que frecuentemente algunos de nuestros prospectos terminaban diciendo: “Oh, queremos… esas decisiones cambian demasiado en comparación con lo que teníamos antes. Así que vamos a introducir restricciones suaves, restricciones que no son reales”.
Por ejemplo, un equipo podría estar acostumbrado a tener MOQ flexibles en lugar de MOQ estrictos, por lo que las cantidades de pedido mínimas son irreales. El proveedor no los tiene. Al almacén no le importa. No hay ningún beneficio económico asociado con ellos. Pero para el equipo de compras, era solo una forma de pasar menos órdenes de compra, hacerlas menos frecuentes porque tenían muy baja productividad y, por lo tanto, esa era una forma de ahorrar tiempo.
Pero nuevamente, una vez que ingresa al territorio de los procesos de toma de decisiones desatendidos, a menos que haya una ganancia económica asociada al procesamiento por lotes de sus órdenes de compra, en cuyo caso debe reflejarse en la receta numérica, entonces no tiene sentido intentar modelar esos MOQ blandos que están completamente inventados y surgen de la nada.
Conor Doherty: Escuchar eso me recordó una anécdota. Fuiste tú, hace muchos años, creo que fue durante un evento en vivo hace un par de años, mencionaste, y nuevamente no voy a decir quién, nuevamente fue un cliente, y en el sector aeroespacial, eso es lo que diremos, pero demuestra la idea de que una vez que instalas un sistema de inteligencia y comienzas a adaptarte, tienes que generar confianza, surgirán decisiones oportunistas y algo así como capitalistas que están fuera de los límites de lo que antes pensabas que era posible.
Y desde ese punto de vista puede parecer una locura, pero una vez que investigas la economía, tiene sentido. Y el ejemplo que creo que dio fue: Voy a destruirlo, pero muy, muy simple, una empresa de MRO tenía una orden de compra recomendada e incluía, por ejemplo, comprar un motor completo. Digamos simplemente, compre un motor. Compra el motor de un A380. Y eso fue marcado como, “Eso es una locura. ¿Por qué me dices que compre un motor completo?”
Y la justificación fue que el sistema de inteligencia había descubierto, bueno, en realidad, estos aviones en el área acababan de ser desguazados. Este motor ahora se vende con un 50% de descuento. Cómprelo, siéntese y podrá venderlo para obtener ganancias en seis meses. Entonces la recomendación no fue comprar para usar, sino comprar para vender, lo cual nuevamente es muy, muy diferente a lo que era el método anterior, del tipo “Compro lo que necesito para satisfacer este propósito”. Mientras que ésta es una perspectiva económica mucho más global. Así que no se trata simplemente de: “Oh, solía marcar esta casilla para lograr este propósito”. Hay varias formas de despellejar a un gato y ganar más dinero.
Joannes Vermorel: Sí, exactamente. Y esto sigue ocurriendo, por ejemplo, en la aviación. Los aviones se desmantelan.
Conor Doherty: Exactamente.
Joannes Vermorel: Y entonces tienes oportunidades de compra, sí, una parte es… nuevamente, depende de tu situación, pero si sabes que eres una empresa que no tiene escasez de efectivo, es rica en efectivo, y eso es algo, y no te falta espacio de almacenamiento, y esto será necesario tal vez dentro de un año, y lo más probable es que, cuando lo necesites, pagues un precio que será casi garantizado mucho más alto que ahora, sí, deberías verlo.
O puede ser un minorista donde tienes una promoción de un proveedor y el producto no perderá su valor demasiado rápido, y simplemente tendrás la oportunidad de venderlo con un margen bruto mucho mejor. Entonces sí, ese es el tipo de cosas donde… pero nuevamente, es por eso que la justificación económica y la explicabilidad, la forma en que fundamentamos la explicabilidad está en la economía.
Ya sabes, es “¿Por qué haces eso?” La respuesta es, bueno, mire las finanzas. Y si el modelo dice que es muy rentable y tiene sentido desde una perspectiva económica, entonces es la decisión correcta, incluso si históricamente no era la costumbre en la empresa.
Conor Doherty: Muy bien. Bueno, lo único que no hemos cubierto todavía es lo que sucede después de la implementación. Entonces digamos que usted es una empresa, ha escuchado todo esto, es genial, quiere salir y comprarse un sistema de inteligencia. Después de la implementación, ¿qué queda bajo el control de un proveedor y qué mantengo como cliente internamente? ¿Qué partes de este proceso están totalmente bajo mi control y qué es externo a usted?
Joannes Vermorel: Creo que, en primer lugar, la gran lección del despliegue es cuál debería ser el final. Ya sabes, si quieres tener éxito, debes apostar por una toma de decisiones desatendida.
Conor Doherty: Mhm.
Joannes Vermorel: Si no lo haces, te costará 10 veces más. Será diez veces más lento y no será acumulativo ni capitalista. No tendrá algo que realmente lleve a su empresa a la siguiente etapa de rentabilidad en lo que respecta a su supply chain. Esta es realmente la lección concisa.
Y no importa si un proveedor está involucrado o no, si desea hacerlo internamente o no, etc. Nuevamente, este libro realmente no trata sobre Lokad. Esto es: ¿qué significa desplegar? Porque verán, el tipo de antipatrón que veo en esta industria es que mucha gente diría: “Oh, hemos hecho esta iniciativa de supply chain, y ésta, y ésta, y ésta”, y ninguno de ellos ha llegado realmente a esta especie de etapa de toma de decisiones desatendida.
Entonces terminas con paneles de control que se ignoran, un dispositivo aquí que se ignora, una pieza de software allá que es solo un pozo de productividad. Literalmente, no aporta mucho considerando la cantidad de tiempo que hay que dedicarle, etc., etc. Así que creo que la idea clave de la implementación es que es necesario tener un objetivo claro independientemente de quién está a cargo de qué. Debería ser terminar con algo en lo que puedas confiar, que genere diariamente esas decisiones desatendidas.
Y luego lo que estoy diciendo es que es una pieza de software y necesita mantenimiento. Una vez más, nadie evita la deriva.
Conor Doherty: Sí, exactamente.
Joannes Vermorel: Simplemente porque no tenemos Skynet AI, no espere que un software, sin importar cuánto genio le ponga, etc., se autoadapte a los cambios estructurales en su mercado.
Conor Doherty: Lo cual es todo el tiempo, para ser completamente honesto.
Joannes Vermorel: Sí, no todo el tiempo. Pero ya ves, porque hay clases de cambios que no son estructurales. Si se trata sólo de que el mercado suba o baje, entonces el modelo de pronóstico, los modelos de aprendizaje automático, se encargarán de eso. El problema es qué sucede cuando su negocio se vuelve diferente, no sólo más de lo mismo o menos de lo mismo porque crece o se está reduciendo, sino cuando se convierte en una bestia completamente diferente.
Piense, por ejemplo, en un MRO que vendía repuestos y ahora vende tiempo de actividad por horas de vuelo.
Conor Doherty: Sí. Es un modelo de negocio completamente diferente.
Joannes Vermorel: Ni siquiera estás vendiendo lo mismo.
Conor Doherty: Sí. Habrá piezas de aviones. Habrá mecanismos superpuestos.
Joannes Vermorel: Pero su modelo de negocio es completamente diferente y sus incentivos son completamente diferentes. El modelo económico de su negocio es completamente diferente. Y lo mismo sucedió, por ejemplo, hace una década, cuando muchos minoristas tradicionales se convirtieron predominantemente en e-commerce. Entonces, obviamente, si predominara el comercio físico y ahora el e-commerce, todos los incentivos, el tipo de estrategia, todo está cambiando. Y eso no se trata sólo de más o menos ventas. Es una transformación. La naturaleza misma de su negocio está cambiando.
Nuevamente, lo que estoy diciendo es que para todas las variaciones mundanas, un proveedor que tiene un problema y los tiempos de entrega se vuelven más lentos, toda la variabilidad mundana debe manejarse sin ningún cambio mediante su receta numérica. Lo que estoy diciendo es que su receta numérica no podrá por sí sola adaptarse al hecho de que, por ejemplo, está introduciendo un nuevo ERP.
Conor Doherty: Sí. O que estás cambiando, o que estás cerrando centros de distribución, o todas esas cosas.
Joannes Vermorel: Sí, exactamente. Quiero decir, cosas que son muy estructurales. Por eso es necesario darle mantenimiento. Es porque necesita a alguien que preste atención y se asegure de que este software esté alineado con la realidad de su mercado, la realidad de su empresa y la realidad de su panorama aplicativo.
Y es por eso que quien esté a cargo, en Lokad lo llamamos Supply Chain Scientist, pero quien esté a cargo de elaborar la receta numérica debe luego estar a cargo de mantener la receta numérica. Y la realidad es que también puedes tener a esta persona encargada de la mejora continua de la receta numérica, porque normalmente cuando entras en producción el trabajo apenas ha empezado.
Ha logrado un cierto grado de rendimiento económico que suele ser un gran avance en comparación con el status quo anterior, que era un proceso manual, pero eso no significa que esté cerca de algo que calificaría como óptimo. Simplemente significa que estás mucho mejor, pero puedes seguir invirtiendo en este activo para mejorarlo con el tiempo.
Conor Doherty: Bueno, repito, no quiero irme, esto no está en el capítulo 10, pero vale la pena unirlo, porque ese es el punto central del tratamiento de la supply chain, en este caso el software de la supply chain, la diferencia entre capex y opex. Porque cuando se invierte en un sistema de inteligencia, como acaba de decir, no hay límite superior sobre cuánto mejor, cuánto más eficiente y cuánto más gratificante financieramente puede llegar a ser una decisión. Quiero decir, estoy seguro de que sólo hay una cierta cantidad de dinero en el mundo, pero siendo realistas, no hay límite para lo bueno que podría ser. Entonces, si invierte adecuadamente en eso, al menos estará orientado en la dirección en la que realmente debería ir financieramente.
Joannes Vermorel: Sí. Sí. Y nuevamente, se convierte, hasta cierto punto, en una empresa empresarial. Tienes que decidir si quieres ampliar el abanico de opciones. ¿Deberían, por ejemplo, tomar decisiones en las que puedan empezar a decir que los MOQ son un hecho, pero la siguiente etapa sería: los MOQ tal vez deberían renegociarse? ¿Hay algún caso? ¿Se puede ganar dinero renegociando los MOQ con los proveedores?
¿De qué debería tratarse la negociación? ¿Cómo debería verse? ¿Estamos bien con un precio unitario ligeramente más alto si podemos reducir sustancialmente el MOQ, o deberíamos hacer lo contrario, etc., etc.? Como ven, comenzamos con… una iniciativa de supply chain comienza con un alcance específico en términos de decisiones, pero luego, con el tiempo, puede expandirse para tener más y más decisiones.
Generalmente se comienza con, diría yo, las decisiones fundamentales básicas que gobiernan el flujo, pero luego se pueden superponer con decisiones que también dan forma al flujo, aunque generalmente se dan por sentado al principio, solo para mantener la iniciativa firme y terminar entregando, nuevamente, una toma de decisiones desatendida rápidamente antes de expandirse a más y más alcances.
Conor Doherty: Bueno, este es en realidad mi pensamiento final, pero sigue lo que acabas de decir. Obviamente, el objetivo final es la toma de decisiones automatizada y desatendida orientada al mejoramiento financiero de la empresa. Excelente. Ese es el producto final de una implementación y, nuevamente, se mejora continuamente, etc. Brillante.
Que puedas juzgar el ROI o que al menos puedas observar. ¿Significa eso, por lo tanto, que en los primeros meses, cuando solo se está en las etapas de validación y clasificación de datos, eso no tiene ningún valor financiero real? Entonces, básicamente, sin el producto final, ¿no tienen valor los primeros pasos? ¿O hay valor en toda esa cadena?
Joannes Vermorel: No. Quiero decir, de nuevo, mientras no generes las decisiones finales, no tienes idea, ni la más mínima, de si estás en el camino correcto o no. Verás, por eso digo que si empiezas a perseguir artefactos numéricos, no lo sabes. Puede que parezca muy bueno, pero la realidad es que no tienes ni la más mínima idea.
Verás, de nuevo, piensa en ello como si te estuviera hablando de ajedrez. Sin sugerir el movimiento final. Si digo… imagina que tienes una partida de ajedrez y hago cientos de afirmaciones sobre cómo se ve, el tipo de cosas que son posición fuerte, posición débil y todo eso, y al final no digo qué tipo de movimiento deberíamos hacer a continuación. Quiero decir, ¿cuál es el valor de toda esta orientación? Verás, es…
Y ahí está el problema: para mí, muchos proveedores de software empresarial han estado utilizando esta ambigüedad para vender cosas durante décadas. Tendrán todo tipo de artefactos numéricos. “Les daré un cuadro de mando para sus proveedores, un cuadro de mando para los productos, indicadores para esto, para aquello, un gemelo digital que simula esto y aquello y aquello y aquello”, un sinfín de cosas. Y luego ni un solo compromiso con una decisión final en la que podamos ponernos de acuerdo: “¿Esto generará ganancias o pérdidas?”
Y lo que digo es que esto no lo es… y esa es una diferencia de apreciación. Este no es un objetivo lejano. Esto es algo que se puede lograr, nuevamente, según la experiencia de Lokad, de ocho a diez semanas. Y nuevamente, de ocho a diez semanas con un equipo que suele ser bastante limitado. Esta no es una empresa enorme. Esto es…
Y para mí, eso es el comienzo de todo. El despliegue no es… para nosotros, decimos que el cierre del despliegue es cuando la empresa realmente confía en el proceso de toma de decisiones desatendido, que es como los últimos dos meses del proceso. Y creo que el error, y por eso digo que muchas empresas terminan distraídas, es que en lugar de tomar directamente decisiones desatendidas, que consideran una meta súper madura y súper remota, comenzarán a perseguir otras metas.
Y dicen: “Oh, no, no podemos tener un sistema completamente robotizado en 10 semanas. Creo que primero debemos establecer un flujo de trabajo, y eso llevará 20 semanas”. Verá, entonces establece un paso intermedio que ya es dos veces más grande y dos veces más complejo que su final. Y es por eso que digo que esos artefactos numéricos, esas ideas que provienen de la teoría dominante de la supply chain, terminan creando tanta complejidad.
Así es como terminas con proyectos que toman varios años. Y después de varios años, todavía no tiene algo que se acerque a un proceso desatendido, o que se acerque a algo que sería gasto de capital, con un activo que sea productivo y donde sus inversiones se vuelvan acumulativas. Por eso digo que es necesario incluirlo en la agenda como si éste fuera el objetivo número uno. Esto es con lo que deberíamos empezar y luego mejorarlo.
Conor Doherty: Estoy de acuerdo. Y bueno, lo único que quiero agregar es que realmente quiero usar la analogía, el símil, que has usado varias veces, es decir, el ajedrez. Y luego solo voy a decir algo, dame tus pensamientos finales.
Pero si el resultado final de un despliegue es hacer los mejores movimientos con las piezas del tablero de ajedrez para poder ganar el juego, ese es el objetivo final, ese es el sistema de inteligencia, las decisiones automatizadas. Los primeros meses, la clasificación y validación de datos, donde se construye el esquema, se analiza, se comprenden las conexiones, es decir, se construye efectivamente el tablero de ajedrez o, al menos, se muestra: “Aquí está el tablero de ajedrez, aquí está el color de los cuadrados, así es como se ven las piezas. Aquí están los movimientos que realmente puedes hacer. Así es como se mueve un caballo. Esto es lo que hace una torre”.
No te daré las decisiones porque aún no he llegado a ese punto. Pero para mí tiene un valor manifiesto saber: “Oh, así es como se ve un tablero de ajedrez. Eso es lo que hacen estas piezas”.
Joannes Vermorel: Sí. Sí. Obviamente. Entonces, si estamos hablando de eliminar riesgos en la iniciativa, sí, puedes tener una idea de la progresión. Sí. Pero seamos realistas: la mayoría de las iniciativas de software de la supply chain normalmente se implementan en varios años. La mayoría de los proveedores de software venderían licencias en las que es necesario tener un compromiso mínimo de un año y, muy frecuentemente, un compromiso de cuatro años. Una vez más, esto es completamente falso.
Lo que estoy diciendo es que deberías apuntar a algo que sea mucho, mucho más corto. Sí. Y 10 semanas no es mucho, ¿sabes? Y nuevamente, si quieren tener una idea de si esta entidad, incluso si es una solución interna, está progresando hacia la solución, en la cuarta semana pueden preguntarle a la persona a cargo, nuevamente, digo una mente, sí, ¿qué estás haciendo? ¿Qué estás construyendo? ¿Tiene sentido para ti? La explicación que se da es: “¿Esto me permitirá conocer la receta completa dentro de seis semanas?”
No creo que haya mucho trabajo para los preparativos, pero en el gran esquema del software empresarial, poder llegar a un punto en el que se entregue el producto final en unas 10 semanas, en términos de efecto túnel, en realidad no es tanto. Realmente no es tanto. Tal vez, en el futuro, con los agentes de codificación, reduzcamos ese tiempo a la mitad, pero creo que sigue siendo muy rápido.
Sí, el problema, verás, no veo mucho potencial… podemos tener un potencial para llevar esto, digamos, 10 semanas de efecto túnel a cinco con muchos agentes codificadores, para acelerar realmente esta parte, pero aquí no es realmente donde está el desafío. El desafío es, en comparación con el status quo, buscar algo en lo que normalmente se obtendrá un resultado en 10 semanas, en lugar de literalmente buscar un proceso en el que, por diseño, se opte por algo que tomará 100 semanas.
Verá, muy frecuentemente cuando se trata de implementación, por ejemplo, una cosa que escucho con mucha frecuencia es que la gente dice: “Oh, sí, oh no, no podemos darnos el lujo de hacer eso, tener resultados en 10 semanas. Necesitamos comenzar haciendo una RFP”, y bam, 18 meses. Bien, entonces te transformaste… tenías algo en lo que podías obtener resultados en 10 semanas, y ahora tienes un año y medio solo para seleccionar proveedores, y esta selección de proveedores te cuesta mucho más que hacer las cosas.
Y luego terminas con un proveedor que literalmente pregunta: quieren un compromiso por un año, si no son como cuatro años. Vale, esto es falso. Esa es también la lección del despliegue: cuáles son las escalas de los cronogramas relevantes.
Lo que estoy diciendo es que se puede llegar a un proceso de toma de decisiones sin supervisión en 10 semanas. Le llevará unos seis meses confiar completamente en esto, porque la mayor parte es en realidad el tiempo que les toma a los humanos confiar en un software. No tiene mucho que ver con la tecnología. Es por eso que incluso si mañana tenemos agentes de codificación que pueden traer este retraso de, digamos, 10 semanas para llegar realmente a una receta numérica que funcione y que no sea completamente loca, probablemente mañana podamos tener esto comprimido en cinco, seamos locos, tres semanas.
Aún pasarán un par de meses hasta que los profesionales, la alta dirección, confíen en este software y le permitan tomar el control de una parte importante de la empresa. Verás, al final, diría que esta no es la verdadera batalla. La verdadera batalla es… Quiero decir, puedes pasar algunas semanas aquí. Lokad está trabajando en ello, pero requiere muchas tecnologías sofisticadas y muchas prácticas muy refinadas, porque cada día cuenta. Quieres ser muy, muy rápido.
Pero muy frecuentemente, verá, Lokad, trabajamos en el desarrollo de tecnologías para poder aprovechar unos días aquí y allá. Pero lo que veo es que veo muchas, muchas empresas en las que estamos en discusión, y comienzan perdiendo años enteros en cosas como, sí, por diseño, donde van para una RFI, boom, ocho meses, luego 12 meses, y luego eligen un primer proveedor que dijo que entregarían algo en ocho meses, pero en realidad un año y medio después todavía no tienen casi nada que mostrar, y ciertamente no está automatizado, etc.
Quiero decir, verás, imagina este tipo de situación súper frustrante en la que Lokad… estamos en conversaciones con una empresa, y luego pasan por un proceso, y nos lleva cinco años finalmente iniciar el piloto, que luego se realiza en 10 semanas.
Conor Doherty: Sí.
Joannes Vermorel: Verás, ese es muy frecuentemente el tipo de… y esa sería tal vez una lección para la implementación. Lo que estoy describiendo es que para implementar una iniciativa de supply chain, las empresas deben tener ambiciones que, en cierto sentido, deben ser mucho más altas. De nuevo, toma de decisiones desatendida.
Y no quieres empezar con algo pequeño. Quieres empezar con el problema más difícil. De nuevo, ¿por qué? Porque desea eliminar a las personas incompetentes, ya sea una solución interna o un proveedor externo. Realmente desea comenzar con algo que sea realmente difícil como forma de evaluar la competencia real de quien espera que resuelva el problema.
No empiece con un problema fácil, porque entonces puede terminar con una entidad incompetente, ya sea una solución interna o un proveedor externo, que simplemente hace un trabajo aceptable, pero no se da cuenta de que es un callejón sin salida porque eligió algo que es fácil, francés, que trata con un pequeño conjunto de datos, etc. No, no. Una vez que entras en el camino moderno de la supply chain, eliges el problema más difícil, el conjunto de datos más grande que tienes, y quieres, en 10 semanas, asegurarte realmente de que la entidad que crees que será tu solución a largo plazo sea examinada en este asunto, que sepas que funciona.
Si comienzas examinando esta entidad en algo que es fácil, no sabes si esta persona o entidad será capaz de hacer las cosas difíciles después. Nuevamente, si el problema difícil tomara como tres años, dirías que no, que tenemos que hacer algo pequeño. Pero lo que estoy diciendo aquí, y eso también es parte del despliegue, es que, hasta donde yo sé, no hay ningún problema en las supply chains donde, en 10 semanas, no se puede tener un proceso de toma de decisiones desatendido que demuestre el hecho de que se es capaz de hacerlo o que demuestre el hecho de que se es incompetente. Eso es todo.
Y es que si el proveedor no puede hacerlo en 10 semanas, no podrá hacerlo en 100 semanas. Por tanto, no tiene sentido seguir invirtiendo. Tienes que admitir que no funcionó. Es necesario cambiar de proveedor, cambiar de método, cambiar algo más fundamental. Simplemente darle tiempo no va a ser suficiente.
Conor Doherty: Muy bien. Bueno, Joannes, no tengo más preguntas. Hemos estado trabajando, creo, durante aproximadamente una hora y media, pero creo que hemos cubierto mucha información muy práctica, que nuevamente recomiendo encarecidamente a la gente que regrese y lea el capítulo 10. Hay muchas cosas muy útiles. Pero muchas gracias por su tiempo y muchas gracias por mirar.
Y sí, si tienes alguna pregunta o quieres hablar con Joannes y conmigo personalmente, puedes comunicarte con nosotros en LinkedIn o enviarnos un correo electrónico a contact@lokad.com. Ya conoces el procedimiento. Y con eso, nos vemos la próxima semana. Vuelve al trabajo.
