Integrar IA con un ERP antiguo sin cambiar de sistema

La frase aparece siempre en el mismo punto de la conversación, y casi siempre con el mismo tono de resignación:

“El ERP corre en un servidor privado que no tiene acceso a internet. La IA ahí no se va a poder meter.”

Es la objeción número uno en cualquier empresa con veinte o treinta años de historia. Y es razonable: casi todas las que visitamos tienen un sistema así. El programa que encargaron en 2005 y sigue funcionando. El ERP a medida en un lenguaje que ya nadie aprende. El Excel maestro que solo entiende una persona.

Nadie lo toca, y con motivo: el día que se toca, se para la empresa.

De ahí sale la conclusión que lo bloquea todo: “para meter IA primero habría que cambiar esto, así que todavía no”. Migración cara, larga y arriesgada. Proyecto aplazado. Otro año igual.

Por qué ese miedo tiene sentido y aun así la conclusión es equivocada

El error está en la premisa. Se asume que la IA tiene que vivir dentro del sistema, y por eso parece que hay que cambiarlo primero.

Pero el trabajo manual que duele no ocurre dentro del ERP. Ocurre alrededor: la factura que llega al correo y alguien pica a mano, el informe del lunes que se monta copiando de tres sitios, la conciliación de cada viernes, el pedido que se confirma por email y luego se teclea. El ERP guarda el dato; la persona hace de puente entre sistemas.

Ese puente es lo que se automatiza primero, y no exige tocar una línea del programa.

Las tres vías que sí funcionan

1. La API del ERP, cuando existe

Si el sistema es moderno o está en migración, lo normal es que exponga una API. Es la vía limpia: la información entra y sale sin exports manuales, y la automatización puede leer y escribir.

Aplica a la mayoría del mid-market actual: SAP Business One, Microsoft Dynamics 365 Business Central, Sage 200, Odoo, A3 en sus versiones recientes. Antes de prometer nada hay que verificar tres cosas con el proveedor: que la API esté activa y documentada, qué operaciones permiten escribir además de leer, y si el servidor tendrá salida a internet.

Conviene comprobarlo, no darlo por hecho: el propio Microsoft documenta que la API de Business Central expone solo un subconjunto de entidades de forma estándar, y ampliarlo exige desarrollo por parte del partner.

Esa última pregunta es la que más veces se responde tarde.

2. Modelos locales, cuando el dato no puede salir

Cuando la política interna, el sector o simplemente una decisión de hace años impiden que la información salga de la empresa, el modelo se instala dentro de su infraestructura. No hay llamada a la nube: el dato no sale de casa.

Nos hemos encontrado organizaciones donde tres o cuatro ordenadores de sesenta tienen conexión a internet, y el resto trabaja en una red cerrada con correo interno. En esos casos la vía local es la única que respeta cómo está montado todo, y funciona. Exige revisar la capacidad del servidor, porque no todo modelo cabe en cualquier máquina.

3. El export periódico, que probablemente ya estáis haciendo

Es la vía menos elegante y la más subestimada. Si el ERP ya deja un volcado en una carpeta (cuatro Excel cada mañana, un CSV cada noche) eso ya es una integración. Solo falta que lo recoja un sistema en lugar de una persona.

Hemos visto a gestores montarse su propia herramienta sobre esos exports y usarla a diario durante meses. Funciona. El problema no es que no sirva: es que la mantiene alguien cuyo trabajo es otro, y que dedicarle tres horas al día no es sostenible.

La vía que conviene descartar

Migrar el ERP antes de automatizar. Es la opción que más veces se propone y la que peor sale.

Tres motivos. Primero, el orden es al revés: una migración se diseña mejor cuando ya sabes qué procesos importan de verdad, y eso lo descubres automatizándolos. Segundo, mientras dura la migración (meses, en el mejor caso) el trabajo manual sigue costando exactamente lo mismo cada día. Y tercero, el riesgo se concentra: cambias el sistema que sostiene la operación y encima estrenas automatizaciones sobre algo que nadie conoce todavía.

Hay un caso donde sí tiene sentido, y es cuando la migración ya está decidida y en marcha por motivos ajenos. Entonces conviene esperar a que el sistema nuevo esté estable y aprovechar sus APIs desde el principio. Fuera de ese supuesto, primero se automatiza alrededor.

Comparativa

Vía	Necesita internet	Escribe en el ERP	Esfuerzo	Cuándo tiene sentido
API nativa	Sí	Sí	Medio	El ERP la expone y el proveedor colabora
Modelo local	No	Depende	Alto	El dato no puede salir de la empresa
Export periódico	No	No	Bajo	El ERP está cerrado o el proveedor no colabora
Migrar primero	—	—	Muy alto	Solo si ya estaba decidida por otros motivos

Cómo saber cuál te toca

Tres preguntas, y con las respuestas ya sabes por dónde empezar:

1. ¿Tu ERP tiene API documentada? Lo sabe el proveedor. Si la respuesta tarda más de una semana en llegar, esa demora ya es información sobre cómo será el proyecto.
2. ¿Puede salir el dato de la empresa? Si hay dudas, la respuesta operativa es que no, y se diseña con modelos locales desde el principio.
3. ¿Qué volcado produce ya el sistema? Cualquier informe que alguien exporta cada mañana es un punto de integración que existe hoy y no hay que construir.

Casi siempre hay una vía. Y cuando no la hay, lo honesto es decirlo: si el servidor está aislado, el proveedor no abre la API y el sistema no genera ningún export, no hay por dónde entrar sin tocar el ERP. Es poco frecuente, pero pasa.

---

Si quieres saber cuál de las tres encaja en tu caso, eso es exactamente lo que sale de un diagnóstico de procesos en tres semanas: qué se puede automatizar, en qué orden y con qué retorno. Lo firma quien después lo construye.

Y si lo que te preocupa no es el ERP sino qué pasa con vuestros datos cuando entra la IA, eso lo tratamos aparte en el blog.

Escrito por Daniel Magarzo, CTO de Made to Scale, que se dedica a integrar estos sistemas.