Un ecommerce puede vender bien durante meses y, aun así, romper la operación por dentro. El patrón suele ser el mismo: el catálogo se ve correcto, los pedidos entran, el ERP recibe datos, y todo parece ordenado hasta que aparecen las excepciones. Entonces llegan las devoluciones parciales, los descuentos comerciales fuera de calendario, los cambios de stock a mitad del día, las facturas retenidas o los pedidos que no deberían haber salido todavía.
La mayoría de las integraciones no fallan por falta de tecnología. Fallan porque nadie definió qué sistema tiene la última palabra cuando el proceso deja de ser estándar.
Mi tesis es simple: una integración ERP-ecommerce no debería diseñarse como un puente de datos, sino como un sistema de decisión operativa. Si no defines quién manda en cada caso, acabas con dos sistemas coherentes en apariencia y contradictorios en la práctica.
El síntoma habitual: todo sincroniza, pero la operación sigue desordenada
Muchos equipos creen que el problema está en la calidad del conector. A veces sí, pero rara vez es la causa principal. Lo habitual es que el negocio haya acumulado reglas implícitas que nunca se documentaron:
- El ecommerce acepta pedidos aunque el stock esté comprometido por canales distintos.
- El ERP corrige precios después de que el cliente ya ha comprado.
- Atención al cliente modifica pedidos sin dejar claro qué evento debe reflejarse en finanzas.
- Logística trabaja con estados propios que no coinciden con los del front.
El resultado es conocido: más tickets internos, más ajustes manuales y más reuniones para aclarar por qué dos pantallas muestran verdades diferentes.
Un indicador muy claro de que la integración está mal planteada es este: si necesitas revisar manualmente los casos “normales” todos los días, la arquitectura ya no está soportando el negocio. No hace falta un gran incidente para notarlo. Basta con ver cuántas excepciones se convierten en rutina.
Qué debe decidirse antes de tocar la integración
Antes de hablar de APIs, colas o middleware, conviene responder preguntas muy concretas. No son preguntas técnicas en sentido estricto; son preguntas de gobierno operativo.
-
Quién es la fuente de verdad para cada dato crítico
- Precio: ¿ERP, ecommerce o PIM?
- Stock disponible: ¿ERP, WMS o una reserva intermedia?
- Estado del pedido: ¿el sistema de venta o el de expedición?
- Cliente: ¿CRM, ERP o ecommerce?
-
Qué eventos son automáticos y cuáles requieren revisión
- Un cambio de dirección puede ser automático antes de expedición.
- Una modificación de precio después de pagar quizá no deba serlo.
- Un pedido incompleto puede necesitar una cola de revisión humana.
-
Qué latencia es aceptable
- No todo necesita tiempo real.
- Hay procesos que funcionan mejor con sincronización casi inmediata.
- Otros mejoran si se actualizan por lotes, con validación y trazabilidad.
-
Qué pasa cuando hay conflicto entre sistemas
- ¿Se bloquea el pedido?
- ¿Se marca como pendiente?
- ¿Se aplica la regla del ERP y se notifica al ecommerce?
- ¿O se deja un conflicto visible para operaciones?
La clave es que estas decisiones se escriban antes del desarrollo. Si se resuelven en producción, ya no son decisiones: son parches.
Mini caso: cuando el problema no era el conector
En un caso compuesto muy típico, una empresa B2B con ecommerce y ERP pensaba que necesitaba “una integración más robusta”. El síntoma era que algunos pedidos se confirmaban con precios desactualizados y otros quedaban bloqueados sin explicación clara.
Después de revisar el proceso, apareció el verdadero problema: ventas podía publicar tarifas promocionales en el front, pero finanzas mantenía reglas distintas para descuentos por cliente. Además, stock y reservas se actualizaban en ventanas distintas. Nadie había definido cuál de los dos sistemas debía prevalecer cuando una promoción caducaba durante una sesión de compra.
La solución no fue “sincronizar más rápido”. Se hicieron tres cambios más útiles:
- Se definió una fuente de verdad por campo, no por sistema completo.
- Se creó una cola de excepciones para pedidos con conflicto de precio o stock.
- Se aceptó que ciertos pedidos no debían automatizarse al 100%.
El resultado operativo fue menos glamuroso que “automatización total”, pero mucho más valioso: menos correcciones manuales, menos reclamaciones internas y una trazabilidad que permitía explicar por qué un pedido se había tratado de una forma concreta.
La decisión incómoda: no todo debe integrarse en tiempo real
Aquí está una de las decisiones más incómodas, y también más sanas: algunas integraciones mejoran cuando dejan de ser instantáneas.
Eso choca con la intuición de muchos equipos. Parece que si un dato tarda más de unos segundos, el sistema es peor. Pero en operaciones reales, el tiempo real puede amplificar errores:
- Si una reserva de stock llega antes de validarse, puedes sobrevender.
- Si una promoción se propaga sin control, puedes facturar mal.
- Si un estado cambia automáticamente sin revisión, puedes disparar logística para un pedido incorrecto.
A veces conviene introducir una validación intermedia, una cola o un estado “pendiente de confirmación”. No es una renuncia a la automatización. Es una forma de evitar que la velocidad convierta una excepción pequeña en un error caro.
También hay una decisión poco popular: no todos los procesos deben tratarse igual. Un pedido estándar no necesita el mismo nivel de supervisión que un pedido con tarifa negociada, condiciones especiales o varias entregas parciales.
Señales de que tu integración ya necesita rediseño
Hay señales operativas muy concretas:
- El equipo usa Excel para reconciliar pedidos entre sistemas.
- Los tickets de soporte repiten las mismas tres causas.
- Las correcciones manuales crecen justo cuando el volumen crece.
- Finanzas y operaciones discuten sobre “qué dato es el correcto”.
- Cada cambio comercial requiere una mini intervención técnica.
Si esto ocurre, el problema no es solo de software. Es que el diseño operativo se quedó atrás.
La forma más útil de abordar una integración ERP-ecommerce es empezar por el flujo crítico, no por la herramienta. Mapear excepciones, definir responsabilidades por dato y aceptar que algunos procesos necesitan control humano es más efectivo que añadir otra capa de automatización sin criterio.
En Codefuente solemos empezar precisamente por esas decisiones de negocio y operación, porque son las que determinan si la integración ayuda de verdad o solo añade complejidad elegante.