Test-User in SAP korrekt klassifizieren: Was zählt als lizenzpflichtig und was nicht

Test-User gehören zu den häufigsten Klassifizierungsfehlern, die SAP Enhanced Audits zutage fördern. Nicht weil die Regel besonders komplex wäre, sondern weil in der Praxis oft unklar ist, welche Systeme als Testumgebung gelten, welche Nutzer welchen Typ benötigen und was vertraglich geregelt sein muss. Dieser Artikel beschreibt die Grundmechanik, die typischen Stolperpunkte und die konkreten Schritte zur Bereinigung.

Welche Systeme sind lizenzpflichtig?

Der erste Irrtum beginnt oft hier: "Testsysteme sind keine Produktivsysteme, also brauchen sie keine Lizenzen." Diese Annahme ist vertragsabhängig, und im Zweifel unzutreffend.

SAP unterscheidet in seinen Vertragswerken grundsätzlich nach Systemtyp. Produktivsysteme sind immer lizenzpflichtig. Bei Nicht-Produktivsystemen kommt es auf die vertragliche Grundlage an.

Systeme, die typischerweise lizenzpflichtig sind

Qualitätssicherungs- und Pre-Production-Systeme, also QA-, QS-, oder PPR-Systeme, auf denen reguläre Geschäftsprozesse nachgestellt oder validiert werden, fallen in den meisten Standardverträgen unter die Lizenzpflicht. Der Grund liegt im Zugriffsumfang: Wenn dieselben Benutzerkonten, dieselben Rollen und dieselben Transaktionen wie im Produktivsystem genutzt werden, ist das System aus SAP-Perspektive lizenzrelevant.

Schulungssysteme, die mit produktiven Benutzern betrieben werden, also wenn reale Mitarbeiter und keine anonymen Schulungskonten eingesetzt werden, unterliegen ebenfalls der Lizenzpflicht.

Konsolidierungssysteme und Reporting-Systeme, die eigenständige Named-User-Zugänge besitzen, zählen in der Standardinterpretation als lizenzpflichtige Systeme.

Systeme, die vertraglich ausgenommen sein können

Sandbox- und Experimentierumgebungen können in manchen Verträgen explizit ausgenommen sein, sofern sie isoliert betrieben werden, also ohne Zugriff auf produktive Daten und ohne Produktionsprozesse.

Die entscheidende Formulierung lautet "können". Ob eine Ausnahme gilt, steht im Vertrag, nicht in einer allgemeinen SAP-Regel. Wer davon ausgeht, dass sein Sandbox-System ausgenommen ist, ohne dies vertraglich geprüft zu haben, trägt ein Risiko.

Für den Steuerungsmoment Nutzung bedeutet das: Eine jährliche Systembestandsaufnahme, die alle Nicht-Produktivsysteme und ihre vertragliche Klassifizierung erfasst, ist kein bürokratischer Mehraufwand, sondern eine notwendige Steuerungsmaßnahme.

Wann zählen Test-User als Named User?

Auch wenn ein System grundsätzlich lizenzpflichtig ist, stellt sich die nächste Frage: Welchen Lizenztyp benötigen die Nutzer in diesem System?

Die Grundregel: Zugriff bestimmt den Typ

Named-User-Lizenzierung folgt dem Prinzip, dass jede Person, die auf ein lizenzpflichtiges SAP-System zugreift, eine dem Zugriffsumfang entsprechende Lizenz benötigt. Das gilt unabhängig davon, ob die Person im Produktivsystem oder im Testsystem arbeitet.

Ein Funktionsberater, der im QA-System Ende-zu-Ende-Prozesse testet, nutzt dieselben Transaktionen wie im Produktivsystem. Das macht aus Lizenzperspektive keinen Unterschied. Ein Professional User im Produktivsystem benötigt denselben Typ im QA-System, sofern er dort dieselbe Funktionstiefe nutzt.

Der Test-User-Lizenztyp: Ausnahme, nicht Regelfall

SAP hat in manchen Vertragsversionen einen dedizierten "Test User"-Lizenztyp vorgesehen, der ausschließlich für QA- und Testaktivitäten in Testsystemen gilt. Die Bedingungen sind eng definiert:

Erstens ist der Test-User-Typ auf definierte Testsysteme beschränkt. Ein Konto, das als Test User lizenziert ist, darf nicht auf Produktivsysteme zugreifen.

Zweitens deckt der Test-User-Typ nur tatsächliche Testaktivitäten ab. Wer über einen Test-User-Account reguläre Geschäftsprozesse ausführt, auch wenn er das "nur zum Ausprobieren" tut, verlässt den lizenzierten Nutzungsbereich.

Drittens ist der Test-User-Lizenztyp vertragsspezifisch. Er existiert nicht in jedem SAP-Vertrag. Bevor eine Organisation einen spezifischen Test-User-Typ einplant, muss der aktuelle Vertrag daraufhin geprüft werden, ob dieser Typ überhaupt vorhanden und definiert ist.

Die Grauzone: Entwickler in Testsystemen

Ein praktischer Sonderfall ist der Developer User in Testsystemen. Entwickler, die im Entwicklungs- und Testsystem ABAP-Code schreiben, testen und deployen, benötigen dort typischerweise einen Developer-Typ. Im FUE-Modell ist das Developer-Gewicht vertragsspezifisch und weicht je nach Vertragsversion erheblich voneinander ab. Dieser Punkt muss im Vertrag verifiziert werden, bevor eine FUE-Kalkulation für Entwicklerkonten aufgestellt wird (Details dazu im Pillar-6-Hub, Abschnitt FUE-Modell).

Vertragliche Regelung: Was in den Vertrag muss

Die häufigste Ursache für Test-User-Compliance-Lücken ist keine falsche Nutzung, sondern fehlende vertragliche Grundlage. Wer annimmt, dass Test-User-Typen automatisch vorhanden sind oder dass Testsysteme automatisch ausgenommen sind, stützt sich auf eine Annahme, die im Audit nicht trägt.

Prüfpunkte für den bestehenden Vertrag

Der SAP-Softwarevertrag, konkret das beigefügte "Product and Pricing Definitions"-Dokument, definiert, welche Lizenztypen verfügbar sind und unter welchen Bedingungen. Folgende Punkte verdienen eine gezielte Prüfung:

Ist ein dedizierter Test-User-Lizenztyp im Vertrag enthalten, und wenn ja, unter welchen Nutzungsbedingungen?

Welche Systemtypen sind explizit als nicht-lizenzpflichtig ausgenommen? Eine Sandbox-Ausnahme muss im Vertrag stehen, sie ergibt sich nicht aus der Systembezeichnung.

Gibt es eine Klausel, die regelt, wie viele Test-User-Lizenzen in Relation zu Produktivlizenzen bezogen werden können? Manche Vertragsmodelle begrenzen die Test-User-Anzahl auf einen Prozentsatz der Produktivlizenzen.

Was bei Neuverhandlungen und RISE-Migrationen adressiert werden sollte

Bei Vertragsverhandlungen, sei es ein Renewal, ein RISE-Übergang oder eine vertragliche Ergänzung, ist der Test-User-Kontext ein konkreter Verhandlungspunkt, der häufig zu spät auf den Tisch kommt.

Wer in einer RISE-Umgebung testet, bewegt sich im FUE-Modell. Dort gibt es keinen eigenständigen "Test-User"-FUE-Typ in der Standarddefinition. Testende Nutzer fallen je nach ihrem Zugriffsumfang in einen der vier FUE-Typen (Advanced, Core, Self-Service, Developer). Die Frage ist, wie viele dieser Nutzer mit welchem Gewicht in den FUE-Pool einfließen und ob vertraglich eine günstigere Regelung für rein testende Accounts ausgehandelt wurde.

Der Steuerungsmoment Kosten umfasst diese Verhandlung explizit: Wer vor dem Renewal die tatsächliche Nutzungsstruktur seiner Test- und QA-Systeme kennt, verhandelt mit einer konkreten Datenbasis.

Bereinigungsschritte vor dem Audit

Wenn ein Audit angekündigt ist oder wenn eine Standortbestimmung im Rahmen der Lizenz-Governance ergeben hat, dass Test-User-Konten unzureichend klassifiziert sind, gibt es einen strukturierten Bereinigungspfad.

Schritt 1: Systembestandsaufnahme

Alle Nicht-Produktivsysteme erfassen: QA, Schulung, Sandbox, DR, Pre-Production. Für jedes System: Ist es im Vertrag als lizenzpflichtig oder ausgenommen klassifiziert? Wenn unklar: Vertrag prüfen, nicht annehmen.

Schritt 2: User-Analyse pro System

Mit USMM oder SAM4U für jedes lizenzpflichtige Nicht-Produktivsystem eine Named-User-Übersicht erstellen. Wie viele Konten sind aktiv? Welcher Lizenztyp ist ihnen zugeordnet? Entspricht der zugeordnete Typ dem tatsächlichen Zugriffsumfang?

Schritt 3: Inaktive Konten bereinigen

In Testsystemen sind inaktive Konten besonders häufig: Projektmitarbeiter, die die Umgebung nach Abschluss ihres Einsatzes nicht verlassen haben, automatisierte Testkonten ohne laufenden Prozess, Schulungskonten aus vergangenen Trainingszyklen. Die 90-Tage-Schwelle ohne Login gilt auch in Nicht-Produktivsystemen als Bereinigungsschwelle.

Schritt 4: Klassifizierung mit Vertragsgrundlage abgleichen

Für jeden aktiven Test-User prüfen: Ist der zugewiesene Lizenztyp vertraglich definiert und entspricht er dem tatsächlichen Nutzungsumfang? Falls ein Test-User-Typ genutzt wird, der im aktuellen Vertrag nicht vorhanden ist, besteht eine Compliance-Lücke, die vor der Datenübermittlung an SAP adressiert werden sollte.

Schritt 5: Dokumentation aufbauen

Für jeden Systemtyp und für jeden Lizenztyp in Nicht-Produktivsystemen eine Dokumentation erstellen: Welche vertragliche Grundlage gilt? Wie viele Konten werden unter welchem Typ geführt? Wer ist verantwortlich für die laufende Pflege?

Diese Dokumentation ist der Ausgangspunkt für den Steuerungsmoment Berechtigungen in Testsystemen: Sie ermöglicht eine quartalsweise Überprüfung, die nicht jedes Mal bei null beginnt.

Fazit

Test-User sind kein Randthema des SAP-Lizenzmanagements. Sie sind ein konkreter Steuerungsmoment Nutzung, der in vielen Organisationen ohne systematischen Governance-Rhythmus unkontrolliert bleibt und im Audit als Lücke sichtbar wird.

Die Grundlage ist einfach: Vertrag prüfen statt annehmen, Systeme inventarisieren, Konten nach 90 Tagen Inaktivität bereinigen und Klassifizierungen dokumentieren. Wer diesen Rhythmus im Betrieb verankert, adressiert den Test-User-Kontext als laufende Steuerungsaufgabe, nicht als Audit-Vorbereitung.

Für eine strukturierte Bestandsaufnahme der Lizenzbasis, einschließlich der Klassifizierung von Nicht-Produktivsystemen, bietet der FinOptory Vertragscheck einen definierten Einstieg.

FAQ

Sind Sandbox-Systeme bei SAP immer lizenzfrei?

Nein. Sandbox-Systeme können vertraglich ausgenommen sein, müssen es aber nicht. Die Ausnahme muss im Vertrag, konkret im beigefügten "Product and Pricing Definitions"-Dokument, explizit genannt sein. Eine allgemeine SAP-Regel, die Sandbox-Systeme grundsätzlich ausnimmt, existiert nicht.

Welchen Lizenztyp benötigt ein Tester in einem QA-System?

Das hängt vom Zugriffsumfang ab. Ein Tester, der vollständige End-to-End-Prozesstests durchführt und dabei Professional-Transaktionen ausführt, benötigt denselben Typ wie im Produktivsystem. Gibt es im Vertrag einen dedizierten Test-User-Typ, kann dieser verwendet werden, sofern die Nutzungsbedingungen eingehalten werden.

Gilt der dedizierte Test-User-Lizenztyp bei RISE?

Im FUE-Modell von RISE gibt es keinen eigenständigen Test-User-FUE-Typ in der Standarddefinition. Testende Nutzer fallen nach Zugriffsumfang in einen der vier FUE-Typen. Vertragliche Sonderregelungen für Testkonten sind möglich, aber ausdrücklich zu vereinbaren.

Was passiert, wenn ein Test-User-Konto auf das Produktivsystem zugreift?

Der Test-User-Lizenztyp deckt ausschließlich den Zugriff auf definierte Testsysteme ab. Ein Konto, das einen Produktivsystem-Zugriff erzeugt, benötigt für diesen Zugriff den entsprechenden Produktiv-Lizenztyp. Ein einmaliger Produktivsystemzugriff durch ein als Test User lizenziertes Konto ist ein Compliance-Befund.

Wie finde ich heraus, welche Lizenztypen in meinem Vertrag enthalten sind?

Im SAP-Softwarevertrag ist das "Product and Pricing Definitions"-Supplement beigefügt. Dort sind alle verfügbaren Lizenztypen und ihre Nutzungsbedingungen definiert. Falls dieses Dokument nicht vorliegt, ist es über den SAP Account Executive oder das SAP Support-Portal zu beschaffen.

Werden inaktive Test-Accounts bei USMM mitgezählt?

Ja. USMM zählt jeden Named User, unabhängig von Aktivität. Inaktive Test-Accounts erhöhen die gemessene Lizenzzahl. Die Bereinigung nach 90 Tagen ohne Login gilt als etablierte Praxisregel.