Español

SQL y diseño de paneles de control que generan confianza en las partes interesadas

El CEO abre el panel de control de ingresos el lunes por la mañana. Hay 14 gráficos. Tres de ellos tienen la palabra "ingresos" en el título. Muestran números diferentes. Le escribe por Slack: "espera, ¿qué significa 'ingresos' aquí?" Usted pasa 30 minutos explicando la diferencia entre reservado, reconocido y cobrado. Le agradece, cierra la pestaña y vuelve al export de Stripe que le envió su responsable de finanzas porque al menos ese número no discute consigo mismo.

Ese panel de control no falló porque tuviera demasiados gráficos. Falló porque dos de esos gráficos decían cosas diferentes y nadie en la sala podía defender ninguno de los dos.

El dolor en el trabajo de BA no es el volumen. Es que cada panel de control que publica es una promesa (este es el número, puede actuar sobre él), y la mayoría de los BA publica esa promesa sin hacer el trabajo que la hace defendible. Este artículo trata sobre ese trabajo. Los patrones SQL, las decisiones de diseño, la higiene de dbt y la disciplina de retirada que transforman una cocina de 14 gráficos en un número sobre el que una parte interesada apostará el presupuesto de un trimestre.

Diseño de paneles de control: una decisión por panel de control

La pregunta más útil antes de construir cualquier cosa: ¿qué acción impulsa este panel de control?

Si la parte interesada no puede completar la oración "después de ver esto, voy a..." en inglés sencillo, no tiene un panel de control. Tiene papel tapiz. Elimínelo o divídalo.

Una decisión por panel de control. No tres. El panel de control de ARR responde "¿estamos en el plan este trimestre?" El panel de control de cobertura del pipeline responde "¿tenemos suficientes acuerdos para alcanzar el próximo trimestre?" Esas son decisiones diferentes, audiencias diferentes, cadencias diferentes. No pertenecen al mismo lienzo solo porque ambas involucran ventas.

Jerarquía visual: la regla de los 2 segundos

Cuando carga el panel de control, el ojo de la parte interesada debe posarse en la respuesta en menos de 2 segundos. Eso significa:

  • Arriba a la izquierda: el número titular. Grande, en negrita, con la comparación integrada ($4.2M ARR · +6% vs plan). No "Revenue YTD" con un gráfico de líneas debajo que hay que leer.
  • Debajo del titular: 2 a 4 cortes de apoyo que expliquen por qué el titular es lo que es. Por segmento, por región, por movimiento. No 12 cortes. Cuatro.
  • Desglose en pestañas o clic de navegación: quien quiera la cola larga puede llegar allí. No fuerce a la vista predeterminada a cargar con ello.

Si el número titular de su panel de control está en el gráfico 7 de 14, ha invertido la pirámide. La mayoría de los BA lo hace porque temen dejar algo fuera. Tema más que las partes interesadas no sepan qué mirar.

Disciplina de color: deje de construir bolsas de caramelos

La mayoría de los paneles de control de BA son una bolsa de caramelos de colores. Ocho colores categóricos, tres colores de acento, un mapa de calor, dos paletas divergentes y un semáforo, todo en una misma página. Eso es ruido, no señal.

Elija una restricción y manténgala:

  • Un color de acento para "bueno" (normalmente un verde o azul de marca).
  • Un color de acento para "alerta" (normalmente rojo o naranja).
  • Todo lo demás es escala de grises neutro.

Si se encuentra buscando un cuarto color, el problema no es que necesite más colores. El problema es que está tratando de mostrar demasiadas cosas en un solo gráfico. Divida el gráfico.

Las anotaciones superan a las leyendas

Una leyenda es algo que la parte interesada tiene que leer, decodificar y recordar. Una anotación es el gráfico hablándole directamente.

Un subtítulo de dos líneas junto a una caída en Q3 ("Caída en Q3 = cambio de precios publicado el 14 de agosto, se espera recuperación para Q4") previene el 80% de los mensajes de seguimiento en Slack. El otro 20% son sobre algo para lo que el panel de control no fue construido, lo cual también es información útil.

Convierta las anotaciones en un hábito. Cada gráfico con una forma no obvia recibe una explicación de una oración en el propio gráfico, no en un documento separado que nadie lee.

Prácticas de SQL que publican confianza

El panel de control es la puerta principal. El SQL subyacente es la base. Las partes interesadas no ven el SQL, pero lo sienten cada vez que el número cambia y usted no puede explicar por qué.

CTEs sobre subconsultas anidadas

Compare estas dos consultas que hacen lo mismo:

-- La versión con subconsulta anidada (no haga esto)
SELECT customer_id,
       SUM(amount) AS revenue
FROM (
  SELECT *
  FROM orders
  WHERE status = 'paid'
    AND created_at >= '2026-01-01'
    AND customer_id IN (
      SELECT id FROM customers
      WHERE region = 'NA'
        AND tier IN ('enterprise', 'mid-market')
    )
) paid_orders
GROUP BY customer_id;

-- La versión con CTE (haga esto)
WITH na_target_customers AS (
  SELECT id
  FROM customers
  WHERE region = 'NA'
    AND tier IN ('enterprise', 'mid-market')
),

paid_orders_2026 AS (
  SELECT customer_id, amount
  FROM orders
  WHERE status = 'paid'
    AND created_at >= '2026-01-01'
)

SELECT po.customer_id,
       SUM(po.amount) AS revenue
FROM paid_orders_2026 po
JOIN na_target_customers c
  ON po.customer_id = c.id
GROUP BY po.customer_id;

Mismo resultado. La versión con CTE tiene nombres. Un colega puede leerla en 30 segundos. La versión anidada es un rompecabezas. Una consulta que un colega no puede leer en 30 segundos es una consulta que se romperá silenciosamente en 6 meses cuando alguien cambie la definición del nivel de cliente y nadie lo note porque no podían encontrar el filtro.

Los CTEs le cuestan cuatro líneas extra y le compran una consulta que sobrevive a la rotación del equipo.

Modelos dbt de fuente única de verdad

Si revenue se calcula en cuatro paneles de control, divergirá en cuatro paneles de control. No "podría." Lo hará. Alguien ajustará uno para excluir los reembolsos. Alguien más ajustará otro para incluir las conversiones de prueba. Seis meses después, cuatro paneles de control muestran cuatro números y la confianza se ha perdido.

Centralice la métrica en un modelo dbt. Un archivo. Una definición. Luego cada panel de control, cada exploración de Looker, cada notebook de Hex hace referencia a ese modelo y solo a ese modelo. Si finanzas quiere cambiar cómo se calcula el ingreso, lo cambia una vez, y cada artefacto dependiente se actualiza.

Esto no es un deseable. Es la diferencia entre un equipo de BA que escala y un equipo de BA que pasa el Q4 de cada año reconciliando números en los que nadie cree.

Pruebas nombradas en cada modelo de métrica

dbt le proporciona cuatro pruebas integradas que detectan la mayor parte de la deriva silenciosa:

version: 2

models:
  - name: fct_revenue_recognized
    description: "Ingresos reconocidos según la política GAAP de la empresa. Propietario: finance-data."
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('dim_customers')
              field: customer_id
      - name: revenue_status
        tests:
          - accepted_values:
              values: ['recognized', 'deferred', 'refunded']

Ejecútelas en cada PR. Si alguien agrega un nuevo valor de revenue_status en el sistema upstream y olvida actualizar el modelo, la prueba falla antes de que lo haga el panel de control. La primera vez que una prueba not_null detecta un error en los datos de producción, se preguntará cómo alguna vez publicó sin ella.

Comente el por qué, no el qué

-- Incorrecto: le dice lo que el código ya dice
WHERE status = 'paid'

-- Correcto: le dice por qué existe la regla
-- Finanzas excluye los reembolsos procesados más de 30 días después del pedido
-- según la política de ingresos v3 (firmada por CFO en Q4 2025).
WHERE status = 'paid'
  AND NOT (status_changed_at > created_at + INTERVAL '30 days'
           AND status = 'refunded')

El comentario incorrecto es ruido. El comentario correcto es lo único que salvará al próximo BA que herede esta consulta en un año. Escriba el por qué. Especialmente para cualquier regla de negocio que no sea obvia a partir del nombre de la columna.

El diagnóstico de "dos definiciones de ingresos"

Aquí está el movimiento de creación de confianza más útil que un BA puede hacer en sus primeros 90 días, y no implica escribir un solo panel de control.

Vaya con su responsable de finanzas. Pregúntele, en una llamada, "¿cómo calculamos los ingresos?" Anote la respuesta.

Vaya con su responsable de ventas. Haga la misma pregunta. Anote la respuesta.

Le darán dos respuestas diferentes.

Ventas le hablará del ACV reservado: acuerdos cerrados, contratos firmados, el número en el marcador. Finanzas le hablará de los ingresos reconocidos: efectivo cobrado neto de reembolsos, diferido según la política, el número que va a la junta. Ambos son correctos. Ambos son reales. Están respondiendo preguntas diferentes. Y ahora mismo, en algún lugar de su empresa, un panel de control muestra uno de ellos y lo llama "ingresos" sin decir cuál.

Documente ambos. Nómbrelos claramente en el modelo dbt:

-- fct_revenue_finance.sql -- reconocido según política GAAP v3
-- fct_revenue_sales_booked.sql -- ACV reservado en la fecha de cierre del acuerdo

Exponga ambos en su capa de BI. Deje que la parte interesada elija el que corresponda a su pregunta. Cuando el CEO pregunte "¿cómo van los ingresos?", usted repregunta: "¿reservado o reconocido?" Se detendrá. Pensará. Le dará la respuesta correcta, y a partir de ese momento usted es la persona en la que confía porque lo hizo sentir competente en lugar de confundido.

Este diagnóstico también le dice qué área de la organización es más descuidada con las definiciones, lo cual es información que usará durante los próximos dos años.

Panel de control versus extracción puntual: cuándo construir, cuándo hacer una captura de pantalla

No toda pregunta merece un panel de control. El valor predeterminado en la mayoría de las organizaciones de BA es "la respuesta a una pregunta es un nuevo panel de control", y así es como se termina con más de 200 paneles de control sin saber cuáles 30 se usan realmente.

La heurística es simple. ¿Se volverá a hacer esta pregunta en 30 días?

  • Sí -> panel de control. Vale el compromiso de mantenimiento.
  • No -> consulta SQL, captura de pantalla, compártala en Slack, listo. No contamine la biblioteca de paneles de control con una extracción puntual para la junta.

Cada panel de control que construye es un compromiso de mantenimiento de 6 meses. Las tablas fuente cambian. Las definiciones derivan. Las partes interesadas cambian de equipo. Le pedirán que lo arregle. Rechace adecuadamente.

El guion para rechazar el panel de control:

"Con gusto lo extraigo como extracción puntual. Le envío el gráfico en Slack antes del fin del día. Si esta se convierte en una pregunta recurrente (la hace de nuevo el mes próximo), lo revisamos y lo construyo correctamente con documentación. Por ahora, construir un panel de control para una pregunta que se hace una sola vez añadiría una carga de mantenimiento que no se amortiza."

Envíe eso a una parte interesada una vez y le respetará más, no menos. Construir todo es una señal de que no valora su propio tiempo, lo que significa que ellos tampoco lo harán.

Control de versiones y disciplina del registro de cambios

Todo el SQL vive en git. Sí, su LookML de Looker. Sí, su notebook de Hex (o copie el SQL en un repositorio). Sí, sus modelos dbt, obviamente. Si un número en un panel de control puede cambiar, el cambio tiene que ser revisable.

Dos reglas que detectan la mayoría de los desastres:

  1. Revisión por dos personas en cambios de métricas. Cualquier PR que toque un modelo fct_* o dim_* es revisado por otro analista antes de la fusión. No un manager. Un colega que realmente leerá el SQL. Esto detecta la deriva silenciosa de definiciones que destruye la confianza.

  2. Tarjeta de registro de cambios fijada en cada panel de control. En la parte superior del panel de control, siempre visible:

Registro de cambios -- Seguimiento de ARR
2026-04-15: Se cambió la fuente de ingresos de Stripe a NetSuite.
            Los números pueden diferir de las capturas de pantalla anteriores en aprox. 2%.
            Propietario: camellia. PR: #1842.
2026-02-03: Se agregó desglose por nivel enterprise.
2025-11-20: Construcción inicial.

Cuando una parte interesada hace una captura de pantalla del panel de control en marzo y pregunta por qué es diferente en mayo, el registro de cambios responde la pregunta sin que usted tenga que hacerlo.

La revisión de retirada de 6 meses

La mayoría de las organizaciones de BA tienen más de 200 paneles de control y usan 30. Los otros 170 son lastre: confundieron a los nuevos empleados, hicieron que los ejecutivos dudaran de los activos activos, consumieron créditos de consulta en el almacén de datos. La limpieza es parte del trabajo.

Configure un recordatorio de calendario cada 6 meses. Ejecute una consulta contra el registro de auditoría de su herramienta de BI:

-- Ejemplo para Looker
SELECT dashboard.title,
       dashboard.id,
       MAX(history.created_at) AS last_opened,
       COUNT(DISTINCT history.user_id) AS unique_viewers_180d
FROM history
JOIN dashboard ON history.dashboard_id = dashboard.id
WHERE history.created_at > CURRENT_DATE - INTERVAL '180 days'
GROUP BY 1, 2
ORDER BY last_opened ASC;

El resultado ordena sus paneles de control de más obsoleto a menos obsoleto. Aplique la regla:

  • No abierto en 90 días -> archive. Sin discusión.
  • Abierto por 1 o 2 personas -> envíeles un DM. "¿Sigue necesitando esto? Si es sí, lo conservo. Si es no, lo archivo el viernes." La mayoría dirá que lo archive.
  • Abierto por 5 o más personas regularmente -> consérvelo, y asegúrese de que esté en su lista de mantenimiento.

Publique la lista de eliminación en un canal de Slack público antes de archivar. Da a las partes interesadas 48 horas para objetar. Casi nunca lo hacen.

Un equipo de BA que hace esto dos veces al año pasa de 200 paneles de control a 40, y los 40 que quedan son los que los ejecutivos realmente consultan. La mejora de la relación señal a ruido es enorme, y usted se convierte en conocido como el equipo que publica menos, lo cual suena contraintuitivo hasta que ve cómo sube el medidor de confianza.

Cierre: la confianza es un resultado del oficio

La confianza no es un rasgo de personalidad. No se trata de ser encantador en las reuniones con las partes interesadas, de decir siempre que sí o de ser el BA servicial. Esas cosas ayudan, pero se desvanecen. Lo que perdura es el oficio.

El BA que puede responder "¿de dónde viene esto, quién más lo usa, cuándo fue el último cambio?" en 10 segundos es el BA que los ejecutivos conservan en los proyectos estratégicos. El BA que no puede es silenciosamente degradado a "mono de consultas ad hoc" y nunca se recupera, sin importar lo amigable que sea.

Construya para una decisión. Mantenga la línea de color. Centralice sus métricas. Pruébelas. Comente el por qué. Pregunte ambas definiciones de ingresos. Rechace los paneles de control que no se ganen su lugar. Fije el registro de cambios. Archive con regularidad.

Ese es el trabajo completo. Ejecute esos movimientos de manera consistente durante dos años y no tendrá que pedir un lugar en la mesa de estrategia. Lo reservarán para usted.

Aprenda más