One, two, three, four.
Hallo und herzlich willkommen bei Smart Hacks für IT Projektmanager,
präsentiert von Sidekick Network basiert unser Podcast auf der Erfahrung
von über 20.000 IT Projekten. Bist du bereit?
Direkt zum Punkt zu kommen?
Dann lass uns starten.
Herzlich willkommen zu einer neuen Folge von Smart City Breakbridge.
Ich bin Anita und heute geht es um eine spannende Herausforderung in der SAP Welt.
Der Umstieg von S vier Hana auf Selective Data Transition, auch bekannt als
Shell Conversion oder Mixer Match.
Da gibt es noch ein paar Unterschiede, aber das wird uns mein
heutiger Gast erklären.
Alex Ich freue mich sehr, dass du da bist.
Sie hat bereits mehrere SAP Projekte geleitet, hat bereits SV Hana Projekt
genau mit diesem Ansatz erfolgreich umgesetzt.
Ich spreche mit dir über Stolperfallen, über Herausforderungen und
wie man diese meistern kann.
Wir erhalten sehr wertvolle Einblicke aus der Praxis.
Und natürlich gibt es wieder ein paar Hacks von uns, die wir
am Ende mitnehmen können.
Ich freue mich sehr auf einen spannenden Podcast.
Ich freue mich darauf, selber was zu lernen und es wird sicherlich
sehr aufschlussreich.
Daher, lieber Alex, herzlich willkommen!
Schön, dass du da bist. Hallo Anita.
Danke, dass ich da sein darf.
Alex was genau ist mit Selective Data Transition im SV Hana Kontext gemeint?
Ich habe gerade schon mal angedeutet, dass es da doch ein paar Unterschiede
gibt mit den ganzen Begriffen.
Es sind, ja, es kursieren ja diverse Begriffe im Internet, in Unternehmen, in
Dokumenten zwischen Menschen, Projektleiter.
Das ist für mich auch oft schwierig.
Ist da den Unterschied zu verstehen.
Daher Selective data Transition.
Kurz die Vorteile dieses Ansatzes.
Da würde ich mich freuen für eine kurze Erläuterung.
Genau.
Also wichtig ist Bei der Selective Data Transition werden existierende
Systemeinstellungen weiterverwendet.
Je nachdem, ob du mehr mitnehmen möchtest von dem, was im System existiert.
Oder du sagst, ich möchte mir gewisse Funktionen auswählen.
Gibt es unterschiedliche Ansätze?
Auch unterhalb der Selective Data Transition.
Das eine, wenn man sagt, man möchte das gesamte Customizing mit übernehmen, dann
bezeichnet man das auch als Shell Conversion.
Und wenn man sagt, man möchte eventuell nur ausgewählte Funktionalitäten aus dem
alten System mitnehmen, dann ist es ein der Mix and Match Ansatz.
Aber beides gehört zusammen zur Selective Data Transition.
So die Daten, die man ja im alten System hat, werden je nach Anforderungen
des Kunden später migriert.
Das heißt, wir befinden uns zwischen Brownfield und Greenfield.
Die Multi Shell oder Shell Conversion wird bezeichnet, wenn man näher an der alten
Lösung ist, das heißt mehr Customizing mitnimmt.
Und mit dem Mix and Match geht man eher in Richtung der Greenfield Implementation,
weil man mehr ist für Hannah dazumischt.
Wir bleiben aber jetzt erstmal für diesen Podcast generell Selective Data
Transition.
Jetzt muss ich auch schon wieder nachdenken, Wie schlimm
ist der Data Transition?
Was sind typische Gründe, warum Unternehmen sich für eine Selective
Data Transition entscheiden?
Der eine Grund ist, dass die Unternehmen vielleicht mit ihrem System sehr zufrieden
sind und sagen Prozessual muss ich nicht wahnsinnig viel verändern,
aber ich muss hier auf SV Hana umsteigen.
Also das ist ja ein Must have, was wir heute haben.
Und mit der gerade mit der Shell Conversion können Sie
viele Ihrer Prozesse übernehmen und erst mal gar nichts oder überhaupt gar nichts
verändern und auf das SV Hana System wechseln.
Dann ist noch ein Aspekt, dass man eventuell Daten, die man über jahrelang
angesammelt hat, weil ein System schon lange läuft, nicht alle mitnehmen möchte.
Also über die Migration kann man Daten auch zurücklassen.
Genau.
Ja, grundsätzlich ist es so die Systemeinstellungen werden aus dem alten
System in ein neues System übernommen.
Das wird erstmal konvertiert.
Dann kümmert man sich um zwingende Anpassungen, die man machen muss oder
guckt was Muss man eventuell optional oder was möchte man optional ergänzen
und übernimmt halt nur die Daten?
Teilweise zwingend sind zum Beispiel Anpassungen,
die die SAP in ihrem Readiness check.
Also es gibt eine Prüfroutine, die die SAP durchführt, bevor man sein System anpasst.
Den Readiness Check.
Dann gibt es zwingende Anpassungen, die man machen muss.
Und das können Funktionen sein, die man im System genutzt hat, später nicht mehr
nutzen kann oder etwas, was man unbedingt nutzen muss, wie den Business Partner.
Das ist ja etwas, was im Svana sein muss. Das ist ja dann super.
Ich will dich nicht unterbrechen, aber dann fällt mir natürlich gleich ein am
Anfang in der Planungsphase, wenn das Thema ist mit Go live.
Was natürlich auch ein sehr strategisches Thema ist.
Dann aber gemeinsam über den Check Go Live.
Welchen Ansatz fahren wir, dass man das komplett miteinander verknüpft, diese
Entscheidungen und diese Diskussion, weil das kann man ja dann
dementsprechend optimieren.
Wie viel Zeit habe ich, welches sollte ich zuerst machen?
Was sind Prioritäten.
Genau?
Und man kann es eben am Anfang, wenn man auch insbesondere
sich für den Ansatz entschieden hat und dann weiß, wie man
genau vorgehen kann und den Realitätscheck analysiert hat, kennt man auch die
wichtigsten Eckpunkte, über die man sich Gedanken machen muss.
Und wenn man nicht viel verändern muss, kann man vielleicht die
Laufzeit verlängern.
Wenn man weiß, ich muss halt viel anpassen in meinem alten System, dann hat man ja am
Anfang noch die Zeit zu sagen okay, wir müssen den Plan vielleicht
nach hinten gehen.
Ist immer besser, als mitten im Projekt überrascht zu werden.
Man erlebt ja, so oder so werden noch Überraschungen kommen
im Laufe des Projekts und daher ist das ja natürlich ein wichtiger Punkt.
Du hast jetzt schon mehrere Projekte erlebt.
Wo liegt aus deiner Sicht speziell bei der Selective Data Transition?
Du hast schon ein paar Punkte genannt, aber wo liegen da konkret die
größten Herausforderungen?
Wie wir gerade gesagt und wie wir gerade gesagt haben, bereits
in der Planungsphase.
Was kann man da bereits in der Planungsphase vermeiden?
Genau.
Also kurz angedeutet schon, aber noch mal konkreter.
Genau.
Die größten Herausforderungen.
Haben sich immer wieder erwiesen.
Ist der Aufbau der Systemlandschaft etwas, was man aus der Erfahrung der bisherigen
Releasewechsel in einem EC System vielleicht nicht so im Fokus hat,
ist das doch etwas speziell, wenn man auf ein SVH System wechselt.
Und was man nicht unterschätzen darf oder was man hochpriorisieren sollte, ist der
Umfang der Tests, dass man dort sich Zeit nimmt und eben auch ausführlich testet,
weil man die Kombination hat von Datenmigration und Funktionen, die sich
verändern, was normalerweise Bei einem normalen
Releasewechsel ist man ja manchmal dazu übergegangen, die Tests schon sehr zu
standardisieren, runterzufahren und auf wirklich kritische
Funktionen zu begrenzen.
Das reicht bei einer Svana Conversion nicht mehr.
Also muss wieder umfangreicher testen.
So, wenn man sich das ganze jetzt mal vor Augen hält, wie eine selektive Data
Transition vor sich geht, ist es so Man nimmt die Systemeinstellungen Customizing
und Entwicklung und kopiert diese aus der Produktivumgebung in ein neues System.
Das ist noch ein CC System.
Dieses System wird dann konvertiert.
Das ist ein SVH System ist und wird später als Entwicklungssystem weiterverwendet.
Ab diesem Zeitpunkt könnten in diesem Entwicklungssystem und werden auch
Anpassungen vorgenommen, die sich aus dem Readiness Check ergeben haben oder
neue Funktionen eingeführt, die man dann doch unter Svhana nutzen möchte.
Da aber Vorsicht, da kommen wir später noch dazu.
Was jetzt hier aber wichtig ist das produktive System läuft
ja in der Regel weiter.
Also die Unternehmen stehen ja nicht still auf einmal, bloß weil ich
auf SVH konvertieren möchte.
Das heißt, ich habe ein System, was ich weiterentwickelt und ich
habe das Svhana System, was zum einen diese Weiterentwicklung immer mitnehmen
muss und aber auch weiterentwickelt wird.
Und zwar anders in eine andere Richtung mit neuen Funktionen etc..
Was sollte man bei den Testzyklen speziell beachten?
Du hast ja erzählt, das verstehe ich auch.
Ich habe parallele Systemlandschaften, wird komplex, Kann ich so
ein bisschen nachvollziehen.
Was sollte ich bei Testzyklen beachten?
Genau.
Also meine Testzyklen habe ich es als sehr vorteilhaft erlebt,
dass man drei Testzyklen sich vornimmt, und zwar
immer in Kombination Datenmigration, gefolgt von einem Funktionstest.
Dann testet man zum einen, wie gut ist die sind die Datenmigration Routinen
entwickelt und zum anderen kann ich mit den migrierten Daten meine
Funktionen ausführen.
Also es empfiehlt sich dann einen ersten Zyklus.
Dann hat man die Datenmigration im ersten Reifegrad.
Vielleicht nur 30 % der Objekte sind realisiert für die Migration oder 31 % der
der Daten sind drüben und man baut mit diesen Daten einen Funktionstest,
gegebenenfalls erweitert um manuell angelegte Daten.
Zweiter Zyklus wäre dann der Reifegrad der Datenmigration verbessert sich und
auch in den Funktionen ist man weiter.
Der dritte Zyklus ist dann eine vollständige Datenmigration
plus Integrationstests.
So, das heißt natürlich im Umkehrschluss, dass man auch mit der Umsetzung der
Routinen für die Datenmigration frühzeitig beginnen muss, damit man das alles
fertig hat in den Testphasen.
Das funktioniert nicht, wenn man zu knapp vor dem Go Live damit beginnt.
Generell ja nicht. Da haben wir das Thema Testwert.
Ich glaube, da werden wir hatten wir gemeinsam sogar schon mal, als wir
zusammen ein Projekt unterstützt haben.
So, und dann ergibt sich die Herausforderung, dass man je nach
Projektplan sich auch überlegen muss, wenn die Tests in eigenen Systemen
durchgeführt oder reichen.
Eigene Mandanten hat auch was mit der Komplexität der Entwicklungen zu tun.
Wenn ich nicht viel in der Entwicklung anpasse, was ja mandantenübergreifend
ist, kann ich mit Mandanten arbeiten.
So, das heißt, daraus ergeben sich auch Anforderungen an eine Systemlandschaft.
Wie muss meine SAP sVorlandschaft aussehen,
damit ich alle meine Projektphasen sauber hintereinander durchlaufen kann?
Ja, und das ist ein bisschen anders wie bei einem Releasewechsel in einem System.
So, dann kommt noch als einen Komplexitätstreiber dazu, dass man
sinnvollerweise für die Tests der Datenmigration im Quellsystem,
also ein Quellsystem nimmt, was man stabil hält für den Test der Datenmigration und
hier natürlich auch immer wieder Daten aus der Produktion auffrischen muss, weil
auch das produktive Leben geht weiter.
Vielleicht entwickeln sich Datenkonstellationen, die man in der
Datenmigration nicht berücksichtigt hat, die Fehler hervorbringen.
Und je näher man an den produktiven Daten ist, desto mehr Fehler hat man in den
Testphasen natürlich schon gesehen, ausgemerzt, korrigiert und desto
geschmeidiger läuft es dann am Ende, wenn man wirklich live geht mit dem Ganzen.
Vor allem, was du gesagt hast, dass es eben parallel Weiterentwicklungen sind in
dem Produktivsystem, in dem vorhandenen EQ.
Da denke ich natürlich an so Orgänderungen.
Reorganisation sollte man nicht tun.
Gerne genommen, da machen wir nicht sehr aufpassen.
Das kennen wir auch, Haben wir gemeinsam auch schon mal erlebt.
Ja und das heißt also wir haben dieses Thema, wir haben die CC Landschaft, die
sich weiterentwickelt, wir haben einen SV Hana System, was eine
neue Technologie ist.
Wir haben die Systemanforderungen für Datenmigration und Tests
und daher sehe ich es so, dass die Gestaltung der Systemlandschaft etwas ist,
was eine der größten Herausforderungen in der SV Hana Conversion ist.
Und wenn man sich darüber am Anfang in der Planung seine Gedanken macht, ist das sehr
hilfreich, weil man teilweise im Verlauf dann dort sehr viel Zeit verlieren kann.
Ein neues System, ein neuer Mandant.
Je nach Flexibilität der IT ist es schnell aufgebaut.
Aber ganz oft sind gerade solche Funktionen ja outgesourced und es sind
administrative Abläufe erforderlich oder Vorwarnphasen, die es
etwas schwieriger machen.
Deswegen, so meine Erfahrung, um dort nicht unter Druck zu geraten, empfiehlt es
sich, dass man sich das schon frühzeitig anschaut und die Gegebenheiten
berücksichtigt, unter denen man seine Systeme aufbauen muss.
Genau.
Sondern aus meiner Erfahrung ist es halt so Man muss sich Gedanken machen
über Anzahl und Größe der Systeme.
Welchen Vorlauf brauche ich, welche Vorlaufzeit, um Systeme aufzubauen?
Welche Vorlaufzeit brauche ich, um ein Quellsystem aufzufrischen und
wie gehe ich mit Retrofit und Transportprozessen
zwischen den Systemen um?
Also retrofit Wie hole ich die Sachen, die ich im ICC gemacht habe auch auf das S4
System muss ich alles manuell abtippen oder habe ich einen Prozess,
den die SAP vorgesehen hat etc..
Also das sind so die vier Bereiche, auf die man ein Auge haben sollte.
Gibt es noch einen weiteren Punkt, der weniger offensichtlich ist, wo du sagst,
das wird auch noch gern übersehen?
Also zuzüglich zu dem, was du gerade schon erwähnt hast.
Genau das ist so halb technisch aus meiner Sicht und halb anwendungsspezifisch.
Gerade in der SV Hana Conversion kommt die SAP ja oder steigt immer mehr auf.
Fury als Oberfläche um und.
Das kennen wir. Ja.
Das ist ja auch so ein schönes Schlagwort und das sieht auch so schön einfach aus
und man kann sich alles sehr schön zusammenkonfigurieren.
Aber ich glaube, dass da oder auch bei uns im Projekt hat es sich
gezeigt, dass das einer der größten Stolpersteine ist.
Wenn man sagt, in der SV Conversion steigt man auch sofort komplett auf Fury um.
Insbesondere wenn man Applikationen mit viel kundeneigene
Entwicklung hat, weil Fury in diesem Fall eben auch weiterentwickelt werden muss.
Also die Oberfläche müssen weiterentwickelt werden und das läuft
etwas anders als in der heutigen App ab Entwicklung oder GUI
Transaktionsentwicklung.
Deswegen ist so meine Erfahrung und meine Empfehlung in der reinen S4 Conversion
sich auf die Transaktionen zu begrenzen, die man unbedingt braucht.
Weil es gibt Transaktionen, die gibt es nur noch in Fury später und ansonsten aber
idealerweise auf der alten GUI Transaktion erstmal zu verbleiben.
Was geht?
Ja und ja, dann sollte man versuchen, das auf kleinere Initiativen in
die Zukunft zu verschieben.
Weil man darf nicht vergessen so eine SV Conversion.
Das gesamte System muss umgestellt werden und das hat eine gewisse Komplexität
schon von sich aus, von Haus aus.
Während wenn man später sagt ich optimiere weitere Funktionen, dann ist es vielleicht
nicht so schlimm, wenn dort sich einmal.
Also erstens kann man die Komplexität reduzieren, weil man einzelne
einzelne kleine Aktivitäten durchführen kann, und es ist nicht so schlimm, wenn
sich dort die Zeit verzögern sollte.
Bei einer SV Conversion ist aber eine Zeitverzögerung direkt extrem teuer,
weil die Mannschaft dabei ist etc.
Deswegen Fokus auf das, was unbedingt notwendig ist und nicht versuchen so
viel wie möglich direkt umzusetzen.
Das fand ich eigentlich ganz nett, nämlich mit dem Bonbonladen.
Ja, ich finde SAP ist halt.
Kann man so ganz nachvollziehen, deswegen würde ich da gern noch mal nachhaken.
Genau.
Also wenn man in die SV Hana Conversion geht, gibt es ja viele neue Funktionen und
vieles, was die SAP auch gerade unter Fury optimiert und einfacher macht.
Und Reporting, Transaktional Reporting Kacheln, die auch wirklich einen guten
Eindruck machen, so dass man davor steht, wie ein kleines Kind im Bonbonladen und
sich denkt Oh, das möchte ich haben und das möchte ich haben
und das schmeckt super.
Und wie mit den Bonbons ist es, Wenn man zu viel auf einmal genießt,
hat man am Ende Bauchschmerzen?
Und für mich war das eine der wesentlichsten Erfahrungen zu
sehen, dass eine SV Hana Orientierung genau das sein kann.
Das kleine Kind im Bonbonladen Lieber wenige Bonbons sehr dosiert essen,
vorher entscheiden, welche Süßigkeiten es heute gibt und in diesem Jahr und dann
später sagen Du kriegst dieses Bonbon drei Monate später oder jenes Bonbon,
dann ein halbes Jahr später.
Und sich einfach in der Organisation, in kleinen Initiativen weiterentwickeln.
Wenn man jetzt am Anfang eines Projektes steht, noch mal ganz kurz
so zusammengefasst.
Also generell was würdest du den Unternehmen raten?
Wie haben die Risiken aufgeführt?
Stolpersteine, wenn du jetzt am Anfang des Projekts stehen.
So, und wenn du jetzt auf die drei Themen siehst, die wir hatten, ist es.
Nimm dir ausreichend Zeit für deine Testzyklen, Plane idealerweise
drei Testzyklen ein.
Immer Migration und Funktion hintereinander geschaltet, immer auch mit
entsprechenden Abnahmezeiten hinten dran.
Denkt frühzeitig an die Systemlandschaft, überlegt, wie man das intelligent aufbauen
kann und welche Zeit ihr vor allem auch dafür braucht, damit es gut funktioniert.
Und ähm, ja, was zu den, ähm, zur Systemlandschaft angeht, da würden wir
dann noch mal auf die Checkliste im Hintergrund verweisen.
Ja, erkläre ich gleich was genau.
Damit ihr da vielleicht auch noch ein paar Fragen zu dem ganzen Text habt.
Welche?
Welche Fragen man sich stellen sollte, wenn man über die
Systemlandschaft nachdenkt.
Ich freue mich, dass du es übernommen hast.
Die Zusammenfassung der Hacks, das schreiben wir auch noch mal in
die Show, in die Shownotes rein.
Das waren jetzt zwei und wir haben einen ganz besonderen dritten Hack heute.
Das hast du gerade kurz erwähnt, dass die sind.
Das ist in den Shownotes aufgeführt. Nämlich?
Du hast uns eine Checkliste mitgebracht, die man für den Systemaufbau bereits in
der Planungsphase nutzen kann, wenn man sich für eine selektive
Data Transition entscheidet.
Egal ob Mixer, Match oder Shell. Das ist das Schöne.
Man kann es für beide verwenden und man kann Copy Paste und man kann in der
Planungsphase dann die Checkliste durchgehen, was natürlich grandios ist.
Ich habe viel gelernt und freue mich ganz herzlich, dass Du da warst.
Vielen Dank für die Insights und auch für die ehrlichen Worte aus deinem Projekt.
Das war wirklich spannend. Danke schön.
Es hat Spaß gemacht.
Und Euch, liebe Zuhörerinnen und Zuhörer, danke fürs Dabeisein.
Bis zum nächsten Mal, eure Anita.
Bis dann.
Ich schicke.