Revenue Data Dictionary: Die gemeinsame Sprache für RevOps

Ein Revenue Data Dictionary definiert die Begriffe und Felder, die das Revenue-System antreiben.

Ohne ein solches Dictionary nutzen Teams dieselben Bezeichnungen unterschiedlich. „Lead-Quelle", „SQL", „Pipeline", „Commit", „Churn" und „Expansion" können je nach Berichterstatter jeweils etwas anderes bedeuten.

RevOps besitzt das Dictionary, damit das Unternehmen seinen Dashboards und Workflows vertrauen kann.

Forresters Modell der RevOps-Verantwortlichkeiten ist hilfreich, weil das Dictionary funktionsübergreifend wirkt und nicht in einem einzelnen Team liegt. Forresters Forschung zur RevOps-Technologieausrichtung bekräftigt zudem, warum Revenue-Technologie gemeinsame Governance braucht.

Wichtige Fakten für den Betrieb

• Ein Revenue Data Dictionary ist keine Tabelle mit Feldnamen. Es ist der gemeinsame Vertrag dafür, wie Teams Revenue-Daten definieren, eingeben, ändern und berichten.
• Die erste Version sollte sich auf Felder und Kennzahlen konzentrieren, die Entscheidungen beeinflussen: Lifecycle-Stufe, Quelle, Segment, Owner, Stufe, Forecast-Kategorie, Betrag, Verlängerungsdatum, Churn-Grund und Expansionssignal.
• Definitionen brauchen Owner. Ein Feld ohne Owner driftet, besonders wenn es in Executive-Reporting, Forecast-Calls oder der Finanzplanung auftaucht.
• Jede Board-relevante Kennzahl sollte sich auf einen Dictionary-Eintrag zurückführen lassen. Das verhindert, dass Board-Ready Revenue Reporting und Forecast Governance zu Definitionsdebatten werden.

Was aufgenommen werden sollte

Mit kritischen Feldern beginnen

Dokumentieren Sie nicht zuerst jedes Feld. Beginnen Sie mit Lifecycle-Status, Lead-Quelle, Owner, Segment, Stufe, Abschlussdatum, Forecast-Kategorie, Betrag, Churn-Grund, Verlängerungsdatum und Expansionstyp.

Verknüpfen Sie dies mit CRM Field Governance.

Warum ein Dictionary wichtig ist

Ein Data Dictionary verhindert, dass Teams vertraute Wörter auf unvereinbare Weise nutzen.

Zum Beispiel:

• Marketing definiert SQL möglicherweise als von Sales akzeptiert.
• Sales definiert SQL möglicherweise als abgeschlossene Discovery.
• Finance definiert Pipeline möglicherweise nur als qualifizierte Opportunities.
• Sales-Manager beziehen frühe Opportunities eventuell in die Pipeline ein.
• CS definiert Churn nach Logo, während Finance Umsatz-Churn berichtet.

Diese Unterschiede sind nicht semantisch. Sie verändern Dashboards, Planung, Budget, Forecast und Verantwortlichkeit.

Struktur des Dictionary

Jeder Eintrag sollte enthalten:

Diese Struktur macht das Dictionary sowohl für Geschäftsführung als auch für System-Owner nützlich.

Qualitätsstandard für Definitionen

Die Qualität eines Dictionary-Eintrags hängt davon ab, ob er Interpretationsspielraum aus der echten Arbeit entfernen kann.

Ein starker Eintrag beantwortet fünf Fragen:

Schwache Definitionen klingen vertraut, leiten aber kein Verhalten an. „Qualified Pipeline ist Pipeline, die echt aussieht" übersteht keinen Forecast-Call. „Qualified Pipeline ist der Betrag offener Opportunities, bei denen die Opportunity die Austrittskriterien von Stufe 2 überschritten hat, ein aktuelles Abschlussdatum besitzt, einen Owner hat und nicht durch die Forecast-Policy ausgeschlossen ist" gibt Managern etwas zum Prüfen.

Derselbe Standard gilt für Felder. „Churn-Grund ist, warum der Kunde gegangen ist" reicht nicht. Der Eintrag sollte festhalten, ob es sich um Logo-Churn oder Umsatz-Churn handelt, wer ihn zuweist, wann er zugewiesen wird, welche Werte zulässig sind und wie er im Reporting genutzt wird.

Kritische Einträge

Beginnen Sie mit Einträgen, die Entscheidungen beeinflussen:

• Lead-Quelle
• Lifecycle-Stufe
• MQL
• SQL
• Opportunity
• Qualified Pipeline
• Forecast-Kategorie
• Commit
• Best Case
• Closed-Won
• ARR
• Bookings
• Verlängerungsdatum
• Churn-Grund
• Expansionssignal
• Kundengesundheit

Versuchen Sie nicht, zuerst jedes obskure Feld zu dokumentieren. Beginnen Sie mit den Feldern, die in Führungsmeetings auftauchen.

Zulässige Werte

Auswahllisten brauchen Governance.

Werte für den Churn-Grund sollten beispielsweise spezifisch genug sein, um handlungsfähig zu sein:

• Schlechte Passung
• Fehlendes Feature
• Kein Budget
• Schlechtes Onboarding
• Kein Executive Sponsor
• Geringe Nutzung
• Wettbewerber
• Geschäft geschlossen

Ist die Liste zu vage, kann das Reporting keine Handlung antreiben. Ist sie zu detailliert, wählen Nutzer den falschen Wert oder greifen standardmäßig auf „Sonstiges" zurück.

Pflichtfelder

Das Dictionary sollte erklären, warum ein Feld verpflichtend ist.

Verknüpfen Sie die Anforderung mit Entscheidungen:

• Routing
• Qualifizierung
• Forecast
• Übergabe
• Abrechnung
• Compliance
• Verlängerung
• Expansion
• Board-Reporting

Hängt keine Entscheidung vom Feld ab, mag es nützlich sein, muss aber nicht verpflichtend sein.

Dictionary-Workflow

Fordert ein Team ein neues Feld oder eine neue Kennzahl an:

1. Die geschäftliche Frage definieren.
2. Owner und Source of Truth identifizieren.
3. Zulässige Werte festlegen.
4. Die Pflicht-Stufe festlegen.
5. Betroffene Reports identifizieren.
6. Über Governance genehmigen oder ablehnen.
7. Eintrag zum Dictionary hinzufügen.
8. Die Änderung kommunizieren.

Das verknüpft das Dictionary mit Required Fields vs Useful Fields.

Minimal tragfähiges Dictionary

Das erste nützliche Dictionary kann klein sein. Es muss nicht jedes CRM-Feld abdecken.

Beginnen Sie mit 20 bis 30 Einträgen in vier Gruppen:

Diese erste Version sollte gut genug sein, um gängige Streitfragen zu klären. Streiten Führungskräfte über Quellattribution, Forecast-Kategorien, die SQL-Definition, Churn-Gründe oder Pipeline-Qualität, sollte das Dictionary die Frage beantworten oder die fehlende Governance aufzeigen.

Beginnen Sie nicht mit selten genutzten Feldern. Das erzeugt Dokumentationsarbeit mit geringer Adoption. Beginnen Sie dort, wo Verwirrung bereits teuer ist.

Change Control

Definitionen ändern sich. Das Problem ist stille Veränderung.

Jede bedeutsame Änderung sollte enthalten:

• Alte Definition
• Neue Definition
• Grund
• Wirksamkeitsdatum
• Betroffene Reports
• Historische Auswirkung
• Genehmigender Owner

Das hilft Führungskräften, Trends korrekt zu interpretieren.

Adoption

Ein Dictionary, das niemand nutzt, ist reine Dokumentation.

RevOps sollte das Dictionary verknüpfen mit:

• Dashboard-Tooltips
• CRM-Feldbeschreibungen
• Onboarding
• Manager-Schulung
• Systems Governance
• Executive-Reporting
• Audit-Checklisten

Das Dictionary sollte während der echten Arbeit leicht auffindbar sein.

Häufige Fehler

Zu früh zu viel dokumentieren. Teams werden überfordert.

Kein Owner pro Eintrag. Definitionen verfallen.

Keine Änderungshistorie. Trendänderungen werden verwirrend.

Nur technische Sprache. Geschäftsanwender verstehen das Feld nicht.

Dictionary vom CRM getrennt. Nutzer sehen an verschiedenen Stellen unterschiedliche Hinweise.

Checkliste für Einsatzbereitschaft

Vor dem Start:

• Kritische Einträge sind dokumentiert.
• Owner sind benannt.
• Source-of-Truth-Regeln sind enthalten.
• Zulässige Werte sind aktuell.
• Pflichtfelder haben geschäftliche Gründe.
• Der Änderungsprozess ist klar.
• Dashboard-Definitionen verlinken zurück auf das Dictionary.

Das Dictionary funktioniert, wenn ein Streit über eine Kennzahl durch das Öffnen des Eintrags gelöst werden kann, nicht durch Nachfragen.

Beispieleinträge

Beispiel: Lead-Quelle

Beispiel: Commit

Beispiele machen das Dictionary leichter adoptierbar.

Dictionary und Onboarding

Nutzen Sie das Dictionary im Onboarding für RevOps, Sales, Marketing, CS und Finance.

Neue Mitarbeitende sollten lernen:

• Was Lifecycle-Stufen bedeuten
• Welche Felder wichtig sind
• Welche Definitionen gemeinsam gelten
• Welche Reports Source of Truth sind
• Wer Änderungen besitzt

Das reduziert stillschweigendes Erfahrungswissen.

Pflege des Dictionary

Überprüfen Sie das Dictionary monatlich für Felder mit hoher Änderungsrate und vierteljährlich für das größere Modell.

Auslöser für die Überprüfung:

• Neue Feldanfrage
• Dashboard-Streit
• Änderung der Forecast-Definition
• Neue GTM-Bewegung
• CRM-Migration
• Integrationsänderung
• Änderung der Finanzplanung

Das Dictionary sollte sich ändern, wenn sich das Geschäft ändert, aber Änderungen sollten sichtbar sein.

Abschaffung von Feldern

Ein Dictionary sollte auch helfen, Felder abzuschaffen.

Schaffen Sie ein Feld ab, wenn:

• Kein Report es nutzt.
• Kein Workflow davon abhängt.
• Die Datenqualität zu schlecht ist, um sie zu reparieren.
• Ein besseres Feld es ersetzt.
• Die geschäftliche Frage nicht mehr relevant ist.

Die Abschaffung von Feldern hält das CRM nutzbar.

Qualitätskennzahlen

Verfolgen Sie die Gesundheit des Dictionary:

• Prozentsatz dokumentierter kritischer Felder
• Prozentsatz kritischer Felder mit Owner
• Felder mit unklaren zulässigen Werten
• Kennzahlen ohne Formel
• Diese Quartal geänderte Definitionen
• Mit dem Dictionary verknüpfte Dashboard-Kennzahlen

Diese Kennzahlen zeigen, ob das Dictionary ein operatives Asset ist.

Qualitätsregel

Das Dictionary sollte nah an der Arbeit liegen. Müssen Nutzer nach Definitionen suchen, fragen sie Kollegen, raten oder erstellen eine lokale Definition. RevOps sollte die offizielle Definition leichter auffindbar machen als die inoffizielle.

Reihenfolge des Aufbaus

Bauen Sie das Dictionary in Phasen auf.

Phase 1: Executive-Kennzahlen.

Dokumentieren Sie Umsatz-, Pipeline-, Forecast-, Konversions-, Retention-, Expansions- und Datenqualitätskennzahlen, die in Führungsmeetings genutzt werden.

Phase 2: Lifecycle-Felder.

Dokumentieren Sie Lifecycle-Stufe, Lead-Status, Opportunity-Stufe, Forecast-Kategorie, Verlängerungsstatus und Expansionsstatus.

Phase 3: Workflow-Felder.

Dokumentieren Sie Owner, SLA, Routing, Übergabe, Risiko, Ablehnung und Closed-Lost-Felder.

Phase 4: Bereinigung und Abschaffung.

Entfernen oder markieren Sie Felder, die keine Entscheidungen mehr unterstützen.

Governance-Rollen

Das Dictionary braucht Rollen:

Ohne Rollen verfällt das Dictionary.

Verbindung zu Dashboards

Jede Executive-Dashboard-Kennzahl sollte auf einen Dictionary-Eintrag zurückverlinken.

Der Eintrag sollte erklären:

• Formel
• Quelle
• Zeitfenster
• Ausschlüsse
• Aktualisierungsrhythmus
• Owner
• Vorbehalte

Das macht Dashboards leichter verteidigbar und leichter zu reparieren.

Verbindung zum CRM

CRM-Feldbeschreibungen sollten mit den Dictionary-Definitionen übereinstimmen.

Sagt das Dictionary etwas anderes als der CRM-Tooltip, folgen Nutzer dem Tool vor sich. RevOps sollte Dictionary und CRM-Hinweise aufeinander abgestimmt halten.

Beispiele für schlechte Definitionen

Schlechte Definition: „Qualified Pipeline ist gute Pipeline."

Bessere Definition: „Qualified Pipeline ist der Wert offener Opportunities, die voraussichtlich in der ausgewählten Periode abgeschlossen werden, deren Opportunity-Stufe qualifiziert oder weiter ist, deren Betrag befüllt ist, deren Abschlussdatum aktuell ist und bei denen ausgeschlossene Stufen entfernt wurden."

Schlechte Definition: „Churn-Grund ist, warum der Kunde gegangen ist."

Bessere Definition: „Churn-Grund ist der primäre kunden-, produkt-, kommerzielle oder Passungsgrund, der beim Churn-Review anhand genehmigter Werte zugewiesen und von CS mit RevOps-Governance verantwortet wird."

Spezifische Definitionen reduzieren Interpretationsspielraum.

Checkliste zur Bereinigung von Definitionen

Vor dem Start:

• Kritische Felder sind dokumentiert.
• Executive-Kennzahlen sind dokumentiert.
• Die CRM-Feldhilfe ist abgestimmt.
• Owner sind benannt.
• Ein Änderungsprotokoll existiert.
• Alte Definitionen sind archiviert.
• Nutzer wissen, wo sie das Dictionary finden.

Das Dictionary ist ausgereift, wenn Teams es nutzen, bevor sie ein neues Feld oder Dashboard erstellen.

Praktische Warnung

Ein Dictionary kann schnell veralten, wenn es als reines Dokumentationsprojekt behandelt wird.

Verknüpfen Sie es mit aktiven Workflows:

• Neue Feldanfragen erfordern einen Dictionary-Eintrag.
• Dashboard-Kennzahlen erfordern Dictionary-Definitionen.
• Änderungen der Forecast-Kategorie aktualisieren das Dictionary.
• Pflichtfelder brauchen dokumentierte geschäftliche Gründe.
• Abgeschaffte Felder werden mit Datum markiert.

Das macht das Dictionary zum Teil der Governance statt zum nachträglichen Gedanken.

Praxisbeispiele zur praktischen Warnung

Bittet eine Sales-Führungskraft um ein neues Pflichtfeld namens „Deal-Qualität", sollte RevOps es nicht sofort erstellen. Der Dictionary-Prozess sollte fragen: Was bedeutet Deal-Qualität, wer besitzt sie, welche Werte sind zulässig, wo ist sie verpflichtend, welcher Report nutzt sie und welche Aktion folgt daraus?

Fragt Finance nach „Qualified Pipeline", sollte RevOps die genaue Formel dokumentieren, bevor das Dashboard gebaut wird. Enthält sie Stufe 1? Enthält sie Verlängerungen? Schließt sie Abschlussdaten außerhalb des Quartals aus? Nutzt sie einen gewichteten oder ungewichteten Betrag?

Fragt CS nach Churn-Gründen, sollte RevOps zulässige Werte definieren, die Verhalten verändern können. Ein vager Wert wie „nicht genug Wert" braucht möglicherweise Unterkategorien zu Adoption, Onboarding, Produktpassung oder Executive Sponsorship.

Adoptionsregel der praktischen Warnung

Das Dictionary sollte gute Daten leichter machen als schlechte Daten. Ist die offizielle Definition schwer zu finden, erfinden Nutzer lokale Definitionen. Passen die zulässigen Werte nicht zur echten Arbeit, wählen Nutzer „Sonstiges". Dauern Änderungen zu lange, umgehen Teams die Governance.

RevOps sollte das Dictionary praktisch, sichtbar und an Entscheidungen geknüpft halten.

Risiko-Checkliste

Testen Sie das Dictionary vor dem Rollout gegen gängige Anfragen:

• Ein neues Pflichtfeld
• Eine neue Dashboard-Kennzahl
• Ein Streit über eine Forecast-Definition
• Eine Bereinigung von Churn-Gründen
• Eine Frage zur Quellattribution
• Eine Board-Reporting-Kennzahl

Für jede Anfrage sollte das Dictionary Definition, Owner, Quelle, zulässige Werte, Pflichtnutzung und betroffene Reports zeigen. Kann es das nicht, ergänzen Sie den fehlenden Eintrag, bevor Sie den Prozess skalieren.

Praktische Regel

Das Dictionary sollte Interpretationsspielraum reduzieren. Ein Sales-Manager, ein Marketer, ein CS-Leiter, ein Finance-Partner und ein RevOps-Analyst sollten denselben Eintrag lesen und dieselbe geschäftliche Bedeutung verstehen.

Diese gemeinsame Sprache macht Revenue-Reporting und Workflows vertrauenswürdiger.

Das Dictionary sollte Teams auch helfen, Nein zu sagen. Hat ein angefragtes Feld keinen Owner, keine Source of Truth, keine zulässigen Werte und keinen Report oder Workflow, der davon abhängt, sollte RevOps es ablehnen oder zurückstellen. Diese Disziplin verhindert, dass sich das CRM mit Feldern füllt, die mehr Arbeit als Wert erzeugen.

Dasselbe gilt für Kennzahlen. Lässt sich eine Kennzahl nicht klar genug für das Dictionary definieren, ist sie nicht bereit für das Executive-Reporting.

Nutzen Sie das Dictionary als Qualitäts-Gate. Bevor ein Feld verpflichtend wird, bevor eine Kennzahl das Board erreicht und bevor ein Workflow von einem Wert abhängt, sollte die Definition klar genug für die Menschen sein, die die Daten eingeben und nutzen.

So wird aus einem Dictionary echte operative Kontrolle statt bloßer Dokumentation. Es schützt Dashboards, Routing, Forecast, Verlängerungsplanung, Kundenübergaben und Führungsreporting, weil jeder abhängige Prozess auf eine klare Definition zurückverweist.

Die Kosten von Drift sind hoch. Ein Feld, das in Marketing mit einer Bedeutung beginnt, in Sales mit einer anderen und in Finance mit einer dritten, wird irgendwann drei widersprüchliche Reports erzeugen. Dann ist die Bereinigung nicht nur technisch. Führungskräfte müssen das Vertrauen in die Zahlen wiederaufbauen. Ein aktuelles Dictionary verhindert diese vermeidbare Arbeit.

So machen Sie das Dictionary sichtbar

Die Adoption verbessert sich, wenn das Dictionary dort auftaucht, wo Menschen bereits arbeiten.

Nutzen Sie mehrere Oberflächen:

Das Dictionary sollte Menschen nicht dazu zwingen, während der aktiven Arbeit ein Wiki zu durchsuchen. Die vollständige Version kann in einem governten Dokument liegen, aber die kurze Definition sollte innerhalb von CRM, Dashboard oder Prozess erscheinen, wo der Nutzer sie braucht.

So verdient sich RevOps auch Compliance ohne starke Durchsetzung. Ist die offizielle Definition leichter zu finden als die inoffizielle, nutzen Menschen sie eher.

Audit des Data Dictionary

Sobald die erste Version live ist, prüfen Sie sie gegen die tatsächliche Arbeit. Das Audit sollte nicht fragen, ob das Dokument vollständig ist. Es sollte fragen, ob das Dictionary Verwirrung bei wichtigen Entscheidungen reduziert.

Nutzen Sie ein praktisches Audit:

Das Audit findet oft drei Arten von Lücken.

Erstens fehlende Einträge. Eine Kennzahl taucht in Führungsmeetings auf, hat aber keine Definition. Ergänzen Sie sie vor dem nächsten Reportzyklus.

Zweitens schwache Einträge. Der Eintrag existiert, beantwortet aber nicht genug Fragen. „Pipeline-Quelle" muss beispielsweise ursprüngliche Quelle, letzte Quelle, Opportunity-Quelle und Kampagneneinfluss klären.

Drittens Adoptionslücken. Der Eintrag ist klar, aber Nutzer sehen ihn während der Arbeit nicht. In diesem Fall liegt die Lösung eher in CRM-Hilfetext, Dashboard-Tooltip, Manager-Schulung oder Feldbereinigung als in mehr Dokumentation.

Das Audit sollte eine kurze Aktionsliste erzeugen. Machen Sie daraus kein vollständiges Datenbereinigungsprogramm, es sei denn, die Evidenz rechtfertigt diesen Umfang. Die besten Audits verbessern das Dictionary und zeigen zugleich, wo Workflow, Reporting oder Governance repariert werden müssen.

Praxisbeispiele

So verändert ein Dictionary gängige RevOps-Gespräche.

Eine Sales-Führungskraft bittet um ein Pflichtfeld „Entscheider". RevOps prüft den Dictionary-Standard, bevor das Feld erstellt wird. Was bedeutet Entscheider? Ist es der Economic Buyer, der Executive Sponsor, die Unterschriftsbefugnis oder ein Meeting-Teilnehmer? In welcher Stufe ist es verpflichtend? Welcher Report oder Workflow nutzt es? Ist die Antwort unklar, ist die Feldanfrage nicht bereit.

Finance fragt, warum sich die Qualified Pipeline seit letztem Monat verändert hat. RevOps öffnet den Eintrag zu Qualified Pipeline. Hat sich die Definition geändert, sollte die Änderungshistorie Wirksamkeitsdatum, Owner und historische Auswirkung zeigen. Hat sich die Definition nicht geändert, prüft das Team die Quelldaten: Stufenbewegung, Änderungen am Abschlussdatum, ausgeschlossene Datensätze, Betragsänderungen und neu erstellte Opportunities.

CS möchte bessere Churn-Gründe. RevOps vermeidet es, sofort zwanzig Werte hinzuzufügen. Der Dictionary-Prozess beginnt mit der geschäftlichen Frage: Welche Churn-Gründe würden Akquisition, Onboarding, Produkt, Pricing oder Kundenbindung verändern? Werte, die keine Handlung verändern, bleiben aus der Auswahlliste draußen.

Marketing möchte ein neues Attributions-Dashboard. RevOps prüft zuerst die Quelldefinitionen. Sind ursprüngliche Quelle, letzte Quelle, Kampagne und Opportunity-Quelle nicht definiert, macht ein neues Dashboard Uneinigkeit nur sichtbarer. Die Dictionary-Arbeit kommt vor dem Report-Bau.

Diese Beispiele zeigen den eigentlichen Zweck des Dictionary. Es hilft Teams, innezuhalten, bevor sie Verwirrung in Systeme codieren.

Änderungspaket für das Data Dictionary

Jede wichtige Feldänderung sollte das Data Dictionary aktualisieren.

Erfassen Sie:

• Feldname.
• Definition.
• Quellsystem.
• Zulässige Werte.
• Owner.
• Pflicht-Stufe.
• Betroffene Reports.
• Betroffene Workflows.
• Änderungsdatum.
• Abschaffungsregel.

Das verhindert, dass das Dictionary zu veralteter Dokumentation wird. Es sollte die Kontrolloberfläche für Revenue-Daten sein, kein Archiv, dem niemand vertraut.

FAQ

Wer besitzt das Revenue Data Dictionary?

RevOps sollte es besitzen, mit fachlichem Input auf Feldebene von Marketing, Sales, CS, Finance und System-Ownern.

Wo sollte es liegen?

An einem sichtbaren, ausreichend versionskontrollierten Ort, an dem Menschen aktuelle Definitionen finden können. Das Format ist weniger wichtig als die Adoption.

Mehr erfahren

• Source of Truth for Revenue Data
• CRM Data Hygiene
• RevOps Metrics
• Lead to Revenue Attribution