Cómo integrar tu ERP con tus demás sistemas

La conversación empieza casi siempre igual: "nuestro ERP ya no nos da, estamos evaluando cambiarlo". Y casi siempre, cuando uno pregunta qué es lo que no da, la respuesta no tiene que ver con el ERP. Tiene que ver con que el ERP no habla con nada más: el e-commerce no baja pedidos, el almacén lleva su propio Excel, el CRM vive aparte y alguien captura todo dos veces.

Cambiar de ERP por ese motivo es de las decisiones más caras que puede tomar una empresa mediana. Casi siempre hay un camino más corto: integrarlo.

Primero, distinguir el problema real

Antes de decidir, vale la pena separar tres cosas que se confunden:

Síntoma	Problema real	Solución
"Capturamos lo mismo en dos sistemas"	Falta integración	Integrar
"El ERP no tiene el módulo que necesito"	Falta funcionalidad periférica	Construir alrededor
"El ERP no soporta nuestro volumen ni nuestro modelo de negocio"	El ERP sí quedó chico	Migrar

Solo el tercer caso justifica una migración. Los dos primeros — que son la mayoría — se resuelven sin tocar el core contable, en una fracción del tiempo y del costo.

Esto importa especialmente en México, donde muchas empresas medianas operan sobre Contpaq i, Aspel, SAP Business One u Odoo. Son sistemas sólidos para lo que hacen: contabilidad, facturación, CFDI. El error es pedirles que además sean el sistema de operación.

Los cuatro métodos de integración, y cuándo usar cada uno

1. API REST — cuando el ERP la ofrece

Es el mejor escenario. SAP Business One tiene Service Layer, Odoo expone XML-RPC y REST, y varios ERP en la nube traen API documentada. La integración es en tiempo real, se puede versionar y los errores son visibles.

Cuándo: siempre que exista. Cuidado con: los límites de peticiones. Casi todas las APIs de ERP tienen tope, y un catálogo de 40 000 SKUs sincronizado ingenuamente lo revienta el primer día.

2. Base de datos intermedia — cuando la API no alcanza

Muchos ERP instalados en sitio no tienen API útil, pero sí una base de datos accesible. El patrón sano no es escribir directo en sus tablas: es una capa intermedia que lee, transforma y escribe únicamente por los procedimientos que el proveedor del ERP soporta.

Cuándo: ERP local sin API. Cuidado con: escribir directo en tablas del ERP. Funciona hasta la siguiente actualización, y entonces rompe la contabilidad. Ese es el peor lugar donde te puede romper algo.

3. Archivos e importadores — cuando el ERP está cerrado

Poco elegante y sigue siendo la respuesta correcta a veces. Casi todo ERP importa y exporta CSV o XML. Un proceso programado que deja archivos en una ruta acordada resuelve muchos casos.

Cuándo: ERP cerrado o proveedor que no autoriza otro acceso. Cuidado con: la latencia. Esto no es tiempo real. Si el negocio necesita inventario al minuto, no sirve.

4. Middleware o capa de integración — cuando son más de dos sistemas

Cuando ya hay ERP, e-commerce, almacén, CRM y facturación, conectar todo contra todo genera un nudo: seis sistemas conectados en pares son quince integraciones que mantener.

El patrón correcto es un hub: cada sistema se conecta una vez a una capa intermedia que traduce y enruta. Seis integraciones en lugar de quince, y agregar el séptimo sistema cuesta una, no seis.

Cuándo: de tres sistemas en adelante, o cuando anticipas crecer. Cuidado con: sobre-arquitecturar. Si solo son dos sistemas y no van a ser más, un hub es gasto innecesario.

Las decisiones que hay que tomar antes de escribir código

Tres preguntas definen casi todo el diseño:

¿Quién manda sobre cada dato? Cada campo necesita una sola fuente de verdad. El precio, ¿lo manda el ERP o el e-commerce? El inventario, ¿el almacén o el ERP? Si no se define, tarde o temprano dos sistemas escriben el mismo campo y gana el último — que no siempre es el correcto.

¿Cada cuándo? Tiempo real cuesta más y falla distinto que cada quince minutos. El inventario de un e-commerce con alta rotación necesita segundos. El catálogo de proveedores aguanta una sincronización nocturna. No todo merece tiempo real.

¿Qué pasa cuando falla? No es si falla: es cuándo. El ERP se cae, la API cambia, llega un dato con formato inesperado. Toda integración necesita reintentos, una bitácora de lo que no pasó y alguien a quien avisarle. Una integración sin manejo de errores no es una integración, es una bomba de tiempo silenciosa.

Los errores que más caro salen

• Sincronizar todo "por si acaso". Cada campo sincronizado es mantenimiento de por vida. Sincroniza lo que el negocio usa.
• Escribir directo en las tablas del ERP. Ya lo mencioné y lo repito porque es el más común y el más caro.
• No registrar la trazabilidad. Cuando un pedido no llegó, necesitas poder responder dónde se quedó. Sin bitácora, la respuesta es abrir la base de datos a mano.
• Integrar procesos rotos. Si el proceso manual está mal, automatizarlo solo hace que se equivoque más rápido. Arregla el proceso primero.
• Depender de una sola persona. La integración que solo entiende un consultor externo es un riesgo operativo, no un activo.

¿Cuánto cuesta y cuánto tarda?

Depende sobre todo de si el ERP tiene API y de cuántos objetos se sincronizan. Como referencia de órdenes de magnitud:

• Una integración simple (ERP ↔ e-commerce, catálogo e inventario, API disponible): semanas, no meses.
• Integración con transformación de datos (unidades, monedas, catálogos que no empatan): sumar el tiempo de mapear los catálogos, que casi siempre es más de lo que se estima.
• Hub multisistema: ya es un proyecto de plataforma, con su discovery y sus fases.

Frente a una migración completa de ERP —que implica volver a capturar catálogos, reentrenar a todo el personal y arriesgar el cierre contable— la diferencia suele ser de un orden de magnitud. Vale la pena agotar la opción de integrar antes de decidir migrar. Si quieres los rangos de inversión, los desglosamos en cuánto cuesta desarrollar software en México.

Cómo lo hacemos en Newsoft

Trabajamos casi siempre alrededor del ERP, no encima de él. El contable se queda haciendo lo que hace bien —contabilidad, CFDI, facturación— y construimos la capa de operación que le falta: portal de pedidos, control de almacén, seguimiento en campo, tablero de dirección, todo alimentado del ERP y devolviéndole lo que necesita.

Es el mismo enfoque de nuestras plataformas administradas: la plataforma opera el negocio y el ERP mantiene la verdad contable. Cuando además hay que interpretar datos que no vienen estructurados —facturas de proveedor, correos de pedidos— entran los agentes de IA en la capa de integración.

Si tu ERP no habla con el resto de tus sistemas y estás evaluando cambiarlo, platícanos tu caso antes de decidir. El discovery es gratuito y en muchos casos la conclusión es que no hace falta migrar.

Conclusión

La mayoría de las empresas que quieren cambiar de ERP en realidad quieren que su ERP hable con lo demás. Son problemas distintos con costos muy distintos.

Antes de arrancar una migración, revisa qué API expone tu ERP, define quién manda sobre cada dato y qué frecuencia necesita cada proceso. Si la respuesta es que se puede integrar, integrar casi siempre sale mejor: menos riesgo, menos tiempo y sin volver a capturar diez años de catálogos.