Conseils

L'analyse avant un projet ERP est-elle une perte de temps ?

Par Marc Adedjouma · Fondateur de We Make Smart · Lecture : 7 minutes

Réponse courte : la plupart des analyses sont effectivement des pertes de temps, parce qu'elles ne décident rien. Mais sauter l'analyse ne fait pas gagner ce temps : il est remboursé avec intérêts pendant le déploiement, au moment où chaque correction coûte le plus cher. La vraie question n'est pas analyse ou pas d'analyse, c'est analyse qui décide ou analyse qui décore.

Quand un dirigeant de PME dit que l'analyse est une perte de temps, il ne dit pas une bêtise. Il décrit ce qu'il a vu : des audits de quarante pages finis dans un tiroir, des expressions de besoin qui recopient la plaquette du dernier éditeur reçu, des semaines de réunions pour reformuler ce que tout le monde savait déjà. Cette méfiance est fondée. La conclusion qu'on en tire ne l'est pas.

Pourquoi l'analyse a-t-elle si mauvaise réputation ?

Parce que la plupart des analyses vendues sur le marché produisent du document, pas de la décision. Une analyse qui ne se termine pas par des choix engageants est effectivement du temps perdu.

Trois espèces d'analyses inutiles peuplent les projets informatiques. L'inventaire exhaustif, qui décrit tout et ne hiérarchise rien : personne ne peut agir dessus. La reformulation savante, qui traduit en vocabulaire de consultant ce que les équipes disaient déjà en français : elle coûte des semaines et n'apprend rien. Et la validation de façade, commandée pour justifier un choix déjà fait : elle décore la décision au lieu de l'éclairer. Un dirigeant qui a croisé l'une de ces trois espèces a de bonnes raisons de ne pas vouloir payer la quatrième.

Le problème de ces analyses n'est pas d'exister. C'est de ne rien trancher.

Que se passe-t-il quand on saute l'analyse ?

Les questions qu'on n'a pas posées avant le projet se posent d'elles-mêmes pendant le projet. Et pendant le projet, chaque réponse coûte dix fois plus cher : ce qui se corrigeait d'un trait de stylo au cadrage se corrige en avenants, en délais et en travaux jetés au déploiement.

Un cas vécu montre la mécanique. Le dirigeant d'une entreprise de taille intermédiaire refuse la phase d'analyse : son choix est fait, l'outil repéré est solide, et cadrer le besoin lui semble une dépense inutile. Sur un point, il avait raison : l'outil était bon. Pris isolément, il aurait convenu.

Mais une entreprise n'achète jamais un outil isolé : elle l'installe dans un écosystème. Et dans cet écosystème vivait un logiciel maison, développé sur mesure pour le cœur de métier, impossible à remplacer à court terme. Personne n'avait posé la question de l'interfaçage entre les deux. La réponse est arrivée en pleine implémentation : impossible. Il a fallu rebrousser chemin, abandonner le déploiement en cours, et reprendre la sélection depuis le début, avec cette fois la contrainte posée noir sur blanc : c'est au nouvel outil de s'adapter à l'outil maison, pas l'inverse.

La facture du demi-tour s'est comptée en centaines de milliers d'euros : de l'ordre de 300 000 euros de travaux d'implémentation à reprendre, sans compter les mois perdus et les équipes à remobiliser. C'était une entreprise de taille intermédiaire, et les montants suivent la taille. Mais ne vous y trompez pas : la mécanique est rigoureusement la même dans une PME, et la proportion aussi. Sur un projet à 150 000 euros, le même angle mort coûte 40 ou 60 000 euros de travaux jetés, et il fait souvent plus mal, parce qu'une PME n'a pas la trésorerie d'une ETI pour absorber un projet payé deux fois.

Le plus instructif n'est pas l'échec, c'est sa cause. Ce projet n'a pas déraillé sur un mauvais produit, un mauvais intégrateur ou un mauvais budget. Il a déraillé sur une question jamais posée, qu'un cadrage d'une semaine aurait mise sur la table dès le premier jour : avec quoi ce système doit-il vivre ?

À quoi reconnaît-on une analyse qui n'est pas une perte de temps ?

Une analyse utile se reconnaît à quatre traits : elle est bornée dans le temps, elle produit des exigences vérifiables plutôt que des souhaits, elle se termine par une décision engageante, et son livrable ressert plus tard. Si un seul de ces traits manque, la méfiance est justifiée.

Elle est bornée. Un cadrage sérieux pour une PME se compte en semaines, pas en mois : des ateliers par profil métier, une consolidation, un document. Une analyse sans date de fin est un abonnement, pas une étape.

Elle produit du vérifiable. Sa matière n'est pas une liste de souhaits (« un outil performant et intuitif ») mais des cas d'usage démontrables, avec des cibles tangibles : « la prise de commande doit tenir en moins de cinq minutes », « la facture sort sans ressaisie depuis le bon de livraison », « le nouvel outil doit échanger avec le logiciel maison, dans les deux sens ». Chaque ligne peut recevoir une réponse binaire en démonstration. C'est ce qui sépare une analyse d'une dissertation. La méthode complète est détaillée dans notre article sur le cahier des charges ERP.

Elle se termine par une décision. Des noms d'outils retenus et écartés, avec leurs motifs écrits. Des chiffres. Un calendrier. Éventuellement la conclusion qu'il ne faut pas acheter d'ERP, ou pas maintenant : une analyse qui ne peut conclure qu'à un achat n'est pas une analyse, c'est un entonnoir commercial.

Son livrable ressert. Le même document cadre la consultation des éditeurs, permet leur engagement au forfait, sert de scénario d'épreuve aux démonstrations, puis de grille de recette au déploiement. Une analyse dont le livrable ne survit pas à la signature était effectivement du papier.

Combien de temps l'analyse fait-elle vraiment perdre, ou gagner ?

Bien menée, l'analyse est l'étape la plus rapide du projet, et la seule qui raccourcisse toutes les autres. L'arithmétique observée sur le terrain : quelques semaines de cadrage contre des mois d'errance évités, et des dizaines de milliers d'euros de travaux non jetés.

Comparez les deux chemins. Sans analyse : des démonstrations en boucle pendant des mois, des devis incomparables, une décision par épuisement, puis les découvertes en cours de déploiement, chacune facturée en avenant. C'est le parcours type des PME qui mettent six mois à ne pas choisir leur ERP. Avec analyse : une trentaine de jours entre le lancement du cadrage et une décision documentée, des éditeurs qui s'engagent au forfait parce qu'ils ont toutes les billes, et des mauvaises surprises débusquées quand elles coûtent une ligne de document plutôt qu'un chantier.

L'analyse ne retarde pas le projet. C'est elle qui l'empêche de durer six mois.

Par où commencer sans consultant ?

Par une page. Listez les trois systèmes avec lesquels votre futur outil devra vivre, les trois irritants qui motivent le changement, et reformulez chacun en cible vérifiable. Cette page est déjà une analyse, et elle vous protège déjà.

Posez d'abord la question qui a coûté 300 000 euros à l'entreprise du cas ci-dessus : avec quoi le nouvel outil doit-il s'interfacer, et parmi ces systèmes, lesquels sont intouchables ? Puis les irritants, traduits en cibles mesurables plutôt qu'en souhaits. Si l'exercice vous prend une heure, vous venez de faire une meilleure analyse que la moitié des projets qui se lancent. S'il vous résiste, c'est le signe que le besoin n'est pas encore clair, et c'est précisément la découverte qui vaut la peine d'être faite maintenant plutôt qu'en pleine implémentation.