Carve-Out: SAP-Daten sauber aus der Landschaft herauslösen

Halb 4. Ich würd sagen, wir beginnen pünktlich. Genau. An alle schon teilnehmenden, herzlich willkommen zur heutigen, ja, zum heutigen Webinar zum Thema SAP Carfouts. Geschäftsteilhalten sauber aus der SAP Landschaft trennen. Das ist Teil 2 aus unserer Webinarserie. Letzten Montag gab's ja schon einen kleinen Webinar zum HCM Carfout, heute noch mal etwas allgemeiner. Genau, was Sie heute vorgenommen haben, ist einmal, was ein Carport technisch und organisatorisch wirklich bedeutet. Da werd ich einmal so über die Grundbegriffe, ja, sag ich mal, eingehen, einmal erklären, was überhaupt ein Carport für uns bedeutet. Dann werd ich auf die, sag ich mal, typischen Projektstolpersteine sprechen, was so, sag ich mal, aus unserer Projekterfahrung immer wieder mal so kleine, sag ich mal, Hürden waren, die die bezogen werden mussten. Und dann schlussendlich würd ich einmal drauf eingehen, wie wir, sag ich mal, von EPI's vor allem mit unserem kleinen Sync sonen KFOR uns, sag mal, bewältigen. Vielleicht bevor ich beginne, noch mal ein, 2 Worte zu mir selbst. Mein Name ist Patrick Neuwald. Ich werde das heutige Webinar und das Webinar am Mittwoch zum Thema KF in, sag ich mal, betreuen. Genau, ich bin seit 2021 Teil von EPI, seit 2023 Teil der Carfault Factory, weswegen ich dann heute hier sitze und das Ganze präsentieren darf. Genau. Sollten Fragen aufkommen, dann gerne einfach den Chat. Ich werde am Ende der Präsentation noch mal drauf eingehen. Sollten wir nicht alle Fragen abdecken können, dann werde ich dann noch mal nach der Präsentation mal einzeln auf die Fragen eingehen. Genau. So. Beginnen wir direkt. Was ist ein k-Wort und was wird geschnitten? Also von unserer Ansicht nach ist, sag ich mal, ein KFORT immer die Trennung 1 Unternehmensteils aus 1 SAP Landschaft. Dabei wird entlang der Organisationsstruktur geschnitten. Unter diesen Organisationseinheiten verstehen wir in erster Linie den Buchungskreis und alle darauf, sag ich mal, zuordenbaren Orgeinheiten. Also zum Beispiel der Werk im klassischen Fall, Verkaufsorganisationseinheiten, Personalbereiche darf man dann nicht vergessen und immer ganz sensibel sind Rechnungskreis und Ledger. Und der Kosten Rechnungskreis im CO ist immer ganz sensibles Thema. Was geschnitten wird, sind natürlich Daten, Stammdaten oder Wirkungsdaten. Bei den Stammdaten beziehen beziehen wir uns dann meistens auf Materialien, Kunden, Lieferanten. Die Bewegungsdaten werden dann zum Beispiel auch anhand ihrer Historie geschnitten, sollte das ein Thema sein. Und an sich, wenn wir schon beim Thema Bewegungsdaten sind, werden natürlich auch alle Belege geschnitten über alle Module hinweg. Was auch wichtig ist, ist die Konfiguration, die geschnitten wird. Also beispielsweise kundeneigener Setup bein, kundeneigener Content. Da gibt's natürlich auch, sag ich mal, Daten, die mitgenommen werden müssen, auch wenn sie nicht zum Standard gehören und natürlich auch Berechtigungen wollen. Also die Kunden werden dann natürlich User haben, die dann mit dem neuen Zielsystem arbeiten wollen. Und da muss natürlich auch da dazu gesichert werden, dass die dass die User dann das System so nutzen können, wie sie's auch im Quellsystem gemacht haben. Genau. Was ein typisches Szenario fürn Kauf out? Ich hab jetzt hier mal, sag ich mal, 3 Fälle aufgelistet, die so für uns ganz in den letzten Jahren immer ganz wichtig waren. Geopolitik und Regulatorik, das hat jetzt innerhalb der letzten 5 Jahre vor allem an, sag ich mal, Relevanz gewonnen. Beispielsweise jetzt in Bezug auf den auf den Russlandkrieg, da haben wir jetzt zum Beispiel Sanktionen, die dafür sorgen könnten, dass man son KFOR durchführt. Wenn man jetzt zum Beispiel Geschäftsfelder hat, die jetzt in Russland tätig waren, in denen KFOR theoretisch so ein Beispiel, wie man diese russischen Daten ausschneiden kann und abgelagert weiterlaufen lassen kann, sodass die die russischen Anbieter dann ein eigenes System haben ohne Fremddaten. Was Regulatoren betrifft, da haben wir zum Beispiel mit der Cyber Sucurity Lore aus China sozusagen ein, ja, regulatorische Ansicht. Zum Beispiel Daten, je nachdem, ob ja, die die die Behörde die Daten sehen möchte, dass wir dann ein quasi einmal Auskunft geben, welche Daten überhaupt gespeichert werden in Bezug auf China. Bei diesen 2 Punkten ist natürlich extremer Zeitdruck immer gefordert. Jetzt beispielsweise mit dem Russlandkrieg wusste man von vornherein, dass jetzt zum Beispiel Russland Ukraine angreift. Und deshalb müssen die Daten dann, sobald diese Aktionen eintreffen, relativ schnell auch getrennt werden. Und so ist son KFOR Projekt bei solchen 2 Fällen immer mit' ziemlich hohen Zeitdruck versehen. Anderes Beispiel, was immer auch allgemein häufig vortritt, sind zum Beispiel Unternehmenstrennungen oder auch sogenannte Investments. Also wenn zum Beispiel Geschäftseinheiten verkauft werden, dann erhält der der Käufer ein eigenes Zielsystem und die Historie ist dabei ein Bestandteil. Das Quellsystem läuft dann produktiv weiter. In erster Linie auch mit den schon ausgeschnittenen Daten. Im im Zeitinstanz wird sich dann Gedanken gemacht, was denn überhaupt mit diesen ausgeschnittenen Daten passiert. Genau. Bei dem muss man immer 2 Seiten bedenken. Wir haben einmal quasi natürlich das Zielsystem, wo landen die Daten? Aber auch das Quellsystem, das da darf nicht vergessen werden. Also woher stammen die Daten? Bei dem Zielsystem ist immer wichtig zu wissen, dass nur ein selektiver Transfer von den betroffenen Org Einheiten entsteht. Also wir wir möchten möglichst nur das kopieren, was auf den, sag ich mal, ausgeschnittenen Org Einheiten zurückzuführen ist. Dabei ist auch wichtig, dass wohin wir die Daten kopieren, das Zielsystem zum Beispiel auf' selben Releasestand ist wie auf dem Quellsystem. Also beide Systeme müssen auf' vergleichbaren Stand sein. Genau. Beim Aufbau muss auch wichtig sein zum Beispiel, dass wir das Ganze wiederholbar und protokollierbar machen. Also wenn wir den Datentransfer machen, bis wir auch im Nachhinein wissen, zum Beispiel in' Fall 1 Prüfung, wie die Daten entstanden sind. Woher stammen die Daten? Welche Tabellen haben wir kopiert oder wie haben wir sie geschnitten? Bei Quellsystemen, ich hab's eben schon leicht angerissen, sobald die Daten übergeben wurden, haben wir immer noch, sag ich mal, diese Altdaten aus den ausgeschnittenen Buchungskreisen. Da muss man sich zum Beispiel auch Gedanken machen, was passiert mit diesen Daten? Wir hätten dann zum Beispiel mit Arcai Central die Möglichkeit, diese historischen Daten aus den ausgestellten Buchungskreisen noch mal zwischenzulagern und sozusagen, ja, das Quellsystem dadurch zu zu verschlanken. Genau. So, und dann kommen wir zum, sag ich mal, interessanten Punkt, wo KFOR Projekte anecken. Ich hab jetzt hier, sag ich mal, 3 3 so gängige, sag ich mal, Stolpersteine aufgelistet. Historische Daten, Org Überschneidungen. Für mich das wichtigste Thema, Timeline und Testen. Ganz kurz zu den historischen Daten. Wie wird muss man zurück in die Historie? Das kommt immer ganz drauf an, wie geschnitten werden muss. Also es kann auch sein, dass nicht nur anhand der Org Struktur geschnitten werden muss, sondern dass man auch einen zeitlichen Schnitt machen muss. Angenommen nur, weil die 10 letzten Jahre relevant sind. Wenn das Unternehmen aber deutlich älter ist als diese 10 Jahre, dann nehmen wir nur einen gewissen zeitlichen Schnitt mit aus dem Quellsystem. Und daher muss son Stichtag direkt zu Beginn des Projektes einmal festgelegt werden und durch dieses Projekt auch konsequent durchgeführt werden. Man muss auch verstehen, dass man keinen harten Cut anwenden sollte. Also kann es nämlich zum Beispiel sein, dass wir in' Belegfluss dann einzelne Belege haben, die außerhalb unseres Zeitschnittes haben. Hätten wir dann harten Zeitschnitt, dann hätten wir im Umkehrschluss auch in Konsequenzen, wenn wir einzelne Belege auslassen aus der Prozesskette beispielsweise. Und auch offene Posten müssen natürlich mitgenommen werden. Wir wollen natürlich, wenn wir das Zielsystem dann neu neu aufbauen, in demselben Stand haben, wie es im Quellsystem war. Also Umkehrschluss, wenn wir dann quasi im Go Life sind, muss mit den offenen Posten weitergearbeitet werden. Das das das Zielsystem arbeitet nach dem Go Life produktiv weiter und es muss quasi in derselben Situation sich befinden wie das Quersystem auch. Was auch sehr häufig vorkommt, sind zum Beispiel Überschneidungen. Ich hab's jetzt hier zum Beispiel als ersten Punkt direkt aufgefasst, wenn wir Material in mehreren Werken haben. Da ist dann meistens auch unklar, was machen wir mit diesen Materialien? Sollen wir sie voll kopieren? Sollen wir sie ausschneiden? Was ist beispielsweise mit Kreditoren in mehreren Buchungskreisen? Das sind auch zum Beispiel sensible Informationen. Nicht immer soll das mitkopiert werden. Ein anderes Beispiel wäre, wenn wir zum Beispiel der Buchhaltungsbeleg haben und für einen Buchhaltungsbeleg ist der Buchungskreis das Buchungskreisfeld nicht gefüllt. Also wir haben keine feste Ortzugehörigkeit zu einem bestimmten Beleg. Da ist dann immer wichtig zu entscheiden, was man damit macht. Wie hier unten stehen haben, jeder Außenminister braucht eine Regel. Sogenannt Blueprint kann man dann festhalten, wie man diese Datenkopie ausführt. Dieser Blueprint ist sozusagen das Gerüst, wie man kopiert, was man kopiert und welche Regel für welches Objekt oder Tabelle besteht. Und das sollte dann quasi einmal von, sag ich mal, Projektführer quasi festgeschrieben werden und dann im Endeffekt auch von Kundenseite auch aus abgenommen werden. Und dann während des Projektes auch, sag ich mal, als Grundstein für die Kopie verwendet werden. Kommen wir zum letzten Punkt bei dem, sag ich mal, Stolperstein. Das wären Timeline und Testen. Für mich, das wär Ihnen ganz wichtig, weil das Testen für für für den Go Life eigentlich so mit das Entscheidende ist. Je besser man testet, desto reibungsloser läuft ein Go Life, weil dann eigentlich keine Unklarheiten mehr aufkommen könnten. Dazu ist wichtig, dass man die Fachbereiche während der Projektlaufzeit einbindet. In der Regel sprechen wir von 2 bis 3 Testphasen, wo die Fachbereiche dann die übergebenen Daten einmal testen, sag ich mal, ihr Daily Business simulieren und dann quasi die übergebenen Daten auch einfach auf prüfen. Dazu reichen dann nicht nur S-sechzehn-Test, es müssen es müssten im besten Fall Transaktionen ausgeführt werden, Testdaten angelegt werden, sodass man auch wirklich weiß, dass das Zielsystem den produktiven Status auch überstehen könnte. Fachbereiche verifizieren dann je Modul. Also wenn wir dann zum Beispiel Leute ausm Millimeter, Leute ausm FI haben, dann müssen typische Transaktionen aus Ihrem Daily Business getestet werden. Wichtig ist dann auch, dass wir dann produktivnahe Daten haben während diesen Testphasen. Also in den meisten Fällen haben wir ein Staging System, von wo wir die Daten dann auskopieren. Das hat den großen Vorteil, dass da dass das Staging System steht und wir in den Testphasen ein stehendes Vergleichssystem haben, von wo dann auch getestet werden kann. Wir können dann die Hektabellen vergleichen, passen SC 16 Abrufe zwischen zwischen den einzelnen Tabellen, zwischen Quellen und Ziele. Und man kann halt auch, sag ich mal, in Ruhe die Tests ausführen. Hätten wir ein Produktivsystem als Vergleichssystem, dann wird das System weiterhin laufen und wir hätten zum Beispiel bei' SE 16 Vergleich durchaus Abweichungen. Genau. So, 2 Datenklassen, die auch gern vergessen werden, die hab ich jetzt extra noch mal, sag ich mal, aufgelistet, weil das auch immer ein spannendes Thema ist. Da haben wir zum Beispiel einmal Archivdokumente im Beispiel von Archiv Link Verknüpfungen. Die sind ja dann in den TOA Tabellen, sag ich mal, gelistet, aber ohne, sag ich mal, feste Orgzugehörigkeit. Erst wenn man die man erst wenn man die Links auflistet und je nach Objekt prüft, woher dieser Link denn überhaupt stand, kann man dann ermitteln, zu welcher Org Einheit meine Verknüpfungen gehören. Und sollte es dann zum Beispiel nach' der Fall sein, dass man sich den Content Repository für eine gewisse Zeit aus teilt, möchte man natürlich nicht, dass man Verknüpfungen zu, sag ich mal, Dokumenten hat, die nicht zu meinem, zu meiner Org Einheit gehören. Deswegen sollte man auch hier prüfen, wie man das Ganze konsequent schneiden kann, damit man dann quasi Konto Repositories und andere Schnittstellen dann auch für das Zielsystem bereitstellen kann, ohne Fremddaten einsehen können. Auch das Thema HCM Personaldaten, ich denk, das wurde auch schon der letzten im letzten Webinar auch angerissen. Da ist dann auch zu klären, ist das HCM überhaupt im Zielsystem notwendig? Da muss dann halt mit Kundenseite gesprochen werden. Haben die vielleicht ein anderes HCM System im Einsatz oder ein anderes Tool dafür? Dann muss auch natürlich überprüft werden, dass der Betriebsübergang der Mitarbeiter artgerecht im Zielsystem im Quellsystem hinterlegt wird, sodass wir da auch auf der sicheren Seite sind. Genau. So, kommen wir zu den TSA Fristen. Das sind's eigentlich so die drückenden Fristen, wenn wir so ein Kauf out durchführen. Da ist dann halt immer die Timeline, sag ich mal, der Faktor, in welcher Geschwindigkeit wir so ein durchführen müssen. Diese TSA Fristen, ich hab's auch hier noch mal hingeschrieben, das sind Transition Service Agreement. Die regeln eigentlich nur die Übergangszeit, bis wann die Daten an Kundenseite übergeben werden müssen. Und zu diesem Stichtag gilt dann eine strikte Datentrennung. Also ab Tag x muss die Kundenseite die Daten zur Verfügung haben. Und solche Verlängerungen sind meistens sehr teuer und werden selten bis gar nicht akzeptiert. Also es muss wirklich strikt im Projekt vorgehalten werden, dass man zum gewissen Stichtag die Daten übergeben kann. Der Schnitt muss natürlich dann vorher erprobt und abgenommen werden. Das, ne, hab ich schon in im Punkt Testen und Timeline angesprochen. Die Tests sind wirklich essenziell, dann halt einen sauberen Schritt zu garantieren und dann am Ende dieser TSA Frist genau die sauberen Daten zu garantieren. Genau. Wie gehen wir mit EPI's so einen selektiven Transfer mit Klein Sync vor? Also im Grunde genommen steht uns bei' Kaufort die volle DSM zu. Wir haben dann nicht nur, sag ich mal, Zugriff auf der Client Sync oder der Object Sync System Builder App im Beispiel Fall oder auch ja, der Data Secure zum Verfremden von Daten wird uns zur Verfügung stehen. Im Grunde genommen führt der Klein Sync aber die Hauptaktivitäten durch. Mit ihm führen wir diese bekannten Kopie geschnitten anhand von Buchungskreisen aus. Genau, und wir haben dann quasi von Kundenseite aus Buchungskreise, welche geschnitten werden muss. Das ist dann quasi die die Selektion, mit welcher wir die Org Einheiten schneiden. Wir schneiden dann quasi anhand von Objekten und keine Tabellen selbst, also können wir auch das Datenmodell dann konsequent schneiden. Es ist ein vorkonfiguriertes Datenmodell. Das heißt, wir haben schon ein fertiges Tool, was zu 80 bis 90 Prozent Daten schon sauber schneidet. Natürlich gibt es dann immer noch Feinheiten, jetzt zum Beispiel Setobjekte, die erst mal aufgenommen werden müssen in unsere Engine, dann quasi auch auf dieser Ebene sauber zu schneiden. Und natürlich ist jeder Lauf wiederholbar. Wir haben eigentlich, bevor wir in die 1. Testphase gehen, eben einen Testlauf 1 Kleinstinks, überhaupt zu ermöglichen, wie denn die Laufzeit ist. Im Grunde genommen haben wir auch die Systemanalyse, die uns schon quasi vorab Informationen gibt, wie das System aufgebaut ist, ob es irgendwelche komplexen Objekte gibt oder sonstige Stolpersteine, die im Vorfeld noch mal behandelt werden müssen. Genau. Die Performance für Kleinstick ist, sag ich mal, paralysierbar, einplanbar. Wir nutzen dann die Bachelorprozesse, die im Quellsystem zur Verfügung stehen. Und wir haben da quasi damit die Möglichkeit, das Quellsystem, sag ich mal, so zu belasten, dass man weiterhin quasi alle eingeplante Jobs ausführen kann. Die Laufzeiten werden gemessen. Also wir haben auch mit dem kleinsten sozusagen ein Chatslauf, der man quasi 30 Prozent der Daten kalkuliert und damit dann imaget, wie lang ungefähr ein Daten benötigt. In dieser Systemanalyse, die ich vorhin schon erwähnt habe, können wir auch diese großen Tabellen identifizieren und diese dann gezielt mit Client Sync noch mal anders, beispielsweise durch solche solche Tabellen Splits effizienter zu zu extrahieren. Die die Downtime selbst ist ein Thema, was immer für ziemlich viele Kunden, sag ich mal, ein abschreckendes Thema ist. Man möchte ja so möglich möglichst wenig Downtimes haben während 1 Projektes. Wenn man dann sogenannte Staging Systeme verwendet, dann kann man Go Life nur zu' nur Downtimes nur zum Go Life verwenden. Und auch ansonsten durch diese ganzen Testphasen, die wir haben, können wir auch ermitteln, wie lang denn so eine Kleinstöckextraktion inklusive Import dann benötigt. Und so können wir dann das Time Downtime Fenster möglichst genau kalkulieren und auch kurz halt durch die Performanceverbesserung, die wir ja vornehmen können. Was unseren Ansatz von von anderen Konkurrenten entscheidet, wie ich schon gesagt habe, der Kleinste ist ein schon fertiges Tool, was 80 bis 90 Prozent der Daten sauber schneidet. Es gibt wenig, sag ich mal, Anpassungen, die die von vorn im vorne rein getätigt werden müssen. Wir bringen sozusagen schon ein fertiges Tool mit. Es muss nicht erst zu bringen, ja, entwickelt werden. Das Start-up Modell wird exakt exakt abgebildet. Wir haben durch, sag ich mal, unsere vierjährige Erfahrung im SAP Umfeld Datenmodelle auf sämtlichen SAP Modulen dargestellt. Wir sind auch auf verschiedene Sub Releases, sag ich mal, einsatzfähig. Also ab ECC 6 oder oder S4, unsere Tool Tools können einfach eingespielt werden. Des Weiteren können wir auch kundeneigene Tabellen in die Kopie mit einfügen, selektiv natürlich. Also in der Systemanalyse selbst sehen wir einmal große Anzahl an kundeneigenen Tabellen, die wir im Quellsystem vorfinden. Und die können wir dann, sag ich mal, ad hoc in dieses in dieses System in die Mandantenkopie mit einfügen. Der Kunde kann uns da quasi einfach die Information geben, sind die kundeneigenen Tabellen gewünscht, sie nicht erforderlich oder gibt es zum Beispiel auch, an denen wir sie schneiden können? Dann können wir das in unserer Engineering hinterlegen und dann auch folgerecht schneiden. Genau, das Ganze ist auch beliebig reproduzierbar. Also wir haben in der Regel ein bis 2 bis 3 Testphasen und so lange können wir den Client Sync dann auch verwenden und immer wieder Vorkehrungen nehmen, noch genauer zu schneiden. Das Ganze ist dann auch zum Beispiel nach dem Go Life weiterhin nutzbar. Also sollten wir in die Situation kommen, dass zum Beispiel der Kunde noch Q- und DEV System aufbauen möchten, dann können wir den Client Sync dazu verwenden und noch mal kleinere Testsysteme erstellen, beispielsweise durch kleine Zeitscheiben, dann dadurch zum Beispiel konsequent konsistente Q- und DEV Systeme zu erstellen. Und wie ich schon in der letzten Folie erwähnt hatte, Datenschutz ist mit eingebaut. Also sollte es zum Beispiel Anwendungsfälle geben, wo wir zum Beispiel Daten schneiden müssten, dann könnten wir das auch direkt in der Kopie mit einfügen. Das ist dann auch auf alle Module erprobt. Wir haben dann auch zum Beispiel Revisionswerke, wo man dann auch noch mal nachvollziehen kann, wie die Daten verfremdet wurden, dass zum Beispiel bei' Auditor geprüft werden kann, wie die Daten verfremdet wurden. Auch beim Client Sync selbst sieht man dann zum Beispiel, wie die Daten kopiert wurden. Also wir haben dann zum Beispiel zu jedem Lauf im Monitor Desk eine Übersicht, wie die Tabellen kopiert wurden. Wurden sie geschnitten? Wurden sie über ein Objekt kopiert? Der Blueprint selbst gibt dann auch zum Beispiel Auskunft, was so zum Beispiel Felder sind, an welchen wir ein Objekt schneiden, ne? Und das ist eigentlich sozusagen der Indiz dafür, wie wir das Quellsystem aufgebaut haben. Kommen wir zum Thema Laufzeit und Kosten. Das ist auch immer so mit 1 der tragenden Punkte, ob man sich für ein KFORD Projekt entscheidet. Im Grunde im Grunde genommen haben wir, sag ich mal, immer 4 Schritte, was sone Projektlaufzeit, ja, festsetzt. Also wir haben zum Beispiel Analyse und Design. Das sind immer sozusagen die initialen Schritte 1 Carport Projektes. Das dauert's immer so in der Regel circa 4 Wochen. Da haben wir zum Beispiel einmal die Erstellung des Blueprintes. Da gehen wir dem Kunden einmal aus, kommt welche Objekte wir gefunden haben. Wie könnten wir unsere Objekte schneiden? Gibt es von Kundenseite aus zum Beispiel andere Felder, an welchen geschnitten werden soll? Es ist dann meistens auch immer CO der Fall, dass man zum Beispiel hier noch mal, sag ich mal, Änderungen vornimmt. Und sobald dann quasi Analyse und Design abgeschlossen wurde, dann beginnen wir direkt mit Testphasen. Je nachdem, wie viele Testphasen eingeplant sind, also maximal reden wir hier von 3 Testphasen, dauert das ungefähr in der Projektlaufzeit 8 Wochen. Und sobald Testphasen abgeschlossen wurden, sobald es da auch von Kundenseite eine Abnahme gibt, das dauert wie gesagt schon 8 Wochen, kommen wir auch direkt zu Go Life und dann zur abschließenden Systemabnahme, womit wir insgesamt 2 Wochen einplanen. Nach dem Go Live befinden wir uns dann immer in' Hypercare Phase, wo wir den Kunden zur Verfügung stehen. Da sind die Testphasen davor natürlich auch ziemlich entscheidend. Also je besser getestet wurde, desto weniger Überraschungen gibt es auch in Go Live, weil man dann einfach die Datenqualität aufs Maximale überprüft hat und im Go Life da quasi ja mit' großen Sicherheit da quasi rangeht. Alle Ausnahmen wurden erfasst. Die Kopie läuft dann im besten Fall auch einfach sorgfältig und man kann dann in der Highbackphase direkt das tägliche Business beginnen mit dem neu aufgebauten Zielsystem. Natürlich, wenn es eine, sag ich mal, harte TSA Frist gibt, kann diese kann können diese Projektlaufzeiten variieren. Also haben wir zum Beispiel ein kurzfristiges Projekt, dann können wir natürlich Zeit einsparen und zum Beispiel auch in der in der Analyse Designphase ja, sag ich mal, spurten, damit wir dann auch, sag ich mal, diese TSA Fristen einhalten können. Ansonsten sind wir da sehr flexibel. Zum Thema Kostenhebel. Dadurch, dass wir granular kopieren und das SAP Datenmodell schon quasi kennen, sind wir ziemlich schnell in der Lage, die ersten Kopie auszuführen. Wir haben auch keine Datenleichen, also es werden Daten direkt anhand von selektieren kopiert und möglichst wenig Tabellen werden vollkopiert. Also die meisten Tabellen, die wir so kopieren, die werden anhand von Objekten kopiert und so kopieren wir nur wirklich die Daten, die wirklich benötigt werden. Ich hab jetzt auch zum Beispiel hier in dem letzten Bullet Point ein Beispiel genommen aus' KFOR Projekt. Da hatten wir das Quellsystem mit ungefähr 12 Terabyte Systemgröße. Und nachdem wir den KFORD final durchgeführt haben und 4, sag ich mal, Buchungskreise ausgeführt mitkopiert haben, war das Zielsystem für Teil bei großen Kunden dann so an den Kunden übergeben werden. Und das sind so zum Beispiel, ja, Kostenfaktoren, die wir uns dann quasi so, ja, besonders machen. Ein Praxisbeispiel, was ich so noch aus' vergangenen Projekt kenne, das war jetzt zum Beispiel auch aufgrund des Russlandkrieges. Da gab's dann den kurzfristigen Marktaustritt unter Zeitdruck. Wir mussten dann quasi auf eine harte Frist diesen Kaufout ausführen, da was die so erfordert hat. Wir haben dann entlang der Buchungskreise alle, sag ich mal, Org Einheiten kopiert, die auf die auf das russische Business zurückzuführen waren. Insgesamt haben wir 3 Testphasen eingeplant mit den Fachbereichen. Und die Besonderheit die Besonderheit hier war die Inter Company Beziehung, die dann noch mal dokumentiert und aufgeschlüsselt werden musste, damit dann quasi im Zielsystem nur noch die Daten da waren, die ja genau für das russische Business notwendig waren. Es sollten also keine Fremddaten übergeben werden. Und so konnten wir dann quasi, ja, folgerichtig den russischen Carve out ausführen. Genau. So, kommen wir zur Zusammenfassung in den nächsten Schritten. Ich bin jetzt etwas über die 20 Minuten, die ich eingeplant hatte. Was sie jetzt gerne mitnehmen können, wären dann einmal für die Entscheider das das Thema Terminrisiko. Es ist kein, sag ich mal, reines IT Projekt. Es gibt immer, sag ich mal, feste Fristen, die beachtet werden müssen. Die TSA Frist ist dann meistens so ein so ein Beschleuniger von sonem Projekt. Also da das ist dann meistens der Faktor, der entscheidet, wie schnell so ein KFOR Projekt durchgeführt werden muss. Genau und ins mit' selektiven Schnitt sieht man dann einfach, sag ich mal, Systemvolumen oder Datenvolumen und damit dann auch einfach die Kosten. Für die Techniker unter uns, wir schneiden anhand von Org Einheiten, also wir nehmen keine Tabellen einzeln vor und kuppi gucken uns dann an, ob wir dort Org Einheiten finden oder nicht. Wir haben, sag ich mal, großes Know how Know how, was wir in unseren, sag ich mal, Objekten gespeichert haben. Das liefern wir direkt zu zum zu Beginn des Projektes mit. Und so können wir dann, sag ich mal, unsere Objekte anwenden, dann, sag ich mal, die Systeme sorgfältig zu schneiden. Zu bedenken sind dann natürlich auch die die Archivdaten, HCM Daten, das muss dann immer beachtet werden. Und man muss auch beide Seiten bedenken. Also nicht nur das Zielsystem ist wichtig, auch die Quelldaten sind immer, ja, ganz wichtig. So. 5 Minuten noch haben wir noch übrig, deswegen noch mal ganz kurz. Die Folien erhalten Sie dann im Nachgang des des Webinars. Sollten Sie Interesse haben, gibt's natürlich die Möglichkeit, unverbindliches Scoping Gespräch zu zu halten. Da können wir noch mal genau über den Use Case sprechen. Wenn Sie jetzt zum Beispiel ein konkretes Thema haben, dann könnten wir auch genau mit der Systemanalyse prüfen, was wir für was für Besonderheiten wir finden. Und ansonsten sehen wir uns dann im Webinar 3 am Mittwoch, wo es das Thema Carf in geht. Genau. Ich seh, da wurden auch schon einige Fragen im Chat gepostet. Ich werd natürlich nicht alle Fragen beantworten können, auch für eine Kürze der verbleibenden Zeit. Alle Fragen, die ich jetzt nicht beantwortet habe, die werd ich dann im Nachgang noch mal beantworten. Und das Recording werd Ihnen dann auch zur Verfügung stehen. Genau. So, kleinen Moment. So, die 1. Frage wäre, warum nicht einfach eine System kopieren und danach löschen, was nicht dazugehört? Das ist eine sehr interessante Frage, kommt durchaus häufig, sag ich mal, von Kundenseite. Da gibt es, sag ich mal, 3 Faktoren, weswegen wir das nicht empfehlen. Gruppe Nummer 1 hier zum Beispiel, dass wir einmal das das Löschen von Produktivdaten immer sehr, sag ich mal, riskant finden. Also das das Kopieren ist unserer Ansicht nach immer leichter als das Löschen. Durch die Kopie können wir dann immer Daten nachschieben. Das ist dann auch im Go Life immer sehr, sehr, sehr wichtig. So können wir zum Beispiel auch das Datenmodell immer richtig nachvollziehen. Und durch das, sag ich mal, ungenaue Löschen könnte es auch dazu dazu kommen, dass wir Datenleichen haben. Also Daten, die jetzt nirgendwo zugeordnet werden können und dadurch nicht gelöscht werden. Grund Nummer 2 wäre dann noch, sag ich mal, wenn wir das komplette System kopieren und bereitstellen, das ist auch nicht, sag ich mal, datenschutzkonform. Im Grunde genommen soll nur das mitgenommen werden, was von Käuferseite aus notwendig ist. Also nur der Buchungskreis zum Beispiel oder die Buchungskreise, die von Käuferseite aus auch erworben wurden. Und des Weiteren aus Infrastruktursicht wird man das ganze System kopieren. Also ich hab's in an einem Fallbeispiel schon gezeigt, Server 3 Arbeit, das muss man auch erst mal, sag ich mal, irgendwo auch speichern können, hosten können. Das ist dann auch immer, sag ich mal, ein negativer Aspekt. Wir können die HCM schon selektiv kopieren und eine kleine Datenmenge bereitstellen. Genau. Ich hoff, das beantwortet die Frage. Ich würd direkt zur nächsten springen aufgrund der Zeit. Wie gehen Sie mit unseren Eigenentwicklungen mit Z-Tabellen Genau. Also wie schon erwähnt, Z-Tabellen, die ermitteln wir quasi schon durch unsere Systemanalyse. Die können wir auch, sag ich mal, ziemlich simpel in unsere Engine mit dazufügen. Schon zur ersten, sag ich mal, Testphase können wir die einschließen. Und an sich sind wir, sag ich mal, mit unserer Engine sehr, sehr flexibel. Also auch was Add ons zum Beispiel, also Non SAP, Non SAP Tabellen beispielsweise, die können wir auch in unsere, sag ich mal, mit einstiegen und die Kopie ausführen. Also Kleinsting ist da sehr flexibel und wir können uns da quasi direkt zu Projektbeginn ziemlich, ja, gut gut auseinandersetzen und, sag ich mal, den Scope gut definieren. Was brauchen Sie von uns, eine Aufwandschätzung abzugeben? Im Grunde genommen ist es ist die Systemanalyse immer so ein, sag ich mal, ein wichtiger Faktor, überhaupt zu ermitteln, wie komplex das System aufgebaut ist. Wir brauchen natürlich auch Informationen zum Beispiel zu den TSA Fristen. Also was ist zum Beispiel die Timeline? Was ist was ist der Need des Kunden? Was sind Besonderheiten, die beachtet werden müssen? Gibt es zum Beispiel Daten, die verfremdet werden sollen? All das sind Informationen, die wir quasi gemeinsam zu Projektbeginn besprechen müssen, dass wir dann einfach quasi unsere Aufwände schätzen können. Und wir brauchen dann natürlich auch von Kundenseite aus ein gutes Testteam, damit wir auch, sag ich mal, erfolgreich testen können und so ein Kaufprojekt erfolgreich durchführen können. All das muss dann quasi mit Kundenseite besprochen werden. Das kann natürlich auch zuerst in dem Fall folgen, wo wir den kleinen Segment mal zeigen, diese Lektion darzustellen. Und ansonsten sind das die Informationen, die wir brauchen, eine Aufwaschschätzung abzugeben. Genau. Gut. Wir haben noch 10 Sekunden übrig, ich würd sagen, an der Stelle. Weitere Fragen, die ich jetzt noch im Chat sehe, werde ich dann im Nachgang beantworten. Ansonsten danke ich vielmals für die Aufmerksamkeit. Ich hoffe, das war informativ, auch wenn ich jetzt, sag ich mal, die letzten 10 Minuten bisher gesprintet bin. Falls Sie Fragen haben sollten, genau, steh ich Ihnen gerne zur Verfügung. Ich hab auch hier noch mal, sag ich mal, verschiedene Wege aufgelistet, mit denen Sie uns erreichen können. Genau. Lassen Sie uns wissen, ob Sie ein Termin benötigen. Da können wir gern noch mal sprechen. Und ansonsten sehen wir uns am Mittwoch. Vielen Dank.