Clean core: la revisión trimestral que evita gobernar por crisis

Noventa minutos. Cuatro personas. Una vez cada tres meses. Y una regla de salida: nadie se levanta de la mesa sin decisiones con dueño y fecha de vencimiento.

Esa reunión —no una herramienta, no una política, no un tablero— es la diferencia práctica entre una distribuidora eléctrica que descubre sus problemas cuando ya son urgencias y una que los ve llegar con un trimestre de margen. El capítulo anterior de esta serie mostró cómo convertir el principio de clean core en un número gobernable. Este trata de algo mucho más aburrido y bastante más decisivo: la casilla del calendario donde ese número se mira y se decide.

Lo aburrido es el punto. En las operaciones latinoamericanas con las que trabajamos —equipos técnicos pequeños, ventanas de mantenimiento estrechas, presupuestos que se defienden línea por línea— lo único que sobrevive al año fiscal es aquello que cabe en un calendario y no depende de que alguien se acuerde de hacerlo.

Noventa minutos, cuatro decisiones: la mecánica antes que el principio

La reunión tiene una forma concreta, y la preparación empieza la semana anterior, no el mismo día.

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#B89C5C'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#B89C5C'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#B89C5C'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#B89C5C'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#d1bf95'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Semana previa: armar el paquete]) --> B[Corrida de ATC y exportación al tablero]
  B --> C[Comparativo contra el trimestre anterior]
  C --> D[Bloque 1: leer la deriva]
  D --> E{Bloque 2: ¿qué se hace con la excepción?}
  E -->|Renovar| F[Excepción renovada]
  E -->|Revocar| G[Excepción revocada]
  E -->|Remediar| H[Tarea de remediación con fecha]
  F --> I([Cierre: comprometer])
  G --> I
  H --> I
  class A inicio
  class E decision
  class B,C,D,F,G,H proceso
  class I bueno
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff

La mesa mínima es corta: arquitecto líder, responsable de desarrollo ABAP, dueño del proceso meter-to-cash y responsable de operaciones TI. En una utility, ese cuarto asiento no es decorativo: es quien sabe si la ventana de mantenimiento del próximo trimestre choca con el ciclo de lectura o con el cierre de facturación.

La forma de la sesión importa tanto como su frecuencia. Un blog de práctica de arquitectura empresarial publicado por SAP describe exactamente este artefacto —una revisión trimestral de landscape enfocada por completo en decisiones: qué decisiones están abiertas, cuáles deben tomarse en el trimestre que viene y qué deriva ocurrió que requiere corrección— y advierte explícitamente que la sesión no debe usarse para actualizar documentación (SAP Community, 2026). Ese mismo texto sugiere sostener aparte, con cadencia semanal y junto al arquitecto del programa, el backlog de decisiones abiertas y deuda técnica que bloquea el trabajo inmediato. La revisión trimestral no compite con ese backlog: lo consume.

Hay además un ítem de agenda propio del sector que conviene fijar: verificar si alguna capacidad recién liberada permite retirar un objeto de nivel C o D. SAP publicó una nota específica con la visión integral de clean core para SAP S/4HANA Utilities —la nota 3406389— y en S/4HANA 2025 la extensibilidad de usuario clave se amplió a datos maestros de punto de suministro y a casos de aclaración BPEM (SAP Community, 2025). Cada liberación de ese tipo es una oportunidad de bajar deuda sin escribir una línea de ABAP.

Por qué el trimestre, y no el proyecto ni el mes

La cadencia no es arbitraria: se deriva del ritmo real del producto y de la herramienta.

SAP S/4HANA sigue un ciclo de release base cada dos años, con Feature Package Stacks cada seis meses, y la mantención principal se extendió de cinco a siete años (SAP Learning). En RISE with SAP, el cliente tiene derecho a solicitar un upgrade al año: SAP ejecuta el upgrade técnico, pero la planificación, la preparación y las pruebas siguen siendo responsabilidad del cliente o de su socio de implementación (SAP Learning). Es decir, la ventana en la que usted puede llegar preparado —o no— se mide en trimestres, no en semanas.

El instrumental está calibrado al mismo pulso. El tablero de metodología RISE with SAP en SAP Cloud ALM incluye un KPI de Technical Debt Score, un puntaje agregado de deuda técnica de los objetos personalizados, ponderado por la severidad de las referencias a objetos SAP, con una tendencia a tres meses que permite monitorear si la mantenibilidad del sistema mejora o empeora (SAP Community, 2026). La vista de operaciones, por su parte, entrega lecturas diarias con hasta 30 días de histórico (SAP Community, 2025).

Los datos diarios responden “cómo estamos hoy”. La tendencia a tres meses responde “hacia dónde vamos”. La revisión trimestral es, simplemente, el momento en que la segunda pregunta se convierte en una decisión firmada.

Los cinco insumos que hacen la revisión posible

Una revisión trimestral de salud del clean core le da a la estructura de gobierno efectividad operativa cuando se apoya en cinco insumos concretos (IgniteSAP, 2026): el conteo de objetos personalizados por nivel, el registro de excepciones de ATC, los KPI de cumplimiento de clean core del tablero RISE with SAP en SAP Cloud ALM, las excepciones nuevas incorporadas desde la revisión anterior y una hoja de ruta de remediación vigente para el código de niveles C y D.

La distinción de niveles importa para priorizar. Los niveles A y B se consideran clean core; el nivel C es condicionalmente limpio —usa objetos internos de SAP, sin recomendación oficial, admisible solo cuando no existe alternativa A o B— y el nivel D corresponde a objetos clasificados como noAPI y a modificaciones clásicas del sistema (software-heroes, 2025). Es en C y D donde vive el riesgo de upgrade, y es allí donde la hoja de ruta debe tener nombres y fechas, no intenciones.

Para alimentar el tablero, el proceso exige haber agregado los checks de clean core a la variante global estándar de ATC e importar los resultados (SAP Community, 2026). Ese requisito técnico, en la práctica, es el que obliga a que la revisión tenga preparación real y no sea una reunión de estado.

Lo que la revisión no debe ser

No es un foro para relitigar la arquitectura ni para revisar avance de proyectos. Es un control de deriva con cinco insumos, una tendencia y decisiones con fecha. Esa restricción es lo que la hace sostenible en organizaciones latinoamericanas que operan con presupuestos acotados, equipos técnicos pequeños y ventanas de mantenimiento estrechas: noventa minutos cada tres meses son financiables; un programa de remediación de emergencia, mucho menos.

Y hay un límite que conviene declarar en voz alta, porque es la objeción más seria a esta práctica: la revisión trimestral no sustituye al control en el punto de decisión. Según la observación de AiFA Labs, las excepciones entran cada sprint, mientras que la mayoría de los programas las revisa trimestralmente en el mejor de los casos, de modo que el backlog de excepciones crece más rápido que el de remediación; y una evaluación puntual no puede prevenir la deuda técnica del trimestre siguiente (AiFA Labs, 2026). La conclusión no es descartar la cadencia trimestral, sino no pedirle lo que no puede dar: es el instrumento que mide la trayectoria y firma la corrección, no el que aprueba la extensión. Ese control vive en la intake del requerimiento y en el transporte, y se sostiene entre reuniones.

La misma advertencia opera en sentido inverso. El modo de falla más común del gobierno de arquitectura en SAP es diseñar el modelo buscando exhaustividad en lugar de velocidad: una gobernanza técnicamente impecable y operativamente paralizante (SAP Community, 2026). Noventa minutos y cuatro decisiones son un límite deliberado, no una concesión.

Cuando no hay fecha: la deriva que nadie firmó

En la mayoría de las distribuidoras eléctricas y operadoras de oil & gas de América Latina con las que hemos trabajado tras su conversión a S/4HANA, la estructura de gobierno existe en el papel. Lo que falta es la casilla. Y sin casilla, el gobierno solo se activa cuando algo duele: cuando el upgrade se atrasa, cuando el cierre de facturación no cuadra, cuando el regulador pide un dato que el sistema tardó tres días en producir.

La erosión no ocurre en un evento. Ocurre en decisiones individualmente razonables: un BAdI no liberado que había que implementar para un proceso de corte y reconexión, un acceso directo a una tabla estándar porque el proyecto cerraba el viernes, una excepción de ATC aprobada “por esta vez”. Ninguna de esas decisiones se ve mal aislada. El problema es acumulativo y, entre crisis, es invisible.

SAP misma reconoció que la clasificación binaria —limpio o no limpio— resultaba demasiado restrictiva y poco aplicable a sistemas con mucho código clásico heredado, y por eso evolucionó el modelo de tres capas hacia el concepto de niveles A a D (SAP Community, 2025). Ese cambio tiene una consecuencia práctica sobre la agenda: la pregunta dejó de ser “¿estamos limpios?” y pasó a ser “¿cuánto nos hemos desviado y hacia dónde?”. Una pregunta de tendencia no se responde con una auditoría cada dos años. Se responde midiendo con regularidad.

Hay un indicador temprano especialmente honesto: un registro de excepciones de ATC que crece sin revisión periódica es una de las señales más claras de deriva de gobierno, y seguir el volumen de excepciones junto con la justificación de aprobación como KPI de clean core detecta esa tendencia antes de que escale a problema de landscape (IgniteSAP, 2026).

El gobierno del clean core no falla por falta de herramientas. Falla porque nadie tiene la fecha en su calendario. Ponerla es la intervención más barata disponible.

En la última entrega de esta serie veremos el reverso: qué le ocurre concretamente a una utility que trata el clean core como un proyecto con fecha de cierre en vez de como una disciplina permanente.

Fuentes

• SAP Community (2025). ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud, actualización de agosto 2025.
• SAP Community (2025). ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development.
• SAP Community (2026). New Clean Core Extensibility KPIs arrive on the RISE with SAP Dashboard.
• SAP Community (2025). SAP S/4HANA 2025: What’s in it for the Utilities Industry?
• SAP Community (2026). SAP Enterprise Architecture in Practice: Governance Models, Clean Core, and the Architecture Runway.
• SAP Learning. Navigating Release Upgrades – Implementing SAP S/4HANA Cloud Private Edition.
• IgniteSAP (2026). SAP’s Clean Core in Practice.
• AiFA Labs (2026). SAP Clean Core: A Continuous Practice, Not a Report.
• software-heroes (2025). ABAP Cloud – Clean Core Level Concept.