El error habitual: tratar la integración como un problema de transporte
Una empresa puede tener un ERP sólido, una tienda online bien vendida y aun así operar mal. El motivo suele ser simple: se piensa la integración como un canal para mover datos, cuando en realidad es una forma de decidir qué proceso manda.
Cuando un pedido entra por ecommerce, el sistema no solo debe “pasarlo” al ERP. Debe decidir si ese pedido se confirma de inmediato, si se reserva stock, si espera validación, si se divide en varios envíos o si se bloquea por una incidencia comercial. Si esa lógica no está escrita, la integración se convierte en una cadena de parches.
Mi tesis es directa: en ERP y ecommerce, el valor no está en sincronizar más objetos, sino en reducir ambigüedad operativa. Una integración rápida pero mal gobernada suele generar más retrabajo que una integración más modesta, pero con reglas claras.
Integrar sistemas sin definir excepciones es una forma elegante de automatizar problemas.
Qué debe decidirse antes de tocar la API
Antes de hablar de conectores, webhooks o middleware, conviene cerrar cinco decisiones operativas.
- Sistema de referencia por dato: ¿quién manda en clientes, precios, stock, impuestos, estados de pedido y facturación?
- Momento de compromiso: ¿cuándo un pedido deja de ser editable y pasa a ser una obligación operativa?
- Manejo de excepciones: ¿qué ocurre con pedidos incompletos, stock negativo, precios desactualizados o direcciones inválidas?
- Secuencia financiera: ¿la factura nace del pago, del envío o de la expedición?
- Trazabilidad: ¿cómo se revisa un caso sin entrar en tres pantallas y dos hojas de cálculo?
Si estas respuestas no existen, el proyecto acaba discutiendo sobre mensajes, colas y endpoints, cuando el problema real es de negocio. Por eso, en integraciones serias, el documento más importante no es el diagrama técnico, sino la tabla de reglas operativas.
También conviene aceptar una verdad incómoda: no todo debe sincronizarse en tiempo real. Hay datos que necesitan inmediatez, sí. Pero otros funcionan mejor por lotes, con validación y reconciliación. Obligar a todo a ser instantáneo suele aumentar fragilidad, coste y dependencia de terceros.
Mini-caso: cuando el stock “correcto” no era suficiente
Un distribuidor B2B y ecommerce vendía productos con mucha rotación y alguna referencia crítica. Su problema no era la falta de integración, sino la falta de criterio común entre ventas, almacén y administración.
La tienda mostraba stock disponible en tiempo real, pero el almacén necesitaba reservar unidades para pedidos recurrentes y la administración bloqueaba ciertas salidas por riesgo de crédito. Resultado: pedidos aceptados en la web que luego no podían cumplirse sin intervención manual.
La solución no fue “sincronizar mejor”. Fue redefinir las reglas:
- stock público distinto de stock comprometido
- pedido confirmado solo después de validar crédito en ciertos clientes
- factura generada por evento logístico en unas líneas y por cobro en otras
- alertas cuando una modificación manual rompía la secuencia normal
La mejora real vino de reducir decisiones improvisadas. El conector siguió siendo importante, pero dejó de ser el centro del proyecto.
La decisión incómoda: a veces hay que aceptar menos automatización
Hay un punto que muchos equipos evitan: automatizar todo puede empeorar la operación. Si el negocio tiene mucha casuística, devoluciones complejas, precios especiales o restricciones por cliente, una automatización total obliga a introducir demasiadas excepciones en el software.
Eso crea dos riesgos:
- la integración se vuelve difícil de mantener
- el equipo deja de entender qué hace el sistema en cada caso
En ciertos contextos, es mejor automatizar el 80% de los flujos y dejar un 20% bajo revisión operativa con colas claras, roles definidos y SLA internos. No es una derrota técnica; es una forma de proteger la continuidad.
Los indicadores que muestran que la automatización está mal planteada son bastante reconocibles: pedidos retenidos sin explicación, conciliaciones manuales diarias, cambios de estado que nadie puede auditar, facturas rehacidas y tickets recurrentes sobre “el sistema no entiende este caso”.
Cómo se diseña una integración que aguanta la operación
Una integración útil no se mide por el número de objetos sincronizados, sino por su capacidad de sobrevivir a cambios reales del negocio.
Tres criterios ayudan mucho:
- Idempotencia y reintentos seguros: si un mensaje se repite, no debe duplicar pedidos ni facturas.
- Observabilidad: cada evento debe poder rastrearse desde su origen hasta su efecto final.
- Reconciliación: siempre debe existir un mecanismo para comparar el estado esperado con el estado real.
Además, conviene definir desde el principio qué fallos se resuelven automáticamente y cuáles generan intervención humana. Esa frontera es una decisión de diseño, no un detalle técnico.
Las empresas que mejor ejecutan estas integraciones no son las que conectan más rápido, sino las que primero estabilizan su modelo operativo. Cuando eso está claro, la tecnología deja de ser una fuente de fricción y pasa a ser una capa de control.
En Codefuente solemos empezar por esas reglas antes que por el conector, porque en ecommerce y ERP la integración correcta es la que la operación puede sostener mañana, no solo la que funciona hoy.