En una operación SAP dentro de casa, que la base crezca es un problema de infraestructura. Alguien compra disco, el backup tarda más, la vida sigue. En RISE es un ítem de factura — y un ítem que usted renegocia desde la peor posición posible: en medio del contrato, con el sistema ya en producción y sin alternativa de proveedor.

Es la diferencia que casi nadie considera en la firma. El contrato cierra un volumen, el volumen se dimensiona con el dato de hoy, y el crecimiento de los tres a cinco años siguientes se cobra a precio de medio término.

Por qué crecer cuesta distinto en RISE

Tres características del modelo se combinan, y su efecto es multiplicativo, no sumado.

El volumen es contractual, no técnico. Usted no compra disco — compra un derecho de volumen. Superarlo no genera lentitud, genera cobro adicional por GB, negociado cuando ya está adentro.

El dimensionamiento va en escalones. La memoria HANA no se vende por GB suelto: hay una base contratada y extensiones vendidas en bloque. Crecer algunos gigabytes más allá del escalón obliga a comprar el escalón entero siguiente. El costo no es proporcional al crecimiento — es una escalera.

El plazo es largo. Contratos de tres a cinco años significan que una decisión de dimensionamiento equivocada no se corrige al año siguiente: se paga hasta el fin del término.

Sume las tres y aparece la asimetría que importa: el momento de actuar es antes de tocar el escalón. Después de subir, reducir el volumen rara vez devuelve dinero — el compromiso ya está firmado. El valor de quitar peso de la base no está en deshacer el escalón que pagó; está en no pagar el siguiente.

SOFFCONT1 es el candidato más obvio que existe

Toda base SAP con algunos años tiene esa tabla crecida sin decisión de nadie. Es donde los adjuntos de GOS quedan guardados dentro de la base: el PDF que alguien arrastró a la orden, el correo que se volvió documento, la planilla adjunta al pedido.

Es el blanco correcto por tres motivos que rara vez coinciden:

No es dato de negocio. Sacar de ahí una partida contable exige proyecto de archivado, regla de retención y conversación con fiscal y auditoría. El adjunto no — sigue existiendo y sigue accesible, solo que en otro lugar.

Nadie decidió ponerlo ahí. Es el comportamiento por defecto cuando ningún repositorio de contenido fue configurado. No hay regla de negocio que preservar, hay una configuración que nunca se hizo.

No para de crecer. Es la única parte de la base que crece con el hábito de las personas, no con el volumen de transacciones. Y el hábito no disminuye solo.

Cómo Cloud Storage se vuelve repositorio de contenido de SAP

Aquí está la parte que cambia la cuenta, y es menos conocida de lo que debería.

SAP guarda contenido externo a través de ArchiveLink, y ArchiveLink habla con un content server HTTP. Históricamente eso significaba una máquina más: instalar el SAP Content Server, licenciar, monitorear, actualizar, incluir en el plan de recuperación. Buena parte de la ganancia de sacar el adjunto de la base se iba en ese servidor.

El ABAP SDK for Google Cloud resuelve esto de manera elegante: trae un handler HTTP escrito en ABAP, publicado en un nodo del SICF dentro del propio sistema. ArchiveLink lo ve como un content server común; el handler recibe la llamada y graba — o lee — el objeto directo en el bucket de Cloud Storage.

El sistema conversa consigo mismo, y el único componente nuevo en el paisaje es un bucket. No hay servidor de contenido que instalar, licenciar ni mantener.

El diseño queda así, en cuatro piezas:

• una cuenta de servicio de Google Cloud con permiso de escritura en el bucket;
• el nodo SICF que publica el handler del SDK;
• un repositorio de contenido creado en OAC0, del tipo content server HTTP, apuntando a ese nodo;
• la vinculación de los tipos de documento al repositorio, en OAC3, para que el adjunto nuevo ya nazca fuera de la base.

Para lo que ya está dentro de SOFFCONT1, la reubicación la hace el report propio de SAP — y ahí está la trampa, que tratamos en detalle en SOFFCONT1 y RSIRPIRL: el paso que parece falla. Conviene leerlo antes de ejecutar, no después.

Dos notas de realidad sobre el SDK: la edición que sirve aquí es la on-premises or any cloud, que es la soportada en S/4HANA Cloud Private Edition — es decir, RISE. Y el límite de tamaño por objeto es el del propio Cloud Storage, 5 TB, que para un adjunto de GOS es holgura sin fin.

La cuenta — y los dos números que solo usted tiene

No se puede publicar el cálculo hecho, porque la mitad está en su contrato. Pero la estructura es simple y cabe en una planilla de una pestaña.

Del lado de SAP, tres medidas: cuántos GB ocupa SOFFCONT1 hoy; cuánto creció en los últimos doce meses; y a cuántos GB está del próximo escalón de dimensionamiento. Esa tercera es la que decide la urgencia — y es la que casi nadie tiene a mano.

Del lado del contrato, un número: cuánto cuesta el GB adicional en su acuerdo, al precio de hoy y no al de la firma.

Del lado de Google Cloud, una elección: la clase de almacenamiento. El adjunto que el usuario abre desde la pantalla del pedido necesita clase estándar, con lectura inmediata. El adjunto de ejercicio cerrado, que solo vuelve en una auditoría, cabe en clase fría — mucho más barata por GB, con costo de recuperación cuando se lee. Mezclar las dos es el error caro: poner adjunto vivo en clase fría convierte cada clic del usuario en una espera y una tarifa.

El orden de magnitud suele ser tan desigual que la planilla responde sola. Lo que no responde — y por eso existe la sección siguiente — es si el resultado aparece en la factura o solo en la próxima renovación.

Lo que sale mal, con nombre

Creer que reducir la base reduce la factura de este mes. No la reduce. El compromiso de volumen está firmado. La ganancia aparece cuando el próximo escalón no es necesario — lo que es enorme, y es distinto de un ahorro inmediato. Prometer lo segundo para aprobar el proyecto es como el proyecto pierde credibilidad en el primer informe.

Tratarlo como proyecto técnico dentro de un sistema que no es suyo. En RISE quien opera es SAP. Instalar el transporte del SDK, crear nodo en SICF y abrir la salida de red hasta el bucket pasan por el proceso de operación del contrato. Hacerlo como sorpresa no es agilidad — es abrir una discusión de frontera de soporte en el peor momento.

Confundir sacar de la base con borrar. La tabla guarda el contenido real del adjunto. Todo el valor está en reubicar; nada de él está en borrar.

Cambiar un problema de espacio por uno de disponibilidad. Con el contenido fuera de la base, abrir el adjunto pasa a depender de la red y de que el bucket responda. Es un buen canje, pero es un canje — y lo que monitoreaba el equipo de base de datos ahora necesita monitoreo propio.

Migrar todo de una vez. Volumen alto en ventana ajustada, sin conteo previo por franja, es como la migración se vuelve incidente en lugar de proyecto.

El límite honesto

Sacar los adjuntos de la base reduce el crecimiento. No resuelve lo que está detrás: nadie decidió qué debería adjuntarse a SAP en primer lugar. La tabla vuelve a crecer, más despacio, por el mismo motivo de antes. Sin una regla sobre qué se adjunta y por cuánto tiempo, esto es postergar, no corregir.

Tampoco es la única fuente de peso. El adjunto suele ser la mayor parte que se puede sacar sin proyecto de negocio, pero si el objetivo es reducir de verdad el ambiente, es el comienzo — y el resto exige archivado con regla de retención, que es otro trabajo y otra conversación.

Y hay un costo que cambia de lugar en vez de desaparecer: sale de la factura de SAP y entra en la de Google Cloud. Mucho menor, con el orden de magnitud a su favor — pero pasa a existir, a necesitar dueño y seguimiento.

Si el punto de partida es saber cuánto de su base es adjunto y qué se puede sacar, empiece por el archiving SAP — SOFFCONT1 suele ser solo una de las tablas grandes. Si la conversación es sobre el contrato entero y no solo sobre espacio, vea FinOps en SAP RISE. Y si el objetivo mayor es entender el ambiente antes de tocarlo, el camino es el diagnóstico de TI.

Preguntas frecuentes