Capitolato software gestionale: la checklist che evita ambiguità

Descrivete i processi come sequenze, non come schermate. Per ogni workflow indicate evento iniziale, attori, informazioni necessarie, passaggi, stati, regole, notifiche e risultato finale. Un esempio sintetico: «il commerciale crea la bozza; sopra una determinata condizione serve l'approvazione del responsabile; dopo l'approvazione il documento non è più modificabile, viene inviato e il gestionale registra data e versione».

Il percorso ideale è solo metà del requisito. Aggiungete le eccezioni: dato mancante, ordine duplicato, approvazione rifiutata, servizio esterno non disponibile, modifica dopo la chiusura, annullamento e riapertura. Dite chi può sbloccare il caso, quale traccia deve rimanere e come evitare che un errore silenzioso produca dati incoerenti. Se state ripensando molti passaggi manuali, la guida all'automazione dei processi aziendali aiuta a distinguere ciò che va semplificato da ciò che conviene automatizzare.

Allegate esempi anonimi di moduli, report e documenti oggi usati. Sono materiale di analisi, non una richiesta di copiare il vecchio strumento. Annotate per ogni campo perché esiste e chi lo usa: spesso emergono duplicazioni, regole tramandate senza motivo o informazioni fondamentali nascoste in note libere.

Un gestionale vive nei suoi dati. Create un inventario delle entità importanti — clienti, prodotti, ordini, commesse, documenti, listini — e indicate per ciascuna la fonte autorevole. Se lo stesso cliente compare in CRM, foglio e contabilità, il capitolato deve dire quale sistema prevale, come si riconoscono i duplicati e chi risolve i conflitti.

Per la migrazione specificate formati disponibili, volume da valutare, qualità nota, storico necessario e dati che possono essere archiviati senza portarli nel nuovo sistema. Prevedete una mappatura tra campi sorgente e destinazione, regole di trasformazione, campioni realistici e verifiche dopo l'importazione. «Importare tutto» non è un criterio di accettazione: servono conteggi, totali di controllo, controlli sulle relazioni e una procedura per gestire gli scarti.

Definite anche conservazione, cancellazione, esportazione e tracciamento delle modifiche in base alle esigenze del processo e alle indicazioni dei vostri referenti privacy. Non trasformate il capitolato in un parere legale: rendete però esplicite le decisioni che software, contratto e organizzazione dovranno attuare.

Per ogni collegamento indicate sistema, proprietario, scopo, dati scambiati, direzione, frequenza e comportamento in caso di errore. Chiarite quale applicazione è la fonte autorevole e se la sincronizzazione è immediata, programmata o avviata dall'utente. Le guide su API e webhook spiegano i due meccanismi più comuni; un caso concreto è l'integrazione tra gestionale ed e-commerce.

Chiedete documentazione e ambiente di prova dei servizi esterni, metodo di autenticazione, limiti, vincoli di licenza e referente tecnico. Il requisito deve coprire anche timeout, messaggi duplicati, indisponibilità e recupero: dove finisce una richiesta fallita? Chi riceve l'avviso? Si può riprovare senza creare due ordini? Esiste una procedura manuale temporanea? Queste domande valgono più di un semplice «integrare il CRM».

Quando un fornitore esterno non offre un'interfaccia affidabile, fatelo emergere come dipendenza e rischio, non come dettaglio da risolvere a sviluppo iniziato. Le credenziali di produzione devono avere un proprietario definito e non vanno incorporate nel codice o condivise informalmente.

I requisiti non funzionali descrivono come il sistema deve operare. Indicate dispositivi e browser realmente usati, condizioni di rete, accessibilità necessaria, lingue, picchi di utilizzo, disponibilità attesa e finestre di manutenzione. Per prestazioni e capacità usate scenari misurabili — pagina, numero di utenti concorrenti, quantità di record e percentile — invece di aggettivi come «veloce» o «scalabile».

La sicurezza va tradotta in controlli e prove: gestione delle sessioni, autorizzazioni lato server, protezione dei dati, registri degli eventi rilevanti, gestione dei segreti, dipendenze aggiornabili, vulnerabilità e risposta agli incidenti. L'OWASP Application Security Verification Standard 5.0 offre una base pubblica per scegliere requisiti verificabili e concordare il livello di rigore, anche in fase di acquisto. Non basta scrivere «il software sarà sicuro».

Per i dati personali, la Commissione europea richiama misure tecniche e organizzative fin dalle prime fasi e impostazioni predefinite che limitino dati, conservazione e accesso a quanto necessario. Nel capitolato traducete questo principio in campi indispensabili, ruoli minimi, cifratura o pseudonimizzazione dove appropriate, log, esportazione e cancellazione. La conformità va poi verificata con i vostri consulenti competenti sul caso concreto.

Per backup e continuità indicate quali dati sono coperti, frequenza, conservazione, posizione, cifratura, responsabilità e procedura di ripristino. Definite quanto dato potete perdere e quanto può durare un'interruzione in base all'impatto aziendale. Soprattutto, richiedete prove periodiche di ripristino: un backup mai restaurato è solo un'ipotesi.

Ogni requisito importante deve poter essere dimostrato. Scrivete criteri in forma concreta: contesto iniziale, azione, risultato e prova disponibile. «Dato un ordine già importato, quando arriva di nuovo lo stesso identificativo, il sistema non crea un duplicato e registra l'evento» è collaudabile; «gestire correttamente i duplicati» lascia spazio a interpretazioni.

Stabilite ambienti, dati di test, responsabilità, categorie di difetto e condizione di approvazione. Prevedete test tecnici, test dei flussi completi e accettazione da parte di utenti rappresentativi. Chiarite cosa blocca il rilascio, come si documentano le anomalie accettate e chi firma il verbale. Una demo o un prototipo validato prima dello sviluppo completo riduce il rischio di scoprire troppo tardi che il flusso corretto è stato interpretato male.

Il piano di rilascio deve comprendere preparazione dei dati, comunicazioni, formazione, assistenza iniziale, monitoraggio e ritorno alla versione precedente quando possibile. Per ogni passaggio nominate responsabile e condizione di via libera.

Elencate gli artefatti oltre al software funzionante: codice sorgente, cronologia del repository, istruzioni di avvio e distribuzione, configurazioni senza segreti, schema dati, documentazione delle integrazioni, test, manuale operativo, inventario delle dipendenze e licenze. Indicate chi possiede gli account Apple, Google, cloud, database, domini e servizi esterni; quando richiesto possono essere intestati direttamente al cliente. Pianificate fin dall'inizio accessi e uscita del fornitore, non soltanto il giorno della consegna.

Nel metodo Contat il cliente riceve accesso al repository Git dall'avvio e può usare e mantenere il codice consegnato senza limiti di tempo per l'intera vita del progetto commissionato, anche dopo il trasferimento del progetto secondo gli stessi accordi. Il contratto distingue il lavoro realizzato per il cliente dai componenti riutilizzabili o preesistenti e dal software di terzi o open source, che conservano titolarità e licenze proprie: è più preciso di promettere una generica «proprietà al 100%».

Definite nel contratto funzioni incluse ed escluse, persone assegnate, eventuali collaboratori esterni, proprietà intellettuale, privacy, sicurezza, backup, ritardi, recesso e consegna del lavoro incompleto. Stabilite canali, orari, priorità, presa in carico, aggiornamenti, monitoraggio e documentazione per manutenzione, correzioni e modifiche successive. Contat include e disciplina questi aspetti per i primi 12 mesi. Prima della firma comunica chi lavorerà sul progetto e gli eventuali collaboratori esterni; il marchio riunisce una rete di circa 22 professionisti tra sviluppo, marketing, social, design e video.

Consegnate lo stesso documento ai candidati e chiedete di evidenziare assunzioni, esclusioni, dipendenze e alternative. Una proposta seria non si limita a confermare ogni riga: segnala conflitti, pone domande e suggerisce una sequenza di validazione. Confrontate copertura dei requisiti, metodo, responsabilità, qualità delle consegne e gestione del rischio; il totale economico, da solo, non rivela cosa state acquistando.

Il capitolato non deve essere perfetto prima del primo confronto. Deve rendere visibili le questioni che richiedono una decisione. Con Smartquote potete ordinare le informazioni iniziali sul vostro software; la prima call con Contat è gratuita e serve a trasformarle in un perimetro concreto prima di firmare.