Blog / Scelta del software gestionale

Capitolato per un software gestionale cloud: requisiti e matrice RFP

Pubblicato il 10 settembre 2026 · Redazione Gestionale sul Web

Chiedere “fatturazione, magazzino, CRM e dashboard” produce quasi sempre risposte positive, ma poco confrontabili. Due fornitori possono dichiarare la stessa funzione e intendere flussi, limiti, costi e responsabilità molto diversi. Un capitolato per il software gestionale trasforma bisogni generici in condizioni osservabili prima della scelta.

Che cosa sono capitolato e RFP

Nel contesto di una selezione software, il capitolato raccoglie ciò che l'azienda chiede alla soluzione e al progetto: obiettivi, perimetro, requisiti, servizi, vincoli, prove e condizioni. La RFP, Request for Proposal, è la richiesta formale con cui quel contenuto viene sottoposto a uno o più fornitori per ricevere proposte organizzate nello stesso modo.

Per una PMI non serve imitare un bando pubblico: serve un documento proporzionato al rischio. Se il gestionale governa ordini, magazzino, fatture e produzione, una mail con un elenco di moduli è troppo debole. Per un perimetro semplice può bastare una matrice essenziale, purché sia verificabile.

Il capitolato completa, senza sostituirla, la guida generale su come scegliere un software gestionale: qui l'attenzione è sul documento operativo che consente di chiedere e valutare le stesse informazioni.

Prima di scrivere: processi, persone e confini

La qualità dei requisiti dipende dal lavoro svolto prima. Riunisci un gruppo piccolo ma rappresentativo: responsabile del progetto, utenti dei processi critici, referente IT o integrazioni, amministrazione e decisore economico. Coinvolgere soltanto la direzione porta a sottostimare eccezioni e attività quotidiane; coinvolgere soltanto gli utenti rischia di perdere vincoli contrattuali e obiettivi di lungo periodo.

1. Definisci l'obiettivo. Ridurre doppie registrazioni, rendere disponibile una giacenza attendibile o chiudere più rapidamente il ciclo ordine-incasso è più utile di “digitalizzare”.
2. Mappa l'AS-IS. Indica sistemi, fogli, ruoli, volumi, picchi, punti di controllo e passaggi manuali esistenti.
3. Disegna il TO-BE. Descrivi il risultato desiderato senza imporre subito la schermata o la tecnologia con cui ottenerlo.
4. Seleziona le eccezioni. Resi, consegne parziali, sconti fuori soglia, articoli sostitutivi e dati incompleti distinguono una demo reale da un percorso ideale.
5. Fissa i confini. Specifica società, sedi, depositi, utenti, lingue, dispositivi, dati storici e sistemi che resteranno esterni.

Usa dati anonimi o sintetici che conservino struttura e casi limite senza esporre informazioni personali o commerciali non necessarie.

Le dieci sezioni che rendono completo il capitolato

Indica anche ciò che è fuori perimetro: se formazione, bonifica dati o un connettore non sono descritti, le offerte possono basarsi su ipotesi incompatibili.

Come scrivere un requisito verificabile

Espressioni come “facile”, “veloce”, “integrato” o “sicuro” descrivono intenzioni, non condizioni di accettazione. Un requisito utile contiene almeno cinque elementi: attore, evento, regola, risultato ed evidenza. Quando conta, aggiungi volume, tempo, dispositivo e permesso.

Chiedi al fornitore di classificare la copertura: standard già disponibile, configurazione, modulo opzionale, integrazione di terzi, personalizzazione o non disponibile. Per ogni risposta non standard servono stima, prerequisiti, impatto sugli aggiornamenti e soggetto responsabile. Una semplice casella “sì” nasconde la parte più importante.

Per le integrazioni non basta indicare il nome dell'altro sistema. Specifica oggetti scambiati, sistema responsabile del dato, frequenza, identificativi, regole di duplicazione, gestione degli errori, riconciliazione, autenticazione e ambiente di prova. La guida sulle API del software gestionale aiuta a porre domande tecniche senza ridurre il requisito alla presenza di un'API.

Obbligatori, valutabili e opzionali: come assegnare le priorità

Se tutto è prioritario, nulla orienta la decisione. Usa tre classi comprensibili a tutti:

• Obbligatorio: senza questo requisito la soluzione non è idonea. Deve essere pochi punti, motivati da processo, rischio o vincolo.
• Valutabile: genera valore e contribuisce al punteggio. Il peso riflette impatto e frequenza, non la preferenza di chi scrive.
• Opzionale: è interessante ma può essere rinviato o escluso senza compromettere il progetto.

Verifica prima gli obbligatori. Solo le proposte idonee entrano nel confronto pesato. Per evitare una precisione artificiale, limita i criteri e usa una scala con definizioni: per esempio 0 non coperto, 1 personalizzazione rilevante, 2 configurazione o modulo, 3 standard dimostrato. Costo e qualità non vanno sommati senza dichiarare metodo, pesi e ipotesi.

Fissa priorità e punteggi prima delle demo, così la presentazione non modifica le regole del confronto.

Requisiti specifici per cloud, dati e contratto

Per un software gestionale in cloud, il capitolato deve collegare l'esperienza applicativa al servizio che la sostiene. Chiedi identità e ruoli, autenticazione, registri delle operazioni, gestione degli accessi, cifratura dove pertinente, backup e prove di ripristino, disponibilità, tempi di risposta, finestre di manutenzione, comunicazione degli incidenti e responsabilità condivise. ENISA propone alle PMI di trasformare rischi e necessità in domande di procurement, e ricorda che le verifiche periodiche del fornitore non sostituiscono il monitoraggio del servizio tra una verifica e l'altra.

Indica volumi realistici: utenti contemporanei, righe documento, articoli, movimenti, allegati e picchi. “Il sistema è veloce” non è misurabile; “la ricerca di un articolo nell'archivio di prova restituisce il risultato entro il tempo concordato nel 95% delle prove” definisce un controllo, purché ambiente e condizioni siano noti.

Portabilità ed uscita vanno progettate prima dell'ingresso. Elenca dati, metadati, allegati e configurazioni da esportare; formati, documentazione, frequenza, tempi, assistenza, conservazione e cancellazione; costi e responsabilità. Il Data Act europeo, applicabile dal 12 settembre 2025, stabilisce regole sul passaggio tra servizi di trattamento dati. L'articolo 25 prevede, tra gli elementi contrattuali, categorie esportabili, assistenza, continuità e sicurezza durante il passaggio, un preavviso massimo di due mesi, un periodo transitorio normalmente non superiore a 30 giorni e almeno 30 giorni per recuperare i dati dopo la transizione. Ambito, eccezioni e applicazione al singolo servizio vanno verificati con competenza legale: il capitolato non sostituisce il contratto.

Completa la visione economica con un costo totale su un orizzonte comune: licenze, utenti, moduli, attivazione, migrazione, formazione, personalizzazioni, integrazioni, ambienti di test, assistenza, consumi, adeguamenti e uscita. La pagina sui prezzi del gestionale cloud mostra le componenti commerciali del prodotto; nella RFP ogni fornitore deve compilare lo stesso schema di costo.

Come inserire le funzioni AI senza comprare promesse

“Include l'intelligenza artificiale” è troppo generico. Descrivi il caso d'uso: cercare informazioni, classificare documenti, suggerire una previsione, riassumere uno storico o preparare un'azione. Per ciascuno indica utenti autorizzati, dati accessibili, risultato atteso, livello di autonomia e conseguenza di un errore.

Chiedi come il sistema mostra fonti, dati e periodo utilizzati; come gestisce informazioni mancanti o domande ambigue; se separa suggerimento ed esecuzione; quali conferme sono richieste; come registra input, output e azioni; chi può disattivare la funzione; quali dati vengono inviati a soggetti terzi e con quali condizioni; come variano costi e limiti d'uso. Se l'AI genera una previsione, il capitolato deve definire anche la misura con cui verrà valutata e il confronto di riferimento.

Prima di chiedere automazioni avanzate, verifica anagrafiche, codifiche, relazioni, storico e permessi con la guida sui dati gestionali pronti per l'AI. Risalire alla fonte è spesso più utile di una risposta formulata con sicurezza.

Dalla risposta alla demo e poi al collaudo

La demo deve verificare i requisiti che separano davvero le proposte. Prepara da tre a cinque scenari frequenti e uno o due casi rari ma rischiosi. Fornisci lo stesso contesto e gli stessi dati a tutti. Lascia operare gli utenti aziendali, annotando esito, tempo, errori, aiuti e qualità del risultato secondo il metodo descritto nel test di usabilità del gestionale.

Se una funzione non esiste, il fornitore deve dichiararlo e proporre perimetro, stima e criteri di accettazione. Un prototipo non prova che la funzione sia pronta per la produzione.

I requisiti selezionati devono poi fluire nel contratto e nel piano di collaudo. A ogni punto critico associa evidenza, responsabile, ambiente, data e gestione dell'esito negativo. Conserva anche le assunzioni dell'offerta: numero utenti, qualità dei dati, disponibilità dei referenti e sistemi esterni possono cambiare tempi e costi.

Matrice RFP di esempio

La tabella seguente è un modello minimo. In un documento operativo aggiungi identificativo, processo, requisito completo, priorità, peso, risposta del fornitore, modalità di copertura, prova, costo, tempi, dipendenze, responsabilità e note.

Errori da evitare

• Copiare il catalogo di un fornitore e trasformarlo nel capitolato.
• Descrivere soltanto il percorso ideale, senza ruoli, eccezioni e controlli.
• Accettare risposte sì/no senza distinguere standard, configurazione, modulo e sviluppo.
• Valutare il canone senza migrazione, integrazioni, formazione, consumi e uscita.
• Chiedere “API disponibili” senza oggetti, limiti, autenticazione, errori e ambiente di prova.
• Rimandare portabilità, proprietà dei dati e cancellazione alla fine della trattativa.
• Assegnare punteggi dopo la demo o cambiare pesi per adattarli al prodotto preferito.

Il capitolato non elimina l'incertezza, ma la rende visibile e negoziabile. Una proposta meno brillante può risultare migliore se dichiara con precisione limiti, dipendenze e responsabilità. È questa trasparenza che permette di passare dalla promessa al progetto.

Domande frequenti

Che cos'è una RFP per software gestionale?

È una richiesta strutturata rivolta a più fornitori per ottenere proposte confrontabili. Descrive contesto, obiettivi, processi, requisiti, vincoli, prove, tempi, responsabilità e criteri di valutazione.

Quanto deve essere dettagliato un capitolato gestionale?

Deve essere abbastanza preciso da rendere verificabili i requisiti, senza prescrivere inutilmente la soluzione tecnica. I processi critici richiedono scenari, regole, volumi ed eccezioni; per le aree secondarie può bastare una descrizione più sintetica.

Come si confrontano le risposte dei fornitori?

Si usa una matrice comune con priorità, modalità di copertura, prova richiesta, costo, tempi, dipendenze e responsabilità. I requisiti obbligatori vanno controllati prima del punteggio pesato degli altri criteri.

Quali requisiti inserire per un gestionale cloud?

Oltre ai processi aziendali, servono requisiti su identità e permessi, sicurezza, disponibilità, prestazioni, browser e mobile, integrazioni, esportazione dati, continuità, migrazione, supporto, aggiornamenti e condizioni di uscita.

Come descrivere le funzioni AI nel capitolato?

Per ogni caso d'uso indica dati accessibili, autorizzazioni, risultato atteso, fonti o evidenze, controllo umano, registrazione delle operazioni, gestione degli errori, possibilità di disattivazione e costi.

Vuoi confrontare il gestionale sui tuoi requisiti reali?

Prepara processi, priorità e scenari: la demo potrà rispondere a domande verificabili invece di mostrare soltanto un catalogo.

Esamina le funzioniRichiedi una demo

Fonti: Regolamento (UE) 2023/2854, Data Act; Commissione europea, Data Act explained; ENISA, Cloud Security Guide for SMEs; ENISA, Procure Secure; NIST Cloud Computing Standards Roadmap. Consultate il 10 settembre 2026.