Customer Relationship Management (CRM) beschäftigt sich mit dem strategischen Ansatz, alle interaktiven Prozesse mit dem Kunden vollständig zu planen, zu steuern und durchzuführen (Gabler Wirtschaftslexikon). CRM-Systeme sind Softwareprodukte, die ein Unternehmen nutzt, um dieses Kundenbeziehungsmanagement zu unterstützen. Sie werden unter anderem dafür eingesetzt Marketing-Kampagnen zu steuern und den Vertrieb zu standardisieren. Für diese Aktivitäten ist eine umfassende Datenbasis erforderlich, über die die Informationen der Kunden und unternehmensseitige Daten zusammengefasst sind.
Der folgende Beitrag befasst sich mit dem Anforderungsmanagement rund um das Datenmodell für die Nutzung in CRM-Systemen und die darauffolgende Aktivität der Integration der Daten. Die für die Erfassung der Anforderungen und Integration der Daten notwendigen Schritte werden anhand eines Vorgehensmodells erläutert. Das Vorgehensmodell soll sowohl System- als auch Branchenagnostisch sein. Ein durchdachtes Anforderungsmanagement ist erforderlich, um die fachlichen Bedarfe für die Umsetzung von CRM-Aktivitäten mit der verfügbaren Datenbasis zu vereinbaren. Ein Integrationskonzept ist notwendig, weil sich das Datenmodell in CRM-Systemen von dem Datenmodell, das im Unternehmen Anwendung findet, unterscheidet. Häufige andere Hürden sind abweichende Datentypen und vom Use Case bedingte Business-Logiken, die sich von denen unterscheiden, die üblicherweise im Unternehmen genutzt werden. Als Quellsystem wird hier von einer Datenplattform ausgegangen, die sich on-premises oder in der Cloud befinden kann. Die Technologie, mit der die Daten physisch gespeichert werden, spielt für diesen Beitrag eine untergeordnete Rolle – ebenso wie das Produkt, das für die CRM-Lösung eingesetzt wird. Dieser Beitrag befasst sich mit der Feststellung des fachlichen Bedarfs bis hin zur Datenübertragung in das CRM-System. Datenschutzrechtliche Aspekte und die technische Umsetzung werden explizit ausgeklammert.
Insbesondere wenn ein Projekt für die Bewirtschaftung des CRM-Systems agil geplant wird, empfiehlt es sich, das unten beschriebene Vorgehensmodell je Datendomäne, die im ersten Schritt identifiziert wird (Kunden, Produkte, Verträge, Bestellungen, etc.), zu durchlaufen. Dabei können die Domänen parallel bearbeitet werden und sich je in einer Phase des Vorgehensmodells befinden. Rechtliche Vorgaben im Unternehmen und Schritte zur Verfügbarmachung der Daten können Abstimmungen mit weiteren Stakeholdern erfordern, die ebenfalls parallelisiert werden können.

Sammlung erster fachlicher Anforderungen
Man geht davon aus, dass ein Use Case für die CRM Software feststeht, der Aktivitäten in Marketing, Vertrieb oder anderen Bereichen des Unternehmens unterstützen soll. An diesem wird sich der fachliche Bedarf für die Daten orientieren. Der zuständige Fachbereich legt hierzu einen Grobbedarf für die Daten an, die für die Umsetzung des Use Cases aus seiner Sicht notwendig sind. An dieser Stelle ist noch keine Abstimmung mit Vertretern des Quellsystems erforderlich. Vielmehr soll der Fachbereich ohne Kenntnis der verfügbaren Daten im Sinne eines Brainstormings Wünsche festhalten, die aus seiner Sicht den Datenbedarf beschreiben. Die Granularität ist an dieser Stelle nebensächlich, wobei mindestens Datendomänen, die für den Use Case betrachtet werden, festzuhalten sind. Je nach Datenaffinität des Fachbereichs kann der Bedarf bereits auf Attributebene festgehalten werden, jedoch ist an dieser Stelle auch eine formfreie Dokumentation des Bedarfs möglich.
Konkretisierung und Überprüfung fachlicher Anforderungen im Feinbedarf
Erst im nächsten Schritt werden Vertreter des Quellsystems hinzugezogen. Der Fachbereich kommuniziert seine Wünsche und äußert Vorstellungen, welche Daten für die Umsetzung des Use Cases erforderlich sind. Vertreter des Quellsystems können schließlich anhand des Grobbedarfs die Verfügbarkeit der angefragten Daten prüfen und Schritte zur Anbindung fehlender, aber im Unternehmen grundsätzlich verfügbarer Daten einleiten. Gleichzeitig können Vorschläge von Seiten des Quellsystems für zusätzliche Daten gemacht werden. Diese Vorschläge können sich aus Daten ergeben, die sich in unmittelbarer Nähe der angefragten Daten befinden (z.B. in den gleichen Datenbank-Tabellen) und sich aus Sicht der Vertreter des Quellsystems für die Nutzung im CRM-System anbieten. Hierzu ist ein grundlegendes Verständnis des Use Cases erforderlich, das der Fachbereich bei den Vertretern des Quellsystems herstellen sollte. Wird ein Datenkatalog im Unternehmen eingesetzt, bietet es sich an, die Datenexploration auf diesem durchzuführen. Ist der Fachbereich selbst dazu befähigt (im Sinne von Berechtigungen und Skillset), kann ein Großteil der Abstimmungen mit den technischen Vertretern der Datenplattform ersetzt werden, wodurch auch eine Beschleunigung dieses Vorgangs erwartet werden kann.
Inzwischen sollte ein erster Aufschlag des Feinbedarfs feststehen. Spätestens an dieser Stelle ist es nötig, den Bedarf auf Attributebene zu dokumentieren. Hierzu eignet sich das Niederschreiben in Tabellenkalkulations-Dateien, in denen je Attribut eine Zeile angelegt wird und um Datentyp, Beispieldaten und Freigabeinformationen ergänzt wird. Im Zuge dessen sollten im Quellsystem auch die Inhalte der angefragten Attribute überprüft werden. Es kann vorkommen, dass die Inhalte dieser Spalten von der Erwartung des Fachbereichs abweichen und sich ein Attribut daher nicht für die Nutzung im CRM-System eignen. Entsprechende Maßnahmen sind zu ergreifen, um den Bedarf dennoch zu befriedigen, wie die Suche nach Alternativ-Attributen, die diese Inhalte liefern oder die Implementierung von Transformationen, wodurch mit den fehlerhaften oder unvollständigen Inhalten umgegangen wird.

Es ist sicherzustellen, dass Berechnungslogiken für Werte in den genutzten Daten der fachlichen Anforderung entsprechen und auch im Datenmodell des CRM-Systems korrekt abgebildet werden. Der fachliche Bedarf kann vorsehen, dass Entitäten zusammengeführt werden. Häufig ist dies erforderlich, um Duplikate in den Quellsystemen zu beseitigen, die im CRM-Zielsystem (abhängig vom Use Case) zu Problemen führen können oder keinen Mehrwert bieten. Ein Folgeproblem liegt vor, wenn die Attributausprägungen eines zusammenzuführenden Duplikats voneinander abweichen. Beispielsweise führt ein Quellsystem Datensätze von Kunden, wobei mehrere Datensätze eines Kunden existieren können. Diese sollen duplikatsbereinigt in das CRM-System übertragen werden. In unserem Beispiel unterscheidet sich nun in den Duplikaten der Eintrag zu einem erteilten Werbeverbot des Kunden. Hier muss fachlich entschieden werden, welcher Eintrag sinnvollerweise für das CRM-System übernommen werden soll. Es könnte der aktuellste Eintrag übernommen werden, der rechtlich ‚vorsichtigere‘ Eintrag (Werbeverbot erteilt) oder derjenige Eintrag, der dem Unternehmen den Werbekontakt erlaubt (kein Werbeverbot erteilt). Diese Entscheidung obliegt dem Fachbereich.
Datenintegration
Mithilfe der Übersicht der erforderlichen Attribute aus dem Quellsystem kann ein erstes Datenmodell für das CRM-System skizziert werden. Dieser Schritt kann je nach eingesetztem Softwareprodukt stark variieren, das für die CRM-Lösung eingesetzt wird. Einige Anbieter liefern bereits vorgefertigte Datenmodelle für unterschiedliche Branchen mit. So werden von Salesforce beispielsweise Datenmodelle für die Verwaltung von Versicherungsprodukten oder Hypotheken mitgeliefert. Es ist zudem üblich, dass diese Datenmodelle um eigens angelegte Attribute erweitert werden können. Wichtig ist hier eine sinnvolle und abgestimmte Kundendefinition. Liegt keine unternehmensweite Definition eines Kunden vor, ist eine solche für das CRM-System zu treffen, da die Verwaltung der Kunden eine der Kernaufgaben des CRM-Systems beschreibt.
Die im Quellsystem identifizierten Attribute sind in diesem Schritt den Attributen des Zieldatenmodells zuzuordnen. Um die Attribute der Datenplattform auf die Felder des CRM-Systems zu mappen, ist eine Prüfung der Metadaten der Felder des technischen Bedarfs erforderlich. Hierzu sind insbesondere Datentypen und Feldlängen zu beachten. Diese können im CRM-Datenmodell in einer bestimmten Form erwartet werden, die sich ggf. von der Form des Quellsystems unterscheiden.
Weichen die Metadaten zwischen Quellsystem und Zielsystem voneinander ab, müssen Maßnahmen ergriffen werden. Diese reichen von Anpassungen im Quellsystem (z.B. in einer Datenbanksicht, die explizit für die Beladung des CRM-Systems erstellt wird) über Anpassungen im Zielsystem (z.B. durch Custom Fields im CRM-System) und Transformationen bei der Beladungsstrecke bis hin zu einer Revision der fachlichen Anforderungen (4c).
Sind jegliche Maßnahmen fachlich abgenommen, kann damit begonnen werden, die Beladungsstrecke einzurichten. Hierzu werden ETL/ELT-Tools eingesetzt, mit denen die notwendigen Daten aus der Datenplattform extrahiert, notwendige Transformationen vorgenommen und die Beladung in den Datenspeicher des CRM-Systems übernommen wird. Fachliche Anforderungen für die Aktualisierung der Daten sollten definiert und mit der Beladungsstrecke umgesetzt werden. Technische sowie fachliche Tests sind schließlich unabdingbar, um die Richtigkeit der übertragenen Daten zu verifizieren.