Hervé Petit, auteur de l’ouvrage « Mettre en œuvre et piloter un projet ERP », a été directeur de projet ERP pour des grands groupes internationaux. Il nous livre son expérience issue de vingt-cinq ans de pratiques d’implémentation de solutions Microsoft Dynamics, SAP et Peoplesoft.
En quoi l’implémentation d’un ERP constitue-t-il un choix structurant ?
Hervé Petit. Choisir un ERP est une décision stratégique, parce qu’il gère la plupart des flux dans l’entreprise. Rappelons que trois types de flux traversent l’entreprise : d’abord, les flux d’informations, lorsque la commande du client se transforme en ordre de production, qui, lui-même, génère une commande d’achat vers les fournisseurs.
Ensuite, les flux de matières, qui viennent des fournisseurs, sont transformées par l’entreprise et vendues aux clients. Enfin, les flux monétaires, lorsque les clients payent l’entreprise qui, elle-même, paie ses fournisseurs. De fait, tout mouvement de matières ou d’argent génère des flux d’informations, autrement dit des transactions dans l’ERP.
Le choix d’un ERP a donc des conséquences, non seulement pour le système d’information, mais pour tous les métiers de l’entreprise. De fait, l’entreprise doit être capable, à la fois de suivre les nouvelles versions de l’éditeur, de réaliser le minimum de développements spécifiques, pour ne pas complexifier les montées de version, et de pouvoir profiter de nouvelles fonctionnalités, si elles sont intéressantes.
Quels sont, selon vous, les principaux facteurs clés de succès d’un projet ERP ?
Hervé Petit. Il y a, bien évidemment, l’incontournable soutien de la direction générale, d’autant que la mise en place d’un ERP fournit l’occasion de remettre en question l’organisation et les processus, ce qui peut générer de la résistance au changement. La DG doit communiquer de façon positive, non pas en affirmant « Vous travailliez mal avant, mais avec le nouvel ERP, vous allez enfin bien travailler », mais avec une communication plus positive mettant en exergue tous les bénéfices de l’ERP.
Cette attitude ne concerne évidemment pas que la DG mais l’ensemble du management, qui doit soutenir la décision de la direction générale. Il arrive pourtant que certains managers ne supportent pas de tels projets, qui modifient les processus et l’organisation, et dans lesquels ils estiment que leurs compétences seront remises en cause.
Ces managers peuvent gravement nuire au projet. Il faut donc, soit les convaincre, soit, malheureusement, s’en séparer, car c’est l’une des principales causes d’échec des projets ERP. Plus globalement, mettre en œuvre un projet ERP passe nécessairement par la définition d’un Core Model basé sur les meilleures pratiques. La tentation est grande de vouloir reconduire l’existant auquel chacun se raccroche, mais l’avantage d’un Core Model , unique pour tous, est qu’il permet de « lâcher prise » et d’accepter de changer dans un objectif de convergence.
Autres facteurs clés de succès : se fixer un objectif clair, qui soit sans ambiguïté possible et mesurable, et savoir prendre des décisions rapidement. Car la principale cause des glissements de planning est la lenteur des prises de décision, voire leur remise en cause. La réussite d’un projet ERP nécessite deux autres conditions : d’une part, des ressources suffisantes.
Trop souvent, les ressources de l’entreprise sont déjà mobilisées par l’opérationnel et le projet à réaliser s’ajoute à leurs tâches. Cela ne peut pas fonctionner, car l’opérationnel prendra toujours le dessus sur les livrables du projet ! Il faut donc dédier des ressources à temps plein, y compris lorsque le projet est terminé. D’autre part, un accompagnement du changement.
Sur ce point, il subsiste beaucoup de résistance au changement dans les organisations : comment y faire face ?
Hervé Petit. Au début d’un projet important et structurant, comme l’est la mise en œuvre d’un ERP, qui change les processus, l’organisation et les outils, il n’est pas possible de répondre aux questions sur le devenir de chacun, c’est beaucoup trop tôt. Tout changement est synonyme d’espoirs et de craintes, mais les changements que nous subissons font bien plus peur que ceux dont nous avons été acteurs.
Il s’agit donc d’identifier, dans l’entreprise, les personnes clés, celles qui ont de fortes compétences, du potentiel, qui sont leaders d’opinion et qui ont montré leur volonté de changer. Et les associer aux choix qui seront faits. On retiendra que la meilleure façon d’avoir moins peur du changement est d’y participer, c’est autant valable pour l’entreprise que pour ses collaborateurs.
Quand faut-il donc démarrer un projet ERP ?
Hervé Petit. Il y a deux manières principales de démarrer un projet ERP : fixer une date ou démarrer quand on est prêt. Ces deux manières de gérer les projets ont des conséquences très différentes. Un des facteurs d’échec est de dire l’un (la date est inchangeable) et de faire l’autre (reporter le projet). Si la date fixée ne peut pas être tenue, il faut agir en prenant plusieurs décisions, par exemple supprimer des livrables, repousser ce qui n’est pas essentiel, réduire le niveau de qualité ou renforcer les équipes… Démarrer quand on est prêt peut sembler une solution plus confortable, mais, en réalité, cette option est très dangereuse.
Pourquoi ?
Hervé Petit. Parce que, dans cette configuration, chaque acteur va prendre son temps, va être perfectionniste (le mieux étant toujours l’ennemi du bien), ne concèdera aucun compromis (pour quelle raison en faire ?), en voudra toujours plus, exigera de nombreux développements spécifiques, de confort ou pour reproduire l’existant.
La résistance au changement des uns et des autres va créer tous les arguments pour allonger le planning. Le plus gros risque est donc de ne jamais démarrer, car il y aura toujours quelque chose d’imparfait, d’incomplet ou d’améliorable. Au lieu de penser éventuellement à des plans B, ce sera impérativement des plans A ou rien, mettant sur le même plan l’important et le superflu. Retenons que plus un projet dure, plus il s’essouffle, plus il est coûteux et moins il est motivant.
Quelle est donc la solution à ces difficultés ?
Hervé Petit. En fait, il faut démarrer quand il faut ! Cela signifie qu’il faut être capable de décider, d’assumer la décision, de la faire porter par toute la chaîne managériale, en choisissant la moins mauvaise des options qui se présentent. C’est l’essence même d’un bon pilotage de projet.
Il revient au comité de pilotage, ainsi qu’à son sponsor, de décider, en se posant les bonnes questions, par exemple : que se passe-t-il si le démarrage se fait à telle date ? Quels sont les impacts sur les coûts, les économies attendues, les optimisations, la satisfaction des clients, l’image de marque ou les autres projets de l’entreprise ? Il s’agit de peser les conséquences sur ces multiples dimensions, à la fois d’un point de vue quantitatif (surcoûts, gains reportés…) et qualitatif.
La décision la moins mauvaise sera par essence critiquable, car non dénuée d’inconvénients, mais il faut savoir l’expliquer et la défendre.
Et si le comité de pilotage ne parvient pas à se décider ?
Hervé Petit. S’il n’y a pas de décision consensuelle, il revient alors au sponsor du projet de trancher. C’est d’ailleurs dans ces moments de forte tension entre les équipes que le sponsor est si important.
Quels sont, selon vous, les critères de choix d’une solution ERP ?
Hervé Petit. On peut en identifier quatre principaux. Le plus important est celui de la pérennité. Dans la mesure où un projet ERP constitue un investissement important, en ressources financières, humaines, internes et externes, il faut pouvoir l’amortir sur au moins dix ans. Cela signifie qu’il faut orienter son choix vers un éditeur et un intégrateur qui a une bonne santé financière et qui peut s’adapter aux changements de l’environnement.
Le deuxième critère est celui de la scalabilité de la solution, par exemple pour accompagner la croissance de l’entreprise ou s’adapter aux évolutions de périmètre. Globalement, si le chiffre d’affaires double tous les cinq ans, l’ERP doit être capable, sur dix ans, de gérer au moins quatre fois plus de données sans dégradation de performance. C’est une façon de garantir la pérennité.
Troisième point important : la déployabilité, notamment en cas de croissance externe. Il est en effet préférable d’imposer son propre Core Model plutôt que de subir le système de l’entreprise acquise. Le quatrième critère concerne les aspects contractuels : il ne faut pas considérer le court terme, mais se projeter à dix ou quinze ans.
La négociation avec l’éditeur, et l’intégrateur, doit s’inscrire dans cette perspective. Il existe plusieurs leviers de négociation qui sont intéressants face à l’éditeur, par exemple lorsque le volume de licences au démarrage est significatif, si l’éditeur souhaite une nouvelle référence emblématique, si l’entreprise est le premier client dans un pays, s’il « essuie les plâtres » d’une nouvelle version ou si le marché est très concurrentiel.
Comment choisir le bon directeur de projet ?
Hervé Petit. Il y a plusieurs possibilités. D’abord, la DSI, qui est un choix a priori naturel, puisque l’ERP a une forte composante technique. Mais c’est loin d’être la meilleure solution. En effet, la mise en place d’un ERP nécessite de moins en moins de compétences informatiques. C’est d’autant plus vrai avec les ERP dans le cloud, où il n’y a plus besoin de serveur pour héberger la solution et l’exploiter, et quasiment plus de développements spécifiques.
En outre, confier le projet à la DSI envoie un très mauvais message : cela montre qu’il est très connoté informatique alors que ce n’est pas le cas, c’est un projet d’entreprise. Et comme les métiers ont tendance à vouloir reproduire le système existant, cela conduit à des demandes de développements spécifiques : or, la DSI ne sera pas à la bonne place pour décider, étant à la fois juge et partie.
Autre piste : la direction financière, ce qui permet de placer la responsabilité au niveau du comité de direction et d’avoir un bon suivi des coûts du projet. C’est encore mieux si le DSI est rattaché à la DAF… Cela dit, les décisions risquent d’être prises avant tout en fonction de critères économiques et comptables.
Le porteur de projet peut également être le comité de direction. Mais, autant le fait qu’il pilote le projet constitue une bonne chose, autant c’est plus problématique de faire du comité de direction le porteur du projet. Comme chaque métier a ses propres enjeux, ses équipes et ses objectifs, les responsabilités vont se diluer à tel point que personne ne se sentira réellement responsable.
On peut également opter pour un directeur de projet externe. C’est l’option la plus chère puisqu’elle ne fait pas appel aux ressources existantes dans l’organisation. Mais elle présente au moins deux avantages : d’une part, une fois le projet fini, les arbitrages douloureux ne laisseront pas de trace ; d’autre part, le directeur de projet externe n’aura pas de parti pris, ne sera pas juge et partie.
Que faut-il vérifier avant le démarrage ?
Hervé Petit. Avant de donner le « Go » qui va entraîner le basculement du système d’information existant vers le futur système, il convient de vérifier plusieurs points, que j’ai listé dans l’ouvrage, en particulier que les règles de gestion sont définies et validées, que les processus sont testés dans le nouveau système, que les utilisateurs ont les bons profils, que l’environnement de production est opérationnel, que les anciens systèmes d’information sont sauvegardés ou encore que la documentation du projet et du post-projet est organisée.
Certes, tous ces objectifs ne seront probablement pas tous atteints, mais il ne faut pas perdre de vue que tout ce qui se fera plus tard se fera dans l’urgence, donc pas de la meilleure manière, en particulier pour tout ce qui concerne la formation et les tests.
Le dernier chapitre met en avant le « dessous des cartes » en présentant, sous la forme de dialogues entre acteurs potentiels du projet, des situations mettant en évidence certaines résistances classiques au changement. Enfin, un lexique anglais/français des termes couramment employés dans ce type de projet, notamment dans les projets internationaux, pourra être d’une grande utilité.
Ce livre, destiné aux directions générales, aux directions métier, et à tous les acteurs du projet, n’est pas un livre technique de plus sur la mise en place des ERP. Il est écrit dans un langage volontairement accessible à tous, de telle sorte que chacun puisse comprendre le fonctionnement (et les dysfonctionnements) d’un tel projet.
Mettre en œuvre et piloter un projet ERP, par Hervé Petit, Editions ENI, 203 pages.
Les cinq types de fournisseurs à éviter
- Les éditeurs en mauvaise santé financière.
- Les éditeurs qui produisent rarement de nouvelles versions, parce qu’ils n’investissent pas assez dans la R&D.
- Les éditeurs qui ont basé leurs solutions sur des technologies anciennes qui n’existeront plus ou ne seront plus maintenues dans les dix ans.
- Les éditeurs qui pourraient se faire racheter par un autre, il n’investit plus et vit de la maintenance sur la base installée.
- Les intégrateurs trop petits.
Les facteurs de risques des projet ERP
- Certaines entités de l’entreprise donnent la priorité à d’autres projets que l’ERP.
- Les décisions prises en cours de projet sont remises en cause.
- La conception est remise en cause durant la phase de déploiement.
- L’existant est systématiquement reconduit.
- Le périmètre change pendant le projet.
- Les ressources nécessaires sont détachées sur d’autres projets.