Antes de dibujar un solo diagrama tienes que saber qué SAP corre tu empresa, porque la versión decide qué protocolos puedes usar y cuáles están cerrados con llave. Es la pregunta más barata del proyecto y la que más veces se salta.
Las cuatro instalaciones que te vas a encontrar
Para efectos de integrar con un CRM, el universo SAP se reduce a cuatro, y son dos mundos: Business One por un lado, la familia ERP —ECC y S/4HANA— por el otro.
- SAP Business One: el ERP de SAP para empresas medianas, muy extendido en LATAM. Es un producto distinto de ECC y S/4HANA, no una versión menor: tiene su propio modelo de datos y su propia forma de integrarse.
- SAP ECC (la generación anterior, todavía muy viva en LATAM): instalación propia, altamente personalizada, con años de desarrollos internos encima.
- S/4HANA on-premise o en nube privada: la generación actual corriendo en infraestructura que tú controlas. Conserva casi todas las puertas abiertas.
- S/4HANA Cloud pública: el mismo producto como servicio, con el sistema cerrado a propósito. Es la variante que más restringe y la que más crece.
Si la respuesta de tu equipo de TI es "Business One", esta guía te sirve igual: el orden de los siete pasos es el mismo y las decisiones de negocio —qué objetos conectar, quién manda sobre cada campo, cómo se concilia— no cambian. Lo que cambia son dos cosas concretas, y están señaladas donde corresponde: los protocolos, acá abajo, y el licenciamiento, en el paso 2.
Qué protocolo habilita cada una
Acá está el dato que cambia el proyecto: S/4HANA Cloud pública bloquea RFC, BAPI e IDoc. Solo deja OData, SOAP y REST. Si tu instalación es esa y alguien te propuso una arquitectura basada en IDocs, esa arquitectura no se puede construir.
ECC es el caso opuesto: te deja usar RFC, BAPI e IDoc con comodidad, pero su capa de APIs modernas es más pobre, así que muchas integraciones terminan apoyadas en lotes de IDocs aunque el negocio pida tiempo real. S/4HANA on-premise es el punto medio cómodo: tiene la capa moderna completa y todavía conserva las puertas viejas.
Business One juega otro juego: no tiene RFC, BAPI ni IDoc, porque esos son de la familia ERP. Lo que tiene es su Service Layer —una interfaz de estilo OData, síncrona, por donde va a salir casi todo— y la DI API para lo que la Service Layer no cubra. En la práctica eso lo acerca al escenario de la nube pública: una sola puerta moderna, y el volumen hay que diseñarlo alrededor de ella.
Qué es cada uno de estos protocolos y cuándo conviene cada uno lo desarrolla el paso 4. Acá solo necesitas saber cuáles están disponibles.
El núcleo limpio: por qué SAP te empuja a no tocar el sistema
La orientación vigente de SAP es mantener el núcleo sin modificaciones e integrar por interfaces publicadas. No es una preferencia estética: cada desarrollo dentro de SAP es deuda que alguien paga en la siguiente actualización, y las actualizaciones dejaron de ser opcionales.
Para tu proyecto esto se traduce en una regla simple: si una propuesta incluye desarrollo dentro de SAP, exige que te expliquen por qué no alcanza con las interfaces estándar y quién mantiene ese código a tres años. A veces la respuesta es legítima. Muchas veces es que resultaba más rápido programar adentro que aprender la interfaz correcta.
Cómo averiguarlo en una reunión de veinte minutos
No necesitas un relevamiento formal. Necesitas sentarte con quien administra SAP y salir con cinco respuestas por escrito: qué producto y versión exacta, si está en infraestructura propia o como servicio, si hay desarrollos internos que toquen clientes o pedidos, si ya existe algún middleware licenciado, y quién autoriza abrir un usuario de integración.
Esa última pregunta suele ser la que más demora el proyecto. Pídela primero.
Diseñar una integración con SAP sin confirmar la versión es cotizar una casa sin haber visto el terreno.
Errores comunes en este paso
- Asumir la versión por lo que dijo alguien de negocio. "Tenemos SAP" no es un dato técnico. Pídelo por escrito a TI.
- Ignorar los desarrollos internos. Un ECC con quince años de modificaciones sobre el maestro de clientes no se comporta como el manual.
- Descubrir el bloqueo de S/4HANA Cloud pública a mitad de la construcción. Es el rehacer más caro de este tipo de proyectos.
- No preguntar por el middleware que ya existe. Muchas empresas ya pagan una licencia de integración que nadie del lado comercial sabe que tienen.
Checklist antes de pasar al siguiente
- Producto y versión exacta de SAP, confirmados por TI por escrito.
- Producto y modalidad: Business One, o familia ERP en infraestructura propia, nube privada o nube pública.
- Lista de protocolos disponibles según esa versión.
- Inventario de desarrollos internos que toquen clientes, productos o pedidos.
- Middleware ya licenciado, si lo hay.
- Nombre de quien autoriza el usuario de integración y sus permisos.
Con la versión confirmada, el siguiente paso es el que decide el presupuesto: paso 2, acceso indirecto. O vuelve a la guía completa.