Prerequisitos y licenciamiento de Data Aging antes de construir en proyectos de utilities SAP S/4HANA

Esta es la tercera pieza de la secuencia de 6 guías técnicas de AGT sobre Archiving y Huella HANA en utilities, y cierra el bloque “antes del proyecto”. Las piezas anteriores establecieron por qué el flujo Meter-to-Cash genera un volumen de datos estructural y recurrente, y cómo decidir qué hacer con los históricos del sistema legado al migrar. Esta pieza resuelve los prerequisitos técnicos y de licenciamiento que deben quedar activos antes de iniciar la construcción — y muestra, con datos concretos del mecanismo de contratación RISE, por qué este paso no es un trámite administrativo sino la bisagra que determina cuánto va a costar el crecimiento mensual del sistema. La siguiente pieza de la secuencia abre el bloque “durante el proyecto” mostrando cómo estos prerequisitos se traducen en configuración concreta durante la construcción.

Fundamento conceptual

Para aplicar Data Aging se requieren ciertos prerequisitos del lado ABAP: la aplicación SAP debe proveer objetos de Data Aging, el parámetro de perfil abap/data_aging debe estar activado, la función de negocio de Data Aging (DAAG_DATA_AGING) debe estar encendida, y deben existir las autorizaciones correspondientes. Data Aging no es un producto con licencia adicional: el framework está disponible junto con SAP NetWeaver desde la versión 7.40 SP05 en adelante. Para que una tabla participe en Data Aging, debe formar parte de uno o varios objetos de Data Aging y de un objeto de partición, además de contar con la columna adicional _DATAAGING, que es la base del particionamiento por selección de tiempo [1].

Esto significa que activar Data Aging no depende de una decisión comercial de licenciamiento — es una decisión puramente técnica de configuración. Pero esa misma característica es la que hace que su ausencia sea tan costosa cuando no se resuelve a tiempo: no hay una barrera de licencia que obligue a discutirlo en el proyecto, así que es fácil que quede fuera del alcance si nadie lo exige explícitamente antes de construir.

Aplicación práctica

Acá es donde este prerequisito deja de ser un detalle técnico y empieza a pesar directamente sobre el contrato RISE with SAP. El mecanismo es concreto y verificable:

El sizing inicial del contrato se calcula con una herramienta específica, el reporte de sizing SAP HANA (/SDF/HDB_SIZING, documentado en la Nota SAP 1872170), que analiza el tamaño actual de la base de datos, los factores de compresión y los volúmenes de transacción del sistema para estimar la memoria HANA requerida [2]. La práctica recomendada explícitamente por la comunidad SAP es archivar y limpiar los datos innecesarios antes de correr este reporte de sizing, precisamente para optimizar el resultado [2]. Si los prerequisitos de Data Aging no están activos en ese momento —porque nadie los configuró antes del sizing—, el reporte calcula la memoria requerida sobre un volumen de datos que ya incluye todo el histórico sin clasificar, incluyendo el crecimiento acumulado del flujo Meter-to-Cash desde el día uno de la operación. El contrato que se firma, entonces, parte de un punto más alto del que hubiera sido posible.

El contrato RISE se estructura en tamaños de “camiseta” (T-shirt sizing) que fijan un volumen de memoria HANA estándar para los ambientes de desarrollo, QA y producción — por ejemplo, un cliente con un volumen de Full User Equivalents (FUE) de aproximadamente 6.001 recibe una asignación XXL que incluye hasta 6.144 GB de RAM de HANA DB para QA y producción [3]. Si el volumen de datos crece más allá de esa asignación estándar —como ocurre mes a mes con cada ciclo de facturación que suma documentos FI-CA, cada lote de lecturas de medidor, y cada acumulación de datos de intervalo de medición inteligente—, la única vía es contratar memoria adicional en bloques de 256 GB a través de la línea de extensión de memoria para los niveles productivos [3]. Es decir: el crecimiento mensual no gestionado del flujo Meter-to-Cash no se absorbe dentro del contrato original — se convierte en compras adicionales, bloque por bloque, cada vez que se supera el umbral asignado.

Este mecanismo no es estático ni se descubre solo al final del contrato: los proveedores realizan reconciliaciones periódicas (trimestrales o anuales) que comparan el consumo real de FUE contra lo contratado, y el consumo excedido obliga a comprar unidades adicionales [4]. Monitorear el uso real de memoria HANA contra la cantidad licenciada de forma continua —no solo esperar a la renovación del contrato— es lo que permite a una organización actuar (limpiar datos o presupuestar más licencia) antes de que la situación se vuelva urgente [5].

Para una utility LATAM, esto se traduce en un cálculo simple pero contundente: si los prerequisitos de Data Aging no están activos antes del sizing inicial, y si el monitoreo de memoria contra lo contratado no es una práctica continua después del go-live, el crecimiento estructural del ciclo Meter-to-Cash —documentos FI-CA por cada cliente en cada ciclo de facturación, lecturas de medidor, datos de intervalo de medición inteligente— se traduce mes a mes en más bloques de memoria adicional contratados, sin que exista un techo natural a ese crecimiento salvo el presupuesto disponible.

Mejores prácticas y consideraciones

• Verificar los cuatro prerequisitos de Data Aging (parámetro de perfil, función de negocio, objetos de Data Aging disponibles, autorizaciones) antes de correr el reporte de sizing, no después. El orden importa: el sizing que define el contrato RISE debe calcularse sobre un sistema donde Data Aging ya puede activarse, no sobre un volumen de datos sin clasificar.
• Tratar el archivado y la limpieza de datos como un paso obligatorio previo al sizing, no como una optimización posterior. Esta es una recomendación explícita de la práctica de sizing para SAP Cloud ERP Private: archivar antes de medir, no medir y archivar después [2].
• No asumir que el T-shirt size contratado absorbe automáticamente el crecimiento del flujo Meter-to-Cash. El volumen de memoria estándar de cada tamaño de contrato es fijo; el crecimiento mensual estructural de una utility —a diferencia de negocios con transacciones más esporádicas— tiende a consumir ese margen más rápido de lo esperado si no hay disciplina de archivado desde el arranque.
• Establecer monitoreo continuo de memoria HANA contra lo contratado, no solo en la renovación. Detectar la tendencia de crecimiento mes a mes permite decidir con anticipación si conviene reforzar el archivado, o presupuestar la compra de bloques adicionales de forma planificada, en lugar de reaccionar a una reconciliación con el proveedor.
• Anti-patrón a evitar: dejar la activación de Data Aging para “cuando haga falta”. Como no requiere licencia adicional, no hay una señal comercial que fuerce la conversación — y esa ausencia de fricción es exactamente lo que hace que el prerequisito quede fuera de alcance si nadie lo exige explícitamente en la fase de planificación.

Con estos prerequisitos resueltos, la siguiente pieza de la secuencia abre el bloque “durante el proyecto” mostrando cómo se configuran, en la práctica, los destinos de reubicación de datos que estos prerequisitos habilitan.

Referencias

1. Data Aging in SAP S/4HANA
2. Sizing Your Success: A Guide to SAP Cloud ERP Private - SAP Community — https://community.sap.com/t5/technology-blog-posts-by-sap/sizing-your-success-a-guide-to-sap-cloud-erp-private/ba-p/14222599
3. RISE with SAP: Summary of public information available - SAP Community — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-members/rise-with-sap-summary-of-public-information-available-part1/ba-p/13558516
4. SAP RISE Negotiations Guide - Redress Compliance — https://redresscompliance.com/sap-rise-negotiations-a-guide-for-cio-and-procurement.html
5. SAP Hana Memory-Based Licensing and Sizing — https://saplicensingexperts.com/sap-hana-memory-based-licensing-and-sizing/