00:00:00 Capítulo cinco: las decisiones requieren apuestas informadas
00:04:48 Teoría de Shannon: la información como cantidad computable
00:09:36 Los datos equivalen a bits; la verbosidad no oculta nada
00:14:24 El conocimiento convierte la información en acciones rentables
00:19:12 Principio del pasado inmutable, los diseños de ERP lo violan
00:24:00 Se reescriben los ceros del faltante de stock, los forecast se vuelven sesgados
00:28:48 Dolor económico: capital mal asignado, retornos más bajos
00:33:36 Los malos datos son chivos expiatorios que enmascaran la confusión arquitectónica
00:38:24 Analogía del historiador: registros fijos, semántica interminable
00:43:12 Sistemas divididos: registros, reportes, inteligencia
00:48:00 Los reportes imponen el cumplimiento, no impulsan decisiones futuras
00:52:48 La inteligencia genera asignaciones bajo incertidumbre
00:57:36 Excel demuestra que las capas de decisiones ya son híbridas
01:02:24 Se venden registros como si fueran mágicos, los proveedores lucran
01:07:12 Prueba decisiva: ¿el software muta el pasado?
01:12:00 Afirmaciones demasiado buenas para ser verdad, despídete del chequeo de realidad de M5
Resumen
Decisiones de supply chain son apuestas sobre un futuro incierto, por lo que el pensamiento claro es importante. La discusión traza líneas claras entre datos, información y conocimiento, y luego argumenta que la mayoría del supply chain software los confunde gravemente. Su punto más agudo es que el pasado debe permanecer inmutable: una vez que las empresas reescriben la historia para adaptarse a modelos débiles, corrompen la base para tomar buenas decisiones. De ahí surge la distinción práctica entre sistemas de registro, sistemas de reporte y sistemas de inteligencia. Las empresas gastan de más en libros contables glorificados, invierten insuficientemente en motores de decisión reales, y luego se preguntan por qué el rendimiento decepciona. Categorías claras, no la mística del proveedor, son el comienzo de la competencia.
Resumen Ampliado
Esta discusión se centra en una idea simple pero de gran alcance: las decisiones de supply chain son apuestas bajo incertidumbre, y por ello, aquello que informa dichas decisiones importa enormemente. La queja central es que la mayoría del pensamiento en supply chain no ha logrado establecer distinciones claras entre datos, información y conocimiento. Los datos son meramente símbolos registrados. La información es lo que reduce la incertidumbre. El conocimiento es la comprensión causal que permite a un tomador de decisiones, sea humano o máquina, convertir la información en acciones que mejoran los retornos económicos.
A partir de esta base surge un segundo punto importante: el pasado debe tratarse como inmutable. Los registros históricos de una empresa deberían reflejar lo que realmente sucedió, y no lo que los planificadores desearían que hubiera ocurrido. Sin embargo, muchos sistemas, especialmente el software empresarial estándar, están construidos de manera que permiten reescribir el pasado. Esto se vuelve especialmente tentador cuando los modelos deficientes chocan con hechos inconvenientes. Por ejemplo, si un faltante de stock conduce a ventas registradas como cero, un sistema de forecast simplista puede interpretar esos ceros como evidencia de una demanda débil. En lugar de arreglar el modelo, los profesionales a menudo “corrigen” el registro histórico. En otras palabras, falsifican el pasado para acomodar las limitaciones del presente. Eso no es simplemente un error técnico. Es un error conceptual, y conduce a una mala asignación de capital y a retornos más bajos.
Se sigue una tercera distinción: las empresas necesitan separar los sistemas de registro, los sistemas de reporte y los sistemas de inteligencia. Los sistemas de registro son libros contables glorificados. Su función no es pensar, sino almacenar registros confiables del pasado. Los sistemas de reporte resumen la actividad pasada y ayudan a la gestión a asegurar el cumplimiento de los procesos existentes. Son instrumentos retrospectivos de supervisión. Los sistemas de inteligencia son algo completamente distinto: se orientan hacia el futuro y generan decisiones sobre cómo deben asignarse los recursos.
El argumento es que las empresas habitualmente gastan de más en sistemas de registro porque los proveedores envuelven de mística lo que, en esencia, son herramientas contables costosas. Mientras tanto, la verdadera fuente de un desempeño superior, los sistemas de inteligencia, es subvalorada porque son más difíciles de construir, más difíciles de explicar y más difíciles de vender con promesas superficiales.
El consejo práctico es sorprendentemente simple. Al evaluar software, pregunte si éste muta el pasado. Pregunte si separa claramente el registro de datos de la toma de decisiones. Si el proveedor no puede responder con claridad, eso por sí solo sirve como respuesta. Mucha decepción en el software empresarial comienza cuando las empresas esperan que los libros contables piensen, que los reportes decidan y que los vendedores digan la verdad sobre cualquiera de ellos.
Transcripción Completa
Conor Doherty: Bienvenidos de nuevo. En esta serie especial, Joannes y yo tomamos su nuevo libro, Introduction to Supply Chain, y vamos capítulo por capítulo, discutiendo los méritos, los desafíos, los problemas y los consejos prácticos.
Para esta serie, asumo la postura de alguien que no conoce a Lokad, no conoce a Joannes, y está completamente ajeno a la perspectiva de Supply Chain Quantitativa. De hecho, asumo la posición de uno de los aproximadamente 10 millones de profesionales en el ámbito de supply chain, alguien que podría ver este libro en una estantería, quizás en una librería, quizá en Amazon, tal vez tomarlo, empezar a leerlo y tener preguntas. Y mi papel en esta serie es ser vuestra voz. Planteo esas preguntas a Joannes y trato de obtener aclaraciones sobre cualquier cosa que pueda parecer poco clara.
Ahora, este es el episodio cinco. Si no han visto los cuatro anteriores, les sugiero verlos, porque lo que decimos hoy seguramente resonará en discusiones previas.
Y con eso, Joannes, es bueno verte de nuevo. Entonces, capítulo 5: información. Creo que, para enmarcarlo, en realidad te leeré la línea de apertura del capítulo 5, porque pienso que realmente proporciona una buena perspectiva para la discusión. El capítulo 5 comienza: “Cada decisión en supply chain es una apuesta bajo incertidumbre. Para ser buena, debe estar informada.” ¿Qué quieres decir con eso, y cuál es el mensaje práctico del capítulo 5?
Joannes Vermorel: Primero, estoy señalando algo que debería ser evidente. Es evidente que tu supply chain es compleja. Está compuesta por muchas personas, muchas máquinas, muchas ubicaciones, muchos inventarios.
Si eres completamente ignorante acerca de todo eso, creo que podemos asumir razonablemente que es evidente que tus decisiones serán muy malas. Podemos entrar en el debate filosófico de si posees algún tipo de presciencia o alguna habilidad mágica que te permita tomar decisiones correctas en ausencia de información, pero eso suena rápidamente a algo nada realista.
Así que ahora, un buen gerente debe estar informado, las decisiones deben estar informadas. Está bien, eso es, en cierta forma, lo que nos interesa. Pero, ¿qué significa eso específicamente? ¿Qué significa eso?
Y la respuesta corta es que la información ha sido completamente codificada a nivel matemático a lo largo del siglo XX. Así, no tenemos que adivinar. Esta es un área en la que, en realidad, contamos con conocimiento científico de altísima calidad y sumamente confiable.
Este conocimiento no es teórico. Literalmente, cada pieza de software en la actualidad utiliza este conocimiento de múltiples maneras, incluso en supply chain. Incluso en supply chain. Así que cualquier software que uses está empleando esta teoría del conocimiento de la información de múltiples maneras.
Sí, tu navegador, tu teléfono, el sistema que usas para videoconferencias, cualquiera, y también tu software de supply chain.
Conor Doherty: Entonces, ¿mi proposición, ERPs, es a lo que te refieres?
Joannes Vermorel: Sí. ERP, cualquier… De nuevo, esta teoría de la información, la teoría de Shannon, es tan fundamental que es un poco como la aritmética básica. Está absolutamente en todas partes, y ese es el punto.
Lo que estoy diciendo es que tenemos algo que es absolutamente masivo, que está en todas partes, y que… si lo quitaras, no existiría ni una sola pieza de software que siga funcionando, casi. Tal vez cosas triviales, pero cualquier cosa que tenga siquiera un atisbo de complejidad simplemente dejaría de funcionar. Y sin embargo, ese es mi punto: ¿cómo es posible que nunca haya visto que esta teoría sea siquiera mencionada en ningún libro de texto sobre supply chain? Tenemos un problema.
Conor Doherty: Cuando hablas de… disculpa, gracias. Cuando hablas de información en esto, nuevamente, específicamente en el contexto de supply chain, ¿te refieres a datos, verdad? ¿O qué es lo que quieres decir específicamente?
Joannes Vermorel: No, ese es el punto, es que este término que se usó de manera muy direccional, como información… ¿qué es la información? “Ah, eso es lo que escucho… lo que se dice en las noticias. Eso es información.” Está bien, esto es en líneas generales correcto.
Pero, ¿qué pasa con una definición súper precisa, matemáticamente correcta… diría que una definición que tenga claridad matemática, no validez, claridad matemática? Algo que sea absolutamente puro, algo tan puro que realmente puedas procesarlo con ecuaciones. Y ese es el punto que estoy exponiendo. No tenemos teorías tan increíbles sobre todo.
Hay muchas cosas en las que… Por ejemplo, en el caso de la inteligencia, no tenemos una teoría de la inteligencia de pureza cristalina, de alta pureza. No, no, no. Tenemos cosas que son sumamente confusas, extremadamente turbias. Así que no siempre está disponible.
Pero resultó que para la información, Shannon, una de las mentes más brillantes del siglo XX, resolvió el problema y nos dio una teoría, la teoría de la información de Shannon, que es sumamente bella, simple y eficiente.
Conor Doherty: ¿Y qué es eso?
Joannes Vermorel: Entonces, ¿qué es eso? Es literalmente algo que codifica a nivel matemático lo que es la información. Y esto no es una especulación matemática.
Resultó que esta codificación matemática es increíblemente eficiente. Hace que el software funcione mejor. De hecho, casi no hay nada que podamos hacer con computadoras modernas que pudiéramos hacer sin recurrir a esta teoría. Así que sé que es un poco extraño tener eso, y que la gente nunca haya oído hablar de ello. Pero para la audiencia que ha hecho algo de informática, es tan obvio como la aritmética. Es fundamental. Es muy difícil imaginar un mundo sin esta teoría de la información.
Conor Doherty: Está bien. Pues déjame leerte algunas citas, porque nuevamente creo que el libro tiene 500 páginas, así que te daré un poco más de contexto aquí, y de esa forma podrás responder de manera un poco más concreta, quizá.
Así que, nuevamente, la idea de que cada decisión en supply chain es una apuesta bajo incertidumbre, para ser buena debe estar informada. También escribes: “La teoría principal de supply chain theory routineariamente colapsa los datos en información. Trata las cantidades sobre las que se pretende decidir, esto es, la demanda, los lead times, los service levels, como directamente observables.” Ahora, a los 10 millones de profesionales que leen el libro y a todos los seguidores que están escuchando, que todos tienen un trasfondo en supply chain, ¿qué les estás diciendo allí, y qué cambia cuando tomo esa información?
Joannes Vermorel: Primero, debemos clarificar, eso es lo que hago en este capítulo, debemos clarificar la diferencia entre datos, información y conocimiento. Y la gente, nuevamente, tiene una intuición direccional, pero si profundizas, usualmente lo que sale es extremadamente confuso. Y de nuevo, si miro el libro de texto promedio sobre supply chain, es muy evidente que el autor no tiene ni idea de cuál es la diferencia entre esas tres cosas.
Nuevamente, cuando hablo de una diferencia, me refiero a si tienes una claridad a nivel matemático sobre ello. Porque es muy importante, ya que si no tienes en tu mente una claridad de grado matemático sobre esos conceptos, significa que no puedes usar ecuaciones. Si no puedes usar ecuaciones, eso significa que no puedes traducirlo a software.
Así que, de nuevo, es muy importante porque, en última instancia, lo que estamos describiendo es que esta claridad no es un lujo, es literalmente el ingrediente, es una cualidad que hace que esto sea traducible a términos de software. Necesitamos… porque, en definitiva, el software es sólo aritmética básica. El software es justo eso.
Así que, si no puedes traducir tus ideas a una aritmética escalonada, en efecto ni siquiera puedes poner eso en software.
Conor Doherty: Entonces, volviendo a datos, información, conocimiento, datos específicamente en lo que respecta a los ejemplos que das: demanda, lead time, niveles de servicio. ¿Cómo encaja esta teoría en esto?
Joannes Vermorel: Primero, datos, ¿cuál es la diferencia? Necesitamos abordar primero los datos. Sí, los datos son simplemente la capacidad de almacenar ceros y unos. Si lo analizas, los datos son solo una representación donde tienes ceros y unos. Eso es todo. Eso son datos.
Ahora, el problema es que los datos, de nuevo, si cuentas en términos de ceros y unos, realmente no te dicen nada, sobre algo que se asemeje a la información. Tenemos que descartar lo superfluo… ¿Por qué? Porque, por ejemplo, el número uno. Puedo escribirlo simplemente como “1”, o puedo escribirlo con una coma y un millón de ceros.
Conor Doherty: Es el mismo número.
Joannes Vermorel: Es el mismo número.
Conor Doherty: En francés, en inglés… o un punto.
Joannes Vermorel: Sí.
Conor Doherty: Por si alguien pensaba que un separador decimal sería un punto en inglés.
Joannes Vermorel: Exactamente. Y puedes rellenar con un millón de ceros. En términos de datos, si añades ese millón de ceros, tendrás un megabyte de datos. Pero, ¿tienes más información? Sigue siendo un número que equivale a uno. Lo que representa sigue siendo lo mismo.
Y así estamos diciendo que cualquier cosa se puede representar de muchas, muchas maneras, y algunas formas son más verbosas que otras. Y el problema con los datos es que los datos no te indican si lo que estás haciendo es verboso o no. Cuando dices, “Tengo un megabyte de datos”, si son solo ceros, no tienes datos, solo tienes ceros. Entonces la pregunta, y esa era la pregunta que hacía Shannon, era: “Bueno, ¿cuál es aquello que sería independiente de la representación?” Nos interesa algo que sea la esencia de lo que hay en los datos, y esta esencia debe ser independiente de la representación.
Y ahora Shannon estaba pensando: “Bueno, ¿qué es exactamente lo que intentamos resolver?” Esa es una gran pregunta, porque bueno, tenemos todas esas representaciones, pero ¿cuál es la finalidad, cuál es el final de tener las cosas representadas de diferentes maneras? Y Shannon llegó con una respuesta absolutamente asombrosa, brillante y simple: en última instancia, es la capacidad para resolver la incertidumbre.
Así que la información es, en el sentido más puro, tu capacidad para resolver la incertidumbre. Y por eso digo, si citas también del libro, que es la razón por la que puedes ver que este número, que puedo representar ya sea como un solo carácter o como un millón, hace lo mismo. Me permitirá resolver la incertidumbre de la misma manera exacta. Así, lleva la misma información.
Y luego Shannon va mucho más allá. Una vez que tienes esta comprensión, la capacidad para resolver la incertidumbre, te proporciona un marco matemático para entender realmente lo que está sucediendo. Te ofrece herramientas como la entropía informacional para que puedas medir de verdad la cantidad de información. Y ese es el asunto: la información se puede cuantificar. Podemos saber, al igual que se cuantifican kilogramos o litros, que se puede cuantificar la información en shannons.
Así que es literalmente algo muy interesante, y demuestra que es una unidad fundamental. Es una unidad fundamental de información.
Bien. Y resultó que, debido a que es tan fundamental, cada software se construye en torno a esas ideas. Y ahora, lo interesante es que, si volvemos a que el supply chain esté informado, es muy interesante, porque de repente tenemos algo extremadamente fundamental. Hemos aclarado, nuevamente con una claridad de nivel matemático, lo que significa realmente estar informado.
Y eso es tan importante, porque ahora no tenemos algo meramente correcto en cuanto a dirección. Tenemos algo que es muy, muy preciso en exactitud. Y ese es un instrumento extremadamente útil. Y nuevamente, la crítica que hago implícitamente en este capítulo es que este es un instrumento, esta teoría de la información, tan importante que no puede tratarse como un detalle cosmético. No es algo que simplemente se tenga por lujo. Es algo fundamental, y los profesionales de supply chain deberían al menos comprender lo que está en juego con esta teoría.
Conor Doherty: Bueno, esa es en realidad la transición perfecta a esta pregunta, porque nuevamente estaba releiendo el capítulo, como hago en preparación para estas discusiones. Estaba consciente de que esto podría volverse demasiado abstracto, ya que, de nuevo, datos versus información versus conocimiento pueden parecer bastante abstractos, y no quiero perder a la gente, ya que hay citas concretas y quiero leerlas para ustedes y luego plantearles una pregunta concreta para que se aclare un poco.
Entonces, solo para resumir con tus propias palabras, literalmente tus propias palabras: “Los datos son símbolos registrados. La información es la capacidad de esos símbolos para resolver la incertidumbre.” Como dijiste, “El conocimiento es la estructura causal que permite a una mente, humana o de machine,” y sé que prefieres machine, “transformar la información en decisiones que mejoren los rendimientos de la empresa.”
Luego añades, esa es la página 133: “Tratar los registros sin procesar, es decir, los datos, como si ya resolvieran la incertidumbre es la causa raíz de dashboards que nunca deciden y módulos de planificación que nunca planifican.” Entonces, mi pregunta es, ¿cómo puede un profesional saber en qué modo de pensamiento se encuentra? ¿Está simplemente jugando con datos? ¿Está jugando con conocimiento? ¿O está jugando con información? Porque, en tu opinión, solo el conocimiento marca la diferencia.
Joannes Vermorel: Sí. Entonces, aquí, ¿cómo evitas la confusión? Sí, es muy simple. No puedes cambiar el pasado. Bien.
Conor Doherty: Entonces, ¿qué significa eso?
Joannes Vermorel: Eso es literalmente… así que necesitas pensar, ¿estoy proyectando en mi mente algo en lo que el pasado es mutable? Si lo haces, estás en serios problemas, porque el pasado no puede ser cambiado. De nuevo, es algo evidente, pero muy frecuentemente lo que veo en supply chains son modelos mentales en los que el pasado es muy mutable.
Conor Doherty: Estás hablando de simplemente tomar los datos del pasado y tomar tus decisiones futuras basadas puramente en el…
Joannes Vermorel: El pasado es literalmente, conceptualmente, a nivel filosófico, algo que puede ser cambiado. Y ese es un problema. Ese es un problema, de nuevo, porque no puede ser cambiado.
Conor Doherty: ¿Estás diciendo que el pasado puede ser cambiado?
Joannes Vermorel: Así que, según la teoría convencional, sí. ¿De acuerdo? Y digo que es muy, muy extraño, y cuando lo piensas, es muy, muy incorrecto. ¿De acuerdo? Porque el pasado, obviamente, no puede ser cambiado.
Así que, de nuevo, el punto es que tienes algo… eso es una especie de razonamiento basado en primeros principios. Tomamos algo que damos por evidente. Necesito hacer suposiciones, así que no quiero hacer suposiciones masivas. Por lo tanto, necesito hacer mis suposiciones lo más pequeñas posibles.
Así que aquí solo estoy diciendo, primer principio: el pasado no puede ser cambiado. Eso es todo. Bien, estoy haciendo una suposición, pero no estoy haciendo una suposición extravagante.
Conor Doherty: Pero, ¿de qué manera actúan las personas como si pensaran que el pasado puede ser cambiado? Quizás esa es una mejor forma.
Joannes Vermorel: Porque la forma en que diseñan su software, el pasado es absolutamente mutable. ¿De acuerdo? El pasado, por ejemplo… de nuevo, cada ERP en el mercado, el pasado es mutable. Es por diseño, el diseño relacional. Así que si diseñas una app siguiendo el CRUD — crear, leer, actualizar, eliminar — es absolutamente mutable. El pasado puede ser cambiado. Conceptualmente, es un problema.
Conor Doherty: Y debido a que, para los profesionales…
Joannes Vermorel: Para los profesionales, sí. Porque eso significa, nuevamente, que tienes que pensar que si el pasado puede ser cambiado, entonces te diriges a problemas. Puedes pensar, “Oh, tal vez no,” pero yo diría que no, vas a tener problemas más adelante, porque lo que estás haciendo es algo que es tan brutalmente inconsistente con algo que es evidente, como que el pasado no puede ser cambiado.
Desde una perspectiva de supply chain, ¿qué significa eso? Significa, ¿tus ecuaciones tratan el pasado como inmutable, o tus ecuaciones mutan el pasado? Así que, si computas algo, vas a obtener números; tendrás muchos números como entrada y muchos números como salida. Pregunta: ¿tienes una frontera clara entre las entradas y las salidas?
Si las salidas… verás, si tienes los números que representan el pasado, como el historial transaccional sin procesar, y dices, “¿Sabes qué? Están congelados. No puedo tocarlos jamás porque ya ha ocurrido.”
Conor Doherty: Porque ha ocurrido.
Joannes Vermorel: Exactamente. Y por eso no puedo tocar esas cosas porque son del pasado. Son inmutables. Pero ahora imaginemos — y en software es muy fácil — que construyo lo que sea, algún tipo de lógica que tenga un bucle de retroalimentación que se dirija lógicamente hacia el pasado.
Conor Doherty: Eso va hacia el pasado. Bien. ¿Por qué haría eso? ¿Porque con qué propósito?
Joannes Vermorel: Primero, no necesita un propósito, porque el software es muy complejo, así que puedes hacer muchas cosas de forma accidental. Así que verás, si no haces cumplir un entorno limpio para decir, “Mi pasado es inmutable,” lo que obtendrás es un pasado mutable por… de nuevo, es simplemente una ley del software. El software es complejo. El hecho de que el pasado sea inmutable debe imponerse. Si no se impone, lo modificarás accidentalmente.
Así que ahora digamos un ejemplo práctico donde el pasado… porque de nuevo, el pasado es… Sé que esto es muy filosófico.
Conor Doherty: Lo sé, pero siento que esto es muy filosófico.
Joannes Vermorel: Pero el problema es que, de nuevo, los problemas de supply chain son cosas que están tan enormemente equivocadas que la gente no puede comprenderlas, porque la tontería ha estado ocurriendo por tanto tiempo que están perdidos.
Conor Doherty: Están perdidos, y por eso estamos aquí.
Joannes Vermorel: Entonces, ¿cómo mutas el pasado? Bueno, tienes un faltante de stock. Bien, tienes tus registros y dicen lo que vendiste. Bien. Así que vendí una unidad este día, tres unidades ese día, cuatro unidades en aquel lugar, y ceros para este día, este día, este día. Bien.
El problema es que los ceros que observé en el pasado, bueno, tuvimos un faltante de stock.
Conor Doherty: Así que el hecho de que hayas vendido cero es el pasado. Esa es la verdad. Vendiste ceros.
Joannes Vermorel: Sí.
Conor Doherty: Bien. No creo que nadie dispute esto hasta ahora. ¿Cómo haces que el pasado sea mutable?
Joannes Vermorel: Ahora tienes un problema porque tu algoritmo de time series forecasting, el forecasting de series de tiempo que utilizas, no se comporta correctamente. Se comporta mal cuando le alimentas con ceros como entradas porque, de hecho, tienes un desajuste de impedancia entre el pasado, la semántica de lo que se observó en el pasado, y la semántica del pasado en el futuro.
El pasado, lo que tienes son las ventas observadas.
Conor Doherty: Sí.
Joannes Vermorel: Así que esta es la semántica de lo que has observado y registrado en el pasado. La semántica es la de las ventas observadas. Pero para el futuro, esa no es la semántica que te interesa. La semántica que te interesa es la demanda futura. Esa es la perspectiva de la teoría convencional de supply chain.
Bien, entonces el problema es que si extrapolo mis ventas pasadas al estilo de forecasting de series de tiempo, esos ceros van a crear un sesgo masivo a la baja.
Así que, de alguna manera… lo siento, lo sé, pero es muy simple. De nuevo, si observas montones de ceros, tu modelo, que es una variante de un promedio móvil de algún tipo — es solo un promedio móvil glorificado con algunas ciclicidades adicionales, pero es un promedio móvil glorificado — así que tu forecast, tu modelo de forecasting de series de tiempo, un promedio móvil glorificado, tomará esos ceros y subestimará la demanda porque tomará tus ceros de unidades vendidas, pero eso fue debido al faltante de stock, como entradas.
Ese es el problema al que se enfrentan las personas. ¿Y cómo resuelves eso de una manera muy equivocada? Porque olvidaste que tenías la invariante de “el pasado es inmutable”, ya sabes. Entonces, ¿cómo puedes resolver eso de una manera profundamente equivocada? Haces que el pasado sea mutable.
¿Qué haces? Reescribes las unidades que vendiste para tener algo que sería la demanda plausible para ese día. Así que modificaste tus datos pasados, y reemplazas tus ceros, que fueron lo que efectivamente observaste, por una demanda plausible para el día. Lo que has hecho es que has cambiado el pasado. ¿De acuerdo? Y es muy inconsistente.
¿Y adivina qué? Terminarás en un mundo de dolor, porque lo que has hecho es tan lógicamente incorrecto que no puede ser de otra forma. Esto desembocará en todo tipo de problemas.
Conor Doherty: Y de nuevo, la gente podría pensar… Te dejaré terminar el punto, pero hay un detalle clave que creo que debes desglosar, que es que has descrito el mecanismo de estar equivocado, pero no has explicado el dolor de estar equivocado. Entonces, has dicho que es lógicamente incorrecto. Ese es el mecanismo. ¿Qué sientes como consecuencia de estar equivocado? Esa es la consecuencia.
Joannes Vermorel: La consecuencia son tus asignaciones. Volvemos a los problemas económicos. Tus asignaciones estarán totalmente desajustadas. Eso significa que efectivamente malasignarás tu capital, y por lo tanto tendrás una tasa de retorno mucho menor de la que deberías tener.
Verás, lo que pasa es que cualquier asignación, buena o mala, te da una tasa de retorno. Y si tienes suerte y estás en un sector muy agradable, incluso las malas asignaciones a veces pueden generar una tasa de retorno positiva. Pero, de nuevo, el objetivo es tener la tasa de retorno máxima.
Así que, fundamentalmente, el dolor será la disminución de las tasas de retorno para todas las asignaciones.
Conor Doherty: Menos dinero, esencialmente.
Joannes Vermorel: Sí. Menos dinero. Sí. Y eso siempre es un problema. Si gestionas tu empresa de manera inadecuada, la sanción es que sea menos rentable. Sí. Eso es todo.
Y aquí debes entender que este invariante — no deberías modificar el pasado — es extremadamente importante, y no puedes jugar con este invariante porque es tan lógicamente inconsistente que, sin importar cuán inteligente creas ser, tendrá muy malas consecuencias para tu supply chain. No puedes desafiar este tipo de principio.
De nuevo, es como si interpretaras la causalidad de la manera equivocada para un asunto empresarial. Si piensas que A causa B, pero en realidad la realidad es que B causa A, si interpretas mal la situación de esa manera, causará daños económicos. Es una especie de profundo malentendido que resonará y creará todo tipo de problemas en el camino porque, fundamentalmente, estás haciendo algo tan incorrecto que, sí, tendrá consecuencias negativas.
Y esas consecuencias negativas serán increíblemente variadas. Estarán increíblemente dispersas. Y dado que es supply chain, es complejo, etcétera, estarán por todas partes, y luego te resultará muy difícil diagnosticar cuál es la causa raíz.
Te digo, puedes volver a la causa raíz. La causa raíz es que no puedes hacer que el pasado sea mutable con impunidad. Es tan simple como eso. Y cuando digo impunidad, no lo pienses como un juicio moral. Es un juicio económico. Esta impunidad se pagará en dólares.
Conor Doherty: Bien. Voy a avanzar un poco en este punto porque hay al menos otros dos pilares fundamentales en el capítulo, pero entre ellos hay otro tema sobre los datos.
En el capítulo hablas de… Así que mencionaste anteriormente que los datos son solo símbolos registrados. Representan algo, los interpretas como desees. Ahora, refutas la idea de que a menudo se utiliza a los datos como chivo expiatorio de las pérdidas financieras y programas fallidos. Afirmas que — y lo has dicho públicamente, de hecho, hemos hecho eventos en vivo antes donde dijiste, “Tus datos no son malos. Si tienes datos transaccionales, básicamente dependiendo del software que tengas, estás listo para comenzar.”
Así que este es, de nuevo, otro ejemplo de cómo tu perspectiva y, digamos, la perspectiva dominante estarán en desacuerdo, porque tú y yo hemos escuchado, no sé, digamos entre cien y mil veces — ese es el orden de magnitud — “Mis datos maestros no son lo suficientemente buenos para iniciar un nuevo proyecto”, lo que sea. Claramente, no estás de acuerdo con esa idea. ¿Por qué?
Joannes Vermorel: Entonces, si volvemos al hecho de que el pasado no debería ser mutable, sí… pero la realidad es que la forma en que se practica la supply chain, en la práctica — y de nuevo, se ha practicado con software durante las últimas tres décadas, así que no conozco ninguna supply chain de ninguna escala que no tenga software por todas partes. El software está en todas partes.
Pero si no tienes un límite muy claro entre lo que representa el pasado y lo que especula sobre el futuro, va a ser un desastre masivo. De nuevo, el software es complicado, el software es complejo, la supply chain es complicada, y la supply chain es compleja. Así que la complejidad está en todos los niveles.
Así que, si no haces cumplir… debes hacer cumplir este invariante de que tienes una clase de software que se encarga del pasado, y que se llamará systems of record. Y luego tienes una clase de software que se encarga del futuro, y que se llamará systems of intelligence.
Si no segregas esos dos, y mantienes esta segregación, ¿adivina qué? Vas a tener una mezcla desordenada que estará tan confundida que ya nadie entenderá lo que está pasando. Y así, en última instancia, culparás a los datos, porque dirías, “Oh, obviamente tuvimos tantos problemas, debe haber sido por bad data.”
Y bad data es un chivo expiatorio muy conveniente porque, al no ser una persona, no culpas a nadie. Es como si, cuando la gente culpa a los datos, estuviera culpando al universo. Y verás, está bien.
Si retrocedes a la antigüedad, eso sería como aquellas tribus primitivas que culpaban a algún tipo de dioses por sus problemas. Obviamente, somos demasiado modernos para culpar a un dios, así que no vamos a culpar a un dios. Simplemente vamos a culpar a un constructo moderno para que se sienta mucho más moderno. Así que vamos a culpar a los datos, en lugar de culpar al dios de la supply chain. Pero, desde una perspectiva racional, esto es exactamente lo mismo. Cuando la gente dice, “Oh, mis datos son un problema,” lo que yo escucho es, “Estoy culpando al dios de la supply chain,” o al dios de IT, algo así.
Conor Doherty: Bueno, para ser justos — y ahora recurriré a mis conocimientos previos, porque sé que tu posición es un poco más benévola de lo que eso suena. Eso suena muy absoluto.
Joannes Vermorel: No, no, pero…
Conor Doherty: Solo para ser justos, insisto en el punto.
Joannes Vermorel: Sí, estás insistiendo en el punto.
Conor Doherty: Pero, para ser justos, has dicho anteriormente — y te estoy parafraseando — que, en efecto, los datos no son malos. Y tu punto es que, mira, los datos transaccionales son lo que son.
Joannes Vermorel: Sí.
Conor Doherty: Pero has señalado que puede ser complicado porque existen semánticas. Y no creo que lo menciones en este libro. Creo, si no me equivoco, que en realidad está en tu primer libro, el Supply Chain Quantitativa Manifesto, el gran libro rojo.
Joannes Vermorel: Sí. Sí.
Conor Doherty: Y diste el ejemplo — es uno de mis ejemplos favoritos, y te lo he planteado antes — como, ¿qué significa ventas en un día? Si abres un libro contable, ¿son esas las ventas que ocurrieron el lunes? ¿O es cuando expiró el período de garantía de las ventas de hace dos semanas? Hay como 10 o 12 o 15 o mil formas de segmentar las unidades de ventas por día.
Joannes Vermorel: Sí. Y eso es… ves, para entenderlo, es que los datos sobre el pasado son inmutables. Piénsalo como los documentos de un historiador. Los documentos son simplemente los documentos.
Así que cuando un historiador trabaja, los documentos son inmutables. Si hubo, por ejemplo, un tratado firmado entre dos países en una fecha determinada, este tratado está perfectamente registrado. Este tratado no cambia.
Conor Doherty: Sí.
Joannes Vermorel: Pero pueden haber tantas sutilezas que se pierden al tratar de entender realmente lo que ocurrió. Así que el trabajo del historiador es, en efecto, revisar esos hechos, esos registros y construir una nueva interpretación de lo sucedido.
Conor Doherty: Me gusta esta metáfora.
Joannes Vermorel: Ves, lo que estoy diciendo es que el trabajo de un historiador es extremadamente difícil. Sí. Porque, de hecho, los registros son inequívocos, pero las interpretaciones que podemos dar a esos registros son infinitas. Y lo mismo ocurre con el software.
Entonces, tu software — supongamos por el momento que tu software está diseñado adecuadamente, aunque en la práctica usualmente no lo está — y que en realidad es un software que se preocupa por hacer el pasado inmutable. Bien. Así que ahora tienes un software limpio donde el pasado es inmutable. Tienes registros limpios que no se mueven constantemente bajo tus pies. Eso es bueno.
Pero no estoy diciendo que entender esos registros sea fácil. Comprender esos registros puede ser extremadamente complicado. Y por eso no quieres empeorar la situación teniendo algún tipo de bucles de retroalimentación que reinjecten cosas en tu pasado.
Solo piensa en ello como en un historiador que trabaja con documentos históricos, pero imagina que tiene una biblioteca que dice, “Oh, aquí está mi colección de documentos sobre lo que sucedió en Francia en el siglo XVII, y esa es la lista de documentos que tengo, ahí están, las referencias, según mi entendimiento.”
Y ahora imagina que en esta biblioteca hay personas que insertan falsificaciones todo el tiempo. Así que insertan documentos falsos del siglo XVII en esta biblioteca constantemente. Entonces el historiador estaría completamente perdido. Diría, “Ahora tenía un problema, que ya era muy difícil, que era entender ese período, y ahora tengo otro problema, que es deshacerme de todas las falsificaciones que fueron creadas después del período que me interesa.”
Ves, eso sería una pesadilla. Así que, obviamente, los historiadores son extremadamente, extremadamente precisos para asegurarse de que todos los documentos que tienen sean realmente del período correcto y no falsificaciones creadas posteriormente.
Y eso es lo que estoy diciendo. Por eso, lo que estoy planteando es que debemos hacer el pasado inmutable. Pero hacer el pasado inmutable, que es el primer paso, ese system of record, no hace que el pasado sea fácil de aprehender. Sigue siendo extremadamente difícil.
Conor Doherty: Por eso hablas de que se necesitan especialistas, supply chain specialists, que puedan analizar la semántica.
Joannes Vermorel: Exacto. Y es difícil, pero no porque esas observaciones sean basura. No han sido contaminadas con falsificaciones hechas después de los hechos. Simplemente tienen una dificultad intrínseca, que es lo difícil que resulta interpretarlas. Cuando digo “las ventas pasadas,” es una afirmación muy ambigua. Es una afirmación muy ambigua.
Y es ahí, en última instancia, donde entra en juego el conocimiento. El conocimiento es ser capaz de resolver esa ambigüedad para que puedas convertir esta información en algo accionable. Necesitas resolver todas esas incertidumbres — o más bien, todas esas ambigüedades, diría, no incertidumbres, ambigüedades.
Conor Doherty: De acuerdo. Bueno, creo que es hora de abordar lo que diría es el pilar central del capítulo, y ciertamente algo que resuena incluso más allá del libro mismo porque está dirigido a los profesionales. Pero esto entra en el concepto completo de dónde asigna una empresa su dinero. Y eso es, sí, systems of record, systems of report, y systems of intelligence.
Entonces, systems of record: tu ERP, lo que sea, el historiador de la empresa, para usar tu propia analogía, lo que pasó, eso es del pasado.
Joannes Vermorel: No es el historiador. El system of record es literalmente el oficinista, el oficinista, el oficinista. Es simplemente el que escribe.
Conor Doherty: La versión digital.
Joannes Vermorel: Exacto, la versión digital del oficinista, alguien que simplemente se encarga de mantener los registros. No está intentando tener ninguna inteligencia. Solo está registrando tal como es — lo bueno, lo malo, los errores y la grandeza — todo tal como es. Eso es todo.
Conor Doherty: De acuerdo. Los systems of report, es decir, las herramientas de business intelligence, son representaciones de eso.
Joannes Vermorel: Así que los systems of report se usan para algo muy diferente. Se utilizan para el cumplimiento. Sí. Ves, ¿qué significa eso? Que vas a decir que tenemos procesos, tenemos reglas, tenemos mejores prácticas, y la gerencia solo necesita un instrumento para hacer cumplir eso.
Así que los systems of report no se tratan de adquirir inteligencia, de entender el futuro, o algo por el estilo. Esencialmente, son un instrumento para que una gran empresa mantenga el cumplimiento de sus propios procesos. Y eso es todo.
Conor Doherty: Ellos quieren una visión, quieren una visualización de lo que está sucediendo.
Joannes Vermorel: Eso es lo que dicen los proveedores que venden business intelligence. En la práctica, nunca he visto que se usen esas herramientas de esa manera. Solamente se utilizan… Realmente, nadie obtiene una visión profunda. Quiero decir, sí, ocasionalmente, muy ocasionalmente, alguien tendrá una intuición al mirar un reporte de business intelligence, pero ese no es el propósito de esa marca, de esa categoría de tecnología. Es tan infrecuente.
Para mí, es nuevamente una analogía débil, pero es tan infrecuente que resulta muy, muy secundaria. Sería como decir que el alcohol es algo que se puede usar para hacer descubrimientos científicos. Sí, ocasionalmente habrá un científico que beba mucho alcohol, y en ese estado mental alterado hará un descubrimiento. Pero decir que el alcohol es un instrumento de la ciencia es un poco exagerado.
Conor Doherty: Ahora estás haciendo un argumento teleológico. Y, en realidad, permíteme establecer un poco más el contexto, porque creo que entonces podemos llevar la idea a un plano un poco más universal.
Así que, de nuevo, has explicado en detalle los systems of record — que es el oficinista, son simplemente los registros de lo que sucedió. Tus systems of report, que son herramientas de visualización como business intelligence, no están destinados a la toma de decisiones. Lo que has expuesto es que, en la práctica, las empresas que operan supply chains son extremadamente grandes, complejas, y por lo tanto, mantenerse coherentes con sus propios procesos proclamados es muy difícil. Así que los systems of report son muy buenos para permitir que los gerentes verifiquen si sus subordinados se están adhiriendo a lo que en la empresa significa cumplimiento.
Bueno, en realidad has dicho… mi propio micrófono está en el camino. Espera un segundo. “Most corporate disappointments come from conflating these different systems, expecting ledgers to think or analytics layers to serve as sources of truth.”
Ahora eso establece la categoría sobre la que aún no te has extendido, que es la de los systems of intelligence. Y yo, nuevamente, habiendo leído el capítulo, me doy cuenta de que es ahí donde crees que realmente residen las decisiones y un mejor desempeño. Así que, por favor, explica, diría de manera algo concisa, qué es un system of intelligence y, fundamentalmente, por qué no se deben tratar las otras dos clases de sistemas como si fuesen un system of intelligence.
Joannes Vermorel: Así que, eso es fundamental, por cierto. Ese es un punto clave.
Entonces, el primero, el system of record, es el pasado. Es un registro del pasado. Es lo mejor que tienes sobre el pasado. Ahora, el system of report también es acerca del pasado. Simplemente te indica si fuiste conforme en el pasado con tus propios procesos. Así que es, en gran medida, retrospectivo.
Así que, ves, este system of report simplemente te cuenta una historia sobre el pasado. Es una manera de construir una narrativa sobre el pasado, si quieres. No es muy elaborado. Es, de nuevo, como la historia económica, ¿dónde la gente francesa era más rica o más pobre hace un siglo? Eso es precisamente lo que te daría el system of report. En lugar de tener millones de registros sobre los estados de resultados de los franceses, tendrías estadísticas agregadas. Eso es lo que tienes.
Conor Doherty: Sin embargo, ya hemos cubierto estos dos. Así que pasemos a la inteligencia.
Joannes Vermorel: Y el tercero, es algo muy, muy diferente. Es el único que en realidad mira hacia el futuro.
Conor Doherty: De acuerdo. ¿Y de qué maneras?
Joannes Vermorel: Por diseño mira hacia el futuro. Es por diseño, porque lo que intenta lograr es generar decisiones. Así que esta decisión siempre es prospectiva. Decides algo porque crees que tendrás algún tipo de retorno de inversión. Por eso tomas esa decisión.
Y he aclarado que, en el caso específico de la supply chain, una decisión es una asignación de recursos. Entonces, una asignación de recursos: esencialmente, asignas un recurso porque esperas algún tipo de retorno de inversión en algún momento. Y tu system of intelligence es simplemente una máquina para generar esas asignaciones para ti. Eso es todo.
Conor Doherty: No quiero interrumpirte, pero aun así, solo para subrayar el punto, incluso si tomas tus decisiones basadas en cosas que has criticado en el pasado, como “quiero mantener altos niveles de servicio,” aun si ese es el caso y esa es tu estrella guía, es todavía porque quieres un retorno de inversión deseable.
Joannes Vermorel: Absolutamente. Ese es el objetivo global, sí. Y, de nuevo, puedes tener systems of intelligence diseñados adecuadamente o systems of intelligence mal diseñados. La única diferencia será la tasa de retorno que obtengas de tus decisiones.
Pero primero, ves, no puedes pasar por alto el hecho de que existe un sistema de decisiones. ¿Por qué? Porque los recursos se asignan. Eso es todo. Los recursos se asignan. Así que se está tomando una decisión. No puedes evadir eso. Los recursos serán asignados.
Como empresa, estás gastando tus dólares todo el tiempo para comprar materias primas, para comprar inventarios que repones. Estás asignando tareas a tus propios empleados para hacer algo. Eso es una asignación de recursos. Esas cosas suceden todo el tiempo. No se pueden evadir.
Y lo que estoy diciendo es que hace un siglo teníamos una situación muy clara. Los sistemas de inteligencia eran exclusivamente humanos. Así que los registros ya eran en parte máquina, porque los registros, incluso hace un siglo, se escribían en libros.
Conor Doherty: De alguna manera, el almacenamiento ya era algo inhumano. No estaba en la mente de una persona.
Joannes Vermorel: No llevaban esta información en sus cabezas. Ya la transportaban a través de dispositivos. Obviamente, no eran sofisticados, pero eran dispositivos, y ya podían almacenar, a través de libros, bastante información. Así que ya teníamos, para los registros, esencialmente artefactos. Las computadoras son artefactos mejores, pero ya teníamos artefactos.
Cuando se trataba de decisiones, era puramente humano. Puramente humano. Pero ahora, durante las últimas tres décadas, lo que tenemos es una mezcla. Nadie tiene ya una capa de decisión puramente humana. No existe. No existe.
Incluso cuando la gente dice, “Oh, lo hacemos todo manualmente.”
Conor Doherty: ¿Lo hacen?
Joannes Vermorel: Oh sí. “Todo se hace manualmente. Simplemente estamos usando Excel.”
Yo digo, “Oh, está bien.” Entonces, ya sabes, Excel es software. Excel es software. Excel es como una extensión de tu mente para hacer toneladas de aritmética básica. Así que ya tenemos una especie de sistema híbrido que es mente humana más máquinas. En cuanto tienes una hoja de cálculo de Excel, es un sistema híbrido. Es software más mente humana, ambos.
Y con el tiempo, lo que estoy diciendo, lo que he visto, es que la parte de software simplemente ha crecido cada vez más. E incluso si no fueran nada más que hojas de cálculo de Excel, porque adivina qué, Excel no es en sí mismo un objetivo móvil. Excel, si retrocedemos 20 años, tenía máximo 65,000 líneas. Ahora tiene un millón de líneas.
Así, Excel, en los últimos 20 años, se expandió en capacidades, y ahora incluso puedes tener scripts en Python en tu hoja de cálculo de Excel. Entonces, Excel mismo se volvió más poderoso. Y hay muchas cosas que se han vuelto más poderosas, porque por ejemplo, la gente dice, “Solo estoy usando Excel.” Pero, ¿realmente están usando solo Excel? No. También están utilizando las capacidades de sus sistemas de registro y de reporte para generar extractos que se usan como insumos para sus hojas de cálculo.
Así, efectivamente, no es solo Excel puro. Es una mezcla del panorama aplicativo que está generando insumos que estás incorporando, et cetera, et cetera. Y lo que estoy diciendo es que, en general, año tras año, la porción que se delega a la máquina crece cada vez más. Eso es lo que estoy diciendo, y por lo tanto, debemos poner eso bajo control.
Conor Doherty: Sí. También has, de nuevo en el capítulo, planteado el argumento de que la verdadera rentabilidad escalable se encuentra invirtiendo más en sistemas de inteligencia en lugar de en sistemas de registro.
Ahora, previamente discutimos en otros episodios que el gasto tiende a ser muy asimétrico. Así, por ejemplo, la mayoría del gasto podría estar en sistemas de registro, a pesar de que argumentas que no generan decisiones. Como, tengo al contador o libro mayor más sofisticado que exista. Eso no te conduce a una mejor decisión. Entonces, ¿por qué es el gasto tan asimétrico?
Joannes Vermorel: Porque, de nuevo, el software es algo grande y complicado, y la gente trata al software como si fuera una especie de magia vudú que ocurre dentro de las oficinas de los proveedores. Esto no es… el software es, sin duda, algo básico. Ciertamente no es magia vudú.
Conor Doherty: Lo retratan algunos proveedores.
Joannes Vermorel: Sí. Porque para los proveedores, dicen, “Tengo una receta secreta. Tengo un ingrediente mágico que no puedes replicar,” o algo por el estilo. Y eso es, esencialmente, palabrería para promocionar tus productos. Pero no es racional.
Ahora, volviendo al software, lo que estoy diciendo es que si mantienes tu entorno muy limpio, como tener una clase de software que solo se ocupa del pasado — es decir, un sistema de registro —, si mantienes, impones esta invariabilidad, entonces de repente te das cuenta: “Oh, esta pieza de software que solo trata con el pasado es simplemente una versión glorificada de mis libros contables.” No hay nada en ella. Es solo una larga serie de registros.
Y, ¿adivina qué? Los discos duros son baratos. Así que puedo tener mis miles de millones de registros y será barato. Entonces, ¿debo pagar una fortuna por eso? No. Es simple. Por lo tanto, debe ser barato.
¿Crees que, como proveedor de software, quieres que tu cliente se dé cuenta de que lo que tienes en tus manos es algo que debería ser super barato? No. Así que vas a mistificar al cliente. Vas a mistificar al cliente, y vas a crear toda una capa de confusión para que la gente se pierda y no se dé cuenta de que en el núcleo lo que tienes es algo extremadamente simple.
Un sistema de registro es extremadamente simple. Es solo un libro mayor glorificado. Nada más, nada menos, nada más. Es súper sencillo.
Conor Doherty: Las empresas — no las personas — gastarán medio billón en un sistema de registro.
Joannes Vermorel: Sí. ¿Y por qué? Porque los proveedores de software empresarial son extremadamente buenos para hacer que sus productos sean deseables. Así que crearán una enorme cantidad de confusión para que la gente piense, “Oh, este software, es mucho más.”
Y yo digo que no. Lo que estás comprando es una ilusión. No es más. Si compras un ERP, estás comprando un sistema de registro, y por lo tanto, esto debería ser muy barato, esbelto, y eso es todo. Y si te enfrentas a un proveedor de software que empieza a mistificarte explicando, “Oh no, no, no, mi ERP lo hace todo, tiene IA, tiene esto y aquello, et cetera,” te están mistificando. Ese es mi mensaje. Te están mistificando.
Es como si un contador te dijera, “Soy un contador rockstar. Hago magia. La ganancia viene de cómo cuento los números. Tú obtienes más ganancia.”
Conor Doherty: En realidad, solo detente un momento para nosotros. Imagina eso. Esa es, de hecho, una línea mejor. Un contador que te diría, “Gracias a mi excelente contabilidad, puedo generar tanto dinero para ti. Vamos a crear dinero de la nada.”
Joannes Vermorel: Suena a fraude.
Conor Doherty: Suena a fraude.
Joannes Vermorel: Quiero decir, se supone que un contador no debe ser capaz de crear dinero de la nada. Los contadores que son capaces de hacerlo, usualmente hacen cosas al estilo Enron. Trabajan para los sindicatos, o Enron. Tenían artimañas contables que eran extremadamente creativas. Se lo reconozco. Enron tenía una contabilidad extremadamente, extremadamente creativa.
Conor Doherty: Admiro el atrevimiento.
Joannes Vermorel: Sí. Eran como pioneros de técnicas contables de vanguardia, y realmente no es bueno. Realmente, realmente no es bueno.
Así que, de nuevo, no quieres que tu libro mayor sea el lugar donde haya innovación. Este es el marco intelectual equivocado. No deseas un contador inventivo. No deseas un contador creativo. Quieres un contador diligente. Quieres un contador fiable, y quieres un contador eficiente en costos. Eso es lo que deseas.
Y, por cierto, todas esas cualidades se trasladan a tu sistema de registro. Son exactamente las mismas.
Conor Doherty: Exacto. Así que este es, de nuevo, un punto clave. Lo tocas en el libro. Sé que también has hablado de ello en otros videos. No necesitamos adentrarnos en la arquitectura de software pesada — ya llevamos casi una hora — pero lo que acabas de decir, que quieres que tus registros sean diligentes, quieres que sean ágiles…
Nuevamente, diferencia clave aquí: solo para comparar estos dos, porque creo que son las dos clases más confundidas en esta designación, tienes sistemas de registro y tienes sistemas de inteligencia. En el libro describes las decisiones como decisiones laboriosas, porque tomar una buena decisión requiere tiempo. Ahora, la arquitectura de software requerida para soportar eso es lo opuesto a la arquitectura de software para hacer un registro preciso y rápido.
Así que, de nuevo, para ser muy concreto, estás en un almacén, o en una tienda, y estás vendiendo cosas. Quieres saber cuántas unidades hay. Quieres saber cuántas unidades hay en el almacén. Quieres saberlo con la mayor precisión y rapidez posible.
Joannes Vermorel: Sí.
Conor Doherty: Ahora, para eso es un sistema de registro. Conoces mejor el diseño, pero ya has hecho la analogía, la analogía deportiva, en la que básicamente puedes ser muy, muy rápido corriendo como un maratonista, el mejor del mundo, o puedes ser un campeón de powerlifting. Es muy difícil hacer ambas cosas, porque cuanto mejor eres en una, se pierde en la otra. Así que, por favor, expande sobre eso con mejores palabras de las que acabo de usar.
Joannes Vermorel: Así que, de nuevo, la analogía del contador es… ¿cuántos rockstars están en su tiempo libre como contadores? Ninguno. Ninguno. Porque si tienes el temperamento para ser un buen contador, no tienes el temperamento para ser un rockstar. Y viceversa.
Nunca confiarías tus cuentas a alguien que toma drogas, que hace cosas salvajes.
Conor Doherty: Entonces, las decisiones son rockstars en esta analogía.
Joannes Vermorel: Las decisiones son, sí, un poco. Un poco, porque son innovadoras, son creativas. Fundamentalmente, lo que estás tratando de hacer es alcanzar la grandeza.
Conor Doherty: Ahí lo tienes.
Joannes Vermorel: Y la contabilidad no está ahí para alcanzar la grandeza, porque la grandeza, precisión en la contabilidad significa Enron. No quieres grandeza. No quieres innovación en precisión. Quieres algo que sea siempre igual, fiable, aburrido.
Conor Doherty: Aburrido.
Joannes Vermorel: Sí. Ahí lo tienes. Sí. Aburrido es una cualidad increíble para un contador. Incluso diría que, si tu contador es un tipo muy interesante, tal vez no confiarías en ese contador. De nuevo, es cuestión de personalidad. El gran contador es alguien tan fiable que resulta aburrido. Eso es lo que esperas de un contador.
Y de un rockstar, este tipo puede ser completamente inestable. Pero, ¿adivina qué? A veces tiene un momento de genialidad, y boom, grandeza. Esa es una gran decisión. Ese es el tipo de cosas que esperas a nivel de decisión.
Porque, de nuevo, el futuro es incierto, así que siempre será una apuesta. Por eso digo que, a nivel de decisión, siempre estás especulando. No hay otra forma. No conoces el futuro. Por lo tanto, hay un elemento de riesgo. Y por eso puedes tener un elemento de grandeza, que si eres muy, muy bueno en la forma en que ves el futuro, entonces puedes lograr algo increíble, que es una tasa de retorno muy, muy alta.
Conor Doherty: Sin duda, me gusta el elemento del contador en esa analogía. Solo quiero proponerte algo, y tú me dices cómo te sientes al respecto.
Utilizando la analogía musical, como yo lo percibí fue: el contador es tu sistema de registro. Queremos que sea algo mundano, fiable, confiable. El sistema de inteligencia es como Bach o Mozart. Ellos compondrán. Será laborioso. Es intensivo. Es creativo. Es enigmático. Una asignación o reabastecimiento realmente bueno es como si estuviera tomando símbolos de todas partes. Toma tiempo. Requiere esfuerzo. El sistema vuelve a calcular y calcula. Y al final, tienes Für Elise. Tienes una de las mayores obras musicales de todos los tiempos.
El rockstar puede hacer que suene caótico, pero para mí la percepción fue como la música clásica. Es precisa. Hay ciencia en ello. Los compases, quieres que todo encaje dentro de parámetros.
Joannes Vermorel: Pero también, si tienes verdadera grandeza en la música clásica, que es de hecho una analogía mejor, no puedes imponer límites. El genio, incluso si está extremadamente codificado y es estricto, nunca se encuentra dentro de los límites, porque el verdadero genio está redefiniendo lo que la música debería ser. Redefiniendo los límites, empujando esos límites no de forma aleatoria, sino con un propósito.
Y eso es en cierto modo lo opuesto al contador, que no se supone que debe empujar los límites. El contador, un buen contador, es por definición… de nuevo, no deseas ninguna situación… sí, debe ser aburrido. Debe estar restringido.
Si se trata de decisiones, sí, es Mozart. Tienes que empujar los límites de lo que la música puede ser. Sí. Y así es como se alcanza esa verdadera grandeza. Y sí, la analogía realmente funciona en este punto.
Conor Doherty: Bien. Bueno, de nuevo, volvemos a… ¿por qué hay, en general en la industria, una aparentemente sistemática — perdona el juego de palabras — subvaloración sistemática de la música clásica, es decir, de los sistemas de inteligencia?
Joannes Vermorel: Así que ahora necesitamos echar un vistazo a los incentivos de los proveedores de software. Entonces, ¿cuál es tu incentivo? Quieres vender al precio más alto posible aquello que te cuesta lo menos producir. Eso es… Soy un proveedor de software. Necesito ganar dinero. Así que tengo el dinero que gano, ese es el precio que la gente paga, y lo que me cuesta es el precio que pago como proveedor de software para tener el software producido.
Hasta ahora, la industria del software es como la producción. Básicamente, quieres comprar barato y vender caro.
Conor Doherty: Eso es.
Joannes Vermorel: Eso es. Ahora, un sistema de registro, como dije, es muy simple y, por lo tanto, muy barato de producir. Genial para mí como proveedor de software. Genial. ¿Por qué? Barato. Bajo costo de producción. Excelente.
Ahora, el problema es… la disposición del cliente no es tan buena. Verás, sí, mis costos son bajos, pero la disposición de los clientes a pagar también es baja. No es un lugar tan grandioso.
Pero imagina que, si mistifico al cliente acerca de exactamente lo que hace mi software, puedo inflar enormemente su disposición a pagar. Habrá un problema, y es que si quiero hacer ese truco de magia, necesitaré magos para ello, porque es como un truco de magia. Así que necesitaré tener a esos magos. ¿Quiénes serán esos magos? Ese será el tipo de los proveedores de software empresarial.
¿Y adivina qué? Esos proveedores de software empresarial, si miras su fuerza laboral, hasta dos tercios de sus empleados son en realidad vendedores. Son vendedores. Entonces, el costo de un proveedor de software empresarial… en el proveedor típico de software empresarial, dos tercios, no estás pagando por el software que se está produciendo. Estás pagando por la estructura de costos de vender el software.
Así que, esencialmente, le estás pagando a un proveedor por los magos que tienen, que están creando la ilusión de que el software es mucho más de lo que realmente es, y así están inflando tu disposición a pagar. Dirías, “Es tan simple,” pero ¿adivina qué? Es simple, y funciona.
Así que toneladas de proveedores de software empresarial están haciendo exactamente eso. Tomas una pieza de software que es barata de producir. Luego, además, contratas a personas que son vendedores empresariales, y esas personas harán el voodoo. Esa es su competencia profesional. Inflarán la disposición a pagar de los clientes. Y al final, lo que tienes son empresas que están pagando precios extravagantes basados en expectativas extravagantes que se van a decepcionar cada vez, porque en última instancia lo que están comprando es algo que nunca podrá cumplir su promesa. Eso es todo.
Y esta historia, desafortunadamente, se ha repetido una y otra vez durante las últimas cuatro décadas.
Conor Doherty: Seamos honestos, llevamos una hora, y creo que ya es hora de que haga la pregunta final. Pero se basa no solo en lo que hemos discutido hoy, sino, honestamente, en los cuatro capítulos anteriores, que es, y creo que probablemente es una de las preguntas más trascendentales, nuevamente no solo para los practicantes, sino para las empresas en las que trabajan.
Has delineado sistemas de registro, sistemas de reporte, sistemas de inteligencia, las funciones de cada uno, dónde reside el valor en cada uno. Bien. ¿Cómo pueden los practicantes que quizás no tengan tu nivel de experiencia en el diseño y la arquitectura de software, y demás, saber mañana, si entran en una conversación con un proveedor para comprar un ERP, un sistema de registro, “¿Estoy a punto de ser estafado aquí? ¿Me están vendiendo snake oil?”
Joannes Vermorel: Necesitas hacer la pregunta básica: “¿Tu software está mutando el pasado?” Sé que es una pregunta extraña.
Conor Doherty: Porque quieres que se la hagan al proveedor.
Joannes Vermorel: Sí. Sí, simplemente haz la pregunta: “¿Mutas el pasado?” Eso es todo. Es una pregunta muy simple. “¿Mutas el pasado?”
Y donde se conecta con la información es que, cuando finalmente entendamos cómo funciona la información, etcétera, etcétera, lo que estás haciendo es plantear una pregunta simple que funciona como prueba de fuego para determinar si el software está haciendo cumplir una invariante fundamental o no.
Si el tipo, si el proveedor, se desconcierta con la pregunta, entonces es una respuesta terrible, porque significa que el proveedor no tiene ni idea de lo que está haciendo. Si el proveedor no tiene ni idea de lo que está haciendo, probablemente no deberías comprarlo.
Conor Doherty: No deberías comprarlo.
Joannes Vermorel: No deberías comprarlo. Imagínate, nuevamente, sé que el software es tan abstracto que la gente tiende a perder la cabeza, pero volvamos a una pregunta sobre un coche. Si le haces una pregunta a un automóvil, sería: “¿Es seguro este coche?” Y si el proveedor dijera, “¿Qué quieres decir con seguro? No entiendo tu pregunta,” entonces dirías, “Supongo que tomaré otro coche. Preferiría comprar un coche de personas que te digan: ‘Oh sí, nuestro coche es muy seguro. Tiene cinturones de seguridad. Tiene airbags. Tiene un diseño en el que, si chocas con algo, el motor pasará por debajo de ti en vez de aplastar tus piernas.’”
Esa es una buena respuesta. Ese es el proveedor que deseas. El proveedor que deseas es aquel que dice: “Oh, mutabilidad del pasado. Oh sí, esa es una preocupación tan importante. Le hemos prestado mucha atención.”
Es algo simple. Es que, si estás comprando un coche y preguntas, “¿Es seguro?” y el proveedor te responde, “¿Es seguro? Nunca lo he pensado realmente.” Eso simplemente no es una buena respuesta. Debería ser una respuesta terriblemente mala.
Y lo que estoy diciendo es, nuevamente, que el software es más fácil y simple de lo que crees. Simplemente deberías preguntarle a tu software: “¿Me estás vendiendo un software que trata con el pasado o con el futuro?” Si trata con el pasado, ¿lo haces de una manera limpia, de modo que no mutes el pasado? Y si estás tratando con un software que se refiere al futuro, entonces, ¿tienes algo que sea como una separación limpia, y no estás intentando mezclar todo junto?
Así que necesitas hacer esas preguntas básicas. Y este tipo de información es simplemente una forma de entender por qué necesitamos esta separación limpia entre el pasado y el futuro, porque en última instancia se trata de esta información. Lo que cuenta como información proviene únicamente del pasado, tu conocimiento sobre él para generar las decisiones.
El conocimiento no mira hacia el pasado. Es fundamentalmente algo que mira hacia el futuro. Pero, de nuevo, necesitas tener esos bloques de construcción, bloques integrales, para que puedas desafiar a tu proveedor de software de maneras muy simples.
Y de nuevo, cuando le haces la pregunta, “¿Tu software muta el pasado?” si el proveedor se queda desconcertado, debes huir. Esto es malo. Realmente, es críticamente malo. Es tan malo como un proveedor de automóviles que dice, “¿Seguridad? No tengo ni idea de a qué te refieres.” De nuevo, deberías huir si se presenta esa situación… ya ves, estas son preguntas simples pero importantes que puedes usar, y eso es lo que sugeriría. Por eso te sugiero leer este capítulo. Necesitas ser capaz de hacer esas preguntas dolorosamente simples. Serán excelentes pruebas de fuego para detectar proveedores peligrosamente incompetentes. Eso es todo lo que digo.
Conor Doherty: Sí. Otra posible manera de encuadrar eso, y puedes decirme qué piensas, es… así que diste el ejemplo de un coche.
Joannes Vermorel: Sí.
Conor Doherty: Y lo que pensé mientras escuchaba fue, bueno, es como si estuvieras comprando un sedán, un coche familiar normal, y dices, “Bien, ¿puedo subir colinas? ¿Puedo subir montañas con este? ¿Estará bien?” Y si ellos dicen que sí, algo escépticos.
Ahora, para trasladar eso a la analogía del software sería: estás comprando un ERP y preguntas, “¿Puede este tomar mejores decisiones para mí?” y ellos dicen que sí. Para mí, una pregunta podría ser algo como, “Bueno, soy un novato, pero mi entendimiento es que los cálculos requeridos para tomar decisiones son increíblemente intensivos, y en un solo software eso impedirá la baja latencia de un sistema de registro. ¿Cómo lo mitigáis?” Simplemente explícame cómo lo mitigáis. Y si no tienen respuesta a eso, yo sería escéptico, porque, de nuevo, entre mejores sean los requisitos para ser bueno en cálculos, viene el riesgo de los registros.
Joannes Vermorel: Yo diría que sí, pero el problema es que… he estado pensando… verás, esta es una buena pregunta, es una buena prueba. El problema que veo es que tu proveedor típico de software empresarial te dará una respuesta que no entenderás, y parecerá inteligente y coherente. Por eso prefiero pedir hechos.
Conor Doherty: Pero esos son hechos también.
Joannes Vermorel: No, no es un hecho, porque el problema es que pueden mentir. No los niego. El problema es que hay maneras de hacerlo funcionar. ¿De acuerdo? Verás, puedes mezclar sistemas de registro y sistemas de inteligencia. Pero hay una trampa: se vuelve exponencialmente costoso.
Por eso, por ejemplo, puedes mezclar, y tienes un ejemplo muy simple: Google lo está haciendo. Tienen un registro limpio de toda la web, más un sistema de inteligencia que puede decidir en tiempo real, todo junto, mezclado. Entonces tienen tanto el sistema de registro como el sistema de inteligencia juntos para darte respuestas brillantes. Así que es posible mezclar los dos.
Pero es posible, pero cuesta mucho dinero, de verdad. Es exponencialmente más costoso para el proveedor, y además requiere un talento increíble. Así que, en resumen, ¿puedes tener algo que sea bueno tanto en sistemas de registro como en sistemas de inteligencia? La respuesta no es no. La respuesta es sí, con toneladas de dinero y toneladas de talento.
Y, ¿adivina qué te dirá el proveedor? “Oh, ese soy yo.”
Conor Doherty: “Ese soy yo. Exactamente yo.”
Joannes Vermorel: “Exactamente yo, y mucho menos de lo que piensas.”
Conor Doherty: Exactamente.
Joannes Vermorel: Exactamente. Y entonces, lo que estoy diciendo es que es demasiado bueno para ser verdad. Es demasiado bueno para ser verdad. Ahí lo tienes. Si suena demasiado bueno para ser verdad, probablemente lo sea.
Y es tan difícil competir con Google. Es tan difícil hacer esas cosas juntas, y los costos son tan abrumadores que la probabilidad de que en realidad te enfrentes a alguien honesto es… de nuevo, diría que tienes que ser escéptico.
Así que creo que es una buena pregunta, pero el problema es que el proveedor… te va a mentir tan fácilmente, porque dirá, “AI, somos tan buenos.” Sí, normalmente no debería ser posible a este precio, pero somos tan buenos que es posible.
Y luego tienes que llamar… estás faroleando. Simplemente estás faroleando, lo siento. Porque, ya ves, el problema es que entonces tienes otro tipo de prueba, que es que, si tuvieras personas tan buenas para hacer algo tan grandioso, no estarías haciendo software de supply chain. Estarías haciendo algo que te generaría aún más dinero.
Imagínate, si tienes equipos tan buenos como los de Google, o incluso mejores, y pueden hacer cosas aún más increíbles, entonces ¿por qué no competir con Google para aplastarlos? Tal vez no lo haces porque, de hecho, no tienes esos equipos.
Y si volvemos a “es demasiado bueno para ser verdad,” volvamos a la competencia M5. La competencia M5 — fue una competición sobre forecast. ¿De acuerdo? Forecast.
Cada uno de mis colegas, mis competidores en Lokad, si visitas su sitio web, te dirán “forecast de última generación. Somos los mejores.” Todos te dicen, “Tenemos el mejor forecast.” A veces no se dice de forma tan directa, pero si no se expresa explícitamente, se implica tan fuertemente que realmente te golpea en la cara.
Así que la situación es que tenemos un centenar de proveedores de software empresarial que están diciendo, “Tenemos modelos de forecast de última generación,” y que realmente, realmente están empujando el límite de lo que es posible en cuanto a precisión. Excelente. Excelente. ¿Por qué no? ¿Por qué no?
Ahora, la M5 fue una competencia con mil equipos compitiendo a nivel mundial. Si miras a las cien personas mejores — y, de nuevo, la gente puede verificarlo, ya que es una competencia de Kaggle, por lo que los registros son públicos — cualquiera en la audiencia puede verificar lo que estoy diciendo. Puedes ir y ver los registros de Kaggle, y observar quiénes estaban entre los cien mejores en esta competencia mundial. La respuesta es: no hubo ni un solo proveedor empresarial.
Oh espera, hubo apenas un proveedor de software empresarial en el top cien. Fue Lokad, y todos los demás estuvieron ausentes.
Conor Doherty: Número uno a nivel de SKU, si mal no recuerdo.
Joannes Vermorel: Sí, fuimos número uno a nivel de SKU y número cinco a nivel agregado. Inicialmente éramos número seis, pero luego alguien fue descalificado porque en realidad hizo trampa, y así, después de los hechos, fuimos reclasificados como número cinco.
Bien. Pero ya ves, por eso digo que es demasiado bueno para ser verdad. Si la gente es tan buena, debe haber algún efecto secundario de esa grandeza.
Compañías como Facebook están, por ejemplo, impulsando el estado del arte en AI. Lo hacen. ¿Cómo lo ves? Bueno, han inventado muchas de las tecnologías que son usadas por todos. Por ejemplo, PyTorch, que es utilizado por casi dos tercios de la comunidad de deep learning, es un producto que salió de los laboratorios de Facebook — quiero decir, Meta hoy en día.
Así que ya ves, si tienes una gran ingeniería, y Meta tiene excelentes ingenieros, uno de los subproductos accidentales es que obtienes grandes piezas tecnológicas que salen de tus laboratorios, o logros de cierto tipo. De nuevo, Google, lo mismo. Google, por ejemplo, inventó los transformers. La revolución de GenAI se inició esencialmente en Google. Así que, de nuevo, eso es una señal de que tenían verdaderamente grandes ingenieros.
Si volvemos a las personas que afirman que pueden hacer sistema de registro más sistema de inteligencia, y debido a que tienen personas tan excelentes, yo digo: “Bien, pero ¿dónde está la prueba de esta grandeza? ¿Qué han logrado que, de alguna manera tangencial, pruebe que tienen una fuerza laboral tan increíble?”
Y muy a menudo la respuesta es que no hay ninguna, porque, en realidad, de nuevo, te dedicas a hacer sistemas de registro, que son aburridos, que no son interesantes, que no representan un desafío técnico. ¿Y adivina qué? Ni siquiera vas a necesitar a los mejores ingenieros, porque si estás haciendo sistemas de registro, ¿por qué querrías pagar mucho dinero por ingenieros de primera que ni siquiera vas a necesitar, ya que lo que estás diseñando es realmente bastante simple? No necesitas a esas personas. Entonces, ¿por qué los contratarías en primer lugar? La respuesta corta: no lo haces.
Conor Doherty: Muy bien. Bueno, has estado hablando ya por bastante tiempo. No tengo más preguntas. Muchas gracias, como siempre, por expandir y tolerar mis preguntas mientras te contrarresto. Espero no haber sido demasiado firme hoy, pero, de nuevo, estás despedido.
Joannes Vermorel: Despedido. Exactamente.
Conor Doherty: Exactamente. Esto es… sí, este es mi último intento. Este es el Custer que estás viendo.
Pero sí, como siempre, solo estoy tratando de llegar al corazón de lo que creo que es un gran libro con unas ideas realmente, realmente, realmente buenas, y solo trato de impulsarte a que lo hagas más claro para la gente que aún no te conoce, porque obviamente cuando leo…
Joannes Vermorel: Y que no tienen ninguna razón para estar de acuerdo conmigo.
Conor Doherty: Y que no tienen ninguna razón para estar de acuerdo contigo. Exactamente. Así que estoy tratando de contrarrestarte. Estoy jugando al abogado del diablo, lo cual sé que me has pedido que haga.
Joannes Vermorel: Sí.
Conor Doherty: Y a ustedes que están viendo en casa, gracias por sus preguntas. Muchas de las preguntas que en realidad te hice hoy, Joannes, vinieron de la audiencia. Y leyendo más citas para contextualizar, también retroalimentación de la audiencia.
Así que si tienes cualquier otro comentario, o simplemente quieres comunicarte y continuar la conversación con Joannes y conmigo, puedes conectarte con nosotros en LinkedIn o enviarnos un correo electrónico a contact@lokad.com.
Y con eso, nos veremos la próxima vez para el capítulo 6. Y sí, vuelve al trabajo.
