Die Datenbasis fuer SAP-Renewal-Verhandlungen aufbauen

Renewal-Verhandlungen werden nicht durch Verhandlungstechnik gewonnen, sondern durch Datenlage. Renewal ist der zentrale kommerzielle Steuerungsmoment im SAP-Vertragszyklus: Wer mit vollständiger, strukturierter Datenbasis in das erste Gespräch mit SAP geht, kann jede Frage zu Volumen, Preis und Klausel sachlich beantworten. Wer diese Datenbasis nicht hat, muss auf SAP-Aussagen reagieren, anstatt eigene Fakten einzubringen.

Dieser Artikel beschreibt, welche vier Datenkategorien eine belastbare Renewal-Position aufbauen, was dabei häufig fehlt und wie die Aufbereitung in der Praxis aussieht.

Drei Missverständnisse über Datenbasis bei SAP-Renewals

Bevor die vier Kategorien beschrieben werden, lohnt ein kurzer Blick auf verbreitete Annahmen, die die Vorbereitung verzögern.

Missverständnis 1: "SAP kennt unsere Nutzungsdaten, wir können sie jederzeit abrufen." SAP hat eigene Verbrauchsdaten. Diese sind jedoch nicht deckungsgleich mit dem, was der Kunde für eine Verhandlungsposition braucht. SAP-seitige Daten zeigen die Messung, nicht die Interpretation: Welche Nutzung ist produktiv, welche ist Test- und Entwicklungsumgebung? Welche Guthaben-Entwicklung entspricht dem ursprünglichen Business-Plan, welche weicht davon ab? Diese Einordnung kann nur der Kunde selbst vornehmen, und sie setzt voraus, dass die eigene Aufbereitung diese Granularität hat.

Missverständnis 2: "Wir brauchen nur die aktuellen Zahlen, nicht eine Zeitreihe." Aktuelle Verbrauchsdaten zeigen einen Stichtagswert, keine Entwicklung. SAP kennt die Verbrauchshistorie aus eigenen Systemen. Wer nur den Momentwert kennt, kann keine Argumentation zu Trends, Saisonalitäten oder Planabweichungen führen. Eine belastbare Renewal-Position erfordert eine Zeitreihe von mindestens zwölf, besser achtzehn Monaten. Der Steuerungsmoment Datenbasis entsteht deshalb nicht kurz vor dem Renewal, sondern in der laufenden Vertragssteuerung.

Missverständnis 3: "Datenbasis aufzubauen ist etwas für die letzte Phase." Die Aufbereitung von Verbrauchs- und Vertragsdaten, die für ein Renewal benötigt wird, lässt sich nicht in vier Wochen nachholen. Monatliche Balance Statements müssen über die gesamte Laufzeit gesammelt, FUE-Auslastungen regelmäßig dokumentiert und Vertragsdokumente aktuell gehalten werden. Wer achtzehn Monate vor Renewal beginnt, stellt fest, dass die eigentliche Datenbasis über die gesamte Vertragslaufzeit aufzubauen ist.

Die vier Datenkategorien im Renewal

1. Verbrauchsdaten: Tatsächliche Nutzung

Verbrauchsdaten sind die zentrale Kategorie für die Renewal-Datenbasis. Sie belegen, was tatsächlich genutzt wurde, und sind die sachliche Grundlage für Volumenplanungen der nächsten Laufzeit.

FUE-Auslastung je User-Typ ist die wichtigste Verbrauchskennzahl im RISE Enterprise Agreement und ein eigenständiger Steuerungsmoment im Bereich Nutzung. Advanced-Use-User (1 FUE je User), Core-Use-User (1 FUE für 5 User) und Self-Service-Use-User (1 FUE für 30 User) haben unterschiedliche Wertbeiträge pro eingesetztem Guthaben. Wer die tatsächliche Auslastung je User-Typ über achtzehn Monate dokumentiert hat, kann die FUE-Allokation für die nächste Laufzeit fundiert planen, auch wenn sich die Nutzerpopulation verändert hat.

BTP-Credit-Verbrauch je Subaccount und Projekt liefert das granulare Bild der Cloud-Plattform-Nutzung unterhalb der FUE-Ebene. Welche BTP-Services werden produktiv eingesetzt, welche sind Test- und Entwicklungsumgebungen? Wie hat sich das Verbrauchsvolumen über die Zeit entwickelt? Dieser Datenstrang ist besonders relevant, wenn eine Erweiterung der BTP-Nutzung für die nächste Laufzeit geplant ist. Eine detaillierte Beschreibung der BTP-Verbrauchsdaten als Verhandlungs-Input bietet der Begleittartikel [SP-2: BTP-Verbrauchsdaten als Verhandlungs-Input].

Cloud-Managed-Services-Nutzung gegen eingekauftes Volumen zeigt, ob die Infrastrukturkomponenten des RISE-Pakets dem tatsächlichen Betriebsbedarf entsprechen. Infrastrukturkapazitäten, die über den produktiven Betrieb hinausgehen, sind kein seltener Befund, insbesondere wenn das initiale Sizing auf Planungsannahmen basiert, die sich im Betrieb nicht vollständig bestätigt haben.

CAS-Paket-Nutzung ist eine häufig vernachlässigte Steuerungskennzahl: bezahltes CAS-Volumen gegen tatsächlich abgerufene Beratungs- und Betriebsleistungen. CAS-Pakete können in den letzten zwölf Monaten vor Vertragsende nicht mehr neu gebucht werden. Wer bis dahin ungenutzte CAS-Kapazitäten hat, hat eingeschränkte Gestaltungsmöglichkeiten für den Ausgleich.

2. Vertragsdaten: Was vereinbart ist

Verbrauchsdaten allein reichen nicht. Der Abgleich von tatsächlicher Nutzung mit vertraglich vereinbarten Konditionen erfordert aktuelle und vollständige Vertragsdokumente.

Schedule 5 als Preislistenreferenz enthält die bei Vertragsabschluss fixierten Stückpreise, Staffelstufen und Mindestmengen für alle Komponenten. Diese Preisfixierung gilt für die gesamte Laufzeit, bei Cloud-Managed-Services jedoch nur für die initiale Subskription. Bei einer Re-Subskription nach Dekommissionierung gelten neue Marktpreise. Wer das nicht weiß, kann eine Dekommissionierungsentscheidung auf falscher Prämisse treffen.

Guthaben-Entwicklung je Vertragsjahr lässt sich nur aus den monatlichen Balance Statements vollständig nachvollziehen. Diese Dokumente sind die einzige belastbare Quelle für den kumulierten Verbrauch und den verbleibenden Guthabenstand. Eine lückenlose Sammlung über die gesamte Vertragslaufzeit ist die Mindestvoraussetzung für eine Hochrechnung auf das Vertragsende.

Subskriptions-Mindestlaufzeiten und Sperrfristen bestimmen, welche Anpassungen noch möglich sind und welche nicht. Cloud-Managed-Services und Cloud-Software haben Mindestlaufzeiten von sechs Monaten, CAS-Pakete von zwölf Monaten. Sperrfristen für neue Subskriptionen gelten in den letzten sechs Monaten (Managed Services, Software) beziehungsweise zwölf Monaten (CAS) vor Vertragsende. Wer diese Fristen kennt, plant Komponentenanpassungen so, dass sie noch vor dem Sperrfenster wirksam werden können.

Sondervereinbarungen in der Order Form werden im Renewal-Prozess häufig übersehen. Amendments, Transformation-Incentive-Vereinbarungen und spezifische Sonderkonditionen stehen über den Standard-Schedules und sind der Ort, an dem im ursprünglichen Verhandlungsprozess relevante Zugeständnisse verankert wurden. Diese Vereinbarungen sind beim Renewal zu prüfen, bevor Vergleiche mit Standardkonditionen gezogen werden.

3. Marktdaten: Was öffentlich verfügbar ist

Marktdaten sind keine Verhandlungsgrundlage im engeren Sinne, aber sie liefern Einordnung: Wie verhält sich die eigene Situation im Branchenvergleich? Öffentlich verfügbare Quellen ermöglichen eine sachliche Orientierung ohne interne Vertraulichkeit zu verletzen.

Öffentliche Berichte und Branchenquellen wie DSAG-Studien, Analyseberichte von Gartner und Forrester sowie spezialisierte Quellen zu SAP-Lizenzen (saprisenegotiations.com, redresscompliance.com) geben Hinweise auf Marktpraxis, typische Klauselgestaltungen und Preisentwicklungen. Diese Quellen ersetzen keine eigene Verbrauchsauswertung, aber sie können die interne Diskussion über Szenario-Optionen fundieren.

Produkttyp-übergreifende Perspektive: Für Unternehmen mit SAP-Portfolio über RISE hinaus, etwa SuccessFactors, Ariba oder IBP, sind die Konditionen dieser Produkte Teil der Gesamtbetrachtung. Wer alle SAP-Vertragsbeziehungen in der Renewal-Vorbereitung zusammenführt, hat ein vollständiges Bild der eigenen Verhandlungsposition gegenüber SAP als Vendor.

Transition-Option als sachlicher Bezugspunkt: Die Transition Option für On-Premise-Kunden nach 2030 ist öffentlich mit einem 20-prozentigen Aufschlag gegenüber vergleichbarer SAP ERP Private Edition kommuniziert, mit einem Service-Start-Fenster zwischen 2028 und 2030 (Quelle: SAP Help Portal). Diese Information ist kein Druckmittel, aber ein sachlicher Bezugspunkt für Gespräche über Vertragskontinuität und die Planbarkeit der eigenen SAP-Strategie.

4. Qualitätsdaten: Was SAP geliefert hat

Die vierte Kategorie ist in der Renewal-Vorbereitung oft am schlechtesten dokumentiert, obwohl sie eine sachliche Grundlage für Gespräche über Vertragsqualität bietet.

SLA-Compliance der letzten zwölf bis achtzehn Monate: Wie oft wurde die vereinbarte Verfügbarkeit eingehalten? Gab es dokumentierte Abweichungen, und wurden SLA-Credits geltend gemacht? Schedule B definiert die Reaktionszeiten und Schedule D die SLA-Credit-Mechanik: maximal 0,25 Prozent des Jahresbetrags pro Quartal, maximal fünf Prozent kumuliert, nur als Gutschrift, geltend zu machen innerhalb eines Monats nach Quartalsende, schriftlich.

Ticket-Volumen und Service-Request-Durchlaufzeiten: SAP garantiert für Service-Requests keine SLA, das ist ein bekannter Bestandteil des RISE-Betriebsmodells. Wer eigene Daten zur durchschnittlichen Bearbeitungszeit, zum Ticket-Volumen und zu Eskalationsquoten dokumentiert hat, verfügt über eine sachliche Grundlage für Gespräche über die operative Servicequalität.

Ungelöste Eskalationen als dokumentierter Sachstand: Offene Fragen aus der laufenden Vertragslaufzeit sind als sachlicher Input in die Renewal-Vorbereitung einzubringen, nicht als Beschwerdeliste. Wer sie strukturiert dokumentiert hat, kann sie im Renewal-Gespräch adressieren, ohne auf Erinnerungen angewiesen zu sein.

Shelfware identifizieren und dokumentieren

Ein spezifischer Steuerungsmoment in der Verbrauchsdaten-Auswertung: die Identifikation von Shelfware. Gemeint sind Komponenten, für die Guthaben aufgewendet wird, ohne dass der vereinbarte Nutzungsumfang ausgeschöpft wird.

Shelfware entsteht nicht notwendig aus Planungsfehlern. Organisationsveränderungen, verschobene Rollouts, veränderte Prozessanforderungen: Diese Entwicklungen führen dazu, dass eingekaufte Kapazitäten nicht in dem ursprünglich vorgesehenen Umfang genutzt werden. Die Feststellung von Shelfware ist keine Kritik am bisherigen Betrieb, sondern Grundlage für eine sachgerechte Volumenplanung der nächsten Laufzeit.

Für die Renewal-Datenbasis ist die Shelfware-Analyse ein eigenständiger Steuerungsmoment im Bereich Kosten: Welche Komponenten haben konsistent eine Nutzungsquote unter 70 Prozent des eingekauften Volumens? Welche FUE-Typen sind überallokiert gegenüber der tatsächlichen Nutzerpopulation? Welche CAS-Pakete wurden nur teilweise abgerufen?

Diese Feststellung ist der Ausgangspunkt für zwei verschiedene Szenarien im Renewal: Volumenreduktion auf Basis belegter Unternutzung, oder Aktivierungsplanung für bisher ungenutztes Potenzial. Beide Optionen erfordern dieselbe Datenbasis, führen aber zu unterschiedlichen Verhandlungszielen.

Self-Report-Pflicht und Overage-Dokumentation

Neben den vier Datenkategorien ist die korrekte Dokumentation von Übernutzungen eine eigenständige Anforderung an die Renewal-Datenbasis.

Im RISE Enterprise Agreement liegt die Pflicht zur Meldung von Übernutzung beim Kunden. Diese Pflicht besteht unabhängig davon, ob SAP die Übernutzung bereits kennt. Verbrauch über das Guthaben hinaus wird mit einem 15-prozentigen Aufschlag fakturiert, und für die Übernutzungsphase gilt keine SLA.

Für die Renewal-Vorbereitung bedeutet das: Alle Overage-Sachstände der laufenden Vertragslaufzeit müssen vollständig dokumentiert und abgeschlossen sein, bevor das Renewal-Gespräch beginnt. Ungeklärte Nachforderungen in den letzten zwölf Monaten vor Vertragsende binden Ressourcen und Aufmerksamkeit, die für die Verhandlungsvorbereitung gebraucht werden.

Ein monatliches Balance-Statement-Review ist der strukturierte Prozess, mit dem Overages frühzeitig erkannt und dokumentiert werden können. Dieser Steuerungsmoment im Bereich Kosten schützt die Renewal-Datenbasis vor nachträglichen Korrekturen. Die Frage, bei welchem Guthabenstand intern eskaliert wird, sollte nicht im Anlassfall entstehen, sondern als Threshold-Definition im Governance-Prozess verankert sein.

Wer die Datenbasis liefert

Eine Frage, die in der Renewal-Vorbereitung regelmäßig zu spät gestellt wird: Wer im Unternehmen kann welche Daten belastbar liefern?

BTP-Betriebsdaten liegen typischerweise beim Architektur- oder Plattform-Team, nicht beim Contract Manager. FUE-Auslastungsdaten werden oft von SAP-Basis oder dem IT-Betrieb verwaltet. Kostenzuordnungen und interne Verrechnungsdaten kommen aus dem Controlling. Vertragsdokumente liegen beim Einkauf oder in der IT-Governance.

Renewal-Vorbereitung erfordert deshalb eine koordinierte Datenlieferung über mehrere Funktionen hinweg. Der Contract Manager verantwortet die Zusammenführung, aber er kann die Rohdaten nicht aus einer einzelnen Quelle beziehen. Diese Koordinationsaufgabe ist einer der Gründe, warum strukturierte Renewal-Vorbereitung achtzehn Monate Vorlauf braucht, nicht sechs.

Fazit: Datenbasis ist keine Vorbereitung, sondern laufende Steuerung

Die vier Datenkategorien, Verbrauchsdaten, Vertragsdaten, Marktdaten und Qualitätsdaten, lassen sich nicht ad hoc aufbauen. Sie entstehen durch kontinuierliche Steuerung über die gesamte Vertragslaufzeit. Wer diese Steuerungsmomente in Nutzung, Berechtigungen, Infrastruktur und Kosten laufend wahrnimmt, hat beim Renewal keine Aufbereitungsaufgabe, sondern eine Konsolidierungsaufgabe. Monatliche Balance Statements, regelmäßige FUE-Auswertungen, gepflegte Vertragsdokumentation und dokumentierte Service-Qualität sind keine Renewal-Vorbereitung, sie sind laufende SAP-Vertragssteuerung.

Das ist der Unterschied zwischen einer Position und einer Reaktion.

Der nächste Schritt in der Renewal-Vorbereitung: der Klausel-Review. Welche Klauseln im aktuellen Vertrag die Steuerbarkeit der nächsten Laufzeit bestimmen, beschreibt [Cluster 3: Kritische Klauseln im SAP-Renewal].

FAQ

Was sind die wichtigsten Daten für eine SAP-Renewal-Verhandlung?

Vier Kategorien bilden die vollständige Datenbasis: Verbrauchsdaten (FUE-Auslastung je User-Typ, BTP-Credit-Verlauf, CAS-Nutzung, Cloud-Managed-Services gegen eingekauftes Volumen), Vertragsdaten (Schedule 5, Balance Statements, Sondervereinbarungen), Marktdaten (öffentliche Branchenquellen, DSAG-Berichte) und Qualitätsdaten (SLA-Compliance, Ticket-Volumen, ungelöste Eskalationen). Eine fundierte Verhandlungsposition erfordert alle vier Kategorien.

Wie lange brauche ich für den Aufbau einer Renewal-Datenbasis?

Die Datenbasis lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über zwölf bis achtzehn Monate, vollständige Vertragsdokumentation und eine koordinierte Datenlieferung über mehrere Unternehmensfunktionen erfordern einen Vorlauf von mindestens achtzehn Monaten. Wer diesen Vorlauf nicht hat, beginnt das Renewal mit lückenhafter Grundlage.

Was ist Shelfware im SAP-Renewal-Kontext?

Shelfware bezeichnet Komponenten, für die Guthaben aufgewendet wird, ohne dass der vereinbarte Nutzungsumfang ausgeschöpft wird. Die Identifikation von Shelfware ist Grundlage für zwei Renewal-Szenarien: Volumenreduktion auf Basis belegter Unternutzung oder Aktivierungsplanung für bisher ungenutztes Potenzial. Beide Optionen erfordern eine dokumentierte Verbrauchshistorie.

Was ist die Self-Report-Pflicht bei SAP RISE?

Im RISE Enterprise Agreement liegt die Pflicht zur Meldung von Übernutzung beim Kunden. Verbrauch über das vereinbarte Guthaben hinaus muss gemeldet werden, bevor er eintritt. Nicht gemeldete Übernutzung wird mit einem 15-prozentigen Aufschlag auf die reguläre Verbrauchsgebühr fakturiert, und für die Übernutzungsphase gilt keine SLA-Garantie.

Welche Rolle spielt die Datenbasis im Verhältnis zu Verhandlungstaktik?

Datenbasis und Verhandlungstaktik sind keine Alternativen, sondern ergänzende Ebenen. Verhandlungstaktik ohne belastbare Datenbasis ist auf die Überzeugungskraft der Argumentation angewiesen. Eine vollständige Datenbasis ermöglicht, jede Frage zu Volumen, Preis und Klausel sachlich zu beantworten, unabhängig von der taktischen Gesprächsführung des Counterparts.

Nächste Schritte

Verbrauchsdaten strukturieren. Wenn Sie Ihre eigene Renewal-Situation einordnen möchten, ist der erste Schritt ein Überblick über die eigene Verbrauchslage: Was liegt bereits vor, was muss koordiniert werden? Der [FinOptory-AI-Chat auf finoptory.ai] hilft, diese Einordnung schnell vorzunehmen.

Vertragscheck als strukturierter Einstieg. Der Vertragscheck von FinOptory liefert in vier Wochen eine vollständige Bestandsaufnahme der eigenen SAP-Vertragsposition, einschließlich Datenbasis-Assessment, Klausel-Bewertung und Renewal-Readiness. Festpreis 7.900 EUR. Ein Erstgespräch ist ohne Vorlaufzeit möglich.

Weiterführende Lektüre. Der Überblick über den gesamten Renewal-Prozess steht im [Hub: SAP Renewal Negotiation Framework]. Den Zeitplan für die Phasen M-18 bis M-0 beschreibt [Cluster 1: Der Renewal-Zeitplan in der Praxis]. Die Klausel-Ebene behandelt [Cluster 3: Kritische Klauseln im SAP-Renewal].

Erstellt 2026-05-21. Version v1, Status: draft, freigegeben für Bernhard-Review. Quellen-Grundlage: SAP_RISE/02, SAP_RISE/04, SAP_RISE/07 (partner-sichtbar), FinOptory-Strategy-Brief-v2.md. SAP_RISE/08_rise_negotiation_playbook.md wurde nicht verwendet.