In breve: un preventivo per software su misura è confrontabile soltanto quando descrive obiettivo, perimetro, utenti, dati, integrazioni, fasi, criteri di collaudo, responsabilità, costi ricorrenti e gestione successiva al rilascio. Il prezzo, da solo, non dice se due proposte comprendono lo stesso lavoro né chi sosterrà i rischi rimasti impliciti.

Che cos’è davvero un preventivo per software su misura?

Non è un listino e non dovrebbe essere una somma accompagnata da poche righe. È la traduzione economica e operativa di un progetto ancora da realizzare. Deve permettere al cliente e alla software house di condividere lo stesso significato di parole come “gestionale”, “dashboard”, “integrazione”, “migrazione” e “assistenza”.

Più il processo è specifico, più una cifra definitiva formulata prima di analizzare utenti, eccezioni e sistemi esistenti va interpretata con cautela. Questo non significa che ogni progetto richieda mesi di analisi: significa che la stima deve dichiarare su quali informazioni e assunzioni si basa.

I 12 elementi che devono comparire

Area Che cosa deve chiarire Rischio se manca
Obiettivo Problema operativo e risultato misurabile Si consegnano funzioni senza migliorare il processo
Perimetro Funzioni incluse, escluse e rinviate Varianti continue e confronto impossibile
Utenti Ruoli, permessi, sedi e dispositivi Accessi errati o interfacce inadatte
Dati Origine, qualità, migrazione, conservazione ed esportazione Costi nascosti e perdita di informazioni
Integrazioni Sistemi, API, direzione e frequenza degli scambi Dati duplicati e processi interrotti
Deliverable Documenti, prototipi, software, manuali e formazione “Completato” assume significati diversi
Fasi Sequenza, dipendenze e responsabilità Tempi non governabili
Collaudo Casi di prova e criteri di accettazione Approvazione basata su impressioni
Sicurezza Accessi, ambienti, backup, log e aggiornamenti Controlli aggiunti troppo tardi
Economica Costi iniziali, ricorrenti, variabili e di terzi Il costo totale emerge dopo la firma
Proprietà Dati, codice, licenze, repository e piano di uscita Dipendenza non prevista dal fornitore
Post-rilascio Garanzia, manutenzione, assistenza e tempi di presa in carico Nessuno presidia il sistema operativo

1. Partire dal risultato, non dalle schermate

“Realizzare un gestionale” non è ancora un obiettivo. Un risultato utile può essere ridurre la doppia registrazione degli ordini, conoscere lo stato reale di una commessa, evitare documenti non aggiornati oppure diminuire il tempo necessario per preparare un preventivo.

Per ogni obiettivo conviene indicare una baseline e una misura successiva. Se oggi la stessa anagrafica viene riscritta tre volte, il progetto può puntare a una sola registrazione. Se una verifica richiede due giorni, si può misurare il tempo dopo il rilascio. Una metrica semplice orienta le priorità meglio di un elenco di funzioni.

2. Separare incluso, escluso e da verificare

Il perimetro dovrebbe distinguere almeno quattro gruppi:

  1. funzioni necessarie al primo rilascio operativo;
  2. miglioramenti importanti ma non bloccanti;
  3. ipotesi che richiedono una verifica tecnica o un prototipo;
  4. elementi esplicitamente esclusi.

Le esclusioni non sono un limite “contro” il cliente. Servono a riconoscere il confine entro cui prezzo e tempi hanno senso. Se app mobile, migrazione storica, firma elettronica o collegamento con un fornitore esterno non sono compresi, devono essere nominati.

3. Descrivere utenti, ruoli ed eccezioni

Il numero di schermate raramente rappresenta la complessità. Incidono di più i ruoli, le autorizzazioni e le eccezioni. Chi può creare, modificare, approvare, annullare o esportare? Un commerciale vede tutti i clienti o soltanto i propri? Un amministratore può correggere un documento già contabilizzato?

Al preventivo non serve allegare ogni regola definitiva, ma devono essere dichiarati i gruppi di utenti, le operazioni sensibili e le aree ancora da approfondire.

4. Trattare dati e migrazione come un progetto

“Importazione dati inclusa” è troppo generico. Bisogna indicare almeno:

  • archivi di origine e formati disponibili;
  • quantità e qualità conosciuta dei dati;
  • regole per duplicati, valori mancanti e codifiche incoerenti;
  • numero di prove di migrazione;
  • chi valida il risultato;
  • periodo di fermo e piano di ritorno, se necessari.

La pulizia dei dati richiede spesso decisioni aziendali, non soltanto attività tecniche. Il referente interno deve poter stabilire quale record sia corretto e quali informazioni possano essere archiviate.

5. Verificare le integrazioni prima di promettere

Per ogni collegamento con ERP, CRM, e-commerce, pagamenti, corrieri o macchine occorre identificare la fonte autorevole del dato, la direzione dello scambio, la frequenza, le credenziali, i limiti del servizio e il comportamento in caso di errore.

Una dicitura come “integrazione con il gestionale” non conferma che esistano API utilizzabili, documentazione aggiornata o un ambiente di test. Nel preventivo dovrebbe comparire l’eventuale dipendenza dal fornitore terzo e che cosa accade se l’interfaccia disponibile non corrisponde a quanto dichiarato.

6. Definire deliverable e avanzamento

Ogni fase dovrebbe produrre qualcosa di verificabile: mappa dei processi, requisiti, prototipo, modello dei dati, ambiente di prova, versione candidata, verbale di collaudo, manuale o sessione di formazione. Le riunioni sono utili, ma non sostituiscono gli artefatti.

È altrettanto importante indicare quando il cliente deve fornire dati, credenziali, esempi o approvazioni. Un ritardo in una dipendenza critica modifica il calendario; renderlo visibile evita che diventi una sorpresa.

7. Scrivere i criteri di accettazione

Per le funzioni centrali, il preventivo o il documento collegato deve spiegare come si dimostrerà il risultato. Un criterio utile contiene dato iniziale, azione, esito atteso, ruolo autorizzato e comportamento in caso di errore.

Esempio: “Un responsabile approva un ordine completo; il sistema assegna un numero univoco, registra autore e data, invia il dato al gestionale una sola volta e mostra un errore recuperabile se il servizio esterno non risponde”. È molto più verificabile di “gestione ordini inclusa”.

8. Integrare sicurezza, privacy e accessibilità

Sicurezza e accessibilità non sono rifiniture da quotare dopo il rilascio. Ambienti separati, controllo degli accessi, gestione dei segreti, backup, log, aggiornamenti e risposta alle vulnerabilità devono entrare nel ciclo di sviluppo. Il NIST SSDF organizza queste attività tra preparazione, protezione del software, produzione sicura e risposta alle vulnerabilità.

Per una web app vanno inoltre definiti navigazione da tastiera, focus, etichette, messaggi di errore e dispositivi previsti. Le WCAG 2.2 forniscono criteri verificabili; il livello e il perimetro applicabile vanno concordati, non presunti.

9. Distinguere tutti i costi

Iniziali

Analisi, UX, sviluppo, migrazione, integrazioni, test, avvio e formazione.

Ricorrenti

Hosting, licenze, monitoraggio, backup, manutenzione e assistenza.

Variabili

Consumi API, messaggi, spazio, transazioni, modelli AI e traffico.

Opzionali

Evoluzioni, importazioni aggiuntive, nuove sedi, moduli o integrazioni.

Il confronto corretto usa il costo totale su un orizzonte realistico, non soltanto il costo di avvio. Per i servizi a consumo servono unità di misura, soglie e modalità di controllo.

10. Chiarire proprietà e piano di uscita

Nel progetto possono convivere codice specifico, componenti riutilizzabili del fornitore, software open source e servizi commerciali. Il contratto deve distinguere licenze, disponibilità del repository, documentazione, credenziali, esportazione dei dati e attività previste in caso di passaggio.

La portabilità va progettata all’inizio. Discuterla non significa prevedere un rapporto breve: significa evitare che la continuità aziendale dipenda da informazioni non documentate.

11. Gestire modifiche e nuove richieste

Durante lo sviluppo emergeranno informazioni nuove. Il preventivo dovrebbe spiegare come vengono valutate le variazioni: descrizione, impatto su costo e calendario, approvazione e aggiornamento del perimetro. Una richiesta non dovrebbe diventare lavoro implicito né una fattura inattesa.

12. Definire il dopo rilascio

Garanzia, manutenzione e assistenza sono servizi diversi. La garanzia riguarda difetti rispetto ai requisiti concordati; la manutenzione mantiene compatibilità e sicurezza; l’assistenza aiuta utenti e responsabili; l’evolutiva introduce nuove capacità.

Tempi di presa in carico, priorità, orari, canali, backup e responsabilità devono essere proporzionati al rischio operativo del sistema.

Come confrontare due preventivi

  1. allineare lo stesso perimetro e le stesse esclusioni;
  2. separare prezzo certo, stima e attività a consumo;
  3. confrontare deliverable e criteri di accettazione;
  4. verificare dipendenze da cliente e terze parti;
  5. calcolare i costi ricorrenti per almeno tre anni;
  6. valutare manutenzione, portabilità e piano di uscita;
  7. attribuire un proprietario ai rischi ancora aperti.

Dieci domande da fare prima della firma

  1. Quale risultato aziendale useremo per valutare il progetto?
  2. Quali assunzioni sostengono prezzo e calendario?
  3. Che cosa non è incluso?
  4. Quali integrazioni sono già state verificate?
  5. Chi pulisce e convalida i dati da migrare?
  6. Come vedremo e approveremo l’avanzamento?
  7. Quali prove determineranno l’accettazione?
  8. Quali costi resteranno dopo il rilascio?
  9. Come esportiamo dati, documenti e configurazioni?
  10. Chi interviene su errori, sicurezza ed evoluzioni?

Domande frequenti

Un preventivo a corpo è sempre preferibile?

No. È efficace quando il perimetro è sufficientemente conosciuto. Se le incognite sono rilevanti, una fase di analisi a costo definito seguita da una stima aggiornata può ridurre il rischio per entrambe le parti.

Quanto deve essere dettagliato?

Abbastanza da rendere confrontabili risultato, responsabilità e criteri di accettazione. Non deve anticipare ogni decisione tecnica, ma deve nominare le incognite che possono modificare prezzo o tempi.

Il prezzo più basso indica maggiore efficienza?

Non necessariamente. Può derivare da un approccio più semplice, ma anche da attività escluse o non considerate. Il confronto va fatto sullo stesso perimetro e sul costo totale prevedibile.

Serve già un capitolato tecnico?

Non sempre. Per il primo confronto sono più utili esempi reali del processo, utenti coinvolti, documenti, sistemi esistenti, eccezioni e obiettivo. La specifica tecnica può nascere dall’analisi condivisa.

Il passo successivo

Per preparare una richiesta confrontabile puoi partire dalla guida su come scegliere una software house, verificare se serve un gestionale standard o su misura e approfondire il nostro metodo di lavoro.

Per aziende di Messina, Milazzo e provincia il primo incontro può concentrarsi su un processo reale, sugli strumenti già utilizzati e sul risultato da migliorare. Non è necessario arrivare con una soluzione già decisa.

Porta un processo da valutare

Fonti tecniche