El Minotauro no era el único peligro del laberinto de Creta. El verdadero enemigo era una arquitectura diseñada para impedir el regreso.
Teseo pudo entrar porque tenía valor; pudo salir porque Ariadna le entregó un hilo. En muchos entornos SAP ocurre algo parecido. Entrar en una personalización suele ser fácil: aparece una necesidad urgente, se escribe un desarrollo y el negocio continúa. Años después, nadie recuerda todas las dependencias. Cada actualización amenaza con romper un rincón distinto y el sistema conserva caminos que solo conoce quien los construyó.
La estrategia clean core no consiste en prohibir toda extensión. Consiste en conservar el hilo.
Qué significa realmente mantener un núcleo limpio
SAP organiza clean core alrededor de cinco ámbitos: procesos empresariales, extensibilidad, datos, integración y operaciones. El objetivo es reducir complejidad innecesaria, mantener el ERP actualizable y reservar las extensiones para capacidades que aportan una diferencia medible.
Un núcleo limpio no es un sistema idéntico al de todas las empresas. Una organización puede necesitar procesos propios, interfaces especializadas o una experiencia de usuario distintiva. La cuestión es dónde viven esas diferencias, mediante qué contratos se conectan y quién garantiza que seguirán funcionando después de la siguiente actualización.
Cómo nace un laberinto
La complejidad rara vez aparece en un único gran proyecto. Se acumula en decisiones pequeñas: una modificación directa para resolver una urgencia, una interfaz punto a punto, una copia de datos sin propietario, una transacción que solo entiende un usuario veterano.
Cada decisión puede ser razonable por separado. El problema aparece cuando nadie mantiene el mapa conjunto. Entonces surgen cuatro costes:
- Las actualizaciones requieren más pruebas y correcciones.
- Los procesos dependen de conocimiento difícil de reemplazar.
- Las integraciones duplican datos y reglas.
- La innovación se retrasa porque cualquier cambio parece peligroso.
El hilo: contratos, catálogo y responsabilidad
Usar interfaces liberadas
Las extensiones desacopladas mediante APIs, eventos y puntos de extensión publicados reducen la dependencia de estructuras internas. SAP BTP ofrece patrones para desarrollar capacidades side-by-side; las extensiones on-stack siguen teniendo su lugar cuando utilizan mecanismos soportados y están gobernadas.
Clasificar antes de tocar
No toda personalización merece migrarse. Conviene clasificar cada objeto: retirar, sustituir por estándar, rediseñar o conservar. La existencia de código no demuestra que siga aportando valor. El uso real, el riesgo y la criticidad deben decidir su destino.
Asignar un propietario
Una extensión sin propietario envejece sin testigos. Cada capacidad necesita un responsable funcional, un responsable técnico, documentación, pruebas y una política de ciclo de vida.
Medir la salud del núcleo
Clean core debe convertirse en un sistema de control, no en un lema. Pueden medirse modificaciones, uso de APIs liberadas, automatización de pruebas, excepciones arquitectónicas, tiempo de actualización y deuda técnica retirada.
Una ruta de salida en cinco movimientos
- Inventariar: desarrollos, interfaces, ampliaciones, formularios, jobs y dependencias.
- Observar: comprobar qué se utiliza y con qué frecuencia.
- Decidir: retirar, estandarizar, rediseñar o mantener.
- Desacoplar: mover reglas y experiencias donde puedan evolucionar sin dañar el núcleo.
- Gobernar: impedir que la siguiente urgencia reconstruya el mismo laberinto.
La trampa de la pureza
Una estrategia obsesionada con la limpieza puede convertirse en otro dogma. El objetivo no es alcanzar una puntuación estética, sino mejorar capacidad de cambio, estabilidad y coste total. Puede haber excepciones justificadas. Lo importante es que sean visibles, temporales cuando sea posible y aprobadas por quien asume su coste futuro.
También sería ingenuo pensar que una plataforma elimina por sí sola la complejidad organizativa. Si Finanzas, Operaciones e IT no acuerdan responsabilidades, la arquitectura reflejará ese desacuerdo con herramientas más modernas.
Clean core como disciplina de gobierno
El cambio más difícil no suele ser técnico. Mientras los equipos sean premiados únicamente por resolver la urgencia de hoy, continuarán aceptando deuda que pagará otra persona mañana. Hace falta un proceso ligero para evaluar excepciones: valor empresarial, alternativa estándar, impacto en actualizaciones, propietario y fecha de revisión.
Ese proceso no debe convertirse en un tribunal interminable. Las extensiones pequeñas y soportadas pueden seguir una vía rápida; las modificaciones de alto impacto requieren arquitectura y negocio. El catálogo debe mostrar no solo qué existe, sino por qué fue aprobado y qué señales obligarían a retirarlo.
La relación entre núcleo limpio e inteligencia artificial
La IA aumenta el coste de la ambigüedad. Si existen cinco definiciones de cliente activo, un asistente encontrará cinco respuestas plausibles. Si una regla importante vive escondida en una modificación sin documentación, un agente puede actuar ignorándola.
Procesos estandarizados, datos gobernados e interfaces publicadas no garantizan una IA fiable, pero crean una superficie que puede comprenderse, probarse y auditarse. Clean core deja de ser entonces una conversación exclusiva sobre actualizaciones: se convierte en la preparación estructural para analítica y automatización.
Un programa que pueda sobrevivir al primer entusiasmo
Una hoja de ruta realista combina victorias visibles con trabajo de fondo. Puede comenzar retirando objetos sin uso, documentando las integraciones críticas y estableciendo un criterio para nuevas extensiones. Después conviene automatizar controles, incorporar pruebas de regresión y vincular las excepciones a responsables.
El éxito no consiste en declarar que el sistema está limpio una mañana. Consiste en que dentro de dos años las decisiones nuevas sigan respetando el mismo hilo.
La cartera de decisiones arquitectónicas
Conviene registrar las decisiones relevantes en documentos breves: problema, alternativas, elección, consecuencias y fecha de revisión. Así se evita que una generación futura interprete cada excepción como un accidente incomprensible.
La cartera también permite agrupar deuda por dominios. Quizá no sea viable retirar hoy una interfaz crítica, pero sí dejar de añadir consumidores, medir su uso y preparar una sustitución. Clean core progresa cuando la deuda tiene dueño y dirección, no cuando desaparece de una diapositiva.
El papel de negocio
IT no puede decidir por sí sola qué procesos diferencian a la empresa. Los responsables funcionales deben justificar qué variaciones crean valor y aceptar la estandarización del resto. Sin esa conversación, clean core se convierte en una limpieza técnica que el siguiente proyecto volverá a ensuciar.
Salir y poder volver a entrar
El hilo de Ariadna no destruyó el laberinto. Hizo posible atravesarlo sin perderse. Clean core cumple una función semejante: permite que la empresa conserve aquello que la diferencia, pero obliga a que cada desvío tenga un propósito y un camino de regreso.
Un sistema SAP saludable no es el que nunca cambia. Es el que puede cambiar muchas veces sin olvidar cómo está construido.
