Le défi de la gestion des licences SAP

La discussion autour de l'utilisation indirecte n'est ni un sujet nouveau ni un sujet spécifique à SAP. Il ressort de la définition de l'utilisation figurant dans les conditions générales de SAP (voir encadré page 47) que non seulement les utilisateurs d'applications tierces doivent obtenir une licence, mais que, le cas échéant, d'autres droits d'utilisation doivent être acquis pour l'application qui communique avec SAP.

Utilisation indirecte - pas de spécificité SAP

Si l'on va plus loin, la définition de l'utilisation peut être interprétée comme ne faisant pas de distinction fondamentale entre l'utilisation directe et l'utilisation indirecte. Le suivi de l'utilisation indirecte doit être examiné de manière plus détaillée, et pas seulement dans le cas de SAP, comme nous l'avons déjà indiqué.

Ce thème existe déjà depuis plus de dix ans : Microsoft, IBM, Oracle et d'autres fabricants le suivent depuis un certain temps. Parmi les clients de Microsoft, la situation est par exemple connue sous le nom de multiplexage : un processus par lequel le matériel et les logiciels sont utilisés pour regrouper les connexions au logiciel, rediriger les informations ou réduire le nombre d'appareils ou d'utilisateurs ayant un accès direct.

Les questions à ce sujet font aussi régulièrement l'objet d'audits logiciels. Pour aborder le sujet de la licence SAP de manière fiable, il faut également faire la distinction entre une simple et pure infraction à la licence et une exigence accrue de licence en raison d'une utilisation indirecte.

Des indices tels que les connexions multiples d'un utilisateur pourraient, le cas échéant, indiquer une utilisation indirecte si le compte d'un utilisateur présente un nombre extrêmement élevé d'accès parallèles, car il serait alors possible de conclure à des accès automatisés.

Par exemple, le compte d'un développeur de logiciels travaillant pour l'entreprise concernée pourrait être utilisé non seulement pour ce développeur, mais aussi pour tous les clients de la boutique en ligne programmée par ce développeur et qui accède à des fonctionnalités SAP.

Le même exemple pourrait être donné si l'on pouvait prouver à l'utilisateur une charge de travail élevée ou une utilisation continue (24 heures sur 24, 7 jours sur 7). Ou alors, le relevé donne des indications sur l'utilisation correspondante de plusieurs composants. Ce ne sont pas forcément des indices valables à 100 %, mais au moins des indices possibles pour donner lieu à une analyse plus approfondie des connexions et de l'utilisation.

Bien entendu, en cas de connexions multiples, de charge de travail élevée ou de longues heures de travail, il pourrait également s'agir d'une "simple" infraction à la licence, c'est-à-dire d'un partage de compte ou d'un utilisateur technique classé par erreur comme utilisateur de dialogue, par exemple.

L'utilisation indirecte/indirecte peut être causée, à titre d'exemple, de la manière suivante : Un utilisateur (licencié ou non) accède par exemple à des fonctionnalités SAP ou à des informations contenues dans l'environnement SAP via une application tierce non-SAP.

Le système non-SAP placé en amont permet donc d'accéder indirectement aux données dans SAP CRM, ERP ou à d'autres composants. Ce qui est important, ce n'est pas seulement l'accès via une application non-SAP, mais aussi la manière dont l'accès se fait :

Les utilisateurs de l'application tierce disposent-ils des licences d'utilisateur SAP Named nécessaires ? Selon les conditions de licence applicables au scénario, le fait que les données soient transmises en temps réel ou en différé peut également jouer un rôle, de même que certains autres critères, selon que SAP propose ou non une solution correspondante qui pourrait remplacer les fonctionnalités externes.

Dans quelle direction s'effectue le transfert de données (unidirectionnel, bidirectionnel, inbound, outbound, etc.) ? Y a-t-il un retrait massif de données (bulk) ? Une évaluation doit être effectuée pour chaque scénario d'utilisation indirecte dans l'environnement de l'entreprise et semble particulièrement utile si l'on peut identifier, à partir des conditions contractuelles possibles, des marges d'interprétation qui pourraient éviter l'octroi inutile de licences supplémentaires.

Par exemple, on trouve souvent dans les anciennes constructions contractuelles (interaction entre le contrat pertinent, la LPC, les conditions générales et la SUR) des informations indiquant que l'utilisation des informations, si elle ne se fait pas en temps réel par exemple et si certains autres critères sont remplis, peut être représentée par des droits d'utilisation existants.

Les conditions contractuelles dans les anciens contrats peuvent donc être des solutions possibles qui, par exemple, n'exigent que l'octroi de licences aux utilisateurs d'applications tierces, mais pas l'application tierce elle-même.

Cette solution doit toutefois être examinée de manière critique et présuppose dans tous les cas que SAP ne fournisse pas de fonctionnalités correspondantes. Ainsi, l'interposition d'un middleware peut être une solution précise, mais cela ne vaut que pour les cas dédiés et suppose la validité des conditions de licence correspondantes.

Ici aussi, l'analyse des contrats est donc indispensable pour garantir le respect des conditions de licence et la conformité nécessaire. Il convient de mentionner ici que les middleware peuvent constituer une solution technique tant que les fonctionnalités du logiciel non-SAP en amont ne sont pas déjà proposées par SAP.

Par exemple, une solution de saisie des temps développée en interne qui ne rapporte pas les données en temps réel et par extraction en masse au système SAP correspondant via un middleware de mise en file d'attente des messages ne constituerait pas une solution appropriée, car SAP propose lui-même des fonctionnalités correspondantes. La situation pourrait toutefois être différente pour les solutions très spécifiques à l'industrie qui ne sont actuellement pas incluses dans le programme logiciel de SAP.

En 2010, SAP a intégré dans son programme la licence "SAP NetWeaver Foundation for Third-Party Applications", qui doit être acquise selon la métrique Named-User ou Core, afin d'obtenir une licence correcte pour les applications tierces, du moins dans la plupart des cas d'utilisation.

La fixation d'une des métriques n'est possible qu'une seule fois, avant le premier achat. Cela signifie qu'il est conseillé de regarder dans les droits et les conditions des anciens contrats et d'utiliser au mieux les marges d'interprétation existantes.

On constate également qu'une tendance se dessine en faveur d'un plus grand choix de licences afin de répondre à la diversité et à la complexité croissante des scénarios d'utilisation indirecte. Le graphique illustre certains de ces scénarios, avec des options de licence alternatives qui sont actuellement développées par SAP.

Ainsi, SAP s'est penché sur les scénarios les plus courants (Procure-to-Pay, Order-to-Cash et Static Read) - comme il l'a également communiqué dans le cadre du Sapphire de cette année à Orlando - et met à la disposition des clients des métriques de licence avec les droits d'utilisation correspondants, comme dans l'exemple ci-dessus, afin de reproduire de manière rentable une attribution correcte des licences.

Pour autant que les clients disposent d'une licence correcte par ailleurs, SAP se montre compréhensif vis-à-vis des besoins actuels des clients en communiquant les concessions faites dans le cadre des mises à niveau nécessaires.

Il est en principe recommandé, quel que soit le fabricant, d'analyser s'il existe des scénarios d'utilisation indirecte dans l'entreprise et de les évaluer du point de vue du droit de licence. Ce n'est qu'ainsi que l'on peut garantir la conformité des licences, qui relève de la responsabilité du preneur de licence.

Accompagner le progrès

Il y a encore deux décennies, les systèmes SAP, à l'époque principalement sous la forme de composants ERP, constituaient, avec leur portefeuille complet d'opportunités commerciales, le frontal idéal pour que les clients osent franchir le pas vers le futur.

Soudain, il était possible de concevoir des processus commerciaux plus efficaces et de réduire considérablement les temps de traitement. Divers flux de travail ont également pu être représentés de manière partiellement ou entièrement automatisée.

Ainsi, l'introduction d'un logiciel ERP était une étape à la fois prestigieuse et courageuse dans un monde de processus commerciaux et d'applications marqué par la numérisation, afin de pouvoir suivre le rythme des structures concurrentielles internationales croissantes.

C'était une époque de bouleversements et de possibilités qui semblaient techniquement infinies, mais pas celle de l'anticipation et de la prise en compte des risques de licence et donc de conformité qui en découlent.

Au fil du temps et avec le développement des possibilités techniques actuelles telles que la virtualisation, les applications en nuage, les appliances de stockage répondant aux exigences réglementaires et les solutions de base de données hautement performantes, le premier grand défi s'est posé à toutes les parties concernées, les concédants de licence comme les utilisateurs.

Les donneurs de licence ont dû anticiper les possibilités techniques futures lors de l'élaboration de leurs modèles de licence, tandis que les preneurs de licence ont été confrontés à la diversité toujours plus complexe des modèles de licence, des métriques et des conditions de licence.

Écosystème SAP

Dans le cas de SAP, l'environnement système homogène qui s'est développé sur deux ou trois décennies s'est éloigné de l'importance qu'il avait autrefois en tant que frontal général pour devenir un écosystème global auquel sont reliées une multitude d'applications spécialisées sur site et dans le cloud.

Les fonctionnalités CRM de Salesforce.com et la gestion du capital humain de Workday en sont des exemples notables. Ces deux exemples remplacent ou complètent généralement des fonctionnalités propres à SAP.

Pour une intégration techniquement correcte de ces applications et d'autres applications spécialisées, SAP met à disposition la technologie correspondante. Dans le passé, cela a été fait de manière exemplaire sous la forme du produit Process Integration (PI).

Outre l'intégration technique, l'utilisation de l'écosystème SAP sous-jacent peut nécessiter l'acquisition de droits d'utilisation supplémentaires. La licence "SAP NetWeaver Foundation for Third-Party Applications", déjà mentionnée, en est un exemple connu.

Un utilisateur qui, par exemple, utilise l'accès aux fonctionnalités SAP uniquement via une plateforme externe, peut ici être doté de droits d'utilisation conformes à la licence grâce à une licence de plateforme correspondante.

Ceci n'est toutefois pas considéré, à tort par de nombreux clients, comme une licence suffisante, mais peut le cas échéant nécessiter l'acquisition supplémentaire de la licence "NetWeaver Foundation for Third-Party Applications", dans la mesure où l'objectif de l'application est basé sur la NetWeaver Platform. En règle générale, même un système PI intermédiaire ne change rien à cette situation.

On reproche souvent à SAP son manque de force d'innovation et on dégrade ses systèmes frontaux originaux en un système back-end pour les jeunes fournisseurs de solutions innovantes. En y regardant de plus près, on obtient cependant une image claire de ce changement, qui permet de le considérer comme l'évolution logique de l'environnement système SAP. Les besoins des entreprises ont évolué et la flexibilité a gagné en importance dans les structures informatiques globales.

Transparence globale

Avec l'hétérogénéité croissante des écosystèmes SAP utilisés par les clients et l'utilisation souvent spécifique aux clients des produits et interfaces intégrés et interconnectés, la création d'une transparence globale prend de plus en plus d'importance depuis un certain temps.

La question de la cause du manque de transparence s'explique souvent de manière simple. Si un gestionnaire de licences est aujourd'hui généralement responsable de toutes les licences logicielles et de la mesure de l'utilisation correspondante, il ne l'est souvent pas dans le cas des licences SAP, ou alors seulement depuis peu de temps.

La raison en est la séparation fréquente entre les unités organisationnelles non-SAP et SAP-IT. Du point de vue du client, pour lequel le système SAP fournit une application critique pour l'entreprise, c'est tout à fait compréhensible, mais du point de vue de la gestion des licences, c'est une tache grise sur la carte des applications à prendre en charge.

Il est donc compréhensible que, dans le passé, les mesures et les achats de licences aient été initiés par ces unités organisationnelles SAP. Mais sans l'établissement de concepts de rôles et de processus correspondants, qui déclenchent par exemple une action en cas d'entrée ou de sortie d'employés de l'entreprise, il est presque impossible de se positionner de manière rentable.

Il est également difficile pour ces unités organisationnelles de suivre l'évolution actuelle des possibilités techniques dans leur connaissance indubitable des licences SAP.

Les infrastructures informatiques convergentes et hyperconvergentes sont des maux nécessaires pour garantir la résilience grâce à l'utilisation des réseaux étendus (WAN) actuels et complètent le degré croissant de virtualisation.

Cependant, saisir l'impact de l'utilisation de ces structures du point de vue de la gestion des licences est souvent hors de portée de la responsabilité correspondante. Les sous-licences sont inévitables en cas d'utilisation de produits dépendant de la structure.

Les anciens contrats de licence logicielle basés sur des modèles de licence CPU ou Core, par exemple, ne sont souvent pas conçus pour être utilisés dans des réseaux virtuels.

En examinant les anciens contrats Business Objects, il est très facile de le constater et, au lieu d'un serveur physique sur lequel le logiciel était utilisé par le passé, il faut maintenant acheter une licence pour le serveur physique de l'environnement virtuel, qui a généralement été configuré de manière beaucoup plus importante en termes de cœurs de processeur, d'unités centrales et de puissance de calcul.

Mais ce serait encore le cas le plus facile à gérer. Les environnements virtuels actuels englobent toutefois au moins plusieurs serveurs physiques sur lesquels la charge de travail est répartie sous la forme d'un cluster. Ainsi, en ce qui concerne la nécessité de licences, on passe d'un serveur physique à plusieurs. Mais ce n'est pas non plus le pire des cas.

Le pire des cas ?

Si l'on utilise la technologie de virtualisation VMware actuelle, on est en mesure, grâce à certaines fonctionnalités (vMotion), de répartir également la charge de travail sur l'ensemble du cluster.

Grâce à l'utilisation de la technologie NSX, par le biais d'infrastructures convergentes et hyperconvergentes, il est même possible de recouvrir des centres de données entiers d'une couche de virtualisation.

La nécessité d'acquérir les droits d'utilisation correspondants, qui résulte de l'obligation d'obtenir une licence, est ici difficilement maîtrisable, car elle n'a souvent pas été prise en compte dans l'analyse de rentabilité de la décision stratégique d'introduire de telles structures.

Mais on peut douter de la nécessité de cette situation, car c'est précisément pour l'évaluation de ces scénarios que l'organisation de gestion des actifs informatiques/gestion des licences est dotée de ressources, de savoir-faire et de compétences, afin d'agir en tant que conseiller de confiance et de fournir des conseils.

La prévention de tels cas est l'une des raisons pour lesquelles une structure de gouvernance établie est nécessaire pour la gestion des actifs informatiques.

Les modèles de licence deviennent de plus en plus complexes

Ce degré de complexité croissant, associé à des modèles de licence et des conditions de licence de plus en plus complexes, ne concerne toutefois pas uniquement les produits propriétaires comme dans le cas de SAP.

En raison de l'évolution décrite de l'écosystème SAP par l'intégration et l'utilisation de produits non-SAP, cela a des répercussions sur d'autres domaines de la gestion des licences.

Cela pose de vastes défis aux organisations dont le niveau de maturité est faible ou qui ne disposent pas d'une gouvernance de la gestion des licences. Ainsi, pour créer la plus grande transparence possible, il est important de reconnaître sa propre utilisation inter-composante ou de savoir par quels moyens les utilisateurs, les systèmes, les bots et autres acteurs communiquent entre eux.

De nos jours, dans le cadre de l'introduction de structures industrielles 4.0 et IoT, les industries automobile et mécanique, par exemple, intègrent de plus en plus de modules de télémétrie, qui se manifestent par exemple par des messages concernant la maintenance à venir ou l'avertissement précoce d'une probabilité prévisible de panne chez le fabricant.

Dans ce cas, l'intégration va parfois si loin que la commande d'assistance correspondante est créée dans SAP et qu'un technicien est envoyé sur place, sans qu'aucune autre interaction ne soit nécessaire. Mais l'absence d'interaction humaine ne signifie pas que ces scénarios ne sont pas soumis à licence.

Il s'agit donc ici d'analyser, avec des connaissances en matière de contrats, de licences et de technique, comment un business case peut être conçu de la manière la plus rentable possible et comment la mise en œuvre peut être représentée conformément aux licences. Dans tous les cas, c'est au client qu'il incombe d'établir une licence correcte.

C'est au plus tard lors de l'utilisation de produits correspondants installés en dehors de SAP, mais ayant accès à des fonctionnalités SAP, que l'on voit la dernière raison pour laquelle l'organisation responsable de la gestion des licences doit absolument être impliquée dès le début de la planification.

Il est nécessaire et important de plonger dans les consoles de gestion des applications externes ou alors d'identifier les groupes d'utilisateurs correspondants jusqu'au niveau des dossiers et d'analyser leurs droits d'accès et leurs autorisations.

La mise en place d'une structure de gouvernance, l'implication continue de l'organisation de gestion des licences et la communication constante des parties prenantes concernées sont devenues, du fait de ces évolutions, une étape indispensable vers un avenir dans lequel la garantie de la conformité des licences est plus exigeante que jamais.

Outre le suivi de tous les canaux de communication basés sur la technologie RFC entre SAP et les systèmes tiers, il convient de recenser et d'évaluer toutes les connexions non RFC (par ex. HTTP, IDoc, IPSec ...) par des méthodes d'enquête qualitatives et quantitatives (par ex. documentation, contrôles de systèmes, etc.).

Recommandations pour la gestion fonctionnelle des licences

Les recommandations pour une organisation fonctionnelle de la gestion des licences sont, à quelques exceptions près, les mêmes pour SAP que pour tout autre fabricant.
Le principe de base de tout bon gestionnaire de licences est de connaître les droits d'utilisation commerciaux, d'identifier les informations sur le type d'utilisation technique et le volume d'utilisation et de les comparer à la fin. En outre, il est important d'identifier les évolutions et les changements dans les règles et les métriques de licence et de les mettre en œuvre dans son propre environnement.
Cela permet d'obtenir des informations sur l'existence d'une sur- ou sous-licence. Voici un bref aperçu des points qui doivent être respectés dans tous les cas pour garantir la transparence nécessaire.

Recommandation : transparence dans l'utilisation indirecte

L'utilisation indirecte des systèmes SAP devrait être considérée individuellement dans le cadre d'une analyse de scénario, en fonction du cas d'application et des conditions sous-jacentes. Le processus de référence suivant s'est établi et a fait ses preuves dans la pratique : Dans un premier temps, il s'agit d'initier et d'effectuer la collecte initiale des données de tous les systèmes de production, de développement ou d'utilisation alternative pertinents pour la mensuration. Selon la taille de l'entreprise, celle-ci dispose de plusieurs dizaines, voire de centaines de sources de données différentes. Cette diversité et cette complexité sont l'une des principales raisons pour lesquelles une collecte/consolidation des données soigneusement planifiée et conçue, suivie d'une analyse, est indispensable.

Dans l'idéal, une instance SAP Solution Manager intégrée et gérée de manière centralisée constitue le point de départ central pour la collecte côté système des informations relatives aux connexions RFC des systèmes SAP pertinents pour la mensuration.

Si une telle source n'existe pas, il convient de trouver une source de données alternative présentant un caractère centralisé similaire. Ensuite, les données et informations collectées sont consolidées, classées et hiérarchisées en fonction de leur pertinence et de leur criticité.

Les systèmes et les connexions qui en découlent sont ensuite présélectionnés selon des critères individuels pour une analyse plus approfondie.

Le résultat représente alors idéalement une vue d'ensemble cohérente des systèmes SAP importants pour la mensuration, dont les connexions avec des systèmes tiers doivent être considérées comme les plus critiques et - en tenant compte de divers aspects de l'utilisation indirecte - les plus pertinentes.

Les scénarios d'utilisation technique, également appelés cas d'utilisation, représentent une composante élémentaire du processus de mesure et de collecte de l'utilisation indirecte. Selon la taille de l'entreprise, il est possible d'identifier quelques scénarios d'utilisation indirecte, mais aussi des centaines de scénarios différents.

Afin de rendre cette complexité un peu plus claire, il est recommandé d'adopter une approche parallèle lors de la définition des scénarios d'utilisation respectifs. En se basant sur la connexion technique sous-jacente et en fonction de la situation de départ, il est toutefois possible de choisir un autre objet de diversification.

En règle générale, on fait toutefois la distinction entre les cas d'utilisation RFC et les cas d'utilisation non RFC.
Après l'observation séparée, il est recommandé de consolider les cas d'utilisation correspondants en scénarios globaux. Pour la consolidation, il est souvent fait appel à des informations techniques sur le niveau de matériel et de virtualisation. Cela permet d'obtenir des précisions supplémentaires et facilite l'analyse et l'évaluation ultérieures.

Le résultat de cette étape du processus est une liste des scénarios d'utilisation les plus pertinents du point de vue de la réduction des risques (sous la forme d'un aperçu logique global).

La troisième étape du processus de référence, la comparaison des licences SAP, s'appuie sur une base de données solide. Il est tout d'abord recommandé d'enrichir les données déjà collectées avec des données d'utilisation ainsi que les autorisations des utilisateurs SAP correspondants sur les applications cibles.

Cela se fait par une extraction de données côté système et une analyse de ces données assistée par le système. Le cas échéant, cela est complété par une analyse des droits d'accès et des autorisations dans l'environnement des applications cibles (par exemple via une analyse au sein de l'Active Directory).

Il s'agit d'abord d'identifier les informations pertinentes pour la licence et de concevoir un mécanisme d'extraction et d'évaluation des données. Ensuite, les profils d'activité correspondants sont développés sur la base des données d'utilisation réelles afin de pouvoir utiliser la base de données réelle comme point de départ.

Il convient de noter que la description réelle des activités doit toujours être considérée de manière générique. Tant les données d'utilisation que les descriptions d'activités des profils respectifs des utilisateurs devraient idéalement disposer des autorisations d'accès techniques et des accès/activités réellement effectués sur les applications SAP correspondantes.

Pour ce faire, il est recommandé d'analyser les applications cibles correspondantes au niveau technique des autorisations. Pour finir, l'état théorique (le nombre de licences indiqué dans le contrat) est comparé à l'état réel. Ce dernier est déduit de l'utilisation effective.

Les enseignements tirés de la comparaison des licences sont utilisés lors de la quatrième étape du processus de référence afin de pouvoir évaluer les cas d'utilisation définis précédemment d'un point de vue économique.

Outre ces considérations, des évaluations des risques sont également effectuées afin de pouvoir considérer l'évaluation à un niveau plus détaillé et plus précis. Ici aussi, il est recommandé, pour réduire la complexité, de répartir les business cases en fonction des données technologiques, de les considérer séparément les unes des autres et de les consolider ensuite en business cases globaux et plus généraux.

Ensuite, les business cases transversales sont soumises à une évaluation critique. Cette évaluation se base sur des critères définis et pondérés au préalable.

Cette procédure permet de garantir que seuls les cas d'entreprise qui ressortent de l'analyse comme pertinents sont inclus dans le cercle restreint de la décision. Dans ce contexte, pertinent ne signifie pas seulement pertinent du point de vue de la minimisation des risques, mais plutôt pertinent pour garantir l'octroi de licences globales comparativement le moins cher et maîtrisable du point de vue de la conformité.

La dernière étape consiste à identifier les possibilités techniques permettant d'anticiper la réduction des risques, ou idéalement d'éviter l'utilisation indirecte. C'est dans ce contexte que s'effectue l'évaluation monétaire des mesures potentielles.

Le regroupement des divers scénarios en paquets logiques globaux permet d'identifier des propositions pour l'octroi de licences globales les plus avantageuses. Dans ce contexte, la conformité est assurée (le cas échéant en concertation avec SAP) par des adaptations techniques ou par l'acquisition proactive des licences nécessaires.

Dans ce contexte, il ne faut pas seulement miser sur une élimination des problèmes à court terme. Il convient plutôt de créer une transparence durable, le cas échéant en collaboration avec des spécialistes. Les solutions élaborées ont pour but d'établir un ensemble de règles pour l'identification et l'évaluation proactive de l'utilisation indirecte dans l'entreprise.

Étude de cas : Saisie des temps

Afin d'examiner de plus près l'exemple de la saisie des temps et de comprendre quand une
Si une solution interne est à l'origine d'une violation de la conformité, trois scénarios différents sont proposés.
à titre d'illustration.

Les collaborateurs d'une entreprise utilisent un logiciel de saisie des temps développé en interne ou par un tiers pour enregistrer leur temps de travail. Les données sont transférées dans le système SAP via SAP PI.

1er scénario :

Tous les utilisateurs qui utilisent le logiciel de gestion du temps seraient donc soumis à une licence. Le montant exact des licences d'utilisateurs nommés nécessaires nécessiterait une analyse permettant de vérifier si les utilisateurs de la saisie des temps disposent déjà de licences d'utilisateurs nommés et si les droits contenus dans ces licences sont suffisants. En outre, il est nécessaire d'obtenir une licence pour l'application propre ou tierce (saisie des temps) avec SAP NetWeaver Foundation for Third-Party Applications.

2e scénario :

L'interposition éventuelle de files d'attente de messages, qui ne transmettent les données qu'en vrac et avec un certain retard via PI au système SAP prévu, pourrait constituer une solution que les utilisateurs ne considèrent pas nécessairement comme relevant de la licence. Cette solution technique possible nécessite toutefois au moins deux conditions :

• Les conditions contractuelles doivent être remplies en conséquence.
• Les fonctionnalités des logiciels non-SAP ne sont pas déjà incluses dans les solutions SAP disponibles.

Ce type de licence n'est toutefois pas clairement défini, de sorte qu'en cas de doute, il existe au moins une obligation de licence comme dans le scénario 1, si le logiciel SAP offre les mêmes fonctionnalités. A cela s'ajouterait le cas échéant une licence correspondante pour le Message Queuing utilisé. En cas de doute, il convient d'analyser ce point.

3ème scénario :

Une autre solution pourrait être d'intercaler un collaborateur des RH ou un collaborateur de service partagé qui saisirait manuellement les données des rapports de l'application non SAP dans SAP. Il faudrait accorder une licence à ce collaborateur et s'assurer que la bonne licence a été attribuée. En règle générale, il s'agirait pour un collaborateur RH d'une licence SAP Professional User.

Aperçus et perspectives

Les défis de la gestion des licences ne sont pas un sujet spécifique à SAP. Au contraire, comme nous l'avons déjà décrit, SAP fournit à ses clients un outil pour les aider à gérer correctement les licences. Pourquoi la gestion des actifs logiciels est-elle pourtant perçue comme un sujet très complexe qui pose souvent problème ?

La numérisation des modèles d'entreprise fonctionne avec des logiciels et, dans de nombreux domaines, les logiciels sont la base du fonctionnement des processus et des modèles d'entreprise.

La complexité croissante de l'exploitation des infrastructures informatiques et des applications logicielles correspondantes augmente en même temps la complexité de l'octroi correct de licences pour les logiciels mis en œuvre et utilisés. Le simple fait de "compter, mesurer et peser", comme on pouvait le faire dans le passé, n'est plus d'aucune aide.

Depuis que la virtualisation et le cloud computing sont de plus en plus utilisés, les modèles de licence des éditeurs de logiciels ont fortement gagné en complexité en raison de ces évolutions technologiques.

De nombreuses entreprises doivent désormais mettre en place des modèles hybrides de gestion des licences, qui associent d'une part la gestion des licences d'origine et d'autre part la gestion des modèles de souscription. Il n'y a guère d'organisation de gestion des licences qui puisse remplir cette tâche.

A cela s'ajoute le fait que ce sujet n'occupe actuellement pas une place de choix dans l'agenda de la plupart des DSI. Dans notre pratique de conseil, nous faisons l'expérience d'entreprises de plus de 100.000 collaborateurs qui n'ont qu'une seule personne chargée de la gestion des licences pour des centaines de produits logiciels.

Il n'est pas rare que cela ne soit pas soutenu par un outil SAM professionnel, mais que la gestion se fasse à l'aide de listes Excel. Si l'on considère qu'un seul éditeur de logiciels modifie environ 50 conditions de licence par semaine, le résultat d'une telle constellation ne peut être que la "non-conformité".

Les discussions émergentes sur des thèmes spécifiques, actuellement par exemple sur le thème de "l'utilisation indirecte", augmentent les incertitudes dans la gestion des licences, bien que ce thème soit déjà abordé depuis des années par différents éditeurs de logiciels.

En raison des récentes concessions de la part de SAP concernant la mise à disposition de modèles de licence correspondants pour les scénarios les plus courants, il est recommandé d'évaluer rapidement la situation individuelle en matière de licences afin de profiter de ces concessions de manière proactive, au lieu de ne plus pouvoir utiliser les possibilités offertes ou de ne pas pouvoir les utiliser complètement en cas d'audit de licence.

Le cloud est actuellement un sujet à la mode chez tous les éditeurs de logiciels et les clients espèrent réaliser des économies par rapport à leurs coûts actuels de licence et de maintenance. Mais comment un client peut-il faire une analyse de rentabilité s'il ne sait même pas s'il est actuellement licencié correctement et de manière rentable ?

Un business case doit être calculé sur une base solide et une gestion des actifs logiciels efficace y contribue. Il en va de même pour le thème de la cybersécurité.

Une gestion des actifs logiciels (SAM) efficace permet à une entreprise de disposer en permanence d'une vue d'ensemble actualisée des logiciels utilisés pour une version donnée et de pouvoir ainsi analyser proprement les risques de sécurité spécifiques à cette version.

Que devraient faire les décideurs informatiques, que leur est-il recommandé de faire pour relever les défis décrits ? Une entreprise qui s'occupe de SAM devrait mettre en œuvre un modèle de gouvernance avec des rôles, des responsabilités et des processus qui permettent une gestion efficace et efficiente des licences.

Dans les grandes entreprises, il ne s'agit pas d'une tâche qui peut être accomplie par un ou deux employés, mais l'organisation SAM doit refléter la complexité de l'entreprise dans son ensemble.

Il convient d'utiliser un outil SAM qui soutienne les gestionnaires de licences dans leurs tâches et permette de piloter le sujet. Un basculement vers des modèles d'abonnement n'est pas une solution pour remédier aux déficits de la gestion des licences.

L'engagement du top management est décisif pour une gestion des licences réussie. Pour le DSI, la gestion des licences doit être une composante importante de sa stratégie informatique globale. Une base sûre est la condition sine qua non pour calculer des business cases et prendre des décisions d'investissement solides pour les nouvelles technologies.

Les résultats d'études internationales prévoient qu'en 2017, plus de 75% de toutes les activités de transformation du cloud se feront sans connaître les coûts réels des licences avant la prise de décision et sans contrôle efficace pendant la transformation. Cela donne à réfléchir !

[/av_textblock]