S/4HANA-Projektmanagement: So setzen Sie das Projekt richtig auf

Die meisten S/4HANA-Projekte werden nicht schlecht umgesetzt. Sie werden schlecht aufgesetzt. Gutes S/4HANA-Projektmanagement beginnt deshalb lange vor dem ersten Customizing. Wenn Kick-off, Berater und System schon da sind, aber niemand sagen kann, wer eine Scope-Entscheidung trifft, ist das kein Start. Das ist ein Termin.

Warum die ersten Wochen mehr wiegen als die letzten

Ich erlebe das in fast jedem Programm. Der Lenkungsausschuss nickt ein Zielbild ab, das auf eine Folie passt. Sechs Monate später stellt sich heraus, dass Vertrieb, Produktion und IT drei verschiedene Projekte genehmigt haben. Das holt man nicht mit einem strafferen Plan ein. Das holt man nur mit einer Korrektur ein, und die ist teuer, weil bis dahin schon gebaut wurde.

Deshalb ist die langweilige Arbeit am Anfang die wichtigste. Wer eine Woche länger über Ziel, Scope und Verantwortung spricht, spart sich später Monate an Umwegen. Das klingt nach Binsenweisheit. In der Praxis verliert diese Woche fast immer gegen den Wunsch, endlich anzufangen.

Ob Sie überhaupt jetzt starten müssen, hängt am Wartungsende. Was 2027, 2030 und 2033 konkret bedeuten, steht im Artikel SAP-Wartungsende 2027: welche Zahl für Sie gilt.

Zielbild: eine Seite, kein Foliensatz

Ein brauchbares Zielbild beantwortet drei Fragen, und zwar so, dass jemand aus dem Fachbereich sie versteht.

Was soll nach dem Go-Live anders sein als heute? Nicht "wir sind auf S/4HANA". Sondern: Welche Prozesse laufen anders, welche Kennzahl verbessert sich, welcher Aufwand fällt weg. Wenn Sie das nicht benennen können, können Sie später auch nicht belegen, dass das Projekt etwas gebracht hat.

Was bleibt ausdrücklich, wie es ist? Ein Projekt ohne Negativliste wächst. Jede Abteilung bringt ihren Wunsch mit, und weil niemand gesagt hat, was nicht dazugehört, ist jeder Wunsch verhandelbar. Genau dort entstehen die Zusatzaufwände, die am Schluss niemand bestellt haben will.

Woran erkennen Sie in zwei Jahren, dass es sich gelohnt hat? Drei Kennzahlen reichen. Mehr misst hinterher niemand.

Scope: die Grenze ist die Leistung

S/4HANA reizt dazu, alles mitzunehmen. Neues Lager, neue Planung, neues Berichtswesen, aufgeräumte Prozesse, und zwar in einem Zug. Jedes dieser Themen ist für sich richtig. Zusammen werden sie unbeherrschbar.

Die ehrlichere Frage lautet: Was muss zum ersten Go-Live fertig sein, damit das Geschäft läuft, und was kann danach kommen? Diese Trennung ist keine technische Frage. Sie ist eine Geschäftsfrage, und sie gehört in den Lenkungsausschuss, nicht in einen Workshop der Teilprojektleiter.

Zwei Faustregeln, die sich bewähren:

• Eigenentwicklungen werden einzeln begründet, nicht pauschal übernommen. Was seit Jahren niemand mehr aufgerufen hat, wandert nicht mit.
• "Das haben wir immer so gemacht" ist kein Anforderungsgrund. Es ist ein Anlass, nach dem eigentlichen Grund zu fragen.

Wer entscheidet was: der Lenkungsausschuss und seine Regeln

Projekte scheitern selten an fehlendem SAP-Wissen. Sie scheitern daran, dass Entscheidungen niemand gehört. Das sieht dann so aus: Eine Frage wird im Arbeitskreis besprochen, im Teilprojekt vertagt, im Lenkungsausschuss "mitgenommen" und drei Wochen später erneut besprochen. In der Zwischenzeit hat das Team entweder auf Verdacht gebaut oder gewartet. Beides kostet.

Eine schlanke Entscheidungslogik genügt:

Der letzte Punkt reibt sich. Gremien fühlen sich sicherer an, weil niemand allein dasteht. Genau das ist das Problem. Wenn alle entscheiden, entscheidet niemand, und am Freitagabend vor dem Go-Live geht das Projekt live, weil keiner der sein will, der es stoppt. Wie Sie die Kriterien dafür vorher festlegen, steht im Artikel Hypercare und Go-Live.

Die Rollen, auf die es ankommt

Ein Organigramm mit vierzig Kästchen braucht niemand. Fünf Rollen entscheiden darüber, ob das Projekt führbar ist.

Sponsoren mit Zeit, nicht nur mit Titel. Der Sponsor gibt dem Projekt im eigenen Vorstand Rückhalt und entscheidet Zielkonflikte. Wer diese Rolle an eine Stabsstelle delegiert, hat keinen Sponsor. Er hat einen weiteren Teilnehmer.

Eine Projektleitung, die übersetzt. Zwischen Fachbereich, IT und den externen Partnern spricht niemand von allein dieselbe Sprache. Die Projektleitung dolmetscht, hält offene Punkte sichtbar und besteht auf Entscheidungen. Sie muss nicht jedes Modul können. Sie muss merken, wenn ein Thema keinen Eigentümer hat.

Prozessverantwortliche aus dem Fachbereich. Pro Kernprozess eine Person, die den Prozess heute verantwortet und den künftigen Prozess fachlich freigibt. Nicht die IT, nicht der Berater. Warum das so oft schiefläuft und wie die Rolle sauber geschnitten wird, beschreibt S/4HANA ist kein IT-Projekt.

Datenverantwortliche, ebenfalls aus dem Fachbereich. Jedes Datenobjekt braucht jemanden, der für dessen Qualität geradesteht. Ohne diese Rolle wird die Migration zur technischen Übung, und der Fachbereich sieht seine Daten zum ersten Mal zwei Wochen vor dem Go-Live. Das Muster und ein konkretes Vorgehen stehen in Datenmigration in S/4HANA.

Ein Lenkungsausschuss, der entscheidet. Klein halten. Wer nur informiert werden möchte, bekommt das Protokoll. Im Raum sitzen die Leute, die Ziel, Geld und Scope ändern dürfen.

SAP-Projektphasen: Activate nutzen, nicht nachbeten

SAP Activate gliedert ein Projekt in sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run. Das ist als gemeinsames Gerüst hilfreich, weil Berater, IT und Fachbereich damit dieselben Begriffe benutzen. Die offizielle Übersicht steht bei SAP Activate.

Was Activate nicht tut: entscheiden. Die Phasen sagen, wann ein Qualitätstor fällig ist. Sie sagen nicht, wer es aufhält, wenn der Inhalt nicht trägt. Drei Stellen lohnen besondere Aufmerksamkeit.

Explore. In den Fit-to-Standard-Workshops fällt, ob Sie den Standard nutzen oder ihn nachbauen. Wer diese Workshops mit den falschen Leuten besetzt, also ohne die Personen, die den Prozess täglich verantworten, dokumentiert Wünsche statt Entscheidungen.

Realize. Hier wird gebaut und getestet. Achten Sie darauf, dass Tests vom Fachbereich abgenommen werden und nicht nur technisch durchlaufen. Ein grüner Testbericht ohne fachliche Abnahme ist eine Ampel, keine Aussage.

Deploy. Cutover, Go-Live und die Hypercare-Phase liegen hier. Die Hypercare gehört noch zum Projekt, nicht zum Betrieb. Wer sie aus dem Projektplan streicht, um früher "fertig" zu sein, verschiebt die Instabilität in den Alltag.

Planung, die man steuern kann

Ein Plan ist kein Versprechen. Er ist die Liste der Annahmen, unter denen das Versprechen gilt. Sobald eine Annahme kippt, muss der Plan sich ändern, und zwar sichtbar.

Dafür reichen wenige Regeln:

• Meilensteine hängen an Ergebnissen, nicht an Terminen. "Fit-to-Standard abgeschlossen" heißt: die offenen Punkte sind entschieden oder terminiert. Nicht: der Workshop hat stattgefunden.
• Abhängigkeiten stehen im Plan, nicht in den Köpfen. Vor allem die zwischen Daten, Tests und Cutover.
• Puffer liegt auf dem kritischen Pfad und gehört dem Projekt. Wer ihn verteilt, verschenkt ihn.
• Änderungen am Scope werden mit ihrer Auswirkung auf Termin und Aufwand entschieden. Eine Änderung ohne Konsequenz ist keine Entscheidung, sondern ein Gefallen.

Und das Berichtswesen: eine Seite. Stand, drei Risiken, Entscheidungen, die diese Runde braucht. Wenn ein Bericht nur noch grüne Ampeln zeigt, bildet er nicht das Projekt ab, sondern die Stimmung, die sich das Team zutraut. Ampeln ohne Zahl und ohne Konsequenz kann man sich sparen.

Risiken, die man ausspricht

Jedes S/4HANA-Projekt trägt dieselben Risiken. Sie werden nur unterschiedlich ehrlich benannt.

• Der Fachbereich hat keine Zeit, weil das Tagesgeschäft vorgeht.
• Die Datenqualität ist schlechter als angenommen.
• Eigenentwicklungen stellen sich als geschäftskritisch heraus, obwohl sie niemand mehr erklären kann.
• Der Implementierungspartner und die Projektleitung steuern in verschiedene Richtungen.
• Entscheidungen dauern länger als die Arbeit, die an ihnen hängt.

Keines davon ist ungewöhnlich. Ungewöhnlich ist, sie mit einem Eigentümer, einem Termin und einer Ausweichlösung zu versehen. Ein Risiko ohne diese drei Dinge ist ein Gesprächsthema.

SAP-Projektleitung: wer das Projekt steuert

Umsetzung und Steuerung gehören auseinander. Der Implementierungspartner wird dafür bezahlt, das System aufzubauen. Dieselbe Partei sollte nicht gleichzeitig bewerten, ob Scope, Tempo und Qualität in Ihrem Interesse liegen. Das ist kein Misstrauen. Das ist eine saubere Rollenaufteilung, wie sie bei Bauvorhaben seit Jahrzehnten üblich ist und bei Softwareprojekten dieser Größe erstaunlich selten.

Was eine externe Projektsteuerung konkret beiträgt: eine Entscheidungslogik, die hält, ein Berichtswesen, dem der Lenkungsausschuss glauben kann, und jemanden, der die unbequeme Frage stellt, solange sie noch billig ist. Genau das ist der Kern des Angebots von Mohr Consulting: operative Steuerung, methodischer Rahmen und Coaching der eigenen Leute, damit das Wissen im Haus bleibt.

Wie sich das über die ganze Laufzeit verteilt, fasst unser Whitepaper zur S/4HANA-Transformation zusammen.

Die fünf Fragen vor dem Kick-off

Wenn Sie auf alle fünf eine schriftliche Antwort haben, ist das Projekt aufgesetzt. Wenn nicht, ist ein Kick-off verfrüht.

1. Was ist nach dem Go-Live anders, und woran messen wir das?
2. Was gehört ausdrücklich nicht zum ersten Go-Live?
3. Wer entscheidet Scope, Termin und Go/No-Go, und in welcher Frist?
4. Wer verantwortet die Kernprozesse und die zentralen Datenobjekte, mit Namen?
5. Welche Annahme würde uns zwingen, den Plan offen zu korrigieren?

Häufige Fragen

Wie lange dauert ein S/4HANA-Projekt?

Das hängt von Umfang, Ausgangssystem und davon ab, wie viel sich fachlich ändern soll. Seriös wird die Antwort erst nach der Bestandsaufnahme. Misstrauen Sie Zusagen, die vor dieser Aufnahme einen festen Termin nennen.

Brauchen wir SAP Activate?

Als gemeinsame Sprache ja. Als Ersatz für Zielbild, Rollen und Entscheidungslogik nein. Activate sagt, was in welcher Phase ansteht. Es sagt nicht, wer bei Ihnen entscheidet.

Reicht ein interner Projektleiter?

Oft ja, wenn die Person den Rücken frei hat und schon ein Projekt dieser Größe geführt hat. Schwierig wird es, wenn sie das Projekt neben der Linienaufgabe machen soll oder wenn niemand im Haus die externen Partner einordnen kann. Dann lohnt sich Verstärkung für die Steuerung, nicht für noch mehr Umsetzung.

Was ist der häufigste Fehler am Anfang?

Der Fachbereich wird informiert statt beteiligt. Wer die künftigen Prozesse nicht selbst verantwortet, wird sie später nicht verteidigen. Und nicht nutzen.

Sie setzen gerade ein S/4HANA-Projekt auf oder merken, dass die Steuerung nicht trägt? In einem Erstgespräch lässt sich meist schnell sagen, wo es hakt und was davon vor dem Kick-off noch zu klären ist.

Termin buchen

Über den Autor

Michael Mohr ist Geschäftsführer der Mohr Consulting & Management GmbH und seit 2010 in SAP-Projekten, zunächst als Produktionsberater, später in der Projekt- und Programmleitung. Mohr Consulting steuert SAP-Projekte, von der Methode bis zum Go-Live. Profil auf LinkedIn.