Nachdem wir im ersten Blogbeitrag die Relevanz von Partnerrollen skizziert und eine Datenmigration schematisch dargestellt haben, geht es nun um deren Ablauf mit SAP MDG Consolidation. Es handelt sich um einen zweistufigen Prozess: Auf die Migration der Kundenstammdaten folgt das Auflösen der Referenzen in den Partnerrollen.
Nach dem Data Cleansing bildet der Datenimport den Auftakt für die Migration. Die Standard-Applikation in SAP MDG Consolidation für den Import heißt „Daten für Konsolidierung importieren“. Zunächst muss der User eine Quelldatei auf Basis eines bestimmten Template auswählen und hochladen. Je nach Use Case stehen verschiedene Templates zur Wahl. Beim Befüllen ist die Source ID wichtig, da sie alle anderen Segmente referenziert.
Als Quellsystem kann der Anwender entweder ein physikalisches System hinterlegen – sofern ein System Landscape Directory angebunden ist – oder einen Freitext. Das Datenpaket ist ebenfalls ein Freitextfeld. Dieses wird später benötigt, um die Daten in einem Paket zu bündeln und in einen Prozess zu überführen. Zunächst werden die Daten also in einen speziellen Quellbereich in SAP MDG Consolidation geladen. Erst wenn der Anwender einen Prozess startet, wählt er anhand der Datenpakete die Daten aus, die er prozessieren möchten. Diese werden dann in einen Arbeitsbereich überführt. Zu diesem Zeitpunkt sind die Daten jedoch noch nicht aktiv.
Ein Klick auf „Importieren“ startet den eigentlichen Importvorgang. Das Importprotokoll zeigt potenzielle Fehler und Warnungen an. Von ihm kann der Anwender über die Schaltfläche „Konsolidieren“ abspringen und das Datenpaket in einen Prozess überführen.
Stellt man während der Migration fest, dass Datensegmente fehlen oder die Daten strukturell nicht valide sind und sich die Fehler nicht beheben lassen, ist die Empfehlung, die Daten nicht neu zu laden, sondern erst zu bereinigen, um nicht mit inkonsistenten Daten fortfahren zu müssen. Hierfür steht die Applikation „Quelldaten verwalten“ zur Verfügung. Sie listet alle importierten Loads und den Status der Datensätze (Neu, In Bearbeitung, Konsolidiert) in einer Übersicht auf.
Wenn die Daten im System sind, wird der Konsolidierungsprozess über die Applikation „Konsolidierungsprozess anlegen“ gestartet. Als Bezeichnung lässt sich ein Freitext hinterlegen. Dann muss der Anwender noch das Prozessziel, eine Prozessvorlage und das entsprechende Datenpaket als Datenquelle auswählen. Da es sich, wie beschrieben, bei der Konsolidierung um einen zweistufigen Prozess handelt, sollten die Quelldaten nach dem Abschluss des ersten Schritts nicht gelöscht, sondern beibehalten werden, um sie nicht erneut in das System laden zu müssen.
Mit einem Klick auf „Sichern“ wird der Prozess angelegt, aber noch nicht gestartet. Im Customizing ist das Prozess-Template mit folgenden Schritten konfiguriert: initiale Prüfung, Key Mapping, Datenvergleich, Ermittlung des optimalen Datensatzes, Validierung und Aktivierung. Die Schritte laufen sequenziell ab. Das heißt, die Reihenfolge lässt sich innerhalb des Prozesses nicht dynamisch verändern. Dafür müsste zunächst das Template modifiziert werden. Dadurch, dass der Prozess immer identisch abläuft, wird die Prozessstabilität erhöht. Bei der initialen Prüfung werden die Daten gegen das Backend validiert und es wird geprüft, ob sie strukturell in Ordnung sind oder ob Pflichtfeldverletzungen vorliegen. Das Ziel der initialen Prüfung ist es, valide Daten zu erhalten.
Bei der Aktivierung prüft SAP, ob die referenzierte Kundennummer aktiv im System vorhanden ist. Ist das nicht der Fall, kommt es zu einem Fehler in der Aktivierung. Im Vorgriff auf diesen Schritt prüft das Key Mapping die ID aus dem Quelldatensatz gegen den Key-Mapping-Store des lokalen Systems. Ermittelt es einen aktiven Datensatz, ersetzt es die Referenz aus der lokalen ID in die Ziel-ID. Findet das Key Mapping keinen aktiven Datensatz, wird die Referenz geleert.
Der Datenvergleich soll verhindern, dass Duplikate in das System kommen. Der Anwender kann frei konfigurieren, welche Attribute relevant sind. Der Datenvergleich bezieht sowohl Daten aus dem aktuellen Konsolidierungsprozess, die noch nicht aktiv sind, als auch den aktiven Datenbestand ein.
Die Ermittlung des optimalen Datensatzes dient dazu, im Falle von Duplikaten sicherzustellen, dass der Zieldatensatz (Best Record) optimal angereichert wird. Die finale Validierung sorgt dafür, dass nur valide Daten in das System kommen.
Grundsätzlich lässt sich SAP MDG Consolidation mit S/4HANA ohne zentrale Governance für die Datenmigration verwenden. In diesem Fall steht nur die direkte Aktivierung der Daten zur Auswahl. Liegt hingegen eine zentrale Governance vor, kann der Anwender konfigurieren, wie die Daten aktiviert werden sollen. Neben der direkten Aktivierung gibt es nämlich die Möglichkeit, die Daten zunächst in einen Änderungsantrag zu schreiben. Das ist beispielsweise sinnvoll, wenn noch komplexe nachgelagerte Prozesse folgen, die ohnehin ein manuelles Eingreifen erfordern. Üblicherweise werden fehlerfreie Datensätze direkt aktiviert und fehlerhafte Datensätze in einen Änderungsantrag geschrieben.
Die Validierung mit SAP MDG Consolidation erfolgt nicht dynamisch. Man muss also zunächst die gefundenen Fehler bereinigen und anschließend einen weiteren Validierungsschritt mit den aktualisierten Daten hinzufügen.
Da bei der Konsolidierung die Referenzen auf andere Kundenstammsätze verloren gehen, ist eine zweite Stufe im Prozess erforderlich: die Aktivierung der Partnerrollen. Sie erfolgt ebenfalls über die Schaltfläche „Konsolidierungsprozess anlegen“. Grundlage für den zweiten Prozessschritt ist ein leicht verändertes Prozesstemplate, das keine initiale Prüfung mehr vorsieht, da diese bereits im ersten Schritt erfolgt ist.
Der Prozess startet also direkt mit dem Key Mapping. Dabei wird deutlich, dass die Referenzen in den Partnerrollen nicht initial sind, sondern die finalen IDs referenziert werden. Beim Datenvergleich erkennt MDG Consolidation, dass der Datensatz bereits prozessiert wurde, und vergleicht automatisch gegen die aktiven Datensätze. Die Best Record Calculation überführt jetzt die korrekten Referenzen aus dem Key Mapping in den Zieldatensatz. Nach der erfolgreichen Validierung lassen sich die Daten schließlich aktivieren. Das Ergebnis: In einem zweistufigen Prozess Kundenstammsätze migriert, Business Partner angelegt und die Referenzen in den Partnerrollen aufgelöst.
Die Migration von Partnerrollen über Referenzen geht mit einigen Herausforderungen einher: Die Referenzen müssen zunächst ermittelt werden und man muss sicherstellen, dass sie korrekt aufgelöst werden. Gelingt das nicht, ergeben sich negative Auswirkungen auf die operativen Prozesse: Waren gehen an den falschen Empfänger, Rechnungen werden an die falsche Adresse gesendet. Hinweis: Mit MDG für S4HANA1909 können Referenzen laut SAP direkt aufgelöst werden, das heißt es ist kein zweistufiger Prozess notwendig.
Auch in der zentralen Governance lässt sich nur gegen aktive Kunden referenzieren. Darüber hinaus gibt es im Customizing je nach Ausprägung der Kontengruppen obligatorische Partnerrollen. Daher muss sichergestellt sein, dass diese Partnerrollen auch am Kundenstamm ausgeprägt sind. Ist das nicht der Fall, erzeugt SAP MDG Consolidation bereits während des Prozesses entsprechende Fehlermeldungen. Dieses frühzeitige Erkennen von Problemen bedeutet einen großen Vorteil.
SAP MDG Consolidation lässt sich auch nutzen, um mehrstufige Migrationsprozesse aufzubauen. Im Falle der Partnerrollen führt das Tool die Auflösung der Referenzen automatisiert durch. Insgesamt bleibt also festzuhalten, dass SAP MDG Consolidation viel Funktionalität bei der Migration von Stammdaten bietet.