Cet article vous apprendra

– Pourquoi SAP s’éloigne du modèle FUE et introduit le modèle PUPM,

– quels sont les nouveaux types d’utilisateurs et en quoi ils diffèrent les uns des autres,

– Comment fonctionne la règle du « type le plus élevé gagne » et pourquoi elle peut entraîner une forte augmentation des coûts,

– les risques liés à l’attribution des rôles et des répertoires d’entreprises,

– Pourquoi les matrices de cartographie sont difficiles dans la pratique et comment les lire,

– ce que signifie la période de transition et quand il sera réellement possible de migrer,

– les outils et activités qui permettent de contrôler les coûts des licences dans le nouveau modèle.

 

Nouveau modèle de licence – la nécessité

Ces dernières années, SAP Cloud ERP avait un modèle FUE (Full Use Equivalent). Les clients devaient convertir les utilisateurs en « équivalents de compte » et ensuite seulement calculer les coûts.

Le problème, cependant, n’était pas seulement d’ordre mathématique, mais surtout de déterminer à quelle catégorie attribuer chaque utilisateur. Une entreprise qui vient d’implémenter SAP et qui n’a pas encore une bonne compréhension du modèle de licence part souvent d’une hypothèse simple : « nous avons 100 personnes qui veulent travailler dans le système » : « Nous avons 100 personnes qui veulent travailler dans le système ». Au lieu de leur donner des autorisations et d’observer l’utilisation réelle, elle devait décider dès le stade de la planification ce que chacune de ces personnes ferait et quel type d’utilisateur lui assigner. Cette tâche était difficile et sujette à un risque d’erreur élevé.

Cette entreprise calculait en fait qu’elle aurait 50 utilisateurs en libre-service, 20 utilisateurs opérationnels, 10 utilisateurs financiers et 5 utilisateurs développeurs. Dans le modèle FUE, chaque type d’utilisateur s’est vu attribuer un taux de conversion – « Libre-service » a été compté comme 0,1 FUE, « Opérationnel » comme 0,5 FUE, « Finance » comme 1 FUE et « Développeur » comme 1,5 FUE. Pour calculer le coût total, un calcul mathématique a dû être effectué : 50 x 0,1 plus 20 x 0,5 plus, etc… ce qui donne 45 FUE. Seul ce total a servi de base à un nouveau calcul des coûts de licence.

Par exemple, un employé du service des achats qui émet principalement des commandes peut être considéré comme un utilisateur opérationnel, mais s’il approuve en outre des factures, il doit être classé comme un utilisateur financier. De même, un directeur des ventes – à première vue opérationnel, mais s’il a accès à des rapports de contrôle de gestion, il fait passer les coûts dans une catégorie supérieure.

En conséquence, les entreprises qui n’avaient aucune expérience de la FUE ont souvent surestimé le nombre de types d’utilisateurs plus coûteux. Au lieu de faciliter le démarrage, le modèle a nécessité des ateliers détaillés, une cartographie des rôles et l’intervention de consultants pour éviter les surcoûts.

 

La FUE a été remplacée par la PUPM – une nouvelle approche

Dans le modèle PUPM (Per User Per Month), SAP a supprimé les taux de conversion qui posaient le plus de problèmes dans FUE. À première vue, le problème semble donc résolu : le client achète des licences clairement nommées, telles que Self-Service, Operational ou Finance Base, et paie un tarif mensuel par utilisateur.

Dans la pratique, cependant, le défi n’a pas complètement disparu, mais a simplement changé de forme. Désormais, ce ne sont pas les taux de conversion, mais les catalogues d’activités attribués qui déterminent le type d’utilisateur qu’une personne recevra. Chaque catalogue se voit attribuer une catégorie de licence, et l’utilisateur hérite du type le plus élevé des catalogues qui lui ont été attribués dans le cadre de son rôle.

Par exemple, si un employé a accès à la fois à l’annuaire Self-Service et à l’annuaire opérationnel, il sera classé comme utilisateur opérationnel. Si, en plus, il a accès au répertoire Finance Base, son type passera à Finance Base, même s’il n’utilise ces fonctions qu’occasionnellement ou pas du tout.

Pour de nombreuses entreprises, cela signifie le retour d’un problème familier : « Nous avons 100 personnes qui veulent travailler dans le système », mais avant de leur donner des rôles, elles doivent comprendre quels annuaires augmenteront le type d’utilisateur et le coût de la licence. Si le calcul est plus simple aujourd’hui qu’il ne l’était dans la FUE, la classification des rôles elle-même est encore parfois compliquée et sujette à des risques d’erreurs. Un répertoire supplémentaire peut faire augmenter les coûts pour tout un groupe d’employés, et attribuer sans le savoir des rôles trop larges revient à payer trop cher.

C’est pourquoi, dans le modèle PUPM, comme dans la FUE, les ateliers et les révisions régulières des droits deviennent cruciaux. Les entreprises qui se limitent à une « simple attribution de rôles » peuvent rapidement découvrir qu’elles paient pour du Premium, alors que les utilisateurs n’utilisent en pratique que du Self-Service ou de l’Opérationnel.

Nouveaux types d’utilisateurs (UGS)

Dans le modèle PUPM, SAP a introduit des catégories d’utilisateurs clairement définies. Par conséquent, le client ne calcule plus des FUE abstraites, mais choisit parmi des paquets spécifiques. Chaque paquet correspond à une gamme différente de fonctionnalités et les prix varient en fonction du niveau.

Base financière et prime financière

• Finance Base est un progiciel de base destiné aux personnes travaillant dans le domaine de la finance – comptables, spécialistes des comptes fournisseurs et des comptes clients, responsables de l’établissement de rapports. Il comprend, entre autres, GL, AP, AR et les processus de contrôle de base.
• Finance Premium est une version améliorée, comprenant des applications et des intégrations supplémentaires, par exemple Ariba, Concur, la gestion de projet, le développement durable, ainsi que la prise en charge de scénarios de contrôle de gestion avancés. La version Premium comprend également toutes les fonctionnalités de Finance Base (modèle imbriqué).

SCM Base et SCM Premium

• SCM Base est un progiciel destiné aux planificateurs et aux opérateurs logistiques – gestion de la chaîne d’approvisionnement, planification de la production, gestion des entrepôts, achats opérationnels.
• SCM Premium est un logiciel complet destiné aux fonctions plus avancées, par exemple les ingénieurs de production, les planificateurs stratégiques et les responsables de la qualité. Il comprend toutes les fonctionnalités de SCM Base ainsi que des modules supplémentaires pour prendre en charge des processus plus complexes.

Combo Base (Finance + SCM)

• Combo Base combine des éléments de Finance Base et de SCM Base en un seul package. Il s’agit d’une solution pour les organisations dont les utilisateurs utilisent à la fois les processus financiers et logistiques et qui ne souhaitent pas acheter deux licences distinctes.

Opérationnel

• L’utilisateur opérationnel est une licence destinée aux utilisateurs qui traitent des transactions de base, par exemple les employés des services d’achat, de vente ou de service à la clientèle. Ce type d’utilisateur émet des commandes, des devis et des confirmations de livraison, mais n’a pas un accès complet au domaine des finances ou de la planification.

Libre-service

• L’utilisateur en libre-service est la formule la plus simple et la moins chère. Il est conçu pour les employés qui n’utilisent que les fonctions en libre-service, par exemple la déclaration des congés, la saisie des feuilles de temps, la visualisation de leurs propres données RH ou des rapports de base.

Développeur

• Developer User est un type de licence spécial pour les développeurs travaillant dans l’environnement SAP. Elle peut inclure l’accès à l’ABAP Workbench, ainsi qu’aux outils de la famille SAP Build (par exemple Build Apps, Build Process Automation).

Types d’utilisateurs – exemple d’application

Imaginons une entreprise manufacturière comptant 100 employés. Soixante employés sont des opérateurs qui n’ont besoin que de Self-Service car ils doivent seulement signaler les congés et saisir les heures de travail. Vingt-cinq personnes s’occupent des ventes et des achats – pour elles, le progiciel Operational semble approprié. Dix employés de la comptabilité ont besoin d’une licence Finance Base, et trois personnes qui s’occupent du contrôle de gestion avancé et de l’intégration avec Ariba et Concur doivent avoir Finance Premium. Enfin, deux développeurs qui utilisent ABAP et SAP Build ont besoin d’une licence Developer.

À première vue, tout semble clair : chacun obtient ce dont il a besoin. Mais supposons maintenant que cinquante employés aient besoin d’accéder à Concur pour comptabiliser leurs frais de voyage d’affaires. En théorie, Concur fait partie de l’offre Finance Premium. On peut donc se poser la question suivante : cela signifie-t-il que des licences Premium plus chères doivent être achetées pour ces cinquante personnes, même si elles n’utilisent que de simples fonctions en libre-service en plus de la saisie des voyages d’affaires ?

Cela montre que le nouveau modèle n’est pas du tout aussi simple qu’il pourrait le sembler dans les présentations. Dans la pratique, des doutes apparaissent :

• Si toutes les personnes qui comptent pour des délégations dans Concur doivent automatiquement avoir Premium,
• si SAP prévoit des exceptions et des scénarios spéciaux pour de tels cas,
• si un « mélange » peut être utilisé – certains employés en libre-service, d’autres en prime, même s’ils effectuent des activités similaires,
• comment répartir les rôles de manière à ne pas surpayer les utilisateurs qui n’utilisent qu’accessoirement des applications plus coûteuses.

Par conséquent, si le PUPM simplifie la liste des prix et élimine les taux de conversion FUE complexes, dans la vie quotidienne, les entreprises doivent toujours analyser très attentivement les attributions de rôles et d’accès. Un répertoire supplémentaire comme Concur peut transformer un utilisateur Self-Service peu coûteux en un utilisateur Premium onéreux et modifier radicalement la structure des coûts.

Exemple numérique

Si ces 50 utilisateurs sont classés comme Self-Service, le coût (exemple hypothétique au taux simplifié) : 50 × 5 EUR par mois = 250 EUR par mois. Mais s’ils sont reconnus comme des utilisateurs Finance Premium, le coût passe soudainement à : 50 × 60 euros par mois = 3 000 euros par mois.

La différence est de 2 750 euros par mois, soit plus de 33 000 euros par an, simplement parce que l’accès à une application (Concur) a fait monter la catégorie des licences.

Que montre-t-elle ?

Cet exemple montre que même si le PUPM semble plus simple que la FUE, en pratique, il reste plein de zones d’ombre. Le client doit déterminer si la comptabilisation des délégations permet à un utilisateur d’obtenir le statut Premium, si SAP autorisera des exceptions ou si des licences coûteuses seront nécessaires pour tous les utilisateurs de l’application Concur. Ce sont ces zones d’ombre qui font que le modèle PUPM, malgré une communication simplifiée, nécessite toujours une analyse détaillée des rôles des utilisateurs, des répertoires et des scénarios pour éviter les surcoûts.

Nombre minimum d’utilisateurs

SAP introduit également un nombre minimum d’utilisateurs : 25 utilisateurs Finance Base ou Premium, au minimum 1 Finance Base lors de l’achat d’une autre UGS de base, Premium supprime les restrictions de base. 1 Finance Base lors de l’achat d’une autre UGS de base, Premium supprime les restrictions de base.

Exemple: Une entreprise souhaite se lancer avec un module d’achat uniquement. Elle doit acheter au moins 1 Finance Base et 25 Base/Premium, même si, en réalité, moins de personnes l’utilisent, ce qui génère des coûts de licence supplémentaires (provision avec astérisque).

Droits commerciaux incorporés

La grande nouveauté est que dans le PUPM, certaines des solutions qui devaient auparavant être achetées sont déjà incluses dans le prix :

• dans Base: Connectivité multibancaire, taux de marché, accès numérique, construction de la base,
• Premium: Ariba, Concur, Sales Cloud, Gestion de projet, Durabilité.

C’est une simplification, mais c’est aussi un risque : le client doit veiller à ne pas payer trop cher pour des fonctions qu’il n’utilise pas réellement.

Comment SAP attribue-t-il un type d’utilisateur ?

Le système est basé sur les catalogues d’entreprise.

Un type d’utilisateur est attribué à chaque répertoire. Rôle = ensemble de répertoires. Le système attribue le type le plus élevé parmi les catalogues. La mesure s’effectue automatiquement dans SAP IAM.

Exemple

– Opérateur d’entrepôt → Libre-service,

– Opérateur de production → SCM Base,

– Comptable en charge des comptes fournisseurs → Finance Base,

– Compliance Officer → SCM Premium

 

Résultat : bien que de nombreux utilisateurs bénéficient de fonctions simples, la présence de plusieurs rôles « premium » fait grimper le coût global.

Pourquoi est-ce encore compliqué ?

Au niveau de la diapositive, cela semble très transparent – plusieurs types d’utilisateurs, une simple règle « le type le plus élevé l’emporte » et une mesure automatique dans SAP IAM. Dans la pratique, cependant, les clients sont confrontés à des matrices de mappage étendues qui ressemblent à d’énormes feuilles Excel, pleines de dizaines ou de centaines de lignes et de colonnes. Dans chaque colonne se trouvent des rôles d’entreprise, dans chaque ligne des tâches spécifiques ou des objets de système, et à l’intersection vous pouvez voir de petites marques – généralement des « x » – indiquant que le rôle nécessite l’accès à un répertoire particulier.

Du point de vue des licences, le principe « le type le plus élevé l’emporte » est essentiel. Il peut arriver que 90 % des droits d’un utilisateur relèvent d’un type inférieur, par exemple Operational ou Finance Base, et qu’une seule application oblige à passer au type Premium. Souvent, l’utilisateur ne se rend pas compte que ce catalogue supplémentaire se traduit par un coût plusieurs fois supérieur pour sa licence. S’il avait su que c’était lui qui surclassait la catégorie, il aurait pu consciemment y renoncer.

Il est donc dans l’intérêt du client de définir l’accès en toute connaissance de cause, en s’assurant qu’il existe bien un besoin professionnel pour un type de licence plus élevé. Mais il est encore plus important de contrôler l’utilisation réelle. Dans la pratique, il arrive souvent qu’au stade du lancement d’un projet, les utilisateurs professionnels se battent pour obtenir les droits les plus larges possibles (« parce qu’ils pourraient être utiles »), les arguments étant parfois liés à des questions d’ego et de position dans l’organisation. Le résultat est qu’un employé obtient un accès premium, l’utilise pendant une semaine ou pas du tout, et que l’entreprise supporte le coût de cette décision pendant des mois.

Il est donc bon qu’il y ait un outil et une personne dans l’organisation responsable du suivi de l’utilisation. Cette combinaison permet de ne pas limiter les licences mais de les optimiser pour les besoins réels. L’idée n’est pas de « ne pas payer » pour SAP, mais de payer pour ce qui est réellement utilisé et non pour quelque chose qui a été gagné au début du système et qui s’est avéré inutile par la suite.

Exemple :
Le comptable des comptes fournisseurs travaille principalement dans Finance Base, mais reçoit un catalogue supplémentaire associé à Concur pour pouvoir comptabiliser les délégations dans des situations exceptionnelles. Le système le classe immédiatement dans la catégorie Finance Premium, ce qui représente plusieurs fois le coût mensuel pour l’entreprise. L’utilisateur pourrait se passer de cette fonctionnalité, mais il ne sait pas qu’elle affecte sa catégorie de licence.

Par conséquent, un petit « x » dans le tableau peut augmenter le coût d’une licence non seulement pour une personne, mais aussi pour l’ensemble du groupe si un rôle est défini de manière large et attribué à un plus grand nombre d’employés. Cela montre que, bien que l’UPM ait simplifié la liste des prix, la gestion des droits nécessite toujours une analyse détaillée et une conception éclairée des rôles, faute de quoi il est facile de payer trop cher.

Limitation importante – flexibilité des licences à sens unique uniquement

Il convient de mentionner que la définition correcte du modèle PUPM n’est pas seulement une question de licences d’utilisateur, mais aussi de l’ensemble de l’offre d’environnement. En fonction du choix de la version de base ou de la version Premium, le client peut recevoir des produits et des fonctionnalités supplémentaires. Toutefois, le modèle PUPM n’offre pas de flexibilité dans les deux sens, ce qui constitue une limite importante.

L’ajout de licences en cours de contrat est possible – le client peut augmenter le nombre d’utilisateurs à tout moment. En revanche, il n’est pas possible de réduire le nombre de licences de manière continue. Un tel ajustement ne peut être effectué qu’au moment du renouvellement du contrat, en fonction de la durée pour laquelle il a été signé (généralement de 3 à 5 ans). Pendant la durée du contrat, SAP n’autorise pas de réduction de volume.

Cela signifie qu’une entreprise qui surestime ses besoins et achète trop de licences premium « au cas où » devra supporter ce coût jusqu’à la fin du contrat. Par conséquent, la sensibilisation des clients et des partenaires qui vendent SAP Cloud ERP est absolument essentielle – elle détermine si une organisation utilisera la ressource de manière efficace ou si elle brûlera des budgets importants pendant plusieurs années pour des accès inutilisés. Un moyen efficace d’atténuer ce risque consiste à surveiller l’utilisation réelle du système et les licences attribuées.

Au lieu d’acheter immédiatement de nouvelles licences, il convient d’examiner si l’utilisation actuelle est suffisamment intensive pour justifier l’ajout de nouvelles licences. Très souvent, l’analyse montre que certains utilisateurs n’utilisent pas pleinement leurs accès. Dans ce cas, au lieu d’augmenter le nombre de licences, il est possible de les réattribuer au sein du pool existant – en retirant les accès inutilisés et en les attribuant à de nouveaux employés.

Cette approche nécessite un suivi systématique, mais permet à l’entreprise d’éviter de payer trop cher et de rester plus flexible dans les limites des licences qu’elle détient déjà.

Résumé

Le risque principal du nouveau modèle PUPM est que les frais sont basés sur les droits attribués plutôt que sur l’utilisation réelle. Cela signifie que l’entreprise peut payer pour un accès que l’utilisateur n’utilise pas réellement. Sans une optimisation régulière des rôles et une analyse de l’utilisation réelle des applications, il est facile d’augmenter les coûts de licence au-delà des besoins. C’est pourquoi des outils tels que SAP GRC, SAP IAG ou SmartGRC, qui vous permettent de voir qui a quels droits, qui utilise réellement le système et où il est possible de réduire les coûts, sont toujours nécessaires.

Pour l’instant, les modèles FUE et PUPM fonctionneront en parallèle jusqu’au premier semestre 2026, et les clients ne sont pas tenus de migrer immédiatement. En outre, les possibilités techniques de migration vers le PUPM ne se présenteront qu’après cette date.

En résumé, le passage au PUPM est une révolution dans la communication, car la liste des prix est plus claire et plus facile à comprendre, mais dans la pratique, il s’agit encore d’une évolution, qui exige que les clients adoptent une approche consciente de la matrice des rôles et qu’ils l’optimisent en permanence. La meilleure solution consiste à considérer la période de transition jusqu’en 2026 comme une période de test, d’atelier et de préparation de l’organisation au nouveau modèle, de sorte qu’après la migration, vous payez pour ce qui est réellement utilisé.