
Publikation
Blog Post


In den meisten SAP-Transformationen passiert genau das Gegenteil.
Zuerst werden Budget, Scope und Go-Live-Termine festgelegt.
Gemessen wird erst später – wenn die Migration bereits läuft.
Dabei lässt sich die Reihenfolge deutlich sinnvoller gestalten.
Warum Fakten vor Entscheidungen kommen sollten
Wer zuerst misst, ersetzt Annahmen durch belastbare Daten.
Nicht:
„Der Prozess läuft wie dokumentiert.“
Sondern:
Diese Prozessvarianten werden tatsächlich genutzt.
Nicht:
„Die Eigenentwicklungen brauchen wir vermutlich.“
Sondern:
Diese Eigenentwicklungen werden aktiv genutzt – und diese seit Jahren nicht mehr.
Nicht:
„Der Umfang der Migration steht fest.“
Sondern:
Dieser Anteil des Systems wird tatsächlich verwendet und rechtfertigt den Scope.
Die Realität sieht oft anders aus
Aus über 2.200 analysierten SAP-Systemen zeigt sich immer wieder dasselbe Muster:
Ein erheblicher Teil dessen, was zu Beginn einer Transformation als unverzichtbar gilt, hält einer objektiven Analyse nicht stand.
Programme, Prozesse und Eigenentwicklungen, die als geschäftskritisch gelten, werden teilweise kaum oder gar nicht genutzt.
Dadurch verändert sich häufig der tatsächliche Transformationsumfang.
Und zwar deutlich.
Die bekannte Lücke verschwindet nicht
Die Abweichung zwischen Annahme und Realität bleibt bestehen.
Oft sprechen wir von 30 bis 60 Prozent Unterschied zwischen dem vermuteten und dem tatsächlichen Zustand eines Systems.
Der entscheidende Unterschied ist jedoch:
Wird diese Lücke früh erkannt oder erst spät?
Im Plan oder in der Eskalation
Wird eine Abweichung früh sichtbar, landet sie im Projektplan.
Wird sie spät sichtbar, landet sie in:
• Change Requests
• Budgetdiskussionen
• Terminverschiebungen
• Eskalationen
Es bleibt dieselbe Information.
Aber die Auswirkungen sind völlig unterschiedlich.
Die teuersten Überraschungen sind die, die niemand eingeplant hat
Eine bekannte Abweichung ist planbar.
Eine unbekannte Abweichung wird teuer.
Deshalb entsteht echter Mehrwert nicht durch mehr Annahmen oder zusätzliche Workshops.
Sondern durch eine belastbare Faktenbasis vor der Entscheidung.
Decision Intelligence für SAP-Transformation
Genau dafür braucht es eine Ebene zwischen Systemrealität und Managemententscheidung.
Eine Ebene, die sichtbar macht:
• was tatsächlich genutzt wird
• welche Eigenentwicklungen relevant sind
• wo Standardisierung möglich ist
• welche Risiken und Potenziale wirklich existieren
Wir nennen diese Ebene den Decision Intelligence Layer.
Unabhängig.
Read-only.
Ohne Implementierungsinteresse.
Ohne Lizenzinteresse.
Klarsicht statt Blindflug.
👉 Wenn Sie vor einer SAP-Transformation stehen, lohnt sich eine einfache Frage: Treffen Sie Ihre Entscheidungen bereits auf Faktenbasis – oder noch auf Annahmen? Schreiben Sie mir gerne für einen Austausch.





