Prima di iniziare: cosa serve davvero per implementare FinOps

Il primo errore da evitare consiste nel considerare FinOps come un progetto esclusivamente
tecnologico. Una piattaforma può raccogliere dati, costruire dashboard e segnalare anomalie, ma non può decidere autonomamente chi debba assumersi la responsabilità di una spesa, quale compromesso sia accettabile o quale risultato debba essere privilegiato.

L’implementazione richiede quattro elementi che devono avanzare insieme:
persone, processi, informazioni e tecnologia. Se uno di questi elementi
rimane indietro, il programma rischia di produrre report sofisticati senza generare
decisioni concrete.

Uno sponsor riconoscibile

FinOps deve avere uno sponsor capace di risolvere conflitti, assegnare responsabilità e
collegare il programma agli obiettivi aziendali. Lo sponsor può essere il CIO, il CFO,
il CTO, il responsabile della trasformazione digitale o un altro dirigente con una
visione trasversale.

La scelta dipende dalla struttura organizzativa, ma lo sponsor deve poter intervenire
sia sulle funzioni tecnologiche sia sui processi finanziari. Una sponsorizzazione puramente
formale raramente è sufficiente.

Un problema aziendale chiaramente definito

Un programma FinOps non dovrebbe partire dalla richiesta generica di “ridurre i costi”.
È preferibile individuare un problema misurabile, per esempio:

• spesa cloud non attribuita a prodotti o business unit;
• forecast poco attendibili;
• ambienti di sviluppo che rimangono attivi senza necessità;
• crescita imprevedibile dei costi legati all’intelligenza artificiale;
• scarso utilizzo degli impegni di spesa acquistati;
• difficoltà nel calcolare il costo unitario di un servizio;
• assenza di responsabilità chiare tra finance, IT e product team.

La definizione di un problema concreto permette di selezionare le capability iniziali,
stabilire un punto di partenza e verificare se il programma sta producendo valore.

Una baseline iniziale

Prima di introdurre nuovi processi occorre documentare la situazione di partenza:
spesa complessiva, percentuale di costi allocati, accuratezza delle previsioni, numero
di account, provider utilizzati, strumenti esistenti e responsabilità già definite.

Come utilizzare il FinOps Framework

Il FinOps Framework definisce un linguaggio comune per organizzare persone, attività, obiettivi e misure di successo. Non è una metodologia rigida e non richiede di implementare contemporaneamente ogni suo componente.

Il framework deve essere utilizzato come una mappa. L’organizzazione seleziona le aree
più importanti in base alla propria strategia, alla complessità dell’ambiente tecnologico
e ai problemi che intende risolvere.

Principi

I principi definiscono il modo in cui le persone devono collaborare e prendere decisioni.
Tra gli elementi centrali rientrano responsabilità condivisa, tempestività dei dati,
centralizzazione della governance e distribuzione delle azioni operative.

Personas

Le FinOps Personas rappresentano gruppi di stakeholder coinvolti nell’utilizzo, nel controllo o nella direzione della spesa tecnologica. Non corrispondono necessariamente a singoli ruoli
aziendali: una persona può coprire più personas e una stessa persona può essere
rappresentata da numerosi professionisti.

Domini e capability

I domini raggruppano i risultati che una pratica FinOps deve perseguire. Le capability del FinOps Framework descrivono invece le attività funzionali che permettono di raggiungerli.

Ogni capability comprende definizioni, stakeholder principali, metriche e attività.
Alcune organizzazioni inizieranno dall’allocazione dei costi, altre dal forecasting,
dall’ottimizzazione dei workload, dalla gestione delle tariffe o dalla costruzione
di una cultura FinOps.

Misure di successo

Il framework non considera il risparmio come unica misura di successo. Un programma
può produrre valore migliorando la prevedibilità, rendendo attribuibili i costi,
accelerando le decisioni, riducendo il rischio o aumentando l’efficienza di un prodotto.

Modello di maturità

Il modello Crawl, Walk, Run permette di far evolvere ciascuna capability
secondo il valore richiesto dall’organizzazione. Non è necessario raggiungere il livello
più avanzato in ogni area.

Per una panoramica in italiano è disponibile anche la documentazione Microsoft sul FinOps Framework

Come costruire il team FinOps

Il modello organizzativo deve essere proporzionato alla complessità dell’impresa.
Una piccola organizzazione può iniziare con un gruppo virtuale composto da poche persone.
Una realtà internazionale può aver bisogno di un FinOps team centrale, referenti locali,
responsabili di prodotto e specialisti dedicati.

In entrambi i casi è utile adottare un modello a due livelli:

1. un nucleo centrale, che definisce standard, dati, strumenti,
   policy e modalità di misurazione;
2. una rete distribuita, che applica le decisioni nei team tecnici,
   nei prodotti e nelle business unit.

Il nucleo centrale FinOps

Il gruppo centrale non dovrebbe diventare il proprietario esclusivo dei costi cloud.
Il suo compito consiste nel rendere gli altri team capaci di comprendere e governare
la spesa.

Tra le responsabilità principali rientrano:

• definizione della tassonomia aziendale;
• normalizzazione dei dati provenienti dai provider;
• gestione delle dashboard e degli strumenti;
• definizione di KPI e report;
• coordinamento dei cicli di forecast;
• supporto alle attività di ottimizzazione;
• gestione delle policy;
• formazione dei team;
• monitoraggio della maturità.

La rete di FinOps champion

I FinOps champion sono referenti inseriti nei team tecnici o di business.
Conoscono il contesto locale, aiutano a interpretare i dati, verificano le anomalie
e coordinano gli interventi.

Questa rete riduce la distanza tra chi produce i report e chi può modificare
effettivamente un’architettura, un’applicazione o una modalità di utilizzo.

La crescita di competenze finanziarie nei team tecnologici è approfondita anche
nell’articolo Data Manager Le competenze FinOps nella corsa all’innovazione cloud

Ruoli e responsabilità in una pratica FinOps

Le responsabilità devono essere definite prima di introdurre dashboard e alert.
In caso contrario, l’organizzazione rischia di individuare numerose opportunità
senza sapere chi debba valutarle o implementarle.

Utilizzare una matrice RACI

Per le attività più importanti può essere utile costruire una matrice RACI,
distinguendo chi è responsabile dell’esecuzione, chi risponde del risultato,
chi deve essere consultato e chi deve essere informato.

La matrice può coprire attività come tagging, forecasting, gestione delle anomalie,
acquisto di commitment, approvazione delle eccezioni e spegnimento delle risorse.

Le fasi di implementazione di FinOps

Un percorso efficace può essere organizzato in sette fasi. Le attività possono
sovrapporsi, ma la sequenza aiuta a evitare che strumenti e automazioni vengano
introdotti prima di aver chiarito obiettivi e responsabilità.

1. Definire obiettivi e perimetro

Il programma deve specificare provider, account, business unit, prodotti e tipi
di costo inclusi. Un perimetro iniziale limitato è spesso preferibile a un progetto
globale difficile da controllare.

Per esempio, un’impresa può iniziare dal principale provider cloud e da due prodotti
digitali ad alta crescita, rimandando a una fase successiva SaaS, data center e altri
ambienti tecnologici.

2. Costruire la baseline

La baseline descrive la situazione iniziale attraverso dati quantitativi e qualitativi:
spesa, qualità dell’allocazione, strumenti, tempi di reporting, accuratezza del forecast
e livello di partecipazione dei team.

3. Rendere visibili e attribuibili i costi

L’organizzazione deve collegare il consumo a proprietari, prodotti, ambienti e finalità.
Questo passaggio può richiedere tagging, gerarchie di account, mapping, regole di
allocazione e gestione dei costi condivisi.

4. Stabilire un ritmo operativo

FinOps diventa concreto quando entra nel calendario aziendale. È necessario definire
incontri, revisioni, responsabilità e scadenze ricorrenti.

5. Individuare le prime opportunità

Le prime azioni dovrebbero essere comprensibili, misurabili e realizzabili:
eliminazione di risorse orfane, spegnimento degli ambienti non produttivi,
rightsizing e correzione di errori di configurazione evidenti.

6. Integrare FinOps nel ciclo di sviluppo

Dopo i primi risultati, il controllo economico deve entrare nei processi di progettazione,
sviluppo e rilascio. Il costo non deve essere scoperto soltanto in produzione.

7. Automatizzare in modo selettivo

L’automazione deve essere introdotta quando regole, responsabilità e soglie sono
sufficientemente stabili. Automatizzare un processo non ancora compreso rischia
di moltiplicarne gli errori.

Dati, tagging e allocazione dei costi

Una pratica FinOps dipende dalla qualità delle informazioni. Se una parte rilevante
della spesa non può essere collegata a un proprietario o a un prodotto, le dashboard
mostreranno il problema senza renderlo governabile.

Definire una tassonomia comune

L’organizzazione deve concordare quali dimensioni utilizzare per classificare i costi.
Una tassonomia essenziale può comprendere:

• business unit;
• centro di costo;
• prodotto o servizio;
• applicazione;
• ambiente;
• proprietario tecnico;
• proprietario economico;
• cliente o progetto;
• requisito di compliance;
• data di scadenza della risorsa.

La tassonomia deve rimanere sufficientemente semplice da essere applicata. Un sistema
troppo articolato può produrre numerosi valori incompleti o incoerenti.

Il tagging non è l’unica soluzione

I tag sono utili, ma non tutti i costi possono essere classificati attraverso di essi.
Alcuni servizi richiedono gerarchie di account, subscription, folder, progetti,
namespace, mapping o regole di allocazione indiretta.

È quindi preferibile definire una strategia di allocazione multilivello, anziché
affidarsi a un unico meccanismo.

Gestire i costi condivisi

Network, sicurezza, piattaforme dati e servizi centrali possono essere utilizzati
da numerosi prodotti. L’organizzazione deve decidere se mantenerli in un centro
di costo condiviso o distribuirli secondo driver come consumo, numero di utenti,
ricavi, transazioni o utilizzo delle risorse.

Showback e chargeback

Lo showback informa i team sui costi attribuiti senza trasferirli formalmente
sul loro budget. Il chargeback assegna invece la spesa alla funzione o al
prodotto responsabile.

Lo showback rappresenta spesso un punto di partenza più prudente, perché permette
di verificare la qualità dell’allocazione prima di produrre conseguenze contabili.

I processi operativi da introdurre

Il valore di FinOps non deriva dalla quantità di report prodotti, ma dalla frequenza
con cui quei report generano decisioni e azioni verificabili.

Revisione settimanale delle anomalie

Le variazioni improvvise devono essere analizzate quando sono ancora correggibili.
La revisione dovrebbe distinguere crescita prevista, errore, incidente, cambiamento
architetturale e nuova domanda di business.

Revisione mensile della spesa

Finance, FinOps e responsabili tecnici confrontano consuntivo, budget e forecast.
L’obiettivo non è soltanto spiegare gli scostamenti, ma aggiornare le decisioni future.

Sessioni di ottimizzazione

I team tecnici valutano raccomandazioni, rischi, dipendenze e possibili interventi.
Ogni opportunità dovrebbe avere un proprietario, una stima del beneficio e una scadenza.

Revisione degli impegni commerciali

Reserved capacity, savings plan e altri commitment devono essere confrontati con
l’andamento effettivo della domanda. Un impegno non utilizzato può trasformare
uno sconto teorico in un costo aggiuntivo.

FinOps nelle architecture review

Le revisioni architetturali dovrebbero includere stime di costo, scalabilità,
variabilità e costo unitario. La documentazione Microsoft sulla capability

Architecting for Cloud

collega esplicitamente le scelte architetturali alle attività FinOps.

La necessità di scegliere l’ambiente più adatto a ciascun workload è approfondita
anche nell’articolo Data Manager Ottimizzare i costi cloud, una necessità improrogabile

Il modello di maturità FinOps: Crawl, Walk, Run

Il FinOps Maturity Model utilizza i livelli Crawl, Walk e Run. L’obiettivo non è
assegnare un voto complessivo all’azienda, ma valutare il livello raggiunto nelle
singole capability.

Un’organizzazione può essere avanzata nell’allocazione dei costi e ancora iniziale
nel forecasting. Questa situazione non rappresenta necessariamente un problema:
maturità e investimento devono essere coerenti con il valore aziendale atteso.

Crawl: costruire le fondamenta

Nel livello iniziale l’organizzazione crea una prima versione del processo.
Le attività sono spesso manuali, ma devono produrre dati utili e responsabilità
riconoscibili.

Esempi di obiettivi Crawl:

• attribuire la maggior parte della spesa a proprietari noti;
• creare una dashboard condivisa;
• definire una prima tassonomia;
• istituire una revisione mensile;
• correggere le inefficienze più evidenti;
• stabilire KPI iniziali.

Walk: rendere i processi ripetibili

Nel livello intermedio la pratica viene estesa a più team, una parte delle attività
viene automatizzata e le metriche diventano più affidabili.

Esempi di obiettivi Walk:

• automatizzare la verifica dei metadati obbligatori;
• migliorare l’accuratezza del forecast;
• introdurre showback o chargeback;
• monitorare l’esecuzione delle azioni di ottimizzazione;
• integrare i costi nelle architecture review;
• coinvolgere stabilmente product owner e procurement.

Run: governare dinamicamente

Nel livello avanzato i processi sono integrati nelle attività quotidiane. I team
possono prendere decisioni rapide, gli interventi ripetitivi vengono automatizzati
e il costo viene collegato a metriche di prodotto e valore.

Esempi di obiettivi Run:

• allocazione quasi completa della spesa;
• forecast continuamente aggiornati;
• policy automatizzate e gestione delle eccezioni;
• cost allocation multicloud normalizzata;
• ottimizzazione basata sul costo unitario;
• integrazione tra FinOps, GreenOps, DevOps e product management.

Una ricerca del Politecnico di Milano sul Cloud Financial Management propone a sua volta un modello qualitativo per valutare la maturità delle pratiche finanziarie cloud e individuare gap coerenti con la complessità della trasformazione intrapresa.

KPI e misure di successo per FinOps

I KPI devono riflettere gli obiettivi iniziali. Misurare soltanto il risparmio
può incentivare interventi che riducono la spesa ma peggiorano prestazioni,
affidabilità o capacità di innovazione.

Misurare i risparmi in modo credibile

È necessario distinguere tra risparmio teorico, costo evitato e riduzione effettiva.
Una raccomandazione non implementata non dovrebbe essere presentata come beneficio
realizzato.

• Risparmio realizzato:
  riduzione verificabile rispetto a una baseline.
• Costo evitato:
  incremento futuro che non si è verificato grazie a un intervento.
• Opportunità identificata:
  beneficio potenziale ancora da validare o attuare.

Questa distinzione aumenta la fiducia tra team tecnici, finance e management.

Gli errori più comuni nell’implementazione di FinOps

1. Comprare uno strumento prima di definire il processo

Le piattaforme accelerano attività già comprese. Non sostituiscono ownership,
tassonomia, priorità e governance.

2. Affidare FinOps soltanto a finance

Finance può spiegare budget e scostamenti, ma molte opportunità richiedono
competenze architetturali e conoscenza dei workload.

3. Affidare FinOps soltanto all’IT

I team tecnici possono ottimizzare le risorse, ma non sempre dispongono delle
informazioni necessarie per valutare valore, marginalità e priorità aziendali.

4. Cercare esclusivamente risparmi immediati

Una riduzione aggressiva può compromettere resilienza, prestazioni o capacità
di sviluppo. Le decisioni devono bilanciare costo e valore.

5. Costruire troppe dashboard

Ogni report dovrebbe rispondere a una domanda, avere un destinatario e generare
una possibile azione. La quantità di visualizzazioni non è un indicatore di maturità.

6. Non assegnare un proprietario alle azioni

Le raccomandazioni senza responsabile, beneficio stimato e scadenza rimangono
spesso irrealizzate.

7. Pretendere una maturità uniforme

Non tutte le capability richiedono lo stesso livello di automazione o investimento.
La maturità deve essere proporzionata al rischio e al valore.

8. Ignorare il cambiamento culturale

Rendere visibili i costi può essere percepito come una forma di controllo punitivo.
La comunicazione deve chiarire che FinOps serve a migliorare le decisioni,
non a limitare indiscriminatamente l’autonomia dei team.

L’importanza della collaborazione interfunzionale, dell’automazione e di una cultura
basata sui dati è approfondita nell’articolo Data Manager FinOps: la bussola strategica per navigare i costi del cloud

Un piano FinOps per i primi 90 giorni

Il seguente piano rappresenta un esempio generale. Tempi e attività devono essere
adattati alla dimensione, ai provider e alla qualità dei dati disponibili.

Risultati realistici dei primi tre mesi

Nei primi 90 giorni l’organizzazione non dovrebbe aspettarsi una trasformazione
completa. Può però ottenere risultati fondamentali:

• linguaggio comune tra tecnologia e finance;
• visibilità condivisa su una parte significativa della spesa;
• prime responsabilità formalizzate;
• backlog delle opportunità;
• processo di revisione ricorrente;
• prime azioni completate e misurate;
• roadmap coerente con le priorità aziendali.

FinOps deve diventare un modo di lavorare

Implementare FinOps non significa aggiungere un ulteriore livello di controllo
burocratico. Significa rendere le decisioni tecnologiche economicamente comprensibili
e le decisioni finanziarie più vicine alla realtà operativa.

Il percorso deve partire da obiettivi concreti, dati sufficientemente affidabili
e responsabilità riconoscibili. Il framework offre un linguaggio e una struttura,
ma ogni organizzazione deve selezionare le capability coerenti con il proprio contesto.

Il modello Crawl, Walk, Run permette di iniziare con processi semplici e farli
evolvere quando il valore ottenuto giustifica maggiore automazione, precisione
e complessità.

Il risultato più importante non è una dashboard perfetta. È la capacità di finance,
engineering e business di prendere insieme decisioni migliori sulla tecnologia.

Nella terza parte della guida analizzeremo strumenti, metriche operative e tecniche
di ottimizzazione: rightsizing, scheduling, gestione degli impegni di spesa,
forecasting e controllo delle anomalie.