Data foundation o proyectos aislados: por qué hacer la base primero

Construir primero un data foundation conviene porque es la única inversión que se reutiliza en todos los proyectos de datos que vienen después. Cuando cada iniciativa (un tablero de ventas, un forecast de demanda, un agente de IA, una automatización) arma su propia integración, su propia limpieza y sus propias definiciones, la empresa paga el mismo trabajo tres o cuatro veces y termina con cifras que no coinciden. Con una base común, el primer proyecto cuesta parecido, pero el segundo, el tercero y el décimo salen mucho más rápidos y más baratos. No se trata de un proyecto de infraestructura de dos años: se construye dominio por dominio, entregando valor desde el primero.

¿Cómo se ve el modelo de proyectos aislados en México?

Es el modelo más común en empresas medianas en México, y nadie lo eligió a propósito. Así suele pasar:

• Año 1. Comercial contrata un tablero de ventas. El proveedor conecta el BI directo al punto de venta y escribe la lógica dentro del tablero.
• Año 2. Finanzas necesita rentabilidad por tienda. Otro equipo extrae del ERP a una base intermedia, cruza a mano con ventas y arma su propio modelo.
• Año 3. Operaciones quiere un forecast de demanda. El equipo de ciencia de datos vuelve a extraer ventas e inventario porque no confía en las dos versiones anteriores.
• Año 4. La dirección pide un agente de IA que conteste preguntas del negocio. Ahora hay tres versiones de la venta y nadie sabe a cuál conectarlo.

Cada proyecto, visto solo, fue razonable. En conjunto, la empresa pagó la integración de ventas tres veces, mantiene tres procesos de carga que se rompen en momentos distintos y tiene tres cifras de venta que discute en cada comité.

¿Qué cambia con una base común?

Concepto	Proyectos aislados	Con data foundation
Integración de fuentes	Se repite en cada proyecto	Se hace una vez por fuente
Definición de métricas	Dentro de cada herramienta	En una capa semántica compartida
Costo del proyecto nuevo	Similar o mayor que el anterior	Baja con cada proyecto
Tiempo del proyecto nuevo	Meses, por la parte de datos	Semanas, solo la parte de consumo
Mantenimiento	Un proceso por proyecto, cada uno con su falla	Un proceso por fuente, vigilado
Confianza en las cifras	Depende del tablero	Una sola versión
Preparación para IA	Hay que empezar de cero	Los agentes consumen lo mismo que los tableros
Cambiar de herramienta	Se pierde la lógica de negocio	La lógica vive fuera de la herramienta

La diferencia más importante no es técnica, es económica: en el modelo aislado el costo de los datos se paga en cada proyecto; con una base común se paga una vez y se amortiza.

¿Por qué el segundo proyecto sale más barato?

Porque en casi cualquier proyecto de analítica o IA, la mayor parte del esfuerzo no está en el tablero ni en el modelo: está en conseguir, limpiar, cruzar y validar los datos. Esa parte es exactamente la que el data foundation deja resuelta.

Un ejemplo con forma de retail mexicano:

1. Primer dominio: ventas. Integras punto de venta y comercio electrónico en Snowflake, modelas tienda, producto, canal y calendario, y defines venta neta, ticket promedio y tiendas comparables. Sobre eso montas el tablero de ventas. Este proyecto carga con el costo de la base.
2. Segundo: inventario. Agregas la fuente del ERP o del almacén. Tienda, producto y calendario ya existen; solo modelas existencias y movimientos. El tablero de quiebres de stock usa los mismos filtros que ventas, sin conciliación.
3. Tercero: forecast de demanda. Ventas e inventario ya están limpios, con historia y llaves estables. El equipo de ciencia de datos empieza a modelar el primer día en lugar del tercer mes.
4. Cuarto: agente de IA. El agente consulta la misma capa semántica que los tableros. Las preguntas “¿cuánto vendimos?” y “¿dónde me voy a quedar sin inventario?” ya tienen respuesta oficial.

En el caso de retail de moda que trabajamos, más de diez fuentes se integraron con Fivetran hacia Snowflake, y sobre esa misma base se montó la capa de visualización y la entrega de información al equipo por Slack. Ese es el patrón: una base, varios consumos.

¿No es más lento empezar por la base?

Es la objeción más razonable, y la respuesta corta es no, si se hace por dominios. El error que hace que la base parezca lenta es intentar integrar todos los sistemas de la empresa antes de entregar nada. Eso sí toma un año y pierde el patrocinio a la mitad.

El enfoque que usamos en arquitectura de datos moderna es otro:

• Un dominio con dueño. Ventas, inventario, cobranza o el que más duela.
• Solo las fuentes de ese dominio. Nada de “ya que estamos, metamos todo”.
• Un consumo real al final. Un tablero que reemplaza un reporte manual o un agente que contesta preguntas reales.
• Tiempos acotados. En nuestra metodología, un MVP con arquitectura productiva y un caso de uso toma de 6 a 10 semanas.

El primer dominio tarda más o menos lo mismo que un proyecto aislado bien hecho. La diferencia es que lo que se construyó sirve para el siguiente.

¿Cuándo sí tiene sentido un proyecto aislado?

Hay casos donde no vale la pena esperar a la base, y conviene decirlo:

• Una pregunta de una sola vez. Un análisis para una decisión puntual (abrir o no una plaza) puede hacerse con un extracto. Solo no lo conviertas en un proceso recurrente.
• Un piloto para demostrar valor a la dirección. Válido, siempre que se diseñe sabiendo que se va a reconstruir sobre la base si funciona. Lo desarrollamos en por qué fracasan los pilotos de IA.
• Una herramienta con datos propios y aislados. Si el dato nace y muere en una sola aplicación y nadie lo cruza con nada, no necesita pasar por la base.

Fuera de esos casos, si el proyecto toca datos que otra área también usa, va sobre la base.

¿Cómo se justifica ante finanzas?

El argumento no es “la base es buena práctica”, porque eso no aprueba presupuesto. Son tres números que cualquier empresa en México puede calcular con sus propios datos:

1. Horas de conciliación al mes. Cuántas personas arman, cuadran y corrigen reportes, y cuántas horas les toma. Lo desarrollamos en cuánto cuesta realmente no tener los datos ordenados.
2. Costo de los proyectos de datos de los últimos tres años. Cuánto de cada uno se fue en integración y limpieza que hoy ya no se reutiliza.
3. La lista de iniciativas pedidas. Cuántos tableros, modelos y agentes están en espera. Cada uno, en el modelo aislado, volverá a pagar la parte de datos.

Con esos tres números el caso se arma solo. Y si quieres entender el modelo de cobro por uso de las plataformas que forman la base, revisa cuánto cuesta Snowflake en México y qué es una arquitectura de datos moderna y qué mueve su costo.

Lo que conviene llevar a la primera llamada

• La lista de proyectos de datos, BI o IA de los últimos tres años, con su proveedor y su estado actual.
• Cuántos procesos de carga distintos mantienen hoy y quién los opera.
• Las iniciativas que la dirección tiene en fila para los próximos 12 meses.
• Cuál de esas iniciativas tiene más presión de tiempo.

Con eso proponemos qué dominio construir primero para que alimente la iniciativa urgente y deje la base para las siguientes. Si quieres el panorama de toda la serie, empieza por qué es un data foundation y por qué agentes y dashboards dependen de él. Agenda la conversación aquí.