La misma venta se registra tres veces: en la tienda, en una planilla y en el sistema contable. Un cambio de stock tarda horas en aparecer. Cuando alguien pregunta cómo integrar sistemas existentes, el problema real suele estar ahí: la información vive en varios sitios y nadie sabe cuál refleja la operación.
Integrar no significa reemplazar todo lo que ya funciona. Significa definir qué sistema manda sobre cada dato, cómo se comunica con los demás y qué ocurre cuando esa comunicación falla. Si se omite ese trabajo, la integración añade otra capa de dependencia sobre un proceso ya frágil.
Antes de conectar sistemas, define el problema
Una integración útil empieza por un flujo concreto. Por ejemplo: un pedido pagado debe descontar stock, generar un documento, avisar a bodega y actualizar el estado que ve el cliente. No hace falta conectar cada herramienta de la empresa para resolver ese flujo.
Conviene dibujar el proceso tal como ocurre, incluyendo los pasos manuales. Ahí suelen aparecer decisiones que estaban escondidas en una persona: qué hacer con un pago rechazado, quién corrige una dirección incompleta o cómo se registra una devolución. El software debe respetar esas reglas o cambiarlas de forma explícita. No puede adivinarlas.
También hay que separar el dato de su representación. Un cliente puede aparecer con nombres distintos en un CRM, una plataforma de ventas y una base de datos interna. Antes de sincronizar, hay que acordar qué identifica a ese cliente. En muchos casos será un correo electrónico; en otros, un identificador interno o un dato fiscal. Usar el nombre como clave termina creando duplicados.
Elige una fuente de verdad por dato
Cada dato necesita un propietario. El catálogo puede vivir en el sistema de inventario. Los pagos, en la pasarela de pago. Los permisos del personal, en la aplicación interna. El resto puede consultar o recibir copias, pero no debería editar el mismo campo sin una regla clara.
Cuando dos sistemas pueden modificar el precio, el stock o el estado de un pedido, aparece el conflicto. A veces se resuelve con una prioridad definida. Otras veces conviene prohibir la edición en uno de los lados. Depende del proceso, pero dejar ambas opciones abiertas por comodidad crea errores difíciles de rastrear.
Cómo integrar sistemas existentes sin duplicar el caos
Hay tres caminos habituales. La elección depende de la calidad de los sistemas actuales, de la frecuencia de los cambios y del coste operativo de un error.
El primer camino es usar la API que ofrece una herramienta. Una API permite que otro sistema lea o escriba datos bajo reglas definidas. Es la opción más estable cuando está bien documentada y cubre las acciones necesarias. No todas las APIs lo hacen: algunas permiten consultar pedidos, pero no crear devoluciones; otras limitan cuántas peticiones se pueden hacer por minuto.
El segundo camino es recibir eventos. En lugar de preguntar cada cierto tiempo si hay una venta nueva, el sistema de origen avisa cuando ocurre. Esto reduce retrasos y evita consultas innecesarias. Requiere que el receptor pueda validar el aviso, registrarlo y procesarlo más de una vez sin duplicar consecuencias. Un mismo evento puede llegar repetido.
El tercero es importar y exportar archivos. Un CSV diario puede ser suficiente para conciliaciones o procesos que no necesitan información al minuto. No conviene despreciarlo por ser simple. Si bodega trabaja por cortes horarios y el volumen es manejable, un archivo validado puede ser más fiable que una integración en tiempo real mal mantenida.
La mala opción es automatizar la pantalla de otro sistema como si fuera una persona haciendo clic. A veces no queda alternativa, especialmente con software antiguo sin API ni exportaciones útiles. Pero es frágil: un cambio visual, una sesión caducada o un campo movido puede detener el proceso. Si se usa, debe tratarse como una solución temporal y vigilarse de cerca.
No conectes directamente todo con todo
Cuando una empresa suma herramientas sin arquitectura, cada sistema acaba conectado con varios más. Una modificación pequeña rompe un flujo que nadie recordaba. El coste no aparece al principio, aparece cuando hay que cambiar una regla de negocio.
Para evitarlo, suele convenir crear una capa propia entre las herramientas externas y la operación. Esa capa guarda los identificadores, aplica las reglas del negocio, registra errores y expone una interfaz estable para el panel interno o la web. Las plataformas externas cambian; la lógica que define cómo se opera no debería quedar repartida entre ellas.
En un desarrollo a medida, una base de datos como PostgreSQL puede concentrar esa información operativa. La aplicación no necesita copiar todos los datos de cada proveedor. Debe conservar lo que necesita para trabajar, auditar acciones y recuperarse de una interrupción. Copiar datos sin criterio aumenta el riesgo de desactualización y complica la protección de información personal.
Diseña la integración para los errores normales
Las integraciones fallan por motivos corrientes: una API responde lento, una credencial caduca, un proveedor devuelve un error temporal o alguien modifica un producto mientras se procesa un pedido. El problema no es que ocurra. El problema es no saber qué quedó a medias.
Cada operación relevante debe dejar un registro. Si se creó una factura, el sistema debe guardar cuándo se intentó, qué respondió el proveedor y qué identificador recibió. Si falló, debe quedar visible para que una persona pueda corregirlo o reintentar el proceso sin crear un duplicado.
También conviene separar la acción que inicia el usuario del trabajo que tarda. El personal no debería esperar en pantalla mientras se sincronizan cientos de registros. La aplicación confirma que recibió la solicitud y procesa la tarea en segundo plano. Si el resultado necesita revisión, lo muestra en una bandeja de incidencias concreta, no en un correo genérico que se pierde entre otros mensajes.
Los reintentos necesitan límites. Repetir una petición puede arreglar un corte breve, pero repetir un cargo o una emisión documental puede causar un problema mayor. Por eso se usan identificadores únicos y reglas de idempotencia: si llega la misma orden dos veces, el sistema reconoce que ya fue procesada y no ejecuta el efecto de nuevo.
Un proceso de cuatro pasos que evita sorpresas
1. Auditar sistemas y flujos
El primer entregable no debería ser código. Debe ser un mapa breve: sistemas involucrados, responsables, datos que intercambian, frecuencia y puntos de fallo conocidos. También hay que revisar accesos. Usar la cuenta personal de un empleado para una integración es una deuda inmediata.
En esta etapa se distingue lo imprescindible de lo deseable. Integrar pedidos y stock puede resolver un cuello de botella. Sincronizar cada campo histórico de un CRM quizá puede esperar. Recortar alcance no significa dejar el trabajo a medias; significa entregar un flujo operativo y verificable antes de abrir otro frente.
2. Definir contratos y permisos
Un contrato especifica qué datos entran, qué datos salen y qué respuesta se espera. Por ejemplo, un pedido debe incluir una referencia única, líneas de producto, importe y estado de pago. Si falta una referencia, el sistema lo rechaza antes de contaminar la base de datos.
Los permisos forman parte de ese contrato. Una integración debe acceder solo a lo necesario. Si necesita leer pedidos, no debería tener permiso para borrar usuarios. Cuando una clave se filtra o un proveedor cambia sus condiciones, limitar privilegios reduce el alcance del incidente.
3. Construir una primera integración medible
La primera versión debe cubrir un recorrido completo. No basta con mostrar datos en una pantalla. Hay que comprobar que el dato llega, se transforma según la regla acordada, produce el efecto esperado y deja trazabilidad.
Aquí conviene usar datos de prueba parecidos a los reales: pedidos cancelados, productos sin stock, clientes repetidos y direcciones incompletas. Las integraciones suelen fallar en las excepciones, no en el pedido perfecto que se usó para la demostración.
4. Pasar a producción con observabilidad
Poner una integración en producción no termina al publicar el código. Hay que configurar alertas que avisen cuando una cola se acumula, una tarea falla repetidamente o una credencial deja de funcionar. Los backups y el monitoreo importan porque una integración modifica datos de negocio, no porque sean una lista técnica obligatoria.
En TevDev Studio, la infraestructura se prepara junto con la aplicación: despliegue, SSL, copias de seguridad y monitoreo. Esto evita que la lógica quede terminada en un repositorio mientras la operación depende de configuraciones manuales sin responsable claro.
Cuándo conviene sustituir un sistema en vez de integrarlo
Integrar tiene sentido cuando el sistema actual cumple bien su función y ofrece una forma razonable de intercambiar datos. Una herramienta de facturación especializada, una pasarela de pago o un servicio logístico suelen encajar en ese caso.
Conviene plantear sustitución cuando el sistema obliga a exportar archivos manuales cada día, no permite controlar permisos, pierde información o depende de una instalación que nadie puede mantener. También cuando las reglas críticas viven en macros de una planilla que solo entiende una persona. Conectar esa fragilidad a una aplicación nueva puede hacer el problema más caro de mantener.
La decisión no es técnica por sí sola. Hay que comparar el riesgo de seguir sosteniendo el sistema con el riesgo de cambiarlo. A veces una integración temporal permite ordenar la operación mientras se reemplaza una pieza concreta. Otras veces, construir alrededor de una herramienta limitada ata el negocio a sus restricciones durante años.
Una buena integración deja claro qué dato manda, quién puede modificarlo y cómo se recupera un error. Si esas tres respuestas están documentadas y se pueden comprobar en la operación, el sistema deja de depender de memoria, mensajes sueltos y archivos enviados por correo.