Por qué los ERPs son lentos y costosos de desplegar — por diseño

Joannes Vermorel

Cada pocas semanas, me encuentro con un ejecutivo que aún está “desplegando el ERP.” El programa comenzó bajo un equipo de liderazgo anterior. El presupuesto se ha convertido en un número que nadie quiere mencionar en voz alta. Y el post‑mortem, ya medio escrito, señala al vendedor, al integrador, a la “resistencia al cambio” o a la singularidad del negocio. Esa historia es tan común que se ha convertido en ruido de fondo.

La incómoda verdad es que la mayoría de los despliegues de ERP son lentos y costosos por razones estructurales. No es porque cada equipo involucrado sea incompetente. Ni siquiera porque los requerimientos fueran poco claros. Son lentos y costosos porque los incentivos económicos y técnicos que han moldeado los ERP a lo largo de décadas los hacen lentos y costosos como categoría.¹

En mi libro Introduction to Supply Chain (Capítulo 5, “Información”, sección “Sistemas de registros”), dedico tiempo a una idea sorprendentemente descuidada: el software que registra transacciones es tanto indispensable como fundamentalmente limitado. Su función es ser un libro mayor confiable—nada más. Cuando las empresas se olvidan de ello, comienzan a pagar precios “estratégicos” por lo que es, en esencia, una máquina clerical transaccional. Ese malentendido es donde comienzan los problemas.

La jungla de entidades y la cinta de correr del proveedor

Comencemos con lo que es un ERP en la práctica. Es un sistema transaccional, construido sobre una base de datos relacional, que rastrea los recursos y operaciones rutinarias de la empresa a través de muchos módulos, muchas pantallas y un extenso catálogo de “entidades” (productos, clientes, facturas, órdenes, y así sucesivamente).¹

Ahora, aquí está la dinámica que silenciosamente asegura que los despliegues de ERP seguirán siendo dolorosos.

Un proveedor de ERP no desarrolla software “para ti.” Ellos desarrollan software para el total de su cartera de clientes, a lo largo de décadas. El producto crece por acumulación. Cada gran cliente viene con un puñado de conceptos “imprescindibles”, excepciones, flujos de trabajo, peculiaridades regulatorias y vocabulario que serán solicitados como características de primera clase. Los proveedores pueden añadir; casi nunca eliminan. No existe un beneficio comercial en eliminar entidades oscuras de las cuales dependa algún cliente heredado. El resultado es un producto que se expande implacablemente, una entidad a la vez, un módulo a la vez.¹

Eso es importante porque la complejidad no escala de manera lineal. Soportar el doble de características cuesta mucho más que el doble del esfuerzo de ingeniería, y la “cohesión semántica” interna del producto se degrada con el tiempo.¹

En el primer despliegue, este crecimiento se disfraza con la dinámica de ventas. Los proveedores de ERP venden por módulos; las empresas cliente adoptan por módulos. Un módulo ahora, otro en seis meses, otro el próximo año. La empresa obtiene la ilusión de un progreso incremental, y el integrador puede distribuir el esfuerzo en fases.¹

Las actualizaciones son donde la ilusión se derrumba.

Incluso si te quedas con el mismo proveedor, las actualizaciones son notoriamente difíciles y a menudo se extienden durante muchos meses, a veces años.¹ La razón técnica no es misteriosa: la migración rara vez es una copia simple uno a uno. El significado de las entidades evoluciona. Una tabla que antes significaba “órdenes de clientes” se reutiliza para representar también devoluciones; la “solución” se convierte en cantidades negativas, banderas adicionales, uniones adicionales, casos especiales y supuestos posteriores que se rompen silenciosamente.¹

Así es como se presenta el verdadero asesino: el problema de mapeo.

La mayor parte del trabajo no consiste en “instalar” software. Consiste en construir una correspondencia entre dos diccionarios incompatibles del negocio: la semántica del antiguo ERP y la semántica del nuevo ERP. Y debido a que ambas semánticas están moldeadas por la historia del proveedor, y no únicamente por tu empresa, el número de conceptos que debes conciliar refleja la cartera acumulada de clientes del proveedor. Tu empresa paga por navegar en un laberinto construido por los demás.

La personalización agrava el problema. Cuando el cliente y su integrador añaden entidades a medida, pantallas a medida, flujos de trabajo a medida—cosas que no eran viables para que el proveedor adoptara—esas piezas personalizadas se convierten en un dialecto local. Más tarde, cuando el proveedor refactorea (incluso ligeramente), la empresa se ve forzada a un segundo mapeo, mucho más feo: del antiguo dialecto personalizado al nuevo dialecto estándar, además de cualquier nueva personalización requerida para llenar los vacíos.

Esto no es un accidente. Es lo que ocurre cuando el éxito comercial de un producto depende de expandir continuamente su alcance mientras se mantiene la compatibilidad retroactiva para una diversa base de clientes. Es la inevitabilidad en cámara lenta de una jungla de entidades.

Cuando un sistema intenta hacer tres trabajos

El segundo problema estructural es aún más generalizado: las empresas rutinariamente piden al ERP que realice tres trabajos diferentes a la vez.

Quieren que el ERP registre transacciones (el libro mayor), que proporcione análisis y paneles de control (el “espejo”), y que genere decisiones (el “cerebro”). Los proveedores lo fomentan complacientemente porque agrupar resulta rentable: una vez que se encuadra al ERP como “la plataforma que dirige la empresa,” cada módulo adicional se convierte en un “imprescindible.”²

Sin embargo, desde una perspectiva de diseño de software, estos trabajos tiran en direcciones opuestas.

El procesamiento de transacciones se trata de actualizaciones rápidas, confiables y de una estricta consistencia. El procesamiento analítico consiste en escanear grandes conjuntos de datos, agregarlos, segmentarlos y explorarlos. Estas son cargas de trabajo diferentes, a menudo implementadas con diferentes modelos de datos y distintos compromisos de rendimiento; la industria ha tenido nombres para esta distinción durante décadas (OLTP vs OLAP).³

Cuando intentas hacer ambas cosas con un solo monolito, creas un sistema que está perpetuamente en guerra consigo mismo. Las operaciones “pesadas”—reportes, análisis, características de pseudo-planificación—compiten con operaciones transaccionales mundanas. Los usuarios lo experimentan como lentitud, tiempos de espera, lotes nocturnos, integraciones frágiles y el eterno estribillo de que “el sistema no puede hacer eso.” Mientras tanto, la empresa paga una prima por el privilegio de incorporar contradicciones en la arquitectura.

No ayuda que “ERP” sea un nombre engañoso. Históricamente, la “P” de planificación suena como una promesa de inteligencia. En realidad, la planificación es, en el mejor de los casos, una preocupación secundaria para los ERP, y la analítica predictiva tiende a estar en desacuerdo con su diseño transaccional básico.¹

Mi artículo de junio de 2024 sobre software empresarial argumentó que el despilfarro crónico de la industria proviene de confundir estas categorías y pagar sumas extravagantes por las cosas equivocadas. El punto básico, sin jerga, es simple: un libro mayor no es un motor de estrategia, y pedirle que lo sea produce complejidad sin entregar el beneficio.²

Si deseas una confirmación vívida de que no soy el único que piensa de esta manera, fíjate en cómo los principales proveedores de computación en la nube explican los sistemas de datos: recomiendan explícitamente usar sistemas transaccionales para almacenar y actualizar registros de forma fiable, y sistemas analíticos para generar reportes y realizar análisis complejos. No pretenden que un modo de base de datos sobresalga en todo; describen roles complementarios.³

Los proveedores de ERP venden el sueño opuesto: un sistema para hacerlo todo. El sueño es lucrativo. La resaca la paga el cliente.

La trampa llamada “personalización” y el trabajo llamado “migración”

La literatura de terceros y la documentación de los proveedores convergen en un punto que los profesionales ya conocen en lo más profundo: la personalización y la migración son donde los proyectos van a morir.

Un artículo de ScienceDirect sobre la personalización de ERP lo describe como una “espada de doble filo”, señalando que, si bien la personalización puede mejorar el encaje, también conlleva mayores costos de implementación, mayor complejidad y gastos para actualizaciones posteriores.⁴ Esa es la versión académica de lo que los integradores discretamente calculan en cada propuesta: cada desviación del camino estándar es un impuesto futuro.

Incluso cuando nos mantenemos dentro de la órbita de los proveedores convencionales, la historia es la misma. La propia guía de Microsoft para implementaciones de Dynamics 365 afirma rotundamente que “La migración de datos es un proceso complejo y que consume mucho tiempo”, y luego procede a enumerar los tipos de trabajo involucrados: analizar fuentes, definir el alcance, mapear y transformar campos, cargar, probar, verificar y validar la calidad de los datos.⁵

Lee esa lista con atención. No es una tecnología exótica. No es “innovación.” Es la industrialización del mapeo y la conciliación.

Precisamente por esto los programas ERP se expanden a asuntos de varios años: el trabajo no consiste en construir un software nuevo; es traducir un negocio vivo a un esquema extenso, en constante cambio y modelado por el proveedor, para luego repetir el ejercicio durante las actualizaciones. Cuanto más el ERP intenta ser el libro mayor, el espejo y el cerebro, más se convierte esa traducción en un proyecto perpetuo en lugar de un ejercicio único.

Una alternativa más sensata: construir a propósito un libro mayor

En este punto, aparece la objeción obvia: “Está bien. Los ERP son desordenados. Pero necesitamos características sofisticadas. Necesitamos planificación. Necesitamos optimización. No podemos simplemente construir esto nosotros mismos.”

Esa objeción contiene el mismo error categórico que la propuesta de los ERP.

Si restringes el alcance al libro mayor —la capa transaccional sencilla que captura la semántica del negocio y respalda los flujos de trabajo rutinarios— el problema se vuelve radicalmente más simple. No es sencillo en el sentido de que no requiera reflexión, sino simple en el sentido de que es mayormente una aplicación CRUD disciplinada.

Y aquí es donde 2026 es verdaderamente diferente de 2015.

Ahora existen agentes de codificación diseñados específicamente para tomar una base de código, un conjunto de tareas y producir cambios funcionales rápidamente. Claude Code de Anthropic es una herramienta de codificación agentiva que vive en el terminal y ayuda a producir código mediante comandos en lenguaje natural. Codex de OpenAI se ha posicionado como un agente de ingeniería de software capaz de manejar tareas como escribir funcionalidades, corregir errores y proponer pull requests. xAI ofrece modelos Grok orientados a la codificación que pueden utilizarse con editores de código mediante flujos de trabajo comunes de agentes.

Estas herramientas no son magia. Un ensayo controlado aleatorizado publicado por METR en julio de 2025 incluso encontró que, en un entorno particular (desarrolladores experimentados trabajando en repositorios open-source familiares), el uso de herramientas de IA hizo que los desarrolladores fueran más lentos en promedio, debido a que el tiempo se trasladó de escribir a revisar y corregir.⁶ Ese resultado es un recordatorio importante: “agentiva” no significa “automática.”

Sin embargo, también aclara dónde es más fuerte la ventaja: cuando el trabajo es repetitivo, bien delimitado y semánticamente restringido—exactamente lo que un libro mayor deliberadamente aburrido debería ser.

He aquí mi recomendación, expresada claramente: para cualquier empresa de tamaño considerable—digamos, con ingresos anuales superiores a 50M €—la postura por defecto debería ser construir la capa de libro mayor internamente en lugar de comprar un ERP monolith y pagar una década de alquiler a su ecosistema.

¿Por qué?

Porque el factor de costo dominante de la “modernización” de ERP es el mapeo de esquemas a través de miles de entidades conformadas por proveedores y años de deriva semántica acumulada. Si comienzas desde cero, puedes construir una capa de registros alineada con tu propia semántica, en lugar de un compromiso diseñado para adaptarse a cada empresa en el portafolio del proveedor. En la práctica, el modelo de datos resultante suele ser uno o dos órdenes de magnitud menor. No porque tu negocio sea trivial, sino porque dejas de pagar por los escombros semánticos dejados por otros clientes.

El despliegue también cambia de forma. En lugar de un corte heroico tras años de especificación, puedes iterar como un equipo de ingeniería sensato. Importas una instantánea fresca de los datos heredados. Permites que los empleados interactúen con el nuevo sistema. Ellos reportan discrepancias entre el software y los flujos de trabajo reales. Ajustas el código. Vuelves a importar. Repites hasta que el libro mayor encaje. Este enfoque es simplemente la versión disciplinada de lo que ya implica la guía de Microsoft: la migración necesita mapeo, testeo, validación y ensayo.⁵

Sí, requiere habilidades de programación. Esa habilidad puede ser interna o externalizada, pero debe ser real. También requiere lo que a menudo llamo simpatía mecánica: suficiente entendimiento por parte del liderazgo para dirigir un proyecto técnico sin quedar hipnotizado por las teatralidades del proveedor. La analogía que he utilizado en otras ocasiones es que los grandes pilotos no son ingenieros mecánicos, pero saben lo suficiente sobre la máquina para sacarle el máximo provecho.⁷

Esta es la parte que muchas empresas tratan de evitar. Prefieren externalizar el pensamiento junto con la implementación. Prefieren comprar la ilusión de seguridad.

Pero externalizar el libro mayor de la empresa a un monolito cuyos incentivos son crecer, agrupar y generar lock-in, no es seguridad. Es la manera más lenta posible de comprar software que eventualmente tendrás que reemplazar de todas formas.

Si deseas planificación y optimización, trátalos como preocupaciones separadas, superpuestas sobre un libro mayor limpio. No obligues al libro mayor a convertirse en el optimizador. No arrastres la optimización en el proyecto de migración. Primero haz que los registros sean precisos, rápidos y aburridos. Luego—y solo entonces—construye sistemas de decisión que puedan mejorarse sin tener que reescribir toda la memoria corporativa cada vez.

Los despliegues de ERP son lentos y costosos porque la categoría de ERP evolucionó bajo incentivos que los hacen lentos y costosos. La salida no es una mejor gestión de proyectos dentro de la misma trampa. La salida es dejar de pedirle a un libro mayor que sea un oráculo, y dejar de pagar el equipaje histórico de un proveedor como si fuera propio.