Quatre signes qu'un projet Anaplan dérive

Les projets Anaplan échouent rarement bruyamment. Ils dérivent, et les symptômes sont visibles des mois avant que le mot ne soit prononcé.
Quatre collaborateurs en réunion autour d'une table de travail

Quand un client nous appelle pour un modèle en difficulté, la dérive est en général visible depuis deux trimestres. Personne ne l'a ignorée : elle n'a simplement jamais franchi le seuil qui oblige à agir. Voici les quatre signaux que nous rencontrons le plus souvent. Chacun a un correctif peu coûteux tôt, et un correctif cher tard.

1. Une seule personne peut modifier le modèle

Demandez qui peut ajouter un line item au module central sans risque. Si la réponse tient en un nom - interne ou côté intégrateur - vous n'avez pas une plateforme de planification, vous avez une dépendance. C'est le signal le plus grave parce qu'il s'auto-renforce : le propriétaire unique devient trop occupé pour documenter, ce qui le rend encore plus indispensable. Le correctif précoce, c'est un deuxième constructeur formé sur le vrai modèle. Le correctif tardif, c'est la rétro-ingénierie d'un système dont l'auteur est parti.

2. Le cycle finit encore sous Excel

Regardez ce qui se passe après la réunion de planification. Si les chiffres sont exportés, ajustés hors ligne puis diffusés par mail, la plateforme est un entrepôt de données, pas un système de planification. En général une chose précise manque - une vue, un droit, un calcul que le modèle ne sait pas faire - et le contournement est devenu le processus. Identifiez la capacité manquante et construisez-la. Si personne ne sait la nommer, c'est un constat en soi : le modèle a été bâti pour un processus qui n'existe pas.

3. Le scope grossit sans rien mettre en production

Les modules se multiplient, le go-live recule, et chaque nouveau besoin est parfaitement légitime. C'est le signal le plus difficile socialement, parce que tout le monde se comporte bien. La discipline qui le corrige est impopulaire et simple : choisir un cycle de planification, le mettre en production avec ses vrais utilisateurs, et refuser tout le reste tant qu'il ne tourne pas. Un cycle en production et cru par tous fait plus avancer la discussion que quatre modules en recette.

4. Les excuses de performance deviennent permanentes

« C'est lent en fin de mois » commence comme un constat et devient une propriété admise du système. Les utilisateurs s'adaptent en planifiant autour - moins de scénarios, moins de rafraîchissements - et le modèle façonne le processus au lieu de le servir. La lenteur est un résultat de conception : sparsité, ordre des dimensions, forme des calculs. Elle se diagnostique et se corrige généralement sans refonte, mais seulement tant que les gens s'en plaignent encore. Le jour où ils se taisent, vous avez perdu le signal.

Par où commencer

Prenez le signal que vous reconnaissez et testez-le cette semaine : demandez qui peut modifier le modèle, ou assistez au prochain cycle et regardez où vont réellement les chiffres. La plupart de ces situations se rattrapent sans refonte si elles sont prises pendant que l'équipe d'origine est encore joignable. Notre practice Anaplan traite cela en une évaluation de deux à trois jours aboutissant à un diagnostic écrit, et le document vous reste dans tous les cas.

À lire ensuite