SAP Readiness Check le dice qué se va a romper. No puede decirle qué merece sobrevivir.
Todo programa de conversión arranca con el mismo artefacto: un informe que cuenta objetos propios, conflictos con simplification items y hallazgos de ajuste. La cifra suele ser de miles, la primera reacción suele ser la alarma, y el primer instinto — remediar todo lo que el informe marca — suele ser el error más caro disponible.
El informe es un inventario. El plan es un triaje. Confundirlos mete el pasado en el precio del futuro.
La mayor parte del código propio está muerto, y los datos de uso lo demuestran. Remedie lo que se gana su sitio; retire el resto sin ceremonias.
Lo que la herramienta sí le da
Tres cosas, y son valiosas: un inventario de objetos propios, un mapeo de dónde chocan con las simplificaciones de S/4HANA y — cuando el registro de uso lleva suficiente tiempo activo — la evidencia de qué se ejecuta realmente en producción. Juntas convierten “tenemos mucho código propio” de leyenda en dato.
El conjunto de herramientas de SAP aquí — Readiness Check más las comprobaciones de migración de código propio en ABAP Test Cockpit — identifica conflictos y esfuerzo de ajuste. Las estadísticas de uso necesitan meses de recogida para ser fiables; activarlas es uno de los movimientos tempranos más baratos que puede hacer un programa.
Lo que no puede decirle
Si alguien sigue ejecutando el objeto
Un hallazgo de conflicto sobre un informe que nadie ha ejecutado desde 2019 no es una tarea — es un candidato a borrado disfrazado de tarea. Sin datos de uso, el informe trata igual a los muertos y a los vivos.
Si el requisito que hay detrás sigue existiendo
Los objetos propios sobreviven a los cambios de proceso, las reorganizaciones y las normativas que los justificaron. La pregunta “¿qué capacidad de negocio sirve esto hoy?” no está en ningún registro — pertenece a los responsables de proceso, y hacerla retira más código que cualquier corrección de sintaxis.
En qué deben convertirse los supervivientes
“Ajustar el código” es solo uno de cuatro veredictos. El informe no puede ver que un requisito superviviente ya lo cubre el estándar, o que es lo bastante diferenciador como para merecer una reconstrucción limpia como extensión. Eso son decisiones de diseño, no hallazgos.
Los cuatro veredictos
Medir el uso→Retirar lo muerto→Interrogar a los supervivientes→Enrutar según clean core
Por qué el triaje cambia el programa
La aritmética es drástica y típica: de la cifra titular, una gran parte no se ejecuta nunca, otra parte duplica lo que el estándar ya hace, y el resto genuinamente diferenciador — el código que merece ingeniería de verdad — es una fracción del número original. La estimación de remediación construida sobre la cifra bruta y la construida sobre la cifra triada son dos proyectos distintos.
El triaje produce además algo que el informe bruto nunca puede: un relato defendible ante auditoría y comité de dirección sobre por qué cada objeto vivió o murió — capacidad por capacidad, no línea por línea.
Perspectiva de VISCAP
La unidad de remediación es una capacidad de negocio, no un objeto. El código solo es evidencia de un requisito — interrogue al requisito.
Tratamos el Readiness Check como el inicio de una conversación con los responsables de proceso, no como un backlog. El informe dice dónde el pasado es incompatible con el futuro; solo el negocio puede decir qué partes del pasado merecía la pena conservar. Los programas que se saltan esa conversación pagan a ingenieros por preservar costumbres.
La cifra que importa
No el número de hallazgos de la página uno — sino la proporción de su código propio con cero ejecuciones en el último año. Pida esa cifra primero. Reencuadra todas las conversaciones que vienen después, normalmente en una sola reunión.