Cómo integrar ERP con e-commerce sin que se rompa todo: arquitectura, patterns y errores comunes

"Tenemos el e-commerce por un lado y el ERP por el otro, y cada actualización de stock o precio la cargamos a mano". Esta frase la escucho en al menos una reunión por mes. La consecuencia siempre es la misma: errores de stock que se venden online sin poder despachar, precios que están desactualizados durante días, pedidos que se ingresan dos veces al ERP, y un equipo administrativo que pasa 20-30% de su tiempo siendo "el cable entre los dos sistemas".

Integrar bien un ERP con un e-commerce no es trivial, pero tampoco es ciencia espacial. Hay cinco patterns que cubren el 90% de los casos. Te paso cuál conviene en cada situación, los errores que vemos repetirse, y cómo evitar que el proyecto se transforme en un agujero negro.

Por qué fallan la mayoría de las integraciones

Patrones de fracaso que vemos repetirse en empresas que vienen con una integración rota:

• Sincronización en una sola dirección cuando el negocio necesita ambas. Por ejemplo: stock baja del ERP al e-commerce, pero las ventas online no actualizan stock en el ERP. Resultado: dos verdades distintas.
• Sincronización por job nocturno en negocios con rotación rápida. A las 9 AM vendés algo que ya estaba agotado a las 8 PM del día anterior pero recién se sincroniza a la noche.
• Acoplamiento punto a punto sin capa intermedia. Cuando cambiás el ERP o el e-commerce, hay que reescribir todo.
• No definir la "fuente de verdad" de cada dato. ¿El precio lo define el ERP o el e-commerce? ¿El stock disponible es el del ERP, o el del e-commerce restando ventas en curso? Sin esa definición, los dos sistemas pelean.
• No diseñar para fallas. ¿Qué pasa si el ERP está caído? ¿Y si la integración se cuelga a mitad de la sincronización? Sin estos escenarios resueltos, una caída de servidor te corta las ventas o te duplica pedidos.

Los cinco patterns de integración

1. Batch nocturno (file-based o por API)

Una vez por noche, un proceso extrae datos de un sistema, los transforma y los inserta en el otro. Es el patrón más antiguo y simple. Suele implementarse con archivos CSV/XML o llamadas a APIs en serie.

Conviene: cuando la frescura de los datos no es crítica. Por ejemplo, e-commerce B2B con productos de baja rotación, catálogos editoriales que cambian poco.

No conviene: e-commerce B2C con stock limitado, productos de alta rotación, o pricing dinámico. El batch nocturno te garantiza un día de delay y eso es venenoso para muchos negocios.

Costo típico: USD 8.000 a USD 20.000 implementación, USD 200-400/mes mantenimiento.

2. Polling cada X minutos

Uno de los sistemas (típicamente el e-commerce) consulta al otro cada N minutos para ver si hubo cambios. Más fresco que el batch pero todavía con latencia.

Conviene: cuando necesitás datos relativamente frescos (≤15 minutos) y el sistema fuente no soporta webhooks.

No conviene: cuando hace falta tiempo real. Tampoco si el sistema fuente tiene rate limits — el polling agresivo te puede comer todas las llamadas permitidas.

Costo típico: USD 15.000 a USD 35.000 implementación, USD 400-700/mes mantenimiento.

3. Webhooks event-driven

Cuando algo cambia en el sistema A (se genera una venta, se actualiza un stock, se crea un producto), A llama un endpoint en B para avisarle. El cambio se propaga en segundos.

Conviene: cuando necesitás casi-real-time y los dos sistemas soportan webhooks. Casi todos los ERP modernos y los e-commerce de las plataformas grandes (Shopify, WooCommerce, Magento, Tienda Nube) los soportan.

No conviene: cuando los sistemas legacy no soportan webhooks (típico en ERPs viejos AS/400, SAP B1, sistemas administrativos argentinos clásicos). Ahí tenés que combinarlo con polling.

Costo típico: USD 25.000 a USD 60.000 implementación, USD 600-1.200/mes mantenimiento.

4. Capa de integración (iPaaS o middleware custom)

Una capa intermedia que orquesta la sincronización entre los sistemas. Puede ser una plataforma SaaS (Boomi, MuleSoft, Make, n8n) o un middleware custom (típicamente un servicio que escucha eventos y maneja los flujos).

La gran ventaja: desacopla los sistemas. Si mañana cambiás el ERP, modificás solo la capa de integración. También permite normalizar datos, manejar errores centralmente, y reintentar operaciones fallidas.

Conviene: cuando tenés varias integraciones (no solo ERP-ecom: agregás marketplaces, sistema de logística, pasarela de pagos, CRM). Y siempre que el negocio sea grande o complejo.

No conviene: para empresas chicas con una sola integración. El overhead no se justifica.

Costo típico: USD 40.000 a USD 150.000 implementación, USD 1.200-3.500/mes mantenimiento (incluye licencias iPaaS si aplica).

5. Event streaming (Kafka, RabbitMQ, AWS SQS/SNS)

Los sistemas publican eventos a un bus de mensajes, y los consumidores (e-commerce, ERP, CRM, BI) los procesan en tiempo real. Es el patrón más sofisticado y el que mejor escala.

Conviene: empresas con volumen alto (millones de transacciones/mes), múltiples sistemas que necesitan los mismos datos, requisitos de auditabilidad fuerte.

No conviene: empresas chicas o medianas. Es overkill para 5.000 pedidos/mes. La curva de aprendizaje y el costo operativo no se justifican.

Costo típico: USD 80.000+ implementación, USD 2.500+/mes mantenimiento. Para empresas con equipos de IT serios.

Qué sincronizar en cada dirección

Una integración típica ERP-ecommerce maneja al menos estos flujos:

El problema del stock (donde más se rompe todo)

El stock es donde más fallan las integraciones, porque hay que decidir entre dos verdades en conflicto:

• El ERP dice "tengo 10 unidades disponibles".
• El e-commerce dice "tengo 10 unidades disponibles porque ayer me sincronicé con el ERP, pero acabo de tener 3 pedidos que todavía no le mandé".

Si no resolvés esto, vendés online cosas que no podés despachar.

Patrón que funciona:

1. El ERP es la fuente de verdad del stock físico (lo que está en el depósito).
2. El e-commerce mantiene un "stock reservado" = pedidos cerrados que todavía no se despacharon.
3. El stock disponible para nuevas ventas = stock físico (ERP) - stock reservado (e-commerce).
4. Cuando se cierra un pedido, el e-commerce mueve la unidad de "disponible" a "reservada" inmediatamente, sin esperar al ERP.
5. El ERP descuenta el stock físico cuando se despacha (no cuando se vende).
6. Reconciliación nocturna: el e-commerce y el ERP comparan totales y disparan alertas si hay discrepancias mayores a X%.

Con este patrón, el riesgo de oversell baja a casi cero, sin sacrificar velocidad de carga del e-commerce.

Los seis errores que cuestan caro

1. Sincronizar todo, todo el tiempo

Es tentador "tener todo sincronizado siempre". En la práctica, sincronizás cosas que no usás y la integración se vuelve frágil. Lo correcto: definí qué dato necesita estar fresco y a qué frecuencia. Catálogo cada 6 horas, precios cada 5 minutos, stock en tiempo real. No hace falta más.

2. No diseñar para reintentos

Las APIs fallan. Las redes se caen. Si tu integración no sabe reintentar (con backoff exponencial), perdés transacciones. Lo correcto: cada operación crítica tiene que ser idempotente y reintentable. Si un pedido se intenta crear dos veces porque la red falló, el segundo intento detecta que ya existe y no duplica.

3. No logear lo suficiente

Cuando algo falla, vas a necesitar saber qué pasó. Loguear cada llamada, su payload, su respuesta, los reintentos. Sin logs, debuggear un problema de stock puede llevar días.

4. Hardcodear la lógica de mapping

"El SKU del e-commerce es el mismo que el del ERP" suele ser falso. O al principio sí, y a los 6 meses alguien cambia algo y dejan de matchear. Lo correcto: tener una tabla de mapping explícita y fácilmente editable.

5. No tener monitoreo

Si la integración falla a las 23:00 del viernes, vas a enterarte el lunes cuando ya perdiste un fin de semana de ventas. Monitoreo: ¿se está ejecutando la sincronización? ¿Hay errores acumulándose? ¿Hay discrepancias entre los dos sistemas mayores a X%? Alertas a Slack/email cuando algo se desvía.

6. No probar con datos reales antes de salir

Una integración probada solo con datos sintéticos suele romperse en producción con la primera semana de datos reales (caracteres especiales, SKUs raros, productos que el ERP marcó como inactivos pero el e-commerce sigue mostrando). Lo correcto: replicar la base del ERP en staging y probar 1-2 semanas antes de cortar a producción.

Checklist para arrancar bien

1. Listá los datos que querés sincronizar, y para cada uno definí: fuente de verdad, frecuencia de actualización, qué pasa si la sincronización falla.
2. Elegí el pattern según volumen y criticidad. Batch para casos chicos y poco urgentes, webhooks para casi-real-time, capa de integración para empresas medianas con múltiples integraciones.
3. Diseñá para fallas desde el día uno: reintentos, idempotencia, logging, alertas, reconciliación periódica.
4. Probá con datos reales en staging antes de salir a producción. Mínimo 1-2 semanas paralelo (operación manual + integración corriendo en sombra, comparando resultados).
5. Definí ownership del mantenimiento. Quién monitorea, quién atiende cuando falla, quién actualiza cuando uno de los sistemas cambia su API.

Cuánto tiempo y plata

Rangos honestos para integraciones productivas (no demos):

• Batch o polling simple (Shopify ↔ ERP estándar como Bejerman, Tango, Calipso): 6-12 semanas, USD 15.000-40.000.
• Webhooks bidireccional con stock en cuasi-real-time: 10-16 semanas, USD 30.000-80.000.
• Capa de integración con varios sistemas (ERP + e-commerce + marketplaces + logística + pagos): 14-26 semanas, USD 60.000-180.000.
• Migración desde una integración rota a una bien hecha: 10-20% más por la limpieza de datos heredados y el período de coexistencia.

Mantenimiento ongoing: típicamente 15-25% del costo inicial por año, dividido en monitoreo, ajustes cuando los sistemas externos cambian sus APIs, y evoluciones del negocio.

En síntesis

Integrar ERP con e-commerce bien no es opcional para una empresa que vende online y crece. La diferencia entre una integración bien diseñada y una mal diseñada se mide en pedidos no despachados, errores de stock, tiempo del equipo administrativo, y oportunidades comerciales perdidas. El pattern correcto depende del volumen, la frescura requerida de cada dato, y la cantidad de sistemas que tenés que conectar. Para la mayoría de las empresas medianas argentinas, una arquitectura híbrida (webhooks donde se puede + polling donde no + capa de integración si hay 3+ sistemas) es lo que mejor balance entrega.

En Pisol diseñamos e implementamos integraciones entre ERPs (locales y globales), e-commerce (Shopify, Magento, Tienda Nube, custom), marketplaces (Mercado Libre, Amazon), sistemas de logística y pasarelas de pago. Si tu integración está rota o estás por empezar una, contanos qué sistemas tenés que conectar y armamos juntos la arquitectura adecuada.