La primera señal de que un ERP y un ecommerce están demasiado pegados no suele ser un error técnico. Es una cola de pedidos retenidos, un cliente que recibe una promesa imposible o un equipo de atención al cliente que pasa la mañana entera explicando por qué el stock “sí estaba” en un sistema y “no estaba” en otro.
La pregunta importante no es si se pueden integrar, sino qué parte del negocio debe seguir funcionando cuando la integración falla.
Esa es la tesis de fondo: en una empresa que vende online y opera con stock, albaranes, precios y devoluciones, la integración no es el objetivo. Es un medio. Y como todo medio, puede simplificar la vida o convertir cada excepción en una crisis compartida.
El síntoma real no es el error, es la dependencia
Muchas conversaciones sobre ERP y ecommerce empiezan en el terreno equivocado: el conector, la API, el middleware, el plugin. Pero la decisión operativa real aparece cuando hay una excepción: una tarifa especial, un pedido parcial, una reserva de inventario, una devolución con reembolso, una venta B2B con condiciones propias.
Ahí se ve si la empresa ha construido una arquitectura de reglas o solo un cable entre sistemas.
Señales de dependencia excesiva:
- Un pequeño fallo en la sincronización bloquea pedidos completos.
- El equipo comercial no sabe dónde corregir precios o descuentos.
- Atención al cliente necesita consultar dos pantallas para responder una incidencia.
- Operaciones desconoce qué cambios del front afectan al back office.
- Cada excepción termina con “lo arreglamos manualmente y luego ya veremos”.
Cuando esto ocurre, la integración deja de ser una ventaja y se convierte en una fuente de deuda operativa.
Cuándo separar tiene sentido
Separar no significa desconectar todo. Significa admitir que no todos los datos deben mandar el mismo tipo de verdad. En ecommerce, la promesa al cliente necesita velocidad; en ERP, la contabilidad operativa necesita consistencia; en almacén, la ejecución necesita instrucciones estables.
Separar sistemas tiene sentido cuando:
- el catálogo cambia con mucha frecuencia y el back office no debe bloquear esas actualizaciones;
- hay varios canales de venta con reglas distintas;
- el stock real depende de ubicaciones, reservas o preparación parcial;
- el ecommerce necesita evolucionar sin someter cada cambio a un ciclo largo de validación ERP;
- el ERP es fuerte en operación interna, pero no debe decidir la experiencia digital completa.
Un caso habitual: una distribuidora con tienda online, pedidos por teléfono y ventas internas. Durante meses vive con una integración “total”. Todo parece correcto hasta que una campaña dispara el tráfico, se agota una referencia crítica y el sistema intenta reservar inventario que ya estaba comprometido en otro canal. El síntoma visible es una venta perdida. El problema de fondo es que ningún equipo definió quién manda sobre la promesa de entrega cuando dos canales compiten por el mismo stock.
La empresa que sale mejor de esa situación no es la que “integra mejor”, sino la que decide con claridad qué sistema es fuente de verdad para cada regla.
La decisión incómoda: aceptar duplicidad parcial
Aquí está la parte que incomoda a muchos responsables: a veces conviene aceptar cierta duplicidad temporal o parcial. No por gusto, sino porque unificarlo todo demasiado pronto obliga a someter cada cambio comercial al ritmo del sistema más rígido.
Eso tiene un coste claro:
- más disciplina en gobierno de datos;
- más cuidado al definir qué atributo vive en cada sistema;
- más procesos de reconciliación;
- menos tentación de “corregir luego en masa”.
Pero el coste de no hacerlo puede ser peor: una operación donde cualquier excepción se convierte en incidencia de integración.
La mala decisión no es tener dos sistemas. La mala decisión es no documentar qué pasa cuando se contradicen. Si el precio cambia en ecommerce pero no en ERP, ¿quién corrige? Si hay stock reservado en una campaña y llega una devolución, ¿qué estado prevalece? Si un pedido entra incompleto, ¿qué equipo lo desbloquea y con qué criterio?
Esas preguntas no son técnicas. Son de gobierno operativo.
Qué mirar antes de decidir
Antes de rediseñar la integración, conviene observar la operación real durante unas semanas. No hace falta empezar por una auditoría monumental. Basta con identificar señales concretas:
- cuántas incidencias nacen de excepciones y no de fallos masivos;
- cuánto tiempo tarda un pedido retenido en volver a flujo normal;
- qué cambios comerciales obligan a tocar el ERP;
- cuántas correcciones se hacen manualmente y con qué frecuencia se repiten;
- qué sistema pierde credibilidad cuando hay una discrepancia.
Si el ecommerce se ha convertido en un escaparate que no puede cambiar sin pedir permiso al ERP, la experiencia comercial se ralentiza. Si el ERP se adapta a cada capricho del canal online, la operación interna pierde estabilidad. Ninguno de los dos extremos es buena noticia.
La decisión madura suele ser menos glamurrosa que la promesa inicial: separar donde la velocidad importa, integrar donde la consistencia manda y definir reglas explícitas para las zonas grises.
Esa claridad reduce fricción, pero también obliga a asumir responsabilidades. Y eso, para una dirección general, vale más que una integración elegante pero frágil.
En Codefuente solemos empezar precisamente por ahí: no por el conector, sino por las reglas que deben sobrevivir cuando el sistema no acompaña. Si tu empresa está dudando entre unificar o separar, la pregunta útil no es qué tecnología parece más limpia, sino qué operación quieres proteger cuando algo falle.