Capitolato tecnico per gestione documentale e conservazione: i requisiti che contano davvero negli enti pubblici complessi

Scrivere un capitolato tecnico per un sistema di gestione documentale o conservazione non significa compilare una lista di funzionalità. Significa decidere, prima della gara o dell’affidamento, quali condizioni devono permettere all’ente di governare documenti, fascicoli, processi, sicurezza, interoperabilità, conservazione, audit e continuità nel tempo.

Negli enti pubblici complessi questo passaggio è decisivo. Una Regione, una ASL, un’Università o un ente multi-sede non compra semplicemente una piattaforma. Sta scegliendo un pezzo dell’infrastruttura amministrativa che dovrà sostenere procedimenti, atti, workflow, accessi, pubblicazioni, conservazione, controlli e integrazioni con altri sistemi.

Il rischio più grande è scrivere un capitolato troppo generico. Oppure, al contrario, costruire un documento molto lungo ma pieno di requisiti poco verificabili. In entrambi i casi l’ente si espone a un problema concreto: selezionare una soluzione che sembra adeguata sulla carta, ma che poi non regge nella pratica.

Un buon capitolato tecnico deve fare una cosa precisa: trasformare la governance documentale in requisiti verificabili.

Questo contenuto apre il blocco dedicato a procurement e capitolati e si collega ai pillar già sviluppati su governance documentale negli enti complessi, matrice RACI nella PA, fascicolo informatico difendibile, metadati per enti complessi, mappa procedimenti e classificazione documentale e security-by-design nella gestione documentale.

Il punto è semplice: se questi temi non entrano nel capitolato, difficilmente entreranno davvero nel progetto.

Perché il capitolato è un atto di governance, non solo di acquisto

Molti capitolati vengono scritti come se il problema fosse solo scegliere un software. Funzionalità, moduli, utenti, protocolli, conservazione, assistenza, formazione. Tutto corretto, ma non sufficiente.

Un sistema documentale non è solo un applicativo. È il punto in cui si incontrano organizzazione, procedimento amministrativo, archivio, sicurezza, interoperabilità, conservazione, responsabilità e qualità del dato.

Per questo il capitolato dovrebbe rispondere a domande molto concrete:

• quali processi documentali deve sostenere il sistema;
• quali ruoli devono poter lavorare e decidere;
• quali fascicoli devono essere ricostruibili;
• quali metadati devono essere governati;
• quali integrazioni sono essenziali;
• quali log devono essere disponibili;
• quali dati devono poter essere esportati;
• quali SLA sono davvero critici;
• quali controlli deve poter fare l’ente;
• come si evita il lock-in tecnologico e contrattuale.

Se queste domande non sono presenti, il capitolato rischia di concentrarsi su ciò che il fornitore sa mostrare meglio, non su ciò che l’ente deve governare davvero.

Il primo errore: chiedere “tutto” senza distinguere ciò che conta

Uno degli errori più frequenti è costruire capitolati con lunghi elenchi di requisiti tutti apparentemente importanti, ma senza una reale gerarchia.

Il risultato è che requisiti strategici e requisiti accessori finiscono sullo stesso piano. L’interfaccia grafica, una funzione marginale, un requisito di reportistica, un’integrazione critica, un’esigenza di export, un vincolo di conservazione e una misura di sicurezza vengono trattati come se avessero lo stesso peso.

In un ente complesso questo approccio è pericoloso.

Un buon capitolato dovrebbe distinguere almeno tra:

• requisiti essenziali;
• requisiti qualificanti;
• requisiti migliorativi;
• requisiti opzionali;
• requisiti da verificare in demo o PoC;
• requisiti da verificare in fase di collaudo.

Questa distinzione aiuta l’ente a valutare meglio le offerte e riduce il rischio di scegliere soluzioni molto convincenti nella presentazione, ma deboli sui punti critici.

Requisito 1: processi documentali e procedimenti reali

Il capitolato deve partire dai processi, non solo dalle funzioni.

Prima di chiedere “il sistema deve gestire i fascicoli”, l’ente dovrebbe chiarire quali fascicoli, in quali procedimenti, con quali passaggi, quali strutture coinvolte e quali punti di controllo.

Per esempio, il capitolato dovrebbe descrivere almeno alcuni scenari d’uso reali:

• gestione di un atto deliberativo;
• gestione di un procedimento multi-ufficio;
• gestione di una gara o contratto;
• gestione di documenti relativi al personale;
• gestione di un fascicolo con dati riservati;
• gestione di un flusso tra protocollo, workflow, firma e conservazione;
• gestione di un procedimento che coinvolge sistemi verticali.

Questi scenari non devono trasformare il capitolato in un manuale operativo. Servono a evitare che il fornitore risponda solo su funzionalità generiche. Per descriverli in modo realistico è utile coinvolgere fin da subito il personale di protocollo e archivio e gli operatori che lavorano ogni giorno su documentazione e fascicoli: sono loro a conoscere le eccezioni, i colli di bottiglia e i passaggi manuali che un capitolato scritto solo a tavolino tende a ignorare.

Un requisito scritto bene non dice soltanto “il sistema deve supportare workflow configurabili”. Dice quali tipi di workflow devono essere sostenuti, con quali passaggi, quali ruoli, quali eccezioni e quali evidenze.

Requisito 2: fascicolo informatico ricostruibile

Il capitolato dovrebbe indicare chiaramente che il fascicolo non è un semplice contenitore di documenti.

Il sistema deve permettere di ricostruire:

• documenti principali e allegati;
• versioni;
• passaggi istruttori;
• stati del procedimento;
• relazioni tra documenti;
• responsabilità e prese in carico;
• log e audit trail;
• collegamento con conservazione;
• eventuali eccezioni o anomalie.

Questo punto si collega direttamente al concetto di fascicolo informatico difendibile. Se il capitolato non richiede ricostruibilità, catena di custodia e versioning, il tema emergerà dopo, quando sarà più costoso correggere.

Un requisito utile potrebbe essere formulato così:

“Il sistema deve consentire la ricostruzione del fascicolo in termini di documenti, allegati, versioni, stati, relazioni, passaggi di responsabilità e principali eventi registrati, garantendo la leggibilità del procedimento nel tempo.”

Questa formulazione è più utile di una richiesta generica di “gestione fascicoli”.

Requisito 3: metadati governabili, non solo configurabili

Molti sistemi permettono di configurare metadati. Ma la domanda vera è: il modello dei metadati è governabile nel tempo?

Il capitolato dovrebbe richiedere almeno:

• definizione di metadati obbligatori e opzionali;
• gestione di vocabolari controllati;
• regole di validazione;
• ereditarietà o valorizzazione automatica quando possibile;
• differenziazione per tipologia documentale o procedimento;
• tracciabilità delle modifiche ai metadati rilevanti;
• interoperabilità dei metadati con altri sistemi;
• esportabilità dei metadati in formato leggibile e documentato.

Il tema è cruciale perché i metadati sono ciò che permette a fascicoli, workflow, ricerca, conservazione e audit di funzionare. Un capitolato che li tratta come semplici “campi” rischia di sottovalutare uno dei punti più delicati della gestione documentale.

Requisito 4: sicurezza, accessi e segregazione dei ruoli

Il capitolato deve tradurre la security-by-design nella gestione documentale in requisiti concreti.

Non basta chiedere autenticazione e profili utente. Bisogna indicare cosa l’ente si aspetta in termini di:

• gestione granulare dei permessi;
• distinzione tra lettura, modifica, approvazione, trasmissione, annullamento, esportazione;
• gestione di gruppi, ruoli e deleghe;
• applicazione del principio del privilegio minimo;
• revoca degli accessi;
• segregazione tra ruoli amministrativi e ruoli operativi;
• tracciamento degli accessi a documenti sensibili;
• log delle azioni rilevanti;
• gestione di eccezioni temporanee;
• report per audit e controllo.

Il requisito di sicurezza non deve essere scritto solo per l’IT. Deve essere leggibile anche da chi governa i processi documentali.

Un sistema sicuro ma ingestibile crea blocchi. Un sistema comodo ma troppo aperto crea rischio. Il capitolato deve cercare l’equilibrio. Vale anche la pena chiedere come la soluzione supporta la continuità operativa in caso di incidente, tema affrontato nel playbook anti-ransomware per sistemi documentali.

Requisito 5: log, audit trail e controlli

Un sistema documentale senza log utili espone l’ente a un problema serio: non riuscire a dimostrare cosa è successo.

Il capitolato dovrebbe richiedere log e audit trail su eventi rilevanti, per esempio:

• accesso a documenti e fascicoli;
• modifiche;
• cambi di stato;
• approvazioni;
• esportazioni;
• trasmissioni;
• pubblicazioni;
• anomalie;
• versamenti in conservazione;
• operazioni amministrative sui profili.

Ma non basta dire che il sistema deve produrre log. Serve specificare che i log devono essere:

• consultabili da utenti autorizzati;
• esportabili;
• leggibili;
• collegabili a documento, fascicolo, utente, ruolo e timestamp;
• utilizzabili in audit;
• conservati per tempi coerenti con le policy dell’ente;
• protetti da alterazioni non autorizzate.

Un log che esiste ma non si riesce a usare in una verifica vale poco.

Requisito 6: interoperabilità con sistemi e piattaforme

Negli enti complessi, il sistema documentale non vive mai da solo.

Deve dialogare con:

• protocollo;
• PEC;
• firme elettroniche;
• sistemi verticali;
• gestionali amministrativi;
• sistemi sanitari o universitari, dove presenti;
• workflow;
• portali;
• piattaforme di approvvigionamento digitale;
• conservazione;
• sistemi di identità e accesso;
• strumenti di pubblicazione e trasparenza.

Il capitolato dovrebbe evitare formule generiche come “il sistema deve essere integrabile”. Serve chiedere:

• API documentate;
• formati di scambio chiari;
• tracciabilità dei flussi;
• gestione degli errori di integrazione;
• log delle interazioni;
• responsabilità tra sistemi;
• documentazione tecnica aggiornata;
• supporto a scenari di interoperabilità previsti dall’ente.

Nel procurement pubblico questo punto è sempre più importante anche perché l’intero ciclo di vita dei contratti pubblici è ormai gestito attraverso un ecosistema digitale e piattaforme certificate, come illustrato nella sezione ANAC sulla digitalizzazione dei contratti pubblici. Per gli enti, questo significa che la gestione documentale deve essere progettata sapendo che dati, atti, fascicoli, procedure e obblighi di trasparenza non vivono in silos separati.

Requisito 7: conservazione digitale e continuità nel tempo

La conservazione non può essere trattata come un modulo finale o come una voce accessoria.

Il capitolato dovrebbe chiarire:

• come il sistema prepara i documenti al versamento;
• come gestisce pacchetti, metadati e relazioni;
• come monitora anomalie e rigetti;
• quali evidenze restano disponibili;
• come si garantisce il collegamento tra fascicolo e conservazione;
• quali responsabilità restano in capo all’ente;
• quali verifiche può fare il Responsabile della conservazione;
• come vengono gestite esibizione, recupero e consultazione.

Uno degli errori più frequenti è separare troppo gestione documentale e conservazione. Così facendo, i problemi prodotti a monte emergono a valle, quando correggerli è più difficile.

Requisito 8: export, reversibilità e riduzione del lock-in

Un capitolato serio deve prevedere il momento in cui il contratto finirà, il sistema cambierà o l’ente dovrà migrare dati e documenti.

Questo è uno dei requisiti più sottovalutati.

Bisogna chiedere in modo esplicito:

• export completo dei documenti;
• export dei metadati;
• export dei fascicoli e delle relazioni;
• export dei log rilevanti;
• documentazione dei formati;
• tempi e modalità di estrazione;
• supporto alla migrazione;
• obblighi del fornitore in fase di uscita;
• test di export durante il contratto, non solo alla fine;
• costi e condizioni della reversibilità.

Il lock-in non nasce solo dalla tecnologia. Nasce anche da contratti che non obbligano il fornitore a rendere l’uscita praticabile.

Per un ente pubblico, la reversibilità non è un dettaglio: è una garanzia di continuità, controllo e autonomia.

Requisito 9: SLA davvero utili

Gli SLA non devono misurare solo disponibilità tecnica o tempi di risposta del supporto.

Un sistema documentale richiede SLA che coprano anche:

• disponibilità del servizio;
• tempi di presa in carico;
• tempi di risoluzione per criticità diverse;
• incidenti su accessi o permessi;
• malfunzionamenti dei workflow;
• anomalie di integrazione;
• problemi di versamento in conservazione;
• indisponibilità di funzioni critiche;
• tempi di ripristino;
• qualità della reportistica;
• supporto nelle verifiche e negli audit.

Gli SLA devono essere collegati a impatti reali sui processi. Un problema sul protocollo, su un fascicolo critico o sulla conservazione non ha lo stesso peso di un problema su una funzione marginale.

Requisito 10: collaudo e verifica dei requisiti

Molti capitolati indicano requisiti corretti, ma poi non prevedono un collaudo abbastanza forte per verificarli.

Il collaudo dovrebbe includere casi d’uso reali, non solo verifica formale della presenza delle funzioni.

Per esempio:

• apertura e gestione di un fascicolo complesso;
• gestione di versioni documentali;
• cambio di stato con profili diversi;
• tracciamento di accessi e modifiche;
• export di fascicolo con documenti e metadati;
• integrazione con un sistema esterno;
• simulazione di anomalia di versamento;
• verifica di log e audit trail;
• test di reversibilità;
• test di backup e ripristino, se compreso nel perimetro.

Senza collaudo operativo, l’ente rischia di accorgersi troppo tardi che un requisito era stato interpretato in modo diverso dal fornitore.

Il ruolo della scorecard

Un buon capitolato dovrebbe essere accompagnato da una scorecard di valutazione.

La scorecard serve a confrontare le offerte non solo sul prezzo o sulla quantità di funzioni dichiarate, ma sulla qualità delle risposte rispetto ai requisiti critici.

Le aree da pesare possono essere:

• copertura funzionale;
• qualità documentale;
• sicurezza;
• interoperabilità;
• conservazione;
• audit e log;
• usabilità per gli operatori;
• supporto e SLA;
• export e reversibilità;
• esperienza su enti complessi;
• qualità del piano di avvio.

Questo tema è approfondito nel contenuto dedicato a come valutare un fornitore con una scorecard.

Gli errori più frequenti nei capitolati documentali

Ci sono errori che si ripetono spesso:

• descrivere solo funzioni e non processi;
• non distinguere requisiti essenziali e migliorativi;
• chiedere integrazioni in modo generico;
• sottovalutare export e reversibilità;
• non prevedere collaudi su casi reali;
• trattare la conservazione come appendice;
• dimenticare log e audit trail;
• non coinvolgere abbastanza gestione documentale, IT, conservazione, protocollo, archivio e strutture operative;
• usare formule troppo vaghe, difficili da verificare;
• non collegare requisiti, SLA e penali a impatti reali.

Un capitolato scritto male non è solo un problema amministrativo. È un rischio di progetto. Molti di questi aspetti tornano anche negli errori ricorrenti nelle gare ICT documentali.

Come partire se il capitolato va scritto in tempi stretti

Capita spesso: il tempo è poco, la gara va preparata, gli uffici devono contribuire rapidamente.

In questi casi conviene evitare la tentazione di copiare capitolati precedenti senza adattarli.

Un metodo pragmatico può essere questo:

1. identificare 5-7 scenari d’uso critici;
2. definire i requisiti essenziali per ciascuno;
3. chiarire quali integrazioni sono davvero necessarie;
4. scrivere requisiti verificabili, non desideri generici;
5. prevedere export, audit, sicurezza e collaudo;
6. costruire una scorecard semplice ma robusta;
7. coinvolgere almeno RTD, gestione documentale, IT, conservazione, protocollo e archivio, gli operatori che gestiscono documentazione e fascicoli e il procurement.

Il capitolato non deve essere perfetto in astratto. Deve essere abbastanza preciso da proteggere l’ente dalle ambiguità più costose.

Dai requisiti sulla carta alla governance reale

Un capitolato tecnico per gestione documentale e conservazione non dovrebbe limitarsi a chiedere un software. Dovrebbe mettere nero su bianco le condizioni minime per governare documenti, fascicoli, processi, sicurezza, conservazione e interoperabilità nel tempo.

Scopri come Docsuite Next può aiutarti a progettare requisiti, processi e criteri di valutazione per una gestione documentale più solida, interoperabile e sostenibile.

Domande frequenti

Che cosa deve contenere un capitolato tecnico per la gestione documentale?

Dovrebbe contenere requisiti su processi documentali, fascicoli, metadati, workflow, sicurezza, log, interoperabilità, conservazione, SLA, export, reversibilità, collaudo e supporto.

Perché il capitolato non deve limitarsi alle funzionalità?

Perché un sistema documentale deve sostenere procedimenti reali, responsabilità, controlli, integrazioni e continuità nel tempo. Le funzionalità da sole non garantiscono governance.

Come evitare il lock-in con il fornitore?

Prevedendo requisiti chiari su export, reversibilità, formati, documentazione, supporto alla migrazione e test periodici di estrazione dei dati e dei documenti.

Gli SLA devono riguardare solo la disponibilità del sistema?

No. Dovrebbero coprire anche supporto, incidenti, workflow, integrazioni, anomalie di conservazione, tempi di ripristino e criticità che impattano i processi documentali.

Perché serve una scorecard di valutazione?

Perché aiuta a confrontare i fornitori su criteri omogenei e verificabili, evitando di scegliere solo in base a prezzo, presentazione commerciale o numero di funzioni dichiarate.