Gobierno del dato para reporting y KPIs

«El margen bruto que sale en el dashboard de ventas no coincide con el que calcula finanzas.» Esta conversación se repite en cada comité de dirección de empresas que han empezado a usar dashboards pero no han definido quién decide cómo se calculan las métricas. El resultado es que nadie confía en los números, cada departamento tiene su propia versión y las reuniones se convierten en debates sobre quién tiene la cifra correcta en lugar de debates sobre qué hacer con la cifra.

Este problema no se resuelve con mejor tecnología ni con un dashboard más bonito. Se resuelve con gobierno del dato aplicado al reporting: definir quién es responsable de cada KPI, cómo se calcula, qué datos lo alimentan y cómo se resuelven las discrepancias.

¿Por qué los KPIs discrepan entre departamentos?

Las discrepancias no son errores. Son consecuencias naturales de que cada departamento tiene necesidades legítimas de medir las cosas de forma distinta:

• Finanzas calcula el margen bruto incluyendo costes de transporte y descuentos. Comercial lo calcula solo con precio de venta menos coste de producto. Ambos tienen razón, pero están midiendo cosas distintas con el mismo nombre.
• Operaciones mide el OTIF (on time in full) considerando el plazo original del pedido. Comercial lo mide desde que el cliente confirma la entrega como satisfactoria. Ambas definiciones son válidas, pero producen cifras diferentes.
• Marketing cuenta como «lead» a cualquier persona que rellena un formulario. Comercial solo cuenta como lead a los que cumplen ciertos criterios de cualificación. El pipeline de leads tiene cifras muy distintas según quién lo mire.

El problema no es que haya definiciones distintas. El problema es que coexisten sin que nadie lo sepa o sin que haya una definición oficial que todos compartan.

¿Qué es el gobierno del dato aplicado a KPIs?

Gobernar las métricas de reporting no significa crear un comité burocrático ni un documento de 200 páginas. Significa tener claro, para cada KPI relevante:

1. 1Definición oficial: cómo se calcula exactamente, con qué fórmula, incluyendo qué datos entran y cuáles se excluyen. Escrita en lenguaje de negocio, no en SQL.
2. 2Propietario del KPI: la persona o rol que tiene la autoridad para decidir la definición. Si hay discrepancia, esta persona arbitra.
3. 3Fuente de datos: de qué sistema o tabla proviene cada dato que alimenta el KPI. Si hay varias fuentes posibles, cuál es la oficial.
4. 4Frecuencia de actualización: con qué periodicidad se calcula (diaria, semanal, mensual) y con qué retraso respecto al cierre del periodo.
5. 5Consumidores: quién usa este KPI, en qué informes aparece y para qué decisiones se utiliza.

Esta información cabe en una tabla. No necesitas un proyecto de meses: necesitas una sesión de trabajo con los responsables de cada área para acordar las definiciones de los 10-15 KPIs que aparecen en los informes de dirección.

¿Cómo definir el propietario de cada KPI?

La pregunta clave es: ¿quién tiene la responsabilidad última de que esta métrica refleje la realidad del negocio? La respuesta suele ser:

• Métricas financieras (margen, EBITDA, coste por unidad): el CFO o la dirección financiera.
• Métricas operativas (OTIF, productividad, eficiencia): el COO o la dirección de operaciones.
• Métricas comerciales (pipeline, conversión, ticket medio): el director comercial.
• Métricas de cliente (NPS, churn, satisfacción): el responsable de experiencia de cliente o el director comercial.

El propietario no es quien introduce los datos ni quien construye el dashboard. Es quien decide la definición y valida que los números son correctos. Si nadie asume ese rol, el KPI será un campo de batalla permanente.

¿Cuáles son los errores más comunes en la gestión de KPIs?

1. 1Definir los KPIs en el dashboard, no en el modelo de datos. Si la fórmula del margen bruto está en una medida de Power BI que creó un consultor hace un año, nadie sabe exactamente cómo se calcula. La definición debe estar documentada fuera de la herramienta de BI, en un sitio accesible para todos.
2. 2No resolver las discrepancias, solo añadir variantes. En lugar de decidir qué definición de margen bruto es la oficial, se crean tres versiones: «Margen bruto (finanzas)», «Margen bruto (comercial)», «Margen bruto (dirección)». Esto multiplica la confusión en lugar de resolverla.
3. 3Asumir que IT puede decidir la definición. El equipo de IT o de datos puede implementar la definición, pero no puede decidirla. La definición de «qué es un cliente activo» o «cómo se calcula el OTIF» es una decisión de negocio, no técnica.
4. 4No comunicar los cambios. Si la definición de un KPI cambia (por ejemplo, se decide incluir los costes de devolución en el margen), todos los consumidores del dashboard deben saberlo. Un KPI que cambia de definición sin aviso destruye la confianza en los datos.

¿Cómo implementar gobierno de KPIs sin burocracia?

El proceso más pragmático que hemos encontrado es este: una sesión de trabajo de medio día con los responsables de cada área, una tabla con las definiciones acordadas y la asignación de propietarios, y la implementación de esas definiciones en el modelo de datos del data warehouse o de la herramienta de BI. A partir de ahí, cualquier cambio de definición pasa por el propietario del KPI. Es gobierno del dato en su forma más simple y más efectiva. Si necesitas ayuda para montar este proceso, en nuestro servicio de gobierno del dato y calidad incluimos la definición y estandarización de KPIs como uno de los primeros entregables, y en la consultoría de Power BI la auditoría del modelo de datos incluye la revisión de todas las métricas y sus definiciones.

KPIs del gobierno del dato por tipo de activo

El gobierno del dato se mide distinto segun el tipo de activo. Un dashboard ejecutivo tiene KPIs distintos que un pipeline de ingesta o que un informe regulatorio. Sin esta segmentacion, los KPIs genericos ('% registros con calidad buena') no dicen nada util. El enlace con calidad de datos en Power BI ayuda a concretar las reglas en informes operativos.

• Dashboards ejecutivos: % variacion entre fuentes (ERP vs contabilidad), tiempo desde ultimo refresh, % metricas con owner firmado.
• Pipelines de datos: SLA de freshness (ej. datos del dia anterior listos a las 7:00), tasa de errores de carga, tiempo medio de resolucion de incidencias.
• Informes regulatorios (RGPD, AEAT, AI Act): trazabilidad de la respuesta (linaje), % campos documentados, % informes validados por el DPO/compliance.
• Catalogo de datos: % activos catalogados, % con owner asignado, % con politica de acceso documentada.

Plantilla practica para documentar KPIs

Cada KPI que aparezca en un dashboard debe tener su ficha de definicion. No necesita ser un documento extenso; una tabla con siete campos es suficiente para evitar el 90% de las discrepancias entre areas.

• Nombre del KPI: como se llama y como aparece en el dashboard. Debe ser unico y no ambiguo.
• Definicion: que mide exactamente. Ejemplo: "Margen bruto = (Ventas netas - COGS) / Ventas netas". Sin formula, no hay definicion.
• Fuente de datos: de que tabla y de que sistema se extrae cada campo. Si el dato viene de dos sistemas, cual prevalece.
• Propietario: quien es responsable de que la definicion sea correcta y de que el dato se actualice a tiempo.
• Frecuencia: cada cuanto se actualiza el KPI (diario, semanal, mensual) y cuando esta disponible.
• Umbral de alerta: a partir de que valor el KPI indica un problema que requiere accion.
• Consumidores: que areas o personas usan este KPI para tomar decisiones.

El valor de esta ficha no es la documentacion en si, sino la conversacion que obliga a tener. Cuando ventas y finanzas se sientan a definir juntos como se calcula el margen, descubren que cada uno usaba una formula diferente. Esa conversacion, no la herramienta, es lo que resuelve las discrepancias.

Para mas contexto, puedes consultar la guia de Gartner sobre calidad de datos.