Le piège du symptôme
Le client appelle : "On a besoin d'un champ custom pour tracker les retards de livraison."
La plupart des consultants : "Pas de problème, on peut faire ça."
Nous : "Pourquoi vous avez des retards de livraison ?"
Cette question change tout.
Parce que la demande n'est pas le problème. C'est un symptôme. Et si vous traitez les symptômes sans trouver la cause racine, vous perdez du temps et de l'argent à construire des choses qui ne règlent rien.
À quoi ça ressemble de corriger des symptômes
L'entreprise a des livraisons en retard. Donc ils :
- Ajoutent un champ pour tracker les retards
- Créent un rapport qui montre les tendances de retards
- Construisent un dashboard avec des métriques de retards
- Mettent en place des alertes quand il y a des retards
Six mois plus tard : Toujours des livraisons en retard. Mais maintenant ils ont une excellente documentation de tout ce qui est en retard.
Le symptôme a été traité. Le problème, non.
Pourquoi ça arrive
Parce que traiter les symptômes est plus facile que trouver les causes racines.
Construire un champ custom prend deux jours. Découvrir pourquoi les livraisons sont en retard prend deux semaines de conversations inconfortables.
Personne ne veut entendre que :
- Les commerciaux promettent des dates de livraison sans vérifier le stock
- L'entrepôt ne met pas à jour les niveaux de stock en temps réel
- Les achats ne réapprovisionnent pas assez vite
- Le management fixe des délais irréalistes pour gagner des contrats
C'est plus facile de construire des outils de tracking que de réparer des processus cassés.
Donc on track les symptômes au lieu de résoudre les problèmes.
Exemple réel : Le problème de stock
Le client appelle. "On a besoin d'une meilleure visibilité sur les stocks. Construisez-nous un dashboard custom."
On creuse.
Le vrai problème : Ils sont en rupture de stock sur leurs best-sellers tout en ayant six mois de stock mort.
Pourquoi ?
- Aucun niveau de stock minimum défini dans le système
- Les achats commandent au feeling, pas sur la data
- L'équipe commerciale ne vérifie pas le stock avant de promettre une livraison
- Les retours ne sont pas remis en stock correctement
Le dashboard qu'ils voulaient aurait montré le problème clairement. Mais il n'aurait rien réglé.
Ce qui l'a vraiment réglé :
- Définir des niveaux de stock minimum pour tous les articles actifs
- Créer des points de réapprovisionnement automatiques
- Rendre la vérification du stock obligatoire avant de confirmer une commande
- Réparer le processus de retours pour mettre à jour le stock immédiatement
Pas de dashboard custom nécessaire. Juste réparer les processus cassés.
Exemple réel : Le problème de reporting
Le client : "La finance prend deux jours pour générer les rapports de fin de mois. Construisez des rapports plus rapides."
On demande : "Pourquoi ça prend deux jours ?"
Réponse : Parce qu'ils exportent manuellement les données de cinq systèmes différents, réconcilient dans Excel, corrigent les erreurs, et reformattent.
Le vrai problème n'est pas les rapports lents. Ce sont les systèmes déconnectés et les processus manuels.
Ce dont ils avaient vraiment besoin :
- Une vraie intégration entre systèmes (pas des exports Excel)
- Des règles de réconciliation automatisées
- Une source unique de vérité pour les données financières
- Des dashboards temps réel pour que la fin de mois ne soit pas une surprise
Des rapports plus rapides auraient économisé du temps. Réparer le processus a éliminé le problème entièrement.
Exemple réel : La spirale de customisation
L'entreprise a 200+ objets custom dans Business Central. Le système est lent. Les mises à jour cassent des trucs. La maintenance coûte cher.
Leur solution : "Construire plus de code custom pour faire marcher le code custom existant."
On demande : "Pourquoi chaque customisation a été construite ?"
Résultat :
- 40% dupliquent des fonctionnalités standard que personne ne connaissait
- 30% contournent des processus cassés
- 20% ont été construites pour des gens qui ont quitté l'entreprise
- 10% ajoutent vraiment de la valeur
Le symptôme : Le système est lent et difficile à maintenir.
La cause racine : Construire des customisations au lieu de réparer les processus.
Ce qui l'a vraiment réglé : Supprimer 90% du code custom. Réparer les processus. Utiliser les fonctionnalités standard correctement.
Comment trouver les causes racines
Demandez pourquoi. Puis demandez pourquoi encore. Puis continuez à demander jusqu'à ce que vous tombiez sur quelque chose qui n'est pas un autre symptôme.
Exemple de conversation :
"On a besoin d'un champ pour tracker les réclamations clients."
Pourquoi vous devez tracker les réclamations ?
"Parce qu'on en a trop."
Pourquoi vous en avez trop ?
"Parce que les livraisons sont en retard."
Pourquoi les livraisons sont en retard ?
"Parce que la production est en retard."
Pourquoi la production est en retard ?
"Parce que les matières premières arrivent en retard."
Pourquoi les matières premières arrivent en retard ?
"Parce qu'on ne commande que quand on est en rupture."
Maintenant on est à la cause racine : Processus de commande réactif.
Le champ qu'ils demandaient n'aurait rien réglé. Réparer le processus de commande règle tout.
Les cinq symptômes qu'on voit partout
1. "On a besoin de meilleurs rapports"
Ça veut généralement dire : On ne fait pas confiance à nos données, nos processus sont cassés, ou on mesure les mauvaises choses.
Réparez la qualité des données et le processus d'abord. Puis le reporting devient facile.
2. "On a besoin de plus d'automatisation"
Ça veut généralement dire : On fait trop de travail manuel parce que nos processus sont inefficaces.
Réparez le processus d'abord. Puis automatisez le bon processus, pas le cassé.
3. "On a besoin de champs custom"
Ça veut généralement dire : On essaie de tracker quelque chose qui ne devrait pas être tracké, ou les champs standard existent mais personne ne les connaît.
Challengez pourquoi la donnée est nécessaire. Souvent, elle ne l'est pas.
4. "On a besoin d'une meilleure intégration"
Ça veut généralement dire : On a trop de systèmes parce qu'on a acheté des solutions au lieu de réparer les processus.
Consolidez les systèmes d'abord. Puis intégrez ce qui reste.
5. "Les utilisateurs n'adoptent pas le système"
Ça veut généralement dire : Le système ne correspond pas à la façon dont les gens travaillent vraiment, ou le processus est cassé.
Réparez le processus pour matcher la réalité. Puis formez sur le système.
Pourquoi les consultants ne font pas ça
Parce que c'est inconfortable.
Dire à un client "votre processus est cassé" est plus dur que dire "bien sûr, on peut construire ce champ custom."
Trouver les causes racines signifie :
- Challenger ce que les gens vous disent
- Poser des questions inconfortables
- Exposer des problèmes organisationnels
- Dire non à des fonctionnalités demandées
- Prendre plus de temps avant de commencer à construire
La plupart des consultants évitent ça. Ils construisent ce qui est demandé, encaissent leur chèque, et partent avant que le client réalise que rien ne s'est amélioré.
À quoi ressemble le Root Cause Consulting
Le client demande la fonctionnalité X.
On demande pourquoi ils en ont besoin.
On creuse jusqu'à trouver le vrai problème.
Souvent la solution est complètement différente de ce qu'ils demandaient.
Parfois la solution c'est de supprimer des choses, pas d'en construire.
Parfois la solution c'est un changement de processus, pas de logiciel.
Et parfois - rarement - ce qu'ils demandaient est vraiment ce dont ils ont besoin.
Le résultat
Des projets qui règlent vraiment les problèmes au lieu de les documenter.
Des systèmes qui deviennent plus simples au lieu de plus complexes.
Des clients qui peuvent expliquer exactement pourquoi chaque fonctionnalité existe.
Un ROI mesurable parce qu'on a réglé ce qui coûtait de l'argent.
Vous reconnaissez ces symptômes ?
Si votre projet ERP :
- Devient de plus en plus complexe avec le temps
- Ajoute des fonctionnalités qui ne semblent pas aider
- Crée plus de rapports sans résoudre les problèmes
- Construit des customisations pour contourner d'autres customisations
- Coûte cher mais les résultats sont flous
Vous traitez des symptômes, pas des problèmes.
Ce qu'on fait différemment :
- On commence par pourquoi, pas par quoi
- On challenge chaque demande jusqu'à trouver la cause racine
- On dit non aux fonctionnalités qui traitent des symptômes
- On répare les processus avant d'écrire du code
- On mesure les résultats par problèmes résolus, pas par fonctionnalités construites
On ne facture pas à l'heure. On n'est pas payé plus pour construire plus. On est payé pour réparer ce qui est vraiment cassé.
Prêt à arrêter de traiter les symptômes ?
Prenez rendez-vous - on vous dit ce qui est vraiment cassé.