Por qué conectar tu tienda online al ERP sale mal (y cómo evitarlo)

Por qué conectar tu tienda online al ERP sale caro (y cómo evitarlo)

Una frase se repite en casi todos los proyectos de eCommerce: «solo conéctalo a nuestro ERP». Suena simple, pero detrás de esas cuatro palabras hay una trampa que ha hundido lanzamientos y quemado presupuestos de cientos de miles de dólares. La palabra que hace todo el daño es «solo»: convierte un sistema legacy cargado de años de reglas no documentadas en una línea más de un sprint de dos semanas.

Una nueva tienda es un proyecto greenfield, en limpio: planeas arquitectura y modelo de datos desde cero. La integración con un ERP existente es brownfield, una excavación arqueológica en un sistema que no construiste, que sigue corriendo y que esconde comportamientos que nadie escribió en ningún lado. Tratarlas como si fueran el mismo deporte es la receta para que la demo funcione y la primera orden real reviente el sistema.

El problema: nadie es dueño de las costuras entre sistemas

El checkout autoriza el pago, el motor de impuestos calcula la retención, el ERP abre la orden de venta y reserva stock, contabilidad genera la factura, el almacén prepara el pedido, el CRM registra todo para que soporte tenga algo que mirar la próxima semana. Cada sistema tiene un dueño, pero la costura entre ellos no tiene dueño: es exactamente donde se rompe la tela.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El pago debe confirmarse de forma síncrona, en milisegundos, mientras el cliente espera en pantalla. Todo lo que viene después —abrir la orden en el ERP, reservar inventario, notificar al almacén— tiene que ser asíncrono. No puedes hacer esperar a un cliente que está pagando por una API legacy que responde cuando le da la gana.

Eso significa que la pantalla de confirmación dice «todo listo» un instante antes de que el sistema sepa si realmente puede cumplir. La mayoría de las veces el hueco se cierra en milisegundos y nadie nota nada. Pero a veces no: el pago pasa, el job que crea la orden se cae en silencio y te quedaste con el dinero del cliente y sin pedido detrás. Cuando eso pasa, el que termina acting como middleware humano es un account manager, cruzando logs de pago a mano y re-tipeando órdenes en el ERP.

El ERP viejo es la memoria del negocio, no basura

Cualquier ERP con años en producción acumula una capa gruesa de comportamiento raro que no aparece en la documentación. Campos que se truncan silenciosamente a 40 caracteres desde 2019. Cron jobs que solo funcionan porque alguien los reinicia cada martes. Columnas de «estado del pedido» que significan cinco cosas distintas según qué departamento las tocó por última vez.

Un equipo externo que llega a conectar ese sistema solo ve la fachada. Puede leer el API y las tablas, pero no puede ver qué paredes sin mapear va a usar su integración como apoyo. El alcance se escribe contra el sistema que existe en el papel, no contra el que tose en producción.

Hay un concepto útil aquí, llamado efecto Lindy: cuanto más tiempo ha sobrevivido algo, más probable es que siga sobreviviendo. Ese ERP de 15 años sigue ahí precisamente porque demasiado depende de él para que alguien se arriesgue a sacarlo. Cuando llegas con tu stack nuevo, la tentación es tratar al sistema viejo como lastre a reemplazar. Resistí ese instinto: ese sistema sobrevivió el contacto real con el negocio durante años y sabe cosas que tu código nuevo todavía no sabe.

La secuencia correcta: construir primero, auditar segundo, integrar al final

El error de planificación más común es tratar el nuevo build y la integración como un solo bloque de trabajo, con la misma estimación y el mismo timeline. No lo son, y meterlos en el mismo scope envenena la integración.

Cuando escribís ese alcance combinado, el modelo de datos de la plataforma nueva todavía no existe. Estás diseñando la integración contra un supuesto, encima de la niebla del ERP viejo. Fallás en cualquiera de los dos extremos y terminás haciendo rework masivo justo cuando la deadline está pegando silbidos en tu oído, que es exactamente cuando los developers empiezan a tomar atajos que se vuelven las costuras frágiles que todos sufren después.

La solución es aburrida y por eso funciona:

Construí primero la plataforma nueva. Mientras eso pasa, mandá a un analista a hacer una auditoría pura del ERP existente.
Mapeá qué hace realmente el sistema viejo y dónde están las paredes sin documentar.
Cuando la plataforma nueva esté casi lista y su modelo de datos sea un hecho, no un pronóstico semanal, ahí sí scopeá la integración. Ahora los dos extremos son conocidos.

Cuestioná el workflow legacy antes de automatizarlo

Incluso bien secuenciadas, las integraciones son el trabajo más difícil de estimar, porque tienen una trampa silenciosa que infla el alcance desde adentro. El cliente tiene un proceso interno complejo y enredado. El instinto natural del developer y del analista es agarrar ese proceso y reconstruirlo fielmente en el sistema nuevo.

La pregunta que casi nadie hace es si ese proceso debería seguir existiendo. ¿Era la mitad un andamiaje para una limitación que el sistema nuevo ya no tiene? Clonar un mal proceso que no debería sobrevivir la migración solo traslada el desperdicio a un lugar más caro y te lo cobra como mudanza.

Un caso real: un cliente grande de farmacia tenía el plan original de gestionar toda la descripción rica de producto (copy de marketing, atributos, especificaciones extendidas) dentro de su ERP legacy, y empujar todo ese contenido al eCommerce. Los ERPs estándar son notoriamente malos manejando datasets complejos de eCommerce y contenido visual rico. En lugar de construir una integración frágil y sobre-ingenierada para forzar a un ERP viejo a hacer el trabajo de un PIM, redibujaron las fronteras de la arquitectura. El ERP se quedó estrictamente en su lane: SKUs, títulos base, precios y stock. Mientras tanto, el eCommerce se volvió la fuente única de verdad para el contenido rico del producto, funcionando básicamente como un PIM liviano.

Cuestionando el workflow legacy en vez de automatizarlo ciegamente, ahorraron meses de integración dolorosa y le dieron al equipo una arquitectura que encaja con cómo trabajan hoy.

Qué poner en el medio: una capa de orquestación con memoria

Wiring point-to-point con código custom entre cada par de sistemas es el default incorrecto. Funciona perfecto hasta el día que una orden se queda atascada y tu respuesta honesta es «el evento pasó entre dos sistemas y se evaporó en el éter».

Lo que aguanta es una capa de orquestación explícita en el medio —un pipeline de eventos como n8n, una aplicación con logging y manejo de eventos propios, o una plataforma de mensajería tipo Kafka, Amazon SQS o RabbitMQ—. Su trabajo es dueño de la secuencia, manejar los reintentos y loguear cada evento mientras pasa, para que el flujo completo pueda inspeccionarse solo.

Cuando algo se rompe, no deberías necesitar acceso de escritura al ERP y una consola de base de datos abierta en el storefront para reconstruir la historia. Deberías tener un solo lugar central que ya guarde los recibos. Esa es la arquitectura que ahora es el default en equipos serios de eCommerce. La herramienta es solo la ejecución; el principio es el punto real: las costuras entre sistemas merecen su propia memoria, porque nadie más está tomando notas.

El contexto importa: n8n dejó de ser un side project

Vale la pena dimensionar este cambio. n8n, mencionado en el artículo como herramienta de orquestación, dejó de ser un proyecto lateral en Berlín. Según reportó The Next Web, SAP la embebió dentro de Joule Studio como la capa de orquestación de su plataforma Autonomous Enterprise, llevando a n8n a una valoración de US$5.200M y convirtiéndola en la empresa de IA más valiosa de Alemania. La plataforma cuenta con más de 1.000 integraciones, 1,7 millones de developers activos al mes y más de 3.000 clientes enterprise incluyendo Microsoft, KPMG, Vodafone y Volkswagen.

La lectura para un founder es clara: la capa de orquestación dejó de ser un detalle técnico para convertirse en infraestructura crítica del stack enterprise. Si SAP la está poniendo en el centro de su estrategia de AI agents, es porque sin esa capa los agentes de IA no pueden ejecutar acciones en sistemas externos.

Qué significa esto para tu startup

Si tu equipo técnico va a conectar un eCommerce nuevo a un ERP que ya está corriendo, tratá la integración como un proyecto separado, no como una línea más del sprint final. Secuenciá los trabajos: primero construí y estabilizá la plataforma nueva, después auditá el ERP viejo con un analista dedicado, y recién al final scopeá la integración con los dos extremos ya conocidos.

Acciones concretas que podés tomar esta semana:

Pedí una auditoría del ERP viejo antes de cotizar la integración. Mapeá qué campos se truncan, qué cron jobs dependen de intervención manual y qué columnas de estado tienen significados ambiguos. Esa auditoría vale más que cualquier POC de la nueva plataforma.
Diseñá una capa de orquestación con memoria desde el día uno, aunque arranque con algo tan simple como n8n o un servicio propio con logging estructurado. Cada evento entre sistemas debe quedar registrado en un solo lugar consultable, no disperso en logs de cada sistema.
Cuestioná cada workflow legacy antes de automatizarlo. Preguntá si el proceso existe por una limitación del sistema viejo que ya no aplica. Muchas veces la respuesta ahorra meses de integración y mejora la operación.