Por qué fallan las Transformaciones Digitales en la Supply Chain (Eric Kimberling) - Ep 181

00:00:00 Introducción de Eric Kimberling y Third Stage
00:04:31 Enfocarse en las personas antes que en la tecnología en los proyectos
00:06:14 Enmarcar correctamente las transformaciones digitales
00:08:08 Superar el incrementalismo en las transformaciones
00:10:53 Los sesgos de los proveedores ponen en riesgo los esfuerzos
00:12:40 Retos en migraciones forzadas a la computación en la nube
00:14:46 Bajo valor al actualizar sistemas o registros
00:19:26 Sensibilidades del sistema e impactos de la transformación
00:21:38 Vulnerabilidades de grandes empresas en la transformación
00:23:39 Problemas de liderazgo aumentan la aversión al riesgo
00:26:22 Falta de perspectiva estratégica en las transformaciones
00:29:42 Importancia de la simpatía mecánica en el liderazgo
00:32:42 La latencia de datos obstaculiza la computación distribuida
00:35:42 Altos costos del procesamiento de datos en terabytes
00:38:38 Análisis de riesgo en la transformación tecnológica
00:41:43 Estrategias visionarias para transformaciones digitales
00:44:25 Equilibrar los presupuestos de los proyectos con los retornos
00:47:42 Expectativas realistas de costos en las transformaciones
00:50:58 La sobrecarga de funciones en el software obstaculiza la productividad
00:53:29 Enfocarse en los procesos empresariales más que en la tecnología
00:56:39 Gestión interna de las transformaciones tecnológicas
00:59:45 La burocracia en la ejecución de la planificación estratégica
01:02:48 La gobernanza previene el caos en las supply chains
01:06:27 Reforma integral para transformaciones ambiciosas
01:09:34 Optimización del capex para el valor en la supply chain
01:12:20 Ineficiencias en las transformaciones actuales
01:15:28 Uso de datos de proveedores para la ventaja competitiva
01:18:11 Incentivos financieros que afectan la productividad
01:21:13 La búsqueda de desarrollos prometedores en tecnología de software
01:23:19 Evitar fracasos costosos reconociendo los costos irrecuperables

Resumen

En su discusión sobre las transformaciones digitales en la supply chain, Eric Kimberling y Joannes Vermorel destacan fracasos frecuentes debido a presiones impulsadas por proveedores y prioridades desalineadas. Kimberling, al frente de Third Stage Consulting Group, aboga por estrategias independientes de la tecnología, enfatizando las necesidades empresariales por encima de simples actualizaciones de software. Advierte contra decisiones apresuradas impulsadas por proveedores que a menudo no logran entregar resultados transformadores. Vermorel subraya la importancia de aprovechar los sistemas existentes mediante complementos innovadores en lugar de reemplazos disruptivos. Ambos líderes enfatizan alinear los esfuerzos de transformación con objetivos empresariales tangibles y recalcan que la gestión del cambio es vital para el éxito. Abogan por una adopción gradual y consciente de la tecnología, asegurándose de que los objetivos se definan y que se gestione el riesgo.

Resumen Extendido

Al examinar por qué las transformaciones digitales en la supply chain a menudo fracasan, es vital considerar las ideas compartidas por líderes de la industria como Eric Kimberling y Joannes Vermorel en su reciente diálogo, presentado por Conor Doherty. Tanto Kimberling como Vermorel poseen una gran experiencia guiando a las empresas a través de las traicioneras aguas de las convulsiones tecnológicas, y sus perspectivas revelan verdades cruciales que a menudo son pasadas por alto por las organizaciones que se embarcan en tales emprendimientos.

Eric Kimberling, una figura destacada en el liderazgo del pensamiento tecnológico, dirige Third Stage Consulting Group—una firma dedicada a ofrecer asesoría independiente e independiente de la tecnología a organizaciones que aspiran a lograr transformaciones digitales exitosas. Su firma opera bajo una misión clara: empoderar a los clientes mediante consejos imparciales que priorizan las necesidades empresariales por encima de simples actualizaciones tecnológicas. El enfoque de Eric destaca la necesidad de que las transformaciones se centren no solo en soluciones tecnológicas, sino en un cambio organizacional holístico que abarque procesos y personas por encima de la tecnología.

La conversación rápidamente pone de relieve la noción de “agnosticismo tecnológico”, un principio que Kimberling sostiene debe estar en el núcleo de cualquier proyecto de transformación exitoso. Advierte contra los sesgos impulsados por proveedores que priorizan las actualizaciones de software sobre las verdaderas necesidades empresariales, un sentimiento compartido por Vermorel. Los proveedores a menudo impulsan cronogramas de actualización rápidos—una estrategia que puede atrapar inadvertidamente a las empresas en decisiones apresuradas que generan mejoras incrementales, en lugar de transformadoras. Eric advierte que dichas actualizaciones apresuradas rara vez se alinean con los objetivos organizacionales a largo plazo y, a menudo, restan valor al propósito que tiene la transformación digital.

Joannes Vermorel, fundador de Lokad, delimita los ámbitos del enterprise software en “sistemas de registros”, “sistemas de informes” y “sistemas de inteligencia”, argumentando que las transformaciones no deberían centrarse miopicamente en los sistemas de registros que ofrecen un valor adicional mínimo. Tanto Vermorel como Kimberling reconocen estrategias alternativas de empresas como Palantir y Snowflake, que mejoran los sistemas existentes sin la necesidad disruptiva de un reemplazo, enfatizando la ventaja estratégica de adaptar las infraestructuras actuales con complementos innovadores.

Un tema recurrente en su diálogo surge, revelando que las grandes corporaciones son particularmente vulnerables a fracasos costosos durante las transformaciones digitales. Kimberling señala que estos fracasos a menudo se derivan de soluciones complejas combinadas con una alta aversión al riesgo y una falta de responsabilidad decisiva, destacando la necesidad intrínseca de una curiosidad mecánica—un concepto que insta a los líderes empresariales a estar íntimamente familiarizados con los requerimientos digitales de su empresa. Sin esta curiosidad, las empresas fracasan cuando externalizan en exceso, tratando a los proveedores como conductores principales en lugar de subcontratistas del cambio.

Los líderes resaltan la importancia de alinear las estrategias de transformación digital con objetivos empresariales tangibles. Presentan la inquietante perspectiva de presupuestos inflados dedicados a actualizaciones de ERP sin un ROI claro —o, peor aún, proyectos que descuidan completamente el análisis de ROI y beneficios. La discusión subraya la importancia crítica de la gestión del cambio, el eje fundamental a menudo pasado por alto para el éxito de la transformación. Las transformaciones que omiten la asimilación cultural y la formación integral están condenadas a complicaciones, independientemente de la destreza técnica involucrada.

Al identificar casos de éxito, Kimberling y Vermorel delinean la importancia de la claridad y la brevedad en los documentos de planificación. En lugar de extensos PowerPoints, planes concisos en texto fomentan una comprensión más profunda y facilitan una comunicación más clara entre las partes interesadas. Exaltan las virtudes de tratar las inversiones en tecnología de manera similar a los gastos de capital—valorándolos como activos duraderos en lugar de meros gastos operativos.

Al concluir el diálogo, la dupla reitera que, si bien las transformaciones impulsadas por la tecnología pueden ser catalizadores potentes para la evolución empresarial, su éxito depende de un cuidadoso equilibrio entre la adopción de innovaciones de software y el fomento del cambio organizacional. Kimberling aconseja emprender estas transformaciones con una gradual consciencia, asegurándose de que los objetivos estén rigurosamente definidos antes de acelerar las implementaciones. Vermorel está de acuerdo, promoviendo compromisos incrementales y un enfoque de “fail fast” que modera el riesgo al tiempo que permite espacio para la adaptación.

A través de su intercambio, Kimberling y Vermorel iluminan el camino para las organizaciones que contemplan transformaciones digitales—instando a los líderes a considerar algo más que el atractivo de tecnologías de moda, enfocándose en cambio en alinear estos proyectos con sus objetivos y aspiraciones empresariales generales.

Transcripción Completa

Conor Doherty: Bienvenidos de nuevo a Lokad. Hoy me complace presentar una conversación entre Eric Kimberling y Joannes Vermorel. Eric es el CEO y fundador de Third Stage Consulting Group, y se une a nosotros hoy para compartir su perspectiva única sobre por qué tantas transformaciones digitales fracasan en la supply chain. Y ya que están aquí, si les gusta lo que hacemos en Lokad, consideren suscribirse a Lokad TV aquí en YouTube. Esperaré.

Conor Doherty: Muy bien, gracias. Y también síguenos en LinkedIn, y con esto, les presento la conversación de hoy con Eric Kimberling. Primero que nada, Eric, muchas gracias por acompañarnos y bienvenido a Lokad.

Eric Kimberling: Gracias por invitarme. Es bueno estar aquí.

Conor Doherty: Entonces, Eric, antes de entrar en el meollo de la conversación, debo decir que eres una voz muy popular en línea. De hecho, te descubrí por primera vez en LinkedIn. Tienes un gran número de seguidores, y eres prolífico también en YouTube. Ahora, tenemos una audiencia principalmente europea, por lo que puede que no te conozcan tan bien. ¿Podrías dar una breve introducción para aquellos de nuestra audiencia que no están en Norteamérica? ¿Qué es lo que hace Third Stage Consulting Group, cómo llegaste hasta aquí, etc.?

Eric Kimberling: Sí, Third Stage Consulting Group es una firma de consultoría en transformación digital con sede en EE. UU. Y la clave de nuestro modelo de negocio es que somos independientes y estamos libres de influencias tecnológicas. Así que ayudamos a los clientes a lo largo de todo el ciclo de vida, desde la estrategia digital y la evaluación y selección de software, pasando por la planificación de la implementación, hasta la gestión del programa de implementación y la gestión del cambio.

Tenemos cerca de 100 consultores. De hecho, contamos con una pequeña oficina en Europa, en el Reino Unido, que gestiona la región EMEA. Así que es cierto que aún no tenemos tanta presencia en Europa, pero nuestro objetivo es tener una presencia en la región EMEA tan fuerte como en Norteamérica. Realmente, fundé la compañía en 2018 porque sentí que no había suficientes consultores que fueran verdaderamente independientes de la tecnología, objetivos y que representaran realmente los intereses de los clientes.

Esa es, en realidad, la premisa por la que fundé la compañía. Fue simplemente para ofrecer a los clientes una alternativa al modelo típico de consultoría.

Conor Doherty: Cuando hablas del modelo típico de consultoría, supongo que el agnosticismo tecnológico es una gran parte de ello, pero ¿podrías explicar a qué te refieres con eso? Es una frase muy bonita, pero, ¿qué quieres decir con agnosticismo tecnológico?

Eric Kimberling: Claro, “tech atheism”, me gusta ese término también. Es incluso mejor. No, ser tech agnostic significa que no somos comisionados por los proveedores de software. En otras palabras, no ganamos dinero cuando los proveedores ganan dinero. Solo ganamos dinero directamente de nuestros clientes. Y esa es una matiz muy importante, porque la mayoría de las firmas de consultoría son incentivadas directamente por los proveedores de software para expandir la huella del software tanto como sea posible en un mercado o región.

Cuentan con un grupo de recursos enfocados en una sola tecnología, y su objetivo es asignar a esos consultores en proyectos centrados en esa única tecnología. Ese sesgo crea una mentalidad de tecnología en primer lugar en la transformación, mientras que, en mi opinión, las transformaciones más exitosas, ya sean transformaciones de la supply chain o implementaciones de ERP, o lo que sea, son impulsadas por las necesidades empresariales y la definición de una estrategia y hoja de ruta que se ajusten a esas necesidades, en lugar de comenzar con la tecnología y luego tratar de encajarla en tu negocio. Puede sonar como un detalle muy menor, pero en realidad es algo muy importante, y es un gran impulsor de lo que causa el éxito o el fracaso en el mercado.

Conor Doherty: Bueno, gracias, Eric, y Joannes, te toca a ti. Eric mencionó las declaraciones de problemas. Sé que tener una mejor comprensión de una declaración de problema es básicamente la base de lo que se quiere lograr. Entonces, ¿cuáles son tus pensamientos sobre lo que dijo Eric y cómo encaja eso en tu entendimiento de la transformación digital?

Eric Kimberling: Realmente, la forma en que la definimos es como un habilitación tecnológica a lo largo de toda la empresa. No se trata solo de tecnología; se podría decir que lo aún más importante es el aspecto operativo y organizacional, es decir, los procesos y las personas.

Cuando se trata de tecnologías específicas, la mayoría de las personas inician con la decisión de que necesitan reemplazar su tecnología. Generalmente, esa es la declaración del problema: “Necesitamos reemplazar cierto tipo de tecnología.” Esa tecnología podría ser un sistema de supply chain, podría ser un sistema ERP, podría ser un CRM o un sistema de gestión de relaciones con clientes; podría ser un sistema de RRHH, financiero, e incluso ahora, con la IA siendo tan relevante, podría ser IA, podría ser business intelligence.

Así que hay todo tipo de tecnologías para elegir. En nuestra opinión, cuando piensas en transformación digital, es un término bastante amplio y vago. Abarca muchas cosas diferentes, muchas tecnologías distintas, y lo más importante al respecto es que creo que el término transformación digital es un poco engañoso porque lleva a pensar que se trata de tecnología. En realidad, estos proyectos suelen volverse mucho más sobre gestionar personas y menos sobre tecnología.

Conor Doherty: Gracias, Eric, y Joannes, te toca a ti.

Joannes Vermorel: Estoy totalmente de acuerdo, en primer lugar, sobre la importancia del agnosticismo tecnológico si se desea proporcionar un buen asesoramiento. Es absolutamente fundamental; de lo contrario, el problema se enmarcará literalmente como lo que expanda la huella de quien ya tiene un pie adentro como proveedor. Eso llevaría a que el proyecto se transforme en cómo actualizamos el ERP de este proveedor de la versión N a N+1. Al final, es como una receta para una inversión masiva y muy poco para mostrar.

Los incentivos no subestiman el poder del incentivo para enmarcar correctamente la declaración inicial del problema. Puede sonar a poco, pero lo que he observado es que esas pocas y diminutas decisiones que se toman, típicamente muy temprano en el proceso, pueden enmarcar completamente los millones de dólares que se van a gastar durante varios años después. Así que, estoy muy de acuerdo en que esto es absolutamente fundamental para tomar el lado del negocio. ¿Qué queremos entregar, sin aún plantear la pregunta de qué proveedor? Y luego está la cuestión secundaria que es realmente, y también estoy muy de acuerdo con tu visión, que la transformación digital se trata realmente de qué tipo de empresa nos convertiremos si podemos hacer las cosas mejor con esas herramientas más sofisticadas y demás.

En lugar de pensar en una progresión lineal al pasar de la versión N a la versión N+1, y esa suele ser una pregunta muy complicada, porque, por ejemplo, podrías pensar, “Está bien, tenemos a tantas personas haciendo esto, esto y esto,” pero resulta que, quizás, si estuviésemos mejor organizados, ni siquiera necesitaríamos hacer esas cosas desde el principio. Así que, no tiene sentido tratar de optimizar lo que están haciendo, porque la mejor organización ni siquiera tendría que hacer eso en primer lugar. Así que, veo eso como un desafío para pensar realmente en el negocio. ¿Qué es lo que realmente estás logrando?

Y luego necesitas tener un buen sentido de la tecnología, lo que puede hacer y lo que no puede hacer. Pero diría que es una preocupación lejana en comparación con tener un entendimiento muy claro del negocio y lo que intentas lograr. Este enmarcado me gusta mucho, y creo que, para mí, el mayor desafío de la mayoría de las empresas —pienso en Europa pero quizá hasta en Estados Unidos también— en esta transformación digital es que es la maldición del incrementalismo. Realmente piensan en lo mismo más algunos adornos, o quisiéramos tener el mismo ERP pero con una interfaz web en lugar de tener una interfaz de escritorio o lo que sea.

Y eso, para mí, sí, estaría bien, pero fundamentalmente el tipo de retorno de inversión para esos proyectos que son muy costosos, o sea, no lo justifica. No actualizas un ERP porque estés harto de tu interfaz fea. Si funciona, funciona, incluso si no es estéticamente agradable. Si quieres actualizar y pasar años haciendo eso, necesitas tener algo que haga que tu empresa sea mucho mejor después, no solo contar con una herramienta de mejor apariencia, sino que la empresa misma se haya convertido en otra cosa. Esa es mi interpretación de lo que realmente significa una transformación digital genuina y correctamente ejecutada.

Eric Kimberling: Sí, ese es un excelente punto porque hay una serie de aspectos muy buenos en ello. Uno es que hablaste sobre la planificación y las decisiones tempranas que se toman y cómo eso establece la trayectoria para el proyecto. Eso es muy cierto, y muchas organizaciones, creo, sienten que simplemente nos apresuraremos a tomar estas decisiones, entremos en el proyecto y luego resolveremos todo durante el proyecto. Y ahí es cuando las cosas se vuelven confusas y no hay claridad en la dirección.

Pero lo otro a lo que también te aludes es que, a veces, está bien decir que no vamos a actualizar nuestra tecnología. ¿Qué pasa si no actualizas al sistema más novedoso y sofisticado que existe? ¿Qué pasa si en cambio optimizas lo que tienes? ¿Qué pasa si te concentras en modificar tus procesos de negocio para que sean más óptimos? ¿Qué pasa si capacitas a la gente para usar el software mejor? ¿Qué pasa si haces todas esas mejoras de bajo costo que proporcionan un valor extremadamente alto y un bajo riesgo para la organización? ¿Por qué no considerar eso como una opción?

Ahora, los proveedores de software estarían totalmente en desacuerdo conmigo. Si yo fuera un proveedor de software, diría que es una idea terrible; necesitas actualizar todas tus tecnologías, necesitas moverte a la computación en la nube, necesitas IA, necesitas todas estas cosas porque estoy tratando de venderte tecnología. Pero si te detienes y simplemente dejas de lado la emoción y eliminas el sesgo del proveedor, muchas veces las organizaciones llegarán a la conclusión de, “¿Sabes qué? No necesitamos apresurarnos a actualizar a la nube solo porque nuestro proveedor nos dice que tenemos una fecha límite para hacerlo.”

Y creo que es realmente importante que tomes la transformación en tus propias manos y la bases en las necesidades de tu negocio, tus prioridades, tus estrategias, y no en los proveedores de software.

Conor Doherty: Eric, si puedo seguir con eso, quiero decir, y no quiero poner palabras en tu boca, pero ¿se implica que las personas quizás sean un poco engañadas por consultores o proveedores, lo que conduce a fracasos en las transformaciones digitales? Si no es así, ¿cuáles ves como algunas de las razones más comunes por las que fracasan las transformaciones digitales?

Eric Kimberling: Sí, es una gran pregunta. Podríamos pasar toda la entrevista discutiendo esa única cuestión. Pero para resumir, diría que sí, los sesgos son sin duda factores que contribuyen al fracaso. Si soy un consultor de software y entro con una visión miope de que esta es la tecnología que necesito para encajar en tu organización, ya habré creado un desajuste porque no me estoy enfocando en tu negocio; me estoy enfocando en mi tecnología.

Mi tecnología tiene mejores prácticas; mi tecnología cuenta con flujos de trabajo integrados; necesitas adaptarte a mi software porque es excelente. Es simplemente un proceso muy disruptivo a causa de eso. Así que, creo que el sesgo es parte de ello; es un gran factor contribuyente. Pero lo que pienso es que hay un factor contribuyente aún mayor que mucha gente no reconoce: que muchos de estos grandes proveedores de software, como SAP o Microsoft, esencialmente están forzando a sus clientes a actualizar a nueva tecnología diciendo, “Vamos a retirar el mantenimiento y el soporte de tu sistema antiguo; lo retiraremos en esta fecha, y tienes hasta esa fecha para pasar al nuevo sistema o, de lo contrario, cortamos el soporte.”

Y creo que eso es extremadamente imprudente; no es una declaración del problema enfocada en el cliente. Esencialmente, están tomando un problema del proveedor y convirtiéndolo en el problema del cliente. El problema del proveedor es que necesitamos movernos a la computación en la nube porque es más rentable para nosotros; nuestros inversionistas lo exigen. Entonces, ese problema se convierte en el problema del cliente porque ahora están diciendo, “Oye, sé que tal vez acabas de implementar una solución on-premise hace, digamos, dos años, pero ¿adivina qué? Vamos a cortar el soporte para ese mismo sistema que acabas de implementar; vamos a cortar el soporte en dos o tres años, y tienes hasta entonces para pasar al nuevo sistema.”

Entonces, eso crea un pánico apresurado en las organizaciones, y ese es el peor lugar para estar cuando estás tratando de llevar a cabo esta transformación porque conduce a muchas de las cosas que mencionas, es decir, ahora simplemente voy a hacer estas mejoras incrementales. Voy a gastar todo este tiempo, dinero y asumir riesgos solo para obtener tal vez algunas mejoras mínimas en mi negocio, y es difícil justificar el ROI siguiendo ese proceso.

Conor Doherty: Joannes, sé que eres un gran fan de los proveedores y los defiendes a capa y espada, pero ¿puedo pedirte un comentario al respecto?

Joannes Vermorel: Sí, quiero decir, mi opinión es que la industria del software —divido, por cierto, el mundo del software empresarial en tres reinos distintos—. Tenemos sistemas de registros, sistemas de informes y sistemas de inteligencia. Los sistemas de registros se tratan realmente de entradas de datos y flujos de trabajo. Esto es todo lo que conlleva la gestión en un sistema de registros, que puede ser CRM, ERP (que debería haberse llamado ERM, gestión de recursos empresariales, porque la planificación es como una preocupación secundaria), TMS, sistemas de gestión de transporte, etc. Todos esos sistemas de gestión son sistemas de registros.

Mi opinión es que una vez que tienes un sistema de registros que encaja, que funciona y que no es excesivamente lento, ya has terminado en lo que respecta a esa capa. Lo que veo como transformación digital es que la gente intenta mejorar cosas que realmente no se pueden mejorar mucho. Si, por ejemplo, eres contador, ya tienes un libro mayor; es bueno, no es tan reluciente, pero, ¿tiene este libro mayor todo lo que necesitas? Sí, y eso es lo que esos sistemas de registros son.

Los sistemas de registros, y es que en esas transformaciones digitales, gran parte de la discusión se centra en actualizar sistemas de registros que ya están capturando, de alguna manera, todo lo necesario. Para mí, el valor añadido de este tipo de transformación, que típicamente absorbe más del 80% del presupuesto, es casi nulo, porque ya tienes tus flujos de trabajo. Ya funcionan. Tu software, quiero decir, la siguiente interfaz no hará gran diferencia, ya que se trata de entradas de datos y demás.

Y si tienes eso, y funciona y captura funcionalmente lo que necesitas, ya estás listo. Y creo que la maldición de esos proveedores empresariales es que se dan cuenta, especialmente compañías como SAP, de que han llegado a un punto en el que el trabajo estaba hecho. Misión cumplida para el sistema de registros hace dos décadas.

Y ahora, y por cierto, se puede explicar todo el movimiento de SAP HANA hacia, “Oh, transformemos esto,” pasando de ser un sistema de registros a un sistema de informes con todo tipo de capas analíticas. Pero mi análisis es que simplemente debes mantenerte firme. Tú eres un sistema de registros. Y cuando las empresas lo ven de esa manera, dirán, “No deberíamos invertir en eso porque la próxima versión solo traerá errores, regresiones, nueva capacitación, a menos que los sistemas antiguos fueran insoportables por ser demasiado lentos, tener demasiados errores o ni siquiera poder capturar esos registros que necesitábamos. Entonces, no hay valor añadido.”

Y para nosotros en supply chain, es realmente importante porque veo muchos clientes que tienen sistemas de gestión de inventario que tienen como 30 años de antigüedad. Son pantallas de consola de texto en blanco y negro, pero funcionalmente hacen el 100% de lo que esas compañías necesitan. Y la gestión de inventario, ya sabes, no es ciencia de cohetes. Tomo algo, más o menos uno en el estante. Pongo algo en el estante, más uno.

Así que ese software es antiguo y, funcionalmente, cumple el 100% de lo que necesitan. Por lo tanto, en este tipo de situaciones, gastar mucho dinero solo para actualizar esos sistemas no conduce, para mí, al resultado que la gente piensa que obtendrá al invertir en este tipo de camino.

Eric Kimberling: Estoy de acuerdo. Y creo que por eso compañías como Palantir y Snowflake, algunos de estos… no quiero decir que sean sistemas acoplables, sino que son sistemas diseñados para interoperar con otros sistemas de registros.

Así es como han surgido compañías como Palantir, Snowflake y otras. Crean una solución que dice, “Conserva tu sistema antiguo. No nos importa. Te proporcionaremos una solución que no interfiera con él. En cambio, se basa en él y te ofrece mejores flujos de trabajo, mejor IA, mejores informes, mejor inteligencia, y todo eso.”

Así que creo que tienes razón. Esas son las opciones que muchas veces las organizaciones y equipos no se dan cuenta. Tienen opciones porque escuchan de otros proveedores que, “No, no, no, necesitas reemplazar tu sistema de registros porque está basado en una tecnología antigua. Tienes deuda técnica. Te vas a quedar atrás.” Ya sabes, es una estrategia de venta basada en el miedo. Y funciona.

Afortunadamente para los proveedores, funciona. Desafortunadamente para los clientes, también funciona. Así que creo que la clave es simplemente educarte, ser objetivo, y obtener esa opinión externa objetiva sobre cuáles son tus verdaderas opciones, porque podría ser que dejes tu sistema de registros en su lugar, pero añadas algo que te brinde más capacidades sin todo el riesgo.

Joannes Vermorel: Promoción sin tapujos, este es exactamente el modelo de negocio de Lokad. Está orientado de la misma manera que Palantir o Snowflake. Hacemos justamente eso por esas razones. Pero, obviamente, no quería obligarte a decirlo. Pero sí, ese es mi punto. El problema con esos sistemas de registros es que, cuando los tocas, la cantidad de disrupción para la organización es inmensa.

Puedes encender y apagar un Snowflake que realice análisis paralelos, ya sabes, sin problema, hasta que dependas realmente de él para tu operación diaria. Pero hasta entonces, puedes encender y apagar esto tanto como desees. A diferencia del sistema de registros, donde si lo tocas y se rompe, se desata el caos porque de repente no sabes a quién debes pagar, a tus proveedores, quién te debe dinero de tus clientes, etc.

Así que los sistemas de registros son una capa mucho más sensible y delicada. Y por eso diría que el aspecto positivo no es tan significativo, porque si ya tienes algo que es funcionalmente satisfactorio, la actualización no hará gran diferencia. Pero el aspecto negativo, si se rompe, puede ser absolutamente inmenso.

Recientemente, en Francia, tuvimos una gran empresa que simplemente quebró, GiFi, debido a —de hecho, tengo esto abierto frente a mí— una mala gestión de la transformación digital. Una empresa multimillonaria que se declaró en bancarrota por una transformación digital mal gestionada.

Eric Kimberling: Digamos que también es una gran empresa bien conocida en Francia, ¿verdad?

Joannes Vermorel: Sí, fue, digamos, una de las diez principales redes minoristas a nivel nacional.

Conor Doherty: Esa es, en realidad, una transición perfecta porque, de hecho, quería hablar de algo en lo que comentas mucho, Eric, que es tomar ejemplos de grandes empresas que todos conocen. De hecho, tengo una lista abierta frente a mí. Has escrito y grabado sobre Lidl, por ejemplo. Lo tengo aquí: un fracaso de 600 millones al intentar transformar su sistema ERP. Disculpa. Pero también existen casos en todo el mundo, no solo en Europa.

Conor Doherty: Tienes a DHL perdiendo cientos de millones, Lidl en Alemania perdiendo medio billón. Asda, GE, Spar. De hecho, recuerdo haber visto un video tuyo sobre Spar también. Así que, de nuevo, se trata de empresas enormes, por lo que, nuevamente, no está localizado únicamente en Europa o solo en Francia, por ejemplo, o únicamente en Washington o lo que sea. Esto es casi una ocurrencia sistémica.

Ahora, no quiero ponerte palabras en la boca, pero si de hecho es algo sistémico entre las grandes empresas, la pregunta se convierte en: ¿hay algo intrínsecamente vulnerable en las grandes empresas que conduce a esto? ¿Les falta agilidad o qué? ¿Por qué estas grandes empresas están perdiendo tanto dinero?

Eric Kimberling: Esa es una gran pregunta. Primero, no lo sé. Tampoco podría decirte de ninguna manera. Sí, sospecho que probablemente hay tasas de fracaso un poco más altas en las grandes empresas, aunque diré que hay muchas empresas pequeñas y medianas que también fracasan. La única diferencia es que no se oye de ellas porque a nadie le importa.

Nadie ha oído hablar de estas empresas antes, pero sí han oído hablar de Lidl. Han oído hablar de Spar Group. Han oído hablar de Asda, o del gran nombre que sea. Pero creo que para responder a tu pregunta sobre por qué, ya sabes, las grandes empresas son más susceptibles a estos fracasos, diría que las dinámicas que se dan en una gran empresa favorecen el fracaso, en parte por el comportamiento organizacional. Parte de ello es que una gran empresa, por ejemplo, es más propensa a implementar una solución grande y compleja porque es una empresa grande y compleja y siente que necesita una solución aún más grande y compleja.

Así que es más probable que compren un SAP o un Oracle u otro sistema grande. Eso, de por sí, es un factor de riesgo. Eso aumenta tu riesgo de inmediato porque ahora tienes un sistema grande y complejo que intentas implementar.

La otra dinámica que se da en las grandes empresas con mayor frecuencia que en las empresas más pequeñas es la falta de responsabilidad, por así decirlo. Hay menos visibilidad y responsabilidad a nivel ejecutivo. A menudo, estos ejecutivos tienen demasiadas cosas en sus manos. Se están expandiendo. Están entrando en nuevos mercados y saliendo a comprar empresas. Están enfocados en estas cosas estratégicas y ven la transformación digital como algo no estratégico, lo cual es un error.

Y delegan eso en la organización. Y esa falta de propiedad ejecutiva, transparencia, visibilidad y compromiso, esa falta de involucramiento ejecutivo, conduce al fracaso. Esa es una de las principales causas. Y luego, diría que una tercera cosa, una tercera dimensión que trabaja en contra de las grandes empresas es que estas son más propensas a ser tan adversas al riesgo que, irónicamente, aumentan el riesgo.

Y con eso quiero decir que dicen, “Bueno, si implemento SAP, SAP es un producto reconocido. Si contrato a Accenture, Deloitte o KPMG, esa es una firma muy reconocida. Así que voy a cubrir todas mis bases y asegurarme de contratar a los nombres blue-chip que me harán sentir cómodo de que son los expertos, de que pueden manejar esto.”

Y luego lo que sucede es que tienes un libro de cheques abierto y el integrador de sistemas se hace cargo de tu proyecto porque tus ejecutivos no están tan involucrados y confían en las grandes marcas. Y esas grandes empresas se encaminarán a implementar tecnología y complicarán las cosas en exceso, incluso si no tiene necesariamente sentido para tu negocio, porque eso es lo que saben. Eso es lo que hacen.

Eso es lo que hacen, y no creo que sea, en realidad, algo malintencionado de forma intencional. Pero creo que la falta de propiedad y transparencia lleva a que las personas persigan su propio interés, lo cual, cuando tienes a los proveedores y a los integradores de sistemas persiguiendo su propio interés, quieren venderte más software. Quieren facturarte más horas, y el ROI no entra en juego en absoluto. No importa si aporta valor o no. Les van a pagar.

Así que los incentivos están desalineados. En una gran empresa, una empresa grande y compleja, esas dimensiones se magnifican porque es una empresa mayor y hay más en juego. Así que, creo que esas tres cosas son probablemente las tres más importantes que vienen a la mente en cuanto a lo que afecta más a una gran empresa que a una más pequeña. Aunque diré que una empresa pequeña o mediana también es probable que fracase si no sigue simplemente los fundamentos básicos.

Y la buena noticia es que no hay ciencia de cohetes ni una fórmula secreta para hacerlas exitosas. Es en realidad bastante simple, pero las organizaciones no se toman el tiempo de detenerse, reflexionar y tomar las decisiones correctas desde el principio. Eso conduce a muchos de estos problemas de los que estamos hablando.

Conor Doherty: Gracias Eric. Joannes, has comentado una o dos veces sobre la burocracia en las grandes empresas. ¿Podrías repetir esos pensamientos?

Joannes Vermorel: Sí, quiero decir, mi opinión es que las empresas pequeñas pueden fracasar porque, sí, carecen de los recursos para tener a los expertos y demás. Creo que en las grandes empresas, donde con frecuencia fracasan, tienen a todos los expertos, pero el problema es que vienen con una agenda. Todos esos expertos son contratados y vienen con todo tipo de agendas.

A veces son, diría yo, agendas tontas, como que la gente solo quiere probar una nueva tecnología porque se verá bien en su currículum. Así que no subestimen tampoco el hecho de que los chicos de tecnología harán cosas tecnológicas simplemente por el gusto de experimentar y trastear.

Pero también, creo que un problema es, como señalabas, que la transformación digital no se considera estratégica. Como efecto cascada, he visto frecuentemente que la alta dirección en las grandes empresas no tiene mechanical sympathy.

¿A qué me refiero con mechanical sympathy? No tienen ninguna curiosidad por lo que ocurre bajo el capó, por cómo se conectan esas cosas, de qué estamos hablando. No estoy hablando de llegar a ser un ingeniero de software experto, sino, ¿estamos hablando de algo simplemente como una aplicación rudimentaria, ya sabes, crear, leer, actualizar, borrar en una base de datos que resulta tener muchas tablas?

¿O necesitamos tiempo real? ¿Qué significa tiempo real? ¿Necesitamos microsegundos, milisegundos, segundos u horas? ¿Necesitamos, etc., etc.? Quiero decir, hay muchas preguntas que son relativamente básicas, pero si no tienes lo que yo llamo ninguna mechanical sympathy en absoluto, entonces los objetos o los objetos de software que manipulas son completamente abstractos.

Y para ti es una serie de nombres en clave que no tienen ningún sentido. “Oh, necesitamos el widget ABC20, y pero para que ABC20 funcione también necesitamos actualizar Contoso12.” Y Contoso12, oh, también necesita la cosa número siete, etc., etc.

Quiero decir, eso es como una larga lista de nombres en clave que no tienen ningún sentido. Entonces, si tienes este tipo de ambiente que, diría yo, se presta muy fácilmente a una especie de captura tecnocrática. Ya sabes, la perspectiva empresarial se tira por la ventana simplemente porque, de hecho, las personas de negocio han renunciado completamente a sus reivindicaciones porque no tienen mechanical sympathy. Así que ni siquiera pueden darse cuenta para expresar una opinión sobre si las cosas se están encaminando en una dirección que esté alineada con el negocio o no.

Disculpa, es una respuesta larga, pero este ingrediente de mechanical sympathy lo he visto ausente en muchas, muchas empresas. Y no requiere tanta experiencia. Ya sabes, es como un tipo al que le gustan los autos, que se tomará un poco de tiempo para saber qué hay bajo el capó, para que no parezca magia pura que el auto se mueva hacia adelante. Existe cierto entendimiento de los principales componentes que hacen que la cosa suceda.

Eric Kimberling: Sí, absolutamente. Es un término interesante. No había oído hablar de mechanical curiosity, y creo que vuelve al punto que a menudo menciono. Creo que están muy interconectados, y eso es la propiedad general y la curiosidad sobre el producto en conjunto.

Y así creo que eso abarca lo que estás diciendo, que es la mechanical curiosity. Pero creo que tienes razón en algo aquí, que es que, si no haces lo que acabas de decir sobre tener esa mechanical curiosity, no hay manera de que tengas la propiedad y la inteligencia adecuada para tomar decisiones inteligentes en torno a estos proyectos.

Y al no tener esa curiosidad práctica y experiencia, no tienes que ser tan experimentado como los expertos, pero al menos lo suficiente para poder gestionar a esos expertos porque es tu trabajo dirigirlos. No deberían gestionarte a ti solo porque son los expertos. Es tu empresa. Tú eres quien tiene que vivir con los resultados, así que adminístralos en consecuencia.

Me asombra cuántas de estas grandes organizaciones dicen, “Eso es, no soy un tipo de tecnología. No soy responsable, voy a dejar que los expertos se encarguen de esto.” Pero es una transformación empresarial, y si la estás haciendo bien, en realidad es una transformación empresarial, y necesitas estar involucrado, muy involucrado.

Incluso si no estás involucrado en la mechanical curiosity técnica, al menos deberías estar involucrado en la curiosidad operativa. ¿Qué significará esto para mi organización? ¿Cómo serán mis operaciones? ¿Cómo se verán afectados los trabajos de las personas? ¿Quiero eso, está bien, o quiero algo diferente?

Y si no estás involucrado en eso, el integrador de sistemas inevitablemente creará lo que ellos consideren correcto, y eso simplemente no coincidirá con tu visión y tu estrategia.

Conor Doherty: Si se me permite, solo porque estoy de acuerdo con ambos, pero solo quiero añadir un pequeño comentario porque te he escuchado hablar sobre mechanical sympathy en algunas ocasiones. Recientemente, en un podcast diferente con the Supply Chain Connect, saludo, hablé de ese concepto exacto.

Había dos puntos realmente buenos, los beneficios directos de mechanical sympathy. Obviamente, cuando entiendes un poco sobre el software, sabes cómo aprovecharlo mejor, por lo que aumenta el ROI directo de utilizarlo. Pero también te protege de afirmaciones falsas de los proveedores.

Y habías dicho eso antes, que entender un poco o algo sobre lo que se está diseñando, lo que el software es capaz de hacer, puede aislarte de quizás afirmaciones engañosas de los proveedores.

Joannes Vermorel: Sí, quiero decir, solo un ejemplo, digamos, por ejemplo, los LLMs. Bien, la IA es genial, fantástica, bien, así que tenemos esos grandes modelos de lenguaje. ¿Cuál es el costo de ingerir un megabyte de datos en un LLM, solo para tener una idea aproximada?

De forma aproximada, es un megabyte, incluso si tomas un modelo barato, estamos hablando básicamente de $1, y eso es en el extremo bajo. Cada vez que quieres obtener una respuesta, si debes procesar un megabyte de datos como entrada con tu LLM, te costará $1, incluso con el modelo más barato.

Si simplemente tienes este número en mente, sabes que hay muchas cosas que están fuera de discusión y probablemente permanecerán invisibles por más de una década. Porque si piensas, bien, tengo terabytes de datos, bien, primero no voy a procesarlos a través de los LLMs.

Y luego, si cada vez que alguien hace clic tuvieras que pagar $1. Es decir, simplemente haces de nuevo una matemática súper básica que te dirá, bien, esto no puede funcionar. No es económicamente viable.

Incluso si el precio baja por un factor de 100, aún estamos a cuatro ceros de cualquier cosa sensata. Solo es un ejemplo, y he visto muchas situaciones en las que, al discutir con prospectos, se dijo: simplemente toma algunos órdenes de magnitud básicos para que sepamos de qué estamos hablando.

Lo mismo, por ejemplo, para la computación distribuida. La computación distribuida está muy limitada por la velocidad de la luz. La gente dice, “¿Por qué necesito saber la velocidad de la luz?” Pero la respuesta es que si tienes un sistema donde vas a tener tu warehouse que estará comunicándose con tu sistema central y la información va y viene, tienes 200 milisegundos de latencia.

Te das cuenta de que necesitas mil idas y vueltas para hacer algo. Entonces ya estamos hablando de 200 segundos solo en idas y vueltas para hacer eso. De nuevo, no es como una matemática súper sofisticada, pero es el tipo de cosas donde, bien, tenemos un problema de diseño.

No necesitas ser un ingeniero avanzado, solo estamos hablando de multiplicaciones simples, solo unos pocos datos básicos. He visto muchos proyectos que han fracasado con nuestros clientes que estaban condenados porque no se habían hecho algunos cálculos básicos de regla empírica.

Si es así, la gente se daría cuenta de que simplemente no funcionaría considerando los objetivos del negocio. Porque el tipo, el tecnólogo, podría decir, “Bueno, tomará 200 segundos. Muchos cálculos toman tiempo, ¿por qué no 200 segundos?”

Pero el tipo diría, “No, esto es algo en lo que un operador está esperando, así que ni siquiera es posible.” O, el LLM diría, “Oh, cuesta un megabyte, $1.” El ingeniero diría, “Sí, ¿por qué no? Sabes que es solo un punto de precio, no me importa.”

No me importa, y luego el negocio dice, “¿Pero te das cuenta de que una persona a la que se le paga algo como $20 la hora va a hacer clic en esto 60 veces por hora?” Así que el costo de tu LLM va a ser como cuatro veces lo que pagamos a la persona que lo opera.

De nuevo, esa es la única manera de asegurarse de que tenga sentido: tener este negocio con algo de mechanical sympathy involucrado, enmarcando el proyecto y su valor agregado, el valor agregado previsto, que en cierto modo tiene sentido. Esa sería mi opinión.

Eric Kimberling: Sí, y solo entendiendo esos costos ocultos y esas cosas que en la superficie pueden parecer que realmente están mejorando tu negocio. Podría estar mejorando tu negocio, pero si aumenta dramática y materialmente tus costos, entonces probablemente no podrás obtener el ROI que buscas.

Joannes Vermorel: Sí, y de nuevo, no subestimes cómo, según mi experiencia con los ingenieros: cómo los ingenieros pueden darte cinco dígitos de precisión, pero la coma está un poco equivocada en el cálculo.

Así que eso es, por eso digo que los ejecutivos realmente necesitan tener, tener este mechanical sympathy, tener este interés por la transformación digital y lo que conlleva. Porque de lo contrario, estás en manos de tecnólogos que están entusiasmados con la tecnología—bien, perfecto—pero que pueden distraerse muy fácilmente y perder de vista esos órdenes de magnitud que simplemente condicionan si tendrás un ROI positivo o no.

Conor Doherty: Solo para asegurarme de haber entendido esto, el impacto que mencionaste anteriormente: un terabyte es un millón de megabytes, ¿verdad? Así que procesar un dólar por megabyte sería simplemente…

Joannes Vermorel: Un terabyte es mil gigabytes. Así que sí, es un millón de megabytes. Entonces, un terabyte a este precio que estaba mencionando costaría un millón de dólares por terabyte para ser procesado.

Conor Doherty: Solo asegúrate de que lo entendí.

Joannes Vermorel: Así que sí, quiero decir, si quieres hacer eso, probablemente no quieras hacerlo en primer lugar. Y si absolutamente tienes que hacerlo, realmente deberías asegurarte de no tener que hacerlo más de una vez al año, porque obviamente, incluso para una empresa grande, estamos hablando de costos de TI bastante extravagantes.

Conor Doherty: Bueno, sí. Bueno, en realidad, Eric, si puedo volver a eso, porque el tenor general de aquello, el marco global, eran cosas que faltaban. Pero quiero volver a algo más que faltaba. Ya sabes, ya discutimos la simpatía mecánica, pero en eso, ambos presentaron la idea del ROI o retorno financiero.

Y algo que dijiste antes, Eric, cuando hablabas de empresas, como grandes compañías, seleccionando cuál va a ser su software, “Oh, simplemente, ¿cuál es el gran nombre? Lo conseguiremos. ¿Y cuál es la gran consultora? La conseguiremos porque, ya sabes, casilla marcada.” Y dijiste, porque en ese contexto, a menudo el ROI no importa. Ahora sé que Joannes ha hablado antes sobre KPIs financieros y ROI en supply chain, pero me preguntaba, ¿podrías desglosarlo un poco, como por qué crees que la perspectiva financiera podría no estar tan presente en supply chain como quizás debería?

Eric Kimberling: Sí, creo que con la tecnología cambiando tan rápidamente y de manera exponencial, es casi como una carrera armamentista nuclear en la que la gente siente FOMO, ya sabes, el miedo a quedarse fuera. Y quieren asegurarse de no sufrir de deuda técnica y de todos esos términos sofisticados que los analistas y proveedores de software inventan.

Así que pierden de vista lo esencial. Creo que, creo que la industria está perdiendo de vista por qué estamos realizando estos proyectos tecnológicos. Quiero decir, no lo hacemos porque queremos capacidades de computación en la nube. No lo hacemos porque queremos IA. Ni siquiera lo hacemos porque queremos mejor inteligencia o reportes o un mejor sistema de registro.

Hemos perdido de vista todo eso. Simplemente, no nos hemos enfocado en por qué necesitamos esa tecnología. ¿Por qué necesitamos, por ejemplo, migrar a la nube? Quiero decir, a veces les pregunto a los clientes y me ponen miradas vacías, como, eh, porque ahora estamos en premisas. Yo digo, “Bueno, están en premisas. Entonces, ¿cuál es lo peor que podría pasar si se quedan en premisas cinco años más?”

Bueno, ya sabes, entonces no estaremos en la nube, o el proveedor de software va a cortar nuestro mantenimiento. Bien, espera un momento. Hablemos de eso. Quizás corten tu mantenimiento, ¿cuál es lo peor que pasaría? Bueno, tendríamos que mantenerlo nosotros mismos, y no podríamos contactar al proveedor para soporte. Bien, entonces quizá tengas que contratar a alguien.

Veamos. Pero revisemos esa opción, porque en realidad podría representar un riesgo mucho menor para ti que pasar por una gran transformación de $600 millones, en el caso de Lidl, por ejemplo.

Así que las empresas no hacen eso lo suficiente porque sienten que deben hacerlo. Sienten que deben hacer una actualización. Deben moverse a la nube. Deben obtener IA, bla, bla, bla. Así que creo que todos los cambios en la tecnología y la velocidad con la que suceden hacen que las empresas se pierdan de vista, se enreden y olviden por qué están realizando estos proyectos en primer lugar.

Joannes Vermorel: Creo que, quiero decir, en primer lugar, los KPIs financieros son algo engañosos porque no creo que sean el enfoque correcto. Tu viaje digital, llamémoslo así, es de como 10 años. Tienes que pensar con una visión a 10 años adelante: ¿dónde quieres estar? Esas cosas son largas. Literalmente, son las empresas que estás diseñando.

Así que, en mi opinión, considerar KPIs que son algo a corto plazo no es realmente, para mí, algo relevante para pensar si es lo correcto o no. Es, típicamente, el tipo de cosas que habría dicho Walmart, año 2002, “Oh, no, e-commerce, no nos importa.”

Ese es el tipo de cosa que te lleva a decir, “Está bien, e-commerce es relevante; es tan pequeño, no nos importa.” No, en realidad es muy relevante, y habrá un gigante que será apenas más grande que tú en unos pocos años si no haces nada. Lo cual fue una transformación digital fallida. Quiero decir, la gran cadena de tiendas podría haberse convertido en el gigante del e-commerce; no lo hicieron porque, en cierto modo, fallaron en la transformación digital.

Pero, volviendo al tema, diría que no estoy tan inclinado, prefiero pensar desde una perspectiva empresarial a largo plazo. ¿Tenemos un cálculo aproximado que nos diga que esto es lo correcto? Ajustado al riesgo, es decir, ¿crees que hay un riesgo del 90%, o del 50% o del 10%, y tratar de tener la simple suposición solo para justificar y avanzar en esa dirección?

Y ahora creo que lo que típicamente falta es que, de nuevo, mencioné el incrementalismo. La gente piensa en su transformación digital como lo mismo pero un poco mejor. Nuevamente, si volvemos a Walmart 2002, el futuro es el ecommerce, así que definitivamente no es lo mismo que simplemente Walmart con un punto de venta un poco mejor con pantalla LCD.

Esto no es, verás, ese es el problema. El futuro es fundamentalmente algo diferente, y creo que ese es usualmente el punto donde las empresas no se esfuerzan lo suficiente para desafiar cómo se verá la compañía en 10 años. ¿Cuáles son los tipos de roles? Creo que hubo un memorando muy interesante del CEO de Shopify que circulaba recientemente en LinkedIn.

Literalmente les decía a todos, “Por ahora pausamos todas las contrataciones, y cada departamento tendrá que justificar que lo que quieren contratar no puede ya ser realizado con las tecnologías de IA, LLMs y demás que ya hemos adquirido, implementado y conectado en nuestro sistema.” Shopify es una compañía bastante de alta tecnología, así que ya tienen varios años de experiencia en ello.

Y decía, “Bueno, tenemos un problema en términos de transformación. Claramente, la esencia del memorando era que la gerencia en general simplemente no se estaba quedando en perspectivas muy incrementales, sino en ser mucho más ambiciosa en el juego final.” Y creo que el mensaje fue muy interesante. No decían, “No invertimos, no contratamos.” Decían, “Necesitas tener un juego final que reconozca que esas tecnologías existen y no deberías intentar seguir una trayectoria que simplemente finge que no existen.”

Ese fue el caso del memorando, y fue muy interesante. Veo muchas grandes empresas donde, en términos de cuál es tu visión a 10 años para la compañía digitalmente transformada, lo que sea que signifique, es simplemente lo mismo pero con una interfaz de usuario un poco mejor. Y para mí, esto es muy poco impresionante.

Piensa a 10 años en el futuro, necesitas imaginar algo en lo que la mitad de los trabajos, especialmente los de oficina, que existen hoy ya no estén. No significa que despidas a las personas; puedes capacitarlas de nuevo, reubicarlas, y demás. Pero los trabajos en sí, al menos la mitad de ellos, dentro de 10 años, simplemente habrán desaparecido, y así será.

Eric Kimberling: Sí, y creo que estás tocando un punto realmente importante, que es, para las personas que escuchan y que están liderando iniciativas de tecnología o transformación en sus supply chains o donde sea que estén trabajando, creo que es importante que se pregunten: ¿Qué queremos que sea esta iniciativa? ¿Es esta iniciativa para reemplazar la tecnología antigua y simplemente mantenerse actualizados, lo cual tal vez sea de carácter incremental, idealmente de menor costo, pero con potencialmente menor ROI? ¿O buscamos transformar nuestro negocio, transformarlo verdaderamente, y explorar nuevos modelos de negocio e innovación? Esos son dos caminos muy diferentes, y ninguno es correcto o incorrecto. Solo tienes que asegurarte de estar alineado y tomar decisiones que se ajusten al camino que estás siguiendo. Tampoco debería ser una propuesta única para todos; debería basarse en quién eres. La estrategia digital de Shopify debería lucir muy diferente a la tuya, la mía o la de cualquier otra persona.

Joannes Vermorel: Estoy muy de acuerdo, pero el problema que veo es que la ruta número uno, simplemente la actualización incremental de bajo ROI, es donde se obtienen los presupuestos masivos.

Eric Kimberling: Sí.

Joannes Vermorel: Sí, y para mí, es como: ¿cómo puedes tener este proyecto en el que, si haces cualquier cálculo aproximado, tu ROI va a ser muy modesto? ¿Por qué gastar? He visto empresas, y no voy a revelar nombres, pero he tenido discusiones con compañías que tienen actualizaciones ERP de más de $100 millones que se extienden a proyectos de más de cinco años. Cuando lo discuto con la alta dirección, es muy difícil ver si habrá algún retorno—no solo retorno sobre la inversión, sino retorno en general. Una vez que actualizas, ¿será el negocio realmente mejor? Ni siquiera está claro, especialmente si tienes que recurrir a los requerimientos de hardware de SAP HANA, es decir, solo estoy mencionando SAP; no son los únicos.

Conor Doherty: Dale, está bien.

Joannes Vermorel: Sí, pero si congelas tu TI durante cinco años, solo el costo de oportunidad es inmenso. No puede ser algo meramente incremental; tiene que ser mucho más que eso.

Conor Doherty: Entonces, Eric, si puedo añadir a eso, porque literalmente, Joannes, ¿qué acabo de escribir allí—costo de primera orden, costo de segunda orden, costo de oportunidad—literalmente, acabo de escribir esas mismas palabras para devolverte la idea. Eric, nuevamente, como consultor, estaba a punto de preguntarte, ¿cómo explicas exactamente el concepto de costos de primera y segunda orden? Porque, obviamente, el costo de primera orden: compras este software, te costará 50, 100, 150 millones; tendrás que contratar personas para supervisarlo, lo que costará otros x millones, lo que sea. Ese es el costo de primera orden.

El costo de segunda orden es, como Joannes acaba de decir, el costo de oportunidad. El dinero que acabas de gastar en eso, ahora no puedes gastarlo en otra cosa, porque un dólar aquí no puede ser gastado simultáneamente allá.

Joannes Vermorel: Tu equipo de TI está inundado, congelado en el tiempo con este asunto durante un cierto periodo también.

Conor Doherty: Esto, de nuevo, se relaciona con la perspectiva financiera a la que me refería antes. ¿Cómo, personalmente, cuando estás en una sala como alguien tecnológicamente agnóstico, ayudas a las personas a entender—y no lo digo de manera condescendiente, simplemente lo digo literalmente—que tomas un dólar, no puedes comprar dos barras de chocolate si una cuesta un dólar y la otra cuesta un dólar; no puedes comprar ambas con un solo dólar. Entonces, costo de oportunidad de primera y segunda orden, ¿cómo abordas esos temas de una manera que realmente resuene con la gente que, como has dicho, tiene FOMO—no quieren quedarse fuera, quieren subirse a la ola, etc.?

Eric Kimberling: Estás aludiendo a algo que no hemos tocado realmente o en lo que no hemos profundizado demasiado, y eso son las expectativas realistas y tener expectativas realistas en torno a esos costos de primera y segunda orden. Creo que la causa raíz, o una de las causas raíz del problema, es que las organizaciones no entienden cuál es el costo real, por lo que no pueden evaluar esos costos de oportunidad porque piensan que costará 100 millones cuando en realidad nunca iba a costar 100 millones; siempre iba a costar 300 millones. Pero alguien te convenció de que se podía hacer por $100 millones, y esa persona estaba sobredimensionando el precio, subestimando el esfuerzo, sabiendo que hay complejidades y riesgos que probablemente van a aumentar el costo. Si lo piensas, cuando un proveedor de software o de soluciones te está vendiendo una solución, no les beneficia, desde una perspectiva egoísta, sobreestimar el costo. Lo que les ayuda es subestimarlo y decir, “No, no, es de bajo riesgo, de bajo costo.” Así que el problema comienza ahí.

Entonces, bueno, si digo que voy a evaluar los costos de oportunidad, esos costos de segunda orden, lo hago con información defectuosa. Incluso si lo hago, no importa porque no tengo la información precisa para tomar esa decisión. Pero creo que si más empresas conocieran el costo real que realmente iba a tener, dirían, “Whoa, whoa, espera, eso es mucho dinero. Ese es dinero que podríamos estar usando para construir otra fábrica. Podríamos abrir 10 tiendas más con ese mismo costo. ¿Es eso lo que queremos?” La mayoría de las organizaciones no llegan a ese punto de decisión porque se basan en un costo subestimado que nunca fue realista.

Otra cosa, bueno, hay otra cosa que, digamos—y pensé que tal vez aquí es donde ustedes iban con el costo de primera y segunda orden—pero otro costo en el que aún no hemos profundizado es la disrupción operativa. Ya sabes, ¿qué sucede cuando adoptas una nueva tecnología por primera vez, sin importar cuán bien se ejecute el proyecto? Va a haber una caída en la productividad de algún tipo. Ahora, con suerte, no será una caída completa por un precipicio en la productividad; demasiadas veces lo es. Pero incluso si lo gestionas muy bien, simplemente vas a tener cierta disrupción.

Entonces, ¿cuál es ese costo de disrupción, y qué pasaría, por ejemplo, si no puedes enviar productos durante dos semanas, cuatro semanas, tres meses? Eso le pasa a las organizaciones; atraviesan estos proyectos, algo sale mal, se ponen en marcha, y luego no pueden enviar productos. Los clientes se enojan, cancelan los pedidos. Esos son los costos reales. Esos son los costos que también debes tener en cuenta en tu ROI, para que puedas optimizar tu implementación y asegurarte de gestionarla bien y entender cuál es el riesgo real.

Conor Doherty: Has sacado un muy buen punto ahí, Eric, y Joannes, quiero volver a ti para retomar el ejemplo que Eric acaba de dar. Como si tomaras a alguien—y no apunto a nadie en particular—pero si tomaras el promedio de la industria automotriz o aeroespacial o de petróleo y gas, y dijeras, “¿Cuánto cuesta, en términos de pérdida de productividad, una hora de inactividad?” Ellos podrían darte un orden de magnitud aproximado, pero los tipos de inactividad que Eric acaba de describir, quizás no podrían cuantificarlos.

Joannes Vermorel: Sí, y también creo que en cuanto al costo operacional, es completamente acertado. Una cosa que la gente no se da cuenta es que la productividad disminuye cuando la complejidad de tu entorno aumenta. Así que, ves, tienes un software; es antiguo, hace muy pocas cosas, pero hace lo que necesitas. Significa que, en términos de mi entorno de TI, mi interfaz de usuario no tiene tantos botones, no tiene tantas opciones, no tiene tantos adornos y palabrerías, y cosas que puedo hacer con él. Ahora lo actualizo a algo que es muchísimo más poderoso. ¿Por qué? Porque el proveedor, había tantas casillas que necesitaban ser marcadas en el AFP. Le preguntamos al proveedor, “Debería ser capaz de hacer esto y aquello y aquello y aquello y aquello y aquello, bueno, 100 casillas después.” Ahora tenemos el sistema actualizado que, además, puede hacer toneladas de cosas.

Pero eso significa que para la persona que opera el software, tienes muchos más menús. Y he visto eso una y otra vez en software empresarial, donde la gente me muestra el software y yo digo, “Esto es horrible.” Es como si tuvieras 30 menús, y luego hago clic en cualquiera de ellos, y cada menú tiene como 30 submenús, y tal vez cada submenú tenga como cinco submenús. Y luego tienes una pantalla completa con 20 opciones diferentes en la pantalla.

Y así, lo que presencié con mucha frecuencia fue que la gente actualiza un software, especialmente esos sistemas de registro, a uno nuevo, mejor. Sí, la IU es más agradable, pero tiene muchas más características que, en realidad, hacen que la productividad sea menor, simplemente porque la gente se pierde en un laberinto de funciones. Y entonces, lo interesante es que en el software empresarial, más no es necesariamente mejor, especialmente cuando se trata de más características. Especialmente características que no usas.

Cada característica en un sistema que no usas es simplemente peso muerto. Significa que confundirá a cada nuevo recluta que venga y empiece a usarlo. Dirán, “¿Por qué no funciona?” Ah, porque hay como cinco pantallas diferentes para realizar órdenes de compra, pero solo usamos una de las cinco. Las otras cuatro, no, son simplemente callejones sin salida. Si ingresas tu información allí, no será procesada; simplemente se perderá y será ignorada. Ese es el tipo de cosas que puedes tener.

Eric Kimberling: Sí, absolutamente. Quiero decir, es un muy buen punto, y vuelve a definir realmente lo que necesitas. Es decir, ¿realmente necesitas toda esa tecnología? Muchas veces las empresas asumen más de lo que pueden manejar, y se sobrecomprometen con el gasto en tecnología. Y luego crea tanta complejidad solo en el lado técnico que después no tienes el tiempo ni los recursos.

Volviendo a tu punto sobre el costo de oportunidad, ahora no tienes el tiempo ni los recursos para invertir en las cosas que realmente importan. Y las cosas que realmente importan son: optimicemos nuestros procesos de negocio, aseguremos que las personas estén bien capacitadas, aseguremos que estamos logrando adopción, asegurémonos de que estamos redefiniendo los roles y responsabilidades de las personas para ajustarse a la nueva tecnología y al nuevo modelo operativo.

Esas cosas son las que determinan el éxito o fracaso de un sistema o una transformación. Pero, aun así, las empresas están sobreinvirtiendo en tecnología. Prefiero mucho más ver a una empresa que compra solo un poco de tecnología pero la implementa muy bien, porque esa empresa tendrá más éxito. Van a disminuir el riesgo, y probablemente obtendrán un mejor ROI.

Y luego, una vez que también has hecho eso, por cierto, una vez que tomas esa pequeña inversión en tecnología y la haces muy bien, construyes confianza, capacidades y madurez en tu organización hasta el punto en que ahora puedes decir, “Bien, voy a asumir un proyecto más grande ahora. Ahora me siento seguro de que hemos aprendido lo suficiente como para invertir en un poco más de tecnología.”

Y en lugar de simplemente comprar un único sistema masivo, gastar todo ese dinero, y luego sentir la presión de implementarlo todo porque lo pagamos, y después se genera toda esta complejidad, y no invertimos en adopción y mejora de procesos, todas las cosas que son importantes. Y es ahí donde muchos de estos proyectos se salen de control.

Conor Doherty: En realidad, y nuevamente, al igual que Joannes anteriormente, has planteado exactamente lo que acabo de anotar como la siguiente pregunta o como seguimiento. Hemos discutido en detalle los problemas y las minas terrestres que se deben evitar. Pero eso realmente pone de manifiesto el concepto de implementación y gestión del cambio, el proceso de gestión del cambio.

Entonces, Eric, primero para ti, quiero decir, en una nota más positiva, ¿hay algo que hayas observado en transformaciones digitales exitosas, ciertamente en el contexto de la gestión del cambio, en toda la cultura, las expectativas, etc.? ¿Cuáles son las cosas que realmente ayudan con eso?

Eric Kimberling: Sí, quiero decir, volveré al término que usaste—honestidad—¿dijiste que era simpatía mecánica, simpatía? Yo estaba diciendo curiosidad mecánica en mi mente. Ambos funcionan, para ser justos. Es más o menos lo mismo. La simpatía mecánica—ya sabía que lo había confundido anteriormente—pero la simpatía mecánica es realmente importante.

Porque los proyectos más exitosos que hemos visto son aquellos en los que los líderes del negocio en la organización están involucrados directamente. Ellos entienden la tecnología; puede que no sean expertos en configurar y codificar, no necesitan serlo, pero sí entienden cómo funciona la tecnología. Y definitivamente entienden cómo funciona su negocio y cómo quieren que funcione.

Esa empatía mecánica conducirá a una mayor responsabilidad y a resultados impulsados por el negocio en lugar de resultados impulsados por la tecnología. Así que eso es algo que vemos mucho: esa responsabilidad del proyecto, la participación activa de los líderes del negocio en la organización.

La otra cosa es, supongo que está algo relacionada con esto, es que no subcontratan la transformación. No dicen simplemente, “Vamos a traer grandes proveedores y dejar que ellos se encarguen de todo.” Dicen, “Vamos a traer expertos, pero los vamos a gestionar.” Así como gestionarías a un subcontratista o a un contratista general si contrataras a alguien para construir una nueva fábrica.

Probablemente no dirán simplemente, “No nos importa, solo vayan y construyan la fábrica, usen las mejores prácticas, hagan lo que necesiten para construir la fábrica.” No, estarán muy involucrados, asegurándose de que la fábrica cumpla con las especificaciones y demás. Pero con los proyectos tecnológicos, muchas empresas no hacen eso. Así que las empresas más exitosas tratan las inversiones y transformaciones en tecnología como cualquier otra inversión de capital.

No lo tratan de manera diferente; esperan un ROI, van a limitar el presupuesto, estarán muy involucrados, y tendrán mucho poder de decisión en el desarrollo del proyecto. Así que todo eso sucede desde el principio, y ese es un factor de éxito importante.

Otro punto, volviendo a lo que uno de ustedes mencionó anteriormente, es que las decisiones que se toman al principio son fundamentales. No quiero decir que la ejecución no importa, porque sí importa, pero lo que es aún más importante son las cosas que conducen a la ejecución real: las decisiones que se toman, las prioridades que se establecen, la alineación.

Lograr la alineación entre el equipo, porque muchas veces cuando entramos a una sala con, digamos, siete ejecutivos y tienes a nuestro comité directivo presente, y les pregunto, “¿Qué significa esta transformación para la organización?” usualmente obtendrás siete respuestas diferentes. Y ninguna de ellas es necesariamente correcta o incorrecta, pero todos están diciendo cosas distintas, y no se puede tener éxito.

Simplemente no tendrás éxito, sin importar a quién contrates, sin importar en qué tecnología inviertas, no tendrás éxito si no están todos en la misma sintonía. Es un proceso desordenado, y en teoría, podría retrasar el proyecto a corto plazo porque ahora estás diciendo, “Espera, detengamos la tecnología, no hagamos eso todavía, primero alineémonos.”

La gente piensa, “Bueno, pero necesitamos comenzar hoy.” Ya sabes, ya vamos atrasados, tenemos que seguir, y decimos, “Bueno, frena, porque si te apresuras, simplemente te lanzarás por un precipicio. Así que asegúrate de no caer; tómate el tiempo extra para asegurarte de tener un camino claro y luego ponerse de acuerdo.”

Entonces, esa alineación y tomarse el tiempo para establecer metas estratégicas, parámetros, prioridades, el caso de negocio, expectativas, gobernanza, definiendo nuestros procesos de negocio para el estado futuro—¿cómo queremos que sean nuestros procesos en el futuro? ¿Cómo queremos que sea la organización de aquí en adelante? Todas esas cosas deben definirse desde el principio antes de comenzar a desplegar la tecnología, y ese es un factor de éxito realmente importante.

Y luego, lo último que mencionaré es la inversión en gestión del cambio. Las empresas que invierten fuertemente, y cuando digo invierten fuertemente, no me refiero necesariamente a mucho dinero. Me refiero a que están invirtiendo tiempo y concentrándose en el cambio organizacional, la comunicación, la adopción, la claridad para la organización. Todo eso aumenta dramáticamente la tasa de éxito.

Joannes Vermorel: Estoy de acuerdo con tu anécdota. De hecho, en el software, ya sabes, yo también soy ingeniero de software. Hay un dicho que dice, “Oh, pasé tres horas pensando en el problema que quería implementar. Pasé tres horas, y me costó tres semanas extra de implementación.”

Pero volviendo al caso inicial, veo muchas empresas, ya sabes, grandes empresas toman esta idea, “Oh, sí, necesitamos planificar cuidadosamente.” Han escuchado ese consejo; no somos los primeros en decirlo. Así que hacen eso, pero veo una perversión de este tipo de pensamiento, lo cual, aunque estoy completamente de acuerdo en que es el camino correcto, requiere pensar muy claramente y tomarse un poco de tiempo, probablemente, en esta fase que es súper crítica.

Pero lo que he visto es que muchas empresas grandes corrompen esta idea en su organización convirtiéndola en un ejercicio de marcar casillas o en un ejercicio burocrático como, “Oh, estamos en la fase de planificación, así que necesito este informe y este informe y esta validación y esta auditoría y esta misión de diagnóstico y esto y esto y esto.” Y con lo que terminas no es claridad; terminas con un caso que puede tener miles de páginas y que aporta cero claridad. Es lo que yo llamo tecnocracia.

Es esta fase de planificación en la que terminas recopilando cosas de la organización, y todos cumplen excesivamente con la solicitud. Así que imagina que eres el directorio, y ahora, en un mes, tus equipos han reunido varias miles de páginas de evaluaciones, diagnósticos, etc. Y nadie tiene la menor idea del contenido. Es un poco como el proyecto de ley de gasto omnibus del Congreso en los EE. UU. Es como un documento masivo, de muchas miles de páginas, y nadie tiene la menor idea de lo que contiene.

Mi opinión es que también en esta fase de planificación se debe comprender que la gente no debe hacer esto como un ejercicio tecnocrático. Debes ser capaz de mantener la claridad en un documento que probablemente tenga, diría yo, entre cinco y 20 páginas como máximo. Si no puedes tener algo que se exprese claramente en máximo 20 páginas, idealmente menos que eso, entonces probablemente estás perdido en un laberinto tecnocrático.

Tu camino va a estar muy mal encaminado después. Y me refiero a páginas escritas en texto, no en PowerPoints, porque con los PowerPoints se puede hacer trampa con las viñetas—no tienes una conexión lógica, por lo que puedes tener algo que es súper ambiguo. Si escribes en inglés con una señalización y conexión adecuadas, entonces no puedes hacer trampa; necesitas tener algo que tenga sentido y un documento que puedas leer en voz alta. Ese es, en cierto modo, mi punto de vista sobre este tipo de pensamiento.

Eric Kimberling: Ese es un gran punto. Y el equipo que está ejecutando el proyecto también necesita tener esa claridad. Sabes, si piensas en una transformación de supply chain, digamos que eres una organización que busca desplegar una tecnología completa de supply chain. Es fácil perderse en muchas complejidades y detalles.

Si lo tratas como una especie de democracia en la que todos tienen voz y voto, con prioridades, solicitudes y cosas que desean del sistema, el proyecto se descontrolará. Necesitas una gobernanza establecida para decir, “¿Sabes qué? Sí, estamos haciendo la transformación de supply chain, pero las compras no son nuestra máxima prioridad en este momento. En cambio, lo que es, es la gestión de proveedores, es la gestión de vendedores.”

Porque, ¿adivina qué? El gobierno de los Estados Unidos está imponiendo todos estos aranceles ahora, o hay todas estas cuestiones geopolíticas que debemos navegar, así que necesitamos una mejor gestión de proveedores, y ese es nuestro enfoque. Necesitas priorizar y decir, “Estamos haciendo esto porque queremos renovar nuestros procesos de gestión de proveedores,” y gestionarlo en consecuencia.

Si no tienes esa claridad en ese documento de 5 a 20 páginas y no logras que todos estén en sintonía, entonces se convertirá en una lucha libre donde todos simplemente piden lo que creen que quieren.

Joannes Vermorel: Por cierto, para que conste, he visto muchas empresas, y nunca he visto documentos de alta calidad excepto por documentos filtrados de empresas tecnológicas estadounidenses como Amazon, Shopify, Apple—memos filtrados que son súper claros, escritos en cinco páginas, bellamente redactados. Puedes ver que la dirección realmente tiene una comprensión muy aguda de dónde están, a dónde quieren ir, etc., y redactan de forma muy clara y concisa.

Cuando visitas empresas no tecnológicas, es sumamente raro ver eso. Sumamente raro. Tal vez puedo pensar en solo una docena de empresas. Berkshire Hathaway, por ejemplo, sus memos son absolutamente brillantes; es cristalino lo que están haciendo, por qué, etc. Pero típicamente, en empresas que mencionábamos, como Lidl y demás, estoy 100% seguro de que nadie tenía un memo sencillo de qué es lo que realmente estamos tratando de lograr aquí. ¿Por qué estamos convencidos de que esta cosa tiene alguna posibilidad razonable de tener éxito?

La mayoría de esos grandes proyectos que estoy presenciando—Lokad a veces forma parte de ellos—ya sabes, actualizan su ERP, actualizan su supply chain analytics con nosotros. Es simplemente tan raro; por eso lo menciono. Casi nunca veo algún grado de claridad cuando se trata de transformación digital. Es solo capa tras capa de tecnocracias.

Nuevamente, mencionaste la subcontratación—también partes que están completamente fuera de la empresa. Así que esos decs, miles de páginas, la mitad de ellas serían proporcionadas por proveedores externos.

Eric Kimberling: Me pregunto si es realmente interesante lo que dices sobre las empresas tecnológicas. No estaba al tanto de eso, o no había hecho esa conexión antes. Ya sabes, tal vez las empresas tecnológicas sean más capaces y maduras en su capacidad para proporcionar esa claridad.

Pero me pregunto, a veces me pregunto si, ya sabes, los ejecutivos de hoy en día… piensas en los ejecutivos que han crecido en el ámbito tecnológico desde, quizás, los ‘90, bueno, tal vez tengan mi edad o un poco más. Recuerdo que salió Windows 98, y fue un gran acontecimiento cuando se lanzó Windows 98.

Fue una especie de disrupción para muchas empresas porque tuvieron que pasar por estas grandes actualizaciones de Windows. Pero al final del día, fue solo una actualización de Windows; no fue una transformación. Fue, “Necesitamos nuevos sistemas operativos para nuestros PCs, nuestras computadoras de escritorio y portátiles.”

Me pregunto si los ejecutivos que crecieron en el ámbito de IT durante esa época todavía piensan en los proyectos tecnológicos como una actualización de Windows 98, y no reconocen que esto no es una actualización de Windows 98. Esto es una revisión masiva no solo de tus sistemas back-office y bases de datos, sino de tus procesos, la forma en que estás organizado, y todo eso.

Esa es simplemente una hipótesis. No sé si es cierto o no, pero estoy intentando llegar a la raíz del problema de lo que estamos hablando aquí para entender por qué es así.

Joannes Vermorel: Mi opinión es que cuando miro los planes de transformación digital para la mayoría de las empresas no tecnológicas, usualmente, como tecnólogo yo mismo—Lokad es una empresa de software que hace básicamente decision-making robotizado para supply chain—lo que veo es que dichas transformaciones digitales me parecen extremadamente tenues.

Cuando pienso en la transformación digital para mi propia empresa, porque esas tecnologías, como mencionaste, están evolucionando y muchas cosas están cambiando para Lokad, veo un futuro dentro de 10 años en el que quizás más de la mitad de los empleos que tenemos desaparezcan en términos de tareas. La gente seguirá estando allí, sin problema, pero realizará cosas diferentes.

Cuando miro las empresas clásicas no tecnológicas—piensa en una empresa de aviation, una empresa manufacturera, una empresa de retail, una empresa de moda—ya sabes, empresas para quienes la tecnología es solo algo adicional, cuando observo su transformación digital, es muy, muy tenue.

Casi no se elimina ningún trabajo, ni se suprime ninguna tarea de forma radical. Cuando piensas en lo que herramientas como, por ejemplo, ChatGPT pueden hacer, ves que hay clases enteras de tareas que obviamente se pueden automatizar.

De todos modos, mi opinión es que las transformaciones digitales frecuentemente carecen de ambición; son extremadamente tenues. Lo único que no es tenue es el presupuesto que tienen para hacer la actualización.

Conor Doherty: Simplemente interviene y expánde sobre eso porque creo que, en el fondo, es como abrir ciclos. Si regresas al ciclo de apertura, al pensamiento fundamental en términos de mentalidad y de cómo enmarcamos el problema para cerrar el círculo, el problema que estamos intentando resolver. Joannes, iré contigo primero y luego con Eric para un comentario.

Joannes, en realidad lancé este punto de fondo porque algo que Eric dijo antes acerca de capex vs. opex me recordó una conferencia que ofreciste sobre la entrega orientada a productos para supply chain en la que argumentaste que el supply chain no es un supply chain opex. Debería recategorizárselo como capex tratado como un activo, y se me ocurrió que el simple encuadre de ese problema, es decir, no tratarlo como un supply chain y todos sus costos asociados como, bueno, simplemente galletas o bolígrafos —son solo cosas que necesito para poder pasar el día—, tratarlo más como un activo que pueda escalar y apreciarse en valor podría ser una forma más útil de iniciar la discusión, ya sea contratando personas o buscando software. ¿Podrías quizá ampliar un poco esa distinción?

Joannes Vermorel: Sí, o sea, es mi opinión personal. Cuando miro los trabajos de oficina, a menos que haya algo realmente especial en ellos, pienso que es simplemente algo por lo que la empresa necesita pagar para obtener cierto rendimiento en términos de transformación de información. Un trabajador de oficina básicamente toma información y produce información que puede adoptar muchas formas. Pero mucha gente, especialmente en el back-office, es lo que hacen en las grandes empresas. En supply chain, por ejemplo, hay personas que obtendrán los niveles de stock para su ERP y además muchos indicadores de las ventas recientes y demás, ¿y qué decidirán? Decidirán para cada SKU, unidad de mantenimiento de inventario: “¿Necesito reordenar, sí o no?” Tengo mil SKUs para gestionar. La organización se divide de modo que un supply y demand planner tiene, digamos, 1,000 SKUs. Tenemos 80,000 SKUs en total, así que son 80 supply and demand planners, y cada uno de ellos diariamente revisa 1,000 SKUs y emite la orden de replenishment para el día. Muchas empresas están organizadas exactamente así.

Entonces, mi opinión es que cuando piensas en tu supply chain practice de esa manera, las personas que tienes son puro opex. Necesitas pagar esos salarios cada día para que tu empresa no deje de operar. Si dejas de pagar a esa gente, no lo harán, la empresa se detiene, el flujo de mercancías se detiene. Si consideras que la manera en la que Lokad lo aborda es decir: “No, deberíamos considerar el supply chain practice como algo que es capex. Tenemos gente que está diseñando software, de una forma u otra. Hay muchas maneras; low code, no necesariamente tienes que programar, pero desarrollas software que genera automáticamente esas decisiones de reabastecimiento.”

Y luego, si tienes que pagarle a una persona más, es para mejorar el sistema. En este caso, tu inversión es capex. Tienes esta pieza de software que se ejecuta automáticamente, y tienes el opex, pero es solo para el software, por lo que el gasto es muy bajo. Y cuando gastas dinero en personas, es para mejorar el sistema, y por lo tanto es muy capitalista. Es acumulativo; es como debe ser un activo. Sí, se convierte en un activo. Así que, tu inversión en personas se transforma en un activo; el resultado de esas personas es un activo tangible para tu empresa, que resulta ser este sistema de toma de decisiones.

Lo que veo en términos de esas transformaciones digitales modernas es que parecen ser extremadamente moderadas en el sentido de que existen toneladas de trabajos que son puramente trabajos administrativos (opex) de cuello blanco que deberían convertirse en capex. Cuando las personas trabajan una hora, entregan algo que suma valor, algo que construye un activo de algún tipo, probablemente software, pero puede ser otras cosas que tienen valor para la empresa, independientemente del trabajo continuo de las personas. Puede sonar un poco extraño, pero es como si esas personas diseñaran la máquina, y luego se pudiera mantener la máquina funcionando indefinidamente. Estoy simplificando, obviamente; esas máquinas necesitan mantenimiento y demás, pero la mayoría de las transformaciones digitales que veo son extremadamente moderadas porque lo único que observan son esas personas que se usaban como opex, es decir, como puro consumible. Necesito reutilizar el tiempo de esas personas una y otra vez.

Estoy hablando de tareas puramente informativas, no de voltear hamburguesas en un restaurante. Para eso, se necesitan manos. Aún no tenemos robots capaces de voltear hamburguesas. Pero me refiero a todo aquello que se parece a un trabajo de oficina de cuello blanco. Para mí, la mayoría de las transformaciones digitales apenas abordan el hecho de que esas tareas, en su gran mayoría, deberían estar completamente robotizadas nuevamente, en el back office, de modo que ni siquiera estemos frente a los clientes. Es un trabajo interno y ajetreado, y sin embargo, en muchas grandes empresas, eso puede representar fácilmente dos tercios de la fuerza laboral de cuello blanco en el back office interno. Muy frecuentemente, veo que esas transformaciones digitales ni siquiera rascan la superficie cuando se trata de abordar esta enorme cantidad de opex que debería transformarse en capex, pero esa es una opinión muy personal.

Eric Kimberling: Estás tocando un punto realmente interesante y, creo, un desafío mayor en la industria tecnológica, en el espacio de tecnología empresarial en general. Has hablado mucho sobre capex y opex y sobre tratar la TI como un activo, pero si observas hacia dónde se encaminan los proveedores de tecnología, se están moviendo hacia un modelo en el que no es un activo para sus clientes; es el activo del proveedor. Y siempre ha sido así, obviamente; es su producto, es su IP. Pero lo que está sucediendo es que estamos pasando de lo local, donde inviertes, realizas esa inversión de capital, haces a medida el software para que se adapte a tus procesos y ese tipo de cosas, y eso se convierte en un activo que deprecias, a una situación diferente en la que vamos a trasladar todo a la cloud. Todos nuestros datos están en la cloud. Ahora se está pasando de capex a opex, y no es solo una decisión contable sobre si es capex u opex.

Es un cambio de mentalidad porque lo que está sucediendo ahora es, por ejemplo, con la IA. Si observamos la IA, lo que pasa es que estos grandes proveedores de tecnología están diciendo: “Oye, tenemos esta tecnología de IA que puede aportar un valor magnífico a tu organización.” Y eso puede ser cierto, pero lo que ocurre en el proceso es que estamos tomando nuestros datos, nuestra propiedad intelectual dentro de la empresa, y los estamos usando para entrenar estos modelos de IA que luego se utilizan en otros competidores y otras empresas. Ahora, el centro del poder se está trasladando de los clientes a los proveedores, porque ahora los proveedores no poseen los datos, sino que poseen la IA y la tecnología que utiliza tus datos para entrenarla y convertirla en una mejor herramienta de IA para vender a otras compañías.

Así que eso es importante. Es algo realmente fundamental en lo que pensar, plantearse una pregunta mayor acerca de qué es la TI para nosotros. ¿Es una commodity de la que simplemente queremos despegarla del balance, queremos sacarla de nuestras operaciones porque no queremos lidiar con ella? Tal vez. Quiero decir, eso podría estar bien para algunas organizaciones. Pero mencionaste Amazon y Spotify. Te garantizo que Amazon y Spotify no ven la TI simplemente como una commodity que alguien más podría gestionar. Es una ventaja competitiva significativa, y no todos tenemos que aspirar a ser Amazon o Spotify, pero sí podemos aspirar a decir: “Por ejemplo, si nuestra fortaleza competitiva es que tenemos una supply chain realmente eficiente, podemos entregar productos a los clientes más rápido que nadie, y podemos customizar nuestros productos rápidamente para hacer llegar los productos a nuestros clientes con mayor celeridad. Bien, esa es tu ventaja competitiva. Ahora construyamos tecnología que sea única para ti, de modo que haga esa ventaja competitiva realmente difícil de replicar. Si simplemente opto por una solución en la cloud que cualquier otro puede comprar, entonces habré perdido mi ventaja.”

Así que, todo este movimiento hacia la estandarización en la cloud de procesos, utilizando datos para entrenar modelos de IA en beneficio de otros, está cambiando. Creo que es una tendencia muy peligrosa que causará muchos arrepentimientos en las organizaciones durante años. Por ello, considero importante detenerse y reflexionar. Si queremos que la TI sea un activo estratégico que nos diferencie, tratemos el proyecto como tal. Entonces, probablemente eso signifique que no optemos por una tecnología estándar ya hecha y lista para usar en la cloud. Tal vez sí optemos por una solución más hecha a la medida, a pesar de que es una palabra de connotación negativa y se supone que no se debe hablar de personalización, ni de desarrollo custom. Esa podría ser la respuesta correcta para ti si ves la TI como una ventaja estratégica.

Joannes Vermorel: Ventaja, sí, y además señalaría de nuevo que muchos proveedores tienen incentivos absolutamente terribles. Una vez más, la gran mayoría de los proveedores de software empresarial cobran por asiento. Así que, cuando se cobra por asiento, definitivamente no se busca una mejora en la productividad. Si puedes hacer que tu software sea menos eficiente o menos productivo, entonces tendrás más asientos.

Verás, es—quiero decir, obviamente, los proveedores de software empresarial no son, ya sabes, malvados. La mayoría de los empleados son simplemente buenas personas, como el 90% de la población. No tratan de empeorar su producto solo para obtener más asientos, pero aun así, el poder de los incentivos es extremadamente importante.

Eso significa que, por ejemplo, si existe un contexto para el proveedor de software que requiere una gran cantidad de personas operando el software, esas situaciones estarán presentes… Cuando el CEO de la compañía de software revisa sus propias ventas, dicen: “Oh, mira, allí hay mucha tracción.” Sí, sí, porque aquí, en esta área, se necesita que muchísimas personas interactúen con el software, lo que impulsa los ingresos.

Y de repente, se vuelve muy complicado. ¿Realmente quieres desafiarte como proveedor de software si cobras por asiento en algo en lo que tu próxima actualización tal vez elimine el 90% de tus asientos? Es… es una pregunta muy, muy difícil. Es una pregunta sumamente compleja. Por cierto, históricamente eso ya le pasó a IBM. IBM cobraba por MIPS, millones de instrucciones por segundo, que era lo que hacían en los 80 y 90. ¿Y adivina qué? Cuando IBM cobraba por MIPS, su software se volvía cada vez más lento en cada generación, obviamente.

Eric Kimberling: Sí, quiero decir, estás planteando otro tema sobre el cual podríamos dedicar un episodio entero, y ese es el de las expectativas desalineadas o los incentivos desalineados. Sabes, si tu proveedor de software y tu integrador de sistemas, y, ya sabes, hay tres partes principales, y si las tres tienen incentivos muy distintos y en conflicto, entonces es difícil de superar.

Conor Doherty: Perdona la interrupción, pero soy consciente del tiempo de Eric. Has sido muy generoso al quedarte con nosotros, así que yo—al menos podemos volver a este tema y hablar sobre la ética de las acciones de cada uno. Pero por hoy, haré la transición hacia un pensamiento final. Empezaré contigo, Joannes, con una nota positiva de nuevo. ¿Qué consejo le darías a las organizaciones a pesar de todo lo que hemos dicho o considerando todo lo que hemos conversado? ¿Qué consejo le darías a las organizaciones que están a punto de iniciar su transformación digital?

Joannes Vermorel: Como un entusiasta del software durante cuatro décadas—fue un entusiasta incluso, ya sabes, hace tiempo con el software, aunque en su mayoría eran videojuegos cuando era muy joven—como un entusiasta del software de por vida, diría que no creo que haya existido un mejor momento en el que las tecnologías de software prometieran tanto. Es simplemente asombroso para mí—la revolución del deep learning, su descendiente con LLMs y demás. Es casi mágico, ya sabes, la idea de que puedes tener algo que procese lenguaje natural para hacer muchísimas cosas.

Es absolutamente increíble, y esas tecnologías son fácilmente accesibles. No son necesariamente baratas, pero son fácilmente accesibles. Así que diría que nunca ha habido un período en el que se pudiera esperar más de una transformación digital. Creo que ahora mismo, si piensas en esa transformación digital, tiene la promesa de convertir realmente a tu empresa en una bestia completamente diferente que haga mucho más por tus clientes de tantas maneras. Puede ser un mejor servicio para tus clientes, una operación más inteligente. Lo que se te ocurra; tiene un potencial absolutamente masivo.

Así que diría, sueña en grande y luego gasta cuidadosamente e incrementalmente en cosas que no sean como mega proyectos debido al riesgo—ese sería mi mensaje para la transformación digital. Necesitas ponerte en una posición de fallar rápido, porque, como proveedor de software, puedo decirte que si le preguntas a un cliente, “¿Puedes darme una estimación realmente mala de lo que sucederá durante los próximos seis meses?” Seis meses, tal vez pueda hacerlo. Sí, un año empieza a ser complicado; dos años son complicados, muy complicados, porque puedo tener gente rotando. Podría ser tan disruptivo como un proyecto de dos años de duración para procesar, es muy difícil.

Cinco años—oh, dios, esto es como si estuviéramos tratando de diseñar la Estrella de la Muerte. Así que mi opinión es que, sí, la transformación digital tiene un potencial enorme. Es excelente, no es tan costosa, así que deberías intentarlo en lugar de pensar que necesitamos asegurarnos de que funcione. Yo diría que hagas lo contrario: haz cosas que sean pequeñas y ejecútalas rápido y falla rápido, de modo que, si falla, puedas reconocer muy bien que es un costo hundido y seguir adelante en lugar de duplicar esfuerzos una y otra vez, que es la receta exacta para los proveedores de software empresarial que terminan haciendo que sus clientes gasten 10 veces más de lo que se gastó originalmente.

Necesitas ser capaz de decir: “No, nos detenemos. Lo intentamos, lo vimos, hemos terminado. Vamos a intentar algo distinto porque el mundo es vasto. Tenemos tanto potencial; no es absolutamente necesario ceñirse al plan original. Está bien fallar en una iniciativa después de tres meses. Simplemente no está bien fallar después de tres años.”

Eric Kimberling: Después de que ya hayas gastado miles de millones o cientos de millones de dólares.

Joannes Vermorel: Sí, sí.

Conor Doherty: Bueno, Eric, es costumbre aquí darle la última palabra a los invitados, así que de nuevo, misma pregunta: ¿algún consejo que compartir para las personas o empresas que están a punto de comenzar su viaje?

Eric Kimberling: Bueno, es decir, ese fue un gran consejo que acabas de dar. Y tal vez añadiría a eso que, ya sabes, invierte en—invierte en la gestión del cambio. Asegúrate de invertir tu tiempo en la gestión del cambio para que sea menos probable que siquiera necesites fallar rápido. Pero estoy de acuerdo, deseas fallar rápido, y por eso creo que comenzar en pequeño, comenzar despacio, y luego acelerar es mucho más efectivo que empezar demasiado rápido y demasiado grande y luego tener que desacelerar. Eso simplemente crea muchos problemas de moral, mucha incertidumbre y dudas en la organización.

Así que, sí, falla rápido, pero también invierte en el cambio organizacional. Y lo otro que diría es que te tomes tu tiempo al principio, porque esos primeros meses de un proyecto, antes de que comiences a implementar tecnología, es cuando se establece la trayectoria. Es decir, estás definiendo la visión, los parámetros, la dirección del proyecto. Así que asegúrate de hacer bien esa parte. Si no lo haces, si tienes dudas sobre si tienes esa claridad, entonces tómate tu tiempo para hacerlo bien.

Porque cuanto más tiempo dediques al principio a hacer bien esa parte, más rápido avanzará en general. De hecho, vas a implementar mucho más rápido y ahorrar mucho tiempo y dinero si simplemente desaceleras al principio. Siempre puedes acelerar más tarde, pero comienza despacio. Ese sería mi último consejo de cierre.

Conor Doherty: No tengo más preguntas. Muchas gracias por tu tiempo, Eric, lo aprecio mucho.

Eric Kimberling: Gran conversación, muy divertida también, la disfruté.

Conor Doherty: Así que, Joannes, no tengo nada más que decir excepto muchas gracias por tu tiempo, Eric, de nuevo. Muchas gracias por el tuyo, y gracias a todos por ver. Nos vemos la próxima vez.