Votre entreprise a enfin décidé à lancer le projet de mise en oeuvre d’ERP. Comment s’y prendre pour ne pas se planter ? Voici quelques pratiques éprouvées qui nous ont permis de réussir les projets que nous avons menés pour nos clients et pour notre propre compte.

Conduire un projet ERP : comment réussir ?

Le projet a été décidé, lancé. Le budget voté, les équipes désignées. Par quoi commencer ?

Conseil n°1 : S’entourer de spécialistes

C’est une évidence pour certains, mais qu’il nous paraît nécessaire de rappeler, tant nous avons vus de projets dont les équipes manquaient des compétences minimales nécessaires.

D’abord, il faut des spécialistes de la transformation. Rompus à la conduite de projet informatiques et business complexes. En effet, dans une entreprise, sauf exception, les compétences requises sont des compétences de production sur le coeur de métiers, et pas la conduite de projets de mise en oeuvre d’ERP. Les spécialistes de ces projets réunissent ces compétences très ciblées :

  • Connaitre la culture et le modèle économique des éditeurs
  • Connaitre la culture et le modèle économique des intégrateurs
  • Comprendre le métier de l’entreprise, ses temporalités, ses spécificités
  • Connaitre les ERP et l’impact que le choix de ces progiciels a sur la manière de conduire un projet informatique
  • Savoir manager l’atteinte d’objectifs en temps et budget contraints
  • Savoir interagir avec des utilisateurs, pour comprendre leurs besoins, et pour les aider à s’approprier le nouvel outil

Il faut ensuite des spécialistes de la solution choisie. Ce ou ces spécialistes a ces compétences :

  • Il sait ce que peut faire la solution, dans son coeur de fonctionnalités, donc bien, ou en périphérie, donc mal
  • Il sait comment bien utiliser la solution pour répondre aux besoins, ce qui garantit l’évolutivité de la mise en oeuvre
  • Il sait que tout développement spécifique en plus est un engagement hors bilan qui durera autant que l’ERP

Un de mes amis, qui a été le créateur du module de gestion des ressources humaines d’un des leaders mondiaux des ERP me disait qu’il y avait en Europe les compétences nécessaires pour diriger 50 projets concurrents sur sa solution. Malheureusement, il y a au même moment 500 projets ERP sur cette solution. Donc 9 projets sur 10 finissent mal.

Conseil n°2 : S’imprégner des besoins métiers

Le travers habituels des éditeurs et intégrateurs de solutions progicielles est de rester cantonnés à leur connaissance de leur solution, et de sous-estimer volontairement la complexité des besoins de leurs clients. Ça se comprend, eux ont choisi leur technologie car elle a pignon sur rue, pourquoi passer du temps à comprendre le client ? A lui de se mobiliser pour répondre juste aux questions posées pour adapter l’ERP aux besoins.

Comme les équipes du Client n’ont pas le temps ou la compétence, cela conduit à des considérations sidérantes que j’ai entendu plusieurs fois : « À la fin, si les utilisateurs ne se bougent pas, entre guillemets, on les violera : on mettra en prod, ça ne marchera pas, ils nous posteront des bugs, et on se refera sur la maintenance corrective et évolutive post go-live qui explosera. De toutes façons, ils n’auront plus le choix, sinon l’entreprise ne pourra plus fonctionner ».

Conseil n°3 : adopter une démarche agile par lots intelligents

Les ERP ne sont pas monolithiques, il peuvent commencer à fonctionner avec un périmètre partiel : produits, achats, ventes. Les stocks, la comptabilité, les calculs de coûts, l’ordonnancement, les approvisionnements, le marketing, l’administration des ventes, les RH… pourront être mis en oeuvre plus tard, ou pas du tout.

Il est donc possible de commencer par des fonctionnalités simples et démonstratives sur des métiers bien maitrisés par les utilisateurs, pour monter graduellement en exigence avec des modules de plus en plus difficiles à mettre en oeuvre.

Cela permet également à l’intégrateur d’appréhender graduellement la complexité et la spécificité de son client, et d’éviter de se retrouver avec une masse de problèmes inextricable.

Une fois qu’un lot est maitrisé, que l’entreprise a tiré des gains, le prochain lot peut être mis en oeuvre.

On peut même gérer la coexistence avec des systèmes préexistants avec des plateformes d’échange de documents de type publication – abonnement (publish-subscribe), permettant de synchroniser les données sans nécessiter d’interfaces complexes. Par exemple, un système A envoie un nouveau produit créé sur une plateforme : elle le publie sous forme de fiche produit. Cette fiche peut être consommée par un système B pour faire des opérations de ventes avec, en double commande avec le système A le temps de s’assurer que les résultats sont les mêmes. Ce qui permet à terme de cloturer la fonctionnalité de vente sur le système A, lorsqu’on s’est assuré que le système B est bien fonctionnel.

Conseil n°4 : soigner les données

Les données de référence sont le coeur d’un ERP. Ce sont :

  • les produits ou services, identifiés par des codes et libellés et autres attributs (poids, forme, plans, prix…)
  • les Clients
  • les Fournisseurs
  • les personnes, employés ou prestataires
  • les codes comptables
  • les structures organisationnelles (pays, gamme de produits, entités, entrepôts…)

Au-delà d’en constituer la liste et les attributs, il faut aussi s’assurer de l’organisation qui les fera évoluer, créera les données au fur et à mesure, s’assurera de la qualité, de supprimer les doublons…

Conseil n°5 : ne jamais s’éloigner des processus standards de l’ERP

Comme tout outil, un ERP a été bâti pour des besoins qui sont en son coeur : gérer des produits, les vendre, les fabriquer, les facturer, acheter des matières premières pour les fabriquer, gérer des stocks. Et des clients ont demandé des extensions, seulement utilisées par un petit nombre d’entre eux. Mécaniquement, darwinnienement, le coeur des fonctionnalités fonctionne bien, car tous les problèmes possibles ont été rencontrés par les nombreux utilisateurs, donc corrigés. Les fonctionnalités périphériques sont moins fiables, car moins utilisées.

Si on en vient à ce qu’un ERP ne fait pas en standard ou avec un paramétrage poussé, je déconseille formellement de se lancer dans des développements. Cela revient à payer trois fois :

  • 1 fois pour la licence
  • 1 fois pour ces fonctionnalités spécifiques
  • 1 fois au prochain changement de version, qui nécessitera de redévelopper la fonctionnalité spécifique

Il existe aujourd’hui, encore grâce aux plateforme publish-subscribe, la possibilité de développer en dehors de l’ERP ce qu’il ne fait pas, ou encore mieux, de prendre une fonctionnalité additionnelle d’un produit tiers, qui lui a ce besoin spécifique dans son coeur de fonctionnalités.

Conseil n°6 : passer du temps avec les key users, les décharger de jobs fastidieux ou impossibles pour eux

Les key users, c-à-d. les spécialistes des différents métiers qui sont reconnus comme référents, et en plus qui sont volontaires pour participer au projet d’ERP en expliquant leurs besoins, renseignant les données, et faisant des tests, ont un gros problème : ils ont une boite à faire tourner, et ils ne sont pas spécialistes de conduite de projets d’ERP, de manipulation et transformation des données, ou de la solution. S’ils sont seuls face à un éditeur ou un intégrateur, cela peut vite tourner au dialogue de sourds : l’éditeur-intégrateur envoie des documents modèles abscons pour décrire les besoins et/ou les données, en attendant une réponse des key users, qui ne vient pas ou qui est à côté de ce qui est attendu. Dérapage de délais, qualité déplorable de la solution, conflits, épuisement, le résultat est connu et déplorable.

Conseil n°7 : manager, anticiper, communiquer, former

L’art du rétroplanning est un art majeur de la conduite de projet d’ERP. On peut faire beaucoup de choses en étant créatifs et organisés, et surtout en anticipant.

Cela permet, par exemple, de faire des arbitrages réguliers entre périmètre couvert, délais et coûts. Cela permet aussi de réussir la phase la plus périlleuse, celle d’ouverture aux utilisateurs, d’autant plus si la coexistence entre les anciens systèmes et les nouveaux n’a pas été pensée ou possible, et s’il y a des migrations de données à mener.

Communiquer les décisions majeures pour les utilisateurs, les situations de difficultés, cela permet de dédramatiser et d’éviter les angoissants effets tunnels. Conduire un projet ERP est difficile, personne ne vous en voudra d’éprouver des difficultés, surtout si elles ont été partagées tôt avec les bonnes personnes.

Une autre dimension importante est la formation : un ERP n’est pas -encore !- aussi simple à utiliser qu’une app de smartphone. Il faut former, communiquer, faire des tutoriels video, ou visuels, re-former, offrir du support, former des formateurs relai… C’est le prix à payer pour que les utilisateurs se servent du système en y saisissant des données fiables, alors que le retour d’expérience est de plus de 30% de données non fiables, et une multitude de tableurs pour pallier les faiblesses de l’ERP.

En conclusion

Mettre en oeuvre un ERP est un projet complexe dont la partie technique n’est qu’une petite partie a priori bien gérée par son éditeur. Il faut surtout gérer l’adéquation entre les besoins et la solution, piloter les délais et les coûts du projet mobilisant des ressources qui conservent des responsabilités de production, procéder par lots de difficultés bien délimitées, et communiquer et former de nombreuses personnes, dans la durée. Il est impensable de réussir un tel projet avec ses propres équipes, ni avec celles d’un éditeur. Il faut se doter de plusieurs spécialistes, notamment en chefs d’orchestres de projets complexes, et en experts de la solution, pour espérer réussir le projet dans des coûts et des délais raisonnables.

 

Sur le même sujet, vous pourrez aussi lire :