Data Ownership im CRM: Wer ist wirklich verantwortlich?

Warum Datenqualität kein technisches Problem ist

Data Ownership im CRM bedeutet, dass für jedes wichtige Datenfeld, jeden Pflegeprozess und jede Aktualisierungsroutine eine Person oder Rolle eindeutig benannt ist, die für Qualität und Aktualität verantwortlich ist. Ohne diese Zuordnung bleiben auch ausgefeilte Validierungsregeln, Pflichtfelder und Deduplizierungs-Workflows wirkungslos, weil sie zwar eine Eingabe erzwingen, aber nicht deren Richtigkeit.

In vielen Unternehmen gilt Datenqualität als IT-Thema. Ein neues Tool soll Duplikate zusammenführen, ein Workflow soll fehlende Felder automatisch nachtragen, eine Integration soll Daten zwischen Systemen abgleichen. Diese Maßnahmen helfen an einzelnen Stellen, sie lösen aber nicht das eigentliche Problem. Wenn niemand im Vertrieb dafür zuständig ist, die Branche eines Kontakts zu pflegen, bleibt das Feld leer, unabhängig davon, wie viele Automatisierungen im Hintergrund laufen. Wenn niemand im Marketing prüft, ob Leadquellen korrekt zugeordnet werden, verzerren sich Reportings über Monate, bevor es überhaupt auffällt.

Der Unterschied zwischen einem CRM mit guter Datenqualität und einem CRM mit chronischen Datenproblemen liegt selten am Funktionsumfang der Software. Er liegt daran, ob jemand die Verantwortung für die Daten tatsächlich übernommen hat, und ob diese Verantwortung dokumentiert, kommuniziert und überprüft wird.

Wer ist eigentlich für welches Datenfeld verantwortlich?

Diese Frage lässt sich in der Praxis selten mit der IT oder dem CRM-Team beantworten. Verantwortung für Daten verteilt sich über mehrere Rollen mit unterschiedlichen Aufgaben und unterschiedlicher Nähe zum Tagesgeschäft. Wer festlegt, welche Werte ein Feld annehmen darf, ist eine andere Person als die, die täglich Datensätze pflegt. Und wer die technische Umsetzung verantwortet, ist wieder eine dritte Rolle.

Ein praxistaugliches Rollenmodell unterscheidet deshalb zwischen fachlicher Entscheidung, operativer Pflege und technischer Umsetzung. Erst wenn alle drei Ebenen besetzt und aufeinander abgestimmt sind, funktioniert Data Ownership dauerhaft, nicht nur für ein paar Wochen nach einem Kickoff-Workshop.

Data Owner, Data Steward, System Owner: die drei Rollen im Detail

Data Owner treffen die fachlichen Entscheidungen. Sie legen fest, welche Felder Pflicht sind, welche Werte in einem Dropdown zulässig sind und wie zum Beispiel ein Lead-Status oder ein Deal-Stage-Übergang definiert ist. In der Praxis übernehmen diese Rolle meist Fachbereichsleitungen, etwa Head of Marketing, Head of Sales oder Head of Customer Success, teilweise auch RevOps-Verantwortliche mit Blick über mehrere Teams hinweg.

Data Steward übernehmen die operative Pflege. Sie korrigieren fehlerhafte Datensätze, räumen Duplikate auf und melden Auffälligkeiten an den Data Owner zurück, etwa wenn ein Pflichtfeld regelmäßig mit Platzhaltern befüllt wird, weil die Auswahlliste in der Praxis nicht passt. Diese Rolle liegt oft bei Teammitgliedern mit hoher Systemnutzung, etwa einem Marketing-Operations-Manager oder einem erfahrenen Vertriebsmitarbeiter.

System Owner verantworten die technische Seite. Sie verwalten Berechtigungen, Integrationen und Automatisierungen und sorgen dafür, dass die fachlichen Vorgaben der Data Owner technisch korrekt abgebildet werden. Diese Rolle liegt häufig bei internen CRM-Administratoren oder bei externen Fachleuten, die die Systemarchitektur betreuen.

Wichtig ist die Trennung: Der Data Owner entscheidet, was gelten soll. Der Data Steward sorgt dafür, dass es im Alltag auch so gelebt wird. Der System Owner stellt sicher, dass das System diese Vorgaben technisch überhaupt zulässt und abbildet.

Wie Verantwortlichkeiten in Marketing, Sales und Service verteilt werden

In der Praxis zeigt sich das Modell am deutlichsten, wenn man es auf einzelne Teams herunterbricht.

Im Marketing definiert der Head of Marketing als Data Owner, welche Felder für die Leadquelle und die Kampagnen-Zuordnung Pflicht sind. Der Marketing-Operations-Manager als Data Steward prüft wöchentlich neu eingehende Leads auf korrekte Zuordnung und meldet systematische Lücken zurück. Der CRM-Administrator als System Owner pflegt die entsprechenden Properties, Formulare und Automatisierungen im System.

Im Vertrieb legt der Head of Sales fest, welche Deal-Felder für einen belastbaren Forecast zwingend nötig sind, etwa Abschlusswahrscheinlichkeit, erwartetes Volumen oder nächster Schritt. Die Teamleitung übernimmt die Rolle des Data Stewards und prüft diese Felder im wöchentlichen Pipeline-Meeting stichprobenartig. RevOps oder ein externer CRM-Berater sorgt als System Owner dafür, dass Pflichtfelder und Validierungen im System korrekt hinterlegt sind.

Im Service definiert der Head of Customer Success, welche Ticket-Kategorien und Eskalationsfelder für saubere Auswertungen notwendig sind. Die Teamleitung im Support pflegt als Data Steward die laufende Qualität, etwa bei der Kategorisierung wiederkehrender Anfragen. Die IT oder ein CRM-Administrator setzt die technischen Vorgaben um.

Bei Feldern, die mehrere Teams gemeinsam nutzen, etwa Firmendaten oder Kontaktinformationen, braucht es einen benannten Owner über Teamgrenzen hinweg, sonst pflegt am Ende niemand das Feld, weil sich jede Abteilung auf die andere verlässt.

Governance verankern: von der Rollenidee zur gelebten Praxis

Ein Rollenmodell auf einer Folie reicht nicht aus. Ohne Dokumentation und Wiederholung verpufft die Idee spätestens ein paar Wochen nach dem Kickoff-Workshop. In der Praxis hat sich ein einfacher Datenkatalog bewährt: Für jedes geschäftskritische Feld wird schriftlich festgehalten, wer Data Owner, wer Data Steward und wer System Owner ist, und in welchem Rhythmus die Zuständigkeit überprüft wird.

Ein quartalsweiser Review reicht in den meisten Fällen aus. Dabei wird geprüft, ob die benannten Personen noch aktuell sind, ob sich die Feldnutzung verändert hat und ob es neue Datenquellen gibt, die eine Zuordnung brauchen. Diese Reviews lassen sich gut mit der ohnehin nötigen Pflege eines RevOps-Datenmodells verbinden, weil beide auf derselben Grundlage aufbauen: einer klaren, dokumentierten Struktur statt informeller Absprachen.

Wichtig ist außerdem, sich nicht auf ein einzelnes System als Lösung zu verlassen. Die Vorstellung, eine einzige zentrale Datenbank würde automatisch für saubere Daten sorgen, hält der Praxis meist nicht stand, wie der Artikel zum Mythos der Single Source of Truth zeigt. Auch das technisch sauberste System bleibt auf Menschen angewiesen, die Verantwortung für die Inhalte übernehmen.

Für Entscheider heißt das konkret: Bevor über neue Tools, KI-Funktionen oder zusätzliche Integrationen nachgedacht wird, lohnt sich die Frage, ob für die bestehenden Datenfelder überhaupt klare Verantwortlichkeiten existieren. Häufig zeigt sich dabei, dass die größten Datenqualitätsprobleme nicht an fehlender Technik liegen, sondern an einer Rollenverteilung, die nie schriftlich fixiert wurde.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Data Owner und Data Steward?

Der Data Owner trifft fachliche Entscheidungen, etwa welche Felder Pflicht sind und welche Werte zulässig sind. Der Data Steward setzt diese Vorgaben im Tagesgeschäft um, korrigiert fehlerhafte Datensätze und meldet Auffälligkeiten zurück.

Muss jedes Unternehmen alle drei Rollen einzeln besetzen?

Nein. In kleineren Teams können mehrere Rollen bei derselben Person liegen, etwa wenn eine Marketing-Leitung sowohl Data Owner als auch Data Steward ist. Wichtig ist nicht die Anzahl der Personen, sondern dass die drei Aufgaben, fachliche Entscheidung, operative Pflege und technische Umsetzung, jeweils klar zugeordnet sind.

Wie oft sollten Verantwortlichkeiten überprüft werden?

Ein quartalsweiser Review hat sich in der Praxis bewährt. Bei größeren organisatorischen Veränderungen, etwa einem Teamumbau oder der Einführung eines neuen Hubs, lohnt sich zusätzlich eine kurzfristige Überprüfung.

Was passiert, wenn Data Ownership nicht klar geregelt ist?

Datenfelder veralten, Duplikate häufen sich, und Reportings verlieren an Aussagekraft, ohne dass jemand sich zuständig fühlt, das Problem zu beheben. Technische Maßnahmen wie Automatisierungen oder Validierungsregeln mildern die Symptome, beheben aber nicht die Ursache.