Gestion des parties prenantes SAP : stopper les conflits avant qu'ils naissent

La gestion des parties prenantes SAP décide si un programme se termine à l'heure ou passe son dernier trimestre à se disputer. Elle tient en quatre habitudes. Cartographier qui compte et ce qui préoccupe chaque groupe. Écrire qui a l'autorité de décider quoi. Installer un rythme de communication adapté à la phase SAP Activate. Consigner chaque décision importante avec ses alternatives. Ce guide s'adresse aux directeurs de programme, aux PMO et aux sponsors des programmes S/4HANA. Servez-vous du tableau des rôles et du rythme phase par phase ci-dessous pour bâtir votre plan d'engagement avant le premier atelier.

J'ai travaillé sur un déploiement SAP où la DSI voulait des contrôles stricts sur le système et où la Finance avait besoin de plus de souplesse. Quand nous sommes arrivés, les deux équipes ne se parlaient plus. La Finance était frustrée. La DSI se braquait. La direction voulait savoir pourquoi personne ne communiquait.

Nous avons construit une cartographie des rôles, tenu des réunions d'alignement régulières et créé une source unique de vérité pour les décisions. Si ce travail de fond avait été fait dès le départ, nous aurions économisé des mois de disputes.

Ce schéma vaut bien au-delà de ce programme. La technologie échoue rarement seule. Les programmes échouent quand les décisions ne sont pas prises et que les attentes n'ont jamais été posées. Ils échouent quand la communication repose sur des relations personnelles plutôt que sur un rythme établi, et quand des conflits qui relevaient du niveau opérationnel arrivent à la direction avec des semaines de retard.

Tout le monde, dans un programme SAP, n'a pas les mêmes préoccupations ni la même influence. Si vous les traitez comme un seul public, vous envoyez des informations hors sujet et vous passez à côté des vrais risques.

Rôle	Ce qui compte pour eux	Comment les mobiliser
Sponsor exécutif (PDG, directeur des opérations, directeur financier du groupe)	Retour sur investissement, risque métier, crédibilité du programme	Direct, régulier, bref
Comité de pilotage (DSI, DAF, directeurs d'unités opérationnelles)	Calendrier, budget, périmètre	Revues de pilotage structurées, avec des décisions à la clé
Direction financière (DAF, contrôleurs de gestion)	Comptabilisation du chiffre d'affaires, fiabilité du reporting, contrôles	Implication précoce dans la conception ; validation du périmètre FI/CO
Responsables des opérations et du métier	Continuité des processus, formation, facilité d'usage	Ateliers de conception ; propriété des tests d'acceptation utilisateur (UAT)
Direction informatique (DSI, responsable de l'architecture)	Architecture, sécurité, intégration, support	Validation de la conception technique
Propriétaires de processus métier	Exactitude des processus, exceptions, cas limites	Animent les ateliers de conception ; valident le paramétrage
Utilisateurs finaux	Courbe d'apprentissage, travail au quotidien, évolution des postes	Formation et conduite du changement
Intégrateur système (SI)	Périmètre de livraison, demandes de changement, ressources	Gouvernance formelle et documents de périmètre
RH et conduite du changement	Impact sur les personnes, changements de rôles, communication	Un chantier parallèle à la livraison

La matrice pouvoir-intérêt indique où concentrer l'effort. Le DSI, le DAF et le sponsor sont haut placés sur les deux axes : ils approuvent les changements, repoussent le go-live et allouent les équipes, et s'ils se désengagent, le programme perd sa couverture. Les propriétaires de processus, les contrôleurs et les architectes ont un fort intérêt et moins de pouvoir formel, mais leur connaissance du fonctionnement réel de l'entreprise les rend indispensables à la conception. Les membres du conseil d'administration et les dirigeants extérieurs au programme ont besoin de points d'étape à chaque jalon, pas de mises à jour hebdomadaires. Les utilisateurs finaux ont peu d'influence et la plus forte exposition : leur adhésion au go-live décide si le système fonctionne en pratique.

Influence sur le résultatÉlevéMoyenFaible

• Conseil d'administration, dirigeants extérieurs

• Sponsor, DAF, DSI

• Propriétaires de processus
• Contrôleurs, architectes

• Utilisateurs finaux

FaibleMoyenÉlevéImpact du programme sur eux

L'engagement le plus efficace a lieu avant que quiconque se plaigne. Verrouillez trois choses au lancement.

Droits de décision

Qui peut approuver une modification de périmètre ? Qui valide l'UAT ? Qui peut porter un report de go-live devant le comité de pilotage ? Écrivez-le, faites-le signer et mettez-le dans la charte du projet. Quand une décision est contestée en cours de route, c'est ce document que vous brandissez.

Sans lui, les décisions contestées reviennent à celui qui crie le plus fort ou qui a l'oreille du sponsor. Ni l'un ni l'autre n'est de la gouvernance, et les deux nourrissent le ressentiment. Mon guide pour rédiger une charte de projet SAP détaille ce que la section sur les droits de décision doit contenir.

Rythme de communication

Décidez dès le lancement à quelle fréquence le programme communique, par quel canal et avec quel contenu. Comité de pilotage toutes les deux semaines. Responsables de chantier chaque semaine. Utilisateurs finaux aux jalons, avec des rappels sur la formation. Si les gens n'entendent parler du programme que lorsque quelque chose va mal, ils en concluront qu'il est toujours en difficulté.

Périmètre de référence

Écrivez ce qui est dans le périmètre et ce qui en est explicitement exclu. Les exclusions comptent autant que les inclusions, car chaque frontière non définie est un futur conflit. Prenez un responsable financier qui croit que la gestion des notes de frais est incluse et découvre en Realize qu'elle ne l'est pas. Cette personne sera difficile pendant tout le reste du programme, non parce qu'elle l'est par nature, mais parce que le programme a rompu une promesse implicite.

Les besoins d'engagement changent à mesure que le programme traverse les phases de SAP Activate. Ce qui marche en Explore ne marche pas en Deploy. Prenez ce tableau comme colonne vertébrale de votre plan d'engagement :

Phase	Axe d'engagement	Rythme	Qui pilote
Discover et Prepare	Cartographie des rôles, structure de gouvernance, briefings du sponsor, premières séances d'alignement avec la Finance, les Opérations et la DSI	Briefing du sponsor au démarrage ; comité de pilotage mis en place	Directeur de programme
Explore	Ateliers Fit-to-Standard avec les responsables métier et les propriétaires de processus ; décisions sur les écarts (fit-gap) revues avant validation	Séances de travail hebdomadaires ; comité de pilotage à la clôture de la phase	Architecte de solution et propriétaires de processus
Realize	Préparation de l'UAT ; temps des responsables métier protégé pour les tests ; suivi des anomalies et de la migration des données	Comité de pilotage tous les quinze jours ; responsables de chantier chaque semaine	Responsable de programme
Deploy	Préparation de la bascule, critères de go/no-go convenus avant le début de la bascule	Points quotidiens de bascule ; briefing exécutif go/no-go	Responsable des opérations métier, avec l'appui de la DSI et de l'intégrateur
Run	Communication d'hypercare, canaux de remontée des incidents, revues de stabilisation	Quotidien pendant deux semaines, puis hebdomadaire ; revues à 30, 60 et 90 jours	Responsable du support et propriétaires de processus

Deux phases posent l'essentiel des problèmes. En Explore, si les mauvaises personnes sont dans la salle, les décisions sont rouvertes en Realize, une fois le paramétrage lancé. En Realize, des responsables d'UAT indisponibles ou mal préparés sont un cas fréquent. Corrigez-le dans le plan pendant Explore, pas deux semaines avant le début des tests.

Le modèle traditionnel comptait trois parties : le client, l'intégrateur et les sponsors. Avec RISE with SAP, SAP rejoint la livraison en tant que participant. Il exploite l'infrastructure et les opérations techniques, et son équipe Customer Success suit l'adoption et la valeur. Trois changements de gouvernance en découlent.

1. Une instance de revue des extensions. Chaque écart appelle une décision : le paramétrer, l'étendre via des API publiées (on-stack avec ABAP Cloud ou side-by-side sur SAP BTP) ou le refuser. Sur S/4HANA Cloud Public Edition, la modification du standard est impossible. Sur Private Edition, elle l'est, mais chaque modification ajoute du travail à la mise à niveau. Une petite instance sous le comité de pilotage, avec un architecte habilité à trancher, évite que chaque débat sur les développements spécifiques atterrisse en comité de pilotage. Sans elle, la dette technique apparaît à la première mise à niveau majeure.
2. Un rythme Customer Success avec SAP. L'équipe de SAP intervient sur l'adoption, l'usage de BTP et la feuille de route. Ce rythme court en parallèle de la gouvernance de la mise en œuvre et se poursuit après le go-live. Intégrez-le à votre gouvernance plutôt que de le gérer à part.
3. Un circuit d'escalade vers SAP. Quand quelque chose tombe en panne au niveau de la plateforme, le DSI doit savoir qui appeler chez SAP, pas seulement chez le partenaire. Confirmez les contacts et les niveaux de service avant de signer.

Les programmes GROW with SAP en Public Edition demandent les mêmes trois éléments, en version allégée : moins de décisions d'extension puisqu'il y a moins de marge pour étendre, un rythme Customer Success plus standardisé et une escalade qui passe généralement d'abord par le partenaire. Les programmes sur site gardent le modèle traditionnel, avec SAP comme fournisseur et non comme participant.

Les outils d'IA aident pour la paperasse de l'engagement, pas pour les relations.

Les comptes rendus de réunion sont le gain le plus net. Microsoft Copilot transforme l'enregistrement d'un comité de pilotage en projet de compte rendu qui demande une courte relecture plutôt qu'une longue rédaction. Les décisions qu'il retient sont généralement justes, car il travaille à partir de la transcription et non de la mémoire.

Les journaux de décisions viennent en deuxième. Les fonctions d'IA de Confluence, désormais sous la marque Rovo d'Atlassian, peuvent transformer des notes de réunion en entrées structurées du journal de décisions une fois que vous avez construit un modèle.

La rédaction des exigences aide en Explore. SAP Cloud ALM peut rédiger des exigences à partir des transcriptions des ateliers Fit-to-Standard. Il faut quand même une personne pour valider chaque ligne.

L'analyse de sentiment est surtout du théâtre sur les programmes de moins de 100 personnes. Le signal est faible, les faux positifs sont fréquents, et être vu en train de surveiller le moral a un vrai coût politique. Sur de très grands programmes, elle peut repérer tôt des groupes qui se désengagent. Pour la plupart des programmes, dépensez le budget d'IA ailleurs.

La résistance à SAP a presque toujours une raison valable. La personne qui s'oppose protège généralement quelque chose : un contournement qui comble une lacune de l'ancien système, un contrôle manuel que le processus standard ne fait pas apparaître, ou l'inquiétude sur la capacité de son équipe à absorber le changement. Trouvez cette raison avant de réagir. Répondez à l'inquiétude de fond et la résistance disparaît généralement sans confrontation.

« Nous avons besoin de ce développement spécifique »

C'est généralement la protection d'un processus qui fonctionne aujourd'hui et que la personne ne croit pas que le standard SAP saura gérer. Parcourez le processus standard et demandez précisément où il échoue. Souvent, la crainte porte sur un cas limite que le paramétrage sait traiter. Parfois, elle est légitime. On ne le découvre qu'en ayant la conversation, et avec le clean core, l'enjeu est plus élevé, car la réponse décide si vous construisez et maintenez une extension.

« Nous ne sommes pas prêts pour le go-live »

Prenez cela au sérieux. Quand un responsable métier dit qu'il n'est pas prêt, il a généralement une raison : qualité des données, formation incomplète, processus non testé. Trouvez la crainte précise. Si elle est fondée, elle doit retarder le go-live. Si c'est de l'anxiété plutôt qu'un fait, répondez par une préparation ciblée, pas par une nouvelle date.

Le cas le plus courant : l'UAT a révélé des problèmes qui n'ont pas été corrigés. Foncer revient à déplacer le problème de l'UAT vers la production. Un report de deux semaines coûte généralement bien moins qu'une période d'hypercare passée à traiter des problèmes connus avant le go-live.

« Personne ne nous a parlé de ce changement »

C'est un échec de communication. La personne figurait sur la liste de diffusion mais n'était pas à la séance de conception, ou le changement dormait dans un document qu'elle n'a jamais lu. Ne discutez pas de qui a communiqué quoi. Excusez-vous, expliquez-lui le changement, ajoutez-la aux futures revues de conception dans son domaine et corrigez la faille dans le plan d'engagement.

Quand un conflit dépasse le niveau opérationnel, trois choses comptent.

Restez dans la gouvernance. Un différend entre la Finance et la DSI sur les accès au système a sa place en comité de pilotage, pas dans une résolution informelle par celui qui est le plus persévérant. Résoudre de façon informelle des conflits structurels crée du ressentiment et des décisions rouvertes.

Formulez-le en termes métier. La Finance et la DSI qui se disputent sur le contrôle des accès, c'est de la politique. La Finance et la DSI qui présentent le risque de sécurité face au coût opérationnel, c'est une décision métier, que le comité de pilotage peut prendre. Traduire l'un en l'autre est le travail du responsable de programme ou du responsable de l'intégrateur, selon le contrat.

Consignez chaque décision importante. Ce qui a été décidé, par qui, quand et quelles alternatives ont été examinées. Dans six mois, quelqu'un dira « nous n'avons jamais convenu de cela ». Quand le comité de pilotage demande pourquoi une configuration a été retenue, ou qu'un nouvel arrivant remet en cause une décision passée, il vous faut le registre, pas une reconstitution de mémoire. Un journal de décisions partagé, mis à jour chaque semaine et revu en comité de pilotage, ne coûte presque rien et fait économiser énormément.

Si la boîte mail du responsable de programme déborde d'escalades urgentes, le plan ne fonctionne pas. Les programmes sains tournent sur des décisions structurées, pas sur la gestion d'urgences au quotidien.

Signaux positifs : les comités de pilotage produisent des décisions plutôt que des reports ; les responsables métier assistent aux ateliers et à l'UAT sans qu'il faille les relancer ; les changements de périmètre passent par le processus de changement ; les problèmes après le go-live remontent par des canaux définis ; le journal des décisions est à jour et sert de référence en comité de pilotage.

Signaux d'alerte : des personnes contactent le responsable de programme en dehors de la structure de gouvernance ; des responsables métier approuvent des livrables sans les lire puis les contestent ; le sponsor disparaît entre deux comités de pilotage ; des personnes qui ont séché la conception contestent le gel des changements ; le même conflit apparaît à trois comités de pilotage de suite.

Quand des signaux d'alerte apparaissent, ne forcez pas davantage sur le plan existant. Déterminez quel élément défaille (rythme, autorité, communication ou documentation) et corrigez celui-là. Plus d'e-mails et plus de réunions aggravent les choses. Pour le comité de pilotage lui-même, voyez mon guide pour créer un comité de pilotage SAP efficace, et pour la dimension humaine du go-live, mes notes sur la conduite du changement SAP.

Qu'est-ce que la gestion des parties prenantes dans une mise en œuvre SAP ?

C'est le travail structuré qui consiste à identifier qui a de l'influence sur le programme ou de l'intérêt pour lui, à comprendre leurs préoccupations, à organiser la communication et la prise de décision, et à les garder mobilisés du lancement à l'hypercare.

SAP touche la Finance, les RH, les Achats, les Opérations et la DSI en même temps, et chacun a des priorités et une influence différentes. Les gérer comme un seul public produit des mises à jour génériques et fait passer à côté des préoccupations qui alimentent la résistance. SAP Activate l'intègre à chaque phase : les ateliers d'Explore, la responsabilité de l'UAT en Realize et les revues de préparation en Deploy reposent tous sur des participants métier préparés.

Comment construire une cartographie des rôles pour un projet SAP ?

Placez chaque personne ou groupe sur deux axes : l'influence sur le résultat et l'effet du programme sur eux. Le sponsor, le DAF et le DSI sont hauts sur les deux et demandent un contact direct et régulier. Les contrôleurs, les propriétaires de processus et les architectes ont un fort intérêt et doivent être présents dans la conception. Les dirigeants extérieurs au programme ont besoin de points d'étape à chaque jalon. Les utilisateurs finaux ont besoin d'une communication ciblée sur ce qui change pour eux, le moment de la formation et où trouver de l'aide.

Gardez la cartographie à jour. Les gens changent de poste, l'influence se déplace à mesure que le programme devient visible, et de nouveaux participants arrivent quand le périmètre s'étend.

Que doit contenir un plan d'engagement SAP ?

Un registre des rôles (nom, fonction, influence, intérêt, principales préoccupations), un plan de communication (canal, fréquence et contenu par groupe), des droits de décision pour les changements de périmètre, les décisions de conception et la préparation du go-live, des activités pour chaque phase Activate, un circuit d'escalade pour les décisions contestées et un moyen de soulever formellement des préoccupations.

Mettez-le à jour à chaque passage de phase. Documentez-le assez bien pour que l'équipe puisse le faire tourner sans que le responsable de programme gère chaque interaction en personne, car cela ne passe pas à l'échelle au-delà d'une trentaine de participants nommés.

Comment gérer la résistance à SAP de la part des responsables métier ?

Trouvez d'abord la source. Les plus courantes : la crainte que le nouveau processus ignore un cas limite important, la peur d'une perte de productivité et le sentiment d'être tenu à l'écart des décisions. Les préoccupations de processus relèvent d'une séance de conception. Les craintes de productivité demandent une formation réaliste et un support d'hypercare clair. L'exclusion est un échec de communication à corriger, pas à débattre.

La résistance sans fondement rationnel est plus difficile. Le levier est généralement le sponsor, qui doit rendre évident que le programme bénéficie de l'engagement de la direction. Forcer le passage sans traiter la résistance est la pire option : les préoccupations réapparaissent en UAT.

Comment gérer les conflits entre la Finance et la DSI dans un programme SAP ?

La plupart se ramènent à l'une de trois tensions : accès contre séparation des tâches, souplesse du reporting contre gouvernance des données, ou rythme d'intégration contre revue de sécurité.

Nommez précisément la tension. « La Finance veut que les contrôleurs aient un accès en lecture aux ordres de fabrication pour le reporting, et la DSI estime que cela brise la séparation des tâches » peut se résoudre ; « la Finance veut de la souplesse » non. Portez-le au comité de pilotage avec les options et leurs risques. Puis consignez la décision et les alternatives, car ces différends reviennent quand les gens changent. Si le comité de pilotage ne peut pas trancher, cela remonte au sponsor. C'est la gouvernance qui fonctionne comme prévu.

Comment RISE with SAP change-t-il la gestion des parties prenantes ?

SAP devient un participant et non plus seulement un fournisseur. Il vous faut une instance de revue des extensions pour décider comment chaque écart est traité sous clean core, une place dans votre gouvernance pour le rythme Customer Success de SAP, et un circuit d'escalade documenté vers SAP pour les problèmes de plateforme, qui ne dépende pas du partenaire. Confirmez les contacts d'escalade et les niveaux de service avant de signer.