Transformación hacia Clean Core · 1 de 8
Clean Core: qué significa realmente para una gerencia de TI
En resumen
Clean Core es el principio de mantener el núcleo de SAP lo más cerca posible del estándar, resolviendo las necesidades del negocio mediante configuración y extensiones gobernadas en lugar de modificaciones al código de SAP. Su objetivo no es prohibir el desarrollo propio, sino garantizar que cada actualización del ERP sea un trámite planificable y no un proyecto de riesgo.
Durante veinte años, la respuesta natural en SAP a una necesidad no cubierta fue modificar el sistema. Funcionó: cada modificación resolvió un problema real. El problema es que el coste no se pagó entonces, sino que se fue acumulando.
Qué es Clean Core
Clean Core es el principio de mantener el núcleo de SAP lo más cerca posible del estándar, resolviendo las necesidades del negocio mediante configuración y extensiones gobernadas en lugar de modificaciones al código de SAP.
Conviene desmontar de entrada el malentendido más común: Clean Core no significa “sin desarrollos propios”. Significa que los desarrollos propios viven en un sitio distinto y bajo reglas distintas. La diferencia no es cuánto se desarrolla, sino si lo desarrollado sobrevive a la siguiente actualización.
Por qué es una conversación de gerencia, no de desarrollo
La tentación es tratarlo como una preferencia técnica. No lo es, porque determina directamente dos cifras del presupuesto.
El coste de cada actualización. En un sistema con modificaciones profundas, un upgrade obliga a revisar cada objeto tocado, reconciliar conflictos y ejecutar una regresión completa. Es un proyecto. En un sistema limpio es una tarea planificable con una ventana de mantenimiento.
La velocidad de adopción. Cuando SAP publica una funcionalidad nueva, una organización con el core limpio la evalúa y la activa. Una con el core modificado primero tiene que averiguar si choca con lo que ya tiene. Esa diferencia se mide en trimestres.
Hay un tercer efecto, menos visible pero más caro a largo plazo: el conocimiento cautivo. Cada modificación no documentada es una dependencia de la persona que la escribió. Cuando esa persona se va, el sistema conserva un comportamiento que nadie sabe justificar y que nadie se atreve a tocar.
La pregunta que cambia
El giro de Clean Core se resume en cambiar la pregunta de partida:
| Antes | Ahora |
|---|---|
| ¿Cómo modificamos SAP para cubrir esta necesidad? | ¿Existe una forma estándar o una extensión gobernada para resolverla? |
Parece un matiz semántico. En la práctica cambia quién toma la decisión: la primera pregunta se responde en el equipo de desarrollo; la segunda exige arquitectura.
Las dimensiones del problema
Clean Core suele reducirse a “no modificar código”, pero abarca varias dimensiones que conviene tener presentes:
- Extensiones — cómo se construye lo que el estándar no cubre. Es la dimensión con más impacto y la que trataremos en profundidad en esta serie.
- Integraciones — si los sistemas se conectan por interfaces publicadas o por accesos directos a tablas.
- Datos — si el modelo de datos se mantiene consistente con el estándar.
- Procesos — cuánto se aleja la operación real del proceso que SAP soporta.
- Operación — si el ciclo de vida del sistema está automatizado y es auditable.
Un core puede estar limpio en código y sucio en integraciones. Es un caso frecuente: nadie modificó un programa estándar, pero hay quince interfaces leyendo tablas directamente. El efecto sobre un upgrade es el mismo.
Cómo saber en qué punto estás
Antes de plantear cualquier hoja de ruta, hay tres preguntas que se responden con datos, no con opiniones:
- ¿Cuántos objetos Z tienes y cuántos se ejecutan de verdad? La brecha entre ambas cifras suele ser enorme. El código que nadie ejecuta se puede retirar sin negociar con nadie.
- ¿Cuántos son modificaciones al estándar y cuántos son desarrollos propios? No es lo mismo. Un programa Z independiente molesta poco; una modificación a un objeto de SAP condiciona cada upgrade.
- ¿Cuántas de tus integraciones usan APIs publicadas? Las que no, son deuda igual que el código.
SAP ofrece herramientas para levantar este inventario —el Custom Code Migration y los chequeos de ATC, entre otras—. Lo importante no es la herramienta: es que la conversación arranque con un número y no con una impresión.
El error de plantearlo como un proyecto de limpieza
Clean Core no se alcanza con una campaña de limpieza puntual. Un sistema se vuelve a ensuciar en dieciocho meses si no cambian las reglas de decisión.
Por eso esta serie no empieza por la tecnología. El orden es deliberado:
- Este artículo — qué es y por qué importa a la dirección.
- S/4HANA Cloud Private Edition — hacia qué se migra y qué cambia.
- Extensibilidad — cómo decidir antes de desarrollar.
- SAP BTP — dónde viven las extensiones que salen del core.
- ABAP Cloud — cómo cambia el trabajo de quien desarrolla.
- Gobierno — cómo evitar volver al punto de partida.
- Migración — cómo ejecutar la transición.
- SAP Business AI — qué habilita tener el core preparado.
En una frase
Clean Core no es una restricción técnica: es la decisión de que el coste de mantener el ERP deje de crecer con cada necesidad nueva.
¿Quieres saber en qué punto está tu sistema? En una sesión de consultoría revisamos tu inventario de código propio y sales con una propuesta técnica y una estimación formal.