El marco A-D de SAP: mida qué tan limpio está su core

Antes de gobernar, hay que medir

En la pieza anterior de esta serie, EvoTech Consulting analizó cómo el core de S/4HANA se ensucia sin que nadie tome esa decisión formalmente: excepción tras excepción, decisión razonable tras decisión razonable, hasta que la estabilidad de upgrade ganada en la conversión se erosiona. Ese diagnóstico deja una pregunta abierta, y es la que aborda esta pieza: si nadie decidió ensuciar el core deliberadamente, ¿cómo saber qué tan sucio está realmente hoy?

La respuesta no puede ser un juicio subjetivo caso por caso. Necesita un criterio objetivo, aplicable a cada extensión que ya vive en el sistema — sea una integración AMI, un reporte de facturación a medida o un ajuste heredado de un proyecto anterior. Ese criterio existe, y es oficial de SAP.

El marco A-D: cuatro niveles, un solo criterio

SAP formalizó en agosto de 2025 un modelo de cuatro niveles para clasificar cada extensión personalizada según su cercanía real al ideal de core limpio (IgniteSAP, 2026). El criterio detrás de cada nivel es exigente pero verificable: qué tipo de objeto SAP usa la extensión y qué tan expuesta queda esa extensión al riesgo de romperse en el próximo upgrade.

Este marco reemplaza al antiguo modelo de tres niveles (“tier 1-3”) de SAP, y su ventaja frente a un simple “limpio o no limpio” es que habilita la priorización: no hace falta llegar al Nivel A de un salto para empezar a gobernar, sino identificar primero qué extensiones están en el Nivel D — las que concentran el mayor riesgo — y moverlas hacia arriba de forma escalonada (IgniteSAP, 2026).

Por qué esto no es solo teoría técnica

Para una práctica SAP enterprise, este marco no es un ejercicio académico de clasificación. Es la base indispensable de cualquier conversación seria sobre riesgo con el negocio. Sin un criterio objetivo como este, “gobernar el core” se reduce a discusiones subjetivas sobre qué extensión es aceptable y cuál no — exactamente el tipo de ambigüedad que, como se planteó en la pieza anterior, permite que cada excepción puntual se cuele sin control.

Con el marco A-D, en cambio, cada extensión existente en el sistema — cada integración, cada personalización heredada, cada “parche urgente” que se resolvió tocando el core directamente — puede clasificarse con un criterio verificable: qué tipo de objeto SAP referencia y qué tan lejos está de las APIs liberadas que SAP garantiza mantener estables entre versiones. En nuestros proyectos, EvoTech Consulting aplica este mismo principio para transformar una discusión de opiniones en una discusión de evidencia técnica antes de comprometer cualquier plan de remediación.

Qué significa esto para utilities y oil & gas en LATAM

En el contexto de servicios públicos y energía de la región, este ejercicio de clasificación suele revelar más extensiones de Nivel C y D de las que la organización anticipa. Integraciones construidas bajo presión operativa — para resolver desbalances de lecturas en Comercial y Facturación, para absorber la latencia de concentradores AMI, o para dar salida a un reporte regulatorio con fecha límite — tienden a apoyarse en el camino más rápido disponible en el momento, no necesariamente en el más limpio.

Eso no convierte automáticamente cada una de esas extensiones en un problema urgente: parte del valor del marco A-D es precisamente que no exige tratar todo por igual. Una extensión de Nivel C, condicionalmente limpia, puede convivir con el sistema mientras se monitorea su exposición; una de Nivel D, en cambio, merece prioridad de remediación porque concentra el mayor riesgo de romperse en el próximo ciclo de actualización. La clasificación es lo que permite distinguir entre ambos casos con criterio, en lugar de tratar cualquier excepción histórica como una emergencia — o, en el extremo opuesto, ignorarlas a todas por igual.

Lo que sigue

Tener el mapa de niveles A-D de cada extensión resuelve la pregunta de “qué tan limpio está” el sistema hoy. Pero clasificar no es lo mismo que decidir qué hacer con esa clasificación: quién aprueba que una extensión nueva se construya en Nivel B en lugar de Nivel A, o quién autoriza que una extensión de Nivel D se mantenga un ciclo más mientras se prioriza su remediación. Esa es la pregunta que aborda la siguiente pieza de esta serie: quién dice sí y quién dice no, y por qué el core limpio necesita un comité, no solo una intención.

Fuentes

• IgniteSAP, “SAP’s Clean Core in Practice” (2026): https://ignitesap.com/saps-clean-core-in-practice/