Redressement de projet SAP : sauver un programme qui dérape

Le redressement d'un projet SAP consiste à arrêter une migration ou une mise en œuvre qui dérape, à établir ce qui est vraiment vrai à son sujet et à replanifier à partir de cette vérité. La première semaine décide de la réussite : évaluer l'état d'avancement du programme, revoir la conception et évaluer ce qui est réellement déployé dans le système.

En bref : si ces trois vérifications concordent entre elles et avec le plan, le programme a besoin d'une relance, pas d'un sauvetage. Si elles divergent, aucun effort supplémentaire sur le plan actuel ne le réparera, et il vous faut un redressement formel avec une nouvelle référence.

Cet article porte sur ce diagnostic et sur ce qui le suit. C'est l'un des volets de mon guide de migration d'ECC vers S/4HANA, qui couvre les voies, les calendriers et les échéances. Ici, la question est plus étroite : votre programme est en difficulté, alors que faire maintenant ?

La plupart des programmes en retard n'ont pas besoin d'être sauvés. Ils ont besoin de décisions prises plus vite, d'un utilisateur clé libéré ou d'un prestataire tenu à une date. C'est une relance.

Un sauvetage, c'est autre chose. Les signes viennent des trois mêmes vérifications que je mène la première semaine, et le signal est simple : l'état d'avancement, la conception et ce qui est déployé ne concordent ni entre eux ni avec le plan.

Voici quelques situations que je traiterais comme des signaux de sauvetage :

1. L'avancement est au vert, le système ne l'est pas. Les rapports disent que l'essentiel de la réalisation est terminé, mais le système de test ne sait pas dérouler un order-to-cash de base.
2. La conception est signée, la réalisation l'ignore. Le paramétrage a été fait à partir de notes d'ateliers, pas à partir de la conception approuvée.
3. Le plan a une date de go-live, personne ne sait expliquer comment y arriver. Les tests, les chargements de données et les répétitions de bascule n'ont pas de créneau réaliste.
4. Le périmètre ne fait que grandir. La liste WRICEF (états, interfaces, conversions, extensions, formulaires et workflows) continue d'augmenter bien après la phase Explore.

Chacun de ces signaux peut se corriger par une relance. Deux ou plus en même temps, en général non.

La première semaine sert à établir ce qui est vrai. Pas à corriger, pas à chercher des coupables et pas à écrire un nouveau plan. J'évalue trois choses, dans cet ordre : l'avancement, la conception et ce qui est réellement déployé.

Voici ce que couvre chaque vérification et ce que révèle un désaccord :

Vérification	Ce que j'examine	La question à laquelle elle répond	Si elle contredit les autres
État d'avancement du programme	Plan, rapports d'avancement, registre RAID, demandes de changement ouvertes, dépenses par rapport au budget	Que croit le programme sur lui-même ?	Le reporting est optimiste ou déconnecté de la livraison
Conception	Conception des processus métier, livrables Fit-to-Standard, liste WRICEF, décisions de conception en suspens	Qu'a-t-on promis au métier ?	La réalisation s'est écartée de ce qui avait été convenu, ou la conception n'a jamais été terminée
Ce qui est déployé	Les systèmes de développement et de test, le paramétrage, les transports, le code spécifique, les chargements de données réalisés	Qu'est-ce qui existe réellement aujourd'hui ?	De l'avancement a été déclaré sur un travail qui n'est pas dans le système

La troisième vérification est celle que la plupart des revues sautent. Elle consiste à s'asseoir devant le système et à dérouler des processus, pas à lire des documents sur le système.

Les rapports d'avancement et les documents de conception sont des affirmations. Le système est une preuve.

Qui doit mener les vérifications

Les personnes qui ont rédigé les rapports d'avancement ne devraient pas être celles qui les vérifient. Ce n'est pas une accusation. C'est la même raison pour laquelle les auditeurs n'auditent pas leur propre travail.

Je confierais la première semaine à quelqu'un d'indépendant du partenaire de mise en œuvre, avec un accès complet aux systèmes et le droit de parler à n'importe qui sur le programme. Si ce n'est pas possible, exigez au moins que le partenaire vous montre le système déployé en direct plutôt que sur des diapositives.

En 2018, j'ai travaillé au redressement d'un programme dans l'aérien. Les modules avaient été déployés, mais rien n'avait été paramétré sur la base des exigences métier.

C'est exactement la situation que les trois vérifications de la première semaine servent à révéler. Des modules déployés ne sont pas une conception qui fonctionne, et seul un examen à l'intérieur du système montre la différence.

Les compagnies aériennes lient étroitement la maintenance, les achats et la finance : une lacune dans un domaine se propage donc. Je traite la façon dont SAP s'adapte à ce secteur dans ma page sur SAP pour l'aéronautique.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, la plus grande erreur que je vois est de ne pas planifier correctement au début de la mise en œuvre. Un sauvetage, c'est souvent cette planification manquante, faite tard et sous pression.

Deux autres causes reviennent sans cesse :

1. Le prestataire contrôle le périmètre. Quand l'intégrateur rédige le périmètre, celui-ci décrit ce que l'intégrateur prévoit de livrer. Les manques arrivent plus tard sous forme de demandes de changement, chiffrées par le même prestataire.
2. Le code spécifique dépasse. D'après mon expérience, le code spécifique est la phase de migration qui dépasse le plus souvent, et c'est aussi le coût caché le plus souvent oublié.

Le volet budgétaire, y compris la raison pour laquelle les coûts bondissent dans la phase Explore, est traité dans mon article sur pourquoi les projets SAP dépassent leur budget. Je ne le répéterai pas ici.

Un pilotage faible est l'autre fil conducteur fréquent. Si le programme n'a jamais eu de rythme hebdomadaire de suivi, d'escalade et de gestion des changements, le sauvetage doit en installer un. Mon guide sur la planification et le pilotage des projets SAP décrit cette cadence avec ses responsables.

Une fois que vous savez ce qui est vrai, le redressement suit une séquence claire. Sauter une étape signifie en général faire le sauvetage deux fois.

Séquence de redressement d'un programme SAP

1. 01

   Diagnostiquer

   Avancement, conception et ce qui est déployé, confrontés les uns aux autres.

2. 02

   Reprendre le périmètre

   Un périmètre détenu par le client, gelé, avec chaque changement chiffré.

3. 03

   Refixer la référence

   Un seul nouveau plan fondé sur des preuves, avec une réserve de votre côté.

4. 04

   Encadrer les phases

   Un quality gate à la fin de chaque phase restante.

5. 05

   Répéter et basculer

   Des répétitions complètes avant de confirmer une date de go-live.

1. Reprendre la maîtrise du périmètre

Avant que quiconque ne replanifie, décidez qui détient le périmètre. Si la réponse est toujours le prestataire, le nouveau plan échouera de la même façon que l'ancien.

Rédigez le périmètre côté client, comparez-le à ce qui est déployé et gelez-le. À partir de là, chaque changement est une décision chiffrée avec un responsable.

2. Refixer la référence une seule fois, sur des preuves

Un redressement a droit à une seule nouvelle référence, pas à une série de petits glissements. Construisez-la à partir de ce que montre le système, pas de ce qu'espérait l'ancien plan.

Réestimez d'abord le code spécifique, car c'est de là que viennent le plus souvent les dépassements. Puis les données, puisque la migration des données représente 30 à 40 % de l'effort et qu'elle est en général en retard dans un programme en difficulté.

Gardez 10 à 20 % de réserve de votre côté, débloquée uniquement face à des risques identifiés. Mon article voisin sur le coût d'une migration S/4HANA explique ce qui détermine les chiffres.

3. Placer un quality gate à la fin de chaque phase

Les programmes en difficulté sont en général passés d'une phase à l'autre sur des dates plutôt que sur des preuves. Corrigez cela.

Dans SAP Activate, la phase Explore déroule des ateliers Fit-to-Standard, et les exigences d'écart approuvées entrent dans le product backlog pour Realize. Si le programme a quitté Explore sans conception terminée, revenez en arrière et terminez-la. SAP Cloud ALM prend en charge des quality gates sous forme de points de contrôle avec des listes de vérification, affichés dans la vue d'ensemble du projet : le gate n'a donc pas à vivre dans un tableur.

4. Répéter avant de s'engager sur une date

Sur une conversion brownfield, je prévois trois conversions à blanc avant la bascule. Les programmes en difficulté réduisent souvent les répétitions pour gagner du temps, ce qui reporte le risque sur le week-end du go-live.

Les arrêts de bascule que j'ai vus vont d'un week-end à une semaine. Un programme redressé doit connaître son chiffre grâce à une répétition, pas grâce à une estimation.

5. Vérifier l'échéance à laquelle vous êtes vraiment soumis

Pour SAP ERP 6.0 sur les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027, avec une maintenance étendue optionnelle jusqu'à fin 2030 moyennant une majoration de deux points de pourcentage (SAP News). Un redressement qui repousse une migration ECC au-delà de 2027 doit budgéter ouvertement la maintenance étendue.

Ne laissez pas l'échéance de 2027 imposer un go-live que les répétitions ne justifient pas. Un go-live tardif coûte des frais de maintenance. Un go-live raté coûte bien plus.

Un sauvetage soulève souvent la question de garder ou non l'intégrateur actuel. Parfois, remplacer le partenaire est la bonne décision. Souvent, le vrai problème est la façon dont le programme a été monté, et un nouveau partenaire en hérite.

Voici les questions que je poserais avant de décider :

1. Pouvez-vous nous montrer le système déployé, en direct, par rapport à la conception signée ? Pas un environnement de démonstration et pas des diapositives.
2. Quels objets WRICEF sont réalisés, testés et transportés, et lesquels sont seulement déclarés terminés ?
3. Quelle est votre conception générale pour terminer, et quelles références pouvons-nous appeler où vous avez redressé un programme comme le nôtre ? Les références et la conception générale sont les deux choses que je demande à tout partenaire avant de signer.
4. De quoi avez-vous besoin de notre part que vous n'obtenez pas ? Les décisions manquantes et les utilisateurs clés à temps partiel représentent souvent la moitié de l'histoire.
5. Pour les clients RISE with SAP : quels problèmes relèvent de SAP plutôt que du partenaire, et qui les fait remonter ?

Le signal d'alerte est le même que celui qui me fait écarter un partenaire lors de la sélection : les réponses génériques. Si le plan de redressement pourrait s'appliquer à n'importe quelle entreprise, il n'a pas été écrit pour la vôtre. Mon guide pour choisir un partenaire de migration S/4HANA couvre le volet sélection.

Si le programme n'a jamais eu de véritable évaluation du système source, faites-en une maintenant. Le SAP Readiness Check analyse votre système existant, et SAP recommande de l'exécuter en production pour obtenir une image fidèle de l'utilisation réelle. Mon article sur le SAP Readiness Check et l'évaluation de migration explique ce qu'il manque, à commencer par les objets spécifiques.

Réservez une demi-journée avec votre directeur de programme et votre responsable SAP, et demandez-leur de vous montrer trois choses côte à côte : le dernier rapport d'avancement, la conception signée et le système de test déroulant un processus métier complet. Si les trois racontent la même histoire, relancez. Sinon, lancez un redressement formel avant le prochain comité de pilotage.

Si vous voulez un avis indépendant sur un programme qui dérape, j'aide les organisations précisément sur ce type de diagnostic. Vous pouvez réserver un appel avec moi.

Qu'est-ce que le redressement d'un projet SAP ?

Le redressement d'un projet SAP consiste à reprendre le contrôle d'une mise en œuvre ou d'une migration SAP qui dérape. Il commence par un diagnostic de l'état d'avancement du programme, de la conception et de ce qui est réellement déployé, puis reprend la maîtrise du périmètre, fixe une seule nouvelle référence et ajoute des quality gates aux phases restantes.

Comment savoir si mon projet SAP a besoin d'un sauvetage ?

Comparez trois choses : ce que disent les rapports d'avancement, ce que dit la conception signée et ce qui est réellement déployé dans le système. S'ils concordent entre eux et avec le plan, le programme a besoin d'une relance. S'ils divergent, davantage d'efforts sur le plan actuel ne le répareront pas et il vous faut un redressement formel.

Que doit-il se passer la première semaine du redressement d'une mise en œuvre SAP ?

Uniquement du diagnostic. Évaluez l'état d'avancement du programme, revoyez la conception et évaluez ce qui est réellement déployé, idéalement sous la conduite de quelqu'un d'indépendant du partenaire de mise en œuvre. N'écrivez pas le nouveau plan avant que ces trois vérifications soient faites.

Faut-il remplacer notre partenaire de mise en œuvre SAP pendant un redressement ?

Pas automatiquement. Demandez au partenaire de montrer le système déployé par rapport à la conception signée, et de vous donner une conception générale pour terminer, avec des références de redressements comparables.

Si les réponses sont génériques, c'est un signal fort pour changer. Si le vrai problème est la maîtrise du périmètre ou des décisions manquantes de votre côté, un nouveau partenaire en héritera.

Pourquoi les migrations SAP S/4HANA dérapent-elles ?

La cause profonde la plus fréquente que je vois est de ne pas planifier correctement au début de la mise en œuvre. Laisser le prestataire contrôler le périmètre en est une autre, et le code spécifique est la phase qui dépasse le plus souvent. La migration des données, qui représente 30 à 40 % de l'effort, est en général en retard elle aussi.

Un redressement va-t-il repousser notre migration ECC au-delà de l'échéance de 2027 ?

C'est possible. La maintenance standard de SAP ERP 6.0 sur les enhancement packages 6 à 8 prend fin le 31 décembre 2027, et la maintenance étendue optionnelle court jusqu'à fin 2030 avec une majoration de deux points. Budgétez la maintenance étendue plutôt que d'imposer un go-live que vos répétitions ne justifient pas.