10 errores de modernización de ERP que debe evitar

Los errores de modernización de ERP que más daño hacen son estratégicos, no técnicos: tratar el go-live como la meta, copiar los procesos heredados en el sistema nuevo, empezar tarde con los datos y el cambio, construirlo todo dentro del ERP y firmar licencias sin un modelo a cinco años. Rara vez se ven en tiempo real. Afloran después del go-live, cuando las eficiencias prometidas no aparecen y vuelven las soluciones provisionales.

Este artículo es para CIO, CFO y directores de programa que planifican o rescatan una modernización a S/4HANA o a otro ERP. Cada error incluye cómo se ve en la práctica y la solución, seguidos de una lista de alerta temprana de una página y de lo que significan los cambios de SAP en 2026.

He visto proyectos bien financiados, con equipos experimentados y un plantel completo de asesores, quedarse igualmente cortos. La causa rara vez es el sistema. Son las brechas de responsabilidad, de planificación de la integración y de comunicación entre equipos que toman decisiones que dependen unas de otras.

1. Tratar el go-live como la meta

Una vez que el sistema está en producción, muchos equipos dan por hecho que lo más pesado ya pasó. Ahí es cuando empieza la presión real: la operación diaria, los requisitos cambiantes y el comportamiento real de los usuarios chocan con el diseño.

He visto proyectos en los que el comité directivo se disuelve justo después del go-live. Seis meses después la adopción está estancada y nadie es dueño del backlog.

La solución: financie un periodo de gobierno de 6 a 12 meses después del go-live. Amplíe el mandato del comité directivo. Supervise la adopción de los procesos, no solo la disponibilidad. Fije quality gates posteriores al go-live con responsables designados.

2. Migrar procesos heredados sin replantearlos

He visto cadenas de aprobación enteras reconstruidas exactamente como eran, aunque la mitad de las personas implicadas no tuviera nada que ver con el proceso actual. Nadie se había preguntado si los pasos seguían siendo necesarios. El resultado fue un ERP moderno que ejecutaba flujos de trabajo antiguos: una versión más cara de lo que ya tenían.

La versión de esto en S/4HANA: procesos por lotes a medida movidos tal cual desde ECC, construidos sobre estructuras de tablas que ya no existen. La migración es técnicamente limpia. La lógica de negocio está rota.

La solución: rediseñe los procesos antes de la construcción. Recorra cada flujo de trabajo junto con los equipos de operaciones, finanzas y entrega, y cuestione cada paso.

Área heredada	Qué suele salir mal	Qué hacer en su lugar
Código a medida de ECC	Código a medida sin uso trasladado a S/4HANA	Ejecute un análisis de uso y las comprobaciones de código a medida de SAP; retire el código que no se usa
Flujos de trabajo antiguos	Se reconstruyen flujos de aprobación cuando ahora es posible automatizar	Revíselos con los responsables de negocio; use apps estándar de Fiori o SAP Build Process Automation
Datos maestros no estándar	Las configuraciones heredadas flexibles no superan la validación de S/4HANA	Depure y armonice antes de la migración, con SAP MDG donde encaje
Informes sobre tablas heredadas	El acceso directo a tablas no encaja con el modelo de datos de S/4HANA	Reconstruya sobre vistas CDS
Soluciones provisionales manuales ocultas	Los procesos paralelos reaparecen tras el go-live	Use process mining antes de la migración y digitalice las brechas

3. Empezar tarde la migración de datos

Llevar datos malos a un ERP nuevo es como mudarse de casa sin tirar nada. El desorden se viene con usted y es más difícil de despejar una vez dentro de un sistema estructurado.

Una vez vi fracasar un go-live porque nadie detectó que un conjunto de datos central tenía registros de cinco unidades de negocio distintas, cada una con su propia lógica de codificación. La migración técnica fue correcta. Los datos no eran utilizables. Los informes fallaron, los usuarios perdieron la confianza y la limpieza con el sistema ya en producción llevó meses.

La solución: convierta los datos en un flujo de trabajo con responsabilidad del negocio. Asigne responsables de proceso, no solo consultores técnicos. Decida qué traer, qué archivar y qué reconstruir antes de que empiece la migración. Haga al menos dos cargas de prueba completas (mock loads), con un mapa de dependencias para la secuencia de carga y un rollback definido para cada carga. Mi artículo sobre por qué fracasa la migración de datos en SAP profundiza en esto.

4. Tratar la gestión del cambio como una tarea secundaria

La versión habitual: la gestión del cambio «ya está resuelta», lo que significa unas cuantas diapositivas, una demostración y una sesión de formación antes del go-live.

La gente no se resiste porque le disguste el cambio. Se resiste cuando nadie explica por qué las cosas cambian ni en qué le benefician. Siguen el sistema lo justo para pasar la lista de comprobación y luego vuelven a las hojas de cálculo.

El detonante habitual es la presión del calendario: se comprime la formación para recuperar tiempo, los usuarios llegan desbordados al go-live y el hypercare adicional cuesta más que la formación que se recortó.

La solución: dé a la gestión del cambio su propio presupuesto, calendario y responsable sénior desde el principio. Mapee los roles pronto, encuentre campeones locales y haga seguimiento de los KPI de adopción junto con los hitos técnicos. Mi guía del plan de gestión del cambio expone la estructura.

5. Planificar en función de las hojas de ruta de los proveedores

He visto equipos basar su estrategia de integración en una versión futura de un proveedor, para ver cómo se retrasaba 12 meses. Mientras tanto se quedaron construyendo soluciones provisionales, y esas soluciones se volvieron permanentes.

Los proveedores construyen sus hojas de ruta para grupos amplios de clientes. Su negocio rara vez es el centro de ese diseño.

La solución: trate la hoja de ruta como un dato más. Diseñe en torno a lo que está disponible hoy con carácter general, pruebe las funciones nuevas en un sandbox antes de planificar con ellas y cuente los beneficios de la hoja de ruta como un extra, no como presupuesto.

6. Sin plan de desmantelamiento de los sistemas heredados

Una vez vi a una empresa pagar seis cifras al año por mantener en marcha un sistema antiguo para seis usuarios que necesitaban sacar informes dos veces al año. Nadie había elaborado un plan de desmantelamiento.

La solución: incluya el desmantelamiento en el acta de constitución desde el primer día, con la participación de legal, cumplimiento y gobierno de datos, no solo de TI. Acuerde los periodos de retención y un enfoque de archivo antes del go-live, mapee y desconecte todas las interfaces con el sistema antiguo y encargue a un equipo la tarea de apagarlo.

7. Subestimar la complejidad de la integración

Cuando falla una integración, el negocio lo nota antes que TI, porque los flujos de trabajo se detienen a mitad de proceso en producción, no en un sistema de pruebas.

El patrón habitual: TI y el negocio suponen cada uno que el otro ha definido los requisitos de integración. Ninguno lo ha hecho. Cuando las brechas aparecen en las pruebas, ya no hay tiempo para rediseñar.

La solución: empiece el diseño de la integración en el blueprint. Defina cada escenario, el middleware, el mapeo y los volúmenes de mensajes, y aclare con el negocio qué interfaces son en tiempo real y cuáles por lotes. Designe un responsable de interfaces con un SLA antes del go-live. Para los programas SAP nuevos el middleware es SAP Integration Suite; SAP PI/PO sale del mantenimiento estándar a finales de 2027.

8. Suponer que el ERP puede con todo

He trabajado en proyectos en los que los equipos metieron a la fuerza en el ERP flujos de servicio complejos (tickets de TI, solicitudes de activos, enrutamiento de escalaciones) porque no querían involucrar sistemas externos como ServiceNow. El resultado fueron campos personalizados por todas partes, soluciones provisionales manuales y usuarios atrapados en un proceso que nunca encajó.

El ERP es bueno en procesos estructurados, transaccionales y anclados en lo financiero. Las plataformas especializadas hacen mejor las solicitudes de servicio de TI, la orquestación de flujos de trabajo y la gestión del conocimiento.

La solución: decida de forma deliberada qué no construir en el ERP. Use extensiones side-by-side en SAP BTP para las excepciones, y ServiceNow u otra herramienta similar para la orquestación fuera del núcleo transaccional. Mi artículo sobre la modernización del ERP con SAP y ServiceNow trata esa división.

9. Subestimar el costo de licencias a largo plazo

Conozco a un equipo que duplicó su gasto en licencias en el segundo año porque necesitaba una sola función incluida en una licencia de nivel superior. El caso de negocio solo había modelado el costo hasta el go-live.

Las licencias de ERP cobran por usuarios, módulos, transacciones y uso de API, y el costo crece con el negocio lo haya planificado o no. En SAP, el modelo de Digital Access implica que los documentos creados por sistemas de terceros pueden acarrear un costo de licencia que no estaba en el modelo comercial original. Con RISE y SAP GROW, el recuento de Full User Equivalent (FUE) crece con la adopción.

La solución: elabore un modelo de licencias a tres o cinco años antes de firmar. Asigne los roles a tipos de licencia, modele el crecimiento de FUE con una curva de adopción realista, entienda el acceso indirecto antes de conectar sistemas externos y audite los usuarios inactivos después del go-live.

10. Tratar el ERP como un proyecto de TI

El patrón más habitual y el más dañino. La planificación empieza en TI, la lidera TI y resuelve problemas de TI.

He visto equipos cumplir todos los hitos sobre el papel mientras el negocio sigue preguntando por qué nada se siente mejor. Eso suele significar que el ERP se construyó para los procesos de ayer, sin líderes de operaciones, finanzas o del área comercial en el diseño.

La solución: incorpore desde el principio a líderes comerciales, de finanzas y de operaciones al comité directivo. Escriba la alineación estratégica en el acta de constitución, no solo el alcance técnico. Contraste los objetivos del programa con los resultados a nivel de consejo antes de que empiece el diseño.

Utilícela en cada comité directivo. Si hay una señal de alerta, el responsable designado informa sobre ella hasta que desaparezca.

1. Acta de constituciónResponsabilidad y costosSin líder de operaciones ni de finanzas, sin modelo de licencias a cinco años, sin fecha de retirada
2. BlueprintDiseño de procesos e integraciónEl proceso actual copiado, interfaces aún sin diseñar
3. Primera carga de pruebaDatosTodavía no hay informe de calidad de datos
4. Go-liveQué pasa despuésSin gobierno financiado para los 12 meses siguientes

Error	Señal de alerta temprana	Responsable
1. El go-live como meta	No hay un plan de gobierno financiado para los 12 meses posteriores al go-live	Patrocinador
2. Procesos heredados copiados	Los talleres de diseño parten de pantallas de «cómo lo hacemos hoy»	Responsables de proceso
3. Datos tardíos	No hay informe de calidad de datos antes de la primera carga de prueba	Líder de migración de datos
4. El cambio como tarea secundaria	El plan de cambio es un calendario de formación	Líder de cambio
5. Dependencia de la hoja de ruta	Una decisión de diseño espera una función que aún no se ha lanzado	Arquitecto de soluciones
6. Sin desmantelamiento	Ningún sistema heredado tiene fecha de retirada en el acta de constitución	PMO
7. Integración subestimada	Interfaces sin diseñar al terminar el blueprint	Líder de integración
8. ERP para todo	Objetos a medida para flujos de trabajo no transaccionales	Arquitecto empresarial
9. Licencias	No hay modelo de licencias a cinco años en el caso de negocio	CFO
10. Programa solo de TI	El comité directivo no tiene líder de operaciones ni de finanzas	Patrocinador

Despliegue. Para los programas SAP nuevos, lo habitual es RISE with SAP sobre SAP Cloud ERP Private, o SAP GROW sobre la edición pública (SAP Cloud ERP) para empresas medianas. Los despliegues on-premise nuevos son poco frecuentes. Los clientes de ECC se enfrentan al fin del mantenimiento estándar el 31 de diciembre de 2027, lo que acorta el tiempo disponible para corregir los errores 2, 3 y 7.

Clean core. SAP clasifica ahora las extensiones en cuatro niveles de clean core, desde el A (solo APIs publicadas, side by side en BTP o dentro del sistema con ABAP Cloud) hasta el D (no clean). La edición pública solo admite el nivel A, lo que fuerza la conversación que hay detrás del error 2. La edición privada todavía admite extensiones clásicas, así que la disciplina tiene que venir del gobierno. El código a medida clásico es lo que convierte cada actualización en un proyecto. Mi artículo sobre la estrategia clean core va más a fondo.

IA en las herramientas de entrega. Joule ya está en SAP Cloud ALM y en el SAP Activate Roadmap Viewer, y SAP Build Code usa Joule para el desarrollo de extensiones. Pregunte a los socios cómo se refleja la IA en su tarifario. Si no se refleja, o el precio es alto o el ahorro se va a su margen.

Herramientas del ciclo de vida. SAP Cloud ALM es la herramienta de gestión del ciclo de vida de los programas en la nube. Solution Manager 7.2 sale del mantenimiento estándar a finales de 2027, así que los entornos que ejecutan ambos necesitan un plan para el traslado.

Los diez errores no cambiaron. Lo que cambió es el costo de cometerlos. En un programa RISE, la decisión de clean core, el modelo de despliegue y el modelo de FUE se fijan en las primeras semanas de movilización. La ventana para influir en ellos es corta.

¿Por qué las iniciativas de modernización de ERP se quedan cortas después del go-live?

La mayoría de los equipos planifica hasta el go-live y se detiene. Nadie es dueño de las mejoras, los comentarios, las correcciones de proceso ni del backlog. La disolución del comité directivo en el go-live es la señal más fiable de problemas. Financie 6 a 12 meses de gobierno posterior al go-live desde el primer día.

¿Cuál es el riesgo de copiar procesos heredados en un ERP nuevo?

El sistema nuevo hereda las viejas ineficiencias a un costo mayor. En las migraciones a S/4HANA en concreto, el código a medida y los procesos por lotes construidos para tablas de ECC a menudo no funcionan, de modo que la migración puede ser técnicamente limpia mientras la lógica de negocio está rota.

¿Cómo daña la mala calidad de los datos una modernización de ERP?

Los proveedores duplicados, los datos maestros inconsistentes, los códigos heredados y los registros incompletos pasan al sistema nuevo si nadie los depura antes. Los informes fallan, los usuarios dejan de confiar en las cifras y la limpieza con el sistema en producción lleva meses.

¿Por qué se subestima tanto la gestión del cambio en los proyectos de ERP?

Porque no se ve en un plan de proyecto como se ve la configuración. Los directivos suponen que unas cuantas sesiones de formación bastan. La gestión del cambio consiste en preparar a las personas para lo que realmente va a cambiar en su trabajo diario, antes del go-live. Las herramientas de adopción digital como WalkMe, ahora propiedad de SAP, ayudan con la guía dentro de la aplicación, pero no sustituyen la explicación del porqué.

¿Por qué los sistemas heredados siguen funcionando años después del go-live del ERP?

Porque nadie planificó apagarlos. Todos están centrados en poner en marcha el ERP nuevo, y los sistemas antiguos se quedan por cumplimiento, por consulta o por comodidad. El desmantelamiento tiene que estar dentro del alcance desde el primer día, con legal y cumplimiento involucrados.

¿Cómo cambian RISE with SAP y el clean core estos errores?

En la edición pública, las reglas de clean core hacen imposible la personalización profunda, lo que fuerza la conversación sobre procesos que hay detrás del error 2. En la edición privada siguen permitidas las extensiones clásicas, de modo que el clean core depende del gobierno. La integración pasa a SAP Integration Suite a medida que termina el mantenimiento de PI/PO. Las licencias se convierten en una cuestión de crecimiento de FUE. El desmantelamiento se vuelve más urgente porque mantener sistemas heredados en paralelo suma costos a una suscripción de varios años.