00:00:07 Importancia del diseño de software en las cadenas de suministro modernas.
00:01:22 Problemas comunes de diseño de software en la gestión de la cadena de suministro.
00:02:37 Desafíos de los sistemas de software en tiempo real en las cadenas de suministro.
00:04:55 Cómo las operaciones complejas pueden afectar a los sistemas en tiempo real.
00:07:13 Sistemas en tiempo real obstruidos por operaciones no en tiempo real.
00:09:13 Importancia de las elecciones de diseño y la escala de tiempo en el software de la cadena de suministro.
00:12:31 Diferencias entre el software de un solo inquilino y el software de varios inquilinos.
00:14:11 Desafíos con múltiples versiones de software en aplicaciones de un solo inquilino.
00:15:33 Ventajas del software de varios inquilinos y el cambio hacia modelos SaaS.
00:17:56 Importancia de comprender las suposiciones fundamentales en el diseño de software para los profesionales de la cadena de suministro.
00:19:18 Suposiciones de diseño fundamentales de Lokad, incluido el modo de procesamiento por lotes y la multiarrendatario.
00:21:35 Reflexiones finales sobre la comprensión de las elecciones en el software y su impacto en las operaciones futuras.
00:23:36 Reflexiones finales.
Resumen
En una entrevista con Joannes Vermorel, fundador de Lokad, se analiza el impacto del diseño de software en la optimización de la cadena de suministro. Los desafíos a menudo surgen de problemas de diseño en lugar de errores o bloqueos, lo que puede hacer que el software sea lento, poco intuitivo y difícil de configurar. El manejo de datos en tiempo real es una característica clave que puede afectar las operaciones. Sin embargo, centrarse en operaciones rápidas y simples puede obstaculizar procesos complejos como la previsión o el análisis a nivel de red. Es crucial comprender las suposiciones de diseño de software para evitar problemas debido a discrepancias entre el diseño del software y el uso previsto por parte de una empresa.
Resumen Extendido
En esta entrevista, el presentador Kieran Chandler discute con Joannes Vermorel, fundador de Lokad, el impacto del diseño de software en las operaciones de la empresa, particularmente en el contexto de la optimización de la cadena de suministro. Vermorel destaca la importancia del diseño de software en las cadenas de suministro modernas, que dependen de múltiples capas de software, como ERPs, MRPs, WMSs, OMSs y EDIs, para funcionar de manera eficiente.
Los desafíos enfrentados por los clientes de Lokad a menudo se derivan de problemas con el diseño de su software, en lugar de errores obvios o bloqueos. Estos problemas de diseño pueden hacer que el software sea lento, poco intuitivo, lento y difícil de configurar. Como explica Vermorel, estos problemas a menudo resultan de una falta de coincidencia entre las decisiones de diseño central tomadas para el software y la realidad actual de la cadena de suministro a la que se pretende servir.
Una de las características clave de la arquitectura de software que puede afectar las operaciones de la cadena de suministro es su capacidad para manejar datos en tiempo real. Vermorel señala que si bien el procesamiento de datos en tiempo real verdadero no es posible debido a la velocidad finita de la luz, muchos sistemas de software de cadena de suministro están diseñados para aproximar el procesamiento de datos en tiempo real. Por ejemplo, cuando se recoge un artículo de un estante, el software decrementa el nivel de stock inmediatamente. Sin embargo, este enfoque en tiempo real puede tener consecuencias no deseadas.
Cuando el software está diseñado para operaciones rápidas y simples, se vuelve difícil ejecutar operaciones más complejas, como pronósticos o análisis a nivel de red. Estas operaciones complejas requieren un nivel más sofisticado de procesamiento de datos, que puede no ser factible dentro de un sistema optimizado para actualizaciones en tiempo real a pequeña escala.
Joannes Vermorel enfatiza la importancia crítica del diseño de software en la optimización de la cadena de suministro. Los desafíos enfrentados por los clientes de Lokad a menudo se derivan de problemas de diseño que hacen que el software sea lento, poco intuitivo y difícil de configurar, como resultado de una falta de coincidencia entre las decisiones de diseño central del software y la realidad actual de la cadena de suministro. La capacidad para manejar datos en tiempo real es una característica clave de la arquitectura de software que puede afectar las operaciones de la cadena de suministro. Sin embargo, cuando el software está diseñado para operaciones rápidas y simples, se vuelve difícil ejecutar operaciones más complejas, como pronósticos o análisis a nivel de red, que requieren un nivel más sofisticado de procesamiento de datos.
Vermorel explica que los problemas enfrentados por los profesionales de la cadena de suministro que utilizan dicho software no siempre son obvios, ya que a menudo se manifiestan como una acumulación lenta de problemas, a lo que él se refiere como “muerte por mil cortes”.
Un problema clave es la necesidad de funcionalidad en tiempo real en ciertos escenarios, como escanear artículos en una cinta transportadora de alta velocidad. Cuando se introducen operaciones no en tiempo real en el sistema, el rendimiento general puede verse afectado negativamente, lo que resulta en ralentizaciones y retrasos. Esto puede llevar a una mayor frustración entre los usuarios y una menor eficiencia.
Vermorel destaca la importancia de tomar las decisiones de diseño central correctas, que deben estar profundamente alineadas con los problemas que el software intenta resolver. En el contexto del software de cadena de suministro, se hacen varias suposiciones centrales, y si estas no se cumplen, pueden surgir problemas más adelante.
La escala de tiempo en la que opera el software es una consideración crucial. Vermorel describe los diferentes tipos de software necesarios para diferentes escalas de tiempo, que van desde tiempos de respuesta de submilisegundos para conducir cintas transportadoras, hasta la planificación a largo plazo que implica decisiones de ubicación de fábricas que abarcan años o incluso décadas. Cada aumento en orden de magnitud en la escala de tiempo requiere un tipo diferente de software con capacidades únicas.
En Lokad, el enfoque suele estar en escalas de tiempo de un día a un año, lo que requiere un enfoque diferente para el diseño de software. Vermorel también menciona las diferencias entre el software de un solo inquilino y el software de varios inquilinos, que es una consideración crítica para los desarrolladores de software, aunque menos familiar para la mayoría de las empresas.
Discuten las diferencias entre el software de varios inquilinos y el software de un solo inquilino, las ventajas del modelo SaaS y las suposiciones centrales que han guiado el diseño de software de Lokad.
Vermorel explica que el software de varios inquilinos sirve a múltiples clientes utilizando la misma pieza de software, mientras que el software de un solo inquilino implica dar a cada cliente su propia versión personalizada. Lokad es de varios inquilinos, con una base de código actualizada semanalmente. Este enfoque tiene varias ventajas, incluyendo una versión simplificada y menos problemas de seguridad. Vermorel contrasta esto con el software de un solo inquilino, que permite la personalización por cliente pero requiere gestionar múltiples versiones, lo que conlleva desafíos operativos.
Observa que, en la última década, muchas empresas de software serias se han inclinado hacia la multi-tenencia. Para aplicaciones web como Lokad, ser de varios inquilinos es bastante sencillo, pero para el software que opera en las máquinas de los clientes puede ser más complicado. Una solución a este problema es la estrategia “evergreen”, como la ejemplificada por Google Chrome y Microsoft Office 365. Estas aplicaciones se actualizan automáticamente, sin intervención del usuario, mitigando así los problemas de tener múltiples versiones del mismo software.
Al discutir el diseño de software de Lokad, Vermorel enfatiza la importancia de comprender las suposiciones centrales de un proveedor. Advierte contra los proveedores que afirman que su software puede hacerlo todo y enfatiza que el diseño implica compromisos, con aspectos positivos y negativos. Anima a los posibles clientes a preguntar a los proveedores de software sobre sus suposiciones centrales y a tener cuidado con aquellos que solo proporcionan respuestas vagas y positivas.
Las suposiciones centrales de diseño de Lokad incluyen el modo de procesamiento por lotes, que Vermorel explica que se elige porque permite una mejor optimización y gestión de recursos.
Uno de los principios clave es priorizar los cálculos inteligentes sobre la velocidad. Lokad prefiere tener cálculos precisos y detallados aunque lleve más tiempo, en lugar de cálculos más rápidos y menos precisos. El software está diseñado para el procesamiento por lotes en lugar de en tiempo real, lo que permite una mayor expresividad y poder en el análisis.
Otra suposición central es la importancia de la multi-tenencia y aprovechar las capacidades ofrecidas por la computación en la nube. Lokad tiene como objetivo utilizar capacidades de escala horizontal en lugar de escala vertical, lo que significa que utilizan varias máquinas más pequeñas para procesar grandes cantidades de datos en lugar de depender de una sola supercomputadora potente.
Vermorel enfatiza la importancia de que los profesionales de la cadena de suministro comprendan las suposiciones centrales de diseño de su software. Esta comprensión ayuda a prevenir problemas que surgen de una falta de coincidencia entre el diseño del software y el uso previsto por la empresa. Los proveedores pueden afirmar que su software es versátil y adecuado para diversas situaciones, pero en realidad, ciertas limitaciones de diseño pueden obstaculizar su efectividad en algunas aplicaciones.
Transcripción completa
Kieran Chandler: Hoy vamos a entender cómo estas decisiones pueden terminar encasillando a una empresa y también entender algunas de las suposiciones centrales que están detrás de ellas. Entonces, Joannes, estamos hablando un poco sobre cómo un mal diseño de software puede afectar a una empresa. ¿Cuáles son algunos de los desafíos que ves?
Joannes Vermorel: El primer desafío es que el diseño de software es de vital importancia para las cadenas de suministro. Las cadenas de suministro modernas funcionan con software. Tienes camiones, máquinas, cintas transportadoras, pero también grandes cantidades de software como tu ERP, MRP, WMS, OMS, EDI y muchas capas más. Las cadenas de suministro modernas no funcionan sin software en grandes cantidades. Cuando hablo con clientes de Lokad, a menudo luchan contra el panorama aplicativo de la cadena de suministro. Hay muchos problemas relacionados con el software, pero no necesariamente son errores o bloqueos. Los problemas de diseño son mucho más generalizados; hacen que las cosas sean lentas, no intuitivas, lentas y lleva mucho tiempo configurar el sistema. Cuando intentas hacer un análisis de causa raíz, con frecuencia te das cuenta de que los problemas son en realidad problemas de diseño de software donde se tomaron decisiones fundamentales sobre el diseño del software y simplemente no coincidieron completamente con la realidad actual de la cadena de suministro en cuestión.
Kieran Chandler: Entonces, ¿cuáles son algunas características de la arquitectura del software que pueden ser tan importantes? ¿Cuáles son algunos de los desafíos que has visto con tus clientes?
Joannes Vermorel: Digamos, por ejemplo, en tiempo real. Muchos software de cadena de suministro en la actualidad están orientados a operaciones en tiempo real. Por tiempo real, me refiero a que si decides tomar una unidad del estante, se va a decrementar el nivel de stock de inmediato. Parece una cosa muy razonable. Sin embargo, tan pronto como tienes este tipo de software diseñado para tiempo real, cualquier cálculo sofisticado va a ser un gran problema para operar en el software. La razón es porque si tu software está diseñado para ser súper rápido para operaciones súper simples, tener una operación compleja, como un pronóstico o un análisis a nivel de red, va a ser una lucha. Esto se debe a que tu software está diseñado para operaciones muy rápidas y pequeñas, y cuando necesitas procesar una cantidad moderadamente compleja de datos, va a ser difícil.
Kieran Chandler: Y si tienes una versión granular grande, va a ralentizar a todos, incluyendo cosas que deberían ser súper rápidas, como simplemente escanear un código de barras y hacer beep. He escaneado, puedes pasar al siguiente artículo. ¿Qué tan obvios son algunos de estos desafíos? Tienes que simpatizar con un profesional de la cadena de suministro. Quiero decir, hay muchas cosas sucediendo, y con mucho tiempo con este software, hay muchas cosas sucediendo bajo el capó. Entonces, ¿qué tan obvio es que algunos de estos desafíos están ahí afuera?
Joannes Vermorel: No es obvio porque por lo general no es un error obvio donde tu sistema se bloquea. Es más como la muerte por mil cortes. Permíteme ilustrar: tienes este sistema que se supone que es en tiempo real. Cuando se escanea algo en una cinta transportadora de alta velocidad, deberías poder hacer beep a tres artículos por segundo, o algo así. Deberías poder ser realmente rápido y tener un tiempo de respuesta en milisegundos.
Ahora, ¿qué sucede si, de vez en cuando, tienes un cálculo que tarda unos segundos en lugar de milisegundos? Si solo tienes una operación, de vez en cuando, que tarda unos segundos, y tu sistema en tiempo real está diseñado de manera adecuada, probablemente la mayoría de las otras operaciones seguirán siendo súper rápidas, por lo que no afectará tanto. Excepto si no tienes suerte, y al mismo tiempo, tienes como diez operaciones diferentes que tardan varios segundos en calcular. Eso simplemente absorbe, en este punto específico en el tiempo, todos los recursos informáticos.
Entonces, lo que sucederá es que el sistema que se suponía que podía escanear y darte retroalimentación en milisegundos de repente tarda un segundo. No es ideal, pero puedes vivir con eso. Sin embargo, de vez en cuando, tienes esta situación en la que esperabas algo extremadamente rápido, pero de repente hay dos o tres segundos de retraso. Por cierto, a veces incluso puedes ver eso en supermercados locales. Tienes un punto de venta y el beep de los artículos es muy fluido, pero en algún momento, simplemente beep algo y pasan tres segundos, y luego beep.
Aquí tienes un sistema en tiempo real que se ha atascado en una operación que no es en tiempo real. No sé qué fue, tal vez una actualización de Windows o algún tipo de cosa extraña que sucede y ralentiza la máquina. Pero en un sistema en tiempo real, no se te permite hacer nada inteligente o complejo porque eso va a degradar las operaciones súper rápidas que deseas llevar a cabo.
Cuando digo muerte por mil cortes, es porque la primera vez que haces algo que no es en tiempo real en un sistema en tiempo real, probablemente no sucederá nada malo realmente. Es raro, así que estás más o menos bien. Pero el problema es que acumulas más y más cosas que no son en tiempo real, y de repente esos problemas que eran muy poco frecuentes comienzan a volverse más frecuentes y más frecuentes, hasta que se vuelven súper frecuentes. Entonces la gente se vuelve loca y dice: “¿Por qué esta cinta transportadora no funciona más rápido? Podría hacerlo”.
La respuesta es porque hay una máquina que se supone que debe escanear el código de barras, y necesitamos esperar a que el sistema responda. He visto situaciones en las que se tardaba medio minuto en que el sistema respondiera después de escanear un código de barras. Se trataba de imprimir algo para poner en la caja, pero la cinta transportadora estaba limitada por la velocidad a la que el sistema podía enviar la orden a la impresora para imprimir algo en la caja. Tenían personas esperando a que la impresora imprimiera.
Tienes muchas opciones de diseño que necesitan tomar las decisiones fundamentales de manera correcta, de formas que estén profundamente alineadas con los problemas que estás tratando de resolver.
Kieran Chandler: ¿Cuáles son las suposiciones fundamentales clave que se hacen en el software de la cadena de suministro y cuáles has observado que realmente no funcionan?
Joannes Vermorel: Hay muchas formas de abordar esto. Primero, considera la escala de tiempo en la que deseas operar. Tenemos cosas que necesitan operar desde tiempos de respuesta de submilisegundos, que es lo que necesitas para literalmente conducir una cinta transportadora, hasta decisiones en las que necesitas pensar en una década por delante, como la ubicación de fábricas. Cada vez que agregas un orden de magnitud, cambias fundamentalmente el software.
Kieran Chandler: ¿Puedes dar algunos ejemplos de diferentes escalas de tiempo y los tipos de software correspondientes?
Joannes Vermorel: Claro. Los submilisegundos son un tipo de software; de 1 a 10 milisegundos, será otro tipo de software; de 10 a 100 milisegundos, será otro tipo, que típicamente es software ERP con tiempos de respuesta de 10 a 100 milisegundos. De 100 milisegundos a 1 segundo, obtienes el tipo de cosas que puedes encontrar en una aplicación web. Luego, si comienzas a pensar de 1 minuto a 10 minutos por delante, ya no estás en tiempo real, pero puedes comenzar a hacer cálculos sofisticados. Por ejemplo, una aplicación de navegación como Waze necesita proporcionar una ruta en medio minuto pero no necesita ser en tiempo real.
Si estás optimizando una ruta para entregas de camiones, generalmente puedes tomar varios minutos para obtener los resultados, ya que no necesita ser en tiempo real. En Lokad, generalmente nos enfocamos en marcos de tiempo de 1 día a 1 año. Este es nuestro punto óptimo y significa que podemos ignorar prácticamente todo lo anterior. Si vamos más allá de un año, entramos en el ámbito del diseño de la cadena de suministro, que es más centrado en el mapa y cambia el problema.
Kieran Chandler: Hablemos más sobre la implementación del software. ¿Cuáles son las principales diferencias entre el software de un solo inquilino y el software de varios inquilinos?
Joannes Vermorel: La diferencia entre un solo inquilino y varios inquilinos es cuántos clientes atiendes con la misma pieza de software. Si eres de varios inquilinos, como Lokad, es el mismo software que sirve a todos nuestros clientes. Solo tenemos una versión implementada en línea en cualquier momento dado, y actualizamos este software semanalmente. La otra forma, que era más común antes de la aparición de SaaS, es el de un solo inquilino. Este enfoque implica dar a cada cliente su propia copia del software, lo que a menudo resulta en personalización para clientes grandes.
Producir el software significa que de repente terminas con muchas variantes de tu software que simplemente están ejecutándose al mismo tiempo, lo que es un gran problema operativo porque significa que si hay un error que ocurrió en una versión, debes solucionar este error en esa versión, pero debes asegurarte de que el error también se solucione en todas tus otras versiones. Por cierto, este es un problema en el que, para las empresas de software, tienes como anti-economías de escala. Cuanto más grande eres, más problemas tienes con tu versionado. Por cierto, este problema está afectando gravemente a Oracle, por ejemplo, con la base de datos de Oracle. Tienen muchas versiones altamente personalizadas que están optimizadas para el rendimiento. No tengo información privilegiada secreta, pero a partir de la información pública, se puede ver que literalmente, en algunas divisiones de ingeniería múltiple en Oracle, están luchando con el hecho de que tienen muchas variantes del software. Obviamente, Oracle tiene toneladas de capacidades de ingeniería, pero aún así, sigue siendo un gran desafío. Entonces, un solo inquilino te brinda la opción de personalización por cliente, pero luego debes lidiar con los costos adicionales por cliente. Varios inquilinos te brinda el hecho de que tienes una base de código para todos, sin personalización, pero a cambio, puedes evolucionar mucho más rápido y también tener muchos menos problemas de seguridad.
Kieran Chandler: Cuando dices que el mercado se está moviendo mucho hacia ese tipo de modelo SaaS, ¿por qué es que este modelo es mucho mejor? ¿Ofrece un mayor grado de flexibilidad para la empresa?
Joannes Vermorel: Sí, en la última década, prácticamente todos los proveedores de software serios se han movido hacia la multi-tenencia, incluso las aplicaciones de escritorio tradicionales clásicas. Porque obviamente, si eres una aplicación web como Lokad, ser multi-tenant es bastante sencillo. Vuelves a implementar las cosas en tus propios sistemas y listo. Obviamente, cuando tienes software que opera en máquinas cliente, como por ejemplo tu navegador, Internet Explorer o Google Chrome, es más complicado porque no tienes control sobre las máquinas cliente. Pero adivina qué han hecho los proveedores de software. Han cambiado a la estrategia evergreen. Por ejemplo, Google Chrome ya no te pregunta sobre la actualización del navegador. Cuando Google decide que tu versión de Chrome está desactualizada y necesita ser reemplazada, Google actualiza tu navegador a distancia. Obviamente, la próxima vez que te conectes a Internet y demás, no pueden actualizar mágicamente tu software si no tienes conectividad a Internet. Pero suponiendo que tienes conectividad a Internet y no has hecho ninguna trampa específica con tu máquina para evitar la actualización, la actualización ocurrirá, básicamente, sin tu intervención. Y cuando ves lo que Microsoft está haciendo con Office 365, es lo mismo. En el pasado, tenías una serie de versiones de Microsoft Office cuando pasabas de una versión de Excel a la siguiente. Hoy en día, es bajo demanda y Microsoft se encarga de la actualización. Tienes una suscripción, el software está instalado en tu máquina, pero puede actualizarse automáticamente a la siguiente versión. Y si lo permites, a menos que desactives las opciones de actualización, Microsoft está actualizando todas las aplicaciones de escritorio precisamente para mitigar el problema de tener muchas versiones del mismo software.
Kieran Chandler: Hablemos un poco sobre Lokad entonces. Dijiste que había ciertos supuestos fundamentales que se deben hacer en el diseño de software que realmente pueden afectar las operaciones futuras. Entonces, ¿cuáles fueron los supuestos fundamentales que hiciste aquí en Lokad?
Joannes Vermorel: Hay toneladas de ellos, pero antes de entrar en los supuestos fundamentales, me gustaría hacer una observación. Si te encuentras con un proveedor de software que
Kieran Chandler: Que te dice que todo mi software, ya sabes. Somos capaces de hacer todo lo que no hicimos. Ya sabes, suposición de software. Si te dan solo eso, ¿puedo sugerirte, ya sabes, cuando te encuentres con un proveedor de software para tu cadena de suministro, pregúntales cuáles son los supuestos fundamentales? Y si te dicen algo vago como “estamos diseñados para la seguridad”, genial. “Estamos diseñados para la velocidad”, sí, yo también. “Estamos diseñados para la eficiencia de costos”, sí. Ya sabes, estas son cosas super vagas, absolutamente positivas. Pero cuando discutimos el diseño, un punto de vista de diseño es un compromiso. Es algo que tiene aspectos positivos y aspectos negativos. Entonces, si puedes discutir con el proveedor de software y todo lo que pueden darte son los aspectos positivos, probablemente ni siquiera entiendan la naturaleza del diseño de software en primer lugar. Entonces, Joannes, ¿cuáles son los supuestos fundamentales de diseño que construiste en Lokad?
Joannes Vermorel: El primero fue un modo de procesamiento por lotes. Entonces, ¿qué significa eso? Significa que lo que queremos es poder procesar toneladas de datos grandes y hacer cálculos muy inteligentes. Obviamente, porque queremos, preferimos ser muy inteligentes en lugar de ser muy, muy rápidos, lo que significa que, para nosotros, tener cálculos que se ejecutan típicamente en minutos, pero que puedan ejecutarse en segundos, es una especie de bonificación. Pero si no podemos, no es tan importante. Preferimos tener mejores números aunque lleve un poco de tiempo. Por cierto, no es porque haya partes nuestras que miren eso, es solo una presentación de los resultados. Entonces, tal vez necesites como media hora para hacer un cálculo masivo, pero cuando quieras acceder a esos resultados, entonces necesita ser en tiempo real, pero está precalculado. Entonces, ves que fue un supuesto fundamental de diseño. Sin tiempo real, o es por lotes. Y la razón es que queremos poder ser muy expresivos y muy poderosos y así ser tan inteligentes como podamos para, diría yo, análisis a nivel mundial. Entonces, ese es un supuesto fundamental. Otro fue que queríamos tener multi-tenencia. Obviamente, hoy en día, la mayoría de las personas lo están haciendo, pero todavía hay empresas que, especialmente en el espacio empresarial, se están quedando atrás. Y diría que la multi-tenencia se hace con todo.
Kieran Chandler: ¿Puedes explicar la diferencia entre escalable y escalable hacia afuera?
Joannes Vermorel: Las capacidades ofrecidas por la nube significan que queremos tener capacidades de escalabilidad hacia afuera en lugar de escalabilidad hacia arriba. La pregunta es, si quieres procesar terabytes de datos, ¿puedes hacerlo acumulando toneladas de máquinas pequeñas o necesitas una supercomputadora para hacerlo?
Kieran Chandler: Entonces, ¿cuál es nuestra principal conclusión aquí hoy?
Joannes Vermorel: Nuestra principal conclusión es que en términos de los datos que tenemos y en términos de tomar decisiones sobre software, puede encasillar mucho lo que haces en el futuro. Entonces, necesitas entender completamente las decisiones que estás tomando.
Kieran Chandler: ¿Puedes ampliar eso?
Joannes Vermorel: Mi sugerencia sería que los profesionales de la cadena de suministro sean más conscientes de los supuestos fundamentales de diseño que caracterizan su propio panorama aplicativo. Tienen muchas aplicaciones, y ¿pueden darme media docena de supuestos de código críticos que expliquen los entresijos del producto? Puede sonar muy técnico, pero si no entiendes esos supuestos fundamentales de diseño, vas a sufrir mucho cuando te des cuenta de que estás intentando hacer algo para lo cual, por diseño, este no va a ser un buen producto. Con frecuencia, he visto muchas empresas donde literalmente sus problemas surgen de una falta de coincidencia entre el diseño del software y lo que están tratando de hacer con él.
Kieran Chandler: ¿Puedes dar un ejemplo?
Joannes Vermorel: Los proveedores intentan ser muy seguros, ya sabes, como proveedor, intentas vender tu software. Quieres actuar con confianza y decirle al cliente que tu software de cadena de suministro será bueno en todas las situaciones, y que te cubrimos. Pero la realidad es que si un cliente va a usar tu software para algo que está fuera de las capacidades de diseño, no puedes simplemente parchearlo. No puedes simplemente agregar una función. Los ingenieros de software en el backend te dirán: “Jefe, lo siento, no podemos hacerlo. Va a ser un infierno”.
Kieran Chandler: Muy bien, vamos a terminar. Gracias, Joannes. Eso es todo por esta semana. Muchas gracias por sintonizar, y nos vemos la próxima vez. Hasta luego.
