CRM-Anwendungen wie Salesforce müssen heutzutage hohen Anforderungen entsprechen und einen multidimensionalen Blick auf den Kunden ermöglichen. Dafür müssen in nahezu jedem Salesforce-Projekt Daten aus Altsystemen in das neue CRM–System integriert oder migriert werden. Diese Datenmigration ist integraler Bestandteil des Projekts und Salesforce bietet mit seiner API dafür eine sehr gute Lösung. Doch in jedem Migrationsprozess kosten Stolpersteine Nerven und wertvolle Ressourcen. Wenn man jedoch weiß, worauf man achten muss, können einige Probleme vermieden werden. Hier die wichtigsten 5 Profi-Tipps.
Tipp 1: Kritische Betrachtung, welche Reports nötig sind
Um die Reporting-Möglichkeiten von Salesforce richtig nutzen zu können, muss das Datenmodell darauf abgestimmt werden. Ein Hauptproblem dabei: Bei Salesforce ist es nicht möglich zwei Objekte, die am selben Mutterobjekt hängen, im selben Visual anzuzeigen – das kann zu Problemen im Soll-Ist Reporting führen.
So ist es zum Beispiel nicht möglich ein Invoice Objekt eines Accounts im gleichen Visual darzustellen wie dein Opportunity Objekt des Accounts. Diese Art von Vergleich ist aber zentral für die Vertriebssteuerung. Wenn jede Rechnung aber einer Opportunity zugeordnet ist, kann so etwas leicht erzielt werden.
Wir empfehlen daher während der Konzeptionsphase ergebnisorientiert zu arbeiten. Zunächst muss also evaluiert werden, welche Reports tatsächlich nötig sind. Erst danach wird mit der Implementierung begonnen. Meistens umgeht man damit viele aufwändige oder unnötige Schritte.
Tipp 2: Externe ID’s nutzen
Der zweite Tipp dreht sich um die Rückverfolgung und Fehlerbehebung bei Datenmigrationen. Hierbei ist es zentral, den Datensatz von Salesforce direkt mit dem in Verbindung stehenden Datensatz im Quellsystem verbinden zu können.
Das wird durch sogenannte External ID’s in Salesforce gelöst. Man kann bei allen Feldern eines Objekts angeben, dass es sich um einen solchen handelt. Wenn zum Beispiel in ein Objekt Daten aus System A und System B gespielt werden, ist es sinnvoll zwei ExternalID Felder zu benutzen (External ID_A und External_ID_B), damit sofort die Verbindung hergestellt werden kann.
Bewährt hat sich in zahlreichen Projekten die API-Funktion in Salesforce, bei der ExternalD Felder auch direkt übergeben werden. Salesforce ist damit in der Lage, einen Datensatz ohne die dazugehörige SalesforceID zu finden.
Die ExternalIDs sind auch die zentrale Funktion bei der Einrichtung von Synchronisationen. Diese halten Daten in verschiedenen Systemen ident.
Tipp 3: Weniger (migrieren) ist mehr
Oftmals wird der Ansatz verfolgt: Wir brauchen alle Daten! Unserer Erfahrung nach ist das jedoch ein Trugschluss. Unsere Empfehlung lautet daher, wirklich nur die verwendeten Felder zu migrieren und möglichst nur, wenn die Information immer noch wichtig ist (ganz im Sinne von Tipp 1). Dadurch vermeidet man unübersichtliche Mappings, den aufwändigen Transfer von großen Datenmengen und Datenmüll, der aus Altsystemen mit übernommen wird. Was uns zum nächsten Tipp führt:
Tipp 4: Vorbereitung ist alles
Für eine ordentliche Migration von mehreren Quellsystemen zu Salesforce ist die Spezifikation das A und O. Wenn nicht genau abgestimmt wird, welche Felder in den verschiedenen Systemen übereinstimmen und welches System dafür das führende ist, sind Probleme mit der Daten-Konsistenz vorprogrammiert. „Garbage in, Garbage out“ gilt bei den meisten Projekten, die Daten betreffen, so auch bei Salesforce Datenintegrations-Projekten. Es ist abzuwägen, welche Daten überhaupt benötigt werden und ratsam die Daten zuvor einem Quality-Check zu unterziehen. So können Inkonsistenzen der Quelldaten (zum Beispiel: Editierungsdatum ist vor dem Erstellungsdatum oder Picklistfelder sind mit Freitext versehen) aufgedeckt und bereinigt werden.
Dabei gibt es die Möglichkeit, die Bereinigung direkt im Migrationsjob einzubauen oder im Quellsystem richtigzustellen. Je nachdem, ob das Quellsystem später noch zum Einsatz kommt oder nicht, ist hier die richtige Variante zu wählen.
Tipp 5: Integrationstests definieren und durchführen
Ohne gut durchdachte Integrationstests war jede noch so gute Vorbereitung umsonst. Bei großen Datenmengen ist es wichtig, dass alle Datensätze migriert und die wichtigsten Eigenschaften und Datensätze (z.B. noch aktive Supporttickets) kontrolliert werden.
Nur so kann festgestellt werden, ob die Migration erfolgreich war oder nicht.
Diese Tests sollten vorher festgelegt und von Key Usern durchgeführt werden. Diese sind als einzige in der Lage, die Daten auch logisch zu prüfen. Eine erfolgreiche Integration oder Migration ist also nur im Zusammenspiel mehrerer Kompetenzen möglich.
Fazit
Die Datenmigration von Altsystemen in das neue System sollte strategisch angegangen werden. Das bedeutet: die konzeptionelle Arbeit, was und zu welchem Zweck migriert werden soll, ist essenziell, um dann die richtigen Schritte einleiten zu können. Bei der Migration wird dann dem Migration Engineer viel zu viel Verantwortung gegeben und dabei außer Acht gelassen, dass dieser zwar die technische Komponente beisteuern kann, jedoch nicht immer die logische. Dies zeigt deutlich, warum man so ein Projekt entsprechend planen sollte, um die oben genannten Fallstricke zu umgehen.