Come scegliere il software di gestione documentale dopo le nuove linee guida Agid

A partire dal primo gennaio 2022 è scaduto il tempo concesso alle Amministrazioni per adeguarsi alle nuove Linee guida per la gestione documentale e la conservazione: al riguardo, l’idea assai diffusa è che l’aspetto tecnologico insito in questo passaggio sia qualcosa di irrilevante, quasi trascurabile. Si tratta in realtà di un aspetto fondamentale, che sebbene non sia condizione sufficiente, è comunque senza ombra di dubbio necessaria per la costruzione di un sistema di gestione documentale degno della funzione chiamato a supportare: sarebbe come pensare che per vincere un GP di Formula 1 l’auto fosse irrilevante.

Fra le questioni tecnologiche quella che maggiormente impatta, ma anche, forse quella di cui meno si è parlato, è senza dubbio il software di gestione documentale. Strumento d’uso quotidiano, le nuove Linee Guida ampliano i suoi casi d’uso e lo elevano a fulcro del sistema informativo dell’Ente. Qui di seguito cercherò, in estrema sintesi di descrivere le caratteristiche essenziali che un software di gestione documentale, aggiornato a ciò che è previsto nelle Linee guida, dovrebbe possedere al fine di supportare efficacemente l’utenza nel passaggio dall’archivio cartaceo a quello digitale.

Nuove Linee guida Agid gestione documentale e conservazione, perché si rischia di non essere pronti

Dal protocollo informatico a sistema di gestione informatica dei documenti

Uno dei maggiori effetti dell’entrata in vigore delle nuove LLGG, è quello di sancire il definitivo passaggio dal protocollo informatico al sistema di gestione documentale. È questo un passaggio importantissimo, spesso non capito dalle PA, e forse nemmeno compreso appieno, quantomeno non in tutta la sua portata, dalle software-house stesse. Le ricadute sono principalmente due:

• Il software è chiamato non solo a gestire il registro di protocollo, cioè solo la fase di registrazione delle entrate e uscite dei documenti dall’archivio, ma l’intero archivio, inteso non solo come raccolta di documenti, ma comprendente tutte quelle strutture (fascicoli in primis, ma anche altre forme di aggregazioni di documenti nonché registri/repertori) che all’archivio danno forma (e sostanza);
• L’utilizzo del software diventa pervasivo, esteso di fatto a chiunque operi nell’Ente, anche non necessariamente a chi svolge mansioni prettamente amministrative o archivistiche.

Questi aspetti hanno risvolti assai rilevanti in termini di progettazione del software in quanto estendono in modo significativo sia le funzionalità da mettere a disposizione, sia l’impostazione stessa, che deve essere adattata ad una platea molto più estesa che ne farà uso quotidiano.

L’archivio digitale

Passare da protocollo informatico a sistema di gestione informatica dei documenti, è un passo più lungo di quanto non si possa immaginare. L’oggetto della gestione passa dall’ essere sostanzialmente un registro (seppur, pian piano, con associati dei documenti) all’intero archivio. Ad oggi i software sono ancora prevalentemente incentrati sulla gestione del registro di protocollo e dedicano minore attenzione all’archivio. Le caratteristiche del sistema, in questo senso sono descritte non solo nelle LLGG ma già nel TUDA stesso. Riassumendo:

• gestione completa dei fascicoli informatici, così come descritto all’articolo 65 del TUDA, dotati dei metadati descritti nell’Allegato 5 e capace di raggiungere gli obiettivi indicati dall’articolo 41 del CAD, nell’ottica di un utilizzo esteso del sistema; fino alla conservazione, così come descritto all’articolo 44 del CAD;
• possibilità di gestire gli strumenti archivistici diversi dal titolario, in particolare il piano di fascicolazione e di scarto;
• gestione di tutte le strutture di archivio: serie di fascicoli e di documenti, repertori, e altri registi;
• la possibilità di poter gestire la fase attiva della formazione dei documenti.

In molti software la gestione dei fascicoli è spesso appena abbozzata, ancora oggi, ahimè, a ben sedici mesi dalla pubblicazione delle LLGG, priva anche dei metadati presenti nell’Allegato 5. Eppure, questi metadati sono essenziali, ad esempio, per implementare il fascicolo di procedimento, così come descritto all’articolo 41 del CAD. Gestione dei fascicoli è, inoltre, impostata secondo una logica prevalentemente archivistica, dimenticando che il fascicolo è più che altro strumento legato all’attività amministrativa quotidiana. Una tale impostazione fa sì che, seppur presente, alla possibilità di formare i fascicoli nel sistema, si preferisca, purtroppo, il file system di qualche server. Con tutto quello che ciò comporta. La mancanza della possibilità di gestire la fase attiva del documento (quella cioè volgarmente detta di “bozza”) completa l’opera.

Gli strumenti necessari

Al di là degli aspetti operativi, che vedremo in seguito, in molti software mancano ancora anche gli strumenti archivistici: piano di fascicolazione e conservazione su tutti, la cui gestione attraverso il software stesso, darebbe grande impulso al loro utilizzo, semplificando non poco, se ben pensati, la strada per raggiungere la corretta strutturazione dell’archivio.

Perché questi non sono quasi mai presenti è emblematico. La causa non va ricercata solo nel fatto che i sistemi ancora oggi sono incentrati sul protocollo piuttosto che sull’archivio, ma anche nella logica del “perché tanto gli utenti non ce lo chiedono”. E qui mi viene in mente ciò che Giovanni Manca, uno che di IT pubblica la sa lunga, mi ricorda in continuazione: la qualità dell’offerta è proporzionale a quella della domanda; aprendo un gigantesco capitolo che però andrebbe affrontato in separata sede ma che rappresenta senz’altro un’emergenza di cui sarebbe bene occuparsi.

Oltre i fascicoli

Altra caratteristica essenziale è la possibilità di gestire anche le altre aggregazioni informatiche e registri/repertori. Non esistono solo i fascicoli, ma le serie (di documenti, di fascicoli), i repertori ed altri registri. E tutti, come puntualmente specificato nelle LLGG (ma anche già nel TUDA, norma del 2000) devono essere gestiti correttamente nel sistema. Anche in questo caso sono funzioni spesso assenti o limitate, con implementazioni minimale e non sempre coerenti. In particolare, i repertori e registri, che, cito testualmente dal paragrafo 3.1.3 delle LLGG, andrebbero gestiti non solo nel sistema ma “applicando ove possibile i requisiti fissati per la registrazione di protocollo anche alle altre forme di registrazione informatica dei documenti”. Ancora oggi capita frequentemente di trovare la gestione dei tipici repertori di un Comune, ad esempio gli atti, gestiti fuori dal sistema e con logiche ben differenti da quelle sopra indicato.

Unicità dell’archivio

Altro aspetto fondamentale che le LLGG rafforzano: il sistema di gestione informatica dei documenti (da qui in avanti SGID) è uno. Ovvero, il SGID è una componente del sistema informativo, unica, a cui ogni altra componente deve fare riferimento quando tratta documenti. In termini tecnici ciò ha ripercussioni importanti:

• SGID deve essere dotato di un set di API estremamente estese, in modo che gli altri software (non solo gli altri SGID di altri Enti, come ahimè descritto nell’Allegato 6 delle LLGG), laddove necessario, possano utilizzare le funzioni messe a disposizione dal sistema per ogni aspetto legato alla gestione dei documenti;
• meglio ancora se la UI (interfaccia utente) dello SGID fosse completamente disaccoppiata dalla parte funzionale del software;
• le altre componenti del sistema non devono trattare/gestire documenti, al di fuori dello SGID.

Caratteristiche queste che potrebbero sembrare banali, ma che ad oggi, con software gestionali nati negli anni 90/2000, pensati con la logica a “silos”, sono ancora spesso presenti nei gestionali in uso presso le PA.

Il nodo dell’interoperabilità

Anche la particolare declinazione di interoperabilità, presente nella normativa e nel Piano Triennale non aiuta. Al di là di quanto stabilito nel succitato Allegato 6, che però si riferisce solo a comunicazioni fra SGID di diverse PA, non esiste una definizione di API standard, lasciando il tutto in capo alle software-house che sono libere di definire le interfacce come meglio credono, creando notevoli problemi di interoperabilità “reale” fra diverse componenti del sistema informatico. Favorendo così la nascita e l’ampia diffusione degli attuali software monolitici in uso presso la maggioranza dei Comuni, che rappresentano l’antitesi dell’interoperabilità, spingendo ai suoi massimi (“on steroids”, come direbbero gli americani) specie ora, con il passaggio al cloud, il deprecabile quanto dannoso fenomeno del “vendor lock-in”.

Interoperabilità dei sistemi tra promesse e realtà: lo stato dell’arte

Per fare un esempio concreto, si pensi ad un portale delle istanze di un Ente: il minimo sindacale da richiedere in termini di integrazione con lo SGID sarebbe quello di eseguire l’acquisizione, con relativa protocollazione automatica dell’istanza ricevuta, la creazione del fascicolo del relativo procedimento e lo smistamento al responsabile del procedimento. Ad oggi, funzionalità simili, sono solo raramente presenti e, laddove lo siano, nella maggior parte dei casi si tratta di soluzioni di un solo fornitore. Ed è bene rimarcare, non si tratta di funzionalità tecnicamente complesse, anzi, sarebbero scontate, ma che la mancanza, a volte voluta, di interfacce standardizzate, rende difficili da realizzare.

Uno strumento di lavoro quotidiano per tutti

Estendere le funzionalità del SGID a tutto ciò sopra descritto, oltre ad essere, come vedremo in seguito, come minimo integrato con un sistema per la gestione dei procedimenti, amplia in modo enorme la platea degli utenti. In buona sostanza, ogni dipendente dell’Ente, anche se in modalità e con scopi differenti, dovrà utilizzare il sistema.

Questo è forse uno degli aspetti più impattanti perché i sistemi sono nati ed hanno un’impostazione “protocollistica”. Ben poche PA usano il sistema in modo così estensivo, quasi nessuna come strumento di lavoro quotidiano, dove formare fascicoli, gestire iter. Attività queste, è bene ricordarlo, che sono il “core business” di una PA. Le caratteristiche abilitanti sono a mio parere le seguenti:

• usabilità: un’interfaccia utente intuitiva, poco “burocratica”, in grado di non fare rimpiangere il file system, che, come si diceva sopra, rimane ancora oggi il luogo privilegiato per la lavorazione dei documenti e la loro aggregazione;
• legato al punto precedente, come già sopra evidenziato, la capacità di poter gestire la fase attiva della produzione documentale: in poche parole non pensare allo SGID come al solo luogo deputato al “records management” (dove si depositano solo i documenti già pienamente formati, per archiviarli) ma anche il luogo dove i documenti si inizia a lavorarli, rivederli (anche a quattro mani, come ad es fanno alcuni strumenti di largo uso), correggerli, scambiarseli; per chi già conoscesse strumenti classici di Document Management come ad esempio Alfresco, sa a cosa mi riferisco;
• funzionalità di “collaboration”, con cruscotti/scrivanie dove è possibile gestire tutte le attività relativa ai singoli documenti o alle pratiche;
• gestione degli utenti/profili e dei diritti di accesso adeguate ad un uso estensivo, basate non solo sui singoli o sull’organigramma, ma con gestioni sofisticate di gruppi ma soprattutto “ruoli”; aspetto questo fondamentale non solo dal lato operativo ma anche e forse soprattutto per gestire correttamente la gestione dei dati personali o sensibili, aspetto che l’estensione della platea complica non poco e a cui raramente si dà il giusto risalto;
• funzionalità avanzate di gestione sostituzioni di personale assente, con possibilità di attivare “deleghe” ed accessi “impersonificati” (accessi “per conto di”, previa delega);
• funzionalità avanzate di trattamento dei documenti, capaci di eliminare o come minimo alleviare, le problematiche che l’uso del documento informatico pone, specie a chi è abituato a formarlo con le consolidate prassi dell’analogico.

L’importanza dell’automazione

Qui c’è poco da dire: l’utilità dello strumento informatico è direttamente proporzionale al grado di automazione che riesce ad introdurre. Non solo, uno strumento informatico non capace di automatizzare, quanto meno il lavoro ripetitivo, spesso non solo non aiuta, ma peggiora la situazione. La gestione documentale in questo non rappresenta un’eccezione. La difficoltà nel realizzare l’automazione è che in questo campo, la si riesce ad ottenere quasi esclusivamente attraverso l’integrazione con altri sistemi (motivo per cui la disponibilità di API, descritta sopra, è ancora più importante).

Esempi:

• automazione di grandi quantità di documenti, quali ad esempio quelli generati da altri sistemi in modo massivo (si pensi ad esempio al sistema di gestione dei tributi, o alle bollettazioni) che devono poter essere generati, protocollati e “postalizzati”, senza interventi di operatori;
• automazione del ricevimento di specifici documenti (magari con l’applicazione di banali filtri alle email, senza pensare a soluzioni più complesse come quelle basate sul riconoscimento tramite ontologie), con conseguente radicale diminuzione delle protocollazioni manuali;
• anche aspetti marginali, quali ad esempio la possibilità di apporre firme massive (anche automatiche) per coloro che firmano giornalmente un numero elevato di documenti (funzionalità di c.d. “libro firma”), sono da considerare con attenzione;
• trattamento automatico dei documenti non testuali; il caso della FE è il più semplice (e ahimè ancora poco automatizzato!) ma anche le istanze provenienti da un portale on-line, dovrebbero poter essere acquisite dai gestionali specifici, senza necessità di inserire dati manualmente.

Ovviamente l’elenco sopra è ben lontano dall’essere esaustivo. Il concetto però deve essere chiaro: i software devono essere impostati in modo da agevolare in tutti i modi l’automazione delle attività. Anche a costo di scontrarsi con le prassi, le abitudini e l’organizzazione presenti nelle PA. È scopo dell’RTD, degli informatici nella PA (se ci sono, altrimenti dotatevi di qualche buon consulente a supporto del RTD) indirizzare correttamente questo aspetto, spiegando all’interno l’importanza dell’automazione, che ben vale qualche modifica alle prassi, e così aiutando le software-house nel proporre strumenti sempre più efficaci.

Il sistema di gestione informatica dei procedimenti

Le LLGG, al pari dell’articolo 41, parlano di un sistema di gestione automatizzata dei procedimenti amministrativi. A parere di chi scrive, questa è una componente funzionale distinta, e non sarebbe corretto, oltre che costoso, implementarla nello SGID (così come in altri software gestionali specifici).

È tuttavia necessario che lo SGID sia in grado di dialogare con questo, per ora ancora fantomatico sistema di gestione dei procedimenti. E come minimo essere in grado di creare un legame fra procedimenti e i relativi fascicoli, anche eventualmente al solo scopo di meglio organizzarli o per dotarli, così come vorrebbe l’articolo 41 del CAD, dello stato di avanzamento della pratica sottesa.

Normalmente, quando si parla di gestione automatica dei procedimenti, si pensa sistemi di Workflow Management (WFMS). Anche se si inizia a discutere di soluzioni basate sull’Intelligenza Artificiale, queste, al momento, appaiono al più futuribili. I WFMS, sebbene strumenti complessi e spessissimo poco accettati per via della loro presunta (e in alcuni casi reale) rigidità, avrebbero il vantaggio di “forzare” una formalizzazione degli iter. Attività propedeutica all’auspicata loro ridefinizione nell’ottica di una loro ottimizzazione e adattamento ai nuovi strumenti disponibili.

Le caratteristiche

Uno SGID, integrato con un WFMS dovrebbe:

• non implementarlo come componente interna dello SGID stesso, al più si possono integrare le componenti di disegno degli iter, per consentire la modellazione, se richiesto, all’interno dello SGID stesso;
• usare WFMS basati su quello che attualmente è lo standard di mercato consolidato, il BPMN (ve ne sono di open source, come ad es. Activiti);
• WFMS che deve essere integrato a sua volta con il sistema di utenti/gruppi/ruoli dello SGID;
• le “scrivanie” di attività, di cui avevamo accennato prima, devono essere costruite sulla base degli stati delle varie istanze di workflow attive nel WFMS;
• rendere ben distinti i workflow documentali (es. quello di firma di un particolare tipo di documento) con quelli di procedimento; i primi devono essere associabili a particolari tipologie di documenti definite nello SGID;
• fornire una “banca dati” di workflow predefiniti, che possano però essere adattati alle esigenze degli Enti.