Solange es SAP-Systeme gibt, ist die Datenmigration nahezu in allen SAP-Einführungsprojekten ein Kernthema. Begonnen bei der Angebotsphase und Auftragserteilung, ist der volle Umfang der zu migrierenden Daten, die Komplexität der Quelldaten und die Veränderung der Anforderungen an die Daten in den zukünftigen Prozessen ein unscharfes Bild. Trotzdem ist eine Schätzung der zu erwartenden Aufwände unumgänglich für Auftraggeber und Leistungsanbieter.
Dieser Blogbeitrag soll einige Fragen aufgreifen und behandeln, die sich Projektleiter und Teilprojektleiter auf Seiten der Auftraggeber und Auftragnehmer zu Beginn eines SAP S/4 HANA On-Premise Einführungs-Projektes in Bezug auf die Projekt- und Aufwandsplanung für die Datenmigration stellen.
Abbildung 1: Migrationsobjekte Stammdatenbereich
Der scheinbare und der reale Scope in der Datenmigration
Eine erste Auflistung der zu migrierenden Daten taucht üblicherweise bereits in den ersten Projekt-Unterlagen zur Angebotserstellung (Request for Proposal) auf. Ist dies nicht der Fall, müssen die Projektbeschreibungen sorgfältig nach Prozessbereichen, Funktionalitäten und Quellsystemen durchgesehen werden, um eine Ausgangsbasis für den Scope zu bekommen. Grundsätzlich sollte für eine Einschätzung der gesamte Projekt-Scope überschaut werden, da eigentlich immer damit zu rechnen ist, dass Prozessbereiche entweder neu strukturiert, vollkommen neu aufgesetzt werden, oder der Zeitpunkt für zusätzliche Funktionalitäten günstig ist bei einem Implementierungsprojekt. Der Ausgangspunkt ist somit nur ein scheinbarer Scope.
Mit der Ausgangsliste hat man erst einmal nur eine Y-Achse. Ist eine Datenübernahme zu einem Objekt aus mehreren Quellsystemen gefragt, so verlängert sich die Liste. Auf der X-Achse muss dann berücksichtigt werden, welche Aufgabenteilung zwischen Auftraggeber und Auftragnehmer anzusetzen ist. Eine Schätzung benötigt daher auf der horizontalen Ebene eine klare Linie der Zuständigkeiten. Im Mindesten sollten die Datenbereitstellung aus den Quellsystemen (Extraktionsaktivitäten), die Datenbereinigungsaktivitäten und die Klärung sowie Dokumentation offener Punkte zu Konvertierungsregeln zugeordnet sein. Die Koordination des Teilprojektbereiches Datenmigration sollte idealerweise auf beide Schultern gleichmäßig verteilt sein.
Ein weiterer Punkt ist die Anzahl der Migrationsläufe und die Versorgung der neu aufzubauenden Systemlandschaft mit Stammdaten aus den Quellsystemen. Der klassische Ansatz in der Datenmigration sieht Funktionstests mit steigender Anzahl an Datensätzen und einen großen Testlauf (Probelauf, nahezu Produktiv-Load) vor. Es sollte allerdings daran gedacht werden, wie die einzelnen Testphasen der Prozessbereiche mit Stammdaten ausgestattet werden. Bei diesem Punkt gehen die Erwartungen der Projektteilnehmer aus den Fachbereichen oft auseinander. Allerdings gehört es auch dazu, dass die Datenmigration Feedbacks über die Qualität der Migration bekommt. Einen effektiven Nutzen gewinnt man daher mit Migrationstestläufen, in denen Daten für die Testphasen bereitgestellt werden. Damit bekommt man für den Scope noch eine weitere (Z-)Achse hinzu, welche wiederum mit Ladeaktivitäten zeitlich an dem Gesamtprojektplan orientiert sein muss.
Abbildung 2: Dimensionsdarstellung – Scope in der Datenmigration
Welche dynamischen und progressiven Faktoren müssen in der Datenmigration berücksichtigt werden?
Ein Projekt lebt von seinen Fortschritten. Die Fortschrittsentwicklung ist wiederum sehr stark abhängig vom Grundlagenwissen, der Erfahrung und der positiv konstruktiven Motivation der einzelnen Projektteilnehmer auf Seiten des Auftraggebers. Zu Beginn eines Projektes ist der Blick nach vorn gerichtet und setzt beim strukturierten Aufbau bzw. Abbildung der notwendigen Funktionalitäten und gegebenenfalls eines Redesigns in den zukünftigen Prozessen der einzelnen Prozessbereiche an. Für die Datenmigration ist es wichtig und entscheidend, nicht isoliert von den Fachbereichen zu arbeiten, sondern einen regelmäßigen Austausch aufzubauen. Ein Austausch am Anfang ist eine detaillierte Bestandsaufnahme mit den Fachbereichen an migrationsrelevanten Objekten, vorhandenen Quelldaten und deren Qualität.
Im zweiten Schritt geht es dann eine Ebene tiefer auf die Feldebene zu den einzelnen Objekten, um ein strukturelles Feld-Mapping aufzubauen. Im dritten Schritt geht es noch eine Ebene tiefer in den Aufbau eines Werte-Mappings zu relevanten Feldwerten. Wenn ein SAP-System Neuland für die Auftraggeberseite darstellt, sind diese Schritte umso schwieriger, weil die grundlegende zukünftige Datenstruktur der einzelnen Objekte erst vermittelt werden muss, was auf dem Reißbrett und in Excel-Tabellen nicht ganz einfach ist. Zu berücksichtigen ist, dass die Datenmigration nicht warten kann mit diesen Schritten und das Verständnis bzw. die Unterstützung zum kontinuierlichen Austausch von Beginn an durch die Projektleitung und die Projektteilnehmer kommen muss.
Die Dynamik in der Datenmigration nimmt im weiteren Projektverlauf stetig zu und fordert ein hohes Maß an Resilienz, da die Prozessbereiche im Designprozess der zukünftigen Funktionalitäten fortschreiten. Daraus ergeben sich Anpassungen im Zielsystem, die in der Datenmigration Änderungen, Erweiterungen und Anpassungen auslösen. Die Änderungsdynamik gibt es folglich so lange, bis die Funktionalitäten und Prozesse auf den Punkt kommen.
Die Datenmigration muss einerseits vorauslaufen, um Daten für Tests liefern zu können und andererseits hinterherlaufen, um die Projektfortschritte in die Datenmigration zu integrieren.
Zusätzlich gibt es regelmäßig Überraschungen, wenn Daten aus den Quellsystemen extrahiert werden und darin Werte auftauchen, die nicht gemappt und geladen werden können, weil Werte in den Einstellungen der Wertelisten im Zielsystem bisher gar nicht berücksichtigt oder noch nicht geklärt waren und daher noch nicht eingestellt worden sind.
Ein weiterer progressiver Faktor ist die zunehmende Komplexität, wenn das Zusammenspiel einzelner Funktionalitäten integrativ betrachtet und getestet wird. Nicht selten müssen dann Einzelheiten für die Migration nochmal integrativ betrachtet, geklärt und abgestimmt werden.
Bei Migrationsobjekten, die prozessübergreifenden Charakter haben, ist die Nachjustierung im Feld- und Werte-Mapping Programm.
Der zeitliche Aufwand für den regelmäßig zwingend notwendigen Austausch zur Klärung, Abstimmung und Nachjustierung wird für die Datenmigration gemeinhin deutlich unterschätzt.
Abbildung 3: Phasenplan in der Datenmigration
Welche qualifizierenden Aufgaben und Faktoren müssen in der Datenmigration berücksichtigt werden?
Unter qualifizierenden Faktoren sind die Dokumentationspflichten und die Anforderungen zur Ergebnisüberprüfbarkeit im gesamten Projektverlauf zu verstehen. Das betrifft die Datenmigration in besonderer Dimension, da das Ergebnis der Migration am Ende ein nachvollziehbares Resultat ergeben muss.
In der Datenmigration ist Nachhaltigkeit und Disziplin in der Dokumentation eine kontinuierliche Aufgabe, um einerseits die Übersicht in einem dynamischen Umfeld zu behalten und andererseits, um auskunftsfähig und effektiv austauschfähig zu sein und Dokumentationen zu liefern, in denen der Scope, die Methodik, die Selektionsregeln, die Konvertierungsregeln und die Darstellung der Resultate klar und nachvollziehbar ist. Die Dokumentationsqualität muss dazu führen, die Resultate der Migration durch die Fachbereiche des Auftraggebers verifizieren und bewerten zu lassen. Auch dieser Anspruch kann nur in Zusammenarbeit und Austausch zwischen Migrationsteam und Projektteilnehmern aus den Fachbereichen erreicht werden.
Darüber hinaus ist die Risikoeinschätzung und die Auditierung nicht zu vergessen, da es sich bei der Datenmigration in den Stammdaten um Kerndaten des Unternehmens handelt und in den Bewegungsdaten um die Grundlagen zur Fortführung des operativen Geschäfts im neuen Systemumfeld.
Ist des Weiteren aus regulatorischen Anforderungen eine Qualifizierung bzw. Validierung des neuen Systems erforderlich, gibt es eine zusätzliche abstimmungsintensive Ebene im gesamten Projektablauf und insbesondere in der Dokumentationssteuerung unter Wahrung von definierten Prüfungs- und Genehmigungsverfahren.
Abbildung 4: Dokumentationsanforderungen in der Datenmigration
Wie ist die Datenmigration in die Projektplanung zu integrieren?
Unter Betrachtung der Aufgaben in der Datenmigration sollte insbesondere der frühzeitige Einstieg in den Austausch mit den Projektteilnehmern aus den Fachbereichen gestützt werden.
Wenn auch in der ersten Phase des Projektes der Fokus auf die zukünftige Abbildung der notwendigen Prozesse gerichtet ist, kann die Datenmigration nicht warten bis die Realisierungsphase anläuft. Das Konzept für die Datenmigration bedarf der Erkenntnisse aus dem frühzeitigen Austausch und der Detaillierung des Umfangs der migrationsrelevanten Objekte.
Innerhalb der Projektplanung ist anzuraten, die Bereitstellung des neuen Entwicklungssystems nicht einzig an dem Beginn der Realisierung von Customizing-Einstellung zu orientieren, sondern einen vorherigen Zugang für vorbereitende Tätigkeiten der Datenmigration in Betracht zu ziehen.
Damit die Datenmigration für Tests und Feinarbeit in den Prozessbereichen Daten liefern kann, müssen die Grundgerüste zur Datenkonvertierung vorab aufgebaut und mit Leben gefüllt werden können.
Ähnlich ist die Bereitstellung des Testsystems und später des Produktivsystems in der Projektplanung unter Berücksichtigung des vorauseilenden Zugriffs für die Datenmigration zu betrachten.
In Betrachtung des Cutover- und GoLive Szenarios, ist die Datenmigration niemals zum GoLive-Termin vollständig abgeschlossen. Bewegungsdaten der Finanzbuchhaltung folgen immer den spezifischen Bedingungen eines Quartals- oder Jahresabschlusses der Finanzbuchhaltung im Cutover-Prozess. Dafür darf kurz vor dem GoLive-Termin gegebenenfalls ein Stammdatendelta nicht vergessen werden. Und in den ersten Tagen nach dem GoLive ist noch einmal eine intensive Teamleistung für den reibungslosen Anlauf der Finanzbuchhaltung im neuen System zu erwarten.
Ebenso sollte nicht in der Planung vergessen werden, dass die Fachbereiche des Auftraggebers extrahierte Daten vor der Migration prüfen und freigeben sollten und nach der Migration die Resultate im neuen System prüfen und bestätigen müssen. Ein Probelauf für den Freigabe- und Prüfungsprozess ist unbedingt anzuraten, um tatsächlich benötigte Zeitaufwände für den Produktivload realistisch zu ermessen und das Vorgehen für alle Beteiligten vorher klar definiert zu haben.
Abbildung 5: Freigabe- und Prüfungsverfahren
Welche Hilfsmittel können zur Aufwandsplanung verwendet werden?
Alle innerhalb dieses Blogs genannten Aspekte in einer kompletten Schätzung vor Beginn des Projektes belastbar und vollständig zu schätzen, ist gewagt. Es können alle Aufgaben der X- Achse und der Z-Achse auf einer horizontalen Ebene in einer Matrix erfasst werden und der bekannte Scope an Objekten zum Zeitpunkt der Schätzung auf einer vertikalen Ebene gelistet und eingeschätzt werden. Dabei bleiben jedoch unbekannte Faktoren, Hindernisse und Entwicklungskurven des Gesamtprojektverlaufes zunächst unbekannt. Kein Projekt verläuft reibungslos, ohne Extraschleifen in der Abstimmung und ohne Anpassungen in den Details. Mustervorlagen dazu lassen sich in den SAP-Informationsbibliotheken bzw. bei Verlegern von SAP-Fachbüchern finden.
Ein Richtwert kann mit einer derartigen Matrix, sofern X- und Y-Achse plausibel aufgestellt worden sind, näherungsweise entstehen.
Abbildung 6: Planungshilfsmittel für die Datenmigration
Wie kann man die Aufwände für die Datenmigration überschaubar aufstellen?
Das einfachste Prinzip besteht in einer sukzessiven Vorgehensweise in der Aufwandsschätzung. Losgelöst von einem Gesamtaufwand, welcher durchaus üblicherweise in Angebotsaufstellungen erwartet wird, ist der Kontext des Gesamtprojektverlaufes eine Entwicklung, die eine Schätzung in Etappen nahelegt. Idealerweise ist eine Einteilung in 3 Phasen günstig. Die Vorbereitungs- und Konzeptionsphase, welche sich bis in die Realisierungsphase des Projektes hinein erstreckt, die Test- und Adaptionsphase, welche sich durch die Realisierungsphase hindurch bis zum Integrations- und User Acceptance Test erstreckt und die Deploy-Phase, die im Bereich der Datenmigration erst nach dem GoLive Termin zum Abschluss gebracht wird.
Eine grundsätzliche Faustregel könnte sein, die Aufwandsplanung auf Seiten des Auftragsnehmers für die Datenmigration, Datenbereinigung und Abstimmungsthemen ähnlich zu den Aufwänden auf Seiten des Auftraggebers anzusetzen, weil es in der Datenmigration um eine Gesamtteamleistung geht. Nur so ist sicherzustellen, dass ein nachhaltiges Ergebnis entsteht, Datenbereinigungsthemen bearbeitet werden, Ressourcen und Aufwände für notwendige Abstimmungen berücksichtigt sind und das Wissen über die Datenbasis und deren Transformation auf der Wegstrecke zum neuen System im Unternehmen verbleibt.
Fazit
Ein Teilprojekt Datenmigration sollte nicht isoliert als reiner Datenlieferant zum Projekt verstanden werden. Der Aufbau des realen Scopes, der Selektionskriterien, der Transformationsregeln und der Datenprüfungen ist ein dynamischer Prozess, der vom Austausch mit den Fachbereichen und den Fachbereichsberatern abhängt. Während des gesamten Projektverlaufes sollte Raum für Abstimmungen zu den Themen, Detailfragen und dynamischen Anpassungsanforderungen der Datenmigration gegeben sein.
Für die Integration der Datenmigration in die Projektplanung ist ein frühzeitiger Zugang zum neuen System notwendig, um Daten für die jeweiligen Testszenarien aufstellen zu können.
Die Aufwandsplanung kann zu Beginn nur einem Schätzwert entsprechen. Daher ist ein modularer, phasenorientierter Aufbau mit entsprechenden Reviews anzuraten auf dem Weg zum Migrationserfolg.