Hace unos días, hablando con varios CIOs, me di cuenta de que casi todos compartían el mismo entusiasmo.

“Con la IA ahora podemos desarrollar nuestras propias aplicaciones.”

Y tienen razón. Nunca había sido tan sencillo convertir una idea en una aplicación funcional. Lo que hace apenas dos años requería meses de trabajo y un equipo de desarrollo, hoy puede estar funcionando en cuestión de días gracias a herramientas como Claude, Cursor, Copilot o ChatGPT. Hasta aquí, todo bien.

Mientras les escuchaba, me vino a la cabeza una conversación que creo que muchos CIOs tendrán dentro de un año. No será con su equipo ni con el proveedor de turno. Será con el CEO.

Llegarán con una aplicación funcionando, usuarios satisfechos y la sensación de haber tomado una buena decisión. Al fin y al cabo, han dejado de pagar una licencia anual y han demostrado que, gracias a la IA, son capaces de desarrollar internamente aquello que antes compraban fuera.

Y ahí empezará la verdadera conversación.

Porque, una vez que la aplicación entra en producción, empieza una etapa de la que casi nadie habla cuando se hace el business case. Aparecen las incidencias, cambian las necesidades del negocio, evolucionan las integraciones, se publican nuevas versiones de las librerías, se consumen tokens, hay costes de infraestructura y, casi sin darse cuenta, el equipo deja de dedicar tiempo a construir para empezar a dedicarlo a mantener.

Y es entonces cuando el ahorro inicial empieza a diluirse.

No porque la IA haya dejado de ser útil. Al contrario. La IA habrá cumplido exactamente lo que prometía: reducir de forma drástica el coste de desarrollar software. Lo que ocurre es que el desarrollo solo representa una parte del problema. La otra, la que acompaña a cualquier aplicación durante toda su vida útil, sigue estando ahí.

Durante años hemos pensado que una licencia SaaS era cara. En realidad, muchas veces era sorprendentemente barata. No porque desarrollar ese software costara poco, sino porque el coste de mantenerlo se repartía entre cientos o miles de clientes.

Esa es la gran ventaja de la economía de escala. Un proveedor desarrolla una funcionalidad una vez, corrige un error una vez, adapta una integración una vez… y ese esfuerzo beneficia a todos sus clientes.

Cuando una empresa decide desarrollar esa misma aplicación para uso interno, esa economía de escala desaparece.

A partir de ese momento, cada incidencia, cada nueva funcionalidad, cada actualización de seguridad y cada cambio solicitado por el negocio recaen sobre un único departamento de IT.

Y ese es el coste que rara vez aparece en la hoja de cálculo cuando se decide desarrollar una aplicación en lugar de comprarla.

No creo que esto sea un argumento para dejar de utilizar IA. Sería absurdo. Estamos viviendo el mayor salto en productividad del desarrollo de software que hemos visto en décadas y las empresas que sepan aprovecharlo tendrán una ventaja competitiva enorme.

Lo que sí creo es que, antes de sustituir una licencia SaaS por una aplicación desarrollada internamente, merece la pena hacerse una pregunta más importante que “¿podemos construirla?”.

La pregunta es:

¿Queremos mantenerla durante los próximos diez años?

Porque sospecho que, dentro de no mucho, muchos CIOs volverán al despacho del CEO.

• ¿Recuerdas aquella aplicación que desarrollamos con IA?
  • Claro.
• Necesitamos contratar dos personas más.

No porque el proyecto haya salido mal. Precisamente porque ha salido bien. Porque ahora forma parte del negocio. Y alguien tiene que mantenerlo. Ese día muchas empresas descubrirán que el coste del software nunca desapareció.

Simplemente cambió de sitio.

No tener esa herramienta tiene un coste real, aunque sea difícil de cuantificar.

Los cierres de mes se alargan porque los datos no cuadran y nadie sabe cuál es la versión correcta de los criterios. Los proyectos de IA se retrasan porque los modelos necesitan datos limpios y bien definidos que no existen como tal. Las iniciativas de analítica avanzada se apoyan en definiciones que cada área interpreta de forma distinta. Y el equipo de datos dedica una parte significativa de su tiempo a responder preguntas que deberían tener respuesta en un sistema, no en una conversación.

El vacío en el stack no es un problema técnico. Es un problema de gobierno. Y el gobierno del dato no puede vivir en Excel

Qué debería existir

Una herramienta construida específicamente para gestionar datos contextuales debería permitir:

• Definir datos maestros con estructura, tipos y validaciones
• Asignar propietarios a cada dato y a cada campo
• Versionar los cambios con auditoría completa
• Aprobar cambios con flujos de revisión
• Sincronizar automáticamente con el data warehouse
• Ser accesible para el equipo de datos sin fricción técnica

Eso es lo que debería existir en el stack. No como un proyecto de consultoría de seis meses. No como una implementación enterprise con un coste de seis cifras. Como una herramienta operativa que cualquier equipo de datos pueda usar desde el primer día.

El vacío existe. Ya era hora de llenarlo.

Hay una conversación que se repite en casi todos los equipos de datos que conocemos. Alguien del negocio pregunta por un dato. El equipo de datos lo busca en el warehouse, no encuentra el contexto que necesita para responder con seguridad, y acaba preguntando a la persona que lleva más tiempo en la empresa. Esa persona abre un Excel.

No es un fallo del equipo. Es el síntoma de un problema estructural que nadie ha resuelto todavía.

El equipo de datos no elige Excel

Cuando alguien de fuera del mundo de los datos imagina a un Data Engineer o un Data Manager, probablemente no los imagina trabajando en Excel. Los imagina con SQL, con Python, con dashboards en Looker o con pipelines en dbt. Y en su mayor parte, así es.

Pero hay una categoría de información que no cabe en ninguna de esas herramientas. Y esa información acaba, inevitablemente, en una hoja de cálculo.

No porque el equipo no sepa hacer las cosas de otra forma. Sino porque no existe otra herramienta específica para hacerlo.

Qué es lo que no cabe en el warehouse

El data warehouse es extraordinariamente bueno para almacenar y procesar datos transaccionales a escala. Millones de filas de ventas, clics, eventos, transacciones. Todo eso vive perfectamente en BigQuery o Snowflake.

Lo que no vive bien ahí es el contexto de esos datos.

¿Qué es un cliente activo según el criterio de negocio actual? ¿Qué valores son válidos para el campo tipo_canal? ¿Cuándo se decidió que los clientes con más de 180 días sin comprar pasaban a la categoría de inactivos, y quién lo decidió? ¿Qué excepción aplica a los clientes del segmento corporativo?

Esas preguntas tienen respuesta. Pero esa respuesta no está en una tabla de BigQuery. Está en la memoria de alguien, en un email de hace dos años, en una reunión cuyas notas nadie guardó bien, o — con suerte — en un Excel que alguien creó para intentar centralizar todo eso.

El Excel como solución de emergencia permanente

El problema con usar Excel para esto no es Excel en sí. Excel es una herramienta brillante para lo que fue diseñada.

El problema es que Excel no fue diseñado para gobernar datos maestros en equipo. Y cuando lo usas para eso, aparecen los síntomas conocidos:

Versiones múltiples. El Excel de clientes tiene cuatro versiones en cuatro carpetas distintas. Nadie sabe cuál es la definitiva. Cuando hay discrepancias en un informe, la primera pregunta es siempre “¿qué versión estabas usando?”.

Sin propietario claro. ¿Quién es responsable de mantener ese Excel actualizado? En teoría, todos. En la práctica, nadie. Hasta que hay un problema.

Sin validación. Cualquier persona con acceso puede escribir cualquier cosa en cualquier celda. No hay reglas. No hay alertas. No hay forma de saber si el dato que acaban de introducir es correcto.

Sin auditoría. ¿Quién cambió ese valor y cuándo? Excel no lo sabe. Si alguien modificó un criterio de clasificación el mes pasado, no hay registro de ello a menos que alguien lo haya documentado manualmente.

Sin sincronización. El Excel vive desconectado del warehouse. Cuando algo cambia en el Excel, alguien tiene que acordarse de actualizarlo también en el sistema. A veces lo hace. A veces no.

Por qué el equipo lo sigue usando

Con todo eso, ¿por qué el equipo de datos sigue usando Excel para gestionar el contexto?

La respuesta es simple: porque no tiene otra opción.

No hay una herramienta específica para gestionar datos contextuales de la forma en que se gestionan los datos transaccionales. Los catálogos de datos existen, pero tienen una implementación compleja y están pensados para el inventario, no para la gestión activa. Las wikis y documentos son estáticos. Los sistemas de MDM tradicionales son proyectos de consultoría de meses con costes que solo tienen sentido para organizaciones enterprise con equipos dedicados.

Para un equipo de datos de tamaño medio que necesita gobernar sus datos maestros hoy, Excel es literalmente la única opción accesible.

El coste que nadie calcula

El coste de este problema raramente aparece en un informe de gestión. No tiene una línea en el presupuesto. Pero existe.

Cada vez que un analista dedica dos horas a reconciliar versiones distintas de los mismos datos, ese tiempo tiene un coste. Cada vez que un cierre de mes se alarga porque los datos no cuadran y nadie sabe cuál es la fuente correcta, ese retraso tiene un coste. Cada vez que un proyecto de IA se para porque los datos de entrenamiento no están bien definidos y validados, esa paralización tiene un coste.

Y más allá del tiempo, hay un coste de confianza. Cuando el negocio no puede confiar en los datos que le da el equipo de datos — no porque el equipo haga mal su trabajo, sino porque el contexto de esos datos vive en sistemas informales y no gobernados — la relación entre datos y decisión se deteriora.

Qué cambiaría si existiera la herramienta correcta

Imagina que el catálogo de clientes no vive en un Excel compartido en Teams sino en un sistema con las siguientes características:

Cada campo tiene un tipo, una validación y un propietario asignado. Si alguien introduce un valor que no cumple las reglas, el sistema lo rechaza antes de guardar. Cuando alguien propone un cambio en los criterios de clasificación, hay un flujo de revisión — el cambio queda en borrador hasta que el responsable lo aprueba. Cada aprobación queda registrada con fecha, usuario y versión. Y cuando los datos se aprueban, se sincronizan automáticamente con BigQuery o Snowflake.

El cierre de mes ya no empieza con “¿qué versión del Excel estábamos usando?” porque hay una sola versión, aprobada, con historial completo.

Eso no es ciencia ficción. Es lo que debería haber existido hace tiempo.

El equipo de datos merece mejores herramientas

El equipo de datos no usa Excel porque quiere. Lo usa porque no tiene otra cosa.

Durante años, la industria ha invertido masivamente en hacer más potente la capa analítica — warehouses más rápidos, pipelines más robustos, visualizaciones más sofisticadas. Y todo eso es valioso.

Pero la capa de gobierno — el contexto que hace que la analítica tenga sentido — ha quedado relegada a hojas de cálculo y documentos informales. Y esa capa es la base de todo. Sin datos bien gobernados, la analítica miente. Sin datos bien contextualizados, la IA alucina.

Es hora de que el equipo de datos tenga una herramienta específica para gobernar lo que más importa: el conocimiento que rodea a los datos.

“La pregunta no es si tu equipo necesita una herramienta mejor para esto. La pregunta es cuánto tiempo más puede permitirse no tenerla”

Después de comprender qué es un Data Warehouse y los desafíos que implica construir uno desde cero, muchas empresas llegan a una conclusión similar: el mayor esfuerzo de estos proyectos no está en analizar datos, sino en construir la infraestructura necesaria para que ese análisis sea posible.
Integrar sistemas, desarrollar pipelines de datos, diseñar modelos analíticos, gestionar la calidad de la información y mantener la plataforma operativa requiere una inversión considerable de tiempo y recursos.
En muchos proyectos, la mayor parte del esfuerzo se destina a resolver problemas técnicos relacionados con la arquitectura de datos, mientras que el análisis de negocio —que era el objetivo original— queda en segundo plano.
Este fenómeno ha llevado a muchas organizaciones a replantearse cómo construyen sus plataformas de datos.
En lugar de desarrollar cada componente desde cero, cada vez más empresas están adoptando un enfoque distinto: plataformas de datos aceleradas.

De proyectos artesanales a plataformas reutilizables

Durante muchos años, los proyectos de Data Warehouse se abordaban como desarrollos completamente personalizados. Cada empresa diseñaba su propia arquitectura, desarrollaba sus integraciones y construía sus modelos de datos desde cero.
Este enfoque ofrecía flexibilidad, pero también generaba proyectos largos y complejos.
Con el tiempo, muchas organizaciones empezaron a observar que gran parte del trabajo que realizaban en estos proyectos se repetía una y otra vez. Integraciones similares, modelos de negocio comparables y arquitecturas que compartían principios comunes.
A partir de esta experiencia comenzó a surgir una nueva forma de abordar estos proyectos: construir plataformas reutilizables que ya incorporan una parte importante de esa infraestructura.
En lugar de empezar desde una hoja en blanco, las empresas pueden partir de una base ya preparada.

Qué es una plataforma de datos acelerada

Una plataforma de datos acelerada es una infraestructura que ya incorpora componentes fundamentales para la construcción de una plataforma analítica.
En lugar de desarrollar cada elemento individualmente, estas soluciones incluyen elementos que normalmente forman parte de cualquier arquitectura de datos moderna.
Entre ellos suelen encontrarse:

• arquitectura de datos preparada para entornos cloud
• pipelines de ingestión y transformación de datos
• modelos de datos orientados al análisis empresarial
• integraciones con sistemas comunes
• estructuras optimizadas para herramientas analíticas

El objetivo no es eliminar la personalización, sino reducir el trabajo repetitivo que aparece en casi todos los proyectos de datos.

Reducir la fricción para llegar antes al valor

Cuando una empresa parte de una plataforma acelerada, gran parte de la infraestructura ya está preparada.
Esto significa que el proyecto puede avanzar más rápidamente hacia las fases que realmente generan valor para el negocio: el análisis, la interpretación de datos y la toma de decisiones.
En lugar de dedicar meses a construir pipelines básicos o definir estructuras comunes, los equipos pueden concentrarse en adaptar la plataforma a las necesidades específicas de la organización.
Este cambio de enfoque reduce significativamente el tiempo necesario para construir una plataforma de datos funcional.

La importancia de las integraciones prefabricadas

Uno de los aspectos que más trabajo genera en los proyectos de datos es la integración de sistemas.
Cada ERP, CRM o aplicación operativa tiene su propia estructura de datos, su propia lógica y sus propias formas de acceso a la información.
Desarrollar conectores e integraciones para cada sistema suele requerir un esfuerzo considerable.
Las plataformas aceleradas abordan este problema incorporando integraciones prefabricadas con sistemas ampliamente utilizados en las organizaciones.
Esto permite acelerar significativamente la fase inicial del proyecto y facilita que los datos empiecen a fluir hacia la plataforma analítica en menos tiempo.

Plataformas diseñadas para la empresa moderna

Otro elemento importante de estas plataformas es que suelen estar diseñadas teniendo en cuenta las necesidades actuales de las organizaciones.
No solo están pensadas para generar informes tradicionales, sino también para soportar un ecosistema analítico más amplio.
Las empresas modernas utilizan sus plataformas de datos para múltiples propósitos:

• reporting empresarial
• análisis de negocio
• optimización operativa
• previsión de demanda
• modelos de inteligencia artificial

Por ello, las plataformas aceleradas suelen incorporar arquitecturas preparadas para soportar distintos tipos de análisis y herramientas.

Un cambio de paradigma en la construcción de plataformas de datos

La aparición de plataformas aceleradas representa un cambio importante en la forma en que las empresas abordan sus proyectos de datos.
En lugar de construir cada componente de la arquitectura desde cero, las organizaciones pueden apoyarse en estructuras ya probadas y adaptarlas a su contexto específico.
Este enfoque permite reducir riesgos, acelerar proyectos y concentrar el esfuerzo en generar valor a partir de la información.
A medida que la importancia de los datos continúa creciendo dentro de las organizaciones, es probable que este tipo de plataformas se convierta en una parte cada vez más habitual de las arquitecturas empresariales.

El siguiente paso: plataformas diseñadas para acelerar la centralización de datos

Las plataformas aceleradas representan un paso importante en la evolución de las arquitecturas de datos. Permiten a las empresas construir infraestructuras analíticas más rápidamente y reducir la complejidad técnica de estos proyectos.

En el próximo artículo veremos un ejemplo concreto de este enfoque: Mind Ocean, una plataforma diseñada para acelerar la construcción de un Data Warehouse corporativo mediante integraciones y modelos de datos ya preparados.

Cuando la idea parece sencilla… pero la implementación no lo es

Después de entender el valor de centralizar datos y de conocer qué es un Data Warehouse, muchas empresas llegan naturalmente a la misma conclusión: necesitan construir una plataforma de datos que integre la información de toda la organización.

Sobre el papel, el objetivo parece bastante claro. Integrar datos de distintos sistemas, organizarlos bajo un modelo común y utilizarlos para generar análisis e indicadores de negocio.

Sin embargo, cuando las organizaciones empiezan a recorrer ese camino, descubren rápidamente que el desafío es mucho mayor de lo que imaginaban.

El concepto de Data Warehouse es relativamente sencillo de entender. Lo complicado es construirlo y hacerlo funcionar de forma fiable a lo largo del tiempo.

El primer desafío: integrar sistemas muy diferentes

El primer obstáculo suele aparecer en el momento de conectar los distintos sistemas de la empresa.

Cada aplicación ha sido diseñada con su propio modelo de datos, su propia lógica de negocio y sus propias reglas internas. Un ERP puede estructurar la información de clientes de una forma completamente distinta a un CRM. Las herramientas financieras pueden utilizar calendarios contables diferentes a los sistemas operativos. Las aplicaciones sectoriales suelen tener modelos específicos que no encajan fácilmente con otros sistemas.

Cuando estos datos se intentan integrar, aparecen múltiples preguntas:

• ¿Cómo se identifica un cliente cuando aparece en varios sistemas?
• ¿Qué sistema contiene la información “correcta”?
• ¿Cómo se gestionan las diferencias en estructuras de datos?
• ¿Qué ocurre cuando distintos sistemas utilizan definiciones diferentes para la misma métrica?

Resolver estas cuestiones requiere comprender profundamente cómo funcionan los sistemas y cómo se relaciona la información entre ellos.

El segundo desafío: transformar datos operacionales en información analítica

Incluso cuando los datos pueden extraerse de los sistemas operativos, rara vez están preparados para ser analizados directamente.

Los sistemas transaccionales están diseñados para registrar operaciones del día a día: pedidos, facturación, pagos, movimientos de inventario o actividad comercial. Su estructura prioriza la eficiencia operativa, no la facilidad de análisis.

Para que estos datos puedan utilizarse en análisis de negocio, deben pasar por procesos de transformación.

Durante esta etapa se realizan tareas como:

• limpiar inconsistencias
• normalizar formatos
• consolidar entidades de negocio
• historizar información
• aplicar reglas de negocio

Este trabajo es fundamental para construir un modelo de datos coherente que permita analizar el negocio de forma consistente.

El tercer desafío: diseñar un modelo de datos que represente el negocio

Uno de los aspectos más complejos de un Data Warehouse es el diseño del modelo de datos.

El objetivo no es simplemente almacenar información, sino representarla de una forma que facilite el análisis del negocio.

Esto implica definir entidades clave como clientes, productos, ventas, transacciones o indicadores financieros, y establecer cómo se relacionan entre sí.

Un buen modelo de datos permite responder preguntas complejas con relativa facilidad. Un modelo mal diseñado puede convertir cada análisis en un ejercicio complicado y lento.

Por eso, el modelado de datos es una de las áreas más críticas dentro de cualquier proyecto de Data Warehouse.

El cuarto desafío: mantener la calidad y coherencia de los datos

Una vez que el Data Warehouse está construido, aparece un nuevo reto: mantenerlo actualizado y garantizar que la información siga siendo confiable.

Los sistemas operacionales cambian con el tiempo. Se incorporan nuevas aplicaciones, se modifican procesos y aparecen nuevas fuentes de datos.

Cada uno de estos cambios puede afectar a los pipelines de integración y a los modelos de datos existentes.

Además, la calidad del dato se convierte en un factor crítico. Si los datos que alimentan el Data Warehouse contienen errores o inconsistencias, los análisis generados a partir de ellos también se verán afectados.

Por eso, muchas plataformas de datos incorporan mecanismos de validación, monitorización y control de calidad que permiten detectar problemas antes de que afecten a los análisis.

El quinto desafío: escalar la plataforma con el crecimiento del negocio

A medida que la empresa crece y adopta nuevas herramientas, el volumen y la variedad de datos aumentan.

La plataforma de datos debe ser capaz de adaptarse a ese crecimiento sin perder rendimiento ni fiabilidad.

Esto implica diseñar arquitecturas que puedan escalar en almacenamiento, procesamiento e integración de nuevas fuentes.

Las tecnologías cloud han facilitado mucho este proceso, pero la complejidad arquitectónica sigue siendo un factor importante en este tipo de proyectos.

Cuando la infraestructura consume el proyecto

Por todas estas razones, muchas empresas descubren que el mayor esfuerzo de un proyecto de Data Warehouse no está en analizar datos, sino en construir y mantener la infraestructura necesaria para que esos análisis sean posibles.

Los equipos terminan dedicando gran parte del tiempo a desarrollar integraciones, mantener pipelines, resolver inconsistencias y adaptar modelos de datos.

El análisis de negocio —que era el objetivo inicial del proyecto— queda a veces relegado a un segundo plano.

Hacia una nueva forma de construir plataformas de datos

En los últimos años, este desafío ha llevado a muchas organizaciones a replantearse cómo abordan la construcción de sus plataformas de datos.

En lugar de desarrollar cada componente desde cero, algunas empresas están empezando a adoptar enfoques más acelerados que reutilizan arquitecturas, integraciones y modelos ya preparados.

Este tipo de plataformas permiten reducir significativamente el tiempo necesario para construir un Data Warehouse y facilitan que los equipos se concentren en generar valor a partir de los datos.

En el próximo artículo veremos cómo está emergiendo una nueva generación de plataformas de datos aceleradas que buscan simplificar la construcción de estas infraestructuras y acelerar los proyectos de analítica empresarial.