Projets ERP : ce qui se décide avant d'installer quoi que ce soit

Un projet ERP est un projet d'organisation qui utilise un logiciel

La majorité des projets ERP n'atteignent pas leurs objectifs, et presque jamais pour des raisons techniques. Le logiciel, lui, fonctionnait.

Les causes sont toujours les mêmes : les équipes n'ont pas été embarquées, les données reprises étaient fausses, et personne dans le projet n'avait déjà vécu ça. Ce qui échoue, c'est le jour où tout le monde doit travailler autrement.

La première question à poser n'est donc pas « quel outil », mais « qui va devoir changer sa façon de travailler, et qu'est-ce qu'on fait pour l'y préparer ».

Chaque ligne de code sur mesure est une facture qui revient à chaque version

Adapter l'outil à sa façon de travailler semble être le but. Sauf qu'à chaque nouvelle version, les développements spécifiques doivent être relus, testés et souvent réécrits, et plus il y en a, plus la mise à jour devient un projet.

La question à poser sur chaque demande n'est donc pas « est-ce faisable », mais « est-ce que ça vaut d'être repayé chaque année ».

En pratique, ça revient à commencer par ce que l'outil fait déjà, paramétré sur vos processus réels, et à regarder les écarts au lieu de les combler par du code. Certains passent. D'autres se règlent en changeant une habitude.

Vos données sont plus sales que vous ne le croyez

Doublons de clients, articles créés en trois exemplaires, soldes qui ne tombent pas juste, colonnes de tableur qui voulaient dire autre chose il y a six ans.

Tant que ces données vivent dans des outils séparés, personne ne s'en aperçoit. Le jour où elles doivent toutes entrer dans le même système, tout ressort en même temps, au moment de la bascule, quand il n'y a plus de marge.

Le seul remède connu est de s'y prendre tôt : extraire les données avant la fin du paramétrage, pendant qu'il reste du temps pour trancher.

• Ce qui est reprenable tel quel
• Ce qui doit être nettoyé avant
• Ce qu'il vaut mieux ne pas reprendre du tout

On peut posséder tout son système et rester coincé chez son prestataire

Le verrou n'est presque jamais dans le contrat. Il est dans les comptes ouverts au nom de l'intégrateur, les connexions qui passent par ses outils, les paramétrages que personne d'autre ne sait relire.

Le test tient en une question : si vous changiez de prestataire le mois prochain, combien de temps le suivant mettrait-il à comprendre votre système ?

Ce qui rend la réponse acceptable n'est pas une clause, c'est de la documentation : pourquoi ce champ, pourquoi ce flux. C'est ce qui manque toujours quand quelqu'un d'autre reprend.

• Les comptes et les accès sont-ils à votre nom ?
• Le code des modules développés pour vous vous appartient-il ?
• Les paramétrages et les décisions sont-ils écrits ailleurs que dans une tête ?