La estadística se cita tan a menudo que ha perdido capacidad de impacto: el 64% de los proyectos ERP exceden el presupuesto inicial y el 75% exceden el plazo original.[1]
Lo que se cita menos es el análisis del otro lado de la distribución: el 36% que termina dentro de plazo y presupuesto. ¿Qué hacen diferente?
Panorama Consulting, que lleva dos décadas analizando implementaciones ERP en empresa mediana, identifica la indefinición del alcance como el principal factor de desviación. No los problemas técnicos de la plataforma. No los bugs del software. La indefinición de lo que el ERP va a hacer y, sobre todo, de lo que no va a hacer.[1]
Las implementaciones que terminan en plazo y presupuesto tienen algo en común: delimitan con precisión los procesos que el ERP no va a cubrir y tienen un plan para cubrirlos de otra forma.
Este artículo analiza ese lado de la estadística. No el fracaso, sino la anatomía del éxito en implementaciones ERP mid-market: qué decisiones previas marcan la diferencia, por qué el ERP no puede cubrir todo por diseño y qué papel juegan las herramientas complementarias en los proyectos que terminan bien.
Por qué el ERP no puede cubrirlo todo (y nunca fue diseñado para ello)
El ERP es, por definición, un sistema de registro transaccional. Está diseñado para capturar, procesar y almacenar las transacciones financieras y operativas que definen el estado legal y contable de la empresa: facturas, pedidos, albaranes, nóminas, asientos contables.
Eso es lo que hace bien. Lo que no hace bien —porque no fue diseñado para ello— son los procesos operativos no transaccionales que rodean y alimentan esas transacciones.
El 78% de las organizaciones considera que su ERP cubre menos del 70% de sus necesidades operativas reales.[4] El 34% identifica que la brecha se genera principalmente en procesos no transaccionales: la gestión de incidencias de calidad, la coordinación de proyectos internos, las aprobaciones de gastos fuera del flujo estándar, el seguimiento de indicadores operativos que el ERP no captura, la comunicación estructurada con proveedores o la gestión de documentos vinculados a pedidos.
Esto no es una limitación del ERP: es su definición. Un sistema diseñado para ser el registro financiero de la empresa no puede también ser el sistema de gestión de incidencias, el portal de proveedores, el tracker de proyectos y el panel de KPIs operativos. El problema no es el ERP. Es esperar que lo sea todo.
La dirección del mercado es clara: SAP está migrando su base instalada hacia S/4HANA Cloud y BTP, y los fabricantes de iPaaS están invirtiendo en conectores certificados para esa arquitectura. Para las empresas que ya están en S/4HANA Cloud, la integración con herramientas como n8n o Make será progresivamente más accesible.
Para las que todavía operan en ECC o Business One, el camino pasa por uno de los cuatro escenarios descritos anteriormente.
Lo que diferencia al 36% que no se pasa de presupuesto
Panorama Consulting identifica tres factores que distinguen sistemáticamente las implementaciones ERP exitosas de las que se desvían:[1]
1. Definición explícita del alcance negativo
El alcance positivo de un proyecto ERP —qué módulos se van a implementar, qué procesos van a cubrirse— siempre está documentado. Lo que distingue a los proyectos que terminan bien es que también documentan el alcance negativo: qué procesos operativos quedan explícitamente fuera del ERP y cómo van a cubrirse.
Esta decisión elimina la principal fuente de scope creep: los usuarios que, durante la implementación, descubren que el ERP no cubre un proceso que necesitan y solicitan personalizaciones para cubrirlo. La personalización del ERP para procesos no transaccionales es, de forma sistemática, la causa más frecuente de desviación presupuestaria.
Un ERP con muchas personalizaciones es también un ERP más difícil de actualizar, más costoso de mantener y más dependiente del proveedor de implementación.
2. Plan paralelo para los procesos que quedan fuera
El 77% de las empresas medianas no utiliza las funcionalidades de workflow management de su ERP.[9]
Una parte de esa estadística refleja workflows que el ERP tiene pero que los usuarios no adoptan porque la experiencia de uso es pobre. Otra parte refleja procesos que el ERP sencillamente no puede gestionar bien.
Las implementaciones exitosas tienen un plan para estos procesos desde antes del go-live. No un “ya lo resolveremos después”, sino una decisión explícita: este proceso se va a cubrir con una herramienta específica, con este diseño y con este responsable, antes de que el ERP entre en producción.
Esa herramienta puede ser una aplicación no-code construida a medida, una plataforma de gestión de proyectos configurada para el caso de uso concreto o una automatización que conecte el ERP con el sistema donde ese proceso sí puede gestionarse bien.
3. Arquitectura de datos desde el inicio, no como afterthought
El 65% de los usuarios considera difícil acceder a sus propios datos dentro del ERP.[5]
Esto no es solo un problema de UX: es un problema de diseño de datos. Las implementaciones que terminan dentro de presupuesto definen desde el inicio cómo van a extraerse los datos del ERP para reporting, qué datos van a vivir en el ERP y cuáles en sistemas complementarios, y cómo van a sincronizarse ambos.
Una capa de reporting o BI que no se diseña durante la implementación del ERP se añade después como un proyecto adicional, con la complejidad de trabajar sobre una estructura de datos ya fijada que puede no haber sido pensada para facilitar la extracción.
Ese proyecto adicional es un coste no presupuestado que aparece entre los seis y los dieciocho meses post go-live.
El modelo que reduce el riesgo: ERP para lo transaccional, satélites para lo operativo
El modelo que caracteriza las implementaciones ERP mid-market exitosas en los últimos cinco años tiene un nombre que se ha popularizado entre consultoras tecnológicas: herramientas satélite.
El ERP mantiene su rol de sistema de registro central para las transacciones financieras y operativas estándar. Las herramientas satélite cubren los procesos operativos no transaccionales que el ERP no puede gestionar bien sin personalización costosa.
Las plataformas low-code e iPaaS han hecho que este modelo sea accesible para empresa mediana. El tiempo medio de implementación de una herramienta satélite vía plataforma low-code es de 4–6 semanas. El tiempo medio de personalización equivalente en el ERP es de 3–9 meses.[6]
La diferencia de coste es proporcional. Y la herramienta satélite no añade deuda técnica al núcleo del ERP: se puede reemplazar sin afectar al sistema central.
Para 2026, Gartner proyecta que el 75% de las nuevas aplicaciones empresariales se construirá con plataformas low-code o no-code.[7] El patrón ERP core + satélites específicos no es una solución de compromiso: es la arquitectura tecnológica emergente del mid-market, que separa el sistema de registro de los sistemas de trabajo.
El posicionamiento más honesto no es reemplazar el ERP. La empresa mediana ya tiene su sistema financiero y cambiarlo es un proyecto de 12–18 meses que ninguna organización acomete sin razones de peso.
Se trata de cubrir el 20–30% que ese sistema nunca fue diseñado para resolver. La empresa que entiende esta distinción invierte mejor y espera resultados más realistas.
Lo que vale la pena calcular antes de empezar cualquier proyecto ERP
El coste de propiedad de un ERP en mid-market representa entre el 3% y el 5% de la facturación anual.[3] Para una empresa de €30 millones de facturación, eso equivale a entre €900.000 y €1,5 millones anuales en licencias, mantenimiento, soporte y ajustes. Es una inversión significativa para cualquier empresa de ese tamaño.
Antes de comprometer esa inversión, hay tres cálculos que las implementaciones exitosas hacen de forma sistemática y que las fallidas rara vez abordan con rigor:
El inventario de procesos no transaccionales
Qué procesos operativos de la empresa no encajan en el modelo transaccional del ERP, cuánto tiempo consumen actualmente y cómo se van a resolver si no se incluyen en su alcance. Sin este inventario, el scope creep es inevitable.
El coste del reporting post-ERP
El nuevo ERP tendrá mejores datos que el anterior, pero esos datos deben llegar a quienes toman decisiones en un formato usable. El diseño del reporting —quién lo necesita, en qué formato y con qué frecuencia— que no se realiza durante la implementación se convierte en un proyecto adicional entre seis y dieciocho meses después.
El presupuesto de cambio organizativo
Panorama Consulting identifica la falta de gestión del cambio como el segundo factor de fracaso, después de la indefinición del alcance.[1]
Un ERP nuevo cambia los flujos de trabajo de todos los usuarios. La formación, la comunicación interna y el soporte durante los primeros meses post go-live tienen un coste que frecuentemente se subestima o se elimina en revisiones presupuestarias.
La consultora que entra después del ERP, no en lugar de él
El modelo de herramientas satélite tiene una implicación directa para el tipo de consultoría que una empresa mediana necesita. El proveedor del ERP —SAP, Microsoft, Oracle, Sage— se ocupa del sistema central. La consultoría que cubre los procesos que quedan fuera no compite con el ERP: complementa lo que el ERP no hace.
Esta posición es estratégicamente diferente a la de un integrador ERP tradicional. El integrador trabaja dentro del sistema. La consultora de herramientas satélite trabaja en el espacio entre sistemas: el hueco operativo que el ERP no llena, los procesos que los empleados resuelven con hojas de cálculo, los workflows de aprobación que circulan por email y los informes que alguien construye manualmente cada mes porque el ERP no los genera en el formato que necesita dirección.
Forrester calcula un ROI del 248% en tres años para organizaciones que cubren correctamente esos huecos con automatización y herramientas low-code.[11]
Solo el 26% de las empresas medianas españolas tiene actualmente buena salud digital.[8] El gap entre el potencial y la realidad es el espacio donde se produce el mayor valor.
Referencias
1. Panorama Consulting Group. (2024). 2024 ERP Report. Panorama Consulting.https://www.panorama-consulting.com/resource-center/erp-report/ —El 64% de los proyectos ERP exceden el presupuesto inicial. El 75%exceden el plazo original. El tiempo medio de implementación enmid-market es de 14,3 meses. La causa más citada de desviación esla indefinición del alcance (scope creep) durante las fases dediseño.
2. Gartner.(2023). ERP in the Midmarket: Why Implementations Fail and How toSucceed. Gartner Research (ID: G00789124). Gartner estima que entreel 55% y el 75% de los proyectos ERP se consideran fracasos parcialespor los propios usuarios al completarse, medido por el gap entreexpectativas iniciales y resultado final. La causa principalidentificada es la subestimación de los procesos que el ERP no puedecubrir por diseño.
3. IDC.(2024). The Cost of Disconnected Data in the Enterprise. IDCResearch. El coste de propiedad ERP en mid-market (100–999empleados) representa entre el 3% y el 5% de la facturación anual.Para una empresa de €30M de facturación, eso equivale a entre€900.000 y €1,5M anuales incluyendo licencias, mantenimiento,soporte y ajustes.
4. Deloitte.(2023). 2023 Global ERP Survey. Deloitte Insights.https://www.deloitte.com — El 78% de las organizaciones consideraque su ERP actual cubre menos del 70% de sus necesidades operativasreales. El 34% identifica que la brecha se genera principalmente enprocesos operativos no transaccionales que el ERP no estaba diseñadopara gestionar.
5. SaaSworthy/ múltiples fuentes compiladas. (2024). Top 50 ERP Statistics ThatWill Define 2025. https://www.saasworthy.com/blog/top-erp-statistics— El 65% de los usuarios considera difícil acceder a sus propiosdatos dentro del ERP. Solo el 23% tiene acceso a datos en tiemporeal. Solo el 11% cree que su ERP captura toda la información nofinanciera necesaria para monitorizar KPIs operativos.
6. MuleSoft(Salesforce). (2024). 2024 Connectivity Benchmark Report. MuleSoft.https://www.mulesoft.com/connectivity-benchmark — Las plataformaslow-code e iPaaS reducen el tiempo de desarrollo de integracionesentre un 50% y un 90% comparado con métodos tradicionales. El tiempomedio de implementación via iPaaS es de 2–6 semanas frente a 3–9meses via desarrollo a medida.
7. Gartner.(2024). Predicts 2026: Low-Code and No-Code Application Platforms.Gartner Research. Para 2026, el 75% de las nuevas aplicacionesempresariales se construirá con plataformas low-code o no-code. Elmercado europeo de plataformas low-code pasará de $2.920M en 2024 a$17.310M en 2033 (CAGR 22%).
8. ONTSI/ Red.es. (2024). Tecnologías digitales en la empresa 2023.Observatorio Nacional de Tecnología y Sociedad. Solo el 26% de lasempresas medianas españolas tiene buena salud digital. El KitDigital (Real Decreto-ley 36/2020) ofrece subvenciones de hasta€29.000 por empresa para digitalización.
9. ERPNews. (2024). Electronic Workflow Process Gaps Kill an Estimated 20%of ERP Productivity. ERP News. El 77% de las empresas medianas noutiliza las funcionalidades de workflow management de su ERP. Entreel 15% y el 20% del valor potencial del ERP se pierde por procesos deaprobación y coordinación no digitalizados.
10. FSNResearch / Gary Simon. (2023). Why Spreadsheets Are Still Filling theReporting Gap. FSN. http://www.fsn.co.uk — Los equipos financierosdedican más tiempo a recopilar y verificar datos del ERP que aanalizarlos. Solo el 11% de las empresas cree que su ERP captura todala información no financiera necesaria para sus KPIs.
11. ForresterResearch. (2024). The Total Economic Impact™ Of Microsoft PowerAutomate. Forrester Consulting.https://tei.forrester.com/go/microsoft/powerautomatetei/index.html —ROI del 248% en tres años para implementaciones correctas. El período de recuperación de la inversión es inferior a seis meses en las organizaciones analizadas.
Artículos destacados
Explora nuestros últimos artículos y tendencias.
¿No sabes por dónde empezar?
Cuéntanos tu reto y te ayudaremos a identificar la solución más efectiva para tu empresa.Ya sea automatizar un proceso, crear una plataforma o formar a tu equipo, estamos aquí para ayudarte a avanzar sin fricciones.
