SAP : le parent pauvre de la gestion des identités et des accès ?

Les ERP sont au cœur des entreprises, pour le pilotage de fonctions telles que les achats, la distribution, la paie… Des fonctions potentiellement sensibles qui imposent évidemment de contrôler le bon fonctionnement des opérations. En commençant par maîtriser dans la durée qui accède à quoi ! Prenons l’exemple d’un ERP parmi les plus connus : SAP.

Pourquoi la gestion des identités et des habilitations des ERP ne doit-elle pas être négligée ?

Les ERP comme SAP sont devenus incontournables dans beaucoup d’entreprises, particulièrement dans les grands groupes. Tout le monde les utilise : de la gestion des achats à celle des contrats, en passant par le contrôle des factures, le mouvement des stocks ou la gestion des ressources humaines, les ERP permettent de tout gérer. À tel point que pour un utilisateur au cœur de ces fonctions, l’ERP peut devenir son principal outil de travail, et représente la majeure partie de « son SI ». Une ville dans la ville du SI, en somme.

Des métiers comme les achats ou la distribution sont potentiellement sensibles, et sont de fait réglementés. La loi de sécurité financière en France, ou la loi Sarbanes-Oxley aux États-Unis, responsabilisent les utilisateurs, mettent en place le contrôle interne et contribuent à la prévention des conflits d’intérêt. Pour être en mesure de se conformer à ces règlementations, il est nécessaire de contrôler les opérations réalisées via les ERP.

Mais encore faut-il savoir qui fait quoi dans l’ERP… ce qui n’est pas toujours le cas. La criticité des opérations impose de donner au sein de l’ERP les bons droits d’accès, aux bonnes personnes, au bon moment, et de contrôler la bonne application des règles. Cela implique, entre autres, de maintenir un référentiel d’utilisateurs dans le temps, de définir des processus d’habilitation à différents niveaux de validation, ou encore de définir des processus de gouvernance qui permettent de faire évoluer la gestion des habilitations de l’ERP en phase avec l’organisation opérationnelle. Avec une attention particulière sur le modèle d’habilitation et l’accompagnement aux utilisateurs.

La richesse des modèles d’habilitation peut induire trop de complexité : comment trouver le bon équilibre ?

Les ERP permettent beaucoup de souplesse dans la définition du modèle d’habilitation. Dans le cas de SAP, le modèle est défini, notamment, via des rôles « pères » et des rôles « fils » liés par des notions d’héritage, et qui instancient un ensemble de transactions sur un périmètre donné. Ou encore des rôles composites qui regroupent plusieurs rôles « fils ». Chaque entreprise utilisant SAP est ainsi en mesure de définir son modèle d’habilitation avec la granularité et la richesse nécessaire à son contexte.

Et c’est bien là le risque. Cette souplesse ne doit pas inciter à définir un modèle d’habilitation (trop) complexe pour l’entreprise. Elle rendrait en effet  la gestion des demandes plus compliquée au jour le jour et induirait au bout du compte un risque de non-conformité aux réglementations.

Nous avons déjà rencontré des situations où les responsables du modèle métier  se désapproprient le sujet, laissant le modèle à la dérive. De même dans le cas des responsables de la ségrégation des tâches (qui limitent le cumul par une même personne de fonctions incompatibles, comme par exemple être en mesure d’éditer une facture et de la payer), cette complexité peut entraîner des attributions abusives de droits. Trop souvent, nous observons la situation « je valide parce que je ne comprends pas… et ne veux pas empêcher les utilisateurs de travailler ».

Le modèle d’habilitation doit donc être cadré et maintenu dans le temps. Un cadre « ferme et simple » fixera des principes et limitera les dérives. Il  définira les rôles types en fonction des métiers et les processus associés, sans essayer de prendre en compte toutes les exceptions de chaque métier.

Par ailleurs, une organisation qui fasse évoluer le modèle dans le temps est aussi nécessaire : la complexité peut résulter d’évolutions successives sans vision d’ensemble. Par exemple dans SAP, le modèle d’habilitation évolue notamment via la mise à jour de rôles simples, lesquels contiennent des droits fins (transactions), répercutés dans plusieurs rôles composites, impactant in fine plusieurs métiers.

Un travail en silo où les évolutions seraient dictées par les besoins spécifiques de quelques fonctions conduirait à un modèle d’habilitation cacophonique. Une organisation et des processus de gouvernance permettent d’éviter cela en contrôlant et en validant collectivement les évolutions. Les acteurs d’une telle gouvernance peuvent inclure des responsables des processus métiers, qui associent la connaissance du terrain à celle du modèle d’habilitation. On pourra y associer un acteur du contrôle interne.

Une équipe transverse s’assure en complément que les responsabilités définies sont bien attribuées et vivent au gré des arrivées, mobilités et départs.

Accompagner les utilisateurs : la clé pour garantir que les outils soient utilisés à bon escient

Les utilisateurs aussi ont besoin de comprendre les habilitations elles-mêmes  et de connaître les acteurs liés aux processus. À défaut de réponse à ces questions, les utilisateurs se tourneront vers le chemin le plus court, parfois même en contournant les processus. Les utilisateurs qui ne savent pas quels rôles correspondent à leur besoin ont tendance à demander les mêmes que leur collègue de bureau, ou bien leur prédécesseur. Ceux qui souhaitent obtenir rapidement un rôle donné seront enclins à le demander directement à la personne effectuant l’attribution finale. Avec le temps, des droits dont les utilisateurs n’ont pas besoin, voire  incompatibles entre eux, s’accumulent.

Permettre aux utilisateurs de travailler correctement sur un ERP implique aussi de les former à l’utilisation des outils. Cela parait naturel pour les transactions métier qu’ils utilisent tous les jours. Mais c’est tout aussi nécessaire pour les démarches de demande d’accès liées à l’ERP qu’ils n’utilisent qu’occasionnellement, et qu’ils ont tendance à oublier.

Enfin la gestion du changement doit permettre de faire vivre les référentiels documentaires et le réseau des utilisateurs clé.

Les projets de gestion des identités et des habilitations du SI ne devraient pas hésiter à intégrer les ERP dans leur périmètre… et réciproquement. En effet ces projets sont encore trop souvent menés de manière disjointe pour les ERP d’une part, et le reste du SI d’autre part. Les gestions des identités et des habilitations doivent pourtant être mises en cohérence opérationnellement, tout utilisateur d’un ERP étant d’abord un utilisateur du SI. Sans surprise, leurs problématiques sont d’ailleurs similaires… et leurs réponses aussi ! Les questions des organisations, des processus et des interfaces techniques entre les deux environnements méritent donc d’être instruites. Bien que ces questions dépendent du contexte, un début de réponse serait à minima de décliner les mêmes processus de gestion des identités. Sans oublier que la gestion des accès doit être considérée comme un pan complet de la conduite du changement et de la formation.

 

Back to top