Qué es SAP BTP: cómo extender tu ERP sin perder el clean core
Toda empresa que crece con SAP Cloud ERP llega, tarde o temprano, al mismo punto: necesita algo que el ERP estándar no trae. Un reporte que combine datos de dos sistemas, una validación adicional antes de aprobar una compra, una integración con un proveedor logístico local. El reflejo natural es modificar el ERP directamente para que haga esa tarea. Ese reflejo es exactamente lo que la estrategia de clean core de SAP existe para evitar, y SAP Business Technology Platform es la pieza que hace posible la alternativa.
Qué es SAP BTP, en términos prácticos
SAP Business Technology Platform (SAP BTP) es la plataforma de SAP para integrar, automatizar, extender y construir aplicaciones y procesos de negocio con inteligencia artificial, según la define SAP en su propio sitio. En la práctica, es el lugar donde una empresa construye lo que su ERP no trae de fábrica, sin tocar el código del ERP mismo. Según SAP, más de 33.000 clientes usan hoy SAP BTP.
La plataforma cubre cuatro frentes: desarrollo de aplicaciones y automatización de procesos (SAP Build), integración de sistemas SAP y no SAP (SAP Integration Suite), datos y analítica, e inteligencia artificial a través de Joule y de agentes que ejecutan tareas de negocio.
El riesgo que el clean core busca evitar: por qué modificar el core sale caro después, no antes
Según lo describe SAP en su propio recurso sobre clean core, los sistemas ERP tradicionales, muy personalizados con el tiempo, acumulan capas de código a la medida, cambios sin documentar e integraciones difíciles de mantener. Cada actualización o cada nueva función se convierte en un proyecto riesgoso que exige pruebas extensas y reprocesos. A esa acumulación de costo y complejidad, SAP la llama deuda técnica, y es la razón por la que actualizar un ERP muy modificado se vuelve, con los años, cada vez más lento y más caro.
SmartShift, firma especializada en modernización de código SAP, estima que entre el 40% y el 60% del código personalizado de un sistema SAP promedio ya no se usa realmente, y que un sistema SAP ECC típico acumula alrededor de 22.000 objetos personalizados y 2,7 millones de líneas de código ejecutable a la medida. Es una cifra de un proveedor externo, no de SAP, pero coincide con el diagnóstico que motiva toda la estrategia de clean core: gran parte de lo que se modificó alguna vez ya es solo peso muerto.
Cómo se resuelve sin renunciar a la diferenciación: side-by-side y on-stack
Un core limpio no significa un ERP sin personalización. Significa que la personalización vive en el lugar correcto. SAP define dos caminos para extender SAP S/4HANA Cloud sin romper esa limpieza: extensibilidad side-by-side sobre SAP BTP, que construye aplicaciones desacopladas que corren en paralelo al ERP, y extensibilidad on-stack con ABAP Cloud, que integra extensiones dentro del propio sistema pero usando únicamente interfaces públicas y estables.
Para ordenar esa decisión, SAP evolucionó su modelo original de tres niveles hacia un modelo de madurez de cuatro niveles —A, B, C y D— que clasifica cada extensión según qué tan expuesta queda a romperse en la siguiente actualización.
| Nivel | Qué usa | Riesgo de actualización |
|---|---|---|
| A — Extender con SAP Build | APIs públicas y estables de SAP, con contratos formales de estabilidad | Ninguno: es el estándar recomendado |
| B — Aprovechar APIs clásicas | APIs clásicas de SAP, bien documentadas y generalmente estables | Bajo |
| C — Acceso a objetos internos | Objetos internos de SAP, con changelog para anticipar cambios | Medio: exige plan de actualización activo |
| D — Extensión no recomendada | Modificaciones directas, escritura en tablas estándar, mejoras implícitas | Alto: es la definición de deuda técnica |
Esta misma serie de contenido ha repasado, solo en 2026, una reforma laboral, la entrada en vigor de la jornada de 42 horas y dos ciclos de calendario tributario. Cada uno de esos cambios normativos suele resolverse con un ajuste puntual en el ERP. Si ese ajuste se hizo modificando el core —nivel D del modelo de SAP—, la siguiente actualización de SAP Cloud ERP puede romperlo sin previo aviso. Si se construyó como extensión side-by-side en SAP BTP, la actualización del ERP y la extensión corren en rutas separadas.
Diseñar bien esa separación desde el inicio —qué se resuelve con configuración estándar, qué se extiende en BTP y qué de verdad justifica una excepción— es trabajo de implementación, no de licenciamiento.
Dónde entra Heinsohn en el proceso, no solo en el contrato
En la metodología de implementación de SAP Cloud ERP que Heinsohn describe en su propio sitio, la configuración y extensiones en SAP Business Technology Platform es un paso explícito del proceso —posterior al blueprint funcional y previo a integraciones y pruebas—, no un servicio aparte que se cotiza después de que algo ya se rompió. Heinsohn ofrece además un diagnóstico gratuito que evalúa procesos, arquitectura actual y madurez tecnológica antes de decidir qué se extiende y qué se deja en configuración estándar.
Un caso público de esa implementación es el del Centro Colombo Americano, que modernizó su gestión académica, financiera y operativa migrando a SAP S/4HANA Cloud ERP con Heinsohn, con procesos más ágiles y trazabilidad completa como resultado reportado. Es evidencia de ejecución real sobre SAP Cloud ERP, no solo de certificación en el papel: Heinsohn es SAP Premier Partner con presencia regional, con metodología basada en SAP Activate y equipo especializado en migración, adopción cloud e integración.
Lo que esto significa en tiempo y costo, no solo en arquitectura
SAP cita un estudio de IDC, patrocinado por SAP, que proyecta un retorno de inversión de 514% a tres años para empresas que combinan SAP BTP con SAP S/4HANA Cloud. Al ser un estudio patrocinado por el propio fabricante, conviene leerlo como una proyección de caso de negocio, no como una medición independiente, aunque SAP respalda la cifra con casos concretos: CONA Services reporta 50% menos costos de runtime usando SAP Integration Suite sobre BTP, Mahindra reporta 35% más eficiencia de desarrollo con SAP Build, y Harrods reporta 30% menos tiempo de proceso conectando sistemas con SAP Integration Suite y SAP Build Process Automation.
Del otro lado, SmartShift —de nuevo, un proveedor externo, no SAP— reporta que las empresas que adoptaron extensiones en BTP de forma temprana gastan entre 30% y 40% menos en mantenimiento anual de sistema, frente a las que siguen dependiendo de código personalizado dentro del core. Las dos fuentes miden cosas distintas, pero apuntan en la misma dirección: la extensión bien ubicada cuesta menos en el tiempo que la modificación directa.
Cómo empezar sin frenar lo que ya funciona
Audita lo que ya existe. Antes de construir nada nuevo en BTP, identifica qué extensiones o modificaciones tiene hoy tu SAP Cloud ERP y en qué nivel del modelo A-B-C-D caería cada una.
Prioriza lo que está en nivel C o D. Esas son las extensiones que más riesgo acumulan en cada actualización; migrarlas primero es lo que más deuda técnica reduce por esfuerzo invertido.
Reserva BTP para lo que de verdad diferencia tu negocio. No todo necesita ser una extensión; muchas necesidades ya están cubiertas por configuración estándar del ERP.
Agenda una conversación con el equipo de Heinsohn para revisar qué extensiones de tu SAP Cloud ERP conviene migrar a SAP BTP antes de la próxima actualización.