None

Das Management entscheidet über SAP-Erfolg oder -Misserfolg

Am Anfang jedes SAP-Projekts steht die Frage, welches Unternehmen künftig entstehen soll. Erst daraus ergeben sich Architektur, Prozesse, Datenmodell, Governance und letztlich auch die technische Umsetzung.PeopleImages.com – Yuri A / Shutterstock



Wer die Ursachen gescheiterter SAP-Programme analysiert, hört fast immer dieselben Erklärungen. Die Technologie sei zu komplex gewesen. Die Anforderungen hätten sich ständig verändert. Die Datenqualität habe nicht ausgereicht. Oder die Implementierungspartner hätten ihre Zusagen nicht eingehalten.



Diese Erklärungen sind nicht falsch. Sie greifen jedoch zu kurz. Nach mehr als dreißig Jahren in internationalen SAP-Programmen komme ich immer wieder zum selben Ergebnis: SAP-Programme scheitern nur selten an SAP. Sie scheitern an Management-Entscheidungen.



Warum Technologie häufig als Ursache gilt



ERP-Systeme bilden heute das digitale Rückgrat von Unternehmen. Mit Cloud, künstlicher Intelligenz (KI), Automatisierung und Echtzeitverarbeitung wachsen ihre Möglichkeiten ebenso wie ihre Komplexität. Gerade diese Entwicklung kann leicht zu der Annahme führen, die Technologie selbst sei die eigentliche Ursache für Projektprobleme.



Tatsächlich ist Technologie meist nur der sichtbare Teil des Problems. Die eigentlichen Ursachen entstehen lange vor dem Projektbeginn – bei der Definition der Ziele, der Priorisierung von Anforderungen, der Governance, der Programmorganisation und der Bereitschaft, konsequente Entscheidungen zu treffen.



Natürlich sind Diskussionen über Cloud-Strategien, Datenmigration oder Testkonzepte ebenfalls wichtig. Sie lenken jedoch häufig vom eigentlichen Problem ab. Technologie macht Management-Probleme sichtbar – sie verursacht sie nicht.



Die entscheidenden Management-Entscheidungen



Ein SAP-Programm beginnt nicht mit der Systemauswahl und nicht mit dem Projektauftrag. Am Anfang steht die Frage, welches Unternehmen künftig entstehen soll. Erst daraus ergeben sich Architektur, Prozesse, Datenmodell, Governance und letztlich auch die technische Umsetzung.



Wer diese Reihenfolge umdreht, überträgt strategische Entscheidungen ungewollt auf Projektteams oder Implementierungspartner. Aus Management-Fragen werden so technische Diskussionen, aus Zielbildern Anforderungskataloge. Und das Programm verliert seine Richtung.



Genau dieses Muster begegnet mir immer wieder. Über Zielarchitekturen, Implementierungsansätze oder Prozessstandards wird früh und intensiv diskutiert. Gleichzeitig bleiben die eigentlichen Management-Fragen unbeantwortet. Etwa:




Welches Ziel verfolgt das Unternehmen?



Welche Veränderungen sind gewollt?



Welche Prioritäten gelten, wenn Zielkonflikte entstehen?




Solange diese Fragen offenbleiben, treffen Projektteams zwangsläufig Entscheidungen, die eigentlich dem Management vorbehalten sind.



Die teuersten Fehler entstehen vor Projektbeginn



In vielen Programmen wird erheblicher Aufwand in Projektpläne, Methoden und Werkzeuge investiert. Deutlich weniger Aufmerksamkeit erhält die Phase davor. Dabei werden gerade hier die Weichen gestellt, die später kaum noch zu korrigieren sind.



Unklare Zielbilder, fehlende Governance, unzureichende Enterprise Architecture, mangelnde Transparenz über Prozesse und Daten oder nicht definierte Verantwortlichkeiten begleiten ein Programm oft über seine gesamte Laufzeit. Technologie kann diese Defizite nicht kompensieren.



Ich erlebe häufig, dass die eigentliche Projektarbeit beginnt, obwohl die grundlegenden Management-Entscheidungen noch ausstehen. Das Projektteam startet mit Workshops, Requirements und Systemdesign, während Zielbild, Verantwortlichkeiten oder Governance noch diskutiert werden. Was zu Beginn nicht entschieden wird, muss später unter Zeitdruck nachgeholt werden – meist mit deutlich höheren Kosten.


“Management-Entscheidungen werden selten dadurch besser, dass sie später getroffen werden. Sie werden lediglich teurer.” Dr. Lukas Röhrs, Interim Executive, Programme Lead und Enterprise Architect mit mehr als 25 Jahren Erfahrung in internationalen SAP- und Transformationsprogrammen.Lukas Röhrs







Governance ist kein Verwaltungsinstrument



Mit jeder vertagten Entscheidung sinkt der Handlungsspielraum. Entscheidungen, die zu Beginn eines Programms noch offen sind, müssen später unter Zeitdruck und während einer laufenden Implementierung getroffen werden.



Governance bedeutet weit mehr als Gremien und Statusberichte. Sie schafft Entscheidungsfähigkeit und damit die Voraussetzung, Komplexität beherrschbar zu halten.



Wo Entscheidungen ausbleiben oder immer wieder vertagt werden, wächst die Komplexität mit jeder Projektphase. Gute Governance schafft deshalb nicht mehr Bürokratie. Sie schafft Klarheit über Verantwortung, Prioritäten und Entscheidungswege.



Erfolgreiche Programme unterscheiden sich nur selten technisch



In erfolgreichen Programmen ist SAP nicht weniger komplex. Die Systeme sind nicht einfacher. Auch die technischen Herausforderungen unterscheiden sich kaum. Der Unterschied liegt im Management.



Erfolgreiche Programme verfügen über ein klares Zielbild, eindeutige Verantwortlichkeiten und eine belastbare Governance.  und die Bereitschaft, Entscheidungen konsequent zu treffen. Sie verstehen Technologie als Mittel zum Zweck und nicht als Selbstzweck.



Projektteams treffen selten schlechte Entscheidungen. Häufig treffen sie Entscheidungen, weil niemand anders sie trifft.



Fazit



SAP entwickelt sich kontinuierlich weiter. Cloud, KI und Automatisierung werden die technologischen Möglichkeiten weiter verändern. Die eigentliche Management-Aufgabe bleibt jedoch dieselbe.



Die erfolgreichsten Programme, die ich begleiten durfte, zeichneten sich nicht durch die beste Technologie aus. Sie zeichneten sich dadurch aus, dass die entscheidenden Management-Entscheidungen früh getroffen, konsequent umgesetzt und auch unter Druck nicht wieder infrage gestellt wurden.



Oder zusammengefasst: SAP ist die Plattform. Über den Erfolg entscheidet das Management. (mb)