Infraestructura de datos en la mediana empresa española: un diagnóstico

Ocho empresas, ocho diagnósticos distintos con un patrón común

Las entrevistas revelan que los problemas de infraestructura de datos son predecibles, pero raramente se anticipan.

Entre febrero y mayo de 2024, el equipo editorial de Pulseobeta realizó entrevistas en profundidad con responsables de datos de ocho empresas medianas con sede en Madrid y Barcelona, con plantillas de entre cincuenta y trescientos empleados y facturaciones anuales de cinco a ochenta millones de euros. El objetivo no era construir un ranking de herramientas ni producir un informe de mercado: era documentar las decisiones reales, los arrepentimientos concretos y los aprendizajes transferibles de quienes ya han recorrido el camino de construir una infraestructura de datos desde cero o desde un estado caótico. El patrón más frecuente que emergió fue el siguiente: las empresas subestiman sistemáticamente el coste de integración de fuentes de datos heterogéneas y sobreestiman la velocidad a la que sus equipos no técnicos adoptarán herramientas de self-service BI. Las decisiones de compra de plataformas (Snowflake, Databricks, BigQuery, Redshift) se toman frecuentemente a partir de benchmarks de rendimiento sin modelar el coste operativo real a doce meses, que incluye formación, mantenimiento de pipelines y deuda técnica acumulada en las transformaciones de datos.

Lo que recomendarían si empezaran de nuevo

Cinco principios extraídos de las entrevistas que los equipos desearían haber conocido antes.

De las ocho entrevistas emergieron cinco recomendaciones que aparecieron de forma independiente en al menos cuatro conversaciones distintas. Primera: modelar el dominio de negocio antes de elegir cualquier herramienta. Las empresas que invirtieron dos o tres semanas en documentar sus entidades de negocio y sus relaciones antes de configurar su data warehouse cometieron menos errores de esquema que las que comenzaron con la herramienta y adaptaron el modelo sobre la marcha. Segunda: tratar la calidad de datos como un producto, no como una tarea de mantenimiento. Tres de las ocho empresas tienen ahora un rol dedicado a data quality; las cinco que no lo tienen señalan la calidad de datos como su principal fuente de fricción operativa. Tercera: no implementar dbt hasta que el equipo tenga al menos un perfil con experiencia en modelado relacional. Cuarta: preferir conectores gestionados (Fivetran, Airbyte Cloud) sobre pipelines custom para fuentes estándar, incluso si el coste mensual parece elevado: el coste de mantenimiento de pipelines propietarios supera ese gasto en todos los casos documentados. Quinta: definir un SLA explícito de frescura de datos para cada dataset antes de ponerlo en producción, porque sin ese contrato los consumidores internos asumen siempre que los datos son más recientes de lo que son.