S/4HANA: el 'upgrade' que el directorio aprobó no es un upgrade
Por qué convertir IS-U de ECC a S/4HANA no es un salto de versión: es un cambio de modelo de datos que el comité de dirección rara vez ve venir.
· 7 min de lectura
SAP fija el fin del mantenimiento mainstream de Business Suite 7 / ECC 6.0 (EHP 6-8) para el 31 de diciembre de 2027, con una fase opcional de mantenimiento extendido hasta 2030 sujeta a condiciones comerciales (SAP, según su estrategia oficial de mantenimiento). Ese calendario está empujando a utilities y operadoras de oil & gas en toda América Latina a decidir, en los próximos comités de dirección, el alcance de su conversión a S/4HANA. Y la mayoría de esos comités la aprueba bajo un supuesto que no resiste el detalle técnico: que se trata de una actualización de versión.
No lo es. S/4HANA no es ECC funcionando sobre una base de datos más rápida, sino un modelo de datos fundamentalmente distinto (TotalTek, 2026). Esa distinción —y no la fecha de fin de soporte— es la que determina si el proyecto que el directorio aprobó se parece o no a lo que realmente hay que construir.
No es una base de datos más rápida: es otro modelo de datos
La forma más común de vender la conversión internamente es decir que S/4HANA corre sobre HANA, una base de datos in-memory, y que por lo tanto todo será más veloz. Es cierto, pero incompleto. Tablas de agregación e índice sobre las que probablemente corre hoy buena parte de la lógica custom de IS-U —desarrollos de facturación masiva, interfaces de lecturas, reportes de cartera— quedan reemplazadas o redirigidas hacia vistas CDS (Core Data Services) que exponen los datos de forma distinta a como los consumía el código heredado (TotalTek, 2026). El sistema puede “verse” igual desde una transacción; por debajo, la forma en que se almacena y se accede a la información cambió de raíz.
De dónde sale la brecha: lo que se aprueba arriba y lo que se ejecuta adentro
En algún comité de dirección de una utility o una operadora de oil & gas en América Latina, alguien presentó la conversión a S/4HANA como lo que en apariencia es: una actualización de versión, aprobada con el mismo lenguaje con el que se aprueba un parche de seguridad o una migración de servidor. El directorio firmó pensando en continuidad: el sistema sigue, solo que más rápido y más moderno.
El arquitecto que va a ejecutar la conversión sabe algo distinto. Sabe que lo que se comunicó “hacia arriba” y lo que técnicamente va a suceder “hacia adentro” del sistema son dos cosas diferentes. Esa brecha —entre la expectativa ejecutiva y el alcance real de la conversión— es el problema central de esta serie.
Por qué esto pesa más en una utility u O&G latinoamericana con IS-U a medida
Un ERP genérico con desarrollos modestos puede absorber ese cambio de modelo de datos con relativamente poco drama. Una utility o una operadora de O&G en la región casi nunca está en ese escenario. IS-U, en particular, suele acumular años de ajustes específicos: lógica de facturación adaptada a tarifarios locales, interfaces a sistemas de medición, reportes regulatorios construidos sobre estructuras propias de ECC. Cada uno de esos desarrollos es un punto donde el nuevo modelo de datos puede generar inconsistencias funcionales o pérdida de rendimiento si no se remedia antes de la conversión (TotalTek, 2026).
Aquí es donde la brecha de expectativa se vuelve costosa. Si el comité entendió “upgrade técnico”, el presupuesto y el cronograma que aprobó fueron los de un upgrade técnico: ventana corta, impacto funcional mínimo, casi sin fricción para el negocio. Si lo que en realidad se ejecuta es un rediseño del modelo de datos subyacente —lo que en la práctica funciona como un reset arquitectónico del sistema, no como una simple actualización—, el trabajo de remediación de código a medida, pruebas funcionales y validación regulatoria es de otro orden de magnitud. Y el proyecto lo va a mostrar tarde: durante la ejecución, no en la sala de juntas.
El costo de gobernar esto como si fuera solo un tema de TI
El error de gobierno ejecutivo no es técnico: es de comunicación y de alcance. Cuando la conversión se presenta al directorio como un tema exclusivamente de TI —“actualizamos la plataforma”— se pierde la oportunidad de dimensionar correctamente lo que realmente hay que remediar: código a medida, integraciones de medición, reportes regulatorios, y la profundidad de la personalización de IS-U que la operación acumuló durante años sobre ECC.
Gobernar bien esta conversión no significa frenarla ni convertirla en un proyecto interminable. Significa que quien presenta el caso de negocio al comité use el lenguaje correcto desde el inicio: no “actualización”, sino “conversión de modelo de datos con impacto directo en el código a medida de IS-U”. Esa sola corrección de vocabulario cambia el presupuesto, el cronograma y las expectativas de continuidad operativa que el directorio va a exigir después.
Lo que viene
Esta primera pieza instala el problema: la brecha entre lo que se aprobó y lo que técnicamente se va a construir. La siguiente entrega de la serie entra al detalle de qué cambia de raíz en el modelo de datos —el modelo simplificado, HANA in-memory y el rol de las vistas CDS frente a las tablas tradicionales— para que el gobierno ejecutivo de la conversión tenga, pieza por pieza, el mapa completo de lo que realmente está en juego.
Fuentes
- TotalTek, 2026. SAP ABAP Custom Code Remediation: Preparing for S/4HANA Compatibility. https://blog.totaltek.com/sap-abap-custom-code-remediation-preparing-for-s/4hana-compatibility
- SAP SE. Estrategia oficial de mantenimiento para SAP Business Suite 7 / SAP ERP 6.0 (fin de mantenimiento mainstream 31 de diciembre de 2027). https://support.sap.com/en/offerings-programs/strategy.html
¿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.
