Gartner proyecta que para 2027, más del 70% de las iniciativas de ERP implementadas recientemente no cumplirán del todo sus objetivos de negocio originales. El informe ERP 2026 de Panorama Consulting encontró que más del 25% de las organizaciones superaron el presupuesto. Un análisis de Godlan de 2026 (socio de Infor, tómese como orientativo) situó el fracaso de ERP en manufactura en el 73%, con sobrecostos promedio del 215%.
Si usted gestiona un puerto, un patio, una mina o cualquier operación de campo, esas cifras le parecerán bajas. La tasa de fracaso no es un problema de gestión de proyectos. Es estructural. Las mismas cinco cosas fallan, en el mismo orden, en cada proyecto que reviso después del hecho.
TL;DR
- Gartner: más del 70% de los proyectos de ERP recientes no alcanzan sus objetivos de negocio originales para 2027.
- Panorama: más del 25% de las implementaciones de ERP superan el presupuesto por necesidades tecnológicas adicionales.
- Godlan: el 73% de los proyectos de ERP en manufactura discreta no cumplen sus objetivos, con sobrecostos del 215%.
- Cinco patrones de fracaso se repiten en los proyectos industriales: desajuste de plantilla, deuda de integración OT, el precipicio de adopción, la caída de piloto a producción, el bloqueo por costos hundidos.
- Hershey (100 millones de dólares en pedidos no cumplidos), Lidl (500 millones de euros dados de baja) y Revlon (déficit de 64 millones de dólares en el primer trimestre) muestran el patrón a gran escala.
- Aproximadamente el 60% de la realidad operativa vive fuera del sistema, en radio, WhatsApp y notas de turno que el ERP nunca ve.
Panorama estadístico del fracaso en implementaciones de ERP
Cada cifra en las secciones siguientes tiene su fuente citada. Esta tabla reúne la evidencia primaria en un solo lugar para consulta rápida.
| Fuente | Hallazgo clave |
|---|---|
| Gartner | Más del 70% de las iniciativas de ERP implementadas recientemente no alcanzan sus objetivos de negocio originales para 2027 |
| Panorama Consulting 2026 | Más del 25% de los proyectos de ERP superan el presupuesto, impulsado por necesidades tecnológicas adicionales |
| Godlan 2026 | El 73% de los proyectos de ERP en manufactura no cumplen sus objetivos, con un sobrecosto promedio del 215% |
| CIO sobre Hershey | Cerca de 100 millones de dólares en pedidos de Halloween de 1999 quedaron sin cumplir tras una puesta en marcha apresurada de SAP |
| Handelsblatt sobre Lidl | Se reportaron cerca de 500 millones de euros dados de baja tras el colapso de un esfuerzo de SAP de siete años |
| Dolfing sobre Revlon | 64 millones de dólares en pedidos del primer trimestre de 2018 no pudieron cumplirse tras la migración a SAP |
| Informe 10-K de Revlon 2018 | Pérdida neta de 294.2 millones de dólares para el año completo 2018, revelada en el informe anual |
Fuentes primarias referenciadas arriba:
Las cinco formas en que los proyectos de ERP fallan en las operaciones industriales
Cinco patrones se repiten una y otra vez. Aparecen en distintas combinaciones según la operación y el proveedor. Cada implementación fallida que he revisado coincide con al menos tres de ellos. Cada patrón tiene su propia sección a continuación.
1. Aumento de alcance por plantillas genéricas
Todo ERP importante se construye sobre plantillas de procesos. Hay una forma estándar de modelar una orden de compra, y una orden de trabajo estándar. Un registro de inventario estándar. Esas plantillas fueron diseñadas para el conjunto de clientes más amplio posible.
Se ajustan a ese conjunto de clientes tan bien como una talla única le queda a un cuerpo humano real.
El equipo de implementación mapea el proceso del cliente a la plantilla. Donde no encaja, deben elegir: personalizar el sistema o cambiar el proceso. La personalización es costosa y crea deuda técnica permanente. Cambiar el proceso les pide a los operadores trabajar de forma distinta a como saben hacerlo.
En la práctica, ambas cosas ocurren a la vez. El alcance se expande para cubrir la personalización. Aun así, se les pide a los operadores que se adapten. El costo de construcción crece de forma significativa antes de la puesta en marcha. El resultado no es ni una plantilla limpia ni una reproducción fiel del flujo de trabajo.
El software a medida parte de su flujo de trabajo, no de la plantilla de un proveedor. No hay una capa de traducción entre cómo funciona la operación y cómo el sistema espera que funcione.
2. Deuda de integración OT
Tecnología operativa significa SCADA, PLC, MES, telemática y redes de sensores. Es lo que hace funcionar la operación física. No habla el lenguaje del ERP.
Los sistemas ERP se construyeron para datos de negocio: transacciones, registros, aprobaciones. OT genera señales en tiempo real a un volumen que la mayoría de los modelos de datos de ERP nunca fueron diseñados para manejar.
La solución habitual es un conector. El middleware traduce las señales OT a registros compatibles con el ERP, y los conectores funcionan bien en demostraciones. En producción se convierten en su propio proyecto de mantenimiento de varios años.
Un conector construido para un firmware de PLC específico deja de funcionar cuando el PLC se actualiza. Uno ajustado para 100 eventos por segundo no sobrevive a 10,000. El backlog de integración de seis meses sigue abierto dos años después. El equipo de operaciones lleva un proceso paralelo en hojas de cálculo porque el sistema conectado solo está conectado alrededor del 60% del tiempo.
He visto este patrón en pisos de operación de puertos y patios. Los conectores no son mal software. Son la arquitectura equivocada para el problema.
El software a medida trata la OT como un requisito de primera clase desde el primer día, no como middleware añadido después. Cuando su capa de integración maneja SCADA, PLC y telemática como flujos de datos nativos, no hay deuda de conectores que se acumule.
3. El precipicio de adopción
El precipicio de adopción golpea cuando las personas que usan el sistema a diario deciden que son más productivas ignorándolo que aprendiéndolo. Operadores de terminal, supervisores de turno, despachadores, cuadrillas de mantenimiento.
Esto no es irracional. Es una respuesta racional a un sistema diseñado en una sala de reuniones por un equipo de proyecto que nunca corrió un turno.
El precipicio aparece dentro de los 90 días posteriores a la puesta en marcha. El equipo de proyecto ya se fue. El equipo de operaciones vuelve a WhatsApp, radio y hojas de cálculo para las decisiones que importan. El ERP se usa para los informes que finanzas exige.
El sistema de registro se convierte en un sistema de cumplimiento.
La adopción no es un problema de capacitación. Más capacitación sobre un flujo de trabajo deficiente sigue siendo más capacitación sobre un flujo de trabajo deficiente. La adopción es un problema de diseño. Las personas que iban a usar el sistema no estaban en la sala cuando se diseñó el flujo de trabajo.
El software a medida se construye aprendiendo del terreno. Sentándose con las personas que dirigen el turno. Mapeando las excepciones y los casos límite reales. Construyendo flujos de trabajo alrededor de lo que ya saben hacer.
El resultado es un sistema que se ajusta al trabajo, de modo que los operadores realmente lo usan. La vista de operaciones en vivo se parece a la operación porque se construyó a partir de la operación.
4. La caída entre el piloto y la producción
Los pilotos de ERP tienen éxito. La prueba de concepto se ejecuta con datos limpios y curados, y un grupo pequeño de usuarios asesorados. Un conjunto de procesos acotado que el equipo de implementación sabe manejar.
El patrocinador ejecutivo ve la demostración. El proyecto recibe luz verde, y comienza el despliegue completo.
La producción es un animal distinto. Tiene datos heredados desordenados que nunca se limpiaron por completo antes de la migración. Tiene casos límite que el piloto nunca tocó. Un transportista con un formato de BOL no estándar. Equipo con un historial de mantenimiento en un sistema no incluido. Un traspaso de turno que se realiza por radio y WhatsApp porque siempre ha sido así.
El entorno piloto limpio y el entorno de producción en vivo no son el mismo lugar.
La caída no es un problema de datos aislado. Es lo que ocurre cuando se pilota sobre una versión simplificada de la realidad, y luego se despliega en la versión completa sin ajustar el sistema.
El software a medida se valida contra cómo se comporta realmente la operación, eso incluye los datos fuera de sistema. La capa de captura de estado maneja lo que llega por radio, WhatsApp y correo electrónico, no solo lo que llega a través de integraciones estructuradas. El entorno de producción es el entorno de diseño.
5. El bloqueo por costos hundidos
Una vez que una organización industrial ha gastado entre dos y cinco millones de dólares en licencias de ERP, consultoría y personalización, retirarse se vuelve políticamente imposible.
El director financiero aprobó la cifra. La junta directiva vio la presentación. Los operadores que plantearon inquietudes desde el principio fueron ignorados. Para cuando queda claro que el sistema no va a cumplir, la organización lleva 18 meses invertida.
Nadie quiere ser la persona que firma el memo que declara la inversión como una pérdida.
Entonces la organización redobla la apuesta, y más personalización. Más consultoría, y más gestión del cambio. El costo total crece, y la puesta en marcha se retrasa. El sistema que finalmente se lanza es un compromiso que nadie tiene autoridad para reemplazar.
He visto a equipos de operaciones ejecutar sistemas paralelos durante años, y el ERP para cumplimiento. WhatsApp y hojas de cálculo para todo lo que realmente importaba.
El software a medida invierte el modelo de riesgo. No gastas dos millones de dólares antes de saber si el sistema funciona. Ves una solución real y funcional sobre tus datos, para un problema que tú eliges, y pagas solo si se gana su lugar. El primer riesgo lo asumimos nosotros.
Cómo se manifiestan las fallas de ERP a gran escala
Los siguientes tres casos son fallas documentadas, con cifras reales. Organizaciones identificadas. Cada una corresponde a uno o más de los patrones anteriores.
Hershey, 1999. Hershey ejecutó una puesta en marcha simultánea de SAP, Manugistics y Siebel en el verano de 1999. El plan se comprimió en aproximadamente seis meses para llegar a tiempo para Halloween. El sistema se puso en marcha justo cuando llegaban los pedidos de Halloween. No pudo cumplir con pedidos por un valor aproximado de 100 millones de dólares en Kisses y Jolly Ranchers a tiempo. Las acciones de Hershey cayeron aproximadamente un 8% en un solo día. La causa fue la caída entre el piloto y la producción a una escala de 100 millones de dólares.
Lidl, 2018. Después de aproximadamente siete años y un gasto estimado de 500 millones de euros, Lidl abandonó su implementación de SAP. Según lo reportado por Handelsblatt, el problema de raíz fue un desajuste en el modelo de datos. El modelo estándar de inventario minorista de SAP funciona sobre precios de venta al público. La operación de Lidl funciona sobre precios de compra. Lidl se negó a cambiar su proceso, así que se personalizó SAP en su lugar. La personalización se extendió durante años sin generar valor. Ni Lidl ni SAP han confirmado oficialmente las cifras reportadas. Desviación de alcance a partir de plantillas genéricas, a una escala de 500 millones de euros.
Revlon, 2018. La migración a SAP de Revlon en su planta de Oxford, Carolina del Norte, interrumpió los envíos del primer trimestre. La compañía no pudo cumplir con pedidos por un valor estimado de 64 millones de dólares solo en el primer trimestre. La cifra surgió en demandas colectivas de inversores basadas en divulgaciones de resultados. Revlon reportó una pérdida neta de 294.2 millones de dólares para el año fiscal 2018 completo en su informe 10-K anual. La cifra de 64 millones de dólares a veces se confunde en LinkedIn con la carga de deuda de 3 mil millones de dólares que precedió a la posterior bancarrota de Revlon. Son eventos distintos. La falla de ERP de 2018 fue una falla de integración OT y de preparación para producción.
El hilo conductor: ninguno de estos fue un problema tecnológico. Fueron problemas de arquitectura y validación. Cada organización desplegó un sistema que funcionaba en un entorno controlado y se rompió bajo operaciones reales.
El tercer camino
Hay dos respuestas obvias a la lista de fallas anterior.
La primera es construir internamente, y contratar un equipo de ingeniería. Especificar los requisitos desde cero. Construir software que se ajuste exactamente a la operación, y funciona en algunas ocasiones. También requiere un compromiso de ingeniería de varios años, liderazgo técnico que la mayoría de los operadores no tienen, e inversión continua para mantener lo que se construyó.
Si tu trabajo principal es operar un puerto, un patio o una mina, construir software internamente es una distracción.
La segunda es comprar un mejor ERP o un SaaS vertical más especializado y gestionar la implementación con más cuidado. Es la misma apuesta hecha de nuevo con mejor gobernanza del proyecto. Los problemas estructurales no desaparecen porque el gerente de proyecto tenga más experiencia.
El tercer camino es diferente en naturaleza, no en grado. Software a medida: construido para tus objetivos específicos, conectado a tus sistemas y datos específicos, validado contra cómo se comporta realmente tu operación. Mantenido en funcionamiento y mejora continua a lo largo de su ciclo de vida.
Este es el tercer camino sobre el que ya hemos escrito antes. Aborda los patrones de falla en su raíz, no en sus síntomas.
Opsima es la fábrica de software nativa en IA para operaciones industriales. Construye el software de CMMS, TMS, TOS, EAM, ERP, monitoreo de equipos y procesamiento de documentos sobre el que funciona su operación, adaptado a cómo trabaja realmente su operación.
Dos modos de servicio: (1) adaptar sobre su stack existente (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) sin reemplazar ningún sistema, o (2) construir el reemplazo desde cero cuando el sistema legacy se ha quedado pequeño. Entrega en semanas. Usted paga solo cuando ve el valor.
El modelo de Opsima hace esto concreto. Aprendemos cómo funciona realmente la operación, casos límite incluidos. Construimos software diseñado alrededor de ese flujo de trabajo. Se integra con el ERP, EAM, TMS, TOS o WMS que ya usas, en lugar de reemplazarlo. Gestionamos los datos que nunca llegan a tus sistemas de registro: las llamadas por radio, los hilos de WhatsApp, las notas de turno escritas a mano. Eso es aproximadamente el 60% de la realidad operativa en la mayoría de las plantas que he recorrido.
Luego pasamos a producción, validamos contra el comportamiento real de producción, y mantenemos el sistema funcionando y mejorando a medida que cambia la operación.
El modelo comercial refleja la inversión del riesgo. No te comprometes con un acuerdo de licencia multimillonario antes de haber visto funcionar el sistema. Construimos una solución real y funcional para un problema que tú eliges, con tus datos, en tu infraestructura. La ves funcionar. La evalúas contra tu operación, y luego decides.
Los detalles están en la página de precios. La versión corta: nosotros asumimos el primer riesgo.
Los casos de estudio muestran cómo se ve esto en la práctica. Uno de ellos es PNCT.
Cómo se ve cuando funciona
Port Newark Container Terminal maneja aproximadamente 1.65 millones de TEU al año a través de una flota de más de 100 straddle carriers. La flota funciona 24 horas al día, siete días a la semana. La disponibilidad de los straddle carriers es la restricción. Cuando un transportador está fuera de servicio, el rendimiento cae. Cada hora de tiempo de inactividad no planificado tiene un costo real.
El problema que PNCT le trajo a Opsima no era exótico. Los datos de equipos, el historial de mantenimiento y los registros operativos residían en sistemas que no se comunicaban entre sí. Los técnicos tomaban decisiones de mantenimiento con información incompleta. Las averías eran reactivas, no anticipadas.
Opsima construyó una solución conectada a los sistemas que PNCT ya operaba. Telemetría, registros de mantenimiento y datos operativos incorporados en una capa de operaciones en vivo que el equipo de mantenimiento realmente podía usar.
El resultado: +5% en la disponibilidad de la flota de straddle carriers y aproximadamente un 15% de reducción en averías no planificadas.
En una flota de 100 transportadores, un 5% de disponibilidad equivale aproximadamente a cinco unidades adicionales en línea por turno. Esas cinco unidades no requieren nuevas compras de equipo. No requieren nueva inversión de capital. No requieren nuevo personal. Son capacidad de rendimiento recuperada de la flota existente mediante mejor información.
El equipo de PNCT lo expresó claramente: “No eran simplemente otro gran proveedor de software. Llegaron ya con un concepto y una actitud de resolver las cosas.”
Esa es la diferencia entre un sistema construido para mil clientes y uno construido para ti.
Un problema acotado, y un sistema entregado. Semanas, no años.
Un diagnóstico de 10 preguntas sobre el ajuste del ERP
Antes de comprometerte con una implementación de ERP, o antes de aceptar que el actual es la mejor opción disponible, responde estas diez preguntas con honestidad. Cada una corresponde a uno de los cinco patrones de falla anteriores.
Sobre el ajuste de plantillas:
- ¿Puede su equipo de operaciones describir un flujo de trabajo que el ERP maneje exactamente como fue diseñado, sin personalización ni solución alternativa?
- Cuando un proceso cambia en el campo, ¿cuánto tiempo toma reflejar ese cambio en el sistema? ¿Horas, semanas o meses?
Sobre la integración OT:
- ¿Sus feeds de SCADA y PLC se tratan como datos de primera clase, o se ingieren mediante un conector fuera de la arquitectura principal?
- ¿Su proyecto de integración ha estado “casi terminado” durante más de seis meses?
Sobre la adopción:
- ¿Las personas que dirigen sus turnos tuvieron una participación real en el diseño del flujo de trabajo? ¿O se les incorporó para las pruebas de aceptación de usuario después de que el diseño ya estaba cerrado?
- ¿Qué porcentaje de las decisiones operativas se toman realmente dentro del sistema, frente a las que se toman al margen de él, en llamadas de radio, WhatsApp y hojas de cálculo?
Sobre el paso de piloto a producción:
- ¿Su piloto se ejecutó sobre un conjunto de datos limpio y curado, o sobre una instantánea real y desordenada de los datos de producción?
- ¿El sistema maneja los casos excepcionales tan bien como el caso estándar? ¿El transportista no estándar, el historial de mantenimiento incompleto, el relevo por radio?
Sobre el riesgo comercial:
- ¿Vio una solución funcionando con sus propios datos antes de comprometerse con el gasto? ¿O se comprometió tras una demo del proveedor ejecutada con datos del proveedor?
- ¿El precio depende de si el sistema funciona para su operación, o el proveedor cobra de todos modos?
Si respondió que no a tres o más, no está describiendo un problema de ajuste de ERP. Está describiendo un problema de software a medida.
La Conclusión
Las implementaciones de ERP fracasan en las operaciones industriales por razones estructurales, y esas razones se repiten.
Las plantillas genéricas obligan a las operaciones a adaptarse, y la deuda de integración OT se acumula. La adopción colapsa cuando las personas que dirigen la operación no estaban presentes cuando se diseñó el flujo de trabajo. Los pilotos tienen éxito con datos limpios y fallan ante la realidad de producción. Los costos hundidos hacen que sea políticamente imposible cambiar de rumbo.
La alternativa es un software construido alrededor de su operación. Su flujo de trabajo, sus sistemas, sus datos. Mantenido en funcionamiento y mejorado a lo largo de su ciclo de vida, no entregado y olvidado.
Software a medida, construido para su flujo de trabajo, pagado solo cuando ve el valor. Eso es lo que el ERP debía ser.
Cuéntenos el proceso que ha dejado de intentar arreglar. Construimos una solución real y funcional con sus datos, para un problema que usted elija. Solo paga si se gana su lugar. Para reducir el riesgo de la próxima implementación con software ERP a medida construido alrededor de su operación, reserve una sesión de trabajo con Opsima.
Deja de perder eventos operativos en hojas de cálculo.
Alrededor del 60% de tus datos ops viven fuera del sistema. Opsima los captura en software personalizado, en semanas.
Ver cómo funciona →
