Qué significa realmente que dos sistemas estén integrados

Que dos sistemas estén integrados no significa únicamente que exista una forma técnica de conectarlos. Significa que la información fluye entre ellos de forma continua, sin que nadie tenga que actuar como intermediario cada vez que hace falta.

Exportar un archivo una vez, o pedirle a alguien de IT que conecte dos herramientas puntualmente, no es lo mismo que tener una integración: una integración sigue funcionando cuando nadie está pendiente de ella.

Señales de que tus herramientas están funcionando como islas

Ninguna señal es determinante por sí sola, pero cuando varias coinciden a la vez, suele valer la pena analizarlo con más detalle:

  • Introducir el mismo dato varias veces. La misma información se escribe a mano en más de un sistema porque no hay ninguna conexión entre ellos.
  • Exportar un Excel de una aplicación para importarlo en otra. El traslado de información depende de un archivo intermedio y de que alguien se acuerde de moverlo.
  • Ver información distinta según en qué sistema la consultes. Dos aplicaciones muestran datos diferentes sobre lo mismo, y nadie tiene del todo claro cuál es el correcto.
  • Alguien actúa como puente manual entre dos aplicaciones. Una persona concreta es, en la práctica, el mecanismo que conecta dos sistemas que deberían hablar entre sí.
  • Un proceso se detiene hasta que alguien actualiza otro sistema. El trabajo no avanza porque depende de que una persona recuerde trasladar la información manualmente.
  • Cuesta saber cuál de dos versiones de un dato es la correcta. Cuando algo no cuadra, hay que preguntar o comparar a mano en lugar de tener una respuesta única y clara.
  • Existen APIs disponibles que nadie ha llegado a utilizar. La conexión técnica es posible, pero el proceso real sigue dependiendo de trabajo manual.

Cuándo integrar puede resolver el problema

Integrar suele tener sentido cuando coinciden varias de estas condiciones:

  • El mismo dato tiene que existir de forma coherente en más de un sistema.
  • El proceso ya está lo bastante definido como para establecer reglas claras sobre qué información debe viajar y cuándo.
  • Hay volumen o frecuencia suficiente para que la duplicación manual sea un problema real, no algo puntual.
  • Los sistemas que hay que conectar van a seguir siendo los que usa la empresa, no están a punto de sustituirse.
  • Existe una forma razonable de conectarlos: una API, una exportación estructurada o algún mecanismo equivalente.

No hace falta que se cumplan todas: cuantas más coincidan, más claro suele estar el caso.

Cuándo el problema no es (solo) de integración

A veces lo que parece un problema de sistemas desconectados es, en realidad, otra cosa distinta.

Todavía no hace falta integrar

Si el volumen es muy bajo, el proceso todavía cambia constantemente, o solo una persona necesita esa información, probablemente el esfuerzo de integrar no se justifique todavía. Antes conviene que el proceso se estabilice.

El problema es de automatización

Integrar significa que varios sistemas compartan información. Automatizar significa que determinadas acciones ocurran sin intervención manual. A veces los sistemas ya comparten la información correctamente, pero alguien sigue teniendo que revisar y ejecutar un paso a mano cada vez. Ahí el problema no es de conexión entre sistemas: es de automatización de una tarea.

El problema es de software a medida

Construir software a medida tiene sentido cuando ninguna de las herramientas existentes cubre bien una parte del proceso. A veces el problema no es que dos sistemas no se hablen entre sí, sino que falta una pieza: ninguna aplicación actual resuelve realmente esa parte del trabajo.

Estas tres situaciones no son excluyentes. Un mismo proceso puede necesitar integración en un punto, automatización en otro, y en algún caso, una pieza de software que hoy no existe.

Un ejemplo: de una venta en el CRM a un pedido en el ERP

Un caso habitual: un comercial cierra una venta en el CRM, y alguien tiene que volver a introducir los datos del cliente y del pedido en el ERP para que se pueda gestionar la producción, el almacén o la facturación. Si además hay que reflejarlo en un tercer sistema, el mismo trabajo se repite otra vez.

Al integrar el CRM con el ERP, los datos necesarios podrían viajar automáticamente de uno a otro en cuanto se cierra la venta. Eso no significa necesariamente que el proceso se vuelva invisible: según cómo se diseñe, puede seguir existiendo un paso de revisión o aprobación antes de que el pedido quede confirmado. Lo que cambia es que esa revisión parte de datos ya correctos, en lugar de depender de que alguien los teclee de nuevo.

El concepto de fuente de verdad

Cuando el mismo dato puede existir en varios sistemas, hay que decidir cuál de ellos manda. La fuente de verdad de un dato es el sistema del que parte esa información, y al que el resto deberían remitirse cuando hay una discrepancia.

No tiene por qué ser siempre el mismo sistema para todos los datos: el CRM puede ser la fuente de verdad de los datos de contacto de un cliente, mientras que el ERP puede serlo de su situación de facturación. Definir esto con claridad, antes de conectar nada, evita buena parte de las inconsistencias habituales.

Qué información debería viajar entre sistemas

No todo necesita sincronizarse, y no siempre en la misma dirección. A veces la información solo necesita viajar en un sentido, por ejemplo del CRM al ERP cuando se cierra una venta. Otras veces necesita viajar en ambos sentidos, por ejemplo si el estado de un pedido en el ERP también debe reflejarse de vuelta en el CRM para que el comercial lo vea.

Antes de conectar sistemas conviene tener claras unas pocas cosas:

  • ¿Qué dato concreto necesita viajar de un sistema a otro?
  • ¿En qué dirección debe moverse: de A a B, o en ambos sentidos?
  • ¿Qué sistema debe considerarse la fuente de verdad de ese dato?
  • ¿Con qué frecuencia necesita actualizarse para que el proceso funcione bien?
  • ¿Qué debería pasar si el dato llega incompleto o incoherente?

Tiempo real o sincronización periódica: depende del proceso

Algunos procesos necesitan que la información esté actualizada al instante, por ejemplo si el stock disponible afecta directamente a lo que se puede vender en ese momento. Otros funcionan perfectamente bien con una sincronización periódica, cada hora o una vez al día, sin que eso suponga ningún problema real para el negocio.

Ninguna de las dos opciones es mejor en abstracto: depende de qué ocurre realmente si esa información tarda un poco en llegar. El tiempo real tiene sentido cuando ese retraso genera un problema; si no, una sincronización periódica suele ser más sencilla de mantener.

Qué ocurre cuando una integración falla

Una integración puede fallar: un sistema no responde, llega un dato incompleto, o dos cambios chocan entre sí. Antes de conectar sistemas conviene tener claro qué pasa en ese momento: si el proceso se detiene, si alguien recibe un aviso, si el dato queda pendiente de revisión, o si existe algún mecanismo de reintento.

Diseñar una integración incluye decidir qué pasa cuando algo no sale como se esperaba, no solo cuando todo funciona bien.

Empieza por el proceso, no por la conexión

Antes de decidir qué conectar, conviene entender el proceso completo: qué información se mueve, entre qué sistemas, con qué frecuencia, quién la usa y qué pasa si algo falla.

Con esa base, decidir si hace falta integrar, automatizar, construir algo nuevo, o simplemente mantener el proceso como está, resulta mucho más sencillo.