Gobierno del dashboard: mantener, versionar y retirar

1.247 dashboards activos. 890 sin una sola visita en 90 días. 340 con métricas que ya no existen en el data warehouse — dan error o muestran cero permanente. 47 con datos incorrectos porque la fuente cambió de esquema y nadie los actualizó. Eso encontró un banco europeo al auditar su plataforma de BI, y muchos de esos dashboards están en más de una de las tres listas. No es un caso raro: es el estado por defecto de cualquier empresa que construye dashboards sin gobernarlos. Nadie se atreve a borrar nada "por si alguien lo necesita", el catálogo crece sin control, y el coste — en licencias, en confusión, en decisiones tomadas con datos muertos — se acumula en silencio.

Este es el problema real de los dashboards en empresa: no es construirlos — es GOBERNARLOS. Construir es la parte fácil y la parte divertida. Mantener, actualizar, decidir qué sobrevive y qué muere, gestionar quién puede ver qué — eso es lo difícil. Y es lo que separa un equipo de datos maduro de uno que produce sin control.

### El ciclo de vida de un dashboard

Un dashboard no es eterno. Tiene un ciclo de vida como cualquier producto:

1. 01.Nacimiento: alguien tiene una necesidad, se define el requisito, se construye.
2. 02.Adopción: los usuarios lo empiezan a usar, piden ajustes, se itera.
3. 03.Madurez: funciona, se consulta regularmente, cumple su propósito.
4. 04.Declive: las necesidades cambian, las métricas se redefinen, los usuarios migran a otro panel o dejan de mirarlo.
5. 05.Retiro: se archiva con fecha y motivo. No se borra — se retira del catálogo activo.

El problema en la mayoría de empresas es que no existe el paso 5. Los dashboards nacen, algunos prosperan, muchos se abandonan, pero NINGUNO se retira formalmente. Se acumulan como cajas en un trastero. Nadie quiere tirar nada "por si acaso". El resultado: un catálogo donde encontrar el dashboard correcto es tan difícil como no tenerlo.

### Cada dashboard tiene un dueño

La regla más importante del gobierno de dashboards: cada panel tiene UN dueño. No "el equipo de datos". No "el que lo creó hace dos años y ya no está". Un nombre concreto, actualizado, que responde cuando algo no cuadra. Sin dueño, un dashboard es huérfano — y los huérfanos no se mantienen.

El dueño no tiene por qué ser quien lo construyó (el analista puede haber rotado). Es la persona responsable de que las métricas sigan siendo correctas y de decidir cuándo el dashboard se retira. En la práctica, suele ser el responsable del área de negocio que lo usa: el head de ventas es dueño del dashboard de ventas, no el analista que lo montó.

### Permisos: quién ve qué, y quién puede romperlo

Los permisos de un dashboard tienen dos niveles que no hay que confundir: acceso al DASHBOARD (quién puede verlo y quién puede editarlo) y acceso a los DATOS (quién puede ver qué filas: la seguridad a nivel de fila o RLS que ya viste). No es lo mismo poder ver el dashboard de ventas que poder ver las ventas de TODOS los equipos.

• ▹Viewer (visor): puede ver el dashboard y usar filtros, pero no modificar nada. Es el rol de la mayoría de stakeholders.
• ▹Editor: puede modificar gráficos, añadir elementos, cambiar fuentes de datos. Solo para el equipo que lo mantiene.
• ▹Owner (propietario): puede compartir, transferir propiedad, y eliminar. Normalmente el creador y el dueño de negocio.

El error clásico: dar permisos de edición a todo el mundo "para que puedan personalizarlo". Resultado: alguien borra un filtro sin querer un martes a las 7am, el dashboard se rompe, y nadie sabe qué ha cambiado. Permisos mínimos por defecto, ampliación solo cuando se justifica.

### La regla de los 90 días

Si un dashboard no ha recibido una sola visita en 90 días, está muerto. No "quizá alguien lo necesite algún día" — está muerto HOY. Los equipos maduros tienen un proceso trimestral de revisión: se miran los logs de acceso, se identifican los paneles sin visitas, se contacta al dueño, y si no hay justificación, se archivan.

Archivar no es borrar. Archivar es mover a una carpeta de "Retirados" con una nota que dice: fecha de retiro, motivo, y quién lo retiró. Si dentro de tres meses alguien lo necesita (raro, pero pasa), se restaura. Si no, a los 6 meses se elimina definitivamente.

El miedo a borrar dashboards es universal. La realidad: en 12 años de carrera, nunca he visto que un dashboard retirado se necesitara de vuelta. Lo que sí he visto mil veces es gente perdiendo veinte minutos buscando el dashboard correcto entre 50 que nadie usa.

### Catálogo de dashboards: el mapa que falta

Un catálogo de dashboards es una lista (puede ser una hoja de cálculo, puede ser una página en Confluence o Notion) que dice: qué dashboards existen, para quién son, quién es el dueño, con qué frecuencia se usan, y cuál es la fuente de datos. Parece burocracia. En la práctica, es lo que evita que alguien construya un dashboard nuevo que ya existe con otro nombre.

• ▹Nombre del dashboard y enlace directo
• ▹Dueño (persona, no equipo)
• ▹Audiencia (quién lo mira, con qué frecuencia)
• ▹Fuente de datos (de dónde salen los números)
• ▹Fecha de creación y última revisión
• ▹Estado: activo, en revisión, archivado

Con un catálogo, cuando alguien te pide "un dashboard de marketing", lo primero que haces es buscar en el catálogo. Si ya existe, se lo enlazas. Si no, lo construyes y lo registras. Sin catálogo, cada petición produce un dashboard nuevo y nadie sabe cuántos hay.

### Versionado: qué cambió y por qué

Los dashboards evolucionan: una métrica se redefine, un filtro se añade, una fuente cambia. Sin un registro de cambios, nadie sabe por qué el número de ayer es distinto del de hoy. El versionado puede ser tan simple como un log en la misma hoja del catálogo: "15-mar-2024: se cambió la métrica de ingresos de bruto a neto. Motivo: alineación con finance."

En herramientas empresariales (Power BI con Azure DevOps, Tableau con version control), el versionado se integra con Git y se gestiona como código. En las herramientas más ligeras no suele haber nada nativo — la alternativa es hacer una copia antes de cada cambio grande y nombrarla con fecha ("Dashboard ventas - v2024-03-15"). No es elegante, pero funciona.

### ¿Cuándo actualizar vs cuándo rehacer?

No todo cambio se resuelve editando. Si la necesidad del negocio ha cambiado fundamentalmente (nueva estrategia, reorganización de equipos, cambio de KPIs), muchas veces es mejor construir un dashboard nuevo desde cero que intentar adaptar uno viejo. El viejo se retira; el nuevo se lanza. Intentar adaptar un dashboard cuyo propósito ya no aplica es como reformar una casa cuyo plano ya no sirve: sale más caro que construir.

La señal de que toca rehacer: cuando llevas más de dos iteraciones añadiendo y quitando cosas del mismo panel, y cada vez se aleja más del diseño original. O cuando el stakeholder dice "esto ya no me sirve" tres meses seguidos y tú sigues parcheando.

### Resumen

El gobierno de dashboards es lo que separa un equipo maduro de uno que produce sin control. Cada dashboard tiene un dueño, unos permisos claros, y un ciclo de vida que incluye el retiro. Un catálogo evita duplicados. La regla de los 90 días identifica lo muerto. Y el versionado (por simple que sea) evita que un cambio rompa la confianza del usuario.