Una métrica de Power BI necesita un contrato antes de publicarse

Dos equipos pueden abrir el mismo panel y llegar a decisiones distintas si no comparten qué mide cada cifra, de dónde sale y cuándo se actualizó. Antes de construir otro visual, conviene acordar un contrato de métrica: una definición breve que una negocio, datos y revisión técnica.

Definir la decisión y la cifra

Empiece por la pregunta que el indicador debe ayudar a responder. Documente nombre, propósito, fórmula, unidad, nivel de detalle y exclusiones. Si la métrica es «ventas cerradas», indique qué cuenta como cierre, cómo se manejan devoluciones y en qué zona horaria se determina el período. Sin esos límites, una discrepancia puede parecer un fallo de Power BI cuando en realidad es una diferencia de definición.

Asigne un responsable de negocio para aprobar el significado y un responsable técnico para custodiar el cálculo. La revisión debe cubrir tanto el uso de la cifra como su implementación.

Un ejemplo que obliga a decidir

Suponga que el indicador es «pedidos cerrados por mes». Antes de implementarlo, el equipo acuerda si el cierre se toma del estado comercial o de la facturación, qué fecha asigna el pedido al mes, cómo se tratan cancelaciones y reaperturas, y si se cuentan pedidos o líneas. Es un ejemplo hipotético: el valor está en dejar explícitas las preguntas, no en adoptar una fórmula universal.

Una ficha útil permite a otra persona reconstruir el cálculo con registros conocidos. Si dos áreas aplican reglas distintas, registre la diferencia y resuélvala con el responsable de negocio antes de publicar un único número.

Seguir el dato hasta el visual

El contrato debe identificar sistemas de origen, tablas relevantes, transformaciones y versión del modelo semántico. Para cada paso, registre qué cambia y qué prueba permite comprobarlo. Una transformación que elimina registros incompletos puede ser legítima, pero debe quedar visible para quien interpreta el resultado.

En Power BI, la vista de linaje del área de trabajo ayuda a inspeccionar relaciones entre fuentes, modelos semánticos e informes. Úsela como comprobación técnica del recorrido; la definición de negocio y las transformaciones que no se vean allí deben seguir documentadas en el contrato.

flowchart LR
  A["Fuente / Source"] --> B["Modelo / Model"]
  B --> C["Revisión / Review"]
  C --> D["Publicación / Publish"]

Probar antes de aprobar

Prepare casos conocidos: un período cerrado, un registro excepcional y un caso sin datos. Compare la salida del modelo con una fuente autorizada y documente las diferencias. Acordar una tolerancia o un umbral sin decir quién puede modificarlo solo desplaza el problema a la siguiente publicación.

Compruebe también el contexto de filtros de la medida y el estado de actualización antes de aprobar el informe. Microsoft documenta cómo se crean medidas y dónde consultar el historial de actualización; ambas verificaciones ayudan a separar una diferencia de cálculo de datos desactualizados.

La aprobación debe dejar fecha, versión, responsables y evidencia. Si cambia la fórmula o el origen, trate el cambio como una nueva versión del contrato, con revisión y posibilidad de reversión. Una ficha breve ayuda a no perder estas decisiones.

Llevarlo a la operación

La ficha no reemplaza el gobierno de datos; hace explícitas las decisiones mínimas para un indicador concreto. Si su equipo ya usa Power BI pero necesita ordenar definiciones, calidad y responsables, explore el servicio Power BI in Order y el enfoque de gobierno de datos.