Limpiar el ERP antes de convertir: la decisión de cronograma
SAP recomienda depurar el código no usado antes de migrar. Por qué esa decisión de cronograma define si el core queda limpio o solo compatible.
· 10 min de lectura
La decisión de limpiar el ERP no se toma en el proyecto de conversión. Se toma alrededor de un año antes, cuando todavía no hay proyecto, ni comité, ni cronograma que defender. Esa es la asimetría que casi nadie agenda: la evidencia que hace confiable la limpieza tarda un año en producirse, y para entonces el proyecto ya arrancó.
De ahí que solo existan dos respuestas posibles, y solo una sea barata: limpiar el ERP de origen una vez, antes de convertir, o arrastrar la limpieza por cada ciclo posterior —cada upgrade, cada release, cada regresión de facturación— durante el resto de la vida del sistema. En nuestra práctica SAP, ese es el punto donde un proyecto decide, sin saberlo, cuánto va a costar operar el core los próximos diez años.
Una distribuidora eléctrica llega a la conversión con un plan detallado: ventanas de corte, pruebas de facturación, capacitación al call center, plan de reversa. Casi nunca llega con una línea que diga quién depura el código propio, con qué criterio y en qué fecha. Esa omisión no se resuelve sola: se traslada.
El insumo que no se improvisa: un año de uso
Para que el dato de uso sea confiable se recomienda recolectarlo durante un año completo con SCMON y SUSG, de modo que queden capturadas las funcionalidades de cierre trimestral y de cierre anual (SAP Tutorials, 2026). Esa sola condición convierte la limpieza en una decisión de calendario y no en una tarea de la fase de realización.
En una distribuidora eléctrica esa ventana no es un tecnicismo. El meter-to-cash tiene estacionalidad propia: ciclos de lectura y facturación que rotan por zona, procesos de refacturación masiva que solo se disparan ante eventos puntuales, reportes regulatorios anuales, actualizaciones tarifarias, campañas de recuperación de cartera. Un programa Z que se ejecuta una sola vez al año —el que arma el reporte al ente de control, el que reprocesa consumos de un período fiscal— aparece como “no usado” si el monitoreo duró tres meses. Y si aparece como no usado, se borra un objeto que la operación necesitaba.
La consecuencia práctica es directa: la decisión de encender SCMON es anterior al arranque formal del proyecto de conversión. Si el comité aprueba el proyecto y recién ahí pregunta por los datos de uso, la limpieza ya perdió su turno.
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#B89C5C'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#B89C5C'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#B89C5C'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#B89C5C'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#d1bf95'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([La decisión de limpiar el ERP]) --> B{¿Cuándo se enciende SCMON?}
B -->|Antes| C[Recolección de un año completo con SCMON y SUSG]
C --> D[Quedan capturados los cierres trimestral y anual]
D --> E([Limpiar el ERP de origen una vez, antes de convertir])
B -->|Después| F[El comité pregunta por los datos de uso con el proyecto aprobado]
F --> G[La limpieza ya perdió su turno]
G --> H([Arrastrar la limpieza por cada ciclo posterior])
class A inicio
class B decision
class C,D,F,G proceso
class E bueno
class H neutro
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
Por qué el orden que recomienda SAP no es un detalle
SAP señala que, en promedio, entre el 40 % y el 60 % del código propio no llega a ejecutarse en el entorno productivo, y su recomendación explícita es depurar el código no utilizado antes de la migración (SAP Community, 2017). El ABAP Call Monitor —transacción SCMON— existe justamente para eso: registrar qué objetos ABAP se ejecutan realmente en producción, no cuáles figuran en el catálogo de desarrollo.
Limpiar primero reduce el universo que hay que analizar, adaptar, probar y volver a probar. Limpiar después significa que ese universo completo cruza la frontera hacia S/4HANA y se convierte en patrimonio permanente: todo lo que viaja hay que mantenerlo, aunque nunca se haya ejecutado.
El mecanismo existe y está documentado
El scoping de código propio permite determinar qué desarrollos se usan activamente en producción y deben llevarse a S/4HANA. El código que queda fuera de alcance puede empaquetarse en órdenes de transporte de borrado y eliminarse durante la conversión del sistema con Software Update Manager (SAP Help Portal, 2026). No es una limpieza artesanal a criterio de cada desarrollador: es un artefacto trazable, con contenido verificable, que se ejecuta dentro de la misma ventana técnica de la conversión.
Nótese dónde está el primer paso de ese mecanismo: la activación de SCMON en producción, antes de que exista un plan de conversión. Todo lo demás depende de que alguien haya activado el monitoreo a tiempo.
La aritmética del cronograma en LATAM
El margen no es infinito. SAP provee mantenimiento mainstream para las aplicaciones core de SAP Business Suite 7 hasta el final de 2027, seguido de un mantenimiento extendido opcional hasta el final de 2030 (SAP Support Portal, 2020). A eso se suma la agenda regulatoria: en Colombia, por ejemplo, las condiciones para la implementación de la infraestructura de medición avanzada en el Sistema Interconectado Nacional fijan obligaciones propias para el operador de red (CREG, 2022), con su propio consumo de capacidad técnica y de presupuesto.
Un comité de TI que enfrenta simultáneamente ambos calendarios tiende a la misma conclusión defensiva: convertir lo antes posible, mover todo tal como está, y “limpiar después, en régimen”. Es una decisión comprensible y significativamente más cara. Cada ciclo posterior vuelve a pagar el mismo trabajo de análisis, adaptación y regresión sobre código que nunca se ejecutó; y ese pago se repite mientras el objeto siga en el sistema.
Restar un año a la fecha de arranque no alarga el proyecto: define si el proyecto entrega un core más chico o solo un core que compila.
Cómo se ve la decisión bien tomada
Una limpieza con dueño en el cronograma se reconoce por cinco señales concretas:
- Hay una fecha de activación de SCMON en producción, anterior al inicio de la conversión, y un responsable nombrado.
- La ventana de recolección cubre los cierres estacionales del meter-to-cash, no solo el trimestre más cercano al proyecto.
- El criterio de alcance está escrito antes de mirar los resultados, para que no se negocie objeto por objeto bajo presión de fecha.
- La orden de transporte de borrado se revisa como artefacto —contenido explícito, respaldo previo del código retirado—, no como un checkbox.
- El comité acepta que el resultado esperado del ejercicio es un core más chico, y no solo un core que compila.
La diferencia entre las dos rutas no está en la calidad técnica del equipo. Está en si alguien puso la limpieza en el calendario cuando todavía se podía. Después de la conversión, la misma tarea sigue disponible —pero ya no es una decisión de proyecto: es una línea permanente en el costo de operación.
Y ahí empieza el capítulo siguiente de esta serie: la fase Run no es soporte, es donde el eje de limpieza sigue corriendo.
Fuentes
- SAP Community. ABAP Call Monitor (SCMON) – Analyze usage of your code. https://community.sap.com/t5/application-development-and-automation-blog-posts/abap-call-monitor-scmon-analyze-usage-of-your-code/ba-p/13313572
- SAP Help Portal. Custom Code Migration Guide for SAP S/4HANA. https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.001/en-US/CustomCodeMigration_EndtoEnd.pdf
- SAP Tutorials. The Ultimate Guide To SAP S/4HANA Custom Code Migration. https://www.saptutorials.in/sap-s-4hana-custom-code-migration/
- SAP Support Portal. Innovation Commitment for SAP S/4HANA until 2040. https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
- CREG. Resolución No. 101 001 de 2022. https://gestornormativo.creg.gov.co/gestor/entorno/docs/resolucion_creg_101-1_2022.htm
¿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.
