El ecosistema SAP desde adentro
Cuando un cliente te dice "queremos implementar SAP", la conversación real apenas empieza. Detrás de esa frase hay decisiones que van a condicionar la arquitectura del negocio por los próximos 10 a 15 años: qué versión, qué módulos, cómo integrar con el ecosistema existente, en la nube o on-premise, y —la pregunta que nadie hace primero pero debería— ¿están realmente listos para esto?
Este artículo no es un resumen de la documentación de SAP. Es una destilación de decisiones tomadas en proyectos productivos, con sus consecuencias reales, incluyendo las que nadie menciona en los casos de éxito publicados.
"El mayor riesgo en un proyecto SAP no es técnico. Es arquitectónico: tomar decisiones de diseño demasiado pronto, con demasiada confianza."
ECC vs S/4HANA: la comparativa que importa
SAP ECC (ERP Central Component) fue la columna vertebral del ERP empresarial durante casi dos décadas. S/4HANA es su sucesor, construido sobre la base de datos in-memory HANA y con un modelo de datos simplificado. La pregunta no es cuál es "mejor" —S/4HANA gana en papel— sino cuándo tiene sentido migrar y a qué costo real.
| Dimensión | SAP ECC | S/4HANA |
|---|---|---|
| Modelo de datos | Complejo, tablas redundantes (BSEG, BKPF separados) | Simplificado — tabla ACDOCA unificada para FI/CO |
| Performance de reportes | Depende de índices y agregados (totals tables) | In-memory nativo, analytics en tiempo real |
| UX | SAP GUI (legacy, funcional) | Fiori (web, responsive) — curva de adopción |
| Extensibilidad | ABAP clásico, modificaciones al estándar | Modelo de extensión estricto (side-by-side, in-app) |
| Licenciamiento | Mantenimiento extendido hasta 2027–2030 | Stack actual, evolución futura de SAP |
| Complejidad de migración | N/A (punto de origen) | Alta — especialmente con customizaciones ABAP |
| TCO a 5 años | Creciente (HW, mantenimiento, skill shortage) | Variable — Cloud reduce ops, aumenta licencia |
El trade-off que nadie documenta bien
Migrar a S/4HANA no es un upgrade —es una reimplementación parcial. Las organizaciones con fuerte customización en ECC enfrentan un dilema concreto: cada Z-program, cada user-exit, cada modificación al estándar es una deuda que se cobra en la migración. Hemos visto proyectos donde el 60% del esfuerzo total fue remediar código ABAP que nadie recordaba haber escrito.
En un proyecto de conversión brownfield (ECC → S/4 conservando datos históricos), el análisis SPDD/SPAU del cliente reveló más de 4,000 objetos modificados. El cronograma original de 8 meses se extendió a 19. El análisis previo había tomado 3 días. Siempre hacer el Custom Code Analysis antes de estimar.
Cuándo migrar a S/4HANA ya
- Greenfield o ECC con bajo nivel de customización
- Necesidad real de analytics en tiempo real (FI/CO)
- Nuevo negocio o spin-off sin legado
- Presión regulatoria o de desinversión de HW
- Equipo ABAP disponible para remediation
Cuándo no apresurarse
- ECC muy customizado, crítico para operaciones
- No hay sponsor ejecutivo con mandato real
- Procesos de negocio no documentados
- Presupuesto subestimado (regla: multiplicar x1.5)
- El "driver" es solo el fin del soporte
On-Premise, Private Cloud, RISE: el modelo de despliegue
SAP ofrece S/4HANA en tres modalidades principales. La elección impacta directamente el modelo operativo, los SLAs, el control sobre upgrades y el perfil de riesgo del cliente.
S/4HANA On-Premise
Control total sobre el sistema. El cliente gestiona HW, OS, base de datos y upgrades. Apropiado para industrias con requerimientos de soberanía de datos estrictos (banca, defensa, gobierno) o donde el equipo Basis es maduro y el ciclo de upgrades puede ser controlado.
Private Cloud (hyperscaler)
SAP sobre AWS, Azure o GCP, gestionado por el cliente o un MSP. El sweet spot para organizaciones que quieren eliminar la capa de HW sin perder control de versiones. El costo operativo cae, pero la complejidad de networking y security no desaparece —se transforma.
RISE with SAP (Business Cloud)
SAP como servicio gestionado: incluye licencia, infraestructura, upgrades y BTP (Business Technology Platform). El pitch es atractivo, el contrato requiere lectura muy cuidadosa. Los SLAs de disponibilidad son robustos, pero la ventana de upgrades puede ser no negociable, y las customizaciones deben cumplir el modelo de extensibilidad clean-core o no se soportan.
RISE simplifica operaciones pero restringe arquitectura. Un cliente que necesitaba acceso directo a tablas HANA para un proceso de conciliación financiero tuvo que rediseñar la solución usando CDS Views y OData APIs —6 semanas de retrabajo— porque el acceso directo a la DB no está permitido en el tier de RISE que contrataron.
Arquitectura de integraciones: el territorio donde se gana o se pierde
SAP raramente existe solo. En la práctica, convive con CRMs (Salesforce), plataformas de ecommerce, WMS externos, sistemas legados de industria específica, y cada vez más con plataformas de datos y ML. La arquitectura de integración es donde los proyectos acumulan más deuda técnica —y donde el impacto operativo de las malas decisiones se siente más rápido.
SAP Integration Suite (ex-CPI / HCI)
La plataforma de integración nativa de SAP, disponible en BTP. Cubre iPaaS, API management, event mesh y conectores prebuilts. Es la opción recomendada por SAP y la más directa para integraciones SAP-a-SAP. El catch: el modelo de licenciamiento es por mensajes/operaciones, y en volúmenes altos el costo puede sorprender. Siempre modelar el volumen esperado antes de comprometerse.
Middleware externo (MuleSoft, Azure Integration, Boomi)
Cuando el cliente ya tiene un ESB o iPaaS corporativo, la pregunta es si conviene unificarlo o bifurcarlo. La respuesta honesta: depende del equipo, no de la tecnología. Un equipo MuleSoft maduro puede integrar SAP con eficiencia. Un equipo que aprende MuleSoft mientras implementa SAP es una receta para delays. SAP Integration Suite tiene la ventaja de los conectores nativos y la proximidad al sistema, pero la curva de aprendizaje también existe.
IDocs vs APIs: la decisión de protocolo
IDocs (Intermediate Documents) son el mecanismo asíncrono clásico de SAP. Robustos, auditables, pero con un modelo de datos rígido y un debugging que puede ser lento. Las APIs REST/OData de S/4HANA son más flexibles para integraciones modernas y son el camino forward de SAP. En proyectos nuevos sobre S/4HANA, preferir APIs OData / SOAP cuando el caso de uso lo permite. Reservar IDocs para procesos masivos, asíncronos y donde el estándar IDoc cubre bien el proceso (ORDERS, INVOIC, DESADV).
Usar IDocs para todo porque "siempre se hizo así" en ECC. En S/4HANA con BTP, el costo de procesar IDocs puede ser significativamente mayor al de APIs directas, además de perder capacidad de observabilidad moderna (traces, correlation IDs).
Clean Core: el dogma y la realidad
SAP lleva años promoviendo el concepto de clean core: mantener el sistema SAP sin modificaciones al estándar, extender la funcionalidad desde BTP (side-by-side extensions) o dentro de guardianes del modelo limpio (in-app, key-user extensibility). El beneficio es claro: upgrades automáticos, menor riesgo, alineación con el roadmap de SAP.
La realidad en proyectos productivos es más matizada. Clean core es un espectro, no un binario. Hay casos de uso donde una extensión ABAP clásica in-system sigue siendo la solución más costo-efectiva y menos riesgosa —especialmente en lógica de negocio muy específica con bajo volumen de cambio.
El modelo de extensibilidad de S/4HANA
SAP define cuatro capas de extensión en orden de "limpieza":
1. Key User Extensibility — campos custom, lógica BAdI sin código, sin ABAP. Ideal para parametrizaciones de negocio, pero limitado en capacidades.
2. Developer Extensibility (in-app) — ABAP en el sistema, pero usando solo released APIs (CDS, BAdIs released). Mantenible en upgrades si se respetan las restricciones.
3. Side-by-side (BTP) — lógica en BTP, conectada via APIs. Máximo desacoplamiento, mayor complejidad operativa, mayor costo de latencia en procesos síncronos.
4. Classic extensibility — modificaciones al código estándar. Solo como último recurso, documentado y con plan de exit.
Framework de decisión para arquitectos
Cuando te sientas a diseñar una arquitectura SAP, estas son las preguntas que deben responderse antes de dibujar el primer diagrama:
¿Cuál es el nivel real de customización actual?
Correr el Custom Code Analysis de SAP antes de cualquier estimación. El resultado suele ser sorprendente —y es información crítica para elegir entre brownfield, bluefield o greenfield.
¿Quién opera el sistema después del go-live?
La arquitectura técnica debe alinearse con la capacidad del equipo que la va a operar. Una solución BTP side-by-side brillante que nadie sabe mantener es peor que una solución ABAP clásica bien documentada.
¿Cuáles son los procesos "core" que no pueden fallar?
Identificar los 5-10 procesos críticos de negocio y diseñar la arquitectura alrededor de su confiabilidad, no de la elegancia técnica general. En manufactura, el Goods Receipt. En retail, el POS integration. En servicios financieros, el posting contable.
¿Cuál es el modelo de integración a 5 años?
No diseñar solo para el estado actual del ecosistema. Un cliente que hoy usa un WMS legacy probablemente lo reemplazará. Diseñar la capa de integración para ser reemplazable por partes, no como un monolito de flujos acoplados.
¿Existe un modelo de gobierno para la arquitectura?
La deuda técnica en SAP no viene de malas decisiones únicas —viene de decisiones inconsistentes repetidas a lo largo del tiempo. Un Architecture Decision Board con al menos poder de veto en objetos custom es casi siempre justificado en proyectos medianos y grandes.
Cierre: lo que los proyectos exitosos tienen en común
Después de ver proyectos que funcionan y proyectos que se extienden dos veces más de lo estimado, hay un patrón claro. Los proyectos exitosos no son los que eligieron la mejor tecnología —son los que tuvieron menos sorpresas en la segunda mitad.
Eso se logra con más análisis previo (Custom Code, Business Process Documentation, Integration Inventory), con decisiones arquitectónicas explícitas y escritas, y con la humildad de reconocer que en un proyecto SAP, el riesgo técnico más subestimado suele ser el que conocemos de memoria —porque precisamente por eso no lo documentamos.
"La diferencia entre un proyecto que termina a tiempo y uno que no, raramente está en el código. Está en cuántas asunciones implícitas quedaron sin cuestionar en el kickoff."
En próximas entregas: casos específicos de integración SAP ↔ Salesforce en proyectos Order-to-Cash, el modelo de datos de ACDOCA y por qué cambia el juego en reportes financieros, y la arquitectura de seguridad en S/4HANA Cloud.