Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 17 Episoden

Laut ist nicht Go-Live-kritisch: Stakeholder-Management und Clean Core in SAP-Projekten

Wie man als Projektleiter unsichtbare „U-Boot-Stakeholder“ früh erkennen, Anforderungen belastbar priorisieren und Scope Creep sowie technische Schulden vermeiden kann.

07.09.2026 25 min

Zusammenfassung & Show Notes

In vielen HR-IT- und SAP-Projekten scheitert der Erfolg nicht an der Technik, sondern an zu spät eingebundenen Stakeholdern, unklaren Prioritäten und immer neuen Sonderwünschen. Gemeinsam mit Johannes Brückmann sprechen wir darüber, wie Projektleiter „laut“ von wirklich Go-Live-kritisch unterscheiden, Stakeholder wirksam einbinden und Scope Creep begrenzen. Außerdem zeigen wir, warum SAP Clean Core vor allem eine Frage von Governance, Veränderungsbereitschaft und konsequenten Entscheidungen ist.

📢 Episode: Laut ist nicht Go-Live-kritisch – Stakeholder-Management und Clean Core in SAP-Projekten

🎙 Gast: Johannes Brückmann – Projektmanager für SAP HCM, HR-IT und Transformationsprojekte

🎯 Thema: Wie Projektleiter relevante Stakeholder frühzeitig einbinden, Anforderungen belastbar priorisieren und SAP Clean Core als organisatorischen Veränderungsprozess etablieren.

🔍 In dieser Episode erfährst du:

✅ Warum HR-IT- und SAP-Projekte häufig nicht an der Technik, sondern an zu spät eingebundenen Stakeholdern scheitern.

✅ Weshalb eine einmalig erstellte Stakeholderanalyse nur ein gefährliches Gefühl von Sicherheit vermittelt.

✅ Wie du „U-Boot-Stakeholder“ rechtzeitig erkennst und dein Stakeholder-Management kontinuierlich aktuell hältst.

✅ Warum informelle Gespräche, persönliche Videos oder kurze Newsletter oft wirksamer sind als formelle Statusberichte.

✅ Mit welcher einfachen Frage du laute Sonderwünsche von wirklich Go-Live-kritischen Anforderungen unterscheidest.

✅ Wie WSJF dabei hilft, Anforderungen nachvollziehbar zu bewerten und politische Diskussionen zu versachlichen.

✅ Warum SAP Clean Core keine einmalige technische Initiative, sondern eine dauerhafte Governance- und Change-Aufgabe ist.

📌 Highlights:

⏳ [00:25] – Warum HR-IT- und SAP-Projekte zur Dauerbaustelle werden
👤 [01:47] – Vorstellung von Johannes Brückmann
⚠️ [03:53] – Die Gefahr der Alibi-Stakeholderplanung
🔄 [06:42] – Warum Stakeholder-Management „atmen“ muss
☕ [08:07] – Vertrauen entsteht vor allem informell
📹 [10:52] – Newsletter, Videos und persönliche Kommunikation statt Textwüsten
🎯 [14:01] – Wichtig, laut oder wirklich Go-Live-kritisch?
📊 [15:59] – Anforderungen mit WSJF nachvollziehbar priorisieren
🧩 [17:53] – Clean Core als Organisations- und Change-Thema
💳 [21:27] – Goldrandlösungen, Custom Code und technische Schulden
🚀 [23:29] – Fazit und sofort umsetzbare Praxis-Hacks

🎧 Jetzt anhören und Stakeholder, Anforderungen und Standards wirksamer steuern!

👉 https://open.spotify.com/show/0APte8frTVKlQ48EfEalcf

🔔 Folge uns, um keine Episode zu verpassen!

Mehr Infos zu Johannes Brückmann:
https://www.linkedin.com/in/johannes-brueckmann/

Mehr Infos zu Sidekick Network:
https://www.linkedin.com/company/sidekick-network/

Transkript

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! In vielen HR-IT- und SAP-Transformationsprojekten scheitert die Umsetzung nicht an der fachlichen Idee. Sondern daran, dass relevante Stakeholder zu spät eingebunden werden, Sonderwünsche unklar priorisiert sind und zwischen Standardisierungen und individuellen Anforderungen kein belastbarer Entscheidungsrahmen besteht. Gerade in großen Organisationen wird HR-IT dann schnell zur Dauerbaustelle. Der Fachbereich fordert Ausnahmen, Entwickler wollen bestehende Lösungen behalten, Parallelprojekte funken dazwischen und kurz vor dem Go-Live wird sichtbar, dass zentrale Rollen im Test oder in der Umsetzung fehlen. In dieser Episode zeigen wir, wie Projektleiter mit gutem Stakeholder-Management zwischen wichtig und laut und wirklich go-live-kritisch unterscheiden und warum das SAP-Leitprinzip Clean Core dabei weniger ein Technikthema als ein organisationaler Veränderungsprozess ist. Unser heutiger Gast ist Johannes Brückmann, ein erfahrener Projektmanager im SAP HCM-Umfeld mit Praxis in komplexen Konzernstrukturen. Johannes bringt konkrete Erfahrung aus HiRIT-, S/4HANA- und HCM-Projekten mit. Besonders spannend ist sein Blick auf Situationen, in denen Projekte nicht an fehlender Methodik scheitern, sondern an nicht eingebundenen Stakeholdern, unklaren Verantwortlichkeiten und dem Konflikt zwischen Standardisierung und Goldrandwünschen. Hallo Johannes, schön, dass du da bist. Dass wir dich heute als Gast begrüßen dürfen. Danke, Andreas, dass ich da sein darf. Wir kennen uns ja jetzt schon eine ganze Weile, die wir zusammenarbeiten durften, und in den Projekten haben wir immer wieder über dieselben Themen gesprochen, wo es sozusagen immer wieder knirscht, was gar nicht so sehr mit der IT und Coding zu tun hat, sondern mit Menschen. Und deswegen bist du heute auch dabei, weil es wiederum sehr interessant sein kann, sich darüber auszutauschen, wenn es denn um die wirklichen Hacks geht. Wo man ansetzen kann. Und aus deiner Sicht, wenn es jetzt um HR, IT und SAP-Projekte in dem Umfeld geht, warum ist gerade dann das Stakeholder-Management so enorm entscheidend? Und woran merkst du früh, dass ein Projekt in die falsche Richtung läuft? Ja, genau. Ich glaube, man kann das gar nicht so sehr pauschalisieren. Jetzt auf das High-End-Umfeld bezogen oder SAP-Projekte, dass die jetzt besonders komplex sind. Aber gerade wenn wir über größere Unternehmen sprechen und SAP-Projekte dann dort, dann muss ich doch festhalten, habe ich beobachtet, sind Projekte selten klein, einfach oder isoliert. Also wir haben massiv integrierte Systeme, also Systeme, die hochgradig vernetzt sind, die am Ende irgendwie das Nervensystem des Unternehmens darstellen. Das heißt, wir haben eine hohe Komplexität, die sich dadurch zeigt, dass wir unzählige Prozessteilnehmer haben. Wir haben vielfältige System Owner, wir haben unterschiedliche Fachbereiche, die natürlich bei so einem Projekt mitreden wollen, aber sie müssen auch mitreden. Und meine Beobachtung aus dem Großkonzern, ich habe eine der größten Systemlandschaften Deutschlands mitbetreuen dürfen, ist eben, dass die Projekte fast nie an einer schlechten fachlichen Idee oder eben der technischen Umsetzung scheitern, sondern sie scheitern daran, dass die wichtigsten Personenrollen zu spät mit am Tisch sitzen. Stakeholder Management steht ja meistens mit auf diesen Folien drauf. Das müssen wir machen. Genauso wie Change Management muss irgendjemand dann mal tun. Wie kriegst du es hin, dass du so— Oftmals wird das ja so als lästige Checkliste abgetan. Ja, ja, das machen wir dann schon noch. Da muss sich jemand im Team drum kümmern. Aber Aber wie bekommst du es hin, dass diese Alibi-Planung, die ja eigentlich auch ganz schön gefährlich ist für so einen Projekterfolg, dann mit einfachen und vielleicht auch sofort umsetzbaren Praxis-Hacks optimiert werden kann? Also ich aus meiner eigenen Erfahrung Stakeholder-Management, das hat immer nicht so viele Leute interessiert und manche haben sich auch gar nicht herangetraut, weil sie dachten, ja, da muss ich ja dann immer mit den Menschen kommunizieren, mit denen ich mich eh schon schwer tue. Und denen jetzt vielleicht auch Wahrheiten mitzuteilen oder einfach nur einen Status zu geben. Ja, ist immer schwierig gewesen für manche Personen. Ja, also du sagst das und ich glaube, wir kennen das beide nur zu gut. Wir haben beide einen Großkonzern mittlerweile unterstützen dürfen. Ich kenne das oder habe es gehört aus dem medizinischen Bereich. Das heißt, alle Produkte, die irgendwie in der Medizin am Ende eingesetzt werden, die müssen extrem dokumentiert, protokolliert werden. Oder auch aus dem Automobilbereich ist er oft vorzufinden. Das heißt, wir haben in Unternehmen und dort geführten Projekten ganz oft riesige Projektframeworks mit Hunderten von To-dos und da ist die Stakeholderanalyse dann eine von unzähligen lästigen Pflichtdokumenten, muss man sagen. Aber ich würde immer auch klar machen, dass wir aufpassen müssen, so was wie Stakeholdermanagement nicht im Pareto-Prinzip zu machen. Also Pareto-Prinzip ist ja 80% der Leistung und 20% der Zeit zu machen. Das kann absolut sinnvoll sein in ganz vielen Bereichen, das ist super effizient. Aber ich glaube, du würdest mir auch zustimmen, dass ein Chirurg, wenn wir gerade operiert wären, dass der vielleicht nicht nach Pareto-Prinzip arbeiten sollte. Und das sehe ich beim Stakeholder-Management genauso, weil am Ende diese fehlenden 20% der Leistung, das können dann eben genau diese U-Boot-Stakeholder sein, die am Ende die anfänglich unsichtbar sind, aber am Ende eben eine ganz große Herausforderung darstellen können. Also wir müssen wirklich aufpassen. Die einen Stein in den Weg legen können, ohne dass du es jetzt schon so richtig auf dem Schirm hast. Genau, genau. Also am Ende eiskalt das Projekt sabotieren. Also wir müssen da wirklich aufpassen, nicht in so eine Alibi-Planung reinzugehen, weil einfach nur abhaken dieses Stakeholder-Management und nie wieder anzufassen. Das sorgt eben dafür, dass wenn wir in Herausfordernde Projektumfelder laufen, dass das dann eben genau zum großen Problem wird. Ja, und wie machst du das dann konkret? Also was ist so dein Go-to-Move? Ja, genau. Also ich glaube, wir kennen alle so die klassischen Werkzeuge. Ich hatte die im Studium, in der kleinen SAP-Beratung damals habe ich die dann nie wieder gehört. Dann kam ich in einen Großkonzern und dann hieß es wieder ja RACI-Matrix, Mennelow-Matrix. Das ist so die Basis. Aber ganz wichtig, ab in irgendeinem Projekt-Folder, wird er dann abgelegt und dann haben wir doch alles. Genau, einmal gemacht, dann abgelegt. Aber wir müssen da wirklich aufpassen, weil Stakeholder sind dynamisch. Sie sind nicht statisch. Das heißt, so ein Stakeholder-Management, das muss atmen, das muss regelmäßig geupdatet werden. Und jetzt ein harmloser Keep-informed Stakeholder, ein Stakeholder, den wir anfänglich am Anfang des Projekts als Keep-informed einfach nur klassifiziert haben, dem wir also vielleicht nur alle paar Wochen mal so ein kleines Update schicken, der kann über Nacht auch ganz schnell mal zum mächtigen Keyplayer werden und dann eben auch aktiv das Projekt in Anführungsstrichen sabotieren. Also da wirklich Obacht! Stakeholder sind dynamisch, aber vielleicht jetzt mal kurz zu den Quick Wins hier an der Stelle. Weil das eine ist natürlich, wie wir Stakeholder überhaupt auf dem Radar haben, wie wir sie klassifizieren, wie wir sie auch in welchem Abstand irgendwie abholen wollen. Aber das andere ist ja dann wirklich auch, wie wir sie ganz tatsächlich abholen. Holen. Und im Großkonzern ganz klassischerweise haben wir ja diese ganz großen Lenkungskreise, also große formelle Statustermine. Und ganz ehrlich, ich habe noch nie jemanden gehört, der gesagt hat, er hat so richtig Bock auf so einen Statustermin. Die waren immer alle tiefenentspannt, von denen ich gehört habe. Ja, genau so sieht es aus in der Praxis. Hast du vollkommen recht. Eben leider nicht. Und deswegen würde ich hier wirklich sagen, vielleicht auch ein bisschen weg von diesem formellen Status-Termin und mehr hin zu informellen Terminen. Dass man versucht, informell einen Kaffeetermin, einen bilateralen Pull-It-Checks oder ein gemeinsames Mittagessen versucht, seine Stakeholder abzuholen. Also wirklich getreu nach dem Motto, dass Vertrauen vor allem informell entsteht. Ja, ich denke auch dann da an dem Punkt immer eine Regelmäßigkeit zu haben. Und vielleicht auch diesen Termin durchzuziehen, auch wenn es im Moment vielleicht gar nicht brennt und man denkt so, ich habe echt andere Sachen zu tun. Aber ich habe mitbekommen, dass die Gegenseite das sehr wertschätzt, wenn man nicht nur kommt, wenn sozusagen jetzt was gebraucht wird von der Gegenseite, sondern auch sozusagen rein informativ immer wieder begleiten. Wo stehen wir im Projekt? Die können ja immer noch ihren Termin absagen, dann hast du die Zeit gespart. Aber dieses Mitnehmen, auch wenn man kein wichtiges To-do an der Stelle mit dieser Person hat, das war immer dann 2, 3 Meetings später, wurde das dann formuliert und wurde gesagt: Übrigens, ich fand das echt gut, dass wir uns trotzdem getroffen haben und dass du nicht bloß zu mir kommst, wenn du ein Problem hast und mich und dann ein halbes Jahr dich gar nicht meldest. Also so Wahrnehmung schaffen. Ja, also vollkommen richtig, weil das eine ist ja, dass du, also wir ein Thema haben, was wir berichten oder eben kein Thema vielleicht, was wir berichten können. Das andere ist ja, dass die Gegenseite vielleicht Sorgen und Ängste hat, die sie dann genau in so einem Termin eben dir auch kommunizieren können. Und deswegen sollte man wirklich versuchen, sei es jetzt auch so ein Status-Termin oder eben auch diese informellen Termine, dass man die wirklich regelmäßig auch beibehält, eben auch genau um der anderen Seite die Möglichkeit zu bieten, Fragen zu stellen, Sorgen und Ängste zu teilen. Da bin ich voll bei dir. Ja, und ich glaube auch, dass solche Infos, wenn du das nicht regelmäßig machst, auch selten dir proaktiv kommuniziert werden. Also da wird niemand kommen und sagen: Hey, übrigens, wäre schön, wenn du dich mal wieder bei mir meldest. Ich fühle mich überhaupt nicht wahrgenommen von dir. Und das passiert immer 2, 3 Jahre später oder 2, 3 Monate später, wenn es dann mal kracht. Dann wird das auf den Tisch gebracht. Na, du hast dich ja auch nie um uns gekümmert. Ja, oftmals auch bei Kiosken der Fall. Genau. Und zum Thema Melden auch: Wir kennen es ja auch, dass dann Projekte halt regelmäßig E-Mails rausschicken an große Verteiler. Also riesige E-Mails mit ganz viel Text, wo dann eben über das Projekt berichtet wird. Und ich habe das auch in einem Projekt mal gesehen und das fand ich super charmant, dass man eben versucht hat, aus dieser regelmäßigen E-Mail, die man an einen großen Verteilerkreis teilt, weg eben von einer Wall of Text und hin zu so einer Art regelmäßigen Newsletter, der bewusst persönlich, informell, lustig gestaltet wird. Vielleicht kann man das Ganze auch so als eine Zeitungspapierseite eben gestalten mit Fotos des Projektteams, Erfolge werden gefeiert, dass man da an der Stelle wirklich versucht, die Leute so abzuholen, dass sie sich eben auch über so eine in Anführungsstrichen regelmäßige Newsletter-E-Mail freuen, ja, statt sie dann eben ungelesen einfach wegzuschmeißen. Also auch Das ist eine Möglichkeit meiner Meinung nach, um sicherzustellen, dass wenn man halt die Stakeholder erst mal alle so erfasst hat, auf dem Radar hat, er regelmäßig zu updaten. Ja, und da würde ich vielleicht noch einen Punkt reinbringen wollen, den ich jetzt mal erlebt habe in einem Projekt: Unterschiedliche Medien nutzen. Also was ist in dem Projekt, wo du drin bist, gewesen, oder in Projekten, die du— bist den ganzen Tag in irgendwelchen Teams Calls. Du bist eigentlich— hast keine Lust, jetzt noch in einen zu gehen. Ja, auf den Kaffeetermin, da gehe ich mal, da habe ich einen Grund, das Büro zu verlassen. Aber was heute ganz oft gemacht werden könnte, ist eben auch ein kleines Video aufnehmen. Die Technik gibt es ja. Und sagen: Hey Johannes, kurzes Update von mir. Ich finde es cool, dass wir da gemeinsam im Projekt rocken. Muss ja nur eine Minute sein. Aber so was Persönliches, Personalisiertes. Und wenn man im PMO vielleicht noch hat, was auch die Skills und die Nerven dafür hat, eine kleine Handschrift, handschriftliche Notiz. Also das muss keine A4-Seite sein, das können 3 Sätze sein. Wir sehen das auch bei unseren Kunden, wenn wir was Handschriftliches rausschicken und die wissen, das ist nicht AI und das ist nicht irgendwie massenproduziert, da steht mein Name drauf. Ja, das bewirkt manchmal 1000-mal mehr als die normalen Wege. Ja, genau. Also das, was wir vorhin gesagt haben, also Vertrauen entsteht informell. Also wirklich nicht jetzt diese große E-Mail, diese PowerPoint-Folie,, sondern so eine handschriftliche Notiz. Also du sagst, das ist super wichtig. Und zu den Videos, das ist mir auch einmal über den Weg gelaufen, ja, da wurden quasi Onboarding-Videos, und das wurde damals als Snackable Video Content formuliert, also Videos und Snackable Content, also die man halt schnell mal einfach so snacken kann. Du hast es gesagt, eine Minute, 2 Minuten, 3 Minuten kurze Videos, wo dann halt eben wichtige Inhalte rübergebracht werden. Das ist wirklich mal was anderes. Es ist ein anderes Medium, hast du vollkommen recht. Und auch hier muss man sagen, Mittlerweile gibt es Unternehmens-KI-Tools, die halt eben auch solche Videos generieren können. Also auch da muss man jetzt nicht unbedingt mega die Production, Video-Production hochziehen, sondern auch da kann die KI wieder unterstützen. Ich glaube, da geht es gar nicht um Qualität des Videos, sondern dass man es einfach personalisiert. Okay, und wenn du jetzt aus deiner Erfahrung rausschaust, weil die ganzen Praxis-Hacks, die du da mitgenommen hast, wie kannst du denn jetzt unterscheiden, wenn du verschiedene Stakeholder hast und die haben alle Bedürfnisse und alle wollen noch den goldenen Wasserhahn mit eingebaut haben zwischen diesen wichtig und laut, vielleicht auch einfach nur laut und wirklich go-live-kritisch. Da muss ich ran, das kann mir alles zerschießen, wenn ich das nicht mache. Und wie belastet oder wie kommunizierst du dann so ein belastbares auch so? Nein. Ja. Ja, ich glaube, das große Problem, was ich auch oft in Großkonzernen jetzt gesehen habe, ist, dass so eine Pseudo-Agilität geliefert wird. Also im Grunde, wir haben diese großen SAP-Projekte und da wird Agilität oft so verstanden: Wir müssen jetzt irgendwie jeden Wunsch der Stakeholder erfüllen. Also wir haben diese lauten Einzelinteressen und wir laufen dann aber in ein sogenanntes Scope Creep rein, also in eine Dauer-Change-Situation. Wir kriegen andauernd neue Anforderungen. Das Team arbeitet und arbeitet, liefert aber keinen echten strategischen Wert. Und wie unterscheidet man jetzt zwischen Go-Live-kritisch und vielleicht nice to have? Einfach mit der einfachen Frage, die man ruhig bei jeder Anforderung hochwerfen kann: Was würde denn an Tag 1 passieren nach dem Go-Live, wenn diese Funktion jetzt fehlen würde? Und da kann die Antwort dann sein: Ja, dann ist der Button halt rosa statt grün, oder die Antwort ist: Das System steht still, wir können keine Gehälter zahlen, die verstoßen gegen Compliance oder Gesetze. Und ich glaube, da kommt man dann sehr schnell zum Ergebnis: Das ist ein Thema, welches Must-have ist oder eben nur nice to have. Das sorgt ja auch dafür, dass dein Gegenüber gerade seine Anfrage auch innerlich zumindest besser einordnet. Oh ja, ob ich damit durchkomme. Genau, genau. Also wir müssen da wirklich weg wegkommen von der Psychologie, eine emotionale Diskussion hin zu einer logischen, vielleicht sogar mathematischen Diskussion. Ich sage jetzt mathematisch, weil ich habe auch eine Zeit lang in einem SAFe-Konstrukt gearbeitet. SAFe ist ja ein agiles Framework, um ganze Organisationen agil zusammenarbeiten zu lassen. Also Beispiel: Wir haben nicht nur ein, zwei agile Teams, die an einem Produkt arbeiten, sondern wir haben 20 agile Teams, die an Produkt arbeiten. Ich habe eine Zeit lang, war ich Produktmanager bei einem Fahrzeug-Frontend, da braucht es halt mehr als 10 Leute, da braucht es dann vielleicht 100, 200 Leute, die an so einem Frontend arbeiten. Und um sicherzustellen, dass die alle synchron zusammenarbeiten, gibt es dann halt eben so was wie SAFe. So, und SAFe hat das sogenannte WSJF-Prinzip, Weighted Shortest Job First, was einfach nur besagt, wir klassifizieren, wir bewerten unsere Anforderungen mit einem Business Value und eben auch mit einer Zeiteinheit, also mit einer Aufwandseinheit. Und wenn man diese beiden Punkte dann ins Verhältnis setzt, also es ist noch mal eigentlich ein bisschen komplizierter, aber um es jetzt einfach mal zu erklären, wenn man diese beiden Einheiten dann ins Verhältnis setzt, dann kommt man eben zu einem Ergebnis und kann damit seinen Backlog priorisieren. Das heißt, wir haben dann auch wirklich so ein mathematisches und noch mehr logische Priorisierung an der Stelle. Und damit ersetzen wir halt wirklich diese Politik, das Emotionale in der Diskussion. Und wenn wir das dann eben umgesetzt haben und wir haben damit unser Backlog priorisiert, dann sollte idealerweise auch jeder Stakeholder nachvollziehen können, warum jetzt seine Anforderung, sein lautes Einzelinteresse, was er geäußert hat, vielleicht eher ein Thema ist für ganz hinten im Backlog. Ja, und dann kombinierst du das noch mit den Themen, die wir vorher gemacht haben, und dann ist das hoffentlich gut managebar. Ja, wir haben ja auch, oder du hast ja auch oftmals im Vorgespräch gesprochen von dem Thema Clean Core, also so möglichst an der Basis dranzubleiben ohne viele individuelle Modifikationen. Was hat das aus deiner Sicht, dieses Thema Clean Core, dann auch mit Stakeholder Management zu tun? Und warum ist die Standardisierung vor allen Dingen so eher ein Organisations- und Change-Thema als alles andere? Ja, genau. Also ich komme ja zuletzt aus einem Großkonzern und wenn wir da über unsere Kernsysteme reden, dann reden wir über Systeme, die über Jahrzehnte angepasst wurden. Also wir haben ein Standardsystem der SAP eingeführt und die SAP hat ja früher ihre Systeme auch damit beworben: Klar, wir verkaufen euch ein Standardsystem, aber ihr könnt da so viel verbauen, wie ihr wollt. Wir helfen euch sogar dabei, Anpassungen im System vorzunehmen. So, und früher hat man auch gesagt, eine Anpassung, die wir vornehmen im System, ist auch ein Wettbewerbsvorteil. Weil klar, also wir sagen, der Standard würde für uns funktionieren, aber wenn wir den Standard verändern, dann können wir noch mehr Zeit einsparen. Ja, dann können wir da wirklich Geld draus machen mit so einer Anpassung. Mittlerweile sagt man aber, und da kommt jetzt Clean Core ins Spiel, dass es doch ganz sinnvoll sein kann, den Kern des Systems sauber zu halten, also frei von kundenspezifischen Erweiterungen. Warum sagt man das? Warum sagt die SAP das? Also Clean Core ist ein Begriff, der von der SAP geprägt ist, weil jede Anpassung, die wir machen im System, die muss ja auch gewartet werden. Also jede Zeile an Custom Coding, die wir im System haben, die muss früher oder später wieder angefasst werden. Also jetzt beispielsweise bei der S/4HANA-Migration. Ja, alle SAP-Systeme müssen von einer alten Systemversion auf eine neue gehoben werden. Und da gibt es jetzt auch eine neue Datenbanktechnologie. Und wenn wir über eine neue Datenbanktechnologie reden, dann müssen wir auch unsere Datenbankzugriffe anpassen. Das heißt, diese ganzen Custom Code Lines, die wir im System über die Jahre erzeugt haben mit unzähligen Datenbankzugriffen, die müssen jetzt tatsächlich bei diesem Upgrade alle angefasst werden. Und das ist natürlich ein Thema, das erzeugt Aufwand, den man früher vielleicht gar nicht so auf dem Schirm hatte. Das heißt, die SAP sagt hier wirklich: Liebe Kunden, wir müssen das jetzt anders machen. Wir müssen weg von diesen extrem verbauten Systemen. Wir müssen hin zu den Systemen, die nah am Standard sind. Denn die SAP will natürlich auch, dass die Kunden perspektivisch in die Cloud wandern. Und wann können die Kunden in die Cloud wandern? Wenn die Kunden flexibel sind, wenn die Systeme flexibel sind, wenn die Systeme nah am Standard sind. Ja, dann ist ja auch der Punkt, dass sich das Ganze entwickeln hat sich ja auch verändert. Es ist ja alles viel, viel dynamischer. Also früher hast du was installiert, dann war das erst mal ein paar Jahre so. Jetzt ist das ja im Viertel-, Halbjahresmodus, gibt es da Veränderungen. Das hat ja, sage ich mal, dieser ganze Aufwand, den Projektleiter reinstecken mussten, um Veränderungen im System zu moderieren, der ist ja auch enorm und hat man über die Jahre, Jahrzehnte akzeptiert, dass das immer so ist. Jetzt geht man Wenn man nah am Standard ist und Scope Creep war auch ein Thema mit Frank in einer vorhergehenden Folge, wirklich ein Riesenthema, was dir Budget kostet. Ja, genau. Aber auf der anderen Seite jetzt auch, jetzt betrachten wir die Ist-Situation. Die Systeme sind schon alle verbaut. Also wir reden teilweise über Millionen Lines of Custom Coding. Das sind alles Zeilen, die, wenn wir jetzt sagen, wir wollen In einem Jahr wollen wir jetzt sauber sein, also das System soll sauber sein. Dann müssten ja diese Lines of Custom Code irgendwie raus aus dem System. Das ist natürlich auch ein Rieseninvest, was vorgenommen wird. Und deswegen ist Clean Core eben auch kein Projekt. Das ist ein fortlaufender Prozess, der niemals endet. Das ist eine Governance, die eigentlich passieren muss. Denn bei jeder Anforderung, die reinkommt, muss man sich jetzt eigentlich die Frage stellen: Brauchen wir die Anforderung überhaupt? Also warum müssen wir, sollen wir diese Goldrandlösung umsetzen? Die nächste Frage, die wir uns stellen würden, ist: Kann man das nicht auch im Standard umsetzen? Also warum sollen wir denn jetzt unser System verbauen, wenn wir vielleicht über Umwege vielleicht das Ganze auch im Standard umsetzen könnten? Und erst später würden wir uns die Frage stellen: Ja Mist, wir brauchen die Anforderung, wir können sie nicht im Standard umsetzen und wie können wir sie dann hochziehen, dass der Kern des Systems sauber bleibt? Da reden wir dann über Side-by-Side Extensions. Also du verbaust dir nicht dein Hauptsystem, sondern du verbaust die dann, oder du baust das Ganze auf einem anderen System und stellst die Funktionen über APIs bereit. Und der Projektleiter, die Rolle des Projektleiters dann in Zukunft, ist dann halt eben wirklich zu versuchen, die Menge an Custom-Erweiterungen— ja, ich beschreibe das auch oft als technischer Kredit, der eigentlich erzeugt wird. Also jede Individualanpassung, die vorgenommen wird im System, ist eigentlich ein technischer Kredit, der ja perspektivisch, wie gesagt, wegen Wartungsaufwänden und so weiter Kosten verursacht. Der Projektleiter hier an der Stelle jetzt eigentlich die Rolle hat, zu versuchen, diese Kreditlast klein zu halten und Goldrandlösungen bestmöglich natürlich wegzudiskutieren. Das ist auch, ich denke, das ist ein guter Abschluss, eine gute Zusammenfassung auch von deiner Seite aus, wie die Rolle sich entwickeln wird. Damit kommen wir auch zum Ende unserer Podcast. Wir haben heute viel besprochen in der kurzen Zeit, also weg von Alibi-Planung wie man das Backlog priorisieren kann. Clean Core eben auch als Chance, wie du es gerade beschrieben hast, diese technischen Kredite zu reduzieren. Und ich fand auch die eine Frage, manchmal ist es nur eine Frage, die man mitnimmt: Was passiert denn am Tag 1, wenn wir das jetzt nicht haben? Das ist vielleicht am einfachsten umsetzbar und direkt machbar. Deshalb vielen Dank, Johannes, dass du heute unser Gast warst. Und Für alle, die dir folgen wollen, die mit dir in Kontakt treten wollen, die Kontaktdaten sind in den Shownotes drin. Gerne auf Johannes auch zugehen. Ansonsten vielen Dank, dass du da warst. Danke dir, Andreas, und gerne wieder. Ja, mach's gut. Tschüss. Ciao.