De 86 Gráficas en una Sola Página a 22 Páginas Organizadas: Un Framework de Consolidación de Dashboards

La primera vez que una analista de finanzas abrió el dashboard heredado, tuvo que hacer scroll durante tres minutos antes de encontrar la gráfica que buscaba. No porque los datos no estuvieran. Porque todos estaban ahí — cada gráfica que alguien había pedido en algún momento, apilada en una sola página, en el orden en que se fue agregando.

86 gráficas. Una página. Sin lógica de agrupación que sobreviviera el contacto con un stakeholder nuevo.

Al terminar el proyecto, teníamos 6 dashboards organizados en 22 páginas. El equipo de Finanzas podía encontrar cualquier número en menos de 30 segundos. Nadie abrió un ticket para volver a agregar gráficas.

Cómo se ve "un solo dashboard" en la realidad

Una empresa de seguridad en la nube llevaba cinco años corriendo analytics de ingresos en una herramienta de BI heredada. Con el tiempo, el dashboard había ido acumulando gráficas de la misma forma que un repositorio acumula código comentado: gradualmente, a través de decisiones razonables, cada una perfectamente justificada por sí sola.

Ingresos por región. Ingresos por región, pero solo cuentas externas. Ingresos por región, pero solo el trimestre vigente. Ingresos por región, filtrado a las cinco cuentas principales. Los mismos datos de fondo, cuatro variaciones, cada una agregada porque alguien necesitaba un corte específico y era más rápido agregar una gráfica nueva que construir un filtro.

El resultado: una sola página con 86 gráficas. El tiempo de carga se medía en minutos, no en segundos. Y algo más concreto: el dashboard se había vuelto inutilizable para las personas a las que supuestamente servía.

El tiempo de carga empeoró todo de una forma particular: cuando un dashboard tarda 60 segundos en cargar, nadie hace scroll más allá de las primeras gráficas visibles. Todos construyeron su modelo mental de "dónde viven los datos" a partir de lo que aparecía al primer render. Las gráficas debajo del fold se volvieron prácticamente invisibles — nadie las usaba, pero todo el mundo las mantenía. Encontramos gráficas en la mitad inferior de la página que no habían sido referenciadas en ningún flujo documentado durante más de un año. Nadie las borraba porque nadie estaba seguro de que no las estuviera usando alguien más.

Cuatro categorías de expansión descontrolada explicaban esto:

Acumulación de variaciones. La misma métrica con distintos filtros, cada una agregada por una solicitud específica. "¿Puedes agregar esto pero excluyendo cuentas POC?" Tres meses después: "¿Puedes agregar esto pero con las cuentas POC en una vista separada?" Ambas sobreviven indefinidamente.

Mezcla de audiencias. Gráficas para la CFO junto con gráficas para el equipo de ventas junto con gráficas para el equipo de datos. Diferentes frecuencias de actualización, diferentes niveles de detalle, diferentes definiciones de "ingreso" — todo en la misma página.

Snapshots heredados. Gráficas que respondían preguntas de años fiscales pasados — cuando el modelo de precios era diferente, antes de que se agregara una categoría importante de clientes, durante un período en que cierta región se rastreaba por separado. Nadie recuerda por qué existen. Nadie las elimina.

El reflejo de "solo agrégalo". En cualquier herramienta de BI, el camino de menor resistencia es agregar una nueva gráfica. Reorganizar las existentes es trabajo estructural. La mayoría de los equipos siempre están demasiado ocupados para el trabajo estructural hasta que tienen que hacer una migración.

El framework de conservar/fusionar/eliminar

Al dimensionar la migración a Sigma, establecimos un framework de decisión para cada gráfica del sistema heredado. Tres opciones, aplicadas en secuencia.

Para cada gráfica:
1. ¿Los datos de fondo son válidos y confiables?
   NO → Eliminar (documentar por qué; no borrar silenciosamente)
2. ¿Esta gráfica es funcionalmente idéntica a una que ya vamos a conservar?
   SÍ → Fusionar (redirigir a stakeholders, no mantener dos versiones)
3. ¿Esta gráfica pertenece al mismo contexto que las gráficas adyacentes?
   NO → Conservar pero reubicar (audiencia distinta o contexto de decisión diferente)
   SÍ → Conservar y asignar a una página

La secuencia importa. No puedes fusionar gráficas hasta eliminar las construidas sobre datos malos. No puedes asignar páginas hasta haber fusionado los duplicados.

Criterios para eliminar. Una gráfica es candidata a eliminación si: la fuente de datos está deprecada, el período fiscal que cubre fue reemplazado, la definición de la métrica cambió y no se actualizó, o nadie puede identificar quién la pidió ni por qué. Documentamos cada eliminación con una línea de contexto — no para la posteridad, sino porque los stakeholders van a preguntar "¿qué pasó con la gráfica que mostraba X?" y "la eliminamos porque Y" es una respuesta mucho mejor que el silencio. Una gráfica eliminada sin documentación se convierte en historia de fantasmas. Una gráfica eliminada con una línea de contexto se convierte en un ticket cerrado.

Criterios para fusionar. Una gráfica es candidata a fusión si muestra la misma métrica que otra, filtrada de manera distinta. El destino de la fusión casi siempre es una gráfica con un filtro interactivo aplicado — lo que significa que el estado final tiene menos gráficas con más interactividad, no una pérdida de capacidad analítica. La fusión más común fue la de dashboards externos vs. internos: los analytics de la empresa habían crecido con dashboards separados para métricas orientadas al cliente externo y métricas internas de negocio. Al agregar un filtro de Tipo de Cuenta aplicado a todas las páginas, ambas vistas quedaron en un solo dashboard sin redundancia.

Criterios para conservar y reubicar. Una gráfica es candidata a reubicación si su audiencia o contexto de decisión no coincide con las gráficas adyacentes. Las gráficas de ARR a nivel de CFO no pertenecen a la misma página que el detalle de cuentas del equipo de ventas. No porque los datos estén mal, sino porque alguien que busca tendencias de ARR tiene un trabajo diferente al de alguien que revisa el patrón de uso de una cuenta específica. Nunca deberían estar en el mismo scroll.

Cómo organizamos 22 páginas

Después de aplicar el pase de conservar/fusionar/eliminar, las gráficas supervivientes cayeron en agrupaciones naturales. Seis dashboards, cada uno con una audiencia y propósito claros, organizados en páginas que coinciden con el flujo de trabajo real de los usuarios.

dashboards:
  revenue_analytics_original:
    purpose: "Precios v1 heredados — referencia histórica"
    pages: [overview, by_region, by_segment, reconciliation]
    audience: Finance, Analytics

  revenue_analytics_fy27:
    purpose: "Precios seed-driven — actual y proyección"
    pages: [overview, by_region, by_segment, reconciliation]
    audience: Finance, FP&A

  arr_dashboard_original:
    purpose: "Historial de ARR — base de cálculo heredada"
    pages: [arr_overview, cohort_analysis, churn_waterfall]
    audience: Finance, Revenue Operations

  arr_dashboard_fy27:
    purpose: "ARR con jerarquía de descuentos actualizada"
    pages: [arr_overview, cohort_analysis, churn_waterfall]
    audience: Finance, Revenue Operations

  accounts_revenue_usage:
    purpose: "Detalle por cuenta + métricas de uso"
    pages: [account_summary, revenue_detail, usage_detail,
            discount_analysis, regional_breakdown, data_audit]
    audience: Deal Desk, Customer Success, Analytics

  invoice_comparison:
    purpose: "Conciliación contra facturas de socios"
    pages: [comparison_overview, variance_detail]
    audience: Finance, Revenue Operations

La convención de nombres fue deliberada. Cada nombre de dashboard dice qué es y para quién es. Cada nombre de página dice qué pregunta responde. Cuando llegas al dashboard, sabes de inmediato si estás en el lugar correcto.

La configuración de alcance de filtros evitó toda una categoría de confusión. En el sistema heredado, un filtro aplicado a una gráfica era solo eso — una gráfica. Filtrabas por período y veías cómo doce gráficas se actualizaban mientras ocho no lo hacían. Configuramos el alcance de los filtros de Sigma a "todas las páginas" para los filtros globales: tipo de cuenta, período fiscal, región. Los filtros que debían ser locales — un filtro de drill específico de una gráfica — se delimitaron explícitamente para evitar contaminación.

# Configuración de alcance de filtros en Sigma (conceptual)
filtros_globales:
  - tipo_cuenta: alcance=todas_las_paginas
  - periodo_fiscal: alcance=todas_las_paginas
  - region: alcance=todas_las_paginas

filtros_locales:
  - drill_detalle_cuenta: alcance=pagina_actual
  - periodo_comparacion: alcance=pagina_actual

El alcance incorrecto de filtros fue uno de los 15 bugs que documentamos durante la migración — las gráficas en las páginas de ARR ignoraban los filtros de período global porque el alcance estaba configurado a "página actual" por defecto. Corregir ese bug retroactivamente fue más difícil que diseñar para ello desde el principio.

La implementación: migrar con stakeholders activos

La migración corrió en paralelo con el uso activo del sistema heredado. Finanzas sacaba números de los dashboards legacy mientras construíamos los reemplazos en Sigma. Esa restricción moldeó todo el enfoque de entrega.

Construimos en paralelo, validamos por replicación, y cortamos solo después de confirmar paridad a nivel de gráfica. El patrón de consulta de validación — un FULL OUTER JOIN entre el output antiguo y el nuevo — está descrito en detalle en nuestro post sobre validación de migraciones de datos financieros.

La estructura de páginas se construyó con un esquema de nombres que hacía imposible mezclar accidentalmente vistas de producción y desarrollo:

-- Targets de base de datos por colaborador
-- dev_arturo  → DBT_DEV__ARTURO (lead del proyecto)
-- dev_shared  → DWH_DB_DEV      (demo / preview para stakeholders)
-- prod        → DWH_DB          (solo CI/CD, requiere CI=true)

-- Macro de seguridad en producción — bloquea ejecuciones directas fuera de CI
{% macro validate_dev_target() %}
  {% if target.name == 'prod' and env_var('CI', 'false') != 'true' %}
    {{ exceptions.raise_compiler_error(
      "Ejecuciones directas en prod bloqueadas. Usa el pipeline de CI."
    ) }}
  {% endif %}
{% endmacro %}

El entorno dev compartido le permitió a Finanzas previsualizar la nueva estructura de dashboards antes del cutover sin tocar datos de producción. Esa preview fue como detectamos dos problemas organizacionales antes de que se convirtieran en quejas — una página que Finanzas esperaba encontrar bajo "Revenue" estaba bajo "ARR", y una vista de conciliación que pertenecía al dashboard de comparación de facturas había quedado en el dashboard de cuentas porque habíamos organizado por tema técnico en lugar del flujo de trabajo real de Finanzas.

La participación del equipo de Finanzas en la preview también moldeó la capa de autoservicio. Cuando los nuevos dashboards salieron en vivo, Finanzas podía actualizar las tarifas directamente en las tablas de input de Sigma en lugar de abrir tickets de ingeniería — un flujo documentado completo en nuestro post sobre cómo darle autoservicio de analytics al equipo de Finanzas. La estructura del dashboard y el modelo de autoservicio se refuerzan mutuamente: las páginas organizadas facilitan encontrar las tablas de input; las tablas de input le dan a Finanzas una razón para abrir los dashboards sin esperar un data pull.

Manejo de stakeholders: estás borrando cosas que la gente usa

El trabajo técnico es la mitad menor de la consolidación de dashboards. La mitad mayor es organizacional.

Cuando eliminas una gráfica, el flujo de trabajo de alguien se rompe. Quizás tenían la URL en favoritos. Quizás capturaban pantalla de la misma gráfica cada lunes para un reporte semanal. Quizás la gráfica estaba mal y llevaban meses ajustando los números manualmente — eso es su propia conversación, pero igual rompe su rutina.

Tres cosas hicieron que la transición con stakeholders fuera manejable.

Anuncia la lista de eliminaciones antes del cutover. Publicamos la lista de gráficas que se eliminarían dos semanas antes del cutover, con la razón de cada eliminación y qué la reemplazaba. Suena obvio. La mayoría de las migraciones no lo hacen. El resultado de no hacerlo es una ola de preguntas de "¿dónde quedó X?" después del lanzamiento, cada una requiriendo investigación individual. El resultado de hacerlo es un puñado de preguntas antes del lanzamiento, la mayoría de las cuales lleva a reconsideraciones legítimas ("en realidad esa gráfica aparece en la presentación del consejo, no la elimines").

Haz un recorrido de 30 minutos para cada audiencia. Finanzas tuvo un recorrido de los dashboards de ingresos y ARR. El equipo de ventas tuvo un recorrido del dashboard de cuentas. No una sesión genérica de "aquí está el nuevo sistema" — una sesión específica de "así es como encuentras los números que buscas todos los días". La reacción más común fue alivio. El tiempo de carga cayendo de 60 segundos a menos de 3 segundos fue inmediatamente perceptible. El recorrido también sirvió como auditoría final: Finanzas decía "espera, ¿dónde está el cohort mensual de ARR?" y o les mostrábamos dónde estaba, o aprendíamos que nos habíamos saltado algo. Dos gráficas volvieron a las páginas principales basándose en el feedback del recorrido. Es mejor resultado que descubrir el hueco tres semanas después del lanzamiento.

Mantén un mapa de redirección por 90 días. Cada gráfica eliminada tuvo una entrada de una línea en un documento compartido: qué era, por qué se eliminó, dónde vive ahora el equivalente. Esto costó unas dos horas armarlo y eliminó la mayor parte de la carga de soporte post-lanzamiento. El mapa de redirección no es documentación para la posteridad. Es un período de gracia de 90 días. Después de 90 días, si nadie consultó algo, no se estaba usando.

# Mapa de Redirección de Dashboards — cutover 2026-01-15
# Fecha de revisión: 2026-04-15

| Gráfica Heredada | Eliminada Porque | Nueva Ubicación |
|---|---|---|
| Ingresos por Región (Externo) | Fusionada — filtro de Tipo de Cuenta reemplaza gráfica separada | ARR Dashboard > Overview, filtro: External |
| ARR por Segmento (sin POC) | Duplicado — la gráfica existente tiene toggle de POC | Revenue Analytics > By Segment |
| Desglose Regional Producto A (2022) | Período de precios deprecado — datos superados por modelo v2 | N/A — datos históricos archivados en data warehouse |
| Cambio ARR Mes a Mes | Fusionada en página de Cohort Analysis con comparación de período | ARR Dashboard > Cohort Analysis |

Qué haríamos diferente

El pase de conservar/fusionar/eliminar es más útil cuando se hace antes de abrir la herramienta de migración. Lo empezamos temprano, pero no lo suficiente — la estructura del dashboard estaba parcialmente construida antes de terminar el análisis organizacional, lo que requirió dos rondas de reestructuración de páginas ya construidas.

La lección: la decisión de arquitectura de páginas es upstream de todo. Tener audiencia, propósito y estructura de páginas acordados en papel antes de construir en Sigma ahorró más tiempo que cualquier optimización técnica.

Una categoría que subestimamos fue la fusión de Externo/Interno. Los dashboards separados habían existido por buenas razones históricas — las métricas externas en algún momento requirieron un modelo de datos fundamentalmente diferente, y la separación tenía significado organizacional para distintos equipos. La fusión fue técnicamente directa (agregar un filtro de Tipo de Cuenta), pero el cambio organizacional requirió aprobación explícita tanto de Finanzas como del lead de analytics. Un cambio técnico que parece una simplificación puede tener peso organizacional. Sácalo a la superficie temprano.

Algo que agregaríamos al recorrido con stakeholders: un lado a lado "antes y después" de las tres gráficas que más usa cada audiencia. Las declaraciones abstractas sobre "tiempos de carga más rápidos" y "mejor organización" aterrizan diferente cuando alguien ve su gráfica de los lunes en la nueva ubicación, cargando en menos de tres segundos, con el filtro que siempre quiso ya integrado. lo concreto siempre pesa más.

El patrón más amplio — el que aplica a cualquier proyecto de consolidación de BI — es que la proliferación de dashboards es síntoma de infraestructura de filtros deficiente. Cada decisión de "solo agrega una gráfica nueva" es una decisión tomada en ausencia de un buen filtro. Arregla la infraestructura de filtros primero. El número de gráficas se reduce naturalmente.

Esa es también la razón por la que los 15 bugs que encontramos durante la validación valió la pena encontrarlos, aunque varios fueran incómodos de sacar a la luz. Un filtro con alcance incorrecto en "página actual" en lugar de "todas las páginas" significa que Finanzas llevaba leyendo números filtrados en algunas gráficas y números sin filtrar en las adyacentes — y llamando a ambos "ingresos". Consolidar la estructura del dashboard sin corregir el comportamiento subyacente habría consolidado la confusión en lugar de resolverla.

La transición de 86 a 22 no fue principalmente un logro técnico. Fue organizacional. El trabajo técnico fue construir los nuevos dashboards; esa parte fue directa. El trabajo real fue ponerse de acuerdo en para qué eran los dashboards, quién los iba a usar, y qué significaba "terminado" desde la perspectiva del usuario — no del constructor.

Esa conversación casi siempre se omite. El resultado son nuevas gráficas en una nueva plataforma que se acumulan igual que las anteriores. Seis meses después del lanzamiento tienes 40 gráficas en una página de Sigma y un equipo preguntándose si es momento de otra migración.

La diferencia entre dashboards que se mantienen organizados y dashboards que se descontrolan está en si las decisiones organizacionales — audiencia, propósito, alcance de filtros, estructura de páginas — se hicieron explícitas durante la construcción, o se dejaron implícitas para que cada colaborador las reconstruyera por contexto. Las decisiones explícitas sobreviven la rotación de equipo. Las implícitas no.

La proliferación de dashboards tiene solución. Solo requiere hacer el trabajo que omitiste la primera vez: decidir para qué es cada gráfica antes de construirla, no después.

Si tus dashboards tienen más gráficos de los que alguien puede usar y tiempos de carga que ponen a prueba la paciencia, podemos hacer una auditoría en unos días. Agenda una revisión de dashboards.