Lade-Entscheidungen für Quellsysteme

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• Quellumfang — dokumentierte Entscheidung, welche Quellen, Tabellen, Felder und Beziehungen für ein Analytics-Produkt geladen, ausgeschlossen oder vertagt werden.
• Zählebene — Einheit der Analyse, zum Beispiel Opportunity, Opportunity Line Item, Account-Aktivität oder Snapshot.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Ist die Org dem Analytics-Team noch unbekannt, zuerst das Erstkontakt-Protokoll: Frage, Menschen, Schema vor Copy.

Herausforderung

Ein objektgetriebener Ansatz beginnt häufig mit einem Connector, einem Exportkatalog oder einem Metadaten-Scan. Weil Objekte verfügbar sind, werden sie „für später“ ausgewählt. So entsteht schnell Datenvolumen, aber nicht automatisch verwertbare Information.

Die daraus entstehenden Probleme sind strukturell:

• Niemand kann erklären, welche analytische Frage ein Objekt unterstützt.
• Tabellen mit unterschiedlichen Zählebenen werden ohne definiertes Beziehungsmodell verbunden.
• Aktuelle Datensatzwerte werden behandelt, als würden sie historische Zustände abbilden.
• Notizen, Aktivitäten, Dateien und Beschreibungen bringen unkontrollierten Freitext und personenbezogene Daten in die Plattform.
• Custom Objects werden ignoriert, obwohl in ihnen möglicherweise der eigentliche Geschäftsprozess umgesetzt ist.
• Standardnamen werden vertraut, obwohl ihre konfigurierte Business-Bedeutung abweicht.
• Gelöschte oder zusammengeführte Datensätze verschwinden ohne explizite Downstream-Regel aus Kennzahlen.
• Jeder spätere Nutzer erbt eine große, schlecht governte Source-Schicht.

Der Objektkatalog definiert nicht das Analytics-Produkt

Ein Katalogeintrag hilft bei der Discovery. Er ist nicht der Analytics-Vertrag, nicht Metadata als Ganzes und kein Dashboard.

Dieselbe Salesforce-Organisation kann für unterschiedliche Analytics-Produkte unterschiedliche Quellumfangs benötigen:

• Ein Produkt für Pipeline nach Stage und verantwortliche Person benötigt möglicherweise Opportunity, die relevanten Account- und Referenz zur verantwortlichen Personen, governte Stage-Semantik und ausgewählte Datumsfelder. Produktpositionen sind nicht erforderlich, solange die Kennzahl nicht auf Positions- oder Produkt-Zählebene liegt.
• Ein Produkt für Bookings nach Produkt benötigt häufig die kommerzielle Beziehung von Opportunity über OpportunityLineItem und PricebookEntry zu Product2 sowie die organisationsspezifische Definition von gebucht, gewonnen, storniert und wirksamem Datum.
• Ein Produkt für Lead Conversion kann Lead und die bei der Konvertierung erzeugten Datensätze oder Schlüssel benötigen. Campaign und CampaignMember bleiben konditional, weil Attribution vom konfigurierten Prozess und nicht allein von der Objektverfügbarkeit abhängt.
• Ein Produkt für Account-Aktivität benötigt Task, Event oder eine andere Aktivitätsquelle nur dann, wenn Entscheidung, Ereignistyp, Akteur, Zeitraum und Ziel-Zählebene definiert sind.

Diese Beispiele sind Muster. Sie sind keine universelle Salesforce-Ladeliste.

Drei Zeitbedeutungen müssen getrennt werden

Salesforce-Quelldaten können unterschiedliche zeitliche Perspektiven unterstützen, diese dürfen jedoch nicht implizit vermischt werden:

1. aktueller Zustand fragt, wie ein Datensatz jetzt aussieht.
2. Event- oder Feldhistorie fragt, welche aufgezeichnete Änderung wann stattgefunden hat.
3. Snapshot-Historie fragt, wie der vollständige relevante Zustand zu wiederkehrenden Zeitpunkten aussah.

Ein veränderbarer aktuell-State-Datensatz kann nicht jeden früheren Zustand rekonstruieren. Ein History-Objekt oder eine Audit-Quelle hilft nur für die Felder und Zeiträume, die tatsächlich aufgezeichnet wurden. Ein Snapshot ist eine eigenständige analytische Designentscheidung und muss in der Datenplattform bewusst erzeugt und aufbewahrt werden.

Freitext ist eine eigene Scope-Entscheidung

Felder und Objekte mit Notizen, Beschreibungen, E-Mails, Kommentaren, Aktivitäten oder Dateien dürfen nicht allein deshalb in den Scope gelangen, weil sie mit einem benötigten Business-Datensatz verknüpft sind. Task, Event, EmailMessage, ContentNote, ContentDocument, ContentVersion, ContentDocumentLink und ältere Attachment-Strukturen können große Volumina, vertrauliche Inhalte, personenbezogene Daten und Binärdateien einbringen.

Für jede Freitext- oder Datei-Quelle braucht es einen konkreten Anwendungsfall, eine Feld-Allowlist, Zugriffsregeln, Retention und eine dokumentierte Entscheidung, ob Inhalt, Metadaten oder lediglich ein abgeleitetes Signal benötigt werden.

Ansatz

KMU/SMB — eine Salesforce-Entscheidung mit Allowlist für Objekte/Felder. Mid-Market — Prozess-Scopes je Domain mit Ausschluss-Listen. Enterprise — Multi-Org-Authority, History- und PII-Gates mit wiederverwendbaren Source-Verträgen.

Leite den Salesforce-Ladeumfang aus Geschäftsprozess und Ziel-Zählebene ab, nicht aus dem vollständigen Objektkatalog. Jedes eingeschlossene Objekt benötigt einen analytischen Zweck. Jedes zurückgestellte oder ausgeschlossene Objekt benötigt eine Begründung und einen Review-Auslöser.

Nutze dafür die folgende Entscheidungsreihenfolge.

1. Die analytische Entscheidung formulieren

Beschreibe die Frage als Entscheidung, nicht als Dashboard-Titel.

Schwach:

Ein Salesforce Sales Dashboard bauen.

Stärker:

Die Vertriebsleitung entscheidet, wo sie im laufenden Quartal eingreifen muss, indem sie offene Pipeline, Stage Age, erwartetes Abschlussdatum und verantwortlicher Person auf Opportunity-Zählebene vergleicht.

Die stärkere Formulierung benennt Nutzer, Handlung, Zeitraum und analytische Zählebene. Gleichzeitig zeigt sie, dass Produktpositionen, Aktivitäten, Notizen oder Cases nicht automatisch erforderlich sind.

2. Prozess, Event und Ziel-Zählebene festlegen

Vor der Objektauswahl müssen feststehen:

• der beobachtete Geschäftsprozess;
• das Ereignis, das einen Fakt erzeugt oder verändert;
• die Zählebene jeder vorgesehenen Faktentabelle;
• die Dimensionen, die diesen Fakt interpretierbar machen;
• die Zeitbedeutung: aktueller Zustand, Event-Historie oder Snapshot;
• die Kennzahlen und Entscheidungen, die das Modell unterstützen muss.

Mögliche Ziel-Zählebenen sind eine Zeile pro Opportunity, Opportunity-Position, Lead-Conversion-Event, Case-Status-Event oder Account-Tag. „Eine Zeile pro Salesforce-Datensatz“ ist keine ausreichende analytische Zählebene, weil damit lediglich die Quellstruktur wiederholt wird.

3. Die erforderlichen Business-Beziehungen verfolgen

Beginne mit dem zentralen Fakt und ergänze nur Beziehungen, die benötigte Bedeutung liefern.

Für einen produktbezogenen Sales-Fakt ist ein häufiges Muster:

Account
  └─ Opportunity
       └─ OpportunityLineItem
            └─ PricebookEntry
                 └─ Product2

Diese Beziehung ist ein Beispiel. Deine Organisation kann stattdessen Custom Products, Subscriptions, Quotes, Orders, Revenue Schedules, Objekte aus Managed Packages oder eigene Junction Objects verwenden.

Für jede Beziehung werden dokumentiert:

• analytischer Zweck;
• Kardinalität und Optionalität;
• Auswirkung auf die Ziel-Zählebene;
• Business Key und Salesforce-Identifier;
• aktuelle gegenüber historischer Bedeutung;
• Umgang mit Duplikaten und verwaisten Datensätzen;
• personenbezogene Daten-Klassifikation;
• ob die Beziehung autoritativ oder lediglich technisch bequem ist.

Lade eine Beziehungstabelle nicht nur deshalb, weil sie existiert. Ein Junction Object ohne Ziel-Zählebene und Allokationsregel kann aus einem Business-Ereignis doppelte Fakten oder ein ungelöstes Many-to-many-Modell erzeugen.

4. Jedes Objekt klassifizieren

Nutze vier Entscheidungszustände statt einer binären Laden-oder-Ignorieren-Auswahl.

Must-have

Das Objekt oder die Exporttabelle ist erforderlich, um den ausgewählten Fakt, eine Dimension, einen Filter, eine Kontrolle oder eine Abstimmung auf der vereinbarten Zählebene zu erzeugen.

Mögliche Muster für einen produktbezogenen Pipeline-Use-Case sind:

• Opportunity als Quelle des kommerziellen Fakts;
• OpportunityLineItem, wenn die Ziel-Zählebene eine Position oder ein Produkt ist;
• Account, wenn Account-Merkmale für die Segmentierung benötigt werden;
• PricebookEntry und Product2, wenn Produkt- und Pricebook-Semantik erforderlich sind;
• User oder eine andere governte Referenz zur verantwortlichen Person, wenn Verantwortlichkeit Teil der Entscheidung ist;
• ausgewählte Datums-, Währungs- oder Territory-Attribute, wenn sie die Kennzahl materiell beeinflussen.

bedingt

Das Objekt wird nur geladen, wenn eine benannte Anforderung freigegeben wurde.

Typische Beispiele sind:

• Lead für Lead-Funnel- oder Conversion-Analysen;
• Campaign und CampaignMember für ein definiertes Attributionsmodell;
• Case für Service-Ergebnisse oder die Interaktion zwischen Sales und Service;
• Task und Event für eine explizite Aktivitätskennzahl;
• die jeweils passenden History-Objekte oder Audit-Quellen für ausgewählte Änderungen;
• Custom Objects und Objekte aus Managed Packages, die den tatsächlichen Geschäftsprozess umsetzen;
• Contact Roles oder andere Beziehungsobjekte, wenn das Zielprodukt sie benötigt.

Zurückstellen

Das Objekt kann später relevant werden, aber das aktuelle Produkt rechtfertigt Kosten oder Risiko noch nicht. Der Quellumfang dokumentiert, welcher Nachweis den Wechsel in den freigegebenen Umfang auslösen würde — beispielsweise eine finanzierte Kennzahl, eine bestätigte verantwortliche Person, eine Retention-Entscheidung oder ein abgestimmtes Beziehungsmodell.

Ausschließen

Das Objekt hat keinen freigegebenen analytischen Zweck oder verletzt die aktuelle Scope-Grenze. Typische Beispiele sind ungenutzte Feature-Objekte, Setup- und UI-Hilfsobjekte, doppelte Exportstrukturen, uneingeschränkte Notizen oder Attachments sowie technische Logs ohne operativen Analytics-Use-Case.

5. Feldbasierte Controls anwenden

Die Aufnahme eines Objekts autorisiert nicht automatisch alle Felder. Erstelle eine Feld-Allowlist auf Basis von:

• Zweck als Kennzahl oder Dimension;
• Business-Definition;
• Join- oder Abstimmungsbedarf;
• Klassifikation personenbezogener Daten;
• Freitext- und Secret-Risiko;
• benötigter Präzision und Formatierung;
• Aktualität- und Änderungsverhalten;
• Retention- und Löschanforderungen.

Felder wie Namen, E-Mail-Adressen, Telefonnummern, Anschriften, freie Beschreibungen, Kommentare und nutzerdefinierte Betreffzeilen sind separate Risikoentscheidungen. Benötigt der Anwendungsfall nur Kategorie, Anzahl, Flag oder Alter, sollte dieses kontrollierte Signal geladen oder abgeleitet werden, statt unbeschränkten Inhalt zu kopieren.

6. Löschung, Historie und Snapshot-Verhalten entscheiden

Salesforce-Datensätze können gelöscht, zusammengeführt oder soft-deleted werden. Ein Quellumfang muss deshalb festlegen, ob Downstream Analytics einen solchen Datensatz:

• entfernt;
• als historisch gültig erhält;
• als gelöscht markiert;
• nach einer Zusammenführung der verbleibenden Business-Entität zuordnet;
• als Löschereignis für Audit oder Kennzahlenkorrektur aufbewahrt.

Gehe nicht davon aus, dass eine normale aktuell-Record-Abfrage gelöschte Zeilen enthält. Salesforce stellt Abfragemechanismen bereit, die noch verfügbare soft-deleted Datensätze einbeziehen können. Das analytische Erfordernis — nicht der Default der Extraktion — muss das Downstream-Verhalten bestimmen.

Für Historie werden die konkret benötigten Felder oder Events benannt. Native History-Daten hängen von Konfiguration und Lizenzierung ab; Umfang und Retention müssen in der tatsächlichen Organisation geprüft werden. Wird eine vollständige Point-in-time-Rekonstruktion benötigt, sind Plattform-Snapshots zu definieren, statt die Source-Historie pauschal als ausreichend anzunehmen.

7. Custom Configuration über Objektnamen stellen

Ein Standardobjektname garantiert keine standardisierte Business-Bedeutung. Organisationen können Labels umbenennen, Stage-Prozesse verändern, Record Types einführen, Validierungslogik ergänzen, Custom Fields anlegen, Managed Packages installieren und kritische Transaktionen in Custom Objects mit der Endung __c abbilden.

Prüfe den konfigurierten Prozess gemeinsam mit fachlich Verantwortlichen und Administratoren. Der richtige Scope kann weniger Standardobjekte und mehr Custom Objects enthalten als eine generische Referenzarchitektur vermuten lässt.

Checkliste

Nutze diese Checkliste vor der Freigabe des Salesforce Quellumfang.

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Entscheidung und Zeithorizont.
• Geschäftsprozess und relevantes Event sind explizit.
• Jeder Fakt besitzt eine definierte Ziel-Zählebene.
• aktueller Zustand, Event-Historie und Snapshots sind getrennt.
• Kennzahlen besitzen abgestimmte Business-Definitionen und Datumssemantik.

Objekte und Beziehungen

• Jedes eingeschlossene Objekt unterstützt eine benannte Anforderung.
• Standardobjekte werden als Beispiele, nicht als Pflichtumfang behandelt.
• Custom Objects und Objekte aus Managed Packages wurden geprüft.
• Kardinalität und Optionalität jeder Beziehung sind dokumentiert.
• Junction Objects besitzen eine Allokations- oder Ziel-Zählebenen-Regel.
• Verhalten bei Duplikaten und verwaisten Datensätzen ist definiert.
• Business Keys und Salesforce-Identifier sind dokumentiert.

Felder und Datenrisiko

• Für jedes eingeschlossene Objekt existiert eine Feld-Freigabeliste.
• personenbezogene Daten und sensible Attribute sind klassifiziert.
• Freitext, Notizen, Aktivitäten und Dateien wurden separat freigegeben.
• Binäre Inhalte sind ausgeschlossen, solange der Anwendungsfall sie nicht benötigt.
• Zugriff, Maskierung, Retention und Permitted Use sind dokumentiert.

Zeit und Lifecycle

• Aktualität wird aus dem Entscheidungsbedarf abgeleitet.
• Soft-Deletion- und Merge-Verhalten sind definiert.
• Benötigte History-Felder und Retention wurden in der Organisation geprüft.
• Snapshot-Frequenz und Retention sind bei Bedarf festgelegt.
• Jedes zurückgestellte oder ausgeschlossene Objekt besitzt einen Review-Auslöser.

Betrieb

• Ein fachlich verantwortliche Person bestätigt die analytische Bedeutung.
• Ein technischer Betreiber validiert Schlüssel, Felder und Extrahierbarkeit.
• Erwartetes Volumen und Änderungsrate sind verstanden.
• Abgleichkontrollen sind definiert.
• Offene Fragen besitzen verantwortlicher Person und Termin.

Artefakt

Erstelle je Analytics-Produkt oder kompatibler Produktgruppe ein governtes Salesforce Quellumfang-Artefakt. Es ist kein rohes Objektinventar, sondern der freigegebene Vertrag zwischen Business-Anforderung und späterem Ingestion Design.

Pflichtfelder

Beispielhafte Entscheidungszeilen

Erforderliche Outputs

Das freigegebene Artefakt erzeugt:

• eine Liste freigegebener Extraktionsobjekte;
• eine Feld-Freigabeliste;
• eine explizite Ausschluss-Liste;
• Beziehungs- und Zählebene-Regeln;
• Anforderungen an Historie, Löschung und Snapshots;
• personenbezogene Daten- und Freitext-Kontrollregeln;
• offene Fragen mit Ownern;
• die Übergabe an Ingestion- und Incremental-Load-Design.

„Nicht geladen“ ist eine dokumentierte Entscheidung. Es ist weder ein zufälliges Versäumnis noch zwangsläufig dauerhaft. Der Review-Auslöser hält den Scope anpassbar, ohne die erste Lieferung in eine unkontrollierte Datenkopie zu verwandeln.

Abzulehnende Anti-Patterns

Tools

• Source Umfang Builder — Objekte, Felder, Beziehungen, Entscheidungen, Begründungen und Review-Auslöser dokumentieren.
• Supplier Landscape: Salesforce — Salesforce in die breitere Source- und Plattformlandschaft einordnen, ohne den Supplier-Katalog zur Architektur zu machen.
• personenbezogene Daten and Auskunfts- und Löschrechte Readiness Checker — Umfang personenbezogener Daten, Zugriff, Retention und Anforderungen aus Betroffenenrechten prüfen, bevor Freitext oder Identitätsattribute geladen werden.

Ressourcen

Die konfigurierte Salesforce-Organisation bleibt die fachliche und technische Source of Truth. Objektverfügbarkeit, Felder, Beziehungen und Berechtigungen müssen gegen die aktuelle Salesforce-Dokumentation geprüft werden.

• Salesforce Object Reference: Standard Objects
• OpportunityLineItem Object Reference
• PricebookEntry Object Reference
• Salesforce Files Data Model
• QueryAll REST Resource
• Field Audit Trail Implementation Guide

Ein SaaS-Export (CRM, Support, Billing) ist für Betrieb und Backup gebaut — kein freigegebenes Analytics-Modell für Warehouse und BI.

Das Team lädt den vollständigen Salesforce-Export „für später“. Neben Opportunity landen Notes, Attachments und Audit-Logs; PII und Kosten explodieren, bevor die Pipeline-Frage definiert ist.

Der Quellumfang muss vor dem Connector feststehen: Braucht eine benannte Entscheidung diese Tabelle — mit beherrschbarer Bedeutung, Autorität, Granularität und Risiko?

Herausforderung

Herstellerexporte stellen mehr Strukturen bereit, als Analytics normalerweise benötigt, weil die Anwendung Workflows, Berechtigungen, Automatisierung, Integrationen, Wiederherstellung, Benutzeroberflächen und operative Diagnose unterstützen muss. Diese Implementierungsanforderungen erzeugen Tabellen, die technisch verfügbar sind, aber nicht automatisch nutzbare Geschäftsdaten darstellen.

Ein praxistaugliches Inventar enthält meist sieben Kategorien:

1. Geschäftsdatensätze wie Accounts, Abonnements, Fälle, Aufträge oder Projekte.
2. Beziehungstabellen, die Geschäftsobjekte, Benutzer, Produkte, Gebiete oder Berechtigungen verbinden.
3. Referenz- und Konfigurationsdaten wie Statuscodes, Kategorien, Routing-Regeln oder Feature-Einstellungen.
4. Historien und Snapshots, die beabsichtigte Geschäftshistorie, technische Änderungsverfolgung oder wiederholte Kopien desselben aktuellen Zustands darstellen können.
5. Audit- und System-Logs, die für Nachvollziehbarkeit, Fehleranalyse, Sicherheit oder Plattformbetrieb erzeugt werden.
6. UI-Caches und temporäre Strukturen, die die Produktleistung verbessern, aber keine dauerhafte analytische Bedeutung besitzen.
7. Freitext, Dateien und Anhänge, deren Inhalt sensibel, schwer klassifizierbar und teuer in der Aufbewahrung sein kann.

Keine dieser Kategorien führt automatisch zu einer einschließen- oder Ausschluss-Entscheidung. Auch eine Geschäftstabelle kann ungeeignet sein, wenn Autorität oder Granularität unklar sind. Eine Historientabelle kann unverzichtbar sein, wenn sie wirtschaftlich relevante Statuswechsel aufzeichnet. Ein Audit-Log kann ein separates Security-Produkt rechtfertigen. Metadaten zu Anhängen können sinnvoll sein, obwohl der Dateiinhalt außerhalb der analytischen Plattform bleibt.

Das zentrale Risiko ist ein unbeabsichtigter Scope. Das Laden aller verfügbaren Tabellen erzeugt mehrere Fehlermuster:

• doppelte Repräsentationen desselben Geschäftsereignisses führen zu Doppelzählungen;
• technische Zeitstempel werden mit beabsichtigter Geschäftshistorie verwechselt;
• Current-State- und Snapshot-Tabellen werden ohne Autoritätsregel verbunden;
• operative Ereignisse werden mit Business Facts auf inkompatiblen Zählebenen vermischt;
• Freitext und Anhänge vergrößern die Grenzen für personenbezogene Daten, Aufbewahrung und Zugriff;
• ungenutzte Tabellen erhöhen Extraktionsvolumen, Modellkomplexität, Testaufwand und Störungsfläche.

Speicher kann im Vergleich zu Governance, Interpretation und Lifecycle günstig sein. „Alles laden, weil Speicher billig ist“ ist daher keine neutrale Entscheidung. Ungeklärte Quellfragen werden lediglich in jedes nachgelagerte Modell verschoben.

Ansatz

Wende auf jede Exporttabelle denselben gestuften Entscheidungstest an — unabhängig vom Hersteller.

1. Benötigt eine definierte Entscheidung die Tabelle?

Benenne den Report, KPI, die Kontrolle, den Workflow oder das Data Product, das die Tabelle konsumiert. Eine allgemeine Aussage wie „Vielleicht brauchen wir sie später“ ist kein ausreichender Anwendungsfall.

Wenn keine benannte Entscheidung oder Kontrolle die Daten benötigt, wird die Tabelle aus dem aktuellen Scope ausgeschlossen. Die Entscheidung wird dokumentiert, damit der Ausschluss sichtbar bleibt und nicht als vergessene Arbeit erscheint.

2. Liefert sie eine eindeutige fachliche Bedeutung?

Prüfe, ob die Tabelle ein neues Objekt, eine Beziehung, einen Statuswechsel, eine Klassifikation oder ein Ereignis beiträgt. Denormalisierte Convenience-Exporte, replizierte API-Views und wiederholte Snapshots enthalten häufig dieselbe Bedeutung nur in einer anderen Form.

Wenn mehrere Strukturen dasselbe Konzept repräsentieren, wird genau eine Autorität ausgewählt. Duplikate werden nicht allein deshalb behalten, weil sie verfügbar sind.

3. Ist die autoritative Quelle bekannt?

Dokumentiere, welche Tabelle oder welches Objekt das System of Record für das analytische Konzept ist. Die Autorität muss explizit sein, wenn Current-State-Tabellen, Historien, Integrationskopien und Convenience-Exporte überlappen.

Ist die Autorität ungeklärt, wird die Tabelle zurückgestellt, statt nachgelagerte Teams unabhängig entscheiden zu lassen.

4. Können Zählebene und Schlüssel beschrieben werden?

Beschreibe eine Zeile in fachlichen Begriffen. Identifiziere Business Key, Technical Key, Beziehungsschlüssel und erwartete Eindeutigkeit. Eine Tabelle sollte nicht als Faktenquelle geladen werden, wenn der Ziel-Zählebene nicht formuliert und getestet werden kann.

Ein Event-Log kann beispielsweise eine Zeile pro Systemaktion enthalten, während der analytische Fact eine Zeile pro Auftragsposition besitzt. Beide können valide Produkte sein, sind aber nicht austauschbar.

5. Wird Historie bewusst benötigt?

Ein Zeitstempel macht eine Tabelle noch nicht zu nützlicher Historie. Kläre, welche Änderung aufgezeichnet wird, ob die Sequenz vollständig ist, wie Korrekturen erscheinen und welche Entscheidung den historischen Zustand benötigt.

Sinnvolle Beispiele sind Statushistorien für Funnel-Analysen, Vertragsversionen für Effective-Date-Reporting oder Verantwortung-Historien für Nachvollziehbarkeit. Wiederholte Exporte desselben aktuellen Zustands ohne temporalen Vertrag sind normalerweise doppelte Snapshots und keine governte Historie.

6. Sind PII, Aufbewahrung und Zugriff gerechtfertigt?

Klassifiziere Identifikatoren, Freitext, Notizen, Anhänge und benutzergenerierte Inhalte vor der Übernahme. Definiere zulässige Nutzung, Zugriffsgrenzen, Retention, Löschweitergabe und ob eine inhaltliche Suche tatsächlich erforderlich ist.

Sensible Inhalte ohne freigegebenen Zweck werden ausgeschlossen. Werden nur Metadaten benötigt, können Dateiname, Typ, verantwortlicher Person, Zeitstempel und Klassifikation geladen werden, ohne die Binärdatei zu kopieren.

7. Können Qualität und Kosten kontrolliert werden?

Prüfe, ob Volumen, Aktualität, Vollständigkeit, Eindeutigkeit und referenzielle Integrität messbar sind. Schätze Kosten für Extraktion, Speicherung, Transformation, Indexierung, Security und Support.

Eine technisch extrahierbare Tabelle bleibt außerhalb des Scopes, wenn ihre Qualität nicht validiert werden kann oder ihre Kosten nicht im Verhältnis zur unterstützten Entscheidung stehen.

Das Ergebnis ist eine von vier Entscheidungen:

• einschließen: benötigte Bedeutung, Autorität, Zählebene, Kontrollregeln und Verantwortung sind klar.
• zurückstellen: der Bedarf ist valide, aber Autorität, Zählebene, Verantwortung, Zugriff oder Qualität sind noch ungeklärt.
• Ausschluss: es existiert kein unterstützter Anwendungsfall, der Inhalt ist redundant oder Risiko und Kosten sind nicht gerechtfertigt.
• separates Produkts Produkt: ein operativer, Security- oder Compliance-Use-Case existiert, die Daten dürfen aber nicht mit dem fachlichen Analytics-Produkt vermischt werden.

Checkliste

Nutze diese Checkliste, bevor eine Tabelle für die Extraktion freigegeben wird.

Fachliche Bedeutung

• Welche Geschäftsentscheidung, welcher KPI, welche Kontrolle oder welcher Workflow benötigt die Tabelle?
• Welches neue Objekt, welche Beziehung, welcher Zustand oder welches Ereignis kommt hinzu?
• Ist die Tabelle autoritativ, abgeleitet, repliziert oder lediglich bequem?
• Kann eine Zeile fachlich beschrieben werden?
• Welche Schlüssel sichern Eindeutigkeit und Beziehungen?

Historie

• Ist die Tabelle aktueller Zustand, Event History, Effective-Dated History oder ein wiederholter Snapshot?
• Welche Änderung ist analytisch relevant?
• Sind nachträgliche Korrekturen, Löschungen und Reprocessing verstanden?
• Kann derselbe Datensatz in mehreren Exportstrukturen erscheinen?
• Ist eine Autoritätsregel dokumentiert, die Doppelzählungen verhindert?

Risiko und Lifecycle

• Enthält die Tabelle direkte Identifikatoren, Quasi-Identifikatoren, Secrets, Notizen oder unbeschränkten Freitext?
• Referenziert sie Dateien oder enthält sie binäre Inhalte?
• Ist die Aufbewahrung für Quelle und analytische Kopie definiert?
• Können Quelllöschungen und Legal Holds weitergegeben werden?
• Sind Zugriff, Maskierung und zulässige Nutzung freigegeben?

Betrieb

• Können Vollständigkeit, Eindeutigkeit, Aktualität und Beziehungen getestet werden?
• Steht das erwartete Volumen im Verhältnis zum Anwendungsfall?
• Gibt es eine verantwortliche Person für die fachliche Bedeutung und eine verantwortliche Person für den Betrieb?
• Kann die Tabelle unterstützt werden, wenn der Hersteller das Schema ändert?
• Ist für zurückgestellte oder ausgeschlossene Tabellen ein Review-Auslöser definiert?

Typische Ausschluss-Muster und valide Ausnahmen

UI-Caches und temporäre Strukturen werden normalerweise ausgeschlossen, weil sie Implementierungszustände des Produkts darstellen. Eine Aufnahme ist nur gerechtfertigt, wenn eine benannte Kontrolle davon abhängt und der Herstellervertrag eine stabile Bedeutung zusichert.

Tabellen ungenutzter Features werden normalerweise ausgeschlossen, weil sie leere oder irreführende Strukturen erzeugen. Sie werden neu bewertet, sobald das zugehörige Business Feature aktiviert und ein Consumer benannt ist.

Doppelte denormalisierte Snapshots werden normalerweise ausgeschlossen, weil sie autoritative Daten wiederholen und Doppelzählungen begünstigen. Einer dieser Snapshots wird nur dann aufgenommen, wenn er als freigegebene Autorität für eine bestimmte Zählebene dient und konkurrierende Repräsentationen explizit verworfen werden.

Umfangreiche Audit-Logs werden normalerweise vom Business Analytics getrennt. Sie gehören in ein governtes Security-, Operations- oder Compliance-Produkt, wenn Eventmodell, Retention, Zugriff und Evidenzanforderung definiert sind.

Unbeschränkte Freitext-Blobs werden normalerweise ausgeschlossen. Ausgewählte Texte werden erst nach Klassifikation, Zweckfreigabe, Retention Design und eingerichteten Qualitätskontrollen aufgenommen.

Dateien und Anhänge werden normalerweise nicht in das Warehouse kopiert. Attachment Metadata kann aufgenommen werden, wenn sie Vollständigkeit, Suchrouting oder Compliance Evidence unterstützt. Der Inhalt selbst wird nur bei einem governte Search-, Legal-, regulatorischen oder analytischen Anwendungsfall kopiert.

Systemkonfigurationsrauschen wird normalerweise ausgeschlossen. Ausgewählte Konfigurationen können aufgenommen werden, wenn sie Geschäftsverhalten, Routing, Schwellenwerte oder Policy Decisions erklären und als versionierte Referenzdaten geführt werden können.

Artefakt

Das freigegebene Ergebnis ist ein governtes Source-Scope-Register mit genau einer Entscheidung pro Tabelle oder Exportobjekt.

Verwende drei explizite Portfolios: Jetzt enthalten, Zurückgestellt und Ausgeschlossen. Ungeprüfte Tabellen dürfen nicht in einem impliziten Backlog verbleiben.

Ein minimaler Entscheidungsdatensatz enthält:

Das Register sollte fünf operative Outputs erzeugen:

1. Field Allowlist — nur freigegebene Felder aus enthaltenen Tabellen.
2. Input für den Source Contract — Zählebene, Schlüssel, Autorität, Aktualität und Change Expectations.
3. Retention Grenze — was in den analytischen Lifecycle gelangt und was außerhalb bleibt.
4. Erwartete Volumenreduktion — Nachweis, dass Scope Control Extraktions- und Betriebskosten reduziert.
5. Offene Fragen — explizite Abhängigkeiten für zurückgestellte Entscheidungen.

Beispiel für ein Entscheidungsregister

Eine ausgelassene Tabelle kann erneut bewertet werden, aber nur durch eine neue Anforderung, einen neuen Control Need oder eine wesentliche Änderung der Quelle. Die Neubewertung erzeugt einen neuen Entscheidungsdatensatz; sie darf die ursprüngliche Ausschlussbegründung nicht stillschweigend umgehen.

Tools

Nutze den Quellumfang Builder, um einschließen-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen auf Tabellenebene mit Autorität, Zählebene, Risiko und Review-Auslösern zu erfassen.

Nutze den Metadata Export Generator, um den freigegebenen Scope in wiederverwendbare Metadaten für Source Contracts, Field Allowlists und die Übergabe an die Implementierung zu überführen.

Die Tools unterstützen den Entscheidungsprozess. Sie ersetzen keine Freigaben durch fachlich verantwortliche Person, Steward, Architecture, Privacy oder Security, wenn diese Rollen erforderlich sind.

Ressourcen

• Salesforce-Tabellen für Analytics — Teil 1 dieser Serie mit Fokus auf beziehungszentrierte Umfang-Entscheidungen für eine konkrete SaaS-Quelle.
• Exportinventar des Herstellers oder Connectors.
• Data-Classification- und Retention-Richtlinie.
• Bestehendes Report-, KPI- und Kontrollregel-Inventar.
• Source Vereinbarung, Schemadokumentation und Änderungshistorie.
• Data-Product-Backlog und Nutzer Map.

Die wichtigste Quellevidenz ist nicht die Gesamtzahl verfügbarer Tabellen. Entscheidend ist die nachvollziehbare Beziehung zwischen einem benannten fachlichen Bedarf und einer autoritativen, testbaren Quellstruktur.

Die erste Quelle einer Analytics-Plattform ist der kleinste Quellausschnitt, der eine benannte Entscheidung Ende-zu-Ende trägt — nicht der Connector, der schon lizenziert ist.

Der Salesforce-Connector ist frei; HubSpot und ERP warten. Sechs Wochen Raw Load später gibt es keine freigegebene Pipeline-Zahl nach Stage und verantwortlicher Person — Verantwortung und Zählebene waren nie gesetzt.

Ergebnis: eine Portfolio-Entscheidung — jetzt starten, vorbereiten oder bewusst zurückstellen.

Herausforderung

Viele Source Roadmaps werden zunächst nach Bequemlichkeit sortiert. Ein Connector ist verfügbar, ein Sponsor sichtbar oder eine große Anwendung wirkt wichtig. Die Ingestion startet, bevor Entscheidung, Autorität, Zählebene und Consumer Outcome feststehen.

Der Convenience-First-Pfad lautet häufig:

Verfügbarer Connector
→ Großer Raw Load
→ Unklarer Consumer
→ Späte Governance-Fragen
→ Rework

Schwache Auswahlkriterien sind:

• der Connector ist bereits lizenziert;
• die Quelle besitzt die meisten Tabellen;
• ein Executive Sponsor fordert Sichtbarkeit;
• der Extraktionsaufwand wirkt niedrig;
• die Quelle erscheint technisch sauber;
• das Team möchte zunächst beweisen, dass Daten bewegt werden können.

Keines dieser Signale zeigt, dass die Quelle ein vertrauenswürdiges Business Outcome erzeugt. Ein technisch erfolgreicher Raw Load kann weiterhin scheitern, wenn Entity Authority ungelöst, Zählebene der Faktentabelle unbekannt, Zugriff nicht freigegeben, History unvollständig oder kein Consumer vorhanden ist.

Reife und Priorität sind unterschiedliche Dimensionen

Eine Quelle kann hohe Priorität besitzen, aber nicht bereit sein. Eine andere kann leicht extrahierbar sein, aber wenig Entscheidungswert liefern. Werden beide Dimensionen in einen Score vermischt, bleibt die richtige Maßnahme unsichtbar:

• Hoher Entscheidungswert, hohe Reife: jetzt starten.
• Hoher Entscheidungswert, niedrige Reife: Verantwortung, Access, Keys oder Quality Nachweis vorbereiten.
• Niedrigerer Entscheidungswert, hohe Reife: nur bei bewusstem wiederverwendbarem Lerneffekt nutzen.
• Niedrigerer Entscheidungswert, niedrige Reife: zurückstellen.

Ansatz

Nutze eine Decision-First-Reihenfolge:

Benannte Entscheidung
→ Candidate Sources
→ Authority- und Zählebene-Check
→ Reife- und Risk-Check
→ Kleinster vollständiger Slice
→ Trusted Outcome

1. Outcome vor der Quelle definieren

Benenne Nutzer, Entscheidung, Handlung, Kennzahl, Population und Zeithorizont. „CRM onboarden“ ist kein Outcome. „Sales Leadership entscheidet jeden Morgen auf Opportunity- und Verantwortungsebene, wo in der offenen Pipeline eingegriffen wird“ ist eines.

Die Formulierung benennt Consumer und veränderte Handlung. Gleichzeitig definiert sie die Acceptance Criteria des vertikalen Ausschnitts.

2. Entscheidungswert bewerten

Bewerte jeden Kandidaten nach:

• benanntem Nutzer und Handlung;
• messbarem Business Impact;
• Urgency oder Kontrollbedarf;
• Wiederverwendung über mehrere Produkte;
• Executive-, Operational- oder Regulatory-Criticality;
• Möglichkeit, das Ergebnis gegen einen bestehenden Prozess abzustimmen.

Hohe Sichtbarkeit ohne definierte Handlung ist kein hoher Entscheidungswert.

3. Quellenreife separat bewerten

Bewerte unabhängig:

• Autorität ist verstanden;
• Zählebene, Keys und Beziehungen sind bekannt;
• fachlich verantwortliche Person und Steward sind verfügbar;
• Access, personenbezogene Daten und Permitted Use sind freigegeben;
• Quality ist messbar;
• History-, Deletion- und Correction-Verhalten ist verstanden;
• Extraction- und Support-Pfad sind tragfähig;
• Abhängigkeiten sind sichtbar und besitzen verantwortliche Person.

Eine Quelle mit niedriger Reife wird nicht dauerhaft abgelehnt. Sie gelangt mit benannten Voraussetzungen in ein Vorbereiten-Portfolio.

4. Kleinsten vollständigen vertikaler Ausschnitt auswählen

Die erste Quelle ist mit Raw Ingestion nicht abgeschlossen. Der Slice verbindet:

Quellumfang
→ Controlled Ingestion
→ abgestimmte Zählebene
→ Data Product
→ Semantic Model
→ Benannte Entscheidung oder Kontrolle

Jede Stufe besitzt eine Acceptance Question:

• Source: Welche Objekte und Felder sind freigegeben?
• Ingestion: Wie werden Changes, Deletions und Failures behandelt?
• Conform: Was ist eine Zeile und welche Autorität gilt?
• Data Product: Welcher Quality Vereinbarung wird erzwungen?
• semantisches Modell: Welche Definitionen und Filter werden wiederverwendet?
• Nutzer: Welche Handlung wird besser, schneller oder sicherer?

Das Anti-Pattern lautet Source → Raw Tables → „Done“. Der erste Slice ist erst erfolgreich, wenn das governte Ergebnis genutzt und reconciled wird.

5. Wiederverwendbaren Lerneffekt maximieren

Die erste Quelle sollte mehr als Technologie testen:

• Verantwortung und Stewardship;
• Vereinbarungen mit dem Quellsystem und Change Management;
• Klassifikation personenbezogener Daten und Zugriffsgenehmigung;
• Qualitätsgrenzen und Verantwortung im Fehlerfall;
• Lineage und Nachweiserfassung;
• Wiederverwendung des semantischen Modells und Akzeptanz bei Nutzern;
• Kostenverantwortung und Betriebssupport.

Wähle Komplexität bewusst. Eine triviale Quelle beweist wenig; eine übergroße Quelle verhindert den Abschluss des Lerneffekts.

6. Starten, Vorbereiten und Zurückstellen dokumentieren

Jeder Kandidat erhält einen Status:

• Starten: genug Nutzen und Quellenreife für einen vollständigen vertikalen Ausschnitt.
• Vorbereiten: wichtige Quelle, aber noch mit klar benannten offenen Voraussetzungen.
• Gezielt lernen: technisch bereite Quelle, die nur für ein begrenztes Lernziel genutzt wird.
• Zurückstellen: zu geringer Nutzen oder zu geringe Quellenreife im aktuellen Horizont.

Kein Kandidat bleibt in einem unerklärten Connector-Backlog.

Checkliste

Entscheidungswert

• Ein benannter Nutzer und eine Handlung existieren.
• Erwarteter fachlicher Nutzen oder Kontrollnutzen ist messbar.
• Dringlichkeit und Zeithorizont sind explizit.
• Wiederverwendung über Produkte ist verstanden.
• Abgleich mit einem bestehenden Prozess ist möglich.

Quellenreife

• Autorität, Zählebene, Keys und Beziehungen sind verstanden.
• Fachlich verantwortliche Person, Steward und technischer Betreiber sind benannt.
• Zugriff, personenbezogene Daten und erlaubte Nutzung sind freigegeben.
• Qualität, Historie, Löschung und Korrektur sind testbar.
• Extraction- und Support-Abhängigkeiten besitzen verantwortliche Person.

Vertikaler Ausschnitt

• Quellen- und Feldgrenze ist explizit.
• Die Datenladung behandelt Fehler und Löschungen.
• Fachliche Zählebene und Qualitätsvereinbarung sind abgestimmt.
• Eine wiederverwendbare Definition für das semantische Modell wird geliefert.
• Ein benannter Nutzer verwendet das Ergebnis und gleicht es fachlich ab.

Portfolio Governance

• Jeder Kandidat ist als Starten, Vorbereiten, Gezielt lernen oder Zurückstellen markiert.
• Voraussetzungen und Review-Auslöser sind dokumentiert.
• Die gewählte Quelle besitzt Erfolgs- und Ausstiegskriterien.
• Lernziele umfassen Betriebsmodell und Technologie.
• Jede Umfangserweiterung benötigt Freigabe.

Artefakt

Erstelle ein Entscheidungsportfolio mit einer Karte oder Zeile je Quelle. Den freigegebenen Ladeumfang dokumentierst du als source-scope.csv / source-scope.md im Quellumfang Builder.

Das Portfolio erzeugt eine gewählte erste Quelle, die Grenze des vertikalen Ausschnitts, benannte Verantwortliche, offene Voraussetzungen, eine Liste zurückgestellter Quellen und messbare Erfolgskriterien.

Tools

Nutze den Quellumfang Builder, um Objekte, Felder, Beziehungen und Risiken ernsthafter Kandidaten zu definieren. Nutze den Metadata Export Generator, um die gewählte Entscheidung in wiederverwendbare Vertragsmetadaten und eine verständliche Umsetzungsübergabe zu überführen.

Ressourcen

• Welche Salesforce-Tabellen für Analytics laden — konkretes Quellumfang-Muster für Salesforce.
• SaaS-Exporte: Tabellen, die man nicht laden sollte — generische Regeln für Ausschluss und separate Produkte.
• Bestehendes Report-, KPI- und Kontrollregel-Inventar.
• Quellenvereinbarungen, Zugriffsrichtlinien und Data-Classification-Regeln.
• Data-Product-Backlog, Nutzerübersicht und Incident-Historie.

Ein HubSpot-Portal ist eine konfigurierte Revenue-, Marketing- und Service-Anwendung und kein universelles Analytics-Modell. Objekte und Properties werden erst dann zu freigegebenen Quellen, wenn sie eine benannte Entscheidung auf einer definierten Zählebene unterstützen.

Das Ziel ist keine generische Tabellenliste, die jedes HubSpot-Portal laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Der Connector listet Contacts, Companies und Deals. Alles wird geladen „für Pipeline-Reporting“. Wochen später fehlen Stage-Semantik und Zählebene der verantwortlichen Person — der Mart ist breit, die Vertriebsentscheidung unbeantwortet.

Ein kataloggetriebener Ansatz startet mit dem Katalog aus CRM-Objekten, Properties und Associations, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Zugriffsgrenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Contacts, Companies, Deals und Tickets
• Products, Line Items und aktivierte Commerce-Objekte
• verantwortliche Person, Teams, Pipelines, Stages und Referenz-Properties
• Aktivitäten wie Calls, Meetings und Communications
• Custom Objects, Custom Properties und Association Labels
• Property History, archivierte Datensätze, Merges und Löschsignale
• Notes, Messages, Files, Attachments und technische Datensätze

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Pipeline-Steuerung nach Deal Stage und verantwortliche Person benötigt Deal-Zählebene, governte Stage-Daten sowie die relevanten verantwortliche Person- und Company-Associations.
• Revenue nach Produkt benötigt Line-Item-Zählebene und eine kontrollierte Beziehung vom Deal zum Line Item sowie bei Bedarf zu einer wiederverwendbaren Product Reference.
• Lifecycle Conversion nach Quelle benötigt ein abgestimmtes Lifecycle-Modell, Event- oder Property-History-Semantik und explizite Contact-Company-Association-Regeln.
• Ticket Resolution nach Team benötigt Ticket-Zählebene, Status- und Datumssemantik, Category-Referenzen und nur die Aktivitäten, die die Kennzahl tatsächlich verwendet.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus HubSpot-Portal bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Kern für den gewählten Anwendungsfall

• Companies oder Contacts, wenn sie den governten Kundenkontext definieren
• Deals für Pipeline- oder Revenue-Entscheidungen
• Tickets für ein definiertes Service-Produkt
• verantwortliche Personen oder Teams, wenn Verantwortlichkeit benötigt wird
• Pipeline-, Stage-, Datums- und Source-Properties der Kennzahl
• Line Items, wenn Revenue explizit auf Positions-Zählebene liegt

bedingt

• Products und Product References
• Campaign- und Attributionsobjekte
• Calls, Meetings und Communication Activities
• Quotes, Orders, Invoices, Subscriptions oder Payments, wenn aktiviert und erforderlich
• ausgewählte Property History
• Custom Objects und Custom Association Labels

Ausschluss ohne konkrete Anforderung

• ungenutzte Feature-Objekte
• All-Property-Exporte
• doppelte Convenience-Repräsentationen
• unbeschränkte Notes, Messages, Files und Attachments
• technische Datensätze ohne benanntes Analytics- oder Kontrollregel-Produkt

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Company ↔ Contact
   \       /
      Deal → Line Item → Product Reference
       |
Ticket oder Activity nur bei Bedarf

Für jede Beziehung werden dokumentiert:

• analytischer Zweck der Association
• Richtung, Kardinalität und Optionalität
• Association Label und konfigurierte Business-Bedeutung
• Auswirkung auf die Ziel-Zählebene
• Verantwortung für doppelte oder mehrdeutige Beziehungen
• aktuell- gegenüber Historical-Bedeutung
• personenbezogene Daten-Klassifikation und Permitted Use

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• eine Many-to-many-Beziehung zwischen Contact und Company wird auf eine willkürliche Company reduziert
• ein Deal wird einmal je zugeordnetem Contact gezählt
• Product Definitions und deal-spezifische Line Items werden als derselbe Zählebene behandelt
• Activities werden durch wiederholte Associations aufgebläht
• Custom Objects des tatsächlichen Prozesses werden ausgelassen

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• aktueller Objektzustand
• Property History für freigegebene Properties
• explizite Lifecycle- oder Business-Events
• plattformseitige Created- und Update-Timestamps
• bewusst erzeugte Snapshots für vollständige Point-in-time-Zustände

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• E-Mail-Adressen, Telefonnummern und Contact-Identifier
• Notes, Messages und Communication Bodies
• freie Beschreibungen und Betreffzeilen
• Files und Attachments
• Verhalten archivierter, zusammengeführter und gelöschter Datensätze

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener Objektumfang
• Property Freigabeliste
• freigegebene Association Map
• explizite Ausschluss-Liste
• History- und Deletion-Vereinbarung
• offene Fragen und Übergabe an Ingestion

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• HubSpot-Dokumentation zu CRM Associations
• HubSpot-Dokumentation zum CRM Object Model
• HubSpot-Leitfaden zu Custom Objects

Die konfigurierte HubSpot-Portal bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.

Eine Dynamics-365-Umgebung ist eine konfigurierte Dataverse-Anwendungslandschaft. Die Verfügbarkeit einer Standardtabelle beweist weder ihre tatsächliche Nutzung noch ihre Autorität oder Eignung für den gewählten analytischen Prozess.

Das Ziel ist keine generische Tabellenliste, die jede Dynamics-365-Umgebung laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Dataverse zeigt Opportunity und Account. Der volle Katalog landet im Lake „für später“. Der erste Sales-Report scheitert an undokumentierten Statuscodes und Verantwortung-Feldern.

Ein kataloggetriebener Ansatz startet mit dem Katalog aus Dataverse-Tabellen und Solutions, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Access Grenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Account-, Contact-, Lead- und Opportunity-Tabellen
• Opportunity Product, Quote, Order, Invoice und weitere Line-Item-Tabellen
• Product-, Price-, Currency-, Date- und Organisationsreferenzen
• Users, Teams, Business Units und Verantwortung-Strukturen
• Activities, ActivityPointer und Activity-Party-Beziehungen
• Custom Tables, Managed Solutions und Application Extensions
• Audit, Annotations, Attachments, Telemetry und Configuration Tables

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Pipeline nach Opportunity und verantwortliche Person benötigt Opportunity-Körnung, konfigurierte Status-Semantik sowie ausgewählten Account-, verantwortliche Person- und Currency-Kontext.
• Revenue nach Produkt benötigt Opportunity-Product-, Quote-Line-, Order-Line- oder Invoice-Line-Zählebene; diese Positionsstrukturen dürfen nicht in einen Header-Fakt gemischt werden.
• Service Analytics benötigt die tatsächlichen Case- oder Service-Application-Tabellen und den konfigurierten Lifecycle, nicht jede installierte Sales-Tabelle.
• Activity Analytics benötigt einen definierten Activity-Subtype, Participant Role, Datums- und Ziel-Zählebene-Regel; das Laden von Activity Parent und Subtype ohne Duplikationsregel bläht Counts auf.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus Dynamics-365-Umgebung bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Erforderlich für den gewählten Prozess

• Account oder Contact, wenn der konfigurierte Prozess sie benötigt
• Lead oder Opportunity
• Opportunity Product bei Positions-Zählebene
• Product-, Price- und Currency-Referenzen
• verantwortliche Person, User, Team und Business Unit für Verantwortlichkeit oder Security Umfang
• erforderliche State-, Status-, Datums- und Organisationssemantik

bedingt

• Quote, Sales Order und Invoice
• Case- oder Service-Tabellen
• Activities und Activity Parties
• ausgewählte Audit- oder Status-Historie
• Campaign- oder Marketing-Tabellen
• Custom Tables und Solution Extensions

Ausschluss oder separates Produkt ohne Bedarf

• ungenutzte Application Module
• doppelte Activity-Repräsentationen
• unbeschränkte Annotations und Attachments
• umfangreiche Audit-Daten ohne Kontrollregel Case
• Platform Telemetry und Configuration Noise
• Convenience Exports mit unklarer Autorität

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Lead
→ Opportunity
→ Quote
→ Sales Order
→ Invoice

Kontext: Account oder Contact; Line Items; Product und Price List; verantwortlicher Person, Team und Business Unit

Für jede Beziehung werden dokumentiert:

• Business Event der Beziehung
• Header- oder Line-Zählebene
• Key, Kardinalität und Optionalität
• Bedeutung von State und Status
• Currency- und Datumssemantik
• Current- gegenüber Historical-Bedeutung
• Verantwortung-, Organisations- und personenbezogene Daten-Klassifikation

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• Header- und Line-Beträge werden doppelt gezählt
• ActivityPointer- und Activity-Subtype-Zeilen werden als separate Aktivitäten gezählt
• inaktive Datensätze werden entfernt, obwohl die Entscheidung sie benötigt
• Choice Labels gehen verloren und nur numerische Werte bleiben
• Custom Process Tables werden ausgelassen, weil Standardnamen vertraut wirken

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• aktueller Datensatzstatus
• konfigurierte State- und Status-Transitions
• ausgewählte Audit-Historie
• Event-Fakten aus expliziten Prozessmeilensteinen
• Plattform-Snapshots für Point-in-time Reporting

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• personenbezogene Daten in Account-, Contact- und Activity-Feldern
• Descriptions, Annotations und E-Mail-Inhalte
• Attachments und binäre Inhalte
• User-, Team- und Organisationsgrenzen
• Deaktivierungs-, Merge- und Löschverhalten

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener Tabellen- und Spaltenumfang
• Beziehung Map
• Choice- und Status-Mapping-Vereinbarung
• explizite Ausschluss-Liste
• Abgleich Requirements
• Übergabe an die Ingestion

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• Microsoft-Dokumentation zu Dataverse-Tabellen
• Microsoft-Dokumentation zu Dataverse Activities
• Dataverse Auditing verwalten

Die konfigurierte Dynamics-365-Umgebung bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.

Dataverse Sales ist nicht Business Central. Der Plattformwechsel Navision On-Prem → BC SaaS liegt in ERP On-Prem nach SaaS.

Der physische S/4-Tabellenkatalog ist Implementierungsevidenz und kein analytischer Vertrag. Der governte Scope folgt Geschäftsprozess, Document Flow, Ziel-Zählebene und einer für Deployment und Release geeigneten unterstützten Quelle.

Das Ziel ist keine generische Tabellenliste, die jede SAP-S/4-Landschaft laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Das Team lädt VBAK/VBAP und dutzende verwandte Tabellen „für Umsatz“. Ohne CDS-Vertrag und Statussemantik weicht Nettoumsatz vom Finance-Ledger ab.

Ein kataloggetriebener Ansatz startet mit dem Katalog aus physischen Tabellen, Geschäftsobjekts und Extraktionsquellen, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Access Grenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Sales-, Delivery-, Billing-, Purchasing-, Goods-Movement- und Accounting-Dokumente
• Header-, Item-, Schedule-Line-, Journal-Line- und Snapshot-Strukturen
• Business Partner, Material oder Product sowie organisatorische Stammdaten
• Status, Document Flow, Pricing und ausgewähltes Customizing
• Company Code, Sales Organization, Plant, Ledger und Fiscal References
• released CDS Views, APIs, Extractors und weitere unterstützte semantische Quellen
• Technical Logs, obsolete Views, temporäre Datensätze, Text und Attachments

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Order-to-Cash benötigt einen expliziten Document Flow von Sales Order über Delivery und Billing bis zur Accounting-Auswirkung.
• Procure-to-Pay benötigt Purchase-Order-, Receipt- und Invoice-Events auf deklariertem Header- oder Item-Zählebene statt eines breiten Purchasing-Tabellensatzes.
• Inventory Analytics benötigt Movement-, Quantity-, Unit-, Plant-, Storage- und Posting-Period-Semantik; ein aktueller Stock Snapshot ist nicht mit Movement History austauschbar.
• Record-to-Report benötigt Journal-Entry-Körnung, Ledger- und Currency-Kontext, Posting- und Reversal-Semantik sowie kontrollierten Organisations-Umfang.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus SAP-S/4-Landschaft bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Transaktionale Fakten

• Sales-, Delivery- und Billing-Dokumente
• Purchase-, Goods-Movement- und Invoice-Dokumente
• Accounting Journal Entries
• Inventory- oder Production-Events

Stamm- und Organisationskontext

• Business Partner-, Customer- oder Supplier-Kontext
• Product oder Material
• Company Code, Sales Organization, Plant oder Cost Center
• Currency, Unit und Fiscal Calendar

Bedingte Prozessnachweise

• Document Flow und Status
• Schedule Lines
• Change- oder Event-Historie
• Pricing Conditions
• ausgewähltes Customizing zur Prozessinterpretation

Normalerweise ausschließen, ersetzen oder als separates Produkt führen

• nicht unterstützte Raw-Table-Copies
• doppelte Extraktionsstrukturen
• obsolete oder deprecated Views
• Technical Logs und temporäre Datensätze
• breite Customizing-Dumps ohne Anwendungsfall
• Attachments und unbeschränkter Text

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Sales Order
→ Delivery
→ Billing Document
→ Accounting Entry

Kontext: Business Partner; Product oder Material; Sales Organization; Company Code; Plant; Currency; Fiscal Period

Für jede Beziehung werden dokumentiert:

• Business Event und Document-Flow-Transition
• Header-, Item- oder Accounting-Line-Zählebene
• Key, Reference und Kardinalität
• Quantity-, Amount-, Currency- und Unit-Semantik
• Status-, Cancellation- und Reversal-Verhalten
• Posting-, Document- und Effective Date
• analytischer Ziel-Zählebene und Abgleich Rule

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• Order- und Billing-Beträge werden als derselbe Fakt gezählt
• Header-Werte werden über Items wiederholt
• stornierte oder reversierte Dokumente bleiben in Kennzahlen aktiv
• Local und Group Currency werden vermischt
• Late Postings werden der falschen Fiscal Period zugeordnet

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• Document und Posting Dates
• Effective und Fiscal Periods
• Delta- und Deletion-Verhalten
• Archiving- und Late-Posting-Regeln
• Cancellation, Reversal und Corrected Restatement

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• personenbezogene Business-Partner- und Employee-Daten
• kommerziell sensible Preise und Margen
• Organisations- und Company-Code-Grenzen
• unbeschränkter Text und Attachments
• nicht unterstützte oder deprecated Extraktionsquellen

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener semantischer Extraktions-Umfang
• Field Freigabeliste
• Source- und Delta-Vereinbarung
• Raw-Table-Ausschluss- oder Replacement-Liste
• Abgleichkontrollen
• Release-Change-Review-Plan

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• SAP: Data Extraction for Analytics
• SAP: CDS Views Enabled for Data Extraction
• SAP-S/4HANA-Cloud-Dokumentation zur Datenextraktion

Die konfigurierte SAP-S/4-Landschaft bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.

Workday muss über eine benannte Workforce-, Finance- oder Control-Entscheidung und die relevanten effective-dated Business Beziehungen gescopt werden. Ein Custom Report oder Integration Output ist eine Implementierung und nicht die Business-Definition.

Das Ziel ist keine generische Tabellenliste, die jede Workday-Tenant laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

HR will Headcount nach Organisation. Der breite Workday-Export landet inklusive Journal und Attachments. Effective-dated Beziehungen bleiben ungeklärt — der Report zählt doppelte Worker.

Ein kataloggetriebener Ansatz startet mit dem Inventar aus Geschäftsobjekts, Reports und Integration Outputs, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Access Grenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Worker- und Contingent-Worker-Kontext
• Position, Job Profile, Manager und Supervisory Organization
• Company, Cost Center, Location und organisatorische Hierarchie
• Staffing-, Recruiting-, Compensation-, Time- und Absence-Events
• Custom Reports, Calculated Fields und RaaS Outputs
• Current-, Trended-, Effective-Dated- und Snapshot-Strukturen
• Payroll, Benefits, Health, Documents, Notes und weitere eingeschränkte Inhalte

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Active Workforce nach Organisation benötigt Worker-Position-Organization-Beziehungen für ein explizites Effective Date.
• Open Positions und Hiring Demand benötigen Position- und Recruiting-Umfang, nicht das vollständige Worker Profile.
• Compensation Analysis benötigt separate Zweckfreigabe, Grundgesamtheit, Period, Security und Aggregation Kontrollregeln.
• Absence- oder Time-Analytics benötigt Event- oder Period-Zählebene und eine klare Trennung zwischen freigegebenen Ergebnissen, geplanten Events und sensiblen Details.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus Workday-Tenant bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Kernkontext der Workforce

• Worker oder Contingent Worker
• Position und Job Profile
• Supervisory Organization
• Company, Cost Center und Location
• Manager und organisatorische Hierarchie

Bedingte Fakten und Ereignisse

• Staffing Events
• Recruiting- und Candidate-Daten
• Compensation und Payroll
• Time, Absence und Leave
• Lerneffekt-, Performance- oder Talent-Daten

Kontrollierte abgeleitete Quellen

• Custom Reports
• Calculated Fields
• Integration Outputs
• freigegebene Snapshots

Normalerweise ausschließen oder einschränken

• unbeschränkte Worker-Profile-Felder
• Health-, Benefits- oder Document Content ohne benannten Zweck
• Notes, Attachments und Case Text
• doppelte Reports mit widersprüchlichen Berechnungen
• Technical Integration Metadata

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Worker
→ Position
→ Job Profile
→ Supervisory Organization
→ Company / Cost Center / Location

Events: Hire; Transfer; Organization Change; Compensation Change; Leave; Return; Termination; Rescind

Für jede Beziehung werden dokumentiert:

• Effective Starten und End
• Current-, Historical- oder Future-Dated-State
• Primary gegenüber Additional Job
• Worker Type und Contingent-Worker-Behandlung
• Correction- und Rescind-Verhalten
• Business Key und Reference ID
• Security Classification und erlaubte Grundgesamtheit

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• die aktuelle Organisation wird auf historische Fakten angewendet
• mehrere Positionen werden in einen Current Record kollabiert
• Future-Dated Changes werden zu früh sichtbar
• rescinded Events bleiben gültig
• die Manager-Hierarchie wird ohne Effective Dates rekonstruiert

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• Effective Date und Entry Date
• Current-, Historical- und Future-Dated-State
• Corrections und Rescinds
• Event History gegenüber Effective-Dated Snapshot
• periodengranulare Payroll-, Compensation-, Time- oder Absence-Facts

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• direkte Identifier und Worker-Profile-Daten
• Compensation-, Payroll- und Financial Detail
• Health-, Benefits- und Leave-Informationen
• Documents, Notes, Attachments und Case Text
• Security-Domain- und Grundgesamtheit-Restriktionen

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener Objekt- und Feld-Umfang
• Security-Domain-Mapping
• Effective-Date-Vereinbarung
• Grenze für eingeschränkte Daten
• Duplicate-Report-Retirement-Liste
• Abgleich- und Access-Review-Kontrollregeln

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• Workday: Building Custom Reports
• Workday: Configurable Security Overview
• Workday: Reporting with HCM Data

Die konfigurierte Workday-Tenant bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.

Eine ServiceNow-Tabellenhierarchie ist ein operatives Anwendungsmodell. Parent- und Child-Klassen, Referenzen, SLAs, Journals, Audit Records und CMDB-Beziehungen müssen erst in eine explizite analytische Zählebene und einen freigegebenen Quellumfang übersetzt werden.

Das Ziel ist keine generische Tabellenliste, die jede ServiceNow-Instanz laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Ein kataloggetriebener Ansatz startet mit dem Inventar aus Tabellenhierarchie, Referenzen und Operational Events, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Access Grenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Task Parent sowie Incident-, Problem-, Change-, Request- und weitere Child Classes
• Requests, Catalog und Workflow Records
• Task SLA und weitere Operational Events
• Users, Groups, Assignments und Reference Records
• technische Geräteliste-CI-Classes, Services und Beziehungen
• Audit, State History, Journals und Snapshots
• Attachments, Configuration, System und Technical Tables

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Incident Backlog nach Service und Assignment Group benötigt Incident- oder governte Task-Class-Körnung, aktuellen Assignment-Kontext und ein separat entworfenes Historical View für Point-in-time Backlog.
• SLA Performance benötigt Task-SLA-Ereignis-Zählebene und Regeln für mehrere SLA Records je Task; sie ist nicht nur eine zusätzliche Incident-Spalte.
• Change Risk benötigt die konfigurierte Change Class, State- und Approval-Semantik sowie ausgewählten CI- oder Service-Kontext, nicht einen vollständigen technische Geräteliste-Dump.
• Service Impact Analysis benötigt eine allowlist-basierte Auswahl von CI Classes und Beziehung Types aus der Service-Frage.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus ServiceNow-Instanz bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Kernfakten des Prozesses

• Incident, Problem oder Change bei Bedarf
• Request oder Request Item
• ausgewählte Task- oder Workflow-Records
• Task SLA für definierte Service-Level-Analyse

Erforderlicher Kontext

• Users, Groups und Assignment
• Services, Offerings oder ausgewählte Configuration Items
• State-, Priority-, Category- und Calendar-References
• freigegebene Custom Tables

Bedingte Historie und Kontrollen

• State Transitions
• Audit Nachweis
• Reassignment- oder Approval-Events
• Snapshots für Backlog- oder Point-in-time-Analyse

Normalerweise ausschließen oder als separates Produkt führen

• doppelte Parent- und Child-Repräsentationen
• unbeschränkte Journals und Work Notes
• Attachments und Binary Content
• breite technische Geräteliste- oder System-Table-Dumps
• Technical Logs ohne Operational Product

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Task
├─ Incident
├─ Problem
├─ Change
└─ Request oder andere Child Class

Bedingte Fakten: Task SLA, Assignment Group und User, CI oder Business Service, Statuswechsel oder Snapshot

Für jede Beziehung werden dokumentiert:

• Class- und sys_class_name-Bedeutung
• Parent- gegenüber Child-Repräsentation
• Business Event und Ziel-Zählebene
• Reference Key und Display Value
• One-to-many-Effekt
• Current- gegenüber Historical-Bedeutung
• Domain-, Role- und personenbezogene Daten-Klassifikation

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• Parent- und Child-Zeilen werden doppelt gezählt
• mehrere SLA Records werden als ein Task behandelt
• aktueller CI- oder Assignment-Kontext wird auf historische Events angewendet
• Journal Updates werden als Task Events gezählt
• technische Geräteliste Beziehung Traversal lässt den Fact Count explodieren

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• aktueller Task State
• State-Transition-History
• SLA Events und Breach Timing
• validierte Audit Nachweis
• bewusst erzeugte Snapshots für Backlog oder Point-in-time State

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• Descriptions, Comments, Work Notes und Journals
• Attachments und Binary Content
• User- und Group-Daten
• Domain- und Role-Access-Boundaries
• Retention-, Archive- und Deletion-Verhalten

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener Tabellen- und Class-Umfang
• Inheritance- und Reference-Map
• Parent-Child-Duplication-Kontrollregeln
• Field Freigabeliste und Text Grenze
• technische Geräteliste Class Freigabeliste
• History- und SLA-Event-Vereinbarung
• Übergabe an die Ingestion

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• ServiceNow-Dokumentation zu Table Extension und Classes
• ServiceNow-Dokumentation zu Tables and Data Models
• ServiceNow-Dokumentation zu technische Geräteliste Class Definitions

Die konfigurierte ServiceNow-Instanz bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.

Multi-Source Authority legt fest, welches System für welches Attribut einer Entity (Customer, Account, Product) gilt — nicht „ein Master für alles“.

CRM und ERP zeigen denselben Kundennamen mit unterschiedlicher Rechnungsadresse. Der Sales-Mart mischt beide; Nettoumsatz nach Region driftet, weil niemand Attribute-Authority dokumentiert hat.

Authority wird auf Entity Identity, Attributgruppe, Business Event, Gültigkeitszeitraum und analytischen Zweck vergeben.

Herausforderung

Zwei Records mit demselben Namen stellen nicht automatisch dieselbe Entity dar. Zwei Systeme mit demselben Attribut besitzen nicht automatisch dieselbe Autorität. Ein CRM kann die Sales Beziehung besitzen, ein ERP Legal Account und Invoice Balance, eine Service Platform den Support State und eine Consent Platform die Communication Preference.

Breite Aussagen erzeugen versteckte Konflikte:

• „CRM ist der Customer Master“ ignoriert Legal-, Billing-, Service- und Consent-Fakten.
• „Der neueste Timestamp gewinnt“ verwechselt technische Aktualität mit Business Authority.
• „Ein Golden Record“ kann legitime kontextuelle Unterschiede verdecken.
• automatisches Matching kann unterschiedliche Entities zusammenführen.
• Last-write-wins kann einen korrigierten autoritativen Wert durch eine spätere Replik überschreiben.
• Downstream-Teams erfinden unterschiedliche Precedence Rules und publizieren widersprüchliche Kennzahlen.

Authority beantwortet für jeden relevanten Fakt vier Fragen:

1. Welches System erzeugt den Fakt?
2. Welche Rolle oder welches System darf ihn korrigieren?
3. Welcher Zeitkontext gilt?
4. Welche Downstream-Entscheidungen dürfen ihn nutzen?

Vier Source Roles unterscheiden

• System of Entry: wo Nutzer oder Prozess den Wert erstmals erfassen.
• System of Record: wo die Organisation den accountable Operational State pflegt.
• System of Reference: governte Quelle zur Standardisierung oder Anreicherung anderer Systeme.
• Analytical Trusted Source: freigegebene Repräsentation für einen analytischen Kontext.

Diese Rollen können identisch sein, müssen es aber nicht.

Ansatz

1. Entity und Matching Grenze definieren

Beschreibe Business Meaning, enthaltene Populationen und ausgeschlossene Subtypen. Definiere Identity Keys, Crosswalk Keys und Matching Scope, bevor entschieden wird, welche Attribute überleben.

Identity Resolution beantwortet nur, ob Records dieselbe Business Entity repräsentieren. Sie darf nicht stillschweigend festlegen, welcher Wert vertraut wird.

2. Authority nach Attribut, Event und Zeit vergeben

Erstelle eine Authority Matrix für beispielsweise:

• Legal Customer Identity;
• Preferred Contact Details;
• Consent und Communication Preference;
• Sales Verantwortung;
• Active Vereinbarung Status;
• Invoice Balance;
• Service Berechtigung;
• Support-Case State.

Dokumentiere je Zeile Source of Entry, Authoritative Source, Analytical Trusted Source, Effective Date, Aktualität Expectation, Conflict Rule, Fallback und verantwortlicher Person.

Authority hängt außerdem vom Zeitkontext ab:

• Current Operational State;
• Historically Effective State;
• Event State at Transaction Time;
• Corrected Restatement.

„Latest Record Wins“ ist nur valide, wenn es für dieses Attribut und diesen Zeitkontext explizit freigegeben wurde.

3. Match, Survive und Publish trennen

Nutze einen governten Flow:

Source Records
→ Standardize Keys
→ Match und Identity Resolution
→ Confidence- und Exception-Gate
→ Attribute Survivorship
→ Conformed Entity oder Source-Specific Views
→ Downstream Products

Die drei Entscheidungen sind getrennt:

1. Match: Stellen die Records dieselbe Entity dar?
2. Survive: Welcher Wert wird je Attribut und Zeit vertraut?
3. Publish: Erhalten Consumer eine Conformed Entity oder mehrere Contextual Views?

Hohe Match Confidence autorisiert nicht automatisch Survivorship. Eine Conformed Entity ist nur sinnvoll, wenn gemeinsame Identität und Attributregeln stabil sind. Source-Specific Views bleiben erhalten, wenn Bedeutungen legitim abweichen oder Conflict Resolution kontextabhängig bleibt.

4. Conflict-, Fallback- und Correction-Regeln definieren

Für jedes governte Attribut oder Event werden festgelegt:

• Precedence zwischen Quellen;
• wann ein Fallback erlaubt ist;
• maximal tolerierte Latency;
• Behandlung von Null, Stale und Invalid Values;
• Propagation von Corrections und Restatements;
• Aufbewahrung ungelöster Konflikte;
• verantwortliche Person für Exceptions.

Verlierende Werte werden nicht gelöscht. Provenance bleibt erhalten, damit die Entscheidung erklärbar und reversibel ist.

5. Identity Exceptions governen

Pflicht-Controls sind:

• Source-to-Conformed Crosswalk Keys;
• Match Confidence und Reason Codes;
• Manual-Review Threshold;
• Merge- und Split-History;
• Unresolved-Duplicate Queue;
• False-Positive Remediation;
• Downstream Impact Analysis vor Identity Changes;
• SLA und Escalation verantwortliche Person für Steward Review.

Mehrdeutige Matches bleiben ungelöst, statt erzwungen in eine Entity überführt zu werden.

6. Provenance und Effective Dating erhalten

Jeder publizierte Wert enthält genügend Evidenz für:

• beitragende Quelle und Source Key;
• Source Extraction und Event Time;
• Authority-Rule-Version;
• Effective Starten und End;
• Conflict- oder Fallback-Status;
• Correction- und Review-History.

Ohne Provenance wird Survivorship zu einem irreversiblen Überschreiben.

7. Downstream Migration kontrollieren

Eine Änderung der Authority Rule kann Identifier, Dimensions, Filter und historische Kennzahlen verändern. Behandle sie als Consumer-Contract-Migration. Identifiziere betroffene Data Products, vergleiche alte und neue Ergebnisse, kommuniziere das Effective Date und erhalte die vorherige Regel lange genug für Reconciliation.

Checkliste

Entity und Identity

• Die Entity besitzt Business Definition und explizite Grundgesamtheit.
• Identity Keys und Matching Umfang sind freigegeben.
• Crosswalk Keys erhalten jede Source Identity.
• Match Confidence und Review Thresholds sind definiert.
• Merge-, Split- und Unresolved-Duplicate-Verhalten ist dokumentiert.

Authority und Survivorship

• Authority ist je Attribut oder Event vergeben.
• Current-, Historical-, Transaction-Time- und Restated-Kontexte sind getrennt.
• Precedence-, Fallback- und Latency-Regeln sind explizit.
• Null-, Stale-, Invalid- und Conflict-Values besitzen Regeln.
• fachlich verantwortliche Person und Steward genehmigen die Matrix.

Publishing und Lineage

• Die Wahl zwischen Conformed Entity und Contextual Views ist explizit.
• Provenance bleibt je publiziertem Wert erhalten.
• Authority-Rule-Versionen und Effective Dates sind abfragbar.
• Corrections propagieren in betroffene Produkte.
• Nutzer Migration und Abgleich sind geplant.

Exceptions

• Eine Exception Queue existiert.
• Steward SLA und Escalation verantwortliche Person sind benannt.
• Temporäre Fallbacks besitzen Expiry und Nachweis.
• False-Positive Merges sind reversibel.
• Review-Auslöser decken Source-, Richtlinie- und Prozessänderungen ab.

Artefakt

Erstelle einen governten Authority Record mit vier verknüpften Bereichen.

Entity Definition

• Entity Name und Business Meaning;
• Identity Keys und Matching Umfang;
• einschließend Populations;
• Excluded oder separates Produkt Entity Types.

Authority Matrix

Exception Rules

Dokumentiere Match-Confidence Threshold, Conflict Type, Steward Queue, Review SLA, Escalation verantwortlicher Person und jeden temporären Fallback mit Expiry.

Downstream Contract

Dokumentiere Conformed Key, Provenance Fields, Aktualität- und Quality Controls, betroffene Products, Change Plan und Review-Auslöser.

Erforderliche Outputs sind freigegebene Authority Matrix, Crosswalk- und Match Policy, Survivorship Rules, Exception Queue, Lineage Requirement und Consumer-Migration-Actions. Matching- oder Formula-Tools können die Entscheidung implementieren, aber keine Business Authority vergeben.

Tools

Nutze den Quellumfang Builder, um den Beitrag jeder Quelle und konkurrierende Repräsentationen zu dokumentieren. Nutze den Metadata Export Generator, um Authority, Precedence, Provenance und Review Metadata in wiederverwendbare Contracts zu publizieren.

Ressourcen

• Data Dictionaries und Source Vereinbarungen der Quellsysteme.
• Identity Crosswalk und Duplicate-Management Records.
• Data-Verantwortung- und Stewardship-Decision-Rights-Modell.
• Nutzer Inventory und Lineage Graph.
• Correction-, Merge-, Split- und Incident History.

Nicht dieser Fall: On-Prem und SaaS derselben ERP-Linie (Navision → Business Central) — ERP On-Prem nach SaaS. CRM gegen ERP bleibt diese Story.