Comment réussir le changement de rôle

Une approche stratégique, une documentation minutieuse et, surtout, des tests approfondis sont tout aussi importants. La gestion des rôles et des autorisations ne doit pas être sous-estimée dans les projets de migration S/4. Dans un projet greenfield, les adaptations nécessaires des rôles des utilisateurs et des autorisations font régulièrement partie du plan de projet. En revanche, lors d'une migration brownfield d'ECC vers S/4 Hana, l'importance et la charge de travail de ce sujet sont souvent sous-estimées.

Dans ce cas également, différentes transactions doivent être remplacées sur la base des éléments de simplification et les rôles des utilisateurs doivent être adaptés en conséquence. Parallèlement, il est possible de redéfinir ou de corriger les autorisations au cours du changement. Si, en plus, des applications Fiori sont utilisées, l'équipe de projet doit faire face à d'autres défis.

Même pour les responsables SAP expérimentés, il est au départ inhabituel que deux autorisations doivent être attribuées pour les applications Fiori - une fois dans le frontend pour l'appel OData et une fois dans le backend pour l'exécution proprement dite des applications. Ce principe a également des répercussions sur la création des rôles d'utilisateur : Si l'on utilise un Central Hub Deployment dans lequel le front-end et le back-end représentent deux systèmes différents, il est impératif d'attribuer également deux rôles. Pour la plupart des entreprises disposant d'un système SAP de taille moyenne, il est en revanche recommandé d'utiliser la structure de déploiement embarqué, plus simple. Dans ce cas, comme le front-end et le back-end fonctionnent sur un serveur, il est en principe possible et souvent conseillé de regrouper les deux autorisations dans un seul rôle. 

Launchpad Fiori

Les applications Fiori ne doivent pas être considérées comme un simple complément aux transactions classiques. Leur utilisation modifie dans tous les cas les interfaces utilisateur, mais le plus souvent aussi les processus correspondants. Les utilisateurs ne lancent plus les différentes opérations via les appels de transaction classiques, mais via le launchpad Fiori. Dans ce point d'entrée central, toutes les applications nécessaires sont rassemblées dans des tuiles Fiori, regroupées de manière claire et adaptées individuellement aux rôles respectifs des utilisateurs.

L'IT peut créer les launchpads à partir de catalogues standard pour chaque utilisateur ou groupe d'utilisateurs. Les exigences pour cela viennent des domaines spécialisés. Pour cela, les responsables métiers doivent d'abord se familiariser avec les nouvelles possibilités offertes par les applications Fiori. 

SAP Activate

La méthode SAP Activate prévoit que les responsables et les utilisateurs clés des départements spécialisés se familiarisent avec le contenu des catalogues SAP standard au cours de la phase d'exploration. Ensuite, ils devraient être en mesure de définir leurs propres processus et les applications dont ils ont besoin. Cette procédure a fait ses preuves dans les projets précédents : La planification précoce des rôles et des autorisations dans les deux premières phases du projet est absolument recommandée. Mais les autorisations jouent également un rôle central dans les phases ultérieures du projet, jusqu'à la phase de réalisation, et doivent être adaptées en permanence.

Les applications sélectionnées pendant la phase d'exploration sont rarement définies de manière définitive dès le début du projet. Dans la pratique, cette fenêtre de découverte initiale s'avère souvent trop courte pour permettre aux utilisateurs d'avoir un aperçu de toutes les options d'utilisation des applications Fiori. Le principe "Insight to Action" permet par exemple de naviguer d'une page d'aperçu jusqu'au niveau du document. Par exemple, à partir d'une représentation graphique du chiffre d'affaires des achats, il est possible de déterminer les postes de documents pertinents en utilisant des filtres, puis de les traiter directement à partir de l'application. Il en résulte d'autres possibilités d'organiser les processus de travail. Au fur et à mesure de la compréhension du fonctionnement, les utilisateurs trouvent ainsi d'autres options d'optimisation des processus, qui devraient ensuite être mises en œuvre.

Pour les responsables de projet SAP, cela signifie d'une part : Les "launchpads" Fiori doivent être adaptés de manière itérative tout au long du projet, jusque dans la phase de réalisation. D'autre part, les modifications des processus impliquent également des adaptations des rôles et des autorisations. Cela signifie que le travail sur les rôles des utilisateurs et les autorisations s'étend sur toute la transition ERP en tant que sous-projet transversal. 

La gestion des rôles et des autorisations des utilisateurs lors du passage à S/4 nécessite donc une réflexion stratégique et des ressources adéquates tout au long du projet. Les automatismes sont utiles et doivent bien entendu être utilisés, mais des tests approfondis restent obligatoires. Les autorisations devraient donc être testées lors de tous les tests d'intégration. Pour ne pas être sous pression vers la fin du projet, les responsables de projet prévoient dès le début les ressources en personnel et en temps nécessaires à cet effet. L'expérience montre que la recherche d'erreurs lors des tests est difficile si une documentation détaillée n'a pas été établie dès le début. FIS a développé un modèle de documentation correspondant. Le surcroît de travail lié à la documentation est dans tous les cas rentabilisé lors des phases de test.