Abonniere den Blog und erhalte wertvolles Wissen und praktische Tipps rund um Customer Intelligence ✨
Montagmorgen, kurz vor neun. Irgendwo im Mittelstand öffnet jemand aus dem frisch gegründeten RevOps-Team drei Browser-Tabs und ein Excel. Aus dem CRM kommt die Pipeline, aus der Marketing Automation kommen die Leads, aus dem ERP kommen die Umsätze. Alle drei Exporte haben unterschiedliche Kundennamen für denselben Kunden. Also beginnt die eigentliche Arbeit der Woche: sortieren, abgleichen, per Hand zusammenfügen. Das Ergebnis heißt Revenue-Report und ist am Freitag schon wieder veraltet.
RevOps sollte das Gegenteil davon sein. Es sollte Marketing, Vertrieb und Finance auf eine gemeinsame Datenbasis stellen und den gesamten Umsatzprozess durchgängig steuerbar machen. Stattdessen entsteht in vielen Mittelständlern eine gut gemeinte Reporting-Abteilung, die ihre Zeit damit verbringt, Silos von Hand zu übersetzen.
Die Idee hinter Revenue Operations ist bestechend einfach. Marketing, Vertrieb und Finance verfolgen dasselbe Ziel, nämlich Umsatz, arbeiten aber mit getrennten Zahlen, getrennten Definitionen und getrennten Systemen. RevOps soll diese drei Funktionen operativ zusammenführen: gemeinsame Kennzahlen, ein gemeinsames Verständnis vom Kunden, abgestimmte Entscheidungen über den gesamten Umsatzprozess hinweg.
In der Theorie ist RevOps damit eine Steuerungsfunktion. Sie steht über den Silos und orchestriert sie. In der mittelständischen Praxis kippt diese Rolle jedoch fast unmerklich. Wer keine verbundene Datenbasis hat, kann nicht steuern, sondern nur berichten. Und wer berichten muss, aber keine fließenden Daten bekommt, sammelt sie eben ein. Von Hand.
So wird aus der geplanten Steuerungsfunktion eine Übersetzungsfunktion. Das RevOps-Team wird zum menschlichen Bindeglied zwischen Systemen, die nicht miteinander reden. Das ist keine Frage von Kompetenz oder Fleiß. Es ist eine Frage der Infrastruktur, die unter der Funktion fehlt.
Wer keine verbundene Datenbasis hat, kann nicht steuern, sondern nur berichten.
Konzerne lösen dieses Problem mit einer Integrationsabteilung und einem Budget, das eigene Data Engineers trägt. Der Mittelstand hat beides selten. Er hat gewachsene Systeme, oft über Jahre einzeln angeschafft, und ein kleines Team, das alles gleichzeitig macht. Genau hier entstehen drei Bruchstellen, die jede RevOps-Initiative ausbremsen.
Die erste: Marketing Automation und CRM leben nebeneinander, nicht miteinander. Ein Lead klickt sich durch fünf E-Mails, lädt zwei Whitepaper herunter und bucht ein Webinar. Im Vertrieb sieht davon niemand etwas, weil dieses Verhalten im Marketing-Tool bleibt. Der Vertriebler ruft einen scheinbar kalten Kontakt an, der in Wahrheit seit Wochen kaufbereit ist.
Die zweite: Die Umsatzdaten aus dem ERP fehlen im CRM. Das CRM kennt die Opportunity bis zum Abschluss und verliert danach den Faden. Ob aus dem 50.000-Euro-Deal am Ende 50.000 Euro Umsatz wurden oder nach Retouren und Gutschriften nur 38.000, weiß nur die Buchhaltung. Forecast und Realität driften auseinander, ohne dass es jemand merkt.
Die dritte, und die tückischste: Es gibt keinen einheitlichen Kundenstamm über die Systeme hinweg. Dieselbe Firma heißt im CRM „Müller GmbH“, im ERP „Mueller GmbH & Co. KG“ und im Shop „mueller-gmbh“. Solange niemand entscheidet, welcher dieser Einträge der richtige ist, lässt sich keine Kennzahl systemübergreifend verlässlich zusammenführen.
Diese drei Bruchstellen haben eine gemeinsame Ursache. Sie sind kein Organisationsproblem, das eine weitere Rolle im Orgchart lösen würde. Sie sind ein Datenproblem. Und ein Datenproblem lässt sich nicht durch eine Person beheben, die tapfer jeden Montag Exporte zusammenkopiert.
Hier lohnt ein Perspektivwechsel. Die meisten RevOps-Debatten drehen sich um Zuständigkeiten, Prozesse und Playbooks. Wer ownt den Funnel? Welche Definition von einem Marketing Qualified Lead gilt? Wichtige Fragen, aber sie behandeln die zweite Etage, während im Keller das Wasser steht.
Denn die entscheidende Voraussetzung liegt tiefer. RevOps funktioniert genau dann, wenn Daten zwischen den Systemen fließen, statt manuell transportiert zu werden. Wenn das Marketing-Verhalten im CRM sichtbar ist. Wenn der ERP-Umsatz neben der Opportunity steht. Wenn ein Golden Record definiert, welcher von drei widersprüchlichen Firmennamen gilt. Dann entsteht die durchgängige Steuerbarkeit, die RevOps verspricht, fast von selbst.
Ein Golden Record ist übrigens kein Datensatz, den man findet. Er ist eine Entscheidung. Wenn drei Systeme drei Versionen derselben Firma führen, legt der Golden Record fest, welche Version gewinnt und woraus sich die verlässlichen Attribute zusammensetzen. Erst diese Entscheidung macht aus drei Fragmenten einen Kunden, über den sich rechnen lässt.
Das verschiebt die Reihenfolge. RevOps ist dann nicht die Funktion, die man einstellt, um Daten zusammenzuführen. Es ist die Steuerungsfunktion, die entsteht, sobald die Daten bereits zusammengeführt sind. Die Organisation kommt nach der Infrastruktur, nicht davor.
Man kann diesen Gedanken zu weit treiben, und ehrlicherweise tun das manche Anbieter. Datenintegration allein macht noch kein funktionierendes RevOps. Wenn Marketing und Vertrieb sich nicht einigen, was ein qualifizierter Lead ist, dann sind sie sich anschließend eben in Echtzeit uneinig. Das Tool beschleunigt den Streit, es beendet ihn nicht.
Die inhaltliche Abstimmung bleibt Handarbeit. Gemeinsame Definitionen, ein geteiltes Verständnis vom Umsatzprozess, klare Übergaben zwischen den Teams: das entsteht in Gesprächen, nicht in einem Mapping. Wer glaubt, eine Integration ersetze diese Arbeit, wird enttäuscht.
Aber die Reihenfolge bleibt trotzdem eindeutig. Ohne fließende Daten scheitert selbst die beste organisatorische Abstimmung an der Umsetzung, weil niemand die vereinbarten Kennzahlen sauber messen kann. Datenintegration ist keine hinreichende Bedingung für RevOps. Sie ist die notwendige. Und eine notwendige Bedingung zu ignorieren, weil sie nicht hinreichend ist, war noch nie ein guter Plan.
Wird der Umsatzprozess zu einem durchgängigen Datenfluss, ändern sich drei Dinge auf einmal. Attribution wird bis zum tatsächlichen Umsatz messbar, nicht nur bis zum Klick oder zum Abschluss. Forecast baut auf konsolidierten Zahlen auf, statt auf einer optimistischen Momentaufnahme im CRM. Und der gesamte Weg vom Lead bis zur Rechnung wird als ein Prozess sichtbar, nicht als eine Kette getrennter Systemabschnitte.
Genau hier setzt eine Plattform wie MARINI an, die Plattform für Customer Intelligence mit Data Integration, Data Cloud und Agentic. In der Phase Data Integration verbindet MARINI die beteiligten Systeme bidirektional und in Echtzeit, sodass Marketing-Verhalten, Vertriebspipeline und ERP-Umsatz nicht mehr in getrennten Welten liegen. In der Data Cloud führt die Plattform diese Daten zusammen, dedupliziert sie und bildet Golden Records, damit „Müller GmbH“, „Mueller GmbH & Co. KG“ und „mueller-gmbh“ endlich als ein Kunde gerechnet werden.
Der Effekt ist unspektakulär und genau deshalb wertvoll. Der Montags-Report entsteht nicht mehr durch drei Exporte und ein Excel, sondern liegt bereits konsolidiert vor. Das RevOps-Team hört auf, Daten zu transportieren, und beginnt, mit ihnen zu arbeiten. Wer den durchgängigen Datenweg vom Lead bis zur Rechnung als Fundament versteht, sieht schnell, wie viel RevOps-Arbeit vorher reine Datenlogistik war.
Bleibt die Frage, was ein Mittelständler daraus mitnimmt, bevor er die nächste RevOps-Stelle ausschreibt. Die ehrlichste Antwort ist eine Reihenfolge, keine Rollenbeschreibung.
Fällt eine dieser Antworten negativ aus, wird die neue RevOps-Rolle einen Teil ihrer Woche mit Excel verbringen, egal wie fähig die Person ist. Nicht weil sie es will, sondern weil die Infrastruktur sie dazu zwingt.
RevOps ohne Datenintegration ist ein Team, das Tabellen baut. RevOps mit Datenintegration ist eine Funktion, die den Umsatzprozess vom ersten Klick bis zur bezahlten Rechnung steuert. Der Unterschied liegt nicht im Orgchart. Er liegt darin, ob die Daten am Montagmorgen schon miteinander verbunden sind oder ob es wieder jemand von Hand tun muss.
Mehr dazu findest du im Fachbuch Customer Intelligence: Strategien und Use Cases zur Nutzung von Kundendaten von Prof. Dr. Emanuel Bayer und Manuel Marini, das über Springer Gabler publiziert wurde.
