Por qué sus sistemas no se hablan entre sí, y qué hacer antes de conectarlos

El problema casi nunca es el sistema: son cinco, y no se hablan

Cuando una empresa mediana dice que «tiene un problema de sistemas», casi siempre describe mal el problema. Lo que tiene son cuatro o cinco sistemas que funcionan bien cada uno por su lado: la venta queda en uno, el cobro en otro, el documento tributario en un tercero, y el detalle que nadie más entiende en una planilla del computador de alguien.

Cambiar de sistema no arregla eso. Se puede migrar del ERP más viejo al más nuevo del mercado y el problema sigue intacto, porque nunca estuvo en qué programa se usa: está en el espacio que queda entre los programas, que no es responsabilidad de ninguno de ellos por separado.

Cinco señales de que sus sistemas no están integrados

Ninguna de estas señales sola es una emergencia. Cuando aparecen varias a la vez, ya está pagando el costo de no tenerlo resuelto, aunque ese costo no figure en ningún presupuesto.

• El mismo cliente tiene tres fichas distintas. Una en el sistema de venta, otra en el de cobranza, otra en la planilla de despacho, y nadie decidió cuál es la buena.
• Un número cambia según en qué sistema se consulte. El total vendido de octubre no es el mismo en el sistema comercial que en el contable, y la diferencia nunca se explica del todo, solo se acepta.
• Alguien traspasa información a mano, todas las semanas. Exportar de un sistema e importar en otro no es un proceso: es un proceso que todavía no se construyó.
• Armar un reporte simple implica abrir cuatro pestañas. Si responder «cuánto llevamos vendido este mes» requiere entrar a varios sistemas y cuadrar a mano, el dato no está integrado, está disperso.
• La respuesta depende de a quién se le pregunte. Dos personas razonables, mirando el mismo negocio, llegan a números distintos porque cada una confía en un sistema diferente.

Por qué pasa, aunque cada sistema funcione bien por separado

Casi nunca es negligencia. Es la consecuencia lógica de cómo crecen las empresas: se compra un sistema para resolver un problema puntual, después otro para el siguiente, y en ningún momento hubo una decisión consciente de cómo iban a convivir. Cada compra fue correcta por sí sola; el conjunto nunca se diseñó.

Nadie quedó a cargo de decidir cuál manda

Cuando dos sistemas registran el mismo dato, alguien tiene que decidir cuál es la fuente oficial y cuál se corrige contra esa. Mientras esa decisión no exista por escrito, cada sistema sigue siendo su propia verdad, y las diferencias entre ellos se descubren tarde, casi siempre en una reunión.

El copiar y pegar parece gratis, y no lo es

Traspasar datos a mano no aparece en ningún presupuesto porque las horas ya están pagadas dentro de un sueldo. Pero cada copiado es una oportunidad de error que nadie va a auditar, y la persona que lo hace hoy es la misma dependencia que después nadie puede reemplazar cuando se va de vacaciones.

Por qué «conectar los sistemas» no alcanza

La primera reacción, apenas se nombra el problema, es buscar una integración técnica: un conector, una API, un intercambio de archivos entre los dos sistemas que más duelen. Ayuda, pero conecta dos sistemas que ya traían clientes duplicados y definiciones distintas de lo mismo, y lo que hace es trasladar el desorden de un lugar a otro más rápido.

Integrar de verdad exige tres cosas al mismo tiempo, no una: la conexión técnica entre los sistemas, un criterio compartido sobre qué significa cada dato, y un control que avise cuando algo deja de cuadrar. Falta cualquiera de las tres y el problema vuelve, solo que ahora es más difícil de encontrar porque está escondido detrás de una integración que en apariencia funciona.

Qué se construye en un proyecto de ingeniería de datos

El trabajo empieza por conectar cada sistema a su propia fuente, con un conector contra la API o la base de datos correspondiente, y traer todo a un solo lugar que le pertenece a la empresa, no al proveedor. Ahí es donde se resuelve, de una vez, cuál ficha de cliente es la buena y qué pasa cuando dos sistemas no coinciden.

La carga se hace incremental: cada proceso trae solo lo nuevo desde la última vez, no reprocesa el historial completo, y se puede correr dos veces sin duplicar nada. Si una fuente falla un día, el sistema avisa y se recupera solo al día siguiente, sin que nadie tenga que intervenir a mano para que el dato vuelva a estar al día.

Con eso resuelto, cada peso se puede seguir desde donde se originó hasta el reporte final, cruzando entre sistemas en vez de confiando en que alguien lo haya cuadrado bien esa semana.

El orden correcto: primero los datos, después lo que se construye encima

Es tentador saltarse este paso e ir directo a lo vistoso: un panel con gráficos, un reporte que se manda solo. La tentación se paga cara, porque un panel armado sobre datos que no cuadran hereda exactamente el mismo problema, solo que ahora con una capa de diseño encima que lo hace parecer resuelto.

El orden que rinde es el contrario: primero la base de datos confiable, y recién ahí encima los paneles de gestión que responden preguntas del negocio, o la automatización de los reportes que hoy alguien arma a mano. Es menos vistoso al principio, y es la diferencia entre un proyecto que sigue en uso a los dos años y uno que se abandona en el primer trimestre.

Cuándo esto todavía no es lo prioritario

No toda empresa necesita este paso ahora, y decirlo con esa franqueza ahorra un proyecto que no tocaba. Si la operación vive prácticamente en un solo sistema y el resto son casos aislados, o si la empresa todavía está definiendo cómo va a operar y ese modelo cambia cada trimestre, conviene esperar: integrar ahora sería construir sobre una base que va a cambiar de forma antes de terminar de asentarse.

También pasa que la señal más urgente en la práctica es otra: si lo que falta es una planilla mejor ordenada y no un proyecto de datos, ese caso lo tratamos en la otra nota, sobre cuándo basta con un Excel mejor hecho.

Cómo saber si es su caso

La pregunta que separa un caso de otro no es cuántos sistemas tiene, es qué tan seguido necesita cruzar información entre ellos para tomar una decisión. Si eso pasa una vez al año, resuélvalo a mano esa vez. Si pasa cada semana, cada mes o cada vez que alguien pide un número, el costo de seguir haciéndolo a mano ya superó hace rato el de resolverlo una sola vez y bien.

Vale la pena hacer una prueba simple antes de pedir cualquier propuesta: la próxima vez que dos números no coincidan entre sistemas, en vez de corregirlo y seguir, anote cuánto tiempo tomó encontrar la diferencia y quién tuvo que involucrarse. Multiplicado por las veces que eso pasa al mes, ese es el número real que hay que comparar contra cualquier proyecto.