Integración de ERP: cómo conectarlo con el resto de sistemas

Una empresa compra un ERP para tener un sitio donde esté todo. A los pocos años, la realidad es otra: el ERP tiene lo contable, el almacén trabaja con otro programa, comercial vive en el CRM, los pedidos entran por correo y hay media docena de hojas de cálculo que nadie se atreve a tocar. Entre esos sistemas hay personas copiando datos.

«Integrar el ERP» nombra al menos tres problemas distintos, y confundirlos es la razón más habitual de que un proyecto de integración cueste el doble de lo previsto o se quede a medias.

Este artículo compara las vías reales de conectar un ERP con el resto de sistemas, con lo que resuelve cada una y cuándo no conviene. Incluida la nuestra.

La pregunta que decide el proyecto y casi nadie hace primero

Antes de comparar presupuestos conviene averiguar tres cosas, por este orden:

1. ¿Qué vías de entrada y salida admite vuestro ERP? API, ficheros, acceso a base de datos, un módulo de integración. La respuesta está en su documentación, no en la propuesta de nadie.
2. ¿Qué permite vuestro contrato de soporte? Hay fabricantes que invalidan el soporte si alguien escribe directamente en la base de datos, y distribuidores que cobran por habilitar la API. Esto decide más proyectos que la tecnología.
3. ¿Quién tiene las credenciales y cuánto tarda en darlas? Si el acceso depende de un tercero, ese plazo es el plazo del proyecto.

Un proveedor que presupuesta sin haber preguntado esto está presupuestando una suposición.

Y después, cuál de los tres problemas tenéis

1. «Tecleamos lo mismo en dos sitios.» El dato existe en un sistema y alguien lo reescribe en otro. Es un problema de transporte.
2. «No sabemos en qué estado está algo.» El dato está repartido y responder a una pregunta sencilla exige mirar en tres sitios o preguntar a dos personas. Es un problema de visibilidad.
3. «El dato entra, pero hay que comprobarlo.» Llega una factura, un pedido o un parte, y el trabajo no es escribirlo sino verificar que cuadra con lo que el ERP ya sabe. Es un problema de reglas.

El primero se resuelve con una integración y suele ser el más barato. El segundo se resuelve con una consulta que reúna las fuentes, y no siempre hace falta mover ningún dato. El tercero es el que ninguna herramienta de catálogo cierra entera, porque las reglas son vuestras.

Casi todas las empresas tienen los tres. Casi siempre duele uno más.

Las cinco vías de integración

1. El conector o el módulo que ya trae el ERP

Muchos ERPs incluyen conectores para las integraciones más frecuentes: una pasarela bancaria, un canal de venta, un programa de almacén conocido. A veces está contratado y desactivado.

Resuelve el transporte en los casos previstos por el fabricante, y lo hace dentro del soporte del producto.

No resuelve nada que el fabricante no haya previsto, y rara vez permite tocar las reglas.

Cuándo conviene. Siempre hay que mirarlo primero. Es la opción más barata que existe, porque ya está pagada, y es la única donde un fallo lo arregla otro.

Cuándo no. Cuando obliga a adaptar vuestro proceso al del conector. Si para usarlo hay que cambiar cómo trabaja el almacén, el ahorro de la licencia se va en formación y errores.

2. La API del ERP

La vía limpia: el ERP expone operaciones y otro sistema las invoca. Es lo que usan los ERPs modernos y lo que los veteranos han ido añadiendo con mejor o peor fortuna.

Resuelve el transporte y buena parte de las reglas, porque permite leer antes de escribir y comprobar el resultado.

No resuelve lo que la API no expone, que suele ser más de lo esperado. Y no todas las APIs son iguales: algunas no permiten consultar lo que acaban de escribir, que es justo lo que hace falta para confirmar.

Cuándo conviene. Siempre que exista y vuestro contrato la permita. Es la base sobre la que se construye cualquier cosa seria.

Cuándo no. Cuando el proveedor cobra por llamada o por usuario de integración de una forma que convierte un flujo de alto volumen en un coste recurrente mayor que el ahorro.

3. Intercambio de ficheros

El ERP lee de una carpeta y escribe en otra, con ficheros en un formato acordado. Suena antiguo y sigue siendo la vía más usada en el mundo real.

Resuelve el transporte con volúmenes altos y procesos por lotes, sin depender de que dos sistemas estén disponibles a la vez.

No resuelve nada en tiempo real, y deja fuera la confirmación: dejar un fichero no es saber que se ha procesado.

Cuándo conviene. Cargas nocturnas, maestros, contabilidad, cualquier cosa que no necesite respuesta inmediata. Y cuando la API no existe o no se puede pagar.

Cuándo no. Cuando alguien necesita el dato en minutos, o cuando el proceso no tolera que un fichero se procese dos veces. Lo segundo pasa más de lo que parece.

4. Plataforma de automatización o iPaaS

Herramientas que conectan aplicaciones mediante flujos configurados, con o sin robots que imitan a una persona pulsando en una pantalla.

Resuelve el pegamento entre piezas que ya funcionan, y permite probar un flujo en días en lugar de en meses.

No resuelve las reglas de negocio complejas, y cuando imita clics es frágil: una actualización del ERP que mueva un botón lo rompe en silencio.

Cuándo conviene. Como conector entre sistemas que ya tienen interfaz, y como forma barata de validar que un flujo merece construirse bien.

Cuándo no. Como arquitectura permanente de un proceso crítico. Lo que se sostiene con robots que pulsan botones se cae el día de una actualización, y normalmente se cae sin avisar.

5. Una pieza propia entre medias

Construir el trozo que falta: el que lee de un lado, aplica vuestras reglas, escribe en el ERP por la vía que este admita y deja las excepciones preparadas para que alguien decida.

Resuelve el tercer problema, el de las reglas, que es el que ninguna de las anteriores cierra. Y resuelve el segundo, porque esa pieza es el sitio natural donde montar la consulta compartida.

No resuelve nada por sí sola si se plantea como sustituta de las otras vías. Reescribir un conector que ya existe es tirar dinero.

Cuándo conviene. Cuando las reglas son vuestras y de nadie más: tolerancias, equivalencias entre referencias de proveedor e internas, criterios de aprobación por importe o por familia.

Cuándo no. Cuando el proceso es estándar y el volumen bajo. Si el conector del fabricante lo cubre, pagar un desarrollo es difícil de justificar.

La comparación en una tabla

	Transportar	Dar visibilidad	Aplicar reglas	Coste inicial	Fragilidad
Conector del ERP	Alta	Baja	Baja	Muy bajo	Baja
API	Alta	Media	Alta	Medio	Baja
Ficheros	Alta	Ninguna	Baja	Bajo	Media
iPaaS y robots	Media	Baja	Baja	Bajo	Alta
Pieza propia	Según diseño	Alta	Alta	Medio	Propia

La tabla compara vías, no productos. Lo normal no es elegir una: es usar la API para lo que admite, ficheros para los lotes, y una pieza propia pequeña que aplique las reglas de la casa.

Lo que rompe las integraciones

No es el código. Son cuatro cosas, siempre las mismas.

Los datos maestros. Si la misma referencia se llama de tres formas, ninguna integración lo arregla: lo hereda. Hace falta una tabla de equivalencias y alguien que la mantenga.

La escritura sin confirmación. Enviar una petición no es haber actualizado el ERP. Sin leer el identificador que devuelve, el equipo cree que el dato está y no está.

El mismo documento dos veces. Un reintento, un fichero que se vuelve a dejar, un correo reenviado. Si el flujo no sabe reconocer lo que ya procesó, duplica. En facturas eso se nota en el banco.

Las excepciones sin dueño. Toda integración deja casos que no encajan. Si nadie los trabaja a diario, la cola crece hasta que alguien vuelve a hacerlo todo a mano «mientras tanto», y ese «mientras tanto» dura años.

Las validaciones mínimas antes de escribir en el ERP son casi siempre estas:

• Que el origen, el centro y la referencia pertenecen al flujo autorizado.
• Que los campos obligatorios están y tienen formato válido.
• Que cantidades y unidades son convertibles al vocabulario interno.
• Que el documento no se ha procesado antes.
• Que lo que llega no contradice los datos maestros ni el pedido vigente.

Qué automatizar y qué dejar en revisión

No todas las decisiones merecen el mismo grado de autonomía.

Situación	Tratamiento recomendable
Campo exacto, formato válido y coincidencia única	Escritura automática
Diferencia menor prevista por una regla aprobada	Corrección automática y registro
Falta un campo obligatorio	Revisión humana
Dos registros podrían corresponder al documento	Mostrar candidatos y pedir confirmación
Cambio con impacto económico o de calidad	Aprobación del responsable
Origen ilegible o contradictorio	Bloquear la escritura y explicar el motivo

La revisión humana no debería consistir en repetir todo el trabajo. Una buena bandeja de excepciones muestra el valor propuesto, el fragmento original, la regla que ha fallado y las acciones disponibles.

Dónde entra la IA, y dónde no

La IA sirve para la parte que no tiene estructura: interpretar un correo escrito de cualquier manera, leer un PDF que cada proveedor monta a su gusto, proponer a qué pedido corresponde algo. Eso antes obligaba a programar un caso por formato, y era la razón por la que muchos flujos no se automatizaban.

Lo que no cambia es el resto. Las referencias, los permisos, los estados permitidos y la confirmación de la escritura siguen siendo reglas verificables, y deben seguir siéndolo. Un modelo que propone y unas reglas que validan es un buen reparto. Un modelo escribiendo directamente en el ERP no lo es.

Si los datos ya llegan estructurados, la IA no pinta nada en ese tramo y una integración convencional es más barata y más fiable.

El coste de la pieza propia ya no es el de hace tres años

La tabla dice «medio» donde hace tres años habría dicho «alto», y conviene explicar por qué, porque mueve el umbral a partir del cual construir sale a cuenta.

Lo que ha bajado de precio es escribir código: los conectores, las validaciones, las pruebas, la pantalla donde alguien revisa las excepciones. Un equipo que trabaja con generación asistida entrega esa parte en una fracción del tiempo que costaba, y esa parte era la mayoría de las horas de cualquier presupuesto.

Lo que no ha bajado es el resto. Entender vuestro proceso sigue costando reuniones. Los datos maestros siguen sin estar limpios. Los permisos del proveedor del ERP siguen tardando lo que tardan. Y alguien sigue teniendo que ser dueño de las reglas.

La consecuencia práctica es que la barrera de entrada se ha movido. Una integración que en 2022 no salía porque el presupuesto no daba puede salir hoy con el mismo volumen, y una empresa de treinta personas puede permitirse una pieza propia que antes solo tenía sentido a partir de varios cientos. Si descartasteis integrar el ERP hace unos años por precio, conviene rehacer esa cuenta.

Esto hace más importante, no menos, saber cuándo no conviene. Cuando construir es barato resulta fácil construir cosas que no deberían existir, y mantenerlas no se ha abaratado en la misma proporción.

Por dónde empezar, y qué mirar al cabo de un mes

Un tipo de documento, un equipo, una operación del ERP y unas reglas acordadas. Durante las primeras semanas, todas las escrituras con confirmación humana. Cuando los resultados sean estables, se automatizan solo los casos que cumplen condiciones conocidas.

El mejor primer candidato no es el que más irrita, sino el que cumple cinco condiciones: frecuencia suficiente, casos parecidos entre sí, resultado verificable, acceso estable a los sistemas y riesgo acotable. Para compararlo con otros candidatos sirve la matriz para elegir el primer proceso que automatizar.

El ahorro se mide sobre el proceso completo, no sobre el paso integrado: preparación, ejecución, revisión, corrección de errores y coste de la herramienta.

• Minutos de trabajo humano por operación.
• Tiempo hasta que el dato está disponible para el siguiente equipo.
• Porcentaje procesado sin intervención.
• Número y tipo de excepciones.
• Errores detectados antes y después de escribir en el ERP.

Un cálculo hipotético para dimensionar: 30 consultas semanales entre departamentos que cuestan cuatro minutos a fábrica, tres a administración y tres a compras suman cinco horas de intervención. Si una consulta compartida las reduce a 90 minutos, libera tres horas y media por semana antes de descontar mantenimiento. No es una cifra medida en un cliente: es la forma de contabilizar el esfuerzo de todos los equipos, que es lo que casi nunca se hace.

El porcentaje automático no debe convertirse en el único objetivo. Un flujo que resuelve el 70 % y presenta bien el 30 % restante suele aportar más que otro que fuerza el 95 % a costa de errores silenciosos.

Lo que haríamos nosotros, si nos lo preguntáis

Mirar el conector del fabricante, aunque dé pereza. Pedir la API y averiguar qué cuesta. Montar el primer flujo con ficheros si la API tarda, porque esperar tres meses a unas credenciales no es un plan. Y dejar la pieza propia para las reglas, que es donde de verdad no hay producto que valga.

Lo que no haríamos: sostener un proceso crítico con robots que pulsan botones, ni empezar por el cierre mensual porque es lo que más duele. Duele mucho y se ejecuta doce veces al año, así que se aprende despacio y se falla caro.

Si lo que entra son facturas, el detalle de ese flujo está en cómo automatizar facturas con IA. Si lo que entran son pedidos de cliente por correo, en pedidos de clientes del correo al ERP. Y si aún no sabéis dónde se concentra el re-tecleo, el diagnóstico de IA industrial ayuda a localizarlo en diez minutos.