Sizing, Early Watch Alert y el impacto del gobierno de datos en el TCO del contrato RISE with SAP para utilities

Esta es la sexta y última pieza de la secuencia de AGT sobre Archiving y Huella HANA en utilities. El recorrido completo mostró, en orden, por qué crece el dato en utilities y cómo se clasifica por temperatura, qué hacer con los históricos del sistema legado al migrar, qué prerequisitos técnicos y de licenciamiento deben resolverse antes de construir, cómo se configuran los destinos de reubicación de datos durante la construcción, y cómo se mueven realmente los datos entre particiones mediante el Data Aging Run. Esta pieza cierra el ciclo mostrando cómo esa configuración se sostiene —o se erosiona— después del go-live, y cómo se conecta, mes a mes, con el TCO del contrato RISE with SAP.

Fundamento conceptual

El potencial de reducción de la huella de memoria de HANA mediante Data Aging se estima con el reporte de sizing disponible en la Nota SAP 1872170 (reporte de sizing para Business Suite on HANA y S/4HANA) [1]. Como la visibilidad del dato envejecido cambia una vez aplicado el aging, es necesario validar que el tiempo de residencia usado en esa estimación sea aceptable para los procesos de negocio. Para sostener esta disciplina en el tiempo, existe además un capítulo de Data Aging dentro del Early Watch Alert (EWA) que muestra el estado de activación y la proporción entre dato actual (caliente) e histórico (frío) — un indicador directo de en qué medida la organización está efectivamente aplicando Data Aging en la práctica, más allá de haberlo configurado [2].

Una vez activadas y programadas las reglas de reubicación de datos, el mecanismo de validación varía según el framework: en aplicaciones nativas de HANA, el Data Lifecycle Manager permite simular y confirmar cuántos registros se moverán antes de cada ejecución; para los objetos de negocio S/4HANA descritos en la pieza 4 de esta secuencia (NSE para tibio, SAP ILM vía SARA para frío), el equivalente es el modo de prueba (test run) de SARA, que confirma qué se archivaría sin ejecutar el movimiento real. Este ciclo de simulación, validación, guardado y activación de reglas, seguido de la programación efectiva de jobs de movimiento de datos, es lo que sostiene en el tiempo el dimensionamiento tanto del servidor de base de datos como de la infraestructura de aplicación asociada — evitando que ambos crezcan de forma no gobernada a medida que el volumen transaccional aumenta.

Un punto que vale aclarar para panoramas sin Solution Manager, cada vez más comunes bajo contratos RISE with SAP: el EWA no depende de tener Solution Manager instalado. El propio sistema ABAP/S/4HANA puede transmitir sus datos de servicio directamente a SAP [3], y SAP confirma oficialmente que clientes con un panorama estándar que no requieren la funcionalidad completa de ALM/ITSM de Solution Manager pueden cubrir sus necesidades básicas mediante sincronización directa de datos de landscape y de EarlyWatch Alert [4]. Más aún: el EWA está disponible e integrado directamente dentro de SAP Cloud ALM [5] — la misma plataforma que, como se señaló en la pieza 4 de esta secuencia, está absorbiendo también el análisis de Data Volume Management. Esto confirma una tendencia clara: Cloud ALM se está consolidando como el punto único de gobierno técnico, incluyendo tanto el monitoreo de memoria HANA (vía EWA) como la planificación de crecimiento de datos (vía el RISE with SAP Methodology Dashboard).

Aplicación práctica

El EarlyWatch Alert no es un reporte puntual: es un servicio automático, incluido sin costo adicional dentro del acuerdo de mantenimiento, que analiza semanalmente las áreas administrativas esenciales de un sistema SAP, tanto on-premise como en la nube [4]. Dentro de él, dos capacidades son directamente relevantes para sostener el gobierno de la huella HANA después del go-live: el pronóstico de consumo de memoria principal, que proyecta hasta 12 meses (extendible a 48) el comportamiento del column store y el row store con base en el historial real del sistema, y el pronóstico de footprint de datos, que ayuda a identificar cuándo el conjunto de tablas column-store y row-store se acerca al límite de asignación global de memoria [6]. El sistema de notificaciones del EWA, además, alerta activamente cuando la memoria crece significativamente más rápido de lo habitual, o cuando se alcanza un nuevo nivel de criticidad respecto al límite efectivo de asignación —clasificado en ventanas de 3 a 6 meses, de 1 semana a 3 meses, o límite ya alcanzado [7].

Para una utility, esto se traduce en un mecanismo de vigilancia concreto sobre exactamente lo que esta secuencia fue construyendo: cada ciclo de facturación agrega documentos FI-CA, lecturas de medidor y datos de intervalo de medición inteligente al volumen caliente del sistema; el Data Aging Run configurado en la pieza 5 de esta secuencia mueve a partición fría lo que ya cumplió su tiempo de residencia; y el EWA, revisado con una cadencia recomendada de una vez por mes como mínimo para trabajar la lista de alertas —además de atender notificaciones puntuales de forma inmediata—, es la herramienta que confirma si ese equilibrio entre crecimiento y aging efectivamente se sostiene, o si el crecimiento está superando la capacidad de la disciplina de archivado configurada [8]. Con el EWA cada vez más integrado a Cloud ALM, y el análisis de crecimiento de datos migrando hacia el mismo lugar, una utility que gobierna su huella HANA desde un panorama sin Solution Manager tiene, hoy, un único punto de partida natural para esta vigilancia: Cloud ALM, en lugar de dos herramientas separadas.

Hay un factor adicional, específico de utilities, que conviene tener presente al definir cuánto tiempo debe permanecer accesible el histórico de facturación y consumo, más allá de lo que Data Aging o el archivado clásico resuelvan técnicamente: los plazos regulatorios y de reclamo tarifario propios del sector. En Brasil, por ejemplo, la ANEEL exige que las distribuidoras mantengan los registros de atención comercial por un mínimo de 5 años para su propio uso regulatorio [9], y el ciclo de revisión tarifaria periódica se produce cada 4 o 5 años según el contrato de concesión —lo que implica que el histórico de facturación de ese período completo pueda ser requerido durante una revisión. En Perú, el Código Civil (artículo 1274) establece un plazo de 5 años para la acción de recuperar montos indebidamente pagados, criterio que la Junta de Apelaciones de Reclamos de Usuarios de OSINERGMIN aplicó de forma uniforme entre 2002 y 2006 para reclamos de facturación eléctrica [10], aunque la vía administrativa actual ante OSINERGMIN maneja una ventana de 3 años para el reintegro de montos cancelados [11]. En otros mercados de la región, los ciclos de revisión tarifaria periódica —también del orden de 4 a 5 años— generan una presión equivalente, aunque sin un mandato explícito y verificado de retención de datos en la misma medida que Brasil o Perú.

La implicancia para el diseño de tiering es directa: el objetivo de reducir memoria contratada bajo RISE with SAP no puede resolverse de forma que el dato quede inaccesible antes de que venza el plazo regulatorio o de reclamo aplicable en cada país donde opera la utility. Esta es exactamente la distinción entre Data Aging/NSE (que reducen memoria pero mantienen el dato accesible dentro de HANA) y el archivado clásico o la destrucción vía ILM (que retiran el dato de la base de datos, pero deben respetar el período de retención regulatorio antes de ejecutar la destrucción) que se estableció en la pieza 2 de esta secuencia: confundir “reducir memoria” con “ya no necesito este dato” es un error que puede exponer a la utility ante un reclamo tarifario o una auditoría del regulador años después del go-live.

Una práctica recomendada dentro del propio EWA es comparar, cada pocos meses, las tablas con mayor consumo de memoria contra su estado anterior, para identificar si existe potencial de ahorro adicional vía archivado, borrado o Native Storage Extension que todavía no se está aprovechando — es decir, el mismo ejercicio de clasificación por temperatura de la primera pieza de esta secuencia, pero repetido de forma recurrente, no una sola vez al inicio del proyecto.

Aquí es donde se cierra el círculo completo con el contrato RISE with SAP descrito en la pieza 3: si el pronóstico de memoria del EWA muestra una tendencia de crecimiento acelerado, y las reconciliaciones periódicas de consumo de FUE contra lo contratado confirman ese mismo crecimiento, la organización tiene dos caminos —reforzar la disciplina de archivado y tiering ya configurada, o presupuestar la compra de bloques adicionales de memoria—. Ambos caminos son legítimos, pero solo uno de ellos es una decisión informada: la que se toma con el pronóstico del EWA en la mano, con meses de anticipación, en lugar de descubrir la necesidad de más memoria recién en la reconciliación formal del proveedor.

Mejores prácticas y consideraciones

• Revisar el capítulo de Data Aging del EWA con la misma disciplina que cualquier otro KPI crítico del sistema. No es un reporte decorativo: es la evidencia concreta de si la clasificación por temperatura definida en el proyecto sigue aplicándose en operación, o si se fue perdiendo con el tiempo.
• Establecer una cadencia mensual de revisión del EWA, con atención inmediata a las notificaciones de crecimiento acelerado. Esperar a la reconciliación anual de FUE del contrato RISE para reaccionar al crecimiento es, por definición, actuar tarde.
• No depender de Solution Manager para sostener esta vigilancia. El EWA se transmite directamente a SAP y se consume, cada vez más, desde Cloud ALM — una utility que migra a RISE with SAP sin Solution Manager no pierde esta capacidad, solo cambia dónde la consulta.
• Usar el pronóstico de footprint de datos del EWA como insumo directo para decidir entre reforzar el archivado o presupuestar memoria adicional. Esta decisión de negocio debe tomarse con datos de tendencia, no como reacción a una factura de reconciliación.
• Verificar los plazos regulatorios y de reclamo tarifario de cada país donde opera la utility antes de fijar tiempos de retención o destrucción. Reducir memoria no equivale a poder destruir el dato: la ventana de reclamo o revisión tarifaria de cada mercado —confirmada, no asumida— debe quedar cubierta por el archivado clásico o la disponibilidad vía ILM.
• Repetir periódicamente el ejercicio de clasificación por temperatura de la primera pieza de esta secuencia, no darlo por resuelto una sola vez.
• Anti-patrón de cierre de toda la secuencia: tratar el go-live como el final del trabajo de gobierno de datos, o asumir que sin Solution Manager se pierde visibilidad sobre la huella HANA. Ninguna de las dos cosas es cierta: el gobierno de datos se sostiene con o sin Solution Manager, y hoy converge cada vez más en Cloud ALM. El TCO de un contrato RISE with SAP para una utility no se decide en el proyecto: se decide en si esta disciplina de sizing, monitoreo y ejecución periódica de Data Aging se mantiene viva después de que el proyecto terminó y el equipo se disolvió.

Referencias

1. SAP Note 1872170 – ABAP on HANA Sizing Report (S/4HANA, Suite on HANA…)
2. How to include Data Aging statistics into the Early Watch Alert (EWA)? - Proceed Group — https://www.proceedgroup.com/faqs/how-to-include-data-aging-statistics-into-the-early-watch-alert-ewa
3. Using the SAP EarlyWatch Alert Status App - SAP Community — https://community.sap.com/t5/technology-blog-posts-by-sap/using-the-sap-earlywatch-alert-status-app/ba-p/14212519
4. SAP EarlyWatch Alert (página oficial de servicio) — https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html
5. SAP KBA 3391480 - EarlyWatch Alert availability in SAP Cloud ALM
6. Memory Forecast for SAP HANA with SAP EarlyWatch Alert Workspace — https://blogs.sap.com/2019/10/01/memory-forecast-for-sap-hana-with-sap-earlywatch-alert-workspace/
7. SAP EarlyWatch Alert: Notifications for SAP HANA Memory - SAP Community — https://community.sap.com/t5/technology-blog-posts-by-sap/sap-earlywatch-alert-notifications-for-sap-hana-memory/ba-p/13491825
8. Best Practice - SAP EarlyWatch Alert - SAP Community — https://community.sap.com/t5/technology-blog-posts-by-sap/best-practice-sap-earlywatch-alert/ba-p/13560822
9. Resolução Normativa ANEEL nº 414/2010 — https://www2.aneel.gov.br/cedoc/ren2010414.html
10. Código Civil del Perú, artículo 1274 (aplicación por JARU/OSINERGMIN 2002-2006) — https://revistas.indecopi.gob.pe/index.php/rcpi/article/download/80/78/196
11. OSINERGMIN — ¿Cómo presentar un reclamo? — https://www.osinergmin.gob.pe/Paginas/Folletos/folletos/como-presentar-reclamo.html