Código Z sin uso: qué dice el benchmark de 40% a 60%
Benchmarks de la industria ubican entre 40% y 60% el código Z obsoleto en un sistema SAP promedio. Qué significa esa cifra —y qué no— antes de convertir.
· 11 min de lectura
En la entrega anterior de esta serie planteamos la primera pregunta que debería anteceder a cualquier proyecto de conversión: qué código Z existe realmente en el sistema, y cuál de ese código se ejecuta. Es una pregunta incómoda porque su respuesta casi nunca está documentada. Y lo es por una segunda razón: antes de medir, nadie sabe qué proporción del inventario simplemente no aporta nada.
Esta entrega intenta poner una referencia sobre la mesa. No una ley general —no existe—, sino una cifra publicada, con su fuente y sus límites, para que un equipo de TI de una utility de América Latina pueda estimar el orden de magnitud del problema mientras consigue su propia medición.
La cifra que circula en el mercado
El material del proveedor de remediación smartShift sostiene que los benchmarks de la industria ubican entre 40% y 60% las personalizaciones técnicamente obsoletas en un sistema SAP promedio (smartShift, 2026). Es la cifra que más se repite en presentaciones comerciales, y conviene leerla con precisión: proviene de un proveedor cuyo negocio es, justamente, automatizar la remediación y el retiro de ese código. Eso no la invalida —ese proveedor analiza repositorios reales de sus clientes—, pero sí obliga a tratarla como referencia de mercado y no como diagnóstico de su sistema.
El propio material del proveedor muestra por qué esa distinción importa. En otra de sus publicaciones el rango se amplía a entre 40% y 70% de personalizaciones que no están, o ya no están, en uso (smartShift, 2026). Dos rangos distintos, del mismo autor, sobre el mismo fenómeno. La conclusión útil no es el número exacto: es que en sistemas maduros la porción inactiva del repositorio tiende a ser la mitad o más.
Lo que el benchmark mide, y lo que no
“Técnicamente obsoleto” es una afirmación sobre ejecución, no sobre valor de negocio. Un objeto que no se llamó en producción durante el período observado es un candidato a retiro, no una sentencia. Puede tratarse de un programa de cierre anual, de un reporte que solo corre ante una fiscalización, o de un include del que depende un objeto activo. Esa es exactamente la razón por la que el análisis de uso se combina con análisis de dependencias antes de decidir nada.
El rango tampoco se cumple parejo. En los casos que el mismo proveedor documenta con nombre propio, las cifras reales quedaron por debajo del promedio: retiros del orden de un tercio a un 40% de los objetos personalizados, no del 60% (smartShift, 2026). Es una referencia extranjera y la citamos solo como eso —evidencia de dispersión—, no como modelo a replicar.
Lo que sí está sólidamente establecido es la magnitud del fenómeno de base. La investigación que ASUG realizó junto con smartShift entre 174 de sus miembros encontró que 95% de las organizaciones construye y ejecuta código ABAP propio para extender SAP, y que el principal desafío reportado al mover a SAP S/4HANA es tener demasiadas personalizaciones en las instancias antiguas (ASUG, 2024). El código Z no es una anomalía: es la norma. La pregunta es cuánto de él sigue vivo.
Por qué un meter-to-cash de utility tiende al extremo alto
En una empresa de servicios públicos de la región, el ciclo comercial y de facturación acumula capas por diseño. Cada cambio en el marco tarifario, cada esquema de subsidio, cada campaña de normalización de pérdidas no técnicas, cada integración con un nuevo concentrador AMI dejó su rastro: programas Z, exits, reportes ad-hoc, tablas auxiliares. Cuando la resolución que originó ese desarrollo fue derogada o sustituida, el código rara vez se retiró. Nadie lo borra porque nadie puede afirmar que ya no se ejecuta.
A eso se suma un patrón conocido en la región: rotación de equipos y de proveedores, documentación fragmentada y presupuestos acotados que priorizan la continuidad operativa por encima de la higiene del repositorio. El resultado previsible es un inventario que crece más rápido de lo que se depura. Por eso, cuando en un IS-U latinoamericano se aplica una medición seria de uso, el resultado suele acercarse al extremo alto del rango publicado —pero eso hay que comprobarlo, no asumirlo.
De la cifra ajena a la cifra propia
La cifra del proveedor sirve para dimensionar la conversación con el comité de inversión. Para dimensionar el proyecto hace falta el dato propio, y SAP documenta cómo obtenerlo. La guía de migración de código propio recomienda recolectar datos de uso en el sistema productivo con ABAP Call Monitor (SCMON) y la transacción SUSG durante al menos un año, de modo que el período observado incluya también la funcionalidad de cierres trimestrales y de fin de ejercicio (SAP, 2026). Ese horizonte no es un detalle: medir tres meses en una utility deja fuera la facturación de cierre anual y convierte código crítico en falso candidato a retiro.
La app Custom Code Migration convierte esos datos en alcance: permite marcar los objetos que no se llevarán a SAP S/4HANA y genera la solicitud de transporte de borrado correspondiente (SAP Community, 2026). El inventario deja de ser un listado y pasa a ser una decisión de proyecto.
Qué cambia cuando la cifra es suya
Cambian tres cosas. Primero, el costo recurrente: el mismo material de industria estima entre USD 0,25 y USD 0,63 anuales por línea de código el gasto de mantener y probar código que nadie ejecuta (smartShift, 2026). Segundo, el esfuerzo de pruebas de regresión, que escala con la cantidad de objetos que se decide conservar. Tercero, el calendario: con el fin del mantenimiento mainstream de SAP Business Suite 7 a finales de 2027 y mantenimiento extendido opcional hasta finales de 2030 (SAP, 2026), cada objeto que entra al alcance compite por una ventana que no se amplía.
En AGT acompañamos a operadores de utilities y de oil & gas de la región a convertir esa medición en una cifra defendible ante el comité de inversión, antes de que el alcance quede congelado por inercia. La cifra de la industria abre la conversación; la propia es la que la cierra.
La entrega siguiente de esta serie toma la consecuencia natural de este hallazgo: por qué decommissionar antes de remediar es la primera palanca de retorno del proyecto, y no una tarea de limpieza posterior.
Fuentes
- smartShift — SAP Custom Code Automation Explained: https://smartshift.com/blog/sap-custom-code-automation-explained-how-smartshift-delivers-real-value
- smartShift — Five reasons why removing unused SAP code matters: https://smartshift.com/blog/removing-unused-code-matters
- smartShift — SAP Custom Code Transformation: https://smartshift.com/solutions/sap-custom-code-transformation/
- ASUG / smartShift — ASUG Research on SAP S/4HANA Custom Code Migration: https://smartshift.com/publications/asug-smartshift-sap-s4hana-custom-code-migration/
- SAP — Custom Code Migration Guide for SAP S/4HANA: 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 — Maintenance Strategy: https://support.sap.com/en/offerings-programs/strategy.html
¿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.
