Inventario y uso: la primera pregunta antes de tocar código Z
Antes de remediar código Z para S/4HANA, la Fase 1 de assessment responde qué existe y qué se ejecuta. Guía para utilities de América Latina.
· 11 min de lectura
Hay un programa de facturación que corre una sola vez al año, en diciembre. Si el equipo de conversión midió el uso del sistema durante un trimestre, ese programa aparece como no usado. Y si aparece como no usado, alguien va a proponer decomisarlo.
Ese es el riesgo específico de esta pieza: no el de contar mal, sino el de medir en una ventana demasiado corta. La entrega anterior de esta serie dejó planteado que el alcance de remediación se dimensiona sobre lo que realmente corre en producción. Falta responder cómo se obtiene esa evidencia, cuánto tiempo hay que dejar el registro encendido, y qué pasa con los procesos que solo se despiertan en el cierre del ejercicio.
Lo que solo se ve en un año completo de producción
La información de uso no se deduce de la documentación ni se pregunta en una entrevista. Se recolecta en el sistema productivo, midiendo la ejecución real de los usuarios finales.
SAP dispone de dos mecanismos para esto: Usage and Procedure Logging (UPL) y el ABAP Call Monitor (transacción SCMON). Cualquiera de los dos sirve, pero se desaconseja usarlos en simultáneo para no afectar el rendimiento del sistema, y la recolección debe hacerse en producción, porque el factor determinante es el uso efectivo por parte de los usuarios finales. Una vez recolectados, la transacción SUSG permite agregar y administrar esos datos (SAP Learning, consultado 2026).
El punto que cambia cronogramas es la ventana temporal. SAP recomienda mantener el registro entre seis y dieciocho meses, incluyendo al menos un cierre de ejercicio anual (SAP Learning, consultado 2026). Y para proyectos de conversión, la recomendación es iniciar la recolección con SCMON y SUSG en los sistemas productivos al menos un año antes del proyecto (SAP Community, 2026).
Para una distribuidora eléctrica, esa ventana no es burocracia: es la única forma de capturar los procesos que corren una vez al año. La refacturación masiva por ajuste tarifario, el cierre contable, la campaña de recambio de medidores, el reporte al ente regulador. Un muestreo de tres meses declararía “no usado” un programa que es indispensable cada diciembre.
Hay una razón de fondo para tomarse el trabajo: en un sistema SAP ECC promedio, una gran parte del código propio nunca llega a ejecutarse en producción, y retirar el código no usado y obsoleto reduce significativamente el esfuerzo de adaptación (SAP Community, 2026). Esa proporción no se descubre leyendo el repositorio. Se descubre midiendo.
La otra mitad: el escaneo que dice qué existe
Los datos de uso, solos, tampoco bastan. Antes de saber qué se ejecuta hay que saber qué hay, y esa mitad es estática: recorrer el cien por ciento de la base de código para descubrir qué existe, identificar riesgos y evaluar la preparación para la modernización antes de transformar nada (smartShift, consultado 2026).
En una utility de la región, ese recorrido rara vez devuelve lo que el área de TI espera. El meter-to-cash acumula capas: reportes de facturación construidos para un esquema tarifario que ya cambió, exits de lectura escritos cuando la toma era manual, interfaces hacia sistemas comerciales que se reemplazaron hace dos ciclos regulatorios. Todo eso sigue transportado, sigue activo y sigue contando como objeto a remediar.
El escaneo estático responde qué existe y qué chocaría contra el modelo simplificado de S/4HANA. En el mundo SAP, esa verificación se ejecuta con el ABAP Test Cockpit contra el ruleset de S/4HANA en un sistema central de verificación, y sus resultados se integran al análisis del SAP Readiness Check (SAP Community, 2025).
Lo que no puede hacer es distinguir entre un programa que corre en cada ciclo de facturación masiva y uno que nadie invoca desde hace años. Esa distinción la aporta únicamente la mitad medida en producción.
El cruce: donde el inventario se convierte en alcance
Las dos mitades se encuentran en la app Custom Code Migration. Allí se crea el proyecto de migración y se cargan los datos de uso recolectados; si provienen de SAP Solution Manager mediante UPL o SCMON, también pueden incorporarse al proyecto (SAP, Custom Code Migration Guide for SAP S/4HANA, 2026).
El resultado deja de ser una lista plana de objetos y pasa a ser una clasificación accionable. En el SAP Readiness Check, la información de uso distingue objetos usados, objetos referenciados estáticamente por objetos usados, y objetos no detectados como usados, que son candidatos a decomisión. Esa distinción es la que permite reducir la cantidad de objetos a actualizar y disminuir el esfuerzo de remediación (SAP Community, 2023).
La categoría “referenciado” merece atención especial en IS-U. Un include compartido entre un exit de facturación vivo y tres reportes muertos no se elimina solo porque los reportes no corran. La evidencia de uso no automatiza la decisión: la informa. Quien decide sigue siendo el equipo funcional que conoce el meter-to-cash.
Por qué comprimir esta fase sale caro
Todo lo anterior explica por qué el “assessment de custom code” no aguanta el tratamiento que suele recibir: el de una actividad preparatoria que se puede comprimir si el calendario aprieta. Conviene desarmar esa idea con un dato de la propia herramienta de SAP.
En el SAP Readiness Check para SAP S/4HANA, la información de alcance de cada objeto de código propio proviene de un proyecto creado en la app Custom Code Migration, apoyado en los paquetes ABAP seleccionados y en la información de uso. Si esa app no se utiliza, todos los elementos quedan marcados como In Scope por defecto (SAP Community, 2023).
Léalo otra vez: por defecto, todo entra al alcance. No porque el negocio lo necesite, sino porque nadie ejecutó el paso que permite decir lo contrario. Esta fase no produce un documento de diagnóstico; produce la única evidencia con la que se puede sacar objetos del alcance. Sin ella, el proyecto arranca con el peor supuesto posible: que cada línea escrita en veinte años es crítica.
Lo que esto cambia en un proyecto LATAM
En la región, los proyectos de conversión se aprueban con presupuestos acotados y ventanas de indisponibilidad negociadas contra continuidad operativa y recaudación. En ese contexto, cada objeto que entra al alcance sin justificación consume horas de análisis, de remediación y de prueba que después faltan en la migración de datos o en la estabilización posterior al arranque.
Hay además una consecuencia de calendario que se subestima. Si la recolección de uso debe cubrir un ciclo anual completo, el reloj de esa medición empieza mucho antes que el reloj del proyecto. Encender SCMON el día del kickoff no produce evidencia: produce un muestreo que llegará tarde a la decisión que debía informar.
Ejecutar esta fase primero no retrasa el proyecto. Redefine su tamaño antes de que el tamaño se vuelva un compromiso contractual.
Queda una pregunta abierta, y es la que abordaremos en la próxima entrega de esta serie: cuando el inventario finalmente se cuenta, ¿qué tan grande resulta ser el iceberg de código que nadie ejecuta?
En AGT acompañamos a las utilities y operadoras de la región a ordenar esa secuencia: primero medir, después cotizar.
Fuentes
- smartShift — SAP Custom Code Analysis: https://smartshift.com/solution/sap-upgrade-code-analysis/
- SAP Community — Get started with the ABAP custom code migration process (actualización abril 2026): https://community.sap.com/t5/technology-blog-posts-by-sap/get-started-with-the-abap-custom-code-migration-process/ba-p/13531886
- SAP Learning — Collecting Usage Data for Custom Code (Practicing Clean Core Extensibility for SAP S/4HANA): 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
- SAP Community — Enhanced Custom Code Analysis in SAP Readiness Check for SAP S/4HANA Upgrades (2023): https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/enhanced-custom-code-analysis-in-sap-readiness-check-for-sap-s-4hana/ba-p/13580469
- SAP Community — SAP Readiness Check for SAP S/4HANA upgrades (actualización octubre 2025): https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-readiness-check-for-sap-s-4hana-upgrades/ba-p/13493174
- SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA (2026-02-25): https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.001/en-US/CustomCodeMigration_EndtoEnd.pdf
¿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.
