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.
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.
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
- Salesforce → Mart: Grain, Fakten und KPI-Karten
- HubSpot → Mart: Deal-Grain zum Pilotprojekt-Mart
- SAP S/4 → Mart: klarer Sales-/Auftrags-Ausschnitt
- Workday → Mart: Workforce-Headcount-Snapshot
- 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
- Welche Salesforce-Tabellen für Analytics laden
- Vom Stakeholder-Interview zum Tabellenmodell
- Welche Quelle zuerst laden?
- Supplier Library: Salesforce
- Source Umfang Builder
- Governance Advisor
Supplier to Mart
Part 1 of 5
View series