La respuesta corta
Para integrar sistemas, use la API del ERP y de los otros sistemas siempre que exista, con webhook cuando una parte necesita saber en el momento que algo cambió. El archivo y la base intermedia sirven cuando no hay API, y el robot que imita clics es el último recurso. Antes de elegir, defina qué sistema es la fuente de la verdad de cada dato.
La forma de integrar es solo la mitad del trabajo. La otra mitad es lo que pasa cuando algo sale mal: el sistema de destino fuera de servicio, un registro rechazado, la misma venta enviada dos veces. Una integración bien hecha trata las fallas, reprocesa sin duplicar, protege las credenciales y avisa a alguien cuando se detiene.
Cuáles son las formas de integrar sistemas
Hay cinco formas principales de hacer que dos sistemas intercambien datos. La elección depende de lo que ofrece cada sistema, del volumen de registros y de cuánto retraso tolera la operación.
| Forma | Cómo funciona | Ventajas | Cuidados |
|---|---|---|---|
| API | Un sistema llama al otro por una interfaz documentada para consultar o grabar datos | Es el camino estándar, seguro cuando está bien configurado, y permite validar cada registro en el momento | Depende de que el proveedor ofrezca la API, de los límites de llamadas y de los cambios de versión |
| Webhook | El sistema de origen avisa al destino automáticamente cuando algo sucede | Datos casi en tiempo real, sin preguntar todo el tiempo si algo cambió | El aviso se pierde si el destino está fuera de servicio, por eso exige conciliación y reenvío |
| Archivo | Exportación periódica en CSV, XML o un formato similar, leída por el otro sistema | Simple, funciona con sistemas antiguos y es fácil de auditar | Retraso entre exportaciones, formatos que cambian sin aviso y riesgo de leer el mismo archivo dos veces |
| Base intermedia | Los sistemas graban y leen en una base o tabla acordada entre ellos | Útil cuando no hay API y el volumen es alto | Ata los sistemas a la estructura de la base, y tocar directamente la base de un sistema comercial puede comprometer el soporte del proveedor |
| RPA (robot de pantalla) | Un robot imita a una persona que hace clic y escribe en la interfaz | Resuelve cuando no existe ningún otro medio | Se rompe con cada cambio de pantalla, es lento y difícil de monitorear |
En la práctica, una integración madura combina formas: API para grabar, webhook para avisar y una conciliación periódica para atrapar lo que se escapó. Cuando el sistema actual no ofrece ningún medio razonable, la pregunta pasa a ser si vale la pena mantenerlo, tema de la guía sobre cómo modernizar un sistema legado.
Qué relevar antes de integrar el ERP con otros sistemas
Buena parte de los problemas de integración nace antes de la primera línea de código, de una pregunta que nadie hizo. Este es el relevamiento que vale la pena hacer antes de elegir la forma de integrar:
- Documentación. ¿El sistema tiene una API documentada? ¿Un ambiente de pruebas? ¿Quién da el acceso y cuánto tarda? Una integración sin ambiente de pruebas termina en pruebas en producción.
- Volumen. Cuántos registros por día y con qué picos. Diez pedidos por día y diez mil requieren diseños distintos.
- Frecuencia. ¿El dato tiene que llegar al instante, cada hora o una vez por día? El tiempo real tiene un costo y solo vale donde la operación lo necesita.
- Fuente de la verdad. Para cada dato, qué sistema manda. Lo tratamos en la próxima sección.
- Identificadores. Cómo saber que el cliente 123 en el ERP es el mismo cliente en el CRM. Sin una clave común, la integración duplica registros.
- Límites y contratos. Límite de llamadas, cobro del acceso a la API por parte del proveedor y lo que el contrato permite hacer con los datos.
- Responsables. Quién en la empresa responde por cada sistema y a quién se avisará cuando algo falle.
En el estudio inicial de nuestros proyectos, mapeamos lo que permite cada sistema y, cuando hay limitaciones, explicamos las alternativas y el impacto de cada una antes de empezar.
Quién es la fuente de la verdad de cada dato
Cuando dos sistemas guardan el mismo dato, hay que decidir cuál de ellos manda. El precio del producto viene del ERP, el contacto del cliente puede venir del CRM, el estado de la entrega viene del sistema de la transportadora. Sin esa definición, cada sistema corrige al otro, y el equipo termina verificando qué versión es la correcta.
La regla práctica es que cada dato tenga un único lugar donde se crea y se modifica. Los otros sistemas reciben copias y no las editan, o, si las editan, devuelven el cambio al origen por un camino acordado. Eso es lo que permite cargar el dato una vez y hacerlo llegar a los otros sistemas sin volver a escribirlo y sin dos versiones de la misma información.
Esa decisión a veces revela que el problema no es integrar, sino que un sistema ya no encaja en el proceso. La guía sobre software listo o a medida ayuda en esa evaluación.
Cómo tratar fallas y reprocesar sin duplicar
Toda integración va a fallar en algún momento: el otro sistema se cae, la red oscila, un registro llega con un campo inválido. Lo que separa una integración confiable de una frágil es lo que sucede en ese momento.
- Cola en lugar de llamada directa. El registro entra en una cola y se envía desde allí. Si el destino está fuera de servicio, espera en lugar de perderse.
- Nuevos intentos con intervalo creciente. Intentar de nuevo enseguida y después con una espera mayor, sin sobrecargar al otro sistema con repeticiones.
- Envío idempotente. Cada registro lleva un identificador único, y el destino reconoce cuando recibe el mismo envío dos veces. Así el reprocesamiento no crea un pedido duplicado.
- Error de dato separado de error técnico. Un sistema caído se resuelve con un nuevo intento; un número de identificación fiscal inválido, no. Los registros rechazados van a una lista de pendientes con el motivo, para que alguien los corrija.
- Conciliación periódica. Una verificación que compara origen y destino y señala lo que quedó atrás, porque ningún mecanismo atrapa todo.
Seguridad en la integración de sistemas
Una integración es una puerta entre dos sistemas y debe tratarse como tal. Los cuidados básicos:
- Credenciales fuera del código. Las claves y contraseñas de API se guardan en un almacén seguro o en variables protegidas, con cambio periódico.
- Permiso mínimo. El usuario de la integración accede solo a lo que usa. Si solo lee pedidos, no puede borrar clientes.
- Canal protegido y llamadas firmadas. Tráfico cifrado y, en los webhooks, verificación de que el aviso realmente vino del sistema de origen.
- Datos personales con finalidad. Solo se transmite lo que el destino necesita, conforme a la ley brasileña de protección de datos (LGPD), y cada movimiento queda registrado.
En el proyecto de monitoreo con beacons, las cifras de presencia salen por una API firmada y las consumen los paneles que la unidad de salud ya usaba, en lugar de obligar al equipo a abrir un sistema más.
Monitoreo: cómo saber que la integración se detuvo
La peor falla de integración es la silenciosa: se detiene un viernes y alguien lo nota el lunes, cuando el inventario no cuadra. Monitorear es saberlo antes que el cliente.
- Alerta de ausencia. Si ningún registro pasó en un período en el que siempre pasan, se avisa a alguien.
- Panel de pendientes. Una cola de errores visible, con el motivo y la antigüedad de cada registro detenido.
- Registro de cada envío. Qué salió, cuándo y con qué respuesta. Es lo que permite investigar una diferencia sin adivinar.
- Dueño de la alerta. Una alerta que llega a todos no llega a nadie. Cada tipo de falla tiene un responsable.
Integrar sistemas es uno de los frentes de nuestro trabajo en automatización e inteligencia artificial y en software a medida. Desde nuestros primeros proyectos de comercio minorista, integrados a ERP y marketplaces, hasta la recepción del sistema de gestión de pacientes, integrada al CAD-SUS y al CNS (la tarjeta nacional de salud de Brasil), la lección se repite: la integración solo está lista cuando alguien sabe, sin tener que preguntar, que está funcionando.