Quand les projets partent en vrille
L'appel commence toujours pareil.
Le projet est en retard. Très en retard. La date de mise en ligne est passée il y a des mois. L'équipe est frustrée. La direction pose des questions difficiles.
Et personne ne sait comment réparer.
On a sauvé des dizaines de projets Business Central ratés. Les problèmes sont toujours différents. Mais le schéma est toujours le même.
Voici comment on les répare.
Étape 1 : Arrêter et évaluer
Le premier réflexe quand un projet échoue ? Travailler plus dur. Aller plus vite. Ajouter plus de monde.
Ça empire tout.
Quand on reprend un projet cassé, on fait l'inverse. On arrête. On évalue. On comprend ce qui est vraiment cassé.
Ce qu'on cherche :
Problèmes de périmètre. Le projet essaie d'en faire trop ? Les besoins changent encore chaque semaine ? Quelqu'un sait vraiment à quoi ressemble la réussite ?
Dette technique. Combien de code personnalisé existe ? C'est documenté ? Ça marche ? Quelqu'un peut le maintenir ?
Trous dans les processus. Les processus métier sont clairs ? Ou l'équipe construit un logiciel pour automatiser le chaos ?
Ruptures de communication. L'IT parle au métier ? Quelqu'un décide ? Qui possède quoi ?
Problèmes de ressources. L'équipe a les bonnes compétences ? Ils sont débordés ? Des personnes critiques manquent ?
Ça prend une à deux semaines. Pas de code. Pas de construction. Juste comprendre ce qui a déraillé.
La plupart des consultants sautent cette étape. Ils foncent direct pour corriger les symptômes. C'est pour ça que les tentatives de sauvetage ratent.
Étape 2 : Prendre des décisions dures
Une fois qu'on sait ce qui est cassé, on décide. Des trucs difficiles.
C'est là que la plupart des projets de sauvetage échouent. Parce que personne ne veut réduire le périmètre. Personne ne veut jeter du travail. Personne ne veut admettre que le plan initial était mauvais.
Mais on ne peut pas réparer des fondations cassées en construisant plus vite dessus.
Ce qu'on coupe :
Les fonctions sympas mais pas essentielles. Tout ce qui n'est pas critique pour la mise en ligne passe en phase deux. Sans exceptions.
Le mauvais code personnalisé. Si des personnalisations causent des problèmes et ne sont pas critiques, on les supprime. On démarre avec le standard.
Les processus cassés. Si un processus métier n'a pas de sens, on corrige le processus d'abord. Pas le logiciel.
Les besoins flous. Si personne ne peut expliquer pourquoi quelque chose est nécessaire, ça dégage. Clarté d'abord.
Ce qu'on garde :
Les fonctions métier essentielles. Le minimum pour faire tourner l'entreprise. Finance. Ventes. Achats. Stock. Rien de fantaisiste.
Des données propres. De bonnes données de base. Des transactions claires. Un paramétrage correct. C'est non négociable.
Les intégrations qui marchent. Seulement celles qui sont vraiment requises. Tout le reste attend.
Cette phase prend une semaine. À la fin, vous avez un plan clair. Tout le monde sait ce qui est dedans et ce qui est dehors.
Étape 3 : Exécuter avec discipline
Maintenant on construit. Mais autrement.
Plus de dérive du périmètre. Plus de changements de dernière minute. Plus de construction sans tests.
Comment on travaille :
Périmètre fixe. Ce qu'on a convenu à l'étape deux, c'est ce qu'on construit. Rien ne s'ajoute sans retirer autre chose.
Démos hebdomadaires. Chaque vendredi, on montre du logiciel qui marche. De vraies fonctions. De vrais progrès. Pas de PowerPoint.
Tester au fur et à mesure. Rien ne passe à la phase suivante sans être testé. Par de vrais utilisateurs. Avec de vraies données.
Tout documenter. Chaque décision. Chaque changement. Chaque contournement. Plus de connaissance tribale.
Former tôt. Les utilisateurs voient le système des semaines avant la mise en ligne. Ils pratiquent. Ils trouvent des problèmes. On les corrige.
Cette phase prend deux à quatre mois selon la taille du projet. À la fin, vous mettez en ligne. Pour de vrai cette fois.
Ce qui fait que ça marche
Trois choses font réussir les projets de sauvetage :
Engagement de la direction. Quelqu'un de senior doit porter le résultat. Prendre des décisions dures. Tuer les vaches sacrées. Sans ça, rien ne change.
Honnêteté brutale. Pas d'enjolivement. Pas de faire semblant. Si quelque chose est cassé, on le dit. Si une décision est mauvaise, on la change.
Discipline plutôt que vitesse. On ne se précipite pas. On ne coupe pas les coins. On fait bien. C'est en fait plus rapide que de mal faire deux fois.
Quand appeler à l'aide
Vous avez besoin d'un sauvetage si :
Votre date de mise en ligne est passée et vous n'êtes toujours pas en ligne.
Votre équipe travaille nuits et week-ends mais rien ne s'améliore.
Les besoins continuent de changer et personne ne peut dire non.
Le code personnalisé casse plus vite que vous ne pouvez le corriger.
Les utilisateurs menacent de démissionner s'ils doivent utiliser le nouveau système.
Si vous voyez ces signaux, arrêtez de creuser. Le trou ne va pas devenir moins profond.
On a sauvé des projets qui étaient six mois en retard. Douze mois au-dessus du budget. À leur troisième cabinet de conseil.
C'est réparable. Mais vous devez d'abord admettre que c'est cassé.