Digital Access nach Benutzer auswerten: ECC und S/4HANA
Digital Access wird nicht wie eine klassische Named-User-Lizenz gemessen. Maßgeblich sind definierte Dokumenttypen, die durch indirekte oder digitale Zugriffe in SAP entstehen. Die Standardmessung zeigt deshalb zunächst Dokumentmengen, nicht die Personen, Schnittstellen oder Automatisierungen hinter diesen Mengen.
Für die laufende Vertragssteuerung reicht die aggregierte Zahl allein häufig nicht aus. Wenn ein Dokumentvolumen steigt, entsteht die nächste Frage: Welche technische Verbindung, welcher Bot oder welcher SAP-Benutzer hat diese Nutzung ausgelöst? Erst diese Zuordnung schafft eine Grundlage, um Nutzung fachlich einzuordnen, Verantwortlichkeiten zu klären und die erwartete Entwicklung bis zum Renewal zu bewerten.
SAP stellt für ECC und S/4HANA unterschiedliche Standardreports bereit, mit denen sich Digital-Access-relevante Dokumentmengen für ausgewählte Benutzer untersuchen lassen. FinOptory führt diese Reports im Managed Service zunächst manuell aus. Dafür benötigt der zuständige FinOptory-Berater einen dedizierten Benutzer in jedem relevanten Quellsystem. Eine zusätzliche Schnittstelle oder eine Änderung am FinOptory-Reporting ist dafür zunächst nicht erforderlich.
Warum Digital Access eine zusätzliche Benutzerperspektive braucht
Bei Named User Licensing ist die Zuordnung im Lizenzmodell angelegt: Ein Benutzer wird einer Lizenzkategorie zugeordnet. Digital Access folgt einer anderen Logik. SAP betrachtet die initiale Erstellung bestimmter Dokumenttypen durch indirekten oder digitalen Zugriff. Dazu gehören unter anderem Sales Documents, Invoice Documents, Purchase Documents und Material Documents.
Diese Dokumentenlogik ist für die vertragliche Messung entscheidend. Für die interne Steuerung entsteht daneben eine zweite Perspektive. Ein Unternehmen muss nachvollziehen können, welche technische Nutzung hinter den gezählten Mengen steht. Ein gemeinsamer Schnittstellenbenutzer kann beispielsweise Dokumente für mehrere Prozesse erzeugen. Ein RPA-Benutzer kann in kurzer Zeit eine große Zahl gleichartiger Vorgänge anlegen. Ein technischer Benutzer kann mehreren Fachbereichen dienen.
Die Benutzerzuordnung beantwortet deshalb nicht automatisch jede fachliche Kostenfrage. Sie liefert aber den technischen Ausgangspunkt:
- Welche Benutzerkennungen erzeugen Digital-Access-relevante Dokumente?
- Welche Dokumenttypen und Mengen sind diesen Kennungen zugeordnet?
- In welchen ECC- und S/4HANA-Systemen entsteht die Nutzung?
- Welche Schnittstelle, Automatisierung oder organisatorische Verantwortung steht hinter der jeweiligen Kennung?
Damit wird aus einer aggregierten Messzahl eine steuerbare Nutzungsstruktur. Diese Struktur kann in die Vertragsprognose, in die Bewertung von Integrationen und in die Renewal-Vorbereitung einfließen.
Welche SAP-Reports für ECC und S/4HANA relevant sind
SAP unterscheidet zwischen der Standardmessung für Digital Access und ergänzenden Auswertungen zur Abschätzung und Analyse.
Für ECC: Der Report DAC_ECC_COUNT_DOCTYP_ITEM wird über SAP Note 2992090 bereitgestellt. Er dient dazu, Digital-Access-relevante Dokumenttypen und Positionen im ECC-Kontext auszuwerten.
Für S/4HANA: Der entsprechende Report heißt DAC_S4_COUNT_DOCTYP_ITEM. Die Bereitstellung und die technischen Voraussetzungen beschreibt SAP Note 2999672.
Für die Standardmessung: RSUVM_DAC ist der zentrale SAP-Report für die Digital-Access-Messung. Die zugehörigen Korrekturen und Voraussetzungen beschreibt SAP unter anderem in Note 2837612.
Für eine gemischte Landschaft bedeutet das: ECC und S/4HANA werden getrennt behandelt. Der jeweils passende Report wird in dem System ausgeführt, dessen Dokumente untersucht werden sollen. Ein zentrales System kann die lokale Ausführung nicht ersetzen, wenn die relevanten Belege und technischen Benutzerkontexte in den Quellsystemen liegen.
Die Ergebnisse können anschließend über die Systeme hinweg konsolidiert werden. Dabei sollten System, Mandant, Zeitraum, Benutzer und Dokumenttyp als getrennte Merkmale erhalten bleiben. Nur so bleibt erkennbar, wo eine Menge tatsächlich entstanden ist.
Das Vorgehen in fünf Schritten
1. Systeme und Benutzer festlegen
Der erste Schritt ist keine Messung, sondern eine klare Abgrenzung. Erstellen Sie eine Liste aller produktiven ECC- und S/4HANA-Systeme, die für die untersuchten Prozesse relevant sind. Dokumentieren Sie pro System mindestens SID, Mandant, Release und Support-Package-Stand.
Danach legen Sie die Benutzerkennungen fest, die untersucht werden sollen. Relevant sind insbesondere technische Benutzer, Schnittstellenbenutzer, RPA-Benutzer und gemeinsam genutzte Integrationskonten. Ergänzen Sie nach Möglichkeit den fachlichen Prozess, den technischen Owner und den verantwortlichen Geschäftsbereich.
2. Technische Voraussetzungen prüfen
Vor der Ausführung muss geklärt sein, ob die erforderlichen SAP Notes und Reports im jeweiligen System vorhanden sind. Für ECC ist Note 2992090 maßgeblich, für S/4HANA Note 2999672. Die allgemeinen Voraussetzungen der Digital-Access-Messung und die SAP-Passport-Kennzeichnung sind ebenfalls zu prüfen. SAP beschreibt den Passport-Kontext in Note 2738406.
Die Release- und Support-Package-Stände gehören in diese Prüfung. Ein Reportname allein bestätigt noch nicht, dass alle erforderlichen Korrekturen vollständig implementiert sind. Deshalb sollte die SAP-Basis die Notes im konkreten System prüfen und den Stand dokumentieren.
3. FinOptory-Benutzer bereitstellen
FinOptory erbringt die Analyse als Managed Service. Deshalb wird für den zuständigen FinOptory-Berater ein dedizierter Dialogbenutzer in jedem betroffenen ECC- oder S/4HANA-Quellsystem angelegt. Ein zentraler Benutzer in einem anderen SAP-System genügt für die lokale Reportausführung nicht.
Dieser Benutzer braucht die Berechtigung, sich per SAP GUI anzumelden, den jeweiligen Report zu starten, die erforderlichen Daten zu lesen und das Ergebnis beziehungsweise den Spool anzuzeigen und zu exportieren. Falls die Ausführung als Hintergrundjob erfolgt, kommen die kundenseitig definierten Job-Berechtigungen hinzu. SAP Note 1732566 kann als Referenz für die von SAP beschriebenen Support-Berechtigungen dienen. Die kundeneigene Minimalrolle wird im jeweiligen Release geprüft und bei Bedarf mit SU53 oder einem Berechtigungs-Trace vervollständigt. Änderungs-, Entwicklungs-, Transport- und Administrationsrechte sind nicht erforderlich.
4. Reports mit vergleichbaren Parametern ausführen
Der Auswertungszeitraum muss vorab feststehen. Für eine Baseline bietet sich ein vollständig abgeschlossener Zeitraum an, beispielsweise das letzte Vertragsjahr oder die letzten zwölf vollständigen Monate. Für Trendanalysen sollten alle Systeme mit derselben Periodenlogik ausgewertet werden.
FinOptory führt in ECC DAC_ECC_COUNT_DOCTYP_ITEM und in S/4HANA DAC_S4_COUNT_DOCTYP_ITEM für die ausgewählten Benutzer aus. Selektionsparameter, Laufdatum und Systemkontext werden dokumentiert. Die Ergebnisliste oder der Spool wird in einem Format exportiert, das die weitere Auswertung zulässt.
Der Reportlauf ist zunächst eine technische Zuordnung. Er beantwortet, welche Mengen unter einer bestimmten Benutzerkennung sichtbar werden. Er beantwortet noch nicht, welcher Fachbereich den Vorgang wirtschaftlich verantwortet. Diese Zuordnung erfolgt im nächsten Schritt.
5. Benutzer technisch und fachlich zuordnen
Verbinden Sie jedes Ergebnis mit dem zugehörigen Integrations- oder Automatisierungsregister. Ein technischer Benutzer sollte mindestens einem System, einer Schnittstelle, einem Prozess, einem Owner und einem Geschäftsbereich zugeordnet sein.
Bei dedizierten Benutzerkennungen ist diese Verbindung meist eindeutig. Bei gemeinsam genutzten Kennungen bleibt die Aussage eingeschränkt. Wenn drei Schnittstellen denselben technischen Benutzer verwenden, lässt sich die Dokumentmenge zunächst diesem Benutzer, aber nicht automatisch einer einzelnen Schnittstelle zuordnen. Für die zukünftige Steuerung kann deshalb eine Trennung der Benutzerkennungen sinnvoll sein.
Das Ergebnis ist eine nachvollziehbare Kette: Dokumentmenge, SAP-System, Benutzerkennung, technische Verbindung und fachliche Verantwortung. Diese Kette bildet die Grundlage für eine verursachungsgerechte Einordnung der Nutzung.
Was Sie für die erste Auswertung bereitstellen
Für den manuellen Einstieg reichen sechs Datenpakete:
- Systemliste: Alle relevanten ECC- und S/4HANA-Systeme mit SID, Mandant, Release und Support-Package-Stand.
- Benutzerliste: Die zu untersuchenden technischen, Schnittstellen- und RPA-Benutzer mit Owner und Prozessbezug.
- Zeitraum: Ein einheitlicher Analysezeitraum, idealerweise ausgerichtet an Vertragsjahr oder Renewal-Vorbereitung.
- Reportstand: Bestätigung, ob
DAC_ECC_COUNT_DOCTYP_ITEM,DAC_S4_COUNT_DOCTYP_ITEMundRSUVM_DACim jeweiligen System verfügbar sind. - FinOptory-Zugang: Ein dedizierter Dialogbenutzer für den zuständigen FinOptory-Berater in jedem Quellsystem, einschließlich SAP-GUI-Zugang sowie Report-, Lese-, Job- und Spool-Berechtigungen.
- Ergebnisexporte: Reportausgaben mit dokumentierten Selektionsparametern und Laufdatum.
Mit diesen Informationen lässt sich die erste Baseline ohne automatische Datenanbindung erstellen. Der manuelle Lauf hat außerdem einen methodischen Vorteil: Systemgrenzen, Benutzerqualität und Datenlücken werden sichtbar, bevor ein wiederkehrender Prozess aufgebaut wird.
Wie die Ergebnisse richtig eingeordnet werden
Die benutzerbezogenen Reports ergänzen die Digital-Access-Messung. Sie ersetzen weder die vertragliche Prüfung noch die offizielle Messlogik von SAP. Insbesondere sollten vier Grenzen dokumentiert werden:
Schätzreport und Standardmessung sind unterschiedliche Ergebnisse. Die Reports DAC_ECC_COUNT_DOCTYP_ITEM und DAC_S4_COUNT_DOCTYP_ITEM dienen der Analyse und Abschätzung. Für die formale Digital-Access-Messung bleibt RSUVM_DAC maßgeblich.
Technischer Benutzer und wirtschaftlicher Verursacher sind nicht identisch. Ein Benutzerkonto kann mehreren Integrationen oder Fachbereichen dienen. Die fachliche Zuordnung braucht deshalb ein gepflegtes Integrationsregister.
Gemeinsame Benutzer begrenzen die Granularität. Je mehr technische Verbindungen eine Kennung teilen, desto weniger präzise ist die verursachungsgerechte Einordnung. Die Auswertung zeigt dann die Grenze der bestehenden Benutzerarchitektur.
Systeme müssen getrennt nachvollziehbar bleiben. Eine frühzeitige Summierung über ECC und S/4HANA kann relevante Unterschiede verdecken. Die Konsolidierung sollte erst erfolgen, wenn System, Mandant und Reportparameter dokumentiert sind.
Diese Grenzen machen die Auswertung nicht weniger nützlich. Sie definieren, welche Aussage belastbar ist und welche zusätzliche Zuordnung noch benötigt wird.
Von der manuellen Baseline zur laufenden Vertragssteuerung
Der erste Reportlauf beantwortet eine konkrete Frage: Welche Digital-Access-relevanten Dokumentmengen lassen sich ausgewählten Benutzern in unseren ECC- und S/4HANA-Systemen zuordnen?
Für die laufende Steuerung kommen anschließend drei Rhythmen hinzu: regelmäßige Wiederholung mit vergleichbaren Parametern, Pflege der Benutzer- und Integrationszuordnung sowie Abgleich mit Vertragsbestand und Renewal-Planung. Erst diese Verbindung zeigt, ob eine Mengenentwicklung einmalig, projektbedingt oder strukturell ist.
FinOptory beginnt dabei bewusst mit der vorhandenen SAP-Standardauswertung und führt sie im Managed Service selbst aus. Eine spätere technische Integration ist möglich, aber keine Voraussetzung für die erste Analyse. Entscheidend ist zunächst eine dokumentierte, reproduzierbare Baseline aus den Quellsystemen.
Weiterführend: Die neun Dokumenttypen bei Digital Access, Integrationsregister für Digital Access und Digital-Access-Audit vorbereiten.
Wenn Sie Ihre SAP-Vertrags- und Nutzungsdaten in eine laufende Steuerungsstruktur überführen möchten, bietet der FinOptory Vertragscheck einen definierten Einstieg.
Häufige Fragen
Welcher Report gilt für ECC?
Für ECC wird DAC_ECC_COUNT_DOCTYP_ITEM verwendet. SAP beschreibt Bereitstellung und Voraussetzungen in Note 2992090.
Welcher Report gilt für S/4HANA?
Für S/4HANA wird DAC_S4_COUNT_DOCTYP_ITEM verwendet. Die zugehörige SAP Note ist 2999672.
Kann der Report zentral aus einem anderen SAP-System ausgeführt werden?
Die benutzerbezogene Auswertung wird im jeweiligen Quellsystem ausgeführt. Bei mehreren ECC- und S/4HANA-Systemen entstehen daher mehrere Läufe, deren Ergebnisse anschließend konsolidiert werden.
Braucht FinOptory einen eigenen SAP-Benutzer?
Ja. Für die Leistungserbringung im Managed Service benötigt der zuständige FinOptory-Berater einen dedizierten Dialogbenutzer in jedem untersuchten ECC- oder S/4HANA-Quellsystem. Die Rolle wird auf Reportausführung, lesenden Datenzugriff, Hintergrundjobs sowie Anzeige und Export der Ergebnisse begrenzt.
Ist das Ergebnis die offizielle Digital-Access-Messung?
Nein. Die benutzerbezogenen Count-Reports unterstützen Analyse und Abschätzung. Die formale Digital-Access-Messung erfolgt über die von SAP vorgesehene Standardmessung mit RSUVM_DAC.
Über den Autor
Bernhard Mändle ist Managing Consultant bei FinOptory. Er unterstützt Unternehmen dabei, SAP-Verträge nach der Unterschrift laufend zu steuern, Nutzung und Kosten aufeinander auszurichten und die SAP-Investition gezielt einzusetzen. Langjährige Erfahrung in SAP-Vertragsverhandlung und Governance über On-Premise, BTP und SAP Cloud ERP, Private Edition, DSAG-Mitglied, unabhängig von SAP, Resellern und Systemintegratoren. Mehr unter finoptory.ai und auf LinkedIn.
Quellen:
Nächste Schritte
Wenn Sie Digital-Access-Mengen in Ihren ECC- und S/4HANA-Systemen auf Benutzer zurückführen möchten, nehmen wir die erforderlichen Systeme, Zugänge und Auswertungszeiträume gemeinsam auf.
Dieser Beitrag gehört zum Themen-Hub Digital Access und Indirect Access bei SAP. Die technische Einrichtung für den Managed Service ist im Onboarding-Leitfaden dokumentiert.
Zuletzt aktualisiert: August 2026