Foto di crycks rilasciata sotto licenza cc - https://www.flickr.com/photos/66833578@N02/6178051052

Master data e building blocks, la strategia del Friuli Venezia Giulia per l’interoperabilità

di Andrea Buttol, referente per l’Agenda digitale Regione Autonoma Friuli Venezia – Cantiere Cittadinanza digitale

A partire dal 2010 la Regione FVG ha iniziato un percorso, che con un’espressione attuale possiamo definire di digital transformation, atto a migliorare i processi di lavoro connessi agli iter relativi alla presentazione di istanze da parte di cittadini e imprese e all’istruttoria delle stesse da parte degli uffici amministrativi competenti, in un’ottica di revisione della spesa congiuntamente alla volontà di offrire servizi più smart alla comunità.

La logica che ha guidato e ancora guida questo percorso, prevede di identificare contesti omogenei (user centered) riferibili a processi differenti e standardizzare le regole, i flussi e i dati necessari per produrre gli output previsti.
I contesti identificati si possono raggruppare in tre tipologie:

  1. processi di front-end;
  2. processi di back-end in ambito contributivo;
  3. processi di back-end in ambito autorizzativo.

Ad esempio se consideriamo il contesto di front-end, ci accorgiamo che, dal punto di vista concettuale, i passi logici che il cittadino deve fare per presentare un’istanza sono i medesimi a prescindere dal tipo di procedimento considerato. Se deve presentare una richiesta di contributo per la frequenza del figlio all’asilo o per un bando del POR FESR in qualità di imprenditore, piuttosto che una SCIA per avviare una attività commerciale o per chiedere un’autorizzazione edilizia dovrà sempre identificarsi, compilare dei dati, allegare dei documenti, sottoscrivere in qualche forma l’istanza, trasmetterla, avere un esito. Analogo ragionamento vale per i contesti di back-end.

Spostandosi su un piano più architetturale, rispetto ai contesti utente, possiamo identificare ulteriori tre insiemi concettuali di oggetti che possono essere argomento di standardizzazione. I tre insiemi sono:

  1. dati (che compongono un’istanza);
  2. step o fasi (di un iter);
  3. canali e metodologie per la trasmissione dei dati.

L’idea alla base consiste nel gestire in maniera disgiunta i tre insiemi creando, per ogni oggetto di un insieme, dei moduli software auto-consistenti (building blocks) che, come dei mattoncini del lego, possono essere connessi tra di loro per andare a costituire un processo. Il framework prevede la realizzazione di una serie di moduli standard, riutilizzabili da tutti i processi attraverso l’esposizione di servizi applicativi e la possibilità di estenderli con moduli specifici per singoli domini applicativi.

Facendo sempre riferimento all’esempio del front-end, tecnicamente l’interazione tra i moduli è orchestrata per il tramite di un contesto informatico[1] che viene configurato in base alla tipologia del procedimento. L’interscambio delle informazioni avviene attraverso una struttura XML che viene letta e/o scritta dai moduli nel rispetto di una semantica condivisa.
Una istanza di parte, vista come oggetto appartenente all’insieme dei dati, sarà pertanto il risultato della composizione di un certo numero di blocchi che racchiudono dati strutturati omogenei e organizzati secondo un’ontologia informatica ben definita che prevede anche la presenza di documenti non strutturati (i.e. allegati) con una parte comune a tutti gli ambiti (i.e. anagrafiche e metadati) e una parte specifica del dominio considerato[2].

Fin da subito c’è stata la consapevolezza che le fondamenta dell’architettura sono i dati; pertanto il punto di partenza dell’intero percorso ha riguardato la definizione dei cosiddetti dati master e l’implementazione dei loro meccanismi di gestione. Le logiche utilizzate sposano i paradigmi del Master Data Management (MDM). Un registro master data è una fonte fidata e autorevole di informazioni che può e dovrebbe essere riutilizzata digitalmente da terzi (consumatori) dove una singola struttura (produttore) è responsabile della raccolta, dell’utilizzo, dell’aggiornamento e della conservazione delle informazioni. Per “autorevole” qui si intende che un master data è considerato la “fonte certificata” di informazioni ossia mostra lo stato corretto, è aggiornato e garantisce i più alti livelli possibili di qualità e integrità

Il primo master data implementato in regione è stato quello dei procedimenti (MDPR) che raccoglie tutti i dati dei procedimenti amministrativi regionali arricchiti con ulteriori informazioni utili alle logiche di business dei vari building blocks come, ad esempio, schede descrittive, tassonomie, date di apertura e chiusura bandi, criteri di obbligatorietà delle informazioni (dati e allegati) da produrre, ecc.

Un processo di acquisizione dati inizia quindi istanziando una configurazione di contesto memorizzata nel MDPR e riferita a una certa tipologia di procedimento. Successivamente sono stati realizzati anche i seguenti due registri base:

  • il master data dei soggetti (MDSO) che raccoglie i dati anagrafici dei soggetti che a qualsiasi titolo vengono in contatto con l’Amministrazione regionale ed è integrato, in cooperazione applicativa, con fonti certificate di anagrafiche quali il registro imprese e altri albi di settore;
  • il master data delle strutture organizzative (MDST), istituito allo scopo di individuare un unico punto di raccolta delle informazioni certificate relative alle strutture organizzative che fanno capo agli enti locali e ad altri enti regionali[3];

Alcuni esempi di building blocks per la gestione degli iter sono: modulo di identificazione e accesso, configuratore di contesto, archivio istanze correnti, gestore deleghe, gestore allegati, controlli di firma, conversione di file, generazione busta trasporto, pagamenti online (compreso @e.bollo), servizi di protocollazione, gestore documentale, gestore integrazioni, scadenzari, cruscotto utente.
Dal momento che i dati che compongono la pratica sono concettualmente disgiunti dai canali di trasmissione, l’architettura consente la definizione di meccanismi di interscambio differenti. Oggi sono operativi servizi in cooperazione applicativa, l’inoltro automatico via PEC e il download da server partendo da un url. In questo modo, a seconda del grado di informatizzazione dell’attore terzo che deve ricevere i dati, il processo potrà essere implementato con il canale più idoneo a garantire l’interoperabilità.

L’applicazione pratica dell’architettura appena descritta ha trovato terreno fertile nel dominio dello sportello unico per le attività produttive (SUAP) che negli anni è diventato un vero e proprio laboratorio di innovazione. A luglio 2013 è stata rilasciata in produzione la versione 1.0 del nuovo portale regionale SUAP in Rete, un’integrazione di building blocks dove, ad esempio, gli alberi di navigazione, le schede descrittive, e gli allegati dei procedimenti provengono dal MDPR mentre gli orari degli sportelli, i riferimenti di contatto e i comuni associati ad uno sportello dal MDST, il tutto rappresentato sul web secondo le regole della user experience. Oggi SUAP in Rete riceve e gestisce una media di circa 950 domande uniche al mese, copre il 71% dei comuni dell’FVG e negli ultimi 12 mesi ha avuto 46.000 visitatori unici.
Preme in questa sede evidenziare che tale risultato non è frutto di una mera architettura tecnico informatica ma di una condivisione e partecipazione di competenze multidisciplinari ai vari livelli, sotto l’egida di un coordinamento ben strutturato. Il primo passo si è concretizzato con la scrittura del regolamento alla L.R. 3/2001 sullo Sportello unico (D.P. Reg. 23 agosto 2011) che istituisce il Gruppo tecnico regionale (GTR) per la gestione del portale e, in particolare, della banca dati unica regionale dei procedimenti. In seno al GTR si è creato un gruppo di coordinamento ristretto che guida il processo e coinvolge nei tempi e nei modi giusti i vari attori, capace di supportare il GTR nelle decisioni da assumere e nella gestione dei sottogruppi tematici (formati tipicamente da volontari esperti)[4] per standardizzare procedimenti e modulistica. Il coordinamento, inoltre, fornisce assistenza e formazione all’utenza (sia di front che di back office) sull’interpretazione normativa, sull’uso del portale e sulla predisposizione della modulistica.
L’iniziativa di SUAP in Rete ha inoltre fatto da volano per altri domini che, di fronte alla disponibilità concreta di meccanismi utili ad aumentare efficienza e efficacia dell’azione amministrativa, hanno sposato la stessa logica. In particolare il sistema regionale per la gestione generalizzata dei procedimenti contributivi (GGPC) riutilizza le stesse ontologie dei dati e gli stessi building blocks di SUAP in Rete spesso estendendoli potenziandone le funzionalità. Da inizio 2017 ad oggi con il GGPC sono stati attivati una cinquantina di bandi di contributo (fondi strutturali e fondi diretti) ed acquisite circa 4.000 istanze. Altri esempi di applicazioni sono l’acquisizione online delle domande per l’iscrizione nei registri regionali dei revisori dei conti degli enti locali e dei mediatori culturali, la pubblicazione automatizzata dei dati sulle attività procedimentali nel sito della trasparenza e la gestione automatizzata del catalogo degli incentivi di cui alla L.R. 3/2015 (RilancimpresaFVG).

La sfida per il futuro è quella di convergere sempre di più verso un’ontologia unica dei dati e convertire i rimanenti domini applicativi alla logica dei building blocks e alle regole di interoperabilità standard.

 

 

 


[1] Inteso come l’insieme di tutte le variabili, costanti e funzioni che risultano disponibili in un dato punto del codice

[2] Da notare che questa strutturazione modulare consente ai sistemi informativi e di conseguenza alle strutture committenti della PA responsabili dei procedimenti, di soddisfare velocemente anche le richieste di acquisizione online di domande i cui dati non sono ancora stati standardizzati e inseriti nell’ontologia semplicemente attivando i moduli dati comuni per la parte strutturata e gestendo il resto con moduli di tipo allegato (questo tipo di soluzione in FVG viene chiamata di tipo light).

[3] Va ricordato che, come previsto dalla L.R. 9/2011 (“Disciplina del Sistema Informativo Integrato Regionale (SIIR) del Friuli Venezia Giulia”), possono accedere ai servizi messi a disposizione dal Sistema Informativo Integrato regionale tutti gli Enti locali, in forma singola o associata, e tutti gli enti pubblici economici del Friuli Venezia Giulia.

[4] sottogruppi tematici sono stati istituiti, ad esempio, per la definizione dei requisiti di sistema, per la standardizzazione di modulistica e per uniformare, su tutto il territorio, i requisiti igienico-sanitari dei luoghi di lavoro destinati alle attività di produzione di beni e dei servizi.

 

 

 

Foto di crycks rilasciata sotto licenza cc – https://www.flickr.com/photos/66833578@N02/6178051052