Das neue ERP benötigt eine Information oder sogar ein vollständiges Datenobjekt. Im Altsystem ist davon auf den ersten Blick nichts zu finden. Damit steht das Projekt vor einer unangenehmen Frage: Muss der gesamte Bestand nun von Hand neu angelegt werden?
Bei fehlenden Daten in einer ERP-Migration sollte zuerst geklärt werden, welche Art von Lücke tatsächlich vorliegt. Die Information kann nur anders heißen, auf mehrere Tabellen verteilt sein, aus vorhandenen Beziehungen ableitbar sein, in einem weiteren System liegen oder wirklich nie erfasst worden sein. Erst danach lässt sich seriös zwischen Rekonstruktion, kontrollierter Anreicherung, fachlicher Neuanlage, einer Änderung der Zielanforderung und einem bewussten Ausschluss entscheiden.
Diese Reihenfolge ist wichtig. Denn eine Migration kann vorhandene Informationen überführen und nach bestätigten Regeln umformen. Was fachlich niemals existiert hat, kann sie dagegen nicht wahrheitsgemäß erfinden.
Fehlende Daten bei der ERP-Migration: Die kurze Antwort
Wenn Daten im Altsystem fehlen, braucht das Projekt nicht sofort mehr Handarbeit, sondern zunächst einen belastbaren Befund. Dafür werden fünf Fragen nacheinander beantwortet:
- Wofür wird die Information im neuen Geschäftsprozess benötigt?
- Ist sie im Altsystem wirklich nicht vorhanden oder nur anders gespeichert?
- Lässt sie sich eindeutig aus vorhandenen Daten ableiten?
- Gibt es eine verlässliche ergänzende Quelle?
- Welche fachliche Entscheidung gilt, wenn die Information tatsächlich fehlt?
Das Ergebnis ist kein pauschales „vorhanden“ oder „fehlt“. Ein Datenobjekt kann für einen Teil des Bestands direkt aufgebaut werden, für einen weiteren Teil eine Ergänzung benötigen und bei einzelnen Datensätzen ungeklärt bleiben. Genau diese Teilmengen müssen getrennt sichtbar werden.
Zuerst prüfen: Braucht das neue ERP diese Information wirklich?
Dass eine Importvorlage ein Feld oder ein Tabellenblatt anbietet, bedeutet noch nicht automatisch, dass es für jeden Datensatz und jeden Geschäftsprozess benötigt wird. Manche Angaben werden erst durch eine bestimmte Zielkonfiguration, Organisationsebene oder gewählte Funktion verpflichtend. Andere gehören zwar zum möglichen Zielobjekt, aber nicht zum vereinbarten Migrationsumfang.
Vor jeder Quellsuche sollte das Zielsystemteam deshalb konkret beantworten:
- Welcher Prozess kann ohne diese Information nicht funktionieren?
- Für welche Datensätze wird sie benötigt?
- Ist sie technisch verpflichtend oder fachlich nur wünschenswert?
- Welche Werte und Beziehungen akzeptiert das konfigurierte Zielsystem?
- Kann die Information nach dem Go-live ergänzt werden, oder muss sie vor dem ersten Geschäftsvorgang vorhanden sein?
Dadurch wird aus „Das Ziel verlangt diese Daten“ eine prüfbare Anforderung. Stellt sich heraus, dass eine unnötig aktivierte Zielstruktur die Pflicht erst erzeugt, ist das keine Datenlücke, die mit erfundenen Werten geschlossen werden sollte. Dann müssen Fachbereich und ERP-Partner die Zielentscheidung überprüfen.
Nicht gefunden ist noch nicht nicht vorhanden
Alte ERP-Systeme bilden fachliche Zusammenhänge häufig anders ab als neue. Ein Objekt, das im Ziel eine eigene Importstruktur besitzt, muss im Altsystem weder denselben Namen tragen noch in einer einzigen Tabelle liegen.
Deshalb unterscheiden wir vier Befunde:
| Befund | Was dahintersteckt | Nächster Schritt |
|---|---|---|
| Anders benannt | Die Information existiert, wird im Altsystem aber unter einer historischen oder unternehmensspezifischen Bezeichnung geführt. | Bedeutung mit Datenwerten, Oberfläche und Fachbereich belegen. |
| Verteilt gespeichert | Das Zielobjekt setzt sich aus mehreren Tabellen, Schlüsseln oder abhängigen Datensätzen zusammen. | Beziehungen technisch nachweisen und die Zielstruktur reproduzierbar erzeugen. |
| Außerhalb des ERP vorhanden | Die maßgebliche Information liegt beispielsweise in einer Fachanwendung, einer kontrollierten Liste oder einem anderen freigegebenen Datenbestand. | Quelle, Verantwortlichkeit, Schlüssel und Datenstand verbindlich festlegen. |
| Tatsächlich nicht erfasst | Die Information wurde nie gepflegt und kann weder belegt noch eindeutig abgeleitet werden. | Fachlich neu festlegen, gezielt erheben, betroffene Datensätze ausschließen oder die Lücke als Blocker behandeln. |
Der Beitrag über die Ablösung eines schlecht dokumentierten Altsystems zeigt ausführlicher, wie technische Struktur, Wertemuster, bisherige Nutzung und Zielanforderung gemeinsam einen belastbaren Datenweg ergeben.
Was bedeutet es, wenn ein vollständiges Datenobjekt fehlt?
Ein Datenobjekt ist hier die zusammengehörige fachliche Einheit, die das neue ERP benötigt – beispielsweise mit Kopf, Positionen, Gültigkeiten und Beziehungen. Das Zielsystem definiert diese Einheit möglicherweise anders als das Altsystem.
Genau deshalb darf die Suche nicht bei einem gleichnamigen Tabellen- oder Menüpunkttreffer enden. Wenn das Ziel etwa eine strukturierte Beziehung erwartet, können ihre Bestandteile trotzdem vorhanden sein: Identitäten in einer Tabelle, Mengen in einer zweiten und Gültigkeiten in einer dritten. Aus der Verbindung entsteht dann erst bei der Transformation das benötigte Zielobjekt.
Die Stücklistenmigration ist ein anschauliches Beispiel dafür. Der allgemeine Grundsatz gilt aber ebenso für andere zusammengesetzte Stammdaten, Organisationszuordnungen oder offene Vorgänge: Die Quellstruktur muss nicht wie die Zielstruktur aussehen. Entscheidend ist, ob die benötigte fachliche Aussage aus den vorhandenen Daten belegbar aufgebaut werden kann.
So wird bewiesen, ob eine Information wirklich fehlt
Eine ergebnislose Suche nach einem Feldnamen ist kein Beweis. Vor der Einstufung als echte Datenlücke sollten vier Perspektiven zusammengeführt werden.
Technische Struktur
Tabellen, Felder, Datentypen, Schlüssel, Indizes und dokumentierte Beziehungen zeigen, welche Informationen grundsätzlich gespeichert werden. Bei unklaren Namen helfen Wertemuster und wiederkehrende Schlüssel dabei, mögliche Zusammenhänge einzugrenzen.
Bisherige Nutzung
Keyuser können zeigen, wo die Information im Arbeitsablauf sichtbar wurde, wodurch sie beeinflusst wurde und für welche Ausgaben oder Entscheidungen sie verwendet wurde. Daraus entsteht eine technische Suchspur. Eine Aussage aus der Bedienoberfläche ersetzt den Datenbanknachweis nicht, gibt ihm aber fachlichen Kontext.
Weitere Unternehmensquellen
Nicht jede maßgebliche Information liegt im ERP. Je nach Unternehmenslandschaft können freigegebene Fachanwendungen, dokumentierte Exporte oder kontrollierte Ergänzungslisten relevant sein. Eine gefundene Datei ist jedoch noch keine verlässliche Quelle. Ihr Stand, ihre Vollständigkeit und die verantwortliche Stelle müssen nachvollziehbar sein.
Zielanforderung
Erst die konkrete Zielbedeutung zeigt, ob ein Quellwert tatsächlich passt. Ein ähnlich benanntes Feld kann eine andere fachliche Aussage besitzen. Umgekehrt kann ein Zielwert aus mehreren Quellmerkmalen entstehen, wenn die Ableitung eindeutig ist und vom Fachbereich bestätigt wird.
Erst wenn diese vier Prüfungen keine tragfähige Quelle oder Ableitung ergeben, sollte die Information als tatsächlich fehlend behandelt werden.
Weg 1: Vorhandene Beziehungen zu einem Zielobjekt rekonstruieren
Ist die benötigte Information indirekt vorhanden, wird sie nicht manuell neu angelegt. Stattdessen entsteht eine dokumentierte Transformationsregel. Sie beschreibt, welche Quelltabellen verbunden werden, welche Datensätze dazugehören, wie Mehrdeutigkeiten behandelt werden und welche Zielstruktur daraus entsteht.
Ein belastbarer Nachweis umfasst mindestens:
- die verwendeten Quellschlüssel und Beziehungen,
- die Auswahl- und Ausschlussregeln,
- bekannte Ausnahmen,
- die erzeugte Zielstruktur,
- sowie fachlich bekannte Beispiele, an denen die Herleitung geprüft wird.
Die Regel sollte bei einem neuen Datenstand erneut ausführbar sein. Eine einmal manuell zusammengesetzte Importdatei beweist dagegen nicht, dass der nächste Testlauf vollständig und gleichartig erzeugt werden kann.
Weg 2: Fehlende Informationen aus einer weiteren Quelle ergänzen
Liegt die Information außerhalb des Altsystems, kann sie kontrolliert in die Migration einfließen. Dafür braucht die Ergänzungsquelle mehr als passende Spalten. Sie benötigt einen eindeutigen Bezug zum Quellobjekt, einen dokumentierten Datenstand und eine Person oder Stelle, die ihren Inhalt verantwortet.
Eine Ergänzungsliste sollte deshalb mindestens enthalten:
- den stabilen Schlüssel des betroffenen Datensatzes,
- den zu ergänzenden Wert,
- die Herkunft oder fachliche Begründung,
- den Bearbeitungs- und Freigabestatus,
- sowie gegebenenfalls einen Gültigkeitszeitpunkt.
Diese Liste wird nicht nachträglich in eine fertige CSV kopiert. Sie wird als definierte Quelle in die wiederholbare Transformation eingebunden. Dadurch bleibt sichtbar, welcher Zielwert direkt aus dem ERP stammt und welcher fachlich ergänzt wurde.
Weg 3: Neue Zielwerte regelbasiert festlegen
Das neue ERP kann eine Klassifikation oder Organisationszuordnung verlangen, die es im Altsystem in dieser Form nie gab. Dann handelt es sich nicht um eine klassische Übernahme, sondern um eine neue fachliche Festlegung.
Eine solche Festlegung kann trotzdem effizient umgesetzt werden, wenn sich klare Regeln bestätigen lassen. Beispielsweise kann eine definierte Kombination vorhandener Merkmale genau einem neuen Zielwert entsprechen. Entscheidend ist, dass die Regel nicht nur technisch plausibel, sondern fachlich beschlossen ist.
Für jeden regelbasiert erzeugten Wert sollte deshalb erkennbar bleiben:
- welche Quellmerkmale die Entscheidung auslösen,
- welcher Zielwert daraus entsteht,
- für welche Teilmenge die Regel gilt,
- welche Fälle ausgenommen sind,
- und wer die Regel bestätigt hat.
Das verwandte Problem einzelner Zielpflichtfelder behandelt unser Beitrag ERP-Migration: Pflichtfelder fehlen im Detail.
Weg 4: Die verbleibenden Fälle gezielt manuell erheben
Manuelle Ergänzung ist sinnvoll, wenn eine benötigte Information wirklich fehlt, keine verlässliche Regel existiert und die betroffene Menge überschaubar bleibt. Sie sollte jedoch erst nach der technischen und fachlichen Analyse beginnen. Sonst bearbeiten Fachbereiche auch Datensätze, die sich automatisch rekonstruieren oder gar nicht migrieren lassen müssen.
Die manuelle Arbeit wird auf eine konkrete Ausnahmeliste begrenzt. Jede Zeile enthält die benötigte Entscheidung, den eindeutigen Datensatzbezug und eine Prüfung auf zulässige Zielwerte. So beantwortet der Fachbereich eine fachliche Frage, statt eine unstrukturierte Rohdatenmenge Zeile für Zeile zu durchsuchen.
Wenn hingegen ein vollständiger, geschäftskritischer Objektbestand neu erhoben werden müsste, ist das kein kleines Bereinigungspaket mehr. Dann braucht das Projekt einen eigenen Umfang mit Verantwortlichen, Kapazität, Termin und Abnahmeregeln.
Weg 5: Ausschließen, Zielanforderung ändern oder den Go-live blockieren
Nicht jede Lücke darf und nicht jede Lücke muss geschlossen werden. Die Entscheidung hängt davon ab, was nach dem Go-live mit dem betroffenen Datensatz geschehen soll.
| Situation | Vertretbare Entscheidung |
|---|---|
| Der Datensatz wird im neuen Prozess nicht benötigt. | Nach bestätigter Scope-Regel ausschließen und die ausgeschlossene Menge nachweisen. |
| Die Zielanforderung entsteht nur durch eine noch veränderbare Konfiguration. | Fachbereich und ERP-Partner prüfen, ob die Zielentscheidung angepasst werden sollte. |
| Die Information kann nach dem Start verantwortbar ergänzt werden. | Übergangsweg, Frist, Verantwortlichkeit und Einschränkung im Zielprozess festlegen. |
| Ohne die Information funktioniert ein geschäftskritischer Startprozess nicht. | Die Lücke bleibt ein sichtbarer Go-live-Blocker, bis eine belastbare Quelle oder fachliche Neuanlage vorliegt. |
Ein Ausschluss ist nur dann sauber, wenn er bewusst entschieden und quantitativ belegt wird. Eine kleinere Importmenge darf nicht versehentlich als vollständiger Erfolg gelten.
Warum pauschale Standardwerte und „später nachpflegen“ oft scheitern
Ein Standardwert kann für eine klar abgegrenzte Teilmenge richtig sein. Problematisch wird er, wenn er lediglich eine Fehlermeldung beseitigt. Dann sieht die Importdatei vollständig aus, obwohl die fachliche Lücke nur verdeckt wurde.
Auch „Wir laden erst einmal alles, den Rest pflegen wir später nach“ kann in begrenzten Fällen funktionieren. Dafür muss aber feststehen, dass der Zielprozess bis zur Ergänzung sicher eingeschränkt werden kann, die offenen Fälle auffindbar bleiben und jemand die Nachpflege verbindlich übernimmt. Fehlen diese Voraussetzungen, wandert die ungeklärte Datenlücke aus dem Projekt in den Produktivbetrieb.
Ebenso vorschnell wäre eine vollständige manuelle Neuanlage. Sie ist erst dann gerechtfertigt, wenn die Informationen nachweislich nicht rekonstruierbar sind und ihr Nutzen den Erfassungsaufwand trägt.
Eine Datenlücken-Matrix hält die Entscheidung je Teilmenge fest
Damit unterschiedliche Lücken nicht in E-Mails und Importfehlern verschwinden, kann das Projekt eine kompakte Datenlücken-Matrix führen. Gemeint ist eine Tabelle, die pro benötigter Information oder Objektteilmenge den Befund und den beschlossenen Weg festhält.
Sinnvolle Spalten sind:
- Zielobjekt und konkret benötigte Zielinformation,
- betroffener Prozess und Kritikalität zum Go-live,
- Quellbefund: direkt, verteilt, ableitbar, extern vorhanden oder tatsächlich fehlend,
- betroffene Datensatzmenge,
- beschlossener Weg und verantwortliche Stelle,
- Herkunftsart des späteren Zielwerts,
- Termin und offener Entscheidungsstatus,
- sowie Prüfkriterium und Ergebnis des nächsten Testlaufs.
Diese Übersicht verbindet technische Analyse und Projektentscheidung. Die IT sieht, welche Quellen noch untersucht werden müssen. Der Fachbereich erkennt die begrenzten Fälle, für die eine Aussage benötigt wird. Die Projektleitung erkennt sofort, welche Lücke den Go-live gefährdet.
Der erste Test sollte alle fünf Wege sichtbar machen
Ein kleiner Prototyp ist aussagekräftiger als eine große Datei, in der unterschiedliche Herkunftsarten vermischt sind. Für ein priorisiertes Datenobjekt sollte der Test deshalb bewusst Fälle enthalten, die direkt übernommen, aus Beziehungen rekonstruiert, aus einer Zusatzquelle ergänzt, neu festgelegt oder ausgeschlossen werden.
Nach dem Import werden nicht nur Fehlermeldungen geprüft. Das Projekt gleicht ab:
- ob jede beschlossene Teilmenge vollständig behandelt wurde,
- ob rekonstruierte Beziehungen im Ziel fachlich stimmen,
- ob Ergänzungswerte genau den vorgesehenen Datensätzen zugeordnet sind,
- ob ausgeschlossene Fälle im Mengennachweis auftauchen,
- und ob der betroffene Geschäftsprozess mit dem Ergebnis funktioniert.
Der Beitrag zur Datenvalidierung bei der ERP-Migration erläutert, wie technische, mengenmäßige und fachliche Nachweise vor einer Abnahme zusammenkommen.
Wer entscheidet, was aus einer echten Datenlücke wird?
Das Zielsystemteam erklärt, welche Struktur und welche Pflichtangaben das konfigurierte ERP tatsächlich benötigt. Die interne IT und gegebenenfalls der bisherige Anbieter machen vorhandene Quellen zugänglich. Der Fachbereich entscheidet, welche Bedeutung, Ableitung oder Neuanlage fachlich richtig ist. Die Projektleitung priorisiert Aufwand und Go-live-Auswirkung.
Wir können als externer Datenmigrationsdienstleister die Quellstrukturen untersuchen, indirekte Informationen rekonstruieren, ergänzende Datenstände kontrolliert verbinden, die unterschiedlichen Herkunftsarten dokumentieren und beschlossene Regeln reproduzierbar umsetzen. Was eine neue fachliche Wahrheit sein soll, entscheiden wir jedoch nicht anstelle des Unternehmens.
Eine echte Datenlücke ist eine Entscheidung – kein leerer Tabellenplatz
Wenn das Altsystem ein benötigtes Objekt nicht unter demselben Namen führt, ist die Information noch nicht verloren. Häufig steckt sie in Beziehungen, weiteren Quellen oder einer anderen historischen Logik. Erst eine zielorientierte Analyse trennt diesen Fall von Daten, die tatsächlich nie erfasst wurden.
Bleibt danach eine echte Lücke, muss sie offen behandelt werden: regelbasiert neu festlegen, kontrolliert ergänzen, bewusst ausschließen oder als Startvoraussetzung lösen. So entsteht kein künstlich vollständiger Datenbestand, sondern eine nachvollziehbare Grundlage, mit der das neue ERP zuverlässig arbeiten kann.