Digital Access in Cloud ERP-Vertraegen: Was die Enterprise-Agreement-Inklusion abdeckt und was nicht

RISE-Verträge mit Enterprise Agreement enthalten für interne Integrationen häufig unbegrenzte Digital-Access-Rechte. Aber "intern" ist vertragsabhängig definiert, und externe Systeme, Partner-Portale sowie IoT-Plattformen fallen typischerweise heraus. Was in Ihrem RISE-Vertrag steht, entscheidet, nicht das, was im Vertriebsgespräch kommuniziert wurde.

Die EA-Inklusions-Logik bei RISE

RISE with SAP wird in der Regel als Enterprise Agreement abgeschlossen. Dieses Vertragsmodell unterscheidet sich strukturell von früheren On-Premise-Verträgen: Der Kunde lizenziert nicht mehr einzelne Produktinstanzen oder Benutzertypen separat, sondern kauft eine Gesamtkapazität, die verschiedene Nutzungsformen unter einem Dach zusammenfasst.

Für Digital Access hat das eine wichtige Konsequenz. In Enterprise Agreements ist Digital Access für interne Integrationen häufig als unbegrenzte Leistung inkludiert. Kein separates Dokumentkontingent, keine Overage-Regelung für interne Systeme, keine gesonderte Position in der Order Form. Das klingt nach vollständiger Planbarkeit, und ist es auch, solange der Integrationsbedarf tatsächlich innerhalb des definierten Geltungsbereichs bleibt.

Der entscheidende Begriff ist "intern". Er ist im Vertrag definiert, nicht im allgemeinen Sprachgebrauch. Was für eine Unternehmensabteilung als intern gilt, muss im Digital Access Supplement des jeweiligen RISE-Vertrags nicht zwingend als intern im Sinne der EA-Inklusion gelten.

Ein Steuerungsmoment entsteht an genau dieser Stelle: Die Inklusionslogik des Enterprise Agreements bietet echten Spielraum für die Gestaltung der internen Integrationslandschaft. Dieser Spielraum lässt sich nur nutzen, wer seinen Vertragstext kennt und versteht, wo die Grenzen der Inklusion liegen.

Was "interne Systeme" bedeutet und wo die Grenze liegt

Im Kontext des SAP Digital Access Supplements bezeichnet "interne Systeme" Systeme, die vom selben juristischen Vertragspartner betrieben werden und unter denselben RISE-Vertrag fallen. In der Praxis bedeutet das: Systeme des Unternehmens selbst, auf denselben juristischen Entitäten, die im Vertragswerk namentlich benannt sind.

Drei Abgrenzungsebenen sind relevant:

Eigene Gesellschaft vs. Konzerngesellschaft: Wenn der RISE-Vertrag auf die Muttergesellschaft lautet und eine Tochtergesellschaft über eine SAP-Schnittstelle Dokumente erstellt, ist das nicht automatisch unter die EA-Inklusion gefasst. Ob Konzerngesellschaften als "intern" gelten, hängt davon ab, ob sie im Enterprise Agreement explizit als berechtigte Einheiten benannt sind. Sogenannte "Affiliate"-Klauseln regeln das, und ihr Umfang variiert erheblich zwischen Vertragsversionen.

Outsourcing-Partner und Dienstleister: Wenn ein externer Dienstleister im Auftrag des Unternehmens SAP-Buchungen erzeugt, zum Beispiel ein Logistik-Outsourcing-Partner, der Wareneingänge bucht, ist das kein interner Systemzugriff im Sinne des Enterprise Agreements. Der Dienstleister ist nicht Vertragspartner, seine Systeme sind nicht Teil des definierten Geltungsbereichs.

Technische Betriebsmodelle: In manchen Infrastrukturmodellen werden Systeme von einem Dritten technisch betrieben, aber im Auftrag und für Rechnung des RISE-Vertragspartners. Ob das als intern gilt, ist eine Auslegungsfrage, die im Zweifelsfall mit SAP geklärt werden sollte. Die Formulierungen im Supplement sind ausschlaggebend.

Die praktische Konsequenz: Wer den Geltungsbereich der EA-Inklusion nicht kennt, kann nicht verlässlich einschätzen, welche seiner Integrationen abgedeckt sind und welche nicht. Das ist ein Steuerungsmoment im Bereich Berechtigungen: Welche Schnittstellen haben eine belastbare Lizenzgrundlage, und welche befinden sich in einer Grauzone?

Was in RISE typischerweise nicht abgedeckt ist

Vier Integrationskategorien fallen häufig aus der EA-Inklusion heraus. Die Formulierung "häufig" ist bewusst gewählt: Der Vertragstext ist der Maßstab, und es gibt kein einheitliches RISE-Vertragswerk. Aber die folgende Kategorisierung spiegelt die Praxis in einer großen Mehrheit der RISE-Portfolios wider.

Externe Drittparteien mit Schnittstellen-Zugriff: Wenn ein Lieferant über ein Einkaufsportal Bestellbestätigungen oder Lieferavise in SAP zurückspielt, handelt er als externe Partei. Das Portal, über das er agiert, ist nicht Teil des EA-Geltungsbereichs. Dasselbe gilt für Kunden, die über ein B2B-Portal Aufträge direkt in SAP erfassen.

Externe SaaS-Plattformen: Wenn eine extern betriebene E-Commerce-Plattform Kundenbestellungen als Sales Orders nach SAP überträgt, ist die SaaS-Plattform kein internes System des RISE-Vertragspartners. Sie ist ein externer Dienstleister, der eine Schnittstelle betreibt. Digital Access für die dabei erzeugten Sales Order Items fällt nicht automatisch unter die EA-Inklusion.

IoT-Plattformen und Connected Manufacturing: Produktionsnahe IoT-Umgebungen erzeugen oft sehr hohe Volumina an Manufacturing Order Items und Goods Movement Items. Wenn diese Plattformen von einem Spezialanbieter betrieben werden oder eigenständige Systeme außerhalb des definierten EA-Scopes sind, greift die Inklusion nicht. Das Volumen macht diesen Fall besonders relevant: Tausende von Fertigungsmeldungen täglich können, ohne belastbare Lizenzgrundlage, erhebliche Nachforderungen auslösen.

Kundenseitige Portale für B2B-Geschäfte: Händlerportale, Serviceanfragen-Plattformen oder Bestell-Applikationen, über die Geschäftskunden direkt Transaktionen in SAP auslösen, sind typischerweise keine internen Systeme. Named-User-Lizenzierung ist hier nicht praktikabel, und die EA-Inklusion deckt diese Szenarien nicht ab. Digital Access über ein DAAP-Amendment ist in solchen Fällen die strukturell richtige Lösung.

RISE-Vertragsgenerationscheck: Welcher Supplement-Stand gilt?

Die RISE-Einführung hat in vielen Unternehmen eine Vertragshistorie, die bis in die On-Premise-Ära zurückreicht. Kunden, die vor 2019 SAP-Verträge hatten und auf RISE migriert sind, haben dabei nicht automatisch alle älteren Vertragsbestandteile durch neue Standardbedingungen ersetzen lassen.

Drei Szenarien sind in der Praxis häufig anzutreffen:

Szenario A: Migration ohne vollständigen Vertragscheck. Der bestehende On-Premise-Vertrag wurde durch einen RISE-Vertrag abgelöst, aber die Supplementstruktur wurde nicht vollständig harmonisiert. Das kann bedeuten: Es existiert kein Digital Access Supplement, weil das DAAP-Programm nicht abgeschlossen wurde. Integrationen, die früher unter Indirect-Access-Regeln liefen, laufen jetzt ohne belastbare Nachfolge-Grundlage.

Szenario B: DAAP-Amendment steht noch aus. Das Unternehmen hat einen RISE-Vertrag abgeschlossen, aber das DAAP-Amendment wurde noch nicht verhandelt. Die EA-Inklusion für interne Systeme gilt, aber der Bereich außerhalb dieser Inklusion ist nicht durch ein Document-Based Licensing Supplement abgedeckt. Für externe Integrationen fehlt die Vertragsgrundlage.

Szenario C: Ältere GTC-Version. Nicht alle RISE-Verträge wurden auf die aktuellen SAP General Terms and Conditions migriert. Ältere GTC-Versionen kennen das Digital-Access-Modell möglicherweise nicht in der aktuellen Form. Ein Vertragsgenerationscheck klärt, welche GTC gilt, welche Supplements vorliegen und welche Konsequenzen sich daraus ergeben.

Die Handlungsempfehlung ist dieselbe in allen drei Szenarien: Welcher Supplement-Stand gilt in Ihrem RISE-Vertrag? Diese Frage lässt sich mit einem Blick in das Digital Access Supplement und das DAAP-Amendment beantworten, sofern beides vorliegt. Ist das Supplement nicht auffindbar, ist das bereits eine relevante Information.

Aktuelle SAP-Vertragstemplates sind öffentlich zugänglich im SAP Trust Center unter sap.com/about/trust-center/agreements.html. Der dort veröffentlichte Stand gibt einen Referenzrahmen, aber Ihr konkreter Vertragsstand kann abweichen.

RISE-Migration: Mitgebrachte On-Premise-Integrationen als Lizenz-Check

RISE-Migrationen betreffen nicht nur das Kernsystem. Sie betreffen die gesamte Integrationslandschaft. Jede Schnittstelle, die ein On-Premise-System mit Drittanbieter-Lösungen verbunden hat, wird in der RISE-Architektur neu konfiguriert, migriert oder abgelöst.

Dabei entsteht ein spezifischer Steuerungsmoment: Der Lizenzstatus einer On-Premise-Integration überträgt sich nicht automatisch auf die RISE-Umgebung. Eine Schnittstelle, die in der On-Premise-Welt über Named User abgedeckt war, muss im RISE-Kontext erneut bewertet werden. Die Frage ist nicht nur, ob die Schnittstelle technisch funktioniert, sondern ob sie lizenzrechtlich korrekt eingeordnet ist.

Drei Bereiche sind bei der RISE-Migration besonders zu prüfen:

Bestehende Named-User-Abdeckungen: Wenn eine Integration bisher über Named User lizenziert war, ist zu klären, ob diese Lizenzierung im neuen RISE-Vertragswerk weiterhin gilt. Named-User-Typen aus On-Premise-Preislisten haben im RISE-EA-Modell keine direkte Entsprechung.

Integrationen, die unter Indirect Access geführt wurden: Vor 2019 abgeschlossene Verträge kennen das Digital-Access-Modell nicht. Wenn eine Integration aus dieser Ära in die RISE-Umgebung überführt wird, ist ihre Lizenzgrundlage neu zu definieren.

Neue Dokumenttypen durch Architekturwechsel: Ein Middleware-Wechsel, etwa von SAP PI auf BTP Integration Suite, kann dazu führen, dass eine Integration andere Dokumenttypen erzeugt als bisher, oder dass sie erstmals als separate Schnittstelle in Erscheinung tritt. Das verändert das Digital-Access-Profil dieser Integration.

Das Integrationsregister, das aus diesem Review entsteht, ist kein einmaliges Projekt. Es ist die Grundlage für den laufenden Steuerungsmoment im Bereich Infrastruktur: Welche Schnittstellen sind aktiv? Welche Middleware verwaltet welche Flows? Hat eine Veränderung der Architektur den Lizenzstatus verändert?

BTP Integration Suite und Digital Access: Zwei getrennte Themen

In RISE-Portfolios wird die SAP Integration Suite auf BTP häufig als zentrale Middleware eingesetzt. Sie verbindet SAP-Systeme mit Drittanbieter-Lösungen und ist über CPEA-Credits lizenziert.

Hier besteht in der Praxis eine häufige Verwechslung: BTP-Credits für den Betrieb der Integration Suite und die Digital-Access-Lizenzierung für die dabei erzeugten Dokument-Items sind zwei getrennte Themen.

Der Betrieb einer Integration über die BTP Integration Suite ist ein BTP-Credit-Verbrauch. Das ist eine Infrastrukturgebühr für die Nutzung des Cloud-Services. Die Lizenzpflicht für die Dokument-Items, die diese Integration in SAP erstellt, ist eine Digital-Access-Frage. Beide Positionen entstehen durch denselben Betrieb, werden aber in verschiedenen Vertragsbestandteilen geregelt und separat abgerechnet.

Das hat eine konkrete Planungskonsequenz: Wer eine neue Integration über BTP Integration Suite plant, muss beide Kostendimensionen in der Kalkulation berücksichtigen. BTP-Credits für den Infrastrukturbetrieb und Digital-Access-Kontingente für die erzeugten Dokumente. Bei hohem Integrationsvolumen können beide Positionen erheblich sein.

Der Steuerungsmoment im Bereich Kosten schließt beide ein: Was wird in der SAP-Rechnung für Digital Access ausgewiesen? Stimmt es mit dem gemessenen Dokumentvolumen überein? Und wie verhält sich der BTP-Credit-Verbrauch zur geplanten Kapazität?

FAQ

Ist Digital Access bei RISE with SAP automatisch und vollständig enthalten?

Für interne Integrationen im Geltungsbereich des Enterprise Agreements ist Digital Access in RISE-Verträgen häufig unbegrenzt inkludiert. "Vollständig" trifft es jedoch nicht: Externe Systeme, Kunden-Portale, Lieferanten-Plattformen und IoT-Integrationen fallen in der Regel nicht unter diese Inklusion. Der Vertragstext ist die maßgebliche Referenz.

Was ist der Unterschied zwischen "intern" und "Affiliate" im RISE-Kontext?

"Intern" bezeichnet im Digital-Access-Supplement typischerweise den direkten Vertragspartner und seine eigenen Systeme. "Affiliate" ist eine davon getrennte Kategorie für verbundene Gesellschaften, die im Vertrag explizit eingeschlossen sein müssen. Ob Konzerngesellschaften als Affiliates gelten und ob Affiliates von der EA-Inklusion erfasst sind, ist vertragsabhängig.

Muss ich nach einer RISE-Migration meine Integrationen erneut auf Digital Access prüfen?

Ja. Die RISE-Migration überführt nicht automatisch die Lizenzgrundlagen aus dem On-Premise-Vertrag. Integrationen, die auf Named User oder historischen Indirect-Access-Regelungen basierten, benötigen eine neue Bewertung im RISE-Vertragskontext. Besonders bei einem Middleware-Wechsel, zum Beispiel von SAP PI auf BTP Integration Suite, kann sich das Digital-Access-Profil einer Integration verändern.

Was passiert, wenn keine DAAP-Verhandlung nach der RISE-Migration stattgefunden hat?

Für externe Integrationen außerhalb der EA-Inklusion fehlt dann die vertragliche Grundlage für Document-Based Licensing. Diese Integrationen befinden sich in einem lizenzrechtlichen Graubereich. Im Enhanced Audit kann SAP diese Lücke identifizieren und retroaktive Nachforderungen geltend machen. Ein DAAP-Amendment kann nachträglich abgeschlossen werden und schließt typischerweise auch eine Retrospektiv-Bereinigung ein.

Nächste Schritte

Digital Access in RISE-Verträgen ist kein Thema, das sich einmalig klärt und dann erledigt ist. Der Geltungsbereich der EA-Inklusion, der Supplement-Stand und der Lizenzstatus einzelner Integrationen sind Steuerungsmomente, die laufend beobachtet werden müssen.

Vertragscheck buchen: In vier Wochen klären wir, welche Integrationen in Ihrem RISE-Portfolio unter die EA-Inklusion fallen, wo DAAP-Bedarf besteht und welche Handlungsoptionen Sie beim nächsten Renewal haben. Festpreis, 7.900 EUR.

Weiterführend: Digital Access und Indirect Access: Begriffe, Geschichte, Lizenzoptionen und Welche Drittanbieter-Systeme SAP Digital Access auslösen.