SAP Fiori est activé chez vous, et personne ne l'utilise. Voici pourquoi.
- STMS
- il y a 2 jours
- 4 min de lecture
Vos tuiles sont déployées. Vos utilisateurs, eux, sont retournés sur le SAP GUI. Ce n'est pas un problème d'interface, c'est un problème de méthode.
Le scénario est presque toujours le même. Le projet a été mené correctement : le socle Fiori est activé, les catalogues sont en place, le Launchpad répond. Techniquement, tout fonctionne.
Trois semaines plus tard, les équipes ont rouvert le SAP GUI. Les tuiles sont là, mais elles sont désertes. Et dans les comités qui suivent, une phrase revient, en général sur un ton résigné : « on a déjà essayé, ça n'a pas pris ».
C'est l'un des irritants les plus fréquents que nous rencontrons sur le terrain, et probablement le plus coûteux, parce qu'il ne se contente pas de bloquer un projet. Il grille le sujet en interne pour plusieurs années.
Activer SAP Fiori et faire adopter SAP Fiori sont deux projets différents
L'erreur d'origine tient en une confusion, et elle est très largement partagée : on traite la Fiorisation comme un chantier d'infrastructure. On active, on ouvre les droits, on communique, et on considère que le travail est fait.
Sauf que l'activation ne produit aucun usage. Elle produit une possibilité d'usage. Entre les deux, il y a tout ce qui décide réellement de l'adoption :
est-ce que l'utilisateur retrouve ses gestes quotidiens ?
est-ce que son launchpad correspond à son rôle, ou est-ce qu'il doit chercher ?
est-ce que ce qu'il gagne compense l'effort de changer d'habitude ?
Un utilisateur SAP expérimenté est rapide sur le GUI. Il connaît ses codes transaction, il navigue en aveugle. Lui proposer une interface plus moderne ne suffit pas : vous lui demandez de redevenir lent pendant quelques jours. S'il ne voit pas ce qu'il gagne au bout, il revient à ce qu'il maîtrise.
C'est un arbitrage rationnel de sa part, pas une résistance au changement.
Le catalogue standard n'est pas un point de départ
Deuxième cause, plus structurelle : la paralysie face au catalogue.
Le catalogue SAP Fiori standard compte des milliers d'applications. Confrontée à cette masse, une DSI n'a aucun critère objectif pour trancher. Alors elle procède par intuition, par domaine fonctionnel, ou en activant large pour ne rien manquer.
Dans les trois cas, le résultat est le même : des launchpads chargés, dans lesquels l'utilisateur ne trouve pas ce qu'il cherche.
Le catalogue est un aboutissement, pas une entrée en matière. Il répond à la question « qu'est-ce qui existe ? ».
Alors que la seule question qui compte au démarrage est : « qu'est-ce que mes équipes font réellement, tous les jours ? ».
Partir de l'usage réel, pas de l'offre disponible
Le principe de Pareto s'applique remarquablement bien à SAP.
Dans la plupart des systèmes que nous analysons, une part très minoritaire des transactions concentre l'essentiel de l'usage effectif.
Quelques dizaines de transactions portent le quotidien de l'entreprise. Le reste est occasionnel, saisonnier, ou dormant depuis des années.
Cette information existe déjà. Elle est dans vos données système, et personne ne la regarde avant de lancer une Fiorisation.
C'est pourtant elle qui répond aux trois questions qui déterminent la suite :
Quelles transactions sont réellement utilisées, à quelle fréquence, et par combien de personnes. Les standards comme les spécifiques.
Quelles populations métier sont les meilleures candidates. Toutes ne se valent pas. Certaines ont des usages intensifs, répétitifs, bien couverts par le standard SAP Fiori. D'autres travaillent sur des processus lourdement spécifiques, où le gain sera faible et l'effort important.
Quelle est la couverture Fiori réelle de vos usages. Combien de vos transactions critiques ont un équivalent standard, et lesquelles n'en ont pas.
À partir de là, vous ne choisissez plus des tuiles.
Vous construisez des launchpads alignés sur des rôles métier, épurés, limités à ce dont chaque population a besoin. C'est cette épuration qui fait basculer l'adoption.
Valider le standard avant de payer la personnalisation
Le dernier réflexe à corriger concerne l'ordre des dépenses.
Beaucoup de projets engagent le budget de personnalisation dès le départ, sur la base de besoins exprimés en atelier. C'est prendre un risque important : vous financez de l'adaptation avant d'avoir la moindre preuve que le standard ne suffisait pas.
L'ordre inverse est plus sûr. Vous déployez d'abord le standard sur une population pilote restreinte et motivée. Vous observez l'usage réel, vous mesurez l'effort d'appropriation, vous collectez les retours. Et vous ne décidez d'engager la personnalisation qu'ensuite, sur la base de ce qui a été constaté, lors d'un point de décision formel.
Ce séquencement a un effet secondaire utile : il vous donne, avant tout investissement lourd, un argument démontré à présenter à votre direction. Pas une promesse d'éditeur, un résultat mesuré chez vous.
Pourquoi le sujet ne peut plus attendre
Il y a une raison conjoncturelle de ne pas laisser le dossier de côté après une première tentative ratée.
Les innovations SAP n'arrivent plus sur le GUI. Elles arrivent sur SAP Fiori, et cela vaut en particulier pour SAP Joule, l'assistant IA de SAP, qui s'appuie sur le socle SAP Fiori. Chaque année passée sur l'interface historique creuse un écart qu'il faudra combler d'un coup, dans des conditions moins confortables.
La dette d'interface ressemble à la dette technique : indolore tant qu'on ne s'en occupe pas, brutale au moment où une échéance la rend obligatoire.
Par où commencer concrètement
Si vous vous reconnaissez dans le scénario du début, la bonne première étape n'est ni un atelier de cadrage, ni un choix de tuiles. C'est un état des lieux factuel de l'usage de votre système : quelles transactions, par qui, à quelle fréquence, et avec quelle couverture SAP Fiori en face.
Cet état des lieux se construit à partir de vos données système, il est rapide à produire, et il transforme un débat d'opinions en décision documentée. C'est le point de départ de la méthode que nous appliquons chez nos clients.
Nous détaillons la méthode complète en direct
Marina Grimaud, responsable de l'offre SAP Fiori chez STMS, et Patrick Perisser présentent la démarche de bout en bout lors d'un webinaire : de la phase pilote à l'industrialisation par vagues, jusqu'au transfert complet de la compétence à vos équipes internes.
Vous y verrez également une démonstration du compte rendu d'usages que nous produisons à partir de données système réelles, avec la lecture qu'on en tire pour prioriser.
💡Un replay est envoyé aux inscrits qui ne peuvent pas être présents.
