La integración entre sistemas de terceros es el gran desafío del desarrollo actual

La parte más difícil de un proyecto de software rara vez es escribir la lógica nueva. Es hacer que hable con lo que ya existe.

ERP, planilla de gestión, sistema de facturación, plataforma de logística, base de datos legada que ya nadie sabe explicar bien — toda empresa que ya opera hace algunos años tiene un ecosistema de sistemas que no fueron diseñados para hablar entre sí. Y es exactamente ahí donde la mayoría de los proyectos de tecnología pierde tiempo, presupuesto y paciencia.

Por qué la integración es más difícil que construir desde cero

Construir una funcionalidad nueva y aislada es un problema bien definido: sabes la entrada, sabes la salida, controlas los dos extremos. La integración es lo opuesto. No controlas el sistema del otro lado — la documentación de la API puede estar desactualizada, el campo que debería ser obligatorio a veces llega vacío, la versión del sistema cambia sin aviso.

Esto es aún más cierto en ERPs como Protheus, SAP o Senior: son sistemas robustos, diseñados para la operación interna, no necesariamente para exponer datos de forma simple a quien está afuera. Integrarse con ellos no es "conectar una API" — es entender la lógica de negocio que el sistema lleva por dentro antes de intentar extraer datos de él.

El error más común: tratar la integración como un detalle técnico

Los equipos de desarrollo suelen dejar la integración para el final del proyecto, como si fuera solo un conector más. En la práctica, es al revés: la integración debería ser una de las primeras preguntas, porque define qué es realmente posible construir encima.

Cuando hacemos Consultoría Agro, la integración con el ERP no es una etapa del proyecto — es el punto de partida. Antes de diseñar cualquier solución ágil por encima, ya sabemos qué se puede extraer de Protheus, de SAP o de Senior, y qué necesita otro camino.

Integrar sin duplicar, sin migrar, sin romper lo que ya funciona

La tentación más cara en proyectos de integración es "cambiemos de sistema". Cambiar un ERP entero para resolver un problema de visibilidad de datos es usar un mazo para clavar un clavo. La alternativa que realmente funciona es construir la capa ágil sobre lo que ya existe — sin duplicar sistemas, sin migraciones riesgosas, sin detener la operación para "modernizar".

Es un trabajo menos vistoso que "construir desde cero". Pero es lo que separa un proyecto que sale del papel de uno que queda atrapado en reuniones de levantamiento de requisitos para siempre.