Falsos negativos de uso: validar antes de retirar código Z
Retirar código Z que sí se ejecuta es el riesgo inverso del descope. Cómo diseñar ventanas de observación que eviten falsos negativos en IS-U.
· 12 min de lectura
Un objeto Z del proceso de facturación que no registra ni una sola ejecución en ocho meses parece un candidato evidente para salir del alcance de remediación. Muchas veces lo es. Pero en el meter-to-cash de una distribuidora, “no ejecutado” y “no usado” son dos afirmaciones distintas, y lo que las separa es la ventana de observación: el período durante el cual el sistema estuvo registrando qué código se llamó y desde qué proceso. Si esa ventana es más corta que el ciclo natural del negocio, el dato no prueba que el objeto esté muerto. Solo prueba que no lo vimos vivo.
La entrega anterior de esta serie sostuvo que reducir el alcance antes de remediar es la primera palanca de ROI de una conversión. Esta cubre el reverso obligatorio de esa tesis: cómo evitar que el descope retire algo que el negocio sí necesita.
El falso negativo no se paga en horas de desarrollo
Conviene separar los dos errores posibles de una decisión de alcance. El falso positivo consiste en conservar código que en realidad nadie ejecuta: cuesta dinero de remediación y pruebas, es decir, cuesta presupuesto. El falso negativo consiste en retirar código que sí se ejecuta: cuesta continuidad operativa.
La asimetría importa porque los dos errores no se manifiestan en el mismo momento. El falso positivo aparece en la factura del proyecto y es visible mientras el proyecto todavía existe. El falso negativo aparece cuando el proceso vuelve a correr —un cierre, un recálculo tarifario, un reporte al ente regulador, una campaña de refacturación—, y ese momento suele estar después del go-live, cuando el equipo de conversión ya se desmovilizó y el objeto retirado ya no está en ningún backlog.
En una utility, además, el proceso que falla rara vez es interno. Es el que emite facturas, el que sostiene la recaudación o el que alimenta un reporte obligatorio. Por eso la regla de decisión no puede ser simétrica: ante evidencia ambigua, el sesgo debe inclinarse a retener.
El meter-to-cash fabrica ciclos que un monitor corto no ve
El ciclo comercial de una distribuidora tiene periodicidades que superan por diseño cualquier ventana de observación breve:
- Procesos anuales: cierres contables, reportes regulatorios, recálculos y actualizaciones tarifarias que corren una sola vez al año, a veces en una sola noche.
- Estacionalidad de consumo y de gestión de cartera, que activa lógica específica solo en ciertos meses.
- Procesos disparados por evento: campañas de refacturación, ajustes retroactivos, revisiones de pérdidas no técnicas, atención de contingencias.
- Interfaces AMI y de eventos de medición cuya lógica excepcional (corte y reconexión masiva, reproceso de lecturas duplicadas, normalización de eventos sin timestamp) solo se ejecuta cuando ocurre la excepción.
A estos ciclos de negocio se suman causas técnicas de falso negativo que no tienen nada que ver con el uso real: el monitor activado tarde o desactivado a mitad del período, la recolección hecha en un entorno que no es producción, la lógica invocada dinámicamente o desde un sistema externo que estuvo fuera de servicio durante la observación, y —muy frecuente— la pérdida de datos por retención. El ABAP Call Monitor conserva los datos de uso en el sistema por un período limitado, de hasta siete días, por lo que almacenarlos durante un plazo largo exige activar la agregación con la transacción SUSG (SAP Community, 2025). Un equipo que activa el monitor y vuelve a mirarlo un semestre después puede encontrarse con una ventana efectiva mucho más corta que la planificada.
Cuánto hay que observar antes de decidir
Aquí la referencia no es una opinión de consultoría: es la recomendación del fabricante. SAP sugiere ejecutar la herramienta de recolección de uso durante un rango de 6 a 18 meses, y que ese período incluya al menos un cierre de fin de año (SAP Learning, consultado 2026). La guía de gestión de código propio para conversiones es más específica sobre el motivo: lo ideal es recolectar datos durante unos 13 meses antes de la migración, precisamente para que aparezcan los reportes que corren una sola vez al año (SAP Help Portal, consultado 2026).
Ese número explica por qué las ventanas de tres o seis meses producen listas de “código muerto” infladas. Y también explica qué hacer cuando el proyecto ya arrancó: la misma guía recomienda activar la recolección igual, aunque queden menos de 13 meses, para al menos capturar lo semanal y lo trimestral (SAP Help Portal, consultado 2026). Observar poco es mejor que no observar; el error es tratar una ventana corta como si fuera concluyente.
El contexto de escala justifica el esfuerzo: en promedio, entre 40% y 60% del código propio no se ejecuta en los entornos productivos, y esa proporción se traduce directamente en esfuerzo de adaptación evitable (SAP Community, 2025).
Un protocolo de validación antes de retirar
La decisión no debería salir de un solo dato. El criterio recomendado es mirar más allá del conteo de objetos: qué categorías hay, cómo dependen unos de otros y con qué frecuencia se ejecutan en producción, dando prioridad al código que gobierna registros financieros, cumplimiento regulatorio y transacciones de cara al cliente antes de decidir qué se retiene, qué se rediseña y qué se retira (smartShift, 2026). El dato de uso es una de esas dimensiones, no todas.
El paso de cuarentena es el que convierte una decisión irreversible en una reversible. La aplicación Custom Code Migration construye el alcance inicial a partir de los datos de uso recolectados y permite ajustarlo manualmente, agregando o quitando objetos (SAP, 2026). Esa capacidad de ajuste es exactamente lo que habilita un descope prudente: sacar el objeto del esfuerzo de remediación sin destruir la posibilidad de recuperarlo si el ciclo anual lo despierta.
Qué hacer cuando la ventana no alcanza
Cuando el cronograma no permite observar el ciclo completo, la mitigación es sustituir el dato faltante por evidencia de otra naturaleza, no por optimismo:
- Cruzar el uso con el catálogo de jobs planificados y sus variantes, incluidas las de periodicidad anual.
- Revisar el análisis de dónde-se-usa para detectar lógica invocada indirectamente o desde interfaces externas.
- Entrevistar a los dueños de proceso de facturación, cartera y regulatorio sobre los procedimientos que corren una vez al año o solo ante contingencia.
- Aplicar la regla de asimetría: ante duda en objetos con impacto en ingresos o sensibilidad regulatoria, retener y documentar por qué.
Nada de esto es gratis, pero todo es más barato que descubrir en el primer cierre posterior al go-live que el reporte obligatorio quedó fuera del alcance. La ventana de observación no es un trámite técnico: es el instrumento que hace defendible la decisión de reducir alcance.
Y esa defensa tiene un destinatario concreto. La próxima entrega de esta serie aborda cómo presentar el nuevo alcance al comité: menos objetos, mismo negocio cubierto.
Fuentes
- SAP Community — ABAP Call Monitor (SCMON): Analyze usage of your code, 2025.
- SAP Learning — Collecting Usage Data for Custom Code, consultado 2026.
- SAP Help Portal — Custom Code Management during an SAP S/4HANA Conversion, consultado 2026.
- SAP — Custom Code Migration Guide for SAP S/4HANA, 2026.
- smartShift — How to Reduce S/4HANA Migration Risk in 2026, 2026.
¿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.
