
Blog
Come calcolare il ROI (ritorno sull'investimento) di un software personalizzato
ROI onesto: baseline, costo pieno, scenari prudenti e gate a 90 giorni.
di Giuseppe Foggetti
Software Engineer & AI Solutions Developer — Foggetti Studio
Il ROI di un software si racconta spesso con slide ottimistiche. In riunione tutti annuiscono. A novanta giorni i numeri veri arrivano tardi, o non arrivano. Nel frattempo avete già pagato licenze, ore interne e un pezzo di pazienza del team.
Un calcolo onesto parte dal processo reale: baseline di tempo e errori, costo pieno dell'MVP (tool + persone + formazione), benefici prudenti, payback con buffer. Poi un gate di revisione — non una speranza.
Baseline, costo pieno, scenari
Misura una settimana tipo sul processo pilota. Conta ore, rilavorazioni, mancate risposte. Stima il costo pieno: non solo canone, ma setup, dati, formazione, supporto. Fai due scenari: prudente e base. Se solo lo scenario ottimista «chiude», non chiude.
Fissa KPI di revisione a trenta e novanta giorni. Se l'adozione è bassa, il ROI non è un problema di Excel: è un problema di processo. Correggi quello prima di ampliare lo scope.
Formazione che resta
Sessioni brevi sui casi veri del team. Una checklist a portata di mano. Un super-user per area nei primi quindici giorni. Evita corsi da catalogo che finiscono in un attestato e zero cambiamento nel martedì successivo.
Come si capisce se state migliorando
Non moltiplicare i cruscotti. Scegli pochi indicatori legati al processo che state toccando — in tema di calcolare il ROI, di solito bastano tempo ciclo, qualità in uscita e adozione del flusso ufficiale. Fissa la baseline nella settimana zero. Rivedi a trenta giorni. Se i numeri non si muovono, cambia processo e input prima di cambiare tool.
Dopo il pilota: allargare senza perdere il filo
Amplia solo se il KPI primario è migliorato, l'adozione supera la soglia concordata, il backlog delle eccezioni è sotto controllo e l'owner è ancora in carica. Altrimenti riduci lo scope o rafforza formazione. Una riunione ogni due settimane basta: numeri, eccezioni top, decisioni. Niente status theater.
Documenta il mapping o le regole del percorso felice in una pagina viva. Quando qualcuno nuovo entra nel team, quella pagina evita tre settimane di oralità. La governance leggera non è burocrazia: è memoria operativa.
Fornitori e confini
Se entra un fornitore esterno, chiarisci chi possiede configurazioni, prompt, mapping e log. Evita dipendenze opache. Un buon partner lascia l'azienda più autonoma a novanta giorni, non più legata a ticket eterni per cambiare una regola.
Un dettaglio che fa la differenza
Blocca in calendario il tempo di lavoro sul pilota. Senza slot dedicati il progetto resta «tra una cosa e l'altra» e non parte mai davvero. Il responsabile operativo aggiorna lo stato ogni settimana in cinque minuti: fatto, bloccato, prossimo passo. È poco elegante. Funziona.
Cosa lasciare volutamente fuori
Il primo rilascio non è il momento di dimostrare tutto ciò che lo strumento può fare. Lascia fuori funzioni senza owner, integrazioni verso sistemi poco usati, automazioni su eccezioni rare e report estetici non collegati a una decisione. Allargare dopo i numeri è coraggio. Allargare prima è ansia mascherata da ambizione.
Dati sporchi, risultati sporchi
Se anagrafiche e input sono disordinati, qualsiasi automazione o modello linguistico amplifica il disordine. Dedica un blocco esplicito a una pulizia minima sul perimetro MVP: duplicati, campi obbligatori, valori fuori range. Non è lavoro «di IT». È lavoro di verità operativa.
Dati sporchi, risultati sporchi
Se anagrafiche e input sono disordinati, qualsiasi automazione o modello linguistico amplifica il disordine. Dedica un blocco esplicito a una pulizia minima sul perimetro MVP: duplicati, campi obbligatori, valori fuori range. Non è lavoro «di IT». È lavoro di verità operativa.
Formazione che resta
Sessioni brevi sui casi veri del team. Una checklist a portata di mano. Un super-user per area nei primi quindici giorni. Evita corsi da catalogo che finiscono in un attestato e zero cambiamento nel martedì successivo.
Come si capisce se state migliorando
Non moltiplicare i cruscotti. Scegli pochi indicatori legati al processo che state toccando — in tema di calcolare il ROI, di solito bastano tempo ciclo, qualità in uscita e adozione del flusso ufficiale. Fissa la baseline nella settimana zero. Rivedi a trenta giorni. Se i numeri non si muovono, cambia processo e input prima di cambiare tool.
Dopo il pilota: allargare senza perdere il filo
Amplia solo se il KPI primario è migliorato, l'adozione supera la soglia concordata, il backlog delle eccezioni è sotto controllo e l'owner è ancora in carica. Altrimenti riduci lo scope o rafforza formazione. Una riunione ogni due settimane basta: numeri, eccezioni top, decisioni. Niente status theater.
Documenta il mapping o le regole del percorso felice in una pagina viva. Quando qualcuno nuovo entra nel team, quella pagina evita tre settimane di oralità. La governance leggera non è burocrazia: è memoria operativa.
Fornitori e confini
Se entra un fornitore esterno, chiarisci chi possiede configurazioni, prompt, mapping e log. Evita dipendenze opache. Un buon partner lascia l'azienda più autonoma a novanta giorni, non più legata a ticket eterni per cambiare una regola.
Un dettaglio che fa la differenza
Blocca in calendario il tempo di lavoro sul pilota. Senza slot dedicati il progetto resta «tra una cosa e l'altra» e non parte mai davvero. Il responsabile operativo aggiorna lo stato ogni settimana in cinque minuti: fatto, bloccato, prossimo passo. È poco elegante. Funziona.
Cosa lasciare volutamente fuori
Il primo rilascio non è il momento di dimostrare tutto ciò che lo strumento può fare. Lascia fuori funzioni senza owner, integrazioni verso sistemi poco usati, automazioni su eccezioni rare e report estetici non collegati a una decisione. Allargare dopo i numeri è coraggio. Allargare prima è ansia mascherata da ambizione.
Cosa lasciare volutamente fuori
Il primo rilascio non è il momento di dimostrare tutto ciò che lo strumento può fare. Lascia fuori funzioni senza owner, integrazioni verso sistemi poco usati, automazioni su eccezioni rare e report estetici non collegati a una decisione. Allargare dopo i numeri è coraggio. Allargare prima è ansia mascherata da ambizione.
Dati sporchi, risultati sporchi
Se anagrafiche e input sono disordinati, qualsiasi automazione o modello linguistico amplifica il disordine. Dedica un blocco esplicito a una pulizia minima sul perimetro MVP: duplicati, campi obbligatori, valori fuori range. Non è lavoro «di IT». È lavoro di verità operativa.
Formazione che resta
Sessioni brevi sui casi veri del team. Una checklist a portata di mano. Un super-user per area nei primi quindici giorni. Evita corsi da catalogo che finiscono in un attestato e zero cambiamento nel martedì successivo.
Come si capisce se state migliorando
Non moltiplicare i cruscotti. Scegli pochi indicatori legati al processo che state toccando — in tema di calcolare il ROI, di solito bastano tempo ciclo, qualità in uscita e adozione del flusso ufficiale. Fissa la baseline nella settimana zero. Rivedi a trenta giorni. Se i numeri non si muovono, cambia processo e input prima di cambiare tool.
Dopo il pilota: allargare senza perdere il filo
Amplia solo se il KPI primario è migliorato, l'adozione supera la soglia concordata, il backlog delle eccezioni è sotto controllo e l'owner è ancora in carica. Altrimenti riduci lo scope o rafforza formazione. Una riunione ogni due settimane basta: numeri, eccezioni top, decisioni. Niente status theater.
Documenta il mapping o le regole del percorso felice in una pagina viva. Quando qualcuno nuovo entra nel team, quella pagina evita tre settimane di oralità. La governance leggera non è burocrazia: è memoria operativa.
Fornitori e confini
Se entra un fornitore esterno, chiarisci chi possiede configurazioni, prompt, mapping e log. Evita dipendenze opache. Un buon partner lascia l'azienda più autonoma a novanta giorni, non più legata a ticket eterni per cambiare una regola.
Un dettaglio che fa la differenza
Blocca in calendario il tempo di lavoro sul pilota. Senza slot dedicati il progetto resta «tra una cosa e l'altra» e non parte mai davvero. Il responsabile operativo aggiorna lo stato ogni settimana in cinque minuti: fatto, bloccato, prossimo passo. È poco elegante. Funziona.
Il valore pratico (e il prossimo passo)
Un ROI onesto confronta baseline, costo pieno e scenari prudenti. Il valore pratico è decidere con numeri — non comprare per entusiasmo e scoprire i costi nascosti dopo.
Scrivi baseline di questa settimana, costo a dodici mesi e tre scenari. A novanta giorni fai un go/no-go con i fatti, non con le sensazioni.
Se ti serve un secondo parere sul perimetro del tuo caso, Foggetti Studio può aiutarti a leggere lo stato attuale e a definire un MVP realistico.