Der SAP-Renewal-Zeitplan: 12 bis 18 Monate vor Vertragsende beginnt die Vorbereitung

SAP-Vertragserneuerungen gewinnt man nicht in den letzten Wochen vor Laufzeitende. Der entscheidende Zeitraum beginnt 12 bis 18 Monate früher. Was in dieser Zeit vorbereitet, strukturiert und entschieden wird, bestimmt die Qualität des nächsten Vertrags. Wer dieses Fenster nicht nutzt, verhandelt unter Zeitdruck, mit unvollständiger Datenbasis und bei aktivem Auto-Renewal-Risiko.

Dieser Artikel beschreibt das Phasen-Modell für eine strukturierte Renewal-Vorbereitung, erklärt, warum SAP früher beginnt als die meisten Kunden erwartet, und nennt die häufigsten Zeitplan-Fehler, die den Steuerungsmoment Renewal kosten.

Warum SAP früher beginnt als der Kunde

Ein struktureller Aspekt der Renewal-Vorbereitung, der in der Praxis regelmäßig unterschätzt wird: SAP startet den Renewal-Dialog auf Kundenseite typischerweise 12 bis 18 Monate vor Laufzeitende. Das SAP-Renewal-Team arbeitet mit strukturierten Vertriebsprozessen, vollständiger Verbrauchshistorie aus eigenen Systemen und einer klaren Zielsetzung für den nächsten Vertragsabschluss.

Für den Kunden bedeutet das: Wer noch keine eigene Renewal-Vorbereitung gestartet hat, wenn das erste SAP-Gespräch kommt, trifft auf einen strukturierten Counterpart ohne gleichwertige Datenbasis. Diese Situation ist nicht unvermeidlich. Sie entsteht dort, wo Verbrauchsdaten nicht kontinuierlich konsolidiert werden und die Renewal-Vorbereitung als administrativer Vorgang statt als Steuerungsmoment behandelt wird.

Der Steuerungsmoment Renewal ist der zentrale kommerzielle Steuerungsmoment im SAP-Vertragszyklus. Wer ihn systematisch vorbereitet, tritt das Gespräch auf gleicher Informationsgrundlage an. Wer ihn als Formalität behandelt, gibt die Initiative ab.

Das Phasen-Modell (M-18 bis M-0)

Ein strukturierter Renewal-Prozess lässt sich in vier Phasen gliedern. Jede Phase hat klare Aufgaben, typische Verantwortliche und ein definiertes Ergebnis. Das Modell beginnt 18 Monate vor Vertragsende und endet mit der Unterzeichnung und der Transition-Governance für die neue Laufzeit.

Phase 1 (M-18 bis M-12): Bestandsaufnahme und Datenbasis

Phase 1 legt die Grundlage für alles Folgende. Das Ziel ist ein vollständiges und aktuelles Bild der eigenen Vertragsposition: Was ist vereinbart? Was wird tatsächlich genutzt? Wo gibt es Abweichungen?

Der erste Schritt in dieser Phase ist häufig der aufwändigste: Alle Vertragsunterlagen, Order Form, Schedules, Amendments und Sondervereinbarungen, auf Aktualität prüfen. Was fehlt, wird bei SAP angefordert. Schedule 5 als Preislistenreferenz wird validiert: Stückpreise, Staffelstufen, Mindestmengen. Guthaben-Entwicklung je Vertragsjahr wird aus den monatlichen Balance Statements nachvollzogen.

Parallel dazu: Verbrauchsdaten konsolidieren. FUE-Auslastung je User-Typ für die letzten 12 bis 18 Monate. BTP-Credit-Verlauf je Subaccount und Projektbereich. Cloud-Managed-Services-Nutzung gegen eingekauftes Volumen. CAS-Paket-Nutzung gegen bezahltes Volumen. Und: Qualitätsdaten aufbereiten, SLA-Compliance-Auswertung, Ticket-Volumen, dokumentierte Eskalationen.

Ergänzend: Unternutzung identifizieren. Komponenten, für die Guthaben aufgewendet wird, ohne dass der vereinbarte Nutzungsumfang ausgeschöpft wird, werden in dieser Phase sichtbar. Das ist keine Kritik am bisherigen Betrieb, sondern die sachliche Grundlage für eine realistische Volumenplanung der nächsten Laufzeit. Wer Unternutzung erst in der Verhandlung thematisiert, verliert den früheren Steuerungsmoment für eine gezielte Planung.

Das Ergebnis von Phase 1 ist eine vollständige Übersicht über die eigene Vertragsposition mit quantifiziertem Delta zwischen vereinbartem und tatsächlich genutztem Volumen. Diese Übersicht ist die Grundlage, ohne die alle weiteren Phasen auf Schätzungen beruhen.

Phase 2 (M-12 bis M-9): Interne Ausrichtung und Szenario-Analyse

Phase 2 bereitet die Entscheidungsgrundlage vor. Das Ziel ist ein intern abgestimmtes Bild der eigenen Anforderungen für die nächste Laufzeit.

Hier wird das Stakeholder-Team formell konstituiert: Contract Manager, Procurement, Controlling und Executive. Jede dieser vier Rollen bringt eine spezifische Perspektive, ohne die spätere Entscheidungen Lücken aufweisen. Wer das Team erst in Phase 3 oder 4 zusammenstellt, verliert Vorlaufzeit und erzeugt Informationsasymmetrien innerhalb der eigenen Organisation.

Auf Basis der Verbrauchsdaten aus Phase 1 werden drei Szenarien definiert. Szenario 1: Status-quo-Renewal, Verlängerung zu im Wesentlichen unveränderten Bedingungen. Szenario 2: Volumen- oder Komponentenanpassung auf Basis der Nutzungsauswertung. Szenario 3: Vollständige Neuverhandlung mit geänderten Vertragsparametern. Jedes Szenario wird mit Budget-Implikationen bewertet.

Schließlich: Projektionsbedarf für die nächste Laufzeit bestimmen. Welche Nutzungsmengen sind geplant? Neue Module, veränderte Nutzerpopulation, geplante BTP-Erweiterungen, AI-Unit-Bedarf. Wo interne Datenlage oder Marktkenntnis unvollständig sind, ist Phase 2 der richtige Zeitpunkt für eine unabhängige Einschätzung der eigenen Vertragsposition.

Das Ergebnis von Phase 2 ist ein intern abgestimmter Entscheidungsrahmen: Welches Szenario wird angestrebt, welche Parameter sind verhandelbar, und welches Budget-Spektrum ist freigegeben.

Phase 3 (M-9 bis M-6): Klausel-Review und Verhandlungsvorbereitung

Phase 3 übersetzt Datenlage und Szenarien in eine konkrete Verhandlungsposition. Das Ziel ist eine vollständige Bewertung der kritischen Klauseln im aktuellen Vertrag und eine dokumentierte Ausgangslage für das Gespräch mit SAP.

Sechs Klausel-Bereiche entscheiden über die Steuerbarkeit des nächsten Vertrags: Preisanpassungsklausel (CPI-Mechanismus), Auto-Renewal-Klausel, SLA-Struktur und Geltungsbereich, Exit-Klauseln und Datenportabilität, Divestiture-Klausel und Subskriptions-Flexibilität. Für jeden dieser sechs Bereiche wird dokumentiert, was im aktuellen Vertrag steht und was für die nächste Laufzeit anders sein sollte. Das ist das Klausel-Delta, das in die Verhandlung eingebracht wird.

BTP-Verbrauchsdaten werden in Phase 3 als strukturierter Verhandlungs-Input aufbereitet: Zeitreihe über 12 bis 18 Monate, Projektzuordnung, Kostenstellenstruktur, Credit-Volumen-Kalibrierung für die neue Laufzeit. Diese Aufbereitung ist der direkteste Beleg für tatsächliche Cloud-Nutzung unterhalb der FUE-Ebene.

Und dann: Erste Gespräche mit SAP proaktiv aufnehmen, bevor SAP seinerseits die Initiative ergreift. Wer den Gesprächszeitpunkt selbst bestimmt, gestaltet den Rahmen des Renewal-Dialogs.

Das Ergebnis von Phase 3 ist eine vollständige Verhandlungsposition: Klausel-Delta, strukturierte Datenbasis, initialer Gesprächsstand mit SAP.

Phase 4 (M-6 bis M-0): Verhandlung, Abschluss, Transition

Phase 4 ist die Umsetzungsphase. Die Grundlage wurde in den vorherigen Phasen gelegt. Jetzt wird verhandelt, entschieden und abgeschlossen.

Verhandlungsführung auf Basis der vorbereiteten Datenbasis: Nutzungsauswertung, Klausel-Delta, Budget-Szenarien. Der Executive gibt in dieser Phase den Verhandlungsrahmen frei. Wer in Phase 2 drei Szenarien definiert hat, tritt die Verhandlung mit klarem Handlungsspielraum an.

Zwei operative Punkte, die in Phase 4 häufig zu spät in den Blick geraten: Sperrfristen und Auto-Renewal-Entscheidung. In den letzten sechs Monaten vor Vertragsende lassen sich keine neuen Managed-Service- oder Software-Subskriptionen mehr einbuchen, in den letzten zwölf Monaten keine neuen CAS-Einheiten. Notwendige Komponentenanpassungen müssen vor diesen Fristen abgeschlossen sein. Die Auto-Renewal-Entscheidung, Kündigung aussprechen oder bewusst laufen lassen, sollte spätestens bei M-3 gefallen sein, auf Basis des Verhandlungsstands und der Budget-Freigabe.

Phase 4 endet mit der Unterzeichnung des neuen Vertrags und einer dokumentierten Transition-Governance: Was läuft bis wann unter dem alten Vertrag, was startet unter dem neuen?

Die häufigsten Zeitplan-Fehler

In der Praxis zeigen sich wiederkehrende Muster, die die Renewal-Vorbereitung strukturell erschweren.

Datenbasis als Engpass. Die häufigste Ursache für einen verspäteten Start ist keine Frage der Absicht, sondern der Datenverfügbarkeit: FUE-Auslastung, BTP-Credit-Zeitreihen, Balance-Statement-Bestände, SLA-Auswertungen. Diese Daten lassen sich nicht in vier Wochen rückwirkend aufbauen. Wer sie nicht kontinuierlich pflegt, stellt in Phase 1 fest, dass die Grundlage für Phase 2 fehlt.

Stakeholder-Einbindung zu spät. Der Procurement-Verantwortliche erfährt drei Monate vor Laufzeitende, dass ein Renewal ansteht. Das Controlling hat keine aufbereiteten Verbrauchsdaten. Der Executive wird erst für die Unterzeichnung eingebunden. Dieses Muster führt dazu, dass Entscheidungen ohne ausreichende Datenbasis oder unter Zeitdruck getroffen werden.

Klausel-Review als Nachpflicht. Klauseln werden häufig erst geprüft, wenn SAP bereits ein Angebot vorgelegt hat. Zu diesem Zeitpunkt ist das Klausel-Delta ein reaktives Dokument statt ein proaktiv definiierter Verhandlungsrahmen.

Auto-Renewal-Frist als strukturelles Risiko. Der Vertrag verlängert sich ohne aktive Entscheidung. Die Kündigungsfrist, typischerweise drei Monate, ist vertragsspezifisch und im Order Form zu finden. Wer sie nicht im Fristen-Kalender verankert hat, riskiert eine ungewollte Verlängerung zu Konditionen, die SAP fristgerecht angekündigt hat. Dieser Steuerungsmoment lässt sich nach Fristablauf nicht mehr nutzen.

Reaktives Warten auf SAP. Wer den ersten Kontakt SAP überlässt, gibt den Framing-Rahmen des Renewal-Dialogs ab. Das muss nicht so sein. Proaktive Kontaktaufnahme in Phase 3, auf Basis einer vollständigen Datenbasis, setzt ein anderes Signal.

FAQ

Wann sollte ich mit der Renewal-Vorbereitung beginnen?

Spätestens 18 Monate vor Vertragsende. Grund: Die Datenbasis, die für eine fundierte Verhandlungsposition benötigt wird, lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über 12 bis 18 Monate, vollständige Vertragsdokumentation und Stakeholder-Ausrichtung erfordern Vorlaufzeit. Darüber hinaus beginnt SAP den Renewal-Dialog auf seiner Seite typischerweise in diesem Fenster.

Was passiert, wenn ich das Auto-Renewal nicht rechtzeitig kündige?

Der Vertrag verlängert sich automatisch, typischerweise um die ursprüngliche Vertragsdauer. SAP darf den Preis für die neue Periode erhöhen, sofern die Erhöhung mindestens 45 Tage vor Verlängerungsbeginn angekündigt wurde. Eine Nachverhandlung ohne neues Opening ist nicht möglich. Das Kündigungsrecht bleibt bestehen, sofern SAP eine Preiserhöhung ankündigt, aber der Zeitraum bis zur Entscheidung ist dann deutlich kürzer. Der Steuerungsmoment für eine proaktive Verhandlungsposition ist zu diesem Zeitpunkt bereits verstrichen.

Kann ich das Phasen-Modell auch verkürzt anwenden?

Wenn der Renewal-Zeitpunkt näher liegt als 18 Monate, ist das Modell auf den verfügbaren Zeitraum anzupassen. Priorität hat dann: Datenbasis aufbauen (Phase 1), Stakeholder konstituieren (Phase 2), Klausel-Review abschließen (Phase 3). Phase 4 braucht mindestens sechs Monate, weil davor die Sperrfristen für neue Subskriptionen greifen. Wer mit weniger als sechs Monaten Vorlauf in die Vorbereitung einsteigt, hat bereits eingeschränkte Handlungsoptionen.

Nächste Schritte

Renewal-Vorbereitung strukturiert starten. Der Vertragscheck von FinOptory liefert in vier Wochen eine vollständige Bestandsaufnahme der eigenen SAP-Vertragsposition: Verbrauchsdaten, Klausel-Bewertung, Datenbasis für das Renewal-Gespräch. Festpreis 7.900 EUR. Nach vier Wochen wissen Sie, wo Sie stehen und welches der drei Renewal-Szenarien für Ihre Situation in Frage kommt.

Weiterführend: SAP Renewal Negotiation Framework gibt den vollständigen Überblick über alle Phasen, Datenkategorien und kritischen Klauseln. Datenbasis aufbauen für SAP-Renewal vertieft die Frage, welche Verbrauchs-, Vertrags-, Markt- und Qualitätsdaten eine fundierte Verhandlungsposition ausmachen.

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