El error de diseñar datos sin diseñar decisiones

La pregunta incómoda que casi siempre se evita

¿Qué es realmente un sistema de datos: una tubería de almacenamiento o una máquina de decisiones? La mayoría de los equipos responde con la primera opción, porque es más fácil hablar de conectores, bases de datos, lago de datos, SQL, Spark y ETL que hablar de personas, preguntas, alertas y acciones. Pero ahí nace el problema: un dato sin una forma clara de ser consumido es un activo incompleto.

Esa es la tensión central que atraviesa todo trabajo serio con datos. Por un lado, están las capas de infraestructura: bases relacionales, servicios NoSQL, contenedores de blobs, canalizaciones, motores analíticos, cómputo distribuido. Por otro, está la experiencia humana: quién mira el informe, qué pregunta necesita responder, qué acción debe desencadenarse, qué pasa si la interpretación llega tarde o en un formato inútil. La mayoría de las organizaciones invierte mucho más en la primera mitad que en la segunda.

El resultado es predecible. Se construyen plataformas técnicamente elegantes que producen poco impacto. Se automatiza la ingesta, pero no la comprensión. Se centraliza el almacenamiento, pero no la atención. Se acelera el procesamiento, pero no la decisión.

Un sistema de datos no termina cuando el dato llega al repositorio. Empieza de verdad cuando alguien puede usarlo para actuar.

La trampa de pensar en capas separadas

Conviene imaginar la arquitectura de datos como una ciudad. Las bases de datos son los almacenes, las canalizaciones son las carreteras, el lago de datos es el puerto, y los motores analíticos son las fábricas que refinan materia prima. Pero una ciudad no se juzga solo por sus infraestructuras. Se juzga por si los ciudadanos pueden encontrar lo que necesitan, moverse sin fricción y tomar decisiones útiles en el momento adecuado.

En muchas organizaciones, la conversación sobre datos se queda en la capa logística. Se decide si la fuente será una base relacional, una base NoSQL, un almacenamiento de blobs o un entorno de análisis unificado. Se evalúa si conviene un motor SQL, Spark, notebooks interactivos o una plataforma integrada. Todo eso importa, pero solo como medio.

La pregunta más importante es otra: ¿qué experiencia debe tener la persona que consume el dato? Porque un informe que solo presenta números puede estar técnicamente correcto y, aun así, ser prácticamente inutilizable. Si el usuario necesita comparar escenarios, recibir alertas, explorar preguntas, abrir una aplicación o dejar comentarios, entonces el diseño del dato ya no es solo técnico. Es conductual.

Aquí aparece una idea poderosa: la arquitectura de datos y la experiencia de usuario no son disciplinas distintas, sino dos mitades del mismo sistema cognitivo. La primera mueve información. La segunda mueve atención. Si una falla, la otra se desperdicia.

---

Del almacenamiento a la intención: el dato como ruta de acción

Pensemos en tres ejemplos.

Primero, un equipo financiero que extrae transacciones desde una base SQL hacia un sistema analítico. Si el informe final solo muestra totales mensuales, el dato llega tarde para quienes necesitan detectar desviaciones diarias. En cambio, si el informe incluye alertas, suscripciones y comparaciones por hipótesis, el mismo flujo técnico se convierte en un instrumento de intervención.

Segundo, una aplicación que usa una base NoSQL para manejar documentos JSON y relaciones flexibles. Esa elección es excelente para modelar entidades complejas y permitir escalabilidad global. Pero si después los responsables de negocio no pueden hacer preguntas comprensibles sobre esa información, la flexibilidad técnica se vuelve opacidad operativa. El dato vive bien, pero nadie lo conversa.

Tercero, una plataforma analítica unificada que combina ingestión, almacén y lago de datos con SQL y Spark. Es una gran solución para reducir fragmentación. Sin embargo, una plataforma unificada no garantiza una experiencia unificada. El usuario final puede seguir enfrentándose a informes desconectados, páginas mal diseñadas o flujos que no admiten interacción. La integración técnica no se traduce automáticamente en claridad humana.

Esto revela una distinción decisiva: hay datos para almacenar, datos para explorar y datos para decidir. No todo dato debe pasar por la misma ruta ni producir la misma interfaz. Un ingeniero de datos piensa en robustez, gobernanza y escalabilidad. Un analista piensa en consulta, modelo y contexto. Un usuario de negocio piensa en acción, confianza y tiempo. El fallo común es diseñar solo para la primera perspectiva.

La madurez analítica no consiste en tener más herramientas, sino en cerrar mejor el circuito entre captura, comprensión y decisión.

El informe no es una página, es una conversación

Cuando se habla de requisitos de experiencia del usuario en informes, la lista suele parecer táctica: compatibilidad con interacciones, preguntas, alertas, vínculos web, acciones para abrir aplicaciones, análisis de hipótesis, impresión, suscripción, diseños de página, comentarios. Pero en realidad esa lista define algo mucho más profundo: el grado en que el informe puede comportarse como una conversación y no como una vitrina.

Un informe pasivo dice: “Aquí están los números”. Un informe útil dice: “Aquí están los números, esto es lo que significan, esto es lo que puedes explorar, y esto es lo que deberías hacer después”. Esa diferencia cambia por completo el valor del dato.

Por ejemplo, un gerente de operaciones no necesita solo ver un KPI rojo. Necesita poder hacer tres cosas: preguntar por qué ocurrió, contrastarlo con otros periodos o segmentos, y actuar sobre él, idealmente sin salir del flujo de trabajo. Si el informe permite comentarios, enlaces a sistemas operativos y acciones hacia aplicaciones, deja de ser un documento y se convierte en un punto de coordinación.

Aquí entra un principio útil: cada elemento de interfaz debe responder a una pregunta humana concreta.

• ¿Quiere comparar escenarios? Entonces necesita análisis de hipótesis.
• ¿Debe reaccionar a un umbral? Entonces necesita alertas.
• ¿Debe escalar el hallazgo? Entonces necesita comentarios y enlaces.
• ¿Debe compartirlo con otros? Entonces necesita suscripción e impresión.
• ¿Debe navegar a una acción externa? Entonces necesita integración con aplicaciones.

No son adornos. Son mecanismos para convertir información en comportamiento. Un buen diseño de experiencia evita la tragedia clásica del analista: descubrir algo importante y luego tener que explicarlo, reenviarlo y perseguirlo manualmente durante días.

La verdadera unificación: del lakehouse al loop humano

La idea de una solución analítica unificada suele enfocarse en la integración técnica. Un solo servicio puede combinar ingestión, almacenamiento en almacén de datos, almacenamiento en lago de datos y análisis con SQL o Spark. Eso reduce fricción, sí. Pero la unificación más valiosa no es la del backend, sino la del circuito completo entre dato y decisión.

Llamemos a esto el loop humano del dato:

1. Captura confiable: el dato entra desde un sistema operativo, relacional o NoSQL.
2. Transformación contextual: el dato se limpia, modela y enriquece para servir a un propósito.
3. Exploración significativa: analistas y equipos técnicos investigan con SQL, Spark o notebooks.
4. Presentación orientada a tarea: el usuario ve solo lo necesario para decidir.
5. Acción y seguimiento: el informe habilita alerta, comentario, enlace o suscripción.
6. Aprendizaje del sistema: la interacción deja trazas para mejorar el próximo ciclo.

Este marco ayuda a explicar por qué tantas iniciativas de datos fallan incluso cuando la infraestructura es sólida. Se optimiza una fase del loop y se ignoran las otras. Es como construir una cocina profesional y luego servir la comida en platos rotos. El alimento existe, la operación funciona, pero la experiencia destruye el valor.

La oportunidad está en diseñar cada capa con la capa siguiente en mente. Si una base relacional será origen de ETL, el modelo debe considerar no solo eficiencia de extracción, sino también cómo se consumirá la información después. Si una fuente NoSQL alimenta una experiencia de negocio, su esquema flexible debe traducirse en vistas comprensibles. Si una plataforma analítica unificada concentra todo, debe hacerlo sin aislar al usuario en un laberinto de opciones técnicas.

Un marco práctico: pensar en tres contratos

Para construir sistemas de datos que realmente sirvan, conviene pensar en tres contratos distintos.

1. El contrato de datos

Define qué datos existen, con qué calidad, con qué frecuencia llegan y quién es responsable de ellos. Aquí viven la gobernanza, la modelización, la seguridad y la escalabilidad.

2. El contrato analítico

Define cómo se exploran, transforman y combinan los datos. Aquí viven SQL, Spark, notebooks, canalizaciones, métricas, semántica compartida y preparación de modelos.

3. El contrato de experiencia

Define cómo una persona entiende y usa el resultado. Aquí viven las interacciones, preguntas, alertas, suscripciones, comentarios, enlaces y diseños de página.

La mayoría de las organizaciones redacta muy bien el primer contrato, redacta parcialmente el segundo y olvida por completo el tercero. Pero el tercero es el que determina si la organización aprovecha de verdad el primero y el segundo.

Si quieres una prueba rápida, revisa cualquier informe crítico y pregúntate: ¿esto permite decidir o solo permite mirar? Si la respuesta es “solo mirar”, el problema no es visual. Es arquitectónico.

El dato no crea valor cuando se almacena. Lo crea cuando encuentra una forma humana de volverse irrelevante para la duda y útil para la acción.

Key Takeaways

• Diseña la experiencia antes de cerrar la arquitectura: define primero qué decisión debe habilitar el dato, y después elige la base, el motor y la canalización adecuados.
• Convierte cada informe en un flujo de acción: añade alertas, enlaces, comentarios o suscripciones solo si responden a una tarea real del usuario.
• Separa datos para almacenar, explorar y decidir: no todo conjunto de datos necesita la misma forma de consumo ni la misma interfaz.
• Evalúa tus plataformas por el circuito completo: una solución técnicamente unificada puede seguir produciendo una experiencia fragmentada.
• Pregunta siempre “¿qué haría alguien distinto después de ver esto?”: si no hay una respuesta clara, el informe probablemente todavía no está terminado.

Conclusión: el dato útil es una promesa cumplida

La forma más común de equivocarse con los datos es tratarlos como si fueran un problema de tuberías. La forma más madura de abordarlos es reconocer que son un problema de promesas. Una organización promete algo cuando captura, transforma y presenta información con la intención de que alguien pueda actuar mejor que antes.

Por eso la pregunta no es solo qué tecnología usar, sino qué experiencia merece el usuario final. La infraestructura importa, pero no como fin. Importa porque hace posible una conversación más rica entre la realidad y la decisión. Cuando una plataforma de datos se diseña bien, no se limita a responder preguntas: aprende a hacerlas mejores.

Y ahí está el cambio de perspectiva más importante. No construimos sistemas de datos para que todo esté centralizado, ni siquiera para que todo esté disponible. Los construimos para que una organización pueda pensar con más claridad. Cuando el dato logra eso, deja de ser un registro. Se convierte en criterio.