Le piège de la personnalisation
La plupart des consultants ERP vont construire tout ce que vous demandez.
Vous voulez un champ personnalisé ? C'est parti. Un workflow spécial ? Pas de problème. Un calcul unique ? Banco.
Six mois plus tard, votre système plante pendant une mise à jour. Personne ne sait pourquoi. Le consultant qui l'a fait est parti. Votre équipe est coincée.
C'est pour ça qu'on dit non à la plupart des demandes de personnalisation.
Pas parce qu'on ne peut pas le faire. Parce qu'on sait ce qui va se passer après.
Ce qui casse avec le code personnalisé
La personnalisation semble inoffensive au début. Juste un petit changement pour faciliter les choses.
Mais voici ce qui se passe vraiment :
Les mises à jour cassent tout. Microsoft sort des mises à jour mensuelles pour Business Central. Le code qui marche aujourd'hui peut planter demain. Il faut le tester. Le corriger. Retester.
Plus personne ne sait pourquoi ça existe. Dans trois ans, ce champ personnalisé sera toujours là. Mais la personne qui en avait besoin a quitté l'entreprise. Personne ne sait si c'est encore utilisé.
Ça se propage comme un virus. Un champ personnalisé demande un rapport personnalisé. Ce rapport demande un calcul personnalisé. Ce calcul demande un autre champ. En un rien de temps, vous avez 50 personnalisations au lieu d'une.
Votre équipe ne peut pas le maintenir. Business Central standard ? Votre équipe peut gérer. Des modifications personnalisées ? Elle a besoin d'aide externe à chaque fois que quelque chose va mal.
Quand la personnalisation a du sens
On n'est pas anti-personnalisation. On est anti-personnalisation-stupide.
On a construit des applications personnalisées massives. Un client a plus de 1000 objets personnalisés dans son système Business Central. Ça gère toute sa chaîne logistique biomasse.
Pourquoi on l'a construit ? Parce qu'aucun ERP standard sur terre ne gère la logistique biomasse. L'entreprise en avait vraiment besoin.
Voici quand la personnalisation a du sens :
Votre business fait quelque chose de vraiment unique. Pas différent. Unique. Si vos concurrents rencontrent le même défi, une solution standard existe probablement.
Le ROI est clair. Vous pouvez pointer des gains de revenus ou des économies de coûts spécifiques qui justifient les coûts de construction et de maintenance.
Vous êtes prêt à le maintenir. Le code personnalisé demande des soins. Des mises à jour. Des tests. De la documentation. Si vous n'êtes pas prêt pour ça, ne le construisez pas.
Les options standard ne marchent vraiment pas. Pas juste gênantes. Vraiment impossibles avec les fonctions standard.
Ce qu'on fait à la place
Quand un client demande une personnalisation, on pose des questions :
Pourquoi vous avez besoin de ça ? Souvent le vrai problème est un processus cassé, pas une fonction manquante.
Qu'est-ce que vous voulez vraiment accomplir ? La solution demandée n'est peut-être pas le meilleur chemin vers le vrai objectif.
Vous avez essayé la façon standard ? Business Central a des centaines de fonctions que la plupart des entreprises n'utilisent jamais.
Qu'est-ce qui se passe dans trois ans ? Vous en aurez encore besoin ? Vous vous souviendrez pourquoi vous l'avez fait ?
La plupart du temps, on trouve une meilleure solution. Plus simple. Plus propre. Sans code personnalisé.
Les deux extrêmes qu'on évite
Extrême 1 : Ne rien construire. Certains consultants refusent toute personnalisation. Tout doit être standard. Ça semble malin jusqu'à ce que vos vrais besoins ne rentrent pas dans la boîte standard.
Extrême 2 : Tout construire. D'autres consultants construisent tout ce que vous demandez. Sans questions. Sans contestation. Ça semble orienté client jusqu'à ce que vous vous noyiez dans la dette technique.
On vit au milieu. On sait quand construire 1000 objets et quand en construire zéro.
La plupart des consultants se trompent dans les deux cas.
Ce que ça signifie pour vous
Si vous voulez un consultant qui construit tout ce que vous demandez sans poser de questions, on n'est pas le bon choix.
Si vous voulez un consultant qui challenge votre réflexion, conçoit des systèmes propres, et construit des solutions personnalisées seulement quand elles ont vraiment du sens, on peut discuter.
On construit des systèmes qui tiennent. Pas des systèmes qui cassent.