Shopify y ERP: cuándo la integración deja de ser un conector y pasa a ser una decisión operativa

Una empresa vende bien en Shopify. El ERP ya existe, finanzas confía en sus cifras y operaciones tiene su propio ritmo. Entonces llega la petición “simple”: conectar todo para que los pedidos entren solos, el stock se actualice en tiempo real y la facturación deje de depender de tareas manuales.

El problema no suele ser integrar Shopify con el ERP. El problema es descubrir tarde que cada equipo estaba usando una definición distinta de pedido, stock y devolución.

Mi tesis es clara: una integración Shopify-ERP no debe diseñarse como un tubo de datos, sino como una decisión sobre gobierno operativo. Si no defines antes qué sistema manda en cada evento, la integración solo trasladará el caos a un lugar más rápido.

El fallo típico: automatizar reglas que aún están discutidas

En muchos proyectos, la discusión técnica empieza antes que la operativa. Se habla de plugins, webhooks, middleware, colas, campos personalizados y frecuencia de sincronización. Todo eso importa. Pero hay una pregunta previa mucho más costosa: ¿qué significa “stock disponible” para tu negocio?

Puede significar varias cosas:

• stock físico en almacén
• stock reservado pero no expedido
• stock comprometido en canales externos
• stock disponible para preventa
• stock que se puede vender aunque aún no se haya conciliado contablemente

Si Shopify publica una cifra y el ERP otra, no tienes un problema de integración. Tienes una definición ambigua.

Lo mismo ocurre con los pedidos. Para ecommerce, un pedido “existe” cuando el pago entra. Para operaciones, puede existir cuando se valida disponibilidad. Para finanzas, cuando se emite la factura. Si no eliges una secuencia clara, terminarás con pedidos duplicados, devoluciones mal tratadas o facturas emitidas antes de tiempo.

Qué debe decidir la empresa antes de conectar sistemas

Antes de tocar la tecnología, conviene cerrar cinco decisiones operativas:

1. Sistema maestro por dato. ¿Quién manda sobre cliente, producto, precio, stock, pedido y factura?
2. Evento de origen. ¿Qué sistema crea el registro y cuál solo lo replica?
3. Manejo de excepciones. ¿Qué pasa si falta stock, falla un pago o un pedido entra con datos incompletos?
4. Latencia aceptable. ¿Necesitas tiempo real, cada 5 minutos o una sincronización por lotes varias veces al día?
5. Responsable de corrección. ¿Quién revisa y corrige cuando dos sistemas discrepan?

Este punto suele incomodar porque obliga a elegir. Y elegir implica renunciar a cierta flexibilidad. Pero una integración sin dueño operativo acaba siendo un generador de incidencias.

Un criterio práctico: si una decisión afecta a dinero, stock o cumplimiento fiscal, no debe depender de una sincronización “best effort”. Debe tener un comportamiento explícito ante fallos.

Mini-caso: cuando el stock en Shopify era correcto… hasta que dejó de serlo

Caso compuesto, muy realista: una empresa de recambios industrial vende por Shopify y también por canal comercial interno. El ERP era la referencia para compras y contabilidad, pero Shopify mostraba stock casi en tiempo real.

Al principio todo parecía funcionar. El problema apareció en tres escenarios:

• reservas manuales de clientes grandes
• devoluciones con inspección diferida
• artículos con stock repartido entre varios almacenes

La integración seguía “funcionando”, pero el negocio no. El equipo comercial veía unidades disponibles que operaciones ya había comprometido. Atención al cliente prometía reposición antes de que compras la confirmara. Finanzas recibía correcciones tardías.

La solución no fue “más integración”. Fue redefinir el proceso:

• el ERP pasó a ser maestro del stock comprometido
• Shopify solo mostró stock vendible con reglas conservadoras
• las devoluciones se clasificaron por estado antes de reingresar inventario
• se creó una cola de excepciones para pedidos no reconciliados

Resultado práctico: menos automatismo aparente, pero muchas menos incidencias y menos trabajo manual invisible.

La decisión incómoda: no todo debe ir en tiempo real

Este es el punto más controvertido. Muchos equipos piden tiempo real porque suena a control y modernidad. En la práctica, el tiempo real puede ser una mala decisión si:

• el dato cambia con frecuencia y genera ruido
• el proceso de negocio aún no está estabilizado
• hay múltiples almacenes o canales con reglas distintas
• la corrección manual posterior es frecuente

En esos casos, una sincronización por lotes bien diseñada puede ser mejor que una integración instantánea. No porque sea más elegante, sino porque reduce la velocidad de propagación del error.

Otro error común es empujar todo al middleware. El middleware no debería decidir la política de negocio; debería ejecutar reglas ya acordadas. Si se convierte en el lugar donde “se improvisa”, se vuelve otro ERP paralelo.

Señales de que tu integración ya necesita rediseño

No hace falta esperar a una caída grande. Hay señales tempranas bastante claras:

• el equipo revisa exportaciones manuales “para confirmar” lo que ya integró
• aumentan las excepciones de stock sin que el catálogo cambie mucho
• soporte detecta pedidos que finanzas no ve o viceversa
• alguien dice “esto normalmente se corrige después”
• cada incidencia termina en una explicación artesanal

Cuando aparecen varias de estas señales, el problema ya no es conectar sistemas. Es decidir qué proceso quieres que sobreviva a la integración.

Cierre

Integrar Shopify y ERP puede ser una muy buena decisión. Pero solo cuando la empresa acepta que la pregunta principal no es tecnológica, sino operativa: qué dato manda, qué excepción se tolera y quién responde cuando la realidad no encaja con el flujo ideal. En proyectos así, Codefuente suele empezar precisamente por esas decisiones antes de construir la capa técnica.