Digital Access und Indirect Access

Spätestens wenn ihr Richtung RISE with SAP, GROW oder SAP Cloud ERP (Public/Private) denkt, taucht ein Thema auf, das gerne „unter dem Radar“ bleibt – bis es teuer wird: Digital Access bzw. Indirect Access. Gemeint ist der Zugriff auf SAP-Systeme über Drittanwendungen, Schnittstellen, Portale, Bots oder Automatisierungen, also nicht über klassische Named User im SAP GUI/Fiori.

Das Problem: Fachlich ist das oft „nur Integration“. Lizenzseitig kann es aber bedeuten, dass Transaktionen oder Dokumente im SAP-System durch Nicht-SAP-Systeme ausgelöst werden – und das kann (je nach Vertrag) lizenzrelevant sein. Wer das zu spät prüft, erlebt im Audit, bei Vertragsverlängerungen oder während der Cloud-Transition unangenehme Überraschungen.

In diesem Artikel bekommst du einen klaren, praxisnahen Überblick: Was ist Indirect Access, was ist Digital Access, warum ist es in der Cloud besonders relevant – und wie gehst du strukturiert vor, um Risiken zu erkennen, zu messen und sauber zu steuern.

Jetzt Kontakt aufnehmen!

Indirect Access beschreibt den Zugriff auf SAP-Funktionalität ohne direkte Anmeldung eines SAP-Nutzers, z. B. wenn:

• ein CRM (nicht SAP) einen Auftrag in SAP anlegt,

• ein E-Commerce-Shop Bestellungen ins SAP ERP schreibt,

• ein MES/Shopfloor-System Rückmeldungen oder Materialbewegungen bucht,

• ein Data-Lake/BI-Tool Daten zieht oder schreibt,

• RPA/Bots Transaktionen ausführen.

Wichtig: Es geht nicht darum, ob jemand „SAP benutzt“, sondern wie SAP-Funktionen konsumiert werden. Lizenzseitig ist genau diese indirekte Nutzung historisch oft der Kern von Diskussionen, weil klassische Named-User-Modelle ursprünglich für eine Welt gebaut wurden, in der „SAP = Benutzer meldet sich in SAP an“.

Digital Access ist ein Lizenzmodell, das Indirect Access über ein dokumentbasiertes Prinzip adressiert. Statt jeden indirekten „User“ nach Named-User-Logik zu lizenzieren, wird – vereinfacht – darauf geschaut, welche geschäftlichen Ergebnisobjekte (Dokumente) im SAP-System entstehen, wenn sie durch Nicht-SAP-Anwendungen angestoßen werden.

Der Nutzen (wenn sauber umgesetzt):

• bessere Planbarkeit für Integrations- und Plattform-Szenarien,

• klarere Diskussion über „Business Outcomes“ statt technische Zugriffspfade,

• weniger Grauzone als bei reinem Named-User-Denken.

Aber: Digital Access ist kein Freifahrtschein. Du musst wissen, welche Dokumentarten zählen, wie sie gezählt werden, und wie du interne vs. externe Auslöser sauber trennst – sonst wird die BOM (Lizenz-Stückliste) unpräzise.

In Cloud-Programmen steigt Indirect Access fast automatisch, weil ihr stärker integriert und automatisiert:

• mehr APIs und Event-basierte Integrationen,

• mehr Side-by-Side Extensions (z. B. auf SAP BTP),

• mehr Self-Service-Frontends (Portale, Apps, Partnerzugriffe),

• mehr Automatisierung (Workflows, Bots, Integration Flows).

Gerade in Public Edition ist „Clean Core“ oft das Ziel: Anpassungen wandern raus in Extensions und Integrationen. Das ist fachlich sinnvoll – lizenzseitig brauchst du dann aber umso mehr Transparenz, welche Prozesse externe Systeme im SAP-Kern auslösen.

Wenn du Cloud ERP evaluierst, helfen diese Seiten als Kontext:  

Public Edition: SAP S/4HANA Cloud, Public Edition - Fink IT-Solutions

Private Edition: SAP S/4HANA Cloud, Private Edition - Fink IT-Solutions

Damit es greifbar wird – hier sind Muster, die ich in fast jedem Unternehmen sehe:

1. E-Commerce → SAP SD
   Bestellung wird im Shop erfasst, SAP erzeugt Auftrag/Lieferung/Rechnung.

2. 3rd-Party CRM → SAP
   Angebote/Opportunities triggern Angebots- oder Auftragsanlage.

3. MES/IoT → SAP PP/MM
   Rückmeldungen, Wareneingänge, Materialbewegungen werden automatisch gebucht.

4. Partnerportal → SAP
   Lieferanten oder Kunden erfassen Daten, die in SAP „echte“ Geschäftsdokumente erzeugen.

5. RPA/Bots
   Bots laufen nachts durch Transaktionen und erzeugen Belege – technisch „kein User“, lizenzseitig aber relevant.

Wenn du Integrationsarchitektur oder Schnittstellenmanagement aufbauen willst, ist das hier ein sinnvoller Einstieg:

Business Process Integration: Business Process Integration - Fink IT-Solutions

Named User lizenziert in der Regel den Zugriff einer Person (oder eines technischen Users) auf SAP-Funktionalität.
Digital Access adressiert typischerweise die indirekte Auslösung von geschäftlichen Dokumenten durch externe Systeme.

In der Praxis ist die entscheidende Frage:

• „Lizenzieren wir Personen, Systeme oder Ergebnisse?“

Und genau deshalb brauchst du eine saubere, programmgesteuerte Sicht:

• Rollenmodell und Berechtigungen (User-Seite),

• Integrationsinventar (System-Seite),

• Dokument-/Transaktionsauswertung (Outcome-Seite).

Wenn du das Thema pragmatisch lösen willst, geh in drei Wellen vor:

Hier passieren in Projekten die teuersten Fehler:

• „Wir haben Integration, also sind wir safe.“
  Integration ist technisch gut – lizenzseitig kann sie neue Zählgrößen erzeugen.

• Non-Prod wird vergessen.
  Dev/Test/Sandbox und Projektspitzen (Cutover/Hypercare) erzeugen Volumen und Zugriff, der in Governance und Vertrag berücksichtigt werden muss.

• RPA wird unterschätzt.
  Bots können innerhalb kürzester Zeit „mehr Business Outcomes“ erzeugen als ganze Teams.

• Scope drift in der Cloud-Transition.
  Heute 20 Schnittstellen, morgen 80 – wenn du die Governance nicht von Anfang an setzt, ist die BOM nach 6 Monaten wertlos.

• Public/Private wird als Schwarz-Weiß verstanden.
  In der Realität entscheidet ihr pro Domäne. Digital Access muss diese Realität abbilden, sonst wird die Lizenzlogik widersprüchlich.

So bleibt ihr handlungsfähig:

1. „Integration Design Authority“ etablieren
   Jede neue Schnittstelle wird architektonisch und lizenzseitig bewertet.

2. Rollenmodell + IAM sauber aufsetzen
   Kein Wildwuchs bei technischen Usern, klare Regeln für Partnerzugriffe.

3. Extension-Strategie dokumentieren
   Was bleibt im Core, was geht Side-by-Side – und welche Lizenz-/Betriebsfolgen hat das?

4. BOM versionieren wie Engineering
   v0.9 Plan → v1.0 Vertrag → v1.1 Go-Live → v1.2 Stabilisierung.
   So bleibt Digital Access steuerbar.

5. Quartals-Review als Standard
   Interfaces, Dokumentvolumen, Bots, neue Länder/Prozesse. Nicht optional.

Indirect Access ist heute Standard – weil moderne ERP-Landschaften integriert, automatisiert und API-getrieben sind. Digital Access kann das lizenzseitig planbarer machen, aber nur, wenn du Transparenz und Governance ernst nimmst: Schnittstelleninventar, Dokument-/Outcome-Sicht, Rollenmodell und regelmäßige Reviews. Wer das früh sauber aufsetzt, schützt Business Case und Compliance – und kann Cloud ERP Public oder Private deutlich entspannter skalieren.