Consumer-Stufen und gemeinsames Modell

Produkte und Entscheidungen

Die Landschaft braucht nicht „eine BI-Plattform“, sondern geschnittene Produkte.

Shared Semantic Grain

Dieses Produkt beschreibt:

• Kennzahl-ID; verbindliches fachliche Ebene; Grundgesamtheit; Einheit und Währung; Upstream-Referenz (Auswertungstabelle / Warehouse / semantisches Modell); Breaking-Change-Regel; verantwortliche Person; Review-Datum.

Entscheidungen:

• Welche Basiskennzahlen sind autoritativ vorgelagert — und welche dürfen tool-lokal bleiben?; Wer schließt fachliche Ebene und Grundgesamtheit?; Wann ist eine Filteränderung eine neue Metric-Version statt eines stillen Slices?

Thin-Consumer-Produkt

Thin ist der Default. Der Consumer gestaltet, er definiert nicht neu.

Es benötigt:

• zertifiziertes Produkt oder semantisches Modell; erlaubte Slices; verbotene Neudefinitionen; Kennzeichnung zertifiziert vs. Experiment; Nutzer-Stufe.

Entscheidungen:

• Welche Stufen dürfen nur lesen und slicen?; Wie sehen Nutzer den Unterschied zwischen zertifizierter Zahl und Sandbox?; Wer nimmt einen Report als schlankes Modell ab, obwohl er lokal eine Kennzahl-Formel enthält?

Thick-Waiver

Thick ist erlaubt, wenn es sichtbar, befristet und promotebar ist.

Entscheidungen:

• Welcher Use-Case rechtfertigt lokale Neudefinition?; Welches Expiry und welcher Produktfreigabe-Pfad gelten?; Wer darf den befristete Ausnahme verlängern — und was passiert, wenn Führung den befristete Ausnahme-Wert bereits steuert?

Change-Gate

Das Gate schützt das Shared Model vor stiller Promotion.

Entscheidungen:

• Wer darf fachliche Ebene, Grundgesamtheit oder Base Kennzahl heben?; Welcher Negativtest muss vorher bestehen (alte Nutzer, Vorstandsbericht, Vereinbarung-Exportdatei)?; Welche tool-lokalen Duplikate werden nach Produktfreigabe sunsett?

Wo Governance hängt

Zwischen Tool-Semantic und Upstream-Grain

Power BI, Tableau, Qlik und Excel können jeweils „ihr“ Modell bauen. Ohne Shared Grain ist jedes lokal korrekt und unternehmensweit falsch.

Zwischen Builder-Speed und zweitem führendes System

„Nur für diesen Sprint“ wird zur Wahrheit, sobald Steuerung und Board denselben Extract nutzen. Speed ohne Waiver ist Drift mit Deadline.

Zwischen Explorer-Experiment und zertifizierter Zahl

Slicen auf dem freigegebenen Modell ist erwünscht. Eine neue Population im Experiment, die ungekennzeichnet ins Pack wandert, ist Metric Drift.

Zwischen Advanced Analytics und Enterprise-Metrik

Features und Sandbox-Extracts dürfen lokal sein. Sie dürfen keine zweite Net-Revenue-Wahrheit für das Unternehmen erfinden.

Zwischen Shadow-Workbook und Board-Pack

Shadow-BI beginnt nicht beim ersten Excel. Sie beginnt, wenn eine Entscheidung den inoffiziellen Wert übernimmt und niemand den Contract nachzieht.

Zwischen Waiver-Expiry und stiller Übernahme

Ein abgelaufener Waiver, der weiter im Umlauf ist, ist ein ungenehmigtes Parallelmodell. Das Gate muss Expiry sichtbar machen.

Rollen-Mapping

Data Owner (Metric / Fachlichkeit)

Head of Finance, FP&A-Lead oder benannter Process Owner ist accountable für Zweck, Grain und Population der Kernkennzahlen. Der Owner entscheidet nicht das Dashboard-Layout.

Data Steward

Analytics Engineer, Revenue Operations oder ein Domain-Steward triagiert Drift-Tickets, pflegt die Consumer Map, überwacht Waiver-Fristen und eskaliert abweichende Tool-Modelle.

Data Product Owner

Priorisiert Shared-Model-Releases, Thin-Templates, Waiver-Queue und Sunset tool-lokaler Duplikate. Nutzen und Lieferbarkeit — nicht die fachliche Kennzahlendefinition.

Data Architect

Schützt Grain und Lineage Mart → Semantic → Tool, Historie von Metric-Versionen und Breaking Changes an Consumer-Schnittstellen.

Report- / BI-Builder

Liefern Darstellung und erlaubte Measures nach freigegebenen Patterns. Sie sind nicht Owner der Unternehmenszahl und nicht berechtigt, ein zweites Semantic als führendes System zu führen.

Data Custodian

BI-Admin und Plattformbetrieb setzen Berechtigungen, zertifizierte Workspaces und Publish-Gates um. Lizenzverwaltung ist keine Semantikhoheit.

Data Consumer

Report-Nutzer, Explorer, Advanced Analytics, Domain-Spezialisten (Pricing, Aktuariat, Supply). Abweichungen laufen über denselben Intake — keine stillen Workbook-Wahrheiten.

Mini-Fall

Symptom: Finance hat den Nettoumsatz in einer Auswertungstabelle freigegeben. Ein selbst gebautes semantisches Modell filtert Testkonten anders. In Tableau wurde eine Zahl direkt in der aktuellen Ansicht korrigiert. Vorstandsbericht und operative Steuerung weichen um vier Prozent ab. Die Führung fragt, welche Zahl gilt.

Typischer Fehlstart: Kennzahlenmodell-Lizenz kaufen und Reports certified taggen, ohne Shared fachliche Ebene, ohne schlankes Modell-Default und ohne Prüfpunkt gegen lokale Grundgesamtheit.

Vereinbarung: Kennzahl-ID mit fachlicher Ebene und Grundgesamtheit vorgelagert; schlankes Modell als Default; lokale Erweiterung nur mit befristete Ausnahme, Owner und Expiry; Change-Prüfpunkt vor Produktfreigabe; Inventar der tool-lokalen Modelle, die noch konkurrieren.

Kritische Übergaben

Anti-Patterns

• Jedes Report-Tool führt ein eigenes semantisches Modell als Wahrheit
• lokale Erweiterung ohne befristete Ausnahme, weil „nur dieser eine Report“
• Capability-Stufe mit Lizenzanzahl verwechseln
• Advanced Analytics als paralleles Enterprise-semantisches Modell
• Shadow-Workbooks steuern, ohne sie zu inventarisieren
• befristete Ausnahme-Expiry ignorieren, sobald das Board den Wert kennt
• BI-Admin als Metric-verantwortliche Person behandeln, weil der Workspace dort liegt

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metrics Foundations
• Lernpfad — Metrics Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Eine board-relevante Kennzahlenfamilie wählen. Grain, Population und Owner dokumentieren. Tool-lokale Modelle (Power BI, Tableau, Qlik, Excel) inventarisieren. Capability-Stufen grob zuordnen.

Schritt 2: Control und Nachweis umsetzen

Thin-Default für einen zertifizierten Consumer produktiv schalten. Einen Thick-Waiver mit Expiry ausstellen oder ein Parallel-Semantic schließen. Consumer Map mit erlaubten Aktionen führen.

Schritt 3: Testen und Ausnahmen sichtbar machen

Change-Gate und Negativtest: lokale Populationsänderung darf das Board-Pack nicht ungeprüft erreichen. Ein Drift-Ticket von Symptom bis Vertrag durchspielen. Ein Shadow-Workbook entweder waivern oder sunsetten.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Shared Grain, Thin-Default, Waiver, Gate) auf eine zweite Kennzahlenfamilie oder ein zweites Tool übertragen.

Exit-Kriterien

• Kernkennzahlen haben Shared fachliche Ebene, Grundgesamtheit und verantwortliche Person vorgelagert.
• schlankes Modell ist Default; lokale Erweiterung existiert nur mit befristete Ausnahme, Expiry und Produktfreigabe-Pfad.
• Capability-Stufen beschreiben erlaubte Aktionen, nicht nur Toolnamen.
• Change-Prüfpunkt und Negativtest sind dokumentiert und einmal durchlaufen.
• Tool-lokale Duplikate sind inventarisiert; Shadow-BI ist benannt oder geschlossen.

Weiterlesen

• Kennzahlenmodell vs Kennzahl im Report
• Self-Service-Kennzahlen vs. governed Metrics
• Ein Datenprodukt, mehrere Nutzer
• KPI-Definition, Verantwortung und Versionierung
• Rollen-Hub

Nicht jede Person mit Report-Zugang darf dieselbe Änderung an einer Kennzahl vornehmen. Capability-Stufen beschreiben Nutzungstiefe auf dem gemeinsamen Modell — nicht neue Governance-Hüte.

Dieser Teil bindet Stufen an Metrikzonen Base / Derived / Local — bevor Tool-Drift und Shadow-BI darauf aufsetzen.

Vorher: Gemeinsames Modell für alle Consumer-Stufen. Weiter: Tool-lokale Modelle und Kennzahlen-Drift.

zen wirkt „Self-Service“ wie Freigabe für jede Formel. Report-Nutzer ändern Filter, Explorer bauen Ableitungen, Builder legen Measures an, Analysten trainieren Features, Domain-Spezialisten pflegen Szenarien — und alle nutzen denselben Namen. Die Metrikzonen Base / Derived / Local bleiben unsichtbar.

Lösung: Jede Consumer-Stufe ist an Metrikzonen gebunden: Report-Nutzer filtern in freigegebenen Grenzen, Explorer ableiten lokal mit Owner und Ablauf, Builder folgen Mustern, Analytics bleibt Sandbox, Domain-Szenarien bleiben gelabelt. Population, Grain und geschützte Namen brauchen Promotion durch Owner und Steward.

In einem Satz: Die Stufe bestimmt, was Sie ändern dürfen; geschützte Namen und Grain wechseln nur über Owner-/Steward-Promotion.

Entscheidung

Verknüpfen Sie Capability-Stufen mit Metrikzonen. Der Data Owner schützt Base und geschützte Namen; der Steward triagiert Promotion und Konflikte; der Custodian setzt Labels und Pflichtfelder in Catalog und Tool durch.

Governed Base bleibt geschützt. Controlled Derived folgt Mustern. Local Exploratory ist erlaubt, wenn Label, Owner, Ablauf und kein Enterprise-Claim gelten — siehe Self-Service-Kennzahlen vs. governed Metrics.

Stufen-Workflow

1. Capability Change Matrix führen

Der Steward legt die Matrix an (Zeilen: Stufen; Spalten: lesen / filtern / ableiten / Measure / Scenario / Promote / Verbote) und koppelt sie an die Shared Model Consumer Map aus Teil 1. Der Data Owner genehmigt geschützte Namen. Ohne Matrix entscheidet die Tool-Lizenz, wer Grain ändert.

2. Zonen sichtbar machen

Custodian setzt Labels governed, derived, experimental dort, wo Consumer wählen — nicht nur im Wiki. KPI Definition hält Verträge für Base und Derived. Unsichtbare Zonen machen jede Ableitung zur heimlichen Base.

3. Promotion anstoßen

Wiederverwendung, Executive-/Finance-Nutzung oder ein geschützter Name öffnet ein Steward-Review mit Owner-Freigabe. Artefakt ist der Promotion-Antrag mit Scope und Zielzone. Still umbenennen auf den Basisnamen ist Drift, keine Agilität.

4. Konflikte eskalieren

Zwei Stufen beanspruchen dieselbe Population? Der Steward triagiert; der Data Owner schließt Grain. Report Inventory findet Measures, die ihre Zone verlassen haben. Wer Konflikte im Chat lässt, züchtet parallele Wahrheit.

5. Shadow-Stopps setzen

Unkontrolliertes Shadow — versteckte Autorität, kein Owner, kein Ablauf — ist kein Explorer-Recht. Harte Stopps und der Local-Pfad stehen in Teil 4. Fehlt der Stopp, wird jede lokale Formel zur Unternehmenskennzahl.

Handoffs

Anti-Patterns

• Self-Service als Lizenz für jede Formel behandeln
• Grundgesamtheit oder fachliche Ebene als Report-Filter umdefinieren
• Nützliche Ableitung still auf den geschützten Basisnamen umbenennen
• Domain-Szenario als unmarkierte Unternehmenskennzahl veröffentlichen
• Fünfzehn Rollen zeichnen, bevor eine Nutzer-/Builder-Trennung steht

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metrics Foundations
• Lernpfad — Metrics Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Capability Change Matrix für drei Stufen (Consumer, Builder, Owner-Änderung) veröffentlichen.
2. Geschützte Metriknamen mit dem Data Owner listen und im Catalog labeln.
3. Ein Promotion-Review für eine bereits wiederverwendete Local-Ableitung fahren.
4. Report Inventory auf Measures prüfen, die ihre Zone verlassen haben.

Mehrere Tool-Semantikmodelle für dieselbe fachliche Frage erzeugen Reconciliation-Schmerz und Executive-Misstrauen. Drift ist selten Absicht — sie entsteht, wenn Builder Power im Tool mit Autorität über Wahrheit verwechseln.

Power BI, Tableau und Qlik zeigen denselben Monatsnamen und drei Revenues. Ein Catalog-Badge ändert daran nichts. Dieser Teil macht Inventory, eine autoritative Schicht und Dual-Run zum Betriebsvertrag — auf den Capability-Stufen aus Teil 2.

Vorher: Capability-Stufen: was Sie ändern dürfen. Weiter: Wann Shadow-BI erlaubt ist.

z in Power BI. Team B in Tableau. Team C in Qlik. Filter, Wechselkurse und Ausschlüsse weichen still ab. Jeder Report ist lokal erklärbar; der Vergleich ist nicht. Meetings enden in Zahlenkämpfen statt Entscheidungen.

Lösung: Tool-lokale Modelle werden inventarisiert, an eine autoritative Schicht gebunden, im Dual-Run mit Toleranz und Enddatum verglichen und dann gebunden, migriert oder retired. Der Data Owner schließt Population und Grain; der Steward triagiert Drift; der Custodian setzt die Upstream-Bindung durch.

In einem Satz: Eine autoritative Schicht für Population und Grain; Tool-UX darf abweichen, die Fachdefinition nicht.

Entscheidung

Behandeln Sie Tool-lokale Modelle als Verdachtsfälle für Drift, nicht als Standardarchitektur.

1. Inventarisieren — Modelle, Measures, Consumer, Kritikalität (Report Inventory).
2. Eine autoritative Schicht wählen — Mart + Semantic Layer / zertifizierte Data Source als Upstream-Bindung.
3. Dual-Run — Referenz vs. Tool-Ausgabe mit Toleranz und Enddatum.
4. Sunset — konkurrierende Logik upstream migrieren oder Tool-Modell an die autoritative Schicht binden; Duplikate retire-n.
5. Bridge nutzen — Report/BI-Builder × Modell: Builder gestalten mit, entscheiden Grain nicht allein.

Darstellung und Layout bleiben tool-spezifisch. Population, Grain und Base Measures nicht.

Drift-Workflow

1. Modelle inventarisieren

Der Steward führt ein Tool-Local Model Drift Register: Modell-ID, Tool, Owner, Kennzahlen, Consumer, Kritikalität. Report Inventory liefert Fund und Abhängigkeiten. Ohne Register bleibt jede Abweichung ein Meeting-Streit statt ein Ticket.

2. Autoritative Schicht wählen

Der Data Owner benennt Mart plus Semantic Layer oder zertifizierte Data Source als Upstream. KPI Definition hält den Vertrag für Population und Grain. Ein Catalog-Eintrag „Revenue“ allein beweist keine vergleichbaren Zahlen.

3. Dual-Run fahren

Custodian vergleicht Referenz gegen Tool-Ausgabe mit Toleranz und Enddatum. Der Steward triagiert operative Breaches; der Data Owner entscheidet bei Definitionsverdacht. Dual-Run ohne Enddatum wird Dauer-Reconciliation.

4. Binden, migrieren oder retire-n

Konkurrierende Logik wandert upstream oder das Tool-Modell bindet sich an die autoritative Schicht. Duplikate bekommen Disposition und Review-Datum. „Beide behalten, bis es passt“ ist Sunset-Verweigerung.

5. Builder-Brücke nutzen

Builder gestalten Layout und erlaubte Measures mit; Grain schließen sie nicht allein. Formelgeneratoren laufen nur auf freigegebenen Mustern. Wird die Brücke übersprungen, entsteht das nächste Parallelmodell unter demselben Namen.

Handoffs

Anti-Patterns

• Tool-lokale Models als Standardarchitektur behandeln
• Catalog-Badge „Revenue“ als Drift-Fix akzeptieren
• Dual-Run ohne Toleranz und ohne Enddatum
• Builder fachliche Ebene und Grundgesamtheit allein schließen lassen
• Konkurrierende Definitionen behalten, weil „jedes Tool anders ist“

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metrics Foundations
• Lernpfad — Metrics Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Drei Tool-Modelle inventarisieren, die dieselbe Kennzahl beanspruchen.
2. Eine autoritative Schicht mit dem Data Owner benennen.
3. Einen Dual-Run mit Toleranz und Enddatum auf einer kritischen Kennzahl starten.
4. Eine Disposition (bind / migrate / retire) für das kritischste Duplikat festhalten.

Shadow-BI entsteht, wenn Teams Zahlen lokal bauen, weil der freigegebene Mart zu langsam oder zu eng ist. Unkontrolliert erzeugt das Drift und Audit-Lücken; mit Guardrails (Owner, Label, Ablauf) kann Local/Exploratory erlaubt bleiben — sonst verboten.

Dieser Teil trennt unkontrolliertes Shadow von kontrolliertem Local — auf den Stufen und der autoritativen Schicht aus Teil 2 und 3.

Vorher: Tool-lokale Modelle und Kennzahlen-Drift.

zerstört oft den Workflow und treibt Arbeit in noch undurchsichtigere Kopien. Uneingeschränkte Duldung macht jedes Workbook und jedes Tool-Modell zur konkurrierenden Wahrheit. Es fehlt die Trennung zwischen unkontrolliertem Shadow und kontrolliertem Local.

Lösung: Unkontrolliertes Shadow bleibt verboten. Kontrolliertes Local ist erlaubt mit Label, Owner, Ablauf und ohne Enterprise-Claim. Harte Stopps (kritische Entscheidung, mehrere Konsumenten, Finance/Regulatory, geschützte Namen) und ein Promotion-Pfad Local → Derived → Base trennen Exploration von Wahrheit.

In einem Satz: Local nur mit Owner, Label und Ablauf; Enterprise-Namen und kritische Entscheidungen brauchen governed Publish.

Entscheidung

Für jedes lokale Workbook, Tool-Modell oder Scratchpad:

1. Begriffe trennen — unkontrolliertes Shadow (versteckte Autorität, kein Owner/Test/Lineage) vs. kontrolliertes Local (Label, Owner, Ablauf, kein Zertifizierungs-Claim);
2. Guardrails — einmalige Hypothese, persönliches Scratchpad, gelabeltes Szenario auf Base, Analytics-Sandbox mit TTL oder Dual-Run mit Enddatum;
3. Harte Stopps — kritische Entscheidung, mehrere Konsumenten, wiederholte Verteilung, finanzielle oder regulatorische Wirkung, geschützter Name, fehlender Owner oder Ablauf;
4. Data Owner schließt Enterprise-Claim und Stopps; Steward führt Decision Card und Promotion; Custodian setzt Labels und Inventory-Flags durch;
5. Promotion-Pfad Local → Derived → Governed Base mit Inventory- und Owner-Review — siehe Capability-Stufen.

Kein Enterprise- oder Bonus-Claim auf einer Zahl ohne governed Publish.

Local-vs-Shadow-Workflow

1. Shadow von Local unterscheiden

Der Steward füllt eine Shadow vs Local Decision Card: Kritikalität, Scope, Owner, Ablauf, Upstream-Bindung. Versteckte Autorität ohne Test und Lineage ist Shadow — auch wenn das Dashboard offiziell aussieht. Wer nur das Dateiformat prüft, lässt Excel und Tableau dieselbe Lücke.

2. Guardrails setzen oder verbieten

Erlaubt bleibt zeitlich begrenzte Hypothese, persönliches Scratchpad ohne Weitergabe als Wahrheit, Domänen-Szenario auf Base, Analytics-Sandbox mit Contract-Extrakt und TTL, Dual-Run mit Enddatum. Der Data Owner genehmigt die Card. Ohne Guardrails ist „Exploration“ nur ein freundlicher Name für Shadow.

3. Harte Stopps durchsetzen

Kritische Entscheidungen, mehrere Konsumenten, Finance- oder Regulatory-Wirkung und geschützte Namen stoppen Local. Custodian flaggt Funde im Report Inventory. Eine Controlled-Local-Metrik, die Boni steuert, muss promotet oder der Anspruch gestoppt werden.

4. Promoten oder retire-n

Local → Derived → Base über Steward- und Owner-Review. Disposition auf der Card: retain local / promote / retire plus Review-Trigger. Dauerhafte Finance-Close-Logik nur in einem persönlichen Workbook ist Retirement-Verweigerung.

5. Zweck und PII halten

Auch Local bleibt zweckgebunden. PII- und Access-Grenzen gelten; Single-Person-Risiko braucht Backup. Wer Local vor dem Catalog versteckt, erzeugt die nächste Audit-Lücke — siehe Excel-Schatten-BI.

Handoffs

Anti-Patterns

• Pauschales Shadow-Verbot, das Arbeit in noch dunklere Kopien treibt
• Jedes Arbeitsmappe als Wahrheit dulden, weil „Self-Service“
• Controlled Local nennen und trotzdem Boni oder Board-Zahlen steuern
• verantwortliche Person oder Ablauf weglassen und es Exploration nennen
• Permanente Close-Logik nur in einem persönlichen Arbeitsmappe halten

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metrics Foundations
• Lernpfad — Metrics Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Fünf lokale Workbooks oder Tool-Modelle als Shadow vs Local klassifizieren.
2. Eine Decision Card mit Owner, Label und Ablauf für ein erlaubtes Local führen.
3. Einen harten Stopp (geschützter Name oder Finance-Nutzung) mit dem Data Owner testen.
4. Ein bereits verteiltes Local promoten oder mit Notice retire-n.