Le nouveau modèle de licence SAP peut coûter cher !

Graves conséquences des autorisations non vérifiées lors de la migration vers S/4

A l'avenir, tout ce qui n'est pas une approche "greenfield" n'aura plus de sens lors du changement. Les conséquences profondes du passage d'un système de licences basé sur la consommation à un système basé sur les droits d'accès sont fatalement sous-estimées par la plupart des clients SAP existants. Dans le cadre d'une conférence en ligne sur les technologies de l'information fin janvier, une enquête menée auprès des entreprises sur la vérification des rôles d'autorisation SAP a confirmé cette impression dans une large mesure : 85% des entreprises ne vérifient qu'irrégulièrement, voire pas du tout, ou ne veulent ou ne peuvent pas donner d'informations à ce sujet - ce qui, par expérience, repose sur ce dernier point. Trop de personnes ne sont donc pas conscientes des conséquences du nouveau modèle de licence pour la migration, et cela devrait changer au plus vite.

Au cours des 25 dernières années, les projets d'autorisation SAP se présentaient classiquement de la manière suivante : La plupart du temps sous la pression du temps, un concept d'autorisation a été défini, qui fonctionne d'une manière ou d'une autre de manière conforme, et les rôles ont été construits de manière à ce que les utilisateurs puissent utiliser ce dont ils ont besoin, voir pages 12 et 20 de ce numéro.Il est également clair que la question de la licence lors de l'attribution technique des autorisations a été négligée dans la plupart des entreprises jusqu'à présent, ce qui a souvent conduit à une prolifération des autorisations. Certains utilisateurs ont jusqu'à 500 autorisations, dont 25% seulement sont nécessaires.

Lorsqu'on demande aux clients quel modèle de licence et quel concept d'autorisation ils utilisent pour préparer le passage à S/4, ils ne savent généralement pas ce que signifie en fin de compte le choix entre une conversion de produit et une conversion de contrat. Jusqu'à présent, personne n'a sérieusement envisagé qu'il puisse y avoir différentes technologies d'accès avec des conséquences monétaires. Mais c'est exactement ce qui se passe aujourd'hui : de nouvelles techniques dans les projets S/4 supposent des scénarios correspondants, le modèle de licence SAP est devenu de plus en plus complexe et il est en train de changer fondamentalement !

Conversion des produits 

Une conversion de produit signifie avant tout que les anciens contrats restent en vigueur et semble avoir le moins d'impact. Contrairement à la conversion de contrat, il est ici possible de conserver les contrats existants avec SAP et donc aussi leurs conditions de licence. Les nouveaux produits de S/4 sont alors ajoutés, ce qui signifie que celui qui veut utiliser un nouveau moteur qui n'existe que sous S/4, l'achète et acquiert une licence en conséquence. Mais il reste plus ou moins dans le domaine ECC avec ses licences d'utilisation et continue à mesurer selon l'utilisation et non selon l'autorisation. Il n'y a donc pas de conversion à partir de licences existantes comme dans le cas de la conversion de contrat. Dans un premier temps, un contrat sur l'achat concret est simplement ajouté à l'existant et la licence continue à être basée sur l'utilisation effective.

Conversion de contrat

Une conversion de contrat est en fait le remplacement des contrats existants. On prend les contrats existants, la valeur de la licence et du logiciel qui se trouve dans ces licences et contrats, et on les évalue. Un nouveau contrat est alors établi pour S/4 et il s'applique désormais avec toutes ses conséquences. Ce qui est important ici : Dans le domaine S/4, les licences sont désormais basées sur des autorisations théoriques et non plus sur l'utilisation effective par l'utilisateur. Pour ce faire, SAP enregistre sur une période standard de trois mois les autorisations auxquelles un utilisateur pourrait avoir accès dans le système - pour lesquelles une licence est alors due sur la seule base de l'utilisation possible.

Ce n'est alors plus la transaction effective qui est pertinente, mais simplement tout ce que l'on aurait pu faire théoriquement avec ses autorisations. Et cela peut devenir extrêmement problématique avec les concepts d'autorisation trop généreux décrits. En outre, les outils qui fournissaient jusqu'à présent des résultats très fiables pour l'optimisation des licences SAP sont devenus obsolètes avec le nouveau modèle de licence.

La tromperie

La comparaison des deux approches pourrait amener à la conclusion confortable que si l'on choisit la conversion de produit, tout reste comme avant en ce qui concerne le thème des autorisations, et que seule la conversion de contrat permet d'introduire la problématique décrite. Mais c'est un peu court à bien des égards. Déjà parce qu'il y a de nouvelles applications dans les nouveaux modèles, tandis que d'autres disparaissent, et si l'on construit ensuite des rôles, la moindre modification peut avoir pour conséquence que ceux-ci ne sont plus compatibles avec les licences, ce qui a les conséquences correspondantes.

En outre, l'expérience montre que lors d'une conversion de produit, les autorisations nécessaires pour les nouveaux produits achetés sont généralement simplement ajoutées aux anciens rôles. En ce qui concerne le rôle, celui-ci est élargi au lieu d'être réduit à une mesure saine. Ainsi, il n'y a guère de réflexion sur les rôles SAP existants, avec pour conséquence que les autorisations qui ne sont plus nécessaires continuent à ne pas être supprimées. Indépendamment de la problématique de la sécurité, qui reste urgente, la règle est désormais la suivante : les autorisations qui débordent coûtent très, très cher à moyen terme. 

L'expérience montre qu'en moyenne, un utilisateur n'a besoin que de 25% des autorisations qui lui sont attribuées, ce qui ne pose pas de problème à court terme, du moins financièrement, tant que la licence peut être accordée sur la base de la consommation. Mais à moyen terme, il faudra accorder des licences en fonction des autorisations, c'est inévitable. L'expérience des dernières années dans le domaine de l'ECC a montré que ces changements vont définitivement avoir lieu, même si les cris d'orfraie de la DSAG e. V. et d'autres comités sont grands. À partir de ce moment-là, ce n'est plus le did-do d'un utilisateur qui décide sans exception, mais exclusivement le could-do. Et ensuite, ces 75% qui n'ont jamais été utilisés seront pris en compte.

Que faut-il faire ?

Dans un premier temps, SAP propose désormais lui-même un outil permettant de déterminer en un clic si un rôle coûte cher. Après un enregistrement sans engagement, un tableau Excel montre quel objet d'autorisation est attribué à quel type de licence et dans quelle mesure. Et on peut utiliser un test qui donne exactement le prix qu'une licence S/4 coûterait actuellement. Le résultat devrait inciter la plupart des entreprises à s'attaquer immédiatement au problème. Mais alors, comment veiller à la pérennité des autorisations et des licences dans le projet de migration des rôles ? La réponse est claire : tout ce qui n'est pas une approche "greenfield" n'a plus de sens pour les autorisations S/4 ! Il ne sert à rien de dire que nous faisons le ménage, car cela n'est pas aussi approfondi qu'une nouvelle création.

L'approche : Green Field avec le soutien d'outils

L'approche correcte d'une bonne pratique consiste à déterminer ce qui a été réellement utilisé par le biais d'une analyse de la consommation de tous les utilisateurs dans le système actuel, ainsi qu'à effectuer une analyse des rôles suite à l'analyse de la consommation. Après avoir clarifié la manière dont les rôles actuels reflètent la consommation réelle, les licences sont réattribuées sur la base de l'analyse de la consommation. Pour ce faire, des outils tels que Pathlock sont actuellement indispensables pour le contrôle continu des résultats. Cela vaut aussi bien pour l'analyse de ce qui est utilisé que pour les résultats de la recréation des rôles et des autorisations.