0%

Dashboards que alguien mira: cómo trabajo los datos

No se trata del dashboard más lindo: se trata de que alguien lo abra y decida algo. Cómo encerco un proyecto de BI antes de tocar Power BI, SQL o cualquier herramienta.

>2 min de lectura>actualizado 10 de noviembre de 2026

Hay una cosa que aprendí después de hacer demasiados dashboards: el problema casi nunca es el gráfico.

Un dashboard puede tener los colores perfectos, las mejores prácticas de visualización y trescientos indicadores, y seguir sin servir para nada si nadie lo abre después de la primera semana.

Por eso hoy encerco los proyectos de datos de una forma muy distinta a como lo hacía al principio.

La pregunta antes que la herramienta

Antes de abrir Power BI, SQL o lo que sea, necesito saber una cosa: ¿qué decisión va a tomar alguien con esto?

Si no hay una pregunta concreta detrás —“¿qué producto se está cayendo?”, “¿cuánto tarda realmente el proceso?”— el dashboard se convierte en una pared de números que nadie mira. Y una pared de números nadie la mira dos veces.

La herramienta viene después. Primero va la pregunta, y muchas veces la respuesta ni siquiera necesita un dashboard: un informe simple alcanza.

Brief de un proyecto de datos: decisión, quién decide, frecuencia y herramienta, en ese orden

La herramienta es el último campo del brief, no el primero. Ilustración editorial.

Menos KPIs, mejores preguntas

Mi regla favorita: si un panel tiene más de diez indicadores, probablemente tenga dos o tres que importan y el resto está de adorno.

Prefiero un tablero chico donde cada número tenga una pregunta clara detrás, a un tablero enorme que impresiona en la primera demo y muere en la segunda semana. Cada KPI que agregás tiene un costo de atención, y la atención de quien lo mira es finita.

Doce indicadores en una grilla, solo tres iluminados, con la leyenda “3 cambian una decisión, 9 de adorno”

Doce indicadores compiten por la misma atención; tres cambian una decisión. Ilustración editorial.

El dato sucio existe

La parte menos glamorosa del trabajo es la que más tiempo lleva: los datos vienen rotos, duplicados, con formatos que cambian porque alguien tocó el sistema fuente un martes.

Gran parte de mi trabajo está en validar, cruzar y a veces reconstruir la ruta del dato antes de que llegue a un gráfico bonito. Un dashboard que muestra mal un número es peor que no tener dashboard: te hace confiar en la decisión equivocada.

Cómo reviso un reporte ajeno

Cuando alguien me pasa su tablero para opinar, miro siempre lo mismo:

  • ¿La primera pantalla responde la pregunta principal o hay que scrollear?
  • ¿Los números tienen unidad, período y fuente a la vista?
  • ¿Hay un valor que claramente no cierra? (Casi siempre hay uno.)
  • ¿Se puede filtrar sin romper el resumen?

Lista de cuatro preguntas para revisar un tablero ajeno, con la tercera destacada: ¿hay un valor que claramente no cierra?

Las cuatro preguntas con las que reviso cualquier tablero ajeno. Ilustración editorial.

Son cuatro preguntas básicas, pero delatan el estado real de cualquier reporte.

Qué quiero que pase cuando alguien abre un dashboard

Que en los primeros cinco segundos sepa si hay algo a lo que atender.

Eso es todo. No el dashboard más lindo, no el con más indicadores: el que mejor cuenta la historia del negocio en el menor espacio posible. Todo lo que hago con datos —SQL, modelos, visualización— está al servicio de esos cinco segundos.

Y si después de esa primera mirada alguien toma una decisión mejor que la que tomaría con la intuición sola, el dashboard hizo su trabajo.