Decomisionar antes de remediar: la primera palanca de ROI
Retirar código Z muerto antes de la conversión a SAP S/4HANA reduce el scope de remediación y el costo anual de pruebas y mantenimiento en utilities de LATAM.
· 12 min de lectura
Cuando una utility de América Latina presupuesta su conversión a SAP S/4HANA, el número que domina la conversación es el volumen: cuántos objetos Z hay en el repositorio, cuántos hallazgos devuelve el ABAP Test Cockpit, cuántos ciclos de regresión hacen falta antes del go-live. Es una conversación honesta, pero incompleta. Falta una pregunta que casi nunca aparece en el acta del comité: de todos esos objetos, ¿cuántos se ejecutaron en producción el año pasado?
Ya sabemos que el iceberg es grande. Lo que sigue es la consecuencia práctica: antes de remediar, conviene retirar. Y esa decisión, tomada con evidencia, es la palanca de ROI más directa de todo el proyecto, porque no negocia alcance funcional con nadie: solo elimina trabajo que jamás debió entrar al plan.
El costo que nadie presupuesta: mantener lo que nadie ejecuta
La cifra que ordena el problema viene de la publicación técnica de SAP sobre el ABAP Call Monitor en SAP Community: en promedio, entre 40% y 60% del código propio de un sistema no se ejecuta realmente en el panorama productivo (SAP Community, 2025). No es código roto ni código malo: es código que sobrevivió a la iniciativa que lo originó, al proceso que lo justificaba o al integrante del equipo que sabía para qué servía.
Ese código no es gratis. Tiene un costo silencioso que se paga cada año en mantenimiento, en revisión de notas, en escaneo de vulnerabilidades y —sobre todo— en pruebas. El material de la industria sitúa ese costo evitable entre USD 0,25 y USD 0,63 por línea de código al año cuando se decomisiona el código muerto en lugar de migrarlo (smartShift, 2026). Aplicado de forma directa, cada millón de líneas retiradas representa entre USD 250.000 y USD 630.000 anuales que dejan de consumirse (cálculo aritmético sobre el rango citado). El mismo material señala que, en la práctica, entre 30% y 50% del código propio puede decomisionarse en vez de transformarse (smartShift, s.f.).
Reducir el scope es la palanca que no exige negociar con el negocio
Un proyecto de conversión tiene tres formas de mejorar su ecuación económica: bajar el precio unitario del esfuerzo, aumentar la automatización, o reducir la cantidad de cosas que hay que hacer. Las dos primeras dependen del proveedor y del mercado. La tercera depende de una decisión interna respaldada por datos.
SAP formaliza esa tercera vía con el nombre de scoping: la Guía de Migración de Custom Code para SAP S/4HANA establece que definir el alcance permite reducir la cantidad de código propio que debe migrarse y minimizar los esfuerzos de adaptación, y que el scoping solo se soporta mediante la app Custom Code Migration (SAP, 2025). No es una optimización marginal: es la definición del denominador sobre el que se calculan después todos los costos del proyecto.
El efecto se propaga en cascada. Cada objeto Z que sale del scope deja de generar hallazgos ATC que analizar, deja de requerir adaptación funcional, deja de necesitar un caso de prueba, deja de aparecer en el inventario de regresión previo al go-live y deja de arrastrar documentación, transporte y gestión de defectos. El ahorro de testing no es un beneficio secundario del decomiso: es su resultado principal.
Cómo se prueba que un objeto está muerto y no solo dormido
Retirar código sin evidencia es una apuesta. Retirarlo con datos de ejecución productiva es una decisión de ingeniería. SAP documenta la secuencia y sus restricciones técnicas.
Dos detalles técnicos condicionan todo el ejercicio. El primero: el ABAP Call Monitor almacena los datos de uso solo por un período acotado en el sistema, y para conservarlos en el tiempo debe usarse la transacción SUSG, cuyo propósito es agregar esa información e identificar cuándo fue la última vez que un programa o procedimiento se usó productivamente (SAP Community, 2024). El segundo: la recomendación de SAP es recolectar datos de uso en producción durante al menos un año antes de la conversión (SAP, 2025). Después, la app Custom Code Migration es capaz de generar una solicitud de transporte que contiene los objetos a eliminar (SAP Learning, s.f.).
Ese horizonte de doce meses no es burocracia: en una utility es la única forma de no confundir muerto con dormido. Un reporte de conciliación regulatoria que corre una vez al año, un programa de refacturación masiva que solo se activa tras un ajuste tarifario o una rutina de cierre que se ejecuta en diciembre son código perfectamente vivo con once meses de silencio.
Qué cambia en el meter-to-cash de una utility LATAM
En IS-U el custom code no está repartido de forma pareja: se concentra donde el negocio nunca aceptó el estándar. Gestión de dispositivos, cálculo y facturación, FI-CA, gestión de cobranza y mora, interfaces con lectura y telemedición, y los conectores hacia canales de recaudación acumulan capas de desarrollos superpuestos a lo largo de dos décadas. Es exactamente donde más duele el testing, porque cada objeto tocado obliga a validar de punta a punta un proceso que impacta la caja.
Por eso el decomiso previo tiene un efecto desproporcionado en esta vertical. Cada rutina de facturación abandonada, cada reporte de cartera reemplazado por otro y cada interfaz de un proveedor de medidores que ya no está en el parque son objetos que hoy inflan el inventario de regresión sin aportar un solo peso de recaudación. Retirarlos antes de comenzar la conversión reduce simultáneamente el costo del proyecto y el riesgo del go-live, con un presupuesto que en la región casi siempre está acotado.
La conversación gana además un anclaje temporal: el mantenimiento mainstream de SAP ERP 6.0 EHP 6–8 llega a su fin el 31 de diciembre de 2027, con mantenimiento extendido opcional y pago hasta 2030 (SEIDOR, 2025). El tiempo disponible para acumular un año limpio de datos de uso antes de arrancar la conversión no es infinito.
Del inventario a la evidencia forense
Decomisionar no es una tarea de limpieza técnica: es la construcción del caso de negocio. Un inventario de objetos con fecha de última ejecución productiva convierte una discusión de opiniones —“ese programa lo usamos”— en una decisión auditable, con trazabilidad de quién aprobó qué se retira y con qué respaldo. Ese mismo enfoque de auditar, limpiar y dimensionar correctamente antes del go-live es el que después sostiene las decisiones de archivado, retención y dimensionamiento de la huella HANA.
En AGT acompañamos a las utilities de la región a instrumentar esa medición temprano, a leer los datos de uso con criterio funcional y a traducir el resultado en un scope de remediación defendible ante el comité y ante el auditor. Nuestro equipo trabaja el decomiso como lo que es: la primera línea del caso de negocio de la conversión, no un anexo del plan de pruebas.
Ahora bien, la evidencia de uso reduce la duda, no la elimina. La siguiente entrega de esta guía aborda el reverso del problema: cómo validar antes de decidir, para no retirar aquello que sí se usa.
Fuentes
- SAP Community — 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
- SAP Community — Aggregate usage data in your production system with SUSG transaction: https://community.sap.com/t5/application-development-blog-posts/aggregate-usage-data-in-your-production-system-with-susg-transaction/ba-p/13401524
- SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA 2025 (edición vigente): https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.001/en-US/CustomCodeMigration_EndtoEnd.pdf
- SAP Community — 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 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
- smartShift — SAP Custom Code Automation Explained: How smartShift Delivers Real Value: https://smartshift.com/blog/sap-custom-code-automation-explained-how-smartshift-delivers-real-value
- smartShift — SAP Custom Code Transformation: https://smartshift.com/solutions/sap-custom-code-transformation/
- SEIDOR — Understanding SAP ECC Deadlines: https://www.seidor.com/en-us/blog/understanding-sap-ecc-deadlines
¿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.
