RISE with SAP: SAP-Basis-Aufgaben, Verantwortlichkeiten und typische Lücken

Wer übernimmt bei RISE with SAP welche SAP-Basis-Aufgaben? Der Überblick zeigt Verantwortlichkeiten, typische Betriebslücken und sinnvolle Rollen für SAP, Kunde und Partner.

RISE with SAP nimmt Unternehmen viele klassische Infrastruktur- und SAP-Basis-Aufgaben ab. Es nimmt ihnen jedoch nicht die Verantwortung für einen funktionierenden SAP-Betrieb.

Mit SAP S/4HANA Cloud Private Edition verschiebt sich der Leistungsschnitt: SAP übernimmt große Teile der verwalteten Infrastruktur sowie definierte technische Betriebsaufgaben. Gleichzeitig bleiben zahlreiche Aufgaben auf Anwendungs-, Prozess- und Governance-Ebene beim Kunden – oder müssen durch einen SAP-Partner abgedeckt werden.

Genau hier entsteht in vielen RISE-Projekten Unsicherheit: Wer überwacht die Schnittstellen? Wer steuert Transporte? Wer analysiert Performance-Probleme? Wer pflegt Berechtigungen? Wer koordiniert SAP bei Incidents? Und wer stellt sicher, dass ein technisch erfolgreiches Upgrade auch fachlich funktioniert?

Die Antwort steht nicht in einem einfachen Satz wie „SAP übernimmt die Basis“. Sie ergibt sich aus dem vertraglichen Roles-&-Responsibilities-Modell und dem konkret vereinbarten Serviceumfang.

SAP selbst weist darauf hin, dass auch in SAP S/4HANA Cloud Private Edition technische und administrative Aufgaben beim Kunden verbleiben und weiterhin Ressourcen für die Systemadministration erforderlich sind.

Das Wichtigste in Kürze

• RISE with SAP ersetzt kein SAP-Basis-Team vollständig, sondern verändert dessen Aufgaben.
• SAP übernimmt insbesondere viele Aufgaben auf Infrastruktur-, Betriebssystem-, Datenbank- und technischer Plattformebene.
• Anwendungen, Geschäftsprozesse, Custom Code, fachliche Tests und zahlreiche kundenindividuelle Betriebsaufgaben bleiben weiterhin in Kundenverantwortung.
• Viele Tätigkeiten können entweder vom Kunden beziehungsweise seinem Partner ausgeführt oder als SAP Cloud Application Services (CAS) zusätzlich bezogen werden.
• SAP unterscheidet im R&R-Modell zwischen Standard Services, Optional Services, Additional Services, Cloud Application Services und Excluded Tasks.
• Technisches Systemmonitoring durch SAP bedeutet nicht automatisch End-to-End-, Anwendungs-, Integrations- oder Business-Process-Monitoring.
• Die Rolle von SAP Basis verschiebt sich von Hands-on-Infrastrukturarbeit zunehmend zu Governance, Koordination, Monitoring, Changes, Releases, Security und Providersteuerung.
• Entscheidend ist nicht nur, wer eine Aufgabe technisch ausführt, sondern auch, wer sie plant, auslöst, genehmigt, überwacht und fachlich abnimmt.

Was ändert sich bei SAP Basis mit RISE with SAP?

In einer klassischen On-Premise-Landschaft liegt ein großer Teil des technischen SAP-Betriebs beim Unternehmen selbst oder bei dessen Managed-Service-Provider.

Das Basis-Team kümmert sich beispielsweise um Betriebssystem, Datenbank, SAP Kernel, Backups, Systemkopien, Monitoring, Transporte, Patches und technische Störungen.

Mit SAP S/4HANA Cloud Private Edition verschiebt sich dieses Modell.

SAP Enterprise Cloud Services übernimmt einen wesentlichen Teil der Infrastruktur- und technischen Administrationsaufgaben. SAP beschreibt die grundlegende Trennung so: Anwendung und Business-Funktionalität liegen grundsätzlich auf Kundenseite, während ECS den überwiegenden Teil von Infrastruktur und technischer Administration übernimmt.

Das bedeutet jedoch nicht:

On-Premise: Kunde macht SAP Basis → RISE: SAP macht SAP Basis.

Treffender ist:

On-Premise: Kunde oder Provider führt viele Aufgaben selbst aus → RISE: Ausführung und Verantwortung werden auf SAP, Kunde und gegebenenfalls SAP-Partner verteilt.

Und diese Verteilung kann je nach Aufgabe unterschiedlich aussehen.

Wer definiert die Verantwortlichkeiten bei RISE with SAP?

Die wichtigste Grundlage ist das Roles & Responsibilities Document, häufig kurz R&R genannt.

Dieses Dokument beschreibt auf Aufgabenebene, welche Services SAP im Standard erbringt und welche Tätigkeiten nicht zum Standardumfang gehören.

SAP veröffentlicht diese Dokumentation für SAP Cloud ERP Private beziehungsweise SAP S/4HANA Cloud Private Edition und aktualisiert sie regelmäßig. SAP Learning zufolge erfolgt typischerweise eine größere Aktualisierung zu Beginn des dritten Quartals und eine kleinere Korrektur gegen Ende des ersten Quartals. Auf dem offiziellen SAP-Dokumentationsportal werden aktuell bereits Versionen v.7-2026 geführt.

Für ein konkretes Unternehmen gilt jedoch immer die für den eigenen Vertrag relevante Version und der tatsächlich bestellte Serviceumfang.

Deshalb sollte eine RACI- oder Betriebsverantwortungsmatrix niemals allein auf Grundlage eines Blogartikels erstellt werden.

Die fünf Servicekategorien im RISE-R&R-Modell

Um zu verstehen, wo Betriebslücken entstehen können, muss zunächst klar sein, was die verschiedenen Servicekategorien bedeuten.

SAP stellt ausdrücklich klar, dass nicht bestellte und nicht als Standardleistung von SAP erbrachte Tätigkeiten beim Kunden verbleiben, sofern sie für dessen Umgebung erforderlich sind.

Gerade die Unterscheidung zwischen Standard Service und CAS ist für das Betriebsmodell entscheidend.

Eine Tätigkeit kann im R&R-Dokument stehen und trotzdem nicht automatisch im RISE-Standardpreis enthalten sein.

SAP Basis bei On-Premise und RISE with SAP: Wer macht was?

Die folgende Matrix zeigt eine typische Einordnung wichtiger Betriebsaufgaben.

Sie ersetzt ausdrücklich nicht die vertragliche R&R-Matrix. Der genaue Scope hängt unter anderem vom Vertrag, der RISE-Variante, der eingesetzten Infrastruktur, zusätzlichen CAS-Paketen und der jeweiligen Kundenlandschaft ab.

Diese Trennung ist der Kern des RISE-Betriebsmodells.

1. Infrastruktur und Betriebssystem: SAP übernimmt viel – aber nicht die Steuerung

Eine der deutlichsten Veränderungen betrifft Infrastruktur und Betriebssystem.

Bei verwalteten SAP-Systemen erhält der Kunde grundsätzlich keinen direkten Betriebssystemzugriff auf die Managed Server. SAP beschreibt stattdessen ein Modell, bei dem der Provider notwendige Betriebssystemaufgaben übernimmt oder alternative Ausführungsmöglichkeiten bereitstellt.

Für ein klassisches Basis-Team verändert sich damit der Arbeitsablauf.

Früher:

Problem erkennen → auf Server anmelden → analysieren → Änderung durchführen

Unter RISE kann daraus werden:

Problem erkennen → Ursache eingrenzen → Service Request erstellen → SAP koordinieren → Umsetzung überwachen → Ergebnis validieren

Die technische Kompetenz verschwindet also nicht.

Sie wird benötigt, um überhaupt beurteilen zu können, welche technische Aktion erforderlich ist und wie sie gegenüber SAP spezifiziert werden muss.

2. SAP HANA und Backups: Ausführung und Verantwortung sind nicht dasselbe

Viele grundlegende SAP-HANA-Operationen gehören zum verwalteten technischen Scope.

In der veröffentlichten R&R-Dokumentation werden beispielsweise normale HANA-Voll- und Logsicherungen sowie die technische Wiederherstellung nach bestimmten Problemen als Standardleistungen geführt.

Für das Unternehmen bleiben trotzdem wichtige Entscheidungen bestehen.

Es muss beispielsweise wissen, welche Business-Anforderungen an Recovery bestehen, welche Abhängigkeiten nach einem Restore geprüft werden müssen und wann ein System aus fachlicher Sicht wieder produktionsbereit ist.

Die technische Durchführung eines Backups beantwortet nicht automatisch die Frage:

Kann unser kritischer Geschäftsprozess nach einem Ausfall innerhalb der geforderten Zeit wieder vollständig betrieben werden?

3. Monitoring: SAP überwacht das System – aber nicht automatisch Ihren Geschäftsprozess

Dies ist eine der wichtigsten möglichen Lücken.

Die R&R-Dokumentation unterscheidet deutlich zwischen verschiedenen Monitoring-Ebenen.

Die Überwachung der SAP-Systemverfügbarkeit und kritischer technischer Systemzustände ist im beschriebenen technischen Scope als Standardservice vorgesehen. Das Monitoring kritischer Geschäftstransaktionen kann dagegen als CAS beziehungsweise Kundenaufgabe eingeordnet sein.

Das bedeutet:

Ein System kann aus Sicht der technischen Infrastruktur grün sein, während ein wichtiger Business-Prozess trotzdem nicht funktioniert.

Beispiel:

SAP S/4HANA läuft.
SAP HANA läuft.
Die Infrastruktur ist verfügbar.

Aber:

Eine Integration zu SAP SuccessFactors ist fehlgeschlagen.
Ein kritischer Batch Job hängt.
IDocs werden nicht verarbeitet.
Eine Rechnung kann nicht gebucht werden.

Deshalb sollte ein RISE-Betriebsmodell zwischen mindestens drei Ebenen unterscheiden:

Infrastructure Monitoring → SAP System Monitoring → Application & Business Process Monitoring

Wer die dritte Ebene übernimmt, muss ausdrücklich definiert werden.

[Interner Link: SAP Monitoring – Cloud ALM, Solution Manager, Focused Run und CCMS im Vergleich]

4. Schnittstellen bleiben eine typische Verantwortungsgrenze

Moderne S/4HANA-Landschaften sind stark integriert.

SAP S/4HANA kommuniziert beispielsweise mit SAP BTP, Integration Suite, SuccessFactors, Ariba, Logistiksystemen, Banken, MES, Data Platforms oder Non-SAP-Anwendungen.

Die technische Verfügbarkeit jedes einzelnen Systems garantiert nicht, dass der End-to-End-Datenfluss funktioniert.

In der R&R-Dokumentation werden Konfiguration und Überwachung verschiedener kundenbezogener Schnittstellenfunktionen ausdrücklich als Tätigkeiten beschrieben, die abhängig vom Scope vom Kunden durchgeführt oder über entsprechende CAS-Leistungen bezogen werden können.

Damit entsteht eine wichtige Governance-Frage:

Wer besitzt den End-to-End-Prozess, wenn SAP-System, BTP, Integration Suite und externes Zielsystem technisch unterschiedlichen Verantwortlichen gehören?

Diese Rolle sollte vor dem Go-live geklärt sein.

5. Transportmanagement: SAP richtet die technische Basis ein – Changes bleiben Governance-Thema

Beim Transportmanagement zeigt sich besonders gut, warum ein einfaches „SAP oder Kunde?“ zu kurz greift.

Die Standard-Ersteinrichtung von Transportdomäne und TMS kann zum SAP-Serviceumfang gehören. Weiterführende TMS-Konfiguration, das Übertragen und Freigeben von Transportaufträgen sowie die Durchführung von Transporten können dagegen als kunden- beziehungsweise CAS-seitige Aufgaben geführt werden. SAP behandelt wiederum technische Probleme des Transport Management Systems innerhalb seines technischen Scopes.

Damit gibt es mindestens drei unterschiedliche Verantwortungen:

Technische Plattform → Change-Prozess → Inhalt des Changes

SAP kann also den technischen Betrieb des Transportsystems unterstützen, ohne zu entscheiden, ob ein bestimmter fachlicher Change produktiv gehen darf.

Diese Entscheidung bleibt Teil von Change-, Release- und Business-Governance.

6. Benutzer und Berechtigungen: RISE verlagert Infrastruktur, nicht Business-Verantwortung

Rollen und Berechtigungen sind ein gutes Beispiel für einen Bereich, der häufig fälschlicherweise dem technischen Betrieb zugerechnet wird.

In der SAP-R&R-Dokumentation wird die Verwaltung nicht-technischer HANA-Benutzer, Rollen und Berechtigungen als kunden- beziehungsweise CAS-seitige Aufgabe beschrieben. Auch die Verwaltung von Kundenbenutzern, Benutzerprofilen, Rollen und Berechtigungen wird entsprechend eingeordnet.

Das ist logisch.

SAP kann nicht entscheiden:

Wer darf Rechnungen freigeben?
Wer darf Zahlungen ausführen?
Welche Rollen verletzen Segregation-of-Duties-Regeln?
Welche Berechtigung entspricht der internen Compliance-Policy?

Diese Entscheidungen gehören zur fachlichen und organisatorischen Governance des Kunden.

Ein SAP-Partner kann das Berechtigungsmodell technisch umsetzen und betreiben, die Verantwortung für die fachlichen Regeln bleibt jedoch beim Unternehmen.

7. Security: Infrastruktur und Applikation sind zwei verschiedene Ebenen

Auch bei Security muss getrennt werden.

Die veröffentlichte R&R-Dokumentation ordnet beispielsweise das Sicherheitskonzept für die Infrastruktur dem technischen Standardservice zu. Das Sicherheitskonzept für die Anwendung wird dagegen als kundenbezogene Aufgabe behandelt.

Weitere anwendungsbezogene Bereiche wie Security-Audit-Log-Analysen, Kundenbenutzerverwaltung, Interface Security oder Application Security Monitoring können ebenfalls auf Kunden- beziehungsweise CAS-Seite liegen.

Das Shared-Responsibility-Prinzip lautet deshalb vereinfacht:

SAP schützt die von SAP verantwortete Plattform. Der Kunde bleibt für die sichere Nutzung und Konfiguration seiner Anwendung verantwortlich.

8. Performance: Wer löst das Problem, wenn S/4HANA langsam wird?

Performance-Probleme zeigen besonders deutlich, warum ein gutes RISE-Betriebsmodell eine funktionierende Übergabe zwischen Teams braucht.

Wenn die Ursache innerhalb der von SAP verantworteten technischen Komponenten liegt, kann deren Analyse und Behebung zum Standardservice gehören.

Liegt die Ursache dagegen beispielsweise in:

Custom Code,
einer Anwendungskonfiguration,
einem ineffizienten Geschäftsprozess,
einem kundenindividuellen Interface oder
einem fachlichen Datenproblem,

bleibt die Analyse auf Kunden-/Partnerseite beziehungsweise kann als zusätzliche Serviceleistung bezogen werden.

SAP unterscheidet in seiner R&R-Dokumentation ausdrücklich zwischen technischen Performance-Ursachen innerhalb des Serviceumfangs und anwendungsbezogenen beziehungsweise außerhalb des technischen Scopes liegenden Ursachen.

Die eigentliche Herausforderung lautet damit nicht:

Wer ist für Performance verantwortlich?

Sondern:

Wer führt die erste Analyse durch und entscheidet schnell, auf welcher Seite die Ursache liegt?

Genau dafür wird weiterhin SAP-Basis- und Application-Know-how benötigt.

9. Incidents: SAP löst technische Incidents – der Kunde braucht trotzdem Incident Governance

SAP bietet für den definierten technischen Serviceumfang Incident Management und entsprechende Bearbeitungsschritte.

Aber auch hier bleibt eine Kundenschnittstelle bestehen.

SAP kann ein Infrastrukturproblem analysieren. Jemand muss jedoch zunächst feststellen, ob es tatsächlich ein SAP-ECS-Problem ist, die notwendigen Informationen liefern, den richtigen Service Request beziehungsweise Incident eröffnen und die Lösung anschließend fachlich validieren.

Die R&R-Dokumentation sieht beispielsweise die Bestätigung und Abnahme einer Lösung als kundenseitige Aufgabe vor.

In komplexeren Betriebsmodellen entsteht deshalb häufig eine neue Rolle:

Single Point of Contact zwischen Business, AMS, SAP Basis, Integration, Security und SAP ECS.

Das kann ein internes Service-Management-Team übernehmen oder ein Managed-Service-Partner.

10. Releases und Upgrades: SAP führt aus – der Kunde muss orchestrieren

Einer der häufigsten Missverständnisse lautet:

Wenn SAP die technische Plattform betreibt, übernimmt SAP auch das komplette Upgrade.

Technische Lifecycle-Aufgaben können tatsächlich von SAP ausgeführt werden. Die organisatorische Verantwortung verschwindet dadurch jedoch nicht.

SAP selbst weist in seiner Guidance zu RISE darauf hin, dass die Planung und Koordination von Software-Lifecycle-Events weiterhin beim Kunden liegt. Abhängigkeiten, Wartungsfenster, Tests und umliegende Work Packages müssen weiterhin koordiniert werden.

Ein Upgrade umfasst deshalb mehr als die technische Installation.

Vorher müssen Auswirkungen analysiert werden.

Danach müssen:

Custom Code,
Integrationen,
Geschäftsprozesse,
Berechtigungen und
kritische End-to-End-Szenarien

validiert werden.

SAP führt einen technischen Upgrade-Schritt durch.

Der Kunde muss entscheiden, ob sein Unternehmen danach sicher weiterarbeiten kann.

Was sind die typischen Lücken im RISE-Betrieb?

Die größten Lücken entstehen selten dort, wo eindeutig SAP oder eindeutig der Kunde verantwortlich ist.

Sie entstehen an den Übergängen.

Lücke 1: Niemand besitzt die Service-Request-Koordination

Unter On-Premise konnte das Basis-Team viele Maßnahmen direkt durchführen.

Unter RISE müssen bestimmte Aktionen über SAP angestoßen werden.

Fehlt ein klarer Owner, entstehen Verzögerungen zwischen Problem, Ticket, Freigabe und Umsetzung.

Lücke 2: Infrastruktur wird überwacht, Anwendungen aber nicht

SAP sieht, dass das System verfügbar ist.

Der Business Owner sieht erst Stunden später, dass Rechnungen nicht verarbeitet wurden.

Deshalb muss Application- und Business-Monitoring separat organisiert werden.

Lücke 3: Technische und fachliche Performance fallen zwischen zwei Teams

SAP sieht keine technische Infrastrukturstörung.

Das Application-Team weiß nicht, wo die Analyse beginnen soll.

Hier braucht es jemanden, der Workload, Anwendung, Custom Code, HANA und Infrastruktur zusammendenken kann.

Lücke 4: Transport und Change sind technisch möglich, aber organisatorisch unklar

Wer darf importieren?

Wer genehmigt?

Wer überprüft Abhängigkeiten?

Wer koordiniert Business Testing?

Diese Fragen löst RISE nicht automatisch.

Lücke 5: Application Security wird mit Cloud Security verwechselt

Die Plattform kann hochsicher betrieben werden, während eine fehlerhafte Rollenstruktur oder unsichere Schnittstellen weiterhin Risiken erzeugen.

Lücke 6: Release-Verantwortung endet vermeintlich bei SAP

Ein technisch erfolgreiches Release ist nicht automatisch ein erfolgreicher Business Release.

Unternehmen benötigen deshalb weiterhin Impact Analysis, Regression Testing und Release Governance.

Lücke 7: BTP und Integrationen haben keinen eindeutigen Owner

Mit zunehmender Nutzung von SAP BTP, Integration Suite, Cloud ALM und SaaS-Lösungen verschiebt sich ein immer größerer Teil des technischen Betriebs außerhalb des klassischen S/4HANA-Systems.

Genau deshalb entwickelt sich die SAP-Basis-Rolle zunehmend zur Plattform- und Operations-Rolle.

Braucht man bei RISE with SAP noch SAP Basis?

Ja.

Aber nicht im exakt gleichen Umfang und mit exakt denselben Aufgaben wie in einer klassischen On-Premise-Landschaft.

SAP selbst betont, dass weiterhin Ressourcen für Systemadministration und Landscape Governance benötigt werden. Eine weitere SAP-Publikation beschreibt die Veränderung sehr treffend: RISE deckt viele klassische Basis-Betriebsaufgaben ab, aber SAP-Technologiekompetenz bleibt notwendig; der Schwerpunkt verschiebt sich stärker von operativer Hands-on-Arbeit zu Koordination und Governance.

Wie verändert sich die Rolle des SAP Basis Administrators?

Die SAP-Basis-Kompetenz wird damit weniger infrastrukturlastig, aber nicht weniger relevant.

Im Gegenteil: Je mehr technische Ausführung auf unterschiedliche Provider verteilt wird, desto wichtiger wird jemand, der die Gesamtarchitektur versteht.

Welche Rolle kann ein SAP Basis Partner bei RISE übernehmen?

Ein SAP-Partner ersetzt SAP ECS nicht.

Seine Rolle liegt vielmehr dort, wo Unternehmen zwischen der SAP-Verantwortung und ihrer eigenen Betriebsorganisation zusätzliche technische und operative Kompetenz benötigen.

Typische Bereiche sind SAP-Basis-Governance, Monitoring, Application Operations, Transport- und Change-Management, Performance-Analyse, Release Readiness, Security, Integration, technische Incident-Triage und die Koordination von Service Requests mit SAP.

SVA positioniert diese Rolle im deutschen Markt ausdrücklich als „RISE-Betriebsergänzung“ und beschreibt sie als Schließen der Lücken zwischen SAP-Standard und Kundengovernance. Auch andere Anbieter vermarkten mittlerweile gezielt Managed Services für diese Basis-Lücke.

Der relevante Unterschied ist deshalb nicht:

SAP oder Partner?

Sondern:

Welche Aufgaben sind SAP-Standard, welche CAS, welche Kundenverantwortung – und wer übernimmt die verbleibende operative Arbeit?

Ein praktisches RACI-Modell für RISE with SAP

Eine RACI-Matrix sollte nicht nur angeben, wer eine Aufgabe „macht“.

Für jede kritische Tätigkeit sollten mindestens vier Fragen beantwortet werden.

Diese Matrix sollte anschließend mit dem aktuellen vertraglichen R&R-Dokument abgeglichen werden.

Welche Fragen müssen Unternehmen vor dem RISE-Go-live beantworten?

Das Ziel sollte ein Betriebsmodell sein, in dem keine Aufgabe zwischen zwei Verantwortungsbereichen liegen bleibt.

RISE with SAP, SAP Basis und Managed Services

Ein Managed-Service-Partner ist bei RISE with SAP nicht zwingend notwendig.

Er wird vor allem dann relevant, wenn das interne Team die verbleibenden Aufgaben nicht vollständig selbst übernehmen möchte oder wenn mehrere technische Domains zentral koordiniert werden sollen.

Ein solches Modell kann beispielsweise SAP Basis, AMS, Monitoring, Integration, Security, Release Management und Service Management verbinden.

Für Unternehmen ist das besonders interessant, wenn SAP nicht der einzige technische Provider im Ökosystem ist.

Denn moderne SAP-Landschaften bestehen häufig aus:

SAP S/4HANA Cloud Private Edition, SAP BTP, Integration Suite, SaaS-Anwendungen, Non-SAP-Systemen und unterschiedlichen Business Services.

Die eigentliche Betriebsaufgabe ist dann nicht mehr nur:

„SAP verfügbar halten.“

Sondern:

„Den gesamten Geschäftsprozess über alle beteiligten Systeme hinweg stabil betreiben.“

Wie LeverX RISE-Betriebsmodelle unterstützt

LeverX unterstützt Unternehmen beim Aufbau und Betrieb von SAP-S/4HANA-Cloud-Private-Edition-Landschaften im Rahmen von RISE with SAP.

Der Schwerpunkt liegt auf den Aufgaben zwischen SAP-Infrastrukturservices und dem Geschäftsbetrieb des Kunden: SAP-Basis-bezogene Operations, Monitoring, Application Management, Performance-Analyse, Changes, Release Readiness, Security und die Koordination technischer Incidents mit SAP.

Dabei können unterschiedliche Modelle eingesetzt werden: punktuelle Unterstützung des internen Teams, Co-Managed Operations oder ein umfassender Managed-Service-Ansatz.

RISE with SAP Managed Services

Fazit: RISE verändert SAP Basis – es macht die Rolle nicht überflüssig

RISE with SAP reduziert den Anteil klassischer Infrastrukturarbeit, den Unternehmen selbst durchführen müssen.

Doch daraus folgt nicht, dass SAP den gesamten technischen Betrieb übernimmt.

Die Verantwortung wird vielmehr neu verteilt.

SAP betreibt definierte Teile von Infrastruktur und technischer Plattform. Kunden behalten Verantwortung für Anwendung, Business-Prozesse, Governance und zahlreiche kundenindividuelle Aufgaben. Weitere Leistungen können über Cloud Application Services oder einen SAP-Partner abgedeckt werden.

Der wichtigste Schritt ist deshalb nicht, pauschal zu entscheiden:

„Wer macht SAP Basis?“

Sondern jede relevante Betriebsaufgabe konkret zu beantworten:

Wer entscheidet? Wer führt aus? Wer überwacht? Wer eskaliert? Wer validiert?

Unternehmen, die diese Fragen bereits vor dem Go-live klären, reduzieren operative Lücken, beschleunigen Incident-Prozesse und schaffen ein deutlich stabileres RISE-Betriebsmodell.

Häufige Fragen zu SAP Basis und RISE with SAP

Übernimmt SAP bei RISE with SAP die komplette SAP Basis?

Nein. SAP übernimmt viele klassische Infrastruktur- und technische Betriebsaufgaben, aber nicht alle SAP-Basis- und Application-Operations-Aufgaben. Der genaue Umfang richtet sich nach dem vertraglichen Roles-&-Responsibilities-Dokument und den zusätzlich vereinbarten Services.

Braucht ein Unternehmen mit RISE with SAP noch SAP Basis Administratoren?

Ja. Die Rolle verändert sich jedoch. Weniger direkte Infrastrukturadministration steht einer stärkeren Verantwortung für Governance, Monitoring, Changes, Service Requests, Releases, Security, Integration und Providersteuerung gegenüber.

Wer ist bei RISE with SAP für das Betriebssystem verantwortlich?

Bei den von SAP verwalteten SAP-Systemen übernimmt SAP beziehungsweise der entsprechende Service Provider die im Vertrag definierten Betriebssystemaufgaben. Kunden erhalten grundsätzlich keinen direkten OS-Zugriff auf die verwalteten Server.

Wer betreibt die SAP-HANA-Datenbank bei RISE?

Viele grundlegende HANA-Datenbankoperationen gehören zum technischen Managed-Service-Scope von SAP. Anwendungsbezogene Performance-, Daten- oder Business-Probleme bleiben davon jedoch getrennt.

Wer ist bei RISE with SAP für Monitoring verantwortlich?

SAP überwacht definierte technische Systemzustände und Verfügbarkeit. Application Monitoring, Integration Monitoring und Business Process Monitoring können dagegen Kunden- beziehungsweise Partneraufgaben oder zusätzliche CAS-Leistungen sein.

Wer führt Transporte bei RISE with SAP durch?

Der Scope ist geteilt. SAP kann die technische Transportinfrastruktur im Standard einrichten und technische TMS-Probleme bearbeiten. Laufende Transporte, kundenindividuelle TMS-Konfiguration und Deployment-Aktivitäten können jedoch beim Kunden beziehungsweise Partner liegen oder über zusätzliche Services abgedeckt werden.

Wer verwaltet Benutzer und Berechtigungen?

Geschäftliche Benutzer, Rollen und Berechtigungskonzepte bleiben typischerweise eine Kunden- beziehungsweise Partneraufgabe. Entsprechende Tätigkeiten können abhängig vom Vertrag teilweise über Cloud Application Services bezogen werden.

Wer ist für SAP Security bei RISE verantwortlich?

RISE folgt einem Shared-Responsibility-Modell. SAP verantwortet definierte Security-Aufgaben innerhalb der von SAP betriebenen Infrastruktur und Plattform. Application Security, Benutzer, Rollen, kundenspezifische Konfigurationen und Business Controls bleiben in erheblichem Umfang auf Kundenseite.

Wer behebt Performance-Probleme?

Das hängt von der Ursache ab. Technische Probleme innerhalb des SAP-Serviceumfangs werden von SAP behandelt. Application Performance, Custom Code und andere kundenbezogene Ursachen müssen vom Kunden, seinem Partner oder über entsprechende Zusatzservices analysiert werden.

Wer plant SAP Releases und Upgrades bei RISE?

SAP kann definierte technische Lifecycle-Aktivitäten ausführen. Planung, Business-Abstimmung, Impact Analysis, Regressionstests, Freigaben und die Koordination abhängiger Systeme bleiben jedoch weiterhin wesentliche Kunden- und Partneraufgaben.

Was sind SAP Cloud Application Services?

Cloud Application Services, kurz CAS, sind zusätzliche Services für Tätigkeiten, die grundsätzlich auch vom Kunden durchgeführt werden können. Wenn der Kunde sie nicht selbst durchführen möchte, können entsprechende CAS-Pakete zusätzlich vereinbart werden.

Was sind typische RISE-Betriebslücken?

Häufige Lücken entstehen bei Service-Request-Koordination, Application Monitoring, Integrationen, Transporten, Berechtigungen, Application Security, Performance-Analyse, Release Readiness sowie bei der Abgrenzung zwischen SAP, internem IT-Team und externem Partner.

Braucht man bei RISE with SAP einen Managed-Service-Partner?

Nicht zwingend. Ein Partner kann jedoch sinnvoll sein, wenn interne Ressourcen begrenzt sind oder wenn verbleibende Basis-, Monitoring-, AMS-, Security-, Integration- und Service-Management-Aufgaben übergreifend betreut w