00:00:00 Introducción a los recursos computacionales en supply chain
00:02:21 Importancia de los recursos computacionales en supply chain
00:07:04 Mechanical sympathy en el contexto de supply chain
00:09:38 Toma de decisiones con hardware de computación
00:12:42 La ilusión de pericia sin profundidad
00:13:59 Dependencia moderna de supply chain en la computación
00:18:32 El impacto de la velocidad del hardware en las decisiones
00:21:40 Las ineficiencias del software incrementan los costos
00:24:42 Propiedades y limitaciones de las bases de datos transaccionales
00:27:59 El aumento de los costos de computación en la nube por ineficiencia
00:30:09 Recetas de software más simples y económicas
00:32:40 Desperdicio extremo de recursos computacionales
00:36:14 Avances del hardware versus el rezago del software
00:40:48 Importancia del conocimiento en la selección de proveedores
00:45:15 Conocimiento teórico versus práctico
00:50:00 Ordenes de magnitud en la eficiencia computacional
00:54:33 Consideraciones de desempeño en el reabastecimiento de inventario
00:56:18 Proceso iterativo para la calidad de los resultados
00:58:50 La disrupción requiere reingeniería
01:00:18 Próximos pasos para los practicantes
01:02:17 Pagar por las ineficiencias de los proveedores
01:05:04 Impacto financiero de las decisiones
01:07:16 La falta de comprensión de los competidores
01:08:40 Conclusiones finales
Resumen
En un reciente episodio de LokadTV, Conor Doherty, Head of Communication en Lokad, conversó con Joannes Vermorel, CEO de Lokad, acerca del rol crítico de los recursos computacionales en la optimización de supply chain. Vermorel enfatizó la necesidad de comprender tanto el hardware como el software para tomar decisiones de supply chain informadas, tal como se detalla en decisiones de supply chain. Comparó este conocimiento fundamental con una conciencia geográfica básica, esencial para prevenir problemas y garantizar una toma de decisiones efectiva. Además, explicó que este entendimiento se extiende a los paradigmas de programación, asegurando que los practicantes puedan optimizar recursos y lograr mejores resultados.
Resumen Extendido
En un reciente episodio de LokadTV, Conor Doherty, Head of Communication en Lokad, participó en una discusión que invita a la reflexión con Joannes Vermorel, CEO y fundador de Lokad, una empresa de software francesa especializada en la optimización predictiva de supply chain. La conversación profundizó en el intrincado mundo de los recursos computacionales dentro del supply chain, un tema que va mucho más allá del mero uso de computadoras. Requiere una comprensión matizada de cómo estas máquinas operan de manera óptima, un concepto al que Vermorel se refiere como “mechanical sympathy.”
Doherty inició la discusión destacando el amplio alcance de los recursos computacionales, que abarca tanto el hardware como el software. Buscó una definición operativa de Vermorel, quien explicó que los recursos computacionales incluyen todas las clases de hardware que constituyen una computadora moderna. Esta clasificación, aunque algo arbitraria, ha evolucionado en los últimos 70 años, dando lugar a categorías distintas como CPUs y memoria, cada una con propósitos específicos en el ecosistema computacional.
Vermorel enfatizó la importancia de estos recursos en el contexto de la gestión de supply chain. Argumentó que, si aceptamos la premisa de que las decisiones de supply chain se toman de manera óptima con la ayuda de computadoras, comprender el hardware que facilita estos cálculos se vuelve crucial. Este conocimiento no se limita únicamente al entendimiento de los componentes físicos, sino que también abarca la comprensión de las clases más amplias de dispositivos y sus capacidades computacionales.
A continuación, Doherty buscó destilar esta información para los practicantes de supply chain, preguntando cómo deberían integrar este conocimiento en sus operaciones diarias. Vermorel aclaró que las computadoras no son inherentemente buenas para tomar decisiones; simplemente son las mejores herramientas disponibles para mecanizar los procesos de toma de decisiones. Esta mecanización, que ha impulsado el progreso durante siglos, ahora se extiende a los trabajos de oficina mediante el uso de computadoras.
Vermorel comparó el conocimiento fundamental de los recursos computacionales con el conocimiento geográfico básico. Así como saber la ubicación de los países en un mapa se considera esencial, comprender los fundamentos del hardware de computación es básico para los practicantes de supply chain. Este conocimiento ayuda a prevenir una serie de problemas potenciales y garantiza que las decisiones se tomen con una comprensión clara de la infraestructura computacional subyacente.
Doherty indagó más a fondo sobre la profundidad de este conocimiento fundamental, preguntando si implicaba conocer detalles simples como la ubicación de un puerto USB o conceptos más complejos como el funcionamiento de un disco SSD. Vermorel respondió que se trata más de comprender las abstracciones y las clases estables de preocupaciones que han perdurado en la computación durante décadas. Esto incluye memoria, almacenamiento, ancho de banda, cálculo aritmético y procesos de entrada/salida.
La conversación luego se centró en cómo este conocimiento fundamental se traduce en una mejor toma de decisiones. Vermorel explicó que sin una comprensión básica del hardware, los procesos de toma de decisiones pueden parecer mágicos, dificultando la evaluación de si un método es adecuado para el hardware disponible. Usó la analogía de seleccionar un automóvil para ilustrar este punto. Así como elegir un automóvil requiere entender su uso previsto, seleccionar recursos de computación requiere conocer sus capacidades y limitaciones.
Vermorel también abordó la importancia de los paradigmas de programación y cómo encajan en el proceso de toma de decisiones. Señaló que, aunque los casos de uso específicos no siempre sean evidentes, tener un conocimiento fundamental de conceptos como el análisis estático, la programación con arreglos y el control de versiones es crucial. Este conocimiento ayuda a los practicantes a evitar “andar a tientas en la oscuridad” y asegura que puedan tomar decisiones informadas sobre las herramientas de computación que utilizan.
En conclusión, Vermorel destacó que las prácticas modernas de supply chain dependen en gran medida del hardware de computación. Incluso las empresas que se consideran de baja tecnología dependen extensamente de las computadoras, ya sea para algoritmos complejos o herramientas simples como Excel. Por lo tanto, tener un conocimiento fundamental de los recursos computacionales no solo es beneficioso, sino esencial para una gestión efectiva de supply chain. Este conocimiento permite a los practicantes tomar decisiones informadas, optimizar sus recursos computacionales y, en última instancia, lograr mejores resultados para sus organizaciones.
Transcripción Completa
Conor Doherty: Bienvenidos de nuevo a LokadTV. Hoy, Joannes y yo discutiremos los recursos computacionales en supply chain. Como oirán, esto es mucho más que simplemente saber cómo usar una computadora. Más bien, requiere una comprensión adecuada de cómo funciona de manera óptima. Esto se llama mechanical sympathy, y como discutiremos, una buena mechanical sympathy puede traducirse en un mejor uso de los recursos computacionales y, en última instancia, en mejores decisiones. Ahora, como siempre, si les gusta lo que oyen, consideren suscribirse a nuestro canal de YouTube y seguirnos en LinkedIn. Y con eso, les presento la conversación de hoy.
Así que, Joannes, los recursos computacionales en supply chain, es un concepto muy amplio. Abarca tanto el hardware como el software. Entonces, para los propósitos de la conversación de hoy, y teniendo en cuenta que la audiencia es de supply chain, ¿cuál es una buena definición operativa de los recursos computacionales?
Joannes Vermorel: Los recursos computacionales es un término general que abarca todas las clases de hardware que constituyen una computadora moderna. Hoy en día, la separación entre estas clases es algo arbitraria, pero solo un poco. No hay nada en la naturaleza que indique que exista una clase de cosas que debamos llamar CPUs (unidades centrales de procesamiento) y otra clase de dispositivos que debamos llamar memoria y demás. Es una coevolución del diseño de computadoras y el rol del mercado lo que ha moldeado ciertos nichos para que aparezcan empresas que resultan tener dispositivos realmente competitivos para propósitos específicos. Así fue como se produjo esta evolución. Ahora, 70 años después de la introducción de las computadoras, contamos con clases muy claras de dispositivos de computación que no lo hacen todo de extremo a extremo. Son como componentes en el cálculo.
Ahora, ¿por qué es importante tener esto? Cuando me refiero a recursos computacionales, me refiero de manera amplia al hardware, pero también de manera implícita a la clase de dispositivos y lo que te ofrecen para realizar cálculos. ¿Por qué es importante para supply chain? Porque si aceptamos supply chain como un ejercicio de toma de decisiones y procedemos con el acto de fe de que estos cálculos se realizarán mejor con computadoras, entonces esta es literalmente la capa física que llevará a cabo esos cálculos. Este acto de fe no es nada insignificante, después de todo. Las computadoras han demostrado ser bastante capaces en la actualidad. Pero, aun así, todo parte de la visión de que todas estas decisiones, esos millones de decisiones que un supply chain considerable necesita tomar, al final se realizarán con una computadora de una u otra manera.
Por lo tanto, si empezamos a pensar en eso, deberíamos comenzar a prestar un poco de atención a esta capa de hardware. La situación se ha vuelto mucho más compleja en las últimas cuatro décadas. Las computadoras siguen avanzando, pero de maneras mucho más complejas y no tan intuitivas en comparación con lo que ocurría hasta finales de los 90.
Conor Doherty: Bien, nuevamente, para resumir, las computadoras son buenas para tomar decisiones. Pero, ¿cómo encaja un practicante de supply chain que escucha esto en la conversación de hoy? ¿Cuál es el mensaje principal o la visión a nivel general para ellos?
Joannes Vermorel: Primero, diría que las computadoras no son especialmente buenas para tomar decisiones. Son simplemente las herramientas que tenemos, y en este momento no contamos con ninguna opción viable para mecanizar los procesos de toma de decisiones. Esto es, en cierto modo, un acto de fe. ¿Por qué queremos mecanizar? Porque la mecanización ha impulsado el progreso durante los últimos dos, quizás incluso tres siglos. En el siglo XX, fue la mecanización de los trabajos manuales con mejoras de productividad que fueron absolutamente asombrosas, como un incremento de 100 veces. Ahora, en el siglo XXI, estamos viendo exactamente lo mismo pero en los trabajos de oficina, y esto sucede gracias a las computadoras. Podríamos imaginar un universo paralelo en el que sucediera con otras cosas, pero por ahora, la mejor opción que tenemos son las computadoras.
Ahora, ¿por qué es importante? Diría que debemos tratar los recursos computacionales y el hardware de computación como parte del conocimiento fundamental. ¿Cuándo fue la última vez que te resultó útil saber dónde se ubica Canadá en el mapa mundial? ¿Cuándo fue la última vez que te resultó útil saber que Rusia no tiene frontera con Brasil? Son el tipo de cosas en las que no es muy evidente en el día a día que, por ejemplo, tener un conocimiento básico de la geografía mundial resulte de alguna utilidad práctica. Sin embargo, si le preguntaras a la gran mayoría de las personas en esta audiencia, dirían que es importante. ¿Qué pensarías de alguien que no pudiera ubicar ni a China, ni a Canadá, ni a Rusia en un mapa mundial? Eso sonaría muy extraño, y probablemente no confiarías esa persona con muchos roles en tu organización.
Así que, puedes verlo como un poco de trivia hasta cierto punto, pero también es conocimiento fundamental. Si no sabes nada al respecto, eso creará problemas. ¿Qué tipo de problemas? Depende mucho de los detalles de la situación, la empresa y el sector. Pero puedes esperar una serie de problemas. Creo que el conocimiento sobre hardware de computación y recursos computacionales encaja perfectamente en esta categoría de conocimiento fundamental que los practicantes de supply chain deberían conocer. Deberían tener, en cierto modo, una mechanical sympathy, un término tomado de la Fórmula Uno, sobre estas cuestiones.
Conor Doherty: Bueno, me gusta la analogía que usas, y voy a tratar de utilizarla para desglosar este punto. Si dices que el conocimiento fundamental es saber que Brasil y Rusia no comparten frontera, esa es una granularidad del conocimiento geográfico. Otra es saber cuántas capitales tiene Sudáfrica. Estas son capas o granularidades cualitativamente diferentes de la conciencia geográfica. Para llevar esa diferencia y aplicarla al hardware o a los recursos computacionales, cuando dices conocimiento básico, ¿te refieres a saber dónde está el puerto USB para mi ratón, o a entender cómo funciona un disco SSD? ¿Cuál es el orden de magnitud del conocimiento aquí?
Joannes Vermorel: Me refiero más a las abstracciones. Hay una cantidad interminable de trivia sobre el hardware de computación. No se trata de conocer cada dispositivo individual y sus puntos de precio. Si eres un geek, puedes disfrutar leyendo sobre eso, y yo lo hago. Pero, fundamentalmente, se trata más de esas clases de recursos muy grandes y muy establecidas. Esto es algo dependiente de la arquitectura, pero estas arquitecturas han sido muy estables durante al menos cinco décadas, por lo que puedes esperar que continúe siendo así.
¿De qué estamos hablando? Estamos hablando de cosas como la memoria, la memoria volátil, el almacenamiento persistente, el ancho de banda, el cálculo aritmético, la entrada y salida (I/O), el rendimiento y la latencia. Todos estos aspectos han sido preocupaciones que han mantenido clases de interés estables durante muchas décadas. Eso es a lo que me refiero con tener este conocimiento básico para ver cuáles son las clases de preocupaciones y el hardware de computación correspondiente. ¿Cómo encajan todos estos elementos para lograr funcionar con una computadora moderna?
Si retrocedemos en términos de capas, en última instancia deseas que tus procesos de toma de decisiones sean computados gracias a este hardware de computación. Si no tienes ni la más mínima idea de lo que sucede a nivel de hardware, es completamente mágico. ¿Cuáles son las probabilidades de que puedas siquiera comprender si un método es adecuado para el hardware que tienes o no? No estoy hablando de una comprensión super detallada, solo de una comprensión básica sobre si funcionará o no en absoluto.
Conor Doherty: Por ejemplo, usas la frase… Perdón, déjame retroceder un paso. Nombraste algunos paradigmas de programación. Creo que fue de una de tus conferencias. Hablaste sobre paradigmas de programación, análisis estático, RA programming, differential programming, control de versiones, persistencia, todos estos conceptos. Mi pregunta es, ¿cómo encajan todos esos para tomar las mejores decisiones de supply chain de las que estás hablando?
Joannes Vermorel: Esto es conocimiento fundamental, así que no esperes casos de uso muy específicos de mi parte, al igual que la geografía básica. ¿Cuándo fue la última vez que necesitaste saber eso absolutamente? Probablemente nunca. Es algo ambiente. El problema es que, si te faltan capas de conocimiento fundamental, estás palpoteando en la oscuridad. Ni siquiera te das cuenta de que estás en la oscuridad. Ni siquiera te percatas de que hay tanto que no comprendes. Ese es realmente mi punto.
Retrocedamos. Quieres generar esas decisiones con una computadora. Eso significa que vas a seleccionar proveedores, probablemente bastantes. Comprarás o rentarás recursos de computación de la computación en la nube. Puedes delegar por completo la tarea a tu departamento de TI, pero ¿por qué el departamento de TI sería super bueno para escoger hardware de algo de lo que no saben nada? Por ejemplo, si te digo, “Querido TI, por favor escógeme el mejor auto,” sin especificar. Bien, entonces TI dice, “De acuerdo, te traigo un Fórmula Uno.” Y tú dices, “Bueno, pero en realidad, quiero conducir en dunas a lo largo de la playa.” Entonces resulta que el Fórmula Uno es un vehículo completamente malo porque no está diseñado para conducir en la arena.
Si todo lo que me dices es que elija algo bueno, escogerán algo fundamentalmente bueno, como un Fórmula Uno. ¿Es un buen auto? Sí, es un buen auto para un uso específico. Pero si dices, “Quiero un auto en el que pueda estacionar a mi familia de ocho,” esa va a ser una definición muy diferente de lo que significa ser bueno. Tenemos esta ilusión de que, cuando se trata de TI, hardware de computación y cosas de computación en general, se trata de una cuestión de especialistas. Así como escoger un auto, yo no soy un especialista en autos, así que le diré al departamento de autos que me escoja un buen auto y se haga cargo. Esas personas tienen tantas opciones de lo que incluso significa ser bueno que eligen algo al azar. Luego puedes quejarte, “Oh, pero el costo de este Fórmula Uno es extravagante. Ni siquiera puedo colocar a una segunda persona en el auto, y donde quiero conducir, que es en la arena, ni siquiera avanzará 10 metros antes de que las ruedas pierdan tracción por la baja altura.” Si fuera un auto, la gente estaría de acuerdo en que sería ridículo.
Pero cuando hablamos de cosas de computación, en la mayoría de las empresas, a la gente le parece completamente aceptable no estar interesada en el asunto. Aunque, nuevamente, vuelvo a la práctica de supply chain. Una práctica moderna de supply chain depende extremadamente de este hardware de computación. Las supply chains fueron digitalizadas hace décadas, e incluso las empresas que piensan que son low-tech dependen en gran medida de las computadoras, aunque sea solo para Excel.
Si dependes de esas herramientas a diario, dependes de ellas de una manera muy elaborada. Por ejemplo, yo dependo de la disponibilidad de agua, pero no necesito saber nada sobre el suministro de agua. Eso es correcto porque el agua como producto es extremadamente simple. Es químicamente simple, y cuando hablas de agua del grifo, esperas 99.99% H2O más un pequeño poco de minerales y un poco de cloro por razones sanitarias, y eso es todo.
Así que ya ves, y la temperatura debería ser algo así como entre 10 y 20 grados, y eso es todo. Es algo que es extremadamente simple. Por eso no tienes, mediante la capa de abstracción, “obtengo agua del grifo y es buena para beber.” Puedo permitirme no saber nada acerca de lo que sucede aguas arriba. Pero el problema, y ahí es donde llego al punto de los recursos de computación, es que los recursos de computación son multidimensionales. Sabes, no es algo simple como el agua. Es mucho más como un auto. Hay tantos tipos diferentes de autos, tantas maneras distintas de definir qué es un buen auto.
Si digo, “¿Qué es agua buena?” sabes, salvo que estés realizando experimentos muy, muy específicos, como procesos industriales que requieren agua ultra pura y demás, para prácticamente todas las situaciones que encontrarás en la vida, el agua del grifo básica es justo lo que necesitas. Así que no necesitas saber nada sobre eso porque, de nuevo, estás tratando con un producto que es extremadamente simple. Pero si tratas con un producto que es multidimensional, como un auto, entonces necesitas saber una o dos cosas sobre el auto si quieres comprarlo.
Así que, de nuevo, si hablamos de los practicantes de supply chain, resulta que dependes extremadamente de los recursos de computación para hacer un montón de cosas. Esas cosas se volverán aún más prevalentes en el futuro. ¿Qué te hace pensar que puedes ser completamente ignorante de la capa física de eso?
Conor Doherty: Bueno, hay algunos puntos allí, uno de los cuales es que las supply chains son obviamente muy complejas. Estás tratando de resolver muchas, muchas cosas, y eso depende del contexto. Por ejemplo, tal vez quieras que el auto conduzca en el desierto, que lo conduzcas en colinas, o que lo conduzcas en la ciudad. Estos son contextos diferentes, pero aún existen propiedades compartidas en términos de lo que al menos pensamos que las empresas deberían intentar hacer con sus recursos de computación. ¿Podrías, por favor, ampliar un poco sobre eso?
Joannes Vermorel: Sí, quiero decir, aquí está la cosa: está bien, quieres, digamos, analizar como línea base tu historial transaccional. Eso sería algo. Bien, eso significa que estos datos necesitan ser almacenados. Entonces, ¿dónde se almacenarán? ¿Qué tipo de hardware? ¿Cuáles serán las características de ese hardware? Si quieres almacenar los datos y luego acceder a ellos, ¿tendrá algún impacto? La respuesta es que sí, lo tendrá. Solo para darte una idea muy simple, consideremos que quieres almacenar estos datos en un disco giratorio.
No importa si es tu disco giratorio o es algo que rentas de una plataforma de computación en la nube. Si los datos se almacenan en un disco que está girando, significa que, en promedio, cuando quieras acceder a un fragmento de los datos, el disco tendrá que girar media rotación para que puedas acceder a esa área. Eso es simplemente porque los datos pueden estar en cualquier parte del disco. Si quieres acceder a una pieza de datos, en promedio el disco tendrá que girar media rotación.
Bien, ¿cuáles son las consecuencias de eso? Bueno, la consecuencia es: ¿qué tan rápido puede girar el disco? Generalmente, un disco gira a algo así como 7,000 revoluciones por minuto, y si es una unidad muy sofisticada, quizá llegue a 11,000 o 12,000, pero eso es todo. Esas son las revoluciones por minuto. Eso significa que, en términos de latencias, deberías esperar algo como 20 milisegundos, aproximadamente, para acceder a cualquier pieza de datos.
Entonces dirías, “Bueno, 20 milisegundos parece poco.” ¿Pero lo es? Porque 20 milisegundos significan que cada segundo solo puedes acceder, si quieres saltar por tu disco, a solo 50 piezas diferentes de datos por segundo. Si tienes que saltar alrededor, 50 por segundo no es mucho. Si tienes millones, decenas de millones de registros que recuperar, verás que muy rápidamente esto se convertirá en demoras locas, locas. Ahora podrías decir, “Bueno, pero mi disco puede almacenar terabytes de datos.”
Sí, pero si recuperar los datos, debido a que tienes que saltar tanto en el disco, toma días, no es muy, muy bueno. Así que, tal vez pueda, ya sabes, utilizar muchos más discos con menor capacidad, y así obtener, ya sabes, mayor capacidad de acceso en cuanto a saltos. O tal vez pueda incluso, ya sabes, usar otra clase de almacenamiento completamente distinta y optar por SSDs, solid state drives, que ofrecen latencias mucho, mucho mejores para esos accesos aleatorios.
Pero ya ves, ese es el tipo de cosas en las que, de nuevo, si no tienes ni la más mínima idea sobre los recursos de computación y las clases de hardware que proveen esos recursos, ese tipo de preguntas ni siquiera ocurrirían en tu forma de pensar. ¿Y puede eso hacerte daño? De nuevo, esa es la pregunta. Lo que no sabes, ¿puede hacerte daño? Yo diría que sí, porque de nuevo, vas a comprar muchas de esas cosas, ya sea de forma directa o indirecta.
Los comprarás directamente si tu IT department simplemente se encarga de comprar recursos de computación en la nube, pero también los adquirirás indirectamente si eliges un proveedor de supply chain software. Porque ya ves, si eliges un proveedor, estás escogiendo una forma específica de consumir esos recursos de computación para obtener el resultado que deseas. Y aquí mi mensaje es que, si crees que el proveedor de software promedio tiene alguna competencia en este asunto, estás completamente engañado.
La gran mayoría de, obviamente esto es una opinión, pero diría que la gran, gran mayoría de mis competidores, competidores de Lokad, tienen, cuando observas la dirección y su interés, en términos generales, cero interés, cero empatía mecánica por el hardware de computación. Y como consecuencia, no debería ser tan sorprendente que su software, como resultado, sea horriblemente ineficiente. ¿Y por qué es eso? Bueno, vuelve a que, si no prestas atención a tu hardware, ¿por qué pensarías que al final del día el software que construirás encima hará muy buen uso de ese hardware?
Sabes, de nuevo, eso sería como escoger un Fórmula Uno sin importar la carretera por la que quieras conducir, y luego te preguntas por qué en la playa este es un vehículo tan deficiente. Sorpresa, sorpresa, eso es lo que sucede cuando no prestas atención al hardware de computación.
Así que, de nuevo, si pudieras confiar en un mundo perfecto, podrías confiar en consultores, proveedores de software, y esas personas habrían tomado todas las decisiones correctas por ti. Pero resultó que, debido a que la gran mayoría de los practicantes de supply chain son completamente ignorantes, entonces los proveedores de software también pueden darse el lujo de ser completamente ignorantes. ¿Por qué no deberían serlo, después de todo, si los clientes no pueden notar la diferencia en el momento de adquirir el software o la solución? No importa, quiero decir, no importa hasta que sean golpeados por las consecuencias de esa ignorancia.
Conor Doherty: Bueno, está bien, así que, primero que nada, no hay nada de malo en tener una opinión, eso es justo lo que hacemos aquí. Pero cuando dices, en última instancia, cuando las empresas compran software de un proveedor, creo que dijiste que consumen recursos para obtener lo que quieren o para obtener lo que tú quieres. En última instancia, seamos prácticos, estamos hablando de tomar decisiones. Has dado algo de teoría, pero ¿podrías ser un poco más concreto para las personas que tienen curiosidad? ¿Cómo influye o se traduce un mejor uso de los recursos de computación, tal como lo describes, en decisiones, en las elecciones tomadas en el mundo real?
Joannes Vermorel: Entonces, cuando tienes decisiones, existen muchas, muchas maneras de elaborar recetas numéricas que, en última instancia, generarán esa decisión. La cuestión es que si la forma en que consumes tus recursos de computación es increíblemente ineficiente, y permíteme dar un ejemplo. Si comienzas a usar, digamos, una base de datos relacional, una base de datos transaccional, una base de datos SQL, lo mismo, nada que ver con el dinero. De hecho, si utilizas una base de datos transaccional y deseas llevar a cabo recetas analíticas, recetas numéricas, simplemente hacer algún tipo de procesamiento numérico, pagarás una sobrecarga de probablemente un factor de 100, al menos dos órdenes de magnitud, si no 300, tres órdenes de magnitud.
Y ¿por qué es eso? Es porque esta capa de software, la capa transaccional, te proporciona algunas propiedades muy interesantes, pero no tienen nada que ver con el cálculo analítico. Básicamente te otorgan las cuatro propiedades conocidas como ACID: atomicidad, consistencia, aislamiento, durabilidad. Esas cosas son muy útiles para los procesos transaccionales. Garanten, por ejemplo, que si deseas declarar que un proveedor ha sido pagado, nunca podrás terminar en una situación en la que el dinero se haya enviado, la orden al banco, pero la factura del proveedor no se haya liquidado, simplemente porque, por ejemplo, el sistema informático se colapsó a mitad de la operación.
Entonces, en teoría, podrías terminar en una situación en la que ya has emitido la orden de transferencia bancaria pero no has registrado el hecho de que la factura de ese proveedor ha sido saldada. Así, la próxima vez que reinicies el sistema, emitirás un segundo pago y, efectivamente, pagarás al proveedor dos veces. Ese es el tipo de situación que puedes obtener con una capa transaccional. Es muy, muy importante para procesos transaccionales, donde esencialmente hay una cuenta que se incrementa y otra cuenta, en el sentido contable, que se decrementa. Quieres que esas acciones ocurran lógicamente al mismo tiempo para que nunca se desincronicen.
Bien, pero si utilizas este tipo de paradigma de software para construir tus recursos analíticos, eres increíblemente ineficiente. Y, por cierto, sorpresa, sorpresa, esto es exactamente lo que hace el 99% de mis competidores. ¿Qué significa eso en términos de toma de decisiones? Bueno, si la forma en que usas los recursos de computación comienza teniendo una sobrecarga de un factor de 100, significa que estás restringido a recetas numéricas muy, muy simplistas. Simplemente porque en cuanto tienes un mínimo de complejidad, te quedas completamente sin presupuesto en cuanto a recursos de computación. Eso implica que los precios se vuelven realmente extravagantes muy rápido.
Ya ves, esto no es un elemento publicitario. Si no controlas el presupuesto de tus recursos de computación, puedes terminar con niveles de gasto insólitos. Solo para darte una idea del precio, muchos de mis colegas, no competidores, colegas que serían empresas de software as a service que manejan cargas analíticas intensas, cuando miro el S1 –el S1 es un documento que debes publicar cuando quieres salir a bolsa en EE. UU.– es muy interesante porque es prácticamente un informe para los inversionistas, para los futuros inversionistas. Aquí puedes ver la descomposición del gasto en los últimos tres o cuatro años.
La mayoría de las empresas de software que eran analíticas, como Lokad, no necesariamente de supply chain, pueden ser cualquier cosa, ya sabes, que pueden ser detección de fraude, procesamiento de logs del sistema, lo que sea. Normalmente destinaban la mitad de su gasto a recursos de computación en la nube. Así que la cantidad de gasto es muy, muy significativa. A pesar de pagar, ya sabes, tener en la nómina ingenieros extremadamente caros y una fuerza de ventas extremadamente costosa, aún logran destinar la mitad de sus gastos a proveedores de computación en la nube. Por lo tanto, ves que la idea de que el costo de los recursos de computación es insignificante es un completo disparate para la mayoría de los proveedores de software de la clase analítica, como Lokad.
Sistemas que no son ni de inteligencia, sino sistemas de reportes o de indigencia, esos gastos pueden ser muy, muy significativos. Cuando digo que, si eres ineficiente, gastas 100 veces más, puedes ver que, si ya estás destinando la mitad de tus ingresos a recursos de computación, gastar 100 veces más simplemente no es una opción. Ni siquiera es remotamente posible. Así que eso significa que, para mantenerte dentro del presupuesto, ¿qué haces? Pues, simplemente aumentas el precio. Eso es lo que hacen, pero incluso eso, tiene límites. Puedes duplicar, tal vez cuadruplicar tu precio, pero no puedes multiplicarlo por 100.
Así que lo que hacen la mayoría de los proveedores de software es optar por recetas más simples y baratas, incluso si son extremadamente simplistas hasta el punto de perjudicar a sus clientes. La realidad es que, como proveedor, no pueden permitirse algo que pudiera ser menos disfuncional porque sería demasiado costoso. ¿Y por qué no se lo pueden permitir? Porque son absolutamente increíblemente derrochadores con sus recursos de computación.
Conor Doherty: Bueno, de nuevo, se me ocurre que cuando hablas y explicas cómo crees que se deben asignar los recursos computacionales, es en pos de tomar decisiones fundamentalmente mejores. En tu mente, ese es el problema que debería resolverse. Pero ese no es necesariamente el mismo paradigma que todas las empresas –o mejor dicho, no todas– aplican. Por ejemplo, podrías ser una empresa que priorice algo como perseguir service level o perseguir forecast accuracy, y ese es el objetivo, ese es el ideal inalcanzable al que aspiras. ¿Cómo diferiría la asignación de recursos computacionales en esa situación? Y siéntete libre de comentar.
Joannes Vermorel: Bien, está bien, te propones un objetivo. Aquí, no cuestiono esa parte. Cuando hablo de decisiones mejores, me refiero a que, de acuerdo con cualquier métrica, cualquier objetivo que te plantees. Así que no importa. Si quieres un mejor service level, perfecto. Ese es tu objetivo. Ahora te has planteado un objetivo, y ahora tienes poder de procesamiento a tu disposición, recursos computacionales que puedes usar para obtener decisiones que serán mejores según los objetivos que te hayas fijado. Perfecto.
Ahora aclaremos cuál es el paradigma ambiental para prácticamente todos mis competidores. El paradigma ambiental es que tendrás ingenieros que comienzan a trabajar en algo, y tan pronto como ese algo es compatible con el mejor hardware que el dinero pueda comprar, dejan de trabajar y empiezan a venderle el producto a los clientes. ¿Cómo se ve esto? Significa que, bueno, quiero hacer el reabastecimiento de inventario para una red minorista. Así que tengo, digamos, 20 millones de SKUs. Bien. Primero, pruebo varias cosas, no funcionan, así que recurro, por ejemplo, al análisis de existencias de seguridad, el cual es excesivamente trivial en términos de recursos computacionales.
Y luego, debido a que mi sistema es tan ineficiente con hardware de computación extremadamente caro, puedo hacerlo funcionar. Después paro y se lo vendo al cliente. Entonces, ¿cuál era la forma de pensar en este paradigma? Porque fue, de hecho, en la industria del software –creo– el paradigma dominante hasta finales de los años 90 del siglo XX. Este paradigma era básicamente que el hardware de computación progresa exponencialmente. Así que la idea era que obtuvieras el mejor hardware que el dinero pueda comprar, y tan pronto como funcionara, es decir, tuvieras algo que funcionara dentro de esas limitaciones, incluso si los costos eran una locura, incluso si no estabas haciendo un buen uso de tus recursos computacionales, no importaba.
¿Por qué? Porque tienes una progresión exponencial del hardware de computación en todas las métricas. Eso era a lo que la gente se refería como la Ley de Moore, pero en realidad existían muchas otras leyes para todo. Todos los recursos computacionales estaban progresando, todas las métricas avanzaban, y esa era, en gran medida, una de las ideas que hizo a Microsoft extremadamente exitoso nuevamente en los años 90. La idea es que, si funciona, no importa cuán terrible sea el rendimiento, porque dentro de cinco años el hardware de computación habrá progresado tanto que esos recursos se volverán triviales.
Esto funcionó hasta finales de los años 90, ya que, esencialmente, desde el año 2000 en esta área, tenemos clases enteras de métricas que no han mejorado. Por ejemplo, la latencia entre la CPU y la memoria prácticamente no ha cambiado en las últimas dos décadas. Debido a que ahora estamos limitados por la velocidad de la luz, no va a cambiar en el futuro previsible.
Otro elemento es, nuevamente, la velocidad de la luz. Los paquetes en Internet a larga distancia ahora viajan aproximadamente a dos tercios de la velocidad de la luz, por lo que no hay mucho margen para mejorar la velocidad de los paquetes en Internet, porque ya estamos muy, muy cerca de la velocidad de la luz. Podemos tener más ancho de banda, por lo que podemos enviar muchos más paquetes sin problema, pero en términos de velocidad bruta de los paquetes en sí, ahora estamos muy cerca de los límites de la física, al menos de la física tal como la conocemos.
Así que, eso es lo que sucede con este paradigma, que era muy prevalente en la industria del software a finales de los años 90, que era “simplemente haz algo que funcione y luego véndelo y no te preocupes por el rendimiento porque es una tarea imposible”. La industria –la industria del hardware– mejorará todo tanto que todas esas preocupaciones de rendimiento quedarán obsoletas en solo unos años. Esa era la mentalidad.
Curiosamente, aún tenemos muy buenos avances en el hardware de computación, pero el progreso se ha vuelto muy sutil. Todavía hay progresiones exponenciales, pero en líneas muy específicas, no en todas las métricas, solo en algunas. Lo interesante es que la mayor parte de la industria de software B2C ha estado prestando mucha atención a esto. Por ejemplo, la industria de los videojuegos dedica una enorme atención a este tipo de detalles. Pero cuando se trata de software empresarial, la mayoría, el 99%, sigue viviendo en los años 90, donde no prestan atención y operan como si, dentro de cinco años, el progreso del hardware de computación hiciera trivial el costo de su sistema. No es el caso.
De hecho, debido a que la cantidad de datos gestionados por las empresas sigue aumentando, terminamos en una situación en la que, año tras año, el costo que necesitas para mantener tus sistemas operativos tiende, para la mayoría de los proveedores de software, a aumentar más rápido de lo que el precio del hardware de computación disminuye. Así que, año tras año, terminas gastando aún más para mantener, prácticamente, el mismo nivel funcional de calidad en tus procesos de toma de decisiones o en el soporte para esos procesos, si es que no están completamente automatizados.
Conor Doherty: Bueno, el progreso del hardware o de la computación se ha vuelto sutil, creo que fue el término que usaste. Es sutil, ya no son saltos exponenciales.
Joannes Vermorel: Es en direcciones específicas, no en dimensiones. En los años 90 lo interesante era que todo mejoraba en todos los frentes. No había ni una sola métrica que no mejorara. Hoy en día, hay muchas métricas que no se han movido literalmente durante una década.
Si miras, por ejemplo, la cantidad de calor que puedes disipar de una computadora, tu computadora necesita deshacerse del calor. Puedes tener cableado de cobre, puedes tener ventiladores, puedes hacer varias cosas para extraer el calor del interior de la computadora y evitar que se sobrecaliente. Pero ya hemos alcanzado el límite de lo que es factible con el aire. Hay límites que se alcanzaron hace dos décadas. Puedes usar agua para hacerla un poco más eficiente. Si quieres ir muy a la moda, puedes optar por nitrógeno líquido. Es bastante poco práctico, pero es posible para buenos benchmarks, etc.
Así que, hemos llegado a los límites. No tenemos materiales mágicos que nos permitan evacuar el doble de calor. Quiero decir, podríamos usar, tal vez, diamante. El diamante es un conductor de calor fantástico, pero la idea de tener kilogramos de diamantes para evacuar el calor todavía está muy lejos. Incluso eso solo nos dará un impulso modesto en comparación con el cobre, que ya es un excelente conductor.
Conor Doherty: Bueno, eso de hecho demuestra un poco más mi punto. Entonces, para terminar la idea, si…
Bueno, en realidad tomaré el ejemplo que acabas de dar. Es decir, estabas hablando de la diferencia entre el cableado de cobre y los diamantes como conductores de calor. Sacar un poco más de rendimiento de las propiedades de disipación de calor de una computadora va a requerir una comprensión bastante matizada y especializada de la ingeniería computacional. Entonces, volviendo al tema principal, ¿cómo se traduce aumentar tu conocimiento fundamental ambiental en un mayor rendimiento de supply chain cuando los márgenes son tan estrechos como describes?
Joannes Vermorel: No, creo que, de nuevo, eso es lo que hace que el conocimiento fundamental aclare la imagen de todo. ¿Está tu departamento de IT comprando el tipo correcto de cosas, al menos en líneas generales? ¿Tienes alguna idea al respecto? ¿Puedes siquiera discutir el asunto con tu departamento de IT? Si no puedes, ¿por qué deberías esperar siquiera que lo que están comprando tenga algo de sentido?
Nuevamente, vuelve a la Fórmula 1 para ir a la playa. No tiene ningún sentido, pero esa es exactamente la clase de cosas que sucede cuando las personas no tienen ningún conocimiento sobre lo que está en juego. Cuando quieres elegir un proveedor, ¿puedes siquiera tener una discusión inteligente sobre la forma en que están consumiendo los recursos computacionales para brindarte decisiones mejores o un mejor soporte para tus decisiones? ¿Están consumiendo esos recursos de manera acorde con el hardware de computación que tenemos? ¿La arquitectura tiene sentido o absolutamente no?
Nuevamente, si piensas en términos de un auto, hay tantas cosas que sabes de forma intuitiva. La aerodinámica, por ejemplo. Si vieras un auto que violara masivamente las leyes de la aerodinámica, pensarías: “Bien, este auto va a tener una resistencia inmensa al aire, su consumo será horrible.” No hay alternativa. Así que, ves, es el tipo de cosa que, simplemente por tener conocimiento fundamental, se vuelve instintivo. No necesitas necesariamente que te digan, al ver un auto muy bajo, que la aerodinámica va a ser buena y que, probablemente, ese auto pueda ir más rápido.
Ese es el asunto. Ni siquiera tienes que pensar en cuáles son las dinámicas de fluidos en juego ni nada de eso. Es instintivo. Es el tipo de cosa que, si buscamos mejores decisiones, te permite intuir cuando algo es tremendamente disfuncional. Mi punto es que, debido a que el 99.9% de los clientes o practicantes de supply chain están totalmente ciegos respecto a la cuestión, si hay unos pocos geeks, eres como una minoría diminuta. Si eres ciego, eso significa que, nuevamente, la respuesta del ecosistema –los proveedores de software, los proveedores de soluciones, los consultores– es que no necesitan prestar atención. Sus clientes no prestan atención. ¿Por qué lo harían?
Si vivieras en un país donde la gasolina es gratuita, ¿por qué los fabricantes de automóviles prestarían atención al consumo de sus coches? Para ellos, si la gasolina es gratuita, significa que, en su mayoría, es una preocupación irrelevante para los clientes. Si los clientes no prestan atención, los proveedores de automóviles tampoco lo hacen. Y si nos referimos a los proveedores de software, si los clientes están desorientados y no prestan atención, ¿por qué los proveedores empresariales deberían hacerlo? La respuesta es, pues, que no lo hacen. Efectivamente, no prestan atención.
Es por eso que hoy en día la gente siempre se sorprende al ver el software empresarial. Haces clic, quieres simplemente ver un reporte, quieres hacer algo mínimo, y te toma segundos. En términos de rapidez, el software empresarial en promedio es muy pobre. Es muy lento. Si lo comparas, digamos, con la búsqueda web –quieres hacer una búsqueda en Google– en algo como 50 milisegundos, tal vez 100, Google es capaz de escanear la web y darte un compendio de cosas que coinciden con tu consulta. Esto es extremadamente rápido y ágil.
Por el contrario, si solo quieres hacer algo súper básico como, “quiero chequear el estado de este SKU”, te toma segundos. Lo interesante es que te toma segundos con el hardware de computación que tenemos en 2024. Hace 20 años ya tomaba un segundo, a pesar de contar con hardware que era 100 veces menos capaz. ¿Qué pasó? Pues, lo que ocurrió es que el hardware de computación extra, las capacidades adicionales de este hardware, simplemente se desperdiciaron en un software ineficiente.
Conor Doherty: Gracias. Cuando hablas de conocimiento fundamental, justo mientras escuchaba se me ocurrió que hay una especie de división en lo que estás describiendo, y quiero saber tu opinión al respecto. Para tomar una analogía de lo anterior, dijiste que si tomas un auto y te vas al desierto, ¿es ese el mejor vehículo para el desierto? Se me ocurre que, en términos de conocimiento fundamental, hay tanto teórico como práctico.
Así que puedes tener una comprensión fundamental teórica de cómo funciona un motor de combustión interna, es decir, así es como se mueve el auto. Esa es una comprensión teórica. También existe un conocimiento fundamental práctico, que es: si se desinfla una llanta, ¿tengo las habilidades y el conocimiento básico para cambiarla? Si el motor no arranca, ¿puedo hacer una reparación básica? Y si vas a conducir en el desierto donde estarás solo, fundamentalmente requerirás tanto un conocimiento fundamental teórico como, al menos, uno práctico básico.
Entonces, volviendo al tema en cuestión, has descrito en cierta profundidad el conocimiento teórico fundamental que las personas deberían tener. En términos de conocimiento práctico fundamental, ¿hay alguna habilidad que creas que todos deberían tener en este ámbito?
Joannes Vermorel: Sí, nuevamente, cuando miras lo práctico, sería tener algunas ideas sobre el tipo de puntos de precio de los que estamos hablando. Ya sabes, ¿cuál es el costo de un terabyte de almacenamiento? ¿Cuál es el costo aproximado de un terabyte de memoria? ¿Cuál es el costo de una CPU que te da 2 GHz de rendimiento de cómputo? Ya sabes, de nuevo, solo tener una idea—si puedes adivinar un número que no esté equivocado por un orden de magnitud, eso ya es muy bueno. Ya sabes, lo curioso de las cosas de computación es que, habitualmente, si la gente tuviera que adivinar, sus estimaciones estarían equivocadas por muchos órdenes de magnitud.
Nuevamente, si te digo cuál es el peso de un automóvil y te muestro el automóvil, tu estimación podría estar equivocada en un 50%. Ya sabes, dices, de acuerdo, una tonelada y media, y resulta que es un auto eléctrico y pesa dos toneladas y algo más. Está bien, pero aun así, estabas dentro del mismo orden de magnitud. Sabes, no ves un auto y dices que pesa 20 kilogramos o 500 toneladas. Pero lo que pasa es que cuando le preguntas a la gente cuál es el costo de un terabyte de almacenamiento persistente, el más barato que puedas encontrar, algunas personas te darán precios que oscilarán, no sé, de 10,000 a 2, y demás, y nadie tendría idea de ello.
Y de igual forma, si te digo cuál es el costo de un chip que pueda realizar, en orden de magnitud, 100 mil millones de operaciones aritméticas por segundo, ¿cuál sería un chipset que pueda hacer eso, y cuál sería su costo? La gente dice, no sé, 100,000 euros o tal vez $50. De nuevo, ese es el tipo de conocimiento práctico: tener algunas ideas sobre los puntos de precio. Nuevamente, eso no es preciso. Si puedes tener una noción del orden de magnitud, ya estás en el camino para hacer que las cosas tengan sentido.
Ese es lo extraño de los recursos de computación: literalmente tienes 15 órdenes de magnitud. Es muy, creo que es bastante único. No existe otro campo que yo conozca en el que el orden de magnitud esté tan increíblemente disperso. 15 órdenes de magnitud significan que, por un lado, hablamos de unidades, ya sabes, una suma, una multiplicación, que serían una unidad de cómputo. Y, por otro lado, hablamos, esencialmente, de miles de millones de miles de millones. Eso es realmente todo un espectro de órdenes de magnitud.
Y eso es difícil de comprender para la mente. Y por eso, por cierto, cuando dije que se pueden cometer errores en cuanto al despilfarro de recursos de cómputo, es porque, de nuevo, la analogía del coche es engañosa: incluso el peor auto solo será como 10 veces peor en términos de consumo que el mejor. Digamos, ya sabes, que si quiero recorrer 100 kilómetros, si tengo un auto súper, súper eficiente, me dará cinco litros de gasolina para recorrer 100 kilómetros.
Si eliges un SUV súper pesado, ineficiente y demás, será, digamos, 50 litros. Factor de 10. Con las computadoras, no es así. Sería como si lo más eficiente consumiera 5 centilitros para 100 kilómetros y lo menos eficiente consumiera cinco metros cúbicos para esos 100 kilómetros. Así que los órdenes de magnitud son simplemente alucinantes. Y ahí es donde necesitas, de nuevo, en términos de practicidad, tener algunas ideas sobre los puntos de precio. También, tener algunas ideas sobre lo que está avanzando y lo que no se está moviendo.
Conor Doherty: ¿Qué quieres decir, qué está avanzando y qué no lo está?
Joannes Vermorel: Por ejemplo, las GPUs han estado progresando en términos de tendencias de red. Las GPUs han progresado de manera increíble durante los últimos 5 años y se espera que sigan progresando de manera increíble durante los próximos cinco. Así que esta es una clase de recursos de cómputo que está mejorando rápidamente. Están mejorando en términos de cantidad de operaciones por segundo. También están mejorando en términos de memoria. Así que eso es muy, muy bueno. Las CPUs están en una pista similar. Están mejorando, tal vez no tan rápido, pero aún así están mejorando muy rápidamente en términos de cantidad de núcleos y el tamaño de la memoria L3, que es la memoria que reside dentro de la CPU.
Sigue mejorando rápidamente. Correspondientemente, si miramos la DRAM, la DRAM es la que se utiliza para la memoria principal de la computadora, la memoria volátil. Así que, si apagas tu computadora, la pierdes. Eso apenas ha cambiado en la última década. Hay muy pocos fabricantes. Hay, como, cuatro fábricas en el mundo. Así que este es un mercado en el que no deberías esperar que las cosas cambien realmente en términos de caídas de precios. No deberías esperar demasiado cambio a corto plazo, etc. Quiero decir, diría que, en términos prácticos, se trata de tener algunas nociones de órdenes de magnitud, conocer un poco los puntos de precio, saber un poco qué puedes esperar, y también tener la intuición de si, digamos, el hardware de grado profesional te dará algo muy diferente al de grado consumidor.
Dependiendo de lo que mires, a veces lo mejor que puedes obtener es simplemente hardware de grado consumidor, y lo mejor que puedes comprar como empresa es solo marginalmente mejor. Verás, en otras áreas no es así. En otras áreas, lo que como empresa puedes comprar es muchas órdenes de magnitud mejor de lo que típicamente se considera adecuado para el mercado consumidor. De nuevo, ese es el tipo de conocimiento que realmente te ayuda a navegar el panorama, escoger al proveedor adecuado, o más bien eliminar a los incompetentes. Ya sabes, ese tipo de cosa en la que, si empiezas a prestar atención, podrás filtrar la incompetencia, ya sea en consultores, en proveedores, y también en proyectos internos. Eso importa.
Conor Doherty: Bueno, tocaste el tema del costo varias veces, pero hablaste principalmente en términos del costo directo de adquirir físicamente hardware. En cuanto al costo directo y, luego, indirecto de no ser más astuto con los recursos de cómputo, ¿cuáles son los órdenes de magnitud de los que estamos hablando aquí? Y para eso, asume una gran tienda minorista, perdón, una gran empresa minorista, una gran red minorista, omnicanal, pinta la imagen que quieras, pero ¿cuál es un orden de magnitud razonable en términos de lo que se puede perder por no ser más astuto con tus recursos de cómputo?
Joannes Vermorel: Bueno, diría que, en una estimación conservadora, más del 90% de las iniciativas de optimización de supply chain fracasan. Y un porcentaje bastante grande de ese 90% —es decir, prácticamente todas las iniciativas de software fracasan— y un gran porcentaje de eso falla, en gran parte, aunque no es la única razón, debido principalmente al desempeño abismal. Ahora, cuando tenemos que pensar en desempeño, debemos considerarlo desde diferentes perspectivas. La gente pensaría, de acuerdo, necesito hacer mi reabastecimiento de inventario cada día, así que el cálculo de todo debe poder hacerse en menos de 24 horas.
Bueno, eso se da por sentado. Ya sabes, si quieres ejecutar el cálculo cada día, si no puedes completarlo en 24 horas, estás en problemas. Así que ese es el límite superior del tiempo que puedes dedicar. Ahora, pensarías que si compras el doble de recursos de cómputo, lo podrás hacer el doble de rápido. Bueno, no necesariamente, porque realmente depende de la arquitectura de software que adoptes. Hay muchas arquitecturas y patrones de diseño que no se prestan a lo que se llama —el término técnico es— “scale-out”. Así que hay muchos enfoques en los que, si le echas más hardware de cómputo al asunto, simplemente no obtienes aceleración.
Conor Doherty: Rendimientos decrecientes, esencialmente.
Joannes Vermorel: Sí, y a veces ni siquiera hay retorno. Literalmente, puedes añadir más recursos y obtener exactamente cero aceleración. Realmente depende de la forma en que hayas diseñado tu software para aprovechar esos recursos de cómputo extra. Ahora, sigamos adelante. Ahora tienes algo que puede calcular tu reabastecimiento en, digamos, cuatro horas, y dices, “Genial, para tu red minorista, solo toma cuatro horas.” Así que tienes 24 horas al día, y parece que vas a ejecutar el cálculo durante la noche. ¿Es satisfactorio?
Bueno, mi respuesta es no, absolutamente no. ¿Por qué? Porque aquí solo estás viendo el proceso una vez en producción. No tomas en cuenta que tu receta numérica necesitará ser ajustada, y tendrás que iterar muchas veces para converger a aquella final que sea satisfactoria. Este proceso experimental va a ser mucho más costoso.
Así que esa es una cosa. Pero luego, la otra es que tienes que pagar para que la gente espere hasta que el cálculo termine, para que puedan revisar los resultados, hacer la evaluación y continuar con la siguiente iteración. Y aquí el gran problema es que, si vuelvo a la iniciativa de software de supply chain que fracasa, este proceso puede volverse dramáticamente lento. Quiero decir, estábamos hablando de unas cuatro horas. Digamos, de nuevo, que los experimentos serán el doble de lentos debido a que estás en condiciones experimentales que no son tan óptimas.
Eso significa ocho horas. Eso significa que solo puedes hacer un experimento al día. Eso significa que, si necesitas hacer 500 iteraciones, esta cosa simplemente tomará dos años. Será tan lento que comenzarás a tener otros problemas, como que las personas que realizan los experimentos empezarán a rotar a otro empleo. Los ingenieros con los que trabajas no estarán contigo por 40 años. Así que, en algún momento, tendrás gente que comenzó a trabajar en el proyecto, y luego se va, y tendrás que incorporar a nuevas personas, y naturalmente estas no recordarán todos los experimentos que se han realizado.
Así que ves, este tipo de problema crea tantos inconvenientes. Incluso si converges a una receta numérica satisfactoria, estás a solo una disruption de distancia, ya sabes, confinamientos o lo que sea, y necesitas reingenierizar la receta de nuevo. Si tu proceso iterativo es increíblemente lento, fallarás sistemáticamente en hacer frente a todas las disrupciones. Para cuando finalmente hayas diseñado la solución para la disrupción, ya habrás pasado a otra cosa. Así que necesitas tener algo que sea extremadamente performant para que tus iteraciones sean muy ágiles.
Y eso también aporta otro matiz, que es que en el rendimiento, al pasar de una iteración a la siguiente, puedes hacer trampa. Porque tal vez, de un experimento al siguiente, vas a repetir la mayoría de los mismos cálculos. ¿Entonces, necesitas reenviar todos esos recursos si, de hecho, solo estás haciendo casi la misma receta numérica con unas mínimas divergencias? Quizás, si adoptas un enfoque inteligente, reciclarás la mayor parte de lo que ya has calculado para poder iterar mucho más rápido sin rehacer todo cada vez.
Pero de nuevo, eso solo funcionará si puedes llegar a entender a dónde se van tus recursos de cómputo, qué estás desperdiciando, qué estás haciendo dos o diez veces seguidas, y que deberías hacerlo solo una vez.
Conor Doherty: Bien, Joannes, la gente que escucha hoy, y estoy seguro de que todos dicen, “Estoy de acuerdo con este hombre. Confío en él. Es de fiar.” ¿Cuáles son los próximos pasos inmediatos para, digamos, el/la practicante de supply chain promedio y las personas a nivel C que te están escuchando y piensan, “De acuerdo, quiero ser más astuto en estas cosas”?
Joannes Vermorel: Diría que empiecen a leer materiales introductorios sobre cómo funcionan las computadoras. Hay muchos libros que te explican cómo funcionan y que te ayudarán a comprender, por ejemplo, lo que venden los proveedores de computación en la nube. Ya sabes, puedes investigarlo. Todos los precios son públicos. Así que puedes ir a Microsoft Azure y ver, “De acuerdo, ¿cuál es el punto de precio para almacenamiento, para CPUs, para máquinas virtuales, para ancho de banda, y demás?” De nuevo, eso es cuestión de unas pocas horas. Diría que existen libros elementales. Quiero decir, hay incluso libros destinados a la secundaria o a la escuela intermedia, y está bien. Ya sabes, se trata de intentar adquirir ese conocimiento.
Y luego, cada vez que surja el tema de una evolución tecnológica, pregunta al proveedor, pregunta al consultor, “De acuerdo, ¿cuál es tu opinión sobre los recursos de cómputo? Queremos tomar las mejores decisiones según cualquier métrica y objetivos que te hayas propuesto.” Involúcrate en la discusión sobre cómo esos recursos de cómputo en bruto que estoy comprando, por un lado, se traducen en las mejores decisiones. Si las personas a las que estás a punto de comprar muchas cosas no tienen ni idea de eso, entonces deberías huir. Ya sabes, esa es mi conclusión. Úsalo como prueba decisiva para detectar a los llamados expertos que ni siquiera deberían ser expertos en primer lugar, que son absolutamente, diría yo, incompetentes.
Porque, en última instancia, si optas por ese tipo de proveedores, terminarás pagando el precio de sus ineficiencias. Y el precio será doble. Por un lado, pagarás mucho más por hardware de cómputo hasta el punto de que resulta extravagante. Como regla general, Lokad, cuando vendemos una suscripción, está muy por debajo del costo de nuestros competidores únicamente en términos de recursos de cómputo, sin siquiera tomar en cuenta la mano de obra o la ingeniería necesaria para configurar y mantener. Simplemente, Lokad tiende a estar por debajo solo del costo del hardware.
Así que ese es un punto. Pero luego tendrás algo incluso mayor, y es que tu proveedor te enjaulará en recetas súper simplistas, tratando de convencerte de que es lo mejor que la ciencia tiene para ofrecer y demás, mientras que en realidad es solo un reflejo de su incapacidad para aprovechar correctamente los recursos de cómputo. Por eso terminas con cosas ultra simplistas como los safety stocks que aún prevalecen. Quiero decir, los proveedores, en el fondo, saben que es una completa porquería. Pero el problema es que son tan ineficientes con el uso de los recursos de cómputo que, para ellos, resultaría tremendamente impráctico siquiera considerar cosas que serían mejores.
Como ves, hay un coste doble: un coste directo, que es gastar de manera extravagante en recursos de computación que no tienen ningún sentido, y luego tienes el segundo orden de coste, que es que te ves encajonado en recetas simplistas donde, en última instancia, como practicante, te verás obligado a intervenir con tus hojas de cálculo para arreglar manualmente toda la locura que generan esos sistemas. ¿Por qué? Porque el sistema utiliza recetas excesivamente simplistas que prácticamente delegan todas las sutilezas en ti, ya que la receta es simplista y no aborda ningún tipo de sofisticación.
Conor Doherty: En realidad, hubo, o mejor dicho, no fue ni siquiera una analogía, sino una regla empírica que usaste anteriormente, o perdón, te interrumpo. Dijiste: “Si no sabes cómo o cuánto cuesta un terabyte de computación en la nube o algo así, si ni siquiera tienes el orden de magnitud, básicamente es un problema.” Y es interesante cuando lo dices, porque la mayoría de las personas en su vida personal, incluso quienes nos escuchan, si entraran a una cafetería para pedir un café y les dijeran, “Bien, eso es €45,” se quedarían perplejos. Se sorprenderían y dirían, “Bueno, eso no está bien. No sé cuánto deberías cobrarme personalmente, pero €45 es un poco exagerado.” Y, presumiblemente, se marcharían y se irían a otro lugar.
Incluso si está en una zona turística, aún dirías, “45, no, eso es incorrecto.” Pero, en última instancia, nada depende de ello. Quiero decir, no te vas a arruinar, presumiblemente no te arruinarás financieramente. No vas a perder tu trabajo por ello.
Sin embargo, el mismo tipo de instinto, instinto de supervivencia, o simplemente la astucia general podría estar completamente ausente cuando se trata de, “Está bien, tengo que tomar decisiones muy costosas sobre qué tipo de recursos de computación o software va a utilizar la empresa.” Los costes directos e indirectos a largo plazo de eso, los costes indirectos a corto plazo y a largo plazo de eso, no se tiene ni idea. Como, “Oh, cuesta 555,000 por segundo de computación o lo que sea.” De nuevo, eso en realidad podría ser correcto. No lo sé, probablemente no. Pero el punto es que, si no puedes responder a esas preguntas, estaría de acuerdo en que hay un enorme vacío en tu propio conocimiento profesional que deberías buscar llenar.
Joannes Vermorel: Sí, de nuevo, quizá sea un poco exigente para los practicantes de supply chain, pero ¿qué está en juego? Grandes líneas presupuestarias. Quiero decir, las grandes empresas están gastando voluntariamente millones y, a veces, decenas de millones de euros o dólares al año en esos sistemas. Y siempre me sorprende completamente cuando se puede gastar tanto y que, como, nadie, proveedor incluido, tenga alguna idea acerca de esos problemas básicos.
De nuevo, eso sería como comprar un edificio, porque eso es algo muy costoso. Es decir, es como comprar un edificio y tener a un arquitecto que no tiene ni idea de lo que realmente es el concreto. Dirías, “¿Sabes qué? No estoy seguro. Tal vez el edificio esté hecho de cartón o concreto, o tal vez de madera o quizá de malvaviscos. Ya sabes, no me importa, solo ponle pintura y todo se ve igual.”
Sabes, de nuevo, creo que el mundo de la computación y el software, ya sabes, la industria del software es muy especial en este sentido. Hay montones de dinero involucrado y existe ese acuerdo implícito de que que todos estén completamente ignorantes al respecto, y está bien. Y esto es, para mí, muy intrigante como industria.
Y he estado hablando con la mayoría de mis competidores, y cuando digo mis competidores, me refiero a los equipos de gestión. Siempre me desconcierta cuando nadie tiene ni idea acerca de ese tipo de simpatía mecánica en la que se posee una comprensión básica de lo que implica.
De nuevo, eso podría ser como, piénsalo como un piloto de Fórmula 1 que dice, “¿Sabes qué? Tengo cuatro ruedas. ¿Qué está pasando entre el pedal y las ruedas? Sabes, es magia, magia. Sabes, hay cosas. Hace un ruido fuerte. Sé que es ruidoso, pero aparte de eso, solo hay cosas.” Sabes, mi visión del coche es que son cosas. Ese es el nivel de granularidad en el que, ya sabes, la gente pensaría que esto es una locura. Deberías saber mucho más si esperas hacer un buen uso del coche.
Y a mi modo, creo que los practicantes de supply chain están utilizando toneladas de herramientas digitales cada día, al igual que un piloto de Fórmula 1 utiliza un coche de Fórmula 1. Y por ello, necesitan entender un poco para tener esa simpatía mecánica de lo que está ocurriendo, cómo funcionan estas cosas, para que puedan tomar decisiones informadas. Al menos, para que la gente no les venda cosas que son completamente ilógicas y que terminan fallando por razones que son totalmente prevenibles.
Conor Doherty: No pude haberlo expresado mejor. Gracias, y muchas gracias por tu tiempo. No tengo más preguntas, y muchas gracias por vernos. Nos vemos la próxima vez.
