El mercado habla de migración e IA. Sin embargo, el archiving SAP sigue siendo la palanca más barata para devolverle velocidad al sistema. Además, es una de las menos utilizadas. El motivo es simple: la gestión del volumen de datos no es glamorosa. Sin embargo, los números sí lo son. En los ambientes que analizamos, una fracción pequeña de las tablas concentra la mayor parte de la base. Además, buena parte de ese volumen es histórico que nadie consulta. Aun así, todos los meses cuesta memoria de HANA, backup y ventana de mantenimiento.

Por eso, en este artículo mostramos cómo funciona el archiving SAP en la práctica. Después, por qué vale aún más antes de una migración a S/4HANA. Por último, cómo lo hacemos en Inove, incluso con una herramienta propia de análisis.

El problema que crece en silencio

Todo SAP acumula datos: documentos de material, órdenes, facturas, registros de asistencia, logs de interfaz. Como resultado, año tras año ese volumen pasa la factura en cuatro frentes:

• Memoria de HANA. Antes que nada, la base en memoria es el recurso más caro del ambiente. Por lo tanto, el dato histórico que ocupa RAM es dinero detenido.
• Performance. Además, los reportes que recorren decenas de millones de registros se vuelven lentos. Es el caso, por ejemplo, de MB51, FBL3N y las consultas de facturación.
• Migración y upgrade. Del mismo modo, cada prueba de conversión a S/4HANA copia y procesa la base completa. Es decir: volumen alto = ventanas más largas, más costo y más riesgo.
• Backup y DR. Por último, la ventana de backup, el almacenamiento replicado y el tiempo de restore — todo crece junto con la base.

Por qué el archiving SAP viene antes de la migración

Si S/4HANA está en tu horizonte, entonces el orden importa: archivar antes de migrar. Cada gigabyte que sale de la base antes de la conversión es un gigabyte que no pagas por migrar. Ese ahorro aparece en tiempo de proyecto, en sizing de infraestructura y en licencia de HANA. En conversiones brownfield, por ejemplo, reducir el volumen acorta las ventanas de downtime. Además, disminuye el riesgo de desborde en el fin de semana del cutover. Ya detallamos esa relación en el artículo sobre la migración a SAP S/4HANA.

El archiving es parte de algo mayor: DVM (Data Volume Management)

Archivar documentos de negocio es la pieza más conocida. Sin embargo, la disciplina completa se llama DVM (Data Volume Management). Además, SAP la trata como un programa continuo, no como un proyecto puntual. En resumen, el DVM combina estos frentes:

• Prevención. Primero, evitar que el dato nazca: revisar logs de interfaz, parametrizaciones de grabación y housekeeping técnico. Tablas como BALDAT (logs de aplicación), DBTABLOG (log de tablas) y APQD (batch input) crecen solas. Lo mismo ocurre con TST03 (spool) y las SWW* (workflow). Sin embargo, casi nunca necesitan todo eso.
• Anexos y contenido. Luego, la SOFFCONT1 guarda anexos (GOS/SAP Office) dentro de la base — un clásico: gigabytes de PDF e imágenes ocupando HANA/Oracle. Por lo tanto, la solución es sacar el contenido de la base y mantener solo el vínculo en SAP. En un cliente del sector retail, por ejemplo, diseñamos exactamente eso con arquitectura de nube moderna. Se trata de la migración de los anexos a Google Cloud Storage usando el ABAP SDK for Google Cloud. Así, SAP escribe y lee directo en el bucket, con costo de almacenamiento de objetos. Ese costo es una fracción del de la base y, además, la experiencia del usuario no cambia.
• Sumarización y borrado. Además, datos técnicos que pueden agregarse o simplemente eliminarse una vez cumplido el plazo (jobs, spools, IDocs procesados).

Del archivado al data tiering — y al costo

• Archivado de negocio. Aquí entran los objetos clásicos (FI_DOCUMNT, MM_EKKO, SD_VBAK…), con retención legal y acceso garantizado — el tema central de este artículo.
• Data tiering en HANA (NSE). Por último, está el Native Storage Extension para bases SAP HANA. Este mueve el dato «warm» de la memoria al disco sin salir de la base. Así, las tablas siguen siendo consultables por SQL normal, pero dejan de ocupar RAM. Es decir, es el complemento perfecto del archiving. El histórico reciente que aún necesita consulta frecuente va a NSE; el antiguo, al archivo. La combinación correcta reduce el sizing de memoria (y la licencia) sin sacrificar acceso.

Además, hay un vínculo directo con el bolsillo. En RISE with SAP, el contrato se dimensiona por la memoria HANA, y cada escalón de sizing tiene precio. Por lo tanto, un DVM bien hecho (archiving + NSE + housekeeping) frena el crecimiento de la base. Como resultado, evita subir de escalón en la renovación. Es FinOps aplicado a SAP: gestión de volumen convertida en reducción directa de la suscripción.

Qué implica un buen proyecto de archiving

• Análisis de volumen por tabla y objeto. Primero, las herramientas del propio SAP muestran dónde está el peso: por año, por organización, por módulo. Son la TAANA (análisis de tablas) y la DB02 (visión de la base). Sin esa radiografía, por lo tanto, el proyecto se convierte en adivinanza.
• Mapa de dependencias entre objetos. Luego, en SAP los objetos de archivado (MM_EKKO, RV_LIKP, SD_VBAK, FI_DOCUMNT…) tienen orden. Es decir, no se archiva la facturación antes de la entrega. Un proyecto serio respeta esa cadena.
• Política de retención legal. Además, el fisco brasileño exige un resguardo prolongado — es decir, el dato sale de la base, no del alcance. ILM y un store adecuado lo resuelven.
• Acceso al dato archivado. Igualmente, lectura vía transacción, SARI/ALO o anexo al documento — al final, el usuario no puede «perder» el histórico.
• Ejecución en olas, sin detener la operación. Por último, escritura, verificación y borrado controlados, con ventanas y monitoreo.

Cómo lo hace Inove — con herramienta propia

El archiving SAP es una de nuestras especialidades. Por eso construimos el SAP Archiving Analyzer, herramienta propia de Inove. Esta analiza las tablas de tu ambiente y propone la estrategia de archivado. Además, respeta ya las dependencias entre objetos:

• Radiografía de la base — distribución por módulo, mayores tablas, evolución del volumen.
• Análisis por año y organización — luego, cuánto de cada tabla es histórico archivable.
• Mapa de dependencias — después, el orden correcto de archivado entre los objetos (MM, PP, FI, SD, CO…).
• Recomendación priorizada — por último, por ganancia de memoria y esfuerzo, para empezar por lo que más devuelve.

Con el diagnóstico en la mano, entonces, ejecutamos la estrategia completa. Eso incluye parametrización de los objetos, retención legal, store del archivo y ejecución en olas. Además, medimos la ganancia: memoria liberada, performance y costo. Todo ocurre dentro de nuestro modelo de soporte AMS, que mantiene viva la política de archivado después del proyecto. Al fin y al cabo, archivar una sola vez y detenerse es trabajar en vano.

Nuestra visión de siempre: queremos que el cliente no tenga dolores de cabeza con TI y sea feliz. En la práctica, eso es un SAP ligero, rápido y más barato de sostener.

Por dónde empezar

1. Radiografía de volumen de tu SAP — dónde está el peso, por tabla, año y organización.
2. Estrategia de archiving — luego, objetos, dependencias, retención legal y store.
3. Piloto en los objetos de mayor impacto — así, ganancia rápida y medible.
4. Rutina continua — por último, la política de archivado operando dentro del soporte.

Lee también

• Migración a SAP S/4HANA: por qué la base decide el proyecto
• Reforma Tributaria de Brasil y SAP: lo que TI debe preparar
• AMS para SAP: el soporte que le quita el peso al equipo

Entonces, ¿tu SAP está pesado y caro? Pide una radiografía de volumen con el SAP Archiving Analyzer — habla con Inove Solutions.