Sept cadres de conseil pour vos projets SAP et IA

Quand un programme SAP ou IA cale, la cause est généralement structurelle, et sept cadres simples permettent de la trouver. Cartographiez l'existant. Convenez de qui décide de quoi avec un RACI. Reliez le travail aux capacités métier. Trouvez les causes racines avec les cinq pourquoi. Classez les exigences avec MoSCoW. Classez les risques selon ce qui peut réellement arrêter le programme. Menez un vrai post-mortem après chaque phase. Ce guide s'adresse aux chefs de programme, aux consultants et aux sponsors de projets SAP et IA. Commencez par le tableau ci-dessous : repérez votre symptôme et utilisez d'abord le cadre correspondant.

Une société de médias de taille intermédiaire au Qatar déployait SAP dans plusieurs régions. La finance et les achats passaient en production dès la première phase. Elle voulait aussi des modèles de prévision par IA dans son reporting.

À la semaine six, des retards s'installaient. Les utilisateurs métier disaient avoir validé les exigences mais restaient confus sur ce qu'ils allaient recevoir. Des cas d'usage d'IA avaient été proposés et personne ne pouvait dire à qui appartenaient les données ni comment le résultat serait utilisé. Les gens arrivaient en retard aux réunions, ou n'y venaient pas du tout.

C'était cette phase intermédiaire. Trop tôt pour parler d'échec. Trop tard pour faire semblant que cela allait s'arranger tout seul.

Nous avons appliqué les cadres pas à pas. Tout n'a pas été bien accueilli au début. Certaines séances ont été silencieuses. D'autres ont dérapé. Mais la structure a facilité le travail : l'équipe a cessé de tourner en rond, le backlog est devenu gérable et les cas d'usage d'IA ont obtenu de vrais responsables. Le projet est passé en production huit semaines plus tard que prévu. Pas parfait. Mais il a atterri, et la phase deux a démarré sur de meilleures bases, avec moins d'inconnues.

J'ai utilisé des versions de ces sept cadres pendant 23 ans de missions sur des programmes SAP, Oracle et IA dans le Golfe, en Europe et ailleurs. Aucun n'est exotique. Tous fonctionnent si vous les appliquez avec discipline plutôt que comme des exercices de documentation.

Associez le symptôme au cadre :

Symptôme observé	Cadre	Ce qu'il produit	Effort habituel
Les utilisateurs ont validé les exigences mais restent confus	1. Cartographie de l'existant	Une carte partagée de la façon dont le travail se fait réellement aujourd'hui	3 à 5 jours d'ateliers
Les décisions rebondissent d'une réunion à l'autre	2. RACI sur les décisions critiques	Des responsables nommés pour les 20 à 30 décisions clés	Un atelier, puis de l'application
Les sponsors se sont désengagés du « projet informatique »	3. Cartographie des capacités	Un avancement rapporté en capacités métier	Intégré au Fit-to-Standard
Le même type d'anomalie revient sans cesse	4. Les cinq pourquoi	Une cause racine sur laquelle agir	Une séance animée par problème
Tout est marqué haute priorité	5. MoSCoW	Un périmètre classé avec une liste Must Have réaliste	Une séance commune métier et IT
Le registre des risques a l'air correct mais l'équipe est tendue	6. Classement des risques	Des listes séparées pour les risques qui peuvent arrêter le programme et pour les risques gênants	Revue hebdomadaire de 30 minutes
Les mêmes erreurs se répètent de phase en phase	7. Post-mortem	Trois à cinq changements avec responsables	Une demi-journée après chaque phase

L'erreur la plus courante au démarrage d'un programme est de sauter à la solution avant d'avoir documenté ce qui existe. La documentation des processus est généralement périmée. Les gens décrivent comment les choses devraient fonctionner, pas comment elles fonctionnent. L'écart entre les deux, c'est là que vivent les problèmes d'implémentation.

Une bonne cartographie de l'existant demande de trois à cinq jours d'ateliers avec les personnes qui font le travail, pas celles qui les encadrent. Elle couvre les étapes du processus dans l'ordre, les systèmes utilisés à chaque étape, les interventions manuelles et les contournements, et les flux de données entre départements.

Cherchez les étapes manuelles que personne ne mentionne parce qu'elles sont devenues invisibles, les contournements en place depuis si longtemps qu'ils comptent désormais comme processus standard, et les problèmes de qualité des données que tout le monde connaît et que personne n'a corrigés.

Au Qatar, la cartographie de l'existant est venue d'ateliers avec les utilisateurs, pas de la documentation. C'est là que la confusion sur les exigences validées a commencé à se dissiper.

Bien faite, une cartographie de l'existant prend quelques jours. Traitée comme un exercice de collecte de documents, elle prend des mois et produit quelque chose en quoi personne n'a confiance.

Les droits de décision sont l'élément structurel le plus souvent absent des projets SAP et IA. Chacun a un avis. Personne ne sait qui tranche. Les décisions passent à la réunion suivante, qui s'en remet au comité de pilotage, qui les renvoie au groupe de travail.

Une matrice RACI (Réalisateur, Approbateur, Consulté, Informé) donne un responsable à chaque décision et à chaque livrable. Une seule personne est Approbateur ; elle peut aussi être Réalisateur ou déléguer la réalisation. Les personnes Consultées apportent leur avis. Les personnes Informées apprennent le résultat.

La version pratique : listez les vingt à trente décisions les plus critiques de la phase en cours et animez un atelier RACI avec les décideurs présents. Là où une attribution est contestée, vous avez appris quelque chose : soit la gouvernance est floue, soit il y a un conflit politique sur l'autorité. Dans les deux cas, faites-le apparaître en semaine deux, pas en semaine quatorze.

Un RACI sans application, c'est de la décoration. Les noms doivent correspondre aux personnes qui ont une réelle autorité. Attribuer la responsabilité finale à un intitulé de poste plutôt qu'à une personne nommée, c'est une façon d'éviter la conversation sur qui porte le risque.

Les programmes SAP et IA génèrent beaucoup d'activité technique que le métier ne voit pas. Le lien entre ce qui se construit et le résultat qu'il doit produire devient abstrait. Les sponsors se désengagent, et l'on reproche au « projet informatique » des retards qui sont en réalité des décisions métier.

La cartographie des capacités relie la fonction du système à une capacité métier : ce que l'organisation doit être capable de faire. Au lieu de suivre si le workflow des commandes d'achat est paramétré, vous suivez si l'organisation peut traiter les factures fournisseurs dans les trois jours suivant leur réception. Le paramétrage est le mécanisme. La capacité est le résultat.

Dans SAP Activate, cela correspond aux ateliers Fit-to-Standard de la phase Explore. Chaque processus du périmètre est une capacité, et chaque écart entre le standard SAP et la capacité requise est une décision : accepter le standard, paramétrer une variante ou étendre. Garder la conversation au niveau des capacités maintient l'attention du métier pendant la construction, et fait apparaître des capacités que tout le monde supposait dans le périmètre sans que personne ne l'ait confirmé.

Quand le même type de problème réapparaît sprint après sprint ou phase après phase, corriger chaque occurrence ne sert à rien. La cause se trouve en amont.

Les cinq pourquoi sont l'outil d'analyse de cause racine le plus simple. Demandez pourquoi le problème s'est produit, puis pourquoi cela s'est produit, jusqu'à atteindre quelque chose que vous pouvez changer. Cinq tours atteignent généralement la vraie cause. Deux tours s'arrêtent généralement au symptôme.

Un exemple de migration de données. Le chargement d'essai présente des erreurs de qualité des données : c'est le symptôme. Pourquoi ? L'extraction source avait de mauvaises correspondances de champs. Pourquoi ? La spécification de correspondance n'a jamais été relue par le propriétaire métier des données. Pourquoi ? Le propriétaire des données n'a été désigné qu'une fois les correspondances terminées. Pourquoi ? Le planning ne faisait pas de l'implication du propriétaire des données une dépendance des correspondances. Voilà la cause racine, et le correctif est une décision de gouvernance, pas une correction de données. Mon article sur les raisons de l'échec des migrations de données SAP montre à quelle fréquence cette chaîne exacte apparaît.

1. 01Erreurs au chargement d'essaiLe symptôme
2. 02Mauvaises correspondances de champsPourquoi le chargement a-t-il échoué ?
3. 03Spécification jamais reluePourquoi les correspondances étaient-elles fausses ?
4. 04Propriétaire nommé trop tardPourquoi la spécification n'a-t-elle pas été relue ?
5. 05Planning sans la dépendancePourquoi le propriétaire est-il arrivé tard ?

La cause racine est une décision de gouvernance, pas une correction de données

Une analyse de cause racine menée dans une salle sans recherche de coupable produit des réponses honnêtes. Menée dans une salle où l'on désigne des fautifs, elle produit de la défensive. Le rôle de l'animateur est de garder la conversation sur le processus, pas sur les personnes. Mon guide de la pensée structurée et de la résolution de problèmes explique comment décomposer un problème confus avant de commencer à demander pourquoi.

Toute discussion de périmètre SAP et IA a son piège du consensus. Personne ne veut arbitrer, alors tout devient haute priorité. Quand tout est haute priorité, plus rien ne l'est, et l'équipe de construction essaie de tout faire.

MoSCoW (Must have, Should have, Could have, Won't have, soit indispensable, important, souhaitable, exclu cette fois) force le choix. Le Must Have est le minimum nécessaire au go-live. Le Should Have est important mais non bloquant. Le Could Have est souhaitable si le temps et le budget le permettent. Le Won't Have est explicitement reporté.

Toute la discipline tient à la ligne du Must Have. Le premier passage d'un exercice MoSCoW met en général bien trop de choses en Must Have. Les recommandations DSDM de l'Agile Business Consortium, d'où vient MoSCoW, fixent un plafond de 60 % de l'effort pour les Must Have et préviennent qu'aller au-delà met la livraison en danger. L'écart entre le premier passage et une liste réaliste tient surtout à des hypothèses non testées.

Faites le MoSCoW avec le métier et la technologie dans la même salle. Séparément, la liste Must Have de l'IT et celle du métier se révèlent incompatibles, et personne ne les réconcilie avant que le paramétrage ait commencé.

La plupart des registres de risques sont de longues listes notées en probabilité et en impact, revues chaque mois, avec des statuts RAG (rouge, orange, vert) qui bougent rarement. Ils enregistrent le risque sans déclencher d'action.

Séparez les risques qui peuvent arrêter le programme de ceux qui le compliquent. Le premier groupe a besoin de responsables, de plans de réponse et d'une visibilité hebdomadaire. Le second a besoin d'être surveillé.

Au Qatar, le journal des risques avait l'air correct sur le papier, mais tout le monde se sentait sur les nerfs. Une matrice risque-impact rapide, revue chaque semaine plutôt que chaque mois, a fait émerger les vraies préoccupations.

Un registre qui a l'air correct pendant que l'équipe est tendue cache presque toujours quelque chose. Le registre n'est pas la vérité ; ce sont les conversations autour de lui. Une revue hebdomadaire qui demande « qu'est-ce qui vous a empêché de dormir hier soir ? » fait remonter plus de choses que « quel est le statut du point 14 ? ». Ma matrice d'évaluation des risques SAP propose un modèle pour la notation et l'attribution des responsables.

Les post-mortems après une phase ou un go-live empêchent les mêmes erreurs de se reproduire à la phase suivante. C'est aussi la première chose que l'on supprime quand le calendrier est sous pression.

Un bon post-mortem pose quatre questions. Qu'avions-nous prévu d'atteindre, et qu'avons-nous atteint ? Qu'est-ce qui s'est bien passé et mérite d'être répété ? Qu'est-ce qui s'est mal passé, et quelle en était la cause ? Que ferions-nous différemment ? Il doit se terminer par trois à cinq actions précises avec des responsables, pas par un document qui résume ce qui s'est passé.

L'échec habituel est un exercice de justification où les équipes défendent leurs décisions au lieu de les examiner. Gardez-le tourné vers l'avenir. La question n'est pas de savoir qui a causé les retards de la semaine six. C'est de savoir quel changement structurel les empêchera à la phase suivante.

Au Qatar, le post-mortem a eu lieu juste après le go-live et s'est concentré sur l'action, pas sur la faute. C'est en grande partie la raison pour laquelle la phase deux a démarré sur de meilleures bases.

Les cadres n'ont pas changé. La façon de les appliquer, si, de trois manières.

La rédaction est devenue plus rapide ; l'écoute, non. Les outils d'IA transforment désormais des transcriptions d'ateliers et des documents de processus en première carte en quelques minutes, et SAP Cloud ALM peut rédiger des exigences à partir de transcriptions d'ateliers Fit-to-Standard. Les ateliers eux-mêmes durent aussi longtemps qu'avant, parce que l'écoute est justement l'objectif. Le temps gagné sur la rédaction doit servir à confronter la carte avec les gens.

Les brouillons de RACI arrivent prêts, et le plus difficile reste entier. Un assistant d'IA généraliste produit un RACI à partir d'une charte et d'une liste de lots de travaux en une minute. La discipline se déplace vers la négociation : chaque cellule demande une vraie conversation sur l'autorité et l'escalade. Le temps gagné sur la construction du brouillon doit servir à ces conversations difficiles.

Le MoSCoW devient plus difficile quand l'IA est dans la salle. Un classement des exigences par l'IA est plausible, soigné et souvent faux sur la politique locale. Les consultants qui l'acceptent sans le challenger produisent de moins bonnes listes de priorités que ceux qui partent d'une feuille blanche. Considérez le brouillon de l'IA comme un point de départ, jamais comme la réponse.

Le jugement qui se superpose à ces cadres vaut plus aujourd'hui, pas moins. Si vous développez ces compétences en tant que consultant, les parcours de carrière de SAPopedia précisent lesquelles comptent à chaque étape d'une carrière SAP.

Que sont les cadres de conseil et pourquoi les projets SAP les utilisent-ils ?

Ce sont des approches structurées pour l'analyse, la décision et la résolution de problèmes. Sur les programmes SAP et IA, ils donnent une méthode commune aux responsables métier, architectes, chefs de projet, intégrateurs et sponsors.

Sans cadre, chaque groupe retombe sur son propre modèle mental : résultats des processus, architecture, ou calendrier et ressources. Des cadres comme la cartographie de l'existant, le RACI et MoSCoW rendent les désaccords explicites et résolubles. SAP Activate est lui-même un cadre de phases, de jalons de contrôle et de livrables ; ces sept cadres fonctionnent à l'intérieur et traitent les questions structurelles et humaines que la méthodologie seule ne résout pas.

Comment fonctionne la cartographie de l'existant dans une implémentation SAP ?

Elle documente comment les processus fonctionnent réellement avant le début du paramétrage, par opposition à ce que dit la documentation existante. Construisez-la en ateliers avec les personnes qui font tourner les processus : étapes, systèmes, passages de relais, interventions manuelles et contournements.

Elle alimente les ateliers Fit-to-Standard de la phase Explore de SAP Activate, où l'état actuel devient la référence comparée aux processus standard de SAP. Terminez-la avant le début de ces ateliers, sinon votre analyse d'écarts repose sur des hypothèses.

Qu'est-ce que la priorisation MoSCoW et quand l'utilise-t-on dans les programmes SAP ?

MoSCoW classe les exigences en Must have (indispensable), Should have (important), Could have (souhaitable) et Won't have (exclu cette fois). Les Must Have sont le minimum pour le go-live ; les Won't Have sont explicitement exclus afin de ne pas se glisser de nouveau dans le périmètre.

Il est surtout utile pendant Explore, quand les constats fit-gap pilotent les décisions d'extension, et pendant Realize, quand les anomalies et les évolutions se disputent le temps de construction. Le problème habituel est un trop grand nombre de Must Have au premier passage. DSDM recommande de ne pas consacrer plus de 60 % de l'effort aux Must Have ; un animateur qui challenge chacun d'eux, avec le métier et l'IT dans la même séance, vous y amène.

Comment mener une revue de risques efficace sur un projet SAP ?

Comme une conversation, pas comme un point de statut. Commencez par des questions ouvertes comme « Quelle est votre principale inquiétude cette semaine qui ne figure pas dans le registre ? » avant de parcourir le registre.

Pour chaque risque de haute priorité, demandez ce qui a changé, quelle action a été menée, si la tendance s'améliore et si le plan de réponse est toujours adapté. Les risques qui restent au même niveau pendant des semaines sans action sont souvent sous-estimés. Faites la revue chaque semaine pendant les phases actives, et montrez au comité de pilotage les cinq premiers avec leur statut et la prochaine action, pas le registre complet.

Qu'est-ce qui fait un post-mortem utile après un go-live SAP ?

Des changements précis et exploitables pour la phase suivante. Un résumé de ce qui s'est passé est un compte rendu, pas un post-mortem.

Couvrez ce que vous vouliez atteindre, ce que vous avez atteint, ce qui a marché et ce qui n'a pas marché. Allez au-delà des explications de surface comme « nous manquions de ressources » : le plan de ressources était-il faux, le périmètre faux, ou le circuit d'escalade rompu ? Terminez par trois à cinq changements, chacun avec un responsable et une date.

Comment les cadres de conseil aident-ils à mettre en œuvre l'IA dans les environnements SAP ?

Les projets d'IA échouent pour les mêmes raisons structurelles que les projets SAP, plus quelques-unes qui leur sont propres : des données sans propriétaire, des mesures de succès non définies et aucun processus convenu pour agir sur le résultat.

La cartographie de l'existant montre à qui appartiennent les données dont un modèle a besoin et quelle est leur qualité. Le RACI répond à qui valide le résultat, qui décide d'agir dessus et qui rend des comptes quand il est faux. MoSCoW sépare les cas d'usage essentiels de ceux qui sont simplement intéressants. Commencez par deux ou trois cas d'usage essentiels avec des responsables et des mesures de succès clairs, pas quinze d'un coup.