Business e documenti: il rapporto fra applicativi verticali e gestione documentale dal punto di vista dello standard ISO 16175

Prendo spunto dal contenuto proposto da Aldo Maugeri nel numero 8 della rivista Digeat per proporre un tema ricorrente che ho trattato anche recentemente, soprattutto nel post sul ritorno dei silos, dall’ulteriore punto di vista di un altro standard internazionale legato alla gestione documentale.

Il tema è il rapporto controverso, negli archivi correnti non solo pubblici ma anche privati, fra il sistema di gestione documentale e gli applicativi che supportano nelle svolgimento delle funzioni istituzionali (anche detti gestionali, verticali, sistemi di business ecc.).

Lo standard internazionale in questione è l’ISO 16175:1-2020, che fornisce indicazioni per processi e requisiti funzionali dei software che trattano^[1]L’inglese manage andrebbe tradotto come gestire. Tuttavia preferisco non usare il termine “gestire” per evitare fraintendimenti e confusione con il sistema di gestione documentale, … Continue reading documenti informatici.

Nota: chi ha già dimestichezza con impostazione e contenuto dello standard può saltare direttamente alla parte sulla gestione documentale nella pubblica amministrazione.

La standard ISO 16175

Lo standard ISO 16175-1 “Information and documentation – Processes and functional requirements for software for managing records – Part 1: Functional requirements and associated guidance for any applications that manage digital records” è una delle norme tecniche che guidano nel comprendere, implementare e gestire gli archivi digitali^[2]Storicamente, lo standard internazionale ISO discende da quello elaborato dall’ICA – International Council on Archives fra il 2006 e il 2008, dal titolo “Principles and Functional … Continue reading. L’edizione più recente è del 2020.

Come tutti i documenti ISO è disponibile a pagamento, ma le anteprime disponibili nei negozi online specializzati consentono di avere un’idea abbastanza completa di temi trattati e approccio. Si può fare riferimento alla preview di ISO 16175-1:2020 disponibile pubblicamente presso il negozio di iTeh^[3]Non ho una preferenza né alcun tipo di affiliazione con il negozio. Semplicemente, avendone visitato qualcuno trovato tramite motore di ricerca mi è sembrato quello con… le anteprime più … Continue reading.

Lo scopo e i destinatari dello standard ISO 16175. Perché è importante

Come si legge nell’introduzione, il documento ISO 16175-1:2020 fornisce un modello, requisiti funzionali di alto livello (descritti in termini generali) e indicazioni per applicazioni software che trattano documenti (incluse copie digitali di documenti analogici), intendendo fra queste sia applicazioni che gestiscono documenti come loro funzione principale sia applicazioni che trattano documenti come parte di un processo più ampio a supporto di un’attività di chi lo utilizza^[4]In inglese, che magari rende meglio l’idea: “This document provides model, high-level functional requirements and associated guidance for software applications that are intended to manage … Continue reading.

Lo standard è destinato sia a chi, a vario titolo, progetta e sviluppa software applicativi, sia a chi, archivista, interviene nello sviluppo dei software o li seleziona in modo che soddisfino le esigenze di un’organizzazione.

In definitiva, lo standard ISO 16175 è importante perché:

• mette a fuoco il problema, spesso trascurato, del rapporto fra software e documenti: in questi casi, già acquisire consapevolezza del problema è un successo;
• guida nel risolvere il problema, senza formule magiche ma con indicazioni che i volenterosi possono seguire.

Requisiti funzionali e architetture per “software che trattano documenti”

Per gestire correttamente i documenti digitali lo standard individua alcuni requisiti funzionali da soddisfare e li raggruppa in quattro famiglie:

• 4.2.1 Records capture and classification – registrazione e classificazione dei documenti: se siamo in un sistema informatico che abilita attività di business o transazioni in genere, questo deve farsi carico di individuare informazioni significative che documentano le attività e registrarle come documenti e collegarle alle attività tramite i metadati^[5]Nella citata intervista, Cunningham riferisce anche di una lettura (Bearman, D., “Documenting Documentation”, in Archivaria vol. 34, 1992, pp. 33-49) che, negli anni ’90 del secolo … Continue reading;
• 4.2.2 Records retention and disposition – mantenimento e dismissione dei documenti: i documenti devono essere disponibili a chi ha diritto di accedervi per il tempo necessario (per legge ed esigenze di business) e devono essere mantenuti e distrutti in modo controllato, sistematico e tracciabile^[6]Il tema “retention and disposition” si lega anche a quello della sorte di dati, documenti e informazioni memorizzati un sistema quando questo diventa obsoleto. Un aspetto critico è … Continue reading;
• 4.2.3 Records integrity and maintenance – integrità e manutenzione dei documenti: tramite l’uso di metadati e la loro associazione stabile ai documenti sono registrate le interazioni con i documenti e le modifiche ai documenti, in modo che sia manifesto l’autore di interazioni e modifiche, il momento (timestamp) in cui queste sono avvenute e il loro dettaglio;
• 4.2.4 Records discovery, use and sharing – ricerca, uso e condivisione: i software di business dovrebbero (should) consentire la ricerca, il recupero, la rappresentazione, l’uso, la condivisione e la redazione dei documenti da parte dei soggetti autorizzati. Dovrebbero, inoltre, supportare l’interoperabilità fra piattaforme (informatiche) e domini distinti e nel tempo^[7]L’espressione over time vuole ricordarci che, mentre gli applicativi gestionali sono potenzialmente effimeri, gli effetti delle attività che supportano vanno potenzialmente mantenuti nel tempo … Continue reading.

Tali requisiti – che non sono sconvolgenti, né si discostano dalle caratteristiche dei sistemi di records management come descritti dallo standard ISO 15489 – non devono essere soddisfatti da un unico componente informatico (software) ma possono essere distribuiti fra più componenti del complessivo sistema informativo di una organizzazione o, addirittura, fra quelli di organizzazioni diverse e anche poggiare su operazioni e procedure esterni ai software. Ne derivano, così, tre configurazioni possibili (paragrafo 4.3):

1. progettare i software che trattano documenti in modo che si facciano carico di tutti i processi di gestione documentale;
2. integrare i software con un componente di gestione informatica dei documenti specializzato (ERMS – Electronic Records Management System), condividendo metadati e demandando al sistema specializzato il controllo dei documenti (i documenti risiedono nel software di business ma sono controllati centralmente dal software specializzato);
3. progettare funzioni di esportazione diretta e completa di documenti e relativi metadati verso un’applicazione specializzata in gestione di documenti.

In quest’ottica l’edizione del 2020 della famiglia ISO 16175, tratta insieme – nel collegato documento di specifiche tecniche ISO/TS 16175-2:2020 – i requisiti dei software dedicati alla gestione di documenti e i software che li trattano come parte di funzioni più ampie, legate al “business” (nella precedente versione le specifiche tecniche erano due distinte).

Di fatto, chi progetta e implementa un software che tratta documenti deve confrontarsi con le esigenze documentali e trovare soluzioni adeguate. La parte 2 dello standard^[8]ISO/TS 16175-2:2020 “Information and documentation – Processes and functional requirements for software for managing records – Part 2: Guidance for selecting, designing, … Continue reading (anteprima), che è una specifica tecnica, è proprio incentrata su quello. Anche in questo caso, uno sguardo all’indice è già significativo, perché il capitolo “determining configuration” che dovrebbe servire a progettare il software, ha sezioni dedicate alle aggregazioni documentali, alla classificazione, a schemi di metadati e a come “catturare” in modo automatico i metadati di processo da associare ai documenti.

In definitiva, si può dire, un software che tratta documenti deve porsi con decisione questioni di gestione documentale. Gli strumenti per orientarsi e realizzare soluzioni corrette e usabili ci sono.

La gestione documentale nella pubblica amministrazione italiana. L’impostazione normativa

La normativa italiana che dà disposizioni su documentazione e amministrazione digitale, definisce il sistema di gestione informatica dei documenti e lo individua come punto di raccolta di tutti i documenti dell’amministrazione.

Di questo tenore sono le disposizioni del dpr 445/2000, che, oltre ad imporre alle amministrazioni l’uso di un sistema di gestione informatica dei documenti (SGID):

• legano indissolubilmente il SGID al piano di classificazione (titolario) dell’amministrazione;
• indicano il SGID come “luogo” in cui si realizzano le aggregazioni documentali e il collegamento fra documenti e procedimenti;
• individuano il SGID come la componente informatica che abilita non solo il reperimento delle informazioni sui documenti registrati (da parte degli utenti “interni”) ma anche l’accesso alla documentazione e ai fascicoli da parte di soggetti esterni.

Il sistema di gestione informatica dei documenti è quindi il “deposito” unico dei documenti di un’amministrazione e sembra escludersi la configurazione di tipo a. (software di business che cura tutti i processi di gestione documentale) previsti dallo standard ISO 16175-1.

Il Codice dell’amministrazione digitale (d.ls 82/2005) e, in particolare, le discendenti Linee guida sul documento informatico confermano l’impianto del dpr 445/2000 per il sistema di gestione informatica dei documenti, come centro di attrazione per tutti i documenti prodotti, quando, per esempio, danno indicazione che:

• “Il documento amministrativo informatico è identificato e trattato nel sistema di gestione informatica dei documenti con le modalità descritte nel manuale di gestione documentale” (par. 2.4.1.);
• “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” (par. 2.4.1);
• “La Pubblica Amministrazione documenta la propria attività tramite funzioni del sistema di gestione informatica dei documenti finalizzate alla produzione, alla gestione e all’uso delle aggregazioni documentali informatiche, corredate da opportuni metadati, così come definiti nell’allegato 5 “Metadati” alle presenti Linee guida” (par. 3.3);

Il SGID è quindi unico, centrale nel sistema documentale dell’amministrazione e consente, dal punto di vista logico almeno, di raggiungere tutti i documenti dell’archivio e alle loro aggregazioni da uno stesso punto di accesso.

Le linee guida definiscono, inoltre, i metadati da associare ai documenti e alle aggregazioni di documenti e li descrivono minuziosamente descritti nell’Allegato 5 che, stando alle definizioni dello standard ISO 23081-1, costituisce lo “schema” di metadati.

Come per lo standard ISO 16175, anche per le linee guida nostrane il piano di classificazione è un elemento fondamentale: “Nel sistema di gestione informatica dei documenti dell’AOO l’attività di classificazione guida la formazione dell’archivio mediante il piano di organizzazione delle aggregazioni documentali” (par. 3.2).

Piattaforme di business “nazionali”

Contemporaneamente, però, la normativa (anche di pari rango rispetto a quella nominata) ha istituito, descritto e regolamentato sistemi di business che sovrintendono a funzioni pubbliche in alcuni domini applicativi. In alcuni casi lo Stato ha sviluppato piattaforme informatiche uniche per tutta la pubblica amministrazione, in altri ha invece dettato regole comuni di architettura, di logica di funzionamento e di interoperabilità a cui attenersi tassativamente.

Tre esempi, di cui mi sono spesso occupato, sono:

• inPA, la Piattaforma del Reclutamento;
• gli applicativi di back-office SUAP (definiti nell’ambito del SSU – Sistema informativo degli Sportelli Unici);
• le PAD – Piattaforme di approvvigionamento digitale.

Vale la pena analizzare velocemente come le regole definite dallo Stato affrontano il tema della gestione documentale, con particolare riferimento, in questo caso, all’impostazione complessiva del sistema documentale data dal legislatore e alle indicazioni dello standard ISO 16175-1.

Analisi delle piattaforme di business: i punti di attenzione

Per valutare l’aderenza delle scelte architetturali e funzionali delle citate piattaforme ai requisiti individuati dallo standard ISO 16175, conviene individuare pochi significativi punti di attenzione, quattro controlli da condurre:

1. Classificazione: è l’elemento essenziale ed imprescindibile per ricondurre i documenti prodotti all’interno di un software all’unicità dell’archivio completo del soggetto produttore. La classificazione è un punto chiave sia dello standard ISO 16175 sia del modello MoReq^[9]Nell’intervista di Aldo Maugeri a Adrian Cunningham si apprende come lo standard ISO 16175 e, prima ancora il lavoro di ICA, nasce proprio dall’esigenza di armonizzare e semplificare i … Continue reading sia dello standard di più alto livello ISO 15489 sui sistemi di records management o di quello di ancora più alto livello ISO 30300^[10]Lo standard ISO 30300 ha lo scopo di fissare termini e definizioni per i concetti chiave del dominio del records management e, quindi, per la serie di standard e specifiche tecniche ISO prodotti … Continue reading. Il punto richiede quindi di rilevare se il software di business è in grado di recepire il piano di classificazione dell’organizzazione e riferirvi i documenti che tratta;
2. Metadati: i metadati sono le informazioni che completano le unità documentarie e archivistiche, integrando il significato del mero contenute delle evidenze informatiche (file o record di database) che compongono il documento. L’importanza dei metadati è rimarcato in tutti gli standard fin qui nominati e ne esiste anche uno ad hoc (ISO 23081): i metadati descrivono il documento nel momento in cui questo entra nel sistema che lo tratta e contengono le informazioni di contesto (chi lo ha creato, quando, come è stato formato, di cosa parla) e si arricchiscono nel corso della vita del documento annotando le vicende della gestione del documento stesso (chi vi ha avuto accesso, chi lo ha eventualmente modificato, se ci sono state migrazioni o conversioni di formato ecc.). Il punto richiede quindi di valutare se e quali metadati la piattaforma/sistema associa al documento e se questi coprono i metadati individuati come obbligatori dalle Linee guida sul documento informatico (allegato 5);
3. Aggregazioni: l’aggregazione di documenti fra loro collegati e la possibilità di fruirne, in qualche misura, in modo “sinottico” è un altro aspetto che completa il significato di un singolo documento, che non è mai autocontenuto relativamente al suo significato, ma ha bisogno di essere apprezzato insieme agli altri documenti che rappresentano la situazione complessiva in cui si inserisce. Il controllo richiede quindi di verificare come nel sistema sono gestite le aggregazioni di documenti e, soprattutto, in che modo si gestisce la situazione in cui documenti collegati a documenti gestiti nel sistema emergono in sistemi differenti^[11]Detto così può sembrare uno scioglilingua ma, in realtà, è un caso pratico ricorrente. Per esempio: un software che gestisce i tributi di un ente locale e consente di interagire con l’ente … Continue reading.
4. Condivisione e interoperabilità di dati e documenti con il sistema di gestione informatica dei documenti e altri sistemi di business (come da paragrafo 4.2.4 dello standard). Nel 2026 la disponibilità e l’accesso a dati e documenti non può ritenersi soddisfatta se l’unico accesso possibile è quello dell’operatore umano che ha dati e documenti disponibili solo ed esclusivamente tramite l’interfaccia nativa del software. Dati e documenti devono essere accessibile anche a partire da altri software/sistemi e circolare in modo protetto. Il punto prevede quindi di verificare se il software/piattaforme espone interfacce API con particolare riferimento a quelle che consentono di accedere ai documenti per trasferirli nel sistema di gestione documentale o trasferirveli.

inPA, il Portale del reclutamento

Per i riferimenti normativi e tecnici: La bussola digitale – inPA.

Un’analisi della gestione documentale implementata di inPA l’avevo fatta a metà 2024 (nel post Archivista non ti arrabbiare, l’importante è partecipare) ed è tuttora attuale visto che non sono intervenute modifiche significative sulla piattaforma.

Di fatto, non c’è traccia di analisi preliminare dei requisiti documentali da soddisfare, non nell’accezione dello standard ISO 16175, ma, direi, nemmeno in altre accezioni più blande. Non sono nemmeno previste interfacce API esposte alle amministrazioni che usano (obbligatoriamente) la piattaforma per gestire i concorsi e le selezioni per il reclutamento del personale. Quindi: niente classificazione, niente metadati, niente possibilità di “aggregare” documenti trattati al di fuori della piattaforma, niente interoperabilità.

Ci sono operazioni manuali possibili, visto che inPA consente di scaricare uno “zippettone” con tutti i documenti accumulati in una singola procedura di concorso e un foglio Excel di riepilogo delle candidature. Tuttavia, in assenza di metadati associati ai documenti diventa già difficile riconoscere ai file contenuti nel pacchetto compresso lo status di documento e, inoltre, diventa complicato se non impossibile avviare processi di gestione documentale su quei documenti.

Il back-office SUAP

Per i riferimenti normativi e tecnici: La bussola digitale – SSU.

Il SSU – Sistema informatico degli Sportelli Unici è una novità recente che dovrebbe prendere vita il prossimo 26 febbraio 2026. Si tratta di una federazione di sistemi propri delle amministrazioni che partecipano ai procedimenti degli sportelli unici SUAP e SUE che aderiscono a uno standard definito dallo Stato per comunicare fra loro e tenere costantemente aggiornato il Catalogo SSU, cervellone del sistema, che tiene traccia di tutti i procedimenti nazionali e del loro stato di avanzamento (oltre che detenere le informazioni necessarie per garantire la comunicazione fra tutti gli attori coinvolti).

Nello specifico, la documentazione relativa a una pratica complessa che coinvolge più pubbliche amministrazioni confluisce tutta nella componente “back-office SUAP”, sistema di business dello sportello SUAP che, per il territorio di competenza, è il punto di contatto unico fra impresa e pubblica amministrazione intesa nel suo complesso. La documentazione ha poi riflesso nei sistemi di business delle amministrazioni coinvolte, detti “back-office Enti Terzi”, per le parti di competenza.

Le regole di funzionamento ed interoperabilità pongono attenzione principalmente allo scambio di dati più che alla formazione e gestione di documenti. Un’analisi degli aspetti documentali si trova nel precedente post Digitalizzazione degli sportelli SUE e SUAP, rev. 2023. Gestione documentale: manca qualcosa?, anch’essa ancora attuale (le specifiche SSU hanno nel frattempo subito solo modifiche minori che non ne impattano l’impianto iniziale).

Poiché non sono contemplati gli aspetti di registrazione dei documenti in un sistema documentale propriamente detto, il requisito della classificazione è assente.

Per quanto riguardo i metadati, tutte le trasmissioni di documenti fra gli attori coinvolti sono accompagnate da messaggi con dati strutturati (in formato JSON) che descrivono anche il contesto procedimentale in cui si inserisce il documento e che a buon diritto possiamo definire metadati. L’attenzione però è sugli aspetti procedimentali e non su quelli documentali. Di conseguenza non c’è piena copertura dei metadati previsti dall’Allegato 5. Per le regole di funzionamento del SSU, la preferenza è lo scambio di documenti con dati strutturati almeno per le istanze iniziali per cui da tempo esistono schemi XML: ulteriori metadati utili alla gestione documentale possono ricavarsi da lì.

Aggregazioni: ogni scambio di documenti fra gli attori coinvolti è accompagnato dal riferimento al CUI – Codice Univoco Istanza che individua in modo univoco il procedimento in cui il documento si inserisce. Ciò favorisce l’aggregazione dei documenti e, anche se non è espressamente previsto dalle regole tecniche, è piuttosto pacifico che il back-office SUAP mostri all’operatore di turno i documenti e i dati di una pratica aggregati fra loro (nella stessa schermata, insomma).

Per quanto riguarda l’interoperabilità, va detto che la revisione degli sportelli unici digitali è tutta incentrata sull’interoperabilità per la quale si definisce una specifica standard tassativa. Tuttavia le interfacce interoperabili sono esposte solo alle componenti informatiche previste dalle specifiche e poi censita nel Catalogo SSU: front-office SUAP, back-office SUAP, back-office Enti terzi, Catalogo SSU, Registro delle imprese e Sistema Com-Unica. Non c’è quindi margine per l’interoperabilità con il sistema documentale degli enti coinvolti, che devono quindi sviluppare in proprio integrazioni a partire dai propri back-office inseriti nel SSU (il fatto di avere a disposizione molto dati strutturati aiuta senz’altro).

Le PAD

Per i riferimenti normativi e tecnici: La bussola digitale – Contratti pubblici e PAD.

Anche agli aspetti documentali delle Piattaforme di Approvvigionamento Digitale (PAD) ho dedicato vari interventi, da ultimo, successivamente all’adozione delle nove regole tecniche che portano novità anche in tema di gestione documentale, il post Ciclo di vita dematerializzato dei contratti pubblici: l’archivio destrutturato al veglione di San Silvestro.

Come evidenziato nel post citato, la riflessione sulla gestione documentale in fase di definizione delle regole tecniche a cui devono attenersi c’è stata, tanto che sembra emergere un modello di records management che prevede la tenuta dei documenti, nel solo sistema di business, con limiti e difficoltà del caso. Questo, addirittura, deve prevedere meccanismi per recuperare e inserire nel “fascicolo di gara” documenti formati esternamente alla piattaforma e, novità della nuova edizione, catturare con strumenti automatici anche i metadati associati ai documenti.

Le regole tecniche fanno esplicito riferimento all’allegato 5 delle linee guida e prescrivono che i documenti trattati nella PAD siano dotati di tutti i metadati che l’allegato prevede. La versione precedente escludeva i metadati legati alla classificazione e alla fascicolazione, la nuova versione supera questa esclusione perentoria e dispone, in modo non del tutto chiaro, che l’amministrazione che usa la PAD adegui i suoi piani di classificazione e fascicolazione a quelli presenti nella PAD. Di fatto, quindi, manca il collegamento con il piano di classificazione dell’ente.

Per quanto riguarda le aggregazioni, la PAD accoglie il già citato “fascicolo di gara” che trova nella PAD la sua sede primaria. Le regole tecniche elencano anche tutti i documenti che, per ogni fase del ciclo di vita del contratto, sono da inserire nel fascicolo. Come detto, la previsione espressa è che il fascicolo recuperi documenti prodotti esternamente, corredati di metadati.

Va sottolineato che le regole sulle PAD costituiscono un apparente unicum nel panorama normativo nazionale, perché considerano sempre i metadati come imprescindibili per il documento (che, in effetti, senza metadati è al più un file).

Interoperabilità: non sono previste interfacce da esporre alle amministrazioni utilizzatrici ma solo alle banche dati centrali.

Considerazioni sull’analisi

I tre esempi di sistemi di business proposti si rifanno tutti alla configurazione del software di business autosufficiente per le questioni documentali, l’unica configurazione che sembrerebbe esclusa dall’attuale assetto normativo della gestione documentale. Tuttavia lo fanno con esiti diversi, probabili conseguenze di diverse sensibilità da parte delle autorità che hanno curato le rispettive regole: Dipartimento per la funzione pubblica per inPA, Dipartimento della funzione pubblica e AgID per il SSU e AgID e ANAC (Autorità Nazionale Anticorruzione) le PAD.

Si conferma, quindi, la discordanza fra impianto normativo di cornice e realizzazioni concrete delle piattaforme che, come ripetuto più volte e in più occasioni, non considerano mai il fatto che l’amministrazione abbia un sistema di gestione informatica dei documenti, un proprio archivio e proprie esigenze di completezza e piena disponibilità del patrimonio informativo.

La tabella seguente mira a valutare il livello di maturità documentale delle tre piattaforme, secondo i quattro criteri sopra enunciati e analizzati.

Piattaforma	Classificazione	Metadati	Aggregazioni	Interoperabilità	Totale
inPA	0	0	0	1	1
back-office SUAP	0	1	1	0	2
PAD	1	2	1	0	4

Come già detto, danno da pensare i tre esiti differenti per gestire situazioni per certi aspetti simili.

Le PAD, nonostante tutto, sembrano quelle più attente. Pur nella già ricordata lontananza dai dettami di TUDA dpr 445/2000 e Codice dell’Amministrazione digitale sono quelle che più di tutte si sono poste il problema della gestione documentale e, in un certo senso, lo hanno risolto. Però, come si può raggiungere uniformità di soluzioni allo stesso problema e, anche, recuperare aderenza con la cornice normativa di riferimento?

Lo standard ISO 16715, per come l’ho percepito io, mira, in primo luogo, a rendere consapevole chi progetta e sviluppa software dei risvolti documentali insiti nel funzionamento del software stesso e, successivamente, a guidarlo nell’adottare misure e scelte utili a preservare la documentazione delle attività che gestiscono.

Che sia forse il caso di diffondere lo standard ISO 16175 (e la specifica ISO/TS 16175.2) più incisivamente sia presso chi sviluppa e propone software, sia presso i funzionati pubblici che li selezionano?

Suggerimenti all’Agenzia per l’Italia digitale

Visto che siamo (o, meglio, l’AgID è) in fase di aggiornamento delle Linee guida su formazione, gestione e conservazione dei documenti informatici, propongo una sinteticissima lista di punti da aggiungere:

• referenziare lo standard ISO 16175-1 e le specifiche tecniche ISO/TS 16175-2 sia nelle linee guida sul documento informatico sia nelle linee guida sullo sviluppo di software (se poi ACN li referenziasse nel regolamento cloud…)
• mettere obbligatori i metadati di cui all’Allegato 5 in tutti i software che trattano documenti;
• rendere obbligatoria l’interoperabilità verso i sistemi dell’amministrazione (proprio tramite un MUST e non tramite uno SHOULD);
• individuare nel piano di classificazione dell’ente (e nel piano delle aggregazioni) l’elemento di collegamento fra software e sistema di gestione informatica dei documenti.

Ricordiamo che ogni applicativo in uso in una pubblica amministrazione a supporto di una funzione istituzionale tratta fatti, atti e dati giuridicamente rilevanti. Per questo motivo, produce (o dovrebbe produrre) documenti; questi vanno trattati e gestiti correttamente, lasciandosi guidare dalle esigenze archivistiche (come ribadite nei moderni standard del records management) e da più generali istanze di sostenibilità ed efficienza.

Chiudo con una citazione dall’intervista di Aldo Maugeri ad Adrian Cunningham: “good records don’t just happen“.

Foto di ruanj2008 da Pixabay