Conectividad entre ERP y BMS sin romper lo que ya funciona

La resistencia a automatizar procesos suele venir de un miedo legítimo: romper un sistema que ya funciona. Ese miedo no es infundado. Un ERP mal migrado, un BMS reconfigurado sin plan de vuelta atrás o una hoja de cálculo que “ya no cuadra” pueden parar una operación entera durante días. La conclusión correcta no es evitar la automatización; es elegir el patrón de integración adecuado.

Por qué el “rip and replace” falla

Sustituir un sistema heredado por uno nuevo parece la solución más limpia sobre el papel: se elimina la deuda técnica de una vez. En la práctica, casi siempre falla por tres razones. Primero, el conocimiento operativo real vive en la cabeza de quien usa el sistema a diario, no en su documentación, y ese conocimiento no migra automáticamente a la herramienta nueva. Segundo, el coste y el tiempo de una migración completa casi siempre se subestiman, porque no se cuentan las integraciones de terceros que dependen del sistema antiguo. Tercero, y más importante: durante la transición, la empresa opera con dos sistemas a la vez, lo que multiplica la fricción en lugar de reducirla.

La alternativa es construir puentes lógicos entre sistemas (ERP, BMS, hojas de cálculo) que respeten el flujo de trabajo existente y solo eliminen la fricción manual entre ellos. Ningún sistema se sustituye. Se conecta.

El patrón de puente lógico

Un puente lógico no es una integración nativa entre dos productos (que rara vez existe entre sistemas heredados) ni una migración de datos. Es una capa intermedia, normalmente orquestada con n8n, que escucha eventos en un sistema, los transforma al formato que el otro sistema espera, y los entrega mediante su API o su mecanismo de importación estándar. Esa capa no almacena la verdad de negocio — la verdad sigue viviendo en el ERP o en el BMS —, solo transporta y traduce.

Esto tiene una consecuencia práctica importante: si el puente falla, se puede desconectar sin perder datos, porque ambos sistemas siguen siendo autosuficientes por separado. Es una propiedad que un “rip and replace” nunca ofrece durante la transición.

Ejemplo concreto: de factura de ERP a ticket de BMS

Un caso habitual: el ERP genera una factura de mantenimiento a un proveedor, y esa factura debería abrir automáticamente un ticket de seguimiento en el BMS para que el equipo de instalaciones confirme que el trabajo se ha realizado antes de aprobar el pago. Sin puente, esto se resuelve hoy con una persona que revisa el ERP, copia los datos relevantes y los introduce a mano en el BMS.

El puente lógico automatiza exactamente ese paso:

1. n8n escucha el evento “factura creada” en el ERP (vía webhook si el ERP lo soporta, o vía consulta periódica a su API si no).
2. Extrae los campos relevantes: proveedor, importe, referencia de contrato, fecha.
3. Transforma esos campos al esquema que el BMS necesita para crear un ticket (los nombres de campo casi nunca coinciden entre sistemas, y esa transformación es el verdadero trabajo de ingeniería).
4. Crea el ticket en el BMS vía su API, y guarda la referencia cruzada entre factura y ticket.
5. Cuando el ticket se marca como resuelto en el BMS, otro flujo notifica de vuelta al ERP (o a la persona responsable) que el pago puede aprobarse.

Nadie ha tenido que copiar un dato a mano, y ningún sistema ha cambiado su forma de funcionar internamente.

Idempotencia: el detalle que decide si el puente es fiable

Un puente lógico que no es idempotente es un riesgo, no una mejora. Si el webhook del ERP se reenvía dos veces por un fallo de red (algo habitual), y el flujo no lo controla, se crean dos tickets duplicados en el BMS por la misma factura. La solución es sencilla pero no opcional: cada evento debe llevar o generar un identificador único (por ejemplo, el ID de la factura), y antes de crear un ticket nuevo, el flujo comprueba si ya existe uno con esa referencia. Si existe, no hace nada. Este control de idempotencia es uno de los primeros puntos que se validan durante la fase de Build, antes de dar el flujo por terminado.

Control de acceso: menos permisos, no más

Conectar dos sistemas no debería significar dar acceso total a uno desde el otro. La credencial que usa el puente para hablar con el BMS solo necesita permiso para crear y consultar tickets de un tipo concreto, no permiso de administrador. Este principio de mínimo privilegio limita el daño potencial si esa credencial se ve comprometida, y es una práctica de seguridad estándar que a menudo se salta por prisa al montar la primera integración.

La idea central

Ningún sistema se sustituye. Se conecta. Un puente lógico bien diseñado, idempotente y con permisos acotados permite que dos sistemas heredados colaboren como si hubieran sido diseñados juntos, sin el riesgo ni el coste de una migración completa — y sin que nadie en el equipo tenga que aprender a usar una herramienta nueva.