Fragen zur SAP Lizenzierung? Hier finden Sie Antworten. Von Named-User-Typen über Digital Access bis zur S/4HANA-Migration: Diese FAQ-100 bündelt unser Praxiswissen aus zahlreichen SAP-Lizenzprojekten – unabhängig, verständlich und aktuell.
SAP lizenziert den Zugriff durch Benutzer über die Metrik „Named User“. Das bedeutet jede Person, die auf die SAP-Software zugreift, benötigt eine Named-User-Lizenz. Mit einer Lizenz darf er alle SAP-Systeme nutzen. Die Nutzung des Accounts durch mehrere Mitarbeiter ist nicht zulässig, da die Lizenz an der definierten Person hängt.
Jedem Named-User-Account wird ein Lizenztyp zugewiesen. Die korrekte Zuweisung liegt in der Verantwortung des SAP-Kunden.
Welcher Typ notwendig ist, wird durch zwei Faktoren bestimmt: erstens durch das, was er tatsächlich tut (Nutzung), und zweitens durch das, was er laut Systemberechtigungen tun dürfte (Berechtigung).
Im SAP ECC Lizenzmodell ist es zulässig nach der Nutzung zu lizenzieren, in S/44HANA verlangt SAP eine Lizenzierung nach Berechtigungen.
Häufiger Denkfehler in der Praxis: „Wer sich nicht einloggt, braucht keine Lizenz.“ Das Gegenteil ist der Fall: Entscheidend für die Lizenzpflicht ist ein aktiver Account mit Berechtigungen. Inaktive Accounts zählen bei der Vermessung voll mit, es sei denn, sie werden über das Gültig-bis-Datum im Benutzerstamm aktiv ungültig gesetzt oder gelöscht.
SAP kennt verschiedene Lizenztypen, die je nach Produkt, Vertragsgeneration und Modell unterschiedlich heißen können. Die wichtigsten im SAP ECC-On-Premise-Umfeld sind:
Wichtig: Die genauen Definitionen stehen im Vertrag, nicht in SAP-Marketingmaterialien. Was SAP heute auf der Website beschreibt, muss nicht das sein, was in Ihrem vor fünf Jahren abgeschlossenen Vertrag steht. Im Zweifel gilt der Vertrag.
Technische Accounts (für User in Schnittstellen, für sogenannte Firefighter etc.) benötigen keinen Lizenztyp. Die Zuweisung bei technischen Accounts sollte leer sein, falls ein Lizenztyp eingetragen ist, wird dieser in der SAP-Vermessung mitgezählt.
Nutzung beschreibt, was ein User im System tatsächlich getan hat: welche Transaktionen er aufgerufen hat, welche Belege er gebucht hat, welche Berichte er abgerufen hat. Berechtigung beschreibt, was er laut seinen Rollen und Profilen tun dürfte – unabhängig davon, ob er es je getan hat.
Beide Dimensionen sind für die Lizenzierung relevant, aber sie führen zu unterschiedlichen Ergebnissen:
Die richtige Vorgehensweise: Nutzung und Berechtigung gemeinsam prüfen, mit dem Vertrag abgleichen – und erst dann Lizenztypen zuordnen.
Der Lizenztyp ergibt sich nicht aus dem Jobtitel, nicht aus der Abteilung und nicht aus dem Bauchgefühl. Er ergibt sich aus einem strukturierten Prozess:
Ein häufiger Fehler ist, Lizenztypen pauschal nach Abteilung zu vergeben. Die Buchhaltung bekommt automatisch „Professional“, der Vertrieb auch – obwohl ein Teil der Mitarbeitenden vielleicht nur Berichte abruft und mit einem günstigeren Typ gut bedient wäre. Das kostet unnötig Geld.
Es gibt spezialisierte Tools auf dem Markt, die die Aktivitätshistorie von Benutzern auswerten, mit den Berechtigungen abgleichen und Empfehlungen geben, welche Berechtigungsanpassungen Sinn machen und welche Lizenztypen zu vergeben sind.
SAP ECC (Enterprise Central Component) ist die klassische On-Premise-ERP-Plattform von SAP, die seit den 1990er-Jahren in verschiedenen Versionen eingesetzt wird. Die aktuelle Version ist ECC 6.0. SAP hat den Mainstream-Wartungsende für ECC offiziell auf 2027 festgelegt – mit optionaler kostenpflichtiger Verlängerung bis 2030.
Für die Lizenzierung bedeutet ECC: Sie arbeiten mit einem etablierten, aber auslaufenden Lizenzmodell. Die Verträge sind oft älter, die Definitionen manchmal unscharf, und SAP hat in der Vergangenheit immer wieder versucht, bei Verlängerungsverhandlungen die Konditionen zu verschärfen. Wer noch auf ECC läuft, sollte jetzt seine Verträge prüfen – nicht erst, wenn die technische Migration beginnt.
SAP S/4HANA ist die Nachfolge-ERP-Plattform von ECC, aufgebaut auf der In-Memory-Datenbank SAP HANA. Sie ist als On-Premise-Version, als Private Cloud und als Public Cloud verfügbar.
Für die Lizenzierung bringt S/4HANA mehrere wesentliche Änderungen:
Kurz gesagt: S/4HANA ist nicht nur ein technisches Migrationsprojekt. Es ist auch ein Lizenzprojekt. Wer das unterschätzt, zahlt drauf.
Bei On-Premise kaufen oder lizenzieren Sie Software, die Sie auf eigener oder gemieteter Infrastruktur betreiben. Sie haben volle Kontrolle über System, Daten und Konfiguration. Die Lizenzierung erfolgt über Named User und – je nach Vertragsmodell – Engine-Lizenzen und Pauschalbeträge.
Bei SAP Cloud (z. B. S/4HANA Cloud Public Edition oder Rise with SAP) mieten Sie die Software als Service. SAP betreibt die Infrastruktur, liefert Updates automatisch, und die Lizenzierung erfolgt in der Regel über User- und Engine-Subscriptions pro Monat oder Jahr.
Die entscheidenden Unterschiede für Lizenzverantwortliche:
Viele Mittelstandsunternehmen betreiben aktuell hybride Landschaften – On-Premise-Kernsysteme mit Cloud-Erweiterungen. Das macht die Lizenzierung nicht einfacher.
Rise with SAP ist ein Angebotspaket von SAP, das SAP Cloud ERP Private (früher: S/4HANA Cloud Private Edition) mit Infrastruktur, Support und weiteren Services bündelt. SAP vermarktet es als „Business Transformation as a Service“ – im Kern ist es ein Weg, On-Premise-Kunden in die Cloud zu bewegen, ohne dass sie ihre gewohnte S/4HANA-Umgebung vollständig aufgeben müssen.
Lizenzrechtlich ist Rise with SAP ein Subscription-Modell: Sie zahlen eine monatliche oder jährliche Gebühr, die Infrastruktur, Lizenzen und Basis-Support enthält. Das klingt einfacher als klassische On-Premise-Verträge – ist es aber nicht unbedingt. Kritische Punkte:
SAP BTP (Business Technology Platform) ist die Integrationsplattform von SAP. Sie dient als technische Grundlage für Erweiterungen, Integrationen, Automatisierungen und Analysen rund um SAP-Kernsysteme. BTP enthält Dienste wie SAP Integration Suite, SAP Extension Suite, SAP HANA Cloud und weitere.
Lizenzrelevant wird BTP auf mehreren Ebenen:
Im Mittelstand wird BTP oft als „technisches Thema“ abgetan und landet beim IT-Team, nicht beim Lizenzverantwortlichen. Das ist ein Fehler. Wer BTP einsetzt oder plant, sollte frühzeitig klären, welche Lizenzkonsequenzen das hat.
Eine SAP-Systemlandschaft beschreibt alle SAP-Systeme, die ein Unternehmen betreibt: Produktivsysteme, Qualitätssicherungssysteme, Entwicklungssysteme, Sandbox-Systeme, Schulungssysteme und etwaige Altsysteme.
Für die Lizenzierung ist die Systemlandschaft aus mehreren Gründen relevant:
Kurz: Jedes System in Ihrer Landschaft hat eine lizenzrechtliche Konsequenz. Wer den Überblick verliert, verliert auch die Kontrolle über die Kosten.
SAP-Lizenzmanagement ist keine Ein-Mann-Aufgabe und auch keine reine IT-Aufgabe. Es braucht klare Zuständigkeiten über mehrere Bereiche hinweg:
Oft ist diese Rollenverteilung nicht klar definiert. Das Ergebnis: Lizenzen wachsen unkontrolliert, Optimierungspotenziale werden nicht gehoben, und beim nächsten SAP-Audit fehlen die Nachweise. Wer jetzt Strukturen aufbaut, spart später erhebliche Kosten.
Früher wurden diese beiden Produkte als SAP S/4HANA Cloud Public Edition (SAP ERP Cloud) und Private Edition (SAP ERP Cloud private) vertrieben. Die Public-Edition ist im Programm SAP Grow enthalten und die Private Edition im Programm Rise with SAP.
SAP bietet S/4HANA Cloud in zwei grundlegend verschiedenen Varianten an – und die Unterschiede sind nicht nur technischer Natur, sondern haben direkte Auswirkungen auf Lizenzierung, Flexibilität und Kosten. Beide Varianten sind nur als Subscription-Modell erhältlich.
Beide Editionen nutzen das FUE-Modell (Full Use Equivalent) zur nutzerbasierten Lizenzierung. Allerdings unterscheidet sich der Zuschnitt der Berechtigungen und Rollen massiv, da in der Public Cloud die technische Flexibilität stark eingeschränkt ist.
Die klassischen FUE-Verhältnisse (wie 1 Advanced User = 1 FUE; 5 Core User = 1 FUE; 30 Self-Service User = 1 FUE) gelten prinzipiell für beide, aber der Nutzen hinter einem „Advanced User“ ist in der Private Edition durch den Zugriff auf den vollen ERP-Funktionsumfang erheblich größer.
Die Mindestabnahmen und Preisstaffeln für FUEs unterscheiden sich ebenfalls zwischen den Modellen.
Früher wurden diese beiden Produkte als SAP S/4HANA Cloud Public Edition (SAP ERP Cloud) und Private Edition (SAP ERP Cloud private) vertrieben. Die Public-Edition ist im Programm SAP Grow enthalten und die Private Edition im Programm Rise with SAP.
Auch in der Lizenzierung der Infrastrukturkomponenten unterscheiden sich beide Modelle:
Früher wurden diese beiden Produkte als SAP S/4HANA Cloud Public Edition (SAP ERP Cloud) und Private Edition (SAP ERP Cloud private) vertrieben. Die Public-Edition ist im Programm SAP Grow enthalten und die Private Edition im Programm Rise with SAP.
Bei den „Engines“ (von SAP offiziell oft als Add-ons oder LoB Solutions bezeichnet, die nach funktionalen Durchsatzmetriken statt nach Nutzern abgerechnet werden) gibt es zwischen der Public Edition und der Private Edition fundamentale Unterschiede.
Diese betreffen nicht nur die Auswahl der verfügbaren Engines, sondern auch die zugrundeliegenden Metriken und die Flexibilität bei der Vertragsgestaltung.
Verfügbarkeit
Metriken
Wichtig für das SAM-Controlling: In der Private Edition müssen Sie diese technischen Kennzahlen über das klassische Vermessungstool (USMM / LAW 2.0) weiterhin aktiv reporten. In der Public Edition erfolgt die Messung des Verbrauchs meist vollautomatisch im Hintergrund über das SAP Cloud Portal.
FUE steht für Full Use Equivalent und ist das Lizenzmodell für SAP S/4HANA Cloud. Anstatt verschiedene Lizenztypen mit unterschiedlichen Preisen zu kaufen, werden alle Nutzer in eine gemeinsame Einheit umgerechnet.
Ein FUE entspricht einem vollwertigen, uneingeschränkten Nutzer. Weniger intensive Nutzertypen „kosten“ nur einen Bruchteil eines FUE-Punktes. SAP unterscheidet hierbei standardmäßig drei (bzw. in der Private Edition vier) Stufen:
| Nutzertyp (Cloud Usage Tier) | Berechtigungsumfang | Wechselkurs / Gewichtung | Praxis-Beispiel |
|---|---|---|---|
| Advanced User | Voller Zugriff auf alle Kernprozesse (Finanzen, Vertrieb, Einkauf, Produktion, Controlling). | 1 Nutzer = 1 FUE | Hauptbuchhalter, Produktionsplaner, Niederlassungsleiter |
| Core User | Eingeschränkter Zugriff auf operative Prozesse (z. B. Logistik, reiner Vertriebsaußendienst, HR). | 5 Nutzer = 1 FUE (0,2 FUE pro Kopf) | Lagermitarbeiter, Vertriebsmitarbeiter im Innendienst |
| Self-Service User | Reine Konsum- und Genehmigungstätigkeiten (z. B. Zeiterfassung, Reisekosten, Bestellanforderungen). | 30 Nutzer = 1 FUE (ca. 0,03 FUE pro Kopf) | Jeder „normale“ Mitarbeiter ohne ERP-Kernaufgaben |
| Developer User (Nur Private Edition!) | Voller Zugriff auf den ABAP-Code, Modifikationen und Entwicklungs-Tools. | 0,5 Nutzer = 1 FUE (2 FUE pro Kopf) | Inhouse-ABAP-Entwickler, Systemadministratoren |
Der große SAM-Fallstrick:
Die Zuweisung, welcher Nutzer welcher Kategorie angehört, erfolgt in der Cloud automatisch über die zugewiesenen Berechtigungsrollen (Rollen-Mapping).
Wenn Sie einem Lagermitarbeiter (eigentlich Core User) auch nur eine einzige Berechtigung aus der Finanzbuchhaltung (z. B. Kontenprüfung) zuweisen, stuft das SAP-System ihn sofort als Advanced User ein. Aus 0,2 FUE-Punkten wird schlagartig 1,0 FUE. Das frisst Ihr Kontingent im Hintergrund unbemerkt auf und führt im nächsten SAP-Audit (Digital Audit) zu teuren Nachzahlungsforderungen.
Wichtig: Das FUE-Modell gilt nicht automatisch für On-Premise- oder Private-Cloud-Verträge. Prüfen Sie, welches Modell in Ihrem Vertrag steht.
In der Cloud kaufen Sie keine dauerhafte Lizenz, sondern mieten ein Nutzungsrecht für eine definierte Laufzeit – typischerweise ein bis drei Jahre. Das hat mehrere Konsequenzen:
Kein Eigentum: Läuft der Vertrag aus und verlängern Sie nicht, erlischt das Nutzungsrecht sofort. On-Premise-Lizenzen dagegen gehören Ihnen dauerhaft – auch wenn der Wartungsvertrag endet.
Laufendes Monitoring statt Jahresvermessung: SAP überwacht Cloud-Systeme kontinuierlich. Es gibt keine einmalige Jahresmessung wie bei On-Premise. Überschreitungen werden zeitnah erkannt und führen zu Nachlizenzierungsforderungen.
Automatische Updates: Cloud-Systeme werden von SAP laufend aktualisiert. Das kann neue Funktionen aktivieren – und damit neue Lizenzpflichten auslösen, ohne dass Sie aktiv etwas tun.
Weniger Verhandlungsspielraum: Die Preismodelle in der Cloud sind stärker standardisiert als bei klassischen On-Premise-Verträgen. Rabattverhandlungen sind möglich, aber der Spielraum ist geringer.
Für Mittelstandsunternehmen, die aus der On-Premise-Welt kommen, ist der Wechsel in die Cloud ein kultureller Bruch: Lizenzmanagement wird vom Jahresprojekt zur laufenden Aufgabe.
Ein Subscription-Modell bedeutet: Sie zahlen eine wiederkehrende Gebühr – monatlich oder jährlich – für das Nutzungsrecht an der Software. Klingt simpel, hat aber weitreichende Konsequenzen.
Abhängigkeit steigt: Bei On-Premise haben Sie die Software gekauft. Sie können sie – theoretisch – weiterbetreiben, auch wenn SAP keine Wartung mehr anbietet. Bei Subscription endet das Nutzungsrecht mit dem Vertrag. SAP weiß das und nutzt es bei Verlängerungsverhandlungen.
Preiserhöhungen bei Renewal: SAP hat in der Vergangenheit bei Vertragsverlängerungen die Preise erhöht. Im Subscription-Modell ist das strukturell einfacher als bei Einmalkäufen, weil der Kunde gezwungen ist zu verlängern, wenn er die Software weiter nutzen will.
Mengenflexibilität nach unten: Ein Vorteil von Subscriptions ist, dass Sie bei Verlängerungen Mengen reduzieren können – anders als bei On-Premise, wo Sie gekaufte Lizenzen nicht zurückgeben können. Das ist real, aber die Hürden für Reduzierungen sind in der Praxis oft höher als im Vertrag suggeriert.
Lock-in durch Integration: Wer SAP-Cloud-Produkte tief in seine Prozesse integriert hat, kann nicht einfach wechseln. Das erhöht die Verhandlungsmacht von SAP bei Renewals erheblich.
GROW with SAP ist das Cloud-Angebot von SAP, das sich explizit an den Mittelstand richtet – im Unterschied zu Rise with SAP, das eher auf Großunternehmen und komplexe Migrationen ausgerichtet ist.
GROW with SAP basiert auf SAP ERP Cloud (früher: S/4HANA Cloud Public Edition) und bietet ein standardisiertes Einführungspaket mit vorkonfigurierten Prozessen, beschleunigten Implementierungsmethoden und einem festen Preisrahmen.
Was das lizenzrechtlich bedeutet:
Für Mittelstandsunternehmen, die neu auf SAP setzen oder einen klaren Schnitt machen wollen, kann GROW eine sinnvolle Option sein. Für Unternehmen mit bestehenden SAP-Landschaften und gewachsenen Prozessen ist es oft zu eingeschränkt.
Der strukturelle Unterschied ist fundamental: On-Premise bedeutet Kauf, Rise with SAP bedeutet Miete.
On-Premise:
Rise with SAP:
Ein häufiges Problem in der Praxis: SAP rechnet die Kosten für Rise with SAP sehr optimistisch (ohne zusätzliche Infrastrukturkosten etc.) und nimmt sehr hohe Kosten für Ihre Infrastruktur, Ihr Personal und Ihren internem Aufwand an. Das ergibt ein verzerrtes Bild. Ein seriöser TCO-Vergleich über fünf bis sieben Jahre ist Pflicht, bevor man unterschreibt.
Das ist eine der kritischsten Fragen beim Cloud-Wechsel – und eine, die SAP-Kunden oft zu spät stellen.
Grundsätzlich gilt: Ihre On-Premise-Lizenzen laufen weiter, solange Ihr Wartungsvertrag aktiv ist. Sie können sie nicht einfach in Cloud-Subscriptions umtauschen – zumindest nicht ohne explizite vertragliche Regelung.
Conversion-Rechte: In vielen Verträgen gibt es sogenannte Umtauschrechte, die erlauben, bestehende On-Premise-Lizenzen anteilig auf Cloud-Subscriptions anzurechnen. Diese Rechte sind an Fristen geknüpft und verfallen, wenn sie nicht genutzt werden. Wie hoch die Anrechnung ist, hängt vom Vertrag und von der Verhandlungsposition ab.
Was Sie vermeiden müssen: Doppelzahlung. Wer On-Premise-Wartung weiter zahlt und gleichzeitig eine Cloud-Subscription aufbaut, zahlt doppelt – manchmal über Jahre, weil die Migration länger dauert als geplant. Das ist im Mittelstand keine Seltenheit.
Empfehlung: Klären Sie vor jedem Cloud-Projekt, welche Conversion-Rechte Sie haben, bis wann sie gelten und wie Sie die Transition strukturieren, um Doppelkosten zu minimieren. Zumindest eine stufenweise Stilllegung der On-Premise-Lizenzen und deren Wartung sollte vereinbart werden.
In On-Premise-Systemen war Lizenzmanagement traditionell eine Jahresaufgabe: einmal vermessen, Ergebnis an SAP melden, fertig. In der Cloud ist das grundlegend anders.
SAP hat in Cloud-Systemen direkten Zugriff auf Nutzungsdaten und überwacht diese laufend. Überschreitungen werden nicht erst beim nächsten Audit sichtbar, sondern zeitnah. Das hat direkte Konsequenzen:
Für Lizenzverantwortliche bedeutet das eine spürbare Mehrbelastung im laufenden Betrieb – sofern keine geeigneten Tools und Prozesse etabliert sind.
SAP betreibt neben S/4HANA eine Vielzahl weiterer Cloud-Produkte, die eigenständig lizenziert werden und in vielen Unternehmen bereits im Einsatz sind – oft ohne dass der Lizenzverantwortliche den vollen Überblick hat.
Die wichtigsten:
Warum das lizenzrelevant ist: Jedes dieser Produkte hat eine eigene Vertragsstruktur, eigene Metriken und eigene Compliance-Anforderungen. Wer sie nicht aktiv managed, zahlt für ungenutzte Kapazitäten oder riskiert Überschreitungen. Oft sind diese Produkte von verschiedenen Abteilungen eingeführt worden – ohne zentrales Lizenzmanagement.
Die SAP Business Technology Platform (BTP) ist das technologische Fundament der modernen SAP-Welt – gewissermaßen das Schweizer Taschenmesser für Integration, Erweiterung und Datenmanagement. Seit SAP die Strategie „Clean Core“ (also den SAP-Standard in S/4HANA unangetastet zu lassen) aggressiv vorantreibt, führt an der BTP kaum noch ein Weg vorbei.
Sie ersetzt die klassischen kundeneigenen Z-Entwicklungen im Core und verlagert diese in die Cloud.
Die 4 Säulen der SAP BTP
Die Plattform bündelt weit über 90 verschiedene Services, die sich im Wesentlichen auf vier Kernbereiche verteilen:
Im Gegensatz zum klassischen ERP-System lizenziert die SAP BTP technisch metrisch und verbrauchsabhängig, nicht primär nach namentlich genannten Nutzern (Named Users). Lizenzrelevant wird das Ganze in folgenden Szenarien:
Beim Umstieg auf S/4HANA (Clean-Core-Strategie)
Sobald individuelle Geschäftsprozesse abgebildet werden sollen, die der S/4HANA-Standard nicht hergibt, dürfen diese nicht mehr als klassische Modifikation im Core programmiert werden. Jede Side-by-Side-Erweiterung auf der BTP erzeugt Cloud-Verbrauch (Compute-Leistung, Speicher, API-Aufrufe).
Bei jeglicher Systemintegration
Wer S/4HANA Cloud einführt, nutzt für die Anbindung von Non-SAP-Systemen fast immer die SAP Integration Suite. Lizenzrelevant wird hier die Anzahl der genutzten Mandanten (Tenants) sowie das Daten- bzw. Nachrichtenvolumen (Messages).
Indirekte Nutzung durch Standard-Cloud-Apps
Viele moderne SAP-Cloud-Anwendungen (wie SuccessFactors, Ariba oder IBP) nutzen im Hintergrund unbemerkt BTP-Kapazitäten für das Event-Processing oder den Datenaustausch. Auch das greift auf die BTP-Lizenzierung zurück.
Die Abrechnung erfolgt im Wesentlichen über sogenannte Capacity Units (CU) – eine universelle Währung der SAP, mit der die verschiedenen Services intern verrechnet werden. Dafür gibt es drei primäre Vertragsmodelle:
| Modell | Funktionsweise | Für wen geeignet? | Risiko / Vorteil |
|---|---|---|---|
| Subscription (Abonnement) | Feste Services werden für eine feste Laufzeit zu einem Fixpreis abonniert (z. B. 3 Jahre Integration Suite). | Unternehmen mit absolut vorhersehbarem, konstantem Bedarf. | Vorteil: Hohe Budgetsicherheit. Risiko: Unflexibel; ungenutzte Kapazitäten verfallen (Überlizenzierung). |
| Pay-As-You-Go (PAYG) | Zugriff auf fast alle Services ohne finanzielle Mindestverpflichtung. Abgerechnet wird monatlich exakt nach Verbrauch. | Einsteiger, PoCs (Proof of Concepts) oder unvorhersehbare Projektphasen. | Vorteil: Kein finanzielles Risiko vorab. Risiko: Höchste Unit-Preise (keine Rabatte). |
| CPEA / BTPEA (Cloud Platform Enterprise Agreement) | Das Unternehmen kauft im Voraus ein jährliches Guthaben (Prepaid-Pool) an Capacity Units. Der tatsächliche Verbrauch wird monatlich dagegen gerechnet. | Etablierte Enterprise-Kunden mit strategischer BTP-Nutzung. | Vorteil: Attraktive Rabatte (oft 20–40 % auf den Listenpreis). Risiko: „Use it or lose it“ – ungenutztes Guthaben verfällt am Jahresende. |
Da die BTP-Kosten durch den tatsächlichen Ressourcenverbrauch explodieren können, ist ein aktives FinOps-Management unerlässlich. Typische Fallstricke in der Praxis sind:
Ein realistischer Kostenvergleich zwischen On-Premise und Cloud ist komplexer, als SAP-Verkaufspräsentationen vermuten lassen. Wer nur die Subscription-Kosten mit der bisherigen Wartungsgebühr vergleicht, rechnet falsch.
Was in den TCO-Vergleich gehört:
On-Premise-Seite: Wartungsgebühren, Infrastrukturkosten (Server, Betrieb, Strom), interne IT-Personalkosten, Kosten für Upgrades und Projekte, Kosten für Eigenentwicklungen und deren Wartung.
Cloud-Seite: Subscription-Kosten, Implementierungskosten für die Migration, Kosten für Prozessanpassungen (weil Eigenentwicklungen wegfallen), laufende Kosten für Add-ons und Integrationen, erhöhter Aufwand für laufendes Lizenzmanagement.
Typische Fallstricke:
Lassen Sie sich von SAP und Implementierungspartnern konkrete Zahlen geben – und prüfen Sie diese kritisch. Ein unabhängiger TCO-Vergleich über fünf bis sieben Jahre ist die Basis für eine fundierte Entscheidung.
Nutzen Sie die Expertise von unabhängigen Lizenzberatern, um eine korrekte ROI-Betrachtung durchzuführen.
Ein Cloud-Vertrag ist eine langfristige Bindung mit erheblichen finanziellen Konsequenzen. Diese Fragen sollten vor der Unterschrift geklärt sein:
Zur Laufzeit und Flexibilität:
Zu den Kosten:
Zur Compliance:
Zur Migration:
Zum Support:
Wer diese Fragen nicht vor der Unterschrift klärt, klärt sie während der Vertragslaufzeit – dann aber mit deutlich weniger Verhandlungsmacht.
Eine SAP-Lizenzrechnung wirkt auf den ersten Blick simpel: Positionen, Mengen, Preise. In der Praxis steckt der Teufel im Detail.
Typische Bestandteile sind: Named-User-Lizenzen nach Typ und Anzahl, Engine-Lizenzen mit ihren jeweiligen Metriken (z. B. Anzahl Belege, Umsatzvolumen), Wartungsgebühren auf den Lizenzgesamtwert, sowie gegebenenfalls Subscription-Positionen für Cloud-Komponenten.
Worauf Sie achten sollten:
Der Listenpreis ist der offizielle, von SAP veröffentlichte Preis pro Lizenzeinheit. Er dient als Ausgangsbasis für Verhandlungen – ist aber faktisch selten der Preis, den jemand tatsächlich zahlt.
Der „Straßenpreis“ (in der Praxis eher: der verhandelte Preis) ergibt sich aus Rabatten, die im individuellen Vertrag vereinbart wurden. Diese Rabatte können erheblich sein und variieren stark je nach Verhandlungsgeschick, Vertragsvolumen, Zeitpunkt im SAP-Geschäftsjahr und strategischer Bedeutung des Kunden für SAP.
Was das praktisch bedeutet:
Kennen Sie Ihren effektiven Rabattsatz für jede Lizenzkategorie. Ohne diese Information verhandeln Sie bei jedem Nachkauf aus einer schwachen Position.
SAP berechnet für On-Premise-Lizenzen eine jährliche Wartungsgebühr, die beim Enterprise-Support üblicherweise bei rund 22 Prozent des Lizenzwerts liegt.
Die entscheidende Frage ist: 22 Prozent von was?
Diese Frage entscheidet über erhebliche Summen über die Vertragslaufzeit. Bei älteren Verträgen ist die Berechnungsgrundlage oft unklar formuliert oder wurde über die Jahre durch Nachträge verändert. Eine genaue Prüfung der Wartungsklausel im Vertrag – inklusive aller Nachträge – ist daher unerlässlich.
Zusätzlich ist im Supportvertrag in der Regel eine jährliche Erhöhung der Wartung vorgesehen. Beträgt diese z. B. 3 %, steigt die Wartung nach dem ersten Jahr auf 22,66 % und nach 5 Jahren bereits auf 25,5 %.
Die jährliche Supportgebühr ist an den kumulierten Wert der erworbenen On-Premises-Lizenzen gekoppelt. SAP ruft standardmäßig folgende Sätze auf:
Wichtig zu wissen: In den letzten Jahren hat SAP inflationsbedingte Anpassungsklauseln gezogen (z. B. Steigerungen um bis zu 5 % basierend auf dem IT-Dienstleistungsindex). Diese Erhöhungen betreffen beide Modelle gleichermaßen.
Wer 22 % statt 18 % bezahlt, muss prüfen, ob die Mehrleistungen des Enterprise Supports die Zusatzkosten rechtfertigen. In der Praxis zahlen viele Unternehmen den Aufpreis, ohne die exklusiven Features überhaupt zu nutzen.
Was bietet Enterprise Support mehr als Standard?
Der Wechsel von ECC nach S/4HANA ist nicht nur ein technisches Migrationsprojekt, sondern hat eine eigenständige Kostenstruktur, die häufig unterschätzt wird. Folgende Kostenarten sollten Sie einplanen:
Lizenzkosten: Conversion bestehender ECC-Lizenzen in S/4HANA-Lizenztypen. Je nach Vertrag gibt es Umtauschrechte – diese sind aber meist nicht 1:1, sondern beinhalten Aufzahlungen („Delta-Lizenzkosten“).
Wartungskosten: Während der Migrationsphase laufen oft beide Wartungsverträge parallel – für das alte ECC-System und für die neue S/4HANA-Umgebung. Zwar wird die ECC-Umgebung in der Regel kostenfrei mit gewartet, aber für Third-Party-Datenbanken gilt dies oft nicht.
Implementierungskosten: Beratungsleistungen für die technische Migration, Anpassung von Eigenentwicklungen (Custom Code), Datenmigration, Tests.
Schulungskosten: S/4HANA bringt eine neue Bedienoberfläche (SAP Fiori) und teilweise veränderte Prozesse – Schulungsaufwand für die Belegschaft ist nicht zu unterschätzen.
Infrastrukturkosten: S/4HANA läuft auf der In-Memory-Datenbank HANA, die andere Hardwareanforderungen hat als die Datenbanken unter ECC.
Eine grobe Faustregel aus der Praxis: Die Lizenzkosten für die Conversion sind oft nur ein kleinerer Teil der Gesamtkosten – die größeren Posten liegen bei Implementierung und Custom-Code-Anpassung.
Conversion-Rechte (auch Umtauschrechte genannt) erlauben es, bestehende SAP-Lizenzen – meist ECC-Lizenzen – auf neue Lizenztypen, etwa für S/4HANA, anzurechnen, statt diese komplett neu zu kaufen.
Wie funktioniert das in der Praxis? Das hängt vom gewählten Migrationspfad ab:
Verhandlungstipp: Verlassen Sie sich niemals auf mündliche Zusagen im Vertriebsgespräch. Conversion-Rechte, Anrechnungswerte und die genaue Zuordnung (Mapping-Tabellen von alt zu neu) müssen zwingend vor Projektschritt in einem separaten, schriftlichen Nachtrag (Addendum) fixiert werden.
Der Zeitpunkt beeinflusst Ihre Verhandlungsposition erheblich. Mehrere Faktoren spielen eine Rolle:
SAP-Geschäftsjahresende: SAP hat – wie viele Softwareunternehmen – ein Geschäftsjahr mit Quartalsabschlüssen, das Ende Dezember endet. Vertriebsteams stehen unter Druck, Deals bis zum Quartals- oder Jahresende abzuschließen. Verhandlungen in diesen Zeiträumen (insbesondere Q4) können für Kunden vorteilhafter sein – SAP ist eher bereit, Zugeständnisse zu machen.
Vor Vertragsverlängerung, nicht währenddessen: Wenn Ihr Wartungsvertrag oder Ihre Cloud-Subscription in wenigen Monaten ausläuft, sinkt Ihre Verhandlungsmacht rapide. Beginnen Sie Verhandlungen mindestens sechs bis zwölf Monate vor Ablauf.
Vor größeren Projekten: Wenn Sie eine S/4HANA-Migration, einen Cloud-Wechsel oder eine größere Erweiterung planen, ist das ein guter Zeitpunkt für Verhandlungen – SAP hat Interesse an dem Zusatzgeschäft und ist eher bereit, an anderer Stelle Zugeständnisse zu machen.
Nicht während eines laufenden Audits: Wenn SAP gerade eine Lizenzprüfung durchführt oder Compliance-Themen offen sind, ist Ihre Position geschwächt. Klären Sie Compliance-Fragen möglichst vor Beginn von Preisverhandlungen.
Es gibt mehr Verhandlungsspielraum als viele Kunden annehmen – aber der Spielraum variiert je nach Position im Vertrag.
Rabatte auf Listenpreise: Der offensichtlichste Hebel. Rabattsätze sind verhandelbar und hängen von Volumen, strategischer Bedeutung und Timing ab.
Anrechnung ungenutzter Lizenzen: Wenn Sie mehr Lizenzen gekauft haben als Sie nutzen („Shelfware“), kann das als Verhandlungsmasse für andere Themen dienen – etwa für die Umwandlung in andere Lizenztypen.
Wartungsbasis: Die Berechnungsgrundlage (Listenpreis vs. Vertragspreis) für die Wartung ist verhandelbar – insbesondere bei größeren Vertragsänderungen.
Sonderkonditionen bei Migrationsprojekten: Conversion-Quoten, Übergangsfristen für Doppelnutzung (On-Premise und Cloud parallel), Preisgarantien für Folgejahre.
Vertragslaufzeiten und Preisanpassungsklauseln: Längere Laufzeiten können niedrigere Preise bedeuten, schränken aber Flexibilität ein. Preisanpassungsklauseln (z. B. maximale jährliche Erhöhung) sind verhandelbar und sollten in jedem Vertrag stehen.
Was meist nicht verhandelbar ist: Die grundsätzliche Produktstruktur, FUE-Gewichtungen im Cloud-Modell oder generelle Geschäftsbedingungen außerhalb des kommerziellen Teils. Den Gesamtumsatz, den man mit SAP hat, kann man nur selten nach unten verhandeln. Es lässt sich nur das Wachstum begrenzen und die Menge an Lizenzen und Services erhöhen, die man dafür bekommt.
Shelfware bezeichnet Lizenzen, die ein Unternehmen gekauft hat, aber nicht oder nur teilweise nutzt – sie liegen quasi „im Regal“.
Wie entsteht Shelfware? Häufige Ursachen sind: Lizenzen wurden für ein geplantes Wachstum gekauft, das nicht eintrat. Mitarbeitende, für die Lizenzen gekauft wurden, haben das Unternehmen verlassen, die Lizenzen wurden aber nicht freigegeben. Projektphasen mit temporär höherem Lizenzbedarf sind vorbei, die Lizenzen wurden aber nicht reduziert. Engine-Lizenzen wurden für Funktionen gekauft, die nie produktiv eingesetzt wurden. Produkte wurden vom SAP-Vertrieb zu Sonderkonditionen in einen Vertrag aufgenommen, ohne dass ein Bedarf existiert.
Welche Auswirkungen hat das?
Eine regelmäßige Inventur Ihrer Lizenzbestände gegen die tatsächliche Nutzung ist der erste Schritt, um Shelfware zu identifizieren und finanziell zu bewerten.
Kostenreduktion bei SAP-Lizenzen bedeutet nicht automatisch, dass Mitarbeitende weniger dürfen. Mehrere Stellschrauben wirken ohne funktionale Einschränkungen:
Lizenztyp-Optimierung: Viele User sind in zu teure Lizenztypen eingestuft, weil Rollen historisch gewachsen sind. Eine Analyse von Nutzung und Berechtigung deckt oft erhebliches Einsparpotenzial auf, ohne dass sich an der tatsächlichen Arbeit etwas ändert.
Bereinigung inaktiver User: Konten von ausgeschiedenen Mitarbeitenden oder ungenutzte technische Accounts, die fälschlich einen Lizenztyp tragen, verursachen unnötige Kosten.
Rollenbereinigung: Überflüssige Berechtigungen, die niemand mehr nutzt, können entfernt werden – das senkt nicht nur Lizenzkosten, sondern verbessert auch die IT-Sicherheit (Stichwort: Segregation of Duties).
Engine-Nutzung prüfen: Manche Engines werden lizenziert, aber kaum genutzt. Eine Prüfung kann zeigen, ob eine Reduktion oder ein anderer Vertragsbaustein günstiger ist.
Shelfware identifizieren: Ungenutzte Lizenzen verursachen Wartungskosten ohne Gegenwert.
Wichtig: Diese Maßnahmen wirken sich nicht negativ auf die tägliche Arbeit aus – sie korrigieren lediglich eine über Jahre gewachsene Diskrepanz zwischen Lizenzierung und tatsächlichem Bedarf.
Aber: Die Optimierung wirken sich bei Subscriptions erst nach dem nächsten Renewal aus. Bei Kauflizenzen im On-Premise-Bereich helfen Ihnen diese Optimierungen nur bei Nachkäufen weniger (Re-Harvesting) oder günstiger (Anrechnung) einzukaufen.
Eine Nachzahlung entsteht, wenn eine SAP-Vermessung ergibt, dass mehr Lizenzen genutzt werden als vertraglich erworben wurden – also eine Unterlizenzierung besteht.
Wie wird die Nachzahlung berechnet? Grundsätzlich wird die Differenz zwischen genutzten und lizenzierten Einheiten zu Listenpreisen berechnet – nicht zu den ursprünglich verhandelten Rabattpreisen. Das ist ein zentraler Punkt: Auch wenn Sie beim ursprünglichen Kauf erhebliche Rabatte erhalten haben, wird die Nachlizenzierung in der Regel zum aktuellen Listenpreis fällig.
Welche Faktoren beeinflussen die Höhe?
Was Sie tun können: Eine Nachzahlungsforderung ist nicht automatisch final. Es gibt in der Regel Verhandlungsspielraum – etwa über alternative Lizenztypen, Bündelungen mit anderen Vertragsthemen oder eine Reduzierung durch nachträgliche Optimierung (z. B. Bereinigung von Berechtigungen vor dem offiziellen Nachweis). Voraussetzung dafür ist, dass Sie die Ergebnisse der Vermessung verstehen und kritisch hinterfragen können, bevor Sie eine Forderung akzeptieren.
SAP erhöht regelmäßig die Listenpreise für seine Produkte. Wie sich das auf Ihren bestehenden Vertrag auswirkt, hängt von der Vertragsstruktur ab.
Bei On-Premise-Lizenzen: Der einmal gekaufte Lizenzbestand ändert sich nicht – Sie zahlen nicht automatisch mehr für bereits gekaufte Lizenzen. Kritisch wird es jedoch bei der Wartungsberechnung: Wenn die Wartung auf Basis des aktuellen Listenpreises berechnet wird, steigen Ihre Wartungskosten mit jeder Preiserhöhung – ohne zusätzlichen Gegenwert.
Bei Nachkäufen: Zusätzliche Lizenzen, die Sie nach einer Preiserhöhung kaufen, unterliegen den neuen Preisen – sofern Ihr Vertrag keine Preisgarantie für Nachkäufe enthält.
Bei Cloud-Subscriptions: Hier ist der Effekt direkter. Bei Vertragsverlängerungen können neue, höhere Preise zur Anwendung kommen – sofern keine Preisanpassungsklausel mit einer Obergrenze (Cap) vereinbart wurde.
Was Sie tun können: Verhandeln Sie Preisanpassungsklauseln mit einer maximalen jährlichen Erhöhung (z. B. gekoppelt an einen Index) – sowohl für Wartung als auch für Cloud-Subscriptions. Ohne solche Klauseln sind Sie Preiserhöhungen weitgehend ausgesetzt.
Aus der Praxis lassen sich einige wiederkehrende Muster identifizieren, die besonders häufig zu überhöhten Lizenzkosten führen:
Zu breite Rollen für Führungskräfte: Führungskräfte erhalten oft Rollenpakete, die weit über ihren tatsächlichen Bedarf hinausgehen – mit der Begründung, sie „könnten ja mal“ Zugriff brauchen. Das treibt Lizenztypen unnötig hoch.
Projektrollen, die nie zurückgenommen werden: Während eines Projekts erhalten Mitarbeitende erweiterte Berechtigungen. Nach Projektende werden diese selten wieder entzogen.
Dauerhaft aktive Firefighter-Zugänge: Notfallzugänge mit erweiterten Rechten, die eigentlich nur temporär für Störungsbehebung gedacht sind, bleiben oft dauerhaft aktiv und tragen einen entsprechenden Lizenztyp.
Sammelrollen „für alle Fälle“: Pauschale Rollenpakete, die viele Funktionen abdecken, „damit man nicht ständig nachfragen muss“ – diese führen regelmäßig zu Überlizenzierung.
Falscher Default-Lizenztyp: Wenn der systemweite Standard-Lizenztyp zu hoch eingestellt ist, werden neue User automatisch teuer eingestuft, selbst wenn ihr tatsächlicher Bedarf gering ist.
Fehlender User-Lifecycle-Prozess: Ohne klaren Prozess für Ein-, Um- und Austritte sammeln sich über Jahre Karteileichen und falsch zugeordnete Lizenztypen an.
Diese Muster sind kein technisches, sondern ein organisatorisches Problem – und entsprechend auch organisatorisch zu lösen.
Die Verhandlung mit SAP bei einer verteilten Unternehmensstruktur erfordert eine klare vertragliche Klammer. Ohne die richtigen Klauseln riskieren Sie, dass Tochtergesellschaften rechtlich wie externe Dritte behandelt werden oder dass Kosten für ungenutzte Standorte explodieren.
Verhandeln Sie zwingend eine präzise definierte Affiliate-Klausel im Rahmenvertrag. Diese regelt, welche Tochtergesellschaften die Lizenzen überhaupt nutzen dürfen.
„`
„`
Kaufen Sie Lizenzen und Subscriptions grundsätzlich zentral über die Holding oder die Muttergesellschaft ein (Zentralvertrag).
„`
„`
Wenn Ihre Standorte oder Töchter im Ausland sitzen, greift die sogenannte Territory-Klausel der SAP. Standardmäßig dürfen Lizenzen oft nur in dem Land genutzt werden, in dem sie gekauft wurden.
„`
„`
Ein fataler und teurer Fallstrick liegt bei Engine-Lizenzen oder Cloud-Services, die nach globalen Metriken wie Revenue (Umsatz) oder Total Employees (Mitarbeiteranzahl) abgerechnet werden.
„`
„`
Was passiert, wenn eine Tochtergesellschaft verkauft wird? Ohne vertragliche Vorsorge verbleiben die Lizenzen bei der Mutter (wo sie nun brachliegen), während die verkaufte Tochter sofort komplett neue, teure Lizenzen bei SAP kaufen muss.
„`
Verhandlungstipp: Nutzen Sie die Internationalität als Hebel. SAP vertreibt ihre Software über regionale Vertriebsgesellschaften (z. B. SAP Deutschland, SAP America). Die länderspezifischen Vertriebsteams stehen im internen Wettbewerb. Wenn Sie als Konzern signalisieren, den Vertrag im Zweifel über die ausländische Holding abzuschließen, erhöht das den Verhandlungsdruck auf Ihr lokales SAP-Vertriebsteam massiv.
Die Begriffe „Vermessung“ und „Audit“ werden oft synonym verwendet, beschreiben aber unterschiedliche Dinge.
Vermessung bezeichnet den technischen Prozess, bei dem lizenzrelevante Daten aus Ihren SAP-Systemen erhoben werden – typischerweise mit dem Tool LAW (License Administration Workbench) oder dessen Nachfolger. Die Vermessung zählt User, ordnet Lizenztypen zu und erfasst Engine-Metriken zu einem bestimmten Stichtag.
Audit (auch „System Measurement“ oder formale Lizenzprüfung genannt) ist der vertragliche Prozess, bei dem SAP von Ihnen die Ergebnisse der Vermessung einfordert, diese prüft und gegebenenfalls Nachzahlungsforderungen ableitet.
Der Unterschied ist wichtig: Die Vermessung führen Sie selbst durch – Sie haben Kontrolle über den Prozess, die Vorbereitung und die Interpretation der Ergebnisse. Das Audit ist der Moment, in dem Sie diese Ergebnisse SAP gegenüber vertreten müssen. Eine gute Vorbereitung auf das Audit beginnt also lange vor dem eigentlichen Audit – nämlich bei einer gut vorbereiteten, selbst durchgeführten Vermessung.
SAP hat vertraglich das Recht, jährlich eine Vermessung anzufordern – dieses Recht ist in praktisch allen On-Premise-Lizenzverträgen verankert. In der Praxis fordert SAP nicht zwingend jedes Jahr aktiv eine Abgabe, aber die Möglichkeit besteht durchgehend.
Wie läuft das ab? Üblicherweise erhalten Sie eine schriftliche Aufforderung mit einer Frist – in der Praxis häufig um die 30 Tage – innerhalb derer Sie die Vermessungsergebnisse einreichen müssen.
Wie bereiten Sie sich vor?
Wer unvorbereitet in ein Audit geht, hat in 30 Tagen kaum Zeit, Optimierungspotenziale zu identifizieren und umzusetzen – die Zahlen sind dann, was sie sind.
Vertraglich ist die Mitwirkungspflicht bei Vermessungen in der Regel klar geregelt – eine Nichteinhaltung der Frist ist ein Vertragsverstoß.
Mögliche Konsequenzen:
Was Sie tun können, wenn die Frist eng wird: Kommunizieren Sie proaktiv mit SAP. Eine Fristverlängerung ist in der Regel möglich, wenn Sie nachvollziehbare Gründe nennen und einen konkreten Abgabetermin in Aussicht stellen. Schweigen oder Ignorieren ist die schlechteste Option.
Die Übermittlungspflicht ist auf lizenzrelevante Daten beschränkt – nicht auf alle Unternehmensdaten.
Was typischerweise übermittelt wird:
Was nicht automatisch übermittelt werden muss:
Wichtig: Wenn SAP über das vertraglich Vereinbarte hinaus Daten anfordert – etwa detaillierte Systemzugriffsprotokolle oder interne Organisationsstrukturen – sollten Sie prüfen, ob dafür eine vertragliche Grundlage besteht, bevor Sie diese herausgeben. Im Zweifel: Rückfrage stellen, nicht automatisch alles liefern, was angefordert wird.
Der Default-Lizenztyp ist die systemweite Voreinstellung, die SAP einem User zuweist, wenn im Benutzerstamm kein expliziter Lizenztyp gepflegt wurde.
Warum ist das kritisch?
Was Sie tun sollten: Prüfen Sie regelmäßig, welcher Default-Lizenztyp in Ihrem System eingestellt ist, und stellen Sie sicher, dass dieser zu Ihrer tatsächlichen User-Struktur passt. Sie sollten vermeiden, dass User über den Default-Lizenztyp vermessen werden. Jedem Dialog-User sollte explizit ein korrekter Lizenztyp zugewiesen werden. Nur so ist eine Fehllizenzierung zu vermeiden. Mit Hilfe von Auswertungen im SAP können Sie alle User ermitteln, die den Default-Lizenztyp verwenden.
„Inaktiv“ ist keine feste, von SAP vorgegebene Definition – es ist eine Regel, die Sie als Unternehmen selbst festlegen und konsequent anwenden müssen.
Wie legen Sie die Regel fest? Typische Ansätze sind zeitbasiert – etwa: Ein Account, der seit 90 Tagen keinen Login hatte, gilt als inaktiv. Die genaue Frist hängt von Ihrer Unternehmenspraxis ab – manche Rollen (z. B. saisonale Mitarbeitende) erfordern längere Fristen.
Was tun Sie mit inaktiven Accounts?
Entscheidend ist die Dokumentation: Legen Sie schriftlich fest, ab wann ein Account als inaktiv gilt, wer für die Umsetzung verantwortlich ist und in welchem Rhythmus die Prüfung erfolgt. Eine Regel, die nur „irgendwo in einem Prozessdokument“ steht, aber nicht gelebt wird, hilft im Audit nicht.
Doppelte User und technische User verzerren Vermessungsergebnisse auf unterschiedliche Weise – und müssen unterschiedlich behandelt werden.
Doppelte User entstehen typischerweise, wenn ein Mitarbeitender mehrere Accounts hat – etwa einen für das Produktivsystem und einen mit einer abweichenden Kennung für ein anderes System, ohne dass dies bewusst gesteuert wird, oder wenn bei einem Rollenwechsel ein neuer Account angelegt wird, ohne den alten zu deaktivieren. Jeder dieser Accounts kann separat einen Lizenztyp tragen – Sie zahlen also doppelt für eine Person.
Technische User sind Accounts, die nicht von Menschen, sondern von Schnittstellen, Hintergrundjobs oder automatisierten Prozessen genutzt werden. Sie benötigen in der Regel keinen kostenpflichtigen Lizenztyp – die Zuordnung sollte leer bleiben. Wird einem technischen Account fälschlich ein Lizenztyp zugeordnet, zählt dieser in der Vermessung mit, ohne dass ein realer Nutzungsbedarf dahintersteht.
Was Sie tun sollten:
Im Compliance-Kontext geht es weniger um die theoretische Definition von Lizenztypen, sondern um die nachweisbare und auditsichere Zuordnung im laufenden Betrieb.
Die zentrale Herausforderung: Das Unterlizenzierungs-Risiko
Das echte Compliance-Risiko bei einem Audit entsteht durch Unterlizenzierung: Wenn ein User als günstiger Functional– oder Productivity-User deklariert ist, im System aber Rechte besitzt oder nutzt, die vertraglich eine Professional-Lizenz erfordern, drohen massive Nachzahlungen zum Listenpreis. Eine Überlizenzierung (teure Lizenz für einen User mit minimalen Rechten) wird von SAP beim Audit hingegen klaglos akzeptiert.
Eine pauschale Zuordnung nach dem Motto „In der Abteilung X reicht für alle die günstigste Lizenz“ hält keinem Audit stand. Wie die Zuordnung erfolgen muss, hängt strikt vom Vertrag und der Systemgeneration ab.
Der fundamentale Paradigmenwechsel: ECC vs. S/4HANA
Um eine Nachlizensierung zu vermeiden, müssen Sie die beiden Systemwelten methodisch sauber trennen:
Das zentrale Vermessungstool der SAP, die License Administration Workbench (LAW / LAW 2.0), misst nicht die tatsächliche Nutzung oder Aktivität im System. Die LAW konsolidiert lediglich die in den einzelnen Systemen manuell oder per Skript hinterlegten, zugewiesenen Lizenztypen der User. Die Compliance-Pflicht, diese Typen im Vorfeld sauber nach den jeweils gültigen ECC- oder S/4HANA-Vertragsregeln zu pflegen, liegt komplett beim Kunden.
Praxistipp: Dokumentieren Sie keine manuellen User-Listen, sondern definieren und pflegen Sie ein zentrales Lizenz-Regelwerk (Klassifizierungsmatrix). In S/4HANA-Umgebungen muss dieses Regelwerk zwingend mit Ihrem Berechtigungsmanagement (Identity & Access Management) verknüpft sein. Rollen müssen so geschnitten werden, dass sie keine „unbeabsichtigten“ höherwertigen Berechtigungen enthalten, die automatisch eine teure Professional-Lizenz triggern. Bei einem Audit weisen Sie SAP gegenüber nicht den einzelnen User nach, sondern die Stringenz Ihres dokumentierten, berechtigungsbasierten Regelprozesses.
Berechtigungen sind ein zentraler Faktor für die Lizenztyp-Zuordnung – insbesondere in S/4HANA, wo die Lizenzeinstufung stärker über Rollen und Berechtigungsobjekte erfolgt als über reine Transaktionsnutzung.
Das Grundproblem: Rollen wachsen über die Zeit. Ein Mitarbeitender bekommt für ein Projekt zusätzliche Berechtigungen, die nach Projektende nicht wieder entzogen werden. Ein Stellenwechsel führt zu neuen Rollen, die alten bleiben aber bestehen „für den Fall, dass“. Über Jahre summiert sich das zu Rollenpaketen, die weit über den tatsächlichen Bedarf hinausgehen – mit direkter Konsequenz für den Lizenztyp.
Wie oft sollten Rollen überprüft werden?
Was eine Rollenüberprüfung umfasst:
Ausnahmen von der Regel „ein User = ein Account = ein Lizenztyp“ kommen in der Praxis vor – sind aber lizenzrechtlich heikel und müssen aktiv gemanagt werden.
Typisches Beispiel: In der Logistik nutzen mehrere Mitarbeitende denselben Scanner oder dasselbe Terminal, technisch hinter einem einzigen Account. Formal ist das eine gemeinsame Nutzung eines Named-User-Accounts durch mehrere Personen – was den Lizenzbedingungen widerspricht, da Named User an eine Person gebunden sind.
Wie gehen Sie damit um?
Die wichtigste Regel: Ausnahmen dürfen nicht zur Dauerlösung werden, ohne dass sie regelmäßig hinterfragt werden. Wenn Ausnahmen zur Regel werden, ist das meist ein Symptom für fehlende Prozesse bei der Rollen- und User-Verwaltung – nicht primär ein Lizenzproblem, aber eines mit direkter Lizenzkonsequenz.
Engines sind Lizenzbestandteile, die nicht an einzelne User gebunden sind, sondern an funktionale Nutzung oder technische Kennzahlen – etwa die Anzahl verarbeiteter Dokumente, das Transaktionsvolumen in einem bestimmten Modul, oder eine unternehmensweite Kennzahl wie Umsatz oder Mitarbeiterzahl.
Warum werden sie übersehen? Aus mehreren Gründen:
Die Konsequenz: Engines werden bei der Lizenzplanung oft erst dann zum Thema, wenn die jährliche Systemvermessung (LAW) eine massive Überschreitung aufzeigt. Da die Funktion zu diesem Zeitpunkt aber bereits genutzt wurde und die Daten historisch in der Datenbank festgeschrieben sind, ist die Compliance-Verletzung für die Vergangenheit nicht mehr heilbar. Die teure Nachzahlung zum Listenpreis ist dann bereits fällig.
Praxistipp für das Lizenzmanagement: Schalten Sie in Ihrer Systemlandschaft neue Module, Business Functions oder erweiterte Standard-Features im Customizing erst dann frei, wenn die vertragliche Lizenzrelevanz geprüft wurde. Eine proaktive Engine-Übersicht, die mindestens vierteljährlich die vertraglichen Schwellenwerte gegen die technischen Zählerstände im System abgleicht, ist für ein risikofreies SAP-Lizenzmanagement unverzichtbar.
Der erste Schritt ist eine vollständige Bestandsaufnahme – nicht eine sofortige Detailprüfung.
Schritt 1: Liste erstellen. Welche Engines sind laut Ihrem Vertrag lizenziert oder potenziell relevant? Typische Beispiele sind Engines für Lagerverwaltung (Extended Warehouse Management), Transportmanagement, HR-Funktionen, oder spezifische Branchenlösungen.
Schritt 2: Belege sammeln. Für jede Engine: Welche Systemdaten zeigen die tatsächliche Nutzung? Gibt es Projektdokumentation, die zeigt, wann und warum die Engine eingeführt wurde? Was sagt der Vertrag zur vereinbarten Metrik und zum lizenzierten Volumen?
Schritt 3: Priorisieren nach Risiko und Kosten. Nicht jede Engine erfordert die gleiche Aufmerksamkeit. Priorisieren Sie nach: Wie hoch ist das finanzielle Volumen dieser Engine im Vertrag? Wie wahrscheinlich ist eine Überschreitung der vereinbarten Metrik, basierend auf dem Geschäftswachstum? Wie aufwendig ist die Datenerhebung für diese Engine?
Schritt 4: Details erst danach. Erst nachdem Sie wissen, welche Engines das größte Risiko oder Potenzial darstellen, lohnt sich eine detaillierte technische Analyse.
Dieser Top-down-Ansatz verhindert, dass Sie Zeit in die Detailanalyse einer Engine investieren, die finanziell kaum relevant ist, während eine andere mit erheblichem Risiko unbeachtet bleibt.
Indirekte Nutzung (oft auch Indirect Use oder Digital Access genannt) beschreibt eine Situation, in der lizenzrelevante Vorgänge oder Dokumente in einem SAP-System entstehen, ohne dass ein Mensch direkt über eine klassische SAP-Benutzeroberfläche (wie SAP GUI oder Fiori) interagiert hat.
Das klassische Szenario: Ein Kunde bestellt über einen externen Webshop oder ein Außendienstmitarbeiter erfasst einen Lead in einem Non-SAP-CRM (z. B. Salesforce). Die Daten fließen über eine API-Schnittstelle automatisch ins SAP-System und triggern dort die Anlage eines Kundenauftrags. Obwohl sich kein Mensch physisch in SAP eingeloggt hat, findet eine lizenzrelevante Nutzung statt.
SAP-Kunden stehen heute vor der Wahl zwischen zwei völlig unterschiedlichen Lizenzierungsphilosophien für Schnittstellen. Die Unterschiede unter Kostengesichtspunkten sind monumental:
| Kriterium | Das klassische Modell (Named User / Legacy) | Das neue Modell (Digital Access / Document Licensing) |
|---|---|---|
| Abrechnungsbasis | Köpfe in den Drittsystemen. Jeder Endnutzer des Fremdsystems (z. B. jeder Webshop-Kunde, jeder Lagerarbeiter am Partnersystem), der indirekt SAP-Daten triggert, benötigt theoretisch eine SAP-Named-User-Lizenz (meist Platform User). | Belege statt Köpfe. Es ist völlig egal, wie viele Menschen oder IoT-Geräte an das Fremdsystem angebunden sind. Lizenziert wird ausschließlich das Volumen der im SAP-System erzeugten Dokumente. |
| Lesender Zugriff (Die größte Falle) | Voll lizenzpflichtig. Wenn ein Drittsystem Daten aus SAP lediglich abfragt (z. B. eine automatisierte Bestandsabfrage oder das Lesen eines Kundenstamms), wertet SAP dies im alten Modell oft als lizenzpflichtige Nutzung. Hier drohen bei Audits immense Nachforderungen. | Komplett kostenfrei. Das reine Lesen von Daten aus SAP heraus über eine Schnittstelle in ein Drittsystem hinein ist im Digital-Access-Modell explizit lizenzfrei abgedeckt. |
| Metrik | Anzahl der namentlich bekannten Nutzer im Fremdsystem. | Anzahl der erzeugten Dokumente, bzw. Beleg-Positionen) in 9 definierten Belegtypen (z. B. Verkaufsbelege, Finanzbelege, Einkaufsbelege). |
Wann wird indirekte Nutzung konkret lizenzrelevant?
Verhandlungstipp: Wechseln Sie niemals ungeprüft in das neue Digital-Access-Modell. SAP bietet zwar Programme zur Migration an (z. B. das Digital Access Adoption Program), bei denen hohe Rabatte gewährt werden. Dennoch müssen Sie vorab über eine präzise Vermessung (z. B. via SAP Passport / Passport-Tooling) simulieren, wie viele Dokumente Ihre Schnittstellen pro Jahr real erzeugen. Für transaktionsstarke Unternehmen (z. B. im B2C-Handel mit Millionen Kleinaufträgen) kann das Dokumentenmodell trotz des wegfallenden lesenden Zugriffs extrem teuer werden. Hier müssen im Vertrag individuelle Paketpreise oder Deckelungen (Caps) verhandelt werden.
SAP Digital Access ist das moderne Lizenzmodell für die indirekte Nutzung (Schnittstellen). Statt Named-User-Lizenzen für alle Menschen oder Maschinen zu kaufen, die im Drittsystem hängen, lizenziert man ausschließlich das reine Volumen der in SAP erzeugten Dokumente. SAP unterscheidet hierbei exakt 9 Belegtypen (z. B. Verkaufs-, Finanz- oder Einkaufsbelege), die über einen Zähler im System erfasst werden.
Die goldene Regel: Keine Mischung erlaubt!
Unternehmen müssen vorab eine fundamentale, strategische Entscheidung treffen. Für die Lizenzierung der indirekten Nutzung gilt das Prinzip: Ganz oder gar nicht. Es ist vertraglich absolut unzulässig, das Altmodell (Named User für Fremdsysteme) und das Neumodell (Digital Access) nebeneinander zu betreiben. Entscheiden Sie sich für den Wechsel zu Digital Access, gilt dieses Modell rückwirkend und für die Zukunft für alle Schnittstellen Ihrer Systemlandschaft.
Wann lohnt sich welches Modell? (Die Entscheidungskriterien)
Verhandlungstipp: Nutzen Sie für die Entscheidung niemals Schätzungen. SAP stellt kostenlose Vermessungsreports zur Verfügung (z. B. via SAP Passport oder auch in der LAW), die das exakte Dokumentenaufkommen Ihrer Schnittstellen über die letzten 12 Monate transparent machen. Erst wenn Sie die genaue Zahl der jährlichen Dokumente kennen, stellen Sie diese den Kosten für eventuell notwendige Named-User-Lizenzen gegenüber. Achten Sie bei einem Wechsel zu Digital Access zudem darauf, dass SAP Ihnen im Rahmen von Migrationsprogrammen (wie dem Digital Access Adoption Program) deutliche Rabatte auf die Dokumentenpakete gewährt.
Der Ausgangspunkt ist nicht das Zählen von Belegen, sondern das Verstehen der Prozesse.
Schritt 1: Schnittstellen identifizieren. Welche Fremdsysteme sind mit Ihren SAP-Systemen verbunden? Webshops, CRM, Portale, Produktionssteuerungssysteme, EDI-Verbindungen zu Lieferanten und Kunden – die Liste ist in vielen Mittelstandsunternehmen länger als angenommen.
Schritt 2: Vorgänge verstehen. Für jede Schnittstelle: Welche Aktionen löst sie in SAP aus? Werden nur Daten gelesen, oder werden Belege erzeugt (Aufträge, Lieferungen, Rechnungen, Bestellungen)?
Schritt 3: Dokumenttypen zuordnen. Welche der erzeugten Belege fallen unter die vertraglich definierten, lizenzrelevanten Dokumenttypen?
Schritt 4: Volumen ermitteln. Erst jetzt wird gezählt – wie viele dieser Belege und Positionen werden pro Jahr über die jeweilige Schnittstelle erzeugt?
Schritt 5: Lizenzmodell zuordnen. Basierend auf Volumen und Vertrag: Ist eine Abdeckung über bestehende Named User ausreichend, oder ist ein separates Modell wie Digital Access wirtschaftlicher?
Ohne diese strukturierte Vorgehensweise bleibt jede Zahl bedeutungslos – Sie könnten zehntausend Belege zählen, ohne zu wissen, ob diese überhaupt lizenzrechtlich relevant sind.
Aus der Praxis lassen sich wiederkehrende Fehlerquellen identifizieren:
Unvollständiges Schnittstellenverzeichnis: Über die Jahre entstehen neue Integrationen – oft im Rahmen einzelner Projekte, ohne zentrale Dokumentation. Wenn niemand den vollständigen Überblick hat, können bei einer Bewertung Schnittstellen schlicht übersehen werden.
Fehlende Abgrenzung der Dokumenttypen: Nicht jeder über eine Schnittstelle erzeugte Datensatz ist automatisch ein lizenzrelevantes Dokument. Eine pauschale Annahme in die eine oder andere Richtung – „alles ist relevant“ oder „nichts ist relevant“ – führt zu falschen Ergebnissen.
Fehlende technische Nachweise: Wie viele Belege tatsächlich über eine bestimmte Schnittstelle entstehen, lässt sich oft nicht ohne zusätzliche Auswertungen feststellen. Ohne diese Daten ist jede Diskussion mit SAP – in beide Richtungen – spekulativ.
Das Ergebnis dieser Fehler: Entweder eine Überlizenzierung, bei der Sie für ein Modell zahlen, das Ihren tatsächlichen Bedarf übersteigt – oder ein Compliance-Risiko, bei dem Sie im nächsten Audit mit einer Nachforderung konfrontiert werden, die Sie nicht vorbereitet erwartet haben.
Eine gute Compliance-Position besteht nicht nur aus korrekten Zahlen, sondern aus der Fähigkeit, diese Zahlen zu erklären und zu begründen.
Was sollte dokumentiert sein?
Warum ist das wichtig? Ohne diese Dokumentation wirken Ihre Ergebnisse – selbst, wenn sie korrekt sind – wie nicht belegbare Behauptungen. Im Audit-Kontext bedeutet das: SAP hinterfragt Ihre Zahlen stärker, und Sie haben weniger Argumente, um Ihre Position zu vertreten. Bei Preisverhandlungen wirkt sich fehlende Dokumentation ebenfalls negativ aus – wer seine eigene Lizenzsituation nicht belegen kann, verhandelt aus einer schwächeren Position.
Eine Vermessung ist nur so gut wie ihre Vorbereitung. Mehrere Festlegungen müssen vor dem eigentlichen Messlauf getroffen werden:
Systeme und Mandanten: Welche Systeme gehören zur Vermessung? Produktivsysteme grundsätzlich ja – aber wie sieht es mit Entwicklungs-, Qualitätssicherungs- und Testsystemen aus? Das hängt von der vertraglichen Definition und der tatsächlichen Nutzung ab. Reine Gateway-Systeme oder Solution-Manager-Systeme sind in der Regel nicht relevant.
Benutzergruppen: Sind alle relevanten Benutzergruppen erfasst – auch solche, die in Randbereichen wie Tochtergesellschaften oder Shared-Service-Centern arbeiten?
Sind Benutzergruppen identifiziert, die über einen „Shared Account“ arbeiten?
In einer S/4HANA-Umgebung sollte geprüft werden, ob User, die nur in separat lizenzierten Engines aktiv sind, mit dem kostenfreien Lizenztyp „HE“ gekennzeichnet sind.
Schnittstellen: Welche Schnittstellen zu Drittsystemen existieren und sind diese im Hinblick auf indirekte Nutzung berücksichtigt?
Engine-Metriken: Welche Engines sind vertraglich relevant und sind die entsprechenden Datenquellen und Ansprechpartner für die Metrikermittlung identifiziert?
Zeitraum: Für welchen Zeitraum gilt die Vermessung – ein Stichtag, oder ein Durchschnitt über einen Zeitraum (relevant z. B. für bestimmte Engine-Metriken)?
Warum ist das wichtig? Wenn diese Festlegungen fehlen oder unvollständig sind, kann das Ergebnis verzerrt sein – durch versehentlich einbezogene Testsysteme, übersehene Schnittstellen, oder falsch interpretierte Engine-Daten. Ein verzerrtes Ergebnis führt entweder zu unnötiger Nachlizenzierung oder zu einem Compliance-Risiko, das bei einer genaueren Prüfung durch SAP auffällt.
Das zentrale Werkzeug für die Lizenzvermessung ist LAW (License Administration Workbench).
Wie funktioniert LAW grundsätzlich? LAW sammelt aus jedem angeschlossenen SAP-System die dort gepflegten Lizenztyp-Zuordnungen der User – die sogenannten USMM-Daten (User- und Measurement-Daten, benannt nach der zugrundeliegenden Transaktion USMM). Anschließend konsolidiert LAW diese Daten über alle Systeme hinweg zu einem Gesamtergebnis.
Wichtig zu verstehen: LAW misst nicht selbst, was ein User tut. LAW konsolidiert lediglich die Lizenztypen, die in den einzelnen Systemen bereits hinterlegt sind. Die Qualität des Vermessungsergebnisses hängt also direkt davon ab, wie sorgfältig die Lizenztyp-Zuordnung im Vorfeld in jedem einzelnen System gepflegt wurde.
Was bedeutet das praktisch? Eine Vermessung ist kein neutraler, automatischer Prozess, der „die Wahrheit“ liefert. Sie spiegelt die Qualität Ihrer internen Pflegeprozesse wider. Wenn die Lizenztyp-Zuordnung in den Systemen nicht korrekt ist – etwa weil der Default-Lizenztyp zu hoch eingestellt ist – wird auch das Vermessungsergebnis entsprechend verzerrt sein, unabhängig davon, wie das Tool selbst funktioniert.
Vermessung und Optimierung sind zwei unterschiedliche, aber eng verzahnte Aktivitäten im Lizenzmanagement.
Die Vermessung bildet einen Zustand zu einem bestimmten Zeitpunkt ab. Sie legt fest, welche Systeme, welche User und welche Engine-Metriken in das Ergebnis einfließen, führt den Messlauf durch und liefert ein Ergebnis – eine Momentaufnahme.
Die Optimierung ist demgegenüber ein fortlaufender Prozess. Sie analysiert die Ergebnisse, identifiziert Diskrepanzen zwischen aktueller Zuordnung und tatsächlichem Bedarf, entscheidet über Maßnahmen, setzt diese um und überprüft die Wirkung in einer erneuten Messung.
Wie hängen sie zusammen? Die Vermessung zeigt Abweichungen auf – etwa User in zu teuren Lizenztypen, ungenutzte Berechtigungen, oder Engines, die nahe an der vertraglichen Obergrenze liegen. Die Optimierung beseitigt die Ursachen dieser Abweichungen. Eine erneute Vermessung zeigt dann, ob die Maßnahmen gewirkt haben.
Die praktische Konsequenz: Eine isolierte Vermessung ohne nachfolgende Optimierung ist nur eine Bestandsaufnahme – sie verändert nichts. Eine Optimierung ohne vorherige Vermessung hat keine belastbare Ausgangsbasis. Beide Aktivitäten ergeben nur im Zusammenspiel einen funktionierenden Prozess.
Eine SAP-Systemlandschaft beschreibt die Gesamtheit aller SAP-Systeme, die ein Unternehmen betreibt. Im sogenannten Drei-System-Modell – der gängigsten Konfiguration – unterscheidet man typischerweise:
Entwicklungssystem (DEV): Hier finden Eigenentwicklungen, Customizing und erste Tests statt. Mehrere Entwickler arbeiten parallel an Änderungen.
Qualitätssicherungssystem (QAS/QS): Änderungen aus dem Entwicklungssystem werden hier getestet, bevor sie produktiv gehen – inklusive Integrationstests und Anwenderabnahmen. Qualitätssicherungssysteme werden regelmäßig als Systemkopien der Produktivsysteme erzeugt, um Test in produktionsähnlichen Umgebungen durchführen zu können.
Produktivsystem (PRD): Das System, in dem der tatsächliche Geschäftsbetrieb läuft.
Zusätzlich existieren häufig:
Jeder dieser Systemtypen hat eine eigene lizenzrechtliche Bewertung.
Grundsätzlich gilt: SAP vermisst alle Systeme, die produktiv genutzt werden – das schließt Produktivsysteme grundsätzlich ein. Entwicklungssysteme werden berücksichtigt um Aktivitäten von Entwicklern (benötigen eine Developer-Lizenz) und Systemadministratoren (benötigen eine Professional-Lizenz) zu berücksichtigen.
Test- und Qualitätssicherungssysteme sind in der Regel von der Vermessung ausgenommen – aber nur unter zwei Bedingungen:
Sandbox-Systeme sind ähnlich zu behandeln wie Testsysteme – die korrekte Deklaration und die tatsächliche Nutzung müssen übereinstimmen.
Schulungssysteme sind in der Regel ausgenommen, sofern sie ausschließlich für Schulungszwecke verwendet werden.
Die kritische Praxis-Frage: Was passiert, wenn ein offiziell als „Testsystem“ deklariertes System de facto produktiv genutzt wird – etwa weil dort regelmäßig echte Geschäftsvorgänge abgewickelt werden, weil das Produktivsystem überlastet ist, oder weil eine Abteilung „vorübergehend“ dort arbeitet? In diesem Fall besteht ein erhebliches Compliance-Risiko: Die Deklaration entspricht nicht der Realität. Bei einer genaueren Prüfung durch SAP kann dies zu Nachforderungen führen – nicht nur für das betreffende System, sondern auch zu einer grundsätzlichen Vertrauensfrage hinsichtlich Ihrer übrigen Deklarationen.
Entwicklungs- und Testsysteme stehen oft im Graubereich zwischen „klar nicht lizenzpflichtig“ und „versehentlich produktiv genutzt“.
Was spricht gegen eine Lizenzpflicht? Diese Systeme sind primär für interne technische Zwecke da – Entwicklung, Customizing, Tests vor Produktivsetzung. Die dort tätigen User sind meist eine kleine, definierte Gruppe (Entwickler, Tester).
Was kann eine Lizenzpflicht auslösen?
Was Sie tun sollten: Definieren Sie klare Nutzungsregeln für jedes System in Ihrer Landschaft – und überprüfen Sie regelmäßig, ob die tatsächliche Nutzung diesen Regeln noch entspricht. Eine klare Trennung zwischen „was passiert technisch in diesem System“ und „was ist offiziell deklariert“ ist die Grundlage für eine belastbare Vermessung.
Altsysteme – Systeme, die nach einer Migration oder Konsolidierung „eigentlich“ abgeschaltet werden sollten, aber aus verschiedenen Gründen weiterlaufen – sind ein häufig unterschätztes Lizenzrisiko.
Warum laufen Altsysteme weiter? Typische Gründe: Archivierungszwecke – historische Daten sollen noch zugänglich bleiben. Einzelne Prozesse oder Reports, die noch nicht migriert wurden. Unsicherheit, ob alle Daten korrekt übernommen wurden, daher „lieber noch nicht abschalten“. Fehlende Priorität – das Altsystem stört (scheinbar) niemanden, also bleibt es einfach an.
Welche Lizenzrisiken entstehen?
Was Sie tun sollten: Erstellen Sie einen verbindlichen Stilllegungsplan für Altsysteme – mit konkretem Datum, Verantwortlichem und den notwendigen Schritten (Datenarchivierung, Zugriffsentzug, Deklarationsänderung bei SAP). „Es läuft halt noch“ ist keine Lizenzstrategie, sondern ein offener Posten, der Geld kostet und Risiken birgt.
Eine Systemkopie ist eine vollständige oder teilweise Kopie eines bestehenden Systems – häufig wird das Produktivsystem kopiert, um eine aktuelle, realitätsnahe Testumgebung zu schaffen.
Was passiert bei einer Systemkopie aus Lizenzsicht? Die Kopie enthält in der Regel auch alle User-Stammdaten inklusive der dort gepflegten Lizenztyp-Zuordnungen aus dem Quellsystem. Wenn diese Kopie als Test- oder Entwicklungssystem deklariert ist und auch entsprechend genutzt wird – also nicht produktiv –, ist sie in der Regel nicht separat lizenzpflichtig.
Worauf Sie achten müssen:
Der zentrale Punkt: Eine Systemkopie ist für sich genommen kein automatisches Lizenzproblem. Das Problem entsteht, wenn die Deklaration und die tatsächliche Nutzung des kopierten Systems voneinander abweichen.
Viele Unternehmen befinden sich aktuell in einer Übergangsphase, in der ECC- und S/4HANA-Systeme parallel betrieben werden – etwa während einer mehrjährigen Migration, oder weil bestimmte Unternehmensbereiche bereits umgestellt sind, andere noch nicht.
Was bedeutet das für die Vermessung?
Was Sie tun sollten: Behandeln Sie eine hybride Landschaft nicht als „zwei separate Vermessungen, die man am Ende zusammenrechnet“, sondern als ein zusammenhängendes System mit Wechselwirkungen. Eine Migration in Phasen erfordert eine entsprechend phasenweise angepasste Lizenzstrategie – nicht nur am Anfang und Ende des Projekts, sondern während jeder Übergangsphase.
Neben den SAP-eigenen Werkzeugen (USMM, LAW) existiert ein Markt spezialisierter Software- und Beratungslösungen, die bei der Lizenzvermessung und -optimierung unterstützen.
Was leisten solche Tools typischerweise?
Wann lohnt sich der Einsatz solcher Tools? Für sehr kleine Systemlandschaften mit wenigen hundert Usern lässt sich vieles noch manuell oder mit Bordmitteln bewältigen. Mit wachsender Komplexität – mehrere Systeme, hybride Landschaften, viele Engines, häufige organisatorische Veränderungen – steigt der Aufwand für manuelle Prozesse überproportional. Tools können hier nicht nur Zeit sparen, sondern auch die Qualität und Konsistenz der Ergebnisse verbessern.
Wichtig: Ein Tool ersetzt nicht die organisatorischen Prozesse – es unterstützt sie. Ein Tool ohne klare interne Zuständigkeiten und Regelwerke liefert zwar Daten, aber keine Entscheidungshilfen.
Aus der praktischen Erfahrung lassen sich wiederkehrende Fehler identifizieren, die die Qualität einer Vermessung beeinträchtigen:
Vermessung erst bei Aufforderung beginnen: Wenn die Vorbereitung erst startet, nachdem SAP eine offizielle Anforderung gestellt hat, bleibt – bei typischen Fristen von rund 30 Tagen – kaum Zeit für eine sorgfältige Prüfung oder Optimierung.
Unvollständiger Scope: Systeme, Mandanten oder Benutzergruppen werden vergessen – mit der Folge, dass das Ergebnis bei einer späteren, vollständigeren Prüfung abweicht und Erklärungsbedarf entsteht.
Fehlende Plausibilisierung: Die Rohdaten aus LAW werden ungeprüft weitergegeben, ohne auf offensichtliche Auffälligkeiten zu prüfen – etwa eine plötzlich stark gestiegene Anzahl von Usern in einem teuren Lizenztyp, die möglicherweise auf einen technischen Fehler statt auf realen Bedarf zurückgeht.
Keine interne Freigabe: Ergebnisse werden direkt an SAP übermittelt, ohne dass eine interne Prüfung durch die zuständigen Stellen (Lizenzmanagement, IT, gegebenenfalls externe Berater) stattgefunden hat.
Engines vergessen: Der Fokus liegt auf Named Usern, während Engine-Metriken – die oft erheblichen finanziellen Einfluss haben – nicht oder nur unvollständig erhoben werden.
Die gemeinsame Ursache dieser Fehler: Vermessung wird als einmalige, reaktive Pflichtübung behandelt statt als wiederkehrender, proaktiver Prozess. Eine kontinuierliche interne Vermessung ist die wirksamste Maßnahme gegen alle diese Fehler.
Eine Vermessung ist kein Ein-Personen-Projekt, auch wenn die Koordination meist bei einer Person liegt. Folgende Beteiligte sind typischerweise erforderlich:
SAP-Basis-Team: Führt die technische Datenextraktion durch – Zugriff auf alle relevanten Systeme, Kenntnis der LAW-Konfiguration und der Systemlandschaft.
Fachbereiche: Können Auffälligkeiten einordnen – etwa, ob eine ungewöhnlich hohe Zahl an Usern in einem bestimmten Lizenztyp einer organisatorischen Veränderung entspricht (z. B. einer neu eingegliederten Abteilung) oder ein Datenfehler ist.
HR: Liefert Informationen zu Ein- und Austritten, die mit den im System hinterlegten Accounts abgeglichen werden müssen.
Lizenzverantwortlicher: Koordiniert den Gesamtprozess, plausibilisiert die Ergebnisse, entscheidet über das weitere Vorgehen.
Gegebenenfalls externe Berater: Insbesondere bei der ersten umfassenden Vermessung oder bei komplexen Sondersituationen (Engines, indirekte Nutzung, hybride Landschaften) kann externe Expertise helfen, Fehlinterpretationen zu vermeiden.
Was das für die Planung bedeutet: Eine Vermessung bindet Ressourcen über mehrere Abteilungen hinweg – nicht nur die der IT. Wenn diese Beteiligung nicht im Voraus geplant ist, sondern erst kurzfristig organisiert werden muss, verlängert das den Prozess erheblich und erhöht das Risiko, dass die Frist zur Abgabe knapp wird.
Ein SAP-system kann mehrere Mandanten (Clients) enthalten – logisch getrennte Bereiche innerhalb derselben technischen Installation, die jeweils eigene Stammdaten, Benutzer und Konfigurationen haben können.
Welche Mandanten sind typischerweise vorhanden?
Was bedeutet das für die Vermessung? Die Vermessung erfolgt grundsätzlich auf Systemebene, erfasst aber die User-Zuordnungen, die in den jeweiligen Mandanten gepflegt sind. Wenn ein User in mehreren Mandanten desselben Systems angelegt ist – etwa im Produktiv- und im Testmandanten – muss geprüft werden, wie diese Mehrfach-Anlage sich auf das Vermessungsergebnis auswirkt und ob eine Konsolidierung notwendig oder möglich ist.
Was Sie tun sollten: Führen Sie eine Übersicht über alle Mandanten in Ihrer Landschaft – mit ihrem jeweiligen Zweck und ihrer lizenzrechtlichen Einordnung. Mandanten, die „irgendwann mal angelegt wurden“ und deren Zweck niemand mehr genau kennt, sind ein typischer blinder Fleck bei der Vermessungsvorbereitung. Vor einer Systemvermessung sollten alle nicht relevanten Mandanten auch als solche gekennzeichnet werden, damit sie in der Vermessung ausgeschlossen werden. Das erfolgt je System in der Transaktion USMM.
In produzierenden Unternehmen arbeiten Mitarbeitende oft im Schichtbetrieb an gemeinsam genutzten Terminals, etwa in der Fertigung oder im Lager.
Welche Besonderheiten ergeben sich daraus?
Was Sie tun sollten:
Prüfen Sie für Produktionsbereiche mit Schichtbetrieb gezielt, ob die technische Account-Struktur (geteilte Terminals vs. individuelle Accounts) mit der lizenzrechtlichen Anforderung übereinstimmt, dass Named User an individuelle Personen gebunden sind. Es empfiehlt sich für die geteilte Nutzung einen Systemuser zu verwenden und für alle User, die darüber auf SAP zugreifen eigene Accounts anzulegen, auch wenn sich die Mitarbeiter darüber nie im SAP-System anmelden. Die Accounts sind notwendig, um die Compliance herzustellen.
Bei saisonalen Kräften sollte der Prozess zur Deaktivierung fester Bestandteil der Personalplanung sein – nicht eine Aufgabe, die „irgendwann“ nachgeholt wird. Beachten Sie dabei, dass Sie gemäß den SAP-Lizenzbestimmungen „zu jeder Zeit“ ausreichend lizenziert sein müssen, nicht nur zum Zeitpunkt der Vermessung.
Eine vollständige und aktuelle Dokumentation der Systemlandschaft ist die Grundlage für jede belastbare Vermessung und für die Kommunikation mit SAP.
Was sollte eine solche Dokumentation enthalten?
Warum ist das wichtig? Bei einer Vermessung oder einem Audit ist diese Dokumentation die Grundlage, um schnell und korrekt zu bestimmen, welche Systeme in welchem Umfang zu berücksichtigen sind. Ohne eine solche Übersicht muss diese Information bei jeder Vermessung erneut zusammengetragen werden – mit entsprechendem Zeitverlust und Fehlerrisiko, insbesondere wenn Wissen an einzelne Personen gebunden ist, die möglicherweise nicht mehr verfügbar sind.
Die Systemlandschaft eines Unternehmens verändert sich kontinuierlich – neue Systeme kommen hinzu, Altsysteme sollen abgeschaltet werden, Schnittstellen entstehen im Rahmen von Projekten, Testsysteme werden kopiert und neu aufgesetzt.
Welcher Rhythmus ist angemessen?
Was Sie vermeiden sollten: Eine Systemlandschaft, die „historisch gewachsen“ ist und deren Dokumentation seit Jahren nicht aktualisiert wurde, ist bei jeder Vermessung eine Quelle von Überraschungen – meist unangenehmen. Die regelmäßige Pflege der Dokumentation ist deutlich günstiger als die nachträgliche Aufklärung im Rahmen eines Audits.
Ein SAP-Lizenzvertrag ist selten ein einzelnes Dokument – über die Jahre einer Geschäftsbeziehung sammeln sich verschiedene Vertragsbestandteile an, die zusammen die vertragliche Grundlage bilden.
Typische Bestandteile:
Warum ist das wichtig? Bei einer Bewertung Ihrer Lizenzsituation – etwa im Rahmen einer Vermessung oder vor Preisverhandlungen – reicht es nicht, nur den ursprünglichen Rahmenvertrag zu kennen. Maßgeblich ist die Gesamtheit aller Dokumente, einschließlich aller Nachträge. Bei Unternehmen mit langer SAP-Historie ist es nicht ungewöhnlich, dass relevante Vertragsbestandteile über Jahre hinweg an verschiedenen Stellen abgelegt wurden – eine zentrale Vertragsablage ist daher ein wichtiger erster Schritt für ein funktionierendes Vertragsmanagement.
Die Product Use Rights (PUR) sind ein Dokument, in dem SAP die Definitionen und Nutzungsbedingungen für die einzelnen Lizenztypen und Produkte beschreibt – etwa, was ein Professional User darf, was ein Limited Professional User darf, oder welche Bedingungen für bestimmte Engines gelten.
Warum sind sie wichtig?
Was Sie tun sollten: Bewahren Sie die für Ihre jeweiligen Lizenzkäufe gültigen PUR-Versionen auf – nicht nur die aktuell auf der SAP-Website veröffentlichte Version. Bei Unklarheiten über die genaue Definition eines Lizenztyps ist die historische PUR-Version oft der entscheidende Beleg.
SAP-Kunden haben in der Regel mehrere Ansprechpartner mit unterschiedlichen Aufgaben und unterschiedlichen Interessen.
Account Executive / Account Manager: Der primäre Vertriebskontakt, verantwortlich für die Geschäftsbeziehung insgesamt und für Vertragsverhandlungen. Hat in der Regel produktbezogene Umsatzziele – das beeinflusst, welche Themen proaktiv angesprochen werden.
Customer Success Manager / Customer Engagement Executive: Fokus auf die Nutzung der vorhandenen Lizenzen und die „Gesundheit“ der Kundenbeziehung – kann eine wichtige Rolle spielen, wenn es um die Identifikation von Optimierungspotenzialen geht, aber auch hier gilt: Die Interessen sind nicht identisch mit Ihren.
License Compliance / Audit-Team: Zuständig für die Durchführung und Bewertung von Vermessungen. Agiert in der Regel formal nach den vertraglichen Vorgaben.
Technischer Support: Für operative IT-Themen – Systemprobleme, Updates, technische Fragen. In der Regel nicht direkt für Lizenzthemen zuständig.
Was Sie wissen sollten: Jeder dieser Ansprechpartner hat eine spezifische Funktion innerhalb von SAP – und entsprechend spezifische Interessen. Eine Frage zur Lizenzoptimierung beim Account Executive zu stellen, kann andere Antworten liefern als dieselbe Frage beim License Compliance Team. Für Lizenzverantwortliche ist es hilfreich zu verstehen, mit wem man über welches Thema spricht – und entsprechend zu erwarten, dass Antworten aus der jeweiligen Perspektive gegeben werden.
Die Beziehung zum SAP-Account-Team ist ein Balanceakt: Eine gute Beziehung kann helfen, etwa bei der Lösung operativer Probleme oder bei der Informationsbeschaffung. Gleichzeitig ist SAP ein Vertragspartner mit eigenen kommerziellen Interessen, die nicht immer mit Ihren übereinstimmen.
Was eine konstruktive Beziehung ausmacht:
Was eine eigenständige Position ausmacht:
Eine konstruktive Beziehung und eine eigenständige Position widersprechen sich nicht – im Gegenteil: Eine gut informierte, eigenständige Position ist oft die Grundlage für eine konstruktive, weil auf Augenhöhe geführte, Beziehung.
Das Audit Right (Prüfrecht) ist eine vertragliche Klausel, die SAP das Recht einräumt, die Einhaltung der Lizenzbedingungen beim Kunden zu überprüfen.
Was umfasst dieses Recht typischerweise?
Welche Pflichten ergeben sich für den Kunden?
Was Sie wissen sollten: Das Audit Right ist Standardbestandteil praktisch aller SAP-Lizenzverträge und nicht verhandelbar in seiner grundsätzlichen Existenz. Verhandelbar können jedoch Details sein – etwa die Frist zur Bereitstellung von Informationen, oder Regelungen zum Umgang mit den Ergebnissen (z. B. eine Karenzzeit zur Behebung von Unterlizenzierung, bevor Nachzahlungsforderungen gestellt werden). Solche Details sollten, wenn möglich, bei Vertragsverhandlungen mit adressiert werden.
Ein Enterprise License Agreement ist eine Vertragsform, bei der ein Unternehmen statt einzelner, separat verhandelter Lizenzkäufe ein umfassendes Paket über einen längeren Zeitraum vereinbart – häufig mit pauschalierten oder vorab definierten Konditionen für einen größeren Umfang an Lizenzen und Services.
Welche Eigenschaften hat ein ELA typischerweise?
Wann ist ein ELA sinnvoll – und wann nicht?
Was Sie vor Abschluss eines ELA prüfen sollten: Wie realistisch sind die zugrunde liegenden Wachstumsannahmen? Was passiert, wenn das tatsächliche Volumen unter den Annahmen bleibt – gibt es Mindestabnahmeverpflichtungen („Use it or lose it“)? Wie flexibel ist der Vertrag bei grundlegenden strategischen Änderungen während der Laufzeit?
Eine Nachzahlungsforderung ist nicht automatisch korrekt, nur weil sie von SAP kommt – aber sie ist auch nicht automatisch falsch, nur weil Sie sie für unbegründet halten. Der richtige Weg ist eine sachliche, faktenbasierte Auseinandersetzung.
Schritt 1: Verstehen, wie die Forderung zustande kommt. Welche Daten liegen der Forderung zugrunde? Welche Lizenztypen, welche Mengen, welche Zeiträume? Ohne dieses Verständnis kann keine fundierte Reaktion erfolgen.
Schritt 2: Eigene Vermessung gegenüberstellen. Wenn Sie eine eigene, aktuelle Vermessung haben, vergleichen Sie diese mit der SAP-Forderung. Wo liegen Abweichungen, und woher kommen sie?
Schritt 3: Mögliche Fehlerquellen prüfen. Wurden Testsysteme fälschlich einbezogen? Wurden technische Accounts falsch gezählt? Basiert die Forderung auf veralteten Daten?
Schritt 4: Sachlich und schriftlich kommunizieren. Legen Sie Ihre Sichtweise mit konkreten Belegen dar – nicht als grundsätzliche Ablehnung, sondern als faktenbasierte Klärung. In vielen Fällen lassen sich Unstimmigkeiten durch eine genauere Betrachtung beider Seiten auflösen.
Schritt 5: Eskalation, wenn nötig. Wenn auf operativer Ebene keine Klärung möglich ist, kann eine Eskalation an höhere Ebenen – sowohl bei SAP als auch intern – notwendig sein. In komplexen oder hochvolumigen Fällen kann auch externe rechtliche oder lizenzrechtliche Beratung sinnvoll sein.
Was Sie vermeiden sollten: Eine Forderung weder kommentarlos zu akzeptieren noch kommentarlos abzulehnen. Beides führt selten zu einem für Sie guten Ergebnis.
Eine Vertragsverlängerung ist mehr als eine reine Formalität – sie ist ein Zeitpunkt, an dem sich Bedingungen ändern können, oft zu Ungunsten des Kunden, wenn dieser nicht aktiv wird.
Worauf besonders erfahrene Lizenzverantwortliche achten:
Die zentrale Haltung: Eine Vertragsverlängerung ist eine Verhandlung, kein Verwaltungsakt. Wer sie als reine Formalität behandelt, übersieht regelmäßig Gelegenheiten zur Kostenoptimierung oder zur Absicherung gegen zukünftige Risiken.
SAP arbeitet mit einem Netzwerk von Implementierungspartnern, Beratungsunternehmen und Software-Anbietern zusammen, die verschiedene Zertifizierungsstufen und Partnerschaften mit SAP haben.
Was bedeutet das für Sie als Kunden?
Die praktische Konsequenz: Wenn Sie Empfehlungen von SAP-Partnern erhalten – sei es zu Lizenzmodellen, Migrationsstrategien oder Add-on-Produkten – ist es sinnvoll, diese Empfehlungen als einen Input unter mehreren zu behandeln, nicht als abschließende, neutrale Bewertung.
Unternehmensstrukturelle Veränderungen haben direkte Auswirkungen auf SAP-Lizenzverträge – und diese Auswirkungen werden oft erst spät im Prozess berücksichtigt, mit entsprechendem Zeitdruck.
Bei einer Übernahme oder Fusion:
Bei einem Verkauf von Unternehmensteilen (Carve-out):
Was Sie tun sollten: Wenn eine Unternehmensumstrukturierung absehbar ist, sollte die Bewertung der SAP-Lizenzsituation früh Teil der Due-Diligence-Prozesse sein – nicht erst nach Abschluss der Transaktion. Eine nachträgliche Klärung unter Zeitdruck führt häufig zu ungünstigeren Konditionen, als sie im Rahmen einer vorbereiteten Verhandlung erreichbar wären.
SAP ist ein global agierendes Unternehmen mit regionalen Vertriebsgesellschaften, und Verträge können je nach Land oder Region unterschiedlich ausgestaltet sein.
Welche regionalen Besonderheiten können auftreten?
Was bedeutet das für Lizenzverantwortliche mit internationalen Strukturen?
Wenn Tochtergesellschaften in verschiedenen Ländern eigene SAP-Verträge mit den jeweiligen lokalen SAP-Einheiten abgeschlossen haben, kann eine Konsolidierung komplex sein, weil unterschiedliche Vertragsversionen, Sprachen und gegebenenfalls Rechtsordnungen aufeinandertreffen.
Was Sie tun sollten: Bei internationalen Strukturen lohnt sich frühzeitig die Frage, ob eine Konsolidierung auf einen globalen Rahmenvertrag sinnvoll und möglich ist – und welche rechtlichen und praktischen Hürden dabei zu beachten sind. Dies ist ein Thema, bei dem in komplexen Fällen rechtliche Beratung mit internationalem Bezug sinnvoll sein kann.
SAP-Vertragsbeziehungen erstrecken sich oft über viele Jahre, während Personen, die diese Verträge ursprünglich verhandelt haben, das Unternehmen verlassen oder die Position wechseln. Ohne gute Dokumentation geht dabei wertvolles Kontextwissen verloren.
Was sollte dokumentiert sein?
Warum ist das wichtig? Wenn ein neuer Lizenzverantwortlicher übernimmt – sei es durch internen Wechsel oder Neueinstellung – und keine zusammenhängende Dokumentation vorfindet, beginnt die Arbeit faktisch bei null. Wichtige Konditionen, die vor Jahren mündlich oder in E-Mails vereinbart wurden, können verloren gehen – mit der Folge, dass bei der nächsten Verhandlung möglicherweise schlechtere Bedingungen erzielt werden, weil frühere Zugeständnisse nicht mehr bekannt sind.
Mittelständische Unternehmen haben oft nicht die Ressourcen, ein vollständiges internes Team für SAP-Lizenzmanagement aufzubauen. Externe Unterstützung kann diese Lücke schließen – in unterschiedlichen Formen.
Welche Formen externer Unterstützung gibt es?
Wann lohnt sich externe Unterstützung besonders?
Worauf Sie bei der Auswahl achten sollten: Die wirtschaftliche Unabhängigkeit von SAP ist ein relevanter Faktor. Fragen Sie nach der Vergütungsstruktur – wird nach Aufwand, nach Projekterfolg, oder auf Basis von Provisionen aus SAP-Geschäften vergütet? Diese Struktur kann beeinflussen, welche Empfehlungen Sie erhalten.
Eine Nutzungsanalyse zeigt, was User in der Vergangenheit tatsächlich getan haben – welche Transaktionen aufgerufen, welche Belege gebucht wurden. Das ist eine wichtige Informationsquelle, aber keine vollständige Grundlage für die Lizenzierung.
Warum ist das nicht ausreichend?
Die Konsequenz: Nutzung und Berechtigung müssen gemeinsam betrachtet werden. Eine Lizenzstrategie, die sich ausschließlich auf „was wurde genutzt“ stützt, übersieht systematisch einen Teil des relevanten Bilds.
Spiegelbildlich zur Nutzungsanalyse hat auch die reine Betrachtung von Berechtigungen Grenzen.
Warum ist das nicht ausreichend?
Die Konsequenz: Eine Berechtigungsanalyse zeigt, was theoretisch möglich ist – nicht, was tatsächlich gebraucht wird. Für eine wirtschaftlich sinnvolle Lizenzierung muss diese Information mit der tatsächlichen Nutzung abgeglichen werden, um zwischen notwendigen und überflüssigen Berechtigungen zu unterscheiden.
Der User-Lifecycle beschreibt den gesamten Weg eines Benutzerkontos – von der Anlage bei Eintritt eines Mitarbeitenden über Änderungen bei Positionswechseln bis zur Deaktivierung bei Austritt.
Die zentralen Phasen:
Was eine funktionierende Umsetzung braucht:
Warum ist das wichtig? Ein fehlender oder lückenhafter User-Lifecycle-Prozess ist eine der häufigsten Ursachen für unnötige Lizenzkosten – durch Karteileichen, falsch zugeordnete Lizenztypen und über die Zeit angesammelte, ungenutzte Berechtigungen.
Lizenzoptimierung ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Ohne einen festen Rhythmus verläuft dieser Prozess erfahrungsgemäß im Sand.
Wie könnte ein solcher Rhythmus aussehen?
Was zu diesem Rhythmus gehört:
Was Sie vermeiden sollten: Optimierung als „Projekt“, das einmal durchgeführt wird und dann als abgeschlossen gilt. Ohne wiederkehrenden Rhythmus sammeln sich dieselben Probleme – ungenutzte Berechtigungen, inaktive Accounts, falsche Lizenztypen – innerhalb weniger Jahre erneut an.
Ein effektives Lizenzmanagement braucht eine kleine, aber aussagekräftige Auswahl an Kennzahlen, die regelmäßig erhoben und verfolgt werden.
Mögliche Kennzahlen:
Warum diese Auswahl? Diese Kennzahlen lassen sich mit überschaubarem Aufwand regelmäßig erheben und geben einen schnellen Überblick darüber, ob sich die Lizenzsituation in eine positive oder negative Richtung entwickelt – ohne dass jedes Mal eine vollständige Vermessung notwendig wäre.
Lizenzmanagement ist kein reines Verwaltungsthema, sondern ein strategischer Querschnittsprozess. Da er mehrere Stakeholder mit völlig unterschiedlichen Interessen und Vorwissen betrifft, muss die Kommunikation zielgruppenspezifisch übersetzt werden.
Die übergreifende Botschaft: Erfolgreiches Lizenzmanagement agiert als Brücke zwischen Business, IT und Finanzen. Es ist kein reiner „Kostenwächter“, sondern ein unverzichtbares Beratungstool, das sicherstellt, dass technologische Innovationen und geschäftliches Wachstum nicht durch unkalkulierbare SAP-Folgekosten ausgebremst werden.
Ohne aktives Lizenzmanagement (ITAM) laufen Unternehmen blind in eine technologische und finanzielle Sackgasse. Die Risiken sind dabei keineswegs nur schleichend – sie entladen sich in der Praxis oft schlagartig in Form von unbudgetierten Millionen-Nachforderungen oder strategischen Blockaden.
Fazit: Die Annahme, Lizenzmanagement sei zu teuer oder erfordere zu viele Ressourcen, ist eine klassische Fehlkalkulation. Die Kosten für den Aufbau eines professionellen, regelbasierten Lizenzmanagements betragen meist nur einen Bruchteil dessen, was ein einziges, unvorbereitetes SAP-Audit an Schaden anrichtet.
Der Aufbau einer Lizenzmanagement-Funktion (Software Asset Management / SAM) von null auf erfordert ein agiles, phasenbasiertes Vorgehen. Wer versucht, Verträge, Berechtigungen und Schnittstellen globaler Systeme am ersten Tag gleichzeitig zu lösen, wird im SAP-Dickicht scheitern.
Bevor interne Strukturen aufgebaut werden, fehlt oft die nötige Rückendeckung beim C-Level. Hier ist der gezielte Einsatz externer SAM-Spezialisten der wirtschaftlichste Hebel:
Erst wenn das Thema die nötige Aufmerksamkeit und das Budget hat, gehen Sie in den strukturierten internen Aufbau über:
Etablieren Sie einen festen, vierteljährlichen Rhythmus. Mindestens drei Monate vor der offiziellen jährlichen SAP-Systemvermessung (LAW) muss eine Inhouse-Probevermessung (Trockenübung) stattfinden. So bleibt genügend Zeit, um Fehlklassifizierungen oder Berechtigungskonflikte vor dem echten Audit glattzuziehen.
Einschätzung zur Praxis: Der Aufbau eines reifen SAP-Lizenzmanagements ist ein Projekt über 2 bis 3 Quartale. Nutzen Sie externe Berater in der Startphase als „Feuerwehr“ und Architekten, um schnelle Erfolge vorzuweisen und teure Anfängerfehler bei der Vertragsinterpretation zu vermeiden. Das langfristige Ziel muss jedoch der Wissenstransfer sein, damit Ihr internes Team den laufenden Regelbetrieb und das Tool-Management eigenständig steuern kann.
Lizenzmanagement wird oft als reines Thema für Spezialisten betrachtet – IT, Lizenzverantwortlicher, gegebenenfalls externe Berater. Tatsächlich spielen aber auch andere Mitarbeitende eine Rolle, ohne dass ihnen das bewusst ist.
Wo entstehen Berührungspunkte?
Was eine sinnvolle Sensibilisierung umfasst:
Die praktische Wirkung: Sensibilisierung ersetzt keine technischen oder organisatorischen Prozesse, kann diese aber wirksamer machen – wenn Mitarbeitende verstehen, warum bestimmte Regeln existieren, ist die Akzeptanz höher und die Umgehung seltener.
IT-Sicherheit und Lizenzmanagement haben teilweise gegenläufige, teilweise sich ergänzende Interessen – ein bewusster Umgang mit diesem Spannungsfeld ist sinnvoll.
Wo gibt es Überschneidungen?
Wo gibt es Spannungen?
Was sinnvoll ist: Eine Zusammenarbeit zwischen IT-Sicherheit und Lizenzmanagement bei der Rollenbereinigung kann Synergien heben – ein gemeinsames Projekt erreicht oft mehr als zwei getrennte Initiativen mit ähnlicher Zielrichtung, aber unterschiedlicher Priorisierung.
Mit wachsender Komplexität der Systemlandschaft – mehrere Systeme, hybride ECC/S4HANA-Umgebungen, Cloud-Komponenten mit kontinuierlichem Monitoring – wird manuelles Lizenzmanagement zunehmend aufwendig und fehleranfällig.
Wofür können Tools eingesetzt werden?
Was Automatisierung nicht ersetzt:
Die praktische Einordnung: Für kleinere Systemlandschaften mag der Aufwand für spezialisierte Tools den Nutzen übersteigen. Mit wachsender Komplexität verschiebt sich dieses Verhältnis – Automatisierung wird dann nicht zum Luxus, sondern zur Voraussetzung, um die in den vorherigen Kapiteln beschriebenen Prozesse überhaupt im notwendigen Rhythmus durchzuhalten.
Über alle bisherigen Themen hinweg lassen sich einige zentrale Prinzipien zusammenfassen, die ein nachhaltiges Lizenzmanagement ausmachen.
Proaktiv statt reaktiv: Lizenzmanagement, das erst beginnt, wenn SAP eine Vermessung anfordert, hat strukturell wenig Spielraum. Wer regelmäßig selbst vermisst und optimiert, ist auf eine offizielle Anforderung jederzeit vorbereitet.
Nutzung und Berechtigung gemeinsam betrachten: Beide Dimensionen sind notwendig, keine reicht für sich allein.
Klare Zuständigkeiten: Lizenzmanagement betrifft mehrere Bereiche – IT, HR, Fachabteilungen, Einkauf. Ohne klare Verantwortlichkeiten bleibt es zwischen den Bereichen liegen.
Dokumentation als Grundlage: Sowohl für Audits als auch für Verhandlungen ist eine nachvollziehbare Dokumentation – von Systemlandschaft, Vertragslandschaft und Zuordnungsregeln – die Basis für eine starke Position.
Eigenständigkeit gegenüber SAP: Eine konstruktive Beziehung zu SAP und eine eigenständige, faktenbasierte Position schließen sich nicht aus – im Gegenteil, letztere ist die Voraussetzung für ersteres auf Augenhöhe.
Kontinuität statt Einmalprojekt: Ob Vermessung, Optimierung, Rollenbereinigung oder Vertragsmanagement – nachhaltiger Erfolg entsteht durch wiederkehrende Routinen, nicht durch einmalige Aktionen.
Die übergreifende Botschaft: SAP-Lizenzmanagement ist kein technisches Detailthema, sondern ein organisatorisches Querschnittsthema mit direkter finanzieller Relevanz. Unternehmen, die es als solches behandeln – mit entsprechenden Strukturen, Prozessen und Ressourcen – reduzieren ihre Kosten und Risiken nachhaltig, während Unternehmen, die es als Nebensache behandeln, diese Kosten und Risiken über Jahre stillschweigend anhäufen.
Die SAP Lizenzierung ist zu wichtig, um sie nebenbei zu managen. Unsere Experten unterstützen Sie bei Vertragsverhandlungen, Compliance-Absicherung und der Optimierung Ihrer Lizenzkosten – herstellerunabhängig und mit langjähriger SAP-Erfahrung. Sprechen Sie uns an.
Geschäftsführer und SAP-Lizenzexperte der SAMtoa GmbH
Lizenzkosten senken
Unsere Experten kennen alle Hebel zur Senkung von Lizenzkosten. Herstellerspezifisch identifizieren wir Potenziale, die langfristig wirken.
Compliance sichern
Wir reduzieren Lizenzrisiken frühzeitig – so bleiben Sie stets handlungsfähig und vermeiden kostspielige Nachforderungen.
SAM Automatisieren
Wir unterstützen Sie dort, wo Ressourcen fehlen – von der Auswahl des richtigen SAM-Tools bis zur verlässlichen Unterstützung im Tagesgeschäft.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen
