Denken und handeln in Daten: Datenkonzeption für die vereinfachte Datenmigration nach SAP S/4 Hana

Mangelnder Überblick über die Daten und fehlende Datenqualität kommen erschwerend hinzu. Eine vorbereitende Datenkonzeption kann für einen schnelleren Time-to-Value wesentlich zur Vereinfachung der Datenmigration beitragen. Die Uhr tickt unaufhörlich. Bis spätestens 2030 müssen Unternehmen, die das wollen, nach SAP S/4 migriert haben. Und eine solche Migration ist nicht so ganz trivial. Denn zur Ablösung der Altsysteme und zum Wechsel auf S/4 sind viele verschiedene Teilschritte zu absolvieren, für die es teils externer Unterstützung bedarf. Und externe Ressourcen sind knapp, gerade jetzt, wo die Deadline immer näher kommt.

Egal welchen Migrationsansatz betroffene Unternehmen wählen, ob Greenfield, Brownfield oder Bluefield, müssen betroffene Unternehmen vieles hinterfragen. Welche Abteilungen sind beteiligt? Wer ist Haupttreiber und Verantwortlicher der Migration? Wo brauche ich welche, auch externe Unterstützung? Welche Prozesse sind betroffen? Und, und, und.

In puncto Daten sind auch eine Menge Dinge zu beachten. Die Vorgabe macht das neue Datenmodell von S/4 Hana. Denn idealerweise krempeln migrierende Unternehmen ihre Daten um. Was bisher separat als Debitor, Kreditor und weiterer Geschäftspartner gelaufen ist, muss künftig im neuen Datenmodell auf den zentralen Geschäftspartner­stamm konsolidiert werden. Da dieser Schritt früher oder später notwendig wird, ist es ratsam, die Datenkonsolidierung bei der Migration zu berücksichtigen. Erschwerend kommen oft eine mangelnde Datenqualität hinzu, eine meist historisch gewachsene Datenhaltung in Silos sowie ein oft recht umfangreiches Customizing.

Diese fast schon toxische Mischung belastender Faktoren lässt die Datenmigra­tion zu einem durchaus herausfordernden Teilprojekt werden. Laut der Studie ‚SAP S/4 Hana 2024 – Aktuelle Cloud-ERP-Trends‘ von CIO, CSO und Computerwoche sehen etwa 39 Prozent der Befragten den Aufwand für Datenmigration als größte Herausforderung beim Umstieg auf S/4 an. Auf den Plätzen zwei und drei folgen der Anpassungsaufwand der bestehenden Systemlandschaft und IT-Architektur mit etwa 37 Prozent sowie fehlende Ressourcen für die Transformation in den zuständigen Fachabteilungen (36 Prozent).

Um die Datenmigration so gut wie möglich zu vereinfachen, ist es zuallererst notwendig, sich möglichst frühzeitig im Migrationsprojekt dem Thema Daten zuzuwenden, und nicht erst, wenn die gesamte Migration so gut wie durch ist. Die Aufgabe besteht insbesondere darin, vorhandene Daten aus dem oder den Altsystemen wie ERP/ECC 6.0) auf das neue Datenmodell von S/4 Hana, den zentralen Geschäftspartnerstamm, zu konsolidieren. Die hohe Schule dabei ist es, gleichzeitig eine Bereinigung und Aufbereitung nach gängigen Datenqualitätsstandards durchzuführen, insbesondere eine postalische Validierung sowie eine Dublettenbereinigung (Identity Resolution).

Für eine effiziente Konsolidierung auf den zentralen Geschäftspartnerstamm ist eine vorbereitende Datenkonzeption ein erster wichtiger Schritt. Die Datenkonzeption bündelt sämtliche Teilschritte, die dazu dienen, die Ausgangssituation und die Zielsituation in Bezug auf die Daten von Debitoren, Kreditoren und weiteren Geschäftspartnern mit ihren Rollen zu erfassen, zu beschreiben und abschließend zu dokumentieren. In diesem Zusammenhang verschafft man sich in diesem Schritt auch einen klaren Überblick über den Zustand der Daten, die aktuellen Prozesse sowie den Grad an Customizing, der die bisherige Situation prägt. Gleichzeitig erfolgt die Festlegung der Art und Weise, wie die Daten vom alten in das neue System übertragen werden. Doch wie läuft nun konkret eine solche Datenkonzeption ab?

Die Data Exploration, also das ganz konkrete Anschauen und Untersuchen der Daten, markiert den Einstieg der Datenkonzeption. Ohne Klarheit, wie die Daten aus den verschiedenen Datenquellen, die zu migrieren sind, tatsächlich beschaffen sind, kann keine vernünftige Datenkonzeption erfolgen.

In der Data Exploration wird einerseits auf die datenqualitätsseitige Situation geschaut. Sind die Daten postalisch korrekt? Wie hoch ist der Anteil an doppelt und mehrfach vorhandenen Datensätzen? Doch auch und insbesondere die strukturelle Beschaffenheit der Daten rückt in den Fokus. Wie sind die Datensätze prinzipiell aufgebaut? Welche Felder sind vorhanden? Sind diese Felder tatsächlich gefüllt? Und sind sie auch mit den richtigen Daten gefüllt? Heißt, enthält ein Hausnummernfeld auch tatsächlich eine Hausnummer, und existiert diese Hausnummer auch wirklich? Oder gibt es ein Postleitzahlenfeld? Und wenn ja, wie ist dessen Füllgrad? Und sind das auch immer plausible Daten, wie zum Beispiel in Deutschland eine fünfstellige Postleitzahl?

Es empfiehlt sich, die zu begreifenden Daten in einen Datenhub wie den Customer Data Hub von Uniserv zu laden. Bei der Arbeit mit den Daten im Datenhub zeigt die Erfahrung, das oft vier bis fünf Iterationen notwendig sind, bis man seine Daten wirklich zu einhundert Prozent erfasst und verstanden hat und am Ende wirklich transparent dokumentiert, was für Daten man tatsächlich hat.

Ist versus Soll

Die Datenkonzeption greift die Ergebnisse der Data Exploration auf und vervollständigt das Bild der Ist-Situation. Dazu werden vor allem die Business-Prozesse erfasst, die aktuell verwendet werden. Und es geht darum, zu begreifen, welche Abteilungen involviert sind und wo welche Daten benötigt werden. Eine Sales-­Abteilung ist beispielsweise interessiert an Umsatzzahlen, Kaufhistorien, Bonitäten. Eine Finance-Abteilung wiederum benötigt Zahlungsdaten und die relevanten Ansprechpartner.

Durch diese unterschiedlichen Sichten auf ein und denselben Datensatz sowie die unterschiedlichen Datenbedarfe wird deutlich, wie komplex es einerseits ist, die Ist-Situation zu erfassen und zu beschreiben, aber gleichzeitig auch, wie wichtig.

Hat man auf der Ist-Seite den vollständigen, transparenten und klar dokumentierten Blick, kann die Arbeit an der Konzeption der Soll-Situation beginnen, dem Ziel. Interessant ist dabei, dass etwas zu beschreiben ist, das noch gar nicht existiert. Ergo ist man hier gefordert, wirklich sehr genau hinzuschauen und mit Blick auf das neue Datenmodell unterschiedlichste Fragen zu beantworten. Dazu gehört beispielsweise zu bestimmen, wie die künftigen Businessprozesse aussehen sollen. Welche Datenflüsse gibt es bereits? Welche Datenflüsse müssen abgelöst werden beziehungsweise welche müssen neu erstellt werden? Es muss festgelegt werden, welche Daten tatsächlich wo benötigt werden und wo diese Daten herkommen. Wichtig ist auch, einen Überblick zu bekommen, wo es welche wie gelagerten Schnittstellen zwischen Systemen beziehungsweise Abteilungen gibt.

Spätestens hier wird man froh sein, wenn man in den vorangegangenen Schritten präzise gearbeitet hat. Denn dann lässt sich zum Beispiel auch feststellen, ob die bestehende Datenqualität ausreichend ist, welche Daten überhaupt noch benötigt werden oder ob künftig gänzlich neue Daten erforderlich sein werden. So lässt sich hier, zunächst auf theoretischer Ebene, festlegen, welche Daten vor der Migration gelöscht werden können und was gegebenenfalls an Daten zu archivieren ist. Für welche Prozesse und Anwendungen werden welche Daten benötigt? Das reduziert die ­Menge der zu migrierenden Daten erheblich. Was zu einer Erleichterung beiträgt.

Think big, start small

Viele Unternehmen, vor allem große Konzerne, haben in ihren Organisationseinheiten und Tochtergesellschaften eine oft ungeheure Menge an Umsystemen und Daten. Wer versucht, hier auf Anhieb sofort alles vollständig zu erfassen, wird wahrscheinlich trotz allen planvollen Vorgehens scheitern. Denn oft können Migrationen nur Schritt für Schritt erfolgen; man kann es sich nicht leisten, den eigenen Betrieb tagelang lahmzulegen.
Es empfiehlt sich deshalb, sich in Data Exploration und Datenkonzeption ein großes Bild zu machen. In der Umsetzung ist es dann aber hilfreich, Quelle für Quelle beziehungsweise System für System abzuarbeiten. Denn mit dem großen Bild entsteht mit Blick auf die Gesamtmigration in Bezug auf das neue Datenmodell das Big Picture. In der kontinuierlichen Abarbeitung von Quellen und Systemen können diese in Einklang mit dem neuen Datenmodell migriert werden. Positiver Effekt: Lessons learned aus jedem Teilschritt können in das Big Picture zurückfließen und dieses weiter schärfen.

Solution Design

Steht die Datenkonzeption, kann man sich konkret Gedanken darüber machen, wie man von seinem Ist-Zustand in den Ziel­zustand kommt. Wie soll also die Transition aussehen? Die Lösung ist es, auf den zen­tralen Datenpunkt hin zu bauen. Ist die aktuelle Lösung gut so, wie sie ist, oder ist etwas anderes Zusätzliches nötig?

Das Solution Design beantwortet also die Frage, wie die Datenmigration konkret umgesetzt werden soll. Dabei bezieht sich das Solution Design auf die Gesamt­lösung und die strategische Planung. So wird die bestehende Lösung gegen ein ­alternatives Lösungsdesign geprüft. Auswahl und Umsetzung von Integrationsarchitektur und Data Stewarding Interface werden angegangen.

uniserv.com