Un campo nuevo no debería convertirse en un proyecto SAP
Sin criterio claro sobre dónde extender SAP S/4HANA, hasta un campo escala a desarrollo formal. Por qué encarece la operación diaria en utilities de LATAM.
· 11 min de lectura
En una comercializadora eléctrica de la región, una analista de facturación necesita algo mínimo: un campo adicional en la pantalla de reclamos para registrar la causa raíz que el call center hoy anota en una hoja de cálculo paralela. Es un campo. No es un proceso nuevo, no es una interfaz, no es un motor de cálculo.
Tres semanas después, el requerimiento está en un comité de arquitectura, tiene un estimado de desarrollo ABAP, compite por presupuesto con la migración de otro módulo y quedó agendado para el próximo release. La hoja de cálculo paralela sigue viva. Y el equipo de negocio aprendió una lección que nadie quiso enseñarle: pedir es caro, así que mejor no pedir.
Esa lección es el verdadero costo. No el del desarrollo: el de las decenas de mejoras que nunca se pidieron porque el camino para pedirlas era demasiado largo.
Lo pequeño no escala solo: escala por falta de criterio
Cuando una organización no tiene un criterio explícito para decidir dónde se resuelve una necesidad de personalización, todas las necesidades toman la ruta más costosa por defecto: la del desarrollo formal. No porque alguien lo decida, sino porque es la única ruta que la organización sabe recorrer.
El síntoma es reconocible. El key user describe su necesidad. El funcional no está seguro de si eso se puede hacer con herramientas de configuración. El arquitecto prefiere no arriesgarse. Y ante la duda, todos escalan. La duda técnica se convierte en ticket, el ticket en estimado, y el estimado en un proyecto pequeño que consume gobierno, pruebas y transporte como si fuera uno grande.
Lo relevante es que ese escalamiento no es un problema de herramientas. SAP lleva años publicando el criterio. El problema es que ese criterio vive en documentación de arquitectura y no en la conversación diaria entre negocio y TI.
Dónde puede extender un key user sin llamar a un desarrollador
La extensibilidad in-app permite personalizaciones directamente en el sistema mediante herramientas de key user, y resulta idónea para personalizaciones más pequeñas, compatibles con SAP y mantenibles en el tiempo (KPS, 2026). No es un atajo ni una solución de segunda: es la ruta diseñada por SAP para el último tramo de adaptación.
En SAP S/4HANA, la aplicación Custom Fields and Logic permite a un experto de negocio o consultor de implementación crear campos personalizados y lógica de negocio para contextos específicos, habilitándolos en interfaces, reportes, plantillas de correo y plantillas de formulario (SAP Help Portal, 2025). Todos los artefactos técnicos —extensiones de tablas, vistas CDS asociadas, servicios OData— los genera la propia herramienta.
La guía de SAP es igual de directa sobre el límite: la extensibilidad de key user está pensada para extensiones de último tramo, mientras que los desarrollos de mayor envergadura corresponden a desarrollo personalizado; la extensibilidad side-by-side aplica cuando la aplicación consume datos del core de forma remota y ocasional, mientras que el uso intensivo de datos de SAP S/4HANA apunta a resolver la necesidad dentro del sistema, on-stack (SAP Learning, 2025).
Traducido a la operación de una utility: un campo de causa raíz en reclamos, una etiqueta reordenada en una orden de mantenimiento o un dato adicional en el maestro de instalación pertenecen a un mundo. Un portal de autogestión para grandes clientes o un motor de reglas que conversa con el sistema comercial pertenecen a otro.
SAP ya publicó el criterio; la organización aún no lo adoptó
En agosto de 2025, SAP actualizó su guía de extensibilidad ABAP y reemplazó el modelo de tres niveles por el clean core level concept: una clasificación de cuatro niveles —A, B, C y D— que evalúa cada extensión según su integridad arquitectónica, su seguridad ante upgrades y su alineación con los principios de clean core (SAP News Center, 2025). La lista oficial de clasificación de frameworks y tecnologías está publicada como nota SAP (SAP Community, 2026).
El nivel A corresponde a las extensiones más limpias, construidas on-stack con el modelo de desarrollo ABAP Cloud o side-by-side sobre SAP BTP; los niveles B a D describen desarrollos ABAP clásicos con distinto grado de riesgo (SAP Community, 2025). Para decidir entre on-stack y side-by-side, SAP publica además la SAP Application Extension Methodology, que ordena la conversación en fases y establece un vocabulario común entre arquitectos, desarrolladores y negocio (SAP Help Portal, 2025).
El punto no es memorizar la taxonomía. El punto es que existe un lenguaje compartido, y que una organización que no lo usa toma cada decisión de personalización desde cero, en una reunión, con el criterio de quien tenga más antigüedad en la sala.
En utilities, la indecisión se paga en la operación diaria
En una distribuidora eléctrica o en un operador de oil & gas de la región, la personalización cotidiana no es un capricho: es cómo el proceso absorbe la realidad regulatoria y comercial local. Un dato adicional en el flujo de reclamos que permite clasificar por causa. Un indicador en la orden de mantenimiento que separa correctivo de emergencia. Un atributo en el maestro de puntos de medición que ayuda a segmentar cartera.
Cada uno de esos ajustes, tomado solo, es marginal. Tomados en conjunto, son la diferencia entre un proceso de meter-to-cash que refleja la operación y uno que la aproxima. Cuando todos escalan a desarrollo, ocurren tres cosas predecibles:
- La lista de espera crece más rápido de lo que el equipo la consume, y el negocio deja de pedir.
- Las hojas de cálculo paralelas se vuelven infraestructura no gobernada, con datos de recaudación y de gestión de pérdidas fuera del sistema.
- El presupuesto acotado de modernización —que debería financiar capacidades nuevas— se consume en mantener personalizaciones que nunca debieron ser código.
Y cuando ese código se construye sin criterio de nivel, la factura se cobra otra vez en el siguiente upgrade.
Un tamiz de tres preguntas antes de abrir un requerimiento
Antes de que una necesidad se convierta en ticket de desarrollo, conviene pasarla por un filtro corto que cualquier funcional pueda aplicar en minutos:
---
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([Necesidad de personalización]) --> B{¿Es un dato o es un proceso?}
B -->|Dato| C[Atributo, etiqueta o vista: extensibilidad in-app]
B -->|Proceso| D{¿Necesita acoplarse al core o vivir aparte?}
C --> D
D -->|Al core| E[Uso intensivo y transaccional del core: on-stack]
D -->|Aparte| F[Consumo remoto y ocasional: side-by-side]
E --> G{¿En qué nivel de clean core queda?}
F --> G
G -->|Baja de nivel| H([Arquitectura antes que estimado])
G -->|Resultado| I([Ruta asignada, no escalada])
class A inicio
class B,D,G decision
class C,E,F proceso
class H neutro
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
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
Este tamiz no reemplaza el gobierno de extensiones. Lo que hace es evitar que el gobierno se dedique a arbitrar campos.
Lo que se juega la operación
La confusión sobre dónde extender no encarece los proyectos grandes: encarece los pequeños, que son la mayoría. Y los encarece dos veces —en el desarrollo y en el upgrade— mientras entrena al negocio para dejar de pedir mejoras.
La conversación productiva no empieza preguntando cuánto cuesta desarrollar. Empieza preguntando si hay que desarrollar. En la siguiente entrega de esta serie abordamos el alcance real de la extensibilidad in-app: qué puede resolver un key user por su cuenta, sin abrir un ticket.
Fuentes
- KPS. Clean Core in SAP S/4HANA: Finding the Right Balance, 2026.
- SAP Help Portal. Creating Custom Fields and Custom Business Logic, 2025.
- SAP Learning. Choosing the Appropriate Extensibility Option, 2025.
- SAP News Center. How to Extend SAP S/4HANA Cloud the Right Way, 2025.
- SAP Community. ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud, August 2025 Update, 2025.
- SAP Community. Clean Core maturity and the new Extensibility Levels, 2026.
- SAP Help Portal. SAP Application Extension Methodology – User Guide / Extension Architecture Guide, 2025.
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
