Start · Lösungen · IT & Services
Lösung · IT & ServicesJeder migrierte Datensatz gegen die Quelle geprüft, bevor jemand den Cutover freigibt
Datenmigration mit Tests geprüft, nicht mit Stichproben
Automatisierte Testfälle gleichen Quelle und Ziel feldgenau für jeden migrierten Datensatz ab, prüfen die Geschäftsprozesse auf migrierten Daten und liefern die Nachweise für die Go-live-Entscheidung.
Kurzfassung für die Geschäftsführung
Eine Tabellenstichprobe von einigen Hundert Datensätzen steht heute zwischen Ihrer Migration und dem Go-live.
Wir bauen Migrationsabsicherung als Testbestand, nicht als Tabellenübung.
Abdeckung ist keine Meinungsfrage mehr: Jeder Datensatz im Umfang wird auf jedem gemappten Feld verglichen.
SAP S/4HANA über SAP BAPI und OData; der Azure-DevOps-Backlog; der Nachweisbestand im Test Manager
Geschäftsproblem
Migrationsabsicherung
Eine Migration verlagert das operative Gedächtnis des Unternehmens in ein neues System: Kunden- und Lieferantenstammsätze, Bankverbindungen, Materialdaten, Konditionen, offene Forderungen und Verbindlichkeiten, Kontensalden, offene Aufträge. Jedes Objekt hat irgendwo im Fachbereich einen Verantwortlichen, der bestätigen soll, dass die Daten richtig aussehen. Das Werkzeug dafür ist ein Auszug und eine Tabelle.
Eine Stichprobe ist keine Abdeckung. Dreihundert Kundenstammsätze von vierhunderttausend sagen fast nichts über den Rest, und Stichproben sind verzerrt: Geprüft wird, was man kennt. Inaktive Kunden, seltene Konstellationen und der lange Schwanz historischer offener Posten sind genau die Stellen, an denen Migrationsregeln brechen. Fünf Gesellschaften, mehrere Wellen und drei Testmigrationen vervielfachen denselben manuellen Vergleich, sodass der Fachbereich im dritten Lauf weniger prüft, genau dann, wenn die Daten der Produktion am nächsten sind. Der technische Bericht bleibt grün, denn übereinstimmende Satzzahlen sind keine übereinstimmenden Werte.
Die Folgen treffen Menschen, die nie in einer Migrationsrunde saßen. Das Forderungsmanagement mahnt Kunden für Posten, die vor Jahren ausgeglichen wurden. Eine gesperrte Lieferung entpuppt sich als Kreditlimit, das als Null migriert wurde. Der Vertrieb findet eine Konditionstabelle ohne Gültigkeitsdaten. Die Treasury findet einen Zahlungslauf, der auf das alte Factoringkonto eines Lieferanten zeigt. Jeder dieser Fälle taucht Wochen nach dem gefeierten Cutover auf.
Wie es heute läuft
In den meisten Konversionsprogrammen ist der eigentliche Testplan ein Stapel Vergleichstabellen in Excel, unabhängig vom Migrationswerkzeug.
- SystemDie Testmigration läuft übers Wochenende; das Cockpit meldet Satzzahlen und Ladefehler je Objekt
- MenschAnalysten ziehen Auszüge aus beiden Systemen und bauen je Objekt Vergleichstabellen in Excel
- MenschJedes Fachteam öffnet eine Stichprobe von einigen Hundert Sätzen und prüft die Felder, die es am besten kennt
- WartezeitBefunde liegen in einer gemeinsamen Liste bis zum nächsten Programmtermin, meist eine Woche
- FehlerrisikoObjekte ohne klaren Verantwortlichen, etwa Konditionen und Partnerrollen, werden zuletzt oder gar nicht geprüft
- MenschDie Freigabe ist eine Unterschrift auf einer Checkliste; der Stichprobenumfang dahinter ist nirgends festgehalten
- FehlerrisikoDer erste vollständige Test der Daten ist der Fachbereich, am ersten Arbeitstag nach dem Go-live
Warum der heutige Prozess mehr kostet, als es scheint
Diese Arbeit hat niemand geplant, sie ist entstanden.
- Wiederholung ist die versteckte Kostenposition. Derselbe Vergleich entsteht bei jeder Testmigration und jeder Welle neu, und nichts davon bleibt, weil er in einer Tabelle lebt.
- Eine Freigabe ohne dokumentierten Stichprobenumfang ist kein Nachweis. Auf die spätere Frage, wie die Eröffnungsbilanzwerte geprüft wurden, lautet die ehrliche Antwort: Einige Personen haben einige Sätze angesehen.
- Fehler kosten nach dem Go-live ein Vielfaches. In der Testmigration ist ein Fehler eine Zeile in einer Liste; in der Produktion sind es eine gestoppte Lieferung, eine falsche Mahnung und eine Korrekturbuchung, die das Rechnungswesen beim Abschluss erklärt.
- Angst vor den Daten bremst das Programm. Wenn niemand das Risiko beziffern kann, ist der Reflex eine weitere Testmigration oder ein längerer Freeze, beides teuer.
Kosten des Nichtstuns
Die zweite Zeile ist die bewegliche. Manuelle Prüfung ist durch die verfügbaren Tage begrenzt, hat also eine Kostenobergrenze; die Fehler, die daran vorbeigehen, haben keine. Eine falsche Bankverbindung im Lieferantenstamm oder offene Posten ohne Fälligkeit binden jeweils mehr Managementaufmerksamkeit als das gesamte Prüfbudget. Ein dritter Kostenblock steht in keiner Zeile: Ein Programm, das sein Datenrisiko nicht beziffern kann, steuert es über Verzögerung, und eine weitere Testmigration oder ein längerer Freeze ist gerade deshalb teuer, weil das Wissen fehlt.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Eine europäische Industriegruppe, fünf operative Gesellschaften in vier Ländern, rund 4.000 Mitarbeitende, Konversion von SAP ECC auf SAP S/4HANA in zwei Wellen; Microsoft 365 E3, Azure DevOps als Programm-Backlog.
Rund 2,4 Millionen Datensätze in etwa achtzehn Migrationsobjekten: Kunden- und Lieferantenstamm mit Bankverbindungen, Materialstamm, Konditionen, offene Debitoren- und Kreditorenposten, Kontensalden, offene Aufträge. Drei Testmigrationen vor dem Cutover.
Nach jedem Lauf veröffentlicht das Datenteam Auszüge, sechs Fachprüfer vergleichen Stichproben rund acht Arbeitstage in Excel, Befunde gehen in eine Liste, jeder Verantwortliche unterschreibt eine Checkliste.
Die Stichprobe deckt je Objekt einen Bruchteil eines Prozents ab und neigt zu bekannten Sätzen; sie lässt sich bei drei Läufen nicht schnell genug wiederholen, sodass die Abdeckung sinkt, wenn die Daten am meisten zählen.
Test Manager hält je Objekt einen Abgleich-Testfall; Roboter lesen beide Systeme über SAP-Schnittstellen, vergleichen jeden Datensatz feldgenau und fahren anschließend Auftrag-bis-Rechnung und Einkauf-bis-Zahlung auf den migrierten Daten. Abweichungen werden zu Fehlern in Azure DevOps und zu Aufgaben in Microsoft Teams; die Ausführungshistorie ist der Freigabenachweis.
Im modellierten Fall steigt die Abdeckung von einer Stichprobe im niedrigen dreistelligen Bereich je Objekt auf jeden Datensatz im Umfang, jede Testmigration wird in Stunden statt Tagen geprüft, und Fehler, die bisher nach dem Go-live auffielen, zeigen sich beim ersten Lauf. Diese Zahlen sind ein Modell, keine Messung.
Vorgeschlagene Lösung
Wir bauen Migrationsabsicherung als Testbestand, nicht als Tabellenübung. Jedes Migrationsobjekt erhält eine Anforderung und einen Abgleich-Testfall in UiPath Test Manager, der Komponente von UiPath Test Cloud, die Testfälle, Testsets, Ausführungshistorie und Nachweise hält. Der Testfall leistet in voller Menge, was die Analysten von Hand taten: Quellsätze lesen, lesen, was in SAP S/4HANA angekommen ist, die Mapping-Regeln anwenden und jeden Datensatz melden, bei dem beide Seiten auseinandergehen. Roboter lesen über SAP-Schnittstellen statt über Bildschirme, sodass der Vergleich Millionen Datensätze innerhalb eines Ladefensters abdeckt.
Der Feldabgleich allein genügt nicht. Ein Kunde mit korrekter Adresse kann trotzdem ein Kreditsegment tragen, das jeden Auftrag sperrt. Deshalb enthält dasselbe Testset Prozesstestfälle auf migrierten Daten: ein Kundenauftrag für einen migrierten Kunden, Lieferung, Rechnung, Zahlungseingang, Mahnung auf einen migrierten offenen Posten. Das sind die Abläufe, die der Fachbereich am Montag fährt, ausgeführt auf den Daten vom Freitag.
Der Rest macht das Ergebnis belastbar. Abweichungen werden regelbasiert klassifiziert, nach Objekt und Schweregrad gruppiert und in den Migrations-Backlog in Azure DevOps gestellt. Der Verantwortliche eines Objekts erhält eine Aufgabe in Microsoft Teams mit den Satznummern und entscheidet: korrigieren, mit Begründung akzeptieren oder den Lauf ablehnen. Test Manager hält Abdeckung, Pass- und Fail-Zahlen sowie Nachweise je Lauf, und genau das braucht ein Go-live-Gate anstelle einer Unterschrift. Das ist eine andere Disziplin als die nächtliche Release-Regression auf einem laufenden SAP-System, auch wenn der Migrationsbestand nach dem Go-live genau zu dieser Suite wird.
UiPath Test Cloud mit Test Manager (Testfälle, Testsets, Ausführungsnachweise, Azure-DevOps-Synchronisation); Zeitpläne, Queues und Prüfpfad in UiPath Orchestrator; UiPath SAP automation (SAP-BAPI- und OData-Konnektoren, SAP-GUI-Aktivitäten); aktionsfähige Benachrichtigungen von UiPath Action Center in Microsoft Teams; Test-Manager-Dashboard in UiPath Insights
Den Abgleich-Testfall je Objekt, Mapping- und Toleranzregeln als Zusicherungen, die Klassifikation der Abweichungen, die Prozesstestfälle, Fehlersteuerung und Schweregradmodell, den Abweichungsauszug und das Bereitschaftsreporting
Lesezugriffe auf SAP ECC und SAP S/4HANA über UiPath-SAP-Aktivitäten; Bereitstellung der Vergleichsmengen in Azure SQL, wo das Volumen eine Tabelle übersteigt
So läuft der automatisierte Prozess
- AutomatisierungJeder Testlauf startet im Test Manager das Abgleich-Testset für jedes Objekt im Umfang
- SystemRoboter lesen die Quellsätze und das Ziel in S/4HANA über SAP-Schnittstellen und stellen beide Seiten bereit
- AutomatisierungJeder Datensatz wird feldgenau verglichen; Abweichungen gelten als fehlend, verändert, abgeschnitten, falsch zugeordnet oder außerhalb der Toleranz
- AutomatisierungProzesstestfälle laufen auf den migrierten Daten: Auftrag bis Rechnung, Mahnung auf einen migrierten offenen Posten, Wareneingang zu einer migrierten Bestellung
- SystemErgebnisse, Satznummern und Nachweise gehen in den Test Manager; Fehler synchronisieren in den Azure-DevOps-Backlog
- MenschDatenverantwortliche bearbeiten ihre Abweichungen als Action-Center-Aufgaben in Microsoft Teams und entscheiden über Korrektur, Annahme oder Ablehnung
- AutomatisierungEine Bereitschaftssicht zeigt Abdeckung je Objekt, offene Fehler nach Schweregrad und den Trend über die Testmigrationen
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Den feldgenauen Vergleich jedes Datensatzes im Umfang nach jedem Lauf
- Die Klassifikation der Abweichungen nach Typ, Objekt und Schweregrad, mit Satznummern
- Die Ausführung der Geschäftsprozesse auf migrierten Daten und die Sicherung der Nachweise
- Fehleranlage in Azure DevOps, Bereitschaftsreporting und den erneuten Lauf nach jeder Korrektur
Menschen entscheiden
- Was je Objekt „richtig“ heißt: Felder im Umfang, gewollte Transformationen, tolerierbare Unterschiede
- Ob eine Abweichung ein Fehler, ein akzeptierter Unterschied oder ein Mapping-Irrtum ist
- Das Schweregradmodell und was am Cutover-Gate offen bleiben darf
- Die Go-live-Entscheidung, getroffen auf Nachweisen statt auf einer Stichprobe
Vorher und nachher
Systeme und Integrationen
Jeder Eintrag lässt sich in der Herstellerdokumentation prüfen. Die Evidenzklasse steht daneben.
Eingänge
- SAP-ECC-Sätze je Objekt
- die Mapping-Spezifikation
- Ladeergebnisse aus dem Migrations-Cockpit
- der Cutover-Plan
Automatisierungsschicht
- UiPath Test Cloud mit Test Manager
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
- Bereitstellung in Azure SQL
Zielsysteme
- SAP S/4HANA über SAP BAPI und OData
- der Azure-DevOps-Backlog
- der Nachweisbestand im Test Manager
Berührungspunkte für Menschen: Action-Center-Aufgaben in Microsoft Teams; ein Teams-Kanal je Welle; der Abweichungsauszug in Excel
Eingesetzte Technologien
Testfälle, Testsets, Ausführungshistorie und Freigabenachweise je Objekt
Afahren die Testsets planmäßig gegen beide Systeme, mit Wiederholungen und Prüfpfad
Aliest Quell- und Zielsätze; fährt die Prozesse auf migrierten Daten
Astellt die Vergleichsmengen bereit; verwahrt die technischen Zugangsdaten
ADatenverantwortliche prüfen und akzeptieren Abweichungen dort, wo das Programm spricht
AMigrations-Backlog: Fehler mit ihren Testergebnissen verknüpft, aus dem Test Manager synchronisiert
Ader Abweichungsauszug je Objekt, den ein Verantwortlicher durcharbeitet
AAbdeckung, Erfolgsquote und Fehlertrend über die Testmigrationen
AIllustratives Wirtschaftlichkeitsmodell
Die Rechnung ist offen, damit man ihr widersprechen kann.
Diese Bandbreiten stammen aus Konversionsprogrammen; keine davon ist eine Messung bei einem Kunden. Migrationsabsicherung ist kein transaktionaler Prozess, deshalb zeigen wir einen Wertpool statt eines Kalkulators. Der Prüfaufwand zählt nur die Tage, die Fachprüfer mit dem Vergleich von Auszügen verbringen. Der Satz von 45 € ist ein vollbelasteter Mischsatz aus Key-Usern und IT-Analysten in Mitteleuropa; die 14.000 € je Produktionsfehler sind ein modellierter Mittelwert aus Korrekturarbeit, Betriebsstörung und der Nacharbeit im Rechnungswesen bis die Salden stimmen.
Geschäftlicher Nutzen
- Abdeckung ist keine Meinungsfrage mehr: Jeder Datensatz im Umfang wird auf jedem gemappten Feld verglichen
- Fehler zeigen sich in der ersten Testmigration statt vor dem Kunden, wenn eine Korrektur eine Mapping-Änderung ist und keine Korrekturbuchung
- Jeder Lauf ist in Stunden geprüft, sodass das Programm nach einer Korrektur neu laden kann, statt bekannte Fehldaten für den Termin hinzunehmen
- Das Go-live wird zu einer Entscheidung mit Nachweisen, und der Testbestand überlebt die Migration als Regressionsbasis
Aus Sicht der Geschäftsführung
- Cutover-Bereitschaft ist eine Zahl je Objekt statt einer im Termin vereinbarten Statusfarbe, sodass das Go-live über Fakten statt über Zuversicht diskutiert wird
- Programmrisiko wird gegenüber Vorstand und Prüfungsausschuss berichtsfähig: was getestet wurde, was durchfiel, was akzeptiert wurde und von wem
- Migrationswissen steckt in Testfällen statt bei Beratern, die zum Projektende gehen
KPIs für die Geschäftsführung
Sicherheit und Governance
Ein Prüfer sollte jede Entscheidung nachvollziehen können.
- Roboter lesen beide Systeme mit technischen Konten, die ausschließlich Anzeigeberechtigung haben; der Abgleich braucht keinen Schreibzugriff
- Die Grenze bilden Ihr eigenes Azure-Abonnement, Ihr Tenant und ein Mandant der UiPath Automation Cloud in der EU-Region; Vergleichsmengen entstehen darin und werden planmäßig gelöscht, und Kunden-, Lieferanten- und Bankdaten verlassen sie nie
- Zugangsdaten liegen im Azure Key Vault, referenziert aus dem Orchestrator, und jeder Lesevorgang ist einem benannten Konto im Prüfpfad zuzuordnen
- Test Manager hält die Ausführungshistorie, sodass Monate später beantwortbar bleibt, wer welche Abweichung wann akzeptiert hat, und genau danach fragt die Prüfung bei den Eröffnungswerten
Warum jetzt
Konversionsprogramme laufen gegen einen festen Horizont: SAP bietet Mainstream Maintenance für die Kernanwendungen der SAP Business Suite 7 bis Ende 2027, mit optionaler erweiterter Wartung bis Ende 2030 gegen Aufpreis. Manuelle Prüfung skaliert in diesem Fenster nicht.
Der illustrative Pool von 220.000 € liegt in einem einzigen Migrationsjahr und ist nicht nachholbar; ein vor dem Cutover übersehener Fehler wird zu Produktionspreisen bezahlt.
Test Manager hält heute die Verknüpfung von Anforderung und Test, Ausführungsnachweise und die Azure-DevOps-Synchronisation und deckt SAP- und Schnittstellentests an einer Stelle ab, sodass dafür kein eigenes Abgleichsprogramm für ein einzelnes Projekt nötig ist.
Relevante Führungsrollen
Eröffnungswerte, offene Posten und Lieferantenbankverbindungen werden gegen Nachweise freigegeben statt gegen eine Stichprobe, und diese Fassung übersteht die Prüfung
Cutover-Bereitschaft wird zu einem messbaren Gate, und der Migrationsbestand arbeitet als Regressionssuite weiter
Der erste Tag nach dem Go-live ist ein normaler Tag, weil Auftrags- und Rechnungsprozesse bereits auf migrierten Daten liefen
Häufige Fragen und Einwände
Gemeinsam ist die Plattform, sonst wenig. Nächtliche Regression schützt ein laufendes System vor den Änderungen, die Sie hineingeben; Migrationsabsicherung belegt, dass eine einmalige Datenverlagerung korrekt angekommen ist, Satz für Satz, bevor jemand unterschreibt. Die nützliche Verbindung: Der Migrationsbestand speist danach genau jene Regressionssuite.
Zahlen belegen, dass Zeilen angekommen sind, nicht dass Werte stimmen. Sie stimmen perfekt, während ein Datum abgeschnitten wird, eine Mengeneinheit doppelt umgerechnet wird oder ein Kreditlimit als Null landet. Der feldgenaue Vergleich beantwortet die Frage, die der Fachbereich später spürt.
Das Lesen über Schnittstellen statt über Bildschirme ändert die Rechnung, und Objekte laufen parallel über mehrere Roboter. Beim Produktivlauf beschränkt sich der Vergleich auf die Objekte, von denen das Gate abhängt, da der volle Umfang in den Testmigrationen bereits belegt wurde.
Wann diese Lösung nicht passt
- Eine Migration von wenigen tausend Sätzen in ein Objekt, bei der ein Analyst beide Seiten tatsächlich in einer Tabelle vergleichen kann
- Das Feld-Mapping ändert sich wöchentlich und kein Objekt hat einen benannten Verantwortlichen; die Regeln haben nichts Stabiles zu prüfen
- Weder das Quellsystem noch ein eingefrorener Auszug ist nach dem Cutover lesbar, es fehlt also die verlässliche Vergleichsseite
Eine Frage für die nächste Sitzung
Welchen Prozentsatz der migrierten Datensätze hat bei unserer Cutover-Freigabe tatsächlich jemand gegen das Altsystem verglichen, und können wir das belegen?
Vorgehen bei der Umsetzung
Die Umsetzung läuft in Etappen, damit sie jederzeit gestoppt werden kann.
Wir liefern
- Eine Bestandsaufnahme der Objektliste: welche Objekte, welche Felder, welche Transformationen, wer verantwortlich ist
- Abgleich-Testfälle im Test Manager je Objekt, mit Mapping-Regeln als Zusicherungen und Toleranzen
- Schnittstellenlesen gegen beide Systeme und die Bereitstellung, mit der ein Vergleich über eine Million Sätze im Ladefenster fertig wird
- Prozesstestfälle auf migrierten Daten über Auftrag bis Rechnung, Einkauf bis Zahlung und Mahnwesen
- Fehlersteuerung nach Azure DevOps und Microsoft Teams, Bereitschaftsreporting und das Nachweispaket für das Go-live-Gate
Wir brauchen von Ihnen
- Die Mapping-Spezifikation, auch wenn sie noch unvollständig ist
- Je Objekt einen benannten Datenverantwortlichen, der entscheidet, was als Fehler gilt
- Technischen Lesezugriff auf beide Systeme, eine Testumgebung und den Cutover-Plan mit seinen Gates
Etappen
Umfang
Objekte, Felder, Verantwortliche und die Definition von richtig, mit dem Fachbereich abgestimmt
Design
Abgleichsregeln, Toleranzen, Abweichungsklassen, Schweregradmodell, Gate-Kriterien
Aufbau
Testfälle im Test Manager, Schnittstellenlesen, Bereitstellung, Azure-DevOps-Sync, Teams-Steuerung
Testmigrationen
Vollständiger Abgleich je Lauf, Fehlerbearbeitung, erneuter Lauf nach Korrekturen, Abdeckungsreporting
Cutover
Abgleich des Produktivlaufs und anschließend Übergabe des Bestands als Regressionssuite
Abteilungsweit. Den Aufwand bestimmen die Zahl der Migrationsobjekte, wie genau das Feld-Mapping dokumentiert ist und ob beide Systeme über Schnittstellen oder nur über Bildschirme lesbar sind.
Die Freigabe sagt, die Daten stimmen. Die Stichprobe dahinter ist ein Bruchteil eines Prozents.
Schicken Sie uns Ihre Liste der Migrationsobjekte und die Mapping-Spezifikation, gern im Entwurf. Sie erhalten einen vorgeschlagenen Abgleichsumfang je Objekt und eine Fehlertaxonomie für die erste Testmigration.
Ein Migrationsobjekt gemeinsam absteckenDer Nachbarprozess hat meist dasselbe Problem
Schließen Sie den Monat nicht länger mit Saldenexporten nach Excel und Freigaben per E-Mail.
Lösung ansehen Supply ChainProdukt- und Preisstammdaten für alle VertriebskanäleSchluss mit dem Abtippen jedes neuen Produkts und jeder Preisänderung in ERP, PIM, Webshop und jeden Marktplatz.
Lösung ansehen Recht & ComplianceFunktionstrennung wöchentlich prüfen statt einmal im JahrIhre Rollenkonflikte findet der Prüfer einmal im Jahr. Der älteste ist dann zwölf Monate alt.
Lösung ansehen IT & ServicesJedes Release regressionsgetestet, auch die mobile AppRegression ist eine Checkliste, die zwei Personen am letzten Nachmittag vor dem Release durchklicken.
Lösung ansehen Case StudySAP-Regression jede Nacht — Case StudyStatt drei Personen, die zwei Tage lang klicken — UiPath-Testagenten durchlaufen die kritischen SAP-Pfade jede Nacht.
Case Study ansehen Case StudyRoboter, die sich selbst reparieren — Case StudyEin SAP-Bildschirm ändert sich und das halbe Roboter-Portfolio steht? Der Healing Agent erkennt die Oberflächenänderung und repariert Selektoren im Flug.
Case Study ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieHandel & E-CommerceFinanzen & Versicherung