00:00:07 Importancia de los sistemas ERP.
00:02:42 ERP: Explicación del nombre inadecuado.
00:03:54 Implementación inicial del sistema ERP.
00:05:07 Capacidades fundamentales de los primeros sistemas ERP.
00:07:34 Sistemas ERP: entidades, interfaces, lógica.
00:09:14 El rol de ERP en la automatización empresarial.
00:09:54 Evolución de los ERPs y estrategias.
00:11:32 Lenguajes específicos de dominio en los ERPs.
00:12:07 Estructura modular de los sistemas ERP.
00:14:22 El rol de los integradores en los ERPs.
00:16:00 Integradores promoviendo soluciones ERP hechas a la medida.
00:17:01 Relevancia de las limitaciones tradicionales de los ERP.
00:19:01 Desafiando la necesidad de un sistema ERP único.
00:20:01 Dificultades en las actualizaciones de los ERP.
00:21:35 El rol del operador ERP y complicaciones.
00:22:53 Riesgos/beneficios de proveedores ERP especializados.
00:25:00 Sistemas ERP: complejidad y desafíos.
00:26:52 Pequeñas empresas y aplicaciones SaaS.
00:28:42 Productos ERP complejos para empresas medianas.
00:30:16 Grandes empresas evitando ERPs monolíticos.
00:31:46 Estrategias de las principales compañías.
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 Enterprise Resource Planning (ERP). Remontándose a su origen 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 fundamentales para el desarrollo de los ERP. Sugiere que “Enterprise Resource Management” es un término más preciso para estos sistemas, que han pasado de ser soluciones a medida para empresas a representaciones preempaquetadas de modelos de negocio. Las funcionalidades modernas de los ERP, tales como las interfaces CRUD y la lógica de flujo de trabajo, han automatizado tareas rutinarias, mejorando la productividad. Vermorel explora las estrategias de proveedores ERP exitosos, como SAP, para gestionar la complejidad del sistema, y también aborda la selección e implementación de ERP para empresas de diversos tamaños.
Resumen Extendido
En la entrevista, el presentador Kieran Chandler conversa con Joannes Vermorel, el fundador de Lokad, para discutir la evolución y funcionalidad de los sistemas Enterprise Resource Planning (ERP).
Vermorel describe los orígenes de los sistemas ERP, señalando que surgieron en la década de 1970, a pesar de que el término “ERP” se acuñó únicamente 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 de que las bases de datos relacionales fueran posibles. Estas bases de datos, aunque rudimentarias en sus primeras etapas, ofrecían una forma versátil de organizar datos. El formato relacional, compuesto por tablas y columnas, era adecuado para modelar diversas actividades empresariales, incluidas transacciones, pagos y las 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. Aunque estos lectores aparecieron en la década de 1950, no fue hasta el avance del hardware informático en los años 70 que pudieron almacenar y procesar grandes cantidades de datos. La combinación de estas dos tecnologías dio lugar a los sistemas ERP que conocemos hoy.
Vermorel también aborda el nombre inadecuado 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, lo que hace que “Enterprise Resource Management” sea un nombre más acertado. Ilustra esto describiendo cómo, en las etapas iniciales, muchas empresas comenzaron a desarrollar sus propios sistemas de software para gestionar recursos utilizando las 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, stocks y empleados—algunas compañías comenzaron a ofrecer versiones preempaquetadas de estas representaciones de modelos de negocio. Vermorel indica que este fue el origen de lo que hoy conocemos como sistemas ERP, aunque sugiere que deberíamos considerarlos como sistemas de Enterprise Resource Management, dada su funcionalidad real.
Las interfaces de usuario, típicamente categorizadas como interfaces CRUD (Create, Read, Update, Delete), operan sobre estas entidades. Permiten realizar tareas básicas de ingreso de datos, como agregar un nuevo producto (create), ver los atributos de un producto existente (read), modificar un producto existente (update) y eliminar un producto (delete). Este patrón CRUD se aplica a cada entidad dentro del sistema ERP.
La lógica de 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 la recepción de una factura del proveedor, seguida por el envío de bienes por parte del proveedor. El sistema ERP rastrea estos pasos y, si no se reciben los bienes, alerta al usuario. Si las cantidades recibidas no coinciden con las cantidades ordenadas, el sistema ERP sugiere los pasos a seguir, como contactar al proveedor para que envíe 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 ERPs, Vermorel enfatiza el rol 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 deben implementar un flujo interminable de entidades, interfaces de usuario y lógica. Se refiere a una estrategia “trifásica” que los proveedores ERP exitosos 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 ERP exitoso, que inventó su propio lenguaje de programación específico de 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 soportar 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 comercial, y los clientes son cobrados 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 ERP. Explica que estos proveedores están incentivados a 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 cambia al tema de la elección entre diferentes enfoques de ERP. Vermorel sugiere que las empresas deberían preguntarse si las limitaciones incorporadas en los ERPs desde 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 conducir a una mayor complejidad y a una multitud de casos extremos. En cambio, sugiere que las empresas reconsideren la suposición de que un solo sistema debe hacer todo, advirtiendo además contra tener demasiados sistemas distintos.
Al discutir la implementación de nuevos sistemas ERP, Vermorel aborda los riesgos y costos significativos asociados con la transición a un nuevo sistema o con la actualización de uno existente. Utiliza el ejemplo de una compañía 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 parte determinada por los operadores del sistema—a menudo cambia de manera sutil pero significativa entre versiones, lo que conduce a numerosos casos extremos y desafíos.
Vermorel cree que los proveedores más pequeños conllevan cierto riesgo, pero es mejor elegir un producto que tenga un núcleo reducido, que refleje la complejidad y el tamaño actual de la compañía. 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 compañías más pequeñas, con menos de 100 empleados, deberían optar por aplicaciones de Software-as-a-Service (SaaS) estrechas, simples y rentables. Recomienda utilizar dos o tres aplicaciones separadas que cubran necesidades específicas en lugar de depender de un ERP integral. Para las empresas medianas, con alrededor de 500 empleados, Vermorel sugiere considerar un producto ERP mediano más complejo que pueda gestionar una gama más amplia de funciones empresariales típicas. Sin embargo, para las grandes compañías con miles de empleados, Vermorel aconseja evitar un enfoque monolítico de ERP y, en cambio, propone una estrategia de divide y vencerás. Sugiere desglosar el panorama en áreas funcionales y construir o comprar soluciones hechas a la medida para cada área, en lugar de intentar implementar un único 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 disponibles. Así que, Joannes, quizás podríamos comenzar mirando el origen de los sistemas ERP. ¿Cómo surgieron originalmente?
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 90, pero a lo que típicamente nos referimos como sistemas ERP en realidad comenzó en los años setenta. Hubo dos innovaciones críticas. Una fue la de los sistemas de bases de datos. El hardware informático avanzó hasta el punto en que se hizo posible una base de datos relacional. Esa fue la primera innovación. La segunda innovación fue la de los lectores de códigos de barras. Cuando se combinan estas dos innovaciones, se comprende que las bases de datos relacionales eran increíblemente versátiles y adecuadas para modelar la mayoría de las actividades empresariales, como pagos, clientes, proveedores y transacciones. Quedó claro que este formato era idóneo para ser el receptor de datos. Los códigos de barras se inventaron en los años 50, pero hasta que el hardware informático avanzó lo suficiente como para almacenar y procesar grandes cantidades de datos en los años 70, no tuvo tanto impacto. Sin embargo, ya era vasto en comparación con el procesamiento manual.
Kieran Chandler: Bien, lo mencionaste ahí. El nombre ERP no apareció hasta un poco más tarde, en los años 90. ERP significa enterprise resource planning. ¿Pero de dónde provino el nombre realmente? ¿Por qué decidieron eso?
Joannes Vermorel: En realidad, ERP es un nombre inadecuado. Desafortunadamente, su nombre fue más bien un truco de marketing que surgió en los años 90. Los sistemas ERP básicamente no tienen nada que ver con la planificación. Un nombre mejor habría sido enterprise resource management. Lo que sucedió es que, tan pronto como se disponía tanto de bases de datos como de lectores de códigos de barras, muchas empresas comenzaron a darse cuenta de que querían un sistema informatizado para gestionar todos esos recursos. Empezaron a implementar sus propios sistemas de software sobre la base de la base de datos y los dispositivos de entrada de datos disponibles en ese momento. Algunas otras compañías se percataron de que muchas empresas tienen necesidades similares en cuanto a representación. Por ejemplo, todo negocio necesita representar pagos, stocks para aquellos que manejan materiales físicos y nóminas de empleados. Así que, algunas empresas de software pensaron, “Tengamos versiones preempaquetadas de estos modelos de negocio,” y de ahí nació el concepto de ERP. Hoy en día, es mejor pensar en ello como ERP, no como enterprise resource planning, sino como enterprise resource management.
Kieran Chandler: Entonces, ¿cuáles eran las capacidades centrales de los primeros sistemas ERP?
Joannes Vermorel: Básicamente, un ERP 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 se desea representar productos, se tendría una tabla llamada “products”, pero puede haber múltiples 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: create, read, update y delete. La mayor parte del tiempo, al trabajar con entidades, se utilizan interfaces CRUD. Se ingresan nuevos productos, se consultan los detalles de productos existentes, se modifican productos o se eliminan. Esto se aplica a cada entidad, como transacciones, clientes y más.
El tercer elemento es la lógica de flujo de trabajo. Tomemos como ejemplo la compra. Primero, se emite una orden de compra, luego el proveedor confirma con una factura. Se reciben los bienes, y es necesario registrarlo en el sistema. La lógica de flujo de trabajo asegura que se envíen alertas si algo falta y verifica que las cantidades coincidan con la orden. Con base en esto, se puede decidir devolver los bienes al proveedor o solicitar los artículos restantes. 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 esos primeros programas? Lo que es muy interesante es que, para entender ese cambio, hay que comprender las dinámicas que están impulsando el mercado de ERP. ERP, especialmente los proveedores ERP, juegan un papel significativo en la implementación de estos sistemas, en lugar de que sean las propias empresas las que los implementen. Profundicemos en ello. La mayoría de los proveedores han adoptado una estrategia trifásica, a la que me refiero como Allah. Esta estrategia ha sido exitosa para conquistar el mercado. Hoy en día, la mayoría de los proveedores ERP exitosos aplican estas tres técnicas.
Joannes Vermorel: El principal desafío que 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 manera de ser más competitivos es contar con tecnologías específicas que agilicen la producción de entidades, interfaces de usuario y lógica. Un ejemplo de dicha tecnología es un lenguaje de programación específico de un dominio. Por ejemplo, el proveedor de ERP exitoso, CP, inventó su propio lenguaje de programación específico de dominio llamado ab app, lo que les ayudó a desplegar entidades, interfaces de usuario y lógica más rápidamente que la competencia.
Kieran Chandler: Interesante. Entonces, el segundo camino es ajustar la estructura de la oferta y la tarificación. ¿Podrías elaborar al respecto?
Joannes Vermorel: Por supuesto. Como proveedor, el costo de producir un ERP se ve fuertemente influenciado por la cantidad de esfuerzo requerido para implementar todos los diferentes elementos. Aunque las piezas individualmente pueden ser sencillas, los ERPs se tratan de lidiar con tareas mundanas, como el manejo de recibos. Debido a que los proveedores tienen que producir y dar soporte a 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 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 vendor lock-in. ¿Se alinean los intereses económicos de los proveedores de ERP con este modelo de precios basado en módulos?
Joannes Vermorel: De hecho, en cuanto introduces módulos, se proporciona una manera eficiente de alinear la tarificación con el costo de implementar todas las funcionalidades. Sin embargo, también crea incentivos específicos. Los proveedores se sienten motivados a seguir desarrollando nuevos módulos para vender sobre 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, 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 vasta complejidad de capturar todos los detalles minuciosos de la realidad, encuentran maneras de crecer aún más rápido a través de integradores. Dado que una empresa no puede gestionar todo, los proveedores de ERP colaboran con compañías externas conocidas como integradores para encargarse del último tramo, asegurando una solución completa y exhaustiva.
Kieran Chandler: Entonces, Joannes, mencionaste anteriormente que Lokad está introduciendo una nueva funcionalidad para sus clientes. ¿Podrías contarnos más al respecto?
Joannes Vermorel: Sí, efectivamente. Estamos lanzando una nueva funcionalidad para nuestros clientes. Implica nuevas entidades, una nueva interfaz de usuario y nueva lógica. Estamos creando una red de socios llamada integradores para implementar esta funcionalidad. Desde una perspectiva de modelo de negocio, es interesante para las compañías proveedoras de ERP porque pueden externalizar el costo y el riesgo asociados con esta funcionalidad. Existe una larga cola de funcionalidades que pueden ser delegadas a compañías externas.
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 alinearse completamente con el incentivo del proveedor de software. ¿Es correcto?
Joannes Vermorel: Exactamente. Los integradores tienen el incentivo de proporcionar a los clientes un alto nivel de personalización, ya que les pagan más por módulos hechos a la medida en lugar de módulos integrados. Pueden convencer a los clientes diciendo que su negocio es único y requiere una solución que refleje esa singularidad. Es una dinámica interesante.
Kieran Chandler: Entiendo. Entonces, existen diferentes enfoques que las compañías pueden adoptar en cuanto a los 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, es necesario cuestionar si todas las restricciones que se incorporaron a los ERPs a finales de los años 70 aún son 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 forma 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 necesitamos replantear la suposición de que aún requerimos un sistema único para manejarlo todo?
Joannes Vermorel: Exactamente. Esa suposición ya no es precisa. Tener 100 sistemas distintos que requieren coordinación es un desafío, pero contar con un sistema maestro que sea el todo en uno también es problemático. Cuando deseas realizar cambios en un sistema así, se convierte en un proyecto masivo que afecta a cada función de la empresa.
Kieran Chandler: Entiendo. Parece que la transición a un nuevo sistema puede ser bastante difícil. Algunas compañías han experimentado fracasos costosos al intentar cambiar a nuevos sistemas ERP. ¿Qué tan práctica es esa transición?
Joannes Vermorel: De hecho, la transición a un nuevo sistema ERP puede ser un reto. Hemos visto compañías desperdiciar miles de millones de dólares intentando 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 un despliegue, solo una actualización. Entonces, la pregunta es, ¿es más difícil actualizar un ERP que migrar a uno nuevo?
Joannes Vermorel: Es una pregunta muy interesante. Sorprendentemente, actualizar un ERP suele ser más difícil que migrar a uno nuevo. Puede parecer contradictorio, pero eso es lo que he observado. Cuando migras a un nuevo ERP, no tienes la ilusión de que será una empresa monumental. Sin embargo, cuando lo consideras simplemente como una actualización, puede sonar sencillo, 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 los productos. Pensarías que la semántica de estas entidades en un ERP es definida por el proveedor, pero 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 los flujos 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 la gente realmente hace con el producto. Pueden ofrecer recomendaciones y programas de capacitación, pero, en última instancia, es un reto. Algunas compañías pueden decidir tener una semántica ligeramente diferente para hacer 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 encontrarte con numerosos casos límite sutiles donde la entidad de repente no significa exactamente lo mismo debido a nuevos desarrollos y una miríada de distintos casos límite.
Kieran Chandler: Eso es interesante. Entonces, en un extremo del espectro, tienes estos grandes enfoques monolíticos, y en el otro extremo, tienes compañías ERP más pequeñas y especializadas. ¿Cuánta confianza se puede 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 con tu propia escala. Los productos ERP tienden a volverse más complejos con el tiempo. Así que, si eres una empresa joven, tal vez de apenas cinco años, y has estado creciendo rápidamente, sería erróneo continuar con un ERP que tiene tres o cuatro décadas de antigüedad. Estos productos antiguos pueden ser increíblemente complejos, con cientos o incluso miles de tablas y entidades. Lidiar con tal complejidad puede ser abrumador.
Así que mi consejo es considerar empresas ERP más jóvenes, incluso si vienen con cierto nivel de riesgo. Ten cuidado de no enterrarte en montones de complejidad. En mi experiencia dirigiendo Lokad durante más de una década, no he visto que una empresa enfrente una situación dramática únicamente por su elección de ERP. Sin embargo, desplegar un producto que es mucho más complejo que tu escala puede, en realidad, ser perjudicial e incluso matar tu negocio. Lo he visto suceder con frecuencia, donde las empresas luchan porque adoptaron un software que era demasiado para ellas en términos de complejidad y funcionalidades.
Kieran Chandler: Parece que cuando se trata de elegir software, tener un núcleo fuerte y aplicaciones interconectadas es crucial para una empresa en crecimiento. Joannes, ¿podrías ampliar esta idea?
Joannes Vermorel: Absolutamente. La esencia contraproducente es que es mejor tener algo con un núcleo reducido que refleje tu complejidad y escala actuales, aunque aún le falten algunas funcionalidades. Siempre puedes complementar lo que falta mediante la integración. Por otro lado, tener demasiadas funcionalidades conflictivas puede causar problemas. Las funcionalidades no utilizadas tienden a provocar estragos en tus procesos y a impedir que realices tareas simples. Los productos de software totalmente integrados dificultan la eliminación o modificación de ciertas funcionalidades sin interrumpir todo el sistema.
Kieran Chandler: Entonces, ¿elegir un producto más pequeño no elimina estos problemas por completo?
Joannes Vermorel: No, la magnitud e importancia de estos problemas dependen de la complejidad y de las entidades dentro del software. Sin embargo, la escala de la empresa también juega un papel. Para las empresas más pequeñas, con menos de 100 personas, es aconsejable encontrar una solución estrecha, simple y rentable, como una aplicación SaaS. Podrías necesitar dos o tres de estas aplicaciones para cubrir diferentes áreas, tales como recursos humanos, nómina y inventory management. No es necesario tener un único ERP que abarque todo. Solo asegúrate de que estas aplicaciones cuenten con APIs para extraer datos y así poder integrarlas posteriormente si es necesario.
Kieran Chandler: Eso tiene sentido. ¿Qué hay de las empresas medianas?
Joannes Vermorel: Para las empresas medianas, de alrededor de 500 empleados, se podría considerar un producto ERP más integral. Será más complicado, con numerosas tablas y funcionalidades. En ese punto, tienes que gestionar varios aspectos típicos del negocio, y un ERP puede cubrir 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 aplicaciones pequeñas que comienzan a mostrar sus límites. Luego, si eres más grande, entonces diría que la situación cambia de nuevo. Si eres más grande, más… quiero decir, digamos que eres una empresa de 5,000 empleados… Ya sabes, tu gran compañía. Entonces, típicamente, diría que hay dos cosas que realmente entran en juego. Primero, quieres descomponerlas en partes más pequeñas. Sabes, el monolito simplemente no va a funcionar para ti si eres grande. Si optas por un ERP monolítico, que es lo que hacen la mayoría de las grandes compañías… Diría que la mayoría… quiero decir, va a ser feo. Va a tomar años. Va a ser increíblemente costoso.
Joannes Vermorel: Si observas lo que están haciendo las mejores grandes compañías, típicamente están desplegando, diría, soluciones bastante hechas a la medida. Y tienen muy buenas razones. Si eres una gran empresa, es probable que tengas alguna ventaja competitiva única que no es algo simple. Está arraigada en tu organización, que es grande, que es compleja, y tal vez tuviste adquisiciones. Así que podrías tener, digamos, un panorama errático y genio en primer lugar. Así que, en lugar de decir, “Quiero un ERP que lo gobierne todo,” lo cual funcionaba cuando tenías, digamos, 500 empleados, se vuelve muy difícil cuando tienes, digamos, 5,000 empleados. Así que mi sugerencia es que básicamente necesitas dividir y conquistar. Este tipo de enfoque que sugería cuando eras muy pequeño, ya sabes, y tenías un par de aplicaciones, puedes replantearlo de una manera completamente diferente si eres grande.
Para decir, voy a dividir el panorama en, no sé, quizás hasta una docena de áreas funcionales. Y luego voy a construir o comprar en cada área, dependiendo de si los proveedores que pueda encontrar son buenos o no. Y el mayor desafío, lo que recomendaría a esas grandes empresas, es básicamente romper el dogma de que necesitas tener, como, un ERP para gobernarlos a todos. Creo que eso es, en su mayoría… quiero decir, es mayormente una tontería. Y si miras a jugadores muy, muy competitivos, digamos Amazon, veamos a Alibaba, veamos a Rakuten, veamos a Zalando, ya sabes, esos jugadores tecnológicos que deben lidiar con la physical supply chain. Así que, no… Sabes, no estoy hablando de Microsoft, que es como un jugador puro… casi… No es completamente un jugador digital puro. Ya sabes, tienen Xbox. El Xbox es un producto muy físico. Pero si miras a las compañías que han sido reconocidas como las mejores en gestionar una physical supply chain, como Amazon, todas optaron por un enfoque de divide y conquista en su panorama aplicativo, donde básicamente, optan de manera muy agresiva por un enfoque de construir o comprar. Y básicamente, ninguna de esas compañías tiene realmente un ERP. Tienen listas de productos. Algunos de ellos estarían más cercanos a un ERP. Y la mayoría de esas compañías de hecho también desarrollaron sus propios sistemas, para partes específicas de lo que típicamente se denominaría como un módulo ERP.
Kieran Chandler: Bueno, tendremos que finalizar aquí, pero muchas gracias por tu tiempo esta mañana.
Joannes Vermorel: Gracias, Kieran.
Kieran Chandler: Eso es todo por esta semana. Adiós por ahora.
