- Cos’è una baseline operativa?
- Quali costi misurare prima dell’automazione?
- Come distinguere ROI reale e risparmio teorico?
Il ROI comincia prima dell’AI
Quando un progetto di automazione promette di ridurre tempi e costi, la prima domanda non dovrebbe essere «quanto risparmieremo?», ma «quanto ci costa davvero oggi questo processo?». Senza una risposta credibile, il confronto nasce già deformato. Il rischio è chiamare ROI una sottrazione costruita su tempi medi incompleti, costi standard e volumi che non distinguono i casi semplici dalle eccezioni.
Nel Service Desk la distorsione è frequente. Il costo visibile comprende licenze, persone e fornitore; quello reale include attese, passaggi tra gruppi, contatti ripetuti, escalation, rilavorazioni, indisponibilità e tempo sottratto all’utente. Se questi elementi non entrano nella baseline, l’automazione sembra conveniente prima ancora di essere misurata.
La baseline non è quindi una fotografia amministrativa. È il punto zero condiviso dal quale osservare se l’AI ha eliminato lavoro, lo ha spostato oppure lo ha reso meno visibile.
Una baseline seria misura il processo, non soltanto il ticket
Il ticket è un contenitore utile, ma non coincide con il lavoro necessario a ripristinare il servizio. Due richieste con la stessa categoria possono avere percorsi completamente diversi: una si chiude al primo contatto, l’altra attraversa più assegnazioni, attende informazioni, genera un secondo contatto e richiede una correzione.
Per questo la baseline dovrebbe combinare almeno cinque dimensioni. Volume e mix della domanda descrivono che cosa entra. Tempo end-to-end e tempo effettivamente lavorato separano attesa e attività. First contact resolution e ricorrenze mostrano la qualità della soluzione. Escalation e rilavorazioni evidenziano il lavoro che ritorna. Eccezioni e varianti raccontano quanto il processo sia davvero standardizzabile.
Il process mining può aiutare perché rende visibili varianti, colli di bottiglia, percorsi lenti e tassi di errore. Ma lo strumento non sostituisce la domanda manageriale: quali eventi rappresentano valore, quali sono spreco e quali sono controlli necessari?
Dal costo medio al costo per outcome
Il costo medio per ticket può essere utile per leggere una tendenza, ma è troppo grossolano per valutare un’automazione. Un contatto chiuso velocemente ma destinato a riaprirsi non ha lo stesso valore di una remediation verificata. La metrica più utile è il costo per outcome riuscito: costo complessivo del percorso diviso per il numero di risultati realmente verificati.
Nel numeratore devono entrare lavoro umano, piattaforme, consumo AI, integrazioni, supervisione, controllo, escalation e rollback. Nel denominatore non vanno contate semplici risposte o esecuzioni, ma casi in cui l’utente può riprendere il lavoro e il problema non ricompare entro una finestra coerente con il servizio.
La FinOps Foundation definisce il unit cost come il costo allocato a un’unità incrementale e misurabile di prodotto o servizio. Applicato all’ITSM, il principio invita a scegliere unità legate al valore: dispositivo ripristinato, accesso correttamente abilitato, richiesta completata senza rilavorazione.
Prima misurare, poi standardizzare, infine automatizzare
La sequenza è importante. Automatizzare prima di comprendere le varianti cristallizza regole fragili e moltiplica le eccezioni. Misurare permette invece di distinguere il percorso dominante dai casi marginali; standardizzare chiarisce input, output, responsabilità e criteri di successo; automatizzare interviene soltanto dove il processo è abbastanza stabile e il rischio è governabile.
Standardizzare non significa forzare ogni richiesta nello stesso percorso. Significa rendere esplicito ciò che può essere replicato e ciò che richiede giudizio. Le eccezioni devono avere un proprietario, una soglia e un fallback. Se rimangono nascoste, riappariranno come escalation e cancelleranno il margine previsto.
Il risultato è un catalogo di automazioni più maturo: prerequisiti, volumi, confini, dati ammessi, outcome, costo unitario, controllo richiesto e condizioni di arresto. Non una vetrina di demo, ma un portafoglio di capacità operative.
La baseline deve restare confrontabile
Una baseline perde valore se il perimetro cambia durante il confronto. Prima e dopo devono usare la stessa definizione di domanda, la stessa finestra temporale e gli stessi criteri di successo. Se dopo l’automazione escludiamo le escalation oppure misuriamo soltanto il canale digitale, il miglioramento è apparente.
Serve anche segmentare. Canale, servizio, sede, tipologia di utente, complessità e livello di autonomia possono cambiare radicalmente il risultato. L’aggregato nasconde sia i casi di successo sia quelli in cui l’AI aumenta il lavoro. Una buona service review mostra distribuzioni e varianti, non soltanto medie.
Infine la baseline va aggiornata, ma non riscritta per giustificare il progetto. Conservare definizioni, fonti e assunzioni permette di spiegare perché una metrica è cambiata e di evitare che il business case diventi mobile quanto l’obiettivo.
Una scorecard che porta a una decisione
La baseline utile deve condurre a una scelta. Propongo una scorecard sintetica con otto righe: volume comparabile, tempo end-to-end, tempo lavorato, costo per outcome, ricorrenze, rilavorazioni, eccezioni ed esperienza dell’utente. A queste si aggiungono, dopo l’introduzione dell’AI, costo del controllo, tasso di intervento umano e rollback.
La decisione non è sempre «scalare». Può essere semplificare il processo, migliorare la knowledge, rimuovere una causa radice, ridurre l’autonomia o interrompere l’automazione. Misurare serve proprio a non confondere l’investimento tecnologico con il risultato.
La conclusione è netta: se non conosciamo il costo reale del processo attuale, non possiamo dimostrare il valore del processo futuro. Prima si misura, poi si standardizza e infine si automatizza. Solo allora il ROI smette di essere teorico e diventa una decisione verificabile.
Fonti e approfondimenti
- NIST — AI RMF Core, funzione Measure — consultato il 17 agosto 2026 ↗
- NIST — AI RMF Playbook — aggiornato 10 giugno 2026 ↗
- NIST — AI Metrology Center — consultato il 17 agosto 2026 ↗
- FinOps Foundation — Capability: Unit Economics — consultato il 17 agosto 2026 ↗
- FinOps Foundation — Terminology: Unit Cost, Unit Metrics e Activity Based Costing — consultato il 17 agosto 2026 ↗
- Microsoft Learn — Process mining integration in process map — 2026 ↗
Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.