Chaque plateforme de planification est vendue avec une belle histoire de go-live, et la plupart sont vraies. Ce que les histoires omettent, c’est l’année deux : le backlog de demandes de changement que personne ne trie, la seule personne qui comprend le modèle qui s’en va, les contournements qui se propagent parce que la voie officielle est lente. Rien de tout cela n’est une défaillance d’outil. C’est l’absence d’un operating model, ce qu’est précisément un centre d’excellence, débarrassé de son grand nom.
Les quatre missions d’un CoE planification
- Gestion de la demande. Un point d’entrée unique pour les demandes de changement, triées chaque semaine au regard d’une feuille de route visible. L’objectif n’est pas la bureaucratie ; c’est que le demandeur le plus bruyant cesse d’être le mécanisme de priorisation de fait.
- Intendance des modèles. Quelqu’un possède l’architecture de chaque modèle : sa conception dimensionnelle, son budget de performance, sa documentation. Les changements qui tordent l’architecture sont signalés avant d’être construits, pas découverts dans une crise de performance deux ans plus tard.
- Discipline de release. Les changements structurels circulent dev → test → production à une cadence autour de laquelle le métier peut s’organiser. En langage Anaplan, une vraie pratique ALM ; en langage Pigment, un usage discipliné des environnements et des restructurations versionnées. Des voies de hotfix existent et sont rares par conception.
- Montée en compétence. Le CoE forme et certifie les power-users fédérés, maintient la bibliothèque de patterns (comment nous modélisons les allocations, comment nous gérons le change, comment nous nommons les choses), et anime la communauté qui empêche la connaissance de se concentrer dans une seule tête.
Dimensionnement : plus petit que ne le disent les éditeurs, plus senior que ne le prévoient les clients
Pour un parc d’un à trois modèles, le régime permanent est typiquement de deux à quatre personnes : un lead qui possède la feuille de route et les relations avec les parties prenantes, un ou deux model builders, et un data engineer à temps partiel partagé avec l’équipe data. Ce que l’équipe doit être, c’est senior. Un CoE doté de juniors devient une file de tickets ; un CoE avec un praticien réellement senior devient l’endroit où vit vraiment la stratégie de plateforme.
Fédéré, central ou hybride
Les CoE purement centraux créent des goulots et du ressentiment ; la fédération pure crée douze modèles incompatibles. Le pattern qui survit, c’est le hub-and-spoke : le CoE possède l’architecture, les standards, les releases et la fondation data partagée ; des power-users intégrés dans chaque business unit possèdent leurs vues, leurs rapports et les petits changements structurels dans le cadre de garde-fous publiés. Le document de garde-fous fait deux pages, pas quarante, ce que les spokes peuvent changer librement, ce qui nécessite une revue, ce qui est interdit.
Mesurer si ça marche
- Temps de cycle des demandes de changement, jours médians de l’entrée à la production, en baisse.
- Santé du processus de prévision, taux de soumission dans les délais, nombre de contournements hors plateforme (comptez les tableurs ; ils sont la vérité).
- Bus factor, chaque modèle a au moins deux personnes capables de le modifier sans risque.
- Profondeur d’adoption, planneurs actifs en proportion des sièges sous licence, exécutions de scénarios par cycle.
Nous montons généralement un CoE en parallèle de la seconde moitié d’une implémentation, transférons la propriété progressivement sur deux à trois mois, et restons sur un retainer léger pour les revues d’architecture. L’objectif est explicite : notre propre sortie. Une plateforme qui a besoin de son intégrateur pour toujours n’est pas une capacité, c’est une dépendance avec un logo.
