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.