El inventario no es el alcance: costear la remediación real
Presupuestar la remediación de código Z sobre todo el inventario infla el alcance de la conversión a S/4HANA. Qué cambia al medir lo que sí se ejecuta.
· 10 min de lectura
En la mayoría de las utilities y operadoras de oil & gas de América Latina, la conversión a SAP S/4HANA empieza con un número: cuántos objetos Z tiene el sistema. Decenas de miles de programas, includes, reportes, user exits, clases y funciones acumulados a lo largo de dos décadas de operación. Ese número viaja rápido. Se multiplica por un esfuerzo promedio por objeto, se le suma un colchón de pruebas y termina convertido en el presupuesto que se lleva al comité de inversión.
El problema no es la aritmética. Es que ese número describe el inventario, no el alcance. Y entre uno y otro hay una diferencia que, en un meter-to-cash de IS-U, suele ser la mitad del proyecto.
El inventario no es el alcance
Un repositorio de código Z es un registro histórico, no un mapa de lo que el negocio ejecuta hoy. Contiene el reporte que se construyó para un esquema tarifario derogado, la interfaz que alimentaba un sistema de campo reemplazado hace tres años, la variante de facturación que se creó para un piloto que nunca escaló y la copia de respaldo de un programa que sí corre, dejada “por si acaso” en una migración anterior.
Ninguno de esos objetos se borra solo. Todos, en cambio, aparecen en el conteo. Y cuando el conteo es la base del presupuesto, la organización termina financiando la remediación, la prueba y la certificación de código que ya no participa de ningún proceso de negocio.
La documentación de SAP es explícita en este punto: en un sistema SAP ECC promedio, una parte importante del código custom nunca se ejecuta en producción, y eliminar el código obsoleto reduce significativamente el esfuerzo de adaptación (SAP Community, 2026). En análisis de campo sobre entornos SAP heredados es común encontrar que entre 40% y 60% de los objetos custom ya no se usan (smartShift, 2026). No es deuda técnica menor: es el cuerpo del presupuesto.
Por qué el meter-to-cash exagera el conteo
En una distribuidora eléctrica o de gas, el meter-to-cash es el proceso con mayor densidad de código Z de todo el paisaje SAP. Cada cambio regulatorio de la última década dejó sedimento: ajustes al cálculo tarifario, reportes al ente regulador, tratamientos de subsidio, esquemas de refacturación, adaptaciones de corte y reconexión, interfaces hacia sistemas de medición sucesivos.
Ese sedimento tiene una característica particular: se agrega, rara vez se retira. Cuando una resolución cambia el esquema de facturación, el desarrollo nuevo entra en productivo, pero el anterior casi nunca se decomisiona formalmente. Queda en el repositorio, sin transportes, sin incidentes, sin dueño —y perfectamente contable el día que alguien pregunta cuántos objetos Z hay en IS-U.
El resultado es un inventario que refleja veinte años de regulación acumulada, y un presupuesto que lo trata como si fuera un solo cuerpo homogéneo de código crítico.
Lo que SAP ya documenta sobre el código que nunca corre
La forma de distinguir un objeto vivo de uno fósil no es la intuición del equipo ni la antigüedad del programa: es el dato de uso. SAP recomienda recolectarlo en los sistemas productivos con el ABAP Call Monitor (transacción SCMON) y agregarlo con la transacción SUSG, y su recomendación es hacerlo con al menos un año de anticipación al proyecto de conversión (SAP Community, 2026). Esos datos, junto con los provenientes de Usage Procedure Logging (UPL), pueden cargarse en la app Custom Code Migration para definir el alcance inicial de la migración (SAP Community, 2026).
Existe además un matiz que en utilities es determinante: la ventana de observación. Para llegar a conclusiones confiables, el análisis de uso requiere un historial suficiente —idealmente cercano a trece meses— de modo que capture todos los ciclos críticos de negocio y los procesos de cierre anual (smartShift, 2026). En un meter-to-cash, un muestreo de tres meses clasificaría como “sin uso” el programa de cierre regulatorio anual, la refacturación masiva estacional o el reporte que solo corre en la ventana de revisión tarifaria. El dato de uso es necesario; la ventana correcta es lo que lo vuelve confiable.
Dos rutas de presupuesto, dos proyectos distintos
La diferencia entre ambas rutas no es de método técnico: es de decisión temprana. La Ruta A se toma en la primera reunión de estimación, mucho antes de que alguien abra un editor ABAP, y condiciona todo lo que viene después.
Lo que cambia cuando el alcance se mide con datos de uso
Retirar código inactivo reduce el footprint del paisaje SAP y con ello el alcance, el esfuerzo de pruebas y el costo global de la conversión (smartShift, 2026). El efecto se propaga hacia adelante: menos objetos remediados significan menos ciclos de regresión, menos ventanas de prueba sobre procesos de facturación en operación y menos exposición durante el corte a productivo.
El punto es especialmente relevante en América Latina, donde la modernización avanza con presupuestos acotados y contra un calendario definido: SAP mantiene el mantenimiento estándar de las aplicaciones core de SAP Business Suite 7 hasta el cierre de 2027, con mantenimiento extendido opcional hasta 2030 (SAP Support Portal, 2020). Cada punto porcentual de alcance que no corresponde a código vivo compite con inversión que la operación necesita en otro lado —recaudación, pérdidas no técnicas, continuidad del servicio.
Vale aclarar lo que este análisis no es: no se trata de borrar código, sino de dejar de presupuestarlo como si fuera crítico antes de haber verificado si lo es. La decisión de decomisionar exige análisis de dependencias y criterio funcional. La decisión de costear exige, apenas, un dato que la mayoría de las organizaciones aún no está recolectando.
La primera pregunta viene antes del primer objeto
Investigación de ASUG citada por proveedores del ecosistema identifica el exceso de personalizaciones como el principal desafío de las migraciones a S/4HANA (smartShift, 2026). Pero el exceso rara vez es el que aparece en el conteo: es el que sobrevive sin que nadie lo cuestione.
En AGT acompañamos a utilities y operadoras de la región a construir el alcance de conversión sobre evidencia de ejecución, no sobre el tamaño del repositorio. La próxima entrega de esta serie aborda el paso que hace posible esa distinción: el inventario y el análisis de uso —la primera pregunta antes de tocar una sola línea de código.
Fuentes
- SAP Community (2026). Get started with the ABAP custom code migration process. https://community.sap.com/t5/technology-blog-posts-by-sap/get-started-with-the-abap-custom-code-migration-process/ba-p/13531886
- SAP Community (2026). SAP S/4HANA System Conversion – Custom code adaptation process. https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-system-conversion-custom-code-adaptation-process/ba-p/13337309
- SAP Community (2025). ABAP Call Monitor (SCMON) – Analyze usage of your code. https://community.sap.com/t5/application-development-and-automation-blog-posts/abap-call-monitor-scmon-analyze-usage-of-your-code/ba-p/13313572
- smartShift (2026). SAP Custom Code Analysis. https://smartshift.com/solution/sap-upgrade-code-analysis/
- SAP Support Portal (2020). Innovation Commitment for SAP S/4HANA until 2040 — Maintenance strategy. https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
- SAP Learning. Collecting Usage Data for Custom Code. https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/collecting-usage-data-for-custom-code_e9bc634f-d673-49ce-a917-983ca50c4e47
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
