Capitolato tecnico software: come scriverlo perché i preventivi siano confrontabili
Il capitolato tecnico di un software descrive chi lo userà, cosa deve fare in ogni situazione, con quali volumi e come si verifica che funzioni. Se è scritto bene, fornitori diversi quotano lo stesso lavoro e la differenza di prezzo diventa leggibile.
A cosa serve davvero un capitolato
Serve a togliere le interpretazioni. Quando tre fornitori ricevono la frase «vogliamo un gestionale per le commesse», uno immagina un foglio condiviso con due stati, un altro un sistema con pianificazione, consuntivi e collegamento all’ERP. I tre prezzi non si possono confrontare, perché ognuno ha quotato un software diverso.
Il capitolato non è un documento tecnico nel senso dei linguaggi o dei server. È la descrizione del lavoro che oggi fate a mano, di chi lo fa, di quante volte succede e di cosa dovrà cambiare. Le scelte tecniche le propone il fornitore; voi fissate i vincoli, per esempio che i dati restino in Italia o che il magazzino lavori anche senza rete.
La lunghezza giusta la decide il numero di situazioni da descrivere, non il numero di pagine. Un software per le richieste di reso con quattro passaggi sta in poche pagine; un sistema che tocca produzione, qualità e spedizioni ne chiede molte di più, divise per reparto.
Le otto sezioni, nell’ordine in cui scriverle
L’ordine conta: le prime sezioni danno il contesto che rende leggibili i requisiti.
Contesto e obiettivo
Chi siete, quante persone useranno il software, perché lo fate adesso. Un obiettivo misurabile aiuta: «chiudere il consuntivo di commessa entro tre giorni dalla consegna, oggi ne servono quindici».
Come si lavora oggi
Il flusso attuale, con i documenti veri allegati: il file Excel delle commesse, il modulo cartaceo del collaudo, la mail tipo con cui arriva un ordine. Il fornitore capisce più da un file reale che da tre pagine di descrizione.
Ruoli
Chi fa cosa, e cosa può vedere. Il capo reparto approva, l’operatore registra, l’amministrazione vede solo i totali. I permessi scritti qui diventano la struttura del software.
Requisiti funzionali come scenari
Ogni requisito parte da una persona e da un evento: chi fa cosa, in quale momento, con quale risultato. Accanto, la priorità: indispensabile per partire, utile, rimandabile.
Volumi e vincoli
Quanti utenti contemporanei, quanti ordini al giorno, quante righe ha l’ordine più lungo, quanti anni di storico vanno conservati. Poi i vincoli: tablet in reparto, guanti, rete assente in magazzino, lingue.
Integrazioni e dati da migrare
Con quali sistemi deve parlare (ERP, firma elettronica, posta) e in quale direzione. Quali dati esistono già e in che stato sono: tre anni di Excel con colonne cambiate nel tempo sono un lavoro a sé.
Cosa resta fuori
Le richieste che avete escluso, scritte. Evita che un fornitore le metta nel prezzo e un altro no.
Criteri di collaudo
Come verificherete che il software funziona: quali scenari proverete, con quali dati, chi firma il collaudo. È la sezione che chiude le discussioni a fine progetto.
Lo stesso requisito scritto due volte
La differenza fra un requisito che si quota e uno che si interpreta sta quasi sempre nei numeri e nella persona che agisce.
| Scritto così | Scritto meglio | Cosa cambia per chi quota |
|---|---|---|
| Il sistema deve gestire gli ordini. | L’addetta vendite inserisce un ordine ricevuto via mail, con fino a 120 righe; il 70% arriva da 15 clienti abituali e va ricopiato dal loro PDF. | Il fornitore capisce che serve l’importazione da PDF per pochi formati, non un inserimento manuale più comodo. |
| Report personalizzabili. | Il direttore di stabilimento ogni lunedì vuole le ore consuntivate per commessa e per reparto della settimana prima, esportabili in Excel. | Da un generatore di report si passa a una vista con due filtri. |
| Il sistema deve essere sicuro. | Gli operatori vedono solo le commesse del proprio reparto; i prezzi li vedono amministrazione e direzione; ogni modifica a un ordine confermato resta registrata con nome e ora. | Da una parola generica si passa a una matrice di permessi e a un registro delle modifiche, due voci che si stimano. |
| Integrazione con il gestionale. | Ogni sera i clienti e gli articoli nuovi arrivano dall’ERP; gli ordini confermati tornano all’ERP entro dieci minuti. | Si sa cosa va in quale direzione, e con che frequenza. |
| Accesso da mobile. | Il tecnico in trasferta compila il rapportino dal telefono, anche senza campo, e lo invia quando torna la rete. | Il lavoro offline cambia l’architettura: meglio saperlo prima del preventivo. |
Cosa non scrivere nel capitolato
Non prescrivete la tecnologia senza scrivere il motivo. «Sviluppato in .NET perché i nostri due sistemisti lo conoscono e faranno la manutenzione» è un vincolo che il fornitore può valutare; «sviluppato in .NET» da solo sembra una preferenza, e chi lavora con altro rinuncia a rispondere.
Non incollate le funzioni della brochure di un gestionale che avete visto in fiera. Ogni voce copiata diventa un costo, anche quelle che nessuno userà. Se una funzione vi è piaciuta, scrivete il problema che risolve.
Non tenete per voi la data che conta davvero. Se il software deve funzionare per l’audit di rinnovo della certificazione a marzo, scrivetelo: il fornitore vi dirà cosa si può avere per quella data e cosa slitta dopo, invece di proporvi un piano che finisce ad aprile.
Errori che vediamo spesso nei capitolati
- Requisiti tutti indispensabili. Senza priorità il fornitore quota tutto, e il primo rilascio arriva dopo mesi invece che dopo settimane.
- Nessun numero sui volumi. «Molti ordini» per qualcuno sono 30 al giorno, per altri 3.000, e il software cambia.
- Il capitolato scritto solo dall’IT o solo dalla direzione. Chi registra i dati ogni giorno, il capo turno o la magazziniera, deve leggerlo prima che parta.
- Criteri di collaudo senza dati di prova. «Il consuntivo deve essere corretto» non si verifica se nessuno ha preparato tre commesse chiuse con il risultato già calcolato a mano.
- Le eccezioni lasciate fuori perché rare. Il reso parziale o l’ordine con due indirizzi di consegna capitano una volta al mese, ma se nessuno li scrive il software non li prevede.
Domande frequenti
Parliamone in 30 minuti
Raccontateci il processo e cosa non funziona: vi diciamo se e come lo risolveremmo, con tempi e costi indicativi.
Matteo Budriesi
CEO e co-founder di Webion, la software house di Modena che sviluppa software su misura e agenti AI per le aziende.
Aggiornato il 30/10/2026