00:00:07 Importancia de los sistemas ERP.
00:02:42 Explicación del malentendido de los ERPs.
00:03:54 Implementación inicial del sistema ERP.
00:05:07 Capacidades principales de los primeros sistemas ERP.
00:07:34 Sistemas ERP: entidades, interfaces, lógica.
00:09:14 El papel del ERP en la automatización empresarial.
00:09:54 Evolución de los ERPs y estrategias.
00:11:32 Lenguajes específicos del dominio en los ERPs.
00:12:07 Estructura modular de los sistemas ERP.
00:14:22 Papel de los integradores en los ERPs.
00:16:00 Los integradores promueven soluciones ERP personalizadas.
00:17:01 Relevancia de las limitaciones tradicionales de los ERPs.
00:19:01 Desafío de la necesidad de un sistema ERP singular.
00:20:01 Dificultades en las actualizaciones de los ERPs.
00:21:35 El papel y las complicaciones del operador del ERP.
00:22:53 Riesgos/beneficios de los proveedores de ERP especializados.
00:25:00 Complejidad y desafíos de los sistemas ERP.
00:26:52 Pequeñas empresas y aplicaciones SaaS.
00:28:42 Productos ERP complejos para empresas medianas.
00:30:16 Grandes empresas evitando los ERPs monolíticos.
00:31:46 Estrategias de las principales empresas.
00:33:39 Reflexiones finales.
Resumen
En una entrevista con Kieran Chandler, el fundador de Lokad, Joannes Vermorel, analiza la evolución de los sistemas de Planificación de Recursos Empresariales (ERP). Rastreando su inicio en la década de 1970, Vermorel destaca dos innovaciones clave: el advenimiento de las bases de datos relacionales y los lectores de códigos de barras, como cruciales para el desarrollo de los ERP. Sugiere que “Gestión de Recursos Empresariales” es un término más preciso para estos sistemas, que han pasado de ser soluciones personalizadas de la empresa a representaciones de modelos de negocio preempaquetados. Las funcionalidades modernas de los ERP, como las interfaces CRUD y la lógica de flujo de trabajo, han automatizado tareas rutinarias, mejorando la productividad. Vermorel explora las estrategias de los proveedores de ERP exitosos, como SAP, para gestionar la complejidad del sistema, y también analiza la selección e implementación de ERP para empresas de diferentes tamaños.
Resumen Extendido
En la entrevista, el presentador Kieran Chandler habla con Joannes Vermorel, el fundador de Lokad, para discutir la evolución y funcionalidad de los sistemas de Planificación de Recursos Empresariales (ERP).
Vermorel describe los orígenes de los sistemas ERP, señalando su aparición en la década de 1970, a pesar de que el término “ERP” se acuñó solo en los años 90. Según Vermorel, dos innovaciones clave llevaron al desarrollo de los sistemas ERP. La primera fue el avance del hardware informático hasta el punto en que fueron posibles las bases de datos relacionales. Estas bases de datos, aunque rudimentarias en sus etapas iniciales, ofrecían una forma versátil de organizar los datos. El formato relacional, compuesto por tablas y columnas, era adecuado para modelar diversas actividades empresariales, incluyendo transacciones, pagos e interacciones con clientes y proveedores.
La segunda innovación crítica que menciona Vermorel es la invención de los lectores de códigos de barras. Si bien los lectores de códigos de barras surgieron en la década de 1950, no fue hasta el avance del hardware informático en la década de 1970 que pudieron almacenar y procesar cantidades considerable de datos. La combinación de estas dos tecnologías dio lugar a los sistemas ERP que conocemos hoy en día.
Vermorel también aborda el error de denominación de ERP, afirmando que fue un truco de marketing iniciado en los años 90. Explica que los ERP tienen poco que ver con la planificación, sino que se centran en la gestión, por lo que “Gestión de Recursos Empresariales” sería un nombre más adecuado. Ilustra esto describiendo cómo, en las etapas iniciales, muchas empresas comenzaron a desarrollar sus propios sistemas de software para gestionar recursos utilizando bases de datos y dispositivos de entrada de datos disponibles en ese momento.
Observando las similitudes en lo que las empresas necesitaban representar, como pagos, existencias y empleados, algunas empresas comenzaron a ofrecer versiones preempaquetadas de estas representaciones de modelos empresariales. Vermorel indica que este fue el origen de lo que ahora conocemos como sistemas ERP, aunque sugiere que deberíamos pensar en ellos como sistemas de Gestión de Recursos Empresariales, dada su funcionalidad real.
Las interfaces de usuario, típicamente categorizadas como interfaces CRUD (Crear, Leer, Actualizar, Eliminar), operan en estas entidades. Permiten tareas básicas de entrada de datos, como agregar un nuevo producto (crear), ver los atributos de un producto existente (leer), modificar un producto existente (actualizar) y eliminar un producto (eliminar). Este patrón CRUD se aplica a cada entidad dentro del sistema ERP.
La lógica del flujo de trabajo, el tercer componente, es donde entra en juego la automatización. Vermorel da un ejemplo de un proceso de compra, que comienza con una orden de compra, luego se recibe una factura del proveedor, seguida del envío de los bienes por parte del proveedor. El sistema ERP realiza un seguimiento de estos pasos y, si los bienes no se reciben, alerta al usuario. Si las cantidades recibidas no coinciden con las cantidades pedidas, el sistema ERP sugiere los siguientes pasos, como contactar al proveedor para enviar el resto o devolver los bienes. Esta automatización de tareas rutinarias conduce a una mejora significativa de la productividad.
Pasando a la evolución de los ERP, Vermorel enfatiza el papel de los proveedores en la configuración de estos sistemas. Señala que el principal desafío para los proveedores es gestionar la complejidad, ya que tienen que implementar una corriente interminable de entidades, interfaces de usuario y lógica. Se refiere a una estrategia “triple” que los proveedores exitosos de ERP utilizan para gestionar esta complejidad y mantener la competitividad.
En primer lugar, los proveedores adoptan tecnologías específicas para agilizar la producción de entidades, interfaces de usuario y lógica. Vermorel menciona el ejemplo de SAP, un proveedor exitoso de ERP, que inventó su propio lenguaje de programación específico del dominio, ABAP, para acelerar el proceso de implementación.
En segundo lugar, los proveedores ajustan la estructura de sus ofertas y precios para reflejar el costo y el esfuerzo de producir y respaldar la diversa gama de entidades. Esto a menudo conduce a una estructura de precios basada en módulos, donde las entidades se agrupan en módulos que tienen sentido empresarial y los clientes se cobran en función de los módulos que utilizan.
Los sistemas ERP, que se han convertido en una parte dominante del mundo del software empresarial, están en constante evolución y adaptación para satisfacer las necesidades de las empresas y sus operaciones complejas.
Vermorel comienza discutiendo los incentivos y el modelo de negocio de los proveedores de ERP. Explica que estos proveedores tienen incentivos para desarrollar continuamente nuevos módulos o características para vender a sus clientes. A menudo, los proveedores ven cada implementación exitosa como una oportunidad para crear y vender un módulo adicional al cliente. Esto crea un ciclo perpetuo de ventas y desarrollo.
La conversación luego se centra en la elección entre diferentes enfoques de ERP. Vermorel sugiere que las empresas deben preguntarse si las restricciones incorporadas en los ERP de finales de los años 70 siguen siendo relevantes para su situación actual. Cuestiona la necesidad de un sistema único e integrado, argumentando que este enfoque puede llevar a un aumento de la complejidad y una multitud de casos particulares. En cambio, sugiere que las empresas reconsideren la suposición de que un sistema debe hacerlo todo, al tiempo que advierte contra tener demasiados sistemas distintos.
Al discutir la implementación de nuevos sistemas ERP, Vermorel menciona los riesgos y costos significativos asociados con la transición a un nuevo sistema o la actualización de uno existente. Utiliza el ejemplo de una empresa que desperdició medio billón de euros en una actualización de SAP en 2009, enfatizando que la semántica de las entidades dentro de un sistema ERP, en gran medida determinada por los operadores del sistema, a menudo cambia sutil pero significativamente entre versiones, lo que lleva a numerosos casos particulares y desafíos.
Vermorel cree que los proveedores más pequeños conllevan ciertos riesgos, pero es mejor elegir un producto que tenga un núcleo estrecho, que refleje la complejidad y escala actuales de la empresa. Aconseja evitar características excesivas que puedan interrumpir los procesos y recomienda seleccionar un producto que pueda complementarse con integración si es necesario.
La discusión también aborda la elección adecuada de ERP para diferentes tamaños de empresa. Vermorel sugiere que las empresas más pequeñas con menos de 100 empleados deberían optar por aplicaciones estrechas, simples y rentables de Software como Servicio (SaaS). Recomienda utilizar dos o tres aplicaciones separadas que cubran necesidades específicas en lugar de depender de un ERP completo. Para empresas de tamaño mediano con alrededor de 500 empleados, Vermorel sugiere considerar un producto ERP de tamaño mediano más complejo que pueda manejar una gama más amplia de funciones comerciales típicas. Sin embargo, para empresas más grandes con miles de empleados, Vermorel desaconseja un enfoque de ERP monolítico y en su lugar propone una estrategia de dividir y conquistar. Sugiere descomponer el panorama en áreas funcionales y construir o comprar soluciones adaptadas a cada área, en lugar de intentar implementar un solo sistema ERP.
Transcripción completa
Kieran Chandler: Hoy vamos a descubrir cómo surgió esta clase de software empresarial y cómo las empresas pueden elegir entre la multitud de opciones diferentes. Entonces, Joannes, tal vez podríamos comenzar analizando los orígenes de los sistemas ERP. ¿Cómo surgieron por primera vez?
Joannes Vermorel: Los sistemas ERP se originaron a partir de dos fuerzas impulsoras en los años setenta. Por cierto, el término ERP se acuñó en los años noventa, pero lo que normalmente nos referimos como sistemas ERP realmente comenzó en los años setenta. Hubo dos innovaciones críticas. Una fue los sistemas de bases de datos. El hardware de computadora avanzó hasta un punto en el que se hizo posible una base de datos relacional. Esa fue la primera innovación. La segunda innovación fueron los lectores de códigos de barras. Cuando se combinan estas dos innovaciones, se da cuenta de que las bases de datos relacionales eran increíblemente versátiles y adecuadas para modelar la mayoría de las actividades comerciales, como pagos, clientes, proveedores y transacciones. Quedó claro que este formato era adecuado para ser el receptor de datos. Los códigos de barras se inventaron en los años cincuenta, pero hasta que el hardware de computadora había progresado lo suficiente como para almacenar y procesar cantidades considerable de datos en los años setenta, no tuvo un impacto tan grande. Sin embargo, ya era vasto en comparación con el procesamiento manual.
Kieran Chandler: Vale, entonces lo mencionaste ahí. El nombre ERP no llegó hasta un poco más tarde en los años noventa. ERP significa planificación de recursos empresariales. Pero, ¿de dónde proviene realmente el nombre? ¿Por qué decidieron eso?
Joannes Vermorel: En realidad, ERP es un nombre equivocado. Desafortunadamente, su nombre fue más como un truco de marketing que surgió en los años noventa. Los sistemas ERP básicamente no tienen nada que ver con la planificación. Un nombre mejor habría sido gestión de recursos empresariales. Lo que sucedió es que tan pronto como tuviste tanto bases de datos como lectores de códigos de barras, muchas empresas comenzaron a darse cuenta de que querían un sistema informatizado para gestionar todos esos recursos. Comenzaron a implementar sus propias implementaciones de software sobre la base de la base de datos y los dispositivos de entrada de datos disponibles en ese momento. Otras empresas se dieron cuenta de que muchas empresas tienen necesidades similares en cuanto a representación. Por ejemplo, cada empresa necesita representar pagos, existencias para aquellos que manejan materiales físicos y nómina de empleados. Entonces, algunas empresas de software pensaron: “Tengamos versiones preempaquetadas de estos modelos de negocio”, y ahí es donde nació el concepto de ERP. Hoy en día, es mejor pensar en ello como ERP, no como planificación de recursos empresariales, sino como gestión de recursos empresariales.
Kieran Chandler: Entonces, ¿cuáles eran las capacidades principales de los primeros sistemas ERP?
Joannes Vermorel: Un ERP básicamente consta de tres cosas: entidades, interfaces de usuario y lógica de flujo de trabajo. Las entidades son las abstracciones sobre las tablas. Por ejemplo, si quieres representar productos, tendrías una tabla llamada “productos”, pero puedes tener varias tablas para diferentes atributos o proveedores. Las entidades representan conceptos de alto nivel como productos, clientes o transacciones, en contraposición a los detalles de implementación de bajo nivel de cómo se almacenan en una base de datos.
Las interfaces de usuario están diseñadas específicamente para operaciones CRUD: crear, leer, actualizar y eliminar. La mayor parte del tiempo, al tratar con entidades, simplemente estás trabajando con interfaces CRUD. Ingresas nuevos productos, verificas los detalles de los productos existentes, modificas productos o los eliminas. Esto se aplica a todas las entidades, como transacciones, clientes y más.
El tercer elemento es la lógica de flujo de trabajo. Tomemos el ejemplo de la compra. Primero, emites una orden de compra, luego el proveedor confirma con una factura. Recibes los bienes y necesitas rastrear eso en el sistema. La lógica de flujo de trabajo garantiza que tengas alertas si falta algo y verifica que las cantidades coincidan con el pedido. En función de esto, puedes decidir devolver los bienes al proveedor o solicitar los artículos restantes. El ERP automatiza estas tareas mundanas y mejora la productividad al gestionar las consecuencias de las operaciones comerciales básicas.
Kieran Chandler: En el mundo del software, ¿cuánto han cambiado desde esas primeras piezas de software? Lo que es muy interesante es que para entender ese cambio, tienes que entender las dinámicas que impulsan el mercado de ERP. El ERP, especialmente los proveedores de ERP, juegan un papel importante en la implementación de estos sistemas, en lugar de que las empresas los implementen por sí mismas. Vamos a profundizar en eso. La mayoría de los proveedores han adoptado una estrategia de tres pasos, a la que me refiero como Allah. Esta estrategia ha tenido éxito en ganar el mercado. Hoy en día, la mayoría de los proveedores de ERP exitosos aplican estas tres técnicas.
Joannes Vermorel: El principal desafío al que se enfrentan los proveedores de ERP es la complejidad. Para abordar este desafío, necesitan implementar flujos interminables de entidades y proporcionar interfaces de usuario y flujos de trabajo que tengan sentido. La primera forma de ser más competitivo es tener tecnologías específicas que agilicen la producción de entidades, interfaces de usuario y lógica. Un ejemplo de esta tecnología es un lenguaje de programación específico del dominio. Por ejemplo, el exitoso proveedor de ERP, CP, inventó su propio lenguaje de programación específico del dominio llamado ab app, que les ayudó a implementar entidades, interfaces de usuario y lógica más rápido que la competencia.
Kieran Chandler: Interesante. Entonces, el segundo camino es ajustar la estructura de la oferta y los precios. ¿Puedes ampliar sobre eso?
Joannes Vermorel: Ciertamente. Como proveedor, el costo de producir un ERP está fuertemente influenciado por cuánto esfuerzo se requiere para implementar todos los diferentes elementos. Si bien las piezas individualmente pueden ser sencillas, los ERPs se tratan de lidiar con tareas mundanas, como manejar recibos. Debido a que los proveedores tienen que producir y respaldar numerosas entidades, tiene sentido comenzar a cobrar no por entidad, sino por módulos. Los módulos agrupan entidades relacionadas y se alinean con consideraciones comerciales. Esto plantea un punto interesante con respecto a cómo los sistemas ERP cobran por su software.
Kieran Chandler: Absolutamente. Entonces, hay un precio adicional por agregar módulos. Anteriormente discutimos el bloqueo del proveedor. ¿Los intereses económicos de los proveedores de ERP se alinean con esta estructura de precios basada en módulos?
Joannes Vermorel: De hecho, tan pronto como se introducen módulos, proporciona una forma eficiente de alinear los precios con el costo de implementar todas las características. Sin embargo, también crea incentivos específicos. Los proveedores están motivados para seguir desarrollando nuevos módulos para vender junto con los existentes. Esto puede llevar a un ciclo interminable de vender más módulos a los clientes. Pero antes de profundizar en los detalles de eso, pasemos a la tercera idea.
Kieran Chandler: Muy bien. ¿Cuál es la tercera idea?
Joannes Vermorel: La tercera idea es que los proveedores de ERP exitosos, debido a la gran complejidad de capturar todos los detalles minuciosos de la realidad, encuentran formas de crecer aún más rápido a través de integradores. Dado que una empresa no puede manejar todo, los proveedores de ERP colaboran con empresas externas conocidas como integradores para manejar el último tramo, asegurando una solución completa y exhaustiva.
Kieran Chandler: Entonces, Joannes, mencionaste anteriormente que Lokad está introduciendo una nueva función para sus clientes. ¿Podrías contarnos más al respecto?
Joannes Vermorel: Sí, en efecto. Estamos lanzando una nueva función para nuestros clientes. Involucra nuevas entidades, una nueva interfaz de usuario y una nueva lógica. Estamos creando una red de socios llamados integradores para implementar esta función. Desde una perspectiva de modelo de negocio, es interesante para las empresas proveedoras de ERP porque pueden transferir el costo y el riesgo asociados con esta función. Hay una larga lista de características que se pueden externalizar a empresas de terceros.
Kieran Chandler: Entonces, los proveedores de software transfieren el riesgo a los integradores y, en última instancia, a sus clientes. Los integradores tienen su propio incentivo, que puede no estar completamente alineado con el incentivo del proveedor de software. ¿Es correcto?
Joannes Vermorel: Exactamente. Los integradores tienen un incentivo para proporcionar a los clientes un alto nivel de personalización porque les pagan más por módulos personalizados en lugar de módulos integrados. Pueden convencer a los clientes diciendo que su negocio es único y requiere una solución que refleje su singularidad. Es una dinámica interesante.
Kieran Chandler: Ya veo. Entonces, hay diferentes enfoques que las empresas pueden tomar cuando se trata de sistemas ERP. ¿Cómo determinas cuál es un buen enfoque y cuál es uno malo?
Joannes Vermorel: Hoy en día, al considerar las opciones de ERP, debes cuestionar si todas las restricciones que se incorporaron a los ERP a fines de los años 70 siguen siendo relevantes para tu situación. Depende de varios factores. Por ejemplo, la idea de que necesitas integrar todo en un solo sistema a menudo carece de sentido porque la complejidad no escala de manera lineal. Agregar más entidades al sistema conduce a más casos límite y variaciones en lo que diferentes industrias consideran como un “producto”.
Kieran Chandler: Entonces, ¿estás diciendo que debemos revisar la suposición de que todavía necesitamos un sistema para manejar todo?
Joannes Vermorel: Exactamente. Esa suposición ya no es precisa. Tener 100 sistemas distintos que necesitan coordinación es un desafío, pero tener un sistema maestro como el todo en uno también es problemático. Cuando quieres hacer cambios en un sistema así, se convierte en un proyecto masivo que afecta a todas las funciones de la empresa.
Kieran Chandler: Entiendo. Parece que la transición a un nuevo sistema puede ser bastante difícil. Algunas empresas han experimentado costosos fracasos al intentar cambiar a nuevos sistemas ERP. ¿Qué tan práctico es hacer esa transición?
Joannes Vermorel: De hecho, hacer la transición a un nuevo sistema ERP puede ser un desafío. Hemos visto a empresas desperdiciar miles de millones de dólares en intentos de tales transiciones. No es una tarea fácil en la práctica.
Kieran Chandler: En 2009, desperdiciaron medio billón de euros en una actualización ASAP. Ni siquiera fue una implementación, solo una actualización. Entonces, la pregunta es, ¿es más difícil actualizar un ERP que cambiar a uno nuevo?
Joannes Vermorel: Es una pregunta muy interesante. Sorprendentemente, actualizar un ERP suele ser más difícil que cambiar a uno nuevo. Puede parecer contraintuitivo, pero eso es lo que he observado. Cuando migras a un nuevo ERP, no tienes la ilusión de que será una tarea enorme. Sin embargo, cuando lo consideras solo como una actualización, puede sonar simple, pero en realidad puede ser muy, muy difícil.
El problema es que cuando pasas de una versión a la siguiente, hay un cambio semántico en las entidades. Verás, los ERPs se tratan de representar entidades que reflejan diversas preocupaciones en tu negocio, como productos. Podrías pensar que la semántica de estas entidades en un ERP está definida por el proveedor, pero eso no es del todo cierto. La semántica final de cualquier entidad reside en el ojo del operador, la persona que interactúa con el sistema y realiza la entrada de datos y el flujo de trabajo.
Entonces, la verdadera semántica de una entidad la determina la persona que opera el ERP. Desafortunadamente para los proveedores de ERP, no tienen mucho control sobre lo que las personas realmente hacen con el producto. Pueden proporcionar recomendaciones y programas de capacitación, pero en última instancia, es un desafío. Algunas empresas pueden decidir tener semánticas ligeramente diferentes para que el ERP funcione en su situación específica. No es porque sean rebeldes; es lo que se necesita para que el ERP funcione.
Sin embargo, el problema surge cuando pasas a la siguiente versión. Puedes encontrar numerosos casos límite sutiles donde la entidad de repente no significa exactamente lo mismo debido a nuevos desarrollos y una miríada de casos límite diversos.
Kieran Chandler: Eso es interesante. Entonces, en un extremo del espectro, tienes estos enfoques monolíticos grandes, y en el otro extremo, tienes empresas de ERP más pequeñas y especializadas. ¿Cuánta confianza puedes depositar en estas empresas más pequeñas que podrían no sobrevivir en la próxima década?
Joannes Vermorel: Si eres una empresa pequeña, quieres un sistema donde la complejidad tenga sentido en relación a tu propia escala. Los productos de ERP tienden a volverse más complejos con el tiempo. Entonces, si eres una empresa joven, tal vez con solo cinco años de antigüedad, y has estado creciendo rápidamente, sería incorrecto quedarse con un ERP que tiene tres o cuatro décadas de antigüedad. Estos productos más antiguos pueden ser increíblemente complejos, con cientos o incluso miles de tablas y entidades. Lidiar con esa complejidad puede ser abrumador.
Entonces, mi consejo es considerar empresas de ERP más jóvenes, incluso si conllevan cierto nivel de riesgo. Ten cuidado de enterrarte en montañas de complejidad. En mi experiencia dirigiendo Lokad durante más de una década, no he visto a una empresa enfrentar una situación dramática únicamente por su elección de ERP. Sin embargo, implementar un producto que es mucho más complejo que tu escala puede ser perjudicial e incluso acabar con tu negocio. Lo he visto suceder con frecuencia, donde las empresas luchan porque adoptaron un software que era demasiado para ellos en términos de complejidad y características.
Kieran Chandler: Parece que cuando se trata de elegir software, tener un núcleo sólido y aplicaciones interconectadas es crucial para una empresa en crecimiento. Joannes, ¿podrías expandir esta idea?
Joannes Vermorel: Absolutamente. La esencia contraintuitiva de esto es que es mejor tener algo con un núcleo estrecho que refleje tu complejidad y escala actual, incluso si aún le faltan algunas características. Siempre puedes complementar las partes faltantes a través de la integración. Por otro lado, tener demasiadas características conflictivas puede causar problemas. Las características no utilizadas tienden a causar estragos en tus procesos y te impiden realizar tareas simples. Los productos de software completamente integrados dificultan la eliminación o modificación de ciertas características sin interrumpir todo el sistema.
Kieran Chandler: Entonces, ¿elegir un producto más pequeño no elimina por completo estos problemas?
Joannes Vermorel: No, la magnitud e importancia de estos problemas dependen de la complejidad y entidades dentro del software. Sin embargo, el tamaño de la empresa también juega un papel. Para empresas más pequeñas con menos de 100 personas, es recomendable encontrar una solución estrecha, simple y rentable como una aplicación SaaS. Es posible que necesites dos o tres de estas aplicaciones para cubrir diferentes áreas, como recursos humanos, nómina y gestión de inventario. No es necesario tener un solo ERP que abarque todo. Solo asegúrate de que estas aplicaciones tengan APIs para extraer datos para que puedas integrarlas más tarde si es necesario.
Kieran Chandler: Tiene sentido. ¿Y qué hay de las empresas de tamaño mediano?
Joannes Vermorel: Para empresas de tamaño mediano, alrededor de 500 empleados, se podría considerar un producto ERP más completo. Será más complicado, con numerosas tablas y características. En este punto, tienes varios aspectos típicos del negocio para gestionar, y un ERP puede proporcionar cobertura para esas necesidades. Puede requerir un proyecto de implementación más largo y un buen integrador, pero puede ofrecer la funcionalidad deseada.
Kieran Chandler: Eso es más productivo en comparación con las pequeñas aplicaciones que comienzan a mostrar sus límites. Luego, si eres más grande, diría que la situación cambia nuevamente. Si eres más grande, más… quiero decir, digamos que tienes 5,000 empleados… Sabes, tu empresa grande. Entonces, típicamente, diría que hay dos cosas que realmente entran en juego. Primero, quieres romperlos en partes más pequeñas. Sabes, el monolito simplemente no funcionará para ti si eres grande. Si optas por un ERP monolítico, que la mayoría de las grandes empresas están haciendo… Diría que la mayoría… quiero decir, será feo. Tomará años. Será increíblemente costoso.
Joannes Vermorel: Si observas lo que están haciendo las mejores empresas grandes, generalmente están implementando cosas bastante personalizadas. Y tienen muy buenas razones. Si eres una empresa grande, es probable que tengas alguna ventaja competitiva única que no es algo simple. Está integrada en tu organización, que es grande, que es compleja y tal vez hayas tenido adquisiciones. Por lo tanto, es posible que tengas un paisaje de genios errático en primer lugar. Entonces, en lugar de decir “quiero un ERP que lo gobierne todo”, eso funcionaba cuando tenías, digamos, 500 empleados, se vuelve muy difícil cuando tienes, digamos, 5,000 empleados. Así que mi sugerencia es que necesitas dividir y conquistar básicamente. Este tipo de enfoque que sugería cuando eras muy pequeño, ya sabes, y tenías un par de aplicaciones, puedes revisarlo de una manera completamente diferente si eres grande.
Entonces, digamos, voy a dividir el panorama en, no sé, tal vez hasta una docena de áreas funcionales. Y luego voy a construir o comprar en cada área, dependiendo de si los proveedores que puedo encontrar son buenos o no. Y el mayor desafío, lo que recomendaría a esas empresas más grandes, es básicamente romper el dogma de que necesitas tener, como, un ERP que lo gobierne todo. Creo que eso es en su mayoría… quiero decir, en su mayoría es absurdo. Y si observas a jugadores muy, muy competitivos, digamos Amazon, Alibaba, Rakuten, Zalando, ya sabes, esos jugadores tecnológicos que tienen que lidiar con la cadena de suministro física. Entonces, no estoy… No estoy hablando de Microsoft, que es, como, un jugador digital puro. Ya sabes, tienen Xbox. Xbox es un producto muy físico. Pero si observas a las empresas que han sido reconocidas como las mejores en la gestión de una cadena de suministro física como Amazon, todas optaron por un enfoque de dividir y conquistar en su panorama aplicativo, donde básicamente van de manera muy agresiva por un enfoque de construir o comprar. Y… Y básicamente, ninguna de esas empresas tiene realmente un ERP. Tienen listas de productos. Algunos de ellos estarían más cerca de un ERP. Y la mayoría de esas empresas también escribieron sus propios sistemas, para partes específicas de lo que se referiría típicamente como un módulo de ERP.
Kieran Chandler: Bueno, vamos a tener que terminar aquí, pero muchas gracias por tu tiempo esta mañana.
Joannes Vermorel: Gracias, Kieran.
Kieran Chandler: Eso es todo por esta semana. Hasta luego.
