El costo de no gobernar el core: la deuda que migra hacia adelante
Qué le ocurre a una utility que trata el clean core como un proyecto con fecha de cierre: la deuda migra y el próximo upgrade repite el infierno.
· 11 min de lectura
El día que cierra una conversión a S/4HANA ocurre algo que parece un éxito y funciona como una trampa: el equipo se disuelve. El comité de arquitectura deja de reunirse porque ya no hay proyecto que gobernar. La política de extensibilidad queda en un documento que nadie vuelve a abrir. Y el sistema —limpio, medido, entregado— queda solo.
Esta es la última entrega de una serie sobre por qué volver a tocar el core repite el mismo infierno. Después del diagnóstico, la medición y la cadencia, queda la pregunta que pocos comités responden en voz alta: ¿qué pasa exactamente si no se hace nada?
La respuesta no es dramática. Es aritmética.
El proyecto termina; la deuda, no
El error de encuadre es anterior a cualquier decisión técnica. El clean core no es un proyecto de una sola vez: es una disciplina continua, un recorrido que se ejecuta típicamente de forma incremental a lo largo de varios años (Saptutorials, 2026).
Esa misma guía separa el trabajo en dos mitades con nombres útiles: Get Clean —reducir la deuda existente— y Stay Clean —impedir que se genere deuda nueva (Saptutorials, 2026). Un proyecto de conversión es, casi por definición, puro Get Clean. Tiene alcance, presupuesto y fecha de cierre. Stay Clean no tiene ninguna de las tres cosas, y por eso casi nunca se presupuesta.
El resultado de hacer solo la primera mitad no es un core limpio. Es la fotografía de un core limpio, tomada el día del go-live, que empieza a envejecer al día siguiente.
El reloj que corre aunque nadie lo mire
Aquí está el mecanismo que convierte una omisión de gobierno en un proyecto forzado.
Desde el release 2023, cada versión de SAP S/4HANA permanece siete años en mantención principal, frente a los cinco de los releases anteriores (SAP News Center, 2022). Para SAP S/4HANA Cloud Private Edition existe un requisito concreto: instalar al menos un upgrade cada siete años para seguir dentro de la mantención principal (SAP Learning).
Siete años suena a holgura. No lo es, por un detalle que suele pasarse por alto: cuando sale el siguiente release base, el anterior deja de recibir Feature Package Stacks y pasa a recibir Support Package Stacks cada seis meses solo con correcciones, sin funcionalidad nueva, hasta el fin de la mantención principal (SAP Learning).
La organización queda entonces en la peor combinación posible: sin innovación entrante y con deuda saliente. Y llega el vencimiento con una remediación acumulada de años, no de un trimestre. En despliegues on-premise la presión es aún más directa, porque el cliente es completamente responsable de implementar todos los aspectos del upgrade (SAP Learning).
Es, punto por punto, el mismo infierno que motivó la conversión original.
Lo que se acumula mientras nadie mira
Conviene ser específico sobre qué se acumula, porque el término «deuda técnica» es lo bastante abstracto como para no asustar a nadie.
El nivel D —el de mayor riesgo— incluye modificaciones a objetos estándar de SAP, escrituras directas a tablas de base de datos y ampliaciones implícitas; genera deuda técnica significativa y debe priorizarse para remediación (Saptutorials, 2026). El nivel C usa objetos internos de SAP no liberados; parte de ese riesgo se mitiga con un registro de cambios sobre los objetos de SAP que permite anticipar cambios que rompen, pero exige monitoreo, planes de refactorización y propiedad clara (Saptutorials, 2026).
Ninguna de esas dos categorías se anuncia. Aparecen de a una, cada una con una justificación razonable, y solo se vuelven visibles cuando alguien las cuenta.
Hay además un indicador que casi nadie mira y que en una utility duele especialmente: el Unused Code Share, la proporción de objetos personalizados que ya no se usan (Saptutorials, 2026). Ese código no aporta nada al negocio y, sin embargo, se prueba, se transporta y se remedia en cada upgrade. Se paga por él en cada ciclo, indefinidamente, hasta que alguien decide retirarlo.
De la política al control: por qué un documento no sostiene nada
La diferencia entre las organizaciones que sostienen el gobierno y las que lo pierden no es la calidad de su política de extensibilidad. Es si esa política está conectada a algo que pueda bloquear un transporte.
Las guías por sí solas no bastan; el clean core se sostiene con controles técnicos concretos (Saptutorials, 2026):
- Restringir el lenguaje: limitar las versiones del lenguaje ABAP mediante autorizaciones.
- ATC en la liberación: checks de ABAP Test Cockpit obligatorios al liberar el transporte.
- Bloquear lo crítico: detener transportes con hallazgos críticos salvo exención formal.
- Pruebas automatizadas: ABAP Unit automatizado, en especial para los niveles B, C y D.
Eso es lo que convierte el clean core de «mejor esfuerzo» en procedimiento operativo estándar (Saptutorials, 2026). Un comité que solo emite recomendaciones no gobierna: opina. El control vive en el punto donde el código pasa —o no pasa— al siguiente sistema.
La cuenta, en la moneda de una utility latinoamericana
SAP es explícita sobre la relación entre disciplina y costo: seguir los principios de clean core reduce el impacto del upgrade y lo convierte en una parte fluida del ciclo de vida del software, mientras que SAP Readiness Check evalúa la condición del sistema para ese upgrade incluyendo código personalizado, uso de compatibility packs y add-ons (SAP Community).
Léalo al revés y tiene el costo de no gobernar: cuanto más código personalizado, más desviaciones y más objetos sin retirar, mayor es el alcance —y el calendario— del próximo proyecto de upgrade.
Para una distribuidora eléctrica u operadora de oil & gas de la región, esa factura no se paga en abstracto. Se paga compitiendo con inversión en reducción de pérdidas no técnicas, en despliegue de medición, en mejora de recaudación. Se paga en ventanas de mantenimiento que chocan con el ciclo de lectura y el cierre de facturación. Y se paga en la credibilidad del área de TI, que vuelve a pedir un presupuesto extraordinario para resolver algo que ya se había resuelto.
La alternativa es deliberadamente modesta. La misma guía propone una meta incremental —reducir la deuda técnica alrededor de un 10 % al año— apoyada en el principio del boy scout: dejar el código más limpio de como se encontró, sin proyectos de limpieza disruptivos (Saptutorials, 2026).
Un core limpio no es un estado que se alcanza. Es un estado que se mantiene.
El proyecto de conversión compró estabilidad de upgrade. Lo que decide si esa estabilidad dura no es la calidad de la conversión: es lo que la organización haga en los cuatro trimestres siguientes, y en los cuatro después de esos. Con esta entrega cierra la serie, y la conclusión es incómodamente simple: el core no se ensucia por una mala decisión, sino por la ausencia sostenida de decisiones.
Fuentes
- Saptutorials.in (2026). SAP Clean Core Extensibility: A Practical, Risk-Based Guide for Modern Consultants — 2026 Edition.
- SAP Learning. Navigating Release Upgrades – Implementing SAP S/4HANA Cloud Private Edition.
- SAP News Center (2022). New SAP S/4HANA Release and Maintenance Strategy to Deliver Greater Innovation and Flexibility.
- SAP Community. SAP System Upgrade: SAP Cloud ERP Private (página de topic de upgrade de SAP S/4HANA).
¿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.
