Cómo montar tu primer Data Warehouse

La guía técnica para unificar datos dispersos, construir métricas fiables y crear una arquitectura de datos sin romper lo que ya funciona

Hay un momento bastante concreto en la vida de muchas empresas en el que los datos dejan de ser “cuatro Excels que nos apañan” y empiezan a convertirse en un problema serio.

No suele ocurrir al principio. Al principio la empresa vende, entrega, factura, atiende clientes, corrige incendios, busca mercado, sobrevive. Bastante tiene ya con existir. Nadie se sienta con una pizarra a diseñar una arquitectura de datos elegante, con capas, gobierno, linaje, métricas certificadas, modelos analíticos y procesos de calidad.

Y, sinceramente, es normal.

Una pyme, una startup o una empresa en crecimiento no empieza montando una plataforma de datos perfecta. Empieza con lo que tiene a mano: Excel, Google Sheets, un CRM barato, un ERP que resuelve facturación, una web en WordPress o Joomla, un WooCommerce, alguna base de datos operacional, herramientas SaaS de marketing, formularios, exportaciones CSV, informes manuales y alguna automatización suelta que alguien montó “temporalmente” hace tres años.

Ahora bien, el problema aparece cuando todo eso empieza a mandar.

Cuando el Excel ya no es una hoja de apoyo, sino el sitio donde se calcula el margen. Cuando el CRM ya no es solo una herramienta comercial, sino la supuesta fuente oficial de clientes. Cuando el ERP tiene una parte de la verdad, la web otra, marketing otra, operaciones otra y finanzas otra. Cuando cada reunión empieza con la misma discusión absurda: “¿de dónde ha salido ese número?”.

Ahí empieza el dolor real. Y ahí muchas empresas dicen la frase mágica:

“Necesitamos un dashboard”.

Puede que sí. Pero muchas veces no.

Muchas veces la empresa no necesita primero otro dashboard. Necesita algo más incómodo, más básico y bastante menos vistoso: entender qué datos tiene, dónde están, quién los usa, qué significan, qué calidad tienen, qué riesgo legal o operativo implican y qué decisiones están alimentando.

Eso es lo que vamos a tratar en esta serie.

No una comparativa de herramientas. No un ranking de Snowflake, BigQuery, Redshift, Microsoft Fabric, Databricks o cualquier otra plataforma. No una colección de diagramas bonitos que luego nadie puede operar.

Vamos a hablar de cómo montar tu primer Data Warehouse de verdad: con criterio, paso a paso, sin destruir lo que ya funciona y sin copiar una arquitectura enterprise absurda para una empresa que quizá todavía está montando su primer equipo de datos.

No llegues tarde y toma las riendas.

Muchas empresas llegan tarde a los datos. Pero no porque sean torpes.

Llegan tarde porque tenían otras prioridades.mientas operativas, ficheros manuales, integraciones parciales, conocimiento tribal y personas concretas que “saben dónde está cada cosa”.

Ese último punto es importante.

Cuando una empresa depende de que una persona concreta sepa qué Excel usar, qué campo del CRM es el bueno, qué exportación hay que tocar, qué pedido se debe excluir o qué tabla no se puede consultar directamente, no tiene un sistema de datos. Tiene memoria humana con acceso a carpetas compartidas.

Y eso escala mal…

Escala mal cuando la empresa crece. Escala mal cuando cambian personas. Escala mal cuando aparecen auditorías. Escala mal cuando negocio pide más velocidad. Escala mal cuando se quiere automatizar. Y escala especialmente mal cuando alguien decide que ahora toca hacer IA, predicción o asistentes conectados a datos internos.

Antes de pedir modelos inteligentes conviene saber si ventas, clientes, pedidos, margen y recurrencia significan lo mismo para todo el mundo (ya te lo adelanto yo, NO).

Qué es realmente montar un primer Data Warehouse

Montar un Data Warehouse no consiste en “crear una base de datos grande donde meterlo todo”. Esa definición se queda corta y además suele llevar a malas decisiones.

Un primer Data Warehouse debería ser el inicio de una capacidad técnica y organizativa para integrar datos dispersos, transformarlos con trazabilidad, definir métricas comunes, exponer información fiable y permitir que la empresa tome decisiones con menos fricción y menos trabajo manual.

Dicho de forma más directa: no montas un Data Warehouse para presumir de arquitectura. Lo montas para que la empresa pueda confiar en sus números.

Eso implica tecnología, claro, pero probablemente, eso sea lo menos importante.

Implica saber qué fuentes existen. Implica entender qué dato es operacional y qué dato es analítico. Implica distinguir entre “este campo existe” y “este campo significa algo útil”. Implica definir ownership. Implica versionar transformaciones. Implica controlar permisos. Implica documentar. Implica medir calidad. Implica pensar en costes. Implica tener presente el RGPD si trabajas con datos personales en Europa.

Y sobre todo implica no empezar por el final, porque uno de los errores más habituales es elegir herramienta antes de entender el problema.

La secuencia suele ser más o menos esta: alguien ve una demo, lee un caso de éxito, viene de otra empresa donde usaban una plataforma concreta o alguien quiere “modernizar el stack”… y, de repente, la conversación se convierte en una guerra de marcas.

Snowflake contra BigQuery. Fabric contra Databricks. Redshift contra lo que toque. dbt sí o no. Fivetran, Airbyte, Power BI, Looker, Tableau, notebooks, lakehouse, data mesh, data fabric y todos los cromos posibles encima de la mesa.

Pero si todavía no sabes qué fuentes tienes, qué datos son críticos, qué métricas duelen, qué procesos dependen de hojas manuales, qué datos personales estás moviendo y qué equipo va a operar todo eso, elegir plataforma solo te da una forma más cara de ordenar el caos (o de amplificarlo).

El problema casi nunca empieza en la herramienta

Hay empresas que no tienen ningún Data Warehouse y aun así generan informes.

Es decir, no disponen de una arquitectura de datos pero alguien está haciendo el trabajo a mano o con soluciones parciales.

Un informe manual puede resolver una necesidad puntual. Una base de datos operacional puede sostener una aplicación. Un CRM puede gestionar actividad comercial. Un ERP puede registrar facturación. Etc. Pero ninguna de esas piezas, por sí sola, suele resolver bien el problema analítico completo de una empresa que empieza a crecer.

Una base operacional está pensada para que el negocio funcione: crear pedidos, registrar clientes, emitir facturas, actualizar stock, guardar transacciones, gestionar usuarios, procesar formularios. Su prioridad es operar.

Un sistema analítico tiene otra prioridad: permitir análisis, reporting, seguimiento, métricas, decisiones, histórico, comparación y consumo por diferentes áreas.

Confundir ambas cosas termina generando problemas….

• Se consulta directamente producción para hacer informes.
• Se rompen consultas porque cambia una aplicación.
• Se calculan métricas de negocio con campos pensados para otra cosa.
• Se fuerzan modelos operacionales para responder preguntas analíticas.
• Se montan dashboards sobre datos que nadie ha validado.

Y luego nos sorprendemos de que dirección no se fíe. No es que dirección sea caprichosa, es que muchas veces tiene motivos.

Si un número cambia según quién lo exporte, desde dónde lo mire o qué filtro recuerde aplicar, no es una métrica. Es una discusión pendiente.

Las señales de que tu empresa ya necesita ordenar datos

No hace falta esperar a tener millones de filas, cientos de empleados o un departamento formal de datos para necesitar una arquitectura mínima; a veces basta con observar los síntomas.

• Si cada área tiene su propia versión de ventas, hay un problema.
• Si finanzas, operaciones y comercial no calculan igual cliente activo, pedido válido, margen, conversión o recurrencia, hay un problema.
• Si los informes dependen de copiar y pegar datos entre Excel, hay un problema.
• Si hay ficheros sensibles circulando por email, hay un problema.
• Si nadie sabe qué procesos dependen de una hoja compartida, hay un problema.
• Si el dashboard existe pero nadie se lo cree, hay un problema.
• Si el equipo técnico no sabe qué tablas puede tocar y cuáles romperían procesos críticos, hay un problema.
• Si una persona se va de vacaciones y el reporting se queda cojo, hay un problema.
• Si se habla de IA antes de tener claras las métricas básicas, hay un problema.

Y no, el problema no se resuelve solo comprando una herramienta.

Una herramienta puede ayudar muchísimo cuando llega en el momento adecuado. Pero si llega antes del inventario, antes de las definiciones, antes del ownership y antes de entender los usos reales, se convierte en otra capa más del desorden.

Más moderna, más cara y con mejor interfaz. Pero desorden al fin y al cabo.

El primer movimiento no es migrar: es inventariar

Este punto parece aburrido, pero pese a que la palabra «documentar» parece crear alergia en la gran mayoría de gente, es uno de los pasos más importantes.

Antes de montar tu primer Data Warehouse necesitas hacer visible el sistema informal de datos que ya existe en la empresa.

Importante: No el sistema oficial que aparece en un organigrama o en una presentación. El real.

Este inventario no tiene que ser perfecto desde el primer día, pero sí o sí tiene que existir. Sin inventario no hay arquitectura, hay intuición.

Y la intuición puede servir para empezar una conversación, pero no para diseñar una plataforma que va a sostener reporting, analítica, automatización, auditoría y quizá futuros productos de IA.

Un inventario inicial debería responder, como mínimo, a estas preguntas:

• Qué fuentes de datos existen.
• Dónde están alojadas.
• Quién es responsable funcional de cada fuente.
• Quién tiene acceso técnico.
• Qué datos contienen.
• Qué procesos de negocio representan.
• Qué informes o dashboards dependen de ellas.
• Qué datos personales o sensibles incluyen.
• Con qué frecuencia cambian.
• Cómo se extraen actualmente.
• Qué calidad aparente tienen.
• Qué problemas conocidos existen.
• Qué pasaría si esa fuente falla, se duplica, se interpreta mal o se expone indebidamente.

No hace falta convertir esto en una burocracia infinita. De hecho, en una pyme sería absurdo empezar con un gobierno de datos sobredimensionado. Pero alguna disciplina mínima tiene que aparecer.

La alternativa es seguir construyendo sobre memoria tribal.

Qué vamos a cubrir en esta serie

Esta guía va a ir bajando desde el problema hasta la ejecución.

La primera parte será el diagnóstico: cómo detectar que tu empresa ya tiene un problema de datos, aunque todavía no lo llame así. Hablaremos de Excel, CRM, ERP, CMS, SaaS, bases operacionales, reporting manual, métricas contradictorias y dependencias invisibles.

La segunda parte entrará en arquitectura. Veremos qué estás montando realmente cuando hablas de Data Warehouse, qué diferencia hay con un Data Lake o un Lakehouse, qué piezas forman una arquitectura moderna y qué significa eso de “modern data stack” cuando lo bajas a una empresa real con presupuesto, equipo y restricciones.

La tercera parte será el roadmap. Cómo ejecutar sin parar la empresa. Cómo priorizar fuentes. Cómo elegir primeros casos de uso. Cómo diseñar una arquitectura mínima viable. Cómo construir el primer pipeline. Cómo validar métricas con negocio. Cómo publicar el primer consumo fiable. Cómo medir calidad. Cómo documentar. Cómo operar.

Y probablemente habrá una cuarta parte sobre equipo. Porque al principio puede haber una sola persona empujando todo, pero esa persona no puede ser eternamente data engineer, analista, responsable de BI, administrador de plataforma, soporte, product owner y gobierno de datos al mismo tiempo.

Lo que esta guía no va a hacer

Esta guía no va a decirte que la mejor opción es una plataforma concreta.

No existe “la mejor herramienta” en abstracto.

Hay herramientas que encajan mejor o peor según ecosistema cloud, volumen, tipos de fuente, presupuesto, capacidades del equipo, necesidades de BI, requisitos legales, complejidad de transformación, gobierno, seguridad y operación.

Una empresa muy metida en Azure y Power BI puede evaluar Microsoft Fabric con bastante naturalidad. Una empresa en Google Cloud probablemente tendrá BigQuery en la conversación. Una empresa que busca una plataforma cloud independiente del hyperscaler puede mirar Snowflake. Un contexto muy orientado a lakehouse, Spark, ML o datos semiestructurados puede llevar a Databricks. Un entorno AWS puede evaluar Redshift y el ecosistema asociado.

Pero esa conversación vendrá después… primero hay que entender el problema.

También conviene decir otra cosa: esta guía no va a vender humo de IA.

La IA puede tener sentido. Los asistentes internos pueden tener sentido. La automatización avanzada puede tener sentido. Los modelos predictivos pueden tener sentido.

Pero montar IA sobre datos que nadie entiende es una forma bastante sofisticada de producir basura con confianza.

Si no sabes qué significa cliente activo, pedido válido, margen neto, stock disponible, lead cualificado o baja voluntaria, quizá el siguiente paso no sea un agente de IA. Quizá el siguiente paso sea definir bien tus datos.

Por qué esto importa a dirección, no solo al equipo técnico

Montar un Data Warehouse se suele presentar como un proyecto técnico. Y sí, en parte lo es, pero reducirlo a tecnología es quedarse corto.

Dirección debería preocuparse por esto porque afecta a decisiones, costes, riesgos y velocidad operativa.

Si los datos no son fiables, las decisiones se discuten desde la base. Si cada área calcula distinto, la coordinación se degrada. Si el reporting es manual, el coste está oculto en horas de personas. Si los accesos no están controlados, hay riesgo de seguridad y privacidad. Si las métricas no tienen dueño, nadie responde cuando cambian. Si no hay trazabilidad, cada cierre mensual se convierte en arqueología.

Y si la empresa quiere crecer, automatizar o usar IA, necesita una base más sólida que un puñado de hojas compartidas y exportaciones manuales.

No se trata de montar una arquitectura perfecta desde el día uno. Se trata de montar una arquitectura que la empresa pueda entender, pagar, operar y evolucionar.

Eso es mucho más difícil que comprar software, y bastante más valioso.

La idea central

No estás montando una base de datos más: estás construyendo la forma en la que la empresa va a confiar en sus números.

Eso significa pasar de datos dispersos a datos integrados. De informes manuales a procesos trazables. De métricas discutidas a definiciones compartidas. De accesos improvisados a permisos pensados. De conocimiento tribal a documentación. De decisiones lentas a información disponible. De “creo que el dato está en este Excel” a “este es el modelo validado y este es su dueño”.

Ese camino no se recorre en una semana, ni hace falta tampoco resolverlo todo de golpe.

Hace falta empezar bien.

Significa entender qué existe, qué duele, qué importa, qué riesgo hay y qué primera arquitectura mínima puede convertir datos dispersos en una capacidad real de negocio.

Esa es la serie que voy a publicar.

La iré desarrollando por partes y, cuando esté completa, la convertiré en una guía técnica descargable en PDF para tener todo el contenido ordenado, revisado y ampliado.

Si este tema te toca de cerca —porque estás montando datos, porque te han dejado ese marrón encima de la mesa, porque diriges un equipo técnico o porque tu empresa ya no puede seguir decidiendo con números que nadie termina de creerse— puedes seguirme en LinkedIn o suscribirte al blog para recibir las siguientes partes.

La siguiente entrega bajará al primer problema real:

Antes del warehouse: cuando los datos ya mandan, pero nadie los gobierna.

Ahí empieza todo.

Fuentes consultadas

DAMA International — DAMA-DMBOK, Data Management Body of Knowledge
https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/

GOV.UK — The Government Data Quality Framework
https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework

European Data Protection Board — Guidelines 4/2019 on Article 25 Data Protection by Design and by Default
https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en

European Commission — What does data protection by design and by default mean?
https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/what-does-data-protection-design-and-default-mean_en

Snowflake Documentation — Key Concepts and Architecture
https://docs.snowflake.com/en/user-guide/intro-key-concepts

Google Cloud Documentation — BigQuery overview
https://docs.cloud.google.com/bigquery/docs/introduction

AWS Documentation — What is Amazon Redshift?
https://docs.aws.amazon.com/redshift/latest/dg/welcome.html

Microsoft Learn — Fabric Data Warehouse architecture
https://learn.microsoft.com/en-us/fabric/data-warehouse/architecture

dbt — What is analytics engineering?
https://www.getdbt.com/blog/what-is-analytics-engineering

Priebe, Neumaier, Markus — Finding Your Way Through the Jungle of Big Data Architectures
https://arxiv.org/abs/2201.04233