El código propio no dejó de ser necesario. Dejó de ser gratis.
La mayoría de los entornos ECC arrastran años de modificaciones, y todas tuvieron sentido en su momento. El coste solo se hizo visible más tarde, al actualizar — cuando cada cambio había que volver a probarlo, reconciliarlo o reescribirlo, y las actualizaciones pasaron en silencio de rutinarias a excepcionales.
Clean core es la disciplina que impide que ese ciclo se reinicie en S/4HANA. No es una regla contra la personalización. Es una regla sobre dónde se le permite vivir a la personalización.
El core permanece estándar para poder seguir avanzando. Todo lo propio vive a su lado y se actualiza en su propio calendario.
Qué significa realmente clean core
El principio se enuncia fácil: el core digital ejecuta procesos estándar, configurados pero no modificados, de modo que las actualizaciones de plataforma puedan adoptarse de forma continua en lugar de en temidos eventos plurianuales. Los requisitos que el estándar genuinamente no puede cubrir se construyen como extensiones — conectadas al core mediante interfaces liberadas, nunca entretejidas en él.
La consecuencia práctica: una actualización deja de ser una negociación con una década de objetos propios. El core se mueve; las extensiones siguen funcionando, porque solo tocaron el core a través de contratos que sobreviven a la actualización.
Las directrices de clean core de SAP distinguen la extensibilidad in-app — puntos de extensión liberados dentro de S/4HANA — de las extensiones side-by-side construidas sobre SAP Business Technology Platform y conectadas mediante APIs liberadas.
Tres preguntas antes de cualquier extensión
¿Lo cubre el estándar tras configurarlo?
Una proporción sorprendente de los “requisitos” son costumbres importadas del sistema anterior. Un taller fit-to-standard existe para separar lo que el negocio necesita de lo que la implantación anterior hacía por casualidad.
Si no — ¿cabe dentro de los puntos de extensión liberados?
Campos añadidos, adaptaciones de interfaz y lógica de negocio acotada suelen caber dentro de la extensibilidad in-app, que está diseñada para sobrevivir a las actualizaciones. Es el hogar más barato que puede tener una extensión.
Si no — va al lado del core, no dentro de él
Aplicaciones completas, lógica pesada y orquestación entre sistemas pertenecen a la plataforma de al lado, hablando con el core mediante APIs liberadas. La única respuesta inaceptable es la antigua: modificar el core porque lo tiene a mano.
Requisito→Comprobación fit-to-standard→Punto de extensión in-app→Side-by-side en BTP
Lo que cuesta realmente el side-by-side
Aquí la honestidad importa, porque el intercambio es real. Una extensión side-by-side es una aplicación en marcha: arrastra suscripción de plataforma, una superficie de integración que hay que vigilar y un ciclo de vida propio. Medida sobre un único requisito, puede parecer más cara que la modificación a la que sustituye.
Medida a lo largo de la vida de la plataforma, la comparación suele invertirse. El precio real de la modificación nunca fue su coste de construcción — fue cada actualización que complicó después, multiplicada por cada otra modificación a su lado. Clean core convierte un pasivo futuro indefinido en un coste corriente acotado.
Qué va dónde
- Configuración, no modificación, dentro del core — procesos estándar ajustados mediante parámetros soportados.
- Extensibilidad in-app para campos añadidos, pantallas adaptadas y lógica acotada que pertenece al proceso que toca.
- Side-by-side en la plataforma para aplicaciones propias, lógica diferenciadora y todo lo que integre varios sistemas.
- Nada en el código base del core. Si un requisito parece exigirlo, el requisito merece una segunda mirada antes que el core.
Perspectiva de VISCAP
Trate cada solicitud de extensión como una hipoteca sobre todas las actualizaciones futuras. La mayoría de las solicitudes no sobrevive a ese encuadre.
Las organizaciones que sufren con clean core rara vez son las que más requisitos tienen. Son las que no tienen una ruta de decisión — donde cada solicitud se discute caso por caso y gana la voz más alta. Las tres preguntas anteriores son deliberadamente mecánicas: convierten el gobierno de las extensiones de un debate en una regla de enrutado.
Las actualizaciones son la cuestión
Un core limpio no es una estética. Es lo que convierte la hoja de ruta de la plataforma — incluido todo lo que SAP entregue a continuación — en algo que su organización recibe en lugar de volver a comprar. La disciplina se paga sola la primera vez que una actualización resulta aburrida.