Hay una escena que se repite en muchas pymes: el equipo de operaciones ve un pedido “confirmado” en la tienda online, pero el almacén no lo puede preparar, contabilidad todavía no lo considera facturable y atención al cliente ya está respondiendo al cliente con una promesa que nadie ha validado. En ese momento no falla el canal de venta; falla el diseño operativo.
El problema rara vez es que ERP y ecommerce “no hablen”. El problema es que hablan demasiado de cosas que no deberían decidir solos.
La discusión habitual suele plantearse mal: integrar o separar. Esa frase suena técnica, pero en realidad es una decisión de gobierno. Cuando una empresa une demasiado ERP, ecommerce, logística y soporte, gana rapidez al principio y pierde claridad cuando llegan excepciones: reservas parciales, devoluciones, sustituciones, tarifas especiales, ventas B2B con condiciones distintas o productos con stock real distribuido entre varios puntos.
La señal de que la integración ya está escondiendo el problema
No hace falta una caída para detectar que el diseño no aguanta. Hay señales mucho más útiles:
- El equipo repite frases como “ya lo vemos en el ERP” o “eso lo corrige comercio”.
- Un pedido necesita tres revisiones manuales antes de considerarse cerrado.
- El mismo dato se corrige en dos sistemas distintos según quién llame primero.
- Soporte atiende incidencias que en realidad son decisiones de inventario, precio o estado.
- Los informes cuadran a final de mes, pero no durante la semana.
Cuando aparecen estas señales, la integración no está resolviendo el flujo; lo está maquillando. El error común es pedir más automatización o más conectores cuando lo que falta es una definición clara de qué sistema manda en cada estado del pedido, del stock y de la factura.
Cuándo separar sistemas sí mejora la operación
Separar no significa volver al caos de los datos duplicados. Significa aceptar que no todas las capas deben moverse al mismo ritmo ni con la misma autoridad.
Hay casos en los que separar el front del back office es sensato:
- Cuando el ecommerce cambia con frecuencia por campaña, UX o catálogo.
- Cuando el ERP necesita estabilidad contable, trazabilidad y control de excepciones.
- Cuando hay varios canales de venta con reglas distintas.
- Cuando la gestión de incidencias requiere autonomía frente a la promesa comercial.
Un caso compuesto muy típico: una empresa vende recambios y material técnico por ecommerce y también atiende pedidos de distribución con precios pactados. Durante años intentó que “todo pasara por el ERP”. El resultado fue un sistema muy rígido: cualquier cambio en la tienda online exigía tocar reglas internas que afectaban a facturación, devoluciones y disponibilidad.
Al separar mejor las responsabilidades, mantuvieron el catálogo y la experiencia comercial en el front, mientras el back office conservó el control de stock comprometido, expediciones y facturación. No eliminaron problemas, pero redujeron el número de decisiones ambiguas. La mejora no vino de integrar más, sino de decidir mejor qué debía mantenerse independiente.
La decisión incómoda: menos automatización, más fricción útil
Esta es la parte que incomoda a muchos equipos: a veces la solución correcta no es automatizar más, sino introducir una pequeña fricción.
Eso puede significar:
- Confirmación manual para pedidos de alto riesgo.
- Estados intermedios visibles en lugar de un “confirmado” demasiado optimista.
- Reglas distintas para stock disponible, stock comprometido y stock publicable.
- Un circuito de excepción para devoluciones, en vez de tratarlas como un caso más.
Desde fuera parece menos eficiente. En la práctica, evita que la empresa regale promesas que luego nadie puede cumplir. La automatización solo compensa cuando la excepción está suficientemente bien acotada. Si no, la velocidad solo multiplica el error.
La pregunta útil no es “¿podemos automatizar esto?”. La pregunta correcta es: “¿qué decisión se vuelve irreversible si este flujo falla?”. Ahí aparece el verdadero criterio arquitectónico.
Cómo decidir con criterio, no por impulso tecnológico
Antes de tocar integración, conviene responder a cuatro preguntas:
- ¿Qué sistema debe ser fuente de verdad para cada dato: precio, stock, pedido, factura, devolución?
- ¿Dónde se produce más coste cuando algo falla: en ventas, en almacén, en finanzas o en atención al cliente?
- ¿Qué excepciones son frecuentes y cuáles son realmente raras?
- ¿Qué equipo necesita autonomía para operar sin bloquear al resto?
Si una empresa no puede contestar esto, lo más probable es que esté comprando una discusión futura. Porque el problema no será “la integración”, sino el desacuerdo sobre quién tenía autoridad para decidir.
Una buena señal de madurez es que el sistema soporta errores previsibles sin crear urgencias artificiales. No hace falta que todo esté unificado; hace falta que cada parte tenga límites claros y que las excepciones se gestionen donde tienen sentido.
En Codefuente solemos ver que la mejor arquitectura no es la más integrada, sino la que deja menos decisiones implícitas. Y en ecommerce eso suele marcar la diferencia entre operar con control o vivir corrigiendo pedidos a mano.