Caso 04 · Dashboard Design · Power BI
Capacity Model — GlobalMed
Planeación de capacidad de manufactura para dos plantas, cinco pantallas de Power BI, un solo esqueleto de diseño. Wireframeado a mano antes de abrir Power BI, para que un VP y un líder de línea pudieran leer el mismo sistema sin que nadie se los explicara.
El Product Report, en producción — mismo esqueleto que el boceto final.
Antes que nada
Seis departamentos, un archivo de Excel. Cero versión única de la verdad.
Después de una adquisición reciente, el equipo de manufactura de GlobalMed planeaba la capacidad de dos plantas —Costa Rica y Santa Clara— dentro de un solo archivo de Excel: 143 hojas, más de 200,000 VLOOKUPs, cinco minutos por recálculo. Cada líder de departamento tenía su propia pestaña. Los números que llegaban a liderazgo eran tan frescos como el último refresh manual de alguien.
La solución técnica fue un sistema en Power Platform. Mi parte: diseñar el dashboard de Power BI que ese sistema iba a entregar — la única pantalla que seis departamentos, y cada nivel de liderazgo arriba de ellos, iba a leer. Este caso es sobre esa pantalla: cómo se wireframeó antes de que existiera un solo visual en Power BI.
El problema real
No era un problema de Power BI. Era un problema de audiencias.
Un VP escaneando el portafolio a tres años necesita una pantalla completamente distinta a la de un líder de línea revisando el rendimiento de este mes — pero las dos tienen que sentirse como el mismo producto. Y el sistema tenía que escalar: veinte y tantos productos médicos, tres configuraciones de turno, un tercer sitio que todavía no existía pero ya había que modelar.
Antes de abrir Power BI, wireframeé cada pantalla en papel — literalmente lo que le mostraría a un stakeholder antes de tocar la herramienta de construcción. Abajo están las dos pantallas que más deliberadamente diseñé: la vista mensual que un planeador abre todos los días, y la que tenía que decir casi nada.
Lo que decidí, y por qué
La pantalla que un planeador abre todos los días.
La cabecera nunca se mueve. Los KPIs van primero.
Filtros arriba a la derecha, fijos — un planeador no debería tener que re-aprender dónde están cuando cambia de producto o de sitio. Debajo, una franja de KPIs a todo el ancho: la respuesta de dos segundos a “¿cómo vamos?” antes de que el ojo llegue al gráfico. La tabla de detalle queda al final, para el analista que hace scroll más allá de los titulares.
Tres formas de ordenar las mismas zonas. Gana la que responde primero.
Probé tres jerarquías: gráfico primero (esconde el número principal), barra lateral primero (aplasta la tabla), y KPI primero con el gráfico al centro. La tercera ganó porque un planeador abre esta pantalla con una sola pregunta —¿estamos cumpliendo el plan?— y esa pregunta tiene que responderse antes de que el ojo llegue al gráfico, no después.
Un dashboard no falla por falta de datos. Falla porque nadie diseñó cuál pregunta responde cada pantalla.
Un cambio de tono
Tres años, cada producto, cada planta — en una sola pantalla.
Si el Product Report responde “¿estamos cumpliendo el plan este mes?”, el Summary responde una pregunta mucho más grande: “¿hacia dónde va el portafolio?” Eso significaba un problema distinto al de las pantallas mensuales — sin franja de KPIs (el gráfico es el KPI), sin medidores (la comparación es el punto, no un número de cumplimiento). El boceto tenía que ganarse la ausencia de todo lo que las pantallas hermanas dan por sentado.
La disciplina fue no importar el mobiliario del Product Report.
Un gráfico dominando la página, sin franja de KPIs. Filtro de año en multi-selección —la comparación entre años es la razón de ser de esta pantalla—. Tabla dinámica debajo, con los mismos grupos de columnas que el gráfico, para que el ojo no tenga que reaprender nada.
Tres años × cada producto, en un gráfico. Probé tres formas de dibujarlo.
Small multiples aísla cada año pero pierde la historia de crecimiento entre paneles. 100% apilado muestra el cambio de mezcla pero borra el crecimiento absoluto. Barras apiladas con una línea de headcount superpuesta gana: pone crecimiento, mezcla de producto y expansión de plantilla en un solo trazo de ojo.
Lo que se sostuvo
Un esqueleto, cinco pantallas.
El Summary comparte el ADN del Product Report y del Family Report que queda entre los dos: mismo patrón de cabecera, misma convención de filtros, misma barra de pestañas abajo. Lo que cambia es el cuerpo —las pantallas mensuales lo llenan de KPIs y medidores; el Summary lo llena de un gráfico grande y deja que el silencio haga el trabajo.
Ese es el argumento que corre debajo de los dos bocetos: el layout no debería cambiar solo porque cambia la escala de tiempo. Nadie tiene que reaprender la pantalla al hacer zoom out de un turno a un portafolio de cinco años. Y mostrar los bocetos —en vez de llegar con el dashboard terminado— cambió la conversación con el cliente: dejaron de solo aprobar y empezaron a opinar. De ahí salieron unos doce ajustes antes de tocar Power BI, y algunos aportes que no estaban en el alcance original y terminaron sumando valor al sistema.
En producción
Cómo quedó, en Power BI.
Cómo se notó
De un archivo que nadie confiaba a un sistema que seis departamentos leen todos los días.
Si esto te suena
¿Tu equipo mira cinco reportes distintos para responder una pregunta?
Contame qué decide tu gente y con qué números. La mayoría de los dashboards no fallan por falta de datos — fallan porque nadie diseñó cuál pregunta responde cada pantalla.
Hablemos