Unbekannte Quelle — wer hilft, PII, Qualität

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklärt sind.
• Quellumfang — Festlegung, welche Objekte geladen, übersprungen oder später geprüft werden.
• Personenbezogene Daten / PII — Informationen, die sich direkt oder indirekt auf eine Person beziehen. PII steht für „Personally Identifiable Information“.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, Zählebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Der Connector ist lizenziert. Leadership will „Salesforce im Warehouse“. Sales Ops ist im anderen Meeting, Privacy kommt „nach dem PoC“. Sechs Wochen später liegen Task.Description und ContentVersion neben Opportunity — ohne Zweck, ohne Owner.

Hier: Frage und Menschen vor dem ersten Copy. Skip ist Default. Welche Tabellen laden, bleibt in Lade-Entscheidungen; Owner suchen in Verantwortung finden.

Ausgangslage

Vier Muster erzeugen denselben Dump:

• Connector zuerst. Der Salesforce-Adapter ist frei; HubSpot wartet. Sechs Wochen Raw Load, keine Pipeline-Zahl nach Stage und verantwortliche Person.
• Inventar als Verständnis. Object-Zählung und Katalogimport ersetzen die Frage, wer morgen eingreifen muss.
• Alles für später. Notes, Attachments, Event Logs — Speicher ist billig, Governance nicht.
• personenbezogene Daten nach dem Proof of Concept. Contact.Email und Freitext sind schon in Nicht-Produktion, Slack-Screenshots und einem Dienstleister-Upload.

Was fehlt, ist nicht Motivation. Was fehlt, ist ein erster Kontakt, der Copy verdient. Welche Tabellen laden, bleibt in Welche Salesforce-Tabellen. Welche Quelle zuerst, in Welche Quelle zuerst laden?. Hier gilt nur: noch bevor der Scope-CSV existiert, darf niemand die Org ausschütten.

Entscheidung

1. Eine Frage, kein Inventar. „Salesforce onboarden“ ist kein Outcome. „Sales Leadership entscheidet morgens auf Opportunity- und Verantwortungsebene, wo in der offenen Pipeline eingegriffen wird“ ist eines.
2. Menschen vor Connector. Admin für Objekte, Sales Ops für Stage und Won, Privacy für Personenbezug — Teil 2.
3. Schema vor Copy. Object Manager, describe, Feldnamen und Keys. Kein Bulk-Export von Contact, Task, ContentVersion.
4. Skip ist Default. Logs, UI-Caches, Anhänge, unbegrenzter Freitext — SaaS-Exporte skippen. Include nur mit benannter Entscheidung.
5. PII am Namen, bevor Werte sichtbar sind. Unreviewed fließt nicht — Teil 3.
6. Sandbox-Profil ohne Leak. Sample in getrennter Umgebung. Keine echten Mails im Catalog. Profiling ist Hypothese — Teil 4.
7. Load nur für den Slice. Rest als Exclude/Defer mit Review-Trigger. Neue Custom Fields später durch dasselbe Tor.

Sizing

Anwendungsbeispiel: „Ladet erstmal Salesforce, wir sortieren später“

Ausgangslage: Mid-Market, neue Analytics-Lane. Der Connector steht. Niemand im Team hat die Org konfiguriert. Leadership will Pipeline im Board-Pack.

Korrektur in fünf Tagen:

1. Frage schriftlich: offene Opportunities nach Owner und Stage.
2. Hilfskarte: SF Admin, Sales Ops, ein Engineer, Privacy als Consulted.
3. Schema: Opportunity, User, Account als Kandidaten; Task/Event/Notes Defer.
4. Namensheuristik: Contact.Email unreviewed — Contact bleibt draußen, bis Zweck existiert.
5. Quellumfang als Artefakt, bevor der erste Job läuft.

Nach 30 Tagen trägt der Slice die Morgenfrage. Freitext ist nicht im Warehouse. Das ist der Test — nicht Objektanzahl.

Der Proof-Pfad bleibt in Von der SaaS-Quelle zum Pilot-Mart. Dieses Playbook ist das Protokoll bevor der Proof startet.

Betriebsablauf (nummeriert)

1. Benannte Frage, Population, Zählebene, Frist — eine Seite.
2. Hilfskarte: wer kennt Technik, Prozess, Buchung, Privacy.
3. Schema lesen; Skip-Muster anwenden; Unreviewed markieren.
4. Quellumfang Include/Defer/Exclude mit Review-Trigger.
5. Sandbox-Profil nur für Include-Kandidaten.
6. Drei Zählebene-Regeln, dann Copy — Teil 4.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Connector als Verständnis. Scheitert, weil Bewegung keine Bedeutung erzeugt.
• Alles laden, Speicher ist billig. Scheitert an personenbezogene Daten, Joins und Lifecycle — SaaS-Exporte.
• Katalogimport als Start. Scheitert, weil Samples leaken und Inventur wie Übernahme wirkt.
• Proof of Concept ohne Unreviewed-Prüfpunkt. Scheitert, weil Nicht-Produktion dieselbe personenbezogene Daten trägt.
• Admin als heimlicher verantwortliche Person. Scheitert, weil Objektkenntnis kein Entscheidungsrecht ist — Teil 2.
• Profil mit echten Werten im Slack. Scheitert als erste Leckage.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten echten 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.

Erster belastbarer Stand: Eine Frage. Hilfskarte. Quellumfang für einen Slice. Kein Freitext im Warehouse. Unreviewed-Gate an.

Stabiler Betrieb: Derselbe Slice hat Owner, drei Zählebene-Regeln und eine Beschreibung, die ein Nicht-Workshop-Teilnehmer findet. Neue Custom Fields laufen durch dasselbe Tor.

Checkliste

• Die Quelle hat eine benannte Entscheidung, kein „onboarden“.
• Menschen sind gefunden, bevor der Connector schreibt.
• Schema ist gelesen; Content ist nicht kopiert.
• Skip/Defer ist Default; Include hat Zweck.
• Unreviewed-Felder fließen nicht.
• Samples stehen nicht im Catalog.

Artefakt

First-Contact Card (Seite 1): Frage, Zählebene, Population, Hilfskarte (vier Hüte), Objekt-Allowlist, explizite Excludes, Review-Trigger. Wächst in den Folgeteilen um PII-Stufen, Profilfragen und Owner-Sätze.

Tools

• Source Umfang Builder — Include/Defer/Exclude, personenbezogene Daten, Review-Frage.
• personenbezogene Daten Recommend Generator — Namensheuristik vor Content.
• Governance Project Anfrageweg — Anfrageweg, bevor der Pilot-Flow startet.

Weiterführend

• Welche Quelle zuerst laden?
• Welche Salesforce-Tabellen laden
• SaaS-Exporte: Tabellen, die man nicht laden sollte
• Proof: SaaS-Quelle zum Pilot-Mart
• Verantwortung finden und verankern

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklärt sind.
• Quellumfang — Festlegung, welche Objekte geladen, übersprungen oder später geprüft werden.
• Personenbezogene Daten / PII — Informationen, die sich direkt oder indirekt auf eine Person beziehen. PII steht für „Personally Identifiable Information“.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, Zählebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Wer Opportunity.Amount joint, kennt die Drähte. Wer den Forecast steuert, kennt Won. Das sind selten dieselben Menschen — und keiner von beiden ist automatisch Owner. Owner ist, wer die Konsequenz trägt, wenn die Definition falsch ist. Der Kenner ist Consulted. Der Lader ist Custodian.

Teil 1 holt die Menschen vor dem Connector. Dieser Teil sagt, wen man bei welcher Frage holt, ohne RACI zu wiederholen. Decision Rights bleiben in Verantwortung ist Entscheidungsrecht. Experten als Netz, nicht als Komitee: Experten beraten, Owner entscheiden.

Ausgangslage

Die Lücke ist Arbeitsteilung, kein Versagen.

Wer lädt, sieht Keys, Record Types, IsDeleted, Formel-Felder, CDC-Lücken. Wer verkauft, sieht Stage-Theater, Credit-Hold, Vertrag vor Closed Won. Sales Ops erklärt den Forecast und nicht, warum Währungsumrechnung nicht zur Finance-Zahl passt. Finance erklärt den Beleg und nicht SOQL.

Drei falsche Anlaufstellen:

• Der Engineer als Orakel für „was ist Won?“
• Der Admin als verantwortliche Person, weil er Validation Rules kennt
• Das Organigramm statt der Frage

RACI sagt, wer entscheidet. Die Hilfskarte sagt, wen man vorher fragt, damit die Entscheidung nicht ins Leere läuft.

Entscheidung

Vier Hüte, oft vier Menschen — eine Person darf mehrere tragen, dann sichtbar:

Hilfskarte für die Pipeline-Zahl:

Privacy bleibt Consulted bei Personenbezug — nicht A für Stage. Tiefe: Teil 3 und Experten beraten.

Sizing

Anwendungsbeispiel: Amount stimmt im CRM, nicht im Board-Pack

Lehrfall. Der Mart zeigt Pipeline-Wert. Sales sagt, der Forecast sei höher. Engineering zeigt Opportunity.Amount plus Währung. Finance sagt, Won ohne Vertrag zähle nicht.

Schnitt:

• Technik: Engineer erklärt Zählebene und Währung — Consulted, nicht A.
• Prozess: Sales Ops erklärt Forecast Category vs. Stage — Experte.
• Buchung: Finance bleibt A für gebuchten Umsatz, C für die Pipeline-Karte.
• Streit „was ist offene Pipeline“: verantwortliche Person (Sales Ops mit Mandat) entscheidet; Steward schreibt den Satz; technischer Betreiber ändert den Test.

Kein Workshop, in dem alle mitstimmen. Kein „der der die Pipeline gebaut hat, besitzt Won“.

Betriebsablauf (nummeriert)

1. Fragetyp benennen: Schema, Prozess, Buchung, Zugriff, Definition.
2. Erste Anlaufstelle aus der Hilfskarte — nicht aus dem Organigramm.
3. Experte liefert Satz oder Join-Erklärung; Owner nur bei Streit oder Freigabe.
4. Custodian setzt um; Steward hält die Karte aktuell.
5. 48 Stunden Antwort oder Eskalation — nicht stiller Slack.

Owner finden über Evidenz bleibt Wie man echte Data Owner findet: Entscheidung → Prozess → Produkt → Quelle. Die Hilfskarte geht denselben Pfad vorwärts.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Wer lädt, owned. Scheitert, weil Custody keine Bedeutung trägt.
• Wer den Prozess kennt, joint. Scheitert an IsDeleted, Historie, Formeln.
• Admin als A für Won. Scheitert, weil Page Layouts kein Forecast-Mandat sind.
• Ein Slack-Kanal für alles. Scheitert, weil Fragetypen verschiedene Hüte brauchen.
• RACI statt Hilfskarte. Scheitert, weil niemand weiß, wen man zuerst fragt.
• Finance als heimliches Pipeline-A. Scheitert als Enteignung — zwei Zahlen, beschriftet, Komponieren, nicht mergen.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten echten 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.

Erster belastbarer Stand: Hilfskarte für eine Quelle, sechs Fragetypen, drei erreichbare Namen. Eine Streitfrage hat Owner, nicht den lautesten Chat.

Stabiler Betrieb: Ein Nicht-Workshop-Teilnehmer findet die Anlaufstelle im Catalog oder auf der First-Contact Card. Definitionsstreit geht an den Owner, Schemafragen nicht.

Checkliste

• Kennen, helfen, entscheiden, betreiben sind getrennt sagbar.
• Jeder Fragetyp hat eine erste Anlaufstelle.
• Engineer ist nicht Orakel für Won; Admin nicht verantwortliche Person der KPI.
• Privacy ist C bei Personenbezug, nicht A für Stage.
• Eskalation an verantwortliche Person nur bei Definitions- oder Risikostreit.
• Antwortfrist ist festgelegt.

Artefakt

Hilfskarte (Seite 2 der First-Contact Card): Fragetyp, erste Anlaufstelle, Consulted, A, 48-Stunden-Regel. Salesforce-Beispielzeilen dürfen bleiben, bis die eigene Org sie ersetzt.

Tools

• Stakeholder Matrix — Mandat, Wissen, Wirkung.
• Source Umfang Builder — Contacts je Objekt.
• RACI für Data Governance — nachdem die Hilfskarte steht.

Weiterführend

• Verantwortung ist Entscheidungsrecht
• Wie man echte Data Owner findet
• Experten beraten, verantwortliche Person entscheiden
• technischer Betreiber vs. kontrollverantwortliche Person

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklärt sind.
• Quellumfang — Festlegung, welche Objekte geladen, übersprungen oder später geprüft werden.
• Personenbezogene Daten / PII — Informationen, die sich direkt oder indirekt auf eine Person beziehen. PII steht für „Personally Identifiable Information“.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, Zählebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Contact.Email heißt nicht „später taggen“. Es heißt: nicht kopieren, bis Zweck und Stufe stehen. Freitext (Task.Description, Notes, Attachments) ist Default hoch — oft Exclude. Scanner schlagen vor; Owner und Privacy geben frei. Samples im Catalog sind Daten, oft die erste Leckage.

Stufen direkt / indirekt / abgeleitet / kombiniert bleiben in PII-Klassifikation. Dieser Teil ist das Tor vor dem Copy an einer unbekannten Quelle — inkl. Schema-Drift nächste Woche.

Ausgangslage

Drei Irrtümer am Start:

• Namen reichen später. Bis „später“ ist die Spalte in Nicht-Produktion, dbt-Docs und einem Dienstleister-CSV.
• Scanner ersetzen Freigabe. Regex findet Mails, nicht „Funktion + PLZ + Geburtsdatum“.
• Proof of Concept ist harmlos. Dieselbe Grundgesamtheit, schwächere Rechte, mehr Screenshots.

Hilfskarte aus Teil 2: Steward schlägt vor, Privacy/DSB ist Consulted, Owner gibt Zweck frei, Custodian hält das Gate. Der DSB löscht nicht und klassifiziert nicht im Alleingang.

Entscheidung

1. Unreviewed-Gate. Feld ohne Stufe fließt nicht in Mart, BI oder AI. PII Unreviewed Gate.
2. Zweck vor Copy. Kein Zweck → kein Contact.Description, kein Task-Body, kein ContentVersion.
3. Heuristik vor Inhalt. Email, Phone, MailingStreet, Name, Custom SSN__c / Bank__c sind Verdacht — PII Recommend.
4. Content-Scan nur in der Sandbox. Hit-Rates aggregiert; keine echten Werte im Catalog oder Slack.
5. Freitext und Files default Defer/Exclude, bis Zweck plus DSDR-Pfad existieren — PII vor AI-Ingestion.
6. Neue Objekte und Fields = unreviewed. Schema-Drift ist Normalfall, nicht stilles Include.
7. Samples sind Daten. Preview folgt derselben Maskierung wie die Plattform — Policies und sensible Daten.

Gestufte Erkennung:

Sizing

Anwendungsbeispiel: Contact sollte „nur für den Account-Namen“ mit

Lehrfall. Der Slice braucht Account-Name am Opportunity-Zählebene. Jemand zieht Contact „mit, falls wir später Personen-Reports wollen“. Email, MobilePhone, Description landen im Raw. Catalog zeigt Sample-Mails. Ein Package addiert TaxId__c.

Korrektur:

• Account-Name aus Account, nicht aus Contact-personenbezogene Daten.
• Contact bleibt Defer; Review-Trigger: benannter Personen-Use-Case plus Minimierung.
• Samples aus dem Catalog entfernen; Preview-Richtlinie.
• TaxId__c unreviewed — Connector-Freigabeliste, nicht „alles Neue“.
• Privacy C, verantwortliche Person A für Zweck, technischer Betreiber R fürs Prüfpunkt.

Betriebsablauf (nummeriert)

1. Feldliste aus Schema; Heuristik laufen lassen.
2. Unreviewed und Freitext auf Defer/Exclude.
3. Zweck je Include-Feld; Privacy C bei Personenbezug.
4. Optional Sandbox-Scan — aggregierte Hits, keine Rohwerte in Tickets.
5. Gate in der Pipeline; Drift: neue Fields blocken, bis Review.
6. Nebenkopien (Nonprod, Export, Notebook) dieselbe Regel.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Taggen nach dem Load. Scheitert, weil Kopien die Tags nicht kennen.
• Scanner als verantwortliche Person. Scheitert bei kombiniertem Personenbezug.
• Proof of Concept-Ausnahme. Scheitert als zweite unkontrollierte Kopie.
• Catalog-Samples mit echten Mails. Scheitert als öffentliche personenbezogene Daten.
• Custom Fields automatisch Include. Scheitert, weil Packages die schärfsten Felder bringen.
• DSB klassifiziert im Alleingang. Scheitert an Mandat und an der Pipeline — Teil 2.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten echten 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.

Erster belastbarer Stand: Unreviewed-Gate am Slice. Freitext draußen. Heuristik für Salesforce-Standard plus Customs. Preview ohne Rohwerte.

Stabiler Betrieb: Ein neues Custom Field wurde geblockt, reviewed, dann bewusst Include oder Defer. Ein PoC-Upload ohne Purpose ist abgelehnt.

Checkliste

• Unreviewed fließt nicht in Mart, BI oder KI.
• Jedes Include-Feld hat Zweck.
• Freitext und Files sind Defer, bis Zweck plus Auskunfts- und Löschrechte existieren.
• Samples sind maskiert oder fehlen.
• Schema-Drift trifft dasselbe Prüfpunkt.
• Privacy ist C, verantwortliche Person A, technischer Betreiber R fürs Prüfpunkt.

Artefakt

PII-Tor (Seite 3): Allowlist, Unreviewed-Liste, Freitext-Excludes, Review-Trigger für neue Fields, Preview-Regel. Hängt an der First-Contact Card.

Tools

• personenbezogene Daten Recommend Generator
• personenbezogene Daten Unreviewed Prüfpunkt Generator
• personenbezogene Daten Richtlinie Generator
• personenbezogene Daten Auskunfts- und Löschrechte Readiness

Weiterführend

• personenbezogene Daten-Klassifikation: direkt, indirekt, abgeleitet, kombiniert
• personenbezogene Daten & Privacy Governance
• personenbezogene Daten vor KI-Ingestion stoppen
• Metadaten nah an der Quelle

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklärt sind.
• Quellumfang — Festlegung, welche Objekte geladen, übersprungen oder später geprüft werden.
• Personenbezogene Daten / PII — Informationen, die sich direkt oder indirekt auf eine Person beziehen. PII steht für „Personally Identifiable Information“.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, Zählebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Ein Überblick über eine unbekannte Quelle ist kein Observability-Kauf und kein vollständiges Warehouse-Profil. Es ist ein Job: Form sehen, Hypothesen notieren, drei Regeln schreiben, die die Zählebene der Frage schützen. Profiling beweist nicht, dass die Pipeline gut genug für den Close ist.

Zweck, Population und Körnung vor dem Test: Qualität beginnt vor dem ersten Test. Die drei Schleifen: Profiling, Validierung, Observability. Produktnamen vs. Fähigkeiten: Metadaten-Tools.

Ausgangslage

Vier Verwechslungen:

• Catalog = Überblick. Metadatenimport ohne Frage zählt Objekte, erklärt Won nicht.
• Profil = Qualität. Nullrate 2 % ist Beschreibung, keine Akzeptanz.
• Observability zuerst. Anomalie-Produkte lohnen, wenn ein Produkt kaputtgehen kann — nicht am Start.
• Testbibliothek als Onboarding. Ohne Zweck und Grundgesamtheit sind Tests Theater — Qualität vor dem Test.

PII-Gates aus Teil 3 bleiben stehen: kein Profil mit echten Mails im Catalog.

Entscheidung

Werkzeuge nach Job, nicht nach Logo:

Drei bis fünf Regeln, die die Zählebene schützen — Salesforce-Pipeline:

1. Opportunity-Id eindeutig im Slice.
2. Stage und CloseDate gesetzt für die Population der Frage.
3. Account existiert (Referenz).
4. Frische: SystemModstamp nicht älter als die vereinbarte Schwelle.
5. Stage nur aus dem vereinbarten Enum — neue Werte sind Triage, keine stille Anpassung.

Negative Amounts ohne Retouren-Kontext sind zuerst Hypothese. Finance erklärt Gutscheine oder Fehler — dann Regel. Das Profil hat gefragt; der Owner hat akzeptiert.

Sizing

Anwendungsbeispiel: Freshness grün, Forecast falsch

Lehrfall. Der Job ist grün. Stage enthält einen neuen Wert Verbal Commit. Amount ist in 8 % der offenen Zeilen null. Engineering will 40 Generic-not-null-Tests.

Korrektur:

• Freshness bleibt Observability — sie beweist keinen Forecast.
• Neuer Stage-Wert: Sales Ops (Experte) erklärt; verantwortliche Person entscheidet, ob Enum erweitert oder Quelle korrigiert wird.
• Null-Amount: Grundgesamtheit prüfen (entwurfene Deals?). Dann eine Regel für die offene Pipeline, nicht für alle historischen Rows.
• Drei Tests an der fachlichen Ebene, nicht vierzig am Raw.

Betriebsablauf (nummeriert)

1. Nur Include-Kandidaten profilieren — Sample, Sandbox, keine PII-Previews.
2. Hypothesen notieren: Keys, Nulls, Enums, Orphans, Verzug.
3. Mit der Hilfskarte klären, was legitim ist — Teil 2.
4. Owner akzeptiert 3–5 Regeln; Custodian implementiert (dbt DQ Rules).
5. Drift: neue Enums und Null-Sprünge als Triage, nicht als stilles Absenken.
6. Observability erst, wenn der Slice Consumer hat.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Nur Profiling. Scheitert, weil Beschreibung keine Akzeptanz ist.
• Observability ohne Produkt. Scheitert als Tool ohne Adressat.
• Tests ohne Zweck. Scheitert am Close trotz grüner Scores.
• Voller Scan als Überblick. Scheitert an Kosten und personenbezogene Daten.
• Catalog-Produkt als Architektur. Scheitert — Fähigkeiten zählen, Metadaten-Tools.
• 80 Raw-Tests. Scheitert an Rauschen; die Zählebene bleibt ungeschützt.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten echten 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.

Erster belastbarer Stand: Ein Sample-Profil des Slices. Drei Zählebene-Regeln live. Freshness getrennt von fachlicher Validierung.

Stabiler Betrieb: Eine Drift-Triage hat eine Regel verschärft oder eine legitime Ausnahme dokumentiert — nicht still ignoriert.

Checkliste

• Überblick läuft auf Include-Sample, nicht auf dem Org-Dump.
• Profiling-Fragen und akzeptierte Regeln sind getrennt.
• 3–5 Regeln schützen die Zählebene der Frage.
• personenbezogene Daten-Samples sind nicht im Profilbericht.
• Observability ist dem Produkt nachgeordnet.
• Neue Enums sind Triage.

Artefakt

Profil- und Regelblatt (Seite 4): Hypothesen, Population, 3–5 Regeln, Runner (dbt/Soda/…), Drift-Weg. Hängt am Quellumfang.

Tools

• Source Umfang Builder
• dbt DQ Rules Generator
• dbt DQ Macro Generator
• Schema YML Editor

Weiterführend

• Qualität beginnt vor dem ersten Test
• Profiling, Validierung und Observability
• Metadaten-Tools und Produktkategorien
• Quality Gates und Verträge

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklärt sind.
• Quellumfang — Festlegung, welche Objekte geladen, übersprungen oder später geprüft werden.
• Personenbezogene Daten / PII — Informationen, die sich direkt oder indirekt auf eine Person beziehen. PII steht für „Personally Identifiable Information“.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, Zählebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Beschreiben heißt nicht, alle Salesforce-Felder zu beschriften. Es heißt, den Slice so zu beschriften, dass ein Nicht-Workshop-Teilnehmer Zweck, empfohlenes Asset, Owner, Frische, Qualität und Grenzen findet — ohne zu raten. Owner wird nicht, wer die Daten kennt. Owner wird, wer die Konsequenz trägt, wenn die Definition falsch ist.

Metadaten nah an der Quelle: Metadaten gehören möglichst nah an die Quelle. Finden und Zählebene: Wie man echte Data Owner findet, Verantwortung sinnvoll zuordnen.

Ausgangslage

Drei Muster lassen den Slice stumm:

• Metadatenimport als Dokumentation. Technische Namen ohne Prozess.
• Wer anlegt, owned. Cost Center und Pipeline-Job werden zu Accountability.
• Alle Felder zuerst. Das Catalog-Programm stirbt; der Slice bleibt ohne den einen Satz, den der Produktiveinsatz braucht.

Die Hilfskarte aus Teil 2 bleibt: Admin pflegt Labels in Salesforce; Sales Ops pflegt „Won heißt Vertrag“; Engineer pflegt Join und Test.

Entscheidung

Wer schreibt welchen Satz wann

Nicht warten, bis „der Catalog vollständig“ ist. Beschreiben, wenn eine Entscheidung den Satz braucht.

Owner bestimmen

Vier Eigenschaften aus der Verantwortung-Serie — alle vier, sonst Experte oder Custodian:

1. Versteht die Wirkung.
2. Darf die relevante Entscheidung treffen.
3. Kann Prioritäten beeinflussen.
4. Akzeptiert die Rechenschaft.

Rückwärts: Entscheidung → Prozess → Produkt → Quelle. Organigramm zuletzt zur Mandatsprüfung. Der Engineer, der fct_opportunity baut, owned nicht Won. Der CRM-App-Owner owned nicht automatisch die kuratierte Revenue-Sicht.

Team-Verantwortung braucht einen erreichbaren Kanal, Frist und Eskalation — ein Gruppenpostfach ohne Prozess ist kein fachlicher Owner.

Sizing

Anwendungsbeispiel: vollständiger Metadatenimport, aber weiterhin drei Betragsdefinitionen

Lehrfall. Catalog zeigt Owner „Sales Analytics“. Niemand antwortet in 48 Stunden, ob gekündigte Verträge zählen. Amount, ExpectedRevenue und ein Custom ARR__c haben dieselben zwei Sätze Copy-Paste.

Korrektur:

1. Eine Entscheidung: offene Pipeline für den Morgen-Standup.
2. Evidenzpfad: Regionalleitung nutzt den Report; Sales Ops definiert Stages; Engineer betreibt den Mart.
3. Owner: Sales Ops mit Mandat — nicht der Mart-Job.
4. Drei Sätze: Technik (Custodian), Bedeutung (Steward, freigegeben), Grenze (nicht Finance-Umsatz).
5. Consumer-Test: jemand, der nicht im Workshop war, findet Zweck, Asset, Owner, Frische, Limit.

Betriebsablauf (nummeriert)

1. Nur Slice-Assets beschriften — nicht die Org.
2. Technische Schicht beim Load; keine fachliche Behauptung ohne Owner.
3. Bedeutungs-Satz bei der ersten Streit- oder Consumer-Frage.
4. Contract, wenn jemand den Slice produktiv nutzt.
5. Owner-Evidenz jährlich oder bei Prozessbruch prüfen — Verantwortung im Takt.
6. First-Contact Card schließen: Frage, Hilfskarte, PII-Tor, Regeln, Sätze, A.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Alle Felder zuerst. Scheitert als Programm ohne Nutzer.
• Engineer als verantwortliche Person im Catalog. Scheitert, sobald Won streitet.
• App-verantwortliche Person = Datenprodukt-verantwortliche Person. Scheitert an kuratierten Sichten.
• Copy-Paste-Beschreibungen. Scheitert, weil Amount dann alles bedeutet.
• Nur zentrale Catalog-Pflege. Scheitert, wenn Salesforce-Hilfe und dbt divergieren — nah an der Quelle.
• verantwortliche Person ohne Frist. Scheitert als Namensschild — Verantwortung ist Entscheidungsrecht.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten echten 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.

Erster belastbarer Stand: Slice-Readme mit drei Schichten. Owner mit Mandat und Stellvertretung. Consumer-Test mit einer Person außerhalb des Workshops.

Stabiler Betrieb: Ein Contract oder Gate am Slice. Ein Owner-Wechsel ohne Drift. Die First-Contact Card ist das Betriebsartefakt, nicht das Kickoff-Foto.

Checkliste

• Technische, fachliche und Versprechen-Sätze sind unterscheidbar.
• verantwortliche Person erfüllt die vier Eigenschaften; sonst Experte oder technischer Betreiber.
• Catalog zeigt erreichbaren Kanal, nicht nur ein Teamlabel.
• Ein Außenstehender findet Zweck, Asset, verantwortliche Person, Limit.
• Pflegeort der Bedeutung ist nah an der Quelle, Catalog verbindet.
• Unbekannte neue Fields bleiben unreviewed — Teil 3.

Artefakt

Slice-Readme (Seite 5 — Abschluss der First-Contact Card): Zweck, Zählebene, Include/Exclude, PII-Stufen, 3–5 Regeln, Hilfskarte, Owner/Steward/Custodian, drei Beschreibungsschichten, Eskalation. Das ist das Pack, das der nächste Domain übernehmen kann.

Tools

• OpenMetadata Domain & Product Generator
• Source Umfang Builder
• KPI Definition
• Mart-Steckbrief-Generator

Weiterführend

• Verantwortung finden und verankern
• Domains, Datenprodukte und Verantwortung
• Metadaten nah an der Quelle
• Proof: SaaS-Quelle zum Pilot-Mart
• Governance als gemeinsamer Standard