La excusa más común para postergar IA en empresas con SAP/Oracle/Dynamics es: "primero tenemos que migrar el ERP". Y esa migración nunca llega. Lo cierto es que no necesitas reemplazar nada para empezar — necesitas elegir el patrón de arquitectura correcto.
Estos son los 5 patrones que usamos en CONECTIE, cuándo conviene cada uno y qué riesgos tiene.
Patrón 1 — API Gateway sobre el ERP
Qué es: una capa de APIs REST/GraphQL que expone funciones del ERP de forma estandarizada hacia afuera. Lo que internamente es una RFC de SAP o un BAPI complejo, hacia afuera es POST /api/orders.
Cuándo usarlo: cuando tu ERP es la fuente de verdad para múltiples sistemas (CRM, ecommerce, BI) y cada uno está intentando integrarse a su manera. El gateway estandariza.
Riesgo principal: performance. Cada llamada externa pasa por el ERP. Hay que cachear y hacer rate limiting bien.
Patrón 2 — Middleware con réplica de datos
Qué es: una base de datos intermedia (PostgreSQL, BigQuery, Snowflake) que mantiene una réplica casi en tiempo real de los datos críticos del ERP. Las consultas analíticas y la IA leen de la réplica, no del ERP.
Cuándo usarlo: cuando necesitas hacer análisis pesados (IA, reportes, BI) sin afectar la performance del ERP transaccional. Es lo más usado en empresas medianas-grandes.
Riesgo principal: el lag de sincronización. Si tu agente necesita data en tiempo real (ej. validar stock antes de cotizar), 5 minutos de delay puede ser problema. Hay que decidir CDC (change data capture) vs batch.
Patrón 3 — Event Bus
Qué es: el ERP publica eventos cuando algo cambia ("factura emitida", "pedido aprobado", "stock bajo umbral") en un bus (Kafka, RabbitMQ, AWS EventBridge). Múltiples consumidores reaccionan a esos eventos.
Cuándo usarlo: cuando tienes procesos que disparan otros procesos. Ej: cuando se aprueba un pedido grande, automáticamente un agente IA evalúa riesgo crediticio, otro reserva stock, otro alerta a logística. Todos en paralelo, todos desacoplados.
Riesgo principal: complejidad operativa. Necesitas monitoreo distribuido y diseñar bien los retries para no duplicar acciones.
Patrón 4 — Agente sidecar (autónomo por área)
Qué es: un agente de IA dedicado a UN área específica (ej. el agente de Finanzas, el agente de Logística). Cada agente tiene su propio acceso al ERP/CRM con permisos limitados a su scope. Operan de forma independiente.
Cuándo usarlo: cuando los procesos de cada área son muy distintos y los equipos quieren autonomía. El agente de Logística no necesita saber nada de cobranza. El agente de Cobranza no toca rutas.
Riesgo principal: silos. Si dos agentes necesitan colaborar (ej. evaluar un cliente moroso para frenar despacho), hay que diseñar la comunicación entre ellos vía Event Bus o capa de orquestación.
Patrón 5 — Capa de orquestación (workflow engine)
Qué es: un motor (Temporal, Camunda, n8n) que define flujos de trabajo donde algunos pasos los hace un humano, otros un agente de IA, otros llamadas a sistemas. El motor garantiza estado, retries, time-outs y auditoría.
Cuándo usarlo: cuando un proceso de negocio cruza varias áreas y combina humano + automático (ej. aprobación de descuento grande: vendedor solicita → agente IA evalúa histórico → si pasa, gerente aprueba → si rechaza, comercial discute → ERP refleja).
Riesgo principal: el engine se vuelve crítico — si cae, los procesos se detienen. Necesita HA (high availability) bien planeada.
¿Cuál elegir?
En la práctica, rara vez se usa UN solo patrón. Lo típico es:
- Empezar con Patrón 2 (Middleware con réplica) — bajo riesgo, valor inmediato para BI/IA.
- Agregar Patrón 3 (Event Bus) cuando hay procesos cross-área.
- Implementar Patrón 4 (Agente sidecar) por área a medida que escala el uso de IA.
- Subir a Patrón 5 (Orquestación) cuando los procesos críticos involucran human-in-the-loop.
- Patrón 1 (API Gateway) es útil pero suele ser parte transversal de los otros.
¿No sabes cuál patrón es para ti?
En el diagnóstico de 60 min mapeamos tu situación actual y te recomendamos arquitectura específica para tu caso.
Solicitar diagnóstico estratégico