Gestionale su misura o software pronto: come scegliere

Quando un’azienda deve scegliere tra un gestionale già pronto e uno costruito apposta, di solito si parte dal confronto tra prodotti: demo, listini, elenchi di funzioni. Io parto da un’altra parte, cioè da come lavori oggi, tu e il tuo team. Il confronto tra prodotti viene dopo, e a quel punto sai esattamente cosa verificare in ogni demo.

Qui sotto ci sono i criteri che uso. Le parti normative sono collegate alla fonte; per i contratti serve comunque un avvocato.

In breve

Prima di guardare i prodotti, disegna il flusso di lavoro di oggi e prova ad accorciarlo.
Confronta i costi su almeno cinque anni, manutenzione compresa.
Per contabilità, paghe e fatturazione esiste già software pronto. Il su misura ha senso per i processi che sono solo tuoi.
Le integrazioni con quello che usi già pesano spesso più delle funzioni.
Chiedi sempre come si esportano i dati e, se il software è su misura, chi possiede il codice.
Valuta la via di mezzo: un prodotto pronto per la parte standard, collegato a una parte su misura.

Prima del software, il flusso di lavoro

La prima cosa che guardo è il lavoro come si svolge oggi: chi fa cosa, in che ordine, dove si aspetta qualcun altro, dove un dato viene ricopiato da un programma all’altro.

L’errore che vedo più spesso è un flusso molto lungo, con tanti passaggi in fila. Ogni passaggio è un punto in cui qualcosa può andare storto, e le probabilità di errore si sommano. Se automatizzi un flusso di dodici passaggi ottieni un software con dodici passaggi: costa di più da costruire o da configurare, e ognuno va testato. Per questo, prima di automatizzare, provo ad accorciarlo. Capita che due passaggi si possano fondere, o che uno serva solo a correggere l’errore di quello precedente e si possa togliere.

Poi divido il problema in parti più piccole e lo metto su carta, con schemi del flusso e descrizioni scritte. Per ogni passaggio annoto:

chi lo fa e quando;
quali dati usa e da dove arrivano;
dove finisce il risultato e chi lo usa dopo;
cosa succede quando un dato manca o è sbagliato.

Questo documento serve anche se alla fine scegli un prodotto pronto: alle demo chiedi al fornitore di mostrarti i tuoi passaggi, con dati simili ai tuoi. Il codice, se serve, arriva solo alla fine, quando il flusso sta in piedi sulla carta.

Il costo vero, su cinque anni

Il canone mensile di un software pronto e il preventivo di uno su misura vanno confrontati su tutto quello che si paga negli anni.

Per il software pronto:

licenza per utente o per sede, e quanto cresce quando aumentano le persone;
moduli aggiuntivi che scopri di servirti dopo l’acquisto;
configurazione iniziale, migrazione dei dati, formazione;
aumenti di prezzo al rinnovo;
il tempo che il personale passa a compensare quello che il prodotto non fa, di solito con fogli Excel di appoggio.

Per il software su misura:

analisi e sviluppo iniziale;
hosting e backup;
manutenzione ogni anno: aggiornamenti di sicurezza, nuove versioni di librerie e linguaggio, piccole modifiche;
documentazione, perché un domani qualcun altro possa metterci le mani.

Un conto con cifre di esempio: 15 utenti a 40 euro al mese fanno 7.200 euro l’anno, 36.000 in cinque anni, prima di moduli e aumenti. È con questo totale che va confrontato un progetto su misura, comprese le sue spese di manutenzione.

Per le pubbliche amministrazioni il confronto è un obbligo: il Codice dell’amministrazione digitale chiede una valutazione comparativa tra le soluzioni disponibili e tra i criteri mette il “costo complessivo del programma o soluzione quale costo di acquisto, di implementazione, di mantenimento e supporto” (CAD, art. 68). È un criterio utile anche per un’azienda privata.

Quanto sono specifici i tuoi processi

Se un processo funziona come in qualsiasi altra azienda, costruirlo da zero raramente conviene. La fattura elettronica, per esempio, passa per tutti dal Sistema di Interscambio dell’Agenzia delle Entrate (MEF), e i programmi che la gestiscono esistono già.

Il su misura comincia ad avere senso quando vedi segnali come questi:

ogni giorno qualcuno ricopia gli stessi dati da un programma all’altro;
c’è un foglio Excel che tiene insieme tutto, e solo una persona sa come funziona;
per adattarti al prodotto hai cambiato un processo che prima funzionava;
le modifiche che chiedi al fornitore costano settimane o restano in coda.

C’è anche il caso opposto. Se il processo cambia ogni mese, o non riesci ancora a descriverlo, conviene stabilizzarlo prima di farlo diventare codice.

Le integrazioni spesso decidono

Fai l’elenco dei sistemi con cui il gestionale deve parlare: fatturazione, pagamenti, e-commerce, il software del commercialista, le piattaforme dei clienti o dei fornitori. Per un prodotto pronto, chiedi se ha API documentate, se sono comprese nel piano che stai comprando, quali limiti hanno e se possono avvisare un altro sistema quando succede qualcosa (per esempio con un webhook).

Nel su misura conviene collegarsi a quello che esiste già, invece di rifarlo. Se più piattaforme hanno ognuna i propri utenti e le proprie password, si può aggiungere un accesso unico: per una società di calcio professionistica ho realizzato un accesso unico a tutte le piattaforme del club, così ogni utente vede le piattaforme di cui fa parte.

Dati, codice e lock-in

Con un software pronto, prima di firmare chiedi come si esportano i dati (tutti, compresi allegati e storico), in che formato e cosa succede alla fine del contratto.

Se il prodotto è in cloud, dal 12 settembre 2025 il Data Act (Reg. UE 2023/2854) dà regole precise. Il regolamento parla di “servizi di trattamento dei dati” e ci fa rientrare anche il software fornito come servizio, il SaaS (considerando 81). Il contratto deve indicare, fra le altre cose (art. 25):

un preavviso massimo di due mesi per avviare il passaggio a un altro fornitore;
un periodo di transizione di 30 giorni, in cui il servizio continua a funzionare;
almeno 30 giorni per recuperare i dati dopo la transizione;
l’elenco completo dei dati esportabili.

Dal 12 gennaio 2027 il fornitore non potrà più far pagare il passaggio; fino ad allora può chiedere solo importi ridotti, non oltre i costi legati direttamente al passaggio (art. 29). Il divieto di far pagare il passaggio non vale per i servizi costruiti in gran parte su misura per un solo cliente e non offerti su larga scala (art. 31).

Con il su misura la domanda è chi possiede il codice. La legge sul diritto d’autore assegna al datore di lavoro i diritti sul software scritto da un dipendente, salvo patto contrario (L. 633/1941, art. 12-bis). Con un fornitore esterno conviene scrivere tutto nel contratto: cessione dei diritti, codice sorgente nel tuo repository, documentazione. Per gli enti pubblici il CAD prevede che l’amministrazione sia titolare di tutti i diritti sul software sviluppato per lei, salvo casi eccessivamente onerosi (CAD, art. 69). Nel mio lavoro codice e dati restano al cliente.

Il lock-in esiste anche con il su misura: se solo una persona sa come funziona il software, sei legato a quella persona. Per questo nei miei progetti prevedo documentazione e passaggio di consegne, e scelgo le tecnologie anche in base a chi dovrà mantenere il software dopo di me.

La via di mezzo: personalizzare un prodotto esistente

Si può partire da un prodotto pronto e:

configurarlo: campi, ruoli, stati, modelli di documento;
estenderlo con un modulo o un plugin che usa le API ufficiali;
affiancargli una piccola applicazione su misura collegata via API, per la parte che il prodotto non copre.

Per un portale di annunci di lavoro, per esempio, ho collegato un plugin WordPress al backend degli annunci per gestire le candidature.

Il rischio da guardare è l’aggiornamento. Le personalizzazioni che modificano il codice interno del prodotto possono rompersi alla versione successiva. Prima di partire chiedi se sopravvivono agli aggiornamenti e chi le mantiene. Quando si può, meglio le estensioni che passano dalle API documentate.

Per analizzare il tuo caso prima di scegliere c’è la consulenza per gestionali e app web su misura.