Software enterprise: costruire o acquistare nel 2026

Elena Marchetti Responsabile strategia di prodotto, YuSMP Group · Architettura di piattaforme enterprise e procurement software per clienti italiani, europei e statunitensi

TL;DR — la decisione in 60 secondi

La decisione enterprise build vs buy non è binaria. Ecco il framework in sintesi:

• Acquistate quando la capacità è una commodity, esiste un mercato SaaS maturo e il workflow non è un fattore di differenziazione competitiva.
• Costruite quando la capacità è una fonte diretta di ricavi o vantaggio operativo, quando la conformità richiede la sovranità dei dati, o quando il debito di integrazione tra più strumenti SaaS ha raggiunto livelli inaccettabili.
• Il modello ibrido è la risposta per la maggior parte delle grandi imprese: acquistate gli strati commodity (identity, pagamenti, comunicazioni) e costruite il core differenziante e l’orchestrazione dell’integrazione.
• Il TCO a 5 anni rende quasi sempre il build più conveniente di quanto appaia nel solo anno 1 — soprattutto quando si modella il pricing per postazione SaaS alla crescita dell’organico enterprise.

Perché questa decisione è diversa su scala enterprise

Per una PMI da 50 persone, una scelta build vs buy sbagliata è recuperabile. Si spende troppo tempo o denaro, si cambia rotta, si va avanti. Per una grande impresa con 2.000 postazioni, integrazioni ERP consolidate e un requisito di audit trail che si estende su sette anni, una scelta sbagliata significa remediation pluriennale, esposizione normativa e responsabilità del management.

Su scala enterprise, tre fattori cambiano completamente il calcolo:

Pricing per postazione non lineare

La maggior parte delle piattaforme SaaS applica un prezzo per postazione o per MAU. Con 100 utenti uno strumento a 55 €/postazione/mese costa 66.000 €/anno — ragionevole. Con 3.000 utenti lo stesso strumento costa 1.980.000 €/anno. I contratti enterprise possono offrire sconti volume, ma raramente superiori al 20–30 %, e gli impegni annuali minimi bloccano il costo indipendentemente dall’utilizzo effettivo. Il software su misura ha una curva di costo di manutenzione piatta: una volta costruito, aggiungere utenti ha un costo infrastrutturale, non di licenza.

Il debito di integrazione si accumula

Le grandi imprese gestiscono in media 900+ applicazioni SaaS (Okta, 2024). Lo strato di integrazione tra queste applicazioni — connettori API point-to-point, middleware, pipeline ETL — costa abitualmente più della manutenzione delle applicazioni stesse. Ogni nuovo strumento SaaS aggiunto è una nuova superficie di integrazione. La costruzione di una piattaforma unificata riduce il debito di integrazione a un unico codebase gestito. Leggete il nostro articolo gemello sulla modernizzazione dei sistemi legacy per il framework completo di remediation.

La conformità su scala enterprise è architettonica

Gli obblighi di responsabile del trattamento dell’Art. 28 GDPR (Regolamento UE 2016/679), i perimetri di audit SOC 2 Type II, i Business Associate Agreement HIPAA e le normative di settore (DORA per i servizi finanziari UE, FedRAMP per la pubblica amministrazione statunitense, nonché le linee guida del Garante per la protezione dei dati personali per le imprese italiane) impongono vincoli architetturali che la maggior parte delle piattaforme SaaS in multi-tenancy soddisfa solo parzialmente. Costruire per la conformità fin dall’inizio è più pulito ed economico su scala.

Per le PMI che valutano la stessa domanda senza vincoli di scala enterprise, consultate il nostro articolo gemello software su misura vs standard.

Quando acquistare

Acquistare è la scelta predefinita corretta per qualsiasi capacità che soddisfa tutti e tre questi criteri:

1. Il workflow non è un fattore di differenziazione competitiva diretta — i vostri concorrenti usano la stessa categoria di strumento senza ottenere alcun vantaggio da esso.
2. Esiste un mercato SaaS maturo con più fornitori credibili, ecosistemi di integrazione consolidati e portabilità ragionevole dei dati.
3. Il costo per postazione alla crescita prevista a 5 anni è inferiore al costo build + manutenzione a 5 anni, incluso un team platform engineering di 2 FTE.

Capacità commodity: acquistate per default

HR e paghe, CRM di base, gestione viaggi aziendali, expense management, infrastruttura email e calendario, videoconferenze — questi sono workflow commodity. Ogni grande impresa li esegue allo stesso modo. Il mercato SaaS è maturo, la portabilità dei dati è consolidata (esportazione CSV, API HRIS standard) e nessuna impresa ottiene un vantaggio competitivo da uno strumento di expense management proprietario. Acquistate questi strumenti, configurateli minimamente e resistete all’impulso di personalizzarli oltre il punto di non ritorno.

Velocità di go-to-market per capacità non core

Quando un nuovo prodotto o mercato richiede una capacità che il vostro team di ingegneria non ha mai sviluppato — comunicazioni in tempo reale, elaborazione video, ricerca avanzata — acquistare uno strato SaaS consolidato consente di lanciare in settimane anziché in mesi. Il calcolo cambia quando quella capacità diventa un fattore di differenziazione core su scala. Iniziate con l’acquisto, monitorate utilizzo e costi, ed eseguite una valutazione build al mark dei 18 mesi.

SaaS compliance-heavy con copertura shared responsibility

Quando un fornitore SaaS offre un modello di responsabilità condivisa certificato che copre genuinamente il vostro perimetro di conformità — SOC 2 Type II, ISO 27001, HIPAA BAA, PCI-DSS SAQ-D, requisiti Garante — e gli obblighi di conformità residui sono minimi, acquistare è spesso più rapido ed economico che mantenere il proprio ambiente certificato. La qualifica è «copre genuinamente»: verificate la matrice di responsabilità condivisa, non la pagina di marketing.

Quando costruire

Costruire è la scelta corretta quando si applica una o più delle seguenti condizioni:

La capacità è un fattore di differenziazione competitiva diretta

Il vostro modello di underwriting proprietario, il vostro algoritmo di demand forecasting, la vostra logica di scoring dei clienti — se questa capacità è il motivo per cui i clienti scelgono voi rispetto a un concorrente, non potete affidarla a una piattaforma SaaS di terze parti. Il fornitore avrebbe visibilità architettonica sul vostro IP differenziante, voi operereste secondo i tempi del loro roadmap e qualsiasi concorrente potrebbe acquistare la stessa piattaforma e colmare il divario. Costruite il core differenziante. Possedete l’IP. Possedete il roadmap.

Il debito di integrazione è diventato il principale onere di manutenzione

Quando il vostro team spende più tempo di ingegneria a mantenere connettori API, job di sincronizzazione e trasformazioni di dati tra strumenti SaaS che a sviluppare nuove capacità di prodotto, avete un trigger di build. Il costo a 5 anni di una piattaforma di integrazione e dati ad hoc che sostituisce 12 connettori SaaS point-to-point è quasi sempre inferiore al costo di manutenzione dell’integrazione in corso, anche prima di considerare il miglioramento della velocità del team di ingegneria.

Il rischio di dipendenza dal fornitore (vendor lock-in) è inaccettabile

Quando i termini di pricing di un fornitore, gli impegni contrattuali minimi o le limitazioni della portabilità dei dati creano un rischio che l’organizzazione non può accettare — dati di audit regolatori bloccati in un formato proprietario, impegni minimi triennali con step-up annuali del 20 %, nessuna API per l’esportazione massiva dei dati — la costruzione è l’opzione di de-risking. Consultate la sezione sulla dipendenza dal fornitore qui sotto.

La sovranità dei dati e l’architettura di conformità la richiedono

Le restrizioni al trasferimento di dati dell’Art. 44–49 GDPR (Regolamento UE 2016/679), le normative settoriali (sorveglianza trade MiFID II, residenza dei dati NHS, requisiti del settore nucleare AIEA) e le considerazioni sulla sicurezza nazionale in certi mercati rendono le architetture SaaS multi-regione in multi-tenancy condivisa architetturalmente incompatibili. Quando i dati devono rimanere in una specifica giurisdizione, in un isolamento logico specifico, con una specifica catena di audit, la costruzione di una piattaforma conforme non è una scelta ma un requisito normativo.

Dipendenza dal fornitore: quantificare il costo di uscita

La dipendenza dal fornitore (vendor lock-in) non è un rischio ipotetico. È una passività quantificabile che appartiene al vostro bilancio. Le imprese che saltano questa modellazione la scoprono sistematicamente al momento del rinnovo, quando tutta la leva è già passata al fornitore.

Un modello completo del costo di uscita dalla dipendenza dal fornitore comprende cinque componenti:

1. Estrazione e migrazione dei dati: ore di ingegneria per esportare tutti i dati dallo schema proprietario del fornitore in un formato portabile, validare l’integrità, trasformare e importare nel sistema sostitutivo. Per una grande impresa con 5 anni di dati operativi, questo è tipicamente 140.000 €–450.000 €.
2. Ricablaggio delle integrazioni: sostituzione di tutte le integrazioni downstream che chiamano le API del fornitore con chiamate al sistema sostitutivo. Moltiplicate il numero di punti di integrazione per 40–120 ore ciascuno.
3. Riaddestramento e change management: per piattaforme ad alto coinvolgimento degli utenti (ERP, CRM, ITSM), prevedete 40–80 ore di change management per ogni 100 utenti coinvolti.
4. Minimi contrattuali e penali di risoluzione: leggete ogni contratto. La maggior parte degli accordi SaaS enterprise include un preavviso di risoluzione di 90 giorni, clausole di impegno annuale minimo e talvolta esplicite penali di «risoluzione per convenienza» del 50–100 % del valore contrattuale residuo.
5. Rischio di business continuity: il costo di esecuzione parallela del vecchio e del nuovo sistema, oltre al premio di rischio per il periodo in cui nessuno dei due è completamente operativo.

TCO a 5 anni su scala enterprise

La tabella seguente confronta una decisione rappresentativa su piattaforma enterprise: una piattaforma di workflow automation e reporting per 1.000 utenti all’anno 1, in crescita a 2.500 utenti entro l’anno 5. Il costo di build presuppone un team di ingegneria nearshore senior che consegna in 18 mesi, più un team platform engineering interno di 2 FTE per lo sviluppo e la manutenzione continuativi.

Il vantaggio di TCO a 5 anni di un build su misura in questo scenario è di circa 2.100.000 € prima dei costi di uscita e di 3.300.000 €–5.100.000 € incluse le penali di migrazione stimate. L’anno di crossover — in cui la curva di acquisto supera la curva di build nel costo cumulativo — è l’anno 3 in questo modello. Per le piattaforme con una crescita più rapida dell’organico, il crossover arriva nell’anno 2.

Queste cifre sono coerenti con i benchmark di advisory enterprise di Gartner e IDC per categorie di piattaforme che includono workflow automation, business intelligence e piattaforme di dati operativi.

Il modello ibrido: acquista commodity, costruisci core

L’inquadratura di «build vs buy» come scelta binaria è essa stessa la trappola concettuale. Il modello vincente per la maggior parte delle grandi imprese è un ibrido strutturato: acquistate la capacità commodity al perimetro, costruite il core differenziante e lo strato di integrazione che li unisce.

Cosa acquistare in un modello ibrido

Identity e access management (Okta, Azure AD), elaborazione dei pagamenti (Stripe, Adyen), infrastruttura di consegna email (SendGrid, AWS SES), videochiamata (Daily.co, Twilio), firma elettronica dei documenti (DocuSign, Adobe Sign) — questi sono problemi risolti con eccellenti prodotti SaaS, API per sviluppatori robuste e portabilità dei dati consolidata. Utilizzarli lascia al vostro team di ingegneria la possibilità di concentrarsi sul core proprietario invece di reinventare l’infrastruttura commodity.

Cosa costruire in un modello ibrido

Il motore di workflow proprietario che codifica le vostre regole di business. Il modello di dati che rappresenta il vostro dominio in un modo che nessun prodotto SaaS generico può replicare. Lo strato di orchestrazione dell’integrazione che instrada eventi e dati tra i servizi commodity acquistati. Lo strato di reporting e analytics che fornisce al vostro management una visione delle metriche che contano per il vostro business specifico — non la dashboard preconfezionata in ogni contratto SaaS.

Il confine di integrazione è la decisione di design chiave

In un modello ibrido, la decisione architettonica più importante è dove tracciare il confine di integrazione tra componenti acquistati e costruiti. Questo confine deve essere pulito, ben documentato e versionato. Gli eventi che lo attraversano devono essere tipizzati, validati tramite schema e idempotenti. Le imprese che falliscono nel modello ibrido sono quelle che permettono ai prodotti SaaS acquistati di penetrare profondamente nel core costruito — creando esattamente il debito di integrazione che cercavano di evitare.

Matrice decisionale

Utilizzate questa matrice per valutare ogni piattaforma o capacità che state esaminando. Attribuite un punteggio da 1 a 5 per ogni fattore. Un punteggio totale superiore a 20 è un forte segnale di costruire; inferiore a 12 è un forte segnale di acquistare; tra 12 e 20 giustifica una valutazione ibrida.

FAQ

Una grande impresa dovrebbe costruire o acquistare software?

Dipende dal fatto che la capacità sia un fattore di differenziazione competitiva o una commodity. Acquistate workflow commodity (HR, paghe, CRM di base) dove il mercato SaaS è maturo e il costo di cambio è accettabile. Costruite quando la capacità è un driver diretto di ricavi o margine, quando la conformità al Regolamento UE 2016/679 e alle linee guida del Garante richiede la sovranità dei dati, o quando il TCO build a 5 anni è inferiore al TCO SaaS alla crescita prevista dell’organico. La maggior parte delle grandi imprese fa entrambe le cose tramite un modello ibrido strutturato.

Cos’è la dipendenza dal fornitore (vendor lock-in) e perché è importante su scala enterprise?

La dipendenza dal fornitore (vendor lock-in) è la condizione in cui abbandonare una piattaforma costa più del valore accumulato del cambiamento. Su scala enterprise questo significa formati di dati proprietari, pricing per postazione che cresce in modo non lineare, impegni contrattuali minimi e costi di migrazione che possono raggiungere 2–5 milioni di euro per una piattaforma enterprise completamente integrata. Modellate il costo di uscita prima di firmare un contratto pluriennale, non al momento del rinnovo quando tutta la leva è passata al fornitore.

Vale la pena investire in software enterprise su misura?

Sì, se applicato all’ambito corretto. Il software su misura vale il costo quando il workflow è un driver di ricavi o margine, quando i requisiti di conformità non possono essere soddisfatti da SaaS in multi-tenancy condivisa, o quando il TCO su misura a 5 anni — incluso un team platform interno di 2 FTE — è inferiore al TCO SaaS a 5 anni alla crescita prevista. Per la maggior parte delle grandi imprese che operano con 1.000+ postazioni su una piattaforma che cresce con l’organico, il build su misura si ripaga entro l’anno 3.

Come si modella il TCO a 5 anni per software enterprise?

Costruite quattro colonne: (1) Acquisto: licenza anno 1 alle postazioni attuali + anni 2–5 alla crescita prevista + connettori di integrazione + personalizzazione; (2) Costruzione: sviluppo anno 1 + anni 2–5 di manutenzione al 18 % del costo di build + team platform di 2 FTE; (3) Ibrido: perimetro di build ridotto + SaaS commodity al perimetro; (4) Costo di uscita per ogni opzione. Calcolate il VAN di ogni colonna al vostro tasso di sconto su 5 anni. L’opzione con il VAN più basso, incluso il costo di uscita, è la decisione corretta. Non escludete il costo di uscita — è la variabile più sottostimata nel procurement enterprise.

Possiamo combinare costruzione e acquisto?

Sì — questo è il modello raccomandato per la maggior parte delle grandi imprese. Acquistate capacità commodity (identity, pagamenti, comunicazioni, analytics) da fornitori SaaS maturi. Costruite il core workflow differenziante, il modello di dati proprietario e lo strato di orchestrazione dell’integrazione. La decisione di design chiave è tracciare un confine di integrazione pulito, ben documentato e versionato tra i due — e farlo rispettare. Permettere ai prodotti SaaS acquistati di penetrare nel core costruito ricrea il debito di integrazione che si cercava di evitare.

Ultimo aggiornamento: 9 giugno 2026. Le cifre TCO riflettono la consegna nearshore senior e i prezzi SaaS enterprise rappresentativi per piattaforme di workflow e dati con 1.000–2.500 postazioni. I costi individuali dei progetti variano. Cifre coerenti con i benchmark advisory enterprise di Gartner e IDC per 2025–2026.