Históricos del sistema legado en utilities: decidir qué se archiva y qué se mantiene accesible vía Data Aging al migrar a SAP S/4HANA

Esta es la segunda pieza de la secuencia de 6 guías técnicas de AGT sobre Archiving y Huella HANA en utilities. La pieza anterior estableció por qué el flujo Meter-to-Cash genera un volumen de datos estructural en utilities y cómo se clasifica ese dato por temperatura (hot/warm/cold). Esta pieza aplica esa clasificación a una pregunta muy concreta que toda utility enfrenta al migrar a SAP S/4HANA: qué hacer con los históricos del sistema legado. La siguiente pieza de la secuencia cerrará el bloque “antes del proyecto” resolviendo los prerequisitos técnicos y de licenciamiento que deben quedar listos antes de iniciar la construcción, una vez decidido qué se archiva y qué se mantiene accesible.

Fundamento conceptual

Data Aging no es lo mismo que archiving clásico, y esta distinción es la base de todo lo que sigue. En Data Aging, el dato frío permanece dentro de la propia base de datos HANA y sigue siendo accesible vía SQL en la misma tabla que el dato caliente, aunque en otra partición. El dato archivado, en cambio, es estrictamente de solo lectura: se escribe en un archivo y se elimina de la base de datos, requiriendo rutas de acceso adicionales —información de dirección o índices de archivo— para poder leerlo nuevamente. Data Aging apunta a reducir la huella de memoria principal, mientras que el archiving es la base de ILM (Information Lifecycle Management), que cubre el ciclo de vida completo del dato hasta su destrucción definitiva [1].

Esta distinción es central al migrar un sistema legado: los datos que deben seguir accesibles en línea —porque el negocio los consulta con cierta frecuencia, aunque sea baja— son candidatos a Data Aging. Los datos que ya cumplieron su ciclo de vida operativo y regulatorio, y que solo se conservan por obligación de auditoría, son candidatos a archiving y, eventualmente, a destrucción vía ILM [1].

ILM introduce, además, dos conceptos que conviene distinguir con precisión: el período de residencia (cuánto tiempo debe permanecer un dato activo en el sistema productivo antes de poder archivarse) y el período de retención (cuánto tiempo debe conservarse ese dato ya archivado antes de poder destruirlo). Automatizar estas reglas mediante políticas es lo que permite a una organización mantener estándares de gobierno consistentes mientras reduce la supervisión manual — pero también significa que retener datos más tiempo del necesario incrementa tanto el costo como el riesgo de cumplimiento, tanto como destruirlos antes de tiempo genera exposición legal [2].

Aplicación práctica

En una utility LATAM que migra de un sistema legado —sea SAP ECC/IS-U u otro CIS— a SAP S/4HANA, esta distinción entre Data Aging y archiving se traduce en decisiones concretas sobre tres tipos de históricos:

Documentos financieros de FI-CA (facturación, pagos, morosidad) suelen tener un período de retención regulatorio ligado a la fecha de compensación del documento, no a su fecha de creación, en muchas configuraciones de archivado FI observadas en la práctica — un matiz que suele generar confusión al definir las reglas de archivado, porque agrupar documentos por año fiscal de compensación no es lo mismo que agruparlos por año de posteo [3]. Para utilities LATAM sujetas a auditoría tributaria o regulatoria, definir esta regla correctamente desde el principio evita descubrir, años después, que el archivo agrupó documentos de forma que complica su recuperación ante un requerimiento de la autoridad.

Datos maestros de clientes y contratos de servicio rara vez pueden bloquearse o destruirse mientras el cliente mantenga alguna relación comercial activa con la utility, incluso si esa relación es intermitente — un patrón habitual en utilities, donde un cliente puede reconectar el servicio después de un período de baja. La regla de “fin de propósito” (End of Purpose) para estos datos no se cumple automáticamente por el simple paso del tiempo, y bloquear datos maestros con negocio activo, aunque sea histórico, genera errores de proceso, no ganancias de footprint.

Datos de lectura de medidor y de intervalo de medición inteligente son, en cambio, los candidatos más claros para Data Aging antes que para archiving puro: se consultan con baja frecuencia después de facturados, pero siguen teniendo valor analítico (perfiles de consumo, detección de pérdidas no técnicas, disputas de facturación) que hace preferible mantenerlos accesibles en línea en frío, en lugar de archivarlos de forma que requiera un proceso de recuperación manual para cada consulta.

La decisión entre conversión brownfield (mantener el sistema y llevar el histórico) o un enfoque greenfield (extraer el histórico del sistema legado hacia un almacén de retención separado y arrancar limpio) tiene un impacto directo en cuánto de este histórico termina pesando sobre la huella HANA del nuevo sistema: en un enfoque brownfield bien ejecutado, se archiva primero el histórico ya completo desde el negocio, se migra el conjunto de datos activo, y luego se reconectan los archivos para que sigan siendo consultables desde S/4HANA — reduciendo el riesgo de la migración sin perder acceso a la información [4]. Casos documentados de esta práctica en el sector de utilities muestran reducciones de base de datos del orden del 80%, con ahorros de costo del orden del millón de dólares y una migración más rápida hacia contratos RISE with SAP [2] — una referencia útil de la magnitud de impacto que puede tener esta decisión, sin que corresponda a un caso LATAM específico.

Mejores prácticas y consideraciones

• Clasificar los históricos del legado en tres categorías, no dos. No es solo “se archiva o no se archiva”: hay datos que deben archivarse y destruirse por regla de retención cumplida, datos que deben archivarse pero permanecer accesibles indefinidamente por continuidad de negocio, y datos que deben quedarse en Data Aging porque su consulta, aunque poco frecuente, sigue siendo operativa.
• Definir la regla de retención junto con legal y auditoría antes de tocar un solo objeto de archivado. La regla de oro es archivar solo lo que está “completo desde el punto de vista del negocio”, respetar el orden de dependencias entre objetos, y acordar la retención con las áreas de legal y auditoría desde el inicio del proyecto — no como un ajuste posterior [4].
• No confundir archiving con destrucción. Archivar mueve el dato fuera de la base de datos productiva, pero lo mantiene disponible para lectura; destruir lo elimina de forma permanente y solo debe ejecutarse cuando el período de retención efectivamente venció. Ejecutar destrucción antes de tiempo por apuro de reducir footprint es un riesgo de cumplimiento, no una optimización.
• Anti-patrón a evitar: migrar todo el histórico “por las dudas”. En un proyecto de utilities con presión de cronograma, la tentación de migrar el histórico completo sin clasificarlo primero es alta — pero esa decisión, tomada por evitar el trabajo de clasificación, es la que después se refleja en un sizing HANA más costoso del necesario.
• Tratar los datos maestros de clientes con especial cuidado. A diferencia de los documentos transaccionales, los datos maestros de clientes y contratos de servicio no siguen una regla de retención simple basada en fecha: dependen de si la relación comercial sigue activa, y bloquear estos datos prematuramente genera errores operativos más costosos que el ahorro de footprint que se buscaba.

Con esta clasificación de históricos resuelta, la siguiente pieza de la secuencia cierra el bloque “antes del proyecto” revisando los prerequisitos técnicos y de licenciamiento que deben quedar activos antes de iniciar la construcción.

Referencias

1. Data Aging in SAP S/4HANA
2. SAP ILM Data Archiving & Retention Management - Auritas — https://www.auritas.com/data-archiving/sap-ilm-data-archiving-retention-management/
3. Data archiving - FI documents retention period - SAP Community — https://answers.sap.com/questions/5599501/data-archiving---fi-documents-retention-period-nee.html
4. A guide to SAP data archiving - Proceed Group — https://proceedgroup.com/sap-data-archiving/sap-data-archiving-guide