El ciclo de vida del dashboard

Hace unos días tuvo lugar un vívido debate en el chat de la comunidad de Datola: «Tu dashboard está muerto» fue la provocadora tesis inicial. Se habló del dashboard como síntoma de inmadurez operativa y se debatió sobre un cambio de paradigma de una analítica descriptiva a una analítica agéntica.

Ese debate me llevó a reflexionar no tanto sobre si los dashboards están vivos o muertos, sino sobre cómo nacen, cómo se usan y cómo acaban muriendo. Con el tiempo, he ido identificando una serie de patrones bastante recurrentes que describen lo que podría llamarse el ciclo de vida del dashboard.

1. La necesidad de ver datos

Es el momento fundacional en el que surge una pregunta, una presión o una incertidumbre que afecta a nuestro negocio. A veces esa inquietud es legítima: «no sabemos qué está pasando»; otras veces es más difusa: «queremos más visibilidad». El punto crítico en esta fase es que no toda necesidad de información implica la creación de un nuevo dashboard. En ocasiones bastará con consultar uno existente, y en otras bastará con hacer una consulta específica dentro de la interfaz de la herramienta con la que se esté monitorizando la actividad.

2. La especificación: qué queremos ver y por qué

Es la fase crítica del proyecto, pues de ella dependerá el éxito o el fracaso del mismo. Han de plantearse ciertas preguntas clave: «¿qué decisión se quiere tomar con esto?», «¿quién la va a tomar?», «¿qué pasa si el dato cambia?». El problema más habitual es que se pide todo y se pide para ya. Se mezclan métricas operativas, tácticas y ejecutivas, y se confunde curiosidad con necesidad de negocio. Con unas especificaciones claras, acotadas y bien contextualizadas, junto con una implicación activa de la parte que demanda la información, el dashboard llegará a buen puerto. De lo contrario, la vida y utilidad del mismo tenderá asintóticamente a cero.

3. La medición e implementación (cuando aplica)

Aquí el rol del analista es fundamental. Hay necesidades de datos que no siempre requieren implementar algo nuevo, sino que el dato ya existe y simplemente no se está usando debidamente. Otras veces, el esfuerzo de medición es más costoso y laborioso de lo que se está dispuesto a asumir: ¿realmente vale la pena dedicar cierta cantidad de recursos a medir este fenómeno? El criterio del analista y su capacidad de negociación y pedagogía serán claves en esta etapa.

4. La construcción del dashboard

Es el momento de mayor entusiasmo. Todo parece claro, el dashboard «tiene buena pinta» y se valida visualmente. En este punto, el riesgo que se corre es doble: por una parte se puede confundir «bonito» con «útil», creando paneles con visualizaciones muy atractivas pero más complejas de interpretar en el día a día; y por otra parte realizar la optimización del dashboard para la herramienta de edición y no para el uso real del mismo, pensando en el destinatario final.

En estos casos, menos es más y es mejor comenzar las iteraciones con versiones simplificadas que permitan al lector del panel una inmersión gradual hasta hacerse con el manejo del dashboard. Iterar dashboards no es señal de fallo, sino de uso real.

5. Entrega y formación

Esta es una fase sistemáticamente infravalorada. Ha pasado ya algún tiempo desde que se detectó la necesidad de información, y si ha habido una implementación compleja de por medio, los implicados en el proyecto suelen estar agotados y con ganas de finalizar y pasar a otra cosa. Es aquí donde se pueden incurrir en dos errores clásicos: entregar el panel sin explicar cómo leerlo; o explicar qué mide, pero no qué NO mide. De nuevo, el analista es fundamental y entra en acción su capacidad de hacer pedagogía para manejar las expectativas de qué se puede y qué no se puede hacer con ese dashboard y evitar frustraciones tras las primeras interacciones con el mismo.

6. Uso real del panel

El destinatario final del dashboard está ya solo en su camino: tiene lo que ha pedido y lo tiene que usar por sus propios medios sin más asistencia que dudas puntuales que puedan surgirle o problemas recurrentes que puedan ocurrir durante su uso. La secuencia más habitual es la siguiente:

• Al principio se mira mucho, de forma diaria o varias veces al día.
• Luego se mira menos, cuando se necesita reportar algo o cuando se integra dentro de una rutina de trabajo repetitiva (revisión semanal, mensual).
• Luego, solo se mira «cuando pasa algo».

Esto es una señal de madurez: el dashboard se usa sólo para confirmar y no para descubrir. Se puede complementar y prolongar su vida útil con alertas y análisis ad hoc, pero poco a poco el uso del panel decae.

7. Abandono (o jubilación)

Llegamos a la fase terminal, la del desuso. Que un dashboard deje de usarse no siempre es un fracaso. A veces simplemente ha cumplido su función y deja de ser relevante, y en otras el contexto ha cambiado y su validez para evaluar la situación ha perdido pertinencia. El problema no es abandonar dashboards, sino hacerlo sin saber por qué.

Críticas, autocrítica y (co-)responsabilidad

Tras muchos años dedicado a la analítica digital, una crítica siempre emerge cuando se acumulan los proyectos relacionados con medición y negocio.

«Tenemos muchos dashboards y ya no sé dónde mirar»

Es una crítica frecuente y lógica: muchas necesidades de información, numerosas peticiones, diversos proyectos y al final Looker Studio puede acabar siendo un cementerio de dashboards que nadie mira. Se suele señalar al analista, pero no sólo es responsabilidad suya. Muchas veces, estas dinámicas se producen como consecuencia de cambios de contexto, rotación de equipos o falta de ownership claro en el desempeño de los roles en la organización.

Autocrítica

Cabe preguntarse si como analistas estamos desempeñando correctamente nuestra función: ¿representamos bien la realidad que pretendemos reflejar? ¿Comunicamos límites e interpretaciones? ¿Gestionamos expectativas? ¿Somos buenos divulgadores del dato? En definitiva, crear cultura del dato no es sólo entregar dashboards: es ir mucho más allá. Si no hacemos esto, el dashboard fracasa aunque técnicamente sea impecable.

Responsabilidad de los equipos

Hay una contraparte en estas situaciones que suele pasarse por alto. ¿Los usuarios del dato corresponden sus expectativas con un esfuerzo para aprender y entender el manejo de datos? ¿Pedir dashboards «por pedir» es suficiente para considerarse data-driven? ¿Se puede desarrollar correctamente un rol dentro de la empresa ignorando datos? La cultura del dato no consiste solo en recibir información, sino en tener voluntad para entender, anticipar y accionar decisiones en base a los datos que se proporcionan.

¿Incorporar IA y agentes es buena idea para reducir estas fricciones? Aún no tengo una opinión clara al respecto. Los agentes no rompen el patrón por sí solos. Si las dinámicas humanas no cambian, el ciclo se repetirá, pero a mayor velocidad. El problema no es el dashboard. Tampoco lo será el agente. El problema es cómo trabajamos con la información.

Si echamos mano de nuestra experiencia, seguro que nos viene a la mente algún proyecto (no sólo de analítica) en el que implementar una nueva tecnología o herramienta iba a transformar la empresa, pero luego al permanecer las mismas personas y la misma cultura organizacional, el proyecto sólo sirvió para seguir con las mismas dinámicas en una nueva solución tras dilapidar una cantidad obscena de recursos.

Conclusiones

A mi modo de ver, la cuestión no gira sobre más o menos dashboards, mejores herramientas o el uso de la IA. Esto va de personas, de responsabilidad, de cultura del dato, de implicación y de pedagogía constante. El rol del analista debe encuadrarse aquí con un papel observador, facilitador, insistente e incómodo cuando hace falta.

Seamos también realistas. El analista no puede ser un llanero solitario, ni Batman en Gotham. Sin un respaldo organizacional claro, el analista «morirá como un héroe» (esto es, dejará la compañía), o «vivirá lo suficiente para convertirse en un villano» (será ese personaje huraño que siempre pone limitaciones o que dice que no a todo).

No abandones a un analista digital. Él no lo haría 🙂