Bei einer GUS-ERP-Einführung wird die Datenmigration leicht auf eine technische Übergabe reduziert: Der Implementierungspartner stellt Importstrukturen bereit, die Fachbereiche sollen ihre Daten liefern und irgendwann beginnt der erste Ladelauf. Was dazwischen geschehen muss, bleibt häufig unscharf. Genau dort entstehen später Zeitdruck, manuelle Nacharbeit und schwer erklärbare Abweichungen.
Eine belastbare GUS ERP Datenmigration braucht deshalb mehr als korrekt gefüllte Dateien. Sie braucht einen entschiedenen Datenumfang, ein nachvollziehbares Mapping, reproduzierbare Transformationen, mehrere echte Testläufe und eine fachliche Abnahme im Zielsystem. Erst das Zusammenspiel dieser Bausteine macht aus einer Datenübertragung eine kontrollierte Migration.
Dieser Beitrag richtet sich an ERP-Projektleitungen, IT-Verantwortliche und Fachbereiche, die eine Einführung der GUS-OS Suite vorbereiten oder bereits mitten im Projekt stehen. Er zeigt, welche Arbeit vor dem GUS-Datenmigrationsleitstand geleistet werden muss, wie sich auch große Datenmengen beherrschbar aufbereiten lassen und wann externe Unterstützung die Einführung tatsächlich entlastet.
Die eigentliche Herausforderung liegt vor dem ersten Import
Das Zielsystem kann nur verarbeiten, was ihm in der erwarteten Struktur übergeben wird. Es weiß aber nicht, welche Datensätze aus dem Altsystem für den künftigen Betrieb benötigt werden, was ein historisch gewachsenes Feld fachlich bedeutet oder welche widersprüchlichen Informationen aus mehreren Quellen gelten sollen.
Vor dem ersten Import müssen deshalb mindestens fünf Ergebnisse vorliegen:
- ein abgegrenzter Umfang aus Migrationsobjekten und relevanten Datensätzen,
- eine belastbare Beschreibung der Quellen einschließlich Tabellen, Dateien und Abhängigkeiten,
- fachlich entschiedene Mapping- und Transformationsregeln,
- technisch reproduzierbare Übergabedaten für den vorgesehenen GUS-Ladeweg,
- Prüfregeln, mit denen Quelle, Übergabestand und Ziel miteinander abgeglichen werden.
Fehlt einer dieser Bausteine, wird das Problem meist in den Import verschoben. Eine Fehlermeldung zeigt dann zwar, dass ein Wert nicht verarbeitet werden konnte. Sie beantwortet aber noch nicht, ob die Ursache in der Quelle, im Mapping, in einer Transformationsregel, in der Zielkonfiguration oder in der Reihenfolge der Objekte liegt.
Was die GUS-OS Suite leistet – und was das Migrationsprojekt liefern muss
Die GUS-OS Suite ist auf Unternehmen der Prozessindustrie ausgerichtet. Entsprechend können neben klassischen ERP-Stammdaten auch anspruchsvolle Zusammenhänge rund um Produkte, Rezepturen, Chargen, Qualität und regulatorische Informationen relevant sein. Welche Objekte und Importmöglichkeiten tatsächlich zur Verfügung stehen, muss für die konkrete Zielversion und Projektkonfiguration mit dem GUS-Implementierungspartner geklärt werden.
Der im Projekt vorgesehene Ladeweg – beispielsweise über den GUS-Datenmigrationsleitstand – übernimmt die technische Verarbeitung der vorbereiteten Daten. Das ist ein zentraler Teil der Ausführung. Die fachliche und technische Vorbereitung davor bleibt jedoch Projektarbeit:
| Der GUS-Ladeweg benötigt | Das Migrationsprojekt muss erarbeiten |
|---|---|
| definierte Zielstrukturen und zulässige Werte | die Zuordnung aus den tatsächlichen Quellfeldern und Altsystemwerten |
| vollständige Pflichtangaben | Regeln für fehlende, widersprüchliche oder nachzuliefernde Informationen |
| technisch gültige Übergabedaten | Extraktion, Bereinigung, Transformation und Formatierung |
| eine verarbeitbare Objekt- und Ladereihenfolge | Abhängigkeiten zwischen Stammdaten, Strukturen, Beständen und Bewegungsdaten |
| einen ausführbaren Ladelauf | fachliche Prüfungen und eine nachvollziehbare Abnahme im Zielprozess |
Diese Grenze ist für die Beauftragung wichtig. Ein ERP-Implementierungspartner kann das Zielsystem und seine Importanforderungen erklären. Ein Datenmigrationsspezialist muss zusätzlich das Altsystem erschließen, die Übergabelogik aufbauen und beide Seiten so miteinander verbinden, dass Fehler reproduzierbar behoben werden können.
Der passende Datenumfang für die GUS-Einführung
Eine GUS-Datenmigration sollte nicht mit der Forderung beginnen, „alle Daten“ zu übernehmen. Zuerst wird je Datenobjekt entschieden, was am ersten produktiven Tag im neuen System wirklich benötigt wird. Dazu gehören typischerweise ausgewählte Stamm- und Strukturdaten, Anfangsbestände und die für den Betriebsstart notwendigen offenen Vorgänge. Historische Informationen können je nach Nutzungs-, Nachweis- und Auskunftsbedarf ebenfalls relevant sein, müssen aber nicht zwangsläufig vollständig in das operative Zielsystem geladen werden.
Für jedes Objekt sind fünf Fragen zu beantworten:
- Welche Datensätze sind noch aktiv oder für den Start erforderlich?
- Welche Beziehungen zu anderen Objekten müssen erhalten bleiben?
- Welche Historie wird operativ gebraucht und welche kann in einem lesbaren Archiv verbleiben?
- Welche Informationen fehlen im Altsystem und müssen aus weiteren Quellen ergänzt werden?
- Wer entscheidet fachlich über Ausschluss, Bereinigung und Zielwert?
Diese Entscheidung verhindert zwei gegensätzliche Fehler: Ein zu großer Umfang belastet Analyse, Transformation und Tests mit Daten, die im neuen System keinen Nutzen haben. Ein zu kleiner Umfang führt nach dem Go-live zu fehlenden Auskünften, unvollständigen Prozessen oder hektischen Nachlieferungen. Eine ausführlichere Entscheidungshilfe bietet unser Beitrag Welche Daten beim ERP-Wechsel ins neue System gehören.
Ein belastbarer technischer Weg in die GUS-OS Suite
Die technische Umsetzung sollte so klein wie möglich und so kontrolliert wie nötig sein. Bei einem relational aufgebauten Altsystem kann ein freigegebener, lesender Datenbankzugriff sehr effizient sein. SQL macht sichtbar, aus welchen Tabellen und Feldern ein Zielwert entsteht, welche Filter gelten und welche Datensätze ausgeschlossen werden. Fehlt ein geeigneter Datenbankzugriff, können dokumentierte Exporte, Schnittstellen oder vom Altsystemanbieter bereitgestellte Auszüge dieselbe Rolle übernehmen.
Ein praxistauglicher Ablauf sieht so aus:
- Quellstrukturen analysieren: Tabellen, Schlüssel, Wertebereiche und Beziehungen werden nicht anhand von Feldnamen geraten, sondern mit Metadaten und realen Datenprofilen verifiziert.
- Rohdaten reproduzierbar extrahieren: Der Datenstand eines Testlaufs muss erneut erzeugt und mit späteren Ständen verglichen werden können.
- Ergänzende Quellen kontrolliert einbinden: Excel-Listen und weitere Dateien erhalten eindeutige Schlüssel, Verantwortliche und einen dokumentierten Stand.
- Transformationen umsetzen: Schlüssel werden übersetzt, Formate vereinheitlicht, Werte bereinigt und fachlich freigegebene Regeln technisch ausgeführt.
- GUS-Übergabedaten erzeugen: Das Ergebnis wird exakt in der für das Zielobjekt erwarteten Struktur bereitgestellt.
- Laden, auswerten und korrigieren: Rückmeldungen aus dem GUS-Lauf werden zur Ursache in Quelle, Regel oder Zielkonfiguration zurückverfolgt.
- Quelle und Ziel abgleichen: Mengen, Werte und Geschäftsbeziehungen werden unabhängig vom reinen Importstatus geprüft.
Manuelle Tabellenarbeit verschwindet dadurch nicht vollständig. Fachbereiche müssen weiterhin Entscheidungen treffen und inhaltliche Ergänzungen liefern. Der Unterschied liegt darin, dass diese Arbeit nicht bei jedem Testlauf von vorn beginnt. Einmal entschiedene Regeln werden reproduzierbar angewendet; offene Fragen bleiben sichtbar und prüfbar.
Warum frühe echte Testläufe so viel verändern
Eine Feldliste oder eine Mapping-Tabelle zeigt noch nicht, ob die Migration funktioniert. Erst ein realer Testlauf verbindet Quelle, Transformation, Zielstruktur und fachliche Prüfung. Deshalb sollten erste Objekte nicht erst dann geladen werden, wenn das gesamte Mapping vermeintlich fertig ist.
Ein früher, bewusst begrenzter Ladelauf beantwortet konkrete Fragen:
- Sind die Schlüssel und abhängigen Objekte in der richtigen Reihenfolge vorhanden?
- Welche Pflichtfelder fehlen tatsächlich?
- Welche Zielwerte und Formate akzeptiert die konfigurierte GUS-Umgebung?
- Kann der Fachbereich die geladenen Daten im vorgesehenen Geschäftsprozess prüfen?
- Wie lange benötigen Extraktion, Transformation, Import und Kontrolle?
Danach folgt kein einmaliges „Fehler beheben“, sondern ein gesteuerter Zyklus: Datenstand erzeugen, laden, technische Rückmeldungen auswerten, fachlich prüfen, Regeln korrigieren und erneut laden. Unser Fahrplan für die ERP-Datenmigration ordnet diese Iterationen in den gesamten Projektverlauf bis zum Go-live ein.
Welche Prüfungen über einen erfolgreichen Import hinausgehen
Eine grüne technische Meldung beweist nur, dass das Zielsystem die übergebenen Daten verarbeitet hat. Für die Abnahme muss zusätzlich feststehen, ob die richtigen Daten vollständig und fachlich nutzbar angekommen sind.
Die Prüfungen sollten zum jeweiligen Objekt passen:
- Mengen: Wie viele aktive Quellsätze wurden erwartet, übergeben, geladen, abgelehnt oder bewusst ausgeschlossen?
- Werte: Stimmen beispielsweise Bestandsmengen, Summen, Einheiten oder relevante Statistikwerte zwischen den definierten Vergleichsständen?
- Beziehungen: Sind abhängige Informationen den richtigen Artikeln, Kunden, Lieferanten, Lagerorten oder Strukturen zugeordnet?
- Regeln: Wurden Wertemappings, Standardwerte und Bereinigungen vollständig angewendet?
- Geschäftsprozesse: Können Key User mit den migrierten Daten die vorgesehenen Abläufe im Zielsystem tatsächlich durchführen?
Technische SQL-Prüfungen und fachliche Tests ergänzen sich dabei. SQL kann große Datenmengen vollständig vergleichen und Auffälligkeiten gezielt sichtbar machen. Der Fachbereich entscheidet, ob das Ergebnis inhaltlich richtig und im künftigen Prozess verwendbar ist.
Was reale GUS-Projekterfahrung über Skalierung zeigt
Bei der Einführung von GUS ERP bei der Mellerud Chemie GmbH wurde die Datenmigration als eigenständiger Arbeitsumfang strukturiert. Rund 15 Datenobjekte waren direkt aus dem Altsystem zu übernehmen. Zusätzlich mussten Informationen aus etwa 20 Excel-Listen kontrolliert angereichert werden. Zu den Daten gehörten unter anderem Artikel-, Stücklisten-, Kunden-, Lieferanten-, Bestands- und Statistikdaten.
Allein die Verkaufsstatistik umfasste mehr als sieben Millionen Datensätze. Die Menge war technisch beherrschbar, weil Extraktion und Transformation automatisiert wurden. Entscheidend war nicht, Millionen Zeilen manuell zu kontrollieren, sondern Regeln reproduzierbar anzuwenden, vollständige Prüfungen zu automatisieren und Auffälligkeiten gezielt zur fachlichen Bewertung vorzulegen.
Gleichzeitig arbeiteten 32 Key User an Pflichtfeldern, Mapping-Regeln und fachlichen Prüfungen mit. Die Daten wurden mit SQL, Python und OpenRefine aufbereitet und anschließend über den GUS-Datenmigrationsleitstand in iterativen Zyklen geladen. Frühe reale Ergebnisse machten offene Entscheidungen sichtbar, bevor sie den Go-live gefährden konnten. Die Migration wurde erfolgreich umgesetzt und schuf eine belastbare Datenbasis für den Betriebsstart.
Dieser Projektnachweis ist kein allgemeines Versprechen für jeden Umfang oder Termin. Er zeigt aber, welche Fähigkeiten für eine GUS ERP Datenmigration entscheidend sind: große Datenmengen technisch beherrschen, zusätzliche Quellen sauber integrieren, viele Fachbeteiligte entscheidungsfähig halten und Ladezyklen bis zur nachvollziehbaren Abnahme führen.
Wer im GUS-Projekt welche Verantwortung tragen sollte
Eine gute Aufgabenteilung vermeidet sowohl Lücken als auch Doppelarbeit. Drei Rollen müssen zusammenspielen:
| Rolle | Kernverantwortung in der Datenmigration |
|---|---|
| GUS-Implementierungspartner | Zielkonfiguration, verfügbare Importobjekte, technische Zielanforderungen und Verarbeitung im GUS-System |
| Kunde und Key User | fachliche Scope-Entscheidungen, Datenverantwortung, Freigabe von Regeln und Abnahme im Geschäftsprozess |
| Datenmigrationsspezialist | Quellanalyse, Mapping-Moderation, Extraktion, Transformation, Übergabedaten, Fehleranalyse, Tests und transparente Steuerung des Migrationsumfangs |
Der externe Datenmigrationsspezialist ersetzt weder den GUS-Partner noch die fachliche Verantwortung des Kunden. Er schließt die Lücke zwischen beiden Seiten. Gerade wenn das Altsystem schlecht dokumentiert ist, viele Datenquellen zusammengeführt werden müssen oder interne Schlüsselpersonen bereits durch die ERP-Einführung ausgelastet sind, kann diese zusätzliche Umsetzungskapazität entscheidend sein.
Wann externe Unterstützung wirtschaftlich sinnvoll ist
Externe Unterstützung ist nicht allein wegen einer hohen Zeilenzahl erforderlich. Millionen gleichartig strukturierter Datensätze können technisch einfacher sein als wenige Tausend Datensätze mit unklaren Schlüsseln, widersprüchlichen Regeln und zahlreichen manuellen Ergänzungen.
Ein spezialisierter Dienstleister ist besonders sinnvoll, wenn mehrere der folgenden Bedingungen zutreffen:
- Die ERP-Projektleitung kann keinen eigenen Verantwortlichen für den gesamten Migrationsumfang stellen.
- Das Altsystem ist fachlich bekannt, aber sein Datenmodell nur unzureichend dokumentiert.
- Daten liegen zusätzlich in Excel-Dateien, Datenbanken oder weiteren Anwendungen.
- Das Mapping kommt nicht voran, weil technische und fachliche Fragen vermischt werden.
- Erste Testimporte erfolgen spät oder liefern Fehler, deren Ursachen niemand durchgängig verfolgt.
- Große Datenmengen müssen automatisiert transformiert und vollständig geprüft werden.
- Key User sollen entscheiden und testen, können aber nicht zusätzlich die technische Datenaufbereitung übernehmen.
Vor einer Beauftragung sollte geprüft werden, ob ein Anbieter tatsächlich Quelle und Ziel verbinden kann. Dazu gehören lesende Datenbankanalyse, verständliche Mapping-Moderation, reproduzierbare Transformation, Erfahrung mit dem GUS-Ladeweg und eine unabhängige Prüfstrategie. Unser Beitrag Datenmigration-Dienstleister vergleichen enthält dafür zwölf konkrete Fragen.
Wovon Aufwand und Kosten einer GUS-Datenmigration abhängen
Eine seriöse Schätzung entsteht nicht aus dem Namen des ERP-Systems oder einer pauschalen Anzahl von Datensätzen. Relevanter sind die Zahl und Komplexität der Migrationsobjekte, die Qualität der Quellstrukturen, zusätzliche Datenquellen, der Umfang fachlicher Anreicherungen, die Zahl der Testzyklen und die geforderte Nachweisführung.
Auch die Verteilung der Verantwortung wirkt sich aus. Wenn interne Key User klare Entscheidungen treffen können, der GUS-Partner Zielstrukturen rechtzeitig bereitstellt und der Migrationsspezialist die technische Strecke automatisiert, bleibt der Aufwand steuerbar. Unklare Zuständigkeiten erzeugen dagegen Wartezeiten und wiederholte manuelle Arbeit, die in einer reinen Tagessatzbetrachtung leicht unsichtbar bleiben.
Für eine belastbare Kalkulation sollten zunächst einige repräsentative Objekte analysiert werden. Daraus lassen sich Quellzugriff, Transformationsbedarf, erwartete Fehlerklassen und ein realistischer Testzyklus ableiten. Wie diese Faktoren in eine Schätzung einfließen, erläutern wir im Beitrag Kosten einer ERP-Datenmigration seriös einschätzen.
Was vor der Beauftragung geklärt sein sollte
Für ein erstes belastbares Bild braucht es noch kein vollständig ausgearbeitetes Migrationskonzept. Hilfreich sind das bekannte Quell- und Zielsystem, der geplante Go-live, eine vorläufige Liste der Datenobjekte, Informationen zu zusätzlichen Dateien oder Anwendungen und der aktuelle Stand erster Exporte oder Testläufe.
Auf dieser Grundlage lässt sich klären, wo das Projekt tatsächlich steht: Fehlt vor allem eine Scope-Entscheidung, eine technische Extraktionsstrecke, die Koordination der Fachbereiche, ein reproduzierbares Mapping oder die Stabilisierung bereits begonnener GUS-Läufe? Erst danach sollte entschieden werden, welches Arbeitspaket intern bleibt und welche Unterstützung sinnvoll beauftragt wird.
So beginnt eine GUS ERP Datenmigration nicht mit einem pauschalen Werkzeugversprechen, sondern mit einer prüfbaren Aufgabenabgrenzung. Das schafft die Voraussetzung für frühe reale Ergebnisse, belastbare Ladezyklen und eine Datenbasis, die im neuen System nicht nur vorhanden, sondern fachlich nutzbar ist.