S/4HANA: por qué el modelo de datos es un reset, no un upgrade
Segunda entrega de la serie: los tres cambios estructurales del modelo de datos en S/4HANA que redefinen el alcance real de una conversión ECC en utilities y O&G LATAM.
· 7 min de lectura
El código heredado que “sigue funcionando” es la señal equivocada
Un desarrollo custom de IS-U que compiló sin errores después de la conversión no es evidencia de que el modelo de datos no cambió. Es evidencia de que SAP construyó un puente para que ese código siguiera funcionando mientras el modelo real ya cambió por debajo. Ese matiz —entre “sigue corriendo” y “sigue siendo la fuente de verdad”— es el que determina si el alcance de una conversión ECC → S/4HANA para una utility u operadora de oil & gas en LATAM está bien dimensionado o si va a mostrar sorpresas más adelante.
Esta pieza se detiene ahí: en el puente, no en el destino. Y en los otros dos cambios que explican por qué ese puente existe y por qué es temporal.
Por qué las vistas de compatibilidad son un puente, no un destino
Buena parte de las tablas de agregación e índice que sostenían reportes de facturación, interfaces de lecturas y extensiones propias de IS-U no desaparecieron de un día para otro tras la conversión. Quedaron emuladas por vistas de compatibilidad, pensadas para que las aplicaciones existentes —incluido el código a medida— no se rompieran de inmediato (SAP PRESS, 2020, act. 2025). Esas vistas son exactamente eso: una capa de transición, no el modelo destino. El desarrollo propio construido durante años sobre el modelo ECC fue diseñado asumiendo tablas que hoy ya no son la fuente de verdad; simplemente no lo nota todavía porque la vista de compatibilidad absorbe la diferencia.
Para el gobierno del proyecto, esto cambia la pregunta que hay que hacerse. No es “¿el código sigue funcionando después de la conversión?” —esa pregunta la responde la vista de compatibilidad, casi siempre que sí—. La pregunta correcta es cuáles de esas vistas seguirán existiendo a mediano plazo y cuáles fueron pensadas como puente temporal que en algún momento SAP deja de sostener. SAP documenta esto en su lista de simplificación, pero traducirla en decisiones concretas para un IS-U customizado de una utility LATAM es trabajo de arquitectura y de gobierno, no un checklist que se resuelve solo.
La causa de fondo: las tablas de agregación dejan de ser necesarias
La razón por la que existen tablas para reemplazar es técnica y anterior a S/4HANA: las bases de datos tradicionales no podían calcular agregaciones al vuelo, así que el sistema pre-calculaba y duplicaba esa información en tablas de agregación e índices, actualizadas constantemente en segundo plano. S/4HANA elimina esa necesidad de origen: el dato se organiza en column store y se agrega en el momento en que se consulta, sin depender de las tablas auxiliares que sostenían ese cálculo en el modelo anterior (Absoft, 2025). Las vistas de compatibilidad descritas arriba existen precisamente para tapar esa ausencia mientras el ecosistema de código custom se pone al día.
El motor detrás: cálculo en memoria en lugar de agregados nocturnos
Lo que habilita ese cambio de fondo es dónde y cuándo se calcula el dato. Al mover el procesamiento a una base de datos in-memory, SAP desplaza el cálculo desde la capa de aplicación (ABAP) hacia la capa de base de datos, evaluando cifras clave en tiempo real en lugar de leer un valor ya agregado por un job nocturno. La literatura técnica describe este movimiento como el paso de un modelo donde los datos se pre-agregaban y duplicaban para sostener el rendimiento, a uno donde el cálculo ocurre bajo demanda, reduciendo la huella de datos y el número de tablas interdependientes (SAP PRESS, 2025).
Para una utility con IS-U customizado, esto tiene una consecuencia operativa directa: procesos de conciliación de medición a facturación (M2C) que hoy corren en ventanas batch nocturnas pasan a poder evaluarse en tiempo real — pero solo si el desarrollo propio fue re-pensado para ese modelo, y no simplemente dejado detrás de una vista de compatibilidad que algún día deja de existir.
Gobierno ejecutivo: la pregunta que hay que hacer antes de firmar el alcance
Un caso de negocio que se limita a preguntar si el código custom seguirá “funcionando” después de la conversión se queda corto: casi siempre la respuesta es sí, gracias a las vistas de compatibilidad. La pregunta que sí debería figurar en el alcance aprobado es cuánto tiempo de vida útil tiene cada uno de esos puentes, y qué desarrollos propios —facturación masiva, interfaces de lectura, reportes regulatorios— necesitan reescribirse contra el modelo nuevo antes de que la vista de compatibilidad correspondiente deje de estar disponible.
Nombrar esto correctamente —no como una migración de infraestructura, sino como un reset del modelo de datos con puentes temporales— es lo que separa un cronograma realista de uno que se entera tarde de su propio alcance. La pieza siguiente de esta serie entra en el segundo efecto de ese reset: por qué el modelo mental equivocado no se destapa en el go-live, sino en la fase de integración — mucho antes, y con mucho menos margen de reacción del que suele preverse.
Fuentes
- Absoft. (2025). SAP ABAP CDS Views: All You Need to Know. https://www.absoft.co.uk/abap-cds-views-all-you-need-to-know/
- SAP PRESS. (2025). SAP ECC vs. SAP S/4HANA: Technical Foundations. https://blog.sap-press.com/sap-ecc-vs-sap-s4hana-technical-foundations
- SAP PRESS. (2020, actualizado 2025). What Is the New Data Model for SAP S/4HANA? https://blog.sap-press.com/what-is-the-new-data-model-for-sap-s4hana
¿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.
