Cómo estrechar un rango de remediación SAP sin fabricar cifras

El patrocinador pide una cifra antes de que exista el sistema donde medirla. En la pieza anterior de esta serie vimos que el inventario ABAP deja fuera interfaces y cargas que igual hay que remediar. Aquí el problema es el siguiente: ya aceptaste entregar un rango en lugar de un número, y ahora la evidencia empieza a llegar en pedazos. La pregunta operativa es cómo se estrecha ese rango por etapas —y cómo se evita que, en algún punto del camino, se convierta silenciosamente en una promesa.

Un rango tiene dos extremos, y cada uno responde otra pregunta

El techo del rango responde: ¿cuánto código, cuántas interfaces y cuántas cargas podrían entrar al alcance? El piso responde: ¿cuánto trabajo cuesta cada hallazgo que sí entró? Son preguntas distintas, con insumos distintos, y ninguna se contesta en una reunión de comité.

De ahí la regla que aplicamos en nuestra práctica SAP: cada vez que el rango se estrecha, se documentan tres líneas. Qué insumo entró, qué extremo movió y qué sigue sin saberse. Si esas tres líneas no se pueden escribir, la reducción no es evidencia: es una opinión con decimales. Para una distribuidora eléctrica cuyo core soporta facturación masiva mensual, o para un operador de O&G con cargas de integridad de activos, esa diferencia es la que separa un presupuesto defendible de una desviación que aparece en el mes cuatro.

Insumo 1: el uso agregado recorta el techo, nunca el piso

El primer recorte real viene de los datos de uso productivo. El scoping de código propio permite reducir la cantidad de desarrollos a migrar y minimizar el esfuerzo de adaptación, está soportado únicamente mediante la app Custom Code Migration, y exige monitorear el landscape productivo por adelantado, recolectando datos de uso con la transacción SUSG durante al menos un año (SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA, edición 2025.001, 2026). El margen que abre no es menor: en promedio, entre 40% y 60% del código propio no se ejecuta realmente en el landscape productivo (SAP Community — ABAP Call Monitor, 2025).

Ahora, lo importante para el dimensionamiento es cómo se calcula ese alcance. Al agregar datos de uso al proyecto, el alcance por defecto incluye los objetos usados, los objetos referenciados estáticamente por ellos y los objetos para los que no hay datos de uso —tablas de base de datos, elementos de datos (SAP Help Portal — Custom Code Migration Guide, edición 2025.001, 2026). Es decir: el alcance por defecto es conservador por construcción. Sirve como techo defendible ante el cliente, no como estimación central, y mucho menos como piso.

El otro punto crítico es la ventana. El ABAP Call Monitor conserva los datos en el sistema durante un período configurable en time slices, con siete días por defecto y esa misma cifra como recomendación de SAP; SUSG existe justamente para agregarlos por un período largo (SAP Community — ABAP Call Monitor, 2025). La evaluación se hace en dos niveles complementarios: la vista detallada de historia reciente en SCMON, cuyas fechas de selección se ajustan automáticamente al rango de datos efectivamente recolectados, y la historia agregada de largo plazo en SUSG (SAP PRESS Blog, 2024). Traducido al sector: una observación de dos semanas no ve el cierre de facturación, ni la refacturación, ni la campaña anual de lectura, ni el reporte regulatorio de fin de ejercicio. Ese código aparece como no usado y no lo está.

Insumo 2: el sandbox convertido traduce objetos en hallazgos

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#B89C5C'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#B89C5C'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#B89C5C'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#B89C5C'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#d1bf95'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Sandbox convertido]) --> B[ABAP Test Cockpit con la variante de readiness]
  B --> C[De cuántos objetos a cuántos hallazgos y de qué tipo]
  C --> D{¿El hallazgo se corrige de forma automatizada?}
  D -->|Sí| E[Quick Fixes de ADT, habilitados para ejecución masiva sobre paquetes o componentes completos]
  E --> G([Adaptación automatizada])
  D -->|No| H[Adaptación a mano]
  H --> I([Adaptación manual])
  class A inicio
  class D decision
  class B,C,E,H proceso
  class G,I bueno
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff

Un objeto en alcance no es una unidad de trabajo. La conversión de un sandbox permite correr ABAP Test Cockpit con la variante de readiness y pasar de “cuántos objetos” a “cuántos hallazgos y de qué tipo”. Ese salto mueve el techo otra vez, ahora del lado del esfuerzo.

Buena parte de esos hallazgos corresponde a incidencias conocidas de simplificación que se pueden corregir de forma automatizada mediante los Quick Fixes de ABAP Development Tools, y los Quick Fixes habilitados para ejecución masiva permiten adaptar paquetes o componentes completos de una sola vez (SAP Community — Custom code adaptation process, 2026). Lo que no puede adaptarse automáticamente debe adaptarse a mano (SAP Learning — Adapting Custom Code, consultado 2026). Esa mezcla —automático contra manual— es el dato que el sandbox entrega y la lista de objetos no entregaba.

Insumo 3: la muestra remediada es la única que produce horas

Los dos insumos anteriores acotan el trabajo por arriba. Ninguno dice cuánto cuesta hacerlo. Eso solo aparece cuando un equipo remedia de verdad una muestra: la corrige, la activa, la prueba y la transporta.

Una muestra útil no es la más cómoda; es la que cubre los estratos del alcance. Al menos un lote de hallazgos resueltos con Quick Fix masivo, al menos una adaptación manual asociada a cambios de modelo de datos, y al menos un objeto que participe en una interfaz o en una carga —el terreno que, como vimos en la pieza anterior, ningún check reporta por sí solo. El resultado no se promedia: se reporta como dispersión. Un promedio esconde justamente el estrato que después desborda el cronograma.

Lo que no estrecha el rango (aunque lo parezca)

Conviene nombrarlo, porque estas cuatro cosas se cobran caro y no mueven ningún extremo. Una ventana de observación corta, por el límite de retención del monitor. Datos de uso tomados de calidad o desarrollo en lugar de producción. La convergencia de una reunión sin insumo nuevo detrás. Y sustituir la dispersión de la muestra por un promedio único, que es la forma más común de convertir una estimación en promesa sin decidirlo.

Cómo se documenta un rango que todavía se mueve

Un rango honesto se reemite con fecha, no se corrige a escondidas. Cada versión indica el insumo que la habilitó, el extremo que movió, la incertidumbre que sigue abierta y la condición que permitiría el siguiente recorte. Así el cliente ve un método que converge, no un consultor que cambia de opinión.

Queda una pieza del problema: qué se le dice al cliente mientras el número firme todavía no existe. Es el cierre de esta serie y el tema de la próxima guía.

Fuentes

• SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA (edición 2025.001, 2026-02-25)
• SAP Community — ABAP Call Monitor (SCMON): Analyze usage of your code (2025)
• SAP Community — SAP S/4HANA System Conversion: Custom code adaptation process (2026)
• SAP PRESS Blog (Rheinwerk) — How to Evaluate Custom Code Usage Data Ahead of an SAP S/4HANA Migration (2024)
• SAP Learning — Adapting Custom Code (consultado 2026)