Descubrir el reset a mitad de proyecto: el costo en cronograma
Qué cuesta descubrir a mitad de proyecto que la conversión ECC→S/4HANA es un reset y no un upgrade, medido en cronograma, para una utility LATAM.
· 11 min de lectura
Semana veintidós. El comité recibe una solicitud de cambio que no pide dinero: pide fecha. El equipo encontró que un bloque de interfaces del ciclo comercial necesita rediseño, no ajuste. Nadie agregó ese trabajo al proyecto. Siempre estuvo ahí. Lo único que cambió es el momento en que la organización se enteró.

La pieza anterior de esta serie mostró dónde aparecen realmente las sorpresas de una conversión ECC→S/4HANA: en el perímetro de integración, antes del go-live. Aquí interesa la otra mitad de la pregunta, la que un directorio sí sabe leer: cuánto cuesta enterarse tarde, expresado en cronograma.
Las cifras que ya están medidas
El dato más reciente y más directo viene de un informe de analista. El estudio State of SAP Migrations encuestó a más de 200 tomadores de decisión senior en grandes empresas globales y encontró que casi 60% de las migraciones SAP van detrás de cronograma y sobre presupuesto, con tres causas dominantes: complejidad subestimada, expansión de alcance y restricciones internas de capacidad (ISG, 2026).
La magnitud del desvío la aporta un estudio anterior con 200 ejecutivos: las transformaciones S/4HANA toman en promedio 30% más de lo planificado, y menos de una de cada diez empresas que ya completaron la transformación cumplió el plazo previsto (Horváth, 2025). La muestra es europea y estadounidense, no LATAM: sirve como patrón de referencia, no como cifra regional.
Conviene ser preciso con lo que esas cifras dicen y con lo que no. Nadie publica el número de semanas que pierde una distribuidora de la región por descubrir tarde el alcance real. Lo que sí está medido es la proporción: un tercio adicional sobre el plan es el promedio, no el peor caso, y cumplir la fecha es la excepción estadística.
El retraso no es técnico
Aquí está el hallazgo que cambia la conversación. Según el mismo informe, los retrasos se deben con más frecuencia a gobernanza débil que a desafíos técnicos, por lo que suelen ser síntoma de un problema mayor (ISG, 2026).
El detalle lo explicita uno de sus analistas: los equipos que intentan una conversión rápida, tipo lift-and-shift lo más barata posible, subestiman la complejidad, el alcance y sus propias restricciones, y luego sufren expansión de alcance y requisitos cambiantes sobre la marcha; buena parte de los retrasos la causan las personas, no la tecnología (ISG, 2026). Y una de las coautoras señala el mecanismo concreto: muchos programas reúnen varios integradores, servicios profesionales y especialistas de nicho, pero carecen de derechos de decisión claros, criterios de aceptación y titularidad definida entre proveedores; esa contabilidad fragmentada es la que produce la expansión de alcance (ISG, 2026).
La lectura operativa es incómoda: la sorpresa no crea el trabajo, lo revela. Lo que el cronograma paga no es el rediseño en sí, sino la re-decisión — reabrir el alcance, renegociar responsabilidades entre proveedores y reconstruir un plan con el reloj corriendo.

Lo que se descubre tarde cuesta más de arreglar
El momento del hallazgo importa por una razón técnica documentada: no todas las incompatibilidades se detectan en el análisis temprano. Muchas emergen durante las pruebas de integración o en la validación de etapa tardía, donde la remediación se vuelve más disruptiva y costosa; sin una estrategia proactiva, las organizaciones corren el riesgo de descubrir bloqueantes cuando los plazos ya están comprimidos (smartShift, 2026).
La misma fuente enumera el efecto en cadena cuando eso ocurre: alcance de remediación ampliado, plazos de prueba extendidos, más coordinación entre equipos y mayor riesgo de negocio (smartShift, 2026). Cada uno de esos cuatro efectos consume calendario, y ninguno se resuelve contratando más gente en la semana veintidós.
En una utility, el cronograma tiene anclas externas
Un proyecto corporativo genérico puede absorber un retraso corriendo la fecha. Una distribuidora eléctrica o una operación de oil & gas de la región tiene anclas que no se negocian: el ciclo de facturación vuelve cada mes, el calendario de reporte al ente regulador no espera, y la recaudación depende de que el ciclo meter-to-cash cierre a tiempo.
Eso cambia la aritmética del retraso. Cuando el trabajo que aparece tarde toca precisamente la cadena de medición y facturación, correr la fecha no es una decisión de proyecto: es una decisión de negocio con efecto sobre el flujo de caja del mes. Y en un contexto regional de modernización con presupuesto acotado, ese efecto se siente antes y con más fuerza que en una casa matriz con holgura financiera.
A esto se suma la restricción de capacidad que el propio informe identifica entre las causas dominantes del desvío (ISG, 2026): el perfil que se necesita para resolver una sorpresa de integración no está disponible bajo demanda, y menos a medida que se acerca el cierre de mantenimiento.
Lo que se traslada no desaparece
Hay una razón adicional para no diferir el problema. Lo que no se resuelve estructuralmente durante la ventana del proyecto no se elimina: se acumula y se traslada al siguiente release (smartShift, 2026).
La ventana tiene un valor que se subestima. Durante ella, el código ya está siendo evaluado, los ciclos de prueba ya están planificados, la mitigación de riesgo ya está financiada y el gobierno de cambios ya está activo. Después del go-live esa alineación se disuelve: los presupuestos cierran, la prioridad pasa a la estabilización y lo que se etiquetó como «fase siguiente» se convierte en deuda diferida (smartShift, 2026). Un enfoque de mantenimiento dual, que sostiene el código en el sistema origen y en el destino durante la conversión, es lo que permite acotar los períodos de congelamiento sin detener la operación (smartShift, 2026).
El reloj externo tampoco ayuda a diferir: el soporte estándar de ECC termina a fines de 2027, con soporte extendido disponible hasta fines de 2030 con un recargo de dos puntos porcentuales sobre la base de mantenimiento existente (SAP, estrategia de mantenimiento; The Register, 2026).

Qué pedirle al comité antes de comprometer una fecha
Tres pedidos concretos, todos anteriores a la firma del cronograma: que el alcance de integración se mida en lugar de estimarse; que cada frente tenga titularidad y criterios de aceptación explícitos entre proveedores, porque la evidencia señala la contabilidad fragmentada como origen de la expansión de alcance (ISG, 2026); y que el plan reserve holgura declarada, no implícita, para hallazgos que aparecerán en pruebas de integración.
En AGT acompañamos a operadores de la región a hacer esa conversación antes y no después, porque una fecha comprometida sobre un alcance supuesto no es un compromiso: es una apuesta con el ciclo de facturación de garantía.
Queda entonces la pregunta que cierra esta secuencia y abre la siguiente pieza de la serie: si la transformación promedio ya toma 30% más de plazo de lo previsto, cuál es exactamente el momento más barato para pagar esa sorpresa.
Fuentes
- ISG, State of SAP Migrations (febrero 2026), encuesta a más de 200 tomadores de decisión senior en grandes empresas globales, complementada con patrones observados en sus compromisos de asesoría. Firma de investigación y asesoría independiente; declaraciones citadas de Michael Dornan y Stacey Cadigan según la difusión pública del informe.
- Horváth, Business Transformation Unlocked – Maximizing the Benefits of SAP S/4HANA (abril 2025), 200 ejecutivos encuestados. Nota de veracidad: muestra de DACH, norte y este de Europa y EE. UU.; no incluye LATAM, por lo que sus cifras se usan como patrón y no como dato regional.
- smartShift, SAP Custom Code Transformation: The Key to Future-Proofing S/4HANA Upgrades (marzo 2026). Nota de veracidad: fuente de proveedor con interés comercial en la remediación automatizada de código custom; sus afirmaciones sobre dónde emergen las incompatibilidades y sobre el traslado de complejidad son atribuidas por el proveedor, no auditadas de forma independiente.
- The Register, cobertura del informe de ISG (5 de febrero de 2026), incluida la referencia a las fechas de soporte de ECC y al recargo del soporte extendido.
- Las afirmaciones sobre el ciclo de facturación, el calendario regulatorio y la presión sobre la recaudación en operadores de la región se presentan en lenguaje cualitativo: son la lectura operativa del equipo editorial, no un dato de mercado medido.
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.