Chi lavora con Azure in un contesto enterprise sa che la relazione con Microsoft passa quasi sempre da un Enterprise Agreement. È il contratto standard con cui le grandi organizzazioni acquistano i servizi cloud Microsoft: definisce i termini commerciali, i volumi di spesa, gli sconti – ed è la cornice dentro cui tutto il resto si muove.
Insieme al contratto arriva una struttura gerarchica precisa e rigida: Enrollment>Department>Account> Subscription, che non governa solo l’organizzazione amministrativa, ma si riflette direttamente sul modo in cui Azure organizza e presenta la spesa cloud.
L’Enrollment è il contratto master, il contenitore che rappresenta l’accordo commerciale con Microsoft. Sotto di lui vivono i Department, raggruppamenti logici che tipicamente corrispondono a divisioni aziendali o aree geografiche. Dentro i Department ci sono gli Account, che rappresentano spesso un owner o una funzione aziendale. E infine, al livello operativo, le Subscription, dove vivono effettivamente le risorse cloud. Ogni report, ogni export, ogni vista di analisi in Azure Cost Management segue questa stessa logica: la spesa è sempre letta attraverso la lente della gerarchia contrattuale.
Questa struttura ha una logica organizzativa chiara. Il problema è che la realtà operativa di un’azienda raramente combacia con il suo organigramma.
Considerate un esempio concreto: il Prodotto X, le cui risorse sono distribuite su tre subscription diverse.
Azure Cost Management vi mostra quanto spende ogni account e ogni subscription. Non esiste però nessuna vista nativa che risponda alla domanda più semplice e più importante: quanto ci costa il Prodotto X?
Il Prodotto X è una dimensione ortogonale rispetto alla struttura dell’enrollment. Per ricavarne il costo dovete incrociare manualmente i dati delle tre subscription coinvolte, fare stime, costruire report ad hoc. Se le risorse non sono taggate in modo consistente, il risultato è approssimato nel migliore dei casi, inutile nel peggiore.
Questo è il limite strutturale di EA: vi dice quanto spende una funzione, non quanto costa un prodotto.
Senza isolare il costo di un prodotto, l’intera catena analitica si rompe.
Se il Prodotto X costa 50.000€ al mese con 10.000 utenti attivi, il costo per utente è 5€. Se il trimestre scorso erano 8.000 utenti con una spesa di 48.000€, il costo per utente era 6€: l’efficienza è migliorata, nonostante la spesa assoluta sia cresciuta. Ma se non riuscite a isolare quei 50.000€ dalla spesa complessiva delle tre subscription, quel ragionamento non potete nemmeno iniziarlo.
Avete un numero grezzo, non un indicatore. E un numero grezzo non vi dice se il vostro prodotto è sostenibile, se scala bene o se sta bruciando margine.
È esattamente su questo che la disciplina FinOps sta insistendo con sempre maggiore forza: la capacità di calcolare il costo unitario, il costo per utente, per transazione, per richiesta API, per qualsiasi unità di misura abbia senso per il vostro prodotto. Il costo unitario è il ponte tra la spesa cloud e il business: non vi dice solo quanto state spendendo, ma quanto vi costa produrre valore.
È la differenza tra sapere che la bolletta cloud è cresciuta del 20% e sapere se quella crescita è un problema o un segnale di salute.
La transizione a MCA: più flessibilità contrattuale, stesso problema operativo
Il Microsoft Customer Agreement cambia la struttura gerarchica: Billing Account>Billing Profile>Invoice Section>Subscription. È un miglioramento reale rispetto a EA, e su alcuni fronti la differenza è sostanziale.
In conclusion Billing Profile permettono di separare fatture e metodi di pagamento per entità legali o divisioni diverse, che in EA richiedeva enrollment separati.
The Invoice Section consentono di raggruppare le subscription in modo più granulare all’interno dello stesso profilo di fatturazione, avvicinando la struttura contrattuale alla realtà organizzativa dell’azienda.
In più, MCA offre maggiore flessibilità nella gestione dei ruoli e dei permessi di accesso ai dati di costo, rendendo più semplice distribuire la visibilità sulla spesa ai team che ne hanno bisogno senza dover intervenire sulla struttura dell’enrollment.
Ma è importante essere chiari su una cosa: MCA migliora la flessibilità contrattuale e amministrativa, non la granularità dell’allocazione operativa dei costi. Il Prodotto X continua a non esistere come dimensione nella gerarchia MCA, esattamente come non esisteva in EA. Le sue risorse sono ancora distribuite su più subscription, e nessun contratto – per quanto flessibile – può aggregarle al posto vostro. Il costo unitario del Prodotto X rimane impossibile da calcolare esattamente come prima.
MCA sposta la flessibilità sulla fatturazione. Il problema dell’allocazione operativa rimane dov’era.
La buona notizia è che la transizione contrattuale è il momento ideale per fermarsi, ridisegnare la governance dei tag e costruire una base dati coerente su cui fare analisi significative. Chi coglie questa opportunità arriva a MCA non solo con un contratto più moderno, ma con una capacità di lettura della spesa cloud che in EA non aveva mai avuto.
A questo si aggiunge una complicazione nuova: i dati storici EA e i dati MCA hanno formati diversi. Le colonne dei file di export si chiamano diversamente, alcune spariscono, altre appaiono. Se avete costruito dashboard, report o automazioni basate sul formato EA, dovete ricominciare.
Il timing peggiora le cose. La transizione a MCA potrebbe richiedere di negoziare un nuovo commitment con Microsoft, ovvero decidere quanta spesa cloud vi impegnate a sostenere in anticipo in cambio di sconti. Per farlo bene dovete capire con precisione la natura della vostra spesa storica: quali workload sono stabili e prevedibili, quali sono variabili, dove c’è margine di ottimizzazione.
Se i vostri dati storici sono frammentati, in formati incompatibili e con tag inconsistenti, rischiate di gonfiare il commitment su workload che potreste ottimizzare o di sottostimarlo su quelli che crescono. In entrambi i casi, state negoziando al buio. Ne abbiamo parlato in modo approfondito in questo articolo.
Rendere compatibili i dati EA e MCA senza strumenti dedicati è un lavoro manuale di data engineering: esportate i file CSV, mappate le colonne, gestite i campi senza corrispondenza diretta, normalizzate date, valute e unità di misura. È fattibile, ma è lento, soggetto a errori e non scala.
In questo scenario, i tag delle risorse sono l’unico elemento che attraversa entrambi i formati – EA e MCA – in modo coerente. Un tag product: prodotto-x applicato su una risorsa nella Subscription A vale tanto in EA quanto in MCA. È il filo che tiene insieme i dati storici e quelli futuri, indipendentemente dal formato contrattuale.
Ma i tag da soli non bastano. Il problema non è tecnico: applicare un tag su una risorsa Azure richiede pochi secondi. Il problema è strategico: senza una tassonomia condivisa e governata, ogni team tagga a modo suo. Qualcuno usa product, qualcun altro usa Product o prodotto. Qualcuno compila il campo, qualcun altro lo lascia vuoto. Il risultato è una base dati frammentata che non potete aggregare in modo affidabile, e su cui qualsiasi analisi di costo unitario è destinata a produrre numeri deboli che non potete portare in una riunione di business.
È qui che entra in gioco FOCUS – FinOps Open Cost and Usage Specification – lo standard aperto sviluppato dalla FinOps Foundation per normalizzare i dati di costo cloud. FOCUS definisce uno schema comune e condiviso: nomi di colonna standardizzati, tipi di dato uniformi, dimensioni obbligatorie. Questo schema comprende la gestione dei tag delle risorse in modo coerente e indipendentemente dal provider e dal tipo di contratto.
Con FOCUS, i vostri tag smettono di essere metadati sparsi su formati incompatibili e diventano una dimensione analitica strutturata: i dati EA storici e i dati MCA futuri parlano lo stesso linguaggio, e qualsiasi strumento compatibile con lo standard li legge allo stesso modo.
Il primo passo – prima di qualsiasi migrazione, prima di qualsiasi analisi – è quindi definire una tassonomia di tag solida coerente con lo schema FOCUS. Non è un lavoro tecnico, è un lavoro strategico. E come ogni lavoro strategico, richiede di coinvolgere le persone giuste: il team Finance, che sa come è strutturato il piano dei conti e quali sono i centri di costo rilevanti; il team Procurement, che gestisce i contratti e conosce le dimensioni su cui vuole riconciliare la spesa; i team di Prodotto, che sanno come sono organizzati i prodotti e quali etichette hanno senso operativamente. Senza questo allineamento, la tassonomia che producete riflette il punto di vista di chi l’ha definita e viene ignorata da tutti gli altri.
Le domande a cui rispondere insieme sono:
Senza queste risposte, qualsiasi strumento di analisi produce output parziali. Con queste risposte, avete una base su cui costruire tutto il resto.
La domanda più comune dei clienti quando iniziamo a collaborare sulla tassonomia dei tag è: da dove si comincia? La risposta onesta sarebbe quella preferita dal consulente (“Dipende!”) ma esistono alcune dimensioni che ricorrono quasi universalmente nelle organizzazioni che gestiscono spesa cloud in modo strutturato.
La prima è il digital product o il servizio: il tag che, in puro spirito ITIL Version 5, risponde alla domanda “a quale prodotto digitale o servizio appartiene questa risorsa?”. È la dimensione che sblocca il costo unitario (per utente, per transazione, per richiesta API) e che permette di portare la spesa cloud in una conversazione di business. Necessaria ma non sufficiente, senza di essa tutto il resto è contorno.
La seconda è l’ambiente: production, staging, quality, development, testing. Sembra ovvia, ma è spesso la prima a mancare in termini di compilazione. Queste distinzioni hanno grosse implicazioni a livello di licensing perché ambienti diversi richiedono licenze diverse. Inoltre, senza questa distinzione non riuscite a separare la spesa operativa reale da quella dei team di sviluppo e qualsiasi ottimizzazione diventa un’operazione a rischio: non sapete cosa potete spegnere e cosa no.
La terza è il team o centro di costo: chi è responsabile operativamente di quella risorsa? Questa dimensione è il ponte tra la spesa cloud e il piano dei conti aziendale. Permette al team Finance di riconciliare la bolletta cloud con i budget interni senza dover ricostruire manualmente i centri di responsabilità. È il tag irrinunciabile per ogni practice di IT Financial Management.
A queste tre si aggiungono, a seconda del contesto e del business, dimensioni come il cliente (fondamentale per chi eroga servizi SaaS) oppure il progetto, la commessa o la release, utili per tracciare la spesa legata a iniziative temporanee senza creare subscription dedicate.
Ricordiamoci che queste dimensioni non sono indipendenti: si combinano. Una risorsa ben taggata porta con sé tutte le informazioni sopracitate. È quella combinazione che rende i dati analizzabili: potete rispondere non solo a “quanto ci costa il Prodotto X?” ma a “quanto ci costa il Prodotto X in produzione, gestito dal team Platform, nel mese di marzo?“. È la differenza tra il dato e la conoscenza.
At WEGG lavoriamo ogni giorno come consulenti ITAM e FinOps, e una delle cose di cui siamo più convinti è che la transizione da EA a MCA non sia solo un cambio contrattuale, ma sia il punto di partenza ideale per mettere a terra una governance solida della spesa cloud.
I limiti nativi di Azure Cost Management sono reali. Le sue viste di analisi sono ancorate alla struttura contrattuale e per quanto MCA offra più flessibilità rispetto a EA, non risolve il problema dell’allocazione operativa né quello della discontinuità dei dati storici. È qui che entra in gioco la tecnologia del nostro partner Flexera.
Il nostro lavoro inizia prima ancora di accendere uno strumento: affianchiamo i team Finance, Procurement e Prodotto nella definizione della tassonomia di tag, traducendo le esigenze di business in uno schema coerente con FOCUS e sostenibile operativamente nel tempo. Una volta definita la tassonomia, non ci fermiamo al presente, la implementiamo retroattivamente sui dati storici, classificando la spesa EA pregressa secondo le stesse dimensioni con cui leggerete quella MCA futura.
È onesto essere chiari su una cosa: i primi risultati non saranno perfetti. I dati storici hanno lacune, i tag mancanti si possono inferire ma non sempre con precisione assoluta e alcune quote di spesa resteranno non allocate. Ma non è questo il punto.
Il valore non sta nella perfezione del dato iniziale, sta nel fatto che da quel momento in poi avete un sistema che funziona. Ogni risorsa creata viene taggata, ogni mese che passa la base dati diventa più completa, ogni trimestre la lettura della spesa per prodotto, per team, per ambiente diventa più affidabile. È un processo che si affina nel tempo, e che ad ogni rinnovo contrattuale vi mette in mano qualcosa di più prezioso: un commitment negoziato non su stime, ma su dati reali.
Flexera Cloud Cost Optimization si connette tramite API ad Azure Cost Management, sia per i dati EA che per quelli MCA, normalizza tutto verso uno schema compatibile con FOCUS e permette di applicare regole di classificazione retroattive sulle risorse storiche. Se una risorsa non era taggata due anni fa, potete definire regole del tipo “tutte le risorse il cui nome contiene ‘prodotto-x’ le assegno al cost center X” e applicarle allo storico già importato, riducendo drasticamente la quota di spesa non allocata.
Il risultato è una base dati unificata, normalizzata, storicamente coerente ed è esattamente quello che serve per affrontare la fase più delicata della transizione: la negoziazione del MACC, il Microsoft Azure Consumption Commitment. Con una governance solida alle spalle, quella negoziazione non è più un’approssimazione, è una scelta informata. Ed è un percorso che affianchiamo direttamente, portando al tavolo sia la competenza contrattuale che la visibilità sulla spesa.
Il tagging e la governance dei costi cloud non sono glamour. Non finiscono su una slide di board. Sono lavoro di trincea – definire standard, applicare regole, convincere i team a taggare le risorse prima di crearle – e come tutto il lavoro di trincea, il suo valore si vede solo quando smettete di farlo o quando non lo avete mai fatto.
Le organizzazioni che hanno una lettura chiara della propria spesa cloud non ci sono arrivate per caso. Ci sono arrivate perché a un certo punto qualcuno ha deciso che navigare a vista costava più del lavoro necessario per smettere di farlo. Non è una questione tecnica, è una scelta culturale. Significa decidere che la spesa cloud non è una utility da pagare a fine mese, ma una leva di business da governare attivamente.
La transizione da EA a MCA è uno di quei momenti in cui quella scelta diventa concreta. Potete attraversarla come un cambio contrattuale. Oppure potete usarla come punto di partenza per costruire una governance che nei prossimi anni vi darà una visibilità sulla spesa che oggi non avete. La differenza non sta nel contratto. Sta in quello che decidete di fare prima di firmarlo.
Ne parliamo nel dettaglio nel webinar del 15 aprile. Vi aspettiamo.
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
