El inventario bruto no es el alcance: qué infla el conteo ABAP
El check devuelve miles de objetos Z, pero buena parte nunca se ejecutó en producción. Cómo separar el inventario bruto del alcance real de remediación.
· 11 min de lectura
En la pieza anterior de esta serie sostuvimos que equivocarse en el número de una remediación cuesta en las dos direcciones: de más se pierde el proyecto, de menos lo paga quien firmó. Aquí atacamos la primera causa del error, y es más temprana de lo que parece. El número con el que casi siempre arranca la conversación —el total que devolvió un check de código propio— no es el alcance de la remediación. Es un inventario. Y un inventario cuenta lo que está guardado, no lo que se usa.
La distinción no es semántica. En una distribuidora eléctrica o en un operador de oil & gas de la región, ese total suele ser el insumo con el que se arma un presupuesto, se negocia una ventana de parada y se compromete una fecha de conversión. Si el total sobreestima el trabajo real, la propuesta sale cara y se cae; si se corrige a ojo, sale barata y la diferencia la absorbe el equipo de entrega.
El conteo bruto responde a otra pregunta
Un check de código propio responde: cuántos objetos existen en el namespace del cliente y cuántos hallazgos generan contra las simplificaciones del destino. No responde: cuánto de eso sostiene hoy un proceso vivo.
SAP separa explícitamente los dos momentos del análisis. SAP Readiness Check se usa en la fase de planeación y entrega una visión de alto nivel del análisis de código propio; el ABAP Test Cockpit se usa en la fase de proyecto y ejecuta el análisis profundo de los usos críticos que deben adaptarse (SAP Community, 2026). Ambos miden el repositorio y su compatibilidad. Ninguno, por sí solo, mide operación.
El propio SAP lo dice sin rodeos: un sistema de cliente típico contiene una cantidad importante de objetos de desarrollo propio —objetos Z, ampliaciones y modificaciones— que no se usan productivamente, y la recomendación es monitorear el landscape durante un período prolongado para eliminar ese código antes de adaptarlo, porque eso reduce significativamente el esfuerzo de adaptación (SAP Community, 2023). La magnitud del fenómeno está documentada: en promedio, entre 40% y 60% del código propio no se ejecuta en el landscape productivo (SAP Community, 2025).
Qué infla el inventario en un ERP de utilities y oil & gas
Cuatro familias explican buena parte de la diferencia entre lo que se cuenta y lo que se opera.
- Clones abandonados. El patrón clásico: se copia un programa estándar o un Z existente para una variante, la variante se descarta o se fusiona, y el clon queda activo en el repositorio con su propia deuda de adaptación.
- Código de industrias y procesos que la empresa nunca operó. Módulos que se dimensionaron en un alcance original, se desarrollaron parcialmente y nunca entraron en productivo; plantillas corporativas heredadas de un modelo de grupo que la filial local no adoptó. Existen, compilan, generan hallazgos, no facturan nada.
- Desarrollos de procesos que se dejaron de operar. Reportes construidos para un esquema tarifario derogado, cargas de un formato regulatorio que el ente cambió, rutinas de campañas comerciales que terminaron hace años. Nadie las borró porque borrar no tenía dueño ni presupuesto.
- Código sombra que nadie reclama. Un inventario completo de extensiones debe cubrir código propio, enhancements, user exits, BAdIs, tablas Z, RFC e IDocs, e incluir explícitamente el código sombra que nadie toca (Avo Technologies, 2025). Ese es justamente el segmento sin dueño funcional que ningún entrevistado va a reivindicar en un taller de levantamiento.
La evidencia que baja el alcance es el uso productivo
La única forma de convertir un inventario en alcance es cruzarlo contra ejecución real en producción. La cadena instrumental está documentada y es la misma para una comercializadora que para un operador de campo.
Dos detalles operativos importan más de lo que sugiere su tamaño. Primero, el ABAP Call Monitor conserva los datos en el sistema por un período corto —del orden de días—, así que sin la agregación de la transacción SUSG la evidencia se pierde justo cuando se la necesita (SAP Community, 2025). Segundo, el scoping solo está soportado mediante la app Custom Code Migration, que genera transportes de borrado aplicables durante la conversión: eso es lo que permite que la reducción de alcance no quede en una planilla, sino que se materialice en el sistema destino (SAP Help Portal, 2025).
Por qué una ventana corta miente en facturación masiva
Aquí es donde el sector castiga los atajos. La recomendación de SAP es que los datos de uso cubran al menos un año, para que también entren los procesos de cierre trimestral y anual (SAP Help Portal, 2025). En una distribuidora eléctrica esa condición no es formalismo contable: la operación tiene rutinas que corren una vez al año o una vez por ciclo largo —ajustes tarifarios, refacturaciones masivas, reportes regulatorios anuales, inventarios de activos de red, cierres de campaña de lectura—. Una ventana de tres meses declarará muertos objetos que solo despiertan en el mes que no se midió.
Hay un segundo cuidado, y es de landscape: los datos de uso se recolectan por sistema, y un objeto sin uso en uno pero con uso en otro no debe darse de baja (SAP Community, 2025). En grupos con varias unidades de negocio o con un sistema por país, esa verificación cruzada es obligatoria antes de firmar cualquier reducción.
Del conteo bruto a un alcance defendible
Con evidencia de uso, el inventario deja de ser un número y pasa a ser tres cubetas: en alcance (uso confirmado en la ventana), fuera de alcance (sin uso, con transporte de borrado asociado) y en observación (sin datos suficientes o con uso ambiguo). La tercera cubeta es la honesta, y es la que se comunica con supuestos declarados: qué ventana se midió, qué sistemas se cruzaron, qué procesos anuales quedaron fuera de esa ventana.
Ese es el entregable que sostiene una negociación. No un total que impresiona, sino una separación auditable entre lo que la operación ejecuta y lo que solo ocupa espacio.
Aun con el inventario ABAP depurado, queda una zona que ningún check reporta: las interfaces y las cargas que sostienen la facturación y la gestión de activos, y que viven fuera del inventario de código propio. Ese es el tema de la próxima pieza de esta guía.
Fuentes
- SAP Community — SAP S/4HANA System Conversion: Custom code adaptation process (2023)
- SAP Community — ABAP Call Monitor (SCMON): Analyze usage of your code (2025)
- SAP Community — Custom code adaptation for SAP S/4HANA: FAQ (2026)
- SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA 2025 (edición vigente 2026-02-25; edición anterior 2025-10-08)
- Avo Technologies — What Is Clean Core A–D Extensibility Model (2025)
¿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.
