Integrar dos sistemas: API, exportación o capa intermedia

Cuando una empresa decide conectar dos sistemas —el CRM con el ERP, la tienda online con el almacén, el programa de fichajes con la nómina— la conversación suele empezar por la herramienta. Y ahí ya se ha torcido. La integración correcta la deciden dos cosas: cada cuánto cambia el dato y quién es su dueño. La tecnología es la consecuencia, no el punto de partida. Un fichero exportado una vez al día puede ser una integración perfectamente sensata; una conexión por API en tiempo real puede ser una inversión cara que resuelve un problema que no tenías.

Este artículo es una guía de decisión. No compara productos: te da el criterio para elegir entre las tres formas reales de integrar dos sistemas, qué condiciones necesita cada una y cómo saber si has acertado.

Las tres formas de integrar dos sistemas

Por debajo del ruido de herramientas, sólo hay tres patrones. Cada uno tiene un coste, un riesgo y un tipo de problema que resuelve bien.

1. Exportación e importación de ficheros

Un sistema genera un fichero (CSV, Excel, XML) y el otro lo lee. Puede ser manual o programado. Es el patrón más antiguo y el más despreciado, y sigue siendo el correcto en muchos casos: cuando el dato se consolida por lotes, cuando el sistema de origen no ofrece otra vía, o cuando la frecuencia natural del proceso es diaria o semanal.

• A favor: coste de implantación bajo, fácil de auditar (el fichero es la prueba), no depende de que ambos sistemas estén disponibles a la vez.
• En contra: latencia alta, dependencia de que alguien ejecute el paso si es manual, y errores silenciosos si el formato cambia y nadie lo detecta.
• Condición mínima: el fichero se genera siempre con la misma estructura y hay un responsable de que el proceso se ejecute y de qué pasa si falla.

2. Conexión directa por API

Un sistema pregunta al otro o le envía datos mediante su interfaz de programación. Es el patrón adecuado cuando el dato cambia con frecuencia y la decisión de negocio depende de tenerlo actualizado: existencias, estado de un pedido, disponibilidad de agenda, saldo de crédito de un cliente.

• A favor: latencia baja, sin pasos manuales, el dato viaja con su estructura y sus validaciones.
• En contra: exige que ambos sistemas expongan lo que necesitas (no siempre ocurre), gestión de credenciales, control de errores y de reintentos, y mantenimiento cuando el proveedor cambia su versión.
• Condición mínima: existe un identificador común fiable entre los dos sistemas. Sin una clave para saber que el cliente A de aquí es el cliente A de allí, la conexión sólo acelera el desorden.

3. Capa intermedia (lo que suele llamarse middleware)

Un tercer componente se sitúa en medio: recoge de un lado, transforma, aplica reglas, registra lo que ha pasado y entrega al otro. Aquí entran desde plataformas de automatización hasta desarrollo propio. Es lo que necesitas cuando la integración no es un traspaso, sino una traducción: los sistemas no hablan el mismo idioma, hay reglas de negocio en medio, o son más de dos sistemas los implicados.

• A favor: un único lugar donde vive la lógica, trazabilidad de cada movimiento, y capacidad de crecer a un tercer o cuarto sistema sin rehacerlo todo.
• En contra: es una pieza más que mantener, con su coste recurrente y su propio riesgo de convertirse en la caja negra de la que nadie sabe nada.
• Condición mínima: las reglas de transformación están escritas y decididas antes de programarlas. Si no, la capa intermedia acaba siendo el sitio donde se esconden las excepciones que nadie quiso resolver.

El error de mercado: elegir por catálogo, no por dato

El patrón que más veces vemos es este: alguien detecta que se está duplicando trabajo entre dos programas, busca cómo conectarlos y termina eligiendo la opción que aparece antes en el catálogo del proveedor o la que suena más moderna. Nadie ha preguntado antes cada cuánto cambia ese dato ni quién decide su valor correcto.

El resultado tiene dos versiones, ambas caras. La primera es la sobreingeniería: montar una sincronización permanente para un dato que se consulta una vez al día y que a nadie le urge. Pagas complejidad, mantenimiento y riesgo de fallo a cambio de una inmediatez que el proceso no aprovecha. La segunda es la infraingeniería: resolver con una exportación manual un dato del que dependen decisiones cada hora. Ahí no ahorras: trasladas el coste a la persona que ejecuta el paso y a los errores que provoca no tenerlo al día.

Integrar sistemas no es lo mismo que mejorar un proceso. Si el flujo está mal diseñado, sincronizarlo sólo reparte el desorden más rápido.

Y hay un tercer error, el más caro: integrar dos sistemas que registran lo mismo sin decidir antes cuál manda. Eso no es una integración; es un conflicto permanente. Es el mismo problema que aparece cuando los informes no cuadran y cada área defiende su cifra.

Las dos preguntas que deciden

Frecuencia: cada cuánto cambia el dato y cada cuánto lo necesitas

Son dos preguntas distintas y conviene separarlas. Un dato puede cambiar continuamente y ser irrelevante hasta el cierre mensual. Otro cambia poco pero, cuando cambia, alguien tiene que enterarse en minutos.

La regla práctica: la frecuencia de la integración la marca el momento en que se toma la decisión, no el momento en que se genera el dato. Si un comercial consulta existencias delante del cliente, ese dato necesita estar vivo. Si contabilidad concilia una vez al mes, un traspaso diario ya va sobrado.

Dueño: qué sistema manda cuando los dos dicen cosas distintas

Antes de conectar nada, hay que declarar quién es el sistema maestro de cada dato. No del conjunto: de cada dato. El ERP puede mandar sobre precios y existencias mientras el CRM manda sobre el contacto y el estado comercial. Lo que no puede pasar es que ambos escriban sobre el mismo campo sin una regla de prioridad.

Y el dueño no es sólo un sistema: es también una persona. Alguien tiene que responder de qué es un dato correcto en ese campo, quién puede modificarlo y qué se hace cuando llega mal. Un dato sin dueño no se integra; se propaga.

Cómo decidir, paso a paso

1. Define el dato, no el sistema. No integres el CRM con el ERP: integra el estado del pedido, la ficha de cliente o el precio de tarifa. Cada dato es una decisión distinta.
2. Determina la dirección. ¿Va en un sentido o en los dos? La integración bidireccional multiplica el coste y el riesgo; sólo se justifica cuando ambos lados generan cambios legítimos.
3. Fija la frecuencia por la decisión. Escribe cuál es el retraso máximo tolerable antes de que alguien tome una decisión equivocada. Ese número, no la tecnología, es tu requisito.
4. Declara el sistema maestro y el responsable humano de cada campo, y la regla de prioridad si hay conflicto.
5. Comprueba el identificador común. Sin una clave fiable que enlace los registros de ambos lados, ninguna de las tres opciones funciona. Si no existe, el primer proyecto es de datos, no de integración.
6. Inventaría las excepciones. Devoluciones, pedidos parciales, clientes duplicados, altas fuera de horario. Las excepciones son las que rompen las integraciones, no el caso normal.
7. Elige la opción más simple que cumpla los requisitos anteriores, y sólo entonces mira herramientas.
8. Define qué pasa cuando falle. No si falla: cuando falle. Quién se entera, dónde queda registrado y cómo se recupera.

Cuándo sí y cuándo no

Exportación e importación

Sí: consolidaciones periódicas, cargas contables, informes de cierre, sistemas antiguos sin interfaz de programación, volúmenes que se procesan mejor por lotes. No: cuando el dato sostiene una decisión inmediata, cuando el fichero lo genera una persona a mano cada día, o cuando el formato depende de cómo lo exporte cada uno.

Conexión directa por API

Sí: dos sistemas, un dato claro, una dirección, frecuencia alta y un identificador común fiable. No: cuando hay reglas de transformación complejas, cuando entran en juego más de dos sistemas, o cuando aún no está decidido quién manda sobre el dato. En ese caso la conexión directa no simplifica: reparte la lógica de negocio en sitios donde nadie la encuentra.

Capa intermedia

Sí: tres o más sistemas, reglas de negocio en medio, necesidad de trazabilidad de cada movimiento, previsión de crecer. No: para conectar dos sistemas con un único dato sencillo. Ahí es un coste fijo que no compra nada.

Y una advertencia transversal: si el proceso que hay debajo está mal diseñado, ninguna de las tres opciones lo arregla. Antes de integrar, decide si lo que tienes es un problema de conexión o de flujo. Esa distinción la desarrollamos en integración, automatización o IA.

Qué medir para saber si ha funcionado

Una integración sin medición es una expectativa. Antes de implantarla, registra el punto de partida de algunas de estas métricas; después, compara:

• Tiempo dedicado al traspaso manual por semana, y de qué personas.
• Discrepancias detectadas entre los dos sistemas por período: cuántos registros no cuadran.
• Retraso real del dato: cuánto tarda un cambio en un sistema en verse en el otro.
• Incidencias por dato incorrecto: pedidos mal servidos, facturas rehechas, consultas al cliente para confirmar información.
• Ejecuciones fallidas de la integración y tiempo hasta detectarlas. Una integración que falla en silencio es peor que no tenerla, porque genera confianza injustificada.

Si no puedes poner un número aproximado a ninguna de las cinco antes de empezar, todavía no estás en fase de integrar: estás en fase de medir. Y esa fase es barata comparada con rehacer una conexión mal elegida.

Cuatro errores que encarecen cualquier integración

1. Integrar sin limpiar antes. Sincronizar dos bases de datos con duplicados los reparte a ambos lados. El orden correcto está en limpiar los datos del CRM antes de comprar más software.
2. Bidireccional por defecto. Se elige porque suena más completo y multiplica los conflictos. Empieza en un sentido; añade el otro sólo si hay un motivo escrito.
3. Nadie mira la integración hasta que alguien se queja. Sin registro de ejecuciones ni aviso de fallos, el primer detector de errores es el cliente.
4. Tratarla como un proyecto que termina. Los proveedores cambian versiones, los campos se amplían, aparecen casos nuevos. Una integración es una pieza que se mantiene, con un coste recurrente que hay que presupuestar desde el principio.

Ninguno de los cuatro es un problema tecnológico. Los cuatro son decisiones de proceso que se tomaron tarde o no se tomaron.

La conclusión práctica es sencilla: elige la opción más simple que cumpla el requisito de frecuencia, con un dueño declarado para cada dato y un plan para cuando falle. Si esa opción resulta ser un fichero diario, es una buena integración. La calidad de una integración no se mide por lo moderna que sea, sino por cuántas discusiones sobre qué dato es el bueno hace desaparecer.