Warum SAP-Projekte scheitern: S/4HANA ist kein IT-Projekt

Hören Sie bitte auf, es ein IT-Projekt zu nennen.

Jedes Mal, wenn eine S/4HANA-Einführung so bezeichnet wird, denke ich an genau die Projekte, die später richtig wehgetan haben. Nicht weil die IT schlecht gearbeitet hätte. Sondern weil man ihr eine Aufgabe gegeben hat, die sie gar nicht allein lösen kann.

Was ein IT-Projekt ist, und was nicht

Ein technisches Release-Upgrade ist ein IT-Projekt. Der Umzug auf eine neue Datenbank auch, ebenso ein neues Ticketsystem oder eine modernisierte Serverlandschaft. Solche Vorhaben sind oft anspruchsvoll. Aber sie ändern nicht grundlegend, wie das Unternehmen arbeitet.

S/4HANA tut genau das. Es betrifft:

• Geschäftsprozesse. Wie geplant, produziert, eingekauft und verkauft wird.
• Rollen und Entscheidungen. Wer was entscheidet, wann und auf welcher Informationsgrundlage.
• Daten und Steuerung. Welche Kennzahlen zählen und woher sie kommen.
• Zusammenarbeit. Wer wofür Verantwortung trägt und wie transparent das ist.

Wer das auf Software reduziert, plant ein anderes Projekt als das, was tatsächlich stattfindet. Und genau diese Lücke ist einer der häufigsten Gründe, warum SAP-Projekte scheitern.

Woran Sie ein falsch aufgesetztes Projekt erkennen

Die Symptome sind fast immer dieselben. Sie zeigen sich nicht am ersten Tag, sondern nach einigen Monaten, wenn es schon teuer wird, umzusteuern.

❌ Der Fachbereich ist informiert, aber nicht beteiligt. Er bekommt Einladungen zu Workshops, aber keine Entscheidungen. Die eigentlichen Prozessfragen beantworten Berater und IT, weil sonst niemand da ist.

❌ Alte Prozesse werden eins zu eins übernommen. Copy and paste statt Neudenken. Jede Sonderlocke aus dem Altsystem findet einen Weg ins neue, weil niemand befugt ist, sie zu streichen.

❌ Projektleitung und Linie gehören verschiedenen Welten an. Die Projektleitung sitzt in der IT, die Prozessverantwortung in den Fachbereichen. Konflikte landen deshalb nicht bei denen, die sie lösen könnten.

❌ Key User arbeiten nebenbei. Sie sollen testen, schulen und entscheiden, zusätzlich zum Tagesgeschäft. Am Ende tun sie nichts davon richtig, und niemand kann es ihnen vorwerfen.

❌ Am Ende steht viel Aufwand, aber wenig messbarer Nutzen. Das System läuft. Was sich verbessert hat, kann niemand belegen, weil vorher niemand definiert hat, woran man es messen würde.

Die Liste ließe sich verlängern. Der gemeinsame Kern ist immer derselbe: Verantwortung für das Geschäft und Verantwortung für das Projekt liegen bei verschiedenen Leuten.

Warum Technik selten der Engpass ist

S/4HANA ist ausgereift. Die Werkzeuge für Konvertierung, Migration und Test sind dokumentiert und erprobt. Die Methode, SAP Activate, bringt mit den Fit-to-Standard-Workshops sogar ausdrücklich den Fachbereich ins Zentrum der Explore-Phase. Nachzulesen in der Übersicht zu SAP Activate.

Und trotzdem laufen Projekte aus dem Ruder. Weil Fit-to-Standard nur funktioniert, wenn im Raum jemand sitzt, der sagen darf: "Ja, wir arbeiten künftig nach Standard, und ich trage das in meinem Bereich durch." Fehlt diese Person, dokumentiert der Workshop Wünsche, und jeder Wunsch wird zur Anforderung.

Das eigentliche Problem ist selten fehlendes SAP-Wissen. Es fehlt ein gemeinsames Modell, wer was entscheidet.

Die Rolle, die den Unterschied macht

Wenn ich mich für eine einzige organisatorische Maßnahme entscheiden müsste, wäre es diese: Jeder Kernprozess bekommt einen Prozessverantwortlichen aus dem Fachbereich. International heißt die Rolle oft Business Process Owner.

Was diese Person tut:

• Sie verantwortet den Prozess heute und den künftigen Prozess nach dem Go-Live.
• Sie entscheidet in den Workshops, ob der Standard passt oder eine Abweichung nötig ist, und begründet Abweichungen.
• Sie gibt das Prozessdesign und die Testergebnisse fachlich frei.
• Sie trägt die Veränderung in ihren Bereich und steht für Fragen zur Verfügung, wenn es unbequem wird.

Was diese Person braucht:

• Zeit. Eine echte, eingeplante Freistellung für die Projektphasen, in denen sie gebraucht wird. Nicht "nebenbei".
• Entscheidungsrecht. Wer jede Frage erst mit dem eigenen Chef klären muss, ist ein Bote, kein Verantwortlicher.
• Rückendeckung. Ein Sponsor, der Konflikte zwischen Bereichen entscheidet, statt sie ins Projekt zurückzuspielen.

Dasselbe Prinzip gilt für die Daten. Auch dort braucht jedes Objekt einen fachlichen Eigentümer, sonst sieht der Fachbereich seine Daten zum ersten Mal kurz vor dem Go-Live. Wie das praktisch geht, steht im Artikel Datenmigration nach S/4HANA.

Change ist kein Kapitel auf Folie 37

In vielen Projektplänen läuft Change Management irgendwo zwischen Testphase und Go-Live mit. Ein Newsletter, eine Schulungswelle, eine Infoveranstaltung. Und dann wundert man sich, warum das neue System nicht so genutzt wird wie geplant.

Veränderung passiert bei Menschen, nicht im Gantt-Diagramm. Sie ist selten geordnet und fast nie bequem. Deshalb beginnt sie nicht mit Kommunikation, sondern mit Verantwortung: Wer den künftigen Prozess selbst gestaltet und freigegeben hat, verteidigt ihn auch. Wer ihn nur vorgesetzt bekommt, arbeitet um ihn herum.

Das heißt nicht, dass Schulung und Kommunikation unwichtig wären. Es heißt, dass sie wirken, wenn die Prozessverantwortlichen sie mittragen, und verpuffen, wenn sie aus dem Projektbüro kommen.

Wie Sie umsteuern, wenn das Projekt schon läuft

Nicht jedes Projekt lässt sich neu aufsetzen. Aber fast jedes lässt sich korrigieren. Drei Schritte, die ohne großen Neustart wirken:

1. Entscheidungen zählen. Wie viele offene Entscheidungen gibt es, wie alt sind sie, und bei wem liegen sie? Diese eine Liste zeigt meist schneller als jede Analyse, wo das Projekt hängt.
2. Prozessverantwortliche benennen oder nachschärfen. Mit Namen, Zeitbudget und Entscheidungsrecht. Und im Lenkungsausschuss bestätigt, damit die Rolle nicht nur auf dem Papier steht.
3. Den Nutzen definieren, den das Projekt liefern soll. Drei Kennzahlen. Wer das nicht kann, wird am Ende auch nicht sagen können, ob es sich gelohnt hat.

Wie Rollen, Entscheidungslogik und Phasen insgesamt zusammenspielen, beschreibt der Leitfaden zum S/4HANA-Projektmanagement.

Selbsttest: Läuft Ihr Projekt als IT-Projekt?

✅ Jeder Kernprozess hat einen namentlich benannten Verantwortlichen aus dem Fachbereich.

✅ Diese Personen haben eingeplante Zeit für das Projekt, nicht nur guten Willen.

✅ Abweichungen vom Standard werden fachlich begründet und von jemandem mit Entscheidungsrecht freigegeben.

✅ Im Lenkungsausschuss sitzen Fachbereich und IT, mit gleichem Gewicht.

✅ Es gibt drei Kennzahlen, an denen der Nutzen nach dem Go-Live gemessen wird.

Wenn Sie bei zwei oder mehr Punkten zögern, lohnt sich ein genauerer Blick. Je früher, desto billiger.

Häufige Fragen

Warum scheitern SAP-Projekte so oft?

Selten an der Technik. Meist daran, dass Verantwortung für das Geschäft und Verantwortung für das Projekt bei verschiedenen Leuten liegen. Dann werden Entscheidungen vertagt, Altprozesse kopiert und der Nutzen bleibt unklar.

Wer sollte ein S/4HANA-Projekt führen, die IT oder der Fachbereich?

Beide, mit klar geteilten Rollen. Die fachliche Verantwortung für Prozesse und Daten liegt im Fachbereich, die technische bei der IT. Die Projektleitung verbindet beides und braucht dafür Zugang zu beiden Seiten.

Was macht ein Business Process Owner in einem SAP-Projekt?

Er verantwortet einen Kernprozess fachlich: heute, im neuen Design und nach dem Go-Live. Er entscheidet über Abweichungen vom Standard, gibt Prozessdesign und Tests frei und trägt die Veränderung in seinen Bereich.

Kann ein laufendes Projekt noch umgesteuert werden?

Fast immer. Der schnellste Einstieg ist eine ehrliche Liste offener Entscheidungen, die Benennung von Prozessverantwortlichen mit Zeit und Entscheidungsrecht und eine klare Definition des Nutzens.

Ihr Projekt läuft, aber es fühlt sich an wie ein IT-Projekt? Das lässt sich in einem Gespräch meist schnell einordnen. Mohr Consulting übernimmt die Steuerung von SAP-Projekten oder coacht Ihre eigenen Leute dabei. Einen Überblick gibt unser Angebot.

Termin buchen