SUAP: se il mio protocollo aveva le ruote era un…

Torno a parlare di digitalizzazione degli sportelli SUAP, visto che da qualche giorno è uscito l‘avviso PNRR rivolto ai comuni chiamati ad adeguare i software di back-office degli uffici che intervengono con pareri, prese d’atto, autorizzazioni e simili nei procedimenti SUAP.

Cosa è la digitalizzazione degli sportelli unici SUAP (e SUE)

Il percorso di nuova digitalizzazione degli sportelli unici SUAP (e in prospettiva, non si sa bene come^[1]Non si tratta di malfidenza, ma dell’osservazione che gli sportelli SUAP hanno una disciplina comune a livello nazionale – a partire dal dpr 160/2010 -, mentre l’edilizia privata e … Continue reading, anche SUE) parte nel 2021 con l’aggiornamento dell’allegato al dpr 160/2010, che preannunciava la pubblicazione di norme tecniche di dettaglio per aiutare la circolazione di dati e documenti fra i soggetti coinvolti nei procedimenti SUAP e superare lo scambio, spesso impossibile anche solo per le dimensioni, di documenti con dati non strutturati tramite i canali più disparati.

Ne ho parlato in vari altri post qui sul blog e anche in eventi di formazione e divulgazione.

Anche l’Agenzia per l’Italia digitale ha realizzato delle pillole video che spiegano, anche a un pubblico di non esperti di trasformazione digitale (quali, per esempio, i responsabili SUAP e i titolari degli uffici comunali coinvolti) in cosa consiste questa “riforma”. Una playlist di video è qui: https://www.youtube.com/playlist?list=PL8wcCbvx01fC-DncztBTPlL3-ySZ3QNQb. Dispiace e fa riflettere il fatto che abbiano ben poche visualizzazioni^[2]Il video che ho messo in evidenza, al momento in cui scrivo, ha poco meno di 500 visualizzazioni in 4 mesi. Quello un po’ più di dettaglio sui documenti strutturati addirittura meno di 200. La … Continue reading. Peccato, perché sarebbe utile per tutti avere una base comune di conoscenza. Qui una introduzione molto generale:

Qualche “a parte che”

Così per liberare la mente da dubbi più o meno queruli, dichiaro subito gli “a parte che” di sfogo:

• a parte che c’è qualche disorientamento temporale: il progetto di digitalizzazione del SUAP doveva terminare 12 mesi dopo la pubblicazione delle specifiche (cioè verso fine 2024); poi 12 mesi dal collaudo del Catalogo SSU e quindi data perentoria il 25 (o 26?) luglio 2025 per essere tutti belli e operativi a parlare interoperabile; adesso l’avviso PNRR dà 270 giorni – che partono dal decreto di finanziamento – quindi si va a dicembre 2025. Poco male, perché qui interessano più gli aspetti funzionali e documentali dell’intera faccenda;
• a parte che non si capisce come mai da anni e anni ci vengono a dire che si devono usare strumenti informatici (software) erogati in modalità cloud come Software as a Service, quindi senza possedere niente ma solo il diritto di usare – come si fruisce di altri tipi di servizio pagati come spesa corrente – un software che gira sui server del fornitore in modo uguale per tutti i clienti con stesse logiche e funzioni, e poi il PNRR finanzia i comuni, con contributi da contabilizzare come fondi per investimenti, per adeguare oggetti (i software) non loro, che oggi usano ma che domani (in senso letterale) potrebbero dismettere per usarne altri analoghi (anche perché c’è il principio della rotazione affermato dall’approccio italiano ai contratti pubblici…)
• a parte che si continua a ignorare che questi processi producono e gestiscono documenti e andrebbero integrati o, meglio, gestiti a livello di sistema di gestione informatica dei documenti…

La componente back-office enti terzi

Nell’architettura complessiva del Sistema Informatico degli Sportelli Unici (SSU) che sta vedendo la luce, gli enti terzi sono quelli che entrano nel merito delle pratiche SUAP che, in linea ideale, sono pratiche complesse (articolate) che richiedono l’intervento di più enti che rilasciano pareri o autorizzazioni (evidentemente parziali, rispetto al provvedimento finale di competenza del SUAP). Gli enti terzi devono dotarsi di interfacce informatiche realizzate secondo le specifiche SSU per scambiare dati (documenti e informazioni relativi alle pratiche) con il back-office SUAP, lo sportello unico titolare del procedimento che fa da nodo di smistamento senziente fra l’impresa e le amministrazioni di volta in volta da coinvolgere. Tutti gli scambi devono avvenire solo ed esclusivamente tramite queste interfacce che, oltre ai documenti, consentono di scambiare dati strutturati di accompagnamento che, quanto meno, tracciano lo stato di avanzamento della pratica. Infatti, a ogni scambio fra SUAP ed enti terzi, si aggiorna lo stato della pratica sulla componente Catalogo SSU del sistema informatico degli sportelli unici. In realtà, quindi, l’interfaccia componente back-office ente terzo dialoga, bidirezionalmente, sia con il back-office SUAP sia con il Catalogo SSU, che risulta un po’ il cervellone che tutto sa del mondo SUAP prossimo venturo.

Anche se sarebbe opportuno suffragare la posizione con dati reali, è abbastanza evidente che ci sono uffici comunali che più di altri, nella loro attività, trattano con costanza procedimenti SUAP come, per esempio, l’ufficio che si occupa di commercio: le attività commerciali con cui interagisce sono imprese che, salvo rare eccezioni, “passano” attraverso il SUAP. Ci sono, di converso, procedimenti SUAP che niente hanno a che fare con il comune non hanno niente a che fare se non, per l’appunto, come punto ingresso e di uscita: in questi casi lo sportello SUAP comunale, stando alla teoria del modello operativo dello sportello unico, fa quasi da mero intermediario, magari solo per porgere a un ente terzo esterno (una ASL, per dire) una comunicazione di cui questo deve solo prendere atto e per rilasciare una ricevuta. Nel mezzo ci sono varie sfumature e uffici comunali che sono chiamati a intervenire in procedimenti SUAP con bassa frequenza.

L’iscrizione al Catalogo SSU che gli enti, comuni inclusi, che interagiscono con il mondo SUAP sono tenuti a fare dovrebbe essere l’occasione buona per fare un censimento preciso di quanti e quali uffici partecipano a procedimenti SUAP, a quali procedimenti partecipano e con quali modalità comunicano con lo sportello SUAP comunale.

Quale componente per gli uffici comunali

Limitandoci al mondo comunale, poi, a un certo punto, è necessario stabilire con quali strumenti, nell’ambito del nuovo sistema di comunicazione interoperabile SUAP, gli uffici che operano come “enti terzi” dialogheranno e si scambieranno dati e documenti con il SUAP. L’ufficio comunale dovrà dotarsi di un software gestionale ad hoc che, nella logica SSU, è detto “componente back-office ente terzo”? Oppure, in caso di SUAP comunale singolo e ufficio dello stesso comune, si può pensare di continuare a usare comunicazioni interne, come, per esempio, una stampa che passa in una cartellina da un ufficio all’altro, oppure più uffici che accedono alla stessa pratica su uno stesso software e ci lavorano insieme, oppure ancora un flusso fra uffici gestito all’interno del sistema di gestione documentale (nella sua veste più evoluta di sistema di gestione dei procedimenti)? A quest’ultima domanda viene subito da rispondere “no!”, perché, come detto, ogni passaggio dal back-office SUAP a un altro ufficio (anche dello stesso comune) e viceversa deve far partire una comunicazione al Catalogo SSU per aggiornare lo stato della pratica.

Allo stato attuale, in accordo con quanto raccontato nel webinar del 27 gennaio 2025 (link) e con le opzioni presenti in un questionario sottoposto ai comuni nel mese di gennaio, le opzioni per l’ufficio comunale-ente terzo sono tre:

• utilizzare la soluzione sussidiaria messa a disposizione da Impresainungiorno (che fa da front-office e back-office SUAP per gli sportelli unici che si appoggiano allo strumento informatico sviluppato da Infocamere per Unioncamere);
• utilizzare una soluzione messa a disposizione da altro ente esterno, tipicamente le regioni che – almeno alcune – mettono a disposizione dei SUAP del territorio la componente front-office e back-office con funzioni analoghe a Impresainungiorno:
• dotarsi di componenti proprie, autonome (il gestionale ad hoc di cui poco sopra).

Ora, la soluzione sussidiaria – lo dice anche il nome – è qualcosa di residuale, una ruota di scorta che resta del tutto slegata dal sistema informativo comunale (o dell’ente realmente terzo) e che quindi, banalmente, non consente nemmeno di protocollare e archiviare la documentazione ricevuta o inviata. Ora, detto e ridetto, un procedimento di un ufficio comunale, se pure inserito in un procedimento complesso SUAP, produce senz’altro documentazione che merita di rimanere nell’archivio comunale e non nel database di Infocamere. Con la soluzione sussidiaria per ottenere lo scopo sembrerebbe che si debba:

• prelevare manualmente la documentazione in arrivo;
• protocollarla per farla entrare nell’archivio;
• lavorarla con gli strumenti messi a disposizione dal sistema informativo comunale (anche solo a livello documentale, senza gestionali specifici a supporto);
• protocollarla manualmente in partenza e depositarla sulla soluzione sussidiaria.

La soluzione sussidiaria dovrebbe farsi carico di gestire i dati aggiuntivi propri del procedimento SUAP e aggiornare a ogni comunicazione il Catalogo SSU. Inoltre, pur confidando nelle immancabili notifiche via mail quando arriva qualche pratica sulla soluzione sussidiaria, l’ufficio ha un ulteriore software da tenere sotto controllo.

Lo stesso dicasi per le soluzioni regionali, per le quali, forse, potrebbero al più prevedere qualche possibilità di integrazione con il sistema informativo, almeno per la protocollazione.

Quindi, almeno da un certa dimensione organizzativa in poi, la soluzione autonoma appare quella più sensata. Dovremmo quindi dotare l’ufficio di un ulteriore software? Oppure adeguare quello che usa per le attività ordinarie in modo che possa gestire le comunicazioni SUAP? Nel primo caso, può convenire espandere ad altri uffici il software – solitamente presente – che supporta nei procedimenti di edilizia privata o in quelli relativi al commercio o all’ambiente? DI nuovo, per capire a quali uffici estendere l’uso di quel software è utile fare un censimento di procedimenti e uffici.

Se il mio protocollo aveva le ruote…

Perché scomodare, nel titolo del post, un detto che senz’altro era in voga nella Toscana di qualche decennio fa e che, forse, adesso potrebbe urtare qualche sensibilità? In tutte le tre opzioni per adeguarsi alla comunicazione interoperabile SUAP, il nostro ufficio comunale deve dotarsi di un nuovo software, imparare a usarlo e conoscerlo nella sua personalità^[3]Sì, gli applicativi in uso alla pubblica amministrazione hanno una loro personalità, spesso votata alla scarsa collaborazione e ad una giocosità cinica talvolta spinta ai limiti del grottesco. … Continue reading, controllarlo periodicamente ecc.

C’è però un applicativo che ogni ufficio comunale usa: il sistema di gestione informatica dei documenti! Non fosse altro che per il fatto che ogni ufficio comunale, qualunque cosa faccia – più o meno – produce documenti.

Se avessimo un sistema di gestione documentale fatto come, da almeno venti anni, ci viene proposto e richiesto dalla normativa, probabilmente saremmo già un passo avanti e riusciremmo a gestire anche l’evoluzione al SUAP interoperabile senza grandi sforzi implementativi e, soprattutto, in modo trasparente per gli utenti.

Cosa servirebbe? In primo luogo un protocollo informatico collegato a un catalogo dei procedimenti che, fondamentalmente, non esiste. Censiamo processi e procedimenti per svariati fini:

• per l’esposizione in Amministrazione trasparente del loro elenco corredato di tempi di conclusione, ufficio responsabile e soggetto che esercita il potere sostitutivo in caso di inerzia;
• per la pubblicazione sul sito internet delle schede dei servizi, che sono, nel modello nazionale di sito comunale, la faccia del procedimento da esporre, con comunicazione incisiva, al cittadino e all’impresa che vuole informarsi sul “come fare”;
• per mappare il rischio corruttivo nel piano di prevenzione della corruzione ora confluito nel PIAO (Piano Integrato di Attività e Organizzazione);
• per produrre il registro dei trattamenti di dati personali come richiesto dal GDPR (General Data Protection Regulation);
• …

Tuttavia, non c’è minimamente cultura di usare un catalogo dei procedimenti unico che sia funzionale a tutto^[4]Qualcosa al riguardo avevo scritto qui: Tassonomie e titolario e possibilmente ancorato al titolario (piano di classificazione) e a organigramma e funzionigramma del comune. Questo è un grande limite, ma, se non si parte da qua, continueremo ancora a lungo a mettere di volta in volta pezze per far fronte a situazioni di urgenza.

Come potrebbe funzionare il “protocollo con le ruote”

Il back-office SUAP, comunque sia strutturato e qualunque soluzione informatica adotti per la comunicazione, in definitiva manda “un pezzo” di pratica SUAP a un ufficio comunale e lo fa invocando un endpoint (che poi è un indirizzo web, più o meno), disinteressandosi totalmente di cosa c’è dietro quell’endpoint, perché il bello della comunicazione interoperabile standardizzata è proprio che si parla con tutti allo stesso modo. L’endpoint potrebbe quindi essere quello esposto dal protocollo informatico, che poi sarebbe, in un certo senso, l’interfaccia orientata al mondo esterno del sistema di gestione documentale.

Il protocollo riceve il dato strutturato secondo le regole SSU e riconosce che si tratta di un procedimento SUAP. Dal catalogo dei procedimenti individua sia l’ufficio a cui smistare la registrazione, sia le modalità per gestire il documento registrato (a partire dalla fascicolazione, per dire), sia cosa comunicare al Catalogo SSU. Quando l’ufficio, semplicemente lavorando come ha sempre fatto, prende in carico il documento il protocollo informatico fa partire un ulteriore aggiornamento al Catalogo SSU. Quando poi l’ufficio ha completato la sua istruttoria, registra a protocollo il suo “parere” (o altro tipo di documento) collegandolo alla registrazione in arrivo^[5]Solitamente i sistemi di gestione documentale / protocolli informatici hanno fra le funzioni di base quella di collegare un protocollo in partenza al protocollo in arrivo a cui risponde, il più … Continue reading, il protocollo sa che deve indirizzare la comunicazione all’endpoint del back-office SUAP e non, per esempio, a un indirizzo PEC o e-mail, oltre che darne notizia al Catalogo SSU. Si fa quindi carico del dialogo interoperabile con lo sportello SUAP da una parte e con il Catalogo SSU dall’altra. Ovviamente, in questo processo appena abbozzato a mo’ di ipotesi, la stabile acquisizione dei documenti nell’archivio comunale è assicurata, senza ulteriori passaggi o duplicazioni.

In questo modo, che la richiesta di parere o autorizzazione sia inserita o meno in un procedimento SUAP, che venga da un’impresa o addirittura da un cittadino, per l’ufficio comunale non cambia niente, la modalità operativa resta invariata. E’ lo strumento informatico che si fa carico di gestire le differenze di contesto procedimentale e tecnologico, l’ufficio si concentra invece sul merito delle questioni.

A questo dovrebbe mirare la trasformazione digitale e non, invece, ad aggiungere ogni giorno un pezzo in più!

Foto di vincenzo adragna da Pixabay