Cus­to­mer Rela­ti­onship Manage­ment (CRM) beschäf­tigt sich mit dem stra­te­gi­schen Ansatz, alle inter­ak­ti­ven Pro­zesse mit dem Kun­den voll­stän­dig zu pla­nen, zu steu­ern und durch­zu­füh­ren (Gab­ler Wirt­schafts­le­xi­kon). CRM-Sys­teme sind Soft­ware­pro­dukte, die ein Unter­neh­men nutzt, um die­ses Kun­den­be­zie­hungs­ma­nage­ment zu unter­stüt­zen. Sie wer­den unter ande­rem dafür ein­ge­setzt Mar­ke­ting-Kam­pa­gnen zu steu­ern und den Ver­trieb zu stan­dar­di­sie­ren. Für diese Akti­vi­tä­ten ist eine umfas­sende Daten­ba­sis erfor­der­lich, über die die Infor­ma­tio­nen der Kun­den und unter­neh­mens­sei­tige Daten zusam­men­ge­fasst sind.

Der fol­gende Bei­trag befasst sich mit dem Anfor­de­rungs­ma­nage­ment rund um das Daten­mo­dell für die Nut­zung in CRM-Sys­te­men und die dar­auf­fol­gende Akti­vi­tät der Inte­gra­tion der Daten. Die für die Erfas­sung der Anfor­de­run­gen und Inte­gra­tion der Daten not­wen­di­gen Schritte wer­den anhand eines Vor­ge­hens­mo­dells erläu­tert. Das Vor­ge­hens­mo­dell soll sowohl Sys­tem- als auch Bran­chen­agnos­tisch sein. Ein durch­dach­tes Anfor­de­rungs­ma­nage­ment ist erfor­der­lich, um die fach­li­chen Bedarfe für die Umset­zung von CRM-Akti­vi­tä­ten mit der ver­füg­ba­ren Daten­ba­sis zu ver­ein­ba­ren. Ein Inte­gra­ti­ons­kon­zept ist not­wen­dig, weil sich das Daten­mo­dell in CRM-Sys­te­men von dem Daten­mo­dell, das im Unter­neh­men Anwen­dung fin­det, unter­schei­det. Häu­fige andere Hür­den sind abwei­chende Daten­ty­pen und vom Use Case bedingte Busi­ness-Logi­ken, die sich von denen unter­schei­den, die übli­cher­weise im Unter­neh­men genutzt wer­den. Als Quell­sys­tem wird hier von einer Daten­platt­form aus­ge­gan­gen, die sich on-premises oder in der Cloud befin­den kann. Die Tech­no­lo­gie, mit der die Daten phy­sisch gespei­chert wer­den, spielt für die­sen Bei­trag eine unter­ge­ord­nete Rolle – ebenso wie das Pro­dukt, das für die CRM-Lösung ein­ge­setzt wird. Die­ser Bei­trag befasst sich mit der Fest­stel­lung des fach­li­chen Bedarfs bis hin zur Daten­über­tra­gung in das CRM-Sys­tem. Daten­schutz­recht­li­che Aspekte und die tech­ni­sche Umset­zung wer­den expli­zit ausgeklammert.

Ins­be­son­dere wenn ein Pro­jekt für die Bewirt­schaf­tung des CRM-Sys­tems agil geplant wird, emp­fiehlt es sich, das unten beschrie­bene Vor­ge­hens­mo­dell je Daten­do­mäne, die im ers­ten Schritt iden­ti­fi­ziert wird (Kun­den, Pro­dukte, Ver­träge, Bestel­lun­gen, etc.), zu durch­lau­fen. Dabei kön­nen die Domä­nen par­al­lel bear­bei­tet wer­den und sich je in einer Phase des Vor­ge­hens­mo­dells befin­den. Recht­li­che Vor­ga­ben im Unter­neh­men und Schritte zur Ver­füg­bar­ma­chung der Daten kön­nen Abstim­mun­gen mit wei­te­ren Stake­hol­dern erfor­dern, die eben­falls par­al­le­li­siert wer­den können.

Samm­lung ers­ter fach­li­cher Anforderungen

Man geht davon aus, dass ein Use Case für die CRM Soft­ware fest­steht, der Akti­vi­tä­ten in Mar­ke­ting, Ver­trieb oder ande­ren Berei­chen des Unter­neh­mens unter­stüt­zen soll. An die­sem wird sich der fach­li­che Bedarf für die Daten ori­en­tie­ren. Der zustän­dige Fach­be­reich legt hierzu einen Grob­be­darf für die Daten an, die für die Umset­zung des Use Cases aus sei­ner Sicht not­wen­dig sind. An die­ser Stelle ist noch keine Abstim­mung mit Ver­tre­tern des Quell­sys­tems erfor­der­lich. Viel­mehr soll der Fach­be­reich ohne Kennt­nis der ver­füg­ba­ren Daten im Sinne eines Brain­stor­mings Wün­sche fest­hal­ten, die aus sei­ner Sicht den Daten­be­darf beschrei­ben. Die Gra­nu­la­ri­tät ist an die­ser Stelle neben­säch­lich, wobei min­des­tens Daten­do­mä­nen, die für den Use Case betrach­tet wer­den, fest­zu­hal­ten sind. Je nach Daten­af­fi­ni­tät des Fach­be­reichs kann der Bedarf bereits auf Attri­bu­tebene fest­ge­hal­ten wer­den, jedoch ist an die­ser Stelle auch eine form­freie Doku­men­ta­tion des Bedarfs möglich.

Kon­kre­ti­sie­rung und Über­prü­fung fach­li­cher Anfor­de­run­gen im Feinbedarf

Erst im nächs­ten Schritt wer­den Ver­tre­ter des Quell­sys­tems hin­zu­ge­zo­gen. Der Fach­be­reich kom­mu­ni­ziert seine Wün­sche und äußert Vor­stel­lun­gen, wel­che Daten für die Umset­zung des Use Cases erfor­der­lich sind. Ver­tre­ter des Quell­sys­tems kön­nen schließ­lich anhand des Grob­be­darfs die Ver­füg­bar­keit der ange­frag­ten Daten prü­fen und Schritte zur Anbin­dung feh­len­der, aber im Unter­neh­men grund­sätz­lich ver­füg­ba­rer Daten ein­lei­ten. Gleich­zei­tig kön­nen Vor­schläge von Sei­ten des Quell­sys­tems für zusätz­li­che Daten gemacht wer­den. Diese Vor­schläge kön­nen sich aus Daten erge­ben, die sich in unmit­tel­ba­rer Nähe der ange­frag­ten Daten befin­den (z.B. in den glei­chen Daten­bank-Tabel­len) und sich aus Sicht der Ver­tre­ter des Quell­sys­tems für die Nut­zung im CRM-Sys­tem anbie­ten. Hierzu ist ein grund­le­gen­des Ver­ständ­nis des Use Cases erfor­der­lich, das der Fach­be­reich bei den Ver­tre­tern des Quell­sys­tems her­stel­len sollte. Wird ein Daten­ka­ta­log im Unter­neh­men ein­ge­setzt, bie­tet es sich an, die Daten­ex­plo­ra­tion auf die­sem durch­zu­füh­ren. Ist der Fach­be­reich selbst dazu befä­higt (im Sinne von Berech­ti­gun­gen und Skill­set), kann ein Groß­teil der Abstim­mun­gen mit den tech­ni­schen Ver­tre­tern der Daten­platt­form ersetzt wer­den, wodurch auch eine Beschleu­ni­gung die­ses Vor­gangs erwar­tet wer­den kann.

Inzwi­schen sollte ein ers­ter Auf­schlag des Fein­be­darfs fest­ste­hen. Spä­tes­tens an die­ser Stelle ist es nötig, den Bedarf auf Attri­bu­tebene zu doku­men­tie­ren. Hierzu eig­net sich das Nie­der­schrei­ben in Tabel­len­kal­ku­la­ti­ons-Dateien, in denen je Attri­but eine Zeile ange­legt wird und um Daten­typ, Bei­spiel­da­ten und Frei­ga­be­infor­ma­tio­nen ergänzt wird. Im Zuge des­sen soll­ten im Quell­sys­tem auch die Inhalte der ange­frag­ten Attri­bute über­prüft wer­den. Es kann vor­kom­men, dass die Inhalte die­ser Spal­ten von der Erwar­tung des Fach­be­reichs abwei­chen und sich ein Attri­but daher nicht für die Nut­zung im CRM-Sys­tem eig­nen. Ent­spre­chende Maß­nah­men sind zu ergrei­fen, um den Bedarf den­noch zu befrie­di­gen, wie die Suche nach Alter­na­tiv-Attri­bu­ten, die diese Inhalte lie­fern oder die Imple­men­tie­rung von Trans­for­ma­tio­nen, wodurch mit den feh­ler­haf­ten oder unvoll­stän­di­gen Inhal­ten umge­gan­gen wird.

Es ist sicher­zu­stel­len, dass Berech­nungs­lo­gi­ken für Werte in den genutz­ten Daten der fach­li­chen Anfor­de­rung ent­spre­chen und auch im Daten­mo­dell des CRM-Sys­tems kor­rekt abge­bil­det wer­den. Der fach­li­che Bedarf kann vor­se­hen, dass Enti­tä­ten zusam­men­ge­führt wer­den. Häu­fig ist dies erfor­der­lich, um Dupli­kate in den Quell­sys­te­men zu besei­ti­gen, die im CRM-Ziel­sys­tem (abhän­gig vom Use Case) zu Pro­ble­men füh­ren kön­nen oder kei­nen Mehr­wert bie­ten. Ein Fol­ge­pro­blem liegt vor, wenn die Attri­but­aus­prä­gun­gen eines zusam­men­zu­füh­ren­den Dupli­kats von­ein­an­der abwei­chen. Bei­spiels­weise führt ein Quell­sys­tem Daten­sätze von Kun­den, wobei meh­rere Daten­sätze eines Kun­den exis­tie­ren kön­nen. Diese sol­len dupli­kats­be­rei­nigt in das CRM-Sys­tem über­tra­gen wer­den. In unse­rem Bei­spiel unter­schei­det sich nun in den Dupli­ka­ten der Ein­trag zu einem erteil­ten Wer­be­ver­bot des Kun­den. Hier muss fach­lich ent­schie­den wer­den, wel­cher Ein­trag sinn­vol­ler­weise für das CRM-Sys­tem über­nom­men wer­den soll. Es könnte der aktu­ellste Ein­trag über­nom­men wer­den, der recht­lich ‚vor­sich­ti­gere‘ Ein­trag (Wer­be­ver­bot erteilt) oder der­je­nige Ein­trag, der dem Unter­neh­men den Wer­be­kon­takt erlaubt (kein Wer­be­ver­bot erteilt). Diese Ent­schei­dung obliegt dem Fachbereich.

Daten­in­te­gra­tion

Mit­hilfe der Über­sicht der erfor­der­li­chen Attri­bute aus dem Quell­sys­tem kann ein ers­tes Daten­mo­dell für das CRM-Sys­tem skiz­ziert wer­den. Die­ser Schritt kann je nach ein­ge­setz­tem Soft­ware­pro­dukt stark vari­ie­ren, das für die CRM-Lösung ein­ge­setzt wird. Einige Anbie­ter lie­fern bereits vor­ge­fer­tigte Daten­mo­delle für unter­schied­li­che Bran­chen mit. So wer­den von Sales­force bei­spiels­weise Daten­mo­delle für die Ver­wal­tung von Ver­si­che­rungs­pro­duk­ten oder Hypo­the­ken mit­ge­lie­fert. Es ist zudem üblich, dass diese Daten­mo­delle um eigens ange­legte Attri­bute erwei­tert wer­den kön­nen. Wich­tig ist hier eine sinn­volle und abge­stimmte Kun­den­de­fi­ni­tion. Liegt keine unter­neh­mens­weite Defi­ni­tion eines Kun­den vor, ist eine sol­che für das CRM-Sys­tem zu tref­fen, da die Ver­wal­tung der Kun­den eine der Kern­auf­ga­ben des CRM-Sys­tems beschreibt.

Die im Quell­sys­tem iden­ti­fi­zier­ten Attri­bute sind in die­sem Schritt den Attri­bu­ten des Ziel­da­ten­mo­dells zuzu­ord­nen. Um die Attri­bute der Daten­platt­form auf die Fel­der des CRM-Sys­tems zu map­pen, ist eine Prü­fung der Meta­da­ten der Fel­der des tech­ni­schen Bedarfs erfor­der­lich. Hierzu sind ins­be­son­dere Daten­ty­pen und Feld­län­gen zu beach­ten. Diese kön­nen im CRM-Daten­mo­dell in einer bestimm­ten Form erwar­tet wer­den, die sich ggf. von der Form des Quell­sys­tems unterscheiden.

Wei­chen die Meta­da­ten zwi­schen Quell­sys­tem und Ziel­sys­tem von­ein­an­der ab, müs­sen Maß­nah­men ergrif­fen wer­den. Diese rei­chen von Anpas­sun­gen im Quell­sys­tem (z.B. in einer Daten­bank­sicht, die expli­zit für die Bela­dung des CRM-Sys­tems erstellt wird) über Anpas­sun­gen im Ziel­sys­tem (z.B. durch Cus­tom Fields im CRM-Sys­tem) und Trans­for­ma­tio­nen bei der Bela­dungs­stre­cke bis hin zu einer Revi­sion der fach­li­chen Anfor­de­run­gen (4c).

Sind jeg­li­che Maß­nah­men fach­lich abge­nom­men, kann damit begon­nen wer­den, die Bela­dungs­stre­cke ein­zu­rich­ten. Hierzu wer­den ETL/ELT-Tools ein­ge­setzt, mit denen die not­wen­di­gen Daten aus der Daten­platt­form extra­hiert, not­wen­dige Trans­for­ma­tio­nen vor­ge­nom­men und die Bela­dung in den Daten­spei­cher des CRM-Sys­tems über­nom­men wird. Fach­li­che Anfor­de­run­gen für die Aktua­li­sie­rung der Daten soll­ten defi­niert und mit der Bela­dungs­stre­cke umge­setzt wer­den. Tech­ni­sche sowie fach­li­che Tests sind schließ­lich unab­ding­bar, um die Rich­tig­keit der über­tra­ge­nen Daten zu verifizieren.