Den Übertragungsweg am Datenmodell wählen
Ein Tabellenimport kann ausreichen, wenn die Daten überschaubar strukturiert sind und die benötigten Beziehungen unterstützt werden. Prüfen Sie dabei, wie IDs, Mehrfachzuordnungen, Anhänge und Aktivitäten behandelt werden. Dass eine Datei eingelesen werden kann, bedeutet noch nicht, dass sämtliche CRM-Informationen enthalten sind.
Ein Importwerkzeug oder eine API-Anbindung kann sinnvoll sein, wenn mehrere Objekte, wiederholte Läufe oder besondere Umwandlungen notwendig sind. Eine API ist die technische Schnittstelle eines Systems. Welche Daten darüber verfügbar sind, welche Grenzen gelten und wie Fehler gemeldet werden, muss für beide Systeme geprüft werden.
| Weg | Vorher prüfen | Besondere Grenze |
|---|---|---|
| CSV-/Tabellenimport | Unterstützte Objekte, Pflichtfelder, Datentypen und Verknüpfungsschlüssel | Anhänge oder komplexe Beziehungen können eine zusätzliche Übernahme benötigen. |
| Importwerkzeug | Unterstützte Versionen, Objekte, Umwandlungen und Wiederholung | Ein angebotener Connector belegt nicht die Abdeckung aller individuellen Felder. |
| Individuelle API-Übernahme | Lese-/Schreibrechte, Limits, Fehlerbehandlung und Wiederanlauf | Technische Verfügbarkeit ersetzt keine fachliche Zuordnung. |
Die passende Methode folgt dem vereinbarten Zielmodell. Falls noch offen ist, wie Kunden, Personen und Verkaufschancen zusammenhängen sollen, klären Sie dies zunächst im CRM-Lastenheft.
Kontakte, Firmen und Chancen gemeinsam zuordnen
Beim Mapping wird jedes relevante Quellfeld einem Zielfeld zugeordnet. Zusätzlich wird festgelegt, wie Werte umgewandelt und Beziehungen aufgelöst werden. Eine Liste mit Spaltennamen reicht dafür nicht aus.
Verwenden Sie stabile Quellkennungen, um den Weg eines Datensatzes nachzuverfolgen. Wenn sich die Kennungen im Zielsystem ändern, brauchen Sie eine Zuordnung zwischen alter und neuer ID. Ein Firmenname allein ist als Verbindung problematisch, sobald mehrere Unternehmen gleich heißen oder sich Schreibweisen unterscheiden.
Das folgende Modell zeigt, warum Objekte und Beziehungen gemeinsam geprüft werden müssen. Ein importierter Kontakt ohne passende Firmenzuordnung kann im CRM sichtbar sein und trotzdem fachlich falsch eingeordnet bleiben.
- Unternehmen
- Quell-ID F-18 → Ziel-ID A-302.
- Kontakt
- Quell-ID P-41 → Ziel-ID C-906; bisherige Firmenreferenz F-18 wird auf A-302 abgebildet.
- Verkaufschance
- Quell-ID V-07 → Ziel-ID O-115; Unternehmen A-302 und Kontakt C-906 werden zugeordnet.
- Prüfung
- Die Chance zeigt denselben fachlichen Kunden und Ansprechpartner wie der freigegebene Quellbestand.
Dokumentieren Sie außerdem Formate, leere Werte und Pflichtangaben. Eine nicht bekannte Telefonnummer bleibt unbekannt; sie sollte nicht mit einem erfundenen Ersatzwert gefüllt werden. Bei Auswahlfeldern müssen alte und neue Kategorien inhaltlich zusammenpassen. Eine pauschale Zuordnung aller offenen Vorgänge zur ersten Pipelinephase würde deren bisherigen Stand verändern.
Microsoft beschreibt in seiner Dokumentation zur CRM-Migration nach Dataverse ebenfalls unterschiedliche Quell- und Zielstrukturen, Datenqualität und Beziehungsabhängigkeiten als eigene Herausforderungen. Die konkreten Importmechanismen bleiben systemspezifisch.
Dubletten als fachliche Entscheidung behandeln
Ähnliche Namen oder dieselbe E-Mail-Adresse können auf einen doppelten Eintrag hinweisen. Sie beweisen ihn nicht. Eine Sammeladresse kann von mehreren Personen genutzt werden; gleichnamige Firmen können unterschiedliche rechtliche Einheiten sein. Trennen Sie deshalb das Erkennen eines möglichen Konflikts von der Freigabe einer Zusammenführung.
Definieren Sie, welche Merkmale einen Prüffall auslösen und wer ihn entscheidet. Halten Sie bei einer Zusammenführung fest, welcher Datensatz bestehen bleibt, welche Feldwerte übernommen werden und wohin Aktivitäten, Dokumente und Verkaufschancen verweisen sollen.
Auch widersprüchliche Angaben brauchen eine Regel. Der zuletzt geänderte Datensatz enthält nicht zwingend die fachlich richtige Information. Bei relevanten Konflikten sollte eine benannte Person die Quelle prüfen und ihre Entscheidung dokumentieren.
- Prüffall: Zwei Kontakte haben denselben Namen und dieselbe geschäftliche E-Mail-Adresse.
- Konflikt: Die Firmenzuordnung unterscheidet sich; beide Einträge enthalten Aktivitäten.
- Entscheidung: Verantwortliche Person prüft, ob ein Firmenwechsel oder eine echte Dublette vorliegt.
- Freigabe: Zielkontakt, erhaltene Beziehungen und Behandlung der Historie sind dokumentiert.
Testimport mit Beziehungstests abnehmen
Wählen Sie eine Testmenge, die Ihre unterschiedlichen Fälle abdeckt: mehrere Ansprechpartner, parallele Chancen, ausgeschiedene Verantwortliche, lange Notizen, Anhänge und bekannte Dubletten. Eine zufällige Handvoll einfacher Kontakte prüft diese Unterschiede nicht.
Vergleichen Sie nach dem Import zunächst Mengen und Fehlerprotokolle. Dabei muss die Rechnung zum vereinbarten Umfang passen: übernommene Datensätze, bewusst zusammengeführte Einträge, ausgeschlossene Bestände und offene Fehler. Gleiche Zeilenzahlen allein belegen keine korrekte Übernahme.
Prüfen Sie anschließend fachlich. Öffnen Sie eine Kundenakte und verfolgen Sie deren Beziehungen, letzte Aktivitäten, Zuständigkeit und aktive Verkaufschancen. Kontrollieren Sie Datumswerte sowie relevante Zeitzonen. Bei Historien ist zu unterscheiden, ob der ursprüngliche Zeitpunkt und die ursprüngliche Person als Information erhalten bleiben oder ob das Zielsystem neue technische Importzeitpunkte anlegt.
Testen Sie außerdem mit den vorgesehenen Benutzerrollen. Ein Administrator kann einen vollständig importierten Datensatz sehen, während dem Vertrieb die erforderlichen Rechte fehlen. Umgekehrt dürfen durch die Übernahme nicht unbeabsichtigt weitergehende Zugriffe entstehen.
Halten Sie erwartetes Ergebnis, beobachtetes Ergebnis und Freigabe fest. Definieren Sie vorab, welche Fehler den produktiven Wechsel verhindern. Ein fehlender Kontaktbezug an aktiven Chancen kann beispielsweise ein solcher Stopgrund sein. Die zuständige Fachrolle entscheidet über die Abnahme; ein erfolgreicher Importstatus genügt dafür nicht.
Änderungen und laufende Automationen kontrollieren
Zwischen Testlauf und Umstellung verändert sich der Bestand weiter. Vereinbaren Sie deshalb einen Stichtag und den Umgang mit neuen oder geänderten Datensätzen. Entweder gibt es eine abgestimmte Schreibpause oder eine geprüfte Übernahme der Änderungen. Die Verantwortlichen müssen wissen, ab wann welches System führt.
Prüfen Sie vor dem produktiven Import die Reaktion von Automationen und Anbindungen. Neue Datensätze könnten Folgeaufgaben, Benachrichtigungen oder weitere Übertragungen auslösen. Legen Sie fest, welche Funktionen während des Imports deaktiviert bleiben und wie sie anschließend kontrolliert aktiviert werden.
Bereiten Sie einen Rückfallweg mit Sicherung, Zuständigkeit und Abbruchentscheidung vor. Berücksichtigen Sie dabei bereits im neuen System erfolgte Änderungen. Ein einfacher Rücksprung zum alten Bestand würde diese sonst übergehen. Testen Sie außerdem, wie ein unterbrochener Import wiederholt werden kann, ohne neue Dubletten anzulegen.
Nach der Freigabe folgt ein begrenzter Nachlauf mit Fehlerliste und verantwortlicher Ansprechperson. Für die Vorbereitung des Teams und den Übergang in den Arbeitsalltag ergänzt der Leitfaden zur CRM-Einführung diese technische Planung.
Mapping und Prüfliste herunterladen
Die CSV-Vorlage für Mapping und Prüffälle enthält Beispielzeilen für Felder, Beziehungen und Dublettenentscheidungen sowie Platz für eigene Einträge. Die Markdown-Vorlage für die Freigabe ergänzt Umfang, Stichtag, Abbruchgründe und Nachlauf. Es sind Planungsdokumente, keine unmittelbar ausführbaren Importdateien.
Füllen Sie die Vorlagen gemeinsam mit der fachlichen Datenverantwortung aus. Tragen Sie offene Punkte ausdrücklich ein und prüfen Sie das Ergebnis an einem Probeexport. Wenn die Übernahme Teil einer individuellen CRM-Lösung werden soll, bilden diese Unterlagen eine konkrete Grundlage zur Abgrenzung des Projekts.