Por qué crece el dato en utilities: clasificación de temperatura y el flujo Meter-to-Cash como motor de volumen en SAP S/4HANA

Esta es la primera pieza de una secuencia de 6 guías técnicas de AGT sobre Archiving y Huella HANA en utilities. Está dirigida a arquitectos de datos, líderes de TI y responsables de infraestructura en utilities de América Latina que necesitan entender, antes de dimensionar o firmar un contrato RISE with SAP, por qué el volumen de datos de una utility crece de forma tan particular. La siguiente pieza de la secuencia tomará esta clasificación de temperatura para resolver una pregunta concreta: qué hacer con los datos históricos del sistema legado al migrar.

Fundamento conceptual

El crecimiento de datos transaccionales en SAP S/4HANA es exponencial con el tiempo, y ese crecimiento presiona directamente sobre la memoria disponible de SAP HANA. Data Aging es un concepto de gestión de datos diseñado específicamente para reducir la huella de memoria de HANA, apoyado en un Data Aging Framework provisto por SAP NetWeaver ABAP. El concepto diferencia entre datos operacionalmente relevantes (calientes/actuales) y datos que ya no se acceden en la operación normal (fríos/históricos): los datos calientes residen en la memoria principal de HANA, mientras que los datos fríos permanecen almacenados primariamente en disco, pero siguen siendo accesibles vía SQL bajo demanda [1].

Este crecimiento acelerado de datos es, en el fondo, un desafío estructural para los departamentos de TI, que deben sostener entornos de procesamiento de datos a gran escala bajo restricciones presupuestarias que compiten con la necesidad de más infraestructura y personal. A medida que los datos envejecen, los usuarios acceden a ellos con menor frecuencia — no todos los datos tienen la misma importancia operativa en el tiempo. Por eso se clasifica la antigüedad de los datos por temperatura: datos calientes (acceso diario u horario), datos tibios (acceso mensual o anual) y datos fríos (conservados por motivos de registro o auditoría, con acceso excepcional) [2].

Esta clasificación por temperatura no es un ejercicio teórico: es la base técnica sobre la que se apoya cualquier estrategia de reducción de huella HANA, y determina qué datos deben seguir en memoria principal para no degradar el rendimiento operativo, y cuáles pueden moverse a un nivel de almacenamiento más económico sin perder accesibilidad.

Aplicación práctica

En ninguna industria esta clasificación por temperatura es tan crítica como en utilities, porque el flujo Meter-to-Cash (M2C) genera volumen de datos de forma estructural, no accidental. Tres fuentes concretas explican por qué:

Primero, el subledger de Contract Accounting (FI-CA) está diseñado explícitamente para procesar grandes volúmenes de documentos: es un componente de contabilidad de subledger desarrollado para industrias con una base de clientes grande y, en consecuencia, un volumen de documentos correspondientemente alto, como las utilities [3]. FI-CA maneja millones de cuentas de cliente y transacciones, procesando facturación, pagos y gestión de morosidad como actividades masivas que dividen automáticamente el conjunto de datos en múltiples trabajos paralelos [3]. Cada ciclo de facturación de cada cliente con contrato de servicio activo genera su propio lote de documentos de contabilización, pago y morosidad — y ese lote se repite, cliente por cliente, ciclo tras ciclo.

Segundo, las lecturas de medidor generan documentos propios, tanto en su modalidad periódica (por ciclo de facturación) como fuera de ciclo (lecturas interinas o de cierre). Cada orden de lectura de medidor y cada resultado de lectura es un objeto de datos adicional que se acumula en el sistema, independientemente de los documentos financieros que después genera la facturación.

Tercero, y de forma creciente, los datos de intervalo de medición inteligente. SAP S/4HANA Utilities incorpora Energy Data Management (EDM), que provee funciones para procesar datos de series de tiempo equidistantes — por ejemplo, valores cada 30 minutos — como lecturas equidistantes, valores de consumo, precios y factores de conversión, todos centralizados en un repositorio de datos de energía (Energy Data Repository) [4]. A diferencia de un documento financiero que se genera una vez por ciclo de facturación, un punto de suministro con medición inteligente genera un registro de intervalo cada 30 minutos o menos, de forma continua — es decir, decenas de miles de registros por punto de suministro al año, multiplicados por toda la base de medidores inteligentes desplegados.

La combinación de estas tres fuentes —documentos FI-CA por cliente, documentos de lectura de medidor, y datos de intervalo de medición inteligente— es lo que hace que la huella HANA de una utility crezca de forma distinta a la de una empresa de manufactura o de servicios profesionales: no es un crecimiento eventual ligado a transacciones de negocio esporádicas, sino un flujo recurrente y estructural, atado al tamaño de la base de clientes y a la frecuencia de facturación. De hecho, el propio roadmap de SAP para utilities incluye como ítem planificado el archivado de objetos de conexión, ubicaciones de dispositivos y dispositivos — un reconocimiento explícito, del lado del fabricante, de que este crecimiento de objetos de datos específicos de utilities necesita mecanismos de gobierno propios [5].

Para una utility LATAM que evalúa modernizar bajo un contrato RISE with SAP o SAP Cloud ERP Private, entender esta dinámica antes de dimensionar el contrato es determinante: el volumen que se factura al firmar no es el volumen final, sino el punto de partida de una curva de crecimiento que sigue el ritmo de facturación de la propia utility. En mercados regulados con presión sobre la recaudación y pérdidas no técnicas, además, la tentación de posponer decisiones de archivado para no interrumpir la continuidad operativa es alta — pero es justamente esa postergación la que después se refleja en un sizing más costoso del que hubiera sido posible con una clasificación de temperatura definida desde el principio.

Mejores prácticas y consideraciones

• Mapear las tres fuentes de volumen antes de dimensionar, no después. Documentos FI-CA, documentos de lectura de medidor y datos de intervalo de medición inteligente crecen a ritmos distintos y deben proyectarse por separado, no como una única cifra agregada de “crecimiento de datos”.
• No asumir que el volumen actual es representativo del volumen a 3-5 años. El despliegue progresivo de medición inteligente en una utility latinoamericana puede multiplicar varias veces el volumen de datos de intervalo respecto del parque de medidores convencionales actual.
• Anti-patrón a evitar: tratar el crecimiento de datos como un problema de infraestructura a resolver “cuando aparezca”. La clasificación por temperatura (hot/warm/cold) es una decisión de arquitectura, no un ajuste operativo tardío; postergarla no evita el crecimiento, solo pospone el costo de gestionarlo.
• Usar la clasificación de temperatura como lenguaje común entre negocio y TI. Distinguir explícitamente qué datos son “calientes” (necesarios para la operación diaria de facturación y atención al cliente) de los que son “tibios” o “fríos” (necesarios por auditoría o continuidad histórica) evita que decisiones técnicas de archivado se tomen sin el aval del área regulatoria o comercial.

Con esta clasificación de temperatura como base, la siguiente pieza de esta secuencia aborda una decisión más concreta: qué hacer con los datos históricos del sistema legado al migrar — cuáles deben archivarse de forma definitiva y cuáles deben permanecer accesibles vía Data Aging.

Referencias

1. Data Aging in SAP S/4HANA
2. Options for SAP HANA Data Tiering — SAP PRESS Blog — https://blog.sap-press.com/options-for-sap-hana-data-tiering
3. Contract Accounting | SAP Help Portal — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/9442486404b54071b4ebeab6a16628e7/59e8c5536a51204be10000000a174cb4.html
4. SAP S/4HANA Utilities | SAP Help Portal — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/021b182b0c47416c8fafed67ebfd78a9/266dce53118d4308e10000000a174cb4.html
5. SAP Utilities Roadmap 2026 Onwards - SAP Community — https://community.sap.com/t5/sap-for-utilities-blog-posts/sap-utilities-roadmap-2026-onwards/ba-p/14285848