Die Umstellung auf eine neue ERP-Lösung wie SAP S/4 HANA stellt für Unternehmen eine große Herausforderung dar. Da ERP-Systeme über alle Bereiche und Ebenen des Unternehmens hinweg zur Steuerung der Geschäftsprozesse genutzt werden, nehmen sie eine Schlüsselrolle in Unternehmen ein und bilden somit den Knotenpunkt der vielen miteinander kommunizierenden IT-Systeme und Anwendungen. Veränderungen am ERP-System sind daher nicht nur sehr komplexe Projekte an sich, sondern haben massive Auswirkungen auf das operative Geschäft. Eine ERP Umstellung wird oft nur als reines IT-Projekt betrachtet, wirkt sich aber auf alle Unternehmensbereiche aus.
Wir sprechen mit Till Hauser darüber, wie wichtig ein gutes Projektmanagement bei einem solchen Mammutprojekt wie z. B. einer SAP S/4HANA Transformation ist, welche Fallstricke und Chancen es gibt und welche Projektmanagement-Methoden sich eignen.
Hören Sie dazu unseren mgm Podcast Folge #17 oder lesen Sie unten das schriftliche Interview.
Inhalt
- Was zeichnet ein ERP-Projekt aus und warum ist ein gutes Projektmanagement bei der Einführung eines ERP-Systems essentiell wichtig ist?
- Welche Rollen und Bereiche im Unternehmen sind üblicherweise in einem ERP-Projekt beteiligt?
- Welche sind die größten Herausforderungen in einer SAP Transformation aus Projektmanagementsicht?
- Welches Standardvorgehen für die SAP S/4HANA Umstellung empfiehlt SAP?
- Worauf ist bei der Anwendung der Methoden Activate und Focused Build in der Praxis zu achten und wie sind diese zu bewerten?
- Was sollte ein Projektmanager bei der Projektplanung besonders beachten? Wie sollte die Auswahl und Gestaltung der Projektmethodik im Einzelfall erfolgen?
- Kannst du anhand eines konkreten Beispiels aus deiner Projekterfahrung beschreiben, wie auf den Unternehmenskontext reagiert wurde und welche Ansätze und Methoden im Projekt erfolgsentscheidend waren?
Carla Tusche: Ich freue mich sehr auf unseren heutigen Interview-Gast Till Hauser. Wir sprechen heute über ein Thema, was für sehr viele Unternehmen, ich würde sagen fast alle, gerade große Relevanz hat, nämlich SAP. SAP stellt bekanntlich bis 2027 den Support für die bisherige Version Ihres ERP-Systems ein und zwingt Unternehmen somit dazu, auf die neue Version S/4HANA umzusteigen. So eine Transformation bringt natürlich auch weitreichende Veränderungen mit sich, die über ein IT-Projekt hinausgehen und alle Bereiche im Unternehmen betreffen. Wir wollen uns daher jetzt in einigen Folgen unseres Podcasts damit beschäftigen, wie eine Transformation gestaltet werden sollte, damit sie auf ganzer Linie erfolgreich ist. Ein Baustein für die erfolgreiche Umsetzung ist dabei auch das Projektmanagement. Dafür habe ich mir heute Till eingeladen, der Experte auf dem Gebiet Projektmanagement ist. Er wird uns dazu jetzt gleich ein paar Hintergrundinfos geben und seine Einschätzung dazu, wie ein Projektmanagement gestaltet sein muss, damit das Projekt danach auch von Erfolg gekrönt ist. Till, magst du dich einmal kurz selber vorstellen?
Till Hauser: Sehr gerne. Wie schon gesagt, mein Name ist Till Hauser, ich bin seit inzwischen gut zwei Jahren bei mgm consulting partners als Berater tätig. Meine Beratungsschwerpunkte liegen im agilen Projektmanagement und agilen Coaching, darüber hinaus im Prozessmanagement und der Organisationsentwicklung. Zuletzt habe ich für gut ein Jahr ein SAP-Projekt als agiler Coach begleitet.
Carla Tusche: Danke, das klingt auf jeden Fall schon einmal sehr spannend und als hättest du da auch schon einige Praxiserfahrungen gesammelt in dem Bereich, deshalb erzähle uns doch einmal, was ein ERP-Projekt auszeichnet und warum aus deiner Sicht ein gutes Projektmanagement bei der Einführung eines ERP-Systems essentiell wichtig ist?
Till Hauser: Bevor wir damit starten ein Projekt aufzusetzen, ist es immer wichtig, einen Blick darauf zu werfen, was der Kontext dieses Projektes ist. SAP-Projekte zeichnen einige Eigenschaften aus, die man berücksichtigen muss, bevor man das Projekt aufsetzt. Zum einen denke ich da an die hohe Komplexität der Projekte. Komplexität heißt hier nicht nur, dass die Projekte technisch sehr komplex sind, oft dann noch dadurch verschärft, dass nur wenige kritische Wissensträger in den Organisationen da sind, sondern auch prozessual komplex. Ein ERP-Projekt beschäftigt sich mit den Prozessen im Unternehmen, wir reden hier von End-to-End-Prozessen, bei denen eine Vielzahl von Stakeholdern aus unterschiedlichen Bereichen im Unternehmen betroffen sind. Dazu kommt noch, dass die Projekte wirklich kritisch sind, wir sprechen oft von Operationen am offenen Herzen, weil sie kritische IT-Systeme und Kernprozesse betreffen. Fallen hier Fehler oder Probleme an, dann haben sie oft direkte Auswirkungen auf das Tagesgeschäft und betreffen so das Unternehmen im Kern. Dazu kommt noch, dass Prozessveränderungen, wenn sie unzureichend geplant oder schlecht kommuniziert sind, massive schlechte Reaktionen der betroffenen Mitarbeiter hervorrufen und dieser Unmut das Unternehmen ebenfalls hart treffen kann.
Carla Tusche: Du hattest das gerade schon erwähnt, dass unter anderem eine Sache diese doch sehr komplexen Prozesse auszeichnet, die ist, dass eine Vielzahl an Stakeholdern betroffen ist und ich hatte es auch schon in der Einleitung gesagt, dass es wichtig ist, dass man ein Transformationsprojekt nicht nur als IT-Projekt versteht, sondern als ein Projekt, dass das ganze Unternehmen betrifft. Deswegen würde ich gerne einmal darüber sprechen wollen, welche Rollen und Bereiche im Unternehmen beteiligt sind? Kannst du uns da ein paar Hintergrundinformationen auch aus der Praxis geben? Welche Stakeholder sind üblicherweise bei der Einführung eines ERP-Systems involviert?
Till Hauser: Ja gerne. Ich hatte schon vorher erwähnt, dass viele Stakeholder betroffen sind, damit ist nicht nur gemeint, dass viele Fachbereiche betroffen sind, sondern auch die verschiedenen Säulen der Organisation oder eines Unternehmens. Zunächst kommt einem natürlich die IT in den Sinn, IT ist unglaublich wichtig, ist aber nur ein Teil des Projekts. Es kommt auf die IT an, wenn es um die Architektur des Projektes geht, die Umsetzung der Anforderungen und später Inbetriebnahme und Betrieb, aber besonders auch das Business spielt eine ungemein wichtige Rolle. Wir reden vom Business gerne als Kunden im Projekt, hier kommt dem Business die Rolle als Key-User zu, der die Anforderungen stellt, definiert und beschreibt, aber auch die Rolle als Tester, wenn Anforderungen dann umgesetzt sind und auch, was Architektur betrifft, findet hier ein Co-Design mit der IT statt. Der Organisation an sich kommt auch eine wichtige Rolle zu, da Architekturentscheidungen und Prozessentscheidungen in jedem Fall auch Strategieentscheidungen sind und zudem ein gutes Change-Management während der Veränderung des ERP-Systems sichergestellt werden muss.
Carla Tusche: Das heißt, wir haben die drei Säulen IT, Business, Business entspricht dem Fachbereich, und die Organisation, die da alle betroffen sind und die natürlich auch alle mit einbezogen werden müssen. Daran sieht man schon ganz gut, dass es sich definitiv nicht um ein reines IT-Projekt handelt, wie man vielleicht am Anfang annehmen könnte. Was siehst du, neben der Einbindung dieser ganzen Stakeholder und der Mitnahme der Mitarbeiter, noch als größte Herausforderung vielleicht auch aus Projektmanagementsicht an?
Till Hauser: Also klassische Projektmanageraufgaben, die in ERP-Projekten anfallen, sind natürlich die Priorisierung von neuen und bestehenden Anforderungen, die im Projekt umgesetzt werden sollen, also was wird wann umgesetzt. Weitere Aufgaben sind Koordination von einzelnen Aufgabenpaketen und Anforderungen zwischen Teams, natürlich das Management von Schnittstellen zwischen Teams, zwischen Systemen, wie dort Umsetzungen stattfinden und Anforderungen generiert werden, aber auch das Management von den Abhängigkeiten der Anforderungen, also in welcher Reihenfolge Anforderungen umgesetzt werden. Das Ganze wird noch dadurch verschärft, dass ständig neue Anforderungen anfallen und dass oftmals Supportaufgaben aus dem Tagesgeschäft von denselben Personen ausgeführt werden, die im Projekt mitwirken und so die Trennung von Projektaufgaben und Linienaufgaben auch noch berücksichtigt werden muss. Dazu kommt noch, dass oftmals in vielen Unternehmen ein Mangel an kritischen Businessträgern und Experten zu den SAP-Systemen besteht und diese, wie schon genannt, oft sehr ausgelastet sind mit dem Tagesgeschäft und so mit diesen Ressourcen gut geplant werden muss, dass sie sinnvoll eingesetzt werden. Dazu kommt dann auch noch eine hohe Fluktuation in Projekten, seien es Berater oder auch Teammitglieder. Hier muss immer wieder methodisch gecoacht werden und die Leute müssen in den Projekten ongeboardet werden. Eine große Herausforderung ist außerdem, dass ERP-Projekte wirklich viel Zündstoff innerhalb einer Organisation bieten und so einen guten Nährboden für Missmut innerhalb des Projektes. Neben proaktivem Change-Management und guter Kommunikation stellt sich hier dem Projektmanager die Coaching-Aufgabe, dass er sicherstellen muss, dass Rollen in Entscheidungsprozessen definiert sind, aber vor allem auch verstanden und gelebt werden und dass betroffene Bereiche zu Beteiligten des Projektes gemacht werden, sie dieses aktiv mitgestalten und so zum Projekt beitragen.
Carla Tusche: Das sind ja ganz schön viele Aspekte, also ich fasse das noch einmal ganz kurz zusammen. Das eine ist, so wie ich es verstehe, das klassische Projektmanagement, also Anforderungsmanagement, Aufgabenpakete verteilen, die Aufgaben koordinieren, Deadlines beachten et cetera. Das andere sagtest du, was immer ein großes Thema wäre, ist die Ressourcenplanung, da SAP-Experten im Unternehmen sehr gefragte Mitarbeiter sind, die oftmals nicht in dem Ausmaß verfügbar sind, wie man sie brauchen würde, das heißt also, man muss ständig wieder neu onboarden. Dann der dritte Punkt, den ich auch sehr wichtig fand ist, dass du sagst, man muss natürlich auch die Mitarbeiter mitnehmen, also im Change-Management, und eine gute Kommunikation haben, damit sich da auch alle abgeholt fühlen und das ganze Projekt mittragen in der Organisation. Nun ist SAP ja ein großer Laden, sehr, sehr viele Unternehmen weltweit nutzen SAP und die wissen um diese Tücken des Projektmanagements und der Komplexität, also würde ich vermuten, dass die auch ein Standardvorgehen haben, mit dem Projekte umgesetzt werden. Kannst du uns da einmal einen Überblick geben?
Till Hauser: Ja sehr gerne. Es gibt gewisse Standards, was die Methodik und die Tools von SAP betrifft. Genannt werden hier kann die SAP Activate Methodology, die einen groben Rahmen für SAP-Projekte vorgibt und dann als Tool, speziell für S/4HANA-Implementierung ist dann Focused Build im Solution-Manager der SAP Standard. Die Activate-Methodik basiert hier auf einem 4-Phasen-Modell. Da wäre zunächst die Prepare-Phase, unter der alle Tätigkeiten zusammengefasst sind, die die Projektinitialisierung umfassen, dann gefolgt von der Explore-Phase. In der Explore-Phase werden mithilfe von Fit-to-Standard-Workshops Anforderungen definiert, die speziell in dem Unternehmen an den Standardprozess angelehnt sind. Im Anschluss geht es in der Realize-Phase darum, die Anforderungen umzusetzen und dann in der Deploy-Phase als der vierten Phase, diese in Betrieb zu nehmen. Der grobe Rahmen von Activate hier mit diesen vier Phasen, die durchlaufen werden, ist eher klassisch als Wasserfallprojekt gedacht, kann aber auch agiler ausgestaltet werden, indem sich dann die Explore-, Realize- und Deploy-Phase zyklisch wiederholen. Focused Build für den Solution-Manager ist auf dieser Methodik basierend das SAP-Standard-Tool und bietet diverse Funktionen zur Planung, es gibt standardisierte Rollen und Abläufe, Templates für Ergebnisdokumente und Anforderungen und allgemein ein Tool zum Tracking von Anforderungen und dem aktuellen Status.
Carla Tusche: Das ist jetzt aber, so wie ich es verstehe, ein Standardvorgehen von SAP, wo man sich dann auch konkret an diese vier Phasen hält beziehungsweise mit Focused Build dann noch die Möglichkeit hat, etwas individueller auf das Unternehmen einzugehen. Jetzt ist jedes Unternehmen sehr unterschiedlich und ich denke, auch die Anforderungen, die ein Unternehmen an SAP hat, sind da sehr verschieden. Wie sind deine bisherigen Eindrücke von diesen beiden Methoden, können die dem gerecht werden? Beziehungsweise worauf ist bei der Verwendung von Activate und Focused Build in der Praxis zu achten?
Till Hauser: Generell schwierig finde ich es, bei den komplexen und innovativen Eigenschaften eines ERP-Projektes in Wasserfallprojektdurchführung zu denken. Diese Projektdurchführung setzt zugrunde, dass man sehr viel Zeit mit Detailfragen zu einzelnen Prozessausprägungen zum Beispiel zu Beginn des Projektes verbringt und hier schon ein sehr hohes Wissen vorausgesetzt wäre über die Art und Weise, wie das ERP-System genutzt werden wird, wie einzelne Prozessschritte aussehen. Hier wäre ein sehr hoher Aufwand zu Beginn des Projektes bei geringem Kenntnisstand erforderlich wäre. Natürlich müssen grundsätzliche Architekturentscheidungen wie eine Systemlandschaft aufgebaut und genutzt werden soll, früh im Projekt getroffen werden, da eine spätere Veränderung sehr aufwendig, teuer und hoch kompliziert wäre. Ich halte aber die Denkweise, jede kleinere Anforderung im Vorfeld zu kennen und planen zu können, für langsam, teuer und gar utopisch aufgrund der hohen Komplexität, daher würde ich im Regelfall immer eine hybride oder agile Herangehensweise vorschlagen. Ansonsten gibt Focused Build technisch einen ordentlichen Rahmen vor und viele Standards werden einem mit an die Hand gegeben, zu beachten ist allerdings, dass die Verwendung wirklich einen signifikanten Ressourcenaufwand nach sich zieht und ein hohes Knowhow notwendig ist, um Focused Build sinngemäß zu bedienen. Es ist daher nicht nur ein Ressourcenbedarf notwendig, sondern auch ein Coaching in den Anwendungstools. Meiner Erfahrung nach wird der Aufwand sowohl an Ressourcen als auch an Coaching in Unternehmen unterschätzt und da rede ich nicht nur von kleinen Unternehmen, sondern auch von mittelständischen und größeren Unternehmen. Daher, wenn man diese Tools einsetzen will, sollte man in jedem Fall im Vorfeld genug Zeit und gute Maßnahmen treffen, wie Mitarbeiter geschult werden, wie viele Ressourcen benötigt werden und was man in diesen Tools in welchem Umfang nutzen will.
Carla Tusche: Heißt das auch, dass die SAP-Activate-Methode gemeinsam mit Focused Build vielleicht jetzt nicht das Standardallheilmittel sein können, sondern dass man schon auf das Unternehmen noch einmal individueller schauen muss? Du hattest gerade schon erwähnt, dass auch die Activate-Methode als Wasserfallmethode doch sehr aufwendig, teuer und kompliziert sein kann, wenn dann später noch Dinge verändert werden müssen beziehungsweise vielleicht auch nicht ganz so realistisch ist, weil man nicht am Anfang schon alle Details des Projektes kennen kann und bei Focused Build auch ein hoher Schulungsaufwand erforderlich ist. Was würdest du denn als Projektmanager bei der Projektplanung besonders beachten? Hast du da Tipps für andere und wie sollte die Auswahl und Gestaltung der Projektmethodik im Einzelfall erfolgen?
Till Hauser: Wie schon gesagt, die Basis der SAP hier ist gut und das kann man so alles verwenden. Wichtig ist, auch über das Standardprozedere hinausgehende Methodiken und Herangehensweisen nachzudenken, damit zu experimentieren. Das können Design-Thinking-Workshops sein, wenn man über die Architektur redet oder während der Explore-Phase über Prozesse. Das können Customer Journeys und Service Blueprints sein, falls in dem Unternehmen noch gar kein so genaues Prozessverständnis des Ist-Prozesses da ist, um erst einmal darüber zu sprechen, bevor man über den Soll-Prozess sprechen kann. Dann geht es darum, wie werden wir uns in der Umsetzung organisieren, hier kann zum Beispiel Scrum sehr gut als Rahmenwerk genutzt werden, wie sich ein Team organisiert und in Zyklen umsetzt. Des Weiteren sollte der hohe Coaching-Aufwand wirklich beachtet werden, unabhängig von Tool und Methodik, also sowohl, wenn man Focused Build benutzt, als auch, wenn man, wie erwähnt, mit Design-Thinking, Customer Journeys, Scrum et cetera arbeitet. Dazu kommt noch, dass im Projekt hier mit Rollen gearbeitet wird, also mit den Key-Usern aus dem Fachbereich, mit den Business Process Experts, die als erste Ansprechpartner zu einzelnen Prozessen oder Prozessvarianten ausgewählt sind. Dann innerhalb der IT die Art und Weise, wie gemeinsam mit dem Business Anforderungen und Lösungswege entwickelt werden, all das muss gecoacht werden. Das Onboarding neuer Berater und Teammitglieder, Teambuilding, Einbindung von Change-Management, all das erfordert einen hohen Coaching-Aufwand. Ein klassischer fachlicher Projektbegleiter, der in erster Linie dafür da ist, das Was zu bestimmen, zu definieren, zu koordinieren und umzusetzen, ist mit all diesem Coaching-Aufwand on top schnell überlastet und überfordert. Daher wäre hier meine Empfehlung, schon früh in der Planung über ein geeignetes Coaching während der initialen Phasen wie auch während der Umsetzung nachzudenken.
Carla Tusche: Ich fasse noch einmal ganz kurz zusammen. Du sagtest, dass SAP eine gute Basis mit Activate bietet, aber du auf jeden Fall die über das Standardprozedere hinausgehenden Anforderungen mit anderen Methoden abdecken würdest. Du hattest da Design-Thinking-Workshops genannt, Scrum, Service Blueprints et cetera. Was dir auch, glaube ich, sehr wichtig ist, ist noch einmal zu betonen, dass ein sehr hoher Coaching-Aufwand besteht, dadurch dass man die Leute immer wieder onboarden muss und vielleicht auch nicht jeder sofort die richtigen Fähigkeiten mitbringt, um dieses Projekt stemmen zu können und dass das ein großer Aspekt ist, der gleich von Anfang an berücksichtigt werden sollte. Till, kannst du anhand eines konkreten Beispiels aus deiner Projekterfahrung noch einmal beschreiben, wie da auf den Unternehmenskontext reagiert wurde und welche Ansätze und Methoden im Projekt erfolgsentscheidend waren? Da kannst du doch sicher aus dem Nähkästchen plaudern?
Till Hauser: Sehr gerne. Zuletzt war ich in einem Projekt bei einem großen Handelsunternehmen tätig, das ich als agiler Coach begleitet habe. In dem Projekt, man kann es als Vorprojekt der S/4HANA-Implementierung sehen, ging es darum, einzelne SAP-Module zu aktualisieren und anbindungsfähig zu machen an die S/4HANA-Landschaft. Darüber hinaus war ich noch bei ein paar kleineren Vorprojekten ebenfalls als agiler Coach tätig. Was ich dort als Coach gelernt habe ist, dass man solche Vorprojekte wunderbar dazu nutzen kann, nicht nur fachlich up to date zu sein und anbindungsfähig, sondern auch einzelne methodische Herangehensweise zu erproben, wie zum Beispiel haben wir Customer Journeys genutzt, um Ist-Prozesse zu definieren, bevor wir dann an Soll-Prozesse uns heranwagen. Wir haben Scrum als Rahmenwerk während der Implementierung verwandt und damit sehr gute Erfahrungen gemacht, wie haben Jira und Confluence zu Dokumentation und zum Tracking von Aufgaben benutzt. All das ist sicherlich unternehmensspezifisch unterschiedlich, aber was man zusammenfassen kann ist, methodisch kann man sich weiterentwickeln und kann man lernen durch Vorprojekte oder auch innerhalb eines Projektes. Genauso sollte Methodik in Projekten betrachtet werden als Rahmenwerk, aber auch als ein Faktor, indem man sich weiterentwickeln und lernen kann. Man sollte nicht zu starr herangehen an die Projekte und an das Management der Projekte und entsprechend Freiraum lassen, um weiterzuentwickeln, wie man zusammenarbeitet und was man fachlich in diesen Projekten umsetzen möchte.
Carla Tusche: Ja danke, das klingt doch schon nach einem sehr, sehr schönen Schlusswort. Du hast an einem ganz spannenden Beispiel aus der Praxis untermauert, wie ihr da herangegangen seid, dass ihr durchaus auch diese agilen Methoden vorher in Vorprojekten ausprobiert habt und dann während des gesamten Projektes später immer weiter gelernt und euer Projektmanagement auch adaptiert und angepasst habt an die Bedürfnisse des Unternehmens. Ein sehr, sehr schönes Beispiel dafür, wie man auf Basis von SAP-Activate auch eine hybride Vorgehensweise und Methodik wählen kann. Vielen Dank für diesen sehr praktischen Einblick, Till. Ich glaube, das war auch für unsere Zuhörer noch einmal ganz interessant zu hören, wie das dann in der Praxis ablaufen kann, also danke dafür. An Sie noch einmal der Apell, wenn Sie Fragen haben zu Projektmanagement in SAP-Projekten beziehungsweise allgemein dazu, wie man eine Transformation im Rahmen von SAP erfolgreich gestaltet, dann sind wir natürlich gerne für Sie da. Schicken Sie einfach eine E-Mail an die info@mgm-cp.com und dann leiten wir diese gerne an Till oder auch an andere Kollegen weiter und sind für Sie da. Wir hoffen Sie konnten etwas mitnehmen aus dieser Folge und freuen uns darauf, Sie beim nächsten Mal wieder begrüßen zu dürfen. Bis dahin, tschüss!
