Pratiche operativeProtocollo informaticoTrasformazione digitaleVetrina - critico

A volte ritornano: i silos e la completezza dell’archivio

A volte ritornano o, forse, non se ne sono mai andati. Partiamo, però, dalla domanda a cui intendo tentare di dare una risposta: perché un software che produce documenti deve essere collegato al sistema di gestione informatica dei documenti e trasferirvi i documenti che produce o riceve?

Incredibilmente, nel 2026, a un lustro dalle Linee guida sul documento informatico, che poi vanno in continuità con le precedenti regole tecniche che a loro volta vanno in continuità con decenni e secoli di disciplina e col buon senso, richiedere l'”integrazione” di un software gestionale con il sistema di gestione informatica dei documenti (passando per lo più dalla porta del protocollo informatico) trova come reazione una malcelata risatina. Di quelle che si riservano a richieste anacronistiche, fuori dal mondo e fuori di testa, come se qualche nostalgico chiedesse di ottimizzare un’interfaccia grafica per la visualizzazione su un monitor a fosfori verdi. Invece si tratta solo di arginare il prepotente ritorno dei silos documentali, che, a ben vedere, forse non se ne sono mai andati.

I contorni della questione

L’offerta di software per la pubblica amministrazione pullula di software “gestionali” capaci di operazioni fantastiche. Questi supportano le funzioni amministrative e contengono al loro interno i dati che sono insieme presupposto e esito dell’esercizio di quelle funzioni. Spesso i gestionali consentono scambi di dati istantanei fra più soggetti. In un contesto di pubblica amministrazione e, più in generale, quando i soggetti che interagiscono sono legati da rapporti che vanno oltre la chiacchiera e l’intrattenimento, i dati e gli scambi di dati, informazioni e documenti hanno una rilevanza giuridica (in senso lato) forte: costituiscono o rappresentano rapporti giuridici in senso stretto, li modificano, sono prove di azioni, sono l’esito di altre azioni meritevoli di essere conservati con autorevolezza. Quando si parla di pubblica amministrazione, poi, le funzioni incidono quasi sempre su diritti e sfera giuridica di cittadini e imprese.

Ciò che avviene tramite il gestionale, allora, ha bisogno di essere trattato con cautela, In particolare, si deve garantire che sia affidabile, ricostruibile, integro, riconducibile alla volontà degli attori coinvolti. Se necessario si deve poter estrarre il contenuto dal gestionale per esibirlo altrove. Queste e altre sono le caratteristiche tipiche che si richiedono a un documento[1]Per esempio, l’articolo 20 del Codice dell’amministrazione digitale elenca sicurezza, integrità, immodificabilità e riconducibilità al suo autore come le caratteristiche che incidono … Continue reading e di cui discipline come archivistica e diplomatica si nutrono da tempo ormai immemore.

Soprattutto, poi, le evidenze documentali hanno bisogno di essere trovate quando serve, tenute insieme a ad altre anche provenienti da fonti differenti. Devono poter sopravvivere, nell’archivio, anche ai sistemi informatici che le hanno originariamente formate: perché, si sa, i software gestionali non durano per sempre. Nemmeno l’archivio digitale, si dirà: in effetti è proprio così, anche l’archivio informatico, il sistema di gestione informatica dei documenti, ha una sua aspettativa di vita limitata come componente informatico, ma, senz’altro è più conveniente dedicarsi al perpetuarsi (nel tempo) dell’archivio digitale (che ha pure un suo gemello nel sistema di conservazione), piuttosto che arrabattarsi dietro al mantenimento di infiniti software con velleità di produrre e conservare documenti. La frammentazione dell’archivio, poi, pone anche diversi problemi per la trasmissione (nello spazio), l’accessibilità dei documenti e la loro fruizione in un ambiente che sia in grado di esplicitare le connessioni che esistono fra i documenti, anche quelli formati in origine da sistemi diversi.

Esempio.

Facciamo un esempio di archivio frammentato e sue conseguenze: un verbale di contravvenzione al codice della strada a seguito di rilevazione dell’infrazione fatta da un sistema automatico. Le “prove” del misfatto stanno nel sistema di rilevazione, per esempio le foto di un “autovelox”. Il verbale è redatto ancora con un software dedicato. Il verbale è notificato magari tramite il servizio SEND che mantiene al suo interno le prove di notifica. La comunicazione dei dati del conducente potrebbe avvenire tramite un portale dedicato e rimanere lì o tramite consegna di un modulo cartaceo o elettronico e finire nel “protocollo”. L’eventuale ricorso al prefetto o al giudice di pace magari non transita direttamente dall’ente, che però poi deve interagire con l’autorità giudiziaria tramite sistemi esterni, quali quello del processo civile telematico o il SANA – Sistema informativo delle SANzioni Amministrative delle prefetture…

Bene, esattamente, il fascicolo della violazione che ne ricostruisce la storia dove sta? Se un pezzo viene meno che ne è della storia?

Ciononostante, la dimensione documentale degli scambi di dati e informazioni che avvengono dentro questi gestionali avveniristici[2]Avveniristici, ma fino a un certo punto. Spesso sono solo tabelle di database ben studiate e presentate in forme grafiche sgargianti. è il più delle volte totalmente negletta.

Vale allora la pena fermarsi un attimo a fissare le idee sul perché collegare un software che produce documenti al sistema di gestione documentale e trasferirvi gli esiti degli scambi sotto forma di documento. Si tratta di un atto doveroso, tanto moralmente quanto giuridicamente.

I motivi per trasferire i documenti nel sistema di gestione informatica dei documenti

Per soddisfare tutti si possono individuare, fra i tanti, motivi di tre nature diverse: l’adempimento di legge/obbligo giuridico, le indicazioni della normativa tecnica (in sé non cogente ma utile alla sopravvivenza), le esigenze pratiche.

Obblighi di legge e adempimento giuridico

Riporto testualmente alcuni passaggi chiave, che evidenziano e convincono del fatto che il sistema di gestione documentale deve essere completo, cioè raccogliere tutti i documenti e tutte le aggregazioni e che, se non c’è registrazione nel sistema (cosa che, allo stato tecnologico attuale, include anche il trasferimento “fisico” delle evidenze informatiche che costituiscono i documenti stessi), ciò è evidentemente impossibile.

Linee guida sul documento informatico (AgID, discendenti dal Codice dell’amministrazione digitale, art. 71), par. 2.4.1.:

  • Il documento amministrativo informatico è IDENTFICATO e TRATTATO nel sistema di gestione informatica dei documenti con le modalità descritte nel manuale di gestione documentale.
  • Al documento amministrativo informatico viene associato l’insieme dei metadati previsti per la registrazione di protocollo ai sensi dell’art 53 del TUDA, nonché i metadati relativi alla classificazione, ai sensi dell’articolo 56 del TUDA, e ai tempi di conservazione, in coerenza con il piano di conservazione, e quelli relativi alla relazione con l’aggregazione documentale informatica d’appartenenza.
    Al documento amministrativo informatico sono associati ulteriori metadati rilevanti ai fini amministrativi o per finalità gestionali o conservative, definiti, per ogni tipologia di documento, nell’ambito del contesto a cui esso si riferisce, secondo quanto previsto dall’Allegato 5 alle presenti Linee guida.
  • Il documento amministrativo informatico assume le caratteristiche di immodificabilità e di integrità, oltre che con le modalità di cui al paragrafo 2.1.1, anche con la sua registrazione nel registro di protocollo, negli ulteriori registri, nei repertori, negli albi, negli elenchi, negli archivi o nelle raccolte di dati contenute nel sistema di gestione informatica dei documenti con le modalità descritte nel manuale di gestione documentale.

Ancora le Linee guida, par. 3.1.3:

  • La registrazione informatica dei documenti è rappresentata dall’insieme di dati in forma elettronica allegati o connessi al documento informatico al fine dell’identificazione univoca di TUTTI i documenti prodotti e acquisiti. Per la Pubblica Amministrazione vale quanto disposto ai sensi dell’articolo 53 comma 5 del TUDA.
  • La Pubblica Amministrazione, al fine di dare attuazione alle disposizioni introdotte dal CAD stesso in materia di sistema di gestione informatica dei documenti realizza le funzionalità di gestione dell’archivio corrente, dell’archivio di deposito, dei flussi documentali, automatizzazione dei procedimenti amministrativi sulla base dei propri obiettivi di miglioramento dei servizi e di incremento dell’efficienza operativa, tenuto conto del rapporto costi e benefici, nel rispetto degli articoli 53 e 55 del TUDA e dei requisiti del sistema di gestione informatica dei documenti e dei flussi documentali” definiti negli articoli 52, 65 e 67 del TUDA, applicando ove possibile i requisiti fissati per la registrazione di protocollo anche alle altre forme di registrazione informatica dei documenti, fatto salvo quanto disposto per esse da eventuali norme vigenti”.

Sempre le Linee guida, par. 3.3.1 e par. 3.3.2:

  • Nelle Pubbliche Amministrazioni l’AOO gestisce i flussi documentali mediante fascicoli informatici predisposti secondo il piano di classificazione e relativo piano di organizzazione delle aggregazioni documentali ai sensi dell’art. 64 del TUDA, anche con riferimento a fascicoli non afferenti a procedimenti.
    La produzione, il mantenimento e l’uso dei fascicoli informatici sono conformi a quanto stabilito dall’art. 65 del TUDA e dell’art 41 del CAD.
  • ALL’INTERNO del sistema di gestione informatica dei documenti la Pubblica Amministrazione forma, gestisce e utilizza tipologie di aggregazioni documentali informatiche diverse dai fascicoli: serie che aggregano documenti e serie che aggregano fascicoli.

l citato articolo 65 del TUDA descrive ulteriori requisiti del SGID: “oltre a possedere i requisiti indicati all’articolo 52, il sistema per la gestione dei flussi documentali deve:

  1. fornire informazioni sul legame esistente tra CIASCUN documento registrato, il fascicolo ed il singolo procedimento cui esso è associato;
  2. consentire il rapido reperimento delle informazioni riguardanti i fascicoli, il procedimento ed il relativo responsabile, nonché la gestione delle fasi del procedimento;
  3. fornire informazioni statistiche sull’attività dell’ufficio;
  4. consentire lo scambio di informazioni con sistemi per la gestione dei flussi documentali di altre amministrazioni al fine di determinare lo stato e l’iter dei procedimenti complessi.”

L’articolo 41 del Codice dell’amministrazione digitale (CAD) ribadisce il concetto, aggiungendo anche che il fascicolo informatico è accessibile anche ai privati interessati dal procedimento.

Senza collegamento e trasferimento al Sistema di gestione documentale come è possibile quanto sopra? Come è possibile formare l’archivio?

Attenzione: l’archivio (digitale o no) non è un vezzo di studiosi e maniaci dell’ordine, tutt’altro. Tenere l’archivio con certi crismi è un obbligo che ricorre anche in altre norme di legge:

  • il Codice dei beni culturali (d.lgs 42/2004) impone agli enti pubblici di “conservare i propri archivi nella loro organicità e di ordinarli” (articolo 30)[3]Va bene, direte voi, è l’approccio culturale (o, addirittura beneculturalista) alla faccenda, noi dobbiamo lavorare… Leggete i riferimenti successivi, allora.;
  • la legge 241/1990, la legge sul procedimento amministrativo, caposaldo indiscusso e luce guida del funzionario pubblico, all’articolo 8 ci dice che, la comunicazione di avvio del procedimento contiene “le modalità con le quali, attraverso [app IO] o con altre modalità telematiche, è possibile prendere visione degli atti, accedere al fascicolo […]”. Se non abbiamo un fascicolo nel sistema di gestione informatica dei documenti che contiene tutti i documenti comunque formati o ricevuti relativi al procedimento, a cosa lo facciamo accedere?
  • il Codice di comportamento dei dipendenti pubblici (dpr 62/2013) – e ci spostiamo nel regno dell’anticorruzione e della trasparenza – all’articolo 9, comma 2 dice testualmente: “La tracciabilità dei processi decisionali adottati dai dipendenti deve essere, in tutti i casi, garantita attraverso un adeguato supporto documentale, che consenta in ogni momento la replicabilità.”. Ora, cosa è mai questa tracciabilità garantita tramite supporto documentale, se non l’archivio completo e ordinato?

Conformarsi alle norme tecniche

Se non si vuole ragionare per adempimenti, guardiamo allora all’archivio come a una risorsa strategica per le organizzazioni. Da secoli la disciplina, adattandosi al contesto tecnologico, elabora tecniche e metodi per gestire la documentazione in modo efficiente e affidabile.

Attualmente, gli esiti delle riflessioni disciplinari, li troviamo, fra le tante fonti, nella norma tecnica ISO 15489. La norma si occupa di sistemi per la gestione documentale (records management) e tratta sia delle caratteristiche dei documenti sia delle caratteristiche del sistema che li organizza (che, poi, sarebbe l’archivio).

Dal punto di vista del documento singolo, ci dice che, in verità, un documento non è mai singolo, perché il suo significato non si esaurisce nel suo contenuto intrinseco ma, al contrario, il suo significato si completa quando è osservato e interpretato insieme agli altri documenti a lui collegati e calato nel contesto in cui si è formato.

Il documento “singolo” deve allora avere caratteri di:

  • autenticità (essere ciò che appare essere);
  • affidabile (reliable, in inglese)
  • integro;
  • usabile;
  • descritto (caratteristiche che aiuta a trovarlo quando serve);
  • relazionato e contestualizzato.

Conseguentemente, il sistema di gestione documentale, cioè l’archivio, deve essere:

  • affidabile, che vuole dire molto: dall’essere disponibile (acceso) quando serve al rendere evidenti le caratteristiche dei documenti sopra elencate;
  • sicuro (nel senso di evitare accessi abusivi ai documenti, per esempio);
  • conforme (compliant) al business (attività) di chi lo detiene, all’apparato normativo e regolatorio e alle aspettative della comunità a cui si rivolge;
  • completo;
  • sistematico, che vuol dire che devo seguire un metodo e delle regole precise[4]Questo richiama l’attenzione sul fatto che, nella gestione documentale, alle questioni tecniche o tecnologiche (informatiche incluse) si abbinano – caso strano, eh? – questioni … Continue reading.

Torna la completezza, requisito essenziale perché l’archivio assolva al suo compito. L’esempio spicciolo della violazione al codice della strada (nel riquadro più in alto) assume adesso un senso più compiuto e collegato a regole che esistono, sia a livello normativo (di legge) sia a livello tecnico. Per garantire la completezza, la strada è quella: portare tutto nell’archivio (quasi tautologico).

Andando sul tecnico, la completezza dell’archivio può realizzarsi a livello logico. In linea teorica ben potrebbero esistere archivi completi i cui documenti “risiedono” in sistemi diversi ma collegati logicamente (interoperabili), in un sistema documentale articolato, dotato di un livello di presentazione dei contenuti che attinge a depositi documentali informaticamente distinti ma garantisce una fruizione completa dell’archivio e delle sue aggregazioni. In linea teorica, perché, diciamocelo, al momento non esistono grandi logiche condivise per arrivare allo scopo. Quindi, per adesso, l’unico modo per avere l’archivio completo è individuare un sistema di gestione informatica dei documenti “fisicamente” unico e trasferirci i documenti ovunque prodotti[5]In una pubblica amministrazione questo vuol dire: protocollare i documenti prodotti dai software gestionali e non lasciarli lì dentro. Se non è protocollazione può essere una “registrazione … Continue reading.

Ancora sul tecnico, si può citare – ma giusto a livello di suggestione, per stimolare approfondimenti – anche il modello MoReq 2010[6]MoReq sta per “Modular Requirements for Records Systems”, iniziativa della DLM Forum Foundation che intende definire un insieme di requisiti per i sistemi documentali, secondo una logica … Continue reading che, nel descrivere le possibili architetture di un sistema di records management, distingue fra “business system” (che possiamo vedere come il “gestionale”) e il “records system” (il nostro SGID). All’architettura tradizionale secondo la quale i documenti (records), anche se prodotti da sistemi di business distinti, sono acquisiti (con duplicazione) e gestiti centralmente dal “records system”, si affiancano anche modelli architetturali alternativi in cui il records system non ha una componente di storage e gestisce i documenti tramite “puntatori” ai sistemi di business che li detengono, oppure ancora modelli in cui, in contesti più ristretti e verticali, il sistema di business diventa esso stesso un sistema di gestione documentale (nel senso che implementa anche le funzioni tipiche della gestione documentale)[7]Per i curiosi, illustrazioni e spiegazioni dei modelli, si trovano nelle parti introduttive del volume delle specifiche di MoReq 2010, pagine 18 e 19..

Questioni pratiche

Per concludere la carrellata di (buoni) motivi per trasferire i documenti nel sistema di gestione documentale, possiamo spostarci su un piano totalmente pratico, distante sia dalla glacialità della norma di legge sia dall’accademia delle regole tecniche e dei trattati di archivistica.

Credo che si concordi tutti sul fatto che, se si vuole lavorare, si devono trovare le informazioni quando servono ed essere certi di poterci fare affidamento. Se mantengo informazioni importanti (solo) in un software e il software viene meno, o se le tengo in disordine, non le trovo quando servono. Quando il software non garantisce che quelle informazioni siano attendibili, che non siano state modificate, che siano riferibili con certezza a un dato momento e a un dato soggetto (ma non solo), la capacità di poterci fare pieno affidamento viene meno.

Se trasferisco nell’archivio quelle informazioni, va decisamente meglio. Si tratta di dare una forma documentale alle informazioni gestite nei software e acquisirle nel sistema di gestione documentale. I documenti, con la loro staticità, non consentiranno di compiere grandi operazioni sulle informazioni e i dati che contengono (per quelle continuiamo ad affidarci ai software) ma garantiscono la certezza e la disponibilità di quelle informazioni.

Quando anche il software che ha originariamente prodotto le informazioni cristallizzate nei documenti venisse meno[8]Perché si rompe, perché la tecnologia su cui poggia diventa obsoleta, perché scade il contratto, per colpa di un fulmine e di un gruppo di continuità ballerino…, se si è trasferito tutto in archivio, le informazioni restano, sono al sicuro. E’ vero che anche l’archivio digitale è un sistema effimero, ma si è già detto in apertura di come sia possibile dedicarsi efficacemente alla cura e al mantenimento nel tempo dell’archivio digitale, dedicando allo scopo sforzi e risorse. Il sistema di gestione documentale, poi, ha pure un gemello, ancora più solido e sicuro, nel sistema di conservazione digitale[9]A proposito, se operate in una pubblica amministrazione, diffidate dai fornitori ICT che propongono software e, invece che collegarli al sistema di gestione documentale, propongono direttamente il … Continue reading.

Cosa possono fare le amministrazioni

Una volta che si è compresa la questione e si concorda sulla sua importanza, l’unico rimedio che si può porre in atto è negoziare con i fornitori i requisiti tecnici dei prodotti che si intende acquistare, con particolare riferimento all’interoperabilità con il resto del sistema informativo e con ancora più particolare riferimento all’integrazione con il sistema di gestione documentale/protocollo informatico per trasferirvi i documenti prodotti (o prelevarne di utili).

Ora, la forma della negoziazione con il fornitore ICT varia decisamente da caso a caso, in base alla dimensione del contratto che si va a concludere e non solo. A un estremo ci sono le procedure aperte in cui l’amministrazione redigecapitolati speciali di appalto che descrivono nel dettaglio – o almeno dovrebbero – gli aspetti tecnici dei prodotti o servizi richiesti; all’altro ci sono affidamenti diretti fatti sulla base di scelte meno formalizzate, nelle quali comunque esiste una fase di negoziazione[10]Se anche si acquista un software su un mercato elettronico tipo il MePA, niente vieta di inserire specifiche di requisiti nelle richieste di offerta. Tecnicamente, sul MePA, a memoria, anche quando … Continue reading, anche informale.Importante, alla fine, è che i requisiti si fissino in qualche modo.

In realtà, le specifiche tecniche da considerare e spesso neglette fra le clausole contrattuali con un fornitore ICT, vanno ben oltre l’integrazione con il protocollo. Propongo di seguito un esempio di clausole tecniche (da rielaborare), non sempre considerate negli schemi di capitolati e contratti “che girano”. Alcune sono considerate, invece, dalla lodevole iniziativa Sistema Comuni Digitali ANCI, che mette a disposizione ampia documentazione e modelli per i contratti di ambito ICT, servici cloud in particolare) e quanto segue può essere integrato in quella proposta.

Esempio di capitolato/clausole tecniche

Con riferimento alla corretta gestione dei documenti – con riferimenti normativi generali dpr 445/2000 (articoli 52, 53, 65 e altri); d.lgs 82/2005 (articoli 40, 40-bis, 41 e altri), Linee guida sul documento informatico (paragrafi 2.4.1, 3.1.3, 3.3.1, 3.3.2 e altri):

  • il software è collegato tramite interoperabilità al sistema di gestione informatica dei documenti . In particolare il software trasferisce nel sistema di gestione documentale, tramite registrazione di protocollo o registrazione particolare, i documenti prodotti ed eventualmente ricevuti.
  • il trasferimento dei documenti nel SGID include anche l’attività di fascicolazione (o altra forma di aggregazione) secondo regole logiche predeterminate, in accordo con il piano delle aggregazioni documentali in uso presso l’amministrazione;
  • in particolare, il software dota i documenti e le aggregazioni che tratta dei metadati previsti dall’allegato 5 e li trasferisce al SGID. Inoltre aggiorna costantemente i metadati di documenti trasferiti nel sistema di gestione documentale e delle relative aggregazioni (per esempio, aggiornare lo stato di un fascicolo di procedimento);
  • la trasmissione di documenti verso l’esterno avviene tramite gli strumenti (PEC, SEND, email) messi a disposizione dal SGID; dove questo non fosse tecnicamente possibile, il software trasferisce prove e ricevute di invio e consegna al SGID/Protocollo informatico e le associa in forma stabile alla registrazione di protocollo (o altra registrazione particolare) oggetto di trasmissione (dpcm 3 dicembre 2013, regole tecniche per il protocollo informatico, articolo 18, comma 1).

Relativamente a interoperabilità del software, portabilità e disponibilità dei dati:

  • “il servizio SaaS espone opportune API di tipo SOAP e/o REST verso l’Amministrazione associate alle funzionalità applicative, prevedendo in particolare la tracciabilità delle versioni disponibili e la tracciabilità delle richieste ricevute ed evase. Inoltre, è disponibile documentazione tecnica, fruibile dall’Amministrazione, in merito alle API esposte e gli endpoint” (Regolamento ACN per i servizi cloud, allegato 3, caratteristica IP.IN-01)
  • il software mette a disposizione funzionalità e/o API per l’esportazione ed importazione massiva dei dati con formati aperti non proprietari (Regolamento ACN per i servizi cloud, allegato 3, caratteristica IP.PO-01);
  • il servizio prevede politiche e procedure per l’interoperablità e la portabilità dei dati aggiornate almeno su base annua e devono essere specificate le modalità di accesso ai dati al termine del contratto (Regolamento ACN per i servizi cloud, allegato 3, caratteristica IP.PO-02 – nel senso che il contratto/capitolato/offerta tecnica deve esplicitare in che formato e in che modalità l’amministrazione riceve i suoi dati);
  • oltre all’accesso ai dati direttamente dall’interfaccia utente, il software mette a disposizione interfacce API ampiamente documentate per accedere ai dati e riutilizzarli (d.lgs 82/2005, articoli 50-quater e 52 – vale per servizi dati in appalto o in concessione, ma ribadisce quanto già espresso)

Relativamente a sicurezza e protezione dei dati personali:

Sulla qualità del software:

Cosa potrebbero fare le istituzioni

Dovrebbe essere chiaro, a questo punto, che un’amministrazione (e una qualsiasi organizzazione), tutte le volte che fa un sospiro, produce documenti e che questi – per normativa, buon senso e buon gusto – vanno gestiti e conservati secondo certe regole, che poi sono quelle che consentono ai documenti di fare il loro dovere: farsi trovare quando servono, spiegare chiaramente cosa intendono contenere (rappresentare) e ispirare fiducia (circa il loro contenuto, chi lo ha prodotto e dove e quando).

Anche se chiaro, il concetto va ribadito ogni volta. Poi, come nella bozza di esempio poco sopra, va declinato in requisiti. Le istituzione che sovrintendono e indirizzano trasformazione digitale e gestione documentale, Agenzia per l’Italia Digitale per prima, dovrebbero fare proprio l’approccio documentale e riversarlo formalmente e incisivamente anche nei documenti normativi e di indirizzo che producono.

Questo approccio non era tangibile negli avvisi PNRR sulla migrazione al cloud, sulle notifiche digitali o sull'”Esperienza del cittadino” (sito e servizi online). Vero che si tratta di prodotti del Dipartimento per la Trasformazione digitale, ma allora estendiamo l’invito anche al Dipartimento.

L’approccio documentale non è presente nemmeno nel regolamento cloud dell’Agenzia per la Cybersicurezza Nazionale: bene, estendiamo anche all’ACN.

Estendiamo anche a PagoPA spa e al DFP – Dipartimento per la Funzione Pubblica, altri soggetti particolarmente attivi nella trasformazione digitale della pubblica amministrazione, enti locali inclusi. ll DFP, per esempio, è promotore delle iniziative di digitalizzazione di SUAP e SUE (dove la gestione documentale è stata, guarda un po’, totalmente dimenticata) o sull‘interoperabilità dei sistemi di gestione delle risorse umane (banca dati Minerva[11]Minerva e interoperabilità esterna dei sistemi di gestione del personale sono per me un’assoluta novità – da approfondire – ma sono anche protagonisti di un avviso PNRR … Continue reading) oltre che soggetto titolare della amata-odiata piattaforma nazionale unica per il reclutamento inPA[12]Su inPA prometto a breve un post (già pronto a metà) che individua qualche miglioria da proporre al DFP., anch’essa un enorme silos di documentazione rilevante per il sistema pubblico.

In definitiva, cosa chiederei alle istituzioni? Quello che, personalmente, mi attenderei è che le istituzioni rendessero la vita più semplice alle amministrazioni, senza obbligarle tutte le volte ad avviare un braccio di ferro con fornitori poco inclini alla gestione documentale. In definitiva, servirebbero nella normativa, nelle linee guida, nei documenti di indirizzo nei momenti formativi[13]Non mi riferisco solo a formazione e informazione sulla gestione documentale, direttamente mirata a quella, ma al richiamo alla correttezza documentale quando si parla d’altro. e nella narrazione in generale, richiami più espliciti alla gestione documentale e veri e propri obblighi e requisiti da rispettare, a partire dalla formazione di evidenze documentali valide e il loro trasferimento nel sistema di gestione informatica dei documenti.

“Richieste” alle istituzioni

Provo un ulteriore elenco, per sollecitare/indirizzare l’intervento delle autorità (AgID, DTD, ACN, DFP. PagoPA Spa):

  • definire chiaramente cosa è il Sistema di Gestione Informatica dei Documenti (SGID): non si può più accettare la risposta del fornitore di turno che “i documenti stanno nel mio software, li numera lui e, di conseguenza, il mio software è il SGID”;
  • spiegare cosa si intende quando, nella linee guida, si dice che il SGID contiene, oltre al registro i protocolli, tutti i registri, i repertori, gli elenchi e gli albi:
    • spiegarlo sia dal punto di vista concettuale (per albo si intende anche l’albo delle associazioni del terzo settore operanti in città?) trovando un equilibrio fra il dinamismo di certi elenchi/registri e la staticità solitamente associata a un documento;
    • spiegarlo dal punto di vista tecnico-informatico: che forma ha un elenco contenuto nel SGID?
  • chiarito questo, che si imponga di dargli seguito: va detto che un software che produce documenti deve trasferirli nel SGID o, se si decide che può tenerli lui, che li metta a disposizione per creare le aggregazioni necessarie a ricostituire le relazioni fra documenti e la completezza dell’archivio.

Un tempo l’AgID se ne usciva con documentazione dannatamente tecnica e incomprensibile ai più. Per esempio. è del 2014 un documento di “requisiti funzionali, non funzionali e di progetto del Sistema di gestione dei procedimento amministrativi (SGPA)”[14]Non ho idea della storia del documento “requisiti funzionali, non funzionali e di progetto del Sistema di gestione dei procedimento amministrativi (SGPA)” né del contesto nel quale si … Continue reading, con un modello di riferimento (architetturale e funzionale) schematizzato in questo modo:

Nella figura si intravvede qualche idea circa le relazioni, per esempio, fra le applicazioni verticali e i servizi di registrazione e metadatazione, che poggiano su un livello di gestione dei dati dove sembra regnare un ambiente di storage virtualmente unico mediato da un livello di registrazione altrettanto unico. Qualunque cosa sia il SGPA, senza dubbio indicazioni del genere, anche se destinate ai tecnici, aiutano a fare chiarezza e uniformare le impostazioni di base dei sistemi. Forse, talvolta, rivendicare un po’ di complessità serve.

Nell’immagine, Libero De Rienzo fa esclamare a Bartolomeo: “ma poi ce sta ‘er silos, ma chi me vede dietro ‘ar silos adesso?” in una scena del primo episodio dell’epica saga “Smetto quando voglio”.

Note

Note
1 Per esempio, l’articolo 20 del Codice dell’amministrazione digitale elenca sicurezza, integrità, immodificabilità e riconducibilità al suo autore come le caratteristiche che incidono sul valore probatorio di un documento.
2 Avveniristici, ma fino a un certo punto. Spesso sono solo tabelle di database ben studiate e presentate in forme grafiche sgargianti.
3 Va bene, direte voi, è l’approccio culturale (o, addirittura beneculturalista) alla faccenda, noi dobbiamo lavorare… Leggete i riferimenti successivi, allora.
4 Questo richiama l’attenzione sul fatto che, nella gestione documentale, alle questioni tecniche o tecnologiche (informatiche incluse) si abbinano – caso strano, eh? – questioni organizzative più ampie e sistemiche, che fanno della gestione documentale una questione di processo.
5 In una pubblica amministrazione questo vuol dire: protocollare i documenti prodotti dai software gestionali e non lasciarli lì dentro. Se non è protocollazione può essere una “registrazione particolare”, ma sempre nel sistema di gestione documentale – di cui il protocollo informatico è parte – deve avvenire.
6 MoReq sta per “Modular Requirements for Records Systems”, iniziativa della DLM Forum Foundation che intende definire un insieme di requisiti per i sistemi documentali, secondo una logica modulare, adattabile a più domini informativi e di business.
7 Per i curiosi, illustrazioni e spiegazioni dei modelli, si trovano nelle parti introduttive del volume delle specifiche di MoReq 2010, pagine 18 e 19.
8 Perché si rompe, perché la tecnologia su cui poggia diventa obsoleta, perché scade il contratto, per colpa di un fulmine e di un gruppo di continuità ballerino…
9 A proposito, se operate in una pubblica amministrazione, diffidate dai fornitori ICT che propongono software e, invece che collegarli al sistema di gestione documentale, propongono direttamente il versamento in un sistema di conservazione… ma ci sarà modo di parlarne in altre occasioni.
10 Se anche si acquista un software su un mercato elettronico tipo il MePA, niente vieta di inserire specifiche di requisiti nelle richieste di offerta. Tecnicamente, sul MePA, a memoria, anche quando si va diretti su un unico fornitore, conviene fare una RdO (Richiesta di Offerta) o una Trattativa diretta, preferibili rispetto all’ODA (Ordine Diretto di Acquisto), perché permettono di inserire nella richiesta documenti ulteriori, prodotti esternamente alla piattaforma, dove dettagliare le specifiche tecniche e inchiodare il fornitore a qualche vincolo e, parimenti, il fornitore può rispondere allegando ulteriore documentazione su cosa sta vendendo. Perché no, il “codice MePA” non basta a definire l’oggetto contrattuale e no, quando qualche vecchia Legge finanziaria impone di usare il MePA per gli acquisti informatici non sta dicendo che basta usare in qualsiasi modo il MePA e il resto dell’apparato normativo è sospeso. Di grazia, la definizione di un oggetto (possibilmente lecito) è l’ABC del negozio giuridico.
11 Minerva e interoperabilità esterna dei sistemi di gestione del personale sono per me un’assoluta novità – da approfondire – ma sono anche protagonisti di un avviso PNRR dell’ultimissima ora.
12 Su inPA prometto a breve un post (già pronto a metà) che individua qualche miglioria da proporre al DFP.
13 Non mi riferisco solo a formazione e informazione sulla gestione documentale, direttamente mirata a quella, ma al richiamo alla correttezza documentale quando si parla d’altro.
14 Non ho idea della storia del documento “requisiti funzionali, non funzionali e di progetto del Sistema di gestione dei procedimento amministrativi (SGPA)” né del contesto nel quale si colloca. Lo ammetto, me lo ero salvato sul PC anni e anni fa e ogni tanto spunta fuori. Ricostruendo sembra un’iniziativa dell’AgID e di altre amministrazioni, per dotarsi di un sistema definito come “riferimento futuro per tutte le pubbliche amministrazioni per favorire la digitalizzazione della pubblica amministrazione”. Gli esiti delle attività del Gruppo di lavoro – fra cui il citato documento – sono stati ceduti in riuso (e, in quella fase, devo averli intercettati e messi da parte).
Condividi

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *