Un premier go-live Anaplan oblige à faire un choix : quel processus mérite de passer en production maintenant, et quelles décisions doivent rester ouvertes ? Un périmètre réduit peut rendre le résultat plus vite utilisable. Il peut aussi masquer un travail reporté sur les utilisateurs si les données, les responsabilités et la gestion des exceptions restent hors du projet.
Notre recommandation : définir une première version autour d’une décision métier complète. Les utilisateurs doivent pouvoir partir de données identifiées, modifier les hypothèses autorisées, examiner les écarts et produire un résultat accepté. Ce périmètre peut être petit ; son fonctionnement doit être explicite.
Choisir un cycle que l’équipe pourra réellement terminer
« Mettre la prévision dans Anaplan » laisse trop de place à l’interprétation. Une formulation plus utile serait : « Chaque mois, les responsables d’une famille de produits revoient la prévision sur un marché, font arbitrer les exceptions et transmettent une version approuvée à la supply chain. »
Cette formulation rend visibles les acteurs, la fréquence, les entrées et la sortie. Elle permet aussi de dire ce qui attendra : d’autres marchés, une granularité supplémentaire ou une méthode de calcul plus élaborée. Le périmètre du premier cycle devient testable.
Déterminer les fondations minimales
Construire toutes les possibilités futures dès le départ consomme du temps sans garantir leur utilité. Certaines décisions structurantes méritent néanmoins d’être prises avant d’accumuler les fonctionnalités.
| Décision | À rendre explicite dès le départ | Extension possible ensuite |
|---|---|---|
| Données | Source, propriétaire, identifiants, contrôles et fréquence du premier cycle. | Automatisation d’un flux supplémentaire, après stabilisation de son contrat de données. |
| Modèle | Maille de décision, calendrier, principales dimensions et règles de calcul. | Cas d’usage ou niveau de détail supplémentaire dont le besoin reste à confirmer. |
| Utilisateurs | Qui saisit, qui consulte, qui approuve ; traitement d’une absence ou d’une exception. | Extension à d’autres équipes avec leurs règles d’accès. |
| Exploitation | Responsable du cycle, procédure de correction et critères d’acceptation. | Indicateurs et routines supplémentaires lorsque le premier cycle fonctionne. |
Un import manuel peut être un choix de départ acceptable si son responsable, ses contrôles et sa fréquence sont définis. Il devient une fragilité si personne ne sait comment reconnaître une donnée manquante, corriger une erreur ou reprendre le cycle.
Un exemple : limiter la couverture, conserver le cycle
Exemple illustratif, sans résultat client revendiqué. Une entreprise souhaite harmoniser ses prévisions sur plusieurs marchés. Le premier lot couvre un marché et une famille de produits. Il inclut le chargement des ventes, la revue des hypothèses, une liste d’exceptions et l’approbation de la prévision.
L’équipe reporte l’extension géographique et un calcul plus avancé des promotions. Elle conserve les identifiants communs, le calendrier de planification et la distinction entre historique, hypothèse et version approuvée. Elle teste ainsi une routine complète avant de l’étendre.
À l’inverse, livrer uniquement un écran de saisie agréable alors que l’arbitrage et la consolidation restent dans des fichiers séparés impose encore un parcours fragmenté. Le périmètre paraît plus court, mais le passage en production n’a pas encore résolu le problème annoncé.
Écrire les critères de go-live avant la démonstration finale
- Le propriétaire métier peut exécuter le cycle défini et expliquer le résultat.
- Les données du périmètre sont rapprochées d’une référence acceptée, avec une tolérance explicitée.
- Les utilisateurs représentatifs disposent des accès et des instructions nécessaires.
- Une exception connue et une erreur de chargement ont été testées avec leur procédure de reprise.
- Chaque élément reporté possède une raison, une conséquence et un responsable d’arbitrage.
Ces critères sont à adapter au projet. Ils permettent surtout de distinguer une démonstration réussie d’un cycle que l’organisation est prête à exploiter.
Ce que le premier lot doit apprendre au programme
Après le premier cycle, examiner ce qui a demandé une intervention imprévue : données, compréhension des règles, droits ou validations. Ces observations doivent alimenter le lot suivant. Une roadmap devient plus crédible lorsqu’elle peut expliquer ce qui est confirmé, ce qui reste hypothétique et ce qui vient d’être révisé.
Le cadrage du premier lot doit donc relier valeur métier, disponibilité des données et capacité d’exploitation. Pour prolonger cette réflexion : les fondations data d’un projet EPM et la décomposition du coût d’un projet Anaplan.
