“Tu quoque, Consip”: l’accordo quadro per i software di protocollo informatico e gestione documentale

Fra gli strumenti di approvvigionamento ICT messi a disposizione della pubblica amministrazione italiana da Consip in attuazione di quanto previsto dall’AgID nel piano triennale per l’informatica nella pubblica amministrazione (edizione 2024-2026), è presente anche l’accordo quadro “Public cloud SaaS – Gestione documentale”.

Sembra uno strumento di capitale importanza, visto che – e non ammetto obiezioni al riguardo – il sistema di gestione documentale è il cuore del sistema informativo di una pubblica amministrazione.

Osservazione dal campo

Di recente, ho esplorato alcune iniziative Consip dal punto di vista dell’ente locale che, in cerca di strumenti per portare avanti il percorso di transizione digitale, ha bisogno di dotarsi degli applicativi (software) a supporto delle proprie funzioni istituzionali.

Solitamente si tratta di sostituire, per vari motivi, gli applicativi in uso o di dotarsi di nuovi software per “digitalizzare” attività ancora condotte con modalità analogiche o con strumenti digitali generici^[1]Conviene dare un senso al concetto di strumenti digitali generici. Mi riferisco anche allo scenario in cui una funzione dell’amministrazione è condotta, per esempio, formando documenti nativi … Continue reading o senza una attenta strutturazione dei dati che ne consenta rapida circolazione e riuso.

In quest’ottica, le iniziative della macroarea “Public cloud SaaS” sembrano le più indicate. Al momento ce ne sono alcune attive:

• Accordo quadro Public cloud Saas – Gestione documentale;
• Accordo quadro Public cloud SaaS – Produttività individuale e Collaboration 2;
• Accordo quadro Servizi SaaS di CRM e Marketing 2 (per il rapporto con i clienti/cittadini);
• Accordo quadro Funzionalità BI SaaS 2 (per la business intelligence).

Il secondo accordo quadro, noto anche come Pr.In.Co. 2, riguarda posta elettronica e suite di collaboration che includono storage condiviso, calendario, messaggistica e videochiamate, strumenti di editing di testi, fogli di calcolo e presentazioni. Tradotto: Microsoft 365, Google Workspace e simili. Mi è capitato, mesi fa, di valutare questo accordo quadro in occasione della scadenza del contratto per la posta elettronica, con scarsa soddisfazione. Infatti, al di là del fatto che le soluzioni Microsoft e Google sono scelte strutturali che vanno ben oltre la posta elettronica, le altre opzioni si sono rivelate incomplete e non integrabili con servizi aggiuntivi per la rigidità delle regole dell’accordo quadro e, dal punto di vista economico, più onerose rispetto alla medesima soluzione SaaS acquistata “sul mercato libero”, direttamente dal suo provider.

Voglio però soffermarmi in un’analisi più approfondita dell’accordo quadro che mette a disposizione software erogati in modalità SaaS per protocollo informatico, gestione documentale e conservazione digitale.

Prima, però, occorre una spiegazione sul significato di “Public cloud SaaS” (chi è già addentro alla questione può saltare il paragrafo a pie’ pari).

La macroarea public cloud SaaS

La macroarea Public cloud SaaS, già dal nome, è quella che dovrebbe consentire alle amministrazioni di dotarsi di software completi, secondo il paradigma Software as a Service, in cui l’amministrazione riceve un pacchetto completo di software già sviluppato e installato in un data center controllato dal fornitore del software stesso, configurazione iniziale, formazione e assistenza all’uso, manutenzione evolutiva durante il periodo di utilizzo ecc. Di fatto, la p.a. non si preoccupa di niente, utilizza un software, resta titolare dei dati presenti nel software, le regole (regolamento ACN per i servizi cloud) le assicurano pieno controllo su quei dati, nel senso che può estrarli in qualunque momento ed ha garanzie contrattuali – o almeno dovrebbe – sulla loro migrazione in altri sistemi a fine rapporto

Il paradigma SaaS consente di raggiungere alcuni benefici, specie quando implementato secondo logiche “moderne”, cioè, semplificando molto il linguaggio (mi scusino gli informatici ortodossi), quando l’installazione è unica per tutti gli enti serviti e l’architettura è magari pensata a microservizi, così che si possono raggiungere economie di scala. Per esempio, nel distribuire la potenza di calcolo (non tutti gli utilizzatori raggiungono il picco di utilizzo nello stesso istante), nell’applicare gli aggiornamenti (si sviluppa un aggiornamento per tutti i clienti, si applica una volta sola – magari senza interruzioni significative del servizio se il sistema è ben architettato) ecc.

Di converso, almeno in apparenza, il SaaS sembra meno propenso a personalizzazioni spinte o ad integrazioni con sistemi già in uso presso l’amministrazione. Infatti, da un lato, il fatto di avere un unico software che deve andare bene per tutti obbliga gli utilizzatori ad adattarsi a logiche di funzionamento condivise. Tuttavia, e ne esistono prove tangibili^[2]Nella mia amministrazione abbiamo in funzione molti SaaS: alcuni sono installazioni dedicate, in cui in linea teorica potremmo chiedere personalizzazioni arbitrarie (e costose, ovviamente); altri … Continue reading, un SaaS ben progettato permette di intervenire sulle configurazioni del singolo utilizzatore in modo molto incisivo, fino a consentire integrazioni con sistemi esterni.

SaaS, IaaS e PaaS

L’uso dei SaaS è ampiamente caldeggiato dal piano triennale per l’informatica della p.a. e, in generale, dalle strategie nazionali^[3]In uno dei capitolati che si citeranno nel seguito, si legge: “Nell’ambito del Programma Nazionale di Abilitazione al Cloud è definita – tra le altre – la strategia “Re-purchase” che … Continue reading, perché solleva le amministrazioni da compiti tecnico-informatici da assolvere spesso senza le necessarie risorse e che, in effetti, possono essere svolti con maggior efficacia se si centralizzano e si affidano, nell’ambito di un rapporto contrattuale chiaro, a un soggetto esterno che si obbliga a soddisfare i requisiti imposti dalla normativa e, in particolare, dal regolamento ACN per i servizi cloud. Per le amministrazioni piccole^[4]Esplicito il concetto di amministrazione piccola: esistono comuni con meno di 5 dipendenti; competenze informatiche utili alla conduzione di server applicativi si possono iniziare a trovare – … Continue reading, poi, il SaaS è davvero l’unica strada percorribile.

Per completare lo scioglimento di acronimi ricorrenti nel mondo del (public) cloud:

• IaaS, che sta per Infrastructure as a Service: il fornitore del cloud pubblico mette a disposizione server (virtuali) con le relative risorse di calcolo, memoria e storage (memorizzazione di dati) e il controllo sull’ambiente complessivo (firewall verso internet, regole di sicurezza interna al data center) e chi usa il servizio pensa (in proprio o delegando ad altri) a installare quanto necessario a far funzionare un software;
• PaaS, che sta per Platform as a Service: il fornitore del cloud pubblico, oltre a quanto previsto nel caso IaaS, mette a disposizione ulteriori servizi di carattere generale, quali per esempio un ambiente di Database Management System o un Web Server, condivisi a livello di data center per tutti gli utilizzatori. Questo solleva il singolo ente dall’allestire e gestire le componenti di supporto al funzionamento dei server applicativi.

Accordo quadro Public cloud SaaS – gestione documentale

Il cuore del sistema informativo della pubblica amministrazione – lo ripeto – è il sistema di gestione informatica dei documenti (SGID). Per sgombrare il campo da equivoci di campanilismo professionale, concedo sin d’ora di considerare altrettanto importante la componente che si occupa di contabilità, perché, si sa, senza soldi si va poco lontano (e però di SaaS per la contabilità Consip pare che non sia ancora occupata).

L’accordo quadro Public cloud SaaS – gestione documentale, relativamente recente^[5]L’accordo quadro è attivo dal 10 aprile 2025 fino al 10 aprile 2027., ha individuato 11 rivenditori di soluzioni SaaS per la gestione documentale. Secondo il capitolato tecnico speciale, l’accordo quadro propone:

• Soluzioni SaaS di Protocollo informatico in un modello di erogazione pubblico;
• Soluzioni SaaS di Gestione documentale (Workflow e procedimenti amministrativi) in un modello di erogazione pubblico;
• Soluzioni SaaS di Conservazione documentale in un modello di erogazione pubblico.

Queste tre tipologie di soluzioni sono chiamate bundle funzionali. Per ogni bundle il capitolato definisce requisiti minimi, caratteristiche ulteriori e caratteristiche complementari.

Fornitori e software disponibili

La pagina dell’iniziativa elenca i fornitori individuati da Consip. La scelta del fornitore e, quindi, dei prodotti SaaS, secondo il capitolato tecnico speciale, è affidata a un configuratore automatico messo a disposizione della piattaforma che propone una graduatoria di soluzioni sulla base delle analisi dei fabbisogni dell’ente.

I fornitori individuati sono, nell’ordine in cui li elenca Consip (accanto indico il prodotto commercializzato, per maggior chiarezza):

1. WE-COM SRL – Prodotti Urbi Smart di PA digitale SpA;
2. CONVERGE S.P.A. – Prodotti Silloge, Connect e Virgilio di SIAV
3. RTI DEDA NEXT S.R.L. (ENERJ S.R.L) – Prodotti Civilia Next e JSDC (conservazione)
4. KONECTA ITALIA S.P.A – Prodotti C,Flow, Explorifile, C,Sost
5. MAGGIOLI S.P.A. – Prodotti Sicraweb EVO su cloud Google e conservazione digitale
6. RTI UNIMATICA S.P.A (DATAMANAGEMENT ITALIA S.P.A.) – Prodotti @kropolis di Datamanagement Italia spa e Unistorage di Unimatica per la conservazione
7. RTI ADS AUTOMATED DATA SYSTEMS S.P.A. (MEDAS S.R.L.; ARUBA PEC S.P.A.) – Prodotti Smart*Gov di ADS e Scryba cloud di Medas su cloud Aruba per la conservazione
8. POSTEL S.P.A. – offre solo conservazione
9. RTI NTT DATA ITALIA S.P.A (NTT DATA Italia Gov&Tech S.r.l, Engineering Ingegneria Informatica S.p.A.) – Prodotti DocsPA di NTT Data e DigiBox di Engineering per la conservazione
10. SB ITALIA S.R.L. – Prodotti Docsweb
11. TELECOM ITALIA S.P.A. – Prodotti Trust Digital Flow e Trust Legal Space

Si tratta per la maggior parte di fornitori noti nel mercato della pubblica amministrazione. Quasi tutti commercializzano software che hanno sviluppato in proprio^[6]Una delle caratteristiche del mercato dei software per la pubblica amministrazione è che le software sviluppano e vendono direttamente i prodotti, senza affidarsi a una rete di distribuzione di … Continue reading. Solo alcuni dei fornitori individuati sono meri rivenditori.

Su completezza, qualità e usabilità dei prodotti presenti nel catalogo dell’accordo quadro non mi sbilancio: non li conosco tutti, e quelli che conosco non li conosco tutti allo stesso livello. Tuttavia, volendo fare accademia, si ripete spesso che la qualità del prodotto offerto è sempre proporzionale alla qualità della domanda^[7]Sul tema mi è capitato anche di scrivere una tesi per un master. Parte dei risultati è confluito nel volume “Umanesimo digitale”, a cura di Paola Ciandrini e Ibridamente, di cui … Continue reading. Nello specifico, la domanda (di Consip) è contenuta nei capitolati tecnici generale e speciale, che, dunque, meritano qualche commento.

Come si individua il fornitore

Il capitolato tecnico speciale descrive le modalità con cui l’amministrazione individua il fornitore e, quindi, i prodotti SaaS da acquistare. Fra la documentazione riservata agli utenti autenticati è presente anche la uida all’uso dell’accordo quadro, che spiega molto didascalicamente tutti i passaggi da fare.

Consip mette a disposizione un “configuratore” che raccoglie le esigenze dell’amministrazione e stila una graduatoria (short list) di fornitori. Le esigenze dell’amministrazione comprendono i bundle funzionali richiesti (protocollo, gestione documentale, conservazione), eventuali caratteristiche tecniche ulteriori (già previste nel capitolato e oggetto di offerta dei fornitori) ed eventuali caratteristiche complementari (previste genericamente nel capitolato ma non oggetto di offerta e negoziazione in fase di definizione dell’accordo quadro).

Se l’amministrazione non richiede caratteristiche complementari e l’importo del contratto è inferiore ai due milioni di euro, l’amministrazione fa un contratto attuativo direttamente con il primo fornitore della graduatoria proposta dal configuratore.

Diversamente l’amministrazione aggiudica un appalto specifico, cioè avvia un confronto competitivo fra i fornitori dell’accordo quadro e individua il contraente con il criterio del prezzo più basso se non ci sono richieste di caratteristiche complementari o con il criterio dell’offerta economicamente più vantaggiosa se richiede caratteristiche complementari.

Nella pratica il configuratore è un foglio Excel con macro (sì, di quelli che ci dicono di non usare, tanto che dovremmo tenere le macro disabilitate – dopo l’uso ricordate di disabilitarle di nuovo). Il configuratore è disponibile nella documentazione, all’interno del “kit per la predisposizione dell’ordine” (un file ZIP che contiene anche la guida all’accordo quado e dei modelli per il contratto attuativo e alcuni suoi allegati, come la nomina a responsabile del trattamento dei dati).

Il capitolato tecnico

A meno di richieste complementari (funzioni contemplate, a livello generale, nel capitolato ma non oggetto di contrattazione in fase di definizione dell’accordo quadro), l’amministrazione non ha alcun margine di discrezionalità per scegliere il prodotto. Questo funziona, ed è anche una semplificazione per tutti, se il capitolato è ben formulato e individua requisiti funzionali, di usabilità e di conformità normativa e tecnica utili all’amministrazione.

L’avviso per individuare i fornitori affidatari è stato pubblicato il 27 maggio 2024 e, ragionevolmente, i capitolati sono stati elaborati a inizio 2024.

Il Capitolato tecnico generale prevede il rispetto da parte dei fornitori, fra gli altri, del regolamento ACN sui servizi cloud. Per tutti i bundle funzionali il Capitolato tecnico speciale richiede (paragrafo 3.3):

• attivazione delle funzionalità anche attraverso API (per integrazione con sistemi di gestione del personale): sembra che si faccia riferimento non tanto all’accesso alle funzioni tramite API quanto piuttosto all’uso di API per l’attivazione/configurazione iniziale del prodotto;
• uso tramite browser web con strumenti di sicurezza quali TLS e VPN IPSEC;
• certificazione ISO 27001 del cloud provider erogatore dei servizi (requisito che dovrebbe essere incluso nella presenza del SaaS nel marketplace ACN dei SaaS qualificati, invero);
• i servizi presenti nei tre bundle devono essere integrati fra loro per coprire tutto il ciclo di vita del documento;
• qualificazione ACN per trattamento di dati di tipo ordinario (paragrafo 5);

Requisiti minimi per il bundle funzionale “protocollo informatico”

Il Capitolato tecnico speciale descrive poi i requisiti per ciascuno dei bundle funzionali. Vale la pena soffermarsi sul dettaglio dei requisiti, a partire da quelli della componente “protocollo informatico”.

Preliminarmente va osservato che, nonostante il capitolato sia del 2024, il riferimento normativo con le prescrizioni per realizzare il servizio di protocollo informatico è il dpcm 3 dicembre 20213, cioè le ormai superate, e non da poco, regole tecniche per il protocollo informatico. E’ noto come queste siano state quasi completamente superate dalle Linee guida sul documento informatico, disponibili nella loro versione aggiornata già da maggio 2021. Una svista non da poco, che si ripercuote sui requisiti minimi, sulle caratteristiche ulteriori e su quelle complementari, che, lo anticipo, destano nel loro complesso più di qualche perplessità. Conviene riportarle testualmente.

Secondo il capitolato tecnico speciale, il servizio di Protocollo Informatico dovrà possedere i seguenti requisiti minimi:

1. funzionalità di accesso tramite credenziali utente;
2. funzionalità di registro di protocollo (numerazione sequenziale);
3. funzionalità di gestione dell’organizzazione dell’Ente (AOO, Unità Organizzative quali Aree, Servizi, Uffici);
4. funzionalità di gestione dei ruoli (ad esempio, protocollatore, assegnatario) e relativa profilatura utente;
5. funzionalità di registrazione di un documento nel servizio di Protocollo Informatico (in Entrata e in Uscita);
6. funzionalità per la gestione degli allegati e correlazione tra documenti;
7. funzionalità di segnatura, ovvero apposizione sul documento delle informazioni quali ad esempio nome dell’Ente, identificazione dell’AOO, il numero e la data di protocollo.

Caratteristiche ulteriori del bundle “Protocollo Informatico”

Le caratteristiche ulteriori sono quelle che il fornitore ha indicato nella sua offerta e che le amministrazioni interessate possono scegliere per descrivere il proprio fabbisogno e confrontare i fornitori al fine di individuare (tramite il configuratore) il più adatto a soddisfare il fabbisogno (il configuratore sceglie, fra i fornitori che soddisfano tutte le richieste, quello che costa complessivamente meno). Ecco l’elenco da capitolato:

• funzionalità di accesso tramite app mobile [qualitativo];
• funzionalità di ricerca testo all’interno di documenti tramite motore OCR [qualitativo];
• funzionalità di ricerca rapida (per numero di protocollo) e avanzata (mediante combinazione di più valori (esempio numero, data, mittente, destinatario, corrispondente interno, fascicolo, …) [qualitativo];
• funzionalità di Protocollo Interno [qualitativo];
• funzionalità di protocollazione di documenti digitali in ingresso e uscita con formati diversi (ad esempio TIFF, PDF, XML, Testo, iDOC, E-Mail) [qualitativo];
• funzionalità di memorizzazione permanente dell’impronta (hash) di ogni documento associato alla registrazione di protocollo (documento principale e allegati) tramite algoritmo Sha-256 [qualitativo];
• funzionalità di protocollazione di documenti analogici tramite scansione e segnatura del documento [qualitativo];
• funzionalità di protocollazione di documenti digitali tramite PEC o tramite integrazione con altri sistemi automatizzati [qualitativo];
• funzionalità di annullamento di un protocollo [qualitativo];
• funzionalità di protocollo “origine”, ovvero riferimento a tutti i protocolli collegati padri e figli con lo stesso protocollo “origine” tramite la costruzione di un albero [qualitativo];
• funzionalità di Gestione dei collegamenti tra protocolli diversi con possibilità di visualizzazione dei documenti collegati sia in avanti sia indietro nel tempo [qualitativo];
• funzionalità di Classificazione ovvero posizione del documento relativamente al Titolario di classificazione definito dalla AOO [qualitativo];
• funzionalità di gestione degli archivi unificata con separazione dei dati ai fini della riservatezza e sicurezza della singola AOO [qualitativo];
• numero di livelli di profondità dell’alberatura relativa al piano di classificazione superiore a 5 e fino ad un massimo di 20 [quantitativo];
• funzionalità di cifratura dei dati e documenti [qualitativo];
• funzionalità di Fascicolazione ovvero inserimento del documento in un Fascicolo [qualitativo];
• funzionalità di Registro di emergenza nei casi in cui non sia possibile utilizzare il sistema di protocollo informatico, anche in assenza di connessione di rete [qualitativo];
• funzionalità di stampa e reportistica, anche di tipo statistico [qualitativo];
• funzionalità di integrazione con strumenti di Business Process Intelligence [qualitativo];
• funzionalità di integrazione con servizi fiduciari (ad esempio Firma digitale, marca temporale) [qualitativo];
• funzionalità di adozione di meccanismi di Intelligenza Artificiale (AI) per la categorizzazione automatica dei documenti, integrabili con i sistemi aziendali [qualitativo].

Anche facendo riferimento alle vecchie regole tecniche per il protocollo informatico, la maggior parte delle caratteristiche bollate come ulteriori, sembrano proprio caratteristiche proprie ed imprescindibili di un protocollo informatico. Viene molto difficile spiegarsi come un’amministrazione possa deliberatamente rinunciare a funzioni come la memorizzazione delle impronte dei documenti, il collegamento con la casella PEC per la protocollazione dei messaggi di posta certificata, il protocollo interno, la classificazione, la fascicolazione o… l’annullamento di protocollo!

Non pervenuti nemmeno i metadati: quelli dell’allegato 5 alle linee guida hanno senz’altro seguito la stessa sorte di oblio patita dalle linee guida stesse, ma di metadati si parla anche nelle regole tecniche e, in generale, in tutta la letteratura tecnica che tratta di gestione documentale.

A mio avviso, sono 24 le “Funzionalità” imprescindibili fra quelle fin qui elencate: il dato è utile per una stima del corrispettivo economico dell’accordo quadro (il protocollo informatico si paga a funzionalità).

Caratteristiche accessorie (per tutti i bundle)

Le amministrazioni possono arrivare ad appalti specifici, richiedendo caratteristiche complementari che integrano i requisiti minimi e le caratteristiche ulteriori e sono da negoziare da zero, anche nella parte economica, all’interno dei seguenti ambiti individuati dal Capitolato tecnico speciale:

• Servizi di gestione delle identità, con i quali le Amministrazioni potranno utilizzare funzioni di Single-Sign-On e autenticazione a più fattori per l’accesso alle risorse ed alle funzionalità cloud;
• Livelli di servizio;
• Grace period;
• Funzionalità e Servizi di sicurezza (sandboxing, antispam, antimalware, Data Loss Prevention etc);
• servizi di migrazione dei dati;
• servizi di supporto alla redazione e aggiornamento della manualistica di gestione documentale;
• servizi di help desk;
• interoperabilità con altri sistemi della PA.

Fortunatamente, all’ultimo tuffo, spunta fuori l’interoperabilità con altri sistemi della pubblica amministrazione: interoperabilità interna al sistema informativo della singola amministrazione o esterna, verso banche dati e piattaforme abilitanti nazionali?

Attenzione, però: se si desidera interoperabilità occorre avviare un appalto specifico e riaprire la negoziazione con gli undici fornitori individuati da Consip. Lo stesso se si vuole il doppio fattore di autenticazione.

Requisiti e caratteristiche per il bundle Gestione documentale (workflow e procedimenti amministrativi).

Se per la componente protocollo informatico, motivi di disappunto a parte, il senso di requisiti e caratteristiche è chiaro, altrettanto non si può dire per la parte di gestione documentale.

Leggendo il capitolato, un grande dubbio emerge istantaneo: cosa si sta intendendo in questo contesto per “gestione documentale”? I segnali sono discordanti.

Intanto, la metrica di calcolo del costo si basa esclusivamente su numero di utenti e numero di gigabyte. Già questo fa pensare alla gestione documentale vista come una cartella condivisa; i requisiti minimi sembrano confermare il primo pensiero, quando aggiungono permessi di accesso diversificati alle cartelle (nominate esplicitamente) e versioning del documento.

Secondo il capitolato, “per Gestione Documentale si intende [sia] il trattamento dei flussi documentali relativi a documenti cartacei resi digitali, che i documenti nativi digitali, che scandiscono la vita del documento e la sua evoluzione nell’ambito della organizzazione dell’Ente”.

Non c’è alcun riferimento, per esempio, al dpr445/2000 che il sistema di gestione informatica dei documenti lo definisce meticolosamente in tutte le sue funzioni.

I requisiti minimi per la gestione documentale, da capitolato, sono:

1. accesso tramite credenziali utente e definizione permessi di accesso per utente e gruppi di utenti;
2. repository centralizzato per la documentazione dell’Amministrazione;
3. ricerca dei documenti veloce tramite attributi (metadati);
4. ricerca full-text, estesa ai contenuti dei documenti;
5. condivisione delle cartelle con relativi permessi di lettura/scrittura;
6. download dei documenti e delle versioni dei documenti;
7. tracciamento della versione del documento (c.d. versioning) con indicazione dell’autore della modifica e della relativa marca temporale;
8. workflow management per gestire ciclo di vita del documento.

Nessuna traccia di “registrazione” dei documenti, di fascicolazione, di accesso da parte di altre amministrazioni ecc.

Non va meglio se si analizzano anche le “caratteristiche ulteriori“:

• gestione multi-azienda, multi-AOO e multi-archivio [qualitativo];
• rappresentazione e gestione degli organigrammi [qualitativo];
• supporto firma digitale qualificata [qualitativo];
• editing documentale collaborativo con interfacce (plug-in) verso sistemi esterni: ad esempio OFFICE365, G-SUITE, ONLYOFFICE, COLLABORA [qualitativo];
• monitoraggio in termini di gestione dei log, eventi di sistema, analisi dati e realizzazione dashboard, alert e notifiche [qualitativo];
• workflow management per gestire ciclo di vita del documento tramite proprie API e generazione di eventi tramite Message broker [qualitativo];
• funzionalità di disegno grafico dei flussi documentali mediante editor interattivo [qualitativo];
• archiviazione documenti nei formati più diffusi [qualitativo];
• integrazione di funzionalità che consentono di firmare e marcare digitalmente documenti e verificare le firme e le marche eventualmente presenti senza ricorrere a componenti esterne [qualitativo];
• gestione adempimenti (worklist) dei procedimenti amministrativi e calcolo automatico delle scadenze [qualitativo];
• monitoraggio dello stato di avanzamento dei processi [qualitativo];
• accesso tramite app mobile [qualitativo];
• scambio di messaggi (chat) tra il personale dell’Amministrazione tramite canale di comunicazione asincrono [qualitativo];
• integrazione con LDAP e MS Windows Active Directory [qualitativo];
• integrazione con i sistemi di ERP (ad esempio SAP, JDE, Navision) [qualitativo];
• integrazione con servizio di Posta elettronica per la gestione e archiviazione di messaggi e-mail [qualitativo].

Il mistero resta fitto. Per esempio, fin qui, non si hanno elementi per capire se dal bundle di gestione documentale (workflow e procedimenti amministrativi) ci si debba attendere che formi e gestisca le determine dei dirigenti o le delibere degli organi collegiali. Minimo minimo, dovrebbe esserci qualche richiamo alla tenuta di registri particolari o repertori. Si parla invece di “gestione degli adempimenti dei procedimenti amministrativi e calcolo automatico delle scadenze”: bello e decisamente desiderabile, ma, esattamente, in che contesto lo si sta ponendo?

Le caratteristiche complementari sono le stesse previste per il protocollo informatico: si tratta di ambiti all’interno dei quali si può riaprire la negoziazione con i fornitori.

Requisiti e caratteristiche del bundle Conservazione digitale

La conservazione digitale, fortunatamente, è un’attività più tipizzata e rigidamente regolamentata, tanto che è un servizio fiduciario che può essere reso solo da soggetti iscritti nell’apposito Marketplace dei servizi di conservazione tenuto dall’AgID.

i requisiti minimi, infatti, si esauriscono in un unico punto che richiede il rispetto dei requisiti previsti dalla determinazione AgID 455/2021 (Regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici) e dei suoi allegati A e B.

L’iscrizione al Marketplace AgID, tuttavia, risulta essere una caratteristica ulteriore! Anche se poi, nel capitolato, si capisce che la mancanza di iscrizione al Marketplace rende impossibile la stipula del contratto attuativo.

Tutte le carateristiche ulteriori sono:

1. iscrizione al Marketplace AgID dei conservatori [qualitativo];
2. trasferimento dati: invio/estrazione pacchetti (archivi) sia in modalità applicativa (API, SOAP-WS…) sia tramite portale web [qualitativo];
3. numero di classi documentali preconfigurate superiore a 3 e fino ad un massimo di 20 [quantitativo];
4. gestione centralizzata per la gestione di utenti, ruoli con segregazione degli archivi e tipologie di documenti accessibili [qualitativo];
5. gestione dell’organizzazione di Amministrazioni complesse tramite alberatura di “soggetti produttori” con accessi differenziati alle sezioni di archivio [qualitativo];
6. estrazione autonoma di fascicoli, documenti, archivi conservati [qualitativo];
7. annullamento delle conservazioni effettuate [qualitativo];
8. motore di ricerca attraverso metadati obbligatori e opzionali [qualitativo];
9. ricezione dei PdV tramite canale FTP con job schedulati, via Web Services o conferimento manuale [qualitativo];
10. verifica integrità del PdV e notifica delle anomalie [qualitativo];
11. generazione del PdA e certificazione con apposizione di firma digitale e marca temporale sull’Indice del PdA [qualitativo];
12. predisposizione e invio del PdD all’Amministrazione tramite canale FTP criptato [qualitativo];
13. monitoraggio degli esiti dei processi attivati sia in modalità applicativa che tramite portale del servizio [qualitativo];
14. gestione delle procedure di scarto archivistico [qualitativo].

Anche in questo caso, risulta difficile comprendere come un’amministrazione possa scegliere di rinunciare a versare i documenti senza canali FTP, web service (API) od operazioni manuali. Oppure come possa rinunciare alla possibilità di estrarre fascicoli e documenti dal sistema di conservazione, magari dopo aver accettato che i pacchetti di archiviazione non siano certificati dal conservatore…

Considerazioni su requisiti e caratteristiche individuati dal capitolato

Come già evidenziato, è incomprensibile come le linee guida sul documento informatico non siano citate fra la normativa di riferimento per le caratteristiche del protocollo informatico e del sistema di gestione documentale e, anche, del sistema di conservazione.

Quasi tutte le caratteristiche ulteriori meriterebbero di essere requisiti minimi, proprio perché funzioni imprescindibili (anche per espressa previsione normativa) di un protocollo informatico o di un sistema di gestione documentale.

Nel capitolato mancano anche altre caratteristiche obbligatorie: per esempio, la possibilità di creare registri, elenchi, repertori ecc. per le registrazioni particolari. Dovrebbero essere presenti, fra bundle protocollo informatico e bundle gestione documentale.

Il capitolato non prevede invece caratteristiche, nemmeno troppo ulteriori o accessorie, che consentirebbero di selezionare ulteriormente i prodotti offerti. Per esempio, in ordine del tutto sparso:

• la possibilità di impostare il piano delle aggregazioni documentali con logiche di creazione guidata delle aggregazioni;
• collegamento nativo interoperabile con i registri dei domicili digitali IndicePA e INAD (magari anche INI-PEC, anche se è a pagamento);
• possibilità di definire template per registrazioni ricorrenti (mediamente tutti i software offrono la funzione, ma specifichiamolo);
• collegamento con la piattaforma SEND per le notifiche a valore legale degli atti (qui, ok, eravamo a inizio 2024, SEND era agli inizi);
• la produzione di copie analogiche conformi di documenti nativi digitali;
• procedure guidate di composizione di lettere, anche massive;
• …

L’elenco potrebbe proseguire.

Ripeto anche che non si capisce esattamente cosa si potrà gestire con la parte di “gestione documentale”: la maggior parte dei fornitori offre moduli separati per gestire certe tipologie documentarie: determine e delibere (volgarmente detti “atti” o “atti amministrativi” – spesso associati a strumenti di gestione degli organi), contratti (spesso associati a strumenti per registrare taluni contratti all’Agenzia delle entrate e dialogare con i suoi sistemi) ecc.

Anche sull’interoperabilità ci sarebbe molto da dire. Nel capitolato è una “caratteristica complementare” che richiede una nuova negoziazione. Nel 2026 è impensabile dotarsi di un protocollo che non consenta la registrazione di documenti tramite API a partire da software esterni (portali di presentazione di istanze e comunicazioni, gestionali che producono massivamente comunicazioni a valore legali quali, per esempio, gli avvisi di accertamento ecc.)

Fra l’altro, e vale la pena ricordarlo, il Regolamento ACN per i servizi cloud prevede espressamente che un servizio cloud (SaaS), esponga API per tutte le sue funzioni applicative. Banalmente, quindi, se posso protocollare un documento manualmente da interfaccia web, devo poterlo fare anche via API a partire da un software esterno. Cito testualmente il passaggio del regolamento ACN (punto IP.IN-01 dell’allegato 3, pag. 2 di 27 dell’allegato 3, pagina 55 di 88 del PDF del regolamento completo):

Molto interessanti anche i requisiti che seguono (invito a leggerli), su portabilità dei dati, accesso ai dati al termine del rapporto contrattuale ecc. Che poi queste debbano essere funzioni di serie o un optional a pagamento sarebbe utile che ce lo spiegassero ACN e AgID…

Una simulazione

Tramite il configuratore Excel, ho fatto una simulazione, così per avere una stima approssimativa del costo di 1 anno di servizio completo. Compilare i campi del configuratore è istruttivo e consente di toccare con mano quanto stigmatizzato nei paragrafi precedenti: perché dovrei rinunciare a certe funzioni? Oppure, specie per il servizio di conservazione, siamo poi così sicuri che tutte le amministrazioni siano in grado di comprendere il senso di tutte le domande?

Personalmente, ho indicato come richieste quasi tutte le caratteristiche ulteriori. Ho fatto qualche eccezione per l’accessibilità tramite applicazione mobile, la cifratura dei dati (mi hanno insegnato che cifrare i documenti protocollati non è il top), l’integrazione con strumenti di business intelligenza (bisne-che?!) e, non me ne vogliate, con meccanismi di intelligenza artificiale per la “categorizzazione” automatica dei documenti (di grazia, ma se nemmeno so se posso implementare un piano di fascicolazione, cosa me ne faccio dell’intelligenza artificiale?).

Ho inserito valori verosimili rispetto al mio ente: ho pensato che la gestione documentale riguarda tutti, ma proprio tutti e ho messo, quindi, 250 utenti per la gestione documentale, 5 utenti per la conservazione. Tasto dolente i “gigabyte”: gigabyte di cosa? Vanno indicati per la gestione documentale ma non per il protocollo… ho messo 1.000 gigabyte (un terabyte) così per avere un’idea.

Il risultato è questo:

Fornitore 1	45.016,80 €
Fornitore 2	59.112,12 €
Fornitore 3	64.964,40 €
Fornitore 4	93.306,60 €
Fornitore 5	134.262,84 €

Ho omesso il nome dei fornitori. Si noti però che non sono presenti tutti, evidentemente qualcuno non offre qualche caratteristica ulteriore richiesta (fra gli esclusi anche qualche sorpresa).

Per avere un’idea, nella proposta più economica, rispetto ai tre bundle il totale è distribuito 11.500 euro circa sul protocollo, 29.000 circa sulla gestione documentale, 4.500 sulla conservazione.

Passare da 1.000 a 3.000 gigabyte di spazio occupato genera un intervallo di prezzi da 60.946,80 euro (Fornitore 1) a 172.002,72 euro (Fornitore 5).

Una rondine non fa primavera, ma devo dire che uno dei cinque prodotti è quello in uso nel mio ente e il contratto attualmente vigente è molto, ma molto, meno oneroso: costa di meno e offre servizi ulteriori, coprendo buona parte dell’area contabilità e servizi demografici.

Chissà poi cosa giustifica che il fornitore più economico costi un terzo del più costoso.

Manca la migrazione dei dati

Occorre inoltre segnalare un aspetto fondamentale: gli importi indicati non includono in alcun modo la migrazione di dati (documenti) esistenti: la migrazione, infatti, è un ambito esplicito di “caratteristiche complementari”, cioè di qualcosa che l’amministrazione deve negoziare in autonomia. Come si possa pensare di avviare un sistema di gestione documentale o un protocollo informatico senza recuperare i dati pregressi resta per me un mistero insondabile. Eppure la migrazione è un optional che Consip non ha ritenuto nemmeno di negoziare nei suoi aspetti tecnici ed economici, lasciando le amministrazioni sole a se stesse.

Al momento il contatore del residuo di contratti attuativi attivabili recita “Piena disponibilità“. Probabilmente, con quanto esposto fin qui, non c’è poi tanto da meravigliarsi se a 8 mesi dalla pubblicazione dell’accordo quadro sui SaaS per la gestione documentale, apparentemente, nessuna amministrazione abbia concluso un contratto attuativo.

Conclusioni

C’è poco da dire, quello della trasformazione digitale della pubblica amministrazione, soprattutto locale, è un mondo difficile. La gestione documentale, parte nevralgica della trasformazione digitale, sconta inoltre la pena di essere perennemente negletta, anche da parte delle autorità centrali che dovrebbero difenderla e presidiarla. Lo dimostrano anche alcune carenze del capitolato di questo accordo quadro, a partire dall’assenza del testo normativo di riferimento più attuale, le Linee guida sul documento informatico.

Emerge evidente il problema di definire cosa sia la gestione documentale e il sistema di gestione documentale, perché si continua a indugiare nell’equivoco se la gestione documentale siano i file organizzati in cartelle di rete, se siano invece i documenti registrati e descritti (tramite metadati) in un sistema strutturato (mah, la norma ISO 15489 a qualcosa servirà?) o, ancora, se sia qualche via di mezzo…

In definitiva, a mio avviso, il capitolato tecnico alla base dell’accordo quadro non è sufficiente a garantire la piena conformità dei prodotti a normative e regole varie e la loro funzionalità alle esigenze complessive di un’amministrazione pubblica.

Fra le tante considerazioni finali, forse se ne può selezionare una amara, da cui il “Tu quoque, Consip”. Lo Stato, nelle sue declinazioni Consip e AgID (che promuove le iniziative tramite il piano triennale), sembra operare senza una conoscenza profonda delle realtà sulle quali vorrebbe intervenire con strumenti di supporto e delle esigenze concrete di quelle realtà. Oppure, la conoscenza c’è ma, alla fine, manca sempre qualcosa per arrivare a strumenti realmente risolutivi.

Molti degli strumenti messi a disposizione delle amministrazioni supportano la transizione digitale solo fino a un certo punto, ma sono molto apprezzati (dai non tecnici della transizione digitale) per gli aspetti di semplificazione amministrativa delle procedure di affidamento.

Eppure, nonostante il clamore della narrazione con cui sono presentati agli interessati, dal punto di vista della transizione digitale in sento stretto, tuttavia, non soddisfano del tutto e, anzi, rischiano anche di essere controproducenti. Infatti, da un lato non impongono requisiti tecnici che possano fare la differenza, dall’altro non sembrano individuare con precisione l’esatto contenuto tecnico di cui le amministrazioni, specie quelle non grandi, hanno bisogno. Il trasformatore digitale scrupoloso ha davvero vita difficile a evidenziare ai decisori di turno^[8]Sento un brusio dal fondo: “ma come, il Responsabile per la Transizione Digitale è un tecnico e un decisore, cosa stai dicendo?”. Mah… fatevi un giro negli enti del mondo reale e … Continue reading i limiti delle proposte e rischia di infilarsi in procedure di affidamento gravose, rese ancora più gravose dall’obbligo di giustificare il mancato ricorso a uno degli strumenti di procurement messi a disposizione da Consip, in un argomentare nel quale, mediamente, le motivazioni tecniche stentano a fare breccia nei cuori di chi valuta e giudica.

Insomma, AgID e Consip, per la gestione documentale si può fare di più e meglio. Proviamoci.

Foto di Domenico Mattei da Pixabay