Gobernanza en Power BI: cómo limpiar un mar de informes y recuperar la confianza en el dato

Durante años, mi trabajo consistió en construir informes. Llegaba una petición, la analizaba, montaba el modelo, diseñaba el dashboard, lo publicaba. Siguiente.

En mi trabajo actual, lo primero que hice no fue construir nada. Fue contar. Contar áreas de trabajo, informes, modelos semánticos y dataflows. Y lo que salió de esa cuenta explica por qué cada vez más analistas dedicamos más tiempo a limpiar que a crear: cientos de informes, decenas de áreas de trabajo, y el mismo informe de ventas publicado tres veces en tres sitios distintos. Con tres cifras distintas, porque cada copia se había preparado con filtros diferentes y nadie sabía ya cuál era la buena.

Esto no es un fallo de una empresa concreta. Es la consecuencia natural de una década de Power BI en autoservicio: la herramienta cumplió su promesa de que cualquiera pudiera publicar un informe, y ahora el problema no es la falta de información, sino que hay tanta que no se puede acceder a la que importa. El trabajo del analista ha cambiado con ello.

Esta guía es la que me habría gustado tener al empezar: cómo inventariar lo que existe, cómo medir el uso real con las herramientas que Fabric y Power BI ofrecen, cómo decidir qué se borra y qué se certifica, cómo resolver los duplicados con números distintos, y cómo evitar que el mar vuelva a llenarse en seis meses.

Cómo se llena el mar: el ciclo de vida del informe que nadie borra

Ningún informe nace pensando en ser un estorbo. El proceso que lleva de cero a cientos es siempre parecido:

• El autoservicio funcionó. Cada equipo aprendió a publicar. Cada analista de negocio tiene su área de trabajo. Cada necesidad se resolvió con un informe nuevo, porque era más rápido que pedir un cambio en el existente.
• Copiar y adaptar. «Descárgate el pbix, cambia el filtro de región y publícalo en tu área». Tres meses después existen cinco versiones del mismo informe con cinco lógicas ligeramente distintas.
• Las reorganizaciones. Los equipos cambian, las personas se van, las áreas de trabajo se quedan. Un informe cuyo dueño ya no está en la empresa no tiene a nadie que lo borre.
• Crear tiene premio; borrar tiene riesgo. Publicar un informe nuevo es visible y se agradece. Borrar uno puede generar una queja. El incentivo empuja en una sola dirección.
• Fabric multiplica los tipos de elemento. A los informes, modelos y dataflows se suman lakehouses, notebooks, pipelines y dataflows Gen2. Más cosas que crear, más cosas que olvidar.

Los síntomas son tres y aparecen en este orden: nadie encuentra lo que busca; el mismo indicador tiene varios valores según dónde lo mires; y la capacidad paga cada noche el refresco de modelos que nadie lee.

El coste de no limpiar

Conviene ponerle cifras, porque «hay demasiados informes» no convence a nadie para dedicar tiempo a esto.

• Confianza. Cuando el director de ventas ve dos cifras distintas para el mismo mes, deja de fiarse de las dos. Vuelve al Excel que se prepara a mano y todo el trabajo de modelado pierde valor. Este es el coste mayor y el más difícil de recuperar.
• Capacidad. Un modelo semántico que se refresca cuatro veces al día y que nadie ha abierto en tres meses consume unidades de capacidad en cada refresco. En una capacidad Fabric eso es dinero, y en horas punta es rendimiento que le quitas a los informes que sí se usan. La métrica que lo destapa es la ratio de refrescos por visualización.
• Soporte. Los modelos zombis fallan. La fuente cambió, la credencial caducó, y cada fallo genera un aviso que alguien tiene que mirar para descubrir que no importa.
• Riesgo. Informes con datos sensibles compartidos con personas que cambiaron de equipo hace dos años y siguen teniendo acceso.
• Incorporaciones. Una persona nueva tarda semanas en saber qué informe consultar para cada cosa. Y suele acabar creando el suyo.

Paso 1: inventario. No puedes limpiar lo que no ves

Antes de tocar nada hay que saber qué existe, quién lo usa y de qué depende. Fabric ofrece varias fuentes de información, cada una con su alcance y su ventana temporal.

Fuente	Qué te da	Ventana	Requisito
Área de trabajo Admin monitoring	Informe de uso y adopción de funcionalidades: actividad por usuario, elemento y área de trabajo. Modelos semánticos reutilizables	Corta (30 días de actividad)	Rol de administrador de Fabric para instalarlo; después se puede compartir
OneLake catalog, pestaña Govern	Inventario de elementos, cobertura de descripción y endorsement, frescura del dato, etiquetas de sensibilidad, acciones recomendadas	Estado actual, refresco diario	Admin ve todo el tenant; cada propietario ve sus elementos
Métricas de uso por informe o área	Vistas y usuarios de un informe concreto	30 días	Permiso sobre el área de trabajo
API de eventos de actividad	Cada acción de cada usuario: abrir informe, refrescar modelo, exportar, compartir	30 días, en llamadas de un día como máximo	Admin o service principal con permisos de tenant
API de elementos sin uso	Modelos, informes y paneles sin uso en un área de trabajo	30 días	Admin; una llamada por área de trabajo
Scanner API	Inventario completo con linaje: qué informe usa qué modelo, qué modelo usa qué dataflow, qué fuentes hay detrás. Opcionalmente, medidas DAX y consultas M	Estado actual	Admin; para DAX y M hay que activar «Mejorar las respuestas de las API de administración con metadatos detallados» en el portal
Semantic Link Labs	Librería Python para notebooks de Fabric que envuelve todas las APIs anteriores en funciones de una línea	La de cada API	Notebook en Fabric con los mismos permisos

Paso 2: la herramienta de uso que me construí

Con las fuentes claras, monté un pequeño sistema que responde las preguntas que las pantallas de Fabric no responden juntas: qué informes se usan menos, qué modelos no tienen ningún informe encima, qué dataflows no alimentan ningún modelo, y qué elementos se refrescan más de lo que se leen. La arquitectura es deliberadamente simple.

Un notebook diario que persiste la actividad

Un notebook programado en Fabric llama cada mañana a la API de eventos de actividad para el día anterior y añade el resultado a una tabla Delta en un lakehouse. La librería Semantic Link Labs lo reduce a unas líneas:

%pip install semantic-link-labs

from sempy_labs import admin
from datetime import date, timedelta

ayer = date.today() - timedelta(days=1)

actividad = admin.list_activity_events(
    start_time=f"{ayer}T00:00:00",
    end_time=f"{ayer}T23:59:59"
)

spark.createDataFrame(actividad) \
    .write.format("delta") \
    .mode("append") \
    .saveAsTable("actividad_powerbi")

La API exige que inicio y fin estén dentro del mismo día, por eso el proceso es diario. Con dos meses de ejecución tienes lo que ninguna pantalla de Fabric te da: un histórico de uso sin fecha de caducidad. Las actividades que más uso después son ViewReport para las visualizaciones y RefreshDataset para los refrescos, pero la tabla guarda todas.

Un inventario semanal con linaje

Una vez a la semana, otro notebook lanza la Scanner API sobre todas las áreas de trabajo, en lotes de hasta cien, y guarda el resultado: elementos, sus dueños, sus fechas de modificación y, sobre todo, las dependencias entre ellos.

from sempy_labs import admin

resultado = admin.scan_workspaces(
    workspace=lista_de_workspaces,   # hasta 100 por llamada
    lineage=True,
    data_source_details=True
)

El resultado es un JSON con una entrada por área de trabajo, y dentro sus informes, modelos y dataflows. Cada modelo indica qué dataflows tiene aguas arriba, y cada dataflow puede indicar a su vez otros dataflows. Con eso, encontrar los dataflows huérfanos es un cruce de conjuntos:

usados = set()

for ws in resultado["workspaces"]:
    for modelo in ws.get("datasets", []):
        for up in modelo.get("upstreamDataflows", []):
            usados.add(up["targetDataflowId"])
    for flujo in ws.get("dataflows", []):
        for up in flujo.get("upstreamDataflows", []):
            usados.add(up["targetDataflowId"])

huerfanos = [
    (ws["name"], flujo["name"])
    for ws in resultado["workspaces"]
    for flujo in ws.get("dataflows", [])
    if flujo["objectId"] not in usados
]

Un dataflow huérfano no es necesariamente basura: puede alimentar un proceso fuera de Power BI o ser el primer paso de algo que aún no existe. Pero es un candidato que hay que preguntar a su dueño. Un matiz importante: los dataflows Gen2 de Fabric aparecen como elementos de Fabric y la cobertura de su linaje en el escaneo puede variar según el tenant. Comprueba con un par de casos conocidos antes de fiarte de la lista.

Un modelo semántico con cinco medidas

Sobre esas dos tablas construí un modelo semántico pequeño, con las dimensiones de área de trabajo, elemento, tipo y dueño, y un puñado de medidas:

Vistas 90d =
CALCULATE (
    COUNTROWS ( Actividad ),
    Actividad[Actividad] = "ViewReport",
    DATESINPERIOD ( 'Calendario'[Fecha], TODAY (), -90, DAY )
)

Usuarios distintos 90d =
CALCULATE (
    DISTINCTCOUNT ( Actividad[UsuarioId] ),
    Actividad[Actividad] = "ViewReport",
    DATESINPERIOD ( 'Calendario'[Fecha], TODAY (), -90, DAY )
)

Días sin uso =
VAR UltimaVista =
    CALCULATE (
        MAX ( Actividad[Fecha] ),
        Actividad[Actividad] = "ViewReport",
        REMOVEFILTERS ( 'Calendario' )
    )
RETURN
    IF ( ISBLANK ( UltimaVista ), 999, DATEDIFF ( UltimaVista, TODAY (), DAY ) )

Refrescos 90d =
CALCULATE (
    COUNTROWS ( Actividad ),
    Actividad[Actividad] = "RefreshDataset",
    DATESINPERIOD ( 'Calendario'[Fecha], TODAY (), -90, DAY )
)

Refrescos por vista =
DIVIDE ( [Refrescos 90d], [Vistas 90d] )

El valor 999 en Días sin uso es deliberado: un elemento que no aparece en la actividad desde que empezaste a guardarla se va al final de la lista ordenada, que es donde debe estar. Y Refrescos por vista es la medida que más conversaciones ha abierto: un modelo con 360 refrescos y 4 visualizaciones en un trimestre no necesita explicación.

Con esto, el informe de la herramienta tiene cinco páginas: informes ordenados por días sin uso, modelos sin ningún informe conectado, dataflows sin ningún modelo aguas abajo, elementos con el mismo nombre en varias áreas de trabajo, y refrescos programados sin lectores. Cada fila tiene el dueño al lado, porque la siguiente fase es hablar con él.

Paso 3: decidir. Los cuatro cajones

La lista de candidatos no es una lista de borrado. Cada elemento va a uno de cuatro cajones, y los criterios deben estar escritos antes de empezar, porque si no cada conversación con un dueño se convierte en una negociación distinta.

Cajón	Criterio	Qué se hace
Eliminar	Cero vistas en 90 días, sin dueño activo o con dueño que confirma que no sirve, y sin dependencias aguas abajo	Copia de seguridad, aviso, eliminación tras el plazo
Archivar	Uso residual o estacional (cierres, auditorías), o dueño que pide conservarlo sin poder justificar uso	Se mueve a un área de trabajo de archivo, sin refresco programado y sin capacidad
Fusionar	Duplicado funcional de otro informe o modelo, con o sin diferencias en los números	Se elige una versión canónica, se migran los usuarios y se elimina el resto
Certificar	Uso alto, dueño claro, fuente de decisiones	Descripción, endorsement, dueño secundario, y pasa a ser la referencia oficial de su tema

Y unas reglas de proceso que evitan la mayoría de los conflictos:

• Nada se borra sin aviso. Al dueño y a los últimos usuarios que aparecen en la actividad, con quince días de margen. La mayoría no responde, y el silencio cuenta como conformidad si se ha anunciado así.
• Nada se borra sin copia. Exportar el pbix o, mejor, la definición del elemento a un repositorio Git con la integración de Fabric. Restaurar un informe borrado hace un año por una petición de auditoría es una tarde de trabajo si tienes la copia y una semana si no.
• Un modelo con informes encima no se borra. El linaje te lo dice. Primero se resuelven los informes, después el modelo.
• El uso bajo no siempre es uso inútil. El informe de cierre anual se abre dos veces al año y es el más importante de la casa. Pide a cada dueño su lista de elementos críticos de baja frecuencia antes de aplicar los criterios de forma automática.

Paso 4: los duplicados con números distintos

Este es el caso que más daño hace y el que más vale la pena resolver bien. Tres informes de ventas en tres áreas de trabajo. El primero excluía las devoluciones, el segundo las incluía, el tercero cortaba el período por fecha de pedido en lugar de fecha de entrega. Tres personas presentaron tres cifras de ventas del mismo mes en la misma reunión, y la reunión se dedicó a discutir cuál era la buena en lugar de a decidir nada.

Cómo detectarlos

• Por nombre. El inventario te da los elementos con nombres iguales o casi iguales en distintas áreas. Es la señal más burda y la más frecuente.
• Por fuente. Modelos distintos que leen las mismas tablas del mismo origen. Los detalles de origen del escaneo lo revelan.
• Por definición. Con los metadatos detallados activados, el escaneo devuelve las expresiones DAX de las medidas. Comparar la medida «Ventas» entre los tres modelos es la prueba definitiva de que están calculando cosas distintas.

Cómo resolverlos

1. Decide la definición con el negocio, no con los analistas. ¿Ventas incluye devoluciones o no? ¿Por qué fecha se corta? La respuesta depende de qué decisión se toma con el número, y esa conversación es la misma que describo en el artículo sobre por qué «quiero ver todos los datos» paraliza las decisiones. Si el negocio necesita las dos cifras, tendrán dos nombres distintos, no el mismo nombre en dos sitios.
2. Un modelo semántico compartido y certificado. La definición de cada indicador vive en el modelo, una sola vez, con su descripción. Si trabajas en retail, las definiciones de los 7 KPIs de retail son un buen punto de partida para el documento de definiciones que debe acompañar al modelo.
3. Informes ligeros conectados en vivo. Las tres copias pasan a ser tres informes sobre el mismo modelo. Pueden diferir en el diseño, en las páginas, en los filtros por defecto. No pueden diferir en los números, porque no calculan nada: solo muestran.
4. Redirige antes de borrar. Durante un mes, sustituye el contenido de los informes antiguos por una única página que diga a dónde se ha movido. Es un truco tonto que evita decenas de correos.
5. Endorsement. Fabric tiene dos niveles: promocionado, que puede marcar cualquier dueño para indicar que el elemento está listo para usarse, y certificado, que solo pueden aplicar las personas autorizadas por el administrador y que significa que la organización lo respalda. La regla que funciona: solo un equipo central certifica, y solo lo certificado se publica en aplicaciones para toda la empresa.
6. Dominios. Si el tenant es grande, organizar las áreas de trabajo en dominios por área de negocio hace que el catálogo sea navegable y que la pestaña Govern pueda filtrar por dominio.

Paso 5: que no vuelva a pasar

Una limpieza sin reglas se repite cada año. Las reglas que propongo son deliberadamente pocas y ligeras, porque las políticas de gobierno de veinte páginas no las lee nadie.

• Convención de nombres. Área de negocio, tema y tipo en el nombre del elemento. Y «copia de» prohibido como prefijo permanente.
• Dueño obligatorio y dueño secundario. Cuando el primero se va, el segundo hereda. Sin dueño no se publica en áreas compartidas.
• Descripción obligatoria para publicar en cualquier área de trabajo que no sea personal. Dos frases: para qué sirve y qué decisión soporta.
• Áreas de trabajo de pruebas con caducidad. Cada equipo tiene su espacio para experimentar, y lo que hay en él se archiva a los 90 días si no se ha promocionado a un área compartida.
• Prohibido duplicar un modelo certificado. Si necesitas una medida nueva sobre las ventas, se pide al modelo certificado o se crea un modelo compuesto sobre él. No se descarga y se copia.
• Pipelines de despliegue desarrollo, pruebas y producción para todo lo certificado. Lo que está en producción no se edita a mano.
• Política de retirada automática. A los 90 días sin uso, aviso al dueño. A los 120, archivo. A los 180, eliminación con copia. El notebook diario lo calcula y manda el correo; nadie tiene que acordarse.
• Revisión trimestral de una hora con los dueños de cada dominio, mirando cinco números: elementos totales, porcentaje certificado, porcentaje con dueño, porcentaje sin uso en 90 días y ratio de refrescos por vista. Si los cinco mejoran, la política funciona.

Lo que cambia en el trabajo del analista

Hace unos años, el valor de un analista se medía por lo que construía. Hoy, en cualquier organización con varios años de Power BI, una parte creciente del valor está en lo contrario: en reducir, en consolidar, en decidir qué merece existir. Esto exige habilidades que no estaban en la descripción del puesto: llamar a una API, leer un JSON de linaje, montar un notebook programado, y sobre todo, negociar con el dueño de un informe que lleva dos años sin abrirse y que aun así no quiere que desaparezca.

Es el mismo problema que describía a nivel de dashboard cuando hablaba de las tablas de 47 columnas, llevado a la escala del tenant entero: más no es más claro. Un catálogo con 80 informes certificados, con dueño y con descripción, vale más que uno con 800 en el que nadie sabe cuál abrir. Y llegar del segundo al primero es, hoy, trabajo de analista.

¿Cuántos informes tiene tu tenant? ¿Y cuántos se han abierto este mes? Si lo has medido, cuéntame en los comentarios qué te encontraste. Y si no, empieza por el notebook diario: en dos meses tendrás la respuesta.

Comentarios

Deja tu comentario

Nombre *

Email * (no se publica)

Comentario *

Publicar comentario

Los comentarios son revisados antes de publicarse.