E alla fine arriva SUE (2): le specifiche di interoperabilità della revisione degli sportelli unici per l’edilizia

“E alla fine arriva SUE” non è il sequel di una commedia romantica ma uno degli atti finali del PNRR digitale che, nell’ambito del subinvestimento 2.2.3 della Missione 1, Componente 1, sotto la regia del Dipartimento della Funzione Pubblica, intende “consentire la piena interoperabilità dei sistemi coinvolti nei procedimenti edilizi“. L’intervento PNRR, collegato al Single Digital Gateway europeo, riguarda anche la rete degli sportelli SUAP (Sportelli Unici per le Attività Produttive) e, per questi ultimi, il percorso di revisione in chiave interoperabile delle comunicazioni fra le amministrazioni che intervengono nei procedimenti, è stato avviato già nel 2021 (ancor prima del PNRR).

L’archivista digitale intende dedicare tre piccoli approfondimenti alla questione:

• il quadro normativo e i punti di contatto con la nuova interoperabilità degli sportelli SUAP;
• uno sguardo alle specifiche di interoperabilità;
• cosa devono o possono fare i comuni e gli attori SUE.

Di seguito, quindi, il secondo episodio della trilogia SUE, che intende analizzare il contenuto delle specifiche tecniche di interoperabilità dei sistemi SUE e illustrarne il funzionamento, non senza qualche commento a margine (e in nota, avviso) .

Le specifiche di interoperabilità e altri riferimenti normativi e tecnici

Prima di iniziare, qualche riferimento normativo e tecnico (si rimanda anche al precedente post sul SUE) è utile, anche perché l’analisi di un sistema ancora in costruzione non può che basarsi sulla documentazione disponibile:

• lo sportello SUE è istituito in ogni comune con il dpr 160/2001 (art. 5).;
• le specifiche di interoperabilità dei sistemi SUE sono state elaborate nell’ambito del nell’ambito del Sub-investimento 2.2.3 (Missione 1, Componente 1) del PNRR (disponibile anche versione senza codice delle API);
• Unioncamere, che gestisce la componente infrastrutturale del sistema, ha redatto e pubblicato delle Linee guida per l’operatività degli Sportelli Unici dell’Edilizia nel SSU;
• le definizioni delle API in formato OpenAPI sono disponibili su un repository GitHub tenuto da AgID (https://github.com/AgID/SUE-allegato-tecnico/tree/main insieme ad altri artefatti citati nelle specifiche di interoperabilità.

Per chi volesse vedere il dettaglio delle API disponibili e valutare le funzioni messe a disposizione, i dati scambiati e il loro formato ricordo che i file di specifiche, disponibili in formato OpenAPI (estensione .yaml) nel repository GitHub, possono essere visualizzati in modo quasi intuitivamente leggibile tramite strumenti online come Swagger Editor: basta copiarci il contenuto del file YAML di interesse, senza nessuna titubanza o preoccupazione di condividere un documento con un “estraneo”, visto che le specifiche SUE sono già ampiamente pubbliche.

Nel seguito analizziamo soprattutto il contenuto delle specifiche tecniche di interoperabilità (testuali), che individuano tre aree di intervento:

• comunicazione interoperabile tra Sportelli SUE ed Enti Terzi: definizione di interfacce non dipendenti da workflow che permettano una comunicazione più efficiente, superando l’uso della PEC e promuovendo l’interoperabilità con le altre componenti architetturali.
• regole di digitalizzazione dei moduli: adozione delle modalità di standardizzazione e validazione dei dati attraverso tecnologie già consolidate nel mondo SUAP all’interno delle Specifiche Tecniche di cui all’articolo 5 dell’allegato al DPR 160 del 2010;
• utilizzo del Catalogo SSU: estensione del catalogo attualmente utilizzato per il SUAP, per includere le componenti dell’ecosistema SUE.

Gli attori dei procedimenti SUE

Le specifiche non li nominano apertamente ma i soggetti che intervengono nei procedimenti SUE sono:

• il privato, solitamente rappresentato da un professionista abilitato, che ha interesse a ottenere un titolo edilizio o a presentare comunicazioni di varia natura, collegato a interventi di edilizia residenziale^[1]Gli interventi e le attività di edilizia produttiva, invece, vivono all’interno del mondo SUAP.;
• il SUE – Sportello Unico per l’Edilizia, da intendersi come ufficio comunale (eventualmente gestito in forma associata da più comuni) che fa da unico punto di contatto con il privato di cui sopra per le questioni legate all’edilizia residenziale. Questo va inteso come ufficio che si occupa di orchestrare l’iter della pratica (spesso complessa e articolata), contatta le amministrazioni da coinvolgere nel procedimento (inclusi gli uffici comunali), raccoglie pareri e atti di assenso, autorizzazioni endoprocedimentali, fa da tramite per richieste di chiarimenti e integrazioni e, alla fine, se necessario, emette il provvedimento finale unico, come somma degli esiti delle istruttorie delle amministrazioni coinvolte;
• gli enti terzi, che sono quelli che entrano nel merito tecnico e giuridico del procedimento, conducono le istruttorie tecniche, rilasciano i pareri necessari e le autorizzazioni (parziali) di competenza. Fra questi ci sono anche gli uffici comunali, ragionevolmente vicini di stanza del SUE, ma logicamente diversi da questo nell’architettura del SSU (Sistema informatico degli Sportelli Unici). Non è escluso, anzi, direi che è l’assetto predominante, che il SUE coincida operativamente e a livello di organigramma con l’ufficio che si occupa di edilizia privata ma, ripeto, ai fini della comprensione del funzionamento del SUE interoperabile occorre mantenere le due funzioni (SUE e Ufficio edilizia privata) distinte;
• Unioncamere, che, con il nuovo disegno, assume un ruolo di regia e di “memoria” anche per le attività di edilizia residenziale: Unioncamere, di fatto fa funzionare il SSU e tiene traccia dell’avanzamento di tutte le pratiche istruite in tutti i SUE nazionali tramite il Catalogo SSU che è posto sotto il suo diretto controllo.

Le componenti informatiche

Per recitare la propria parte, gli attori SUE devono dotarsi di strumenti tecnologici (chiamiamoli pure software) che le specifiche tecniche chiamano “componenti informatiche“. Queste sono, rifacendosi alle definizione del capitolo 3, da pagina 9 in poi:

• il Front-office (front-office SUE), che espone le informazioni all’utenza, consente ai privati interessati la presentazione di istanze e comunicazioni, è il punto di contatto telematico (e unico) fra il SUE e il privato che vi si rivolge e si collega con la componente back-office per la trasmissione delle istanze e lo scambio delle successive comunicazioni fra SUE e intestatario della pratica, fino alla trasmissione dell’eventuale provvedimento finale^[2]A costo di essere eccessivamente didascalico, si parla di eventualità del provvedimento finale perché alcune attività edilizie si svolgono in un “regime amminsitrativo” che non … Continue reading;
• il Back-office (back-office SUE), che consente al SUE di svolgere il suo ruolo di coordinamento e verifica delle pratiche istruite tramite il SUE stesso, di smistare agli enti terzi coinvolti nei procedimenti le parti di competenza e di comunicare e scambiare documenti e informazioni (richieste di pareri e successive risposte, richieste di integrazioni ecc.) con gli enti terzi;
• la componente Enti terzi (back-office enti terzi), che è quella a supporto dell’attività di ciascun ente terzo: questa deve essere in grado di scambiare documenti e informazioni con la componente back-office SUE e consente agli enti terzi di condurre le attività di competenza in modalità digitale, fare le valutazioni ed emettere eventuali pareri. In linea di principio, la componente enti terzi non è esclusivamente dedicata alle attività SUE. Anzi, auspicabilmente un ente terzo dovrebbe essere dotato di uno strumento informatico che lo supporti nelle sue attività istituzionali: questo dovrebbe essere ampliato nelle sue funzioni in modo da interagire in interoperabilità con la componente back-office SUE. Ragionevolmente, la componente Enti terzi deve interoperare anche con le componenti back-office dei SUAP del su territorio e, il fatto che le regole di interoperabilità siano fondamentalmente le medesime, dovrebbe spingere a non frammentare i sistemi informatici. Fra l’altro, se una soprintendenza rilascia un parere per un intervento edilizio in un centro storico tutelato, dal punto di vista procedurale e documentale poco cambia se l’intervento è di edilizia produttiva o residenziale o se, addirittura, è risposta a una richiesta avanzata direttamente alla Soprintendenza (cosa che a rigore non dovrebbe succedere, ma succede);
• il Catalogo SSU, tenuto da Unioncamere, che è il cervellone dell’ecosistema SUE (e SUAP), cura la registrazione delle componenti informatiche degli enti coinvolti corredata degli indirizzi telematici (URL degli endpoint) per raggiungerli e dei metadati per interagirci correttamente, fornisce, per ogni istanza presentata tramite qualsiasi SUE di qualsiasi comune italiano il Codice Univoco Istanza (CUI) e tiene traccia dello stato di avanzamento delle conseguenti pratiche. Perché il Catalogo possa tenere traccia dello stato delle pratiche, ognuna delle componenti sopra menzionate deve, parallelamente a ogni operazione fatta in una pratica e a ogni scambio con qualche altra componente informatica, darne comunicazione al Catalogo e quindi deve implementare al suo interno le regole per dialogare con il Catalogo.

Tolto il Catalogo SSU, che è evidentemente uno solo, delle altre componenti ogni ente che partecipa al mondo SUE realizza una propria istanza, che può anche essere condivisa con altri enti.

Per esempio, una componente Front-office è offerta da Unioncamere con il portale Impresainungiorno^[3]Che il portale Impresainungiorno offra anche servizi relativi al SUE, io personalmente lo apprendo dalla documentazione messa a disposizione e dalle evidenza degli opendata pubblicati dal DFP. , altre componenti sono offerte da alcune Regioni. Altre ancora, la maggior parte, sono realizzate da operatori del mercato IT per la pubblica amministrazione. La componente front-office, comunque, è unica per ogni SUE^[4]Potrebbe essere tecnicamente possibile e anche affascinante e stimolante un’architettura in cui ogni SUE ha più di un front-office, in cui ogni utente esterno può scegliere per una data … Continue reading

Per quanto riguarda i comuni, come già detto, nell’impostazione del SSU ogni ufficio comunale che interviene nei procedimenti SUE è, dal punto di vista logico, un ente terzo e, quindi, deve dotarsi di un software che implementi le funzioni di back-office per enti terzi. Nella pratica è possibile che, in un comune, il software che supporta le attività di edilizia privata abbia anche funzioni in grado di supportare gli altri uffici comunali che intervengono, quali quelli che si occupano di funzioni relative all’ambiente, alla viabilità, all’urbanistica.

Potrebbe anche darsi il caso che il software “di edilizia privata” inglobi anche la funzione di back-office SUE^[5]Si è già osservato che spesso e volentieri, in un comune, la funzione SUE coincide con la funzione “edilizia privata”.- Anche questo è uno scenario ammissibile: tuttavia, poiché alla fine non esiste una trasmissione materiale di documenti fra sistemi diversi (il software è lo stesso!), se anche potrebbe essere inutilmente oneroso e insensato attivare la comunicazione interoperabile secondo le specifiche tecniche^[6]Sottolineo il “se anche”: niente vieta che lo stesso software decida di passare informazioni fra sue componenti interne tramite gli schemi delle specifiche tecniche SUE. Anzi, questo … Continue reading, sicuramente il software monolitico deve aggiornare il Catalogo SSU a ogni intervento di un ufficio.

Stiamo scambiando documenti

La trattazione fin qui, tolto qualche inciso e qualche nota (le avete lette? fare pure, vi aspetto), non ha preso in considerazione una funzione e una componente informatica fondamentali in qualsiasi ente pubblico. La funzione è la gestione documentale (o tenuta dell’archivio che dir si voglia). La componente informatica è il sistema di gestione documentale con la sua sezione di protocollo informatico.

Va sottolineato che, come per il caso SUAP, il fatto che i procedimenti di cui si tratta generino documenti (che ne sono, guarda un po’, “presupposto e residuo”), che le amministrazioni titolari dei procedimenti siano tenute a gestire correttamente quei documenti e quindi a registrarli e memorizzarli (con tanto di metadati) nel sistema di gestione informatica dei documenti passando dalla protocollazione, che di ogni procedimento o attività deve esserci un fascicolo aperto e contenuto nel sistema di gestione documentale e non altrove… ecco, di tutto questo le specifiche tecniche non fanno assolutamente menzione.

Eppure, gli scambi interoperabili di cui stiamo parlando coinvolgono proprio documenti! Gli enti devono ricordarsene, perché, anche se le specifiche non toccano il tema, la normativa, le prassi archivistiche e il buon senso non sono sospesi in alcuna misura. Per esempio, la legge 241/1990, che disciplina l’iter generale di ogni procedimento amministrativo, prescrive che, addirittura, le istanze siano protocollate il giorno stesso della loro presentazione^[7]Lo dice all’articolo 18-bis e, per quanto in un contesto “umano” la disposizione possa suonare eccessivamente onerosa se non impossibile, in un contesto automatico e interoperabile … Continue reading

E’ decisamente un peccato e una mancanza, che affligge sia la parte testuale delle specifiche tecniche^[8]Provare per credere: fate pure una ricerca (tipo con CTRL+F) per “protocoll*” o “document*” e ammirate come il poco che otterrete non riguarda minimamente l’ambito … Continue reading sia la parte di definizione del dettaglio informatico delle comunicazioni interoperabili. Per mantenere viva l’attenzione sul tema basterebbe poco: per esempio, che quando una componente informatica trasmette all’altra dei documenti ne trasmettesse anche gli estremi di protocollazione, fra i metadati che accompagnano la tresmissione^[9]Nello specifico, il documento da trasmettere non è allegato nativamente alla comunicazione interoperabile. Quest’ultima contiene solo dei metadati e un identificativo per consentire alla … Continue reading

A ben vedere, poi, il sistema di gestione informatica dei documenti potrebbe davvero fare le veci delle componenti informatiche di back-office (tanto SUE quanto Enti terzi), come, del resto, il dpr 445/2000 preconizzava ben cinque lustri fa. Ne ho parlato in un precedente post e rimando a quello per approfondimenti. Qui, pragmaticamente, occorre adattarsi a quello che c’è e sfruttarlo al meglio.

Le interfacce interoperabili e le interazioni fra le componenti informatiche

Le interfacce di interoperabilità descritte nelle specifiche tecniche sono basate su tecnologia REST, tecnologia raccomandata dal modello di interoperabilità tecnica nazionale, il ModI. A voler essere eccessivamente semplicistici, ciò vuol dire che le interazioni sfruttano il protocollo di trasferimento di dati HTTP (lo stesso del web) e prevedono lo scambio di informazioni (payload) in formato JSON.

Sono previsti, ancora in conformità con il ModI dei meccanismi di sicurezza: ovviamente, prima di interagire con una componente informatica occorre farsi riconoscere ed essere autorizzati (autenticazione) e, a maggior tutela della comunicazione, occorre anche “firmare” il contenuto informativo inviato (integrità del payload). Tali meccanismi di sicurezza sono realizzati grazie all’intermediazione della PDND (Piattaforma Digitale Nazionale Dati):

• l’autenticazione è garantita dal “voucher” ottenuto tramite la PDND (è la sua funzione di base), a valle del perfezionamento di un accordo di fruizione, la definizione di una finalità di uso dell’interfaccia interoperabile di interesse con annessa valutazione del rischio e del caricamento di opportuno materiale crittografico (la componente pubblica di una coppia di chiavi asimmetriche);
• l’integrità del payload (e la sua provenienza) è garantita dal pattern di sicurezza [integrity_rest_02] del ModI: di fatto, la stessa coppia di chiavi asimmetriche del punto precedente, è utilizzata per firmare il file JSON.

Detto dei tecnicismi da nerd, che poi sono qualcosa con cui occorre prima o poi sporcarsi le mani se si vogliono fare considerazioni sulla sicurezza, l’affidabilità e il valore giuridico e documentale degli scambi interoperabili (SUE o non SUE), si può dire qualcosa del contenuto di questi scambi.

Nella versione breve, si può dire che le interfacce sono di fatto le medesime elaborate per il SUAP interoperabile, con alcune modifiche per “generalizzarle” ed estenderle anche alle esigenze SUE.

Infatti, come si legge nelle specifiche tecniche, l’intervento ha lo scopo di realizzare “un ecosistema digitale integrato per gli Sportelli Unici per l’Edilizia (SUE), assicurando una comunicazione efficace e automatizzata tra i sistemi ICT delle amministrazioni coinvolte, in coerenza con quanto già approvato per l’ecosistema SUAP“. SI può anche anticipare che, dalla lettura delle specifiche, l’impianto complessivo risulta meno maturo di quello SUAP, tanto che le stesse specifiche parano di “una prima fase di adeguamento dei sistemi ICT coinvolti, base per l’avvio dell’interoperabilità del contesto SUE”. Il completamento del percorso richiederà “un impegno continuativo delle Amministrazioni, anche oltre i tempi previsti dal PNRR, al fine di massimizzare l’efficacia degli investimenti e garantire un adeguamento costante delle Specifiche Tecniche in linea con le esigenze evolutive del sistema”.

Del resto, come sottolineato nel primo approfondimento, da un punto di vista operativo gli attori e le operazioni che questi conducono, sono analoghe fra SUE e SUAP: riceveer, smistare, raccogliere, inviare. Se si ha chiaro il funzionamento del SUAP interoperabile, ci si può concentrare sui punti che, nell’incontro fra SUE e SSU, presentano differenze. Fra l’altro, questo è anche l’approccio delle specifiche tecniche stesse, che fanno costante riferimento al funzionamento del SSU per il “contesto” SUAP.

La generalizzazione delle interfacce di interoperabilità SUAP

La maggior parte delle modifiche rispetto alle specifiche di interoperabilità SUAP, ben evidenziate nel testo delle specifiche SUE, sono finalizzate alla generalizzazione delle prime per poter abbracciare anche scambi di tipo SUE e distinguerli dagli altri.

Quindi, la novità principale è che, già nel “descrittore dell’istanza^[10]Qui “istanza” non è il giuridichese per “domanda”, ma sta a indicare la realizzazione concreta di un procedimento, che ha un carattere generale. “Istanza” sta, … Continue readingdi un procedimento” (InstanceDescriptor, pagina 18 delle specifiche), accanto ai dati del CUI (Codice Univoco Istanza), compaiono le chiavi “context” e “sub_context“.

Le specifiche ci dicono che “attualmente”, le combinazioni context/sub_context sono:

• SUAP/SUAP;
• SUE/SUE Produttivo;
• SUE/SUE Residenziale.

Per preservare il corretto funzionamento delle realizzazioni fin qui prodotte di interoperabilita dei SUAP (fatte quanto la chiave del “contesto” non esisteva), è chiaramente specificato che se non si specifica un contesto (e un subcontesto), per impostazione predefinita si assume il contesto SUAP.

Qualche riflessione è d’obbligo:

• se l’intervento PNRR nasce già in origine con l’intento di abbraccia siare SUAP sia SUE, non ci si poteva pensare subito a questa distinzione di contesto? Del resto, che i flussi a livello operativo e documentale fossero sovrapponibili quasi in maniera perfetta è abbastanza evidente^[11]Fra l’altro, a occhio, credo che qualsiasi procedimento edilizio possa avere una realizzazione produttiva e una residenziale, quindi i procedimenti edilizi potrebbero quasi essere un … Continue reading.
• Non è chiarissimo cosa si intenda per “SUE Produttivo”. Emerge forse un vulnus di fondo nella partizione del mondo in SUAP e SUE, nella quale SUAP fa riferimento a una caratteristica soggettiva (l’essere “attività produttiva” da parte di chi presenta l’istanza/comunicazione) e SUE fa riferimento a una caratteristica oggettiva (l’istanza/comunicazione riguarda l’edilizia, non solo quella residenziale a quanto pare).
• Il fatto che si dica “attualmente”, sta forse a significare che dobbiamo attenderci estensioni di questo paradigma di comunicazione interoperabile ad altri tipi di procedimenti amministrativi? L’idea non sarebbe male, anche se il coinvolgimento diretto del mondo camerale, a mio modo di vedere già un po’ forzato per il SUE, sarebbe del tutto fuori luogo per altre aree funzionali di comuni o altri enti.

Altre modifiche di generalizzazione riguardano il diagramma entità-relazioni (che descrive il modello di dati) del Catalogo SSU. Nell’immagine a pag. 12 delle specifiche (riportata qui sotto) queste sono evidenziate in rosso.

Da notare, sempre con la premessa “perché non pensarci prima?”, che l’entità “Sportello SUAP” è rinominata in “Sportello SSU” e la specificazione se sia sportello SUE o SUAP è demandato all’attributo “contesto” di cui si è detto prima.

Altre modifiche riguardano aspetti più di dettaglio. Vale la pena però evidenziare che, per espressa ammissione delle specifiche, non c’è stata un’attenta analisi dei workflow (flussi) procedurali dei procedimenti SUE^[12]Testualmente, da pagina 19 delle specifiche: “alla data di stesura del presente documento non sono stati definiti workflow specifici per il contesto SUE, pertanto si aggiunge una chiusura di … Continue reading e, di conseguenza, non esiste un elenco tassativo degli stati in cui può trovarsi l’istanza di un procedimento. per questo (si veda a pag. 19), quando un attore SUE aggiorna lo stato della pratica ha a disposizione anche l’opzione “ended_by_generic_conclusion”^[13]Eh, sì, il SUE parla inglese. che può essere ulteriormente specificata con una stringa di testo libero. C’è solo da confidare nella perizia di chi compilerà queste voci in modo che la “conclusione generica” non diventi il porto sicuro dove far approdare ogni procedimento SUE.

Alcune delle scelte sopra descritte, tuttavia, sembrano evidenziare l’affanno PNRR-correlato con cui si è voluta presentare la revisione di SUAP e SUE che, probabilmente, poteva avere un maggior livello di coordinamento sin dalla fase iniziale. Del resto anche i tempi previsti dall’avviso PNRR per completare le operazioni di adeguamento dei sistemi (120 giorni dall’individuazione dell’operatore economico a cui affidare l’incarico) hanno una loro intrinseca dose di ansiogenità.

E-service coincidenti o distinti?

Torno un attimo nelle questioni nerd, chi vuole può saltare il paragrafo.

Direi che a livello di implementazione informatica delle specifiche si pone un primo problema: se ho un software che sovrintende contemporaneamente a funzioni SUAP e funzioni SUE, devo elaborare due servizi distinti che restino in attesa delle chiamate delle componenti informatiche di altri enti? Devo comunque rendere disponibili tramite PDND due e-service distinti (uno per le finalità SUAP e un per quelle SUE) anche se questi condividono lo stesso endpoint?

Il fatto che le definizioni delle interfacce siano le stesse e che le informazioni richieste nei payload siano state integrate con la specificazione del contesto, sembrerebbe stare a significare che ci si attende che uno stesso servizio in ascolto possa ricevere indistintamente comunicazioni SUAP e comunicazioni SUE (altrimenti non c’era bisogno di specificare ogni volta il contesto).

Poiché però le definizioni in formato OpenAPI hanno nomi e intestazioni diverse per SUAP e SUE, sembrerebbe che sulla PDND debbano finire pubblicati due e-service diversi, che poi punteranno allo stesso servizio informatico, pronto a ricevere scambi SUAP e scambi SUE.

Se questa lettura è corretta, tuttavia, emerge, almeno a livello teorico, una complicazione su come gestire le autorizzazioni all’uso del servizio. Se ho fatto accordo di fruizione solo per l’e-service SUE, il servizio non deve consentirmi di inoltrare comunicazione che, nel payload, hanno la chiave “context” valorizzata con il valore “SUAP”. Ma questi sono dubbi che, volentieri, lasciamo a fornitori e sviluppatori…

La modulistica

Quando l’intervento di digitalizzazione SUAP e SUE parla di modulistica, non si riferisce, ovviamente, alla messa a disposizione di documenti PDF pronti da stampare per essere compilati a mano. Non si riferisce nemmeno a moduli online (form) da compilare a video. Si riferisce invece alla definizione di regole per creare questi ultimi, soprattutto a livello di contenuto e di logica di compilazione e successiva validazione.

I moduli, compilati attraverso il front-office SUE, una volta completati dovrebbero viaggiare verso il SUE nel duplice formato di documento testuale (PDF) firmato digitalmente e di documento XML che contiene gli stessi dati contenuti nel documento testuale ma in forma strutturata e immediatamente interpretabili da un sistema automatico.

La modulistica di cui parlano le specifiche si riferisce esattamente alla struttura e al contenuto dei documenti XML. Tramite la definizione di schemi XML sia tramite i tradizionali XML-Schema in formato XSD sia tramite più sofisticati modelli Schematron (che consentono anche di definire elementi che possono esserci o non esserci a seconda dl verificarsi di determinate condizioni), l’ecosistema SSU dà un nome esatto agli elementi che compongono un modulo, fornisce vocabolari controllati per compilare alcune voci, organizza i moduli in sezioni che sono riutilizzabili con la stessa struttura in moduli diversi (per esempio: la sezione anagrafica del richiedente, la localizzazione dell’intervento). Per inciso, a detta di chi ci lavora, la creazione dei form online compatibili con schemi XML e Schematron non è propriamente una passeggiata di salute.

Se sono chiare le regole per descrivere le regole dei moduli, non è altrettanto chiaro dove siano i moduli esistenti e chi si occupa di realizzarli. Per il SUAP, anche tramite successivi chiarimenti, si è capito che lo Stato (Conferenza Stato-Regioni) licenzia la modulistica nazionale di base e la deposita nel Catalogo SSU. Poi, con apposito procedura, le Regioni apportano le modifiche necessarie per adeguarli alle normativa regionale. I singoli SUAP, poi, con analoga procedura, possono personalizzarli ulteriormente per soddisfare ulteriori specificità locali. chiaro però chi fa i moduli, per il mondo SUAP è stato esplicitato il modello (almeno teorico) in cui lo Stato fa della modulistica, le Regioni la adattano alla normativa regionale, i singoli SUAP (anche su impulso degli enti terzi ai quali spesso e volentieri fanno da mero passacarte) li adeguano a specificità locali.

E per i SUE? A chi spetta l’iniziativa? Lascio la domanda aperta, senza risposta (e la domanda non è nemmeno eccessivamente retorica).

Fa però un po’ riflettere e preoccupare quanto si legge nelle Linee guida per l’operatività degli Sportelli Unici dell’Edilizia nel SSU redatte da Unioncamere, a pag. 6: “Anche in ambito SUE i Front Office dovranno essere in grado di gestire procedimenti con moduli strutturati e procedimenti con moduli non strutturati. In quest’ultimo caso, le componenti Front Office, Back Office ed Enti Terzi non potranno eseguire la validazione della form^[14]Per Unioncamere (e non solo), form è femminile: anglismi in cerca di identità di genere (“su Rieducational Channel”, chioserebbe Vulvia). che riporta i dati della pratica compilata dall’istante^[15]Qui “istante” non sta per “attimo” ma per “colui che presenta l’istanza”, dove “istanza” torna ad avere il significato giuridichese di … Continue reading. Eventuali necessità di elaborazione dei dati da parte delle componenti informatiche destinatarie della comunicazione necessitano della condivisione dei tracciati tra le amministrazioni.”. Il fronte di preoccupazione è duplice:

• si apre alla presentazione di moduli privi di dati strutturati, fatto che fa morire sul nascere ogni possibilità di automazione e, quindi, non solo di velocizzare i processi, ma, soprattutto, di rendere più preciso e accurato il contenuto informativo: si sa, l’operatore umano (esageriamo) tende a scrivere tutte le informazioni che gli servono in un unico campo, magari nel campo “note”, perché, in effetti, a colpo d’occhio è più semplice, almeno nell’immediato. Poi non si possono fare ricerche sensate o elaborazioni statistiche, ma uno se ne rende conto solo dopo…
• si rimanda alle amministrazioni la condivisione dei tracciati per elaborazioni dei dati (strutturati?): non è chiaro se si richieda una condivisione locale fra amministrazioni che insistono per competenza su un medesimo territorio o una condivisione ad alto livello. E quei contesti regionali in cui esiste una modulistica ufficiale? Il sistema sarà in grado di recepirla e non vanificare gli sforzi fatti? E la modulistica che, in assenza di standard cogenti, è stata elaborata dai fornitori più attenti all’intero processo? E ancora: una soprintendenza o una ASL che riceve richieste di pareri da una pluralità di SUE del territorio che, in linea teorica, potrebbero scambiare documenti con dati strutturati con un proprio tracciato, come potrebbe mai automatizzare l’istruzione delle pratiche di sua competenza?

L’affermazione delle linee guida di Unioncamere suona molto come ammissione di essere ancora in alto mare. Va anche detto che, a rigore, i moduli non strutturati non sembrerebbero esattamente previsti nelle specifiche tecniche. Non lo erano nemmeno in quelle SUAP, eppure l’affermazione fatta da Unioncamere per i SUE ricalca quanto è emerso nel dibattito che ha accompagnato la realizzazione dell’intervento di digitalizzazione del SUAP.

ll sistema sarà sostenibile?

Anche la domanda conclusiva, non retorica, la lascio senza risposta.

Non sono in grado al momento di dare una risposta. Da un lato, replicare il modello SUAP anche al contesto SUE è sensato, visto che proceduralmente i due mondi si assomigliano molto e non ci sono state grandi levate di scudi sulla revisione SUAP, forse anche perché il percorso parte da molto più lontano e si pone in un contesto in cui è presente, forte, un soggetto istituzionale nazionale. Dall’altro, ragionevolezza a parte, le strade SUE e SUAP sono state fin qui distinte e hanno raggiunto livelli e modalità diversi di digitalizzazione: alcune regioni hanno investito su front-office per un mondo ma non per l’altro, allo stesso modo il mercato ha sviluppato ora soluzioni più complete da una parte e non dall’altra. C’è poi la questione della mancanza della modulistica (che dovrebbe essere il motore dell’interoperabilità), ed è da vedere se il sistema è in grado di salvaguardare quanto fatto a livello locale e magari estenderlo (grazie alla standardizzazione della definizione delle regole e al Catalogo SSU) a beneficio di chi nel frattempo è rimasto indietro.

Se si guarda alla sostenibilità a lungo termine, quello che mi sento di dire è che, necessariamente, occorre integrare la mirabolante interoperabilità degli sportelli unici con i sistemi di gestione documentale, cioè con gli archivi degli enti coinvolti e riscoprire quella dimensione archivistica che è in grado di resistere al tempo e superare i cambiamenti tecnologici e gli avvicendamenti di soluzioni software.

Foto di Peggy und Marco Lachmann-Anke da Pixabay