Qué salió mal: SAP S4HANA - Ep 178

00:00:00 Las fallas de SAP desencadenan esta inmersión profunda
00:02:15 Billones perdidos en ERP, solo la punta del iceberg
00:06:15 Los errores de diseño heredados persiguen a los sistemas modernos
00:10:20 La lógica de acaparamiento de tierras detrás de la expansión de ERP
00:12:26 Aplicaciones CRUD y la mercantilización de los ERPs
00:16:30 HANA fue el giro estratégico de SAP hacia la analítica
00:20:38 Por qué las bases de datos tabulares fallan en los informes
00:26:23 Bases de datos columnares: pros y costos ocultos
00:30:21 Apostar por la RAM es la apuesta que falló
00:34:31 Colisiones de rendimiento en bases de datos híbridas
00:40:41 El software híbrido falla en todo
00:42:33 Sistema de inteligencia: un tercer paradigma
00:46:59 Los primeros ERPs falsamente comercializados como inteligentes
00:52:33 Por qué S/4HANA no puede ser todo a la vez
00:58:43 El fracaso de Google con CRUD muestra una falta de coincidencia cultural
01:05:02 La programabilidad es clave para los sistemas de decisión
01:10:38 El fracaso económico del enfoque todo en uno
01:16:30 Por qué la modernización de ERP es tan lenta y costosa
01:22:06 Optimizar decisiones, no solo procesos
01:27:24 Consejos sobre cómo construir tu propia capa de registros
01:34:13 Código abierto y el verdadero costo de la tecnología de commodities

Resumen

En una discusión perspicaz entre Conor Doherty de Lokad y el CEO Joannes Vermorel, profundizan en los contratiempos financieros asociados con las implementaciones de software de SAP. Vermorel aclara los problemas fundamentales de fusionar sistemas de registros, sistemas de informes y sistemas de inteligencia en una sola solución de ERP, lo que conduce a ineficiencias y conflictos. Destacan los costosos fracasos experimentados por empresas como DHL y Lidl debido a las estrategias defectuosas de SAP, especialmente la integración de HANA. Vermorel aboga por sistemas especializados y soluciones de código abierto como PostgreSQL, que ofrecen funcionalidad sólida a costos más bajos, alejando a las empresas de amalgamas de software complejas e ineficaces.

Resumen Extendido

En vista de las recientes revelaciones que muestran una gran cantidad de pérdidas financieras vinculadas a la implementación de software de SAP por parte de grandes corporaciones, Conor Doherty, Director de Comunicación en Lokad, se sentó con Joannes Vermorel, CEO y Fundador de Lokad, para una discusión profunda. Su conversación, que abarca los desafíos del diseño de software empresarial y las trampas de las estrategias ambiciosas pero defectuosas de SAP, ofrece un análisis rico y esclarecedor.

Vermorel explica las sutiles distinciones en los sistemas de software utilizados por las empresas: sistemas de registros, sistemas de informes y sistemas de inteligencia. El problema fundamental surge cuando las empresas intentan amalgamar estos tres sistemas distintos dentro de un paquete de software único, lo que inevitablemente conduce a conflictos e ineficiencias. Este escenario se ejemplifica con la incorporación por parte de SAP de elementos fundamentalmente incompatibles dentro de sus soluciones de ERP, como HANA, lo que resulta en importantes contratiempos estratégicos y operativos con el tiempo.

Los ejemplos de fracasos relacionados con SAP son asombrosos. Como relató Conor, empresas como DHL, Lidl, Spar y Asda han reportado pérdidas que ascienden a cientos de millones de dólares debido a sus implementaciones de SAP ERP. Estas pérdidas son solo una fracción del estancamiento económico más amplio experimentado por estas organizaciones durante los períodos prolongados dedicados a las actualizaciones del sistema. Vermorel señala que tales empresas congelan los esfuerzos de modernización y sofocan otros avances digitales, inflando dramáticamente los costos reales de estos proyectos.

El núcleo del problema, argumenta Vermorel, se remonta a decisiones esenciales tomadas por SAP hace décadas. SAP se centró originalmente en sistemas de registros, esencialmente sofisticados libros electrónicos que pretendían cubrir aspectos integrales de las operaciones de la empresa. Esta estrategia de “apropiación de tierras” llevó a alcances extensos pero también resultó en una comoditización de CRUD (Crear, Leer, Actualizar, Eliminar). A principios de la década de 2000, se produjo un cambio hacia sistemas de informes, lo que llevó a herramientas analíticas sofisticadas pero engorrosas.

Una de las decisiones críticas que tomó SAP fue integrar HANA, una base de datos columnar en memoria diseñada para mejorar las capacidades analíticas pero inadecuada como base de datos fundamental para operaciones transaccionales. Vermorel detalla cómo este error estratégico ha tenido repercusiones generalizadas, ralentizando los procesos centrales y creando problemas de rendimiento que requirieron una ingeniería excesiva y costosa para gestionar.

La entrevista aborda el conflicto inherente entre las necesidades de diseño de diferentes sistemas de software. Los sistemas de registros requieren un procesamiento transaccional rápido y de alta integridad, mientras que los sistemas de informes demandan amplias capacidades de análisis de datos. Combinar estos con sistemas de inteligencia, que buscan automatizar la toma de decisiones a través de la programabilidad, complica aún más la arquitectura de software. Este dilema se asemeja a tratar de construir un vehículo que sea tanto un excelente avión como un fantástico barco, un esfuerzo condenado a resultar en un híbrido mediocre.

Conor menciona el papel de la “simpatía mecánica” en la elección de soluciones de software, esencialmente entender las características inherentes y las limitaciones del software, como las diferencias entre bases de datos tabulares y columnares. Este conocimiento básico podría ayudar a las empresas a evitar decisiones costosas.

Vermorel destaca el potencial de soluciones de código abierto como PostgreSQL. Aboga por aprovechar estos sistemas accesibles y robustos, sugiriendo que su costo modesto y alta funcionalidad ofrecen un camino viable para evitar los problemas ilustrados por los errores de SAP.

En conclusión, la discusión de Vermorel y Doherty subraya una precaución esencial: si bien las soluciones de software ambiciosas prometen unificar diversas funcionalidades bajo un mismo techo, la realidad es que tales integraciones a menudo conducen a una complejidad excesiva y problemas de rendimiento. En cambio, las empresas deberían considerar sistemas especializados hechos a la medida de sus necesidades específicas, beneficiándose del rico panorama de ofertas de código abierto que ofrecen una excelente ingeniería sin los costos exorbitantes asociados. La conversación sirve como un marco orientativo para que las empresas naveguen su transformación digital evitando errores históricos que han demostrado ser económicamente perjudiciales.

Transcripción completa

Conor Doherty: Bienvenidos de nuevo a Lokad. A la luz de las recientes noticias de que algunas empresas muy grandes perdieron cantidades muy grandes de dinero en sus implementaciones de SAP, Joannes y yo decidimos sentarnos a discutir, bueno, qué salió mal exactamente. Joannes describe los desafíos detrás del diseño de software empresarial, así como su perspectiva sobre las diferencias entre sistemas de registros, sistemas de informes y sistemas de inteligencia. Como argumenta Joannes, cuando las empresas intentan producir los tres en una sola pieza de software, comienzan a surgir problemas.

Ahora, como siempre, si les gusta lo que escuchan, suscríbanse al canal de YouTube y síganos en LinkedIn. Y con eso, les presento la conversación de hoy. Así que Joannes, gracias por acompañarme en la Logia Negra. Debería preparar un poco el terreno para ti.

En la introducción, reconocí que una de las razones por las que estamos aquí es discutir sobre algunas empresas muy grandes que perdieron sumas muy grandes de dinero. Ahora, esa es una afirmación muy amplia. Cómo realmente llegamos a tener esta conversación fue a través de una publicación que se volvió algo viral en LinkedIn de Anthony Miller, un amigo del canal, donde recopiló muchas cifras bastante condenatorias relacionadas, en muchos casos, con empresas de miles de millones de dólares informando cientos de millones de dólares de pérdidas que atribuyeron a su implementación de SAP.

Entonces, solo para citar o parafrasear, debo decir, DHL aparentemente perdió más de $370 millones tratando de implementar una solución de SAP e IBM. Lidl en Alemania, ahora antes de que alguien me corrija en los comentarios, es Lidl en Irlanda, es Lidl en el continente pero es Lidl en Irlanda, redujeron sus pérdidas después de gastar medio billón de euros. Entonces, cancelaron la implementación después de medio billón de euros.

SPAR, la cadena holandesa, creo, afirmó haber perdido $109 millones en ventas debido a su implementación de SAP. Entonces, una consecuencia de la implementación. Y ASDA reportó $25.5 millones de inconsistencias de stock entre su ERP de SAP y su WMS. Nuevamente, hay otros, pero el punto aquí es decir que son más de mil millones de dólares o mil millones de euros en pérdidas. Así que no estamos hablando de dinero de poca monta aquí.

Entonces, llego a la pregunta: Joannes, ¿qué está saliendo mal exactamente con estas enormes empresas y sus implementaciones de SAP?

Joannes Vermorel: Y obviamente, el denominador común de todos esos problemas es elegir al proveedor equivocado, SAP. Pero, uh, pero también, creo que desafortunadamente, esos números son solo la punta del iceberg. De hecho, mi observación casual es que las pérdidas son órdenes de magnitud mayores y estas son las que la gente reconoce. Quiero decir, y realmente no reconocen los costos reales.

Simplemente, um, por ejemplo, simplemente, uh, reconocen el hecho de que pagaron dinero por algo que no funcionó. Lo que no reconocen es que generalmente el proceso tomó muchos años para muchos de esos proyectos. De hecho, la empresa estuvo congelada en el tiempo durante medio decenio, a veces una década, donde no podían hacer nada más que centrarse en la actualización del ERP.

Entonces, ves que significa que no solo desperdiciaste cientos de millones, sino que de hecho eso es solo una pequeñez porque lo que hiciste efectivamente fue pausar toda la modernización, toda la digitalización, toda la transformación en curso que podrías haber tenido de otra manera porque tenías que ocuparte de tus actualizaciones de ERP. Y he visto eso muchas, muchas veces donde las empresas optan por un proceso de varios años donde pausan todo por esta cosa que tiene que suceder. El costo es absolutamente gigantesco.

Quiero decir, obviamente es un testimonio de la calidad de esas empresas que incluso sobreviven a este proceso porque, seamos realistas, por ejemplo, en la industria del software, cualquiera que pause su propio desarrollo durante medio decenio simplemente estaría muerto. Quiero decir, serían reemplazados por cosas que están como tres generaciones de tecnologías más allá de ellos. Así que felicitaciones a esas empresas por sobrevivir. Significa que tienen un dominio absoluto de su juego para poder sobrevivir tanto tiempo con un proceso tan disfuncional.

La realidad es que la perspectiva es absolutamente terrible. Y si vamos más allá de este denominador común y queremos examinar la causa raíz, porque culpar a SAP no arroja luz sobre el caso, creo que la causa raíz son una serie de errores que se cometieron hace mucho tiempo, literalmente décadas atrás.

Conor Doherty: ¿Decisiones empresariales o te refieres a errores de software? Cuando dices errores, ¿a qué te refieres?

Joannes Vermorel: Me refiero a errores de diseño estratégico cometidos por personas en SAP que se cometieron hace décadas. Esos fracasos se pueden remontar a errores cometidos hace décadas. Y eso es interesante porque cuando analizas estos fracasos, será el juego de culpas: “El integrador no fue bueno” o “La gestión del cambio no se hizo correctamente en la empresa” o “El departamento de TI de la empresa no estaba al nivel que debería haber estado” o esto o aquello o aquello o aquello. Ya sabes, excusas, excusas, excusas.

Y de hecho, cada fracaso se ve único porque es un desastre muy específico cada vez. Pero nuevamente, esas no son explicaciones satisfactorias. Creo que si realmente quieres entender por qué surgen todos estos problemas, es algo muy específico de esos grandes proveedores de software empresarial. Hay causas raíz claras que se pueden remontar a decisiones tomadas hace décadas. Ahora solo estamos viendo las consecuencias desplegarse.

La audiencia puede que no se dé cuenta, pero cuando operas una empresa de software, debes vivir con tus pecados, con tus errores pasados durante mucho tiempo, posiblemente para siempre. Y eso es muy extraño porque pensarías que el software es completamente mutable, puedes cambiar todo lo que has hecho. La realidad es diferente.

Volviendo a diferir, por lo general, cuando se trata de decisiones arquitectónicas, cuando se cometen errores, puedes quedarte atascado con ellos indefinidamente. Y esos errores simplemente vienen y te persiguen para siempre, y envenenan todo lo que estás haciendo. La gente ve los síntomas, todos los problemas, pero no necesariamente los rastrea hasta la causa raíz, que a menudo es tan antigua que la gente no la ve.

Conor Doherty: Bueno, SAP, para que quede constancia, es una empresa enorme que tiene más de 50 años. Así que cuando hablas de causas raíz y decisiones de diseño estratégico de décadas atrás, vivir con esos errores en 2025, son afirmaciones bastante extremas que requieren pruebas extraordinarias. ¿Puedes darme un ejemplo de qué podría ser una elección de diseño estratégico de la década de 1970 que esté persiguiendo a un ERP de SAP en 2025?

Joannes Vermorel: Entonces, SAP comenzó a finales de los años 70 y son lo que describo como sistemas de registros. Eso es lo que la gente llama ERP, CRM, WMS, todas esas piezas de software, que son fundamentalmente el contraparte electrónico de algo que está sucediendo en la empresa. Esos sistemas de registro, no hay inteligencia; son, diría, libros contables sofisticados. Si retrocedemos en el pasado, los proveedores que tuvieron éxito fueron los que más terreno ganaron.

¿Qué quiero decir con ganar terreno? Si comienzas a gestionar inventario, necesitas gestionar empleados, luego necesitas gestionar pedidos, luego pagos, luego compras, clientes, proveedores, socios, etc. La idea es que debes ir y tomar posesión de la tierra de tener una cobertura completa, una cobertura que sea lo más extensa posible para tus registros. Retrocediendo en el tiempo, digamos los años 80, esta competencia por ganar terreno estaba en marcha. La realidad era que para cualquier empresa que comenzara a adoptar un proveedor dominante (en ese momento podría ser SAP, Oracle o IBM), habría un efecto de ganador se lo lleva todo dentro de la empresa.

Eres una empresa cliente, operas software de un proveedor, tan pronto como comiences a tratar con este proveedor, prácticamente dirigirás todo tu negocio hacia este proveedor. ¿Por qué? Porque en ese momento, la ingeniería de software distribuido era absoluta. Significaba que si todo el software no vivía en el mismo mainframe, estabas jodido. En teoría, podrías hacer redes (estamos en los años 80) y algunos bancos lo estaban haciendo en ese momento, pero era extremadamente complicado, extremadamente costoso.

Realísticamente, la única solución económicamente viable para gestionar inventario y proveedores y conectar los puntos era poner todo eso en el mismo sistema. Por lo tanto, un proveedor para ganar debe cubrir todo. Eso es lo que finalmente haría que los proveedores tuvieran éxito, las personas que desarrollarían lo que se llama ERP y CRM. Esos grandes mega sistemas fueron los que tuvieron éxito, teniendo una cobertura masiva. ¿Qué implica eso? Significa que necesitas cubrir la mayor cantidad de terreno posible y terminas tocando todo.

Ahora, eso no crea mucho incentivo para tener una hiperconsistencia, una hiperintegridad. Realmente se trata de capturar la mayor cantidad de terreno posible lo más rápido posible. En el proceso, lo que las grandes entidades se dieron cuenta es que las aplicaciones CRUD (Crear, Leer, Actualizar, Borrar) son bienes completamente comunes. En el proceso de hacer eso, la industria del software se dio cuenta de que este proceso es un bien completamente común. Si quieres tener un sistema de registros, una aplicación CRUD, es muy simple.

Necesitas una base de datos relacional y un marco para proporcionar una serie de vistas para cada entidad, ofreciendo una interfaz de usuario para ejecutar operaciones CRUD para todas las entidades. Puedes crear un cliente, actualizar un cliente, borrar un cliente, etc. Puedes hacer eso para clientes, proveedores, facturas, etc. Muy rápidamente, esos proveedores se dieron cuenta de que esta cosa es simplemente un bien común. La fase de captura de terreno prácticamente termina en los años 2000. Para el año 2000, no todo estaba cubierto, estaban surgiendo nuevas áreas, por ejemplo, el comercio electrónico.

En ese momento, no estaba allí; necesitas agregar eso. Siempre hay cosas nuevas, pero la mayor parte de la captura de terreno estaba cubierta, lo cual es un problema. Proveedores como SAP vieron que la commoditización estaba llegando con mucha fuerza. Esos sistemas de registros son fáciles y deberían ser muy baratos, muy baratos. Entonces, ¿cómo vas a mantener tus ganancias y márgenes si estás vendiendo una tecnología que es un bien completamente común?

Ahí es donde vieron un rayo de esperanza: sistemas de informes. A mediados de los años 90, surgió una empresa llamada Business Objects, creando el primer gran éxito a gran escala en la venta de tecnología OLAP (Procesamiento Analítico en Línea): un sistema de informes. Esto fue un gran éxito. Business Objects fue adquirida en 2006 o 2007 por SAP. La gente se dio cuenta de que tal vez el valor está más en los sistemas de informes. En ese momento, parecía sofisticado.

Claramente, a diferencia de los registros electrónicos donde una vez que tienes todo lo que hay que saber en la base de datos sobre tus clientes, tu valor es un poco limitado. Se supone que debes proporcionar contrapartes electrónicas para el negocio. Una vez que tienes una representación electrónica satisfactoria del negocio, no hay mucho más que agregar. Solo hay tantas cosas que puedes agregar para describir un producto en tu base de datos, un cliente, etc. En resumen, hay esta tendencia hacia la analítica. SAP se dio cuenta de eso y decidió apostar por esta segunda etapa a partir de 2010 con HANA.

Eso sería, para mí, la raíz de la mayoría de los problemas hoy en día. Creo que proviene de esta decisión de optar por HANA. Volviendo a esta decisión en ese momento, SAP aún tenía un problema estratégico: su dependencia de bases de datos de terceros. En los años 2000, dependían predominantemente de bases de datos de Oracle, un poco de Microsoft e IBM DB2, pero predominantemente de Oracle. Esto significaba que el ERP en ese momento, SAP ECC y todas sus suites (con muchos productos y adquisiciones), dependían de una base de datos de terceros.

Eso era un problema porque una gran parte del valor iba a otra empresa de software. Debido a la commoditización, competir por un mercado en contracción era problemático. SAP decidió implementar su propia capa de base de datos, con el nombre en código HANA. Viendo claramente que querían avanzar fuertemente en esta dirección analítica, apuntaron a un sistema que es columnar y en memoria. Esta decisión sola, en 2010, desencadenó el error.

El ERP S4 se lanzó solo en 2015. Entonces, una vez que tienen su nuevo sistema de base de datos, necesitan unos años para reconstruir su propia tecnología ERP sobre esta nueva base de datos. Pero si retrocedemos en el tiempo, creo que la raíz del error que se está desarrollando en este momento se puede rastrear hasta HANA. Ahora tenemos que entender un poco más. Eso es un poco más complicado, así que tal vez me tome un poco de tiempo para explicar lo que está sucediendo aquí.

Para un sistema de registro, lo que necesitas es una base de datos tabular, es decir, una base de datos tradicional. Entonces, ¿qué es una base de datos tabular? Es una base de datos que tiene tablas donde los datos están organizados línea por línea. Eso es algo que debes tener en cuenta con los sistemas informáticos: la localidad de referencia es extremadamente importante para el rendimiento. Eso significa que cuando deseas acceder a una colección de datos, si deseas tener rendimiento, todos estos datos deben estar ubicados en un solo lugar en el sistema, en el mismo lugar.

Entonces, digamos que deseas actualizar un proveedor. El proveedor tiene muchas piezas de información: su nombre, su ubicación, su certificación, esto, aquello. Quiero decir, puedes pensar en todos los atributos de la entidad proveedor dentro de tu sistema. Será una tabla. Habrá tal vez una tabla llamada “Proveedores”, y esta tabla tendrá docenas, posiblemente cien, columnas. Entonces, si organizas tu base de datos de manera tabular, significa que cuando seleccionas un proveedor, mostrará al proveedor.

Toda la información de un proveedor dado está colocalizada en el mismo lugar dentro de tu sistema. Y si deseas actualizar, lo mismo. Y si tienes una representación tabular de tus datos, es muy sencillo agregar una línea, eliminar una línea. Nuevamente, esas cosas están muy bien colocalizadas. Funciona genial. Entonces, para bases de datos tabulares, para sistemas de registro, son simplemente perfectas.

Pero son completamente malas cuando se trata de análisis. Ese es un problema. Esa es la mediocridad de esas bases de datos tabulares. Es la razón número uno por la que los objetos comerciales, ya sabes, el uno y todas esas herramientas de inteligencia de negocios, tuvieron éxito en primer lugar. Es porque en los años 90, comenzaron a proporcionar lo que se llama OLAP, que son cubos, hipercubos, que viven junto a la base de datos y que son mucho más convenientes para proporcionar análisis.

¿Y por qué es eso? Quiero decir, solo piénsalo. Si deseas ver, digamos que tienes una tabla que son pedidos, y la tabla de pedidos tiene, digamos, una columna que es el monto expresado, digamos por simplicidad, en dólares. Pero la tabla de pedidos de otra manera tiene como 100 columnas. Ahora deseas calcular cuántas ventas en dólares tuviste el año pasado. La realidad es que si deseas calcular este volumen de negocios del año pasado, que es solo una suma de la columna, ya sabes, montos, podrás, si tienes una base de datos tabular, analizar prácticamente toda la tabla. Tu sistema recorrerá cada línea, pero como resultado, no podrá aislar la columna de monto porque está completamente en medio de todas las demás.

Entonces, para calcular esta adición de esta única columna, terminas viendo toda la tabla, lo cual puede ser cientos de veces más información que la cifra que deseas para cada línea, lo que ralentiza enormemente el sistema. Ahora, hay una solución, y es organizar la base de datos en un formato columnar. Entonces, ¿qué significa eso? Que en lugar de agrupar o empaquetar los datos línea por línea, los empaquetas por columna.

De repente, si deseas seleccionar una columna y realizar una operación como, “Quiero sumar todo lo que está en esta columna”, se vuelve súper rápido porque tienes acceso a esta columna de forma aislada. No necesitas tener el ID de pedido, el ID de cliente, el ID de producto y todas esas otras columnas que encontrarías en la tabla de pedidos. Aislarás la única columna que deseas. Lo mismo si deseas hacer una selección por fecha, podrás seleccionar la columna de fecha y aplicar tu filtro.

Va a ser órdenes de magnitud más eficiente. Eso es muy genial. Entonces, y por cierto, este formato columnar es históricamente, ya sabes, cuando las personas comenzaron a hacer análisis empresarial, comenzaron con hipercubos, esas tecnologías OLAP. Pero muy rápidamente, hacia finales de los años 2000, las personas se dieron cuenta de que las bases de datos columnares eran simplemente mejores. Así que hubo una fase en términos de tecnología donde los objetos comerciales estaban lidiando con hipercubos, y la tecnología se transformó muy rápidamente en una versión superior de eso, que eran las bases de datos columnares.

Bien, ahora las bases de datos columnares son mucho mejores para análisis. Así que para todos esos sistemas de informes, esa es una noticia fantástica. Tenemos algo que es mucho mejor para la audiencia. Por cierto, una base de datos columnar sería, por ejemplo, Spark, una implementación de código abierto que proporciona una base de datos columnar.

Eso es una escalabilidad increíble con la que lidiar, y es muy, muy eficiente en términos de rendimiento. Ahora, no significa que esta cosa no venga con un trade-off. El trade-off es que una base de datos columnar es una porquería completa para un sistema de registros. Es decir, por diseño, eso va a ser en dos frentes. Primero, si organizas tus datos en columnas, entonces cada vez que desees actualizar una línea, terminarás tocando muchas columnas. Debes identificar la posición correcta en cada columna, y si tienes 100 columnas, eso significa que tendrás 100 lugares distintos en tu sistema para actualizar.

Mientras que en el pasado, con tu base de datos tabular, podías hacer una actualización; sería solo local. Pero aquí, tus datos están organizados en columnas. Entonces, si deseas actualizar un registro, se distribuirá en muchas columnas. Será órdenes de magnitud menos eficiente. Nuevamente, aquí no hay almuerzo gratis. O bien organizas tus datos como un sistema tabular, y eso es genial para sistemas de registros, o haces columnar, y eso es genial para sistemas de informes. No puedes tenerlo de ambas maneras.

SAP decidió apostar por completo por HANA, que era una base de datos columnar. Creo que esa fue la decisión sola que marcó el destino de todo lo que estaban haciendo como capa fundamental, que eran los sistemas de registros.

Conor Doherty: Bueno, solo para intervenir porque se cubrió mucho, eso fue bueno, gracias. Pero solo en caso de que, para situarme como alguien que podría estar escuchando esto ahora, podrían decir: “¿Estás afirmando seriamente que DHL y Spar y Asda perdieron, en total, mil millones de dólares en inventario o simplemente dinero tratando de implementar solo por errores analíticos columnares versus tabulares? Esa es la causa raíz del problema. ¿Se está haciendo esa afirmación?”

Joannes Vermorel: En gran medida, sí. Quiero decir…

Conor Doherty: Fundamenta eso para mí.

Joannes Vermorel: Sí, la cuestión es que cuando tienes errores arquitectónicos críticos, tienden a salirse de control causando miles de efectos secundarios. No es porque algo sea súper caótico y complejo que la causa raíz sea en sí misma algo muy complicado y caótico. Un ejemplo sería la rotación de la Tierra. La Tierra en comparación con el Sol tiene una inclinación en su eje, lo que causa un sistema súper complicado de estaciones con períodos de calor y frío, vientos y un montón de cosas que son solo una consecuencia de esta simple inclinación.

Entonces puedes tener una causa raíz que es extremadamente simple, pero cuando miras las consecuencias, son increíblemente complejas y variadas, y sin embargo se puede rastrear hasta algo muy simple.

Conor Doherty: Estoy de acuerdo, y ese es un encantador ejemplo astronómico.

Joannes Vermorel: Aquí, esto significa que al tomar una decisión que es positiva para sus análisis pero perjudicial para su sistema de registros, han creado un sistema increíblemente lento. Aquí también podemos ver el tipo de apuesta que SAP hizo en 2010. No solo lo hicieron columnar; también lo hicieron en memoria. Ese fue otro error. La idea de hacerlo en memoria significa que dijeron que todos los datos vivirían en DRAM, esencialmente el tipo de RAM que tienes para servidores.

El pensamiento de la época era que la DRAM se volvería increíblemente barata y mucho más rápida en el futuro, lo cual sería genial. Las empresas de software tienden a decir: “Tenemos un problema de rendimiento ahora, pero si tomamos las decisiones correctas, el progreso de la industria del hardware anulará este problema para nosotros en el futuro”. Creen que si el hardware informático se vuelve cien veces más rápido o mejor en la dirección correcta, entonces cualquier problema de rendimiento que tengan ahora podría desaparecer en unos pocos años.

Microsoft fue notorio por hacer eso durante mucho tiempo. Lanzarían software que apenas funcionaba en cualquier máquina, luego, unos años más tarde, todo era más rápido y el software funcionaba perfectamente. El problema es que desde 2010, la RAM no ha progresado casi tanto en una década y media. Progresó, pero solo un poco en comparación con todo lo demás, especialmente en comparación con otras formas de almacenamiento de datos como los SSD.

La RAM apenas se movió en términos de costo, velocidad, latencia y todo, pero las unidades de estado sólido (SSD) mejoraron en un factor de más de mil durante el mismo período. Así que apostaron a que esta tecnología mejoraría en órdenes de magnitud, pero no lo hizo, y lo más probable es que no lo haga por muchas razones. Otras cosas están progresando como locas en la informática.

Las tarjetas gráficas utilizadas, las GPUs utilizadas para la IA, están progresando enormemente. Quiero decir, hay muchas otras áreas que están progresando enormemente, pero esta no lo hizo. Y el problema fue que el sacrificio que estás haciendo si utilizas tu base de datos haciéndola columnar para ejecutar un sistema de registro es que tu latencia va a ser horrible.

Las cosas van a ser lentas prácticamente por diseño. Y eso ya era un problema con el cuello de botella del diseño tabular. Eso ya era un problema, pero aquí lo estás empeorando mucho, mucho más. Lo que significa que como consecuencia de eso estarás apagando incendios todo el tiempo para mitigar todos los problemas que son causados en primer lugar por tu arquitectura incorrecta.

Conor Doherty: Bueno, eso presenta la transición perfecta porque estaba a punto de decir lo mismo. Si aplicas lo que acabas de describir: el sistema de registro y el sistema de informes, el sistema de registro, tu ERP, en un caso de uso concreto escaneas códigos de barras y el sistema se actualiza para que sepas cuánto de una cosa tienes en tu almacén en cualquier momento o cuánto tienes en la tienda. Vale, genial. Eso requiere una latencia bastante baja, supongo?

Joannes Vermorel: Absolutamente.

Conor Doherty: Vale, genial. Ahora, ¿qué pasa con la estructura de diseño para ese sistema de registro significa que o viene con el peligro o viene con el costo de un buen sistema de informes, que es solo para fines de informes comerciales esencialmente? ¿Dónde está la lucha? Porque me estás diciendo que hay una lucha, pero no entiendo en términos… Quieres que el sistema, quieres que tu núcleo racional sea súper rápido cuando se trata de escanear el código de barras. Así que escaneas el código de barras y suena, la cosa es reconocida, todo está bien. El código de barras existe en tu sistema. Todo. Ese es el pitido que obtienes, el sistema reconoce que todo está registrado. Estamos bien. Avanzamos. Perfecto.

Joannes Vermorel: Ahora el problema es, en primer lugar, si optas por una configuración columnar, esta operación, que es simplemente reconocer que acabas de escanear algo, va a ser mucho más lenta por definición porque va a haber docenas de información que tienen que conectar los puntos con muchas columnas que están desconectadas en tu sistema.

Así que tienes eso como el primer obstáculo que hace que tener un sistema tan rápido sea mucho más difícil por diseño porque, nuevamente, las bases de datos columnares son excelentes para análisis a gran escala. No son rápidas. No hay nada en esas bases de datos que esté realmente diseñado para bajas latencias. Eso no es para lo que han sido diseñadas. El diseño mismo es un poco antagonista a eso.

Ahora el problema se agrava por otra cosa, que es que estás afirmando que tu capa de base de datos se utilizará como la misma que estás utilizando para tu sistema de registros. Así que las cosas que están gestionando tu inventario, los empleados que fichan, todo donde quieres una precisión absoluta exactamente. Y también quieres una capacidad de respuesta extrema cuando alguien está fichando y acreditando.

No quieres que el sistema diga “Dame 20 segundos mientras averiguo si eres un empleado real y si realmente puedes acreditar hoy”. ¡No! Quieres que esto sea súper rápido. ¡Acreditar, beep, inmediatamente! De lo contrario, todo se ralentiza.

Ahora, el problema es que el mismo sistema, porque lo has diseñado como una base de datos columnar con la intención explícita de querer hacer análisis. Entonces tú, el sistema de registros para el sistema de informes, sí. Lo que va a suceder es que la gente va a hacer informes. Dices, “Ok, tenemos este sistema que está literalmente diseñado para que podamos hacer análisis sofisticados. ¡Hagamos análisis sofisticados!”

Pero, ¿cuál es la consecuencia de los análisis sofisticados? La consecuencia es que haces operaciones donde escaneas, donde tienes que procesar cantidades muy grandes de datos. Y eso es completamente antitético a la baja latencia. Tienes este núcleo de base de datos que se comparte entre todos los procesos. Tiene que ser compartido porque de lo contrario no tienes integridad. La gente no tiene la misma visión de cuál es el nivel de stock actual.

Si no tienes la misma visión sobre cuál es el nivel de stock, significa que alguien en el sitio web puede pedir una unidad que no tienes porque alguien más ya eligió esta unidad y hubo retrasos en propagar esta información. El comercio electrónico cree que todavía queda una unidad cuando no hay ninguna. ¡Eso es un gran lío!

Entonces necesitas tener esta integridad para que no termines con un montón de problemas estúpidos. Ahora tu recurso de base de datos relacional se comparte entre cosas que son muy ligeras y que necesitan ser súper rápidas y cosas que son súper pesadas: tus informes donde dices “Analiza todos los clientes que han hecho más de tres compras el año pasado por categoría” y lo que sea.

Así que tienes solicitudes que son intensivas en cómputo, que pasan por una parte considerable de todos los datos que tienes. Esa es la antítesis. Ese es todo el punto de hacer análisis. El análisis no se trata de buscar este SKU o este cliente. El análisis se trata de escanear cada cliente para tener estadísticas sobre esto y aquello.

Voy a escanear todo mi historial de ventas en los últimos años para analizar una cuestión de tendencias. Así que tienes los mismos sistemas donde tienes muchas operaciones que son muy codiciosas. Y de nuevo, ¿cómo mitigas el hecho de que daña por completo tu latencia?

Quiero decir, la respuesta es que lanzas hardware al problema. ¿Qué tipo de hardware necesitas lanzar al problema? Bueno, necesitas lanzar memoria porque decidiste en 2010 que sería un sistema columnar en memoria. ¡Mala suerte!

Si el mundo hubiera tomado una dirección diferente, si la DRAM se hubiera vuelto mil veces más barata y rápida, esa sería la elección perfecta. Pero no sucedió y lo más probable es que no suceda. Quiero decir, esta tecnología, la DRAM, sigue progresando pero en ninguna parte tan rápido como la mayoría de las otras tecnologías en hardware informático.

Es una de las tecnologías que está progresando más lentamente, especialmente en cuanto a latencia, donde apenas ha avanzado en casi dos décadas. Incluso hay clases de cosas, especialmente en el frente de la latencia, donde no debes esperar ninguna mejora en el corto plazo.

Habrá muchas mejoras, pero no en este frente. Así que las personas que se comprometieron por completo, como jugando al póker y apostándolo todo, pero sus cartas no son buenas en absoluto. Eso es más o menos lo que sucedió en 2010. Y vemos las consecuencias desplegándose de formas muy diversas hoy en día.

Conor Doherty: Nuevamente, quiero intentar resumir tanto como pueda. Corrígeme si me equivoco. Las decisiones de diseño que uno toma para destacar en la primera clase de software, el software empresarial que describes como sistemas de registro, son antitéticas a las decisiones de diseño que tomarías si quisieras destacar en una pieza de software analítico como un sistema de informes.

Y tratar de hacer ambas cosas, hibridando, como dijiste, intentar hacer ambas cosas simultáneamente resulta en esencialmente una lucha de poder donde podrías hacer ambas cosas, pero las harás menos bien de lo que lo harías si las hicieras individualmente.

Joannes Vermorel: Más o menos, sí. Exactamente. Quiero decir, ese es el problema: no puedes tener algo que sea tanto un barco muy bueno como un avión muy bueno. Es una cosa u otra. Si intentas hacer ambas cosas, es posible, pero será un mal barco y un mal avión.

Conor Doherty: Bueno, porque nuevamente estoy familiarizado con el blog donde presentaste por primera vez este concepto, va a ponerse un poco más complicado en un momento. Pero antes de hacerlo, cubramos el terreno o resumamos el terreno que hemos cubierto. Utilizas la analogía de correr y levantar pesas. Las cosas que te hacen muy bueno, y me gusta eso porque la analítica se trata de abarcarlo todo. Me gustó la idea de levantar pesas como analogía.

Puedes ser un levantador de pesas muy, muy bueno. Si quieres levantar 200, 300 o 400 kilos del suelo, necesitas ser grande para hacerlo. Es un movimiento basado en la fuerza. ¿Correr 100 metros en menos de 10 segundos? No lo harás si pesas 150 kilos; simplemente no va a suceder. Así que puedes ser muy bueno en correr ejercicio aeróbico, o puedes destacar y ser de clase mundial en ejercicios de levantamiento de pesas anaeróbicos. No puedes ser ambos, y si intentas ser ambos, realmente no destacas en ninguno.

Joannes Vermorel: Sí, eso es exactamente correcto. Sí, bueno, la cosa es que nuevamente, porque estoy familiarizado con donde presentaste esta perspectiva, en realidad hay una tercera categoría para las clases de software empresarial. Porque hemos cubierto nuevamente los sistemas de registros, los ERPs, registrando listas de datos, unidades de stock en mano, tienes tus sistemas de informes, herramientas de BI básicamente para fines analíticos y de presentación. Hay una tercera clase de software que aún no hemos tocado.

Conor Doherty: ¿Qué es eso?

Joannes Vermorel: El tercero son los sistemas de inteligencia. Lo interesante es que un sistema de inteligencia, a diferencia de las dos primeras clases, tiene como objetivo tomar decisiones directamente. Eso es todo. Lo interesante es que si observas la historia del software empresarial desde el principio a finales de los años 70, todo el software empresarial siempre se ha comercializado como sistemas de inteligencia, lo cual es bastante desconcertante.

Así que no importa si lo que estás vendiendo es un sistema de inteligencia o no. Mientras apuntes a las empresas, se comercializará como un sistema de inteligencia: mejores decisiones para ti.

Conor Doherty: Sí, y eso es muy desconcertante. Veamos, por ejemplo, el software de gestión de inventario. Efectivamente, esto es solo un libro mayor. Simplemente cuenta cuánto tienes en stock. Cuando seleccionas algo, disminuye tu stock. Cuando pones algo, aumenta el stock. Eso es todo. No hace nada más que ser un reflejo electrónico de tu stock.

Joannes Vermorel: Esos productos invariablemente se comercializaban como “Tendrás menos faltantes de stock y menos excesos de stock”, lo cual no tiene nada que ver con el libro mayor en sí.

Conor Doherty: No, quiero decir, podrías decir que tendrás más eficiencia al llevar la contabilidad de tu inventario. Puede que tengas menos errores de oficina, pero ¿por qué creerías que vas a tomar mejores decisiones de inventario? El software no hace eso. Solo te dice lo que tienes. Simplemente te permite tomar tus decisiones, tal vez de una manera ligeramente mejor.

Pero es como si pudieras jugar al ajedrez en un tablero de ajedrez real o en un tablero de ajedrez de computadora. Ciertamente, si quieres hacer un seguimiento de todos tus juegos anteriores, la versión electrónica es más conveniente, pero el hecho de que esté en una computadora no te convertirá en un mejor jugador de ajedrez. Lo más probable es que incluso sea una distracción que en realidad te convierta en un peor jugador de ajedrez.

No es seguro que las decisiones que estás tomando con una computadora sean automáticamente mejores solo porque estás interactuando con una computadora en lugar de hacerlo con un bolígrafo en papel. Puede suceder, pero no está diseñado para hacerlo lógicamente. Incluso argumentaría que mi propia experiencia casual es que cuando le pides a la gente que realmente piense en algo, una pantalla de computadora es una distracción por regla general.

Diría que si realmente quieres tomar buenas decisiones, no estoy seguro de que una pantalla con una gran cantidad de desorden ayude a enfocarse y realmente pensar detenidamente.

Joannes Vermorel: Esa es una afirmación muy audaz. Solo para ser claro, no estamos desestimando el valor de un sistema de registros. El punto, según entiendo, es no confundir tu sistema de registros y sus capacidades con las capacidades de un software que está explícitamente diseñado para producir decisiones.

Para defender a esos primeros vendedores de software empresarial, era extremadamente confuso. Lo que nos resulta muy claro ahora: esos sistemas de registros, aplicaciones rudimentarias, sistemas de informes con todas las herramientas de inteligencia empresarial y análisis moderno, y luego sistemas de inteligencia donde tienes capacidades de predicción, capacidades de optimización, con la idea de automatizar literalmente los procesos de toma de decisiones, este tipo de clasificación era simplemente super confusa en ese entonces.

Estaban tratando de hacer las tres cosas, y en los años 70, los primeros sistemas de gestión de inventario se comercializaban como “Automatizaremos directamente todas las decisiones de inventario”. Se comercializaban de esa manera. La comunidad se dio cuenta de que era muy fácil gestionar el inventario. Gestionar en el sentido de que incluso hay un giro en el término gestión.

Cuando la gente decía gestión de inventario en los años 70, se referían a todas las cosas que haría un gerente, y un gerente no solo se dedicaría a la contabilidad. También tomaría decisiones sobre el inventario. Así que la gente decía que cuando pensaban en la gestión de inventario, pensaban en algo que haría todo el paquete: hacer un seguimiento del inventario y tomar todas las decisiones relevantes. Resultó no ser el caso.

Por eso hemos subdividido el dominio en gestión de inventario, optimización de inventario—la optimización perteneciente al sistema de inteligencia. Pero en ese momento, era super confuso. Lo mismo con el análisis—puedes mostrar cosas, pero la gente no se había dado cuenta de lo grandes que crecerían las bases de datos y todos los desafíos que tendrías para producir estadísticas a partir de ellas.

Tener estadísticas ya era posible desde el principio. Esos sistemas típicamente se ejecutaban durante la noche, pasando una vez por toda la base de datos para recopilar estadísticas. Así que era posible, incluso con una base de datos tabular, podrías tener lotes nocturnos que recopilarían las estadísticas que buscabas, pero era muy incómodo porque era muy lento.

Tenías que preparar tu lógica con anticipación, y una vez que tenías tu lógica, tenías que esperar hasta el lote nocturno para que se ejecutara. Solo te dabas cuenta de que tenías un error tipográfico en tu código al día siguiente. Operativamente, era una pesadilla. Era posible, pero la cantidad de fricción era simplemente excesiva.

Por eso esas herramientas como Business Objects desarrollaron esencialmente tecnologías OLAP con hipercubos, donde podías tener en cuestión de segundos algunos análisis. Esto fue un cambio de juego completo porque de repente no tenías que pasar por, digamos, implementar algo y esperar hasta mañana para ver si te equivocaste. Podías hacer eso a 100 veces la velocidad que podías hacerlo antes.

Conor Doherty: Anteriormente, mencionaste S4/HANA, que se lanzó en 2015. En el momento de grabar esta conversación, casi tiene diez años—creo que fue hace diez años, hace dos días. Ahora, después de revisar el material de marketing al respecto, en particular usando tu clasificación, se presentó como teniendo todas las capacidades de un sistema de registros, un sistema de informes y, a través de su toma de decisiones impulsada por IA, un sistema de inteligencia. Así que cubriste los problemas creados al intentar combinar sistemas de registros y sistemas de…

Joannes Vermorel: Algunos análisis fueron, diría, un cambio de juego completo porque de repente no tenías que pasar por, sabes, implementar algo y esperar hasta mañana para ver si te equivocaste. Solo para reiterar, podías hacer eso a 100 veces la velocidad que podías hacerlo antes.

Conor Doherty: Bueno, nuevamente, anteriormente mencionaste SAP S/4HANA, que se lanzó en 2015. De hecho, en el momento de grabar esta conversación, casi tiene 10 años—creo que, hace 10 años, hace dos días. Ahora, después de revisar el material de marketing al respecto, en particular, usando tu clasificación, se presentó básicamente como teniendo todas las capacidades de un sistema de registros, un sistema de informes y, a través de su toma de decisiones impulsada por IA—un sistema de inteligencia. Ya has cubierto los problemas cuando intentas hacer sistemas de registros y sistemas de informes simultáneamente. ¿Qué sucede cuando intentas hacer las tres cosas bajo un mismo techo?

Joannes Vermorel: Sí, quiero decir, aquí estamos tratando de ser un tren, un barco y un avión al mismo tiempo, así que es aún peor. Sabes, es como entrar en el territorio de Frankenstein donde va a ser realmente feo. La realidad es que todo está un poco en tu contra como proveedor de software si intentas hacer las tres cosas. Solo pausa un segundo para darte cuenta de lo que implica exactamente.

Un sistema de registros, típicamente cobrarías por operador, por asiento, por usuario. Esa es la forma en que vendes este tipo de cosas hoy en día; ese sería un métrica muy típica. Si estás haciendo un sistema de inteligencia, eso no tiene sentido porque de alguna manera eliminas a los usuarios. Oh sí, ese es tu objetivo—quieres tomar decisiones acertadas. Así que obviamente, cuanto mejor seas, menos usuarios tendrás. En última instancia, solo tendrías un puñado de usuarios en la empresa cliente solo para supervisar tus decisiones y listo. Entonces, si estás cobrando por usuario, esto no va a funcionar; tienes un antagonismo en términos de incentivos. Pero obviamente, es solo un detalle; hay muchos otros problemas.

El problema es que el tipo de ingenieros de software que necesitas no son los mismos. Por cierto, creo que una empresa, esa empresa de software, que sufrió un problema masivo por el problema opuesto, fue Google. Google fue pionero en cosas que estaban muy en el campo de los sistemas de inteligencia. ¿Cuál fue la decisión inteligente tomada por Google en ese momento? Esa fue la búsqueda; aquí está mi consulta, identifica cuál es la más relevante de mil millones de sitios web. Esa es una decisión que se toma, y tiene que hacerse de manera muy inteligente. Google hizo su fortuna teniendo esas decisiones tomadas de manera extremadamente bien—al menos mejor que su competencia. Construyeron toda una fuerza laboral en la idea de que tendrían ingenieros muy inteligentes abordando problemas muy difíciles porque la toma de decisiones, la característica es que son casi muy difíciles.

Es por eso que quieres delegarlas a una computadora. Si no fueran difíciles, ni siquiera calificarían como una decisión. Si algo es solo una cuestión de aritmética simple, dirías “Bueno, es solo un cálculo básico, no hay nada que ver aquí, sigue adelante.” Google contrató a toneladas de ingenieros capaces para hacer esos sistemas sofisticados. Cuando se trataba de desarrollar sistemas de registros, que son mundanos, aburridos y repetitivos, bueno, fracasaron.

Si miras la historia de Google, todo lo que era mundano fue desechado. Tenían Google Reader, un lector de blogs, que fue ampliamente adoptado. Era simple, una aplicación rudimentaria, pero una aplicación rudimentaria no es suficiente para Google, así que la descartaron. Tenían docenas de productos similares donde si es una aplicación rudimentaria—rudimentaria en el sentido de Crear, Leer, Actualizar, Eliminar—la lanzaban pero no podían mantenerla porque estaba por debajo de ellos.

Este es un problema real cuando toda tu empresa está orientada a desarrollar sistemas de inteligencia: tu fuerza laboral de ingeniería no está interesada en hacer un trabajo tedioso y repetitivo. Por el contrario, si has estado viviendo durante décadas haciendo sistemas de registros, tu fuerza laboral simplemente está acostumbrada a crear miles de pantallas, reconociendo “Bueno, este software necesitará 5,000 o 20,000 características distintas, todas individualmente súper fáciles sin ningún desafío en absoluto,” pero aún así necesitan hacerse.

En cuanto a la fuerza laboral de ingeniería y la cultura, es completamente diferente. Mi percepción es que SAP terminó con una fuerza laboral orientada hacia esta mentalidad de acaparamiento de tierras—vamos a tener un millón de ingenieros que pueden hacer un millón de pantallas y un millón de características, todas ellas súper simples individualmente. Luego intentan dar el salto a los sistemas de inteligencia, y fallan de manera muy grave.

Un área donde puedes ver a personas que son buenas en sistemas de inteligencia es que logran avances tecnológicos, y se filtran en forma de proyectos de código abierto. Google, por ejemplo, puede haber fallado en mantener aplicaciones rudimentarias, pero tuvo éxito en lanzar valiosas piezas de tecnologías de código abierto, muy intrincadas y difíciles de ingeniar debido a su talentosa fuerza laboral. Si miras a SAP, no estoy seguro de poder mencionar siquiera un solo proyecto de código abierto de interés que haya surgido de SAP como comparación.

Conor Doherty: Bueno, me doy cuenta de que hemos pasado bastante tiempo delineando la estructura de los sistemas de registros y los sistemas de informes, pero en realidad no hemos cubierto exactamente cuáles serían las elecciones de diseño arquitectónico estratégico—las elecciones de diseño arquitectónico estratégico—para un sistema de inteligencia y por qué eso sería incompatible con las otras dos arquitecturas. Por ejemplo, Lokad es un sistema de decisiones, un sistema de inteligencia; ¿qué hay en su composición que significa que intentar cuadrar eso con un sistema de registros sería problemático, por decirlo suavemente?

Joannes Vermorel: Diría que un sistema de inteligencia, en sus fundamentos, tiene algunas similitudes con un sistema de informes. Quieres esta representación columnar; eso tiene mucho sentido para el análisis. Pero luego, lo que quieres de un sistema de inteligencia es la programabilidad muy rápida. Si quieres la flexibilidad para ingeniar un proceso de toma de decisiones, necesitas algo extremadamente expresivo. Por cierto, es por eso que las hojas de cálculo de Excel se utilizan con frecuencia para respaldar procesos de toma de decisiones; con Excel, obtienes un lenguaje de programación, que es muy importante.

Las fórmulas de Excel pueden ser arbitrariamente complejas, y si eres sofisticado, incluso puedes programar a través de VBA o Python. Excel es programable, y por eso se usa con frecuencia como una herramienta para respaldar sistemas de inteligencia. Necesitas programabilidad, que es un juego completamente diferente en comparación con los sistemas de informes donde debería ser accesible para todos. Estás en el territorio de WYSIWYG (Lo que ves es lo que obtienes); tienes interfaces elegantes, que es el mundo de los sistemas de informes.

Conor Doherty: También me doy cuenta de que hay una perspectiva económica aquí que aún no hemos tocado. Y de nuevo, eres un hombre de economía, un hombre de Thomas Sowell.

Me doy cuenta de que, ya sea en términos de software una decisión inteligente intentar comprar una solución tres en uno donde tienes tu sistema de registros, informes e inteligencia juntos. Podemos dejar eso a un lado. ¿No hay un argumento económico que diría que como conjunto de compensaciones, podría ser más barato comprar básicamente una pieza de software que al menos alega poder hacer las tres cosas en lugar de tres suscripciones separadas a tres piezas de software separadas, tres problemas separados, teniendo que capacitar a todos para usar tres cosas separadas?

Joannes Vermorel: Sí, quiero decir, esa es literalmente la historia del F-35. Estás hablando de este avión de combate estadounidense que será el avión más caro de la historia. El problema es que esas cosas no son lineales.

Si dices, “Quiero que mi avión sea súper bueno en combate cercano, súper bueno en operaciones de largo alcance y sigiloso, y que pueda despegar verticalmente”, terminas con algo donde cada vez que agregas una característica, estás duplicando el precio de todo el conjunto.

Así que al final, terminas con un avión que cuesta el precio típico de quizás otros diez aviones: uno para operaciones de largo alcance, uno para combate táctico con otro avión, uno para ser sigiloso, uno para despegue vertical. No necesariamente necesitas tener todo eso, etc. etc. Entonces, ves, no es lineal. No puedes simplemente tener todas esas cosas en una configuración.

Ahora, podrías decir que si SAP hubiera decidido tener tres sistemas completamente independientes: uno que lidie con el sistema de registros, otro que lidie con el sistema de informes, el tercero que lidie con el sistema de inteligencia, y pones muros chinos entre todas esas divisiones y operan de forma independiente, eso podría haber funcionado. Pero no es lo que se hizo.

La tentación era demasiado fuerte para juntar todo, incluidas las soluciones de terceros que se adquirieron. La mezcla es simplemente tóxica. Tomas productos que se mezclan muy mal y obtienes algo disfuncional. Creo que eso es lo que estamos viendo en este momento.

Volviendo a la línea de tiempo, tuvimos HANA en 2010. Les llevó cinco años implementar S/4 sobre eso. La mayoría de esos fracasos literalmente llevaban una década en gestarse. Estamos viendo cosas que tardaron una década en desarrollarse.

Estamos viendo fracasos de HANA que recién se están volviendo públicos. Es solo la punta del iceberg. Los costos de oportunidad de muchas empresas son simplemente ridículos porque les lleva tantos años actualizarse. Estamos hablando de actualizaciones de más de cinco años, lo cual es simplemente una locura.

Es insano. Mira el hecho de que ChatGPT y la inteligencia artificial generativa no existían hace cinco años. Llegarás muy tarde a la batalla. Además, se tomaron decisiones muy malas, como apostar todo a los sistemas en memoria, lo que significa gastar en exceso en infraestructura.

Si tienes toneladas de hardware, mucho más de lo que deberías tener, significa que necesitas más administradores de sistemas, más personas en TI para gestionar todo eso. Todo se vuelve increíblemente complejo. No solo es más complejo, sino también más lento. Esas cosas se suman. Es mucho más costoso, más lento, necesitas más personas y hace que el costo de oportunidad sea aún peor.

Luego, las personas en la capa de gestión se asustan porque hay mucho en juego. Ralentiza el proceso aún más. Es como un círculo vicioso. Los problemas simplemente se están volviendo visibles. Las empresas hacen todo lo posible para asegurarse de que los errores internos nunca sean de conocimiento público porque no es buena prensa. No quieres publicitar tu propia incompetencia. Si puedes lidiar con eso puertas adentro, es mucho mejor.

Piensa en lo extremo que debe ser el problema para terminar revelando toda esa información al público. Casi todas las situaciones, a menos que la empresa cotice en bolsa y esté contra la pared y tenga que revelar cosas porque de lo contrario se consideraría fraude, no se van a divulgar.

Conor Doherty: Bueno, has mencionado el costo de oportunidad un par de veces. Has mencionado el costo de oportunidad de quedar atrapado en una implementación. De repente, te quedas atrapado en ese proceso, impidiéndote cambiar a otra cosa. También tiene el costo creciente asociado con las personas que lo mantienen.

En realidad, hay otra dimensión en esto, y he anotado aquí “perfeccionabilidad”. En términos de costo de oportunidad, si tomaste las tres clases de software individualmente, y teóricamente están en su mejor momento cuando se mantienen separadas porque tienes un sistema de registros separado, un sistema de informes separado y un sistema de inteligencia separado.

Intentas perfeccionar cada uno. Hay un límite superior para lo perfecto que puede ser un sistema de registros. Una vez que tienes un 100% de precisión, eso es todo. Por ejemplo, ¿cuántas botellas hay en la mesa? Hay dos. Eso es todo. No puedes mejorarlo más que eso.

Una vez que tienes una latencia de 50 milisegundos, es inconsecuente; la gente ya no lo nota. ¿Qué tan bien puede verse un tablero de control? Podemos debatir estéticamente, pero hay un límite superior en cuánto tiempo y dinero quieres invertir antes de experimentar rendimientos decrecientes.

Un sistema de inteligencia, como dijiste, implica decisiones. En la filosofía de Lokad, eso significa considerar el retorno de la inversión para cada decisión tomada. Teóricamente, me doy cuenta de que no hay un punto de perfección donde puedas decir, “Esta es la mejor decisión que podría tomar”.

No es necesariamente perfectible. Puedes mejorar continuamente un algoritmo para tomar mejores decisiones. ¿Estoy equivocado?

Joannes Vermorel: Entonces, no, pero también tenemos que disipar una idea errónea. Los matemáticos dirían: “Oh, pero una vez que alcanzas lo óptimo, eres el mejor”. Sabes, por definición, una vez que tienes lo óptimo, no se puede mejorar. Y para cualquier, diría yo, rompecabezas matemático dado, si tomas un rompecabezas matemático y dices, “Esto es, esto es un rompecabezas”, entonces puedes tener la solución óptima para este rompecabezas.

Pero donde es incorrecto pensar así en los negocios es que la elección del rompecabezas es muy arbitraria. Sabes, puedes decidir, “De acuerdo, tal vez tengo lo óptimo para este marco, pero tal vez pueda reinventar mi propio negocio y luego tendré un nuevo marco que me dé aún mayores rendimientos”. Entonces, las opciones que tienes no son estáticas. Decides lo que estás dispuesto a hacer, y dentro de las cosas que estás dispuesto a hacer, puede haber un óptimo, pero fundamentalmente, tus posibilidades son infinitas.

No hay límite superior, tal como lo veo, más allá de la ingeniosidad humana misma. Entonces, dices, “Mi óptimo no tiene sentido porque está dentro de limitaciones formales”. Donde yo digo, “Solo puedo decidir dentro, sabes, trazo una línea en la arena, digo que solo puedo mirar esta área y decir, okay, dentro de esta área que he delimitado en la arena, sí, mi óptimo podría ser eso, tal vez incluso pueda probarlo matemáticamente”.

Pero la realidad es que es solo una línea dibujada en la arena. Puedes ir a donde quieras. Entonces, sí, la conclusión es que, de hecho, cuando piensas en términos de decisiones empresariales, no hay límite más allá de la inteligencia y la ingeniosidad de las personas que trabajarán en el caso.

Ahora, creo que la industria del software se dio cuenta de eso muy temprano. Sabes, es por eso que, desde los años 70, todos los proveedores estaban promocionando beneficios expresados en términos de una mejor toma de decisiones. Literalmente estaban anunciando un sistema de inteligencia porque se dieron cuenta de que el problema de tener una representación electrónica de tu inventario era finito. Una vez que se hacía correctamente, ¿qué harías?

Resultó que las personas pasaron por etapas. Primero, tenías interfaces de texto, luego tenías interfaces gráficas como con el escritorio, la generación de clientes pesados de los años 90. Hoy en día, tienes aplicaciones web y ahora aplicaciones móviles. Entonces, resultó que incluso a nivel de interfaz de usuario, había una serie de transiciones.

Incluso si el desafío era finito, resultó que las empresas de software aún estaban ocupadas solo actualizando desde el terminal de texto hasta la interfaz gráfica, luego la aplicación web y ahora la aplicación móvil. Pero la cuestión es que estaba muy claro para todos que esto terminaría de alguna manera, en el sentido de que no crecería indefinidamente para convertirse en algo extremadamente grande.

Es por eso que, desde muy temprano, muchos proveedores, incluido SAP, se posicionaron en contra de esas decisiones, incluso si su software no tenía nada que ver en la práctica con la generación de mejores decisiones.

Conor Doherty: Bueno, se me ocurre que hemos hablado mucho de teoría, y eso está bien. Bueno, teoría mezclada con algo de práctica aquí, pero ciertamente, quiero intentar que sea un poco más práctico. Quiero plantear la pregunta de esta manera: Al comienzo del episodio, mencioné a DHL, Asda, Spar. Había otros ejemplos en la publicación de Anthony Miller.

Si estuvieras en una sala hoy, si estuvieras en la sala de juntas con los tomadores de decisiones, los grandes jefes, los grandes jugadores, y te dijeran: “De acuerdo Joannes, ¿qué deberíamos hacer a continuación?” Probamos esto, esto no funcionó. ¿Cuál sería tu consejo?

Joannes Vermorel: Mi consejo es muy simple. Los sistemas de registros se han convertido en una mercancía hace más de una década, de hecho, hace más de una década. Entonces, vamos paso a paso. Tu base de datos va a ser, digamos, PostgreSQL. Es de código abierto, es excelente.

Eso fue lo que sucedió en 2010 cuando SAP dijo: “Tuvimos tantos problemas, vemos a Oracle como una amenaza estratégica”. Lo que no se dieron cuenta es que Oracle era insignificante. El verdadero desafiante era en realidad el código abierto.

Entonces, la base de datos relacional que ganó hoy en día son las bases de datos de código abierto. Las bases de datos relacionales son ahora una mercancía completa hasta el punto de que los mejores productos son proyectos de código abierto, y PostgreSQL está muy por delante de Oracle y de las bases de datos privadas.

Así que, aquí estamos en una situación en la que un gran proveedor, SAP, que quería contener a otro proveedor, Oracle, terminó desarrollando una tecnología que resultó ser inferior a un producto de código abierto, que es simplemente PostgreSQL.

¿Y cómo sé que es inferior? Quiero decir, solo mira en Hacker News o discute lo que las startups están haciendo hoy en día. He auditado un número de tres dígitos de startups. Nunca he visto una startup que use una base de datos relacional que no sea de código abierto durante la última década. Nunca.

Solo usarían bases de datos de código abierto. Nunca he visto una startup que use, por ejemplo, Oracle Database. Nunca. Entonces, eso te da la idea de que las personas que conocen la tecnología, que trabajan en tecnología, no toman esta decisión. Primero, le diría a esta sala de ejecutivos: “Para la capa de base de datos, necesitan elegir una de las excelentes opciones de código abierto que están en el mercado.”

Eso puede ser PostgreSQL. Estas soluciones son excelentes, y si no lo hacen, la pérdida de oportunidades es enorme porque lo que obtienes si eliges una de esas bases de datos es que, además de eso, tienes literalmente más de un millón de ingenieros de software que ya son competentes en esas tecnologías en comparación con tecnologías privadas, firewall oscuras que son mucho más difíciles de operar. Ese fue el primer problema.

Entonces, ¿qué necesitas en la parte superior? Básicamente necesitas un marco para implementar una aplicación básica sobre la base de datos. Hay un montón de esos marcos, y nuevamente, están disponibles en código abierto. Eso sería Django si estás en Python, eso sería el marco MVC en ASP.NET para Microsoft, que también es de código abierto. La lista continúa. Estos marcos existen para todas las pilas principales: Python, Java, .NET.

Debido a que está completamente mercantilizado, o eliges para tu sistema de registros un proveedor que ya es de código abierto, esos existen, o simplemente creas el tuyo propio, y ni siquiera es tan caro. La cuestión es que cuando terminas con un proyecto de cinco años para hacer una actualización de ERP, sería mucho mejor simplemente implementar tu propia pieza de reemplazo poco a poco.

En seis meses, podrías tener una serie de módulos que ya se están actualizando y reemplazando si simplemente lo haces internamente o con algo de ayuda de una empresa de TI. Nuevamente, lo bueno de tener esos sistemas de registros completamente mercantilizados es que es muy sencillo encontrar personas que puedan hacerlo. Es muy sencillo subcontratar estas cosas, también es muy sencillo hacerlo internamente si así lo deseas.

La barrera es muy baja; es muy barato. Cuando miras a todas las empresas expertas en tecnología de este mundo, las Zalando de este mundo, han desarrollado su propio ERP; están muy bien con eso. Si miras a Amazon, están haciendo lo mismo; JD.com está haciendo lo mismo. Todas las personas que son nativas digitales vieron eso como una solución obvia para el sistema de registros.

Los registros están completamente mercantilizados. Al final, no es difícil, quiero decir, esos productos ciertamente no deberían ser caros. Si son caros, entonces tu plan B debería ser: “Bueno, sabes, simplemente lo haré yo mismo”. Si le pides a un pintor que haga una pintura para una pared de tu casa y te dice que va a costar 2 millones de euros.

Sabes, son cuatro metros cuadrados, pero, sabes, si no puedo hacerlo mejor, dirías: “Bueno, simplemente lo haré yo mismo”. Sabes, si es la única opción, lo haría yo mismo. Sí, preferiría no hacer la pintura, pero, sabes, no estamos hablando de enviar cohetes al espacio. Estamos hablando de algo que de todos modos es bastante sencillo.

Conor Doherty: Bueno, esto, nuevamente, porque tomo notas copiosas, como puedes ver. Pero la siguiente pregunta que quería hacer era, habiendo delineado las tres clases y nuevamente estás en esa sala con los ejecutivos, y nuestro sesgo potencial es claro, como sabes. Lokad es un proveedor en sí mismo. En términos de costos para cada una de estas clases, porque nuevamente, has comentado varias veces en los últimos dos o tres minutos sobre cómo, “Mira, quiero decir, básicamente podrías hacer esto tú mismo”.

Quiero decir, si eres experto en tecnología, podrías y eres digitalmente— el término utilizado fue “nativo digital”, podrías diseñar tu propio sistema de registros. Bueno, entonces presumiblemente debería costar menos que un sistema de informes y un sistema de inteligencia o ¿cómo asignas presupuesto en ese sentido?

Joannes Vermorel: Quiero decir, claramente, los sistemas de registros son mucho más simples que el resto. Sabes, nuevamente, fueron los primeros en llegar. La tecnología está completamente mercantilizada. El código abierto proporciona todas las piezas que necesitas. Desarrollar una aplicación básica es un ejemplo perfecto de para qué sirven los entornos de desarrollo integrados.

Entonces, las herramientas son excelentes, el marco es excelente y las herramientas son excelentes. Tienes toneladas de ingenieros que tienen una productividad masiva, y aún mejor con LLMs hoy en día. Este es el tipo de situación donde la inteligencia artificial generativa simplemente se destaca cuando se trata de escribir toneladas de código no inteligente. Esas herramientas son muy buenas para hacer eso.

Conor Doherty: Entonces, $20 mil millones, eso es lo que deberíamos cobrar.

Joannes Vermorel: Sí, entonces eso debería ser relativamente, quiero decir, eso debería ser bastante barato nuevamente para las empresas como base. Si terminas pagando más de una décima parte de lo que pagaste por sistemas similares hace 10 años, eso es un robo. Sabes, esa debería ser tu base. Así que deberías estar buscando, “Vamos a hacerlo de nuevo, pero a una décima parte del presupuesto”. Y ni siquiera es exagerado.

Creo que considerando la evolución de la tecnología, es un punto de partida. Estoy bastante seguro de que si fueras a una estrategia loca y agresiva—digamos que Elon Musk se hace cargo del caso—sería, “Voy a hacerlo 100 veces más barato”. Pero diría que tu próximo proyecto de ERP debería ser una décima parte del costo de lo que gastaste hace 10 años. Creo que es una base razonable, al menos para los sistemas de registros.

Para el sistema de informes, la tecnología está bastante empaquetada. Entonces, el problema es que generalmente termina siendo muy costoso porque la empresa solo quiere un montón de informes. El costo está en la implementación, a medida, de un número ilimitado de informes—un número increíblemente alto de informes.

Entonces, cuando tienes un sistema de informes, en algún momento la gente diría, “Oh, pero me gustaría tener algunos informes que sean listos para usar, plantillas predefinidas”. Y luego el proveedor diría, “Sí, no hay problema, ¿cuántos quieres?” Y luego enumeran, y terminas con miles de informes. Si haces eso, entonces se vuelve increíblemente costoso solo porque estás pidiendo tanto.

Entonces aquí, debería ser bastante barato porque la tecnología está bastante empaquetada, pero más que los sistemas de registros. Es más difícil, por lo que es el tipo de cosa en la que no aconsejaría hacerlo tú mismo. Pero nuevamente, con tecnologías de código abierto como Spark, no es tan difícil. Aunque es más difícil que los sistemas de registros.

Aquí, creo que si quieres mantener el presupuesto ajustado, necesitas mantener tus demandas bajo control. Existe esta tentación, especialmente en grandes empresas, de solicitar una lista interminable de informes que nadie va a consumir nunca. Resulta ser súper costoso porque todas esas personas tienen que mirar esos números de vez en cuando, y realmente no tiene sentido.

Así que mantenlo breve y enfocado, y el costo no será muy alto. Debería ser en realidad mucho más pequeño que el costo de tu ERP base de hace 10 años. Dije que el nuevo ERP debería ser casi una décima parte de eso. El sistema de informes debería ser una fracción de este costo, no más del 20% del costo de este ERP de próxima generación.

De eso estamos hablando, algo muy pequeño. En última instancia, los informes no deberían costar millones o decenas de millones para informar estadísticas descriptivas básicas sobre tu negocio. No tiene sentido. La tecnología ha avanzado lo suficiente como para que debería ser muy barato.

Conor Doherty: Cuando propusiste por primera vez la categorización de las tres clases o clasificación de los tres tipos de software empresarial—Tú—no puedo recordar la proporción exacta, pero era algo así como que el 90% de tu presupuesto de TI debería ir a los sistemas de inteligencia.

Joannes Vermorel: La división que propuse fue del 20% para ERP, 5% para sistemas de inteligencia y 75% para—perdón, 20% para sistemas de registros, 5% para sistemas de informes y 75% para sistemas de inteligencia. Eso es lo que sugiero como una heurística para la casi totalidad de las empresas.

En contraste, lo que está sucediendo hoy es 75% para ERP, 20% para inteligencia empresarial o sistemas de informes, y solo 5% para sistemas de inteligencia. Digo que estos números están equivocados. Necesitamos intercambiarlos. ¿Por qué deberías gastar la mayor parte de tu dinero en sistemas de inteligencia?

Obviamente, Lokad es un sistema de inteligencia, por lo que la audiencia debería estar gastando mucho dinero. Pero la realidad es que hay un retorno de inversión exactamente. Ahí es donde puedes tener un gran beneficio si las decisiones se toman correctamente. Los sistemas de informes son principalmente para asegurarse de que no estás en problemas.

Se trata de mirar hacia atrás para ver si estás cumpliendo con tus propios procesos, si estás en el camino correcto. Pero fundamentalmente, ninguna empresa ha tenido un éxito masivo simplemente mirando hacia atrás. Ese es el problema con los sistemas de informes. Estás mirando en el espejo retrovisor.

Si quieres ganar una carrera, no la ganas teniendo los ojos en el espejo retrovisor. En algún momento, necesitas mirar hacia adelante.

Conor Doherty: Se me ocurre que en realidad tengo una computadora portátil frente a mí, y esta tiene Wi-Fi. El blog al que me refería se llama “Las Tres Clases de Software Empresarial”. Fue de junio del año pasado.

Solo para aclarar los números, recordaste correctamente cómo las empresas, la casi totalidad de las empresas, suelen dividir sus gastos—Su presupuesto de TI es 75% para sistemas de registros, y has puesto “equivocado” entre paréntesis después de eso. 20% para sistemas de informes, también “equivocado”, y 5% para sistemas de inteligencia, con “completamente equivocado” al final de eso.

Invertir 75% para sistemas de inteligencia, cinco para sistemas de informes y 20 para sistemas de registros. Ahora, uh, recomiendo encarecidamente leer el blog. Es muy bueno.

Ahora, uh, última pregunta antes de empezar a concluir, pero es algo que se me ocurre. Uh, es un punto que has mencionado antes y en tus conferencias, y lo he mencionado algunas veces en conversaciones aquí: el papel de la simpatía mecánica. Y no tenemos que hablar mucho al respecto, pero se me ocurre que una familiaridad básica con, digamos, ¿cuáles son los parámetros requeridos o las elecciones de diseño arquitectónico necesarias para sobresalir en la herramienta que estás buscando comprar?

Si estás algo familiarizado con eso, al menos puedes tener una idea de que “esto podría no ser para mí”. Entonces, nuevamente, incluso solo la diferencia entre bases de datos columnares y tabulares—si entiendes bien qué sistema usa este y para qué quiero ese sistema, eso podría guiarte a reconsiderar inmediatamente una elección potencialmente costosa.

Joannes Vermorel: Sí. Y nuevamente, si volvemos a los errores que SAP cometió en, eh, en 2010… Quiero decir, HANA se lanzó en 2010, por lo que probablemente ya estaban en el proceso de trabajar en eso durante algunos años. Y en ese momento, sospecho que parecía una buena idea, ya sabes, parecía, “Bueno, supongamos que esas latencias que tenemos dentro de los sistemas informáticos simplemente van a mejorar, seguir mejorando, que la memoria seguirá siendo mucho más barata”.

Porque nuevamente, si miramos cuál es la gran diferencia entre 2010 y, digamos, eh, el año, eh, 15 años antes, ya sabes, 1995. Durante esos 15 años, la memoria se había vuelto radicalmente más barata y radicalmente más abundante. Recuerdo que en ese momento, en 1995, recuerdo que la primera computadora que usé, Windows 95, tenía algo así como 8 megabytes de memoria.

Y luego, para el año 2010, eso era, creo que en ese momento era Windows 7 o algo así. Sospecho que en ese momento tenía 8 gigabytes, ya sabes, por lo que había crecido mil veces en este período de tiempo. Y la latencia se había dividido por algo así como un factor de 50 o algo así.

Entonces, si hubiera continuado en esta línea, eso habría sido increíble. Significaría que, ya sabes, tenía 8 GB en mi computadora en 2010. Si 15 años después hubiera mejorado de la misma manera, tendría 8 terabytes en mi computadora hoy. Esto no es lo que tengo, por supuesto, en mi computadora. Nadie tiene 8 terabytes en su computadora.

Pero ves que si la tecnología hubiera progresado como lo hizo en los 15 años anteriores, eso es lo que la gente habría tenido. Y si también tuviéramos una reducción similar en la latencia, el problema es que la velocidad de la luz es un fastidio, ya sabes. La física no juega a tu favor. Tienes esta velocidad de la luz que está un poco en el camino.

Pero, sin embargo, creo que cometieron este trágico error. Y a partir de eso, tantas cosas tuvieron que ser sobreingenierizadas porque esto es como el pecado original. Debido a eso, tuviste que hacer tantos parches que tenías que hacer solo para… Cuando tienes un problema de diseño masivo como ese, puedes intentar salir del problema con parches. Puedes, pero todo va a ser tosco.

Y así, cuando te enfrentas a problemas de rendimiento, puedes resolverlos agregando hardware. Sí, obviamente puedes empezar a comprar hardware súper caro, ese sería el primer paso. Pero luego puedes sobreingenierizar como loco ciertas cosas para que no sea demasiado disfuncional. Porque fundamentalmente, con suficiente ingeniería, puedes mitigar algunos de esos problemas.

Pero aún así, SAP quiere cubrirlo todo, con la ambición que estaba describiendo. Quieres ser el sistema de registro para una cosa, pero quieren ser el sistema de registro para todo. Lo que significa que la superficie donde puedes tener problemas de rendimiento solo por esta elección es absolutamente gigantesca.

Y creo que lo que estamos viendo es simplemente, ya sabes, una implosión en cámara lenta. Eso es lo que estamos viendo. Toma mucho tiempo. Se tardaron cinco años en lanzar un ERP sobre HANA, eso es S/4. Y luego les llevó años vender el ERP a su primera empresa.

Porque nuevamente, cuando quieres vender software empresarial, no cierras el trato en seis meses; a menudo lleva varios años. Entonces toma como un ciclo de medio siglo implementar. Y luego tal vez una vez que tomas medio siglo, ese es tu plan para la actualización.

Eso es una locura. Pero la realidad es que comienzas a fallar porque no toma medio siglo, toma una década completa. Así que simplemente estamos presenciando fallas causadas por malas decisiones que se tomaron hace mucho tiempo. Y estamos rastreando en las décadas pasadas. Creo que veremos que esos problemas siguen surgiendo, pero no es nuevo. Simplemente refleja errores que se cometieron hace mucho tiempo.

Y ahora, lo único que realmente podemos sugerir es no repetir errores antiguos. Pero lo increíble es que esos errores se cometieron hace tanto tiempo que la gente de SAP… quiero decir, errores de SAP, y la gente que los adoptó pensando que sería lo correcto.

Y lo interesante es que esos errores se cometieron hace tanto tiempo que la gente podría estar pensando: “Oh, pero hoy en día debería estar bien”. Han reunido sus cosas. Han unido sus mentes. Esto está resuelto. Porque obviamente, como proveedor, si tuviera que presentar un producto así, diría: “Estimado prospecto, tenga la seguridad de que hemos aprendido de nuestros errores. Esos problemas se han corregido. Hemos aprendido tanto. No volverán a ocurrir”.

Yo diría, no del todo, porque el problema sigue estando en el núcleo mismo de su tecnología. HANA sigue siendo el centro de todas las ofertas de SAP. Mientras siga así… Sí, estás en problemas. Tienes que deshacer todo eso para posiblemente entrar en territorios más razonables.

Hoy en día, a menos que cambien de rumbo y simplemente eliminen HANA, opten por PostgreSQL o cualquier otra cosa de código abierto, y luego dividan y subdividan su oferta para que puedan tener aplicaciones ligeras que estén estrechamente desacopladas. Integrar cosas a través de internet es bastante fácil hoy en día, por lo que podrían tener un diseño súper modular.

A menos que comiencen a hacer eso, los pecados originales siguen ahí; la ambición de ser el sistema de todo más el motor equivocado en el núcleo del sistema.

Conor Doherty: Bueno, para intentar terminar de manera positiva, ¿hay algún consejo constructivo que puedas compartir con las personas para que puedan evitar, entre comillas, las minas terrestres que algunas de estas enormes empresas han cometido?

Joannes Vermorel: Quiero decir, la perspectiva realmente positiva, y es ahí donde me entristece mucho cuando veo esos errores, es que la comunidad de código abierto ha entregado algo que es increíblemente grandioso. PostgreSQL es una maravilla de la ingeniería. Esto es de código abierto. Esto es magia.

Vivimos en una era donde, literalmente por el precio, no es exactamente gratis—por supuesto que necesitas pagar por tu conexión a internet—pero por un precio increíblemente bajo, puedes tener sistemas increíblemente bien diseñados o piezas de ingeniería que representan cientos de años de algunos de los ingenieros más brillantes de nuestro siglo. Esto es increíble, y puedes obtenerlo de forma gratuita. Así que, esa es mi opinión.