Software custom o SaaS off-the-shelf? Il framework decisionale a 5 criteri per PMI

La decisione 'lo facciamo noi o lo compriamo già fatto?' è la più frequente e la più sottovalutata nelle PMI italiane. Sottovalutata perché viene presa due o tre volte in modo casuale, su sensazioni del direttore IT o sulla simpatia del venditore SaaS di turno, e poi diventa irreversibile per cinque anni. Un cambio di SaaS o una riscrittura di un custom mal pensato costano dieci volte la decisione iniziale.

Esiste un framework ragionevole per non sbagliare. Cinque criteri, dieci minuti di analisi per criterio, output un foglio Excel firmato in cui c'è scritto perché avete deciso così. Quando tra due anni qualcuno chiederà 'perché non abbiamo comprato XYZ?', avrai una risposta documentata. La decisione era ragionevole con le informazioni del momento — non un capriccio.

Criterio 1 — Criticità del processo per il business

La prima domanda non è tecnica, è strategica: questo processo è core o è di supporto? Il processo core differenzia la tua azienda dai competitor. Il processo di supporto è necessario ma non differenziante. Su quello core, custom è di default. Su quello di supporto, SaaS è di default. La maggior parte delle PMI sbaglia perché tratta tutti i processi come core, e finisce a sviluppare custom anche per task generici (timesheet, ferie, gestione contratti).

Tre domande per classificare un processo come core o di supporto.

1. Se questo processo si fermasse per una settimana, il fatturato scenderebbe in modo misurabile? (Sì = core)
2. Se questo processo girasse esattamente come quello dei competitor, perderei un vantaggio competitivo? (Sì = core)
3. Questo processo contiene informazioni o logiche che non vogliamo che escano dal perimetro aziendale? (Sì = core)

Esempio reale: un nostro cliente nel settore retail aveva sviluppato custom il proprio gestionale dei contratti di fornitura — processo di supporto, completamente standard. Stesso cliente usava SaaS off-the-shelf per il sistema di pricing dinamico — processo core, il loro unico differenziatore competitivo. Avevano fatto il make/buy al contrario su entrambi i fronti. Cinque anni di lock-in al contrario.

Criterio 2 — Fit funzionale del SaaS disponibile

Se decidi di valutare il buy, devi misurare quanto bene un SaaS off-the-shelf copre i tuoi requisiti reali. La regola pratica: meno dell'80% di fit è una pessima base per il buy. Tra 80% e 95%, il buy è vincente se accetti di adattare i tuoi processi al tool (cosa difficile ma spesso possibile). Sopra il 95%, il buy è quasi sempre la scelta giusta.

• Estrai dal processo i 15-20 requisiti funzionali più critici (non i nice-to-have).
• Valuta ogni SaaS candidato spuntando solo i requisiti coperti out-of-the-box, non quelli 'coperti con configurazioni avanzate' o 'sulla roadmap'.
• Calcola la percentuale di copertura: numero di requisiti coperti / totale requisiti critici.
• Per i SaaS sotto l'80%, valuta il costo della personalizzazione: spesso annulla il vantaggio rispetto al custom.

Criterio 3 — Lock-in del fornitore

Il lock-in è il costo di uscita dal SaaS quando, tra due o tre anni, il fornitore aumenta i prezzi del 40%, viene acquisito da un competitor o cambia strategia commerciale. Non è una possibilità astratta: è la cronaca degli ultimi cinque anni del mercato SaaS. Salesforce, Atlassian, Microsoft, Adobe, Zendesk — tutti hanno aumentato listini del 25-60% sui clienti esistenti.

Quattro indicatori di lock-in da valutare prima di firmare un SaaS, in ordine di gravità.

• Esportabilità dati: il fornitore offre export completo in formato aperto (CSV, JSON, SQL)? Se no, lock-in massimo.
• Standard di integrazione: il SaaS espone API REST documentate, o solo connettori proprietari? API aperte riducono il lock-in.
• Migrabilità di logiche: se hai costruito automazioni o workflow nel SaaS, sono in formato esportabile o sono legati al motore proprietario?
• Quota di mercato del fornitore: leader di mercato consolidato riduce il rischio di sparizione del servizio.

Custom riduce il lock-in al fornitore ma ne crea uno diverso, sulla tecnologia scelta. Se sviluppi su Microsoft Power Platform, sei agganciato a Microsoft. Se sviluppi in stack standard (Node, Python, Postgres, React), il lock-in è quasi zero — qualsiasi sviluppatore competente prende in mano il progetto.

Criterio 4 — TCO a 3 anni, non solo licenza

Il confronto economico tra make e buy diventa onesto solo a 3 anni e includendo tutti i costi, non solo la licenza SaaS o l'investimento iniziale di sviluppo. Il TCO a 3 anni è il numero su cui decide il CFO. Spesso ribalta la decisione che sembrava ovvia.

Cosa includere nel TCO buy a 3 anni.

• Licenze per utente, moltiplicato per crescita prevista del team in 36 mesi.
• Costi di setup iniziale e onboarding del fornitore.
• Personalizzazioni e integrazioni con i sistemi esistenti.
• Formazione del personale al nuovo tool e change management interno.
• Tempo interno IT/operations per la gestione del fornitore e dei suoi aggiornamenti.

Cosa includere nel TCO make a 3 anni.

• Sviluppo iniziale (l'MVP a 12 settimane è il punto di partenza, non il TCO).
• Manutenzione evolutiva: tipicamente 20-30% del costo iniziale per anno.
• Hosting, monitoring, sicurezza: 3.000-15.000 euro/anno a seconda dei volumi.
• Patch di sicurezza e aggiornamenti delle librerie: 5-10 giorni-uomo all'anno.
• Risorse interne dedicate alla gestione (anche se le risorse sono esterne, l'azienda deve avere un referente).

“Il TCO a 3 anni capovolge la decisione make/buy nel 40% dei casi che vediamo. SaaS sembra sempre più economico al primo anno, e custom sembra sempre più economico al terzo. La verità è nel mezzo, e va calcolata.”

Criterio 5 — Time-to-value reale

Il time-to-value è il numero di settimane tra la decisione e il momento in cui il primo utente trae valore reale dal sistema. Per SaaS è tipicamente 4-12 settimane (setup + integrazione + onboarding). Per custom è tipicamente 12-24 settimane (i 3 mesi di MVP più un mese di adozione). La differenza non è enorme come si pensa.

Tre situazioni in cui il time-to-value è decisivo e ribalta il framework.

1. Hai un obbligo regolatorio con scadenza imminente (es. nuova normativa GDPR di settore): SaaS è quasi sempre la scelta, anche con fit basso.
2. Hai un'opportunità commerciale che apre tra 6 mesi e devi essere pronto: valuta SaaS, oppure custom MVP con scope ridottissimo.
3. Stai testando un'ipotesi di business (PoC, MVP esplorativo): SaaS o low-code in prima battuta, custom se l'ipotesi viene validata e diventa core.

Caso pratico: PMI manifatturiera, 120 dipendenti

PMI manifatturiera del nord Italia, 120 dipendenti, doveva scegliere tra SaaS di gestione ordini e custom. Processo: ordini clienti B2B con configurazione complessa di prodotto. Applicazione del framework: criticità 5 (è il core business), fit dei SaaS valutati 65% (configuratore di prodotto troppo specifico), lock-in dei SaaS valutati alto (formato dati proprietario), TCO a 3 anni equivalente entro 8%, time-to-value SaaS 14 settimane vs custom 22 settimane.

Decisione finale: custom. Motivo dominante: criticità e fit. Il TCO equivalente non bastava a giustificare la perdita di differenziazione competitiva. Sviluppato in 22 settimane, in produzione da 16 mesi al momento di scrivere. Costo totale custom inferiore del 12% rispetto al TCO SaaS a 36 mesi.

Se hai una decisione make/buy in corso o in arrivo e vuoi che ti accompagniamo nell'applicazione del framework — con la nostra esperienza su 11 casi reali negli ultimi 18 mesi — prendiamoci trenta minuti per una chiamata gratuita. Ti aiutiamo a identificare il criterio dominante per il tuo caso e a evitare le tre trappole più frequenti nella decisione.