Pedidos de ecommerce al ERP: 4 arquitecturas de integración

Una integración de ecommerce es una pieza de software pequeña con un radio de fallo desproporcionado. Cuando funciona, nadie piensa en ella. Cuando falla, un cliente ha pagado por algo que el almacén no sabe que existe, finanzas retiene ingresos que no puede reconocer, y la cifra de la tienda online y la del ERP no coinciden — lo que significa que, durante un tiempo, nadie en la empresa sabe qué se vendió realmente.

Existen esencialmente cuatro arquitecturas para llevar los pedidos de una tienda online a un ERP. Las cuatro están en producción en empresas mid-market reales ahora mismo. Las cuatro son la elección correcta en alguna circunstancia y desastrosa en otras, y el fallo casi nunca está en el código: está en el desajuste entre la arquitectura elegida y el volumen, el número de canales y la tolerancia al error del negocio que la utiliza.

Este artículo expone las cuatro, el punto en el que cada una se rompe y cómo saber cuál debería estar usando.

Por qué esto importa

Tres fuerzas han vuelto esta decisión más difícil para las empresas mid-market de lo que era hace cinco años.

El número de canales ha crecido más rápido que los presupuestos de integración. Una empresa que vendía a través de una tienda online vende ahora a través de una tienda online, dos o tres marketplaces, posiblemente un portal B2B y un canal social. Cada uno tiene su propio esquema de pedido, su propio modelo de liquidación y su propia idea de qué es un cliente. Una arquitectura que era suficiente para un canal suele ser silenciosamente insuficiente para cinco.

El volumen de pedidos es irregular, no lineal. El ecommerce mid-market es estacional, promocional y cada vez más impulsado por campañas. Una integración por lotes cómoda con 200 pedidos diarios estables puede no sobrevivir a 3.000 en una tarde — y el pico de ventas es precisamente cuando el fallo resulta más caro.

Las expectativas del cliente ya incluyen el back office. La disponibilidad de stock en tiempo real, las promesas de entrega precisas y la visibilidad inmediata del estado del pedido son todas funciones de la rapidez y la fiabilidad con que el ERP y la tienda online se ponen de acuerdo. La latencia de integración se ha convertido en un atributo que percibe el cliente.

De un vistazo: las cuatro arquitecturas

En términos generales: la opción 1 es donde la mayoría de las empresas mid-market deberían empezar, la opción 3 es donde acaban la mayoría, la opción 2 es donde la mayoría se quedan atrapadas, y la opción 4 es la correcta menos veces de lo que sugieren sus defensores.

Las cuatro en detalle

1. Conector nativo.
Una integración preconstruida, normalmente mantenida por el proveedor de la tienda online, el proveedor del ERP o un tercero. La más rápida de desplegar — semanas en lugar de meses — y la más barata con diferencia. La contrapartida es que hereda el modelo de otro sobre cómo debe fluir un pedido.

Falla de tres maneras. Su lógica de negocio excede lo que el conector expone: una regla de precios, un tratamiento fiscal, una división de preparación y envío para la que no fue diseñado. El número de canales crece y se encuentra operando tres conectores con tres comportamientos distintos de gestión de errores y ninguna visión consolidada. O la hoja de ruta del proveedor se separa de sus necesidades y queda esperando una funcionalidad que puede no llegar nunca.

2. Desarrollo a medida point-to-point.
Código específico directo entre dos sistemas. Control total, exactamente la lógica que especificó. Es la respuesta correcta cuando un único canal es estratégicamente crítico y su lógica es genuinamente inusual — y hay un ingeniero que lo mantiene.

El fallo es aritmético. Cada sistema nuevo multiplica las conexiones, y cada conexión lleva su propia lógica de reintento, su gestión de credenciales y su reporte de errores. Un cambio de tarifa afecta a todos los desarrollos. El conocimiento documentado vive con quien lo escribió, y las empresas mid-market rara vez retienen a esa persona durante toda la vida de la integración. Es la arquitectura en la que más a menudo encontramos empresas atrapadas, precisamente porque funcionó muy bien con el primer canal.

3. Plataforma de integración.
Una plataforma central intermedia todos los canales: transformación en un solo lugar, gestión de errores coherente, lógica de reintento, monitorización y una traza de auditoría. Añadir un cuarto canal pasa a ser configuración en lugar de un proyecto. Para una empresa mid-market con varios canales y requisitos cambiantes, esta es normalmente la arquitectura correcta, y es donde se concentra nuestro trabajo con clientes — típicamente sobre una plataforma de integración con la que Atypical Tech es partner, con agentes de IA encargados de clasificar y enrutar excepciones en lugar de volcar los fallos en una cola que nadie lee.

Su modo de fallo es organizativo. Como los flujos son fáciles de crear, proliferan. En dos años existe una capa de lógica de negocio no documentada que nadie entiende por completo, que es el mismo problema que la opción 2 pero mejor vestido. Las plataformas necesitan propiedad, convenciones de nomenclatura, documentación y revisión periódica: gobierno, no tecnología.

4. Middleware orientado a eventos.
Los sistemas publican eventos; los consumidores se suscriben de forma independiente. Es genuinamente la respuesta correcta con volumen alto, tráfico irregular y varios consumidores del mismo evento de pedido — un sistema de almacén, una verificación antifraude, un pipeline analítico y un servicio de notificación al cliente reaccionando todos a un mismo pedido.

Falla por madurez organizativa más que por tecnología. La arquitectura orientada a eventos exige personas cómodas con la consistencia eventual, la idempotencia y el replay, y los equipos mid-market a menudo no las tienen y no pueden contratarlas. También falla cuando el negocio no ha asimilado qué significa la consistencia eventual: «el pedido existe pero la cifra de stock aún no se ha actualizado» es un estado legítimo en esta arquitectura e inaceptable para un director financiero al que nadie se lo ha explicado.

Qué conviene reconocer con honestidad

La arquitectura rara vez es la restricción determinante. Fracasan más integraciones por calidad de datos y gestión de errores que por la elección arquitectónica. Si la tienda online puede crear una ficha de cliente que el ERP rechazará, ninguna arquitectura le salva.

Nadie quiere financiar la gestión de errores. El camino feliz es quizá el 60% del trabajo; el 40% restante es qué ocurre cuando el pago se completa y el pedido falla, cuando un producto no existe en el ERP, cuando un marketplace envía un reembolso parcial. Los proyectos que se saltan esto entregan a tiempo y consumen personal de operaciones indefinidamente después.

Migrar de arquitectura es caro y normalmente necesario. Pasar de point-to-point a una plataforma implica operar ambas en paralelo, conciliar y hacer el corte en un periodo sin pico de ventas. Es un proyecto de verdad. También es la decisión correcta más a menudo de lo que los clientes quieren oír.

El tiempo real no siempre es lo adecuado. La sincronización de pedidos en tiempo real suele ser correcta. La sincronización de inventario en tiempo real hacia todos los canales puede generar carga y condiciones de carrera desproporcionadas respecto a su valor; un búfer corto con lógica de reserva a menudo sirve mejor al cliente que el tiempo real estricto.

Los agentes ayudan con las excepciones, no con la arquitectura. Un agente de IA que clasifica los fallos, resuelve los mecánicos y enruta el resto con contexto adjunto reduce de forma material el coste operativo de cualquiera de estas cuatro opciones. No convierte en bueno un encaje arquitectónico malo.

Marco de decisión: cómo elegir su arquitectura

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Tiene uno o dos canales convencionales, lógica de pedido estándar y ningún plan inmediato de añadir más?
Use un conector nativo. No desarrolle. La ingeniería que gastaría se aprovecha mejor en otra parte, y puede migrar más adelante si aparece la restricción.

2. ¿Tiene un canal estratégicamente crítico con lógica genuinamente inusual y un ingeniero de mantenimiento en plantilla para el futuro previsible?
Un desarrollo point-to-point es defendible. Documente el mapeo fuera del código y fije un disparador de revisión: en el momento en que se planifique un segundo canal, vuelva a evaluarlo.

3. ¿Tiene tres o más canales, o requisitos que cambian más de una o dos veces al año?
Use una plataforma de integración y asigne un responsable con nombre antes de construir el primer flujo. La mayoría de las empresas mid-market que leen este artículo están en esta fila.

4. ¿Tiene volumen alto e irregular, varios consumidores independientes de los eventos de pedido e ingenieros que ya han operado sistemas orientados a eventos?
El middleware orientado a eventos es apropiado. Si cumple las dos primeras condiciones pero no la tercera, use una plataforma y vuelva a evaluarlo en un año — no aprenda esta arquitectura en plena campaña.

5. ¿Está actualmente en point-to-point con más de dos canales?
Su arquitectura es el problema, independientemente de todo lo anterior. Planifique una migración a una plataforma, secuenciada fuera del pico de ventas, operando en paralelo con conciliación hasta que tenga confianza.

6. ¿Todo lo anterior resuelto y los pedidos siguen fallando?
El problema es la calidad de los datos o la gestión de errores, no la arquitectura. Instrumente los fallos, clasifíquelos durante quince días y corrija las tres categorías principales — que normalmente serán desajustes de master data (datos maestros) y no fallos de integración.

Coste y esfuerzo indicativos

Se asume una única instancia de ERP y un perfil transaccional mid-market. Un tratamiento fiscal complejo, estructuras multientidad o la conciliación de liquidaciones de marketplace alargan estos plazos. Solicite un presupuesto para una estimación acotada.

Preguntas frecuentes

¿Podemos empezar con un conector nativo y migrar más adelante?
Sí, y para la mayoría de las empresas esa es la secuencia correcta. Reduzca ahora el coste de la migración documentando la lógica de su flujo de pedidos fuera de la configuración del conector, para que cuando migre no tenga que hacer ingeniería inversa de sus propias reglas de negocio.

¿Cómo gestionamos las liquidaciones de marketplace?
Por separado de la integración de pedidos, y de forma deliberada. Los pagos de marketplace llegan netos de comisiones, agrupados en muchos pedidos y según el calendario del marketplace — conciliarlos con pedidos individuales es un problema distinto que exige su propia lógica de emparejamiento. Tratarlo como parte de la integración de pedidos es un error común y caro.

¿La sincronización de inventario debe ser en tiempo real?
Normalmente no en tiempo real estricto. Una actualización casi en tiempo real con un búfer de reserva sirve mejor al cliente que el tiempo real puro, que es propenso a condiciones de carrera cuando dos canales venden la última unidad en el mismo segundo. Lo que importa es que se evite la sobreventa, y la lógica de reserva lo consigue con más fiabilidad que la velocidad de actualización.

¿Qué ocurre con los pedidos que fallan en la integración?
Esta es la pregunta que separa una integración que funciona de una frágil. Los pedidos fallidos deben aterrizar en algún sitio visible, con el motivo adjunto, un responsable y una vía de resolución definida — no en un fichero de log. Si su respuesta actual es «alguien se da cuenta», tiene una brecha de gestión de errores independientemente de la arquitectura.

¿Necesitamos también un data warehouse?
Para reporting, con el tiempo sí — pero no como parte de esto. La integración de pedidos es un flujo operativo; la analítica es una preocupación aparte. Combinarlas suele producir una integración optimizada para reporting y poco fiable en operación.

¿Con qué rapidez se puede implementar realmente una de estas arquitecturas?
Depende de cuál. Un puente provisional por CSV o manual son días; un conector nativo o una integración por middleware suele llevar entre 6 y 12 semanas. La arquitectura de sincronización en tiempo real suele ser la más rápida de levantar técnicamente — un partner certificado como Stacksync puede tener la sincronización bidireccional de pedidos funcionando en pocas semanas — pero antes hay que cerrar las decisiones de mapeo y gestión de excepciones de los apartados anteriores, o habrás automatizado rápido el flujo equivocado en lugar del correcto despacio.

Cierre — Próximos pasos

Las cuatro arquitecturas no son una escalera de madurez. Un negocio de un solo canal que opera bien un conector nativo está en mejor forma que un negocio de cinco canales con cuatro desarrollos a medida, independientemente de cuál parezca más sofisticado. La única pregunta que merece la pena hacerse es si su arquitectura encaja hoy con su número de canales, su perfil de volumen y su tolerancia al error, con una vía plausible hacia donde estará en dos años.

Un punto de partida práctico: cuente sus canales, cuente sus conexiones de integración y saque quince días de pedidos fallidos con sus motivos. Esas tres cifras le dirán en qué fila del marco está y si el problema real es la arquitectura o los datos.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que atiende a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricción, y en construir pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos de ventas y finanzas. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutado de excepciones, el procesamiento de documentos y la conciliación — convirtiendo flujos de pedidos fragmentados en sistemas fiables que se monitorizan a sí mismos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de publicación y deberían verificarse antes de la publicación.

• Oracle NetSuite, documentación de integración y SuiteTalk — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, investigación sobre plataformas de integración e iPaaS (en gran medida de acceso para clientes) — https://www.gartner.com
• Comisión Europea, VAT in the Digital Age (ViDA) — requisitos de reporte digital y facturación electrónica que afectan al ecommerce transfronterizo — https://taxation-customs.ec.europa.eu
• Agencia Tributaria (España), Suministro Inmediato de Información (SII) — https://sede.agenciatributaria.gob.es
• Experiencia de proyectos de Atypical Tech, integraciones de ecommerce y ERP en el mid-market de Iberia
• Stacksync, blog de la plataforma de integración y sincronización en tiempo real — https://www.stacksync.com/blog