La course au code
La plupart des projets ERP démarrent pareil.
Semaine 1 : Recueil des besoins. Deux jours de réunions. Les parties prenantes listent ce qu'elles veulent. L'IT note.
Semaine 2 : Conception technique. Les architectes dessinent des boîtes et des flèches. Les développeurs estiment les heures.
Semaine 3 : Le code démarre.
Six mois plus tard : Personne ne peut expliquer pourquoi la moitié des fonctions existent. L'autre moitié ne fait pas ce dont les gens ont besoin. Le projet est au-dessus du budget et en retard.
Le problème n'était pas l'exécution. C'était le départ.
Ce que clarté veut vraiment dire
La clarté, ce n'est pas noter ce que les gens disent vouloir.
La clarté, c'est comprendre quel problème vous résolvez vraiment.
Quand quelqu'un demande un champ personnalisé pour suivre "la priorité client", la vraie question n'est pas comment construire ce champ. C'est pourquoi il en a besoin.
Les commerciaux se battent pour savoir quelle affaire conclure en premier ? C'est un problème de structure de rémunération, pas un problème de logiciel.
Le service client route mal les tickets ? C'est un problème de processus, pas un problème de champ.
La direction essaie de prévoir le chiffre d'affaires ? C'est un problème de qualité de données, pas un problème de personnalisation.
Même demande. Trois causes racines complètement différentes. Trois solutions complètement différentes.
Si vous commencez à coder avant de comprendre quel problème vous résolvez, vous allez construire la mauvaise chose.
Pourquoi les projets sautent cette étape
Parce que la clarté est inconfortable.
Demander "pourquoi" cinq fois expose les processus cassés. Les responsabilités floues. Les priorités en conflit. Les trucs dont les gens préfèrent ne pas parler.
C'est plus facile de juste construire ce qu'ils ont demandé.
Le consultant est payé. Le projet reste dans les temps. Tout le monde évite la conversation difficile.
Jusqu'à six mois plus tard quand le système va en ligne et rien ne marche comme prévu.
À quoi ressemble clarté avant code
On ne commence pas par les besoins. On commence par les questions.
Qu'est-ce qui est cassé maintenant ? Pas quelles fonctions vous voulez. Qu'est-ce qui ne marche pas dans votre business aujourd'hui.
Que se passe-t-il si on ne fait rien ? Si la douleur ne vaut pas le coup d'être réglée, on ne devrait rien construire.
Qui porte le résultat ? Si personne ne sera responsable du succès, ça ne marchera pas.
À quoi ressemble le succès ? Spécifique, mesurable, délimité dans le temps. Si vous ne pouvez pas le définir, on ne peut pas le construire.
Qu'est-ce qu'on est prêt à tuer ? Chaque oui est un non à autre chose. Qu'est-ce que vous êtes prêt à ne pas faire.
Ces questions prennent du temps. Elles sont inconfortables. Elles font remonter des problèmes que les gens ne veulent pas gérer.
C'est le but.
Mieux vaut découvrir que votre processus est cassé en semaine un qu'au mois six quand vous avez déjà cramé le budget.
La phase de découverte
C'est pour ça qu'on commence toujours par la découverte.
Prix fixe. Périmètre fixe. Deux à quatre semaines.
On audite le système actuel. On interviewe les utilisateurs. On mappe les processus. On documente les workflows réels, pas ceux rêvés.
On trouve les écarts entre ce que les gens disent faire et ce qu'ils font vraiment.
On identifie ce qui est un problème logiciel et ce qui est un problème humain.
À la fin, on livre un plan. Ce qui est dans le périmètre. Ce qui est dehors. Ce que ça coûte. Combien de temps ça prend. Quels sont les risques.
Ensuite le client décide s'il continue.
Parfois non. Les chiffres ne collent pas. Le timing est mauvais. L'organisation n'est pas prête au changement.
C'est OK. Mieux vaut le savoir maintenant qu'après avoir cramé six mois et un demi-million d'euros.
Ce que ça prévient
La dérive du périmètre. Parce que tout le monde a validé en amont ce qu'on construit et pourquoi.
Les refactorisations. Parce qu'on a compris le problème avant de coder.
Les batailles politiques. Parce qu'on a fait remonter les conflits tôt quand ils sont peu coûteux à résoudre.
Les déploiements ratés. Parce qu'on sait à quoi ressemble le succès et on peut mesurer si on est sur la bonne voie.
La dette technique. Parce qu'on ne construit pas des fonctions dont personne n'a besoin juste parce que quelqu'un les a demandées.
Pourquoi la plupart des consultants ne font pas ça
Parce que ça retarde le revenu.
Si vous passez trois semaines sur la découverte, c'est trois semaines où vous ne facturez pas d'heures d'implémentation.
Si la découverte révèle que le projet n'est pas prêt, vous pourriez perdre le deal entièrement.
Donc la plupart des consultants sautent la découverte. Ils prennent les besoins pour argent comptant. Ils commencent à construire direct.
Ils sont payés plus vite. Le projet a l'air d'avancer.
Et six mois plus tard quand tout pète, ils sont déjà partis.
Ce que ça signifie pour vous
Si un consultant est prêt à commencer à coder le jour un, fuyez.
S'il ne pose pas de questions inconfortables sur vos processus, votre organisation, votre préparation au changement - fuyez.
S'il prend votre liste de besoins et dit "bien sûr, on peut tout construire" sans rien challenger - fuyez.
Les meilleurs projets ERP démarrent lentement. Avec des questions, pas des réponses. Avec de la clarté, pas du code.
Parce que si vous ne savez pas quel problème vous résolvez, peu importe la qualité du code.