Eine ERP-Testmigration mit eigenen Daten ist ein begrenzter Probelauf: Ausgewählte Altdaten werden vor dem formellen Integrationstest in das neue Zielsystem geladen. Dadurch können Key-User nicht nur Funktionen anklicken, sondern an vertrauten Materialien, Kunden und Vorgängen prüfen, ob Zielprozess und Mapping fachlich zusammenpassen.
Genau diese Prüfung fehlt, wenn das neue ERP nur fremde Beispieldaten zeigt. Die Key-User können Menüs öffnen und Standardabläufe ausprobieren, erkennen aber kaum, ob ihr tatsächliches Tagesgeschäft richtig abgebildet ist. Ein früher eigener Datenbestand schafft diesen Bezug, solange Mapping, Konfiguration und Importlogik noch ohne Zeitdruck korrigiert werden können.
Der Lauf darf dafür klein und ausdrücklich vorläufig sein. Entscheidend ist, dass die ausgewählten Daten für die Testumgebung freigegeben sind, fachlich zusammengehören und eine konkrete Prüffrage beantworten. Dann wird aus einem Vorabimport ein kontrollierter Lernlauf für Projektleitung, Key-User und Migrationsteam.
Warum eine ERP-Testmigration mit eigenen Daten mehr zeigt als Beispieldaten
Beispieldaten sind für Schulungen und erste Funktionstests nützlich. Sie zeigen, wo eine Eingabe erfolgt, welche Maske danach erscheint oder wie ein Standardprozess grundsätzlich abläuft. Für die fachliche Beurteilung fehlt ihnen jedoch häufig etwas Entscheidendes: Die Key-User kennen weder die Geschichte des angezeigten Datensatzes noch seine Bedeutung für das eigene Unternehmen.
Bei einem vertrauten Material erkennen sie dagegen sofort, welche Einheit verwendet wird, welche Merkmale dazugehören und mit welchen anderen Informationen es im Alltag verbunden ist. Bei einem bekannten Kunden fällt ihnen auf, ob Zahlungsbedingungen, Ansprechpartner oder Vertriebszuordnungen fehlen. Ein abstrakter Feldname bekommt dadurch eine konkrete Prozesswirkung.
Wenn Key-User mit Beispieldaten wenig belastbare Rückmeldung geben, ist das daher nicht automatisch ein Motivations- oder Schulungsproblem. Möglicherweise fehlt ihnen schlicht die fachliche Verbindung zwischen dem vorgeführten Zielsystem und ihrer bisherigen Arbeit.
Warum Zielsystemverständnis und Mapping voneinander abhängen
Damit eigene Daten im Testsystem erscheinen, muss bereits festgelegt sein, wie Informationen aus dem Altsystem in das neue ERP gelangen. Dieses Mapping beschreibt die Zuordnung und notwendige Veränderung der alten Werte. Für ein belastbares Mapping müssen die Fachbereiche wiederum verstehen, wie das neue System seine Felder und Prozesse tatsächlich verwendet.
Dadurch entsteht ein Kreislauf:
Ohne eigene Daten bleibt das Zielsystem abstrakt. Ohne ausreichendes Zielsystemverständnis bleibt das Mapping unsicher. Ohne Mapping können keine eigenen Daten sinnvoll geladen werden.
Der Kreislauf lässt sich nicht auflösen, indem eine Seite zuerst vollständig fertig werden muss. Stattdessen braucht das Projekt einen begrenzten Zwischenstand. Die ERP-Testmigration lädt dafür einen bewusst ausgewählten Datenbestand mit einem vorläufigen, aber nachvollziehbaren Mapping. Ihr Zweck ist noch keine Freigabe, sondern neues Wissen, das anschließend in Zielkonfiguration, Mapping und den nächsten Datenlauf zurückfließt.
Welche eigenen Daten in die frühe Testmigration gehören
Für diesen frühen Lauf ist kein vollständiger Kunden-, Lieferanten- oder Materialbestand nötig. Ein beliebiger kleiner Ausschnitt reicht allerdings ebenfalls nicht. Die Auswahl muss zu dem Prozess passen, den die Key-User beurteilen sollen.
Die Datensätze müssen vertraut sein. Der zuständige Fachbereich sollte die ausgewählten Materialien, Kunden oder Vorgänge fachlich kennen. Nur dann kann er Abweichungen erkennen, ohne parallel erst den Testfall recherchieren zu müssen.
Die notwendigen Beziehungen müssen enthalten sein. Ein einzelner Materialstamm genügt nicht, wenn der Test zusätzlich Einheiten, Klassifikationen, Stücklisten oder einen konkreten Vorgang benötigt. Der Datenbestand muss den betrachteten Prozess so weit zusammenhängend abbilden, dass das Zielsystem nicht nur einzelne Masken, sondern die benötigte Verbindung zeigen kann.
Normalfall und wichtige Abweichung gehören zusammen. Ein Standarddatensatz zeigt, ob der vorgesehene Weg grundsätzlich funktioniert. Mindestens eine für den Prozess wichtige Besonderheit zeigt, ob Mapping und Zielkonfiguration auch mit der tatsächlichen Vielfalt umgehen können. Welche Besonderheit relevant ist, entscheidet der Fachbereich – nicht eine allgemeine Testdatenliste.
Die Auswahl bleibt bewusst begrenzt. Ein aussagekräftiger Datenbestand muss hier nicht statistisch für alle Unternehmensdaten stehen. Er enthält vielmehr genau die fachlichen Beziehungen und Unterschiede, die für die konkrete Prüffrage benötigt werden. Dadurch bleibt der erste Lauf schnell korrigierbar und sein Ergebnis verständlich.
„Eigene Daten“ bedeutet dabei nicht automatisch, eine ungefilterte Kopie des Produktivsystems zu verwenden. Welche Datensätze in der Testumgebung zulässig sind und ob Werte zuvor begrenzt oder geschützt werden müssen, richtet sich nach den freigegebenen Regeln des Unternehmens.
Künstliche Testdaten und eigene Daten erfüllen verschiedene Aufgaben
Künstliche Testdaten sind gezielt angelegte Datensätze, mit denen sich ein bestimmter Normal- oder Fehlerfall kontrolliert auslösen lässt. Sie sind besonders hilfreich, wenn eine Funktion isoliert geprüft werden soll oder eine seltene Grenzsituation in den vorhandenen Unternehmensdaten nicht zuverlässig vorkommt.
Eigene migrierte Daten beantworten eine andere Frage. Sie zeigen, ob die tatsächlich gewachsenen Strukturen, Bedeutungen und Beziehungen des Unternehmens im neuen ERP richtig ankommen. Außerdem können Key-User vertraute Ergebnisse leichter beurteilen als erfundene Beispiele.
Deshalb ist die Entscheidung kein pauschales Entweder-oder. Ein künstlicher Datensatz kann beweisen, dass eine Funktion mit einem bewusst konstruierten Fall arbeitet. Ein kleiner eigener Datenbestand zeigt anschließend, ob Mapping, Transformation und Prozess auch unter den tatsächlichen Datenbedingungen zusammenpassen. Für einen späteren formellen Integrationstest kann beides erforderlich sein; eine vollständige Testdatenstrategie muss jedoch passend zu den vorgesehenen Tests festgelegt werden.
Warum der erste Ladevorgang eine Prüffrage statt einer Abnahme braucht
Eine ERP-Testmigration wird wertvoll, wenn vor dem Import klar ist, was das Projekt daraus lernen möchte. „Die Daten einmal ansehen“ ist dafür zu unbestimmt. Eine bessere Frage lautet beispielsweise: Kann der Key-User den ausgewählten Materialdatensatz im neuen Beschaffungsprozess vollständig verwenden, und welche fehlende oder falsch übersetzte Information verhindert das?
Damit sich das Ergebnis später einordnen lässt, sollten fünf Grundlagen festgehalten werden:
- welcher Prozess oder fachliche Zusammenhang geprüft wird,
- welche konkreten Quellobjekte und Datensätze ausgewählt wurden,
- welche Version von Mapping, Transformation und Importstruktur verwendet wurde,
- welches Ergebnis erwartet wird und wer es fachlich beurteilt,
- welche bekannten Lücken der frühe Stand noch enthält.
Diese Kennzeichnung verhindert, dass ein bewusst begrenzter Lernlauf später wie eine bereits abgenommene Migration behandelt wird. Zugleich macht sie eine Rückmeldung konkret: Der Key-User bewertet nicht „die Migration insgesamt“, sondern einen benannten Prozess auf einem bekannten Daten- und Regelstand.
Ein sichtbarer Fehler muss zuerst richtig zugeordnet werden
Eigene Daten machen Probleme sichtbar, nennen aber nicht automatisch deren Ursache. Wenn ein Wert fehlt oder ein Prozess nicht funktioniert, kommen mindestens vier unterschiedliche Ursachen infrage:
- Das Zielsystem ist noch nicht passend konfiguriert.
- Das Mapping oder die technische Transformation erzeugt einen falschen Zielwert.
- Die benötigte Information fehlt oder ist bereits im Altsystem uneindeutig.
- Der ausgewählte Datensatz deckt den vorgesehenen Testfall nicht vollständig ab.
Diese Unterscheidung ist wichtig, weil jede Ursache eine andere Reaktion verlangt. Eine Konfigurationsfrage gehört zum ERP-Partner. Eine fachliche Zuordnung benötigt die Entscheidung des zuständigen Fachbereichs. Eine fehlerhafte Transformation muss in der Migrationslogik korrigiert werden. Und ein unvollständiger Testfall braucht einen besser ausgewählten Datenbestand statt einer Änderung am System.
Wer alle Abweichungen lediglich als „Importfehler“ sammelt, vermischt diese Ursachen. Dann werden Mapping, Konfiguration und Datenqualität gleichzeitig verändert, ohne dass anschließend klar ist, welche Korrektur tatsächlich geholfen hat.
Die Rückmeldung muss in Mapping und nächsten Datenlauf zurückfließen
Der frühe Test endet nicht mit einer Liste von Beobachtungen. Jede relevante Rückmeldung braucht einen Bezug zum betroffenen Datensatz, zum erwarteten Ergebnis und zur verwendeten Regel. Danach wird entschieden, ob Zielkonfiguration, Mapping, Transformation, Quellauswahl oder Testfall angepasst werden muss.
Erst wenn diese Entscheidung dokumentiert und im nächsten Datenlauf erneut geprüft wird, entsteht aus dem Test ein belastbarer Fortschritt. Unser Beitrag zum Datenmapping im ERP-Projekt zeigt ausführlicher, wie fachliche Zuordnungen und technische Regeln nachvollziehbar verbunden werden.
Der Ablauf bleibt dabei bewusst klein:
Auswählen → vorläufig zuordnen → laden → mit Key-Usern prüfen → Ursache entscheiden → Regel anpassen → erneut laden.
Mit jeder Schleife verbessert sich nicht nur die Datei. Auch das Verständnis des Zielsystems und die Qualität der fachlichen Entscheidungen wachsen. Deshalb beantwortet ein Datenlauf mehr als eine rein technische Importfrage.
Wann der frühe Test mit eigenen Daten sinnvoll beginnen kann
Das vollständige Zielsystem und das endgültige Mapping sind keine Voraussetzung. Der frühe Lauf kann beginnen, wenn der betrachtete Zielprozess praktisch aufrufbar ist, eine verwendbare Importstruktur vorliegt, ein begrenzter eigener Datenbestand ausgewählt wurde und ein Key-User die konkrete Prüffrage beurteilen kann. Offene Annahmen müssen dabei sichtbar bleiben.
Fehlt dagegen noch der Importweg oder ist nicht klar, wofür das Datenobjekt im Zielsystem gebraucht wird, würde ein früher Ladevorgang nur neue Unklarheit erzeugen. Dann sollte das Projekt zuerst genau diese Grundlage mit dem ERP-Partner klären. Wie sich diese Entscheidung in den Gesamtstart der Migration einordnet, erläutert unser Beitrag Wann sollte die Datenmigration beim ERP-Wechsel beginnen?
Wir können den frühen Datenlauf operativ vorbereiten: geeignete Quelldatensätze untersuchen, einen belegten Mappingvorschlag erstellen, Transformationen wiederholbar umsetzen und die Ergebnisse für die fachliche Prüfung nachvollziehbar bereitstellen. Die Entscheidung über Zielprozess, zulässige Testdaten und fachliche Freigabe bleibt beim Unternehmen und den jeweils verantwortlichen Stellen.
Key-User sollten ihre eigenen Daten daher nicht erst im formellen Integrationstest sehen. Ein kleiner, gezielt ausgewählter Datenbestand schafft früher die Verbindung zwischen abstrakter Zielstruktur und tatsächlichem Tagesgeschäft. Wie viele weitere Testmigrationen sinnvoll sind, entscheidet danach nicht ein fester Standard, sondern die noch offene Unsicherheit – das vertieft unser Beitrag über Testmigrationen im ERP-Projekt.