Migrar a la nube no es tener una estrategia de datos

Por qué mover tus datos a Databricks, Snowflake o cualquier nube no resuelve las preguntas de negocio, y qué capa falta después de migrar

Tu empresa migró a la nube hace un año. ¿Alguien puede decirte hoy, sin abrir un Excel paralelo, cuál fue tu cliente más rentable el mes pasado?

Si la respuesta es no, el problema no es la nube. Es que se confundieron dos decisiones que parecen una sola pero no lo son: dónde viven y se procesan tus datos, y qué significan esos datos para tu negocio.

Un artículo reciente de dbt Labs lo resume con precisión: “tu plataforma de cómputo y tu lógica de transformación son dos decisiones separadas. La mayoría de los ejecutivos las aprueba como una sola”. Esa frase describe exactamente lo que vemos en empresas medianas que migraron a Databricks, Snowflake o cualquier nube esperando que la migración por sí sola resolviera sus preguntas de negocio — y un año después siguen resolviendo esas preguntas en un Excel aparte.

Las dos decisiones que se están confundiendo

Decisión uno: dónde viven y se procesan los datos. Esto es infraestructura — capacidad de cómputo, almacenamiento, velocidad de procesamiento, seguridad, cumplimiento normativo. Es un problema real y hay proveedores excelentes resolviéndolo: Databricks, Snowflake, BigQuery, y en el mundo open source, combinaciones como DuckDB o ClickHouse sobre almacenamiento en la nube. Esta decisión se resuelve con un contrato, una arquitectura técnica y una factura mensual.

Decisión dos: qué significan esos datos para el negocio. Esto es semántica de negocio — qué es exactamente un “cliente activo” (¿compró en los últimos 30 días? ¿90? ¿tiene una suscripción vigente?), cómo se calcula el margen real de un producto (¿incluye costos logísticos? ¿comisiones?), qué reporte es la fuente de verdad cuando ventas y finanzas dan números distintos del mismo mes. Nadie vende esto empaquetado con la plataforma de nube. Se construye — o no se construye, y ahí empieza el problema.

La confusión no es exclusiva de PYMEs sin equipo técnico. Ocurre en empresas con presupuestos grandes y equipos de ingeniería sólidos, porque la venta de las plataformas de nube está diseñada para sonar como si resolviera todo: “sube tus datos acá y vas a poder responder cualquier pregunta”. Técnicamente es cierto — la plataforma puede ejecutar cualquier consulta. Lo que no resuelve es qué consulta es la correcta, ni qué significan sus resultados.

Cómo se ve en la práctica

Imaginemos una empresa mediana — digamos, una distribuidora con 150 empleados — que migró su ERP y sus datos de ventas a la nube hace un año. La migración salió bien: los datos están ahí, accesibles, con dashboards conectados. Pero pasan estas cosas, todas al mismo tiempo:

• El equipo comercial calcula “ventas del mes” sumando pedidos facturados. El equipo de finanzas calcula “ventas del mes” sumando pedidos cobrados. Ninguno está mal — están midiendo cosas distintas con el mismo nombre.
• Un gerente pide “el top 10 de clientes más rentables” y recibe tres respuestas distintas de tres personas distintas, porque cada una define “rentable” de forma distinta (margen bruto, margen neto, margen después de logística).
• El dashboard de la nube muestra números en tiempo real, pero nadie confía del todo en ellos, así que se sigue manteniendo un Excel “de respaldo” que en la práctica es el que realmente se usa para decidir.

Ninguno de estos problemas se resuelve con más capacidad de cómputo, ni con una plataforma más moderna. Se resuelven definiendo, una sola vez, en un solo lugar, qué significa cada métrica de negocio — y haciendo que todos los reportes de la empresa consulten esa misma definición en vez de recalcularla cada uno a su manera.

Cómputo vs. semántica: la tabla que aclara la diferencia

	Plataforma de cómputo (nube)	Capa semántica (definición de negocio)
Qué resuelve	Dónde se procesan y almacenan los datos	Qué significan los datos para la empresa
Quién la vende	Databricks, Snowflake, AWS, GCP, Azure, y proveedores open source	Nadie la vende empaquetada — se construye a medida
Cómo se mide si funciona	Velocidad, uptime, costo de cómputo	Si dos áreas distintas obtienen el mismo número para la misma pregunta
Qué pasa si falta	La empresa no puede procesar volumen o velocidad de datos	La empresa tiene datos rápidos pero sigue sin poder confiar en ellos
Con qué se confunde	”Ya migramos, ya tenemos estrategia de datos”	Documentación técnica que nadie del negocio revisa

La columna de la izquierda es la que casi siempre se prioriza primero, porque es la que un proveedor puede vender con un caso de negocio claro (“reduce tu costo de infraestructura 30%”). La columna de la derecha rara vez tiene un vendedor empujándola — y sin embargo es la que determina si la inversión en la nube realmente cambia cómo opera la empresa.

¿Cuándo aplica esto y cuándo no?

Aplica directamente si tu empresa ya migró a la nube (o está por hacerlo) y las preguntas de negocio siguen sin respuesta clara — si distintas áreas reportan números distintos para lo mismo, si los reportes tardan más en revisarse y corregirse que en generarse, o si el “Excel de respaldo” sigue siendo el que de verdad se usa para decidir.

No aplica, al menos no como prioridad inmediata, si tu empresa todavía no tiene los datos centralizados en ningún lado — en ese caso, la decisión de plataforma de cómputo sigue siendo la primera que hay que resolver, porque no se puede construir una capa semántica sobre datos que viven repartidos en quince hojas de cálculo sin conexión entre sí. El orden importa: primero centralizar, después dar significado.

También hay un tercer escenario, más simple de lo que parece: empresas chicas con pocas métricas de negocio, donde una hoja de cálculo bien mantenida y con definiciones claras (documentadas, aunque sea en un párrafo) puede ser suficiente por ahora. La capa semántica no siempre requiere una herramienta — a veces requiere solamente que alguien escriba, una vez, qué significa cada número y por qué se calcula así.

Cómo se empieza a construir la capa semántica

Si después de leer hasta acá reconoces que tu empresa tiene la infraestructura pero no la capa de significado, hay una forma de empezar sin contratar una plataforma nueva ni parar la operación.

Primero, identificar las 5-10 métricas que realmente mueven decisiones. No hace falta documentar cada dato de la empresa — alcanza con las métricas que aparecen en reuniones de directorio o de gerencia: ventas del mes, margen por producto, clientes activos, costo de adquisición, lo que sea que se use para decidir. En la mayoría de las empresas de 50 a 500 empleados esa lista tiene menos de 15 métricas, aunque se sienta como si fueran cientos.

Segundo, para cada métrica, escribir la definición exacta en una sola frase que cualquiera del negocio entienda. No una fórmula técnica en un notebook que solo lee ingeniería — una frase clara: “cliente activo es quien compró en los últimos 90 días”, “margen neto es precio de venta menos costo de producto menos costo logístico”. Esto suena obvio hasta que se hace el ejercicio y aparecen tres versiones distintas de la misma definición flotando en la empresa.

Tercero, hacer que todos los reportes que usan esa métrica consulten la misma definición, no que cada uno la recalcule. Acá es donde entra la tecnología — una capa de métricas centralizada, un modelo en dbt, o incluso una tabla intermedia bien documentada — pero solo después de que la definición de negocio ya está acordada. Meter la herramienta antes de acordar la definición es repetir el mismo error de origen: resolver la parte técnica antes que la de negocio.

Este orden no requiere un equipo de datos grande ni meses de proyecto. Requiere que alguien del negocio — no solo de tecnología — se siente a definir, por escrito, qué significa cada número que la empresa usa para decidir.

El takeaway de esta semana

Antes de evaluar la próxima inversión en infraestructura de datos, hazte una pregunta distinta a la que probablemente te está haciendo tu proveedor de nube: si dos personas de tu empresa calculan la misma métrica hoy mismo, ¿les da el mismo número? Si la respuesta es no, el problema no se resuelve con más cómputo — se resuelve escribiendo, en un solo lugar, qué significa cada dato que importa para decidir.

Preguntas frecuentes

¿Necesito contratar una herramienta especial para la capa semántica?

No necesariamente al principio. Existen herramientas específicas para esto (dbt, capas de métricas, catálogos de datos), pero el primer paso real es documentar las definiciones de negocio en un lugar accesible para todos — la herramienta ayuda a mantener eso consistente a escala, no reemplaza la decisión de negocio en sí.

¿Esto aplica solo a empresas que ya migraron a la nube?

Aplica sobre todo a esas, porque son las que ya gastaron el presupuesto de infraestructura y todavía no ven el resultado de negocio que esperaban. Pero el principio — separar “dónde viven los datos” de “qué significan los datos” — aplica desde el día uno de cualquier proyecto de datos, migrado o no.

¿Cómo sé si mi empresa tiene este problema?

La señal más clara: si le pides el mismo número (ventas del mes, clientes activos, margen) a dos personas de áreas distintas y obtienes respuestas diferentes, sin que ninguna esté “mal” técnicamente, tienes exactamente este problema.

¿Cuánto tiempo toma resolver la capa semántica?

Depende del número de métricas críticas del negocio, pero para las 5-10 métricas que realmente mueven decisiones, alcanza con semanas de trabajo enfocado — no es un proyecto de meses si se acota bien desde el principio.

---

¿Quieres profundizar en cómo identificar si tu infraestructura de datos actual tiene esta brecha? También puedes revisar nuestro artículo sobre vendor lock-in vs. stack abierto para entender qué preguntas hacerle a cualquier proveedor de nube antes de comprometerte con una plataforma.