Un catálogo de métricas es la lista gobernada de los KPI del negocio, donde cada métrica tiene un nombre acordado, una fórmula exacta, un grano válido, un propietario y un registro de cambios. Deja de existir cuando cada equipo guarda su propia definición en una hoja aparte.
En muchas empresas la discusión no es sobre los datos, sino sobre las definiciones. Ventas cuenta ingresos por pedido facturado, finanzas los cuenta al cobrar, dirección los mira netos de devoluciones. Los tres tienen razón dentro de su propia hoja, y ninguno decide sobre la misma base. El catálogo de métricas es la pieza que corta ese problema de raíz.
Por qué el catálogo es gobierno y no un anexo
El catálogo de métricas no es documentación de apoyo que se escribe al final. Es una pieza de gobierno. Cada KPI relevante necesita una definición capaz de sostener tres usos al mismo tiempo: la conversación de comité, el cálculo técnico y el uso diario en un informe o en Excel. Sin esa definición común, la empresa gasta reuniones debatiendo qué número es el correcto en lugar de decidir con él.
Esto se vuelve más crítico cuando entra la IA. Una métrica que va a Power BI, a Excel, a Copilot o a un agente de datos necesita nombre de negocio, descripción, propietario y ejemplos de uso. Las medidas auxiliares, los selectores, los títulos dinámicos y las tablas técnicas deben quedar ocultos o fuera del esquema expuesto, porque un modelo mal preparado no confunde solo a las personas: confunde también a la IA que lee ese esquema. La preparación para IA pertenece al modelo, no al informe.
Los campos que convierten una definición suelta en una ficha
Una ficha de métrica es más que una fórmula. Estos son los campos que la hacen usable y gobernable:
| Campo | Contenido | Por qué importa |
|---|---|---|
| Nombre de negocio | Cómo se nombra la métrica en comité, ventas, finanzas u operaciones | Reduce las traducciones entre equipos |
| Fórmula | Cálculo exacto: filtros, exclusiones, moneda, impuestos, devoluciones y período | Evita que existan varias verdades |
| Grano | Nivel mínimo válido: día, pedido, línea, cliente, oportunidad, ticket | Evita sumar lo que no se debe sumar |
| Propietario | Persona o área que valida la definición y acepta cambios | Hace gobernable la evolución |
| Consumos | Dónde aparece: informe, Excel, Scorecard, Copilot, alerta o aplicación | Permite medir impacto y riesgo de un cambio |
| Dirección de tendencia | Si subir es bueno, bajar es bueno, o si necesita una regla propia | Permite colorear variaciones y objetivos sin codificar cada visual por separado |
| Targets y escenarios | Objetivo, presupuesto, previsión, periodicidad y propietario | Conecta el BI con la gestión: contra qué compromiso se compara |
La columna de consumos suele ser la que más sorprende. Sin ella, nadie sabe qué se rompe cuando alguien ajusta la fórmula. Con ella, un cambio de definición se vuelve una decisión con impacto conocido en vez de una sorpresa que aparece en el comité del mes siguiente.
El grano y la fórmula son las decisiones que evitan las falsas verdades
Dos campos concentran casi todos los conflictos. El primero es la fórmula: no basta con decir "ingresos". Hay que fijar si es bruto o neto, con o sin impuestos, en qué moneda, con qué tipo de cambio, incluyendo o excluyendo devoluciones, y sobre qué período. Cada una de esas decisiones, si se deja implícita, genera una verdad paralela.
El segundo es el grano: el nivel mínimo al que la métrica es válida. Una métrica definida a nivel de pedido no se puede sumar directamente a nivel de línea sin volver a pensar el cálculo. Documentar el grano evita agregaciones que producen números plausibles pero incorrectos, que son los más peligrosos porque nadie los cuestiona.
Dónde vive el catálogo: el modelo semántico como contrato
Un catálogo no puede vivir en una hoja de cálculo suelta, porque ahí vuelve a divergir. Vive dentro del modelo semántico, que actúa como el contrato común de las métricas del negocio. La documentación de modelos semánticos en Fabric explica cómo centralizar medidas y relaciones en un modelo explícito, separado de los elementos de datos crudos. Ese es el lugar correcto para que la definición sea única.
Microsoft dejó de crear automáticamente modelos semánticos predeterminados para nuevos lakehouses y warehouses, y esa decisión apunta en la misma dirección: conviene trabajar con modelos explícitos, nombrados y gobernados, no con modelos implícitos que después nadie sabe mantener. El catálogo de métricas es lo que le da nombre y dueño a ese modelo. Si quieres profundizar en cómo se estructura esa capa, revisa la guía sobre el modelo semántico en Power BI.
El patrón catálogo más puente para métricas compartidas
Cuando una misma métrica aparece en varios equipos, la tentación es duplicarla: una versión para ventas, otra para finanzas. Ese es el camino que devuelve a cada área su propia versión del número. El patrón correcto mantiene la tabla de métricas como catálogo único y resuelve la asignación a equipos, el orden y el rol con una tabla puente.
Así, Power BI, Excel, Copilot, los Scorecards y una aplicación a medida leen la misma definición sin duplicar nombres ni romper el orden de clasificación. En experiencias a medida conviene incluso consultar los metadatos de las métricas como datos: la definición, el formato, el equipo, la tendencia y las dimensiones se leen desde el modelo, en lugar de recodificarse en cada aplicación. Esa lectura de metadatos es lo que permite que la propia aplicación decida si una subida es favorable sin que un desarrollador lo escriba a mano en cada visual.
El control de cambios es lo que sostiene la confianza
Gobernar no es frenar. Es permitir que el sistema crezca sin romper la confianza. El campo de propietario existe para eso: alguien acepta o rechaza cada cambio de definición, y ese cambio queda registrado. La documentación de gobierno y cumplimiento en Fabric reúne los controles nativos de nombres, responsables, linaje, sensibilidad y ciclo de vida que hacen posible ese registro.
El valor no está en tener todas esas piezas activas, sino en convertirlas en reglas sencillas que la empresa pueda sostener en el tiempo. Un catálogo con quince campos que nadie mantiene es peor que uno con siete que se revisan de verdad. La decisión de cuántos campos incluir y con qué frecuencia revisarlos depende del tamaño del equipo y de cuántos consumos tenga cada métrica, no de una regla universal.
Empieza por las métricas que ya se discuten en comité
No intentes catalogar todo de una vez. La forma práctica de arrancar es tomar las métricas que ya generan discusión en tus reuniones de dirección, esas donde dos áreas presentan cifras distintas para el mismo concepto. Escribe la ficha completa de cada una: nombre de negocio, fórmula exacta con sus exclusiones, grano, propietario y dónde se consume hoy. Ese primer bloque de fichas suele ser corto y resuelve la mayor parte de los conflictos reales.
La acción concreta para arrancar es simple: elige las tres métricas que más se discutieron en tu último comité y escribe su ficha completa con fórmula y propietario. Ese es el catálogo empezando a existir. Y si quieres ver cómo se ve un catálogo gobernado funcionando sobre un modelo semántico real, mira la demo gratuita y evalúa el camino que mejor encaja con tu equipo.
Preguntas relacionadas
¿En qué se diferencia un catálogo de métricas de un diccionario de datos?
Un diccionario de datos describe columnas y tablas técnicas. Un catálogo de métricas describe KPI de negocio con nombre acordado, fórmula, grano, propietario y consumos, pensado para que dirección, finanzas y ventas decidan sobre la misma base.
¿Cuántos campos debe tener una ficha de métrica?
Depende del tamaño del equipo y de cuántos consumos tenga cada métrica. Un catálogo con siete campos que se revisan de verdad es más útil que uno con quince que nadie mantiene. Conviene empezar por nombre, fórmula, grano, propietario y consumos.
¿Dónde debería guardarse el catálogo de métricas?
Dentro del modelo semántico, que centraliza las definiciones del negocio, no en una hoja de cálculo suelta que vuelve a divergir entre equipos. Así Power BI, Excel y otras experiencias leen la misma definición.
¿Qué hago cuando la misma métrica la usan varios equipos con matices distintos?
Se mantiene una única definición en la tabla de métricas y se resuelve la asignación por equipo, el orden y el rol con una tabla puente. Duplicar la métrica por área es lo que hace que cada equipo termine con su propio número.
¿Por qué importa registrar el propietario y los cambios de una métrica?
Porque hace gobernable la evolución. Una persona valida o rechaza cada cambio de definición y queda registrado, lo que permite que el sistema crezca sin que las cifras dejen de ser confiables entre un comité y el siguiente.