Von Quelle zum Mart

Einstieg

Der Salesforce-Quellumfang ist freigegeben: Die zulässigen Objekte, Felder und Beziehungen stehen fest. Trotzdem ist damit noch nicht geklärt, was eine Zeile im späteren Pipeline-Mart bedeutet. Genau diese Entscheidung muss vor dem ersten Dashboard fallen.

Ein Beispiel zeigt das Problem. Eine Opportunity kann drei Produktpositionen enthalten. Werden Opportunity und Positionen in dieselbe Faktentabelle geschrieben, erscheint der Opportunity-Betrag leicht dreimal. Wird dagegen nur die Opportunity betrachtet, lässt sich der Umsatz nicht verlässlich nach Produkt auswerten. Beides ist sinnvoll, aber nicht in derselben Zählebene: Für die Pipeline braucht es eine Zeile pro Opportunity; für die Produktauswertung eine eigene Tabelle mit einer Zeile pro Position.

Dieses Kapitel führt deshalb vom freigegebenen Quellumfang zu einem prüfbaren Mart-Steckbrief: Geschäftsereignis festlegen, Bedeutung einer Zeile beschreiben, Fakten und beschreibende Merkmale trennen und Kennzahlen auf genau dieser Grundlage definieren. Die weiteren Serienteile wenden denselben Gedanken auf HubSpot, SAP S/4, Workday und Dynamics 365 an.

Begriffe vor dem Lesen

• Quellumfang — die freigegebenen Objekte, Felder und Beziehungen. Er legt fest, was geladen werden darf, aber noch nicht, wie die Auswertung aufgebaut wird.
• Zählebene — die fachliche Bedeutung einer Zeile, etwa „eine Zeile pro Opportunity“ oder „eine Zeile pro Produktposition“.
• Faktentabelle — eine Tabelle mit messbaren Geschäftsereignissen und Werten, beispielsweise Betrag oder Menge.
• Dimension — beschreibender Kontext zu einem Fakt, beispielsweise Kunde, Produkt, Vertriebsphase oder Datum.
• Snapshot — ein gespeicherter Zustand zu einem bestimmten Berichtszeitpunkt. Er macht historische Verläufe nachvollziehbar, ohne sie aus dem heutigen Zustand zurückzurechnen.
• KPI-Karte — die dokumentierte Definition einer Kennzahl mit Berechnung, betrachteter Datenmenge, Zeitlogik, Ausschlüssen und fachlich verantwortlicher Person.

Die Beispiele sind Lehrfälle und enthalten keine Kundendaten. Objekt- und Feldnamen orientieren sich an Salesforce, müssen aber gegen die Konfiguration des eigenen Unternehmens geprüft werden.

Produkte und Entscheidungen

Der Salesforce-Mart braucht nicht „eine CRM-Kopie“, sondern geschnittene Produkte.

Vereinbarung zur Zählebene

Dieses Produkt beschreibt:

• Geschäftsereignis; primäre Zählebene (Opportunity) oder alternative Zählebene (Position); explizites Verbot, beide in einer Fact zu mischen.

Entscheidungen:

• Reicht Opportunity-Körnung für Stage-, verantwortliche Person- und Forecast-Fragen ohne Produktkomplexität?; Wann wechselt ihr auf OpportunityLineItem — Revenue nach Produkt oder Menge?; Entsteht dann eine zweite Fact statt einer Spalten-Erweiterung?

Fakten- und Dimensionskandidaten

Entscheidungen:

• Welche Fakten sind additiv (Amount, Quantity, Expected Revenue)?; Welche Attribute sind Status (Probability, StageName)?; Braucht Verlauf durch die Vertriebsphasen einen eigenen Snapshot-Fact?

KPI-Karten auf der Zählebene

Auf Opportunity-Zählebene verlässlich:

• Pipeline Value — Summe Amount offener Opportunities je Stage, Owner und Periode.
• Win Rate — Anteil gewonnener an abgeschlossenen Opportunities im Zeitraum.
• Average Deal Size — durchschnittlicher Amount gewonnener Opportunities.
• Sales Cycle Length — Tage zwischen CreatedDate und CloseDate bei gewonnenen Opportunities.
• Stage Conversion Rate — Anteil, der von einer Stage zur nächsten übergeht.

Entscheidungen:

• Welche Karten gehören in v1 — nicht alle fünf auf einmal bei KMU?; Wer ist KPI-verantwortliche Person?; Welche Formel ohne Angabe der Zählebene gilt als Folklore?

Mart-Steckbrief plus Scope-Artefakte

Drei Dateien, eine Zählebene:

• source-scope.csv / source-scope.md — freigegebene Objekte aus dem vorgelagerten Register.
• kpi-cards.csv — Standard-KPIs mit Formel, Zählebene, Filtern, verantwortliche Person.
• mart-design-brief.md — Event, Zählebene, Fact/Dim, Historie, bewusst ausgeschlossene Inhalte — frei vor Tabellenbau.

Entscheidungen:

• Wer gibt den Brief frei — Sales Ops oder Analytics-Lead?; Welche Contact-/User-Felder bleiben Skip laut Umfang?; Welche Custom Objects und History-Regeln bleiben in Salesforce-Tabellen für Analytics?

Wo Governance hängt

Zwischen Quellumfang und Mart-Zählebene

Geladene Objekte beantworten nicht, was eine Zeile bedeutet.

Zwischen Opportunity und Line Item ohne Allokation

Summen weichen ab, sobald Rabatte, Teilmengen oder Pricebooks greifen. Eine Fact für beide Grains ist Drift.

Zwischen aktuellem StageName und historischer Periode

Current-State rückwärts gelegt täuscht „schon immer gewonnen“ vor. Bewegung braucht Snapshot.

Zwischen Amount-Summe und Forecast-Kategorie

Finance unterscheidet Best Case, Commit und Pipeline. Roh-Summen ohne Kategorie sind keine KPI-Karte.

Zwischen frei eingetragenem Verantwortlichen und User-Referenz

Reorganisationen verfälschen Historie, wenn Owner nicht governte Dimension ist.

Zwischen PII-„später anreichern“ und Quellumfang

Contact- und User-Felder nur mit Allowlist. Freitext, Notizen und Activities bleiben draußen, solange kein Use Case existiert.

Rollen-Mapping

Sales Operations / Mart-Owner

Accountable für Event, Zählebene und Leit-KPIs. Sales Ops ersetzt nicht Finance für Commit-Zahlen und nicht Legal für PII.

Sales Leadership

Consumer von Pipeline und Win Rate. Darf Karten fordern, nicht Zählebene still mischen.

Analytics Engineer / Custodian

Setzt Fact/Dim und Modelle um. Implementierungsmacht ist keine Zählebene-Verantwortung.

Data Architect

Schützt Zählebene-Grenze, Stage-Referenz und Breaking Changes beim Wechsel auf Positions-Zählebene.

Privacy / PII Steward

Hält Skip- und Allowlist-Entscheidungen aus dem Quellumfang. Privacy ersetzt nicht den Mart-Owner für Amount-Logik.

Finance Consumer

Empfängt Karten mit Kategorie und Währung. Finance erfindet keine Parallel-Fact ohne eigenen Brief.

Mini-Fall

Alltagssituation: Der Umfang der Auswertung ist nicht festgelegt. Das Dashboard startet, ohne zu erklären, wofür eine Zeile steht. Verkaufschance und Angebotspositionen landen in einer Tabelle. Der aktuelle Verkaufsstatus überschreibt die Historie. Beträge sind nicht nach Commit und Best Case getrennt. Die verantwortliche Person steht nur als Textfeld im Export.

Was schiefläuft: Das Team baut Tabellen, bevor die fachliche Entscheidung beschrieben ist. Ohne Event-Definition, Tabellen-Brief und KPI-Karten wird aus Salesforce schnell ein Mart, der präzise aussieht, aber falsche Fragen beantwortet.

Vereinbarung: Vor Tabellenbau werden Zeile, Event, Historie, Betragslogik und verantwortliche Person definiert. KPI-Karten beschreiben, welche Entscheidung die Kennzahl unterstützt und welche fachliche Ebene gilt.

Vereinbarung: Event benennen; Opportunity-Körnung für das Pilotprojekt; zweite Fact wenn Produkt-Revenue nötig; Karten mit KPI Definition; Brief mit Mart-Steckbrief-Generator; personenbezogene Daten mit personenbezogene Daten Recommend im Umfang halten.

Kritische Übergaben

Anti-Patterns

• Von Salesforce direkt ins Dashboard springen
• Opportunity und Line Item in einer Fact mischen
• Historie aus aktuellem StageName simulieren
• Amount ohne Währung und Forecast-Kategorie summieren
• verantwortliche Person als Freitext lassen
• personenbezogene Daten „für später“ kopieren
• KPI-Karten vor der Zählebene schreiben
• Brief nach dem Tabellenbau nachreichen

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

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

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

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

Schritt 1: Rahmen und Entscheidung klären

Freigegebenen Quellumfang lesen. Event und gewünschte Zählebene skizzieren. Sales Ops und Architect benennen. Bekannte Dashboard-Konflikte listen.

Schritt 2: Control und Nachweis umsetzen

Vereinbarung zur Zählebene schließen. Fact-/Dim-Tabelle für das Pilotprojekt füllen. Zwei bis drei KPI-Karten auf dieser Zählebene versionieren. Brief-Entwurf.

Schritt 3: Testen und Ausnahmen sichtbar machen

Brief freigeben. Ausschluss personenbezogener Daten gegen Scope prüfen. Negativtest: Line-Item-Spalten dürfen die Opportunity-Fact nicht erweitern. Ein Consumer-Tool anbinden.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Bestandenes Muster nach HubSpot (Teil 2) nur übertragen, wenn Zählebene und Brief gehalten haben.

Exit-Kriterien

• Der Pilotprojekt-Mart hat einen Satz zur Zählebene und vermischt Opportunity nicht mit Position.
• KPI-Karten referenzieren dieselbe Zählebene; Formeln ohne Zählebene sind Folklore.
• Snapshot-Bedarf ist ja oder nein — nicht heimlich aus Current-State gebaut.
• personenbezogene Daten/Skip folgt dem Quellumfang, nicht einer stillen Erweiterung.
• Engineer bleibt technischer Betreiber; Sales Ops bleibt für Event und Leit-KPIs accountable.

Weiterlesen

• Welche Salesforce-Tabellen für Analytics laden
• Vom Stakeholder-Interview zum Tabellenmodell
• Welche Quelle zuerst laden?
• Supplier Library: Salesforce
• Quellumfang Builder
• Governance Advisor

Ein freigegebener HubSpot-Quellumfang legt fest, welche Objekte, Eigenschaften und Beziehungen geladen werden dürfen. Damit ist aber noch kein Mart entstanden. Dieses Kapitel zeigt den nächsten Schritt: einen kleinen Deal-Mart mit einer Zeile pro Verkaufschance, klar benannten Fakten und Dimensionen sowie einer ersten Version der wichtigsten Pipeline-Kennzahlen.

Der Fokus liegt bewusst auf einem kleinen, vollständigen Pilot-Mart statt auf einer Kopie des gesamten HubSpot-Portals. Eine Auswertung, die die Steuerung der Vertriebsphasen zuverlässig unterstützt, schafft mehr Vertrauen als ein breiter, aber unfertiger Export aller Objekte.

Herausforderung

HubSpot-Portale sind konfigurierbar: Pipelines, Stages, Custom Properties und Association Labels unterscheiden sich zwischen Portalen und sogar zwischen Business Units desselben Unternehmens. Ein Mart, der Deal-Objekte ungeprüft übernimmt, erbt typische Probleme.

• Ein Deal kann mit mehreren Companies oder Contacts assoziiert sein; ohne eine explizite Primary-Company-Regel entstehen doppelte oder willkürlich reduzierte Zeilen.
• Property History und der aktuelle Deal-Zustand werden vermischt, sodass eine Analyse des Verlaufs durch die Vertriebsphasen denselben Datensatz mehrfach oder falsch datiert zählt.
• Deal Amount wird ohne Line-Item-Kontext summiert, obwohl Revenue nach Produkt eigentlich Positions-Körnung benötigt.
• Pipeline- und Stage-Bezeichnungen werden als stabile Business-Begriffe behandelt, obwohl sie im Portal jederzeit umbenannt oder neu sortiert werden können.

Der freigegebene Quellumfang aus Welche HubSpot-Tabellen laden — und welche skippen entscheidet, welche Objekte und Properties überhaupt verfügbar sind. Die Entscheidung über Zählebene und Fakten für den Mart bleibt trotzdem ein eigener Schritt.

Ansatz

Freigegebener Quellumfang
→ Geschäftsereignis und gewünschte Zählebene
→ Fakten- und Dimensionskandidaten
→ KPI-Karten auf derselben Zählebene
→ Mart-Steckbrief

Für einen ersten Pilotprojekt-Mart ist Deal-Zählebene der pragmatischste Startpunkt: eine Zeile pro Deal, angereichert um governte Company-, Contact- und Angaben zu verantwortlichen Personen. Diese Zählebene beantwortet die häufigste Einstiegsfrage — wo in der Pipeline muss eingegriffen werden — ohne Produktkomplexität vorwegzunehmen.

Sobald Revenue nach Produkt eine Rolle spielt, wird eine zweite Faktentabelle auf Line-Item-Zählebene ergänzt, statt den Deal-Mart nachträglich zu verbiegen. Für Company-Assoziationen gilt eine feste Regel: Wenn ein Deal mit mehreren Companies verknüpft ist, wird eine Primary-Company-Zuordnung dokumentiert und angewendet — nicht implizit die erste oder zufällig zurückgegebene Assoziation verwendet.

Zählebene und Fakten- und Dimensionskandidaten

Primäre Zählebene: eine Zeile pro Deal.

Alternative Zählebene (Produkt-Mart): eine Zeile pro Deal-Line-Item.

Amount und Quantity sind additive Fakten, solange sie über die vorgesehenen Dimensionen konsistent summierbar bleiben. Stage und Deal Status sind Statusattribute. Eine Analyse des Verlaufs durch die Vertriebsphasen benötigt einen eigenen Snapshot- oder Event-Fact (eine Zeile pro Deal und Stage-Wechsel oder Berichtsdatum) statt einer Ableitung aus dem aktuellen Deal-Zustand.

Personenbezogene und ausgeschlossene Daten

Contact- und Company-Felder werden nur mit freigegebener Property-Allowlist übernommen. Notes, Messages, Calls und Meetings bleiben außerhalb des Pilotprojekt-Marts, solange kein benannter Aktivitäts-Use-Case existiert. Property History wird nur für die tatsächlich benötigten Felder geladen, nicht pauschal für das gesamte Deal-Objekt.

Die vollständige Entscheidung über Objekte, Felder, Associations und Löschverhalten steht in Welche HubSpot-Tabellen laden — und welche skippen. Für die Feldklassifikation eignet sich der PII Recommend Generator.

Standard-KPIs

Auf Deal-Zählebene lassen sich für den Piloten definieren:

• Pipeline Coverage — Verhältnis von offenem Pipeline-Wert zu Zielumsatz je Periode.
• Win Rate — Anteil gewonnener Deals an allen abgeschlossenen Deals im Zeitraum.
• Average Deal Size — Durchschnittlicher Amount gewonnener Deals.
• Sales Cycle Length — Tage zwischen Create Date und Close Date bei gewonnenen Deals.
• Deal Velocity — durchschnittliche Verweildauer je Stage.

Jede Kennzahl benötigt eine eigene KPI-Karte statt nur einer Formel. Nutze KPI definieren für die Methodik und den KPI Definition-Generator zur strukturierten Erfassung.

Artefakt

• source-scope.csv / source-scope.md — freigegebene HubSpot-Objekte, Properties und Associations.
• kpi-cards.csv — die Standard-KPIs mit Formel, Angabe der Zählebene, Filtern und verantwortliche Person.
• mart-design-brief.md — Geschäftsereignis, Zählebene, Fact-/Dimension-Kandidaten, Primary-Company-Regel und bewusst ausgeschlossene Inhalte für den Deal-Mart.

Dieselben Dateinamen werden über alle Guides dieser Serie hinweg verwendet, damit Exporte, Tools und Dokumentation konsistent bleiben.

Tools und nächste Schritte

• Quellumfang Builder — HubSpot-Objekte, Properties und Associations als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Contact- und Company-Properties klassifizieren.
• Mart-Steckbrief-Generator — Zählebene, Fakten, Dimensionen und bewusst ausgeschlossene Inhalte als mart-design-brief.md freigeben.
• KPI Definition — Standard-KPIs als kpi-cards.csv versionieren.

Für die grundsätzliche Priorisierungsfrage — ob HubSpot überhaupt die richtige erste oder nächste Quelle ist — bleibt der Governance Advisor der Einstiegspunkt. Dieser Guide vertieft die Entscheidung, ersetzt sie aber nicht.

Verwandte Playbooks

• Welche HubSpot-Tabellen laden — und welche skippen — die vorgelagerte Load/Skip-Entscheidung für Objekte, Properties und Associations.
• Vom Stakeholder-Interview zum Tabellenmodell — die allgemeine Methodik für Zählebene, Fakten, Dimensionen und den Mart-Steckbrief.
• Welche Quelle zuerst laden? — die Portfolio-Entscheidung, falls HubSpot noch gegen andere Kandidaten priorisiert werden muss.

Das vollständige Supplier-Profil mit Produktkontext, Compliance-Hinweisen und weiteren Ressourcen steht in der Supplier Library: HubSpot.

Eine SAP-S/4-Landschaft deckt Sales, Logistik, Einkauf und Finance ab. Dieser Guide baut bewusst keinen vollständigen ERP-Mart. Er zeigt, wie aus dem freigegebenen Quellumfang ein eng geschnittener Ausschnitt entsteht: Sales Order und Auftragsposition als Fact-Quelle, ergänzt um die Beziehung zum Billing Document, wenn realisierter statt zugesagter Umsatz benötigt wird.

Der schmale Zuschnitt ist kein Kompromiss, sondern die eigentliche Empfehlung. Ein Order-to-Cash-Mart, der Header, Item und Billing sauber trennt, liefert früher belastbare Kennzahlen als ein Versuch, die gesamte Auftragsabwicklung in einem Schritt zu modellieren.

Herausforderung

Der physische S/4-Tabellenkatalog ist Implementierungsevidenz, kein analytisches Modell. Ein objektgetriebener Ansatz führt zu vorhersehbaren Fehlern.

• Header-Werte wie der Gesamtnettowert eines Auftrags werden über Positionen wiederholt und dann versehentlich mehrfach summiert.
• Order- und Billing-Beträge werden als derselbe Fakt behandelt, obwohl ein Auftrag mehrfach oder teilweise fakturiert werden kann — Order Value und Billed Value sind unterschiedliche Wahrheiten zu unterschiedlichen Zeitpunkten.
• Organisationsstrukturen wie Sales Organization, Distribution Channel oder Company Code werden nicht konsistent auf Kopf- und Positionsebene geführt.
• Released CDS Views, native Tabellen und Custom Extraktoren liefern konkurrierende Repräsentationen desselben Geschäftsvorfalls, ohne dass eine Autorität dokumentiert ist.

Der freigegebene Quellumfang aus Welche SAP-S/4-Tabellen für Analytics laden — und welche skippen entscheidet, welche Views, Extraktoren und Felder überhaupt zulässig sind. Zählebene, Fakten und die Order-to-Billing-Beziehung sind eine eigene Modellierungsentscheidung, die dieser Guide trifft.

Ansatz

Freigegebener Quellumfang
→ Document Flow und gewünschte Zählebene
→ Fakten- und Dimensionskandidaten
→ KPI-Karten auf derselben Zählebene
→ Mart-Steckbrief

Der Document Flow für Order-to-Cash lautet in vereinfachter Form:

Sales Order (Header)
→ Sales Order Item
→ Delivery
→ Billing Document
→ Accounting Entry

Für einen ersten Mart wird nur ein Ausschnitt dieses Flows freigegeben: Sales Order Header und Item als primäre Fact-Quelle für Order Value und Backlog, sowie optional die Beziehung zum Billing Document, wenn realisierter Umsatz statt zugesagtem Auftragswert benötigt wird. Delivery- und Goods-Movement-Ereignisse bleiben außerhalb des Scopes, solange keine Logistik-Kennzahl explizit gefordert ist.

Order Value und Billed Value werden nicht in derselben Kennzahl vermischt. Eine KPI wie Book-to-Bill vergleicht beide Werte explizit auf vergleichbarer Periodenbasis, statt sie stillschweigend gleichzusetzen.

Zählebene und Fakten- und Dimensionskandidaten

Primäre Zählebene: eine Zeile pro Sales-Order-Position (VBAP-Ebene, konkret über die freigegebene CDS View oder den Extraktor).

Ergänzende Zählebene (Umsatzrealisierung): eine Zeile pro Billing-Document-Position.

Auftragsmenge und Nettowert sind additive Fakten auf Positionsebene. Der Auftragsstatus ist ein Statusattribut. Currency- und Unit-of-Measure-Umrechnung werden explizit dokumentiert, bevor über Organisationseinheiten oder Perioden aggregiert wird — Beträge aus unterschiedlichen Währungen dürfen nicht ungeprüft addiert werden.

Personenbezogene und ausgeschlossene Daten

Ein Sales-Order-Mart enthält primär kommerzielle, keine personenbezogenen Daten. Wo Ansprechpartner-Referenzen oder Kontaktfelder aus dem Customer-Master einfließen, gilt dieselbe Feld-Allowlist-Regel wie in jeder anderen Quelle: nur freigegebene Felder, keine unbeschränkten Freitextfelder oder Notizen.

Die vollständige Objekt- und Feldentscheidung — inklusive Technical Logs, obsoleter Views und Textfeldern — steht in Welche SAP-S/4-Tabellen für Analytics laden — und welche skippen. Nutze den PII Recommend Generator für die Feldklassifikation, falls Kundenkontakte einbezogen werden.

Standard-KPIs

Auf dem gewählten Order-/Billing-Ausschnitt lassen sich verlässlich definieren:

• Order Backlog — Summe offener, noch nicht fakturierter Auftragswerte je Periode.
• Book-to-Bill Ratio — Verhältnis von Auftragseingang zu fakturiertem Umsatz im selben Zeitraum.
• Revenue by Product — fakturierter Wert je Material und Periode.
• Order Fulfillment Rate — Anteil vollständig fakturierter Positionen an allen Positionen im Zeitraum.

Jede Kennzahl benötigt eine eigene KPI-Karte mit Zähler, Nenner, Zeitlogik, Währungsregel und Owner. Nutze KPI definieren für die Methodik und den KPI Definition-Generator zur Erfassung.

Artefakt

• source-scope.csv / source-scope.md — freigegebene Views, Extraktoren, Felder und die Order-to-Billing-Zuordnung.
• kpi-cards.csv — die Standard-KPIs mit Formel, Angabe der Zählebene, Währungsregel und verantwortliche Person.
• mart-design-brief.md — Document Flow, Zählebene, Fact-/Dimension-Kandidaten und explizit ausgeschlossene Prozessschritte (Delivery, Goods Movement) für den Sales-Order-Mart.

Dieselben Dateinamen gelten über alle Guides dieser Serie hinweg.

Tools und nächste Schritte

• Quellumfang Builder — freigegebene Views, Extraktoren und Felder als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko klassifizieren, sobald Kundenkontakte einbezogen werden.
• Mart-Steckbrief-Generator — Zählebene, Fakten, Dimensionen und bewusst ausgeschlossene Inhalte als mart-design-brief.md freigeben.
• KPI Definition — Standard-KPIs als kpi-cards.csv versionieren.

Ob überhaupt ein schmaler Sales-Ausschnitt oder ein anderer SAP-Prozess der richtige Startpunkt ist, klärt der Governance Advisor. Dieser Guide setzt eine bereits getroffene Priorisierung fort.

Verwandte Playbooks

• Welche SAP-S/4-Tabellen für Analytics laden — und welche skippen — die vorgelagerte Load/Skip-Entscheidung für Views, Extraktoren und Felder.
• Vom Stakeholder-Interview zum Tabellenmodell — die allgemeine Methodik für Zählebene, Fakten, Dimensionen und den Mart-Steckbrief.
• Welche Quelle zuerst laden? — die Portfolio-Entscheidung, falls SAP S/4 noch gegen andere Kandidaten priorisiert werden muss.

Das vollständige Supplier-Profil mit Produktkontext, Compliance-Hinweisen und weiteren Ressourcen steht in der Supplier Library: SAP S/4HANA.

Workday führt Worker, Position und Organisation als effective-dated Objekte: Jede Änderung besitzt ein Gültigkeitsdatum, und mehrere Zustände können nebeneinander existieren. Ein Headcount-Mart muss diese Zeitsemantik bewusst abbilden, statt sie in einen einfachen aktuellen Zustand zu komprimieren. Dieser Guide zeigt, wie aus dem freigegebenen Quellumfang ein periodischer Snapshot-Mart entsteht, der Headcount, FTE und Vakanzen auf einer konsistenten, wiederholbaren Grundlage berichtet.

Der Snapshot-Ansatz ist bewusst gewählt: Workforce-Kennzahlen werden fast immer zu einem Stichtag oder für eine Periode gebraucht, nicht als kontinuierlicher Eventstrom.

Herausforderung

Ein aktueller Worker-Export beantwortet nur, wie die Belegschaft heute aussieht. Historische oder periodische Fragen scheitern an typischen Fehlern.

• Die aktuelle Supervisory Organization wird rückwirkend auf vergangene Perioden angewendet, sodass eine Reorganisation die Historie verfälscht.
• Mehrere Positionen desselben Workers (Primary und Additional Job) werden in einen Current Record kollabiert, wodurch Headcount und FTE nicht mehr übereinstimmen.
• Future-Dated Changes — bereits erfasste, aber noch nicht wirksame Änderungen — werden zu früh sichtbar, wenn Effective-Date-Logik fehlt.
• Compensation- und Payroll-Daten werden ungeprüft in denselben Mart geladen wie Headcount-Kennzahlen, obwohl beide unterschiedliche Zweckfreigaben und Security Domains benötigen.

Der freigegebene Quellumfang aus Welche Workday-Objekte laden — und welche auslassen entscheidet, welche Objekte und Felder überhaupt zulässig sind. Die Snapshot-Logik und die Zählebene für den Headcount-Mart sind eine eigene, hier getroffene Entscheidung.

Ansatz

Freigegebener Quellumfang
→ Workforce-Entscheidung und Snapshot-Zählebene
→ Fakten- und Dimensionskandidaten
→ KPI-Karten auf derselben Zählebene
→ Mart-Steckbrief

Die zentrale Entscheidung lautet: Der Headcount-Mart ist ein periodischer Snapshot, keine Transaktionstabelle. Für jeden Snapshot-Zeitpunkt — üblicherweise Monatsende — wird eine Zeile pro aktivem Worker und Position erzeugt, basierend auf dem zu diesem Zeitpunkt effective-dated Zustand. Correction- und Rescind-Verhalten werden explizit behandelt: Eine rückwirkende Korrektur verändert einen bereits erzeugten Snapshot nicht automatisch, sondern löst eine dokumentierte Reprocessing-Regel aus.

Compensation, Payroll und andere Financial-Detail-Daten werden nicht Teil dieses Marts. Sie benötigen eine eigene Zweckfreigabe, eigene Population und eigene Security Domain und gehören in ein separates Produkt.

Zählebene und Fakten- und Dimensionskandidaten

Primäre Zählebene: eine Zeile pro Worker, Position und Snapshot-Datum.

Headcount und FTE sind additive Fakten innerhalb eines Snapshots, aber nicht über Snapshots hinweg summierbar — sie werden je Periode neu berechnet, nicht kumuliert. Vakante Positionen sind ein eigener Fact-Kandidat, kein Attribut des Worker-Fact. Turnover- und Hiring-Kennzahlen benötigen ein separates Event-Fact (eine Zeile pro Eintritt, Austritt oder Wechsel), weil sie Bewegungen und keinen Zustand messen — sie werden nicht aus der Differenz zweier Snapshots geraten, sondern aus den zugrundeliegenden Events abgeleitet.

Personenbezogene und ausgeschlossene Daten

Ein Headcount-Mart benötigt keine direkten Worker-Identifikatoren, Kontaktdaten oder Compensation-Details. Aggregierte oder pseudonymisierte Worker-Referenzen genügen für Headcount- und FTE-Kennzahlen. Health-, Benefits- und Document-Content-Daten bleiben grundsätzlich außerhalb, ebenso unbeschränkte Freitextfelder aus Worker-Profilen.

Die vollständige Objekt- und Feldentscheidung — inklusive Security Domains und Feldminimierung — steht in Welche Workday-Objekte laden — und welche skippen. Nutze den PII Recommend Generator, falls einzelne Worker-Attribute doch benötigt werden.

Standard-KPIs

Auf der Snapshot-Zählebene lassen sich verlässlich definieren:

• Headcount — Anzahl aktiver Worker je Snapshot-Datum, Organisation und Standort.
• FTE — Summe der Full-Time-Equivalent-Werte je Snapshot-Datum und Organisation.
• Vacancy Rate — Anteil offener Positionen an allen budgetierten Positionen.
• Span of Kontrollregel — durchschnittliche Anzahl direkter Berichte je Manager.

Turnover- und Time-to-Fill-Kennzahlen gehören auf ein separates Event-Fact und werden hier nur als Ausblick genannt. Jede Kennzahl benötigt eine eigene KPI-Karte mit Population, Snapshot-Logik und Owner. Nutze KPI definieren für die Methodik und den KPI Definition-Generator zur Erfassung.

Artefakt

• source-scope.csv / source-scope.md — freigegebene Worker-, Position- und Organisationsobjekte samt Security-Domain-Entscheidung.
• kpi-cards.csv — Headcount-, FTE- und Vacancy-KPIs mit Snapshot-Logik und verantwortliche Person.
• mart-design-brief.md — Snapshot-Körnung, Effective-Date- und Correction-Verhalten, Fact-/Dimension-Kandidaten und explizit ausgeschlossene Compensation-Daten.
• dq-backlog.csv — offene Datenqualitätsfragen, etwa unvollständige Effective-Date-Ketten oder ungeklärte Multiple-Job-Fälle.

Dieselben Dateinamen gelten über alle Guides dieser Serie hinweg.

Tools und nächste Schritte

• Quellumfang Builder — Worker-, Position- und Organisationsobjekte als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Worker-Attribute klassifizieren.
• Mart-Steckbrief-Generator — Snapshot-Körnung, Fakten, Dimensionen und bewusst ausgeschlossene Inhalte als mart-design-brief.md freigeben.
• KPI Definition — Standard-KPIs als kpi-cards.csv versionieren.

Ob Workday überhaupt die richtige nächste Quelle ist und wer die Snapshot-Entscheidung freigeben muss, klärt der Governance Advisor.

Verwandte Playbooks

• Welche Workday-Objekte laden — und welche skippen — die vorgelagerte Load/Skip-Entscheidung für Objekte, Felder und Security Domains.
• Vom Stakeholder-Interview zum Tabellenmodell — die allgemeine Methodik für Zählebene, Fakten, Dimensionen und den Mart-Steckbrief.
• Welche Quelle zuerst laden? — die Portfolio-Entscheidung, falls Workday noch gegen andere Kandidaten priorisiert werden muss.

Das vollständige Supplier-Profil mit Produktkontext, Compliance-Hinweisen und weiteren Ressourcen steht in der Supplier Library: Workday.

Eine Dynamics-365-Umgebung ist eine konfigurierte Dataverse-Anwendung. Standardtabellen wie account, contact und opportunity können durch eigene Prozesse, Auswahllisten und Geschäftsregeln erweitert werden. Dieses Kapitel zeigt, wie aus dem freigegebenen Quellumfang ein Opportunity-Mart entsteht: mit einer Zeile pro Verkaufschance, klaren Fakten und Dimensionen sowie einer ersten Version der wichtigsten Pipeline-Kennzahlen.

Wie bei den anderen Quellen dieser Serie ist der Ausgangspunkt nicht die vollständige Dataverse-Tabellenliste, sondern eine benannte Entscheidung — hier: Pipeline-Wert und -Bewegung nach Stage und Owner sichtbar machen.

Herausforderung

Ein tabellengetriebener Zugriff auf Dataverse führt zu denselben Fehlermustern wie bei anderen CRM-Systemen, verschärft durch die Konfigurierbarkeit der Plattform.

• opportunity und opportunityproduct (Line Item) werden vermischt, obwohl sie unterschiedliche Grains besitzen — Summen auf Opportunity-Ebene können von der Summe der Produktpositionen abweichen.
• Der aktuelle statuscode- oder stepname-Wert wird auf historische Perioden angewendet, sodass Verlauf durch die Vertriebsphasenen nicht mehr rekonstruierbar sind.
• Option-Set-Werte (z. B. Stage- oder Status-Labels) werden als stabile Business-Begriffe behandelt, obwohl sie in der Solution jederzeit umbenannt oder umsortiert werden können.
• account und contact werden ungeprüft mit voller Feldbreite geladen, obwohl nur wenige Segmentierungs- und Kontextfelder für den Mart benötigt werden.

Der freigegebene Quellumfang aus Welche Dynamics-365-Tabellen laden — und welche skippen entscheidet, welche Tabellen, Felder und Beziehungen zulässig sind. Zählebene und Fakten für den Opportunity-Mart sind eine eigene, hier getroffene Entscheidung.

Ansatz

Freigegebener Quellumfang
→ Geschäftsereignis und gewünschte Zählebene
→ Fakten- und Dimensionskandidaten
→ KPI-Karten auf derselben Zählebene
→ Mart-Steckbrief

Für ein erstes Vertriebsprodukt ist Opportunity-Zählebene der pragmatischste Startpunkt: eine Zeile pro opportunity, angereichert um governte account-, contact- und Angaben zu verantwortlichen Personen (systemuser). Diese Zählebene beantwortet Pipeline-Wert, Stage-Verteilung und Forecast-Fragen, ohne Produktkomplexität vorwegzunehmen.

Sobald Revenue nach Produkt benötigt wird, wechselt eine zweite Faktentabelle auf opportunityproduct-Zählebene — die Opportunity liefert dann nur noch Header-Kontext. Option-Set-Werte für Stage und Status werden auf eine governte, stabile Referenz gemappt, statt das rohe Label direkt als Dimension zu verwenden.

Zählebene und Fakten- und Dimensionskandidaten

Primäre Zählebene: eine Zeile pro Opportunity (opportunity).

Alternative Zählebene (Produkt-Mart): eine Zeile pro Opportunity-Produktposition (opportunityproduct).

estimatedvalue und actualvalue sind additive Fakten, solange sie über die vorgesehenen Dimensionen konsistent summierbar bleiben — actualvalue ist erst nach Win/Loss belastbar befüllt. Statuscode und Stage sind Statusattribute, keine additiven Kennzahlen. Eine Analyse des Verlaufs durch die Vertriebsphasen benötigt einen eigenen Snapshot- oder Event-Fact, nicht eine Ableitung aus dem aktuellen Zustand.

Personenbezogene und ausgeschlossene Daten

contact- und systemuser-Felder werden nur mit freigegebener Allowlist übernommen. Activities (phonecall, appointment, email) bleiben außerhalb des Opportunity-Marts, solange kein benannter Aktivitäts-Use-Case existiert. Custom Fields und Custom Tables aus installierten Solutions werden gegen den konfigurierten Prozess geprüft, bevor sie in den Scope aufgenommen werden.

Die vollständige Objekt- und Feldentscheidung — inklusive Security Roles und Löschverhalten — steht in Welche Dynamics-365-Tabellen laden — und welche skippen. Nutze den PII Recommend Generator für die Feldklassifikation.

Standard-KPIs

Auf Opportunity-Zählebene lassen sich verlässlich definieren:

• Pipeline Value — Summe estimatedvalue offener Opportunities je Stage, Owner und Periode.
• Win Rate — Anteil gewonnener Opportunities an allen abgeschlossenen Opportunities im Zeitraum.
• Average Deal Size — Durchschnittlicher actualvalue gewonnener Opportunities.
• Stage Conversion Rate — Anteil der Opportunities, die von einer Stage zur nächsten übergehen.

Jede Kennzahl benötigt eine eigene KPI-Karte mit Zähler, Nenner, Zeitlogik und Owner. Nutze KPI definieren für die Methodik und den KPI Definition-Generator zur strukturierten Erfassung.

Artefakt

• source-scope.csv / source-scope.md — freigegebene Dataverse-Tabellen, Felder und Beziehungen.
• kpi-cards.csv — die Standard-KPIs mit Formel, Angabe der Zählebene, Filtern und verantwortliche Person.
• mart-design-brief.md — Geschäftsereignis, Zählebene, Fact-/Dimension-Kandidaten, Stage-Mapping und bewusst ausgeschlossene Inhalte für den Opportunity-Mart.

Dieselben Dateinamen gelten über alle Guides dieser Serie hinweg.

Tools und nächste Schritte

• Quellumfang Builder — Dataverse-Tabellen, Felder und Beziehungen als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Contact- und User-Attribute klassifizieren.
• Mart-Steckbrief-Generator — Zählebene, Fakten, Dimensionen und bewusst ausgeschlossene Inhalte als mart-design-brief.md freigeben.
• KPI Definition — Standard-KPIs als kpi-cards.csv versionieren.

Ob Dynamics 365 überhaupt die richtige nächste Quelle ist, klärt der Governance Advisor. Dieser Guide vertieft eine bereits getroffene Priorisierung.

Verwandte Playbooks

• Welche Dynamics-365-Tabellen laden — und welche skippen — die vorgelagerte Load/Skip-Entscheidung für Tabellen, Felder und Beziehungen.
• Vom Stakeholder-Interview zum Tabellenmodell — die allgemeine Methodik für Zählebene, Fakten, Dimensionen und den Mart-Steckbrief.
• Welche Quelle zuerst laden? — die Portfolio-Entscheidung, falls Dynamics 365 noch gegen andere Kandidaten priorisiert werden muss.

Das vollständige Supplier-Profil mit Produktkontext, Compliance-Hinweisen und weiteren Ressourcen steht in der Supplier Library: Dynamics 365.