Un cuadro de mando se usa cuando responde decisiones concretas con datos confiables y responsables claros. Power BI no corrige definiciones contradictorias ni maestros deficientes: antes de diseñar gráficos hay que acordar KPIs, construir un modelo semántico reutilizable, controlar permisos y establecer quién certifica, publica y mantiene cada contenido.
Empezar por decisiones
Para cada página del cuadro conviene definir:
- Quién la utiliza.
- Qué decisión toma.
- Con qué frecuencia.
- Qué indicador necesita.
- Qué umbral activa una acción.
- Quién responde.
Si un gráfico no cambia ninguna decisión, probablemente sobra.
Definir KPIs
Cada indicador necesita una ficha propia:
| Campo | Ejemplo |
|---|---|
| Nombre | Margen bruto |
| Fórmula | Ventas − coste atribuible |
| Fuente | ERP |
| Periodo | Mensual |
| Propietario | Finanzas |
| Segmentos | Cliente, producto y canal |
| Umbral | Desviación frente a objetivo |
| Limitación | Coste pendiente de cierre |
Así se evita crear una fórmula distinta en cada informe.
Modelo semántico
La pyme debe centralizar dimensiones y medidas comunes: calendario, cliente, producto, empresa, vendedor, ventas y costes. Un modelo en estrella suele simplificar el rendimiento y la consistencia.
Las transformaciones críticas se documentan. Power Query no debe convertirse en una cadena invisible que solo una persona entiende.
Calidad del dato
Antes de publicar conviene revisar:
- Recuentos contra origen.
- Totales contables.
- Duplicados.
- Fechas y zonas horarias.
- Valores nulos.
- Unidades y monedas.
- Maestros sin correspondencia.
- Periodos cerrados.
El dashboard muestra la fecha de actualización y sus limitaciones. Un dato incompleto no se disfraza con diseño.
Arquitectura y actualización
Se decide entre importación, DirectQuery u opciones mixtas según volumen, latencia, origen y capacidad. El gateway on-premises debe tener propietario, alta disponibilidad cuando proceda, credenciales gestionadas y monitorización.
La frecuencia de actualización se alinea con la decisión que soporta. Actualizar cada cinco minutos no aporta valor a un KPI mensual y aumenta el coste.
Workspaces y ciclo de vida
Se separan desarrollo, prueba y producción. Los workspaces tienen propósito, propietario y grupos, no permisos individuales sin control.
El flujo habitual es:
- Desarrollo.
- Revisión técnica.
- Validación de negocio.
- Publicación.
- Monitorización.
- Retirada.
Los cambios en medidas pasan pruebas de regresión.
Seguridad
Microsoft indica que la seguridad a nivel de fila (RLS) restringe filas para usuarios Viewer, pero no se aplica igual a los roles Admin, Member o Contributor del workspace. Por eso los consumidores no deben recibir roles de edición solo para ver informes.
Controles a aplicar:
- Grupos de identidad.
- Mínimo privilegio.
- RLS probado con la función «Test as role».
- Sensibilidad y DLP.
- Control de exportación.
- Auditoría.
- Revisión periódica.
- Baja automática.
El RLS no corrige una arquitectura en la que los datos sensibles se duplican en archivos locales.
Autoservicio gobernado
El autoservicio funciona con límites:
- Modelos certificados.
- Catálogo.
- Definiciones comunes.
- Formación.
- Sandbox.
- Proceso para promover contenido.
- Soporte comunitario.
No toda persona que crea un gráfico debe publicarlo para toda la empresa.
Diseño
- Una pregunta por visual.
- Jerarquía clara.
- Color con significado.
- Unidades visibles.
- Comparaciones y contexto.
- Accesibilidad.
- Rendimiento móvil.
- Tablas para el detalle.
Evite velocímetros, 3D y colores decorativos. La precisión importa más que el impacto visual.
Adopción
Conviene medir:
- Usuarios activos.
- Recurrencia.
- Tiempo de carga.
- Informes no usados.
- Preguntas resueltas.
- Decisiones y acciones.
- Tickets.
- Exportaciones a Excel.
Una exportación masiva puede indicar que el informe no cubre bien el proceso.
Rendimiento
- Reducir columnas.
- Evitar cardinalidad innecesaria.
- Medidas eficientes.
- Agregaciones.
- Actualización incremental.
- Limitar visuales por página.
- Revisar consultas y gateway.
Se fija un objetivo de tiempo de carga y se mide el percentil 95, no solo una prueba local.
Gobierno mínimo
| Rol | Responsabilidad |
|---|---|
| Propietario de negocio | Definición y aceptación |
| Data owner | Calidad y acceso |
| BI developer | Modelo e informe |
| Administrador | Tenant y capacidad |
| Seguridad/DPO | Permisos y privacidad |
| Soporte | Incidencias y operación |
Plan de 90 días
Días 1 a 30
Decisiones, KPIs, fuentes y calidad.
Días 31 a 60
Modelo, seguridad, prototipo y validación.
Días 61 a 90
Producción, formación, métricas y retirada de hojas paralelas.
Errores frecuentes
- Empezar por los gráficos.
- Definir el KPI en cada informe.
- Dar rol Member a los consumidores.
- No conciliar con el ERP.
- Depender de una sola persona.
- Publicar desde Desktop sin ciclo de vida.
- Actualizar con demasiada frecuencia.
- Ignorar el gateway.
- Crear cientos de informes.
- Medir vistas, no decisiones.
Checklist
- Decisiones y audiencia definidas.
- KPIs definidos.
- Modelo común construido.
- Calidad conciliada.
- Workspaces y ciclo de vida establecidos.
- RLS y grupos configurados.
- Gateway y actualización revisados.
- Diseño accesible.
- Adopción y rendimiento medidos.
- Propietarios y retirada definidos.
Preguntas frecuentes
¿Power BI sustituye al ERP?
No. Consume y modela datos; el ERP sigue siendo la fuente operativa.
¿RLS protege a todos los usuarios?
Debe probarse según el rol. Microsoft aclara que el RLS se aplica a Viewer, no a los roles de edición del workspace.
¿Cuántos informes necesita una pyme?
Los mínimos que cubran sus decisiones. Es mejor un modelo común y pocos informes bien mantenidos.
Fuentes oficiales consultadas
- Microsoft: planificación de implementación.
- Microsoft: estrategia BI.
- Microsoft: RLS.
- Microsoft Fabric Adoption Roadmap.
Summum Sistemas puede definir KPIs, modelo, gobierno y despliegue de Power BI.