Cómo centralizar los datos de varios sistemas: el orden que funciona

La forma de centralizar datos que funciona no es conectar todos tus sistemas a la vez: es elegir un dominio de negocio, integrarlo completo hasta que alguien decida con él, y usar ese resultado para financiar el siguiente. El proyecto que intenta integrar todo de golpe es el que se cancela en el mes ocho, cuando lleva medio presupuesto gastado y nadie ha tomado una decisión distinta.

Esta es la secuencia, con lo que hay que hacer en cada fase.

Fase 0 — Elegir el dominio, no las fuentes

Antes de mirar ninguna herramienta, decide qué decisión de negocio quieres poder tomar mejor. No “integrar el ERP”: “que cobranza pueda ver cada lunes qué clientes se van a atrasar”.

Esa formulación hace tres cosas que un alcance técnico no logra:

• Define automáticamente qué fuentes hacen falta (y cuáles no).
• Da un criterio de éxito que se cumple o no se cumple.
• Le da un dueño natural al proyecto: quien toma esa decisión hoy a ciegas.

Cómo elegir entre dominios: el que tenga el mayor costo actual. Si conciliar inventario consume 15 horas semanales de dos personas y cobranza detecta atrasos con un mes de retraso, empieza por el que puedas cuantificar mejor. El método para calcularlo está en cuánto cuesta no tener los datos ordenados.

Fase 1 — Inventario de fuentes del dominio

Solo del dominio elegido. Para cada fuente, cuatro datos:

Qué documentar	Por qué importa
Sistema y forma de acceso	¿Base de datos, API, archivo, SAP? Determina la herramienta de ingesta
Frecuencia de actualización real	No la teórica. Si el ERP cierra a las 2 a.m., ningún dato del día está completo antes
Volumen y crecimiento	Define el costo de cómputo y si conviene carga incremental
Dueño en el negocio	La persona que puede explicar por qué un campo tiene tres valores raros

Ese último renglón es el que más se omite y el que más tiempo ahorra después. Sin él, tu equipo técnico va a pasar semanas adivinando reglas de negocio.

Fase 2 — Ingesta: traer los datos sin construir plomería

Aquí la decisión clave es no desarrollar conectores propios salvo que no exista otra opción. El costo dominante de estos proyectos nunca fueron las licencias: es el mantenimiento de la integración cuando el proveedor del sistema cambia su API.

Según la fuente:

• Aplicaciones de negocio comunes —CRM, e-commerce, marketing, bases de datos— con Fivetran: conectores gestionados, sin mantenimiento propio.
• Integración enterprise y MDM con Informatica, cuando además hace falta gobierno de datos maestros.
• Conexión vía APIs con MuleSoft, cuando el problema es conectar front-office con back-office de forma gobernable.
• SAP con Theobald. Extraer datos de SAP hacia analítica es un problema propio, y esta es la vía estable sin desarrollar en ABAP.

El principio que ahorra más trabajo: carga primero, transforma después (ELT en lugar de ETL). Trae los datos como están a la Data Cloud y transfórmalos ahí. Si transformas antes de guardar y luego descubres que necesitabas un campo que descartaste, tienes que rehacer la ingesta.

Fase 3 — Data Cloud: un solo lugar consultable

Los datos llegan a una plataforma donde se pueden cruzar. Usamos Snowflake por una razón operativa concreta: separa el cómputo del almacenamiento, así que un proceso de carga pesado no bloquea los tableros de nadie y pagas cómputo solo cuando consultas.

Dos decisiones prácticas de esta fase:

Conserva los datos crudos. Guarda una copia tal como llegó, antes de transformar. Cuando aparezca una discrepancia —y va a aparecer— poder comparar contra el origen es la diferencia entre resolverlo en una hora o en una semana.

Modela por capas. Crudo → limpio → modelo de negocio. Que cada capa sea reconstruible desde la anterior. Así un cambio de regla de negocio no obliga a volver a extraer nada.

Si estás decidiendo entre warehouse, lake o lakehouse, la respuesta para la mayoría de las organizaciones medianas está en este artículo — y suele ser más simple de lo que te están proponiendo.

Fase 4 — Definiciones: el paso que casi todos se saltan

Aquí es donde se decide si el proyecto sirvió o solo movió el problema.

Con los datos ya juntos, hay que acordar una sola definición por métrica. Y esto no es trabajo técnico: es una conversación entre áreas. Cuando Finanzas cuenta clientes activos excluyendo cobranza y Comercial incluye a cualquiera con compra en 12 meses, ninguna está mal — falta declarar cuál es la oficial.

El entregable de esta fase es una capa semántica: la lógica de negocio definida una vez, que todo lo demás consulta. Es lo que permite que un tablero, una hoja de cálculo y un agente de IA devuelvan el mismo número. Está explicado a fondo en qué es una capa semántica.

Advertencia práctica: esta fase casi siempre toma más de lo estimado, porque el trabajo real es organizacional. Presupuéstalo como tal.

Fase 5 — Gobierno, y luego el siguiente dominio

Tres cosas antes de declarar el dominio terminado:

1. Permisos aplicados en los datos, no en el tablero. Si el filtro vive en la capa de presentación, cualquier agente que consulte por debajo lo rodea.
2. Un responsable por dominio — alguien de negocio, no de TI — que responda por la calidad.
3. Linaje documentado, para poder rastrear cualquier cifra hasta su origen. Alation resuelve esta parte.

Con eso listo, el siguiente dominio entra sobre el mismo cimiento y cuesta bastante menos.

Los tres errores que hacen fracasar el proyecto

1. Empezar por la herramienta de visualización. Es el más común y el más caro. Se compra y migra la capa de presentación, y seis meses después las preguntas nuevas siguen tardando semanas — porque el cuello de botella nunca estuvo ahí. Más sobre esto en BI tradicional vs moderno.

2. Integrar todo antes de entregar algo. Cada mes sin un resultado visible es un mes en el que el proyecto pierde patrocinio interno. Un dominio funcionando vale más que ocho a medias.

3. Tratar las definiciones como un detalle técnico. Si se deja para el final o se delega al equipo de datos “para que decida”, terminas con la plataforma centralizada y las cifras seguirán sin cuadrar. Y ahí sí, el proyecto se recuerda como un fracaso aunque técnicamente funcione.

Cuánto tarda, honestamente

Depende del número de fuentes y de qué tan limpias estén, así que cualquiera que te dé un número sin haber visto tus sistemas está adivinando.

Lo que sí puedo decirte del patrón: el primer dominio es el más lento porque incluye construir el cimiento, y los siguientes bajan de forma notable porque reutilizan ingesta, modelo y gobierno. Si un proveedor te cotiza los dominios al mismo costo, no está aprovechando lo que ya construyó.

Y una señal de alerta al evaluar propuestas: si nadie menciona la fase 4 —las definiciones— es que están cotizando un proyecto de plomería, no de datos.

---

En EGOS BI hacemos exactamente esta secuencia, por dominios, desde Monterrey y para clientes en México, Colombia, Perú, Chile y Estados Unidos. El alcance completo está en centralización de datos, y si quieres empezar identificando qué dominio te está costando más, agenda un diagnóstico.