WEBVTT

00:00:02.560 --> 00:00:04.840
One, two, three, four.

00:00:05.200 --> 00:00:09.800
Hallo und herzlich willkommen bei Smart
Hacks für IT Projektmanager,

00:00:10.240 --> 00:00:14.495
präsentiert von Sidekick Network basiert
unser Podcast auf der Erfahrung

00:00:14.520 --> 00:00:18.080
von über 20.000 IT Projekten.
Bist du bereit?

00:00:18.120 --> 00:00:19.480
Direkt zum Punkt zu kommen?

00:00:19.520 --> 00:00:21.160
Dann lass uns starten.

00:00:26.200 --> 00:00:29.800
Herzlich willkommen zu einer neuen
Folge von Smart City Breakbridge.

00:00:30.000 --> 00:00:34.280
Ich bin Anita und heute geht es um eine
spannende Herausforderung in der SAP Welt.

00:00:34.600 --> 00:00:39.735
Der Umstieg von S vier Hana auf Selective
Data Transition, auch bekannt als

00:00:39.760 --> 00:00:41.375
Shell Conversion oder Mixer Match.

00:00:41.400 --> 00:00:44.495
Da gibt es noch ein paar Unterschiede,
aber das wird uns mein

00:00:44.520 --> 00:00:46.920
heutiger Gast erklären.

00:00:46.960 --> 00:00:48.960
Alex Ich freue mich sehr, dass du da bist.

00:00:49.480 --> 00:00:53.535
Sie hat bereits mehrere SAP Projekte
geleitet, hat bereits SV Hana Projekt

00:00:53.560 --> 00:00:56.040
genau mit diesem Ansatz
erfolgreich umgesetzt.

00:00:56.280 --> 00:00:59.895
Ich spreche mit dir über Stolperfallen,
über Herausforderungen und

00:00:59.920 --> 00:01:01.200
wie man diese meistern kann.

00:01:01.240 --> 00:01:04.015
Wir erhalten sehr wertvolle
Einblicke aus der Praxis.

00:01:04.040 --> 00:01:06.695
Und natürlich gibt es wieder ein paar
Hacks von uns, die wir

00:01:06.720 --> 00:01:07.800
am Ende mitnehmen können.

00:01:07.880 --> 00:01:10.040
Ich freue mich sehr auf
einen spannenden Podcast.

00:01:10.065 --> 00:01:13.720
Ich freue mich darauf, selber was zu
lernen und es wird sicherlich

00:01:13.760 --> 00:01:15.160
sehr aufschlussreich.

00:01:15.200 --> 00:01:17.200
Daher, lieber Alex, herzlich willkommen!

00:01:17.240 --> 00:01:19.320
Schön, dass du da bist.
Hallo Anita.

00:01:19.440 --> 00:01:20.880
Danke, dass ich da sein darf.

00:01:22.280 --> 00:01:26.855
Alex was genau ist mit Selective Data
Transition im SV Hana Kontext gemeint?

00:01:26.880 --> 00:01:30.815
Ich habe gerade schon mal angedeutet, dass
es da doch ein paar Unterschiede

00:01:30.840 --> 00:01:32.375
gibt mit den ganzen Begriffen.

00:01:32.400 --> 00:01:37.415
Es sind, ja, es kursieren ja diverse
Begriffe im Internet, in Unternehmen, in

00:01:37.440 --> 00:01:40.240
Dokumenten zwischen
Menschen, Projektleiter.

00:01:40.360 --> 00:01:42.135
Das ist für mich auch oft schwierig.

00:01:42.160 --> 00:01:43.560
Ist da den Unterschied zu verstehen.

00:01:43.585 --> 00:01:46.040
Daher Selective data Transition.

00:01:46.840 --> 00:01:49.295
Kurz die Vorteile dieses Ansatzes.

00:01:49.320 --> 00:01:51.735
Da würde ich mich freuen
für eine kurze Erläuterung.

00:01:51.760 --> 00:01:52.120
Genau.

00:01:52.160 --> 00:01:55.415
Also wichtig ist Bei der Selective Data
Transition werden existierende

00:01:55.440 --> 00:01:57.560
Systemeinstellungen weiterverwendet.

00:01:57.600 --> 00:02:03.775
Je nachdem, ob du mehr mitnehmen möchtest
von dem, was im System existiert.

00:02:03.800 --> 00:02:07.760
Oder du sagst, ich möchte mir
gewisse Funktionen auswählen.

00:02:07.800 --> 00:02:09.720
Gibt es unterschiedliche Ansätze?

00:02:09.760 --> 00:02:11.760
Auch unterhalb der
Selective Data Transition.

00:02:12.080 --> 00:02:15.855
Das eine, wenn man sagt, man möchte das
gesamte Customizing mit übernehmen, dann

00:02:15.880 --> 00:02:18.120
bezeichnet man das auch
als Shell Conversion.

00:02:18.160 --> 00:02:22.015
Und wenn man sagt, man möchte eventuell
nur ausgewählte Funktionalitäten aus dem

00:02:22.040 --> 00:02:26.000
alten System mitnehmen, dann ist
es ein der Mix and Match Ansatz.

00:02:26.120 --> 00:02:29.360
Aber beides gehört zusammen
zur Selective Data Transition.

00:02:29.880 --> 00:02:33.120
So die Daten, die man ja im alten System
hat, werden je nach Anforderungen

00:02:33.145 --> 00:02:34.960
des Kunden später migriert.

00:02:35.200 --> 00:02:40.440
Das heißt, wir befinden uns
zwischen Brownfield und Greenfield.

00:02:40.480 --> 00:02:44.735
Die Multi Shell oder Shell Conversion wird
bezeichnet, wenn man näher an der alten

00:02:44.760 --> 00:02:46.840
Lösung ist, das heißt
mehr Customizing mitnimmt.

00:02:47.000 --> 00:02:51.080
Und mit dem Mix and Match geht man eher in
Richtung der Greenfield Implementation,

00:02:51.120 --> 00:02:52.760
weil man mehr ist für Hannah dazumischt.

00:02:53.760 --> 00:02:58.760
Wir bleiben aber jetzt erstmal für diesen
Podcast generell Selective Data

00:02:59.560 --> 00:03:00.280
Transition.

00:03:00.320 --> 00:03:03.520
Jetzt muss ich auch schon wieder
nachdenken, Wie schlimm

00:03:03.840 --> 00:03:05.680
ist der Data Transition?

00:03:06.680 --> 00:03:10.680
Was sind typische Gründe, warum
Unternehmen sich für eine Selective

00:03:10.720 --> 00:03:12.200
Data Transition entscheiden?

00:03:13.120 --> 00:03:16.720
Der eine Grund ist, dass die Unternehmen
vielleicht mit ihrem System sehr zufrieden

00:03:16.745 --> 00:03:20.720
sind und sagen Prozessual muss ich nicht
wahnsinnig viel verändern,

00:03:21.560 --> 00:03:23.600
aber ich muss hier auf SV Hana umsteigen.

00:03:23.640 --> 00:03:26.800
Also das ist ja ein Must
have, was wir heute haben.

00:03:26.880 --> 00:03:30.055
Und mit der
gerade mit der Shell Conversion können Sie

00:03:30.080 --> 00:03:36.255
viele Ihrer Prozesse übernehmen und erst
mal gar nichts oder überhaupt gar nichts

00:03:36.280 --> 00:03:39.040
verändern und auf das
SV Hana System wechseln.

00:03:39.960 --> 00:03:43.375
Dann ist noch ein Aspekt, dass man
eventuell Daten, die man über jahrelang

00:03:43.400 --> 00:03:48.615
angesammelt hat, weil ein System schon
lange läuft, nicht alle mitnehmen möchte.

00:03:48.640 --> 00:03:52.000
Also über die Migration kann
man Daten auch zurücklassen.

00:03:52.960 --> 00:03:53.360
Genau.

00:03:53.400 --> 00:03:59.775
Ja, grundsätzlich ist es so die
Systemeinstellungen werden aus dem alten

00:03:59.800 --> 00:04:01.960
System in ein neues System übernommen.

00:04:02.240 --> 00:04:03.880
Das wird erstmal konvertiert.

00:04:03.920 --> 00:04:08.040
Dann kümmert man sich um zwingende
Anpassungen, die man machen muss oder

00:04:09.960 --> 00:04:14.280
guckt was Muss man eventuell optional oder
was möchte man optional ergänzen

00:04:14.680 --> 00:04:16.815
und übernimmt halt nur die Daten?

00:04:16.840 --> 00:04:21.215
Teilweise
zwingend sind zum Beispiel Anpassungen,

00:04:21.240 --> 00:04:22.960
die die SAP in ihrem Readiness check.

00:04:23.000 --> 00:04:27.800
Also es gibt eine Prüfroutine, die die SAP
durchführt, bevor man sein System anpasst.

00:04:27.840 --> 00:04:28.760
Den Readiness Check.

00:04:29.400 --> 00:04:31.880
Dann gibt es zwingende
Anpassungen, die man machen muss.

00:04:32.480 --> 00:04:37.720
Und das können Funktionen sein, die man im
System genutzt hat, später nicht mehr

00:04:37.760 --> 00:04:42.280
nutzen kann oder etwas, was man unbedingt
nutzen muss, wie den Business Partner.

00:04:42.680 --> 00:04:45.520
Das ist ja etwas, was im Svana sein muss.
Das ist ja dann super.

00:04:45.560 --> 00:04:48.720
Ich will dich nicht unterbrechen, aber
dann fällt mir natürlich gleich ein am

00:04:48.745 --> 00:04:51.440
Anfang in der Planungsphase,
wenn das Thema ist mit Go live.

00:04:51.640 --> 00:04:54.040
Was natürlich auch ein sehr
strategisches Thema ist.

00:04:55.080 --> 00:04:59.120
Dann aber gemeinsam
über den Check Go Live.

00:04:59.280 --> 00:05:03.855
Welchen Ansatz fahren wir, dass man das
komplett miteinander verknüpft, diese

00:05:03.880 --> 00:05:06.920
Entscheidungen und diese Diskussion, weil
das kann man ja dann

00:05:06.960 --> 00:05:08.375
dementsprechend optimieren.

00:05:08.400 --> 00:05:10.760
Wie viel Zeit habe ich, welches
sollte ich zuerst machen?

00:05:10.785 --> 00:05:12.000
Was sind Prioritäten.

00:05:12.800 --> 00:05:13.120
Genau?

00:05:13.360 --> 00:05:16.760
Und man kann es eben am Anfang, wenn man
auch insbesondere

00:05:17.280 --> 00:05:20.040
sich für den Ansatz entschieden hat und
dann weiß, wie man

00:05:21.800 --> 00:05:26.055
genau vorgehen kann und den Realitätscheck
analysiert hat, kennt man auch die

00:05:26.080 --> 00:05:29.440
wichtigsten Eckpunkte, über die
man sich Gedanken machen muss.

00:05:29.560 --> 00:05:32.615
Und wenn man nicht viel verändern muss,
kann man vielleicht die

00:05:32.640 --> 00:05:33.575
Laufzeit verlängern.

00:05:33.600 --> 00:05:39.215
Wenn man weiß, ich muss halt viel anpassen
in meinem alten System, dann hat man ja am

00:05:39.240 --> 00:05:41.775
Anfang noch die Zeit zu sagen okay, wir
müssen den Plan vielleicht

00:05:41.800 --> 00:05:42.500
nach hinten gehen.

00:05:42.525 --> 00:05:45.440
Ist immer besser, als mitten im
Projekt überrascht zu werden.

00:05:46.360 --> 00:05:49.880
Man erlebt ja, so oder so werden noch
Überraschungen kommen

00:05:50.520 --> 00:05:54.360
im Laufe des Projekts und daher ist
das ja natürlich ein wichtiger Punkt.

00:05:56.520 --> 00:05:59.400
Du hast jetzt schon
mehrere Projekte erlebt.

00:05:59.880 --> 00:06:04.840
Wo liegt aus deiner Sicht speziell
bei der Selective Data Transition?

00:06:04.880 --> 00:06:08.200
Du hast schon ein paar Punkte genannt,
aber wo liegen da konkret die

00:06:08.720 --> 00:06:09.880
größten Herausforderungen?

00:06:09.905 --> 00:06:12.775
Wie wir gerade gesagt und wie wir gerade
gesagt haben, bereits

00:06:12.800 --> 00:06:13.720
in der Planungsphase.

00:06:13.745 --> 00:06:16.340
Was kann man da bereits in
der Planungsphase vermeiden?

00:06:16.800 --> 00:06:17.080
Genau.

00:06:17.105 --> 00:06:20.720
Also kurz angedeutet schon,
aber noch mal konkreter.

00:06:21.400 --> 00:06:21.800
Genau.

00:06:22.680 --> 00:06:24.400
Die größten Herausforderungen.

00:06:26.560 --> 00:06:27.760
Haben sich immer wieder erwiesen.

00:06:27.785 --> 00:06:32.535
Ist der Aufbau der Systemlandschaft etwas,
was man aus der Erfahrung der bisherigen

00:06:32.560 --> 00:06:36.640
Releasewechsel in einem EC System
vielleicht nicht so im Fokus hat,

00:06:37.680 --> 00:06:42.200
ist das doch etwas speziell, wenn
man auf ein SVH System wechselt.

00:06:42.680 --> 00:06:48.255
Und was man nicht unterschätzen darf oder
was man hochpriorisieren sollte, ist der

00:06:48.280 --> 00:06:53.535
Umfang der Tests, dass man dort sich Zeit
nimmt und eben auch ausführlich testet,

00:06:53.560 --> 00:06:57.095
weil man die Kombination hat von
Datenmigration und Funktionen, die sich

00:06:57.120 --> 00:07:01.335
verändern,
was normalerweise Bei einem normalen

00:07:01.360 --> 00:07:05.215
Releasewechsel ist man ja manchmal dazu
übergegangen, die Tests schon sehr zu

00:07:05.240 --> 00:07:08.255
standardisieren, runterzufahren und auf
wirklich kritische

00:07:08.280 --> 00:07:09.495
Funktionen zu begrenzen.

00:07:09.520 --> 00:07:12.320
Das reicht bei einer Svana
Conversion nicht mehr.

00:07:12.720 --> 00:07:14.440
Also muss wieder umfangreicher testen.

00:07:16.360 --> 00:07:21.335
So, wenn man sich das ganze jetzt mal vor
Augen hält, wie eine selektive Data

00:07:21.360 --> 00:07:27.735
Transition vor sich geht, ist es so Man
nimmt die Systemeinstellungen Customizing

00:07:27.760 --> 00:07:33.400
und Entwicklung und kopiert diese aus der
Produktivumgebung in ein neues System.

00:07:33.440 --> 00:07:35.040
Das ist noch ein CC System.

00:07:36.920 --> 00:07:39.655
Dieses System wird dann konvertiert.

00:07:39.680 --> 00:07:45.320
Das ist ein SVH System ist und wird später
als Entwicklungssystem weiterverwendet.

00:07:46.160 --> 00:07:49.480
Ab diesem Zeitpunkt könnten in diesem
Entwicklungssystem und werden auch

00:07:50.720 --> 00:07:56.080
Anpassungen vorgenommen, die sich aus dem
Readiness Check ergeben haben oder

00:07:56.560 --> 00:08:01.680
neue Funktionen eingeführt, die man
dann doch unter Svhana nutzen möchte.

00:08:02.160 --> 00:08:04.840
Da aber Vorsicht, da kommen
wir später noch dazu.

00:08:07.760 --> 00:08:11.375
Was jetzt hier aber wichtig ist das
produktive System läuft

00:08:11.400 --> 00:08:13.120
ja in der Regel weiter.

00:08:13.160 --> 00:08:16.440
Also die Unternehmen stehen ja nicht still
auf einmal, bloß weil ich

00:08:16.480 --> 00:08:18.560
auf SVH konvertieren möchte.

00:08:18.720 --> 00:08:22.615
Das heißt, ich habe ein
System, was ich weiterentwickelt und ich

00:08:22.640 --> 00:08:26.080
habe das Svhana System, was zum einen
diese Weiterentwicklung immer mitnehmen

00:08:26.105 --> 00:08:28.280
muss und aber auch weiterentwickelt wird.

00:08:28.320 --> 00:08:32.840
Und zwar anders in eine andere
Richtung mit neuen Funktionen etc..

00:08:33.480 --> 00:08:35.760
Was sollte man bei den
Testzyklen speziell beachten?

00:08:35.880 --> 00:08:37.800
Du hast ja erzählt, das verstehe ich auch.

00:08:38.400 --> 00:08:42.655
Ich habe parallele Systemlandschaften,
wird komplex, Kann ich so

00:08:42.680 --> 00:08:44.015
ein bisschen nachvollziehen.

00:08:44.040 --> 00:08:45.880
Was sollte ich bei Testzyklen beachten?

00:08:47.040 --> 00:08:47.280
Genau.

00:08:47.320 --> 00:08:52.015
Also meine Testzyklen
habe ich es als sehr vorteilhaft erlebt,

00:08:52.040 --> 00:08:57.400
dass man
drei Testzyklen sich vornimmt, und zwar

00:08:57.440 --> 00:09:00.960
immer in Kombination Datenmigration,
gefolgt von einem Funktionstest.

00:09:01.000 --> 00:09:05.135
Dann testet man zum einen, wie gut ist die
sind die Datenmigration Routinen

00:09:05.160 --> 00:09:08.895
entwickelt und zum anderen kann ich mit
den migrierten Daten meine

00:09:08.920 --> 00:09:10.040
Funktionen ausführen.

00:09:10.480 --> 00:09:12.480
Also es empfiehlt sich
dann einen ersten Zyklus.

00:09:12.520 --> 00:09:15.480
Dann hat man die Datenmigration
im ersten Reifegrad.

00:09:15.600 --> 00:09:21.240
Vielleicht nur 30 % der Objekte sind
realisiert für die Migration oder 31 % der

00:09:21.280 --> 00:09:25.255
der Daten sind drüben und man baut mit
diesen Daten einen Funktionstest,

00:09:25.280 --> 00:09:28.120
gegebenenfalls erweitert
um manuell angelegte Daten.

00:09:28.240 --> 00:09:31.815
Zweiter Zyklus wäre dann der Reifegrad der
Datenmigration verbessert sich und

00:09:31.840 --> 00:09:33.440
auch in den Funktionen ist man weiter.

00:09:33.680 --> 00:09:36.920
Der dritte Zyklus ist dann eine
vollständige Datenmigration

00:09:36.960 --> 00:09:38.800
plus Integrationstests.

00:09:39.440 --> 00:09:43.495
So, das heißt natürlich im Umkehrschluss,
dass man auch mit der Umsetzung der

00:09:43.520 --> 00:09:47.720
Routinen für die Datenmigration frühzeitig
beginnen muss, damit man das alles

00:09:47.800 --> 00:09:49.335
fertig hat in den Testphasen.

00:09:49.360 --> 00:09:53.160
Das funktioniert nicht, wenn man zu
knapp vor dem Go Live damit beginnt.

00:09:54.040 --> 00:09:57.560
Generell ja nicht.
Da haben wir das Thema Testwert.

00:09:58.080 --> 00:10:01.240
Ich glaube, da werden wir hatten wir
gemeinsam sogar schon mal, als wir

00:10:01.265 --> 00:10:03.480
zusammen ein Projekt unterstützt haben.

00:10:03.600 --> 00:10:07.695
So, und dann ergibt sich die
Herausforderung, dass man je nach

00:10:07.720 --> 00:10:13.495
Projektplan sich auch überlegen muss, wenn
die Tests in eigenen Systemen

00:10:13.520 --> 00:10:14.895
durchgeführt oder reichen.

00:10:14.920 --> 00:10:19.135
Eigene Mandanten hat auch was mit der
Komplexität der Entwicklungen zu tun.

00:10:19.160 --> 00:10:22.575
Wenn ich nicht viel in der Entwicklung
anpasse, was ja mandantenübergreifend

00:10:22.600 --> 00:10:24.600
ist, kann ich mit Mandanten arbeiten.

00:10:24.640 --> 00:10:29.335
So, das heißt, daraus ergeben sich auch
Anforderungen an eine Systemlandschaft.

00:10:29.360 --> 00:10:32.800
Wie muss meine SAP sVorlandschaft
aussehen,

00:10:33.760 --> 00:10:39.080
damit ich alle meine Projektphasen
sauber hintereinander durchlaufen kann?

00:10:39.920 --> 00:10:44.120
Ja, und das ist ein bisschen anders wie
bei einem Releasewechsel in einem System.

00:10:44.840 --> 00:10:48.360
So, dann kommt noch als einen
Komplexitätstreiber dazu, dass man

00:10:48.400 --> 00:10:52.720
sinnvollerweise für die Tests der
Datenmigration im Quellsystem,

00:10:54.040 --> 00:10:58.495
also ein Quellsystem nimmt, was man stabil
hält für den Test der Datenmigration und

00:10:58.520 --> 00:11:02.080
hier natürlich auch immer wieder Daten aus
der Produktion auffrischen muss, weil

00:11:02.120 --> 00:11:04.040
auch das produktive Leben geht weiter.

00:11:04.360 --> 00:11:07.240
Vielleicht entwickeln sich
Datenkonstellationen, die man in der

00:11:07.280 --> 00:11:12.560
Datenmigration nicht berücksichtigt
hat, die Fehler hervorbringen.

00:11:12.600 --> 00:11:16.575
Und je näher man an den produktiven Daten
ist, desto mehr Fehler hat man in den

00:11:16.600 --> 00:11:20.760
Testphasen natürlich schon gesehen,
ausgemerzt, korrigiert und desto

00:11:21.240 --> 00:11:25.200
geschmeidiger läuft es dann am Ende, wenn
man wirklich live geht mit dem Ganzen.

00:11:25.360 --> 00:11:29.295
Vor allem, was du gesagt hast, dass es
eben parallel Weiterentwicklungen sind in

00:11:29.320 --> 00:11:32.440
dem Produktivsystem,
in dem vorhandenen EQ.

00:11:32.720 --> 00:11:36.160
Da denke ich natürlich
an so Orgänderungen.

00:11:36.320 --> 00:11:39.255
Reorganisation sollte man nicht tun.

00:11:39.280 --> 00:11:42.400
Gerne genommen, da machen
wir nicht sehr aufpassen.

00:11:42.840 --> 00:11:45.440
Das kennen wir auch, Haben wir
gemeinsam auch schon mal erlebt.

00:11:45.800 --> 00:11:48.855
Ja und das heißt also wir haben dieses
Thema, wir haben die CC Landschaft, die

00:11:48.880 --> 00:11:51.720
sich weiterentwickelt, wir haben einen SV
Hana System, was eine

00:11:51.745 --> 00:11:53.240
neue Technologie ist.

00:11:53.840 --> 00:11:56.800
Wir haben die Systemanforderungen für
Datenmigration und Tests

00:11:57.280 --> 00:12:01.055
und daher sehe ich es so, dass die
Gestaltung der Systemlandschaft etwas ist,

00:12:01.080 --> 00:12:06.200
was eine der größten Herausforderungen
in der SV Hana Conversion ist.

00:12:06.360 --> 00:12:11.280
Und wenn man sich darüber am Anfang in der
Planung seine Gedanken macht, ist das sehr

00:12:11.320 --> 00:12:15.760
hilfreich, weil man teilweise im Verlauf
dann dort sehr viel Zeit verlieren kann.

00:12:16.320 --> 00:12:18.280
Ein neues System, ein neuer Mandant.

00:12:18.960 --> 00:12:22.095
Je nach Flexibilität der IT
ist es schnell aufgebaut.

00:12:22.120 --> 00:12:26.375
Aber ganz oft sind gerade solche
Funktionen ja outgesourced und es sind

00:12:26.400 --> 00:12:30.320
administrative Abläufe erforderlich oder
Vorwarnphasen, die es

00:12:30.360 --> 00:12:32.280
etwas schwieriger machen.

00:12:32.800 --> 00:12:37.895
Deswegen, so meine Erfahrung, um dort
nicht unter Druck zu geraten, empfiehlt es

00:12:37.920 --> 00:12:42.375
sich, dass man sich das schon frühzeitig
anschaut und die Gegebenheiten

00:12:42.400 --> 00:12:45.400
berücksichtigt, unter denen man
seine Systeme aufbauen muss.

00:12:45.800 --> 00:12:46.240
Genau.

00:12:47.320 --> 00:12:51.135
Sondern aus meiner Erfahrung ist es halt
so Man muss sich Gedanken machen

00:12:51.160 --> 00:12:53.120
über Anzahl und Größe der Systeme.

00:12:53.240 --> 00:12:57.560
Welchen Vorlauf brauche ich, welche
Vorlaufzeit, um Systeme aufzubauen?

00:12:57.600 --> 00:13:01.880
Welche Vorlaufzeit brauche ich, um ein
Quellsystem aufzufrischen und

00:13:03.280 --> 00:13:05.775
wie gehe ich mit Retrofit und
Transportprozessen

00:13:05.800 --> 00:13:06.960
zwischen den Systemen um?

00:13:07.000 --> 00:13:10.895
Also retrofit Wie hole ich die Sachen, die
ich im ICC gemacht habe auch auf das S4

00:13:10.920 --> 00:13:15.320
System muss ich alles manuell abtippen
oder habe ich einen Prozess,

00:13:15.360 --> 00:13:18.040
den die SAP vorgesehen hat etc..

00:13:18.080 --> 00:13:22.480
Also das sind so die vier Bereiche,
auf die man ein Auge haben sollte.

00:13:23.280 --> 00:13:29.120
Gibt es noch einen weiteren Punkt, der
weniger offensichtlich ist, wo du sagst,

00:13:29.560 --> 00:13:31.280
das wird auch noch gern übersehen?

00:13:31.320 --> 00:13:33.720
Also zuzüglich zu dem, was
du gerade schon erwähnt hast.

00:13:34.320 --> 00:13:40.400
Genau das ist so halb technisch aus meiner
Sicht und halb anwendungsspezifisch.

00:13:40.560 --> 00:13:44.520
Gerade in der SV Hana Conversion kommt
die SAP ja oder steigt immer mehr auf.

00:13:44.560 --> 00:13:46.560
Fury als Oberfläche um und.

00:13:46.600 --> 00:13:49.080
Das kennen wir.
Ja.

00:13:49.120 --> 00:13:52.960
Das ist ja auch so ein schönes Schlagwort
und das sieht auch so schön einfach aus

00:13:53.000 --> 00:13:57.215
und man kann sich alles sehr
schön zusammenkonfigurieren.

00:13:57.240 --> 00:14:01.415
Aber ich glaube, dass da
oder auch bei uns im Projekt hat es sich

00:14:01.440 --> 00:14:04.695
gezeigt, dass das einer der
größten Stolpersteine ist.

00:14:04.720 --> 00:14:09.120
Wenn man sagt, in der SV Conversion steigt
man auch sofort komplett auf Fury um.

00:14:10.880 --> 00:14:15.055
Insbesondere wenn man
Applikationen mit viel kundeneigene

00:14:15.080 --> 00:14:20.960
Entwicklung hat, weil Fury in diesem Fall
eben auch weiterentwickelt werden muss.

00:14:21.000 --> 00:14:25.095
Also die Oberfläche müssen
weiterentwickelt werden und das läuft

00:14:25.120 --> 00:14:29.560
etwas anders als in der heutigen
App ab Entwicklung oder GUI

00:14:29.600 --> 00:14:31.160
Transaktionsentwicklung.

00:14:31.480 --> 00:14:35.800
Deswegen ist so meine Erfahrung und meine
Empfehlung in der reinen S4 Conversion

00:14:35.840 --> 00:14:40.240
sich auf die Transaktionen zu
begrenzen, die man unbedingt braucht.

00:14:40.280 --> 00:14:44.440
Weil es gibt Transaktionen, die gibt es
nur noch in Fury später und ansonsten aber

00:14:44.480 --> 00:14:47.880
idealerweise auf der alten GUI
Transaktion erstmal zu verbleiben.

00:14:47.920 --> 00:14:48.600
Was geht?

00:14:48.840 --> 00:14:55.295
Ja und ja, dann sollte man versuchen, das
auf kleinere Initiativen in

00:14:55.320 --> 00:14:56.760
die Zukunft zu verschieben.

00:14:56.960 --> 00:14:59.495
Weil man darf nicht vergessen
so eine SV Conversion.

00:14:59.520 --> 00:15:04.040
Das gesamte System muss umgestellt werden
und das hat eine gewisse Komplexität

00:15:04.680 --> 00:15:06.800
schon von sich aus, von Haus aus.

00:15:07.400 --> 00:15:11.535
Während wenn man später sagt ich optimiere
weitere Funktionen, dann ist es vielleicht

00:15:11.560 --> 00:15:14.175
nicht so schlimm, wenn dort sich einmal.

00:15:14.200 --> 00:15:17.320
Also erstens kann man die Komplexität
reduzieren, weil man einzelne

00:15:18.720 --> 00:15:23.800
einzelne kleine Aktivitäten durchführen
kann, und es ist nicht so schlimm, wenn

00:15:23.840 --> 00:15:25.480
sich dort die Zeit verzögern sollte.

00:15:25.505 --> 00:15:30.080
Bei einer SV Conversion ist aber eine
Zeitverzögerung direkt extrem teuer,

00:15:30.680 --> 00:15:32.560
weil die Mannschaft dabei ist etc.

00:15:32.960 --> 00:15:39.695
Deswegen Fokus auf das, was unbedingt
notwendig ist und nicht versuchen so

00:15:39.720 --> 00:15:41.720
viel wie möglich direkt umzusetzen.

00:15:43.240 --> 00:15:49.600
Das fand ich eigentlich
ganz nett, nämlich mit dem Bonbonladen.

00:15:50.560 --> 00:15:53.120
Ja, ich finde SAP ist halt.

00:15:53.160 --> 00:15:57.760
Kann man so ganz nachvollziehen, deswegen
würde ich da gern noch mal nachhaken.

00:15:58.240 --> 00:15:58.520
Genau.

00:15:58.560 --> 00:16:02.295
Also wenn man in die SV Hana Conversion
geht, gibt es ja viele neue Funktionen und

00:16:02.320 --> 00:16:08.695
vieles, was die SAP auch gerade
unter Fury optimiert und einfacher macht.

00:16:08.720 --> 00:16:15.375
Und Reporting, Transaktional Reporting
Kacheln, die auch wirklich einen guten

00:16:15.400 --> 00:16:18.655
Eindruck machen, so dass man davor steht,
wie ein kleines Kind im Bonbonladen und

00:16:18.680 --> 00:16:21.120
sich denkt Oh, das möchte ich haben und
das möchte ich haben

00:16:21.360 --> 00:16:22.680
und das schmeckt super.

00:16:23.000 --> 00:16:26.200
Und wie mit den Bonbons ist es, Wenn man
zu viel auf einmal genießt,

00:16:26.440 --> 00:16:28.120
hat man am Ende Bauchschmerzen?

00:16:28.360 --> 00:16:33.455
Und für mich war das
eine der wesentlichsten Erfahrungen zu

00:16:33.480 --> 00:16:37.015
sehen, dass eine SV Hana
Orientierung genau das sein kann.

00:16:37.040 --> 00:16:43.615
Das kleine Kind im Bonbonladen
Lieber wenige Bonbons sehr dosiert essen,

00:16:43.640 --> 00:16:48.200
vorher entscheiden, welche Süßigkeiten es
heute gibt und in diesem Jahr und dann

00:16:48.520 --> 00:16:53.160
später sagen Du kriegst dieses Bonbon drei
Monate später oder jenes Bonbon,

00:16:53.200 --> 00:16:54.520
dann ein halbes Jahr später.

00:16:54.560 --> 00:16:58.920
Und sich einfach in der Organisation,
in kleinen Initiativen weiterentwickeln.

00:16:59.040 --> 00:17:02.680
Wenn man jetzt am Anfang eines Projektes
steht, noch mal ganz kurz

00:17:03.360 --> 00:17:04.640
so zusammengefasst.

00:17:06.200 --> 00:17:09.320
Also generell was würdest
du den Unternehmen raten?

00:17:10.400 --> 00:17:11.760
Wie haben die Risiken aufgeführt?

00:17:11.800 --> 00:17:14.200
Stolpersteine, wenn du jetzt
am Anfang des Projekts stehen.

00:17:14.880 --> 00:17:18.360
So, und wenn du jetzt auf die drei
Themen siehst, die wir hatten, ist es.

00:17:19.640 --> 00:17:22.775
Nimm dir ausreichend Zeit für deine
Testzyklen, Plane idealerweise

00:17:22.800 --> 00:17:24.240
drei Testzyklen ein.

00:17:24.440 --> 00:17:28.800
Immer Migration und Funktion
hintereinander geschaltet, immer auch mit

00:17:28.840 --> 00:17:32.440
entsprechenden Abnahmezeiten hinten dran.

00:17:32.960 --> 00:17:37.695
Denkt frühzeitig an die Systemlandschaft,
überlegt, wie man das intelligent aufbauen

00:17:37.720 --> 00:17:42.040
kann und welche Zeit ihr vor allem auch
dafür braucht, damit es gut funktioniert.

00:17:42.400 --> 00:17:50.295
Und ähm, ja, was zu den, ähm,
zur Systemlandschaft angeht, da würden wir

00:17:50.320 --> 00:17:52.570
dann noch mal auf die Checkliste
im Hintergrund verweisen.

00:17:52.600 --> 00:17:54.600
Ja, erkläre ich gleich was genau.

00:17:55.000 --> 00:17:58.840
Damit ihr da vielleicht auch noch ein
paar Fragen zu dem ganzen Text habt.

00:17:58.880 --> 00:17:59.280
Welche?

00:17:59.320 --> 00:18:01.935
Welche Fragen man sich stellen sollte,
wenn man über die

00:18:01.960 --> 00:18:03.120
Systemlandschaft nachdenkt.

00:18:03.160 --> 00:18:04.420
Ich freue mich, dass
du es übernommen hast.

00:18:04.445 --> 00:18:08.775
Die Zusammenfassung der Hacks,
das schreiben wir auch noch mal in

00:18:08.800 --> 00:18:10.880
die Show, in die Shownotes rein.

00:18:11.200 --> 00:18:15.960
Das waren jetzt zwei und wir haben einen
ganz besonderen dritten Hack heute.

00:18:16.000 --> 00:18:18.575
Das hast du gerade kurz
erwähnt, dass die sind.

00:18:18.600 --> 00:18:20.480
Das ist in den Shownotes aufgeführt.
Nämlich?

00:18:20.520 --> 00:18:25.775
Du hast uns eine Checkliste mitgebracht,
die man für den Systemaufbau bereits in

00:18:25.800 --> 00:18:28.440
der Planungsphase nutzen kann, wenn man
sich für eine selektive

00:18:28.480 --> 00:18:30.680
Data Transition entscheidet.

00:18:30.880 --> 00:18:33.880
Egal ob Mixer, Match oder Shell.
Das ist das Schöne.

00:18:33.920 --> 00:18:38.855
Man kann es für beide verwenden und man
kann Copy Paste und man kann in der

00:18:38.880 --> 00:18:42.400
Planungsphase dann die Checkliste
durchgehen, was natürlich grandios ist.

00:18:43.640 --> 00:18:49.040
Ich habe viel gelernt und freue mich
ganz herzlich, dass Du da warst.

00:18:49.080 --> 00:18:52.775
Vielen Dank für die Insights und auch für
die ehrlichen Worte aus deinem Projekt.

00:18:52.800 --> 00:18:54.960
Das war wirklich spannend.
Danke schön.

00:18:55.000 --> 00:18:55.960
Es hat Spaß gemacht.

00:18:56.520 --> 00:18:59.415
Und Euch, liebe Zuhörerinnen und
Zuhörer, danke fürs Dabeisein.

00:18:59.440 --> 00:19:01.200
Bis zum nächsten Mal, eure Anita.

00:19:01.720 --> 00:19:02.240
Bis dann.

00:19:08.200 --> 00:19:08.880
Ich schicke.