Metrik-Zertifizierung in Fabric und Power BI

In Fabric und Power BI markiert ein Endorsement-Badge Auffindbarkeit — es ersetzt nicht die fachliche Freigabe einer Kennzahl.

Ein Semantic Model trägt das Label zertifiziert. Darin steckt weiterhin eine ungeprüfte Nettoumsatz-Measure mit anderer Storno-Logik als Finance. Nutzer vertrauen dem Badge; die Evidenz fehlt.

Metrik-Zertifizierung ist eine verantwortete Evidenzentscheidung: Zuerst Scope, Owner und Nachweis — danach das Plattform-Endorsement auf dem Item, das die Implementierung enthält.

Herausforderung

Organisationen verwenden den Begriff certified häufig für unterschiedliche Dinge:

• ein Endorsement-Badge in Power BI oder Fabric;
• die Freigabe eines semantisches Modells;
• die Freigabe einer einzelnen Business-Kennzahl;
• den Abschluss eines Governance-Workflows;
• eine berufliche Qualifikation wie CDMP;
• eine Datenschutz-, Security- oder Compliance-Zertifizierung.

Diese Bedeutungen sind nicht austauschbar.

Ein Plattform-Badge ist nützliches Metadatum. Es hilft Nutzern, Inhalte zu finden, die die Organisation als wertvoll oder autoritativ einstuft. Es definiert jedoch nicht, welche Evidenz geprüft wurde, welcher Kennzahlen-Scope freigegeben ist oder unter welchen Bedingungen der Vertrauensanspruch gültig bleibt.

Das Plattform-Label ist nicht die Governance-Definition

Stand Juli 2026 unterstützt Microsoft Fabric die Endorsement-Labels Promoted, zertifiziert und Master data für geeignete Fabric Items. Das Power-BI-Endorsement konzentriert sich auf Promoted und zertifiziert. Certification wird über Tenant Settings und benannte Zertifizierer kontrolliert, während Promotion breiter durch Item Owner oder Nutzer mit Schreibberechtigung gesetzt werden kann.

Diese Funktionen wirken auf Item-Ebene. Eine Power-BI-Measure ist ein Objekt innerhalb eines Semantic Models und erhält kein eigenes eingebautes Endorsement-Badge. Ein zertifiziertes Semantic Model kann daher enthalten:

• freigegebene gemeinsame Measures;
• technische Hilfs-Measures;
• Measures, die nur in einem begrenzten Kontext gültig sind;
• deprecated Measures während einer Migration;
• ungegovernte lokale Berechnungen, die downstream entstehen.

Die Organisation muss die Zertifizierungsentscheidung auf Kennzahlenebene separat führen und mit der produktiven Implementierung verknüpfen.

Fünf typische Anti-Patterns

Badge ohne freigegebene Definition. Das Semantic Model ist zertifiziert, weil es häufig verwendet wird. Der KPI besitzt aber weiterhin keine formal abgestimmte Population, Ausschlüsse, Zeitlogik und keinen eindeutigen Basis-Grain.

Owner-Feld ohne Entscheidungsbefugnis. Im Katalog steht ein Name, aber diese Person kann Bedeutung nicht freigeben, Risiko nicht akzeptieren, Remediation nicht priorisieren und die Kennzahl nicht stilllegen.

Zertifizierung wird über Umgebungen kopiert. Ein Development- oder Test-Artefakt gilt als vertrauenswürdig, weil ein verwandtes Production Item zertifiziert ist. Oder der Trust-Status wird bei einem Deployment als automatisch übertragen angenommen. Umgebungsspezifische Quellen, Regeln, Refreshes, Zugriffe und Evidenz werden nicht erneut geprüft.

Keine Rezertifizierung nach Änderungen. Quelle, Formel, Beziehung, Grain, Filterregel, Access Policy oder Owner ändern sich, während Badge und Trusted-Metric-Eintrag unverändert bleiben.

Zertifiziertes Semantic Model mit ungegovernten lokalen Kennzahlen. Nutzer erstellen Report-lokale, visuelle oder Composite-Model-Berechnungen, die das Vertrauenssignal übernehmen, aber die freigegebene fachliche Bedeutung neu definieren.

Das Problem ist nicht die Endorsement-Funktion. Das Problem entsteht, wenn das Badge die governte Entscheidung ersetzt.

Zertifizierung muss eine präzise Frage beantworten

Eine belastbare Zertifizierungsaussage ist abgegrenzt:

Nettoumsatz Version 3.2 ist für das monatliche Management Reporting in EUR auf Sales-Order-Line-Grain freigegeben. Sie verwendet die dokumentierten Regeln für Eligibility, Stornos, Retouren und Währung, ist im produktiven Sales Semantic Model implementiert, reconciled innerhalb der freigegebenen Toleranz gegen das Finance-Referenzergebnis und wird quartalsweise oder unmittelbar nach einem definierten Change Trigger geprüft.

Diese Aussage ist testbar. „Zertifizierter KPI“ ohne Scope, Version, Implementierung und Review-Bedingung ist es nicht.

Ansatz

Definiere Metrik-Zertifizierung als Lifecycle-Entscheidung mit expliziten Zuständen, Evidenz, Entscheidungsrechten und Review Triggern.

Die interne Governance-Entscheidung erfolgt vor dem Setzen des Plattform-Labels.

Ein praktikabler Decision Flow ist:

Kennzahlenkandidat
→ Prüfung von Definition und Grain
→ Owner-Freigabe
→ Lineage- und Quality-Evidenz
→ Reconciliation und Consumer-Validierung
→ Prüfung von Zugriff und erlaubter Nutzung
→ Zertifizierungsentscheidung
→ Veröffentlichte Trusted Metric

Die möglichen Ergebnisse sind nicht auf certified oder rejected begrenzt:

• zertifiziert — die Kennzahl erfüllt den erforderlichen Evidenz- und Kontrollstandard für den freigegebenen Umfang.
• Promoted — die Kennzahl oder das enthaltende Item ist nützlich und auffindbar, aber die vollständige Zertifizierungsevidenz ist noch nicht abgeschlossen.
• Zur Remediation zurückgegeben — der Kandidat ist grundsätzlich valide, aber Evidenzlücken müssen geschlossen werden.
• Abgelehnt — vorgeschlagene Bedeutung, Implementierung oder Kontrolldesign sind nicht akzeptabel.
• Deprecated oder Retired — die Kennzahl ist nicht mehr für neue Nutzung freigegeben und Nutzer müssen migrieren.

Trust States unabhängig von Plattformmechanik definieren

Verwende vier organisationsinterne Zustände.

Ordne diese internen Zustände nur dann Microsoft-Plattformlabels zu, wenn die Zuordnung sachlich passt.

Master data ist ein separates Fabric Endorsement für geeignete datenhaltende Items. Es ist kein Synonym für eine zertifizierte Kennzahl.

Metrik-Zertifizierung und Semantic-Model-Zertifizierung trennen

Semantic Model und Kennzahl sind verbundene Governance-Objekte, aber nicht identisch.

Eine Metrik-Zertifizierung gibt frei:

• Business-Frage und beabsichtigte Entscheidung;
• Definition, Einschlüsse und Ausschlüsse;
• Basis-Körnung und Aggregationsverhalten;
• Zeit-, Filter- und Dimensionssemantik;
• verantwortlichen Owner und erlaubte Nutzer;
• Referenzergebnis und Abgleich-Toleranz;
• Version, Effective Date und Review Trigger.

Eine Semantic-Model-Zertifizierung gibt das wiederverwendbare Item frei, das eine oder mehrere Kennzahlen und Dimensionen implementiert:

• Modellstruktur und Beziehungen;
• freigegebene Measures und Berechnungsverhalten;
• Refresh- und Betriebscontrols;
• Security und Build Access;
• Lineage, Verantwortung und Support auf Modellebene;
• kontrollierten Release- und Change-Prozess;
• Eignung für governte Wiederverwendung.

Der Zusammenhang muss explizit sein:

zertifiziert Metric Record
→ Referenz auf freigegebene Implementierung
→ Production Semantic Model
→ technisches Measure-Objekt
→ erlaubte Reports und Consumer

Die Zertifizierung des Modells ist erforderlich, wenn das Modell der governte Delivery Channel ist. Sie reicht nicht aus, um jede enthaltene Kennzahl zu zertifizieren.

Entscheidungsrechte zuweisen

Zertifizierung darf keine alleinige Selbstfreigabe des Implementierungsteams sein.

In kleineren Organisationen kann eine Person mehrere Rollen übernehmen. Die Verantwortlichkeiten müssen trotzdem unterscheidbar bleiben. Wer die DAX Expression schreibt, darf die fachliche Bedeutung nicht still selbst festlegen.

Umgebungsspezifische Freigabe verlangen

Development, Test und Production besitzen unterschiedliche Trust-Auswirkungen.

Ein Certification Record identifiziert das exakte Production Item und die Implementierungsversion. Ein Deployment in einen anderen Workspace oder eine andere Stage beweist nicht, dass:

• das Ziel dieselbe governte Quelle verwendet;
• Gateway, Credentials und Refresh funktionieren;
• Access und RLS gleichwertig sind;
• Deployment Rules auf die beabsichtigte Umgebung zeigen;
• Abgleich-Ergebnisse innerhalb der Toleranz bleiben;
• das endorsed Item tatsächlich das freigegebene Production Object ist.

Behandle Production Certification als Release Gate. Kopiere den Trust-Anspruch nicht nur deshalb, weil Content kopiert wurde.

Auffindbarkeit ermöglichen, ohne Discovery und Access zu verwechseln

Endorsement unterstützt Discovery. In Power BI kann ein endorsed Semantic Model discoverable gemacht werden, sodass Nutzer es auch ohne aktuellen Zugriff finden und Access anfordern können. Discoverability erteilt keine Build Permission und umgeht keine Security.

Der Trusted-Metric-Eintrag sollte daher sichtbar machen:

• Kennzahlenname, Zweck und Definition;
• Status und freigegebenen Umfang;
• verantwortlichen Owner und Supportkontakt;
• Production semantisches Modell und Kennzahl;
• Freshness und letzten erfolgreichen Evidenzreview;
• erlaubte Nutzer und Access-Request-Pfad;
• Ersatz bei Deprecation;
• Links zu Lineage, Tests und Abgleich-Ergebnissen.

Discovery zeigt, dass ein freigegebenes Asset existiert. Access Controls bestimmen weiterhin, ob es genutzt werden darf.

Zertifizierung ist ein Lifecycle

Ein permanentes Badge erzeugt veraltetes Vertrauen. Zertifizierung muss bei veränderter Evidenz oder verändertem Kontext in den Review zurückkehren.

Verwende einen geschlossenen Loop:

Vorschlagen
→ Evidenz prüfen
→ Lücken beheben
→ Freigeben und veröffentlichen
→ Nutzung und Qualität überwachen
→ Änderung erkennen
→ Neu bewerten
→ Rezertifizieren oder deprecated setzen

Unmittelbare Reassessment Trigger sind:

• Änderung an Quellsystem oder Quelltabelle;
• Änderung an Formel, fachliche Ebene, Beziehung oder Aggregation;
• neuer Nutzer-Kontext oder wesentlich andere Entscheidung;
• Quality Threshold Breach oder ungelöster Incident;
• Refresh- oder Freshness-Fehler;
• Änderung an Access-, personenbezogene Daten- oder Permitted-Use-Richtlinie;
• Wechsel von verantwortliche Person oder Steward;
• Production-Migration oder wesentliche Plattformänderung;
• geplantes Review-Datum.

Ein kalenderbasierter Review bleibt erforderlich, weil nicht jede wesentliche Änderung automatisch erkannt wird. Eine risikobasierte Cadence kann kritische Executive- oder regulierte Kennzahlen quartalsweise, breit wiederverwendete operative Kennzahlen halbjährlich und stabile Kennzahlen mit geringerem Risiko jährlich prüfen. Change Trigger haben immer Vorrang vor dem Kalender.

Checkliste

Nutze diese Checkliste, bevor eine Kennzahl als certified freigegeben wird.

Definition

• Business-Frage und unterstützte Entscheidung sind explizit.
• Formel, Einschlüsse, Ausschlüsse und Exception Rules sind freigegeben.
• Die Kennzahl besitzt eine stabile ID und Version.
• Ähnliche Bezeichnungen und konkurrierende Definitionen wurden geprüft.

Grain und Semantik

• Basis-Körnung und gültige Aggregation sind dokumentiert.
• Zeitbasis, Effective Date und Periodenverhalten sind explizit.
• Filterverhalten und unterstützte Dimensionen sind definiert.
• Währung, Einheit, Vorzeichen und Null-Verhalten sind kontrolliert.
• Erlaubte lokale Ableitungen sind von Neudefinitionen getrennt.

Verantwortung und Entscheidungsrechte

• Ein verantwortlicher Data Owner kann Bedeutung freigeben und Risiko akzeptieren.
• Ein Kennzahlenverantwortliche Person oder Data Product Owner pflegt den Lifecycle.
• Ein Steward validiert Terminologie und Evidenz.
• Ein Implementation technischer Betreiber unterstützt das technische Objekt.
• Autorisierte Plattform-Zertifizierer sind über Tenant Governance definiert.

Lineage und Implementierung

• Governte Quellsysteme und Tabellen sind verlinkt.
• Transformationen und Orte der Fachregeln sind nachvollziehbar.
• Das exakte Production semantisches Modell und die Kennzahl sind identifiziert.
• Downstream Reports, Composite Models und wesentliche Nutzer sind bekannt.
• Development- und Test-Objekte können nicht mit Production verwechselt werden.

Qualität und Freshness

• Quality Rules, Thresholds und Schweregrad Levels sind dokumentiert.
• Testergebnisse sind aktuell und reproduzierbar.
• Refresh- und Freshness-Erwartungen sind explizit.
• Incident Verantwortung, Escalation und Remediation sind definiert.
• Bekannte Einschränkungen und akzeptierte Ausnahmen besitzen Ablaufdaten.

Reconciliation und Consumer-Validierung

• Ein Referenzergebnis oder autoritativer Vergleich ist benannt.
• Abgleich-Körnung, Zeitraum und Toleranz sind dokumentiert.
• Abweichungen sind erklärt und freigegeben.
• Nutzer Representatives haben Interpretation und Nutzbarkeit validiert.
• Evidenz ist verlinkt und nicht nur in Screenshots konserviert.

Protection und erlaubte Nutzung

• Access-Anforderungen und Build Permission wurden geprüft.
• RLS, OLS oder andere relevante Kontrollregeln sind getestet, wenn sie eingesetzt werden.
• personenbezogene Daten-, Sensitivity- und Permitted-Use-Klassifikationen sind dokumentiert.
• Discovery legt keine eingeschränkten Details offen.
• Export-, Sharing- und Downstream-Reuse-Bedingungen sind explizit.

Lifecycle

• Effective Date und Review-Datum sind gesetzt.
• Change Trigger sind registriert.
• Owner und Evidenzanforderungen für Rezertifizierung sind klar.
• Deprecation-Status, Ersatz und Migrationsplan sind definiert.
• Der Trust Marker wird entfernt oder geändert, wenn die Freigabe abläuft.

Plattform-Mapping

• Der interne Trust State ist vor dem Plattform-Endorsement entschieden.
• Der gewählte Item Type ist für das beabsichtigte Endorsement geeignet.
• Tenant Settings und Certifier Permissions sind geprüft.
• Das Endorsement wird auf das exakt freigegebene Production Item angewendet.
• Metrik-Evidenz bleibt unabhängig vom Item-Badge zugänglich.

Artefakt

Das zentrale Ergebnis ist ein Metric Certification Record. Er ist das evidenzbasierte Entscheidungsartefakt hinter Katalogeintrag und Plattform-Endorsement.

Eine praktische Struktur kann so aussehen:

metric_certification:
  metric_id: net-revenue
  metric_name: Nettoumsatz
  version: 3.2
  governance_state: certified
  effective_date: 2026-07-28

  business_scope:
    question: Wie viel zulässiger Umsatz verbleibt nach freigegebenen Stornos und Retouren?
    decisions:
      - monatliches-management-reporting
      - regionaler-sales-review
    approved_consumers:
      - executive-sales-report
      - regional-sales-analysis
    prohibited_uses:
      - statutory-revenue-reporting-ohne-finance-adjustments

  definition:
    approved_definition: /governance/metrics/net-revenue/3.2
    formula_components:
      - eligible-sales-lines
      - approved-cancellations
      - approved-returns
      - reporting-currency-conversion
    base_grain: sales-order-line
    aggregation: additive-by-approved-reporting-dimensions
    time_basis: posting-date
    exclusions:
      - test-orders
      - unapproved-manual-adjustments

  ownership:
    data_owner: sales-finance-owner
    metric_owner: sales-data-product-owner
    steward: commercial-data-steward
    implementation_custodian: bi-platform-team
    platform_certifier: authorized-certifier-group

  implementation:
    environment: production
    workspace: governed-sales-bi
    semantic_model: sales-performance
    semantic_model_item_id: linked-platform-id
    measure: Nettoumsatz
    deployment_version: release-2026.07.28
    endorsement:
      requested: certified
      applied_after_governance_decision: true

  evidence:
    lineage: /lineage/net-revenue/3.2
    quality_results: /quality/net-revenue/latest
    freshness_slo: data-available-by-07-00-cet
    reconciliation:
      reference: finance-monthly-close
      tolerance: 0.10-percent
      latest_result: passed
    consumer_validation: /reviews/net-revenue-consumers
    access_review: /access/sales-performance

  lifecycle:
    review_cadence: quarterly
    next_review: 2026-10-28
    change_triggers:
      - source-change
      - formula-or-grain-change
      - quality-threshold-breach
      - access-policy-change
      - ownership-change
    deprecation_replacement: null

  decision:
    outcome: certified
    approved_by: accountable-data-owner
    reviewed_by:
      - commercial-data-steward
      - quality-control-reviewer
      - consumer-representative
    decision_date: 2026-07-28
    open_exceptions: []

Der Record sollte auf dauerhafte Evidenzorte verweisen. Kopierte Screenshots veralten schnell, sind schwer abfragbar und verlieren häufig den Kontext, in dem sie erzeugt wurden.

Mindestergebnisse

Der Zertifizierungsworkflow sollte erzeugen:

• Zertifizierungsentscheidung und freigegebenen Umfang;
• verantwortlichen Owner und Implementation technischer Betreiber;
• Referenz auf die Production-Implementierung;
• Ergebnis der Evidenzvollständigkeit;
• Aktion für das Plattform-Endorsement;
• ungelöste Ausnahmen und Ablaufdaten;
• Review-Datum und Change Trigger;
• Deprecation- oder Migrationsmaßnahme, falls erforderlich.

Sinnvolle Betriebsmetriken sind:

• Certification Lead Time;
• Nachweis Completeness;
• Wiederverwendung zertifizierter Kennzahlen;
• ungelöste Exceptions;
• überfällige Reviews;
• Quality Incidents mit Auswirkung auf zertifizierte Kennzahlen;
• Nutzer-Migration von deprecated Metrics.

Diese Kennzahlen messen die Gesundheit des Trust-Prozesses. Die reine Anzahl der Badges tut das nicht.

Tools

Nutze die bestehenden Binom Tools, um das Evidenzpaket zu erstellen und zu validieren:

• KPI Definition Card — erfasst Business-Frage, freigegebene Definition, fachliche Ebene, Formelkomponenten, verantwortliche Person, Status und Version.
• Report Inventory Canvas — identifiziert konkurrierende Kennzahlenimplementierungen, lokale Overrides, betroffene Nutzer und Migrationsscope.
• BI Python Export Toolkit — extrahiert größere Inventare von Power BI semantisches Modells, Measures, Expressions und Report-Abhängigkeiten für den Review.
• Power BI DAX Kennzahl Generator — erzeugt Implementierungscode und Dokumentation erst nach Freigabe von Definition und Zertifizierungsscope.

Die Tools erzeugen Evidenz oder Implementierungsartefakte. Sie geben keine fachliche Bedeutung frei, akzeptieren kein Risiko und setzen keine Zertifizierung autonom.

Ressourcen

• Kennzahlenmodell vs Kennzahl im Report — entscheide vor der Zertifizierung, wo die Kennzahl implementiert werden soll.
• Trusted Metrics Learning Path — verbindet Definition, Verantwortung, Implementierung, Evidenz und Lifecycle.
• BI-Publish Deep Dive — Workspace, Stage und Produktfreigabe; ein Zertifizierungslabel ist kein Publish-Vertrag.
• Microsoft Learn — Endorsement von Power-BI-Inhalten
• Microsoft Learn — Fabric- und Power-BI-Items endorsen
• Microsoft Learn — Item Certification aktivieren
• Microsoft Learn — Auffindbarkeit von semantisches Modells
• Microsoft Learn — Build Permission für semantisches Modells
• Microsoft Learn — Metadata Scanning
• Microsoft Learn — OneLake Catalog erkunden
• Microsoft Learn — Fabric Deployment Process

Feature-Stand: Juli 2026. Microsoft-Produktnamen, geeignete Item Types, Tenant Controls, Certifier Permissions, Discovery-Verhalten, APIs und Lizenzbedingungen können sich ändern. Prüfe vor der Umsetzung die aktuelle Microsoft-Dokumentation und die Konfiguration des eingesetzten Tenants.

Berufliche Qualifikationen oder externe Compliance-Zertifizierungen können individuelle Kompetenz oder organisatorische Controls nachweisen. Sie ersetzen keine metrikspezifische Definition, Lineage, Qualität, Reconciliation, Access- und Lifecycle-Evidenz.