RISE with SAP: 5 kritische Herausforderungen aus der Praxis
RISE with SAP verspricht Einfachheit: eine Vertragsbeziehung, ein Ansprechpartner, ein Weg in die Cloud. Die Realität in Projekten sieht differenzierter aus. Wer RISE als reines Hosting-Modell betrachtet, unterschätzt, was er tatsächlich kauft – und welche Konsequenzen das hat.
RISE ist ein Betriebsmodell. Und genau dort entstehen die Probleme, über die in Verkaufsgesprächen selten gesprochen wird.
Dieser Artikel benennt fünf kritische Herausforderungen aus der Praxis – nicht um RISE zu verteufeln, sondern um eine informierte Entscheidung zu ermöglichen.
1. Eingeschränkte technische Kontrolle: Was man aufgibt, wenn SAP den Betrieb übernimmt
In einem klassischen On-Premise- oder selbst betriebenen Cloud-Szenario hat das eigene IT-Team direkten Zugriff auf Infrastruktur, Betriebssystem und Datenbankebene. Basis-Administratoren kennen ihre Systeme in- und auswendig, können bei Problemen direkt eingreifen und Anpassungen vornehmen.
Mit RISE ändert sich das grundlegend. SAP übernimmt den Systembetrieb – und damit auch die Kontrolle über Schichten, auf die Kunden bisher Zugriff hatten. Das bedeutet konkret:
- Kein direkter Infrastrukturzugriff: Betriebssystem, Netzwerkkonfiguration und Storage liegen in SAPs Verantwortungsbereich. Für Standardanforderungen ist das kein Problem. Für Spezialanforderungen – etwa spezifische Sicherheitsanforderungen, regulatorische Vorgaben oder besondere Integrationsarchitekturen – kann das zur echten Einschränkung werden.
- Eingeschränkte Basis-Operationen: Bestimmte administrative Aufgaben, die On-Premise selbstverständlich waren, sind in RISE nur über SAP-Support oder definierte Service-Prozesse möglich. Das erhöht die Reaktionszeiten und erfordert ein Umdenken in der eigenen IT-Organisation.
Unternehmen mit komplexen technischen Anforderungen oder hohem regulatorischen Druck sollten diesen Punkt vor Vertragsabschluss detailliert prüfen.
2. Unklare Verantwortlichkeiten: Das Drei-Parteien-Problem
RISE with SAP bedeutet in der Praxis: SAP als Vertragspartner, ein Hyperscaler (AWS, Azure oder Google Cloud) als tatsächliche Infrastrukturplattform und der Kunde als Nutzer. Drei Parteien, ein System – und bei Problemen entsteht daraus regelmäßig eine unangenehme Frage: Wer ist eigentlich zuständig?
Bei einem Performanceproblem stellt sich die Frage, ob die Ursache im SAP-Applikationscode liegt, in der Datenbankschicht, in der Infrastruktur des Hyperscalers oder im eigenen Netzwerk. Die Antwort bestimmt, wer tätig werden muss – aber bis diese Antwort vorliegt, vergeht Zeit, die in produktionskritischen Situationen fehlt.
Bei Integrationsfehlern wird es noch komplexer. Sobald Drittsysteme, eigene Middleware oder BTP-Services ins Spiel kommen, verschwimmen die Verantwortungsgrenzen weiter. SAP verweist auf die Kundenschnittstelle, der Hyperscaler auf SAP, der Kunde sitzt dazwischen.
Was in der Praxis hilft: ein klar definiertes Service-Management-Modell vor Go-Live, mit explizit vereinbarten Eskalationspfaden und SLA-Verantwortlichkeiten für genau diese Szenarien. Wer das dem Zufall überlässt, wird es im Ernstfall lernen – aber zu einem ungünstigen Zeitpunkt.
3. Kostenstruktur: Was RISE wirklich kostet
Die Preisgestaltung von RISE with SAP ist eines der am häufigsten unterschätzten Themen in der Evaluierungsphase. Auf den ersten Blick klingt das Modell attraktiv: ein Paketpreis, der Lizenz, Cloud-Infrastruktur und bestimmte Services zusammenfasst. Auf den zweiten Blick zeigt sich ein komplexeres Bild.
Schwer kalkulierbare Gesamtkosten: Der Paketpreis deckt nicht alles ab. Zusätzliche BTP-Services, Migrationsprojekte, optionale Managed Services und der eigene Transformationsaufwand kommen hinzu. Unternehmen, die nur den RISE-Listenpreis als Budgetgrundlage nehmen, erleben regelmäßig Überraschungen.
Langfristige Vertragsbindung: RISE-Verträge laufen typischerweise über mehrere Jahre. Das schränkt die Verhandlungsposition bei späteren Anpassungen ein und bedeutet, dass Einsparungseffekte, die durch technologische Entwicklungen entstehen könnten, nicht automatisch an den Kunden weitergegeben werden.
Versteckte Wechselkosten: Ein oft übersehener Kostentreiber ist der potenzielle Exit aus dem RISE-Modell. Datenmigration, technische Anpassungen und der Aufbau einer neuen Betriebsinfrastruktur können erhebliche Investitionen erfordern – auch wenn dieser Fall bei Vertragsabschluss unrealistisch erscheint.
Eine ehrliche Total-Cost-of-Ownership-Betrachtung über fünf bis sieben Jahre ist vor der RISE-Entscheidung unerlässlich.
4. Innovationsgeschwindigkeit vs. Stabilität: Der Konflikt mit Release-Zyklen
Einer der zentralen Versprechen von RISE ist der automatische Zugang zu SAP-Innovation: neue Features werden kontinuierlich bereitgestellt, ohne dass aufwändige Upgrade-Projekte notwendig sind. In der Theorie ein klarer Vorteil. In der Praxis ein zweischneidiges Schwert.
Jedes neue SAP-Release kann bestehende Prozesse, Schnittstellen oder Erweiterungen beeinflussen. In einer On-Premise-Welt hatte die IT-Abteilung die Kontrolle darüber, wann ein neues Release eingespielt wird – und damit Zeit für Tests, Kommunikation und Anpassung. In einer Managed-Cloud-Umgebung unter RISE verringert sich dieser Handlungsspielraum.
Für Unternehmen mit stabilen, hochintegrierten Prozessen und vielen Schnittstellen zu Drittsystemen ist die Frage nach der Release-Steuerung kritisch. Wer kann welche Updates wann und mit welcher Vorlaufzeit verhindern oder verschieben? Welche Testkapazitäten müssen dauerhaft vorgehalten werden, um mit der Innovationsgeschwindigkeit Schritt zu halten?
Diese organisatorischen Konsequenzen werden in RISE-Evaluierungen häufig unterschätzt.
5. Vendor Lock-in: Die strategische Abhängigkeit wächst mit jedem Jahr
Mit RISE with SAP steigt die Abhängigkeit von SAP als Technologieanbieter erheblich – und das auf mehreren Ebenen gleichzeitig: Lizenz, Infrastruktur, Support, Betrieb und Innovationspfad liegen in einer Hand. Das hat Vorteile, solange die Beziehung funktioniert. Es hat erhebliche Nachteile, wenn sich das ändern sollte.
Technologische Abhängigkeit: Je tiefer ein Unternehmen in das RISE-Ökosystem investiert – BTP-Services, SAP Integration Suite, SAP Build – desto aufwändiger wird ein späterer Wechsel zu alternativen Technologieplattformen.
Verhandlungsposition: Ein Unternehmen, das vollständig auf RISE setzt und keine realistische Exit-Option mehr hat, verliert schrittweise seine Verhandlungsposition bei Verlängerungen, Preisanpassungen und Leistungsänderungen.
Exit-Komplexität: Ein Ausstieg aus RISE ist technisch und organisatorisch aufwändig. Datenmigration, Neuaufbau der Betriebsinfrastruktur, Lizenzneuverhandlungen – all das erfordert erhebliche Ressourcen. Die Entscheidung für RISE ist deshalb keine, die man leichtfertig rückgängig machen kann.
Das bedeutet nicht, RISE zu vermeiden. Es bedeutet, die strategische Abhängigkeit bewusst einzugehen – mit einer klaren Abwägung von Nutzen und Risiko.
Fazit: RISE ist eine strategische Entscheidung, kein Standard-Einkauf
RISE with SAP ist kein „No-Brainer“. Es ist eine weitreichende strategische Entscheidung mit Konsequenzen, die über IT-Abteilungen hinausgehen und Unternehmensführung, Einkauf und Finanzplanung betreffen.
Das Modell kann für viele Unternehmen der richtige Weg sein – wenn die Anforderungen passen, die Kosten realistisch kalkuliert wurden und die Abhängigkeit bewusst und akzeptiert ist. Was es nicht ist: eine einfache Antwort auf komplexe Fragen.
Die fünf beschriebenen Herausforderungen verschwinden nicht durch Ignorieren. Sie werden handhabbar durch sorgfältige Vorbereitung, klare Vertragsgestaltung und ein realistisches Bild davon, worauf man sich einlässt.
Sie evaluieren RISE with SAP?
Wir helfen Ihnen bei einer realistischen Bewertung – jenseits der Verkaufsargumente. Von der Total-Cost-of-Ownership-Analyse über die Prüfung technischer Anforderungen bis hin zur Vertragsverhandlung begleiten wir Sie dabei, eine fundierte Entscheidung zu treffen.
Jetzt Kontakt aufnehmen und RISE with SAP unabhängig und ehrlich bewerten.
Bis bald und viel Erfolg!
Euer amotIQ solutions Team
