Wenn Sie von ECC zu RISE with SAP migrieren, sollten Sie sich der Unterschiede zwischen den Lizenztypen bewusst sein. Wenn Ihre ECC-Rollen nicht optimal angelegt sind, wird die Umstellung auf RISE with SAP durchschnittlich 50-150% höhere Kosten verursachen. Dieser Artikel soll alle notwendigen Informationen aufzeigen, die bei der Entscheidung über die Höhe der Lizenzkosten im RISE-mit-SAP-Modell helfen.
Dieser Artikel zielt darauf ab, alle notwendigen Informationen zu veranschaulichen, die bei der Entscheidung über die Höhe der Lizenzkosten im Modell RISE with SAP helfen. Darin weise ich darauf hin, dass:
die derzeit nicht optimalen Rollen in ECC sich messbar auf die Lizenzwerte in RISE mit SAP auswirken werden.
Ich habe den Artikel in die folgenden zwei Abschnitte unterteilt:
Im ersten Teil - Theoretische Grundlagen - beschreibe ich die Unterschiede zwischen ECC- und S/4-Umgebungen im RISE with SAP-Modell. Darin mache ich auf die möglichen Fallstricke dieser Unterschiede aufmerksam und zeige ein Beispiel für solche Unterschiede, die sich auf die Lizenzbewertung auswirken können.
Zweiter Teil - Praxis - In diesem Teil wird die Arbeitsmethodik im Zusammenhang mit der Lizenzsimulation und der Rollenoptimierung, noch in der ECC-Umgebung, demonstriert, um die Kosten für FUE-Lizenzen zu minimieren.
Zunächst einmal einige grundlegende Informationen, die zwar hier und da wiedergegeben werden, aber für diesen Artikel lohnt es sich, einige davon herauszustellen:
In Anlehnung an den Bericht von Gartner (Oktober 2023) können wir feststellen, dass die von SAP angebotenen neuen Umgebungen überwiegend auf dem Modell RISE with SAP basieren. Was bedeutet dies für bestehende Kunden, die noch migrieren müssen? Es gibt mehrere wichtige Elemente, auf die man achten sollte:
Wenn man die klassische On-Premises-Version von S/4 mit dem RISE with SAP-Modell vergleicht, muss man auch die Änderung bei der Lizenzierung von benannten Benutzern erwähnen. Der klassische Ansatz, bei dem wir einen Pool von Benutzern hatten, für die Lizenzen erworben wurden, wird durch Tokenisierung ersetzt. SAP führt das Konzept des Full Use Equivalent (FUE) ein und verflacht die Arten von Genehmigungen. Wir werden gleich noch ausführlicher über FUE sprechen.
Nochmals eine kleine Wiederholung - wir sind zurück bei den Grundlagen der Lizenzierungsprinzipien. Bisher konnten Kunden in ihren Verträgen mit SAP nachlesen, welche Arten von Lizenzen der Nutzung welcher Geschäftsfunktionen entsprachen.
Diese Vertragsbedingungen waren insofern kompliziert, als dass sie die Tätigkeiten, die der Benutzer ausführen sollte, offen beschrieben. Die vom Professional User ausgeführten Tätigkeiten bestanden aus mehreren Aufzählungspunkten, bei denen man vergeblich nach einem Bezug dieser Funktionen zur Ausführung bestimmter Transaktionen suchen würde.
Einerseits ist dies ein komplizierter Prozess. Andererseits wäre es, wenn es mit Transaktionen verbunden wäre, ein einfacher Workaround für die Lizenzen (und damit eine Kostenoptimierung) für kreative Kunden, die Funktionen auf Z* umzuschreiben, aber lassen wir dieses Thema. Wir haben eine Reihe von Lizenzen und eine Beschreibung der Funktionen, die von dem Benutzer, der die Funktion ausführt, ausgeführt werden können.
Noch einmal zur Erinnerung: Die Lizenzen für ECCs umfassen Folgendes:
Wenn Sie 200 Professional User Lizenzen gekauft haben und nur 170 davon nutzen, können Sie die restlichen 30 auslagern oder an nicht lizenzierte Benutzer verteilen. Seien Sie außerdem vorsichtig, wenn Sie einem Nutzer nicht die richtige Lizenz zuweisen (oder es gar nicht tun), denn wenn Sie die Lizenzen prüfen, könnten Sie feststellen, dass damit erhebliche Kosten verbunden sind.
Betrachten Sie darüber hinaus die Definitionen der Lizenztypen. Nehmen wir ein Beispiel: In einem ECC-System wird einem Professional User eine Lizenz zugewiesen, weil er Vertriebsprozesse im SD-Modul durchführt. Laut Vertragsdefinition erfordert jede operative Tätigkeit im ECC für den Vertrieb eine Professional User-Lizenz.
Erinnern wir uns an das obige Beispiel (für Professional und SD). Wir werden gleich darauf zurückkommen. Halten wir nun die grundlegenden Informationen über die neuen Anforderungen fest. In den neuen Systemen wird zwischen den folgenden Lizenztypen unterschieden:
SAP führt das Konzept des FUE, des Full Use Equivalent, ein. Dies ist der erste große Unterschied zwischen ECC und RISE. Bislang kaufte man eine bestimmte Anzahl von Benutzern. Heute kaufen Sie sozusagen Token (mehrere FUEs), mit denen Sie bestimmte Arten von Lizenzen vergeben (entsprechend einem Multiplikator, den ich mit der Zahl "Faktor" beschrieben habe).
Das funktioniert zum Beispiel nach einer einfachen Rechnung:
Theoretisch ermöglicht FUE den Kunden, effizient und flexibel durch die Anzahl der Lizenztypen zu navigieren, ohne eine bestimmte Anzahl von jedem Typ zu kaufen. Die Unterschiede bei den Lizenztypen sind jedoch nicht alles. Auch bei den Definitionen der Lizenztypen selbst gibt es Unterschiede. Kehren wir also zum Beispiel des SAP ECC und des Professional User zurück, der Verkaufsaktivitäten durchgeführt hat.
Wenn Sie eine einfache Lizenzübertragung für diesen Benutzer unabhängig von der S/4-Definition durchführen, zahlen Sie möglicherweise zu viel für Lizenzen. Warum? Weil Lizenzen in S/4 (sowohl im S/4 on-prem- als auch im RISE-Modell) Vertriebsaktivitäten für Lizenztypen unterhalb von Professional definieren. Und so auch für Core Use:
Was bedeutet das? Nichts weniger als die Notwendigkeit, die Lizenztypen sorgfältig auf die tatsächlichen Aktivitäten zu übertragen. Es gibt immer noch einige Unterschiede, also wie migrieren Sie Lizenzen?
Zusätzlich zu den oben erwähnten Unterschieden in den Definitionsbereichen ist ein weiterer wichtiger Aspekt der de facto Schlüssel zum Verständnis dessen, was der Kunde VOR dem Migrationsgespräch mit SAP tun sollte. Schauen wir uns die FUE-Definition an:
"Full Usage Equivalent (FUE) ist die Zahl, die der Anzahl der Personen entspricht, die zum Zugriff auf bestimmte Lösungsfunktionen berechtigt sind."
Ich habe das Schlüsselwort zur Verdeutlichung fett markiert. Was bedeutet es im Zusammenhang mit der Migration? Eine vollständige Änderung der bestehenden Lizenzierungsgewohnheiten.
Ich möchte an dieser Stelle auf unsere durchschnittlichen Ergebnisse der von uns durchgeführten Berechtigungsprüfungen hinweisen. Die Ergebnisse waren in der Regel, dass die Benutzer 10 % der zugewiesenen Berechtigungen nutzen. Die restlichen 90 % (im Durchschnitt, unabhängig von der Branche und dem Standort des Kunden) sind überflüssige Berechtigungen, die den Benutzern nicht zugewiesen werden sollten. Und doch sind sie es. Was könnte dies für die Migration bedeuten? Sie ahnen es: beträchtliche Kosten.
Wir wissen bereits, dass eine 1:1-Migration bestehender Nutzertypen nicht möglich ist und mit einer geeigneten Arbeitsmethodik angegangen werden muss. Der SAP STAR-Service, der ECC-Kunden bei der Migration zu S/4 unterstützt, kann dabei helfen. Eines seiner Ergebnisse ist die Fähigkeit, Lizenzen von ECC auf S/4 abzubilden/zu mappen, und zwar auf der Grundlage einer angemessenen Anpassung an die kontextuellen Unterschiede der einzelnen Benutzer.
Das Wort "mappen" ist hier wichtig, denn es geht nicht um Optimierung, sondern nur um die Darstellung des Vorher-Nachher-Zustands. Dies alles basiert auf den Rollen der Nutzer im ECC.
Und hier kommen wir zum Kern der Sache:
Die ECC-Lizenzierungswelt der benannten Benutzertypen unterscheidet sich erheblich von der neuen Welt in RISE with SAP. Die wichtigsten Unterschiede sind:
Wir beobachten in Organisationen, die das Projekt der Rollenoptimierung noch nicht effektiv angegangen sind, eine Tendenz, den Inhalt der den Benutzern zugewiesenen Rollen stark zu übertreiben. Im Durchschnitt werden nur 10 % der zugewiesenen Berechtigungen von den Benutzern genutzt.
Warum ist das so? Es gibt viele Faktoren. Lassen Sie uns ein paar davon erörtern:
Wie ich bereits erwähnt habe, enthält der SAP-Vertrag beschreibende Definitionen von Lizenztypen. Diese beschreiben, welche Aktivitäten Benutzer durchführen können (oder wozu sie berechtigt sind). Diese Form der Beschreibung enthält keine spezifischen Definitionen von Transaktionen oder Berechtigungsobjekten. Wie können wir also diese Definitionen abbilden?
Das Tool des SAM-Marktführers konzentriert sich auf die Spezifika von SAP-Lizenzen. Es ermöglicht eine umfassende Lizenzoptimierung in SAP, unabhängig davon, ob es sich um ECC oder S/4 (on-prem oder Cloud) handelt. Dieser Blog konzentriert sich auf das RISE with SAP-Modell, das die Berechtigungen für bestimmte Benutzer betrachtet.
USU’s SAP-Lizenzmanagement-Software verfügt über lizenztypspezifische Libraries zu den Transaktionen und Berechtigungsobjekten, die einer bestimmten Lizenz zugeordnet sind. Wenn Sie benutzerdefinierte Transaktionen haben (es gibt kein SAP ohne Z*), fügen wir den Definitionen natürlich die Parameter der T-Codes oder Berechtigungsobjekte hinzu, die für den Lizenztyp geeignet sind.
Der Aufbau der spezifischen Lizenzdefinition für das Beispiel der Core Use (1/5 FUE) ist wie folgt:
In Zeile 2 oben erscheint die Definition der Transaktionen, auf die ein bestimmter Benutzer Zugriff hat. Es öffnet sich eine detaillierte Liste mit dem Inhalt, der die erforderlichen Zugänge beschreibt:
Zusätzliche Informationen zu den Lizenzstufen umfassen auch Daten zu den Berechtigungsobjekten.
Nach der Aktualisierung mit benutzerdefinierten Transaktionen und Berechtigungsobjekten simulieren wir Änderungen der Lizenztypen für das Migrationsszenario.
Die USU-Software filtert den Benutzer so, dass er die Anforderungen eines bestimmten Lizenztyps erfüllt. Der (übergeordnete) Algorithmus lautet wie folgt:
Mit diesem Algorithmus können wir aktuelle Lizenzen auf SAP-Systemen optimieren und die Migration von Lizenztypen von einer Umgebung in eine andere simulieren.
Diese Punkte sind uns bereits bekannt:
Es ist also wichtig, die Rollen zu klären, bevor wir mit SAP über die beabsichtigten Werte der FUEs sprechen, die wir erwerben wollen.
Projekte zur Umstrukturierung von Rollen sind oft mit endlosen Diskussionen über die Legitimität bestimmter Rollenzugriffe verbunden. Es kann immer eine Transaktion geben, die wir für etwas verwenden wollen. Was ist, wenn ich meine Arbeit zu einem entscheidenden Zeitpunkt erledige? Ist es nicht besser, heute einen umfassenderen Zugang zu gewähren?
Jedes Autorisierungsprojekt erfordert eine angemessene Identifizierung der notwendigen Aktivitäten, wie z.B. eine Liste von Geschäftsprozessen, die mit Transaktionen und Autorisierungsobjekten abgebildet werden können. Was ist, wenn eine solche Prozessliste in der Organisation nicht vorhanden ist oder aktualisiert werden muss?
Die in die Tools integrierten bewährten Verfahren helfen dabei, die erforderlichen Rollen effizient und maßgeschneidert zu erstellen. Auf diese Weise können Job-Rollen spezifische Geschäftsanforderungen erfüllen, ohne übermäßige Zugriffe zu generieren.
Pathlock ist Marktführer bei dedizierten Lösungen für SAP-Berechtigungsmanagement und Sicherheit (und nicht nur SAP, aber in diesem Artikel konzentrieren wir uns auf den SAP-Bereich).
Das Tool automatisiert den mühsamen, meist manuell ausgeführten Prozess der Erstellung von geschäftsadäquaten Rollen vollständig. Kurz gesagt, das Tool steuert das gesamte Berechtigungskonzept (Pflege der Dokumentation, Rollenvergabe-Workflow, Naming Convention, Positionen und Verantwortlichkeiten).
Das Verfahren ist wie folgt:
Schritt 1 - Organisatorische Struktur
Hier wird jedes Element der Organisationsstruktur logisch von der Abteilungs- und Bereichsebene bis zur Stellenebene abgebildet. Unter Berücksichtigung der Organisationsebene liegen die Unterschiede im Zugriff auch auf der Ebene der Berechtigungsobjekte.
Schritt 2 - Analyse der Nutzeraktivitäten
Wir behandeln die Positionen aus dem vorherigen Schritt als eine Art Box. In diese legen wir die aktuellen Benutzer. Das Pathlock Role Management analysiert ST03 (und Informationen aus SU24, unter anderem).
Schritt 3 - Automatischer Vorschlag von Stammrollen für eine Planstelle
Nach der Analyse schlägt das System den Inhalt der führenden Rollen für die Planstellen vor, wobei sich die Details aus den verschiedenen Parametern der Berechtigungsobjekte ergeben. Je nachdem, in welcher Organisationsebene der Mitarbeiter arbeitet oder wofür er zuständig ist. Der Rollenvorschlag basiert auf den historischen Daten aus Schritt 2.
Schritt 4 - Abnahmeworkflow mit SoD-Analyse
Die Verantwortlichen des Geschäftsbereichs akzeptieren den Inhalt der Rollen. Die Informationen zur Abnahme können auch eine SoD-Analyse beinhalten.
Schritt 5 - Tests
Der kritische Punkt, an dem die Nutzer neue Berechtigungen testen. Diese Phase ist für die Endnutzer transparent, da der folgende Algorithmus angewandt wird: Der Benutzer handelt, und das System prüft, ob die Aktion in den neuen Rollen möglich ist, und wenn ja, führt es sie aus. Wenn nicht, war sie in den alten Rollen verfügbar? Wenn nein - wird sie nicht ausgeführt. Wenn ja - kann er sie ausführen, und das Projektteam erhält sofort Informationen über die Unterschiede zwischen alter und neuer Rolle und kann eine fundierte Entscheidung treffen.
Schritt 6 - Produktivsetzung und Dokumentation
Nach der endgültigen Übertragung der neuen Rollen in die Produktion kann der Benutzer für einen bestimmten Zeitraum schnell zu den alten Rechten zurückkehren (unter Notfallzugriff). Es wird eine vollständige Dokumentation erstellt.
Schritt 7 - der Lebenszyklus der Rolle
Wenn sich der Inhalt von Rollen (in Form von Codes und Berechtigungsobjekten) ändert, ändert das Berechtigungsteam schnell die Stammrollen. Es propagiert die Änderungen gemäß dem Organisationsstrukturschlüssel. Das Ändern von Rollen für zusätzliche Organisationseinheiten dauert nur wenige Minuten.
Fassen wir das Projekt zusammen: Wir haben Rollen, die auf unsere Bedürfnisse zugeschnitten sind, immer noch in der ECC-Umgebung. Wir sind in der Lage, die Rollen mit den USU-Tools zu simulieren, da diese mit Libraries geliefert werden, die die Lizenztypen aufgeschlüsselt nach den in den Rollen enthaltenen Transaktionen und Berechtigungsobjekten enthalten.
Aus den Projekten, die das USU-Team durchführte, geht hervor, dass der Aufwand für FUE-Lizenzen um 50 bis 150 % steigen kann, wenn die Rollen vor dem Mapping mit dem SAP STAR-Service nicht optimiert werden. Wie ich oben beschrieben habe, können beträchtliche Geldbeträge vermieden werden.
Die Migration von ECC zu RISE with SAP ist ein Prozess, bei dem auch die Zuordnung von Lizenztypen für die Zielbenutzer berücksichtigt werden muss. Es gibt eine ganze Reihe von Änderungen bei den Definitionen und der Abrechnung (schon allein aus der Perspektive, dass im RISE-Modell nicht in Rechnung gestellt wird, was der Benutzer getan hat, sondern was er tun könnte, d. h. wozu er durch die ihm zugewiesenen Rollen berechtigt ist.
Durch die Berücksichtigung von zwei Themen - Rollenoptimierung und Simulation von Lizenzstufen - werden die zu erwartenden Kosten von RISE mit den von SAP angestrebten Lizenzabonnements erheblich reduziert.
Der Autor ist Head of Security Development bei LUKARDI, einem exklusivem USU-Partner in Polen.
Weitere Informationen:
Learn more about USU Software Asset Management and schedule a free consultation.