Von Quelle zum Mart

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Sizing: KMU — ein Grain-Satz und ein Fact-Kandidat bis zum publizierbaren Mart, Standard-KPIs auf diesem Grain. Mid-Market — shared Dims über zwei Consumer-Tools, Steward in Sales Ops oder Analytics. Enterprise — Multi-Prozess-Marts, Snapshot-Fact für Stage-Bewegung, Retire-Kriterien, KPI-Karten im Review-Takt.

Source-to-Mart-Governance beginnt nicht mit einem Salesforce-Dashboard. Sie beginnt mit der Entscheidung, was eine Zeile im Pipeline-Mart bedeutet — nachdem der Source Scope Objekte freigegeben hat, bevor Amount summiert wird.

Typische Fragen sind:

• Welches Business Event bestimmt die fachliche Ebene — Opportunity erstellt/bewegt/geschlossen, nicht die Tabellenliste?; Opportunity-Körnung oder Positions-Körnung, und warum nicht beides in einer Fact?; Welche Objekte sind Fact-Quelle, welche Dimension (Account, User, Stage-Referenz)?; Welche Felder bleiben Skip — Contact-personenbezogene Daten, Notizen, Activities ohne Use Case?; Welche KPI-Karten hängen am selben fachliche Ebene — Pipeline Value, Win Rate, Cycle Length?; Wer gibt den Auswertungstabelle Design Brief frei, bevor Tabellen gebaut werden?

Wenn Scope, Grain und Dashboard auseinanderlaufen, gelten Objekte als „geladen“, Opportunity und Line Item mischen sich, und StageName färbt die Historie rückwirkend. Das Problem ist nicht Snowflake. Es ist der fehlende Vertrag zwischen Event, Grain und Karte.

Guter Salesforce-Mart macht die Zeile ausführbar — Event, Grain und KPI am selben Fact, nicht am neuesten Report.

Anschluss an Welche Salesforce-Tabellen für Analytics laden, Vom Stakeholder-Interview zum Tabellenmodell und Supplier Library: Salesforce.

Weiter: HubSpot → Mart: Deal-Grain zum Pilotprojekt-Mart.

Die Serie Von Quelle zum Mart gibt dir den Einstieg und den roten Faden für die folgenden Teile. Die folgenden Teile übertragen dasselbe Muster auf HubSpot, SAP S/4, Workday und Dynamics 365 — als Operating-Verträge je Source, nicht als fünf Connector-Tutorials.

Ausgangslage

Der Salesforce Source Scope ist freigegeben: Objekte, Felder, Beziehungen. Ein Team springt trotzdem direkt ins Dashboard. Opportunity und OpportunityLineItem landen in einer Fact. Der aktuelle StageName wird auf alte Perioden gelegt. Amount wird ohne Währungs- und Forecast-Kategorie summiert. Owner bleibt Freitext. Teams kaufen dann ein neues BI-Tool oder taggen den Mart certified — und die nächste Produktsicht verdoppelt den Umsatz.

Was diese Serie klärt

• Orientierung: Event → fachliche Ebene → Fact/Dim → KPI-Karten → Brief (diese Seite, Salesforce)
• Vertiefung: HubSpot Deal-fachliche Ebene
• Vertiefung: SAP S/4 Sales-/Auftrags-Ausschnitt
• Vertiefung: Workday Workforce-Headcount-Snapshot
• Abschluss: Dynamics 365 Opportunity-Fakten-Kandidaten

Begriffe und Kürzel vor dem Lesen

• Source Umfang — freigegebene Objekte, Felder und Beziehungen. Er erlaubt Load, er definiert nicht den Auswertungstabelle-fachliche Ebene.
• Business Event — Opportunity wird erstellt, durch Stages bewegt, gewonnen, verloren oder storniert. Das Event bestimmt die fachliche Ebene.
• fachliche Ebene-Satz — eine Zeile pro Opportunity oder pro Position. Beide in einer Fact zu mischen ist Drift.
• Fact vs. Statusattribut — Amount und Quantity sind additiv; Probability und StageName beschreiben Zustand, keine Menge.
• Snapshot-Fact — eine Zeile pro Opportunity und Berichtsdatum für Stage-Bewegung; nicht rückwirkend aus dem Current-State simuliert.
• KPI-Karte — Zähler, Nenner, Zeitlogik, Ausschlüsse, verantwortliche Person — am deklarierten fachliche Ebene, nicht als Dashboard-Folklore.

Lesepfad

1. Salesforce → Mart: Grain, Fakten und KPI-Karten
2. HubSpot → Mart: Deal-Grain zum Pilotprojekt-Mart
3. SAP S/4 → Mart: klarer Sales-/Auftrags-Ausschnitt
4. Workday → Mart: Workforce-Headcount-Snapshot
5. Dynamics 365 → Mart: Opportunity-Fakten-Kandidaten

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Objekt-, Feld- und Toolnamen durch eure Catalog-, CRM- und Prozessquellen.

Produkte und Entscheidungen

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

Grain-Vertrag

Dieses Produkt beschreibt:

• Business Event; primärer fachliche Ebene (Opportunity) oder alternativer fachliche Ebene (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?

Fact- und Dimension-Kandidaten

Entscheidungen:

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

KPI-Karten auf dem Grain

Auf Opportunity-Grain 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 fachliche Ebene-Referenz gilt als Folklore?

Mart Design Brief plus Scope-Artefakte

Drei Dateien, ein Grain:

• source-scope.csv / source-scope.md — freigegebene Objekte aus dem vorgelagerten Register.
• kpi-cards.csv — Standard-KPIs mit Formel, fachliche Ebene, Filtern, verantwortliche Person.
• mart-design-brief.md — Event, fachliche Ebene, Fact/Dim, Historie, Umfang-Out — 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 Source Scope und Mart-Grain

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 Owner-Freitext und User-Referenz

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

Zwischen PII-„später anreichern“ und Source-Scope

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, Grain 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 Grain still mischen.

Analytics Engineer / Custodian

Setzt Fact/Dim und Modelle um. Implementierungsmacht ist keine Grain-Verantwortung.

Data Architect

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

Privacy / PII Steward

Hält Skip- und Allowlist-Entscheidungen aus dem Source Scope. 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

Symptom: 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. Der verantwortliche Person steht nur als Textfeld im Export.

Typischer Fehlstart: Neues Warehouse oder certified-Tag, ohne Event, ohne Brief und ohne KPI-Karten an der fachlichen Ebene.

Vereinbarung: Event benennen; Opportunity-Körnung für das Pilotprojekt; zweite Fact wenn Produkt-Revenue nötig; Karten mit KPI Definition; Brief mit Auswertungstabelle Design Brief 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 dem fachliche Ebene schreiben
• Brief nach dem Tabellenbau nachreichen

Erster Umsetzungsschnitt

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

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

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

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

Schritt 1: Rahmen und Entscheidung klären

Freigegebenen Source Scope lesen. Event und Ziel-Grain skizzieren. Sales Ops und Architect benennen. Bekannte Dashboard-Konflikte listen.

Schritt 2: Control und Nachweis umsetzen

Grain-Vertrag schließen. Fact-/Dim-Tabelle für das Pilotprojekt füllen. Zwei bis drei KPI-Karten auf diesem Grain versionieren. Brief-Entwurf.

Schritt 3: Testen und Ausnahmen sichtbar machen

Brief freigeben. PII-Skip 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 Grain und Brief gehalten haben.

Exit-Kriterien

• Der Pilotprojekt-Auswertungstabelle hat einen fachliche Ebene-Satz und vermischt Opportunity nicht mit Position.
• KPI-Karten referenzieren denselben fachliche Ebene; Formeln ohne fachliche Ebene sind Folklore.
• Snapshot-Bedarf ist ja oder nein — nicht heimlich aus Current-State gebaut.
• personenbezogene Daten/Skip folgt dem Source Umfang, 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
• Source Umfang Builder
• Governance Advisor

Ein freigegebener HubSpot Source Scope legt fest, welche Objekte, Properties und Associations geladen werden dürfen. Damit ist aber noch kein Mart entstanden. Dieser Guide zeigt den nächsten Schritt für ein typisches Pilotprodukt: einen Deal-Mart, der Pipeline-Steuerung nach Stage und Owner unterstützt, mit explizitem Grain, benannten Fact- und Dimension-Kandidaten und einer ersten Version der Standard-KPIs.

Der Fokus liegt bewusst auf einem kleinen, vollständigen Pilotprojekt-Mart statt auf einer vollständigen Abbildung des HubSpot-Portals. Ein Pilotprojekt, der Stage-Steuerung zuverlässig unterstützt, liefert 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 Stage-Bewegungsanalyse 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 Source Scope aus Welche HubSpot-Tabellen laden — und welche skippen entscheidet, welche Objekte und Properties überhaupt verfügbar sind. Die Grain- und Fakten-Entscheidung für den Mart bleibt trotzdem ein eigener Schritt.

Ansatz

Freigegebener Source Scope
→ Business Event und Ziel-Grain
→ Fact- und Dimension-Kandidaten
→ KPI-Karten auf demselben Grain
→ Mart Design Brief

Für einen ersten Pilotprojekt-Mart ist Deal-Grain der pragmatischste Startpunkt: eine Zeile pro Deal, angereichert um governte Company-, Contact- und Owner-Kontexte. Dieser Grain 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-Grain 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.

Grain und Fact/Dim-Kandidaten

Primärer Grain: eine Zeile pro Deal.

Alternativer Grain (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 Stage-Bewegungsanalyse 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.

PII und Skip

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-Grain 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, fachliche Ebene-Referenz, Filtern und verantwortliche Person.
• mart-design-brief.md — Business Event, fachliche Ebene, Fact-/Dimension-Kandidaten, Primary-Company-Regel und Umfang-Out für den Deal-Auswertungstabelle.

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

Tools und nächste Schritte

• Source Umfang Builder — HubSpot-Objekte, Properties und Associations als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Contact- und Company-Properties klassifizieren.
• Auswertungstabelle Design Brief Generator — fachliche Ebene, Fakten, Dimensionen und Umfang-Out 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 fachliche Ebene, Fakten, Dimensionen und den Auswertungstabelle Design Brief.
• 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 Source Scope 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 Source Scope aus Welche SAP-S/4-Tabellen für Analytics laden — und welche skippen entscheidet, welche Views, Extraktoren und Felder überhaupt zulässig sind. Grain, Fakten und die Order-to-Billing-Beziehung sind eine eigene Modellierungsentscheidung, die dieser Guide trifft.

Ansatz

Freigegebener Source Scope
→ Document Flow und Ziel-Grain
→ Fact- und Dimension-Kandidaten
→ KPI-Karten auf demselben Grain
→ Mart Design Brief

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.

Grain und Fact/Dim-Kandidaten

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

Ergänzender Grain (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.

PII und Skip

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, fachliche Ebene-Referenz, Währungsregel und verantwortliche Person.
• mart-design-brief.md — Document Flow, fachliche Ebene, Fact-/Dimension-Kandidaten und explizit ausgeschlossene Prozessschritte (Delivery, Goods Movement) für den Sales-Order-Auswertungstabelle.

Dieselben Dateinamen gelten über alle Guides dieser Serie hinweg.

Tools und nächste Schritte

• Source Umfang Builder — freigegebene Views, Extraktoren und Felder als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko klassifizieren, sobald Kundenkontakte einbezogen werden.
• Auswertungstabelle Design Brief Generator — fachliche Ebene, Fakten, Dimensionen und Umfang-Out 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 fachliche Ebene, Fakten, Dimensionen und den Auswertungstabelle Design Brief.
• 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 Source Scope 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 Auswertungstabelle geladen wie Headcount-Kennzahlen, obwohl beide unterschiedliche Zweckfreigaben und Security Domains benötigen.

Der freigegebene Source Scope aus Welche Workday-Objekte laden — und welche skippen entscheidet, welche Objekte und Felder überhaupt zulässig sind. Die Snapshot-Logik und der Grain für den Headcount-Mart sind eine eigene, hier getroffene Entscheidung.

Ansatz

Freigegebener Source Scope
→ Workforce-Entscheidung und Snapshot-Grain
→ Fact- und Dimension-Kandidaten
→ KPI-Karten auf demselben Grain
→ Mart Design Brief

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.

Grain und Fact/Dim-Kandidaten

Primärer Grain: 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.

PII und Skip

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 dem Snapshot-Grain 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

• Source Umfang Builder — Worker-, Position- und Organisationsobjekte als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Worker-Attribute klassifizieren.
• Auswertungstabelle Design Brief Generator — Snapshot-Körnung, Fakten, Dimensionen und Umfang-Out 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 fachliche Ebene, Fakten, Dimensionen und den Auswertungstabelle Design Brief.
• 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, in der Standardtabellen wie account, contact und opportunity durch Custom-Prozesse, Option Sets und Business Rules ergänzt werden können. Dieser Guide zeigt, wie aus dem freigegebenen Source Scope ein Opportunity-Mart entsteht: mit explizitem Grain, konkreten Fakten- und Dimensionskandidaten aus Dataverse und einer ersten Version der Standard-KPIs für Pipeline-Steuerung.

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 Stage-Bewegungen 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 Auswertungstabelle benötigt werden.

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

Ansatz

Freigegebener Source Scope
→ Business Event und Ziel-Grain
→ Fact- und Dimension-Kandidaten
→ KPI-Karten auf demselben Grain
→ Mart Design Brief

Für ein erstes Vertriebsprodukt ist Opportunity-Grain der pragmatischste Startpunkt: eine Zeile pro opportunity, angereichert um governte account-, contact- und Owner-Kontexte (systemuser). Dieser Grain 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-Grain — 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.

Grain und Fact/Dim-Kandidaten

Primärer Grain: eine Zeile pro Opportunity (opportunity).

Alternativer Grain (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 Stage-Bewegungsanalyse benötigt einen eigenen Snapshot- oder Event-Fact, nicht eine Ableitung aus dem aktuellen Zustand.

PII und Skip

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-Grain 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, fachliche Ebene-Referenz, Filtern und verantwortliche Person.
• mart-design-brief.md — Business Event, fachliche Ebene, Fact-/Dimension-Kandidaten, Stage-Mapping und Umfang-Out für den Opportunity-Auswertungstabelle.

Dieselben Dateinamen gelten über alle Guides dieser Serie hinweg.

Tools und nächste Schritte

• Source Umfang Builder — Dataverse-Tabellen, Felder und Beziehungen als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko für Contact- und User-Attribute klassifizieren.
• Auswertungstabelle Design Brief Generator — fachliche Ebene, Fakten, Dimensionen und Umfang-Out 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 fachliche Ebene, Fakten, Dimensionen und den Auswertungstabelle Design Brief.
• 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.