Ce que vous ne savez pas des projets SAP

Il y a ce qu'on lit dans les livres blancs SAP, les architectures BTP, le Clean Core, les roadmaps S/4HANA.

Et il y a ce que vivent les consultants sur le terrain, au quotidien, entre deux réunions de pilotage et un Go-Live qui glisse.

En synthétisant leurs retours d'expérience, une vérité s'impose : un projet ERP n'est pas une implémentation logicielle.

C'est une gestion permanente de la friction entre la rigueur du système et la réalité humaine de l'organisation.

Le mythe du changement "simple"

L'une des frustrations majeures rapportées par les consultants que nous rencontrons est l'incompréhension du client face à la complexité systémique.

Ce qui semble être un ajustement cosmétique à l'écran influence en réalité plusieurs étapes critiques du processus.

Cette opacité crée une tension entre les équipes métier et les équipes projet.

Un consultant avec lequel nous avons échangé en a fait l'expérience.

Positionné sur une migration S/4HANA par son cabinet, il arrive sur le projet et réalise rapidement que le vrai frein n'est pas technique.

La hiérarchie du client résiste au changement, pas par mauvaise volonté, mais parce que personne n'a pris le temps de leur expliquer concrètement ce que la transition allait changer dans leur quotidien.

Le travail de paramétrage était déjà largement avancé.

Il a fallu tout mettre en pause, organiser une série de workshops pédagogiques, reprendre depuis le début le travail d'adhésion que le projet aurait dû faire en amont.

Résultat : plusieurs mois de décalage, une pression considérable sur le consultant, et au bout du compte deux mois sans mission pour récupérer. Ce n'est pas un cas isolé.

C'est le scénario qui attend tout projet SAP qui sous-estime le volet conduite du changement.

Le consultant chevronné le sait : le temps passé en analyse et en pédagogie n'est pas une perte de productivité.

C'est une assurance pour éviter des problèmes bien plus graves post-démarrage.

Et dans un système intégré comme SAP, l'effet papillon n'est pas une métaphore.

Modifier une règle centrale, c'est accepter que le système l'applique partout, impactant parfois des flux que le métier croyait totalement isolés.

C'est là que le consultant quitte son rôle de paramétreur pour devenir un stratège de l'impact global.

La donnée : le miroir de la rigueur métier

Le système est souvent le bouc émissaire idéal quand les résultats sont incohérents.

Pourtant les retours de nos consultants sont unanimes sur ce point : SAP n'invente rien, il exécute.

Si les données sources ne sont pas conformes, le résultat sera mathématiquement erroné.

Il en va de même pour les blocages en production.

Là où l'utilisateur voit un bug ou une contrainte rigide, le système agit comme une barrière de sécurité pour éviter une situation risquée.

Le vrai défi n'est plus technique, il est pédagogique : faire comprendre que la rigueur de l'outil est le reflet de la nécessaire rigueur du métier.

La fin des shadow processes

Prenons un Go-Live FI/CO sur S/4HANA.

Les équipes finance ont validé les flux en recette, les key users ont signé.

Le jour J, les comptables ouvrent le système et réalisent que les règles de rapprochement automatique ne correspondent pas à la façon dont ils traitaient réellement leurs écritures depuis des années, un processus parallèle jamais formalisé, jamais documenté, mais parfaitement intégré dans leurs habitudes.

Le système, lui, applique ce qui a été conçu. La crise éclate.

Le consultant doit alors jouer un rôle qu'il n'avait pas anticipé : pas réparer un bug, mais expliquer à la direction financière que le problème n'est pas dans SAP, mais dans l'écart entre leurs processus réels et ceux qu'ils ont validés sur le papier.

C'est à ce moment précis que le projet bascule, dans un sens ou dans l'autre.

Plutôt que de chercher à reproduire l'existant à l'identique, erreur classique qui alourdit inutilement le core, l'expert doit amener le client vers de nouveaux réflexes structurels.

Car si l'on peut techniquement tout développer, chaque spécifique devient une chaîne qui entrave les évolutions futures de l'organisation.

La posture du Trusted Advisor

À l'approche du Go-Live, le consultant est souvent réduit à un rôle d'exécutant sous pression.

C'est pourtant là que sa valeur ajoutée est la plus forte.

Son rôle n'est pas de dire oui à un périmètre qui change sans arrêt, mais d'alerter sur les conséquences de chaque ajout sur le planning et la stabilité finale.

Savoir dire non, ou plutôt savoir dire "voici ce que ça coûte", est une compétence rare que les années forgent et que les profils juniors n'ont tout simplement pas encore.

Le professionnalisme sur SAP ne se mesure pas à la complexité du jargon maîtrisé.

Il se mesure à la capacité de transformer une situation technique opaque en décision compréhensible pour un directeur financier ou un DSI qui n'a pas le temps de rentrer dans les détails.

C'est exactement le type de profil que nous cherchons à identifier pour nos clients chez Zenith : des consultants SAP FI/CO qui ne sont pas seulement bons dans le système, mais qui savent lire une organisation, anticiper ses résistances et sécuriser un projet quand la pression monte.

Si vous êtes DSI ou manager IT et que vous préparez une migration S/4HANA, c'est le bon moment pour en parler.