Menos objetos, mismo negocio: reportar el scope al comité
Cómo presentar al comité un scope de remediación de código Z más pequeño y más preciso, con la cobertura del negocio intacta y evidencia de uso.
· 13 min de lectura
Un número correcto puede perder la sala.
Cuando el equipo de conversión a SAP S/4HANA presenta un scope de remediación más chico que el del trimestre anterior, lo que se juega en esa reunión no es la aritmética. Es la credibilidad de quien reporta. La cifra llega sola a la mesa y, si nadie la acompaña con su método, la dirección la interpreta por su cuenta.
La interpretación por defecto es la peor de las dos posibles: que el proyecto recortó alcance para cuadrar presupuesto. La otra —que dejó de estimar sobre percepciones y empezó a estimar sobre evidencia— no aparece si no se enuncia. Esa diferencia no se resuelve con una lámina de más: se resuelve con la forma en que se reporta el número.
Este artículo no trata de cómo se calcula el scope. Trata de cómo se defiende cuando alguien en el comité pide ver el método.
Las tres preguntas que va a hacer el comité
Las preguntas llegan casi siempre en el mismo orden, y conviene tener la respuesta lista antes de que se formulen.
¿Y si retiramos algo que sí se usa? Es la pregunta correcta y merece una respuesta operativa, no defensiva. El scope se construyó sobre datos de ejecución, no sobre memoria institucional, y la validación previa a la decisión de retiro es un paso propio del método. Vale además decir en la sala que el camino tiene retorno: SAP indica que es posible activar SCMON en el sistema productivo SAP S/4HANA después de la conversión, recolectar datos de uso y retirar el código no utilizado en ese momento (SAP Community, 2025).
Hay una salvaguarda adicional que rara vez se menciona ante la dirección y que desactiva buena parte de la ansiedad: es posible conservar un respaldo de los objetos retirados usando abapGit, almacenando en un repositorio Git los objetos del deletion transport request generado por la app Custom Code Migration (SAP Community, 2026). SAP publicó después una alternativa que describe como la mejor opción para respaldar y eventualmente restaurar el código no utilizado: habilitar gCTS tras la conversión y transferir los objetos del transporte de eliminación a un repositorio Git externo (SAP Community, 2025). El retiro deja de ser una puerta de una sola dirección.
¿Esto es un recorte de presupuesto disfrazado? No, y la prueba es la capa de cobertura funcional. Un recorte de presupuesto elimina alcance de negocio; este ejercicio elimina objetos que ningún proceso de negocio invoca. Son operaciones distintas y el reporte debe mostrarlas como distintas.
¿Este número es definitivo? Tampoco, y conviene decirlo antes de que lo pregunten. El scope es una fotografía con fecha de corte y método declarado. Si el período de observación se extiende o cambia el release destino, el número se recalcula. Un scope que se presenta como inmutable pierde credibilidad en la primera revisión.
El reporte no es la lámina
Quien reporta suele confundir el entregable con la presentación. La lámina resume; lo que sostiene la decisión vive en otro lado, y saber señalarlo cambia el peso de lo que se afirma.
El análisis de SAP Readiness Check, por ejemplo, no termina en un archivo suelto: una vez procesada, la analítica queda disponible como un tablero interactivo dentro de la aplicación en la nube de SAP Readiness Check, donde los resultados se pueden explorar directamente (SAP Community, 2024). Poder decir en la sala «el número sale de aquí, y aquí se puede revisar» es una respuesta distinta a «confíen en el equipo».
Ese es el cambio de registro que persigue esta etapa: el proyecto deja de pedir presupuesto contra una incertidumbre y empieza a mostrar una reducción medible de superficie de riesgo, alineada además con la dirección de clean core que SAP promueve para el ciclo de vida del código propio.
El comité no evalúa código: evalúa riesgo, fecha y dinero
Un comité de una distribuidora eléctrica o de una operadora de gas en América Latina no discute paquetes ABAP. Discute tres cosas: si el negocio queda cubierto, si la fecha se sostiene y cuánto cuesta en dólares llegar ahí. Todo lo que se le presente tiene que traducirse a ese lenguaje o no entra en la decisión.
La fecha, además, ya no es una variable libre. Para los enhancement packages 6 a 8 de SAP ERP 6.0, el mantenimiento mainstream termina el 31 de diciembre de 2027, con mantenimiento extendido opcional hasta finales de 2030 mediante un costo adicional (SEIDOR, 2025). Cada objeto que permanece en el scope de remediación compite por una ventana de calendario que es finita y por horas de consultoría que en la región son escasas y caras.
Por eso la reducción de scope no es un detalle técnico del workstream de desarrollo. Es, potencialmente, el entregable más valioso que ese workstream produce antes de que empiece la conversión.
Qué se lleva a la lámina y qué se deja fuera
Hay una regla de presentación que ahorra la mitad de las objeciones: no mezclar nunca los dos números en la misma lámina. Son magnitudes que responden a preguntas distintas y ponerlas juntas invita a leer la diferencia como una resta arbitraria.
La documentación oficial de SAP respalda el criterio con el que se separa uno del otro: el scoping de custom code permite determinar el código ABAP que se usa con frecuencia y que debe llevarse a SAP S/4HANA, mientras que el código no utilizado puede eliminarse mediante deletion transport requests durante la conversión del sistema; el scoping solo está soportado a través de la app Custom Code Migration (SAP, Custom Code Migration Guide for SAP S/4HANA 2025, edición 2026).
Y el orden de magnitud de la diferencia no es una intuición de consultor: SAP documenta que, en promedio, entre 40 % y 60 % del custom code no se ejecuta en los entornos productivos, lo que convierte al monitoreo de uso en un paso esencial antes de una transformación a SAP S/4HANA (SAP Community, 2026).
La afirmación que se lleva al comité, entonces, no es “borramos código”. Es: identificamos qué parte del código sostiene el negocio y dejamos de pagar por el resto.
La evidencia que sostiene el número
Un scope reducido sin trazabilidad es una opinión. Con trazabilidad, es un hallazgo auditable. Tres capas de evidencia lo sostienen.
Datos de uso reales, no percepciones
La recomendación de SAP es recolectar datos de uso en los sistemas productivos al menos un año antes del proyecto de conversión, usando las transacciones ABAP Call Monitor (SCMON) y SUSG; los datos de uso ya recolectados con SAP Solution Manager y UPL también pueden considerarse (SAP Community, 2026). En una utility, ese año importa más que en otros sectores: la facturación tiene estacionalidad, y hay procesos de corte, reconexión y refacturación que solo se activan en ciertas ventanas del año.
Hallazgos filtrados, no ruido acumulado
El análisis técnico se ejecuta con ABAP Test Cockpit contra la Simplification Database. Aquí hay un matiz que evita reportar un número inflado: al crear una baseline de hallazgos existentes y exenciones en ABAP Test Cockpit antes de ejecutar SAP Readiness Check, es posible excluir resultados heredados de proyectos anteriores y concentrarse en los hallazgos relevantes para el proyecto actual (SAP Community, 2026).
Cobertura funcional explícita
Esta es la capa que el comité entiende sin traducción. Los objetos que sobreviven al scoping se mapean contra los procesos del meter-to-cash: lectura y validación, facturación, corte y reconexión, recaudación y atención de reclamos. Lo que se valida en la sala no es una lista de objetos: es que ningún proceso del ciclo comercial quedó sin respaldo.
El ciclo comercial contra el que se valida la cobertura
Presentado así, el reporte deja de pedirle al comité que evalúe una lista de objetos y le pide algo que sí sabe evaluar: si cada etapa del ciclo comercial quedó respaldada.
Un scope más chico es un entregable, no una excusa
Reportar bien esta etapa cambia la naturaleza de la conversación con la dirección. Deja de discutirse cuánto se recortó y pasa a discutirse qué quedó demostrado.
Como lo plantea la industria especializada en análisis de código SAP, esta claridad permite planificar la transformación con precisión, reducir el riesgo y modernizar con confianza, en lugar de partir de un inventario sin depurar (smartShift, 2026).
En AGT Comunidades acompañamos a utilities y operadoras de la región a construir ese reporte: no la lámina, sino la evidencia que la sostiene cuando alguien en el comité pide ver el método. Nuestro equipo trabaja el scoping como lo que es —una decisión de negocio documentada— y no como un subproducto técnico que se descubre a mitad de la conversión.
Fuentes
- SAP. Custom Code Migration Guide for SAP S/4HANA 2025 (How-to Guide, PUBLIC, 2026-02-25; edición vigente que sucede a la de 2025-08-06 para el target SAP S/4HANA 2023). https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.001/en-US/CustomCodeMigration_EndtoEnd.pdf
- SAP Community. Get started with the ABAP custom code migration process (última actualización agosto 2026). https://community.sap.com/t5/technology-blog-posts-by-sap/get-started-with-the-abap-custom-code-migration-process/ba-p/13531886
- SAP Community. SCMON Setup and Execution Guide (2026). https://community.sap.com/t5/abap-blog-posts/scmon-setup-and-execution-guide/ba-p/14363378
- SAP Community. Enhanced Custom Code Analysis in SAP Readiness Check for SAP S/4HANA Upgrades (2026). 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. Custom code adaptation for SAP S/4HANA – FAQ (2026). https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/custom-code-adaptation-for-sap-s-4hana-faq/bc-p/13753486
- SAP Community. How to backup custom code with gCTS (2025). https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-backup-custom-code-with-gcts/ba-p/13505991
- SAP Community. SAP Readiness Check Optimization (2024). https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-readiness-check-optimization/ba-p/13578152
- SAP Community. ABAP Call Monitor (SCMON) – Analyze usage of your code (hilo de respuestas, 2025). https://community.sap.com/t5/application-development-and-automation-blog-posts/abap-call-monitor-scmon-analyze-usage-of-your-code/ba-p/13313572
- smartShift. SAP Custom Code Analysis (2026). https://smartshift.com/solution/sap-upgrade-code-analysis
- SEIDOR. Understanding SAP ECC Deadlines: What 2026 and 2027 Mean for Your Business (2025). 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.
