Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 7 Episoden

Copy, Paste, Rollout

Der Template-Approach in komplexen IT-Programmen.

22.05.2025 14 min

Zusammenfassung & Show Notes

In dieser Folge von Smart Hacks für IT Projektmanager spricht Anita-Dora Andreadis mit Lukas Allmansberger über den "Template Approach" bei großen SAP-Rollout-Programmen. Lukas bringt seine Erfahrung aus einem umfangreichen S/4HANA-Programm in einem internationalen Pharmakonzern ein und schildert praxisnahe Herausforderungen und Lösungen. Die beiden diskutieren u. a. darüber, wie wichtig es ist, Templates frühzeitig einzuführen, klar zu kommunizieren und kontinuierlich weiterzuentwickeln. Besonders betont werden die Bedeutung intuitiver Gestaltung, Verantwortlichkeitsregelungen sowie die Einbindung aller Nutzergruppen – vom PMO bis zu lokalen Rollout-Teams.

📢 Episode: Templates, Teamwork & Timing – Erfolgsfaktoren bei globalen SAP-Rollouts

🎙 Gast: Lukas Allmansberger – IT-Projektmanager & S/4HANA-Programmerfahrener

🎯 Thema: Warum ein strukturierter Template-Ansatz und echte Einbindung der Nutzer entscheidend für den Erfolg internationaler Rollouts sind.

🔍 In dieser Episode erfährst du:
✅ Wie ein zentrales Template Kosten, Qualität und Zeit positiv beeinflussen kann
✅ Warum ein Template kein Nebenjob ist – und was das mit PMOs zu tun hat
✅ Wie man lokale und zentrale Teams smart integriert
✅ Warum „weniger ist mehr“ auch für Projektpläne gilt
✅ Was ein Template mit einer App gemeinsam hat – und warum Intuition zählt

📌 Highlights:
[00:00] – Begrüßung & Vorstellung Lukas Allmansberger
[00:07] – Warum ein Template allein kein Selbstläufer ist
[03:19] – Drei Schritte zum funktionierenden Template: Verantwortung, Einbindung, Kommunikation
[05:30] – Must-haves im Template – und warum Naming Conventions wichtig sind
[07:10] – Flexibilität vs. Standardisierung: So bleibt das Template nutzbar
[08:20] – Ein gemeinsamer Plan für zentrale und lokale Teams
[09:25] – Retrospektiven, Feedback & Automatisierung als Erfolgsbooster
[13:10] – Die drei zentralen Hacks im Überblick

🎧 Jetzt reinhören & bewährte Praxis aus dem Projektalltag mitnehmen!
👉 LINK

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

📎 Mehr über Lukas Allmansberger:
👉 https://www.linkedin.com/in/lukas-allmansberger/

📎 Mehr über Sidekick Network:
👉 https://www.linkedin.com/company/sidekick-network/

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 Episode von Smarttextur IT Projektmanager. Ich bin Anita. Und heute werfen wir einen Blick auf das Thema Template Approach bei großen SAP Programmen, generell bei großen Rollout Programmen. Wenn mehrere Länder Teams Prozesse gleichzeitig live gehen sollen, parallel live gehen sollen, wird es schnell komplex. Dann denkt man okay, ich habe ein zentrales Template, Super ist meine Rettung, es läuft, ich kann smooth durch ein Projekt laufen, ist jedoch nicht ganz so einfach und daher freue ich mich, dass wir Lukas heute dabei haben. Lukas hat mehrere Jahre Erfahrung in IT Projekten, vor allem in S vier Hana Programmen. Aktuell auch. Bist du gerade beim SV Hana Programm in einem großen Pharmakonzern? Und daher freue ich mich auf Einblicke. Ich freue mich auf smarte Tipps und wahrscheinlich haben wir auch ein paar Aha Momente bei den Zuhörern und Zuhörer. Lukas Schön, dass du heute mein Gast bist. Ich freue mich, hier zu sein. Ich bin selbst schon ganz gespannt. Lukas kannst du über einen besonders schwierigen Fall berichten, bei dem die Umsetzung des Templates eher herausfordernd war? Ja, sehr gerne. Es war ein recht großes ERP Projekt, also wirklich sehr, sehr viele Rollouts, mehrere Jahre und auch einige parallele Rollouts. Also eigentlich perfektes Szenario für einen Template Approach, weil man natürlich da einfach ein paar Vorteile zu nennen. Man kann natürlich durch die Standardisierung des Rollout Approaches, durch Vorlagen für Pläne für Lieferobjekte schafft man es natürlich, dass man den Aufwand für die Projektmanager reduziert. Man kann die Planung beschleunigen und unterm Strich Man spart Zeit und natürlich auch Ressourcen. An der Stelle und um zumindest einen zweiten Punkt zu nennen Man lernt ständig aus Back practices. Das heißt, man kann Fehler reduzieren, vor allem Fehler, die häufiger passieren. An klassischen Stolperstellen also. Kurz zusammengefasst Man schafft es. Ich sage mal, in allen drei klassischen Dimensionen Kosten, Zeit und Qualität einen positiven Einfluss zu gewinnen oder hat einen positiven Einfluss. Okay, zurück zum herausfordernden Fall. Als ich in das Projekt kam, gab es bereits einen Template Approach und der wurde kurz bevor ich reingekommen bin, eingeführt. Aber in der Umsetzung gab es noch einige Schwierigkeiten. Also das Problem war vor allem es wurde nicht konsequent umgesetzt. Das hat man daran gemerkt. Die Teams haben eigene eigene Arbeitsweisen entwickelt, divergierende Arbeitsweisen. Also jedes Projektteam hat hat für sich Dinge anders gemacht Und natürlich dann haben sich Fehler wiederholt. Genau das, was ich eben erwähnt habe in das Gegenteil. Fehler wiederholen sich, gleiche Dokumente wurden mehrfach erstellt und um vielleicht eine erste Ursachenanalyse schon reinzugehen. Ich glaube, das große Problem war hier, dass das Template noch nicht zu Beginn stand. Das heißt, die Teams haben selbst eigene Arbeitsweisen entwickelt gehabt. Und als das Template kam, sich an eigene Arbeitsweisen schon gewöhnt. Das heißt, ich glaube, wenn wir direkt am Heck einsteigen wollen, der ersten Frage. Ich glaube, das Template zumindest eine Basisversion sollte vor dem ersten Rollout stehen. Aber ich denke mal zu wie genau. Ich glaube, wir kommen später noch dazu, wenn wir dann ein bisschen über die Details reden, wie das aussieht. Es ist interessant, weil du natürlich wichtige Erfolgsfaktoren genannt hast, also positiven Einfluss auf Geld, Qualität. Und dennoch, wie auch bei dir hat man immer wieder die Herausforderung schwierig in der Umsetzung und daher interessiert es mich natürlich jetzt sehr. Was habt ihr gemacht? Also wie seid ihr mit dem Problem umgegangen, das du gerade beschrieben hast? Genau. Der erste Schritt. Das erste, was wir gemacht haben, war eine klare Verantwortung festlegen. Das heißt, wir haben in unserem Fall im PMO klar festgelegt Das Team ist verantwortlich für den Template approach, also wenn es um die Umsetzung geht, die Verbesserung, dass man quasi klar jemand hat, weil das ist am Ende ein Template approach erstellen und auch maintain. Das ist kein Nebenjob, das ist nicht etwas, was irgendwie eine Projektmanager noch nebenbei macht. Das ist wichtig. Das muss man als Investition in die Zukunft sehen und eine Investition, Da muss man auch mal Zeit reinstecken. Deshalb klar die Verantwortung festgelegt, wer sich darum kümmert. Dann, im zweiten Schritt, haben wir die Experten einbezogen, Das heißt diejenigen, die wissen, wie es geht, die Anforderungen haben, also Projektmanager, fachliche Experten, Prozessexperten. Wir haben den gesprochen. Was braucht ihr? Welche Szenarien gibt es, auf die das Template sich einstellen muss? Und einfach deren Expertise genutzt an der Stelle und dann natürlich darauf aufbauend dann ein Template aufgesetzt bzw das Template angepasst verbessert und das dann im dritten Schritt ganz klar kommuniziert. Das heißt, wir haben uns mit den Teams hingesetzt und ganz klar vermittelt, das ist das Template, das ist die Methodik, die dahinter steht, auch die Vorteile vermittelt. Was das denn für euch bedeutet, Das ist eine Entlastung. Es hilft euch. Also nutzt es. Also wirklich die positiven Aspekte dargelegt. Und natürlich auch Erwartungen kommuniziert. Also das ist natürlich auch ein Teil, dass wir gesagt haben das Template bitte nutzen. Genau. Und ganz, ganz wichtig, ganz, ganz wichtig hierbei ist es natürlich Das ist keine einmalige Sache, das muss man ständig wieder machen, Das ist kontinuierlich Arbeit in Retrospektiven. Es ist ein lernendes Dokument. Das ist nicht nicht zu Ende nach dem ersten Satz. Das geht bis zum letzten Rollout durch. So was wie ein lebendiges Werkzeug. Genau. Lebendes Dokument, lebendiges Dokument. Das finde ich sehr, sehr schön. schöner. Ja, vor allem gerade bei diesen komplexen Programm, über das wir sprechen. Das sind dann Jahre konzernweit Europa weltweit. Und da das den Aspekt, den du erwähnt hast mit kein Nebenjob das ist, das ist sehr wichtig. Also natürlich, wir reden hier nicht über zwei drei Rollouts, sondern wirklich konzernweite und große Teams. Was macht für dich inhaltlich den Unterschied? Also worauf kann man inhaltlich besonders achten? Ganz, ganz wichtig. Ich fange mal mit den Must haves an an der Stelle. Was für mich definitiv dazugehört in so ein standardisiertes Template. Ich nenne es mal Plan an der Stelle ist natürlich, dass die Hauptaktivitäten in dem Template in dem Plan enthalten sind. Das sind die wichtigsten Aktivitäten, die man machen muss. Das sind Lieferobjekte. Quality Gates Also diese zentralen Aspekte sollten, finde ich, sind für mich die Must haves, die da drin sind. Und hier als wichtige Randbemerkung wichtig natürlich, dass man darauf achtet, dass auch die Naming Convention übereinstimmt mit gegebenenfalls einem Programm oder mit anderen äußeren Rahmenbedingungen bzw mit anderen Dokumenten, dass man da eine Standardisierung auch da drin drin hat. Das ist, finde ich, glaube ich, ganz, ganz wichtig. Und um vielleicht jetzt hier die Verbindung auch zum Ersten Hack wieder zu machen, den wir anfangs erwähnt hatten mit vor dem ersten Rollout bereits ein Template. Ich glaube hier ist ganz wichtig fangt erstmal mit den Must haves an, fangt nicht an mit einem riesengroßen Template, sondern fangt mit den Must haves an! Im ersten Schritt ist ist weniger mehr. Man lernt noch, man weiß ja noch nicht alles. Das heißt das kommt dann noch mit der Zeit, was man an Addons noch braucht. Genau. Und wenn schon Add ons sage also nur um vielleicht einen kleinen Einblick zu geben, was was bei uns der Fall ist. Wir beispielsweise haben dann neben den Must haves noch entschieden, dass wir noch einen detaillierteren Projektplan machen, weil es einfach in unserem Fall den Projektmanagern hilft. Das reduziert in unserem Fall deren operativen Aufwand. Das heißt, wir haben gesagt, wir bieten euch das noch an, dass ihr das nutzen könnt in unserem Fall. können nicht müssen und das lässt sich beliebig erweitern, also über Kommunikationspläne, Trainingspläne. Also die die Liste kann ewig lang sein. Ganz wichtig natürlich Balance zwischen Komplexität und Flexibilität und den Bedürfnissen. Also am Ende fängt klein an und dann schaut was macht Sinn in dem jeweiligen Fall. Das gefällt mir super. Also vor allem mit den mit den zwei Plänen. Ich habe auch aus der Zeit, wo ich selbst solche großen Programme unterstützt habe, war immer die Frage, wie wenig, wie viel Maximum ist es overengineered oder nicht. Das gefällt mir wirklich gut. Ihr habt nämlich einen kleinen Plan, was ihr wahrscheinlich auch für kleinere Rollouts benutzt, also nicht ganz so komplex sind und dann je nachdem. Aber mindestens Lieferobjekte habt ihr sicherlich und daher gefällt mir sehr gut. Jetzt haben wir über den Inhalt gesprochen. Welche weicheren Faktoren gibt es noch? Was habt ihr noch? Was sollte man noch beachten? Genau. Sehr, sehr wichtiger Punkt. Ich glaube, im Kern ganz wichtig ist, dass man schaut was brauchen die Nutzenden, was sind die die Bedürfnisse? Welche Herausforderungen müssen mit dem Template auch gelöst werden? Und dann natürlich auch schaut, wenn es. Es soll ja genutzt werden. Das heißt, man muss auch entsprechend flexibel genug gestalten an die individuellen Anforderungen des jeweiligen Rollout. Wir hatten es gerade schon. Kleineres Rollout, komplexeres Rollout. Das haben wir gerade schon kurz angerissen, aber auch in die eigenen Arbeitsweisen der Deployment Manager der Teammitglieder. Weil jeder hat seine eigenen Arbeitsweisen und das ist auch wichtig, dass da das nicht zu starr ist, sondern dass jeder mit dem Template gut arbeiten kann und dazu der passende Begriff, glaube ich auch intuitiv. Es muss intuitiv gestaltet sein. Also Beispiel App Wenn ich jetzt eine App runterlade, ich öffne sie und komme nicht zurecht, weiß nicht was ich machen soll. Keine Ahnung wo ich hin muss. Die ist genauso schnell wieder deinstalliert und es ist mit dem Template ja nicht anders. Wenn ich als wenn ich in das Template gehe und ich komme damit nicht zurecht, dann ist natürlich schon das größte Hindernis überhaupt, dass die Leute es annehmen und nutzen. Deshalb intuitive Gestaltung. Ganz, ganz, ganz wichtig. Denke ich auch. Genau. Ansonsten Ich finde, es gehört eine gewisse. Man muss eine gewisse Kultur der Nutzung und Verbesserung etablieren. Also das ist wahrscheinlich auch ein gewisses Mindset. Man muss den Leuten die Vorteile vermitteln, was den Leuten hilft. Man muss im Umgang damit schulen und auch stetig unterstützen bei Bedarf und natürlich Feedbackmechanismen, Retrospektiven, weil das ist ja das Ganze, der Kern auch am Ende. Wir wollen ja auf den Erfahrungen aufbauen. Deshalb ist ganz, ganz wichtig, das auch als Kultur denke ich zu verankern. Und jeder hat schon 1000 Mal gehört. Es gehört natürlich auch hierhin die richtigen Tools wählen. Es ist auch hier natürlich A und O, natürlich an der Stelle Was hat man unternehmen, was was bietet sich an? Und vielleicht auch mal schauen, wo kann ich die eine oder andere Automatisierung einbauen, ohne natürlich das ganze over zu inszenieren, sondern so, dass es dass es unterstützt? Aber ich denke hier das wichtigste Take away an der Stelle ist, die Nutzenden einzubeziehen. Was brauchen sie Natürlich auch in der Beachtung von äußeren Umständen. Man muss natürlich immer schauen, was ein Unternehmen, Standards, was sind Anforderungen eines Programms? Aber natürlich im Kern die Nutzenden einzubeziehen. Das gefällt mir gut. Wir haben jetzt viel über das zentrale Team gesprochen einigendes globales Team, je nachdem, wie die Begriffe in den Konzernen genutzt werden. Wie habt ihr das mit den Rollouts gemacht oder Deployment Kits? Wie habt ihr die eingebunden? Die haben ja auch Schritte, die haben ja auch Lieferobjekte. Sehr gute Frage, weil gerade unter dem Aspekt, den ich gerade genannt habe, mit Nutzen einzubeziehen. Man darf nicht vergessen, auch die lokalen Teams sind Nutzende, zumindest meines. Deshalb ich finde, die sollten auch die Aufgaben, die Verantwortlichkeiten, Lieferobjekte der Local sites gehören auch in den Plan inkludiert. Das, finde ich, ist ein ganz, ganz zentraler Aspekt. Und ich finde auch gerade deshalb, weil die Roll Out Teams sind häufig ja auf mehreren Rollouts, das heißt, sie entwickeln eine gewisse Routine mit der Zeit. Sie wissen, was auf sie zukommt. Bis zu einem gewissen Grad. Aber die Locals Sites machen das meistens einmal oder häufig nur einmal. Das heißt, gerade für dieses will ich noch mal besonders hilfreich. Es gibt Sicherheit und Unterstützung und hilft natürlich auch im gegenseitigen Erwartungsmanagement. Also in beide Richtungen. Wer macht was, wer hat welche Verantwortlichkeiten? Deshalb, ich würde sagen best case, einen gemeinsamen Plan, der beides beides beinhaltet. Finde ich super. Also da kann ich. Kann ich dir nur zustimmen. Lucas ganz herzlichen Dank. Ich freue mich über die Einblicke. Vor allem über deine Erfahrung und auch über die ehrliche Lessons Learned, dass uns da wirklich klare Insights gegeben hast. Ich bin mir sicher, dass während wir das Interview hatten, dass einige Zuhörer und Zuhörerinnen gesagt haben Oh ja, kennen wir auch und daher hoffen wir, dass wir da doch ein paar Tipps mitgeben konnten. Daher würde ich gern noch mal die Hacks zusammenfassen. Und zwar Erstens habe ich mir mitgenommen, wenn die Nutzer ein. Und denkt daran, es ist so ein lebendiges Werkzeug, es entwickelt sich immer weiter. Zweitens starte mit dem Matthews lieber erstmal einfach als überkomplex und drittens Fang früh an! Vor dem Rollout sollten wir doch dass die erste Version stehen haben und am besten mit den gemeinsamen mit dem gemeinsamen Lieferobjekten Tätigkeiten zusammen mit den Rohloff Zeitz. Lukas, schön, dass du mein Gast warst. Vielen Dank. Sehr gerne. Es war mir eine Freude. Und Euch, liebe Zuhörerinnen und Zuhörer, schön, dass ihr dabei wart. Bis zur nächsten Folge eurer Anita. Der Clou.