Zum Inhalt springen
Search the hub
Salesforce → Mart: Grain, Fakten und KPI-Karten

Salesforce → Mart: Grain, Fakten und KPI-Karten

Aus dem freigegebenen Salesforce Source Scope einen konkreten Pipeline-Mart mit Opportunity-Grain, Fact/Dim-Kandidaten und versionierten KPI-Karten ableiten.

Category
Data Governance
Reading time
9 min
Published
Tags
salesforce mart-design grain data-governance
Download PDF

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

Rolle Salesforce-Objekt Verwendung
Fact-Quelle (Opportunity-Grain) Opportunity Amount, Probability, CloseDate, StageName je Opportunity
Fact-Quelle (Positions-Grain) OpportunityLineItem Quantity, UnitPrice, TotalPrice je Position
Dimension: Kunde Account Segment, Industry, Region als beschreibender Kontext
Dimension: Ansprechpartner Contact nur mit freigegebener Feld-Allowlist, primär als Rollen-Referenz
Dimension: Owner User verantwortliche Vertriebsperson oder Team
Dimension: Produkt Product2 / PricebookEntry nur bei Positions-Grain erforderlich
Dimension: Stage governte Stage-Referenz Mapping von StageName auf eine stabile Stage-Reihenfolge
Dimension: Datum Kalender-Dimension CloseDate, CreatedDate, LastModifiedDate getrennt gehalten

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

Von An Artefakt
Source-Scope-Owner Mart-Owner source-scope.csv und Skip/PII-Grenzen
Sales Ops Architect / Engineer Grain-Satz und Event
KPI-Owner Steward kpi-cards.csv auf dem Grain
Architect Engineer Fact-/Dim-Kandidaten und Snapshot-Ja/Nein
Engineer Steward Umsetzung versus Brief — keine stille Grain-Mischung
Privacy Engineer Contact-/User-Allowlist

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.

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

Supplier to Mart

Part 1 of 5

View series

Knowledge check

Tour