Enseignée en direct, sur votre propre modèle, par ceux qui ont construit l’outil.

D’une demi-journée à une journée, avec dans la salle ceux qui prennent les décisions. Au programme :

• Cartographier les décisions. Ce qui se choisit réellement dans votre entreprise, par qui, dans quelle fenêtre — et lesquelles se rediscutent tous les mois parce que personne n’a écrit qu’elles étaient tranchées.
• Ce que chacune verrouille. Une décision qui ne fixe rien en aval n’est pas une décision ; une décision dont personne n’a calculé les conséquences est un espoir.
• De la décision à l’inducteur, et de l’inducteur au chiffre. Comment un choix devient un inducteur, et un inducteur une ligne du P&L — et pourquoi un plan bâti dans l’autre sens ne sait pas répondre à « pourquoi cela a-t-il bougé ».
• Le plan of record. Ce à quoi l’on se mesure, qui a le droit de le rebaser, et ce que l’écart cesse de vouloir dire quand tout le monde le peut.
• Le switchover et la clôture. Là où les réalisés s’arrêtent et où le débat commence.
• Des scénarios qui sont des arguments, pas des copies. Une seule décision changée, tenue à côté de la base, avec la conséquence dérivée plutôt que saisie.

Vous repartez avec une carte des décisions de votre propre processus de planification. Savoir si elle devient un modèle dans Superiora est une autre question, et nous le dirons quand la réponse est non.

Deux à trois sessions, les mains dedans, à construire un vrai modèle plutôt qu’à en regarder un. Au programme :

• Le vocabulaire — dimensions, hiérarchies, hypercubes, mesures, sous-ensembles, propriétés — et pourquoi la maille d’un cube est la première décision, et celle qui coûte cher à changer.
• Les formules — le DSL, l’alignement des dimensions, l’agrégation et la recherche, les fonctions temporelles, et la lecture de l’erreur que le vérificateur vous rend quand une formule ne tient pas dans la forme du modèle.
• Le calendrier et les versions — les exercices fiscaux, le switchover, le réalisé face à la prévision, et ce qui est figé dès que des données existent.
• Faire entrer les données — CSV et Excel avec un mappage demandé cible d’abord, une source Postgres, et des imports enregistrés que vous relancez à la main ou selon un calendrier.
• Les changesets et le rythme d’écriture — préparer un ensemble de modifications, en voir l’impact, les appliquer en une seule révision, et revenir en arrière.
• L’accès et la clôture — les rôles, l’accès dimensionnel, le verrouillage d’une période et ce qu’un verrou refuse.
• Relire le modèle — le « pourquoi cette valeur » de l’inspecteur de cellule, la trace des dépendances, et trouver tout ce qui casserait avant un renommage.
• Spaces — les boards, les vues enregistrées, les graphiques, et un board pack qui s’imprime et s’exporte.

Une session, et celle devant laquelle on arrive le plus sceptique. Au programme :

• Ce qu’est réellement l’interface. Le modèle exposé par MCP avec de vrais outils — lire le modèle et sa carte, parcourir le graphe sémantique, tracer les dépendances d’une formule, trouver tout ce qui référence un objet, calculer ce qu’atteint un changement de dimension, vérifier une modification, l’appliquer, et consigner pourquoi — plus une ligne de commande qui partage le même vocabulaire.
• Pourquoi il est ancré. Un agent lit la structure même du modèle plutôt que de la deviner à partir d’une description, si bien qu’un changement qu’il propose est vérifié contre le graphe avant d’être appliqué.
• Les barrières tiennent. Un agent est un utilisateur avec un rôle. Une période verrouillée le refuse. Un droit d’accès dimensionnel le refuse. Ses écritures atterrissent dans le journal d’audit sous sa propre identité, pas sous la vôtre.
• Ce qu’il faut déléguer — dresser et remodeler la structure, construire les scénarios et les références, la routine mensuelle des imports, des notifications et des board packs.
• Ce qu’il ne faut pas déléguer — la décision elle-même. La plateforme montre ce que coûte chacune de ses versions ; c’est une personne qui la signe.
• Relire le travail d’un agent, qui est la compétence qu’il faut vraiment enseigner : lire un changeset avant de l’appliquer, et l’aperçu d’impact posé à côté.