Évaluation des risques d'un projet SAP : la version pratique

Une évaluation des risques d'un projet SAP recense ce qui pourrait faire dérailler le programme et note chaque risque selon sa probabilité et son impact. Chaque risque reçoit un responsable nommé et une réponse convenue avant qu'il ne se produise, et la liste est revue chaque semaine. Les risques qui font couler les programmes SAP sont rarement des surprises : migration des données, intégration, disponibilité des personnes, dérive du périmètre et adoption. Ce guide s'adresse aux chefs de programme et aux sponsors qui veulent un registre des risques qui change des décisions, et non un registre qui dort dans un dossier. Il vous donne une matrice chiffrée, un modèle de registre, trois échecs publics comme cas d'école, et les risques qu'ajoutent RISE with SAP et le Clean Core. Commencez par attribuer un responsable nommé à chacun des risques que vous avez déjà.

La plupart des évaluations des risques SAP sont construites avant le premier comité de pilotage, relues une fois, puis plus jamais touchées. Ce n'est pas de la gestion des risques. C'est un document.

J'ai vu des risques ignorés parce qu'il était trop inconfortable de les soulever tôt. Ce silence coûte presque toujours plus cher ensuite. Ce qui commence comme un petit problème d'intégration dans Materials Management finit par bloquer la finance. Un rapport qui semblait correct en test casse après une mise à jour du système. Je l'ai vu arriver plus d'une fois.

Les risques n'étaient pas des surprises. Ils étaient documentés. Personne n'a agi.

Périmètre. Le projet démarre avec des modules standard. Puis quelqu'un ajoute « juste un rapport de plus », puis un tableau de bord, puis quelques développements. Le danger, ce sont les changements de périmètre introduits de façon informelle dans les ateliers, les e-mails et les conversations de couloir, dont le chef de projet n'entend parler qu'après la fin du paramétrage. Mon guide pour éviter la dérive du périmètre présente les contrôles.

Ressources. L'architecte est happé par un incident de production. Un développeur clé part. Les utilisateurs métier manquent des cycles de test parce que leur travail quotidien ne s'arrête pas. Obtenez les disponibilités par écrit. Les promesses verbales s'évaporent sous la pression sur les effectifs.

Technique. Des correspondances de champs jamais validées par rapport à la structure cible. Des interfaces qui passent les tests unitaires et cassent au volume réel de transactions. Du code spécifique qui paraît correct jusqu'à la charge de production. Tout cela est prévisible si l'on sait où regarder.

Calendrier. Un blueprint tardif comprime les tests, mais la date du go-live reste fixe. L'UAT, la formation et la préparation des données sont bâclées. On retrouve le même schéma sur presque tous les programmes qui ratent un point de contrôle de phase sans décaler le plan en aval.

Adoption. Les gens rejettent ce qu'ils ne comprennent pas. Une formation faible ou tardive produit des contournements, les contournements dégradent les données, et l'on reproche au système ce qui est un échec de la conduite du changement.

Ces cas sont publics et bien documentés. Les schémas se répètent à toutes les échelles.

Lidl : environ 500 millions d'euros en sept ans

Lidl a lancé son projet eLWIS sur SAP for Retail en 2011, est passé en production dans quelques petits pays, puis l'a abandonné en 2018 pour un coût rapporté d'environ 500 millions d'euros. Une cause largement rapportée : Lidl valorisait ses stocks au prix d'achat, alors que le modèle standard de SAP pour le commerce de détail utilise les prix de vente. Lidl a préféré personnaliser plutôt que de changer sa pratique, et l'entreprise a déclaré que les objectifs initiaux ne pouvaient pas être atteints avec un effort raisonnable.

Leçon : un décalage entre votre modèle de données et le standard SAP est un risque de la première semaine, pas une découverte de la cinquième année.

HP : environ 400 millions de dollars de chiffre d'affaires perdu

En 2004, HP a migré une partie de son activité serveurs vers un système consolidé de commandes et de chaîne logistique reposant sur SAP. Des commandes sont sorties du flux entre l'ancien frontal et SAP et ont exigé un traitement manuel, et l'arriéré de commandes a doublé. Le PDG de HP a déclaré que ces problèmes avaient coûté au groupe serveurs et stockage environ 400 millions de dollars de chiffre d'affaires et 275 millions de dollars de résultat d'exploitation, laissant un arriéré de 120 millions de dollars. Le DSI de HP a dit plus tard que l'équipe avait prévu trois semaines de perturbation et aurait dû prévoir une marge de quatre à six semaines.

Leçon : dimensionnez la marge pour une mauvaise bascule, pas pour une bascule moyenne, et constituez des stocks ou des tampons de canal avant de basculer.

Nike : plus de 100 millions de dollars de ventes perdues

En 2000, Nike a mis en production le logiciel de planification de la demande d'i2 avant son programme ERP SAP. Le logiciel avait été fortement personnalisé pour fonctionner avec les systèmes existants de Nike, il tournait lentement et plantait face au volume de produits. Il a commandé trop de certaines chaussures et pas assez d'autres. Nike a perdu plus de 100 millions de dollars de ventes et son action a chuté d'environ 20 %. Nike a ensuite transféré dans SAP la planification à court et moyen terme.

Leçon : ne supposez jamais qu'une intégration fonctionne tant qu'elle n'a pas tourné au volume de production avec des données réelles.

Une évaluation construite sur des hypothèses est pire que pas d'évaluation, car elle crée une fausse confiance. Six éléments comptent :

1. Documentation du périmètre : charte, périmètre approuvé et exigences signées. S'ils n'existent pas, le risque de périmètre est déjà élevé.
2. Engagements de ressources : engagements écrits des directeurs de service, matrice de compétences pour les rôles critiques et suppléant nommé pour chaque poste clé.
3. Budget et calendrier : budget approuvé avec marge pour aléas, et calendrier confronté à des programmes comparables. Six mois et un financement minimal pour un déploiement complet, c'est un risque à signaler dès maintenant.
4. Engagements des fournisseurs : contrats avec niveaux de service et pénalités. Avec RISE, les responsabilités de SAP et la voie d'escalade.
5. Paysage technique : compatibilité avec l'existant, complexité de la migration des données, modèle de déploiement et plan Clean Core pour tout développement spécifique.
6. Historiques de projets passés : registres des risques, journaux d'incidents et retours d'expérience de programmes SAP ou ERP antérieurs. La plupart des risques ne sont pas nouveaux.

Notez chaque risque de 1 à 5 en probabilité et en impact, puis multipliez. L'exemple ci-dessous est un point de départ typique pour un programme S/4HANA ; vos notes seront différentes.

Risque	Probabilité (1-5)	Impact (1-5)	Note	Priorité
Échec de la migration des données	4	5	20	Élevée
Retards d'intégration	4	4	16	Élevée
Contraintes de ressources	4	4	16	Élevée
Dépassement de budget	3	5	15	Moyenne
Code spécifique dans le noyau bloquant les mises à niveau	3	5	15	Moyenne
Dérive du périmètre	4	3	12	Moyenne
Lacunes de couverture des tests	3	4	12	Moyenne
Performance en pointe de charge	3	4	12	Moyenne
Lacunes de conformité	2	5	10	Moyenne
Pas de voie d'escalade vers SAP (RISE)	2	5	10	Moyenne
Faible adoption par les utilisateurs	3	3	9	Moyenne
Exposition aux coûts d'abonnement ou de licence	2	4	8	Moyenne
KPI non suivis	3	2	6	Faible

Les notes de 16 et plus exigent un responsable nommé et une action immédiate. Les notes de 8 à 15 exigent un suivi avec un seuil d'escalade défini. En dessous de 8, gardez le risque au registre sans y consacrer de temps prioritaire. Les notes sont un point de départ, pas un verdict : une lacune de conformité notée 10 peut passer à 25 dans un secteur réglementé.

Une note seule ne change rien. Chaque risque a besoin de ces champs, renseignés.

Champ	Ce qu'il faut écrire	Exemple
Risque	L'événement, en une phrase	Les données de base fournisseur ne sont pas nettoyées avant la migration à blanc 2
Responsable	Une personne nommée	Responsable des comptes fournisseurs
Note	Probabilité × impact	4 × 5 = 20
Déclencheur	Le seuil mesurable à partir duquel vous agissez	Taux de doublons supérieur à 5 % dans l'extraction de la migration à blanc 1
Réponse	Éviter, atténuer, transférer ou accepter, avec l'action	Atténuer : deux analystes comptes fournisseurs sur le nettoyage pendant trois semaines
Prochaine revue	Date	Revue des risques de lundi prochain
Statut	Ouvert, en cours d'action, clos	En cours d'action

Exprimez le coût en termes concrets quand vous le pouvez. « Risque élevé » est vague. « Un retard d'une semaine sur l'UAT coûte un montant à six chiffres en temps d'équipe et peut repousser le go-live de trois semaines » attire l'attention.

Le code spécifique est une catégorie de risque à part entière. Sur S/4HANA Cloud Public Edition, le code spécifique dans le noyau n'est pas possible. Les extensions passent par SAP BTP, des API publiées ou des outils key user. En cloud privé et sur site, on peut encore modifier le noyau, et les partenaires habitués à le faire le feront. Cette dette technique refait surface à la première mise à niveau majeure. Suivez combien de personnalisations identifiées ont une approche Clean Core convenue, vérifiez l'expérience du partenaire en extensions BTP, et mettez en place une instance de revue d'ici la fin d'Explore.

RISE change qui est responsable de la disponibilité. SAP exploite l'infrastructure ; le risque passe donc de « notre équipe est responsable de la disponibilité » à « SAP en est responsable et il nous faut un accès rapide quand quelque chose tombe en panne ». Consignez les contacts nommés chez SAP, la voie d'escalade et les niveaux de service, ainsi qu'un plan d'incident convenu avant le go-live. Sans eux, des problèmes qui devraient aller chez SAP restent trop longtemps dans l'équipe projet.

L'IA aide pour la paperasse, pas pour le jugement. Les assistants basés sur Joule dans SAP Cloud ALM et des outils comme Microsoft Copilot peuvent rédiger des entrées de registre et des dossiers de comité de pilotage à partir de rapports d'avancement, de journaux d'anomalies et de comptes rendus. Cela accélère la tenue du registre sur les programmes dont les données sources sont propres. L'IA repère les risques déjà visibles dans les données. Elle ne décide pas quels risques méritent une action, ne pousse pas les responsables à agir et n'escalade pas les risques que la direction préférerait ignorer.

1. Identifiez les risques dans les cinq catégories. Animez des ateliers avec l'IT, le métier et les fournisseurs ; chacun voit des risques différents. Avec RISE, associez les contacts SAP à au moins un atelier. Les risques que les équipes oublient le plus souvent : l'IT et le métier qui n'attendent pas la même chose, des intégrations externes mal définies, des responsables UAT indisponibles et des changements de périmètre informels.
2. Notez chaque risque en probabilité et en impact, avec des chiffres réels quand c'est possible.
3. Attribuez un responsable par risque. Une personne, pas une équipe. Pas de responsable, pas de suivi, pas de résolution.
4. Définissez la réponse avant que le risque se réalise. Éviter, atténuer, transférer ou accepter. « Surveiller et réagir » n'est pas un plan. C'est une décision différée.
5. Revoyez chaque semaine. Passez en revue les risques ouverts, ajoutez-en de nouveaux, renotez ceux dont les conditions ont changé et escaladez tout ce qui approche de son seuil. Portez les principaux risques au comité de pilotage avec une proposition de décision plutôt qu'une couleur.

1. 01IdentifierLes cinq catégories
2. 02NoterProbabilité × impact, de 1 à 5
3. 03Désigner un responsableUne personne, pas une équipe
4. 04Définir la réponseÉviter, atténuer, transférer ou accepter
5. 05Revoir chaque semaineRenoter, escalader près des seuils

16 ou plus : un responsable nommé et une action cette semaine

Qu'est-ce qu'une évaluation des risques dans un projet SAP ?

C'est le processus qui consiste à identifier ce qui pourrait mal tourner, à noter chaque risque selon sa probabilité et son impact, à donner un responsable à chacun et à convenir d'une réponse avant qu'il ne se produise. Les programmes SAP mènent de front plusieurs modules, des intégrations, une migration des données, un programme de conduite du changement et un go-live à date fixe ; une gestion des risques informelle ne tient donc pas. Une courte liste de vrais risques avec des responsables vaut mieux qu'un long document que personne ne lit.

Comment construire une matrice des risques pour un projet SAP ?

Listez les risques de périmètre, de ressources, techniques, de calendrier et d'adoption, auxquels s'ajoutent le Clean Core et l'escalade vers SAP avec RISE. Notez chacun de 1 à 5 en probabilité et en impact, puis multipliez. Considérez 16 et plus comme élevé, 8 à 15 comme moyen et moins de 8 comme faible. Donnez à chaque risque moyen ou élevé un responsable et un seuil mesurable, par exemple « si l'avancement de l'UAT est inférieur à 80 % à la semaine 16, la date du go-live passe en revue ». Renotez chaque semaine et à chaque point de contrôle de phase.

Quels sont les risques les plus courants dans les mises en œuvre SAP ?

L'échec de la migration des données, parce que les données issues des systèmes existants sont presque toujours plus désordonnées qu'estimé. Les retards d'intégration, surtout avec des interfaces existantes non documentées et des fournisseurs tiers. La dérive du périmètre, qui comprime les tests et la formation. Les contraintes de ressources, comme des personnes clés détournées ou des utilisateurs indisponibles pendant l'UAT en fin de mois. Une faible adoption due à une formation qui montre des écrans au lieu de simuler le travail réel. Avec RISE, ajoutez le code spécifique dans le noyau et l'absence de voie d'escalade vers SAP.

Quand faut-il faire une évaluation des risques pendant un projet SAP ?

Avant le démarrage du projet, quand les risques structurels, comme les écarts de modèle de données ou les calendriers irréalistes, sont les moins chers à corriger. Avant chaque point de contrôle de phase SAP Activate, car chaque phase modifie le profil de risque. Chaque fois que le périmètre, le budget ou les ressources changent. Et quand un risque devient un problème, pour vérifier ce qu'il touche d'autre. Entre-temps, revoyez les risques chaque semaine.

Qui doit être responsable des risques dans un programme SAP ?

La personne qui peut agir dessus. Le responsable des données porte le risque de migration des données, l'architecte technique celui de l'intégration, le responsable du changement celui de l'adoption et l'architecte de solution celui du Clean Core. Avec RISE, le DSI ou le directeur de programme est responsable de la voie d'escalade vers SAP. Le chef de programme suit la santé du registre, mais n'est pas responsable de chaque risque.

Que se passe-t-il quand l'évaluation des risques ERP est négligée ?

À grande échelle, on obtient des cas comme Lidl, qui a abandonné son projet SAP pour le commerce de détail en 2018 après environ 500 millions d'euros. Ou HP, dont la migration de 2004 vers un système de commandes SAP a coûté à son groupe serveurs environ 400 millions de dollars de chiffre d'affaires. À plus petite échelle, le mécanisme est le même : des écarts de modèle de données découverts tard, des intégrations qui échouent au volume de production et des échecs d'adoption dus à une formation insuffisante. Les risques étaient identifiables avant de devenir des problèmes.