Tres señales de que tu extensión SAP debe vivir en BTP
Integración con terceros, lógica propia y escalamiento independiente: las señales de que una extensión SAP debe construirse en BTP y no dentro del core.
· 11 min de lectura
En la entrega anterior de esta serie recorrimos el alcance real de la extensibilidad in-app: todo aquello que un key user puede resolver por configuración, sin abrir un ticket ni convocar a un desarrollador ABAP. Ese territorio es más amplio de lo que la mayoría de las áreas de negocio supone. Pero tiene un borde, y el borde es lo que casi nunca se discute a tiempo.
Este artículo trabaja el criterio inverso. No qué se puede resolver adentro, sino cómo reconocer —temprano, antes de que el esfuerzo esté comprometido— que un requerimiento cotidiano de facturación, reclamos o mantenimiento ya no cabe dentro del sistema y debe construirse side-by-side sobre SAP Business Technology Platform.
El límite no lo marca el tamaño del pedido
El error más frecuente en las utilities de la región es evaluar la extensión por su esfuerzo aparente. “Es solo un campo más en la orden de servicio”, “es un cálculo chico en el recibo”. La conversación arranca por el tamaño y termina en el lugar equivocado.
SAP formalizó dos caminos limpios para extender S/4HANA Cloud, y ninguno de los dos se elige por tamaño: la extensibilidad side-by-side sobre SAP BTP, que produce aplicaciones desacopladas y escalables que corren de forma independiente del core, y la extensibilidad on-stack con ABAP Cloud, para extensiones estrechamente integradas y estables ante upgrades dentro del propio sistema. La recomendación explícita del fabricante es elegir entre ambas según el caso de uso, aplicando una estrategia BTP-first (SAP News Center, 2025).
El matiz importa: las extensiones side-by-side vía SAP BTP están pensadas para implementar extensiones más complejas fuera del core, mientras que las on-stack habilitan a los desarrolladores ABAP a mejorar procesos estándar cuando el requerimiento exige integración estrecha con el backend, manteniendo el core digital aislado del código propio (KPS, 2026).
Dicho de otro modo: la pregunta no es cuánto trabajo cuesta, sino qué naturaleza tiene el requerimiento. Y esa naturaleza se delata con tres señales bastante concretas.
Señal 1: el requerimiento cruza la frontera hacia un tercero
La primera señal es la más visible en el sector y la más subestimada: el pedido no se resuelve con datos que ya viven en el core. Necesita hablar con algo de afuera.
En las utilities latinoamericanas, ese “afuera” es un ecosistema denso: infraestructura de medición avanzada y sus concentradores, plataformas de gestión de datos de medida, pasarelas de recaudo, canales de autoatención, aplicaciones de campo de cuadrillas contratistas, sistemas de gestión de la distribución. Cada uno con su propio proveedor, su propio ciclo de release y su propia disponibilidad.
El marco regulatorio refuerza esa separación en lugar de disolverla. En Colombia, la Resolución CREG 101 001 de 2022 estableció las condiciones para la implementación de la infraestructura de medición avanzada en el Sistema Interconectado Nacional, determinando responsables de instalación, administración, operación y reposición, y fijando lineamientos de interoperabilidad, ciberseguridad y manejo, uso y protección de los datos (CREG, 2022). Un requerimiento que toca esa capa hereda obligaciones de interoperabilidad y protección de datos que no pertenecen al modelo de facturación: pertenecen a la capa de integración.
Forzar esa conversación dentro del core significa incrustar en el sistema transaccional el conocimiento de un protocolo ajeno, sus reintentos, su normalización de eventos y su ventana de indisponibilidad. Cuando el proveedor cambia de versión, el cambio aterriza en el core. Esa es exactamente la deuda técnica que la estrategia de clean core busca evitar.
Señal 2: la lógica tiene ciclo de vida propio
La segunda señal aparece cuando se intenta describir el requerimiento y no alcanza con una frase. Hay estados. Hay reglas que dependen de un ente regulador y que cambiarán sin avisar. Hay datos que no son del core y que igual hay que persistir, versionar y auditar.
Eso ya no es un campo adicional: es una aplicación con su propio ciclo de vida, alojada por error en un lugar donde el ciclo de vida lo dicta el calendario de upgrades del ERP.
La orientación del fabricante es consistente en este punto: el modelo side-by-side es la opción preferida para extensiones débilmente acopladas pero integradas de forma fluida a datos, transacciones o aplicaciones de S/4HANA, incluyendo aplicaciones dirigidas a un grupo de usuarios distinto del habitual del ERP (SAP Community, 2023). Un portal para contratistas de mantenimiento o una herramienta de gestión de reclamos con reglas de escalamiento propias caen de lleno en esa descripción.
Vale la pena recordar que SAP evolucionó su modelo de tres tiers hacia el clean core level concept, un modelo de madurez que clasifica cada extensión en cuatro niveles (A, B, C y D) según su integridad arquitectónica, su seguridad ante upgrades y su alineación con los principios de clean core (SAP News Center, 2025). Ese vocabulario común es útil precisamente cuando hay que justificar, ante un comité, por qué algo “chico” se construye afuera.
Señal 3: la carga escala a un ritmo distinto al del core
La tercera señal es de comportamiento, no de diseño. Hay funcionalidades cuyo volumen no crece al ritmo del negocio, sino al ritmo del despliegue tecnológico: eventos de medición, consultas de autoservicio en el pico de vencimiento, notificaciones a usuarios finales, procesamiento analítico sobre curvas de consumo.
Cuando ese perfil de carga vive adentro, compite por recursos con la facturación masiva y con la operación comercial. El modelo side-by-side existe también por esta razón: aplicaciones que corren en paralelo al ERP y reducen la carga sobre el sistema operativo, o que requieren proximidad a servicios de la plataforma como los de inteligencia artificial y aprendizaje automático (SAP Community, 2023).
En un contexto regional donde la modernización avanza con presupuesto acotado, esta señal tiene una lectura financiera directa: dimensionar el core para absorber picos que no son suyos es pagar capacidad permanente por una demanda intermitente.
Cómo se ve la evaluación en la práctica
---
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([Llega el requerimiento]) --> B{¿Depende de un sistema fuera de SAP?}
B -->|Sí| F[Construir side-by-side en SAP BTP]
B -->|No| C{¿Tiene estados y reglas propias?}
C -->|Sí| F
C -->|No| D{¿Su carga crece a otro ritmo?}
D -->|Sí| F
D -->|No| E([Ninguna de las tres señales está presente])
F --> G([Integrado por APIs y eventos publicados])
class A inicio
class B,C,D decision
class F proceso
class G bueno
class E neutro
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
La evaluación no requiere un comité de arquitectura de tres semanas. Requiere hacer las preguntas en orden y aceptar la respuesta.
En nuestros proyectos con operadores de servicios públicos de la región, el patrón se repite: la extensión que hoy genera fricción en cada upgrade rara vez nació como un proyecto grande. Nació como un pedido pequeño que cumplía una de estas tres señales y se resolvió adentro porque adentro estaba el equipo disponible.
La disciplina de clean core no consiste en prohibir la personalización, sino en decidir conscientemente dónde vive. EvoTech Consulting acompaña esa decisión con el vocabulario del fabricante, no con preferencias de equipo.
Reconocer las señales es la mitad del trabajo. La otra mitad es convertirlas en una decisión repetible que cualquiera del equipo pueda tomar en minutos y defender después: eso es exactamente lo que aborda la siguiente pieza de esta serie, un árbol de decisión para ubicar cada extensión sin depender de la intuición.
Fuentes
- SAP News Center (2025). Discover How to Extend SAP S/4HANA Cloud the Right Way.
- KPS (2026). Clean Core in SAP S/4HANA: Finding the Right Balance.
- SAP Community (2023). SAP S/4HANA Extensibility Options For Clean Core Journey.
- Comisión de Regulación de Energía y Gas, CREG (2022). Resolución No. 101 001 de 18 de enero de 2022.
¿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.
