Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 10 Episoden

S/4Hana Selective Data Transition: Der flexible Weg – mit versteckten Fallstricken

01.07.2025 19 min

Zusammenfassung & Show Notes

In dieser Folge von Smart Hacks für IT-Projektmanager spricht Anita-Dora Andreadis mit der SAP-Expertin Alexandra Lügger über den komplexen Umstieg von SAP ECC auf S/4HANA mittels Selective Data Transition (SDT). Dabei werden die Unterschiede zwischen Shell Conversion und Mix-and-Match-Ansätzen erläutert. Alexandra teilt ihre praktischen Erfahrungen, beleuchtet typische Herausforderungen – insbesondere bei Systemlandschaft, Datenmigration und Testplanung – und gibt konkrete Handlungsempfehlungen für eine erfolgreiche Projektumsetzung. Besonders hilfreich: eine mitgebrachte Checkliste zur Systemplanung sowie klare Tipps zur Vermeidung häufiger Fehler.

📢 Episode: Selective Data Transition – So gelingt der smarte Umstieg auf SAP S/4HANA

🎙 Gast: Alex – SAP-Projektleiterin & SDT-Praktikerin
🎙 Gastgeberin: Anita-Dora Andreadis - Managing Director Sidekick Network GmbH

🎯 Thema: Warum die Selective Data Transition der Mittelweg zwischen Greenfield und Brownfield ist – und worauf es wirklich ankommt.

🔍 In dieser Episode erfährst du:

✅ Was genau Selective Data Transition ist und wie sie sich von Shell Conversion und Mix & Match unterscheidet.
✅ Welche Vorteile dieser Ansatz Unternehmen bei der S/4HANA-Umstellung bietet.
✅ Welche Stolpersteine in Planung, Test und Systemlandschaft auf dich warten – und wie du sie vermeidest.
✅ Warum Fiori in der Conversion-Phase oft zum Problem wird – und wie du smarter damit umgehst.
✅ Bonus: Eine praktische Checkliste zur Planung deiner Systemlandschaft! (siehe unten)

📌 Highlights:

⏳ [00:00] – Begrüßung & Intro
🔄 [00:30] – Selective Data Transition: Was steckt dahinter?
📈 [02:00] – Gründe für SDT & typische Szenarien
🚧 [04:00] – Herausforderungen & Fehlerquellen aus der Praxis
🧪 [06:00] – Teststrategie & Systemlandschaft: Drei Zyklen, klare Struktur
🖥️ [12:00] – Fiori-Falle & Entwicklungskomplexität
🍬 [14:30] – „Kind im Bonbonladen“: Fokus statt Feature-Overload
✅ [17:00] – Drei Hacks + Checkliste für die Planung (sieh unten)
👋 [18:30] – Abschluss & Ausblick

🎧 Jetzt reinhören & deine SAP-Projekte smarter machen!

🔔 Abonniere den Podcast, um keine Episode zu verpassen! 🚀

Mehr Infos zu Alex: https://www.linkedin.com/in/alexandra-l%C3%BCgger-5aa081178/
Mehr Infos zu Sidekick Network: https://www.linkedin.com/company/sidekick-network/

CHECKLISTE: „Sicht eines Projektleiters auf die Systemlandschaft einer S4 Conversion“:

Umfang der S/4 Hana Systemlandschaft:

Wie viele Systeme werden über die gesamte Projektlaufzeit benötigt werden?
Wie viele Mandanten soll es in den Systemen geben?
Soll die S/4 Hana Landschaft eine Drei- oder Zwei-System Landschaft werden?
Wann wird das produktive S/4 System aufgebaut?
Entwickelt sich die S/4 Landschaft zum GoLive ggf. zu einer Drei-System-Landschaft?
Tipp: eine einfache Übersicht der Systeme und Mandanten für die jeweiligen Aktivitäten ist hilfreich 😉

Anforderungen aus den Testzyklen:

Wie viele Testzyklen sollen durchgeführt werden?
Sollen die Testzyklen aus jeweils Datenmigrations- und Funktionstests in separaten Systemen durchgeführt werden?
Sind ggf. unterschiedliche Mandanten ausreichend?
Was soll in welchem System / Mandanten wann erfolgen?
Welche Systeme werden als Basis für die Datenmigrationstests genutzt?
- Müssen diese ggf. mit Daten aus einem Produktivsystem aktualisiert werden?
- Ist es erforderlich, Systemverbindungen zwischen Quell- und Zielsystemen aufzubauen?

Zeitlicher Vorlauf:

Werden die Systeme durch das Unternehmen selbst oder durch einen Provider zur Verfügung gestellt?
Sind es On Premise Systeme oder erfolgt die Migration in ein Cloud System?
On Premise Systeme zusätzlich: Ist ausreichend Hardware vorhanden oder muss weitere Hardware beschafft werden?
Welcher zeitliche Vorlauf wird benötigt, um die Systeme oder die Mandanten aufzubauen? ○ Dauer der Beschaffung von Hardware
- Vorlaufzeiten / Anmeldezeiten bei IT oder Provider
- Dauer für den Systemaufbau durch IT oder Provider
- Dauer der Einbindung in die Transportlandschaft

Anforderungen an das Transportwesen:

In welchem System erfolgt die Custom Code Adaption?
Wie werden die Daten aus dem ECC-System in das S/4 Hana System übertragen? ○ Ist ein Retrofit Prozess implementiert?
- Wer sichert die Qualität des Retrofits ab?
Wie sehen die Transportfreigaben / Transportfenster für die Vorbereitung der Tests aus, d.h. auf welchem Stand der Projektarbeit kann der jeweilige Test erfolgen?
Ab wann kann die Weiterentwicklung auf dem ECC System gestoppt werden? ○ Spätestens zum Start des 3. Testzyklus sollten alle Entwicklungen auf dem ECC System abgeschlossen und in das S/4 Hana System übertragen worden sein.

Transkript

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.