Clean Core es un estándar que se sostiene, no un proyecto que se termina — el menos invasivo de los tres niveles de SAP. VISCAP lo sostiene: evaluación, remediación, arquitectura de extensiones, gobernanza de versiones.
Ocho áreas de capacidad, nombradas antes que cualquier herramienta — cada una es un entregable, no una política, una licencia o una puntuación de madurez.
Extensibilidad in-app de SAP S/4HANAHerramientas para key users
El primer nivel que probar — nada sale de los puntos de extensión autorizados, así que sobrevive a cada actualización.
ABAP CloudExtensibilidad para desarrolladores de SAP S/4HANA
Más allá de las herramientas para key users — el mismo lenguaje, un contrato más estrecho.
SAP BTP ABAP environmentSAP Build CodeSAP Business Application StudioSAP Cloud Application Programming Model
Para cualquier cosa sustancial: lógica fuera del núcleo, con su propio ciclo de release.
SAP Build AppsSAP Build Process AutomationSAP Build Work Zone
La gobernanza importa más que las herramientas — el low-code sin gobernar reconstruye la deuda en otro sitio.
SAP Integration SuiteAPI ManagementSAP Event Mesh
Las integraciones punto a punto que llegan a las tablas del núcleo no son limpias.
Análisis de código a medida de SAPGestión de transporte y ciclo de vida
El análisis de uso a menudo encuentra objetos sin usar durante años — retirarlos es el trabajo de Clean Core más económico disponible.
Clean Core funciona como una disciplina, no como un mandato — VISCAP cubre todo el arco, desde el inventario de objetos personalizados hasta la gobernanza de releases que evita que la deuda se reconstruya. Aquí es donde encaja cada etapa y qué es lo que asumimos.
Clean Core afecta a casi todas las partes de un entorno SAP — el código, las interfaces, el calendario de releases, la forma en que las personas construyen. Estos ocho servicios lo cubren.
Todos los servicios de VISCAPEvalúe la posición de Clean Core: personalización, deuda técnica, extensibilidad, preparación para la actualización.
Mantenga el estándar de Clean Core en nuevas implementaciones y despliegues.
Inventario de código a medida, análisis de uso, retirada, remediación y reconstrucción como extensiones side-by-side.
Integración de Clean Core: racionalización de interfaces, conexiones punto a punto migradas a API y eventos gobernados.
Informes personalizados trasladados de objetos del núcleo modificados a vistas liberadas y analítica gobernada.
Opere el inventario de extensiones, los controles de transporte y ciclo de vida, y las salvaguardas para las nuevas construcciones.
Evaluación del impacto del release, seguimiento de funcionalidades obsoletas, alcance de la regresión y backlog de actualizaciones.
Capacite a key users y desarrolladores en los niveles de extensibilidad, para que se elija el adecuado sin ayuda.
RR. HH. y talento estandarizados entre los equipos de planta y corporativos — un único modelo para la plantilla de fabricación de vidrio.
El ciclo de vida completo del empleado en una sola capa de SuccessFactors, en operaciones distribuidas de agronegocio y productos orgánicos.
Dónde encaja la lógica de extensión una vez que el núcleo queda fuera de los límites, y qué cuesta el side-by-side en SAP BTP.
El informe da un recuento — no cuáles objetos importan, cuáles están muertos ni cuáles merece la pena reconstruir.
Clean Core significa que el núcleo se mantiene estándar: la personalización utiliza puntos de extensión autorizados, no modificación. Las actualizaciones siguen siendo rutinarias porque su lógica nunca tocó los elementos internos que cambian.
No — la personalización sigue existiendo, solo cambia dónde: herramientas para key users, ABAP Cloud o side-by-side en SAP BTP, nunca modificando el código estándar.
Tres niveles, de menos a más invasivo: in-app para key users; extensibilidad para desarrolladores mediante ABAP Cloud; side-by-side en SAP BTP. Deténgase en el primer nivel que funcione.
ABAP Cloud es el modelo de desarrollo restringido para el SAP moderno: el mismo lenguaje, limitado a API y objetos liberados — a prueba de actualizaciones, y las competencias en ABAP se mantienen vigentes.
Una API o un evento liberado es el contrato publicado y estable de SAP. Construya sobre objetos liberados, no sobre tablas, para mantener las extensiones a prueba de actualizaciones.
SAP BTP aloja las extensiones side-by-side: el ABAP environment, SAP Build Code y SAP Build Apps construyen aplicaciones personalizadas sobre datos de SAP a través de interfaces gobernadas, con versiones que se liberan con independencia del núcleo.
Un núcleo con decenas de interfaces punto a punto hacia sus tablas no está limpio. Integration Suite traslada esas interfaces a API y eventos gobernados — un contrato publicado, no una dependencia oculta.
No del todo, pero inventariar y retirar primero suele salir más barato: el análisis de uso a menudo encuentra objetos sin usar durante años, algo mejor decidido antes del traslado que a mitad de la conversión.
Empezamos con un inventario de desarrollo personalizado y un análisis de uso: qué existe, qué se ejecuta y qué depende de objetos no liberados — un panorama de la deuda técnica, una línea base de preparación para la actualización y una lista de brechas que sustentan la estrategia de extensibilidad y el plan de remediación.
Sí — es el tipo de proyecto más habitual, ya que la mayoría de los entornos S/4HANA se desvían tras el go-live. El mismo tipo de trabajo: inventario, remediación, reconstrucción de la lógica en side-by-side, racionalización de interfaces y gobernanza para sostener la posición.
Hable con los arquitectos SAP de VISCAP sobre su posición en código a medida, su ciclo de actualizaciones y cuánto núcleo sigue modificando.