Checkliste für CRM-Datenimporte: So testen Sie ein selbst gehostetes CRM, bevor Sie Ihre Datensätze umziehen

Warum die Importqualität wichtiger ist als ein erfolgreicher erster Upload

Eine Import-Schaltfläche ist kein Migrationsplan. Ein erster Upload kann erfolgreich wirken, während er unbemerkt doppelte Kontakte erstellt, Datensätze dem falschen Team zuweist, einen Deal mit der falschen Organisation verknüpft oder Zeilen verwirft, die die Validierung nicht bestehen.

Bewerten Sie die Importfunktion als Kontrollsystem. Sie müssen wissen, was die Anwendung erstellt, aktualisiert, ablehnt und meldet, ob Sie Fehler korrigieren können und ob eine Wiederholung sicher ist. Die relevante Frage lautet nicht „Kann sie CSV importieren?“, sondern „Können wir aus unseren tatsächlichen Quelldaten zuverlässig und wiederholbar vertrauenswürdige Datensätze erzeugen?“

Verschiedene CRMs setzen diese Kontrollen unterschiedlich um. EspoCRM dokumentiert beispielsweise die Importmodi „Nur erstellen“, „Erstellen & Aktualisieren“ und „Nur aktualisieren“. Bei den aktualisierungsfähigen Modi muss die Person, die den Import ausführt, Felder auswählen, die einen vorhandenen Datensatz identifizieren. Diese Auswahl ist eine Entscheidung der Data Governance und keine technische Standardeinstellung. Siehe die [EspoCRM-Importdokumentation](https://docs.espocrm.com/administration/import/).

• Genehmigen Sie ein CRM nicht allein anhand einer sauberen Demodatei.
• Testen Sie mit denselben Datentypen, Inkonsistenzen und Beziehungen, die im Produktionsexport vorkommen.
• Dokumentieren Sie jede Konfigurationsentscheidung, die in jedem Testlauf verwendet wird.
• Definieren Sie Erfolg als korrekte, nutzbare Datensätze mit erklärbaren Ausnahmen.

Beginnen Sie mit einer Bestandsaufnahme der Quelldaten

Erstellen Sie eine Bestandsaufnahme, bevor Sie auch nur eine Spalte zuordnen. Tabellenkalkulationen und abzulösende CRMs enthalten zusammengehörige Informationen häufig in getrennten Registerkarten, Modulen, Freitextnotizen und Dateispeichern. Wenn die Bestandsaufnahme nur Kontakte zählt, kann die Migration vollständig wirken, obwohl Vertriebskontext, Eigentümerschaft oder Betriebshistorie verloren gehen.

Identifizieren Sie für jede Quelltabelle oder jeden Export den geschäftlichen Zweck, die Datensatzanzahl, die primäre Kennung, den aktuellen Eigentümer, den Datenverantwortlichen, die Zielentität und Beziehungsabhängigkeiten. Markieren Sie, welche Daten am ersten Tag unverzichtbar sind und welche zurückgestellt oder außerhalb des CRM archiviert werden können.

Beziehen Sie Aktivitäten erst ein, nachdem Sie bestätigt haben, dass das Zielmodell die relevanten Datensätze und Bereiche unterstützt. Bei EspoCRM hängen beispielsweise die verfügbaren Bereiche für Aktivitäten, Historie und Aufgaben vom konfigurierten Entitätstyp ab. Gehen Sie nicht davon aus, dass jede benutzerdefinierte Entität dieselben verknüpften Informationen wie ein Personen- oder Organisationsdatensatz bereitstellt. Siehe die [EspoCRM-Entity-Manager-Dokumentation](https://docs.espocrm.com/administration/entity-manager/).

• Kern-Datensätze: Personen, Organisationen, Leads, Deals oder entsprechende Entitäten.
• Beziehungen: Kontakt zu Organisation, Deal zu Kontakt, Eltern-Kind-Datensätze und alle Viele-zu-Viele-Verknüpfungen.
• Betriebskontext: Notizen, Anrufe, Besprechungen, Aufgaben, E-Mails und Historie, sofern erforderlich.
• Dateien: Anhänge, Dokumente, Dateipfade und Links zu externen Repositories.
• Konfigurationsdaten: benutzerdefinierte Felder, Listenwerte, Tags, Teams, Eigentümer und Statuswerte.
• Quellkennungen: IDs aus der Tabellenkalkulation oder dem vorherigen System für jede Entität.

Definieren Sie das Zieldatenmodell, bevor Sie Felder zuordnen

Die Feldzuordnung sollte einem bewusst vereinbarten Zieldatenmodell folgen, nicht dem Wunsch, jede Quellspalte beizubehalten. Entscheiden Sie, welche Zielentitäten existieren werden, welche Felder erforderlich sind, welche Felder benutzerdefiniert sind, welche Werte kontrollierte Listen darstellen und welche Informationen außerhalb des CRM bleiben sollten.

Wählen Sie für jedes Quellfeld genau ein Ergebnis: direkt zuordnen, transformieren, aufteilen, zusammenführen, in einem kontrollierten benutzerdefinierten Feld ablegen, in einem Archiv behalten oder ausschließen. Dokumentieren Sie die Begründung. Eine Freitextspalte „Status“ sollte beispielsweise nicht einem eingeschränkten Statusfeld zugeordnet werden, bevor ihre unterschiedlichen Quellwerte geprüft und normalisiert wurden.

Prüfen Sie die Importberechtigung auf Feldebene. Die Studio-Dokumentation von SuiteCRM beschreibt die Konfiguration von Feldern und Beziehungen, einschließlich der Frage, ob Felder für Importe über den Importassistenten erlaubt, nicht erlaubt oder erforderlich sind. Sie nennt außerdem Feldtyp, Auditierung und Einstellungen zur Duplikatzusammenführung als Feldeigenschaften. Die genauen Kontrollen unterscheiden sich je nach CRM. Validieren Sie daher die Zielanwendung, statt sie aus einem anderen Produkt abzuleiten. Siehe die [SuiteCRM-Studio-Dokumentation](https://pre-release.docs.suitecrm.com/admin/administration-panel/studio/).

• Name der Zielentität und des Zielfelds.
• Quelltabelle, Spalte und Quelldatentyp.
• Transformationsregel und zulässige Werte.
• Status als erforderlich, optional, sensibel oder schreibgeschützt.
• Importberechtigung und Standardverhalten.
• Verantwortliche Person für die Zuordnungsentscheidung und das Testergebnis.

Erstellen Sie einen repräsentativen Testimport, statt ein bereinigtes Beispiel zu verwenden

Ein sorgfältig aufbereitetes Beispiel beweist nur, dass sich sorgfältig aufbereitete Daten importieren lassen. Erstellen Sie einen kleinen, repräsentativen Testdatensatz aus Kopien echter Datensätze und schützen Sie sensible Werte bei Bedarf. Bewahren Sie die Probleme, die Ihre Produktionsdaten tatsächlich enthalten, damit der Test zeigt, wie sich der Importer verhält.

Nehmen Sie sowohl gewöhnliche Datensätze als auch absichtliche Sonderfälle auf. Testen Sie fehlende Pflichtwerte, inkompatible Werte für kontrollierte Listen, doppelte Namen, doppelte E-Mail-Adressen, wiederholte Quell-IDs, uneinheitliche Telefonnummernformate, Mehrfachwertfelder, Satzzeichen, Nicht-ASCII-Zeichen und Datumsangaben in mehr als einem Format.

Validierungsfehler sind wertvolle Nachweise. EspoCRM dokumentiert, dass eine Zeile, die bei der Validierung fehlschlägt, keinen Datensatz erstellt; als Beispiele nennt es inkompatible Enum-Werte und leere Werte für ein nicht leeres Enum. Ihr Test sollte das entsprechende Verhalten in dem bewerteten CRM bestätigen, einschließlich der Auswirkungen auf gültige Felder in einer teilweise ungültigen Zeile. Siehe die [EspoCRM-Importdokumentation](https://docs.espocrm.com/administration/import/).

• Verwenden Sie für jede Testdatei eine bekannte Datensatzanzahl.
• Kennzeichnen Sie die Testdatensätze, damit sie später gefunden und geprüft werden können.
• Bewahren Sie eine unveränderte Kopie des ursprünglichen Testextrakts auf.
• Nehmen Sie bekanntermaßen korrekte, bekanntermaßen fehlerhafte und absichtlich mehrdeutige Zeilen auf.
• Ersetzen Sie Produktionswerte nicht durch unrealistisch einheitliche Platzhalter.

Testen Sie die Entscheidungen, die schlechte CRM-Daten verursachen: Duplikate, fehlende Werte, Formatierung und Eigentümerschaft

Die Duplikatkontrolle beginnt mit einer expliziten Abgleichrichtlinie. Legen Sie fest, welche Quellkennungen maßgeblich sind, ob eine E-Mail-Adresse für Ihren Anwendungsfall eindeutig genug ist und wie das CRM einen Treffer in einem Feld, aber nicht in einem anderen behandeln soll. Halten Sie für jeden Lauf die exakt ausgewählten Abgleichfelder fest.

Stabile Quellkennungen sind besonders für Korrekturschleifen wichtig. Odoo dokumentiert, dass konsistente externe IDs wiederholte Importe ohne das Erstellen von Duplikaten unterstützen können, während das Ändern oder Entfernen einer externen ID zu einem neuen Datensatz statt zu einer Aktualisierung führen kann. Unabhängig davon, ob Ihr gewähltes CRM externe IDs oder einen anderen Kennungsmechanismus verwendet, prüfen Sie, dass seine Kennung bei einem erneuten Import exakt wie erwartet bestehen bleibt. Siehe die [Odoo-Dokumentation zu Export und Import](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Vertrauen Sie der automatischen Datumserkennung nicht. Odoo weist darauf hin, dass Datumsformate falsch erkannt werden können, einschließlich vertauschter Tag-Monat-Reihenfolgen, und empfiehlt, ein ISO-8601-Format zu prüfen oder festzulegen. Nehmen Sie mehrdeutige Daten wie 03/04/2024 in die Testdatei auf und prüfen Sie den gespeicherten Wert, nicht nur die Importvorschau.

Die Eigentümerschaft erfordert dieselbe Sorgfalt. EspoCRM kann beim Import Standardwerte, einschließlich Zugewiesenem Benutzer und Teams, auf neue und aktualisierte Datensätze anwenden. Testen Sie, ob der Quelleigentümer beibehalten, übersetzt, durch einen Standardwert ersetzt oder nicht gesetzt wird. Entscheiden Sie dann, welches Verhalten für jede Entität akzeptabel ist. Siehe die [EspoCRM-Importdokumentation](https://docs.espocrm.com/administration/import/).

• Erstellen Sie einen Datensatz mit einer bestehenden Quell-ID und geänderten Nicht-Schlüsseldaten; testen Sie den vorgesehenen Aktualisierungspfad.
• Erstellen Sie zwei Datensätze mit ähnlichen Namen, aber unterschiedlichen IDs; stellen Sie sicher, dass sie nicht versehentlich zusammengeführt werden.
• Testen Sie leere Felder in einer Aktualisierungsdatei, um festzustellen, ob sie bestehende Werte löschen, ignoriert werden oder die Validierung nicht bestehen.
• Testen Sie Formate für Datum, Zahl, Währung, Telefon und Mehrfachauswahl.
• Testen Sie einen Datensatz, dessen ursprünglicher Eigentümer im Ziel nicht mehr existiert.
• Prüfen Sie Eigentümer- und Teamwerte nach Erstellungs- und Aktualisierungsläufen.

Überprüfen Sie Beziehungen und Historie: Kontakte, Organisationen, Deals, Notizen, Aufgaben und Anhänge

Die Genauigkeit von Beziehungen entscheidet oft darüber, ob ein CRM nützlich ist oder nur ein Verzeichnis nicht verbundener Datensätze. Erstellen Sie Testfälle, in denen eine Organisation mehrere Kontakte hat, ein Deal mehrere zugehörige Personen hat und Datensätze ähnliche oder identische Anzeigenamen teilen. Prüfen Sie jede Beziehung von beiden Seiten in der Zieloberfläche.

Importieren Sie übergeordnete Entitäten vor untergeordneten Entitäten, wenn die Beziehung von zuvor importierten Datensätzen abhängt. SuiteCRM weist an, Accounts vor zugehörigen Kontakten zu importieren, damit die Beziehung hergestellt werden kann. Odoo dokumentiert ebenfalls, dass verknüpfte Objekte zuerst importiert werden sollen, wenn Beziehungen über externe IDs wiederhergestellt werden. Siehe die [SuiteCRM-Dokumentation zur Datensatzverwaltung](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/) und die [Odoo-Dokumentation zu Export und Import](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Verlassen Sie sich beim Abgleich von Beziehungen nicht auf Namen, wenn Mehrdeutigkeit möglich ist. Odoo warnt, dass Daten bei mehreren verknüpften Datensätzen mit demselben Namen möglicherweise mit dem ersten passenden Datensatz verknüpft werden. Verwenden Sie stabile Kennungen für Beziehungsfelder, wenn das Ziel sie unterstützt, und belegen Sie das Ergebnis mit absichtlich mehrdeutigen Testdatensätzen.

Anhänge und Aktivitätshistorie verdienen separate Abnahmetests. Bestätigen Sie, ob Dateien importiert, verknüpft, übersprungen werden oder ein separates produktspezifisches Verfahren benötigen. Gehen Sie nicht davon aus, dass der CSV-Importer für Kern-Datensätze auch Anhänge, Notizen, Aufgaben oder Historie importiert. Bestätigen Sie für jedes unterstützte Verfahren, dass Daten, Autoren, übergeordnete Datensätze und Berechtigungen angemessen sind.

• Importieren Sie Organisationen oder Accounts vor den zugehörigen Kontakten.
• Importieren Sie übergeordnete Deals oder Fälle vor ihren abhängigen Notizen und Aktivitäten, sofern das Modell dies erfordert.
• Verwenden Sie nach Möglichkeit Quell-IDs statt Anzeigenamen, um Datensätze zu verknüpfen.
• Prüfen Sie die Anzahl der Beziehungen und einzelne Verknüpfungen in der Anwendung.
• Öffnen Sie Beispielanhänge und überprüfen Sie ihre vorgesehene Datensatzzuordnung.
• Prüfen Sie Aktivitätsdaten, Ersteller, Zuständige und Sichtbarkeit.

Prüfen Sie, wie die Anwendung abgelehnte oder geänderte Datensätze meldet

Ein Importer, der nur eine Gesamtsumme am Ende meldet, lässt sich nur schwer sicher betreiben. Fordern Sie Nachweise für jede abgelehnte Zeile: ihre Quellzeile oder Kennung, den Grund des Fehlers und die bereitgestellten Werte. Fordern Sie außerdem eine Möglichkeit, neu erstellte Datensätze von Aktualisierungen und übersprungenen Zeilen zu unterscheiden.

EspoCRM bietet einen Fehlerbereich mit Fehlergrund, Zeilenindex und Zeilenwerten und kann fehlgeschlagene Zeilen zur Korrektur und zum erneuten Import in CSV exportieren. Die SuiteCRM-Dokumentation beschreibt ebenfalls einen Fehler-Tab zur Prüfung und Korrektur vor der erneuten Ausführung eines Imports. Betrachten Sie dies als nützliche Beispiele für die Nachweise, die Sie suchen sollten, und nicht als Annahme, dass jedes CRM identische Berichte bereitstellt. Siehe die [EspoCRM-Importdokumentation](https://docs.espocrm.com/administration/import/) und die [SuiteCRM-Dokumentation zur Datensatzverwaltung](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/).

Führen Sie einen Test mit gültigen Datensätzen, ungültigen Datensätzen und Aktualisierungskandidaten durch. Gleichen Sie die Quellanzahl mit den Ergebnissen für erstellte, aktualisierte, abgelehnte und übersprungene Datensätze ab. Jede nicht erklärte Abweichung ist ein nicht erfülltes Abnahmekriterium.

• Können Sie fehlgeschlagene Zeilen zur Korrektur exportieren?
• Identifiziert jeder Fehler eine Quellzeile oder eine stabile Quell-ID?
• Erklärt der Bericht den Fehler in operativen Begriffen?
• Können Sie Erstellungen, Aktualisierungen, Ablehnungen und Überspringen unterscheiden?
• Können Sie Zuordnungs- und Duplikatprüfeinstellungen für einen wiederholbaren Lauf speichern?
• Können Sie die resultierenden Datensätze direkt aus dem Importbericht prüfen?

Testen Sie Korrektur und erneuten Import, ohne Datensätze zu vervielfachen oder vertrauenswürdige Daten unbeabsichtigt zu überschreiben

Der wichtigste Importtest ist normalerweise der zweite. Korrigieren Sie eine begrenzte Menge abgelehnter Zeilen und importieren Sie die korrigierte Datei dann mit dem vorgesehenen Aktualisierungsmodus und den Abgleichregeln erneut. Bestätigen Sie, dass korrigierte Datensätze genau einmal erstellt oder aktualisiert werden, bereits erfolgreiche Datensätze nicht dupliziert werden und nicht betroffene Felder vertrauenswürdig bleiben.

Trennen Sie Erstellungsverhalten und Aktualisierungsverhalten in Ihren Abnahmekriterien. In EspoCRM erstellt „Nur erstellen“ Datensätze, während „Erstellen & Aktualisieren“ und „Nur aktualisieren“ ausgewählte Abgleichfelder verwenden, um Datensätze zur Aktualisierung zu finden. Ein Produktionsteam muss wissen, welchen Modus es für die Erstbeladung, Fehlerkorrektur und spätere inkrementelle Aktualisierungen verwenden wird. Siehe die [EspoCRM-Importdokumentation](https://docs.espocrm.com/administration/import/).

Testen Sie leere und geänderte Werte sorgfältig. Ein erneuter Import kann Informationen überschreiben, die nach dem ersten Import bearbeitet wurden, abhängig vom gewählten Modus und den Zuordnungen. Legen Sie ein Umstellungsfenster fest, bestimmen Sie für jedes Feld während der Migration das führende System und definieren Sie, ob Änderungen nach dem Import geschützt, überschrieben oder manuell abgeglichen werden.

Behalten Sie die stabile Quell-ID in jeder Korrekturdatei bei. Ändern Sie sie nicht nur, um einen Fehler verschwinden zu lassen; das kann eine beabsichtigte Aktualisierung in einen neuen Datensatz verwandeln. Odoo dokumentiert dieses Risiko für externe IDs. Siehe die [Odoo-Dokumentation zu Export und Import](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

• Führen Sie einen Erstimport durch und dokumentieren Sie erstellte IDs und Quell-IDs.
• Korrigieren Sie nur fehlgeschlagene Zeilen und behalten Sie deren ursprüngliche Kennungen bei.
• Importieren Sie erneut und vergleichen Sie die Datensatzanzahlen vor und nach dem Vorgang.
• Testen Sie bewusst einen geänderten Wert in einem bestehenden Datensatz.
• Testen Sie bewusst einen leeren Wert in einem bestehenden Datensatz.
• Prüfen Sie, ob Felder, die nach der Erstbeladung im CRM bearbeitet wurden, wie vorgesehen erhalten bleiben oder überschrieben werden.