Data warehouse: qué es, cuándo hace falta y qué cuesta mantenerlo

Un data warehouse es una base de datos pensada para responder preguntas de negocio, no para que funcione una aplicación. Esa es toda la definición, y explica casi todo lo demás: por qué es distinto de tu ERP, por qué una empresa mediana puede pasar años sin necesitarlo y por qué, cuando llega el momento, montarlo mal sale más caro que no montarlo. En esta guía va lo que preguntan de verdad las direcciones que nos llaman: qué es, cómo saber si hace falta ya, qué alternativas más baratas existen y cuánto cuesta el mantenimiento que nadie presupuesta.

Vaya por delante una advertencia útil: el almacén de datos es la respuesta correcta a un problema muy concreto, y la respuesta equivocada a muchos otros. Hemos visto empresas gastar seis cifras en una plataforma para acabar exportando a Excel igual que antes, porque el problema nunca fue dónde vivía el dato, sino que nadie se había puesto de acuerdo en qué significaba «cliente activo».

¿Qué es un data warehouse y en qué se diferencia de tu ERP?

Tu ERP, tu CRM y tu plataforma de comercio electrónico son sistemas transaccionales. Están optimizados para escribir muchas operaciones pequeñas muy rápido: grabar un pedido, actualizar un stock, registrar un cobro. Su modelo de datos está normalizado y repartido en cientos de tablas, porque así la aplicación funciona bien.

Un data warehouse es un sistema analítico. Está optimizado para lo contrario: leer millones de filas de golpe y agregarlas por producto, cliente, mes o comercial. Su modelo está desnormalizado a propósito —tablas de hechos y dimensiones— para que una pregunta de negocio se responda en una consulta y no en un rompecabezas de quince uniones.

Tres consecuencias prácticas de esa diferencia:

• Guarda historia. El ERP suele sobrescribir el estado actual: si un cliente cambia de tarifa, la tarifa antigua desaparece. El almacén guarda la foto de cada día, y sin esa foto no hay serie histórica ni previsión de demanda que valga.
• Cruza fuentes. Une las ventas del ERP con el pipeline del CRM y el gasto publicitario, cosa que ningún sistema origen hace por ti.
• No molesta a la operación. Una consulta pesada sobre el histórico completo no puede tumbar el sistema con el que factura el equipo cada mañana.

Si tus informes siguen saliendo del ERP y nadie se queja, no necesitas un almacén de datos todavía. Necesitarlo es algo que se nota, no algo que se decide en una presentación de un proveedor.

¿En qué se diferencia de un data lake y de un lakehouse?

Los tres nombres se usan como sinónimos en las demos comerciales, y no lo son. La diferencia real está en cuándo se impone la estructura al dato:

| Tipo | Qué guarda | Estructura | Encaja cuando | |---|---|---|---| | Data warehouse | Datos ya limpios y modelados | Al escribir | El 95% del dato útil es tabular: ventas, compras, stock, cobros | | Data lake | Ficheros en bruto de cualquier formato | Al leer | Hay imágenes, audio, logs o volúmenes muy grandes sin modelar | | Lakehouse | Ficheros en bruto con capa de tablas encima | Mixta | Quieres las dos cosas y tienes quien lo mantenga | | Data mart | Un recorte del almacén para un área | Al escribir | Finanzas o comercial necesitan su vista sin tocar el resto |

Para la inmensa mayoría de empresas medianas españolas, el dato que mueve decisiones es tabular y cabe de sobra en un almacén convencional. El data lake se justifica cuando entra en juego dato no estructurado —documentos, imágenes de control de calidad, grabaciones— o cuando el volumen hace inviable modelarlo todo por adelantado. Si alguien te propone un lakehouse para 40 GB de facturas, está vendiendo arquitectura, no resolviendo tu problema.

¿Cuándo necesita un data warehouse una empresa mediana?

Estas son las seis señales que usamos nosotros. No hacen falta las seis; con tres, la conversación ya es seria.

• Cruzas fuentes a mano cada mes. Alguien descarga del ERP, descarga del CRM, pega en una hoja y cruza con un BUSCARV. Si eso pasa todos los meses, ya tienes un almacén de datos: vive en un portátil y no tiene copia de seguridad.
• Necesitas historia que el sistema no guarda. Quieres saber cuántos clientes tenías en tarifa premium en marzo del año pasado y no hay forma de reconstruirlo.
• Las consultas pesadas ralentizan la operación. El informe trimestral hay que lanzarlo de noche porque de día deja el ERP inservible.
• Dos áreas dan cifras distintas de lo mismo. Síntoma clásico. Ojo: esto casi nunca se arregla con tecnología. Se arregla definiendo métricas y poniéndoles dueño, que es gobierno del dato. El almacén sirve para que la definición acordada viva en un solo sitio, no para inventarla.
• Cada nuevo informe cuesta semanas. Porque se empieza de cero desde los sistemas origen cada vez, en lugar de partir de tablas ya preparadas.
• Quieres modelos en producción. Un modelo de previsión o de scoring necesita datos con la misma forma todos los días. Sin una capa estable debajo, lo que tienes es una maqueta que funciona en el portátil de alguien. Lo contamos entero en ingeniería de datos.

Y la señal inversa, igual de importante: si toda la información relevante vive en un único sistema, los informes nativos te bastan y nadie pasa horas montando hojas, no lo necesitas. Montarlo «para estar preparados» es la forma más común de pagar mantenimiento durante tres años por algo que nadie consulta.

¿Qué alternativas hay más baratas antes de montar uno?

Casi siempre hay un escalón intermedio que resuelve el 80% del dolor por una fracción del coste. Por orden de menos a más:

| Alternativa | Qué resuelve | Dónde se rompe | |---|---|---| | Informes nativos del ERP/CRM | Preguntas de un solo sistema | En cuanto hay que cruzar dos fuentes | | Réplica de lectura del ERP | Consultas pesadas sin tocar producción | No guarda historia ni cruza fuentes | | Base de datos pequeña con dos o tres cargas | Cruce de ventas y CRM, historia básica | Al crecer sin modelo ni pruebas se vuelve un pozo | | Herramienta de BI con modelo propio | Cuadros de mando rápidos para un área | La lógica queda atrapada dentro del producto | | Data warehouse completo | Fuente de verdad multiárea, historia, modelos | Exige mantenimiento y alguien que responda de él |

La opción de la base de datos pequeña con cargas programadas es la más infravalorada. Con un almacén gestionado en la nube, tres procesos de carga nocturnos y un modelo de cinco tablas se cubre lo que la mayoría de comités necesita, y el coste de infraestructura para volúmenes de empresa mediana es del orden de decenas de euros al mes, no de miles. Lo caro nunca es el almacenamiento: es el trabajo de acordar definiciones, construir las cargas y mantenerlas vivas.

Si lo que buscas es sobre todo visualización, empieza por ahí y no por la plataforma: el criterio de elección está en herramientas de business intelligence.

¿Cuánto cuesta montarlo y, sobre todo, mantenerlo?

Tres partidas. La tercera es la que hunde proyectos porque no aparece en la propuesta inicial.

Construcción. Ingesta de los sistemas origen, modelo analítico y primeras tablas de servicio para un dominio acotado —ventas, normalmente—: semanas de trabajo, no meses, si el alcance está cerrado. Cuando se propone «integrar todo», el proyecto se mide en trimestres y el riesgo se multiplica.

Infraestructura. Almacenamiento y cómputo. Para volúmenes de empresa mediana suele ser la partida más pequeña y la que más miedo da por desconocimiento. El gasto se dispara por consultas mal hechas y cargas completas innecesarias, no por el tamaño del dato.

Mantenimiento. Aquí va el dinero de verdad. El ERP se actualiza y cambia un campo. El negocio abre una línea nueva. Aparece una filial con su propio maestro de clientes. Alguien pide una métrica que obliga a tocar el modelo. Como regla de trabajo, presupuesta cada año en torno a un 15-25% de lo que costó construirlo, solo para que siga siendo cierto lo que cuenta. Un almacén sin mantenimiento no se rompe de golpe: se va degradando hasta que la gente vuelve a fiarse de su Excel. La lógica completa de cómo se presupuesta esto está en qué cuesta un proyecto de IA.

Y una pregunta que le hacemos a todo proveedor, nosotros incluidos: cuando terminéis, ¿quién puede tocar esto sin vosotros?. Si la respuesta implica dependencia permanente, el precio real no es el del presupuesto.

¿Cómo se monta sin abrir un proyecto de un año?

La secuencia que funciona, y el orden importa más que las herramientas:

1. Elige una decisión, no un sistema. «Saber cada lunes el margen por línea de producto» es un alcance. «Integrar el ERP» no lo es. 2. Acuerda las definiciones antes de tocar nada. Qué es un pedido válido, cómo se tratan devoluciones y abonos, qué fecha manda. Escrito y firmado por quien responde del número. 3. Monta la capa en bruto primero. Copia del origen tal como llegó, con fecha de carga. Es lo que te permite recalcular el pasado cuando descubras un error de criterio, y ocupa mucho menos de lo que la gente teme. 4. Modela solo lo que esa decisión necesita. Una tabla de hechos, tres o cuatro dimensiones. Resistir la tentación de modelar el negocio entero es la mitad del trabajo. 5. Pon la transformación en código versionado. Si la lógica vive en clics dentro de una herramienta, cambiar de herramienta cuesta el doble y saber qué tocó alguien el martes es imposible. 6. Añade tres pruebas y una alerta. Unicidad de la clave, rango de importes y frescura. La alerta, a un canal donde alguien la vea. 7. Conecta el cuadro de mando al final y apaga el informe manual. Si el proceso antiguo sigue vivo, no has terminado: has añadido trabajo. Cómo diseñar ese cuadro de mando está en cuadro de mando integral.

En seis a ocho semanas eso está en producción para un dominio. Lo más valioso no suele ser el resultado, sino lo que se aprende por el camino sobre el estado real de los sistemas, que casi nunca coincide con el inventario oficial.

Preguntas frecuentes

¿Data warehouse en la nube o en servidor propio?

Para la mayoría de empresas medianas, en la nube. El coste inicial es cero, el crecimiento es elástico y no hay que dimensionar hardware a ciegas. El servidor propio se justifica cuando hay requisitos legales de ubicación del dato o cuando ya existe infraestructura amortizada y equipo que la opera.

¿Necesito un data warehouse para hacer BI?

No siempre. Para cuadros de mando de un solo sistema, la herramienta de BI conectada directamente puede bastar. El almacén se vuelve necesario cuando hay que cruzar fuentes, conservar historia o dar la misma cifra a varias áreas. La diferencia entre las dos capas está en qué es business intelligence.

¿Cuánto tarda en verse el retorno?

El retorno inmediato es tiempo recuperado: las horas que alguien dedicaba a montar informes a mano, medibles en la primera o segunda semana tras el corte. El retorno de decidir mejor tarda más y es más difícil de atribuir, pero el primero ya suele pagar la construcción de un dominio.

¿Y si mis datos están sucios?

Es la situación normal, no la excepción. El almacén no limpia nada por sí solo: hace visible la suciedad, que ya es un avance. La limpieza se ataca por prioridad —primero los campos que alimentan la decisión elegida— y se sostiene con reglas automáticas en cada carga, no con una limpieza heroica de una vez. El plan de por dónde empezar está en estrategia de datos.

Si has reconocido tres o cuatro señales de las de arriba, el siguiente paso no es pedir presupuestos de plataforma: es acotar una decisión concreta y ver qué falta para alimentarla. Eso es exactamente lo que hacemos en la auditoría —dos semanas, sistemas reales, mapa de lo que hay y de lo que falta— y si prefieres contrastarlo antes en una conversación sin compromiso, hablemos.