Les entreprises qui choisissent d’abandonner l’environnement ERP Central Component (ECC) au profit de S/4 HANA ou RISE with SAP doivent prendre conscience de la nouvelle méthode de licensing affectant les différents types de licences. Faute d’optimiser les rôles ECC, la migration vers S/4 HANA ou RISE with SAP se traduira par une hausse des coûts de 50 à 150 % en moyenne. Cet article a pour objectif de présenter en détail les informations permettant de quantifier le coût des licences dans les modèles S/4 HANA et RISE with SAP.
ECC — Comptage des licences en fonction des transactions (objets d’autorisation) effectuées par les collaborateurs.
S/4HANA et RISE with SAP — Comptage des licences en fonction du type de transactions (objets d’autorisation) auxquelles le collaborateur peut accéder (en fonction de ses rôles).
Le service SAP STAR (S/4HANA Trusted Authorization Review) implique l’allocation des licences dans S/4 sur la base de l’analyse des rôles à partir d’ECC.
Si vos rôles ECC ne sont pas optimisés, la migration vers S/4HANA ou RISE with SAP entraînera une augmentation moyenne des coûts de 50 à 150 %.
Certains outils disponibles sur le marché analysent les licences (notre outil SAM for SAP® Software, notamment) et optimisent automatiquement les rôles par rapport aux usages du collaborateur.
Ce document fournit les informations nécessaires au calcul du coût des licences dans les modèles S/4HANA ou RISE with SAP. Dans cet article nous précisons que les rôles actuels qui ne sont pas optimisés dans ECC auront un impact mesurable sur la valeur des licences dans RISE with SAP.
Ce document est divisé en deux parties :
Une première partie théorique, où nous présentons les différences entre les environnements ECC et S/4 dans le modèle RISE with SAP, en insistant sur les points d’attention qui caractérisent ces différences ; nous présentons un exemple de différences susceptibles d’avoir un impact sur la valeur de la migration de vos licences.
La deuxième partie pratique présente la méthodologie de travail associée à la simulation des licences et à l’optimisation des rôles dans l’optique d’économiser au maximum le coût des licences FUE (Équivalents en Utilisation Complète).
Dans un premier temps, nous allons revenir sur des informations élémentaires disponibles publiquement, mais sur lesquelles il est important d’insister ici :
Selon l’étude publiée par Gartner en octobre 2023, nous pouvons affirmer que les nouveaux environnements proposés par SAP reposeront dans une large mesure sur le modèle RISE with SAP. Quelles sont les conséquences pour les clients qui n’ont pas encore entamé le processus de migration ? Plusieurs éléments essentiels doivent être pris en compte :
Revenons un instant sur les principes de base de l’octroi de licences. Jusqu’à présent, les clients pouvaient savoir quel type de licence correspondait aux fonctions métier de leurs contrats avec SAP.
Ces clauses étaient rendues complexes par le fait qu’elles décrivaient explicitement les activités que l’utilisateur était censé effectuer. Les activités exécutées par les utilisateurs, quelles que soient leur licence attribuée, consistaient en une définition vague où l’on pouvait chercher en vain la moindre référence de ces fonctions à l’exécution de transactions précises.
Ce processus d’attribution de licences est donc très complexe. La solution d’optimisation des licences SAP dispose d’un ensemble de jeu de règles et d’une description des fonctions qui peuvent être exécutées par l’utilisateur dans le monde ECC.
Pour rappel, les principales licences ECC sont les suivantes (liste non exhaustive) :
Si vous avez acheté 200 licences Utilisateur Professionnel (Professional User) et n’en utilisez que 170, les 30 restantes peuvent être mises de côté, attribuées à des utilisateurs sans licence ou dont la licence est en excès au regard des quantités acquises. Attention, si vous n’attribuez pas à un utilisateur la licence appropriée (ou si vous ne le faites pas du tout), vous risquez de découvrir des coûts aussi élevés qu’inattendus lorsque vous procéderez à un audit de votre parc de licences.
De plus, il convient d’examiner la définition des différents types de licences. Dans un système ECC par exemple, une licence est attribuée à un Utilisateur Professionnel parce qu’il exécute des processus de vente dans le module SD (Sales & Distribution). Par définition contractuelle, toute activité opérationnelle de vente dans le système ECC nécessite une licence Utilisateur Professionnel.
Reprenons l’exemple précédent (Utilisateur Professionnel et Sales & Distribution) et notons les informations élémentaires concernant les nouvelles modalités de licensing.
Dans les systèmes S/4 HANA, les typologies de licences sont les suivantes :
Dans les systèmes RISE, les typologies de licences sont les suivantes :
SAP introduit le concept d’Équivalents en utilisation complète (FUE — Full Use Equivalent), qui représente la première différence majeure entre ECC et S/4HANA ou RISE. Alors que vous deviez jusqu’à présent acheter un nombre spécifique de licences SAP pour chaque utilisateur, vous achetez aujourd’hui des « tokens » (plusieurs FUE), que vous utilisez pour octroyer un type de licence spécifique en fonction d’un multiplicateur décrit ci-dessus.
Le calcul est relativement simple, mais mérite d’être suivi finement :
En théorie, les équivalents FUE permettent aux entreprises de gérer les différents types de licences avec efficacité et flexibilité sans devoir acquérir un nombre précis de chaque type. Notons qu’il existe encore des différences dans la définition même des types de licence. Revenons à l’exemple de l’utilisateur professionnel de SAP ECC qui effectue des activités commerciales.
Si vous effectuez un simple transfert de licence pour cet utilisateur sans tenir compte de la définition de S/4, vous risquez de surpayer les licences. En effet, les licences dans S/4 (que ce soit dans les modèles S/4 on-premise et RISE) définissent les activités commerciales pour des types de licence inférieurs à Utilisateur Professionnel (Professional User). Il en va de même pour les utilisations de base (Core use) :
En conclusion, il est nécessaire d’adapter soigneusement le type de licence en fonction des activités réelles. Compte tenu des différences qui subsistent, comment migrer ces licences ?
Outre la différence entre les définitions évoquées ci-dessus, un autre aspect important entre en ligne de compte : comprendre ce que le client doit faire avant de négocier la migration avec SAP. Examinons la définition des équivalents FUE :
L’expression « Équivalents en utilisation complète » (FUE — Full Usage Equivalent) désigne le nombre de personnes autorisées à accéder aux fonctions associées à la solution. »
Que signifie « FUE » dans le contexte de la migration ? Un changement total des habitudes liées à la gestion des licences.
Passons maintenant rapidement aux résultats moyens des audits que nous avons réalisés à propos des autorisations. Ces résultats montrent de manière générale que les utilisateurs utilisent 10 % des autorisations qui leur sont attribuées. Les 90 % restants (en moyenne, indépendamment du secteur d’activité et de la géolocalisation du client) sont des autorisations redondantes qui ne devraient pas être attribuées à ces utilisateurs, ce qui est pourtant le cas. Les conséquences en termes de migration ? Des coûts considérables !
Nous savons déjà que la migration directe (1 pour 1) des types d’utilisateurs existants est impossible et que cette problématique doit être abordée selon une méthodologie de travail appropriée. Le service SAP STAR (S/4HANA Trusted Authorization Review), qui aide les clients d’ECC à migrer vers S/4, représente une bonne solution. Il permet en effet de « mapper » les licences entre ECC et S/4 sur la base d’une adaptation appropriée aux différences contextuelles des différents utilisateurs.
Le terme « mapper » est important ici, car il ne s’agit pas d’optimisation, mais seulement de représentation de la situation avant et après, en fonction du rôle des utilisateurs dans ECC, et non en fonction de ce qu’ils utilisent réellement
Et c’est ici que nous entrons dans le vif du sujet :
Dans ECC, les licences Utilisateurs Nommés (Named User) diffèrent grandement de RISE with SAP. Les principales différences sont les suivantes :
Dans les entreprises qui n’ont pas encore abordé le projet d’optimiser les rôles de manière efficace, nous observons une tendance à exagérer de façon significative le contenu des rôles attribués aux utilisateurs. En moyenne, seulement 10 % des autorisations attribuées sont effectivement utilisées.
Comment expliquer une telle situation ? Voici quelques raisons :
Comme nous l’avons vu, le contrat SAP contient des définitions de différents types de licences qui décrivent les activités que les utilisateurs peuvent effectuer (ou être autorisés à effectuer). Cette description ne comprend pas de définitions spécifiques des transactions ou des objets d’autorisation. D’où la question : comment faire correspondre ces définitions ?
Leader sur le marché de la gestion des actifs logiciels (SAM), l’outil USU SAM for SAP se concentre sur les spécificités des licences SAP et permet d’optimiser intégralement les licences dans SAP, qu’il s’agisse d’ECC ou de S/4 (on-premise ou dans le Cloud). Cet article se concentre sur le modèle RISE with SAP et aux autorisations attribuées à des utilisateurs spécifiques.
L’outil USU SAM for SAP dispose de bibliothèques de jeux de règles concernant les transactions et les objets d’autorisation attribués à chaque type de licence. Si vous effectuez des transactions personnalisées (pas de SAP sans code Z *!), nous ajoutons aux définitions les paramètres des codes T ou des objets d’autorisation qui correspondent au type de licence.
La licence correspondant à l’exemple d’utilisation de base (Core Use - 1/5 FUE) est construite comme suit :
À la ligne 2 ci-dessus apparaît la définition des transactions auxquelles un utilisateur donné peut accéder. Une liste détaillée s’ouvre, un contenu décrivant les transactions considérées (au moins, optionnel, exclu) :
Il est également possible de lire les objets d’autorisation et d’ajouter, pour chaque compte et chaque rôle, la transcription de la licence requise.
En intégrant et classifiant les transactions et des objets d’autorisation personnalisés, nous simulons les changements dans les types de licences pour le scénario de migration vers S/4HANA ou RISE. Nous assurons également de la licence adéquate à chaque compte, selon ses autorisations, une fois le passage en licensing S/4 effectué. Des rapports vous permettront d’identifier rapidement quels utilisateurs ont un usage inférieur à leurs autorisations, dont les rôles pourraient être amenés à évoluer afin de réaliser des économies de licences.
Le logiciel fonctionne en passant chaque compte utilisateur dans le jeu de règles de manière ordonnée, afin de répondre aux exigences d’un type de licence donné. Une fois que les critères correspondent à 100 %, l’analyse s’arrête, la licence simulée est allouée à l’utilisateur et l’analyse passe à un autre compte utilisateur. L’algorithme (de haut niveau) utilisé est le suivant :
Cet algorithme permet d’optimiser les licences actuelles sur les systèmes SAP et de simuler la migration des types de licences d’un environnement / licensing à l’autre.
Comme nous l’avons vu :
Il est par conséquent important de définir les rôles avant de commencer à évoquer avec SAP la valeur des FUE que vous voulez acquérir.
Les projets de réorganisation des rôles sont souvent associés à des discussions sans fin au sein de l’entreprise à propos de la légitimité de certains accès / rôles. Il est toujours possible que l’on veuille utiliser une transaction pour une opération donnée. « Et si j’ai besoin de telle autorisation à un moment donné ? Ne serait-il pas préférable de m’accorder un accès complet dès aujourd’hui ? »
Chaque projet d’autorisation nécessite une identification appropriée des activités correspondantes, telles qu’une liste de processus métier pouvant être mis en correspondance avec des transactions et des objets d’autorisation. Que se passe-t-il si cette liste de processus n’existe pas dans l’entreprise ou doit être mise à jour ?
L’expertise et les bonnes pratiques, couplées aux bons outils, permettent de bâtir les rôles sur mesure et de façon efficace, ce qui permet de répondre aux besoins propres à l’entreprise sans générer d’accès excessifs.
Pathlock est le leader sur le marché des solutions dédiées à la gestion des autorisations et de la sécurité dans SAP et d’autres environnements.
Cet outil automatise tout ce qui est possible dans ce processus fastidieux — s’il est exécuté manuellement — de création de rôles adaptés à l’entreprise. En bref, Pathlock pilote de A à Z le concept d’autorisation (gestion de la documentation, workflows d’acceptation, convention d’appellation, postes et responsabilités).
Objectif : Créer des rôles adaptés aux besoins réels de l’entreprise.
La procédure est la suivante :
Étape 1 — Structure organisationnelle
Ici, nous allons créer la cartographie de chaque élément de la structure organisationnelle de façon logique, depuis le département et la division jusqu’au niveau de l’utilisateur. Si l’on considère le niveau de l’organisation, toute différence d’accès se retrouve également au niveau des objets d’autorisation.
Étape 2 — Analyse de l'activité des utilisateurs
Nous considérons les positions de l’étape précédente sous forme de « boîte » où nous plaçons les utilisateurs actuels. La solution de gestion des rôles de Pathlock analyse ST03 (et les informations de SU24, entre autres).
Étape 3 — Proposition automatique de rôles-maîtres pour un poste
Après analyse, le système propose le contenu des rôles principaux pour les postes, les détails distinctifs reflétant les différents paramètres des objets d’autorisation. En fonction du niveau d’organisation où travaille l’employé, ou de ce dont il est responsable, la proposition de rôle repose sur les données historiques de l’étape 2.
Étape 4 — Workflows d’acceptation avec analyse de la séparation des tâches (SOD)
Les responsables du domaine d’activité acceptent le contenu des rôles. Les informations relatives à l’acceptation peuvent également inclure l’analyse de la séparation des tâches.
Étape 5 — Tests
C’est le point critique auquel l’utilisateur teste de nouvelles autorisations. Cette étape est transparente pour les utilisateurs finaux grâce à l’application de l’algorithme suivant : l’utilisateur agit et le système vérifie si l’action est possible de la part des nouveaux rôles ; si oui, il l’exécute. Dans le cas contraire, l’action était-elle disponible dans les anciens rôles ? Si non, il ne l’exécute pas. Si oui, il peut l’exécuter, et l’équipe projet obtient immédiatement des informations sur les différences entre les anciens et les nouveaux rôles, et peut prendre une décision en connaissance de cause.
Étape 6 — Déploiement et documentation
Lorsque les nouveaux rôles sont mis en production, l’utilisateur peut rapidement revenir aux anciens droits (dans le cadre d’un accès d’urgence) pendant une période déterminée. Une documentation complète est créée.
Étape 7 — Cycle de vie des rôles
Lorsque le contenu des rôles (en termes de codes et d’objets d’autorisation) change, l’équipe chargée des autorisations modifie rapidement les rôles maîtres. Elle applique les modifications en fonction de la structure organisationnelle. La modification des rôles en vue d’ajouter des unités organisationnelles ne prend que quelques minutes.
Récapitulons le projet : certains rôles répondent à nos besoins, d’autres sont tout simplement inutilisés mais non supprimés. Notre solution de gestion des licences SAP permet de suivre et d’optimiser les licences allouées, au travers de nos jeux de règles contenant des types de licences ventilés en fonction des transactions utilisées et des objets d’autorisation associés aux rôles.
D’après les projets menés par l’équipe d’USU, si les rôles ne sont pas optimisés avant d’être mappés à l’aide du service SAP STAR, l’augmentation de la valeur des licences FUE peut être comprise entre 50 % et 150 %. Des dépenses importantes peuvent être évitées, comme nous l’avons décrit précédemment.
La migration d’ECC vers S/4 HANA ou RISE with SAP est un processus qui doit également prendre en compte le mappage des types de licences pour les utilisateurs cibles. Les changements apportés aux définitions et à la facturation ne sont pas négligeables (avec le modèle S/4 HANA ou RISE, ce n’est pas ce que l’utilisateur a fait qui est facturé, mais ce qu’il peut faire, c’est-à-dire ce qu’il est autorisé à faire au travers des rôles qu’il détient).
En résumé, l’optimisation des rôles et la simulation des niveaux de licence permettront de réduire de façon significative le coût de S/4 HANA ou RISE au regard des souscriptions aux licences cibles de SAP.
L'auteur est responsable du développement de la sécurité chez LUKARDI, un partenaire exclusif d'USU en Pologne.
Plus d'informations :
En savoir plus sur USU Software Asset Management et planifier une consultation gratuite.