Insegnata dal vivo, sul vostro modello, da chi ha costruito la cosa.

Da mezza giornata a una giornata, con nella stanza le persone che prendono le decisioni. Che cosa si vede:

• Mappare le decisioni. Che cosa si sceglie davvero nella vostra azienda, da parte di chi, in quale finestra — e quali di queste vengono ridiscusse ogni mese perché nessuno ha scritto che erano chiuse.
• Che cosa fissa ciascuna. Una decisione che non fissa nulla a valle non è una decisione; una decisione di cui nessuno ha calcolato le conseguenze è una speranza.
• Dalla decisione al driver alla cifra. Come una scelta diventa un driver, e un driver diventa una riga del P&L — e perché un piano costruito al contrario non può rispondere a «perché si è mosso questo».
• Il plan of record. Contro che cosa si misura, chi può ridefinirne la baseline, e che cosa smette di significare lo scostamento quando può farlo chiunque.
• Lo switchover e la chiusura. Dove finisce il consuntivo e comincia la discussione.
• Scenari che sono argomenti, non copie. Una sola decisione cambiata, tenuta accanto alla base, con la conseguenza derivata invece che digitata.

Uscite con una mappa delle decisioni del vostro processo di pianificazione. Se poi diventerà un modello in Superiora è un’altra domanda, e diremo noi quando la risposta è no.

Da due a tre sessioni, con le mani sulla tastiera, costruendo un modello vero invece di guardarne uno. Che cosa si vede:

• Il vocabolario — dimensioni, gerarchie, hypercube, misure, sottoinsiemi, proprietà — e perché la grana di un cubo è la prima decisione, e quella cara da cambiare.
• Le formule — il DSL, l’allineamento delle dimensioni, aggregazione e lookup, le funzioni di tempo, e la lettura dell’errore che il verificatore vi restituisce quando una formula non entra nella forma del modello.
• Il calendario e le versioni — anni fiscali, lo switchover, consuntivo contro previsione, e che cosa si congela una volta che esistono dati.
• Far entrare i dati — CSV ed Excel con una mappatura chiesta a partire dalla destinazione, una sorgente Postgres, e import salvati che si rieseguono a mano o secondo una pianificazione.
• I changeset e il ritmo della scrittura — mettere in staging un insieme di modifiche, vederne l’impatto, applicarle come una sola revisione, e tornare indietro.
• Accessi e chiusura — ruoli, accesso dimensionale, bloccare un periodo e che cosa un blocco rifiuta.
• Rileggere il modello — il «why this value» dell’ispettore di cella, la traccia delle dipendenze, e trovare tutto ciò che si romperebbe prima di una rinomina.
• Spaces — board, viste salvate, grafici, e un board pack che si stampa e si esporta.

Una sessione, ed è quella su cui si arriva più scettici. Che cosa si vede:

• Che cos’è davvero l’interfaccia. Il modello esposto su MCP con strumenti veri — leggere il modello e la sua mappa, percorrere il grafo semantico, tracciare le dipendenze di una formula, trovare tutto ciò che fa riferimento a una cosa, calcolare che cosa raggiunge una modifica di dimensione, verificare un cambiamento, applicarlo e registrare il perché — più una riga di comando che condivide lo stesso vocabolario.
• Perché è ancorata. Un agente legge la struttura stessa del modello invece di indovinarla da una descrizione, così una modifica che propone viene verificata contro il grafo prima di essere applicata.
• I varchi tengono. Un agente è un utente con un ruolo. Un periodo bloccato lo rifiuta. Un permesso di accesso dimensionale lo rifiuta. Le sue scritture atterrano nel registro di audit sotto la sua identità, non la vostra.
• Che cosa delegare — tirare su e rimodellare la struttura, costruire scenari e baseline, la routine mensile di import, notifiche e pack.
• Che cosa non delegare — la decisione stessa. La piattaforma mostra quanto costa ogni sua versione; a firmarla è una persona.
• Rivedere il lavoro di un agente, che è l’abilità che va davvero insegnata: leggere un changeset prima di applicarlo, con accanto l’anteprima dell’impatto.