17. März 2014

Migration von CRM On-Premise zu CRM Online mit Hilfe von Scribe

Nachdem wir nun schon einige Jahre mit einem Microsoft Dynamics CRM On-Premise unterwegs waren, haben wir uns dazu entschlossen, den Einstieg in die Cloud zeitgleich mit der Verfügbarkeit von Dynamics Online 2013 zu wagen. Bei der Recherche nach einem geeigneten Tool zur Unterstützung der Migration trifft man unweigerlich auf Scribe, wofür wir uns letztendlich auch entschieden haben. Genauer gesagt handelt es sich um Scribe Online, bei dem der gesamte Funktionsumfang über eine Weboberfläche zur Verfügung gestellt wird. Unsere Erfahrungen bei der CRM Migration mit Hilfe von Scribe wollen wir an dieser Stelle weitergeben. Eine Migration über die Export/Import Funktionalität des CRMs ist nicht empfehlenswert. Gegen dieses Verfahren spricht, dass es leider nicht möglich ist, Anhänge zu migrieren und es Probleme beim Referenzieren von anderen Entitäten gibt, falls kein eindeutiger Name beim Lookup-Wert vorliegt.

Einrichtung von Scribe Online

Die ersten Schritte nach der Anmeldung bei Scribe können sozusagen chronologisch anhand der linken Navigationsleiste abgearbeitet werden. Unter „Solutions“ aktiviert man zunächst die „Integration Services“, die man sogar 15 Tage mit vollem Funktionsumfang nutzen kann. Innerhalb von „Agents“ wird anschließend ein On-Premise Agent installiert, der benötigt wird, sobald ein On-Premise System Bestandteil der Migration ist. Die Verbindungsdaten zum alten und neuen CRM trägt man unter „Connections“ ein. Dabei sollte man beachten, dass der jeweilige User über die notwendigen Lese- und Schreibberechtigungen verfügt, die für das Auslesen der Altdaten bzw. das Erstellen der neuen Daten benötigt werden.

Definition der zu importierenden Entitäten und Feldmapping

Bevor man mit der Migration beginnt und Scribe die Arbeit machen lässt, sollte man sich darüber klar werden, welche Entitäten ins neue CRM migriert werden soll. Für jede dieser Entitäten wird es später erforderlich sein, ein Daten- bzw. Feldmapping  zu erstellen. Scribe bietet dazu bereits eine Automapping-Funktion an, die Felder mit gleicher Feldbezeichnungen automatisch verbindet. Falls im alten CRM Anpassungen an den Formularen vorgenommen wurden, so sollte man diese Anpassungen auf das neue CRM übertragen, sofern die Anpassungen ins neue System übertragen werden sollen. Ein Export/Import der Solution(s) kann hierbei schon den erhofften Effekt bringen.

Sind die benötigten Entitäten identifiziert sollte man sich Gedanken machen, in welcher Reihenfolge diese ins System gespielt werden. Falls die Importreihenfolge falsch aufgebaut ist, kann es passieren, dass Datensätze nicht importiert werden, da sie zu einem noch nicht vorhandenen Datensatz in Beziehung stehen. Die Entität Verkaufschance sollte erst angelegt werden, nachdem auch Leads, Firmen und Kontakte importiert wurden. Grundlegend kann man sich im Bereich Vertrieb am Vertriebsprozess und seinen Entitäten orientieren. So kann die Reihenfolge im Bereich Vertrieb aussehen:
  • Leads
  • Firmen (ohne primäre Kontakte)
  • Kontakte
  • Update der Firmen (Mapping der primären Kontakte)
  • Verkaufschance
  • Angebote
  • Aufträge
  • Rechnungen
  • Aktivitätstypen
  • Notizen
Diese Übersicht dient nur exemplarisch für eine mögliche Reihenfolge im Vertriebsbereich. Bei Benutzung von weiteren Entitäten kann sich die Reihenfolge natürlich noch ändern. An dieser Stelle kann man festhalten, dass Aktivitäten gleich welcher Art erst importiert werden, nachdem alle sonstigen Entitäten importiert wurden, die im CRM direkt aufgerufen werden können. Die Entität Notizen bildet grundsätzlich das Schlusslicht beim Import, da man zu eigentlich jeder Entität Notizen erstellen kann. Eine Besonderheit ist der Import der Firmen. Da Firmen primäre Kontakte aufweisen, ist es erst nach dem Import der Kontakte möglich, der Firma einen primären Kontakt zuzuweisen. Scribe bietet neben der klassischen Importfunktionalität auch die Möglichkeit Entitäten zu aktualisieren. Diese Update-Funktion werden wir später noch ausgiebig nutzen. Die Migration sollte allerdings nicht direkt mit dem Vertriebsbereich begonnen werden. Es empfiehlt sich mit dem Produktkatalog zu beginnen, um auf Preislisten, Produkte usw. zurückgreifen zu können.

Bevor man mit dem Import startet gibt es noch drei wesentliche Aspekte, die es zu beachten gilt. Es geht dabei um die GUIDs der Entitäten, das User-Mapping und den Status der importierten Entitäten.

GUIDs der Entitäten

Beim Import von Entitäten bestehen zwei Möglichkeiten, um die GUIDs festzulegen. Entweder es findet kein Mapping statt und die GUIDs werden vom System neu vergeben oder man übernimmt die GUIDs aus dem alten CRM. Die erstgenannte Lösung spiegelt mehr oder weniger die Möglichkeiten der normalen Export-/Importfunktion wider und kann nur verwendet werden, wenn man eindeutige Bezeichner verwendet. Der zweite Lösungsansatz ist deutlich flexibler und kommt problemlos mit Relationen zu anderen Entitäten zurecht. Um dies zu bewerkstelligen wird im Mapping festgelegt, dass die ID der jeweiligen Entität und die IDs der relationalen Entitäten ebenfalls „gemappt“ werden.

User-Mapping

Der Punkt User-Mapping bezieht sich hauptsächlich auf die Besitzer von Entitäten und wie man diese wieder richtig zuordnet. Sowohl unser CRM On-Premise als auch unser CRM Online sind mit unserem AD gekoppelt. In diesem Fall sind die User im CRM Online bereits angelegt und verfügen über eine andere GUID im Vergleich zu den Usern im CRM On-Premise. Da es essentiell ist, dass wir nach dem Import die richtige Zuordnung der Besitzer haben, müssen wir uns mit einer Mapping-Tabelle behelfen. In die erste Spalte schreiben wir die User-GUIDs aus dem alten CRM und die zweite Spalte wird mit den korrespondierenden User-GUIDs des neuen CRM befüllt. Beim Mapping von Entitäten kann man nun auf die soeben erstellte Tabelle zugreifen. Das Mapping der Owner-ID wird über folgende Funktion abgebildet: 
  • LOOKUPTABLEVALUE2_DEFAULT(“[NAME DER USER MAPPING TABELLE]”, owner.id, “[DEFAULT-GUID]”)
  • LOOKUPTABLEVALUE2 (“[NAME DER USER MAPPING TABELLE]”, owner.id)
Die Default-GUID setzt einen Wert für den Fall, dass die Owner-ID nicht in der Mapping Tabelle gefunden wird. Dies macht insbesondere dann Sinn, wenn ausgeschiedene Mitarbeiter nicht ins neue System übernommen werden sollen und man stattdessen einen vorher definierten User als Besitzer der jeweiligen Entität festlegen möchte. Alternativ kann man bei besonders vielen Mitarbeitern zu jedem ausgeschiedenem Mitarbeiter einen Vertreter festlegen.
Status der Entitäten

Grundsätzlich muss man beim Mapping Vorsicht hinsichtlich der Status der Entitäten (STATECODE und STATUSCODE) walten lassen. Diese sollte man beim Mapping außen vor lassen, da es sonst passieren kann, dass Beziehungen zwischen zwei Entitäten nicht aufgebaut werden können. Hintergrund ist, dass Datensätze nicht mehr aktualisiert werden können, sobald sie einen inaktiven Status besitzen. Somit ist auch keine weitere Zuordnung eines Datensatzes zu einem in Relation stehenden Datensatz möglich. Erst wenn alle Entitäten importiert wurden und keine Datensätze vermisst werden, kann man die Status der Entitäten in derselben Reihenfolge wie beim Import aktualisieren.

Somit ist die Migration abgeschlossen. Im Nachgang wird man leider feststellen, dass Datumsfelder wie bspw. „Erstellt am“ bei allen Entitäten oder „Tatsächliches Abschlussdatum“ bei den Verkaufschancen das Datum des Imports übernehmen. Dies lässt sich leider nicht umgehen, da es sich dabei um systemseitige Felder handelt.

Bei Fragen, Anregungen und Kommentaren können Sie sich gern an die Allgeier Productivity Solutions wenden, oder direkt die Kommentarfunktion hier benutzen. Wir freuen uns auf Feedback.

0 Kommentare: