Das Integrationsregister als Compliance-Basis fuer Digital Access

Wer seinen Digital-Access-Status kennen will, braucht zuerst eine vollständige Antwort auf eine einfache Frage: Welche Systeme haben eine Schnittstelle zu SAP, und was schreiben sie dort hinein?

Diese Frage klingt trivial. In der Praxis ist sie es nicht. CRM-Systeme, Warehouse-Management-Lösungen, RPA-Bots, E-Commerce-Plattformen, Treasury-Systeme: Sie alle können über ihre SAP-Schnittstellen Dokument-Items erzeugen, die eine Lizenzpflicht auslösen. Welche das konkret sind, und ob die jeweilige Lizenzgrundlage dokumentiert ist, ist in vielen SAP-Portfolios nicht systematisch erfasst.

Das Integrationsregister schließt diese Lücke. Es ist kein Audit-Dokument, das einmalig erstellt und abgelegt wird. Es ist ein lebendes Werkzeug im Steuerungsrhythmus für den Steuerungsmoment, der entscheidet, ob Sie bei einem Enhanced Audit mit offenen Karten verhandeln oder mit Erklärungsbedarf.

Warum ein Integrationsregister die Basis ist

Digital-Access-Governance beginnt mit Sichtbarkeit. Wer nicht weiß, welche Integrationen in seinem Portfolio welche Dokumenttypen in SAP erstellen, kann weder den Lizenzstatus prüfen noch Overage-Risiken erkennen noch eine DAAP-Verhandlung vorbereiten.

In der Praxis zeigt sich, dass Integrationslandschaften über Zeit gewachsen sind, oft ohne zentrales Inventar. IT-Architektur-Dokumentationen erfassen Systeme und Schnittstellen aus Betriebsperspektive. Die Frage, welche dieser Schnittstellen lizenzpflichtige Dokumenttypen erstellen, wird dabei häufig nicht mitgeführt.

Das schafft einen Steuerungsmoment im Bereich Berechtigungen: Welche Schnittstellen sind aktiv, welche Dokumenttypen erzeugen sie, und ist die Lizenzgrundlage für jede Schnittstelle dokumentiert? Diese Frage ist keine rein technische Frage. Sie ist eine Governance-Frage, die in der Verantwortung von Contract Management und Procurement liegt.

Das Integrationsregister ist die strukturierte Antwort auf diese Frage: systematisch aufgebaut, im Steuerungsrhythmus gepflegt und bei Renewal und Audit als belastbare Grundlage eingesetzt.

Welche Informationen pro Integration erfasst werden

Ein belastbares Integrationsregister erfasst für jede Schnittstelle zu SAP sieben Informationskategorien.

System-Bezeichnung und Verantwortlicher: Name des Drittsystems, der technische Ansprechpartner und die Fachseite, die das System verantwortet. Diese Zuordnung ist wichtig, weil Lizenzentscheidungen die Fachseite betreffen, nicht nur die IT.

Kommunikationsrichtung: Liest das System nur SAP-Daten aus (Static Read, keine Lizenzpflicht), oder schreibt es in SAP zurück? Bei bidirektionalen Schnittstellen ist der schreibende Teil lizenzrelevant.

Erzeugte Dokumenttypen: Welche der neun definierten Dokumenttypen erstellt die Schnittstelle in SAP? Sales Order Items? Goods Movement Items? Journal Entries? Für Schnittstellen, die nichts aus der Liste der neun Typen erzeugen, entsteht keine Digital-Access-Pflicht.

Monatliches Dokumentvolumen: Wie viele Dokument-Items erzeugt die Schnittstelle pro Monat? Diese Zahl ist die Planungsgrundlage für DAAP-Kontingente und die Grundlage für die Entscheidung Named User vs. Document-Based Licensing.

Nutzerbasis: Wer steht hinter der Schnittstelle? Interne Mitarbeiter, externe Kunden, Lieferanten oder vollständig automatisierte Prozesse (Bots)? Die Antwort beeinflusst direkt, welcher Lizenzweg geeignet ist.

Aktuelle Lizenzgrundlage: Named-User-Lizenz, Digital-Access-Supplement (DAAP-Amendment), anerkannte Ausnahme (Static Read, Export-Regel, IRPA-Typ-68/69-Bot) oder keine dokumentierte Grundlage. Dieser Eintrag ist der Kern der Compliance-Bewertung.

Statusdatum und letzter Review: Wann wurde die Schnittstelle zuletzt auf Richtigkeit geprüft? Eine Angabe, die nicht gepflegt wird, verliert ihren Aussagewert.

Diese sieben Felder bilden das Minimum. In größeren Portfolios können weitere Felder sinnvoll sein, etwa die Middleware, über die die Schnittstelle betrieben wird, oder der Prüfstatus nach einer RISE-Migration.

Wie das Register aufgebaut wird (Schritt für Schritt)

Der Aufbau des Integrationsregisters folgt einem strukturierten Prozess in fünf Schritten.

Schritt 1: Alle Systeme mit SAP-Schnittstelle identifizieren

Der erste Schritt ist eine umfassende Erhebung. Quellen dafür sind IT-Architektur-Dokumentationen, Middleware-Konfigurationen (SAP Integration Suite, SAP PI/PO, iPaaS-Plattformen wie MuleSoft oder Boomi), Schnittstellen-Register und, oft unterschätzt, vergangene SAP-Vertragsverhandlungen, in denen bestimmte Integrationsbestandteile bereits kommerziell berücksichtigt wurden.

Für die Erhebung empfiehlt sich eine Befragung der Fachbereiche: Welche externen Systeme nutzen SAP-Daten oder schreiben in SAP? Fachbereiche kennen häufig Systeme, die in keiner IT-Dokumentation auftauchen, weil sie als Business-Applikationen eingeführt wurden, ohne formalen IT-Architektur-Review.

Schritt 2: Dokumenttypen und Volumen pro Schnittstelle erfassen

Für jede identifizierte Schnittstelle wird geprüft, welche der neun Digital-Access-Dokumenttypen sie erzeugt und in welchem Volumen. Das Volumen sollte auf Basis eines repräsentativen Zeitraums von mindestens zwölf Monaten ermittelt werden, um saisonale Schwankungen zu erfassen.

Bei Schnittstellen, bei denen das Volumen nicht direkt aus einem Monitoring-Tool ablesbar ist, können Transaktionslogs in SAP oder der Middleware als Grundlage dienen. Das SAP Measurement Tool, das auch im DAAP-Prozess eingesetzt wird, ist ein geeignetes Instrument für diese Erhebung.

Schritt 3: Lizenzstatus pro Schnittstelle bewerten

Mit dem Inventar aus Schritt 1 und den Volumen aus Schritt 2 wird für jede Schnittstelle der Lizenzstatus bewertet. Gibt es eine dokumentierte Lizenzgrundlage? Wenn ja, welche? Wenn nein, ist diese Schnittstelle als Lücke zu erfassen.

Nicht jede Lücke hat dasselbe Risikoprofil. Eine Schnittstelle, die täglich tausende Sales Order Items erzeugt und keine Lizenzgrundlage hat, hat ein anderes Exposure als eine Schnittstelle, die monatlich wenige Inbound Delivery Items schreibt. Die Priorisierung der Lücken sollte das Volumen und den Dokumenttyp berücksichtigen.

Schritt 4: Lizenzentscheidung treffen und überführen

Für jede identifizierte Lücke wird entschieden: Named User oder Digital Access? Die Entscheidungslogik folgt dem Verhältnis zwischen Nutzerbasis und Dokumentvolumen. Bei bekannten, identifizierbaren Nutzern in begrenzter Zahl ist Named User oft der einfachere Weg. Bei anonymen Nutzern, hohem Volumen oder vollständig automatisierten Prozessen ist Document-Based Licensing die überlegene Option.

Diese Entscheidung sollte dokumentiert werden. Im Audit ist die Nachvollziehbarkeit der Entscheidungslogik mindestens genauso wichtig wie das Ergebnis.

Das Ergebnis wird in eine Vertragsänderung überführt: DAAP-Amendment für Document-Based-Lücken, Named-User-Ergänzung für identifizierbare Nutzer-Szenarien. Für DAAP-Verhandlungen bildet das Integrationsregister die Verhandlungsgrundlage gegenüber SAP.

Schritt 5: Register als lebendes Dokument etablieren

Das Integrationsregister hat nur dann dauerhaften Wert, wenn es aktuell bleibt. Dafür braucht es zwei Mechanismen.

Erstens: Neue Integrationen durchlaufen eine Lizenzprüfung vor dem Go-Live. Das ist kein optionaler Schritt, sondern ein Pflichtschritt im Einführungsprozess. Wer eine neue Schnittstelle ohne vorherige Digital-Access-Prüfung in Betrieb nimmt, schafft eine Compliance-Lücke.

Zweitens: Quartalsweise Review des Registers. Volumenentwicklung prüfen, geänderte Systemkonfigurationen erfassen, neue Integrationen nachtragen, inaktive Schnittstellen als solche markieren. Dieser Rhythmus ist Teil des systematischen Steuerungsansatzes für den Steuerungsmoment im Bereich Berechtigungen.

Neue Integrationen einführen: Lizenzprüfung als Pflichtschritt

Eine der häufigsten Ursachen für Digital-Access-Lücken ist nicht das Bestandsportfolio, sondern die neue Integration, die ohne Lizenzprüfung eingeführt wurde. Ein RPA-Rollout, der ad hoc genehmigt wurde. Eine neue E-Commerce-Plattform, bei der die Schnittstellen-Architektur in der Spezifikation steht, aber nicht die Lizenzfrage. Ein zusätzliches WMS-Modul, das als technische Erweiterung behandelt wurde.

Der Steuerungsmoment bei neuen Integrationen liegt vor dem Go-Live, nicht danach. Die Lizenzprüfung sollte Teil des Einführungsprozesses sein, verankert in den Abnahmekriterien oder in der Release-Checkliste.

Für neue Integrationen sind drei Fragen zu beantworten, bevor der Betrieb startet. Erstens: Erzeugt die Integration einen der neun Digital-Access-Dokumenttypen in SAP? Zweitens: Welcher Lizenzweg gilt, Named User oder Digital Access? Drittens: Ist die Lizenzgrundlage im Integrationsregister dokumentiert und im Vertrag verankert?

Wer diese drei Fragen vor Go-Live beantwortet, vermeidet den Aufwand einer nachträglichen Bereinigung, die bei vielen Portfolios im Rahmen einer RISE-Migration oder eines Enhanced Audits anfällt.

Laufende Pflege: Quartalsweise Review-Prozess

Das Integrationsregister verliert seinen Wert, wenn es nicht gepflegt wird. Quartalsweise Reviews sind der Rhythmus, der die Aktualität sicherstellt.

Ein strukturierter Quartals-Review umfasst vier Prüfpunkte.

Volumenentwicklung: Hat sich das Dokumentvolumen pro Integration im vergangenen Quartal signifikant verändert? Welche Schnittstellen nähern sich dem vereinbarten Kontingent? Gibt es Wachstumstrends, die auf eine Overage-Situation in den nächsten Quartalen hindeuten? Diese Fragen sind der Steuerungsmoment im Bereich Nutzung.

Neue Integrationen: Wurden im vergangenen Quartal neue Schnittstellen eingeführt oder bestehende wesentlich verändert? Sind diese im Register erfasst und mit einer Lizenzgrundlage versehen?

Inaktive Integrationen: Welche Schnittstellen sind lizenziert, aber nicht mehr aktiv? Inaktive, lizenzierte Integrationen sind eine Möglichkeit, Kontingente zurückzugeben oder Vereinbarungen anzupassen. Wer das Register quartalsweise pflegt, erkennt diese Gelegenheiten systematisch.

Infrastrukturveränderungen: Wurden Middleware-Komponenten ausgetauscht, neue API-Typen eingeführt oder Systemgrenzen durch eine RISE-Migration verschoben? Der Steuerungsmoment im Bereich Infrastruktur fragt, ob diese Veränderungen den Digital-Access-Status einer Schnittstelle beeinflusst haben.

Wie das Integrationsregister bei Renewal und Audit eingesetzt wird

Das Integrationsregister ist nicht nur ein internes Steuerungsinstrument. Es entfaltet seinen Wert besonders in zwei externen Situationen.

Im SAP-Enhanced-Audit

Im Enhanced Audit fordert SAP eine vollständige Liste aller Drittsysteme mit SAP-Schnittstellen an. Wer ein aktuelles Integrationsregister führt, kann diese Anforderung strukturiert erfüllen. Wer kein Register hat, muss die Erhebung unter Zeitdruck durchführen, mit dem Risiko von Lücken.

Ein vollständiges Register zeigt SAP, dass der Integrationsbestand bekannt ist und aktiv gesteuert wird. Das verändert die Dynamik im Audit: Der Kunde kommt nicht als reaktive Partei, die Auskunft geben muss, sondern als Partei, die ihren Bestand kennt und bereit ist, ihn zu besprechen.

Für Schnittstellen, bei denen die Lizenzgrundlage dokumentiert ist, entfällt die Diskussion über Nachforderungen. Für Lücken, die bereits identifiziert und als DAAP-Amendment überführt wurden, besteht kein retroaktives Exposure mehr. Das Integrationsregister ist die Grundlage dafür, dass ein Enhanced Audit keine Überraschungen produziert.

In der Renewal-Verhandlung

SAP-Renewals sind der Steuerungsmoment im Bereich Kosten, bei dem das Dokumentvolumen und die Kontingentstruktur verhandelt werden. Wer das Volumen kennt, seine Wachstumsannahmen dokumentiert hat und den aktuellen Lizenzstatus aller Integrationen belegen kann, verhandelt auf einer belastbaren Grundlage.

Wer in eine Renewal-Verhandlung geht, ohne seinen Integrationsbestand vollständig zu kennen, riskiert, dass SAP auf Basis eigener Messungen Kontingenterhöhungen vorschlägt, die möglicherweise über dem tatsächlichen Bedarf liegen.

Das Integrationsregister ist kein Verhandlungsargument im rhetorischen Sinne. Es ist die faktische Grundlage, ohne die eine eigenständige Verhandlungsposition bei Digital Access nicht belastbar aufgebaut werden kann.

FAQ

Welches Format ist für ein Integrationsregister sinnvoll?

Das hängt von der Größe des Portfolios ab. Für kleinere Integrationslandschaften mit unter zwanzig Schnittstellen ist ein strukturiertes Tabellenformat ausreichend. Für größere Portfolios oder solche mit häufigen Änderungen empfiehlt sich ein dediziertes Governance-Werkzeug, das Versionshistorie, Statusänderungen und Volumentrends abbilden kann. Das Format ist nachrangig. Entscheidend ist, dass es konsistent gepflegt wird.

Wie detailliert muss das Volumen erfasst sein?

Die Genauigkeit sollte ausreichen, um Overage-Risiken zu erkennen und DAAP-Kontingente zu verhandeln. Exakte tagesaktuelle Werte sind nicht erforderlich. Monatsdurchschnitte auf Basis eines zwölf-Monats-Zeitraums sind eine belastbare Grundlage. Wichtiger als Präzision auf Einzelintegrations-Ebene ist die Vollständigkeit des Registers.

Wer ist verantwortlich für das Integrationsregister?

In der Praxis liegt die Verantwortung an der Schnittstelle zwischen IT-Architektur, Contract Management und Procurement. Die IT liefert die technischen Informationen zu Schnittstellen und Volumina. Contract Management bewertet den Lizenzstatus. Procurement stellt sicher, dass Lizenzentscheidungen in Vertragsveränderungen überführt werden. Ohne klare Eigentümerschaft wird das Register nicht gepflegt.

Kann FinOptory beim Aufbau und der Pflege des Integrationsregisters unterstützen?

Ja. Der Vertragscheck schließt die Erhebung und Bewertung des Integrationsbestands ein. Im Rahmen des Managed-Service-Modells (Wir steuern) wird das Integrationsregister als Teil des Steuerungsrhythmus laufend geführt und bei Renewal und Audit eingesetzt.

Das Integrationsregister ist kein aufwändiges Projekt. Es ist ein strukturierter Schritt, der die Steuerungsmomente bei Digital Access überhaupt erst operabel macht. Wer seinen Integrationsbestand kennt, steuert. Wer ihn nicht kennt, reagiert.

Wenn Sie wissen möchten, wo Ihr Portfolio heute steht, ist der Vertragscheck der geeignete Einstieg. In vier Wochen haben Sie einen belastbaren Überblick über Ihren Digital-Access-Status und klare Empfehlungen für den nächsten Schritt.