Una empresa puede vender más y, aun así, operar peor.

El problema no suele ser que falten integraciones, sino que la integración esté absorbiendo decisiones que deberían vivir en el proceso.

Ese patrón aparece mucho en pymes que han crecido por capas: primero una tienda online, luego un ERP, después un marketplace, un CRM, una herramienta de logística y, finalmente, una red de automatizaciones que nadie controla del todo. Desde fuera parece ordenado porque “todo está conectado”. Por dentro, el equipo vive en una cadena de excepciones: pedidos bloqueados, stock que no cuadra, facturas que llegan tarde, devoluciones mal imputadas y clientes a los que se les promete algo que el back office ya no puede cumplir.

Mi tesis es simple: cuando ecommerce y ERP empiezan a definir la operativa diaria, la pregunta correcta no es cómo sincronizar más datos, sino qué sistema debe mandar sobre cada decisión. Si no se responde, la integración deja de ser una ventaja y se convierte en una fuente de fricción.

El síntoma típico: la integración funciona, pero la operación no

El error más común es medir el éxito por el estado técnico del conector. “Los pedidos entran”, “el stock baja”, “la factura se genera”. Pero la operación no se evalúa por si el dato viaja, sino por si el equipo puede trabajar sin frenar ventas ni fabricar urgencias.

Hay señales muy concretas de que la arquitectura ya está mal planteada:

• El equipo comercial promete plazos que logística corrige después.
• Se crean pedidos manuales para saltear reglas del sistema.
• Un mismo producto tiene precios, unidades o impuestos distintos según el canal.
• El stock disponible depende de sincronizaciones por lotes y no de una fuente clara de verdad.
• Cada excepción requiere intervención de alguien “que sabe dónde tocar”.

Cuando esto ocurre, la integración ya no está resolviendo fricción. La está ocultando.

Qué debe vivir en el front y qué debe mandar el back office

No todas las decisiones necesitan el mismo nivel de control. Un error habitual es mover demasiado poder al ecommerce porque “es donde vende”. Eso funciona al principio, pero se vuelve peligroso cuando la operación crece.

Una división útil suele ser esta:

• Front ecommerce: catálogo visible, experiencia de compra, promociones de canal, contenido comercial y reglas de presentación.
• Back office ERP: stock comprometible, costes, impuestos, preparación, facturación, trazabilidad, reglas de crédito y estados operativos.

El problema no es técnico, es de gobierno. Si el ecommerce decide el stock, los precios y la prioridad de preparación, el ERP deja de ser sistema de control y se vuelve un espejo tardío. Si el ERP impone demasiadas reglas al front, la tienda se vuelve rígida y el negocio pierde agilidad comercial.

La clave está en definir quién es la autoridad de cada dato y de cada estado. Por ejemplo:

• El precio comercial puede nacer en ecommerce, pero el precio efectivo debe validarse en ERP si hay listas, descuentos o márgenes por canal.
• La disponibilidad visible puede venir de una capa intermedia, pero el stock comprometido debe vivir en un único sistema.
• El estado del pedido para cliente puede simplificarse, pero internamente debe conservar hitos operativos claros.

Mini-caso: cuando “sincronizar todo” empeoró la distribución

Una empresa mediana de distribución, con venta directa y canal online, llegó con un problema típico: querían que el ecommerce mostrara stock en tiempo real y que el ERP recibiera cada pedido sin retraso. La teoría era razonable. La práctica, no tanto.

Cada ajuste de stock disparaba un efecto en cadena: reservas incompletas, pedidos parcialmente confirmados y atención al cliente respondiendo sobre pedidos que aún no habían pasado por revisión operativa. El equipo había ganado velocidad aparente, pero había perdido control.

La solución no fue “mejorar la sincronización”, sino cambiar la regla de negocio. En vez de publicar el stock bruto, se mostró stock comprometible con un margen de seguridad por canal. Además, algunos pedidos de alto riesgo no entraban automáticamente en preparación hasta pasar una validación simple de margen, crédito o incidencias previas. Eso redujo ventas impulsivas en ciertos casos, pero también redujo errores, anulaciones y llamadas internas para apagar incendios.

La lección es incómoda: a veces la mejor integración es la que acepta cierta latencia o cierta limitación funcional para proteger la operación.

La decisión incómoda: sacrificar inmediatez para ganar control

Este es el punto donde muchos equipos dudan. Separar mejor front y back office suele implicar renunciar a algo: inmediatez total, simplicidad aparente o autonomía absoluta del canal comercial.

No es una decisión popular. Comercial quiere velocidad. Operaciones quiere certeza. Finanzas quiere trazabilidad. Tecnología quiere una arquitectura limpia. No siempre se pueden maximizar las cuatro cosas a la vez.

La pregunta útil no es “¿podemos sincronizarlo en tiempo real?”, sino:

• ¿Qué error nos cuesta más dinero: vender de más o vender con una pequeña restricción?
• ¿Qué dato debe ser exacto ahora mismo y cuál puede actualizarse en segundos o minutos?
• ¿Qué excepciones justifican intervención humana y cuáles deberían automatizarse?
• ¿Qué sistema será responsable cuando haya discrepancia?

Si esa discusión no se da, el proyecto se resuelve con más conectores, más reglas y más deuda operativa.

Qué revisar antes de rediseñar la integración

Antes de tocar la arquitectura, conviene revisar cuatro cosas:

1. Autoridad del dato: un solo sistema para cada dato crítico.
2. Estados operativos: definir qué significa “confirmado”, “reservado”, “preparado” o “facturado”.
3. Excepciones frecuentes: devoluciones, pedidos mixtos, roturas de stock, cambios de precio y crédito bloqueado.
4. Métricas operativas: no solo pedidos creados, sino porcentaje de pedidos con intervención manual, tiempo de resolución de incidencias, rotación real de stock y tasa de cancelación por error de integración.

Cuando esas piezas están claras, la integración deja de ser un parche y pasa a ser una decisión de diseño.

La conclusión es sencilla: en ecommerce y ERP, integrar no siempre significa unir más; a veces significa separar mejor para que cada sistema haga lo que sabe hacer sin invadir al otro. Ese tipo de decisión es menos vistosa que un conector “perfecto”, pero mucho más rentable para la operación. En Codefuente solemos empezar precisamente por ese mapa de decisiones antes de proponer tecnología.