Das Leiden der Eigenentwicklungen
Unter der Version R/2, aber vor allem unter R/3 waren die Eigenentwicklungen der Kunden noch ein Teil der SAP-Strategie und hatten einen wichtigen Anteil an der Erfolgsgeschichte. SAP stellte den Kunden die notwendigen Lösungen als Standard-lösungen in Form von Modulen zur Verfügung. Alle Module waren einerseits in sich abgekapselt, aber andrerseits beim Einsatz weiterer Module untereinander voll integriert. Ein erfolgreicher Teil der Strategie war auch die Möglichkeit, die modularen Standardlösungen bei Bedarf durch Modifikationen anzupassen. Darüber hinaus war für die Kunden der größte Nutzen, die Standardlösungen auch durch Eigenentwicklungen von kundenspezifischen Anforderungen ergänzen zu können. Ein wirklich tolles Konzept für die Kunden! Diese Kombination und Integration führten SAP auch zur führenden Marktposition.
Überforderter Support
Durch das globale Wachstum an Kunden bekam SAP aber damit möglicherweise ein Problem. Die laufende Pflege und die Bereitstellung der Modifikationen wie auch die Sicherstellung der Integration der zahlreichen kundenspezifischen Eigenentwicklungen dürften den Support überfordert haben. Die Vermutung liegt nahe, dass mit S/4 durch eine Strategieanpassung das Problem gelöst werden sollte. Die neuen Applikationsplattformen Cloud, die Public Cloud und die Private Cloud sollten die bisherigen On-prem-Varianten ersetzen. So wurden die Kunden von SAP mit der breit kommunizierten Cloud-only-Strategie unter Druck gesetzt. Nur haben viele Kunden, vor allem die Bestandskunden, damit ein großes Problem bekommen – bis die DSAG zu Hilfe kam.
So wurde zwar von SAP die S/4-Strategie von Cloud only auf Cloud first geändert, aber die Kundenprobleme waren damit nicht gelöst. Die Cloud-Lösungen und die Public Cloud lassen als Standardlösungen faktisch keine kundenspezifischen Anpassungen mehr zu. Es bleibt nur mehr die Private Cloud dafür übrig, die allerdings aus der Sicht der Systemarchitektur auch nur ein eingeschränktes Outsourcing darstellt. Durch diese Situation gehen die meisten Bestandskunden den Weg der hybriden Systemlandschaften mit der bestehenden On-prem-Variante, ergänzt durch Cloud-Lösungen. Bei diesem Ansatz laufen sie aber in das Problem der noch oft fehlenden Integration.
Neben den Herausforderungen der eingeschränkten Modifikationen ist es eine riesige Aufgabe und ein enormer Aufwand, die zahlreichen Eigenentwicklungen in die S/4-Transformation mitzunehmen. Dies beginnt mit der Selektion der Zusatzentwicklungen im Hinblick darauf, was noch benötigt wird und was nicht. Vor allem werden viele Reports nach Ausscheiden von Benutzern nicht mehr verwendet. Das „Ausmisten“ der Eigenentwicklungen ist eine gute Tat, weil damit auch der Betriebsaufwand gesenkt werden kann. Gleichzeitig sollte man genau untersuchen, welche Eigenentwicklungen durch die neuen S/4-Applikationen ganz oder zumindest teilweise ersetzt werden können.
Diese Fit-Gap-Analyse ist einer der Schwerpunkte in jedem S/4-Transformationsprojekt. Das Ergebnis zeigt auch auf, welche bestehenden Eigenentwicklungen geändert werden müssen und wo neue Eigenentwicklungen notwendig sind. Die Gründe dafür sind Änderungen bei den Prozessen oder der Funktionsabgleich mit den neuen S/4-Applikationen. In vielen Projekten werden dabei aus Zeit- und Kostengründen auch Prioritäten bei der Umsetzung vorgenommen.
Auf jeden Fall müssen bei der S/4-Umstellung alle Eigenentwicklungen auf ihre technische Funktionalität überprüft werden. Gründe dafür sind die massiven Änderungen in den bestehenden Datensätzen durch die Simplifizierung wie auch technologische Änderungen in der Programmierung. SAP stellt dafür sehr gute Services und Tools zur Verfügung. Ein guter Tipp dazu aus eigener Erfahrung und aus vielen Projekten ist, dass man damit nicht früh genug anfangen kann.
