Preventivo software su misura: come preparare un capitolato che rende confrontabili le offerte

Parliamo del tuo progetto →

Quando un responsabile chiede un preventivo software su misura, il vero obiettivo non è ricevere più offerte: è ricevere offerte confrontabili. Se il brief è vago, ogni fornitore interpreta un perimetro diverso. Uno include analisi, test e documentazione; un altro solo sviluppo; uno considera integrazioni e manutenzione, un altro le tratta come extra. Il risultato è un confronto falso, anche quando i numeri sembrano chiari.

Per questo, prima di parlare di prezzo conviene preparare un capitolato breve ma completo. La documentazione Microsoft sui requisiti raccomanda di scrivere requisiti verificabili e criteri di accettazione chiari (Requirements phase recommendations). Quando il progetto può appoggiarsi a una soluzione già esistente, la distinzione tra fit-to-standard e fit-gap aiuta a capire cosa copre davvero lo standard e cosa invece richiede estensioni (fit-to-standard e fit-gap). Per la supply chain software, OWASP SCVS insiste su scope esplicito ed evidenze verificabili: la stessa logica è utile anche qui, perché un brief senza confini e senza responsabilità chiare produce preventivi difficili da confrontare (Using the SCVS).

Se il tuo bisogno è capire cosa preparare prima di contattare una software house, questo articolo risponde proprio a quello. Non è una guida per confrontare preventivi con l’AI, né una pagina su come scegliere il fornitore migliore: qui si costruisce il documento di partenza, cioè il perimetro.

Per un approfondimento sul servizio puoi collegarti a Sviluppo software su misura e integrazioni, affiancarlo a Consulenza strategica e governance IT quando serve una fase di analisi più ampia, e usare Contatti Dedaloop per inviare una prima descrizione del processo. Se stai ancora valutando il criterio di scelta del fornitore, può aiutare anche Come scegliere una software house quando servono integrazioni tra sistemi già esistenti.

Quando il preventivo è davvero confrontabile

Un preventivo è utile solo se misura la stessa cosa per tutti i candidati. Per farlo, il brief deve dire almeno tre cose:

qual è il processo da digitalizzare;
quali funzioni stanno dentro e quali restano fuori;
quali risultati devono essere verificabili alla fine.

In pratica, il documento serve a tre decisioni:

capire se il problema merita davvero un software su misura;
evitare offerte che includono cose diverse;
separare costo iniziale, evoluzioni future e manutenzione.

Quando il processo è molto vicino a un flusso già coperto bene da un gestionale o da una piattaforma standard, una mini fit-gap è spesso il passo più sensato prima del preventivo dettagliato. Se invece il vantaggio competitivo dipende da regole specifiche, integrazioni particolari o approvazioni proprie, il su misura ha più senso. Il confronto va fatto sul processo, non sul totale in fondo all’offerta.

Brief simulato compilato: il caso da usare come modello

L’esempio che segue è volutamente semplice ma completo. È un caso simulato, non descrive un cliente reale. Puoi riusarlo come modello per il tuo progetto.

Campo	Contenuto simulato
Obiettivo	Sostituire Excel e passaggi via email con una web app interna per tracciare richieste, approvazioni e stato lavorazione
Destinatari interni	Richiedenti, approvatori, operatori di magazzino, amministratori
Problema attuale	Dati duplicati, versioni diverse dello stesso file, mancanza di storico e difficoltà nel capire lo stato di una richiesta
Risultato atteso	Una sola fonte di verità per le richieste interne, con stato aggiornato e storico delle modifiche
Canale di accesso	Browser desktop; accesso autenticato con ruoli
Confine del progetto	Dentro: richieste, validazione, assegnazione, stato, notifiche, report base. Fuori: contabilità completa, CRM avanzato, BI completa, app mobile nativa
Vincoli	Non usare dati sensibili in chiaro nei campi liberi; definire ruoli e permessi prima dello sviluppo
Decisione attesa	Capire se il progetto deve partire da MVP o se esiste già un prodotto standard abbastanza vicino al processo

Questo brief dice al fornitore cosa deve entrare nel perimetro e cosa no. Il punto non è essere lunghi, ma essere specifici.

Requisiti indispensabili e opzionali

Per evitare ambiguità, separa i requisiti in due gruppi. Quelli indispensabili sono il cuore del progetto; quelli opzionali possono essere rimandati a una fase successiva o esclusi senza compromettere l’obiettivo.

Tipo	Requisito	Nota di chiarimento
Indispensabile	Autenticazione utenti	Serve sapere quale sistema di login è previsto e chi gestisce gli account
Indispensabile	Ruoli minimi: richiedente, approvatore, operatore, amministratore	Ogni ruolo deve avere permessi espliciti
Indispensabile	Creazione richiesta con campi obbligatori	Il brief deve elencare quali campi sono davvero obbligatori
Indispensabile	Ricerca e filtro per stato, data, reparto	Serve indicare anche l’ordinamento predefinito
Indispensabile	Storico modifiche	Va chiarito quali eventi entrano nel log
Indispensabile	Esportazione dati base	Specificare formato e per quale uso operativo
Opzionale	Notifiche email	Da attivare solo se il processo lo richiede davvero
Opzionale	Dashboard riepilogativa	Utile, ma non necessaria per avviare il primo rilascio
Opzionale	Integrazione con gestionale via API	Va descritta solo se il dato deve essere sincronizzato davvero
Opzionale	Allegati alle richieste	Attenzione a formato, dimensione e gestione accessi
Opzionale	Regole di approvazione configurabili	Vanno definite solo se cambiano spesso

Se un requisito è “utile” ma non cambia la decisione operativa, in genere è un candidato da spostare dopo il primo rilascio. Questo riduce il rischio di confondere il preventivo con una lista dei desideri.

Dati, sistemi e responsabilità: chi è titolare di cosa

Un preventivo serio non descrive solo schermate e funzioni. Deve anche dire quali dati entrano nel sistema, da dove arrivano, chi li mantiene e quale sistema è autorevole quando due valori non coincidono.

Elemento dati o sistema	Titolare del dato	Sistema autorevole	Note da inserire nel brief
Anagrafica utenti	IT o HR, secondo l’organizzazione	Directory aziendale o gestione account interna	Indicare se gli utenti arrivano da import manuale o da directory
Reparti	Amministrazione o direzione	Elenco reparti approvato	Serve una lista unica e aggiornata
Centri di costo	Amministrazione	Sistema contabile o gestionale	Va chiarita la fonte ufficiale
Stato richiesta	Processo interno definito dal progetto	Nuova app	Il flusso stati deve essere descritto in anticipo
Eventuali dati da gestionale	Team applicativo o ERP owner	Gestionale esistente	Specificare se l’integrazione è in lettura, scrittura o entrambi
Notifiche	Team progetto	Servizio email aziendale	Va definito chi gestisce errori e bounce

Il punto chiave è questo: se il brief non dice chi possiede il dato, il fornitore farà ipotesi. E le ipotesi, nei preventivi, diventano extra o ritardi.

Le voci del costo totale da mettere a confronto

Senza prezzi inventati, puoi comunque chiedere che ogni offerta espliciti le stesse voci. Così il confronto sarà sul contenuto, non solo sul totale finale.

Voce di costo	Cosa include	Cosa chiarire nel preventivo
Analisi iniziale	raccolta requisiti, workshop, mappa processo	numero di incontri, deliverable, esclusioni
Progettazione funzionale	flussi, wireframe, modello dati, permessi	chi approva e quante revisioni sono incluse
Sviluppo base	funzioni core del perimetro	cosa entra nel primo rilascio
Integrazioni	API, import/export, connettori	sistemi coinvolti e responsabilità di ciascun lato
Test e accettazione	test tecnici e supporto UAT	chi prepara i casi e chi firma l’esito
Rilascio	ambienti, deploy, configurazioni	quanti ambienti e quali finestre di rilascio
Formazione	training utenti e admin	durata, formato, materiali
Sicurezza e accessi	hardening, ruoli, audit	standard minimi attesi
Documentazione	manuali tecnici e utente	livello di dettaglio e aggiornamento previsto
Manutenzione	correzioni e supporto	SLA, canale di segnalazione, orari

Un’offerta più bassa non è automaticamente migliore: può semplicemente aver escluso alcune voci. Con questo schema, invece, il confronto diventa leggibile.

Gestione dei cambiamenti e manutenzione

La parte più costosa di un progetto software spesso non è l’avvio, ma il cambio di perimetro non governato. Per questo il brief deve dire come si gestiscono le variazioni.

Regola pratica da inserire:

la richiesta di modifica va scritta;
il fornitore valuta l’impatto su tempi, costi e test;
il cambiamento si approva prima dell’esecuzione.

Per la manutenzione, non fermarti a parole come “supporto incluso”. Chiedi invece di specificare:

cosa è correzione e cosa è evoluzione;
come si apre una segnalazione;
chi risponde;
quali tempi di presa in carico sono previsti;
come si misura una richiesta chiusa.

Questo evita che il preventivo sembri conveniente all’inizio e poi cresca a ogni richiesta non prevista.

Proprietà del codice, accessi e passaggio di consegne

Su proprietà del codice, repository e accessi serve chiarezza, ma non è il caso di improvvisare clausole legali nel brief. Il documento può però elencare i punti da concordare nel contratto:

chi possiede il codice sviluppato;
quali diritti di uso e modifica restano al cliente;
chi controlla repository, credenziali e pipeline;
come si gestiscono dipendenze e aggiornamenti;
cosa succede a fine progetto o in caso di cambio fornitore.

Il brief non deve sostituire il contratto; deve impedire che il contratto venga scritto su presupposti sbagliati.

Prove di accettazione: come rendere verificabile il lavoro

Microsoft sottolinea che i requisiti devono essere abbastanza chiari da permettere una verifica coerente. Qui il modo migliore è scrivere casi di accettazione semplici, con input esplicito ed esito atteso. Nel preventivo, questi casi aiutano anche a capire se il fornitore ha compreso davvero il processo.

Prova	Input	Esito atteso
1. Creazione richiesta	L’utente inserisce titolo, descrizione, reparto, priorità e allegato	Il sistema salva la richiesta, assegna un ID univoco e la mostra nello stato “nuova”
2. Campo mancante	Il richiedente lascia vuoto il reparto	Il sistema blocca l’invio, evidenzia il campo mancante e non crea record parziali
3. Cambio stato autorizzato	Un approvatore apre una richiesta “nuova” e la approva	Lo stato passa a “approvata” e l’evento resta nello storico
4. Ricerca filtrata	L’utente filtra per stato “in lavorazione” e intervallo date	Il sistema mostra solo le righe coerenti con i filtri
5. Azione non autorizzata	Un utente senza ruolo amministratore prova a cambiare parametri globali	Accesso negato e nessuna modifica salvata
6. Tracciamento modifica	Un operatore cambia un campo rilevante della richiesta	Il sistema registra chi ha cambiato cosa e quando

Questi non sono test teorici: sono esempi da copiare e adattare al tuo caso. Se il fornitore non riesce a commentarli con precisione, il brief è ancora troppo vago.

Quando basta un prodotto standard

Non sempre il custom è la scelta giusta. In diversi casi un prodotto standard, eventualmente configurato, basta davvero.

Una soluzione standard può essere sufficiente quando:

il processo è comune e non distingue l’azienda;
le eccezioni sono poche;
la personalizzazione servirebbe solo a replicare abitudini storiche;
il costo di manutenzione di un custom rischia di superare il beneficio.

Qui la fit-gap analysis è utile: elenca cosa copre lo standard, cosa manca e quanto pesa davvero il gap. Se la parte mancante è piccola, il preventivo per un progetto su misura può non essere la strada migliore. Se invece il gap è strutturale, allora ha senso formalizzare bene il capitolato e chiedere offerte comparabili.

Errori frequenti e come evitarli

Ecco i problemi che fanno saltare più spesso i preventivi:

Obiettivo troppo generico: “vogliamo digitalizzare il processo” non basta. Va detto quale processo, per chi e con quali dati.
Perimetro senza confini: se non scrivi cosa è fuori, ogni fornitore immagina cose diverse.
Integrazioni nominate ma non descritte: dire “si collega al gestionale” non basta; serve sapere in che direzione, con quali dati e chi possiede l’informazione.
Mancanza di criteri di accettazione: senza test concreti, l’offerta non aiuta a capire se il lavoro è finito davvero.
Manutenzione confusa con sviluppo: tenere insieme bug fix e nuove richieste rende impossibile capire il costo reale.

Se vuoi evitare questi errori, il consiglio più semplice è questo: prima di chiedere il preventivo, prova a far leggere il brief a una persona che non conosce il progetto. Se non capisce cosa deve succedere, il fornitore avrà lo stesso problema.

Cosa inviare per discutere il progetto

Quando sei pronto a parlare con una software house, non inviare dati riservati né credenziali. Bastano informazioni operative non sensibili, ma complete:

obiettivo del processo;
utenti coinvolti e ruoli;
sistemi già in uso;
integrazioni necessarie;
tre problemi principali da risolvere;
due risultati che il progetto deve ottenere;
vincoli di sicurezza, audit o tempi di rilascio;
eventuali parti già coperte da strumenti standard.

Se vuoi approfondire il caso con chi progetta software e integrazioni, puoi partire da Sviluppo software su misura e integrazioni, valutare una fase di analisi con Consulenza strategica e governance IT e usare Contatti Dedaloop per inviare una descrizione del processo e dei sistemi da collegare.

In sintesi: un preventivo software su misura è confrontabile solo se il capitolato dice chiaramente cosa entra nel progetto, cosa resta fuori, quali dati valgono come fonte, come si testano i risultati e come si gestiscono cambiamenti e manutenzione. Prima del listino, serve il perimetro.