Sette SaaS o un solo sistema? Quando conviene un software su misura

Il SaaS è il modo più economico per partire. Dopo qualche anno, però, un singolo processo commerciale attraversa cinque o sette strumenti e l’azienda finanzia a rate una piattaforma di grandi dimensioni che non ha mai acquistato. Come nasce questa situazione l’abbiamo analizzato nell’articolo La vostra azienda non ha bisogno di più software. Ha bisogno di meno caos. Questo testo non ripete la descrizione del problema: affronta ciò che viene dopo, cioè come decidere e come difendere la decisione con i numeri.

Il confronto software aziendale su misura vs SaaS si può calcolare in modo che il risultato regga davanti alla proprietà e davanti al commercialista. La maggior parte delle aziende, però, decide sulla base dei due numeri che dicono meno di tutti sul costo reale: il canone mensile e la cifra scritta nel preventivo di sviluppo. Entrambi sono soltanto biglietti d’ingresso a diversi anni di esercizio.

Il costo reale non è il canone

Il Total Cost of Ownership, cioè il costo totale di proprietà, è una metodologia che guarda oltre il prezzo di acquisto e conteggia tutto quello che l’acquisizione e l’esercizio continuano a costare. Lisa M. Ellram l’ha descritta a metà degli anni Novanta su casi di studio di undici aziende, e per il software vale come per l’acquisto di materiali: il prezzo è una sola voce, e di norma non quella decisiva.

Che non si tratti di una sfumatura accademica lo mostra la ricerca sui costi di ciclo di vita di trenta sistemi applicativi IT condotta da Rüdiger Zarnekow e Walter Brenner dell’Università di San Gallo. Su un esercizio di cinque anni, i costi ricorrenti di esercizio, supporto, manutenzione e sviluppo successivo rappresentano il 79% dei costi di ciclo di vita. Alla pianificazione e allo sviluppo iniziale spetta il 21%.

La maggior parte delle decisioni su costruire o acquistare viene però presa proprio su quel quinto più piccolo, perché è l’unica parte che compare nel preventivo. Il resto arriva dopo e si dissolve negli stipendi, nel supporto e nel tempo delle persone che in qualche modo risolvono la cosa. Con la stessa affidabilità vengono sottovalutati sia l’esercizio di un sistema proprietario sia l’amministrazione di un pacchetto di abbonamenti che cresce.

Cosa entra davvero nella tabella TCO

La tabella TCO ha due colonne, lo stack di oggi e l’alternativa proposta, e in entrambe le stesse categorie. Altrimenti non state confrontando due soluzioni, ma due modi di tenere la contabilità.

• Licenze, consumo e postazioni inutilizzate. Oltre alla tariffa mensile rientra qui il comportamento del prezzo quando l’azienda cresce. Zylo, nel SaaS Management Index 2026, riporta che il 78% dei responsabili IT ha registrato costi imprevisti su listini a consumo o legati all’AI, che il 61% ha dovuto tagliare altri progetti per un aumento non pianificato della spesa e che le organizzazioni lasciano inutilizzate in media il 36% delle licenze SaaS. La spesa mediana in SaaS per dipendente è quantificata in 9.455 USD e nell’edizione precedente la sua crescita su base annua risultava del 21,9%. Sono dati provenienti da un portafoglio di grandi aziende. Per una piccola impresa vale la direzione, non il valore assoluto.
• Integrazioni e loro manutenzione. Il MuleSoft Connectivity Benchmark Report di Salesforce riporta che l’organizzazione media utilizza 897 applicazioni, che soltanto il 29% di esse è collegato e che i team IT dedicano il 39% del tempo a progettare, costruire e testare integrazioni proprie. Quel tempo è un costo come gli altri, solo che nessuno lo fattura.
• Lavoro umano tra i sistemi. Una ricerca pubblicata da Harvard Business Review ha seguito 137 persone in venti team di tre aziende della classifica Fortune 500. Passavano da un’applicazione o da una finestra all’altra circa 1.200 volte al giorno, ogni passaggio costava poco più di due secondi e la somma è risultata pari a circa il 9% del tempo di lavoro annuo speso a riorientarsi. Nel TCO entra come tariffa oraria moltiplicata per le ore.
• Visibilità sulla propria spesa. Flexera, nello State of ITAM Report 2026, riporta che il 43% delle organizzazioni segnala un aumento su base annua della spesa SaaS sprecata, che per il software AI la quota sale al 59% e che soltanto il 36% ha piena visibilità sul proprio ambiente IT. Senza di essa il TCO non si può calcolare e la decisione è un’ipotesi con una presentazione allegata.

Non tutto conviene sviluppare internamente

Un calendario proprietario, un client di posta o un software contabile su misura sarebbero per la maggior parte delle aziende un investimento privo di senso. La ragione è economica: si tratta di funzioni il cui sviluppo è finanziato da decine di migliaia di clienti contemporaneamente. Eurostat riporta che nel 2025 il 52,7% delle imprese dell’UE utilizzava servizi cloud a pagamento, più spesso per l’e-mail (85,2%) e per il software finanziario o contabile (58,2%). Con una diffusione simile, nessuno riesce a costruirsi da solo un costo unitario paragonabile.

Il software su misura inizia ad avere senso economico dove il processo costituisce un vantaggio competitivo: pricing, gestione della capacità, workflow di vendita, portale clienti o lavoro su un modello dati proprietario. La domanda corretta non è quindi se costruire o acquistare, ma: quale parte del proprio funzionamento è strategico che l’azienda possieda?

Va detto anche quello che di solito un fornitore di sviluppo non dice. Buona parte delle richieste che arrivano con la frase «ci serve un sistema nostro» si può risolvere a costi inferiori: con un audit delle licenze, con una configurazione seria dello strumento che avete già, spostando il processo in un unico sistema esistente invece che in tre, oppure con uno strumento no-code, cioè un ambiente in cui la logica si compone senza programmare. Se il problema si risolve a un decimo del prezzo, lo sviluppo proprietario è la risposta sbagliata. E se è sbagliato il processo stesso, il nuovo software non farà altro che accelerarlo, come abbiamo scritto nel testo L’AI non salva un processo sbagliato.

Spesso vince l’architettura ibrida

Un’architettura moderna non significa programmare tutto da zero. L’azienda mantiene i servizi esterni per pagamenti, e-mail, contabilità o autenticazione e possiede soltanto il layer che governa il proprio processo distintivo, i dati e l’interfaccia.

Il meccanismo è semplice. Il layer proprietario definisce il modello dati, cioè il modo in cui l’azienda chiama la commessa, il cliente, la capacità e il prezzo. Gli altri sistemi diventano così fornitori di funzioni sostituibili, invece che proprietari della verità sull’azienda. La differenza si vede alla seconda sostituzione di uno strumento: cambia l’integrazione, non cambia il processo. Anche l’ibrido, però, ha la sua voce in tabella: le interfacce da mantenere sono di più, non di meno.

«Una tantum» non significa senza costi successivi

Un software proprietario non è un bene che si mantiene da solo. Richiede hosting, monitoraggio, aggiornamenti di sicurezza e sviluppo continuo. La differenza rispetto all’abbonamento sta nel fatto che l’investimento crea un asset sotto il vostro controllo, non nel fatto che i costi ricorrenti spariscano.

A questo si aggiunge il rischio di esecuzione, che nei preventivi di solito non compare. Bent Flyvbjerg e Alexander Budzier hanno analizzato un campione di 1.471 progetti IT e hanno rilevato uno sforamento medio del budget del 27%. Più significativa è la forma della distribuzione: un progetto su sei era un cosiddetto cigno nero, con uno sforamento medio dei costi del 200% e dei tempi di quasi il 70%. Il rischio non sta quindi nella media, ma nella coda, e più grande è il perimetro affrontato in una volta sola, più alta è la probabilità di finirci dentro. Per questo conviene costruire a piccoli passi e ricalcolare dopo ciascuno se il successivo abbia ancora senso.

Un business case su tre-cinque anni

Su un orizzonte di un anno non si può decidere. Nel primo anno la soluzione proprietaria di norma perde: sostiene l’intero investimento e quasi nessun risparmio. Modellate tre-cinque anni e confrontate i costi cumulati, non la prima fattura. Il modello richiede quattro input:

1. La base. Quanto costa lo stack di oggi, incluso il lavoro umano tra i sistemi.
2. La curva di crescita. Come si comporta la base con il doppio dei clienti. Con licenze conteggiate per utente cresce in modo lineare, con un layer proprietario di norma no.
3. L’investimento e il suo esercizio. Non soltanto il prezzo dello sviluppo, ma anche quanto costerà nei cinque anni successivi.
4. Il punto di pareggio. L’anno in cui le curve cumulate si incrociano e che cosa succede se si sposta di dodici mesi.

Esempio modellato. I numeri sono ipotesi scelte per illustrare il calcolo, non misurazioni di un progetto reale. Un’azienda con 40 dipendenti gestisce un processo di commessa attraverso sei strumenti e paga di licenze 2.200 euro al mese, cioè 26.400 euro all’anno. Con una crescita annua del quindici per cento, in tre anni fanno circa 92.000 euro. Il preventivo per il layer proprietario è di 70.000 euro. Se valesse la proporzione dello studio dell’Università di San Gallo, dove lo sviluppo iniziale rappresenta il 21% dei costi quinquennali, la somma su cinque anni si collocherebbe nell’ordine dei 330.000 euro, cioè circa 66.000 euro all’anno.

In questo calcolo contano due cose. La prima è metodologica: 92.000 euro sono un totale a tre anni, 330.000 euro un totale a cinque, e confrontabili sono soltanto periodi di uguale durata. A parità di orizzonte, in questo modello la soluzione proprietaria risulta più costosa, non più conveniente. La seconda è scomoda: le sole licenze risparmiate non coprono una differenza simile. Il business case deve reggersi sulla capacità liberata delle persone, sulla riduzione del tempo di attraversamento della commessa, sugli errori che smettono di verificarsi oppure sul fatturato che lo stack attuale non riesce a servire. Se nulla di tutto questo si riesce a stimare almeno in modo grossolano, il progetto non è pronto per una decisione.

L’investimento, inoltre, non si confronta con lo zero, ma con la migliore alternativa, che di solito è un’assunzione in più. A questo abbiamo dedicato un testo a parte, su se all’azienda serva un sistema oppure una nuova assunzione.

Segnali su quando il software su misura conviene e quando no

Vale la pena fare il calcolo se ricorrono più punti tra questi

• Il processo in questione è la fonte del vostro vantaggio competitivo, non un adempimento amministrativo.
• Il costo cresce in modo lineare con il numero di persone o di transazioni, mentre il beneficio dello strumento non cresce.
• Il fornitore ha cambiato il modello di prezzo oppure ha eliminato una funzione su cui si regge il vostro processo.
• La vostra offerta ai clienti è limitata da quello che lo strumento consente, non da quello che il mercato chiede.

È la risposta sbagliata se ricorre anche uno solo di questi

• Si tratta di una funzione commodity, che un servizio pronto risolve altrettanto bene.
• L’azienda non ha ancora fatto un audit delle licenze e non sa con precisione quanto e per che cosa paga oggi.
• I requisiti cambiano ogni mese e nessuno riesce a fissarli nemmeno per un trimestre.
• In azienda non esiste una persona che dopo la consegna prenda in carico il sistema e ne sia responsabile.

I costi di uscita non sono più un’incognita. Almeno nell’UE

Nel TCO rientra anche quanto costa andarsene. Fino a poco tempo fa questa voce non era quantificabile, e così se ne ricavava un argomento fatalista del tipo «tanto siamo in trappola dal fornitore». La regolamentazione ha cambiato le cose. Secondo la Commissione europea il Data Act, cioè il regolamento (UE) 2023/2854, è applicabile dal 12 settembre 2025 e agevola il trasferimento dei dati e il passaggio tra fornitori cloud. L’analisi giuridica dello studio Latham & Watkins aggiunge che gli obblighi valgono per IaaS, PaaS e SaaS e che dall’11 gennaio 2024 i fornitori possono addebitare i costi di passaggio soltanto come ribaltamento dei costi diretti, senza margine. Dal 12 gennaio 2027 saranno vietati del tutto.

Le conseguenze sono due e non puntano nella stessa direzione. Il prezzo dell’uscita scende, quindi scegliere un servizio pronto è meno rischioso, perché uno strumento scelto male si può sostituire. Allo stesso tempo scende la barriera al trasferimento dei dati su infrastruttura propria, il che rende più economica anche la strada verso una soluzione proprietaria. Nella tabella TCO serve quindi una riga con il prezzo e il formato dell’export. Si può testare oggi, non al momento della separazione.

La decisione tra sistema proprietario e abbonamento non è una questione di gusto tecnologico, ma di quale parte del proprio funzionamento l’azienda voglia possedere e se saprà pagarla anche tra tre anni. La risposta non si può chiedere a un fornitore di software: conosce la propria offerta, non i vostri numeri. Il primo passo non è la scelta della tecnologia, ma la diagnosi: quanto costa oggi il vostro stack, quanto lavoro umano genera intorno a sé e quale sua parte è una commodity.

Cosa portarsi a casa

• Confrontate il costo totale di proprietà, non il canone né il prezzo dello sviluppo. Secondo lo studio dell’Università di San Gallo, lo sviluppo iniziale rappresenta soltanto un quinto dei costi quinquennali di un’applicazione.
• Modellate tre-cinque anni e cercate il punto di pareggio, con entrambe le opzioni sullo stesso orizzonte.
• Prima di costruire qualsiasi cosa, fate un audit delle licenze e un consolidamento. Se il problema si risolve a un decimo del prezzo, lo sviluppo proprietario è la risposta sbagliata.
• Possedete il processo che vi distingue e acquistate quello che è commodity. L’architettura ibrida è spesso un compromesso più ragionevole di entrambi gli estremi.
• Il rischio di un progetto IT sta nella coda, non nella media. Costruite a passi piccoli e utili già di per sé.