Règle n°1 d'une gestion de projet : définir la date de fin ?
En matière de gestion de projet, et l’implémentation d’ERP n’y fait pas exception, l’une des premières questions mises sur la table est la suivante « Quels sont les dates de début et de fin de projet ».
Lorsque cette question est posée, en réalité, le projet a déjà démarré.
Dès les premières réunions « commerciales », la confiance s’installe et l’intégrateur collecte déjà un certain nombre d’informations que son équipe va pouvoir réutiliser lors du 1er atelier, par exemple pour dessiner de manière plus fine le contour du projet (le scope).
La question de la fin du projet est toute différente.
Il est communément admis que le projet ERP se termine au moment du go-live ou, dans le meilleur des cas, après une période de support de 6 semaines.
Le client est rassuré.
L’intégrateur est tout aussi satisfait.
Il peut planifier ses ressources pour déjà vendre une nouvelle implémentation chez un autre client.
En réalité, c’est au moment du go-live que commencent les vrais défis.
Lorsque le système est techniquement prêt.
Les utilisateurs ont été formés.
Sur papier, tout est en ordre.
Le COMEX peut cocher la case « Terminé ».
La face cachée de l’iceberg est bien différente
Les utilisateurs peuvent réaliser les opérations simples, mais pas celles qui arrivent une fois par mois.
Personne n’y a pensé.
Une solution standard existe dans le nouveau système, mais puisque la phase de stabilisation est terminée, il n’y a plus personne à qui demander.
Alors on contourne le système.
Pas par mauvaise volonté.
Par instinct de survie.
De nombreux rapports de gestion sont disponibles dans le nouvel ERP.
Ils ont été présentés lors de la démo commerciale !
Mais la direction s’attend à recevoir les rapports sous le même format qu’avant.
On procède aux mêmes extractions.
On réutilise les mêmes modèles Excel.
Ceux qu’on maîtrise.
Personne n’a le courage, ni l’envie, de dire au management qu’avec l’arrivée de S/4HANA le rapport sera présenté différemment.
Le reporting destiné au groupe se fait dans un système externe.
Mais personne n’a pensé à construire un plan comptable qui permet de faire un lien direct vers ce fameux « EPM », supposé gérer la performance de l’entreprise.
Le reporting groupe, c’est « autre chose », on verra ça plus tard.
En fait, jamais.
Le problème ?
Le COMEX a dépensé une fortune en pensant transformer l’organisation pour devenir « plus efficace », mais les habitudes de travail, elles, n’ont pas changées.
Le nouveau système fonctionne très bien.
Tout a été validé pendant le testing.
Mais les comptables et les contrôleurs de gestion ne comprennent plus d’où viennent les chiffres.
Parce-que les écritures comptables sont automatisées. Les schémas d’écriture n’ont pas été expliqués.
Encore moins documentés.
On passe ses soirées à « débugger », essayer de traçer la source des écritures.
Au lieu d’analyser les chiffres.
Les KPI de déploiement ont permis de montrer que le projet avait été livré « on time » et « on budget ».
Le contournement du système, la fatigue des équipes, les clôtures aussi laborieuses qu’avant, l’impression que « rien n’a vraiment changé ».
Cela ne transparaît dans aucun KPI.
Le système fonctionne, mais une partie de son potentiel reste inexploité.
La solution ?
La mise en place d’un ERP devrait être vue sous l’angle Kaizen, cette méthode d’amélioration continue japonaise.
Même si le go-live se fait sous la forme d’un Big Bang pour des raisons techniques, le fonctionnement de l’ensemble de l’organisation ne peut être changées en une fois.
Or, les processus doivent évoluer avec l’ERP.
De nouveaux rapports doivent être développés après le go-live.
Des petites modifications de paramétrage peuvent changer la vie d’un utilisateur.
Des changements qui ne peuvent être anticipés, car trop précis.
Si l’on ne voit la mise en place de l’ERP que comme un projet technique one-shot, les gains d’efficacité promis ne seront jamais là.
Ma dernière longue mission ?
3 ans de stabilisation et d’accompagnement métier.
6 mois avant le go-live et 2 ans et demi après.


