Fundamentos de Datos Unificados

Cómo Lo Construimos

Su equipo de Finanzas saca números de Oracle. Operaciones tiene otra versión en una hoja de cálculo. Marketing confía en una tercera fuente que nadie puede rastrear. Tres departamentos, tres respuestas a la misma pregunta — y una discusión el lunes por la mañana sobre cuál es la correcta.

Eso es lo que cuesta no tener una infraestructura de datos. No en dinero (aunque los costos se acumulan), sino en confianza. Cuando los líderes no confían en los números, dejan de usarlos. Las decisiones se vuelven lentas. La gente recurre a la intuición.

Cómo se ve el problema en la realidad

La mayoría de las empresas con las que trabajamos comparten un patrón: analistas consultando bases de datos de producción directamente, métricas definidas de forma diferente por departamento, y procesos de reporteo que toman días porque alguien tiene que reconciliar manualmente antes de que alguien apruebe. Un cliente de franquicias tenía 100+ sucursales sin un warehouse centralizado — los KPIs críticos estaban dispersos entre Oracle EBS, hojas de cálculo y reportes manuales. Otro tenía Shopify, plataformas de publicidad y Odoo ERP, cada uno contando una historia diferente sobre los márgenes.

La causa raíz rara vez es incompetencia técnica. Es crecimiento orgánico. Se agregan sistemas, los equipos construyen soluciones temporales, y nadie tiene el mandato de unificar el desorden.

Qué construimos en la práctica

Diseñamos stacks de datos cloud-native usando Fivetran (ingesta), Snowflake (warehouse) y dbt (transformación y gobernanza). La arquitectura sigue un patrón estricto de tres capas: modelos de staging que limpian datos crudos de origen, modelos intermedios que aplican lógica de negocio, y marts que sirven datasets listos para analítica.

Para Carl’s Jr México (Grupo AFAL), eso significó 134 modelos de staging, 47 modelos intermedios y 34 marts — construidos desde cero con 231 pruebas automatizadas de calidad de datos. Cada definición de métrica está documentada en código. Cada prueba se ejecuta antes de que los dashboards se actualicen. Cuando un número está mal, lo sabe en horas, no en semanas.

También conectamos la capa semántica — la parte que la mayoría de las implementaciones omiten. Una capa semántica significa que “ingresos” significa lo mismo ya sea que su CFO abra Tableau, su gerente de operaciones abra un bot de Slack, o su científico de datos consulte Snowflake directamente. Sin ella, tiene un warehouse. Con ella, tiene una infraestructura.

Con qué se queda al final

Una plataforma de datos lista para producción: ingesta automatizada desde sus sistemas fuente, pipelines de transformación gobernados con lógica versionada, un suite de pruebas que detecta problemas de calidad antes de que lleguen a los dashboards, y controles de acceso basados en roles para que las personas correctas vean los datos correctos.

Los entregables típicamente incluyen: arquitectura del warehouse (diseño de base de datos, esquemas y accesos), proyecto de dbt con pipeline completo de staging a marts, conectores de ingesta automatizados, suite de pruebas de calidad de datos, documentación de definiciones de métricas, y un runbook para que su equipo pueda operar de forma independiente.

Cuándo esto no es lo que necesita

Si ya tiene un warehouse funcionando y su problema es la calidad o adopción de dashboards, empiece con Reportes Automatizados. Si su volumen de datos es pequeño (menos de 10 tablas fuente) y su equipo es técnico, una configuración ligera sin dbt puede ser más rápida. Se lo diremos durante la evaluación.

Tres preguntas para hacerte a ti mismo

¿Dos departamentos alguna vez presentan números diferentes para la misma métrica en la misma junta? ¿Los analistas consultan bases de datos de producción porque no hay warehouse o el warehouse está desactualizado? ¿Algún proyecto de reporteo se ha estancado porque nadie podía ponerse de acuerdo en las definiciones de métricas?