Lorsque rien ne fonctionne plus : Redémarrer

Les constats sont décisifs lors de la refonte d'un concept d'autorisation. Ceux-ci sont répartis en différents niveaux de risque. La rapidité avec laquelle les risques peuvent être éliminés est également importante.

Les paramètres système qui n'ont pas le bon réglage sont un exemple de défaut. Le rapport RSPARAM montre les paramètres du système. Il permet d'afficher des paramètres tels que la journalisation générale du système, qui doit être activée de manière générale, sous peine d'enfreindre la loi (risque élevé, qui peut toutefois être corrigé en temps voulu).

Les paramètres relatifs à la longueur et à la complexité des mots de passe ou au contrôle des utilisateurs SAP standard peuvent également y être vérifiés et, le cas échéant, corrigés.

Un autre exemple est celui des autorisations attribuées. Ici aussi, nous trouvons dans certaines circonstances des autorisations critiques qui sont liées à un risque élevé. Par exemple, l'objet d'autorisation S_SCD0 avec l'activité 06.

Cet objet d'autorisation permet de supprimer des documents de modification (interdiction de gommer). Cela constituerait une violation du Code de commerce allemand dans un système pertinent pour les finances.

Qu'est-ce qui est vraiment critique ?

La prise en compte des risques liés aux autorisations attribuées dépend de nombreux facteurs. L'un de ces facteurs est bien entendu l'existence d'autorisations critiques au regard de la législation, comme le montre l'exemple ci-dessus.

Ces problèmes d'autorisation sont relativement faciles à attribuer à un niveau de risque. En outre, il existe toutefois des risques qui dépendent de l'entreprise. Dans ce cas, il convient d'analyser au préalable avec précision où se trouvent les données de l'entreprise qui sont pertinentes en termes de risques.

Ainsi, une banque qui exerce ses activités bancaires en dehors de SAP et ne fait transiter que ses flux financiers internes par SAP considère que son système financier interne n'est pas aussi critique. Un autre exemple serait celui d'une entreprise chimique qui conserve ses recettes dans SAP.

Cette entreprise considérerait cela comme très critique et donc comme un risque très élevé. Les risques doivent donc être définis en fonction de l'entreprise.

Catalogue de risques spécifique à l'entreprise

Dans certaines circonstances, les efforts nécessaires pour résoudre les problèmes d'autorisation constatés peuvent être très importants. Cela est généralement lié à la structure des autorisations.

Les choses se compliquent lorsque les rôles d'autorisation sont trop grossiers ou trop granulaires. De même, si un concept d'autorisation défini n'est pas respecté de manière conséquente, des incohérences apparaissent.

Pour déterminer si les lacunes et les incohérences du système d'autorisation existant peuvent être corrigées ou s'il est préférable de mettre en place un nouveau système, il est nécessaire de procéder à une analyse préliminaire détaillée par des experts.

La question est alors la suivante : le temps et le coût d'une correction sont-ils plus élevés que ceux d'une refonte du système ?

Étapes de la refonte

Un redesign exige un engagement important de la part des collaborateurs. Les administrateurs des autorisations et le service spécialisé sont notamment très impliqués. Cela représente une charge de travail supplémentaire importante pour les collaborateurs par rapport aux activités quotidiennes.

Souvent, il est également fait appel à des entreprises externes, ce qui entraîne des coûts supplémentaires pour un tel projet. S'il est nécessaire de redéfinir le concept d'autorisation, les dépenses devraient être aussi limitées que possible.

Pour ce faire, nous examinons comment le redesign peut être mis en œuvre, quels sont les risques et quels outils SAP Bord peuvent être utilisés à cet effet. Les logiciels spécialisés peuvent compléter les outils de bord SAP à de nombreux endroits ou automatiser entièrement certaines étapes du processus.

Cela permet de réduire encore la charge de travail. L'utilisation éventuelle d'un tel logiciel devrait être prise en considération.

Étape 1 :

Dans le cadre d'une refonte des autorisations, il convient d'abord d'examiner attentivement la documentation existante relative à un concept d'autorisation éventuellement déjà en place et de la compléter éventuellement.

Ces documentations devraient également définir, par exemple, les conventions de dénomination, la gestion des utilisateurs (p. ex. protection de la maternité) et la création de rôles via le générateur de profils.

Le grand défi lors de l'élaboration d'un concept d'autorisation consiste à trouver un équilibre : D'une part, tous les points importants doivent y figurer. D'autre part, les points qui changent fréquemment ne doivent pas être rédigés de manière trop détaillée.

Étape 2 :

L'étape suivante consiste à effectuer un contrôle des autorisations dans les systèmes. Malheureusement, cela n'est possible que de manière très limitée via les outils de bord SAP. Les restrictions techniques et les rapports standard contenant des erreurs en sont la cause.

Étape 3 :

Ensuite, il y a la phase de mise en œuvre, pour laquelle trois questions sont déterminantes : QUOI doit faire un utilisateur dans le système SAP, COMMENT il doit le faire et OÙ il doit le faire ?

Le "quoi" est généralement représenté par la transaction. Le "comment" est réglé par les valeurs de champ correspondantes (par exemple les activités "lire" ou "modifier").

Le "où" est contrôlé par ce que l'on appelle les unités organisationnelles. Cela signifie dans quelle société les écritures doivent être effectuées. La question de savoir ce qu'un utilisateur peut faire, c'est-à-dire de quelle transaction il a besoin, peut être résolue par une analyse du poste de travail.

Cela signifie que l'on s'assoit avec chaque employé de l'entreprise et que l'on passe en revue et note les différentes transactions dont l'utilisateur a besoin.

Il s'agit d'une procédure très complexe. Pour accélérer ce processus, on peut recourir aux informations disponibles dans le système. Pour cela, il existe principalement trois méthodes :

1. via la transaction ST03N. A cet endroit, on enregistre quelle transaction a été appelée par quel utilisateur. Dans la plupart des cas, les informations sont disponibles dans le système SAP pour les trois derniers mois.

Conseil : le délai peut être prolongé à 14 mois environ. Ainsi, les transactions pour la clôture annuelle sont également prises en compte.

2. les favoris créés par l'utilisateur peuvent également être utilisés pour une analyse plus approfondie. C'est souvent à cet endroit que sont déposées les transactions Z* ou Y* rarement utilisées, qui ne sont pas mises en évidence par l'analyse ST03. Les favoris peuvent être lus de manière centralisée via un tableau. Tableau : SMEN_BUFFC

3. les transactions qu'un utilisateur avait dans ses anciens rôles (table AGR_1251 et table AGR_USERS). Cette information peut également être utilisée. Il faut toutefois faire attention au fait que les anciens rôles contiennent souvent trop de transactions.

Une fois que l'on a déterminé et analysé ces informations sur tous les utilisateurs du système, ces informations doivent être filtrées et évaluées. Le risque est alors que les informations soient soit oubliées, soit mal interprétées.

L'utilisation d'un produit logiciel supplémentaire peut s'avérer très utile à ce stade. Si cela a été fait pour tous les utilisateurs et tous les domaines spécialisés, on peut commencer à structurer les rôles d'autorisation correspondants selon les tâches partielles des domaines spécialisés et à ajouter les transactions correspondantes.

Il faut veiller à ce que les rôles soient attribués par la suite à des personnes responsables (propriétaires des données). C'est pourquoi les rôles d'autorisation doivent, dans la mesure du possible, être propres à chaque module.

L'un des principaux défis à cet égard est de déterminer les tâches que chaque service doit effectuer en dehors de son domaine de compétence.

Le domaine de compétence se réfère ici au module SAP. Par exemple, les employés des finances travaillent à la fois dans un module COM et dans un module HCM.

Après cette étape du projet, tous les rôles relatifs aux domaines spécialisés correspondants ont été créés avec les transactions. L'étape suivante consiste à définir les rôles créés.

Les questions "comment" et "où" doivent être clarifiées. Ici aussi, le domaine spécialisé est très fortement impliqué. Il existe différentes possibilités pour définir les rôles créés.

Une possibilité est de s'appuyer sur l'expérience des collaborateurs du domaine et de définir les rôles en conséquence. Mais comme la définition des rôles est souvent très technique, on se heurte très vite à des limites.

La possibilité suivante consiste à utiliser les informations de trace (ST01) qui sont générées dans le système SAP. Après activation, il est possible de lire les résultats et de les utiliser pour l'attribution des rôles. Cette possibilité est toutefois considérée comme très coûteuse.

Comme il faut beaucoup d'expérience pour définir les rôles et que les outils standard ne sont que partiellement utiles, l'expérience montre que dans la plupart des cas, les rôles sont définis avec des droits trop élevés.

Le domaine du contrôle de gestion représente un défi particulier. Les entreprises comptent généralement plusieurs centaines de centres de coûts, qui doivent être séparés en rôles sur le plan organisationnel.

Risque : rôles avec des droits trop élevés

Le résultat après la définition manuelle des rôles est généralement encore incomplet et imprécis. Point important lors de la définition des rôles : Il ne faut en aucun cas renoncer à une gestion SU24 lors de l'expression des valeurs de champ.

Les valeurs par défaut du générateur de profils (PFCG) sont paramétrées via la SU24. Une SU24 proprement gérée facilite et accélère considérablement l'administration ultérieure des rôles d'autorisation.

Elle permet également d'augmenter la qualité des rôles d'autorisation. C'est pourquoi cette étape devrait être prise en compte dans tous les cas. Toutefois, l'effort manuel est si important qu'un logiciel spécial devrait être utilisé.

Qualité et sécurité grâce aux soins SU24

La dernière étape avant la mise en production consiste à effectuer un test très intensif des rôles. L'ensemble du scénario de test doit être planifié en détail et accompagné par les membres du projet.

Pour ce faire, des protocoles de test doivent être établis au préalable afin de guider le collaborateur et de lui donner la possibilité de consigner les résultats. Une mise en œuvre rapide des résultats des tests doit être effectuée par l'administration des autorisations.

Une fois les premiers résultats de test corrigés, d'autres tests doivent être effectués. Ce processus doit être poursuivi jusqu'à ce qu'il n'y ait plus d'erreurs d'autorisation.

Un test négatif doit également être effectué. Il s'agit de tester si les utilisateurs peuvent faire quelque chose qu'ils ne devraient pas faire. Par exemple, enregistrer dans une société étrangère.

Souvent, ce test négatif n'est pas effectué. Il y a donc un risque que les rôles avec des autorisations trop élevées ne soient pas reconnus et ne soient pas adaptés.

Lorsque le scénario de test, très long et fastidieux, est terminé, les rôles peuvent maintenant être transportés dans le système de production et attribués aux différents utilisateurs.

Avant le démarrage productif d'un nouveau concept d'autorisation, il faut là aussi disposer d'une planification détaillée. Il n'est pas recommandé de convertir tous les utilisateurs en même temps.

Il est recommandé de changer un ou deux utilisateurs de chaque domaine. Cela permet de voir si, éventuellement, toutes les étapes n'ont pas été prises en compte dans le test précédent et si des problèmes d'autorisation peuvent en résulter. Un scénario dit de "fallback" (l'utilisateur retrouve son ancien rôle) doit être prévu ou représenté par un logiciel spécial.

Trois à quatre mois après la fin du projet, les anciens rôles d'autorisation peuvent être supprimés du système.

La condition préalable est bien sûr que les nouveaux rôles soient fonctionnels. Pour finir, il faut veiller à ce que les processus définis au préalable dans le concept soient respectés. C'est la seule façon de faire en sorte que le nouveau concept d'autorisation, maintenant très laborieusement élaboré, soit conservé.

Conclusion : en cas de graves lacunes dans un concept d'autorisation SAP, une refonte est souvent la solution la plus efficace. La nouvelle conception est toutefois coûteuse et risquée.

Les logiciels spécialisés peuvent ici aider à minimiser les efforts et les risques. On obtient ainsi une meilleure qualité et une réduction des coûts. Les logiciels spécialisés peuvent également être utilisés pour contrôler et soutenir les activités quotidiennes.

Conseil 1

Il y a des cas où il est préférable, dans certaines circonstances, de reprendre entièrement un concept d'autorisation, car un "nettoyage rapide" n'améliore la situation qu'à court terme.

Conseil 2

Si le niveau de détail des concepts d'autorisation est trop élevé, il faut beaucoup de temps pour les entretenir. Les solutions logicielles peuvent apporter une aide dans ce domaine.

Conseil 3

Tant la gestion des concepts d'autorisation que le contrôle peuvent être représentés par des logiciels spéciaux.

Conseil n° 4

Créez régulièrement un téléchargement en masse des rôles modifiés. Vous avez ainsi la possibilité de revenir à tout moment à une version plus ancienne des rôles. Il arrive régulièrement que, dans le feu de l'action, des modifications de rôles qui prennent du temps soient écrasées.

Conseil n° 5

Le risque existe que des collaborateurs soient fortement gênés dans leur travail quotidien en raison d'autorisations manquantes.

Conseil n° 6

Lors de l'utilisation d'un logiciel correspondant, il faut veiller à ce qu'il s'appuie sur les fonctions standard de SAP, afin que les entreprises ne deviennent pas dépendantes de solutions spéciales, ce qui rendrait impossible la gestion manuelle des autorisations.