Fachliche Logik außerhalb der BI-Apps halten

Die BI-App darf nicht selbst zum Warehouse werden

Gemeinsame Fachlogik (Bereinigung, Integration, Kennzahl-Grundlagen) gehört in governte Modelle außerhalb einzelner BI-Apps — sonst wird jede App zum Mini-Warehouse.

Qlik, Power BI und Excel berechnen jeweils „Umsatz“ mit anderer Storno-Logik. Das Lenkungsmeeting sieht drei Nettoumsatz-Zahlen für dieselbe Woche.

Eine BI-Anwendung ist oft der schnellste Ort für ein Problem. Das strukturelle Risiko entsteht, sobald dieselbe fachliche Bedeutung unabhängig in mehreren Nutzer-Artefakten landet.

Eine typische Landschaft enthält dann beispielsweise:

Qlik-App A       Umsatz schließt Stornostatus 90 aus
Qlik-App B       Umsatz schließt Status 90 und 95 aus
Power-BI-Modell  Umsatz zieht Stornodokumente ab
Excel-Datei      Umsatz entfernt negative Werte manuell
SQL-Export       Umsatz verwendet das Stornokennzeichen der Quelle

Alle fünf Ergebnisse können Umsatz heißen. Sie bilden trotzdem nicht dieselbe Kennzahl ab.

Das Problem besteht nicht darin, dass Qlik-Skripte, DAX oder Excel-Formeln verwendet werden. Diese Fähigkeiten sind am richtigen Ort unverzichtbar. Problematisch wird es, wenn ein Nutzungswerkzeug der einzige Ort ist, an dem gemeinsame Bereinigung, Integration, Historisierung und Kennzahl-Regeln verstanden werden.

Daraus entstehen mehrere Folgen:

• Jeder neue Bericht implementiert vorhandene Logik erneut.
• Korrekturen müssen mehrfach ausgerollt werden.
• Datenqualität wird unterschiedlich oder überhaupt nicht geprüft.
• Lineage endet in schwer nachvollziehbarem Anwendungscode.
• Eine Anwendung kann einen anderen Nutzer nicht sicher versorgen.
• Fachliche Definitionen hängen von einzelnen Entwicklern ab.
• Migrationen werden schwierig, weil Logik und Darstellung untrennbar verbunden sind.

Kapitel 5, Ein bestehendes Warehouse modernisieren, hat gezeigt, wie duplizierte QVD-, SQL-, Qlik-, Power-BI- und Excel-Logik schrittweise ersetzt werden kann. Dieses Kapitel definiert das Zielprinzip für die daraus entstehende Architektur.

Definiere gemeinsame fachliche Bedeutung einmal in einer governten Datenschicht. Qlik, Power BI und Excel konsumieren diese Bedeutung und ergänzen nur die Logik, die für ihr jeweiliges Analyseerlebnis spezifisch ist.

Architekturprinzip: zentrale Wahrheit, schlanke Nutzer

Die Zielarchitektur trennt zwei unterschiedliche Verantwortlichkeiten.

Die governte Datenplattform verantwortet wiederverwendbare fachliche Wahrheit:

Bereinigung
Standardisierung
Quellenintegration
Business Keys
Referenzzuordnungen
Historisierung
Kennzahl-Grundregeln
Währungsbehandlung
Stornologik
Datenqualitätsregeln
Veröffentlichungsverträge

Die BI-Nutzer verantworten Tool-spezifisches Analyseverhalten:

Assoziative Exploration
Filterkontext
Visuelle Berechnungen
Interaktive Zeitvergleiche
Darstellung
Navigation
Kommentare
Kontrollierte manuelle Eingaben

Diese Trennung ist präziser als die Aussage „Alle Logik muss außerhalb der Apps liegen“. Bestimmte Logik besitzt nur innerhalb des Nutzer eine sinnvolle Bedeutung.

Eine Qlik-Link-Table existiert wegen des assoziativen Modells. Section Access steuert den Zugriff in einer Qlik-Anwendung. Set Analysis kann einen benutzerbezogenen Vergleich innerhalb des aktuellen Selektionszustands ausdrücken. DAX wertet Measures im Filterkontext des semantischen Modells aus. Excel ermöglicht Layouts, Kommentare und kontrollierte Szenarien, die nicht zwingend in eine Warehouse-Tabelle gehören.

Das sind legitime Ausnahmen.

Die leitende Regel lautet deshalb:

Gemeinsame fachliche Wahrheit gehört außerhalb einzelner Apps. Tool-spezifische Semantik darf im Tool verbleiben, wenn sie einen klaren analytischen oder operativen Mehrwert erzeugt und explizit dokumentiert ist.

Die schlanke Qlik-Anwendung

Eine umfangreiche Qlik-Anwendung übernimmt mehrere Architekturaufgaben gleichzeitig:

Eine schlanke Qlik-Anwendung beginnt wesentlich später im Lebenszyklus.

Eine praktikable schlanke Qlik-Anwendung kann weiterhin enthalten:

• Verbindungs- und Ladeanweisungen;
• Feldauswahl und technische Umbenennungen für das lokale Modell;
• für das Analyseerlebnis erforderliche Assoziationen;
• eine Link Table oder kanonische Datumsstruktur, sofern fachlich und technisch begründet;
• Section Access, wenn die Zugriffsdurchsetzung auf Anwendungsebene erforderlich ist;
• gezielte Performance-Optimierungen;
• Master-Elemente und visuelle Ausdrücke;
• Set Analysis für interaktive Analysekontexte.

Sie sollte normalerweise nicht enthalten:

• wiederholte Joins zwischen Quellsystemen;
• die einzige Implementierung der Stornoregel;
• unabhängige Länder- oder Statuszuordnungen;
• lokale Rekonstruktion der Kundenhistorie;
• eigene Regeln für die Währungsumrechnung;
• duplizierte Datenqualitätsentscheidungen;
• eine abweichende Definition des unternehmensweiten Umsatz-Kennzahl.

Der Begriff schlanke App bedeutet nicht „kein Skript“. Er bedeutet, dass das Skript auf Konsum, Qlik-spezifische Modellierung und begründete Optimierung beschränkt bleibt.

Was gehört wohin?

Der richtige Ort einer Logik hängt davon ab, ob sie wiederverwendbare fachliche Wahrheit oder nutzungsspezifisches Analyseverhalten darstellt.

Eine praktikable Zuordnung lautet:

Der Ort kann geteilt werden, wenn unterschiedliche Verantwortlichkeiten bestehen. Beispielsweise kann die Zugriffsberechtigung zentral erzeugt werden, während Section Access sie innerhalb von Qlik durchsetzt. Die zentrale Schicht definiert, welcher Nutzer für welche Vertriebsregion berechtigt ist. Die Qlik-App konsumiert diese Berechtigungstabelle und wendet sie an.

Mit der einfachsten sinnvollen Umsetzung beginnen

Fachliche Logik außerhalb von BI-Anwendungen zu halten, erfordert weder eine neue Cloud-Plattform noch ein zusätzliches Transformationsprodukt.

Die kleinste sinnvolle Umsetzung kann so aussehen:

Angenommen, ein Unternehmen verwendet bereits SQL Server, PostgreSQL, Oracle oder eine andere relationale Datenbank. Es kann eine kleine Zahl klarer Verantwortungsbereiche einführen:

stg       technisch standardisierte Quelldaten
core      integrierte Entitäten, Schlüssel und Historie
mart      governte Fakten, Dimensionen und Reporting Views
quality   Testläufe und Regelergebnisse
control   Lade-, Versions- und Veröffentlichungsmetadaten

Das erste Ziel ist nicht, sofort einen theoretisch perfekten Semantic Layer zu schaffen. Zunächst wird eine duplizierte Regel an einen governten Ort verschoben.

Beispiel:

create view mart.sales_consumption as
select
    s.business_date,
    s.order_id,
    s.order_line_id,
    s.customer_key,
    s.product_key,
    s.country_code,
    s.currency_code,
    s.gross_revenue_amount,
    case
        when s.is_cancelled = 1 then 0
        else s.revenue_amount_in_reporting_currency
    end as net_revenue_amount,
    s.quality_status
from core.sales_order_line s
where s.publication_status = 'PUBLISHED';

Diese View ist bewusst einfach. Die eigentliche Komplexität sollte bereits in kontrollierten vorgelagerten Schritten aufgelöst worden sein:

• is_cancelled folgt einer freigegebenen Status- und Dokumentregel;
• revenue_amount_in_reporting_currency verwendet ein freigegebenes Wechselkursdatum;
• customer_key löst Kundenidentität und Historie auf;
• country_code folgt einer governten Zuordnung;
• publication_status berücksichtigt persistente Qualitätsprüfungen.

Qlik, Power BI und Excel erhalten nun dieselbe faktische Grundlage.

Konkretes Kennzahl-Beispiel: Nettoumsatz

Betrachten wir den Kennzahl Nettoumsatz.

Seine gemeinsame fachliche Definition benötigt Entscheidungen in fünf Bereichen:

Diese Entscheidungen gehören in den governten Datenpfad, weil jeder Nutzer sie identisch anwenden muss.

Die Plattform kann folgende Felder veröffentlichen:

gross_revenue_amount
net_revenue_amount
reporting_currency
business_date
customer_key
product_key
country_code
quality_status

Die Nutzer ergänzen anschließend Kontext, ohne die Kennzahl neu zu definieren.

Qlik

Das Basis-Measure kann sehr klein bleiben:

Sum([Nettoumsatz Amount])

Set Analysis kann einen analytischen Vergleich ergänzen:

Sum({
    <BusinessYear = {"$(=Max(BusinessYear)-1)"}>
} [Nettoumsatz Amount])

Der Set-Analysis-Ausdruck steuert den Vergleichskontext. Er berechnet Stornos, Währung oder Kundenhistorie nicht erneut.

Power BI

Das Basis-Measure kann denselben veröffentlichten Betrag verwenden:

Nettoumsatz :=
SUM ( SalesNutzung[NetRevenueAmount] )

Ein Zeitvergleich kann im semantischen Modell verbleiben:

Nettoumsatz Previous Year :=
CALCULATE (
    [Nettoumsatz],
    DATEADD ( 'Date'[Date], -1, YEAR )
)

DAX liefert den Modellspezifischen Analysekontext. Die zugrunde liegende Umsatzregel wird nicht neu aufgebaut.

Excel

Excel sollte vorzugsweise mit der zertifizierten Reporting View oder dem semantischen Modell verbunden werden und Folgendes verwenden:

• eine PivotTable;
• eine kontrollierte Abfrage;
• eine aktualisierbare Tabelle;
• freigegebene Szenariospalten, die klar von Ist-Daten getrennt sind.

Die Arbeitsmappe sollte keine versteckte Formel wie diese enthalten:

IF(amount < 0, 0, amount)

und das Ergebnis Nettoumsatz nennen. Dadurch entstünde eine neue lokale fachliche Definition.

Fachliche Logik außerhalb der Apps

Sobald gemeinsame Logik externalisiert ist, kann ein governter Kern mehrere Nutzer bedienen, ohne sie auf dieselbe Oberfläche oder Berechnungssprache festzulegen.

Die zentrale Schicht muss kein einzelnes physisches Produkt sein. Sie kann ein logischer Vertrag sein, der über folgende Komponenten umgesetzt wird:

• SQL-Tabellen und Views;
• Warehouse-Schemas;
• Lakehouse-Tabellen;
• governte Dateien;
• semantische Modelle;
• APIs;
• eine optionale QVD-Verteilungsschicht;
• eine Kombination dieser Komponenten.

Die architektonische Anforderung lautet, dass die maßgebliche Regel eindeutig identifizierbar, wiederverwendbar und testbar ist.

Ein geeigneter Datenproduktvertrag sollte Folgendes festhalten:

Dieser Vertrag ist wichtiger als das physische Tool, mit dem er erzeugt wird.

Optionale zentrale QVD-Schicht

Eine zentrale QVD-Schicht kann insbesondere in einer bestehenden Qlik-Landschaft eine gültige Umsetzungsoption sein.

Beispiel:

Die QVD-Schicht kann folgende Vorteile bieten:

• effiziente Qlik-optimierte Verteilung;
• Entkopplung von der Verfügbarkeit der Quellen;
• Wiederverwendung über mehrere Qlik-Anwendungen;
• kontrollierte inkrementelle Ladevorgänge;
• einen Migrationsschritt weg von App-lokaler Quellenextraktion.

Sie sollte jedoch nicht automatisch zum Ort der gesamten unternehmensweiten fachlichen Wahrheit werden.

Eine governte QVD-Schicht ist geeignet, wenn:

• Qlik der dominante oder einzige Nutzer ist;
• das Team die QVD-Erzeugung zentral betreiben und testen kann;
• Datenverträge, Verantwortung und Lineage explizit sind;
• Power BI und Excel keine ausschließlich in QVDs vorhandene Logik zurückentwickeln müssen;
• die Schicht Duplizierung reduziert, statt eine zusätzliche Kopie zu schaffen.

Wenn mehrere Nutzer-Technologien dasselbe Produkt benötigen, ist eine plattformneutrale Tabelle, View oder API in der Regel der bessere führende Vertrag. QVDs können daraus weiterhin als Qlik-spezifisches Verteilungsformat erzeugt werden.

Die Entscheidung lautet deshalb nicht „QVD oder Warehouse“. Ein sinnvolles Muster kann so aussehen:

Governte Warehouse-Modelle
        ↓
Optionaler governter QVD-Cache
        ↓
Schlanke Qlik-Apps

Umsetzungsoptionen nach vorhandener Plattform

Das logische Prinzip bleibt über Plattformen hinweg identisch.

Vorhandenes relationales Warehouse

Nutze Schemas, Views, Tabellen, Stored Procedures und den vorhandenen Scheduler. Ergänze persistente Qualitäts- und Kontrolltabellen. Das ist häufig die einfachste tragfähige Variante.

Microsoft-orientierte Umgebung

Nutze die vorhandene Microsoft-Datenplattform, um governte Warehouse- oder Lakehouse-Tabellen und Nutzer Views zu veröffentlichen. Ergänze separate semantische Measures nur dort, wo Power-BI-spezifischer Filterkontext erforderlich ist. Verschiebe gemeinsame Regeln nicht in jeden Bericht, nur weil die Plattform lokale Modellierung komfortabel macht.

Snowflake-orientierte Umgebung

Veröffentliche governte Tabellen oder kontrollierte Nutzung Views. Nutze zunächst SQL-Transformationen und die vorhandene Orchestrierung. Ergänze dbt, wenn modulare Modellabhängigkeiten, Tests, Dokumentation und Team-Deployment-Workflows ein reales Zusammenarbeitsproblem lösen.

Databricks-orientierte Umgebung

Veröffentliche governte Delta- oder SQL-Nutzung-Tabellen aus kontrollierten Transformationsschichten. Nutze Spark-spezifische Verarbeitung dort, wo Skalierung, Streaming oder Engineering-Anforderungen sie rechtfertigen. Eine kleine relationale Kennzahl-Regel wird nicht automatisch besser, nur weil sie in verteiltem Code ausgeführt wird.

Umgebung mit dbt

Nutze dbt als optionales Engineering-Framework für versionierte Modelle, Abhängigkeiten und Tests. dbt kann die Umsetzungsdisziplin verbessern, ist aber nicht selbst die fachliche Architektur. Vertrag, Verantwortung und Nutzer-Grenzen müssen weiterhin gestaltet werden.

Qlik-zentrierte Umgebung ohne Warehouse

Baue einen zentral betriebenen Qlik-Transformations- oder QVD-Erzeugungspfad als Zwischenarchitektur auf. Verschiebe Quellen-Joins, Bereinigung, Historisierung und gemeinsame Kennzahl-Grundlagen aus einzelnen Apps. Dokumentiere den Pfad als governtes Datenprodukt und behalte nur Qlik-spezifische Logik in den konsumierenden Anwendungen.

Datei-basierte oder kleine Umgebung

Ein kontrollierter Satz aus CSV-, Parquet- oder tabellenbasierten Ausgaben kann für einen kleinen Umfang ausreichen, sofern Erzeugung, Schema, Qualität, Verantwortung und Aktualisierung kontrolliert sind. Das Fehlen einer großen Plattform rechtfertigt keine unkontrollierten lokalen Definitionen.

Notwendige Tool-spezifische Ausnahmen

Bestimmte Logik sollte im Nutzer verbleiben, weil ihre Verlagerung Funktionalität entfernen, die Nutzbarkeit verschlechtern oder eine künstliche Abstraktion erzeugen würde.

Qlik-Ausnahmen

Gültige Qlik-spezifische Logik kann Folgendes umfassen:

• Link Tables, um mehrere Fakten und gemeinsame Dimensionen im assoziativen Modell zu verwalten;
• kanonische Datumsmodelle, um mehrere fachliche Datumsrollen über einen Kalender zu analysieren;
• Section Access für Reduktion auf Anwendungsebene;
• gezielte Set Analysis für selektionsabhängige Vergleiche;
• Alternate States für kontrollierte Vergleichsanalysen;
• lokale Assoziationsbehandlung, wenn das Nutzung Model sie benötigt;
• Performance-orientierte Feldaufbereitung, wenn sie das Anwendungsverhalten wesentlich verbessert.

Diese Ausnahmen dürfen nicht als Begründung dienen, Quellenbereinigung und unternehmensweite Kennzahl-Definitionen wieder in die App zu verschieben.

Power-BI-Ausnahmen

Gültige Power-BI-spezifische Logik kann Folgendes umfassen:

• Measures im semantischen Modell;
• DAX-Zeitintelligenz;
• Calculation Groups;
• Row-Level Security, wenn sie durch das semantische Modell durchgesetzt wird;
• Display Folders und Modellmetadaten;
• Darstellungsberechnungen, die vom Filterkontext abhängen;
• What-if-Parameter für kontrollierte Szenarioanalysen.

Die zugrunde liegenden Fakten, Mappings, Stornoregeln und historischen Zuordnungen sollten außerhalb des Berichts wiederverwendbar bleiben.

Excel-Ausnahmen

Gültige Excel-spezifische Logik kann Folgendes umfassen:

• Berichtslayout;
• Kommentare und Annotationen;
• kontrollierte Szenarioannahmen;
• manuell eingegebene Planwerte;
• Arbeitsmappen-spezifische Darstellungsformeln;
• lokale Pivot-Auswertungen und Diagramme;
• Abstimmungen als sichtbare temporäre Kontrolle.

Manuelle Eingaben sollten klar von governten Ist-Daten getrennt werden. Werden Eingaben operativ wichtig, benötigen sie verantwortliche Person, Validierung, Versionierung und einen kontrollierten Rückführungspfad in die Plattform.

Jede Ausnahme dokumentieren

Eine Ausnahme sollte in einem Architekturregister sichtbar sein und nicht in einem Skript oder einer Arbeitsmappe verborgen bleiben.

Ein vergleichbarer Eintrag kann ein DAX-Measure oder eine kontrollierte Excel-Eingabe dokumentieren.

Das Register beantwortet fünf Fragen:

1. Warum existiert die Logik im Tool?
2. Welche gemeinsame Definition konsumiert sie?
3. Verändert sie fachliche Wahrheit oder nur den Analysekontext?
4. Wer verantwortet und testet sie?
5. Unter welcher Bedingung wird sie verschoben, wiederverwendet oder entfernt?

Datenqualität muss außerhalb der Visualisierung bleiben

Ein Bericht kann Qualitätsergebnisse darstellen. Er sollte jedoch nicht der einzige Ort sein, an dem Qualität ausgewertet wird.

Persistente Qualitätsausführung sollte mindestens Folgendes erfassen:

test_run_id
data_product
rule_id
severity
object_name
record_key
expected_value
actual_value
result_status
executed_at
owner

Für das Umsatzbeispiel können Regeln enthalten:

• Kennung der Auftragsposition ist vorhanden;
• Kundenschlüssel wurde aufgelöst;
• Produktschlüssel wurde aufgelöst;
• Business-Datum ist gültig;
• Wechselkurs ist verfügbar;
• Stornostatus ist bekannt;
• Nettoumsatz entspricht der freigegebenen Regel;
• Veröffentlichung ist vor dem vereinbarten Zeitpunkt vollständig.

Qlik und Power BI können Fehlerrate, Entwicklung und betroffene Datensätze visualisieren. Excel kann eine kontrollierte Bearbeitung unterstützen. Regelausführung und Ergebnishistorie bleiben unabhängig von allen drei Nutzern.

Zugriffslogik kann ohne Duplizierung geteilt werden

Security erstreckt sich häufig über Plattform und Nutzer.

Ein sinnvolles Muster lautet:

Die Plattform kann folgende Felder veröffentlichen:

user_id
region_key
product_scope
valid_from
valid_to
access_status

Qlik kann diese Tabelle in Section Access verwenden. Power BI kann dieselbe Berechtigung in seinem Security Model einsetzen. Excel erhält ausschließlich eine freigegebene View oder einen kontrollierten Extrakt.

Die Berechtigungsregel ist zentral. Der Mechanismus zur Durchsetzung ist Tool-spezifisch.

Typische Fehlmuster

Das Warehouse in jeder Qlik-App neu aufbauen

Quellen-Joins, Mappings, Historisierung und Kennzahl-Berechnungen werden in mehrere Reload-Skripte kopiert. Jede App wird zu einer eigenen Warehouse-Implementierung.

Eine gemeinsame Qlik-Include-Datei mit vollständiger Governance verwechseln

Eine Include-Datei reduziert kopierten Code. Sie liefert jedoch nicht automatisch Verantwortung, Testing, versionierte Datenverträge, Qualitätsevidenz oder plattformneutrale Wiederverwendung.

Sämtliche Logik in eine riesige SQL-View verschieben

Zentralisierung allein schafft keine Wartbarkeit. Eine einzelne undurchsichtige View kann genauso schwer governbar werden wie ein großes Qlik-Skript. Verantwortlichkeiten müssen getrennt und Zwischenergebnisse bei Bedarf persistiert werden.

Denselben Kennzahl in DAX erneut implementieren

Jeder Power-BI-Bericht erzeugt seine eigene Variante von Nettoumsatz, Deckungsbeitrag oder aktivem Kunden. Ein gemeinsames semantisches Modell hilft. Wiederverwendbare faktische Regeln sollten bei Bedarf trotzdem außerhalb einer einzelnen Berichtstechnologie verfügbar sein.

Excel als unsichtbare Korrekturschicht verwenden

Nutzer korrigieren Ländercodes, entfernen Stornos oder ergänzen fehlende Mappings manuell. Die Arbeitsmappe wird operativ kritisch, ohne Verantwortung oder Nachvollziehbarkeit zu besitzen.

Jede Analyseberechnung in die Plattform zwingen

Wer jeden Vergleich, jedes Ranking und jeden selektionsabhängigen Ausdruck in Warehouse-Spalten verschiebt, erzeugt viele kontextspezifische Felder und reduziert die analytische Flexibilität.

Jede Tool-spezifische Logik zur Ausnahme erklären

Eine Ausnahme wird durch den Ausführungskontext des Tools begründet. „Es war lokal schneller umzusetzen“ ist keine belastbare Architekturbegründung.

Eine weitere zentrale Kopie erstellen, ohne lokale Logik stillzulegen

Ein neuer governter Mart wird veröffentlicht, alte Qlik-Skripte, Power-Query-Schritte und Excel-Formeln bleiben jedoch aktiv. Die Architektur gewinnt eine zusätzliche Schicht, ohne Inkonsistenz zu reduzieren.

dbt, Fabric, Snowflake oder Databricks verpflichtend machen

Das Prinzip kann mit vorhandenem SQL, governten QVDs oder kontrollierten Dateien umgesetzt werden. Ein neues Produkt ist nur gerechtfertigt, wenn es ein identifiziertes Problem bei Lieferung, Skalierung, Zusammenarbeit oder Betrieb löst.

Entscheidungshilfe

Verwende für jedes Stück Logik folgende Fragen:

Eine kompakte Regel lautet:

Gemeinsame Bedeutung       → zentral
Wiederverwendbare Logik    → zentral
Qualität und Historie      → zentral
Tool-Ausführungskontext    → lokal und dokumentiert
Darstellung                → lokal
Temporäre Exploration      → lokal, mit Pfad zur Überführung

Wichtigste Empfehlungen

1. Behandle Qlik, Power BI und Excel als Nutzungswege governter Datenprodukte und nicht als unabhängige Warehouses.
2. Verschiebe gemeinsame Bereinigung, Integration, Schlüsselauflösung, Historisierung, Kennzahl-Grundlagen und Datenqualitätsregeln aus einzelnen BI-Artefakten.
3. Beginne mit einer duplizierten, fachlich wertvollen Regel, statt alle Anwendungen gleichzeitig neu zu gestalten.
4. Halte Qlik-Skripte so schlank wie praktisch möglich und behalte nur Verbindung, Laden, Assoziationen, Zugriff, Performance und begründete analytische Logik.
5. Nutze Set Analysis für Qlik-spezifischen Analysekontext und nicht zur erneuten Umsetzung gemeinsamer Storno-, Währungs- oder Historienregeln.
6. Nutze DAX für semantisches Modell- und Filterkontextverhalten und nicht als einzige Implementierung wiederverwendbarer fachlicher Wahrheit.
7. Verbinde Excel mit zertifizierten Views oder governten Modellen und trenne kontrollierte Annahmen von Ist-Daten.
8. Veröffentliche einen stabilen Nutzungsvertrag mit Granularität, Definitionen, verantwortliche Person, Aktualisierung, Qualität, Security und Änderungsrichtlinie.
9. Persistiere Datenqualitätsergebnisse außerhalb von Berichten und definiere das Veröffentlichungsverhalten explizit.
10. Zentralisiere die Zugriffsberechtigung und verwende in jedem Nutzer den passenden Mechanismus zur Durchsetzung.
11. Erlaube Tool-spezifische Ausnahmen nur, wenn der Ausführungskontext einen realen Mehrwert erzeugt.
12. Dokumentiere jede Ausnahme mit Zweck, verantwortliche Person, betroffener Definition, Test und Bedingung zur Entfernung.
13. Nutze eine zentrale QVD-Schicht, wenn sie Qlik-Duplizierung reduziert, verwende QVD-only-Logik jedoch nicht als Standardvertrag für Nutzer außerhalb von Qlik.
14. Nutze vorhandene relationale Datenbanken, Scheduler und BI-Landschaften, bevor eine weitere Plattform ergänzt wird.
15. Behandle Fabric, Snowflake, Databricks und dbt als Umsetzungsoptionen und nicht als Voraussetzungen.
16. Entferne alte lokale Definitionen, nachdem der governte Ersatz validiert wurde.
17. Messe Erfolg an weniger widersprüchlichen Definitionen, schlankeren Nutzer-Artefakten, schnelleren Änderungen und besserer Nachvollziehbarkeit.